Wikipedia:バグの報告/2016年

リンクを追加

Wikipedia空間に存在しないページが検索候補にあがる[編集]

特別:検索で「Wikipedia:さ」と記入するとWikipedia:さとうあきらとWikipedia:さいとうひろしという存在もしない記事が検索候補として表示されます(他にも「Wikipedia:い」と入力することでWikipedia:いとうまこと、Wikipedia:いせちか。「Wikipedia:か」では、Wikipedia:から転送など他数例が表示されます。）ブラウザーのキャッシュ・記事そのもののキャッシュは廃棄していますが、表示がそのままです。ブラウザー再起動なども効果なしでした。--組曲師（talk/ 履歴） 2016年1月1日 (金) 13:03 (UTC)

コメント 検索のアルゴリズムによるものなので、「何がダメか」というのをそれに組み込む必要があると考えられます。そうなると、この部分はローカルで開示されているものではないので仮に追加するとしてもその度にPhabricatorへ連絡してシステム上に組み込んでもらう必要が出てきます。リストで抑制することも考えることはできますが、そちらはそちられ別の空間にも影響を及ぼしてしまう可能性が出てきますし、その追加も管理者かインターフェース編集者でなければいけないので現実的ではないと思われます。特別に影響が出ているわけではない（バグではない）と思いますがどうでしょうか。--アルトクール(話/歴) 2016年2月15日 (月) 05:41 (UTC)
コメント ご回答ありがとうございます。管理者さんが関わることまでは想像していましたが、Phabricator:といった外部のプロジェクトも関わるとなるとご迷惑をおかけするわけにもいきませんし、そう考えれば現行のままでよろしいですね…。 --組曲師（talk/ 履歴） 2016年2月16日 (火) 09:31 (UTC)
コメント もっと言えば例えばウィキニュースで「ウィキニュース:ほげほげ」がページがないのに予測検索に挙がるというのと同じことなんですね。なので、ウィキペディア日本語版だけではなく、他言語版を含めた全ての姉妹プロジェクトに影響を及ぼすものになるのでなんともいえない（要望を出せば検討されるかもね？という程度）です。機能として組み込んだほうが言いと言う話があれば、ウィキペディア日本語版からの要望としてMediaWikiの開発側に提出するのがいいかなぁと思われます。--アルトクール(話/歴) 2016年2月16日 (火) 09:46 (UTC)
コメント うーん。さとうあきら、さいとうひろし、から転送、はリダイレクトとして存在するので、素直に何らかのバグだと思うのですが。「存在しないページが検索候補に出てきてしまう」という問題ではなく、「出てきてはいけないページを登録できるようにする」という問題なのでしょうか。--Frozen-mikan（会話） 2016年2月16日 (火) 09:53 (UTC)
コメント 本来、標準名前空間の（Wikipedia: プレフィックスの付かない）ページを探しているはずなのに、勝手にWikipedia: プレフィックスを付けられてしまうのは仕様として解釈しても、ユーザーの側からすれば、ありがた迷惑なような気がします。特別:検索では名前空間を指定して検索できるようになっているのに、どうかと。--Licsak（会話） 2016年2月17日 (水) 20:29 (UTC)
コメント 申し訳ありませんが、仰ってることが理解できません。本件では、名前空間付きの検索をする際に存在しないページが候補に出てきてしまう問題を取り上げているものと思います。--Frozen-mikan（会話） 2016年2月18日 (木) 07:08 (UTC)
コメント 英語版でも同様の挙動を確認できました。標準名前空間の「en:Directory of portals」が別名前空間の「en:Wikipedia:Portal/Directory」へと転送されており、なおかつ転送先のWikipedia名前空間に同名の「en:Wikipedia:Directory of portals」は存在しません。このとき、「Wikipedia:Directory of portals」が検索候補に現れることを確認しました。今回の例は「en:Category:Cross-namespace redirects」から探したのですが、他にもあるかもしれません。現時点では遭遇頻度と影響からして本件バグの重要度はあまり高くないと思っていますが、関連するバグの報告が「Phabricator」にあるかもしれません。--Frozen-mikan（会話） 2016年2月18日 (木) 07:08 (UTC)
コメント ちょっとIRCで検索の話題になったので。現在のウィキペディアというかメディアウィキの検索はグーグルの検索エンジンで検索をかけているので、根本的に解決するには新しい検索エンジンを作るとかそういうレベルになると考えられます。なので、要望としては出せますがバグとして報告するのは難しいです。それに「候補」ではなく「予測」なので、現状を考えれば候補予測を切れるかどうかを聞いてみるとかそういうレベルになるかと。存在しないページが「候補」に上がるのは問題かもしれませんが、「予測」にあがるのはそれだけ検索で使われたキーワードとして多かったということなので話が異なります。--アルトクール（会話） 2016年2月18日 (木) 07:41 (UTC)
コメント MediaWiki の内部検索はCirrusSearchというもので、自身のデータベースを参照しています。この際、名前空間名は「ページ名」としては保存されていません。名前空間は NSID 形式でページ名とは分けて保存されます。IRC での話題はおそらく、ウィキメディア財団が独自にインターネット検索エンジンを作るというもののことだと思います。--rxy（会話） 2016年2月18日 (木) 08:32 (UTC)
名前空間をまたぐリダイレクトに関して生じる誤作動として去年10月に Phabricator に報告されていました。問題ではあるが影響は大きくないとして、積み残しになっているようです。 whym（会話） 2016年2月19日 (金) 09:09 (UTC)

リンクしていない部分も青くなる[編集]

正十二面体の記事の冒頭に

[[倍数接頭辞|dodeca]]hedron

と書いたにもかかわらず、

[[倍数接頭辞|dodecahedron]]

とした時と同様、「hedron」の部分が青くなっています。

OSはWindows Vista。ブラウザはIE 9とfirefox 43.0.1双方。バグなのか仕様なのか分かりませんが、報告しておきます。--Giant2007（会話） 2016年1月7日 (木) 12:21 (UTC)

コメント 英語などの複数形その他の語尾変化を書きやすくするため（[[pencil|pencils]]を[[pencil]]sと書ける）、意図的に実装されているものです（Help:リンク#ウィキリンクとウィキ間リンクのマークアップ一覧）。--Jkr2255 2016年1月7日 (木) 12:25 (UTC)
コメント 仕様ついでに一つ。「[[倍数接頭辞|dodeca]]hed<nowiki />ron」のように、あふれたリンクを区切りたい箇所に<nowiki />を入れておくと、「dodecahedron」と表示されます。--Frozen-mikan（会話） 2016年1月7日 (木) 15:34 (UTC)
ありがとうございます。早速当該項目をなおしました。 --Giant2007（会話） 2016年1月8日 (金) 00:33 (UTC)

「小口忠彦」のページ[編集]

解決済み

小口忠彦の各節名の後ろの「編集」が大きいフォントで表示されていて、リンクも機能しません。--Tatsubou（会話） 2016年1月29日 (金) 12:54 (UTC)

空編集したら直りました。--tomato tomato tomato（会話） 2016年1月29日 (金) 13:03 (UTC)
早速の対応ありがとうございます。--Tatsubou（会話） 2016年1月30日 (土) 02:43 (UTC)

閲覧回数[編集]

解決済み

ページの左側にある、ページ情報>閲覧回数を選択すると internal server error になるのは、閲覧回数が廃止になるということですか?--ワーナー成増（会話） 2016年2月24日 (水) 22:56 (UTC)

コメント 詳細は不明ですが、そのサイトのトップページ [1] は稼働しています。何らかの問題があって個々のデータを表示できない状態にある、という程度だと思います。--Frozen-mikan（会話） 2016年2月25日 (木) 03:54 (UTC)
そのサイトの管理をしていると思われる Henrik さんの 会話ページ を見ていただければわかるかと思いますが、更新が停止し、管理されていないようです。toollabs:pageviewsをご利用ください。MediaWiki:Pageinfo-footer と MediaWiki:Statistics-footer を書き換える必要がありますね。--rxy（会話） 2016年2月25日 (木) 10:28 (UTC)
御二方コメントありがとうございます。toollabs:pageviewsは英語版でも使用したのですが、いつまでも実行中で使い方が分からなかったのですが、 Pageviews Analysis – FAQにある Why do I need to disable my ad blocker? に従って、アドブロックを停止させたら実行出来ました。Project にja.wikipedia.org を、Pages に Wikipedia:バグの報告 を設定すると、結果、Wikipedia:バグの報告の閲覧回数が取得出来ました。ありがとうございました。--ワーナー成増（会話） 2016年2月26日 (金) 09:20 (UTC)

節の見出しの横にある編集リンクの表示について[編集]

節の見出しの横にある、節単位の編集画面に移動するリンクに関することです。通常は「見出し [編集]」のように表示されますが、一部の記事では「見出し編集 」という表示になってしまっています。具体例としては海保帆平、常滑市立図書館、八幡山城、ハインツ・ヨスト、電源回路、電流源です。スキンやブラウザを変えてみても同様でしたが、バグでしょうか。--Qurren（会話） 2016年3月8日 (火) 09:08 (UTC)

情報 空編集をすれば一時的には直りますが、根本的な解決にはならないようです。#「小口忠彦」のページで同じ報告がありました。--Wjp28y（会話） 2016年3月8日 (火) 09:13 (UTC)
情報提供ありがとうございます。たった今、上記記事を再度参照したところ、すべて正常に戻っておりました。空編集の履歴はありませんでしたので、一時的なものだったようです。「おまかせ表示」を繰り返していると、同様の問題が生じている記事が他にも存在しているようで、少々気になります。--Qurren（会話） 2016年3月8日 (火) 09:25 (UTC)
m:Tech/News/2016/10/ja にも記されているとおり、phab:T124356 に上がっています。?action=purge をすればそのページでは治るかと思います。他の同様の現象が起きているページも、ページの編集やキャッシュ期限切れ、または ?action=purge 等によってキャッシュが破棄されれば、同様の現象は発生しなくなるはずです。--rxy（会話） 2016年3月8日 (火) 14:46 (UTC)

混同テンプレート内で仮リンクテンプレートを用いると不要な(?)ダブルブラケット[[ ]]が現れる[編集]

解決済み

サンマルコス砦　先頭行です。ソースも確認ください。実害は有りません。見栄えだけの問題です。--Momijiro（会話） 2016年3月9日 (水) 11:25 (UTC)

とりあえず
  • {{混同|:en:Castle of San Marcos (El Puerto de Santa María){{!}}サンマルコス城}}
このような回避策はいかがでしょう？--Triglav（会話） 2016年3月9日 (水) 11:33 (UTC)
コメント バグではなくテンプレート内の引数の取り方の問題です。{{混同}}では引数に指定した文字列をウィキリンクにするようにテンプレートが構成されています。そのため、混同の引数にウィキリンクする構文（{{仮リンク}}だけでなく、単純に[[Wikipedia:バグの報告]]と入れても同様の現象がおきます。（後者の場合はウィキリンクはされるが、[[ ]]が表示で残ります）
つまり、{{混同}}では引数にウィキリンクを内包するようなリンク用テンプレートの使用を許可していないのです。
そのため、引数にウィキリンクをそのまま使える{{簡易区別}}を使って{{簡易区別|{{仮リンク|サンマルコス城|en|Castle of San Marcos (El Puerto de Santa María)}}}}と書けば、おそらく意図した表記にすることが可能になります。Triglavさんの回避方法とはスタイルの違いですので、このあたりは好みになるかと思われます。--アルトクール（会話） 2016年3月9日 (水) 11:52 (UTC)

早速有難うございます。試してみました。

「サンマルコス城」とは異なります。 Triglavさんの方法
サンマルコス城とは異なります。　アルトクールさんの方法
鍵括弧はある方が良いと思ったのでTriglavさんの方法で修正致しました。--Momijiro（会話） 2016年3月9日 (水) 12:16 (UTC)

svgとframe[編集]

カーネル密度推定にあるsvgがどういうわけかキレイに表示されていません。どうやらframeをつけると画質が落ちるようです（下図：比較例）。

これはバグなのでしょうか？ --ARAKI Satoru（会話） 2016年3月25日 (金) 12:38 (UTC)

質問への回答にはなっていませんが、thumbではきれいに表示されると思います。--Yapparina（会話） 2016年4月24日 (日) 09:47 (UTC)
[[File:Parzen window illustration.svg|center|thumb|620px]]
コメント 状況としては、frameにすると元のsvgのサイズである620pxのpngで表示されますが、何も指定しない/thumbだと930pxと1.5倍になってから縮小表示しているので、前者だけ汚く見えるという状況のようですね。バグと呼ぶには少々微妙（おそらく仕様？）な気がします・・・・。--青子守歌（会話/履歴） 2016年4月24日 (日) 11:33 (UTC)
青子守歌さんのコメントと前後しますが、Phabricatorにこの問題を報告しました。とりあえずご報告まで。 --ARAKI Satoru（会話） 2016年4月24日 (日) 11:48 (UTC)

画像の削除依頼ができない。[編集]

ある画像 (.jpg) を削除依頼に出したいのですが、Wikipedia:削除依頼にある手順通りにファイル:Sakujo-note-2.jpgの画像を保存後、当該画像のページにアップロードしようとしましたが、

[2d88e52c189589eadf144f8a] 2016-04-01 05:56:51: 種別「UploadStashFileException」の致命的例外

という内部エラー警告が出てアップロードできません。

これでは削除依頼が出来ないので改善、もしくは回避する方法を教えて下さい。--M-sho-gun（会話） 2016年4月1日 (金) 06:03 (UTC)

コメント 試してみたところ、確かに内部エラーを吐き出します。（おそらく同じ方法で回避していると思いますが）警告を無視してアップロードを行うことでひとまずエラーを回避することができます。おそらくですが、アップロードにおけるエラーの内部判定の動作で致命的なエラーが発生しているようで、この動作をスキップすることで回避しているものと考えられます。まずは回避方法と言うことで。--アルトクール（会話） 2016年4月1日 (金) 06:15 (UTC)
アルトクール様、ありがとうございます。先ほど、ブラウザをIEに変更したところアップロードに成功いたしました。参考までにエラー発生時の環境はOSがWin7(SP1)、ブラウザがFirefox42.0です。--M-sho-gun（会話） 2016年4月1日 (金) 06:19 (UTC)
エラーの発生状況の説明が足りなかったかもしれないので追記いたしますと、上記環境で「画像をアップロード」ボタンをクリックすると警告画面を飛ばしてエラー画面に異動してしまいます。IEだと普通に警告画面に移行し無事アップロードすることが出来ました。--M-sho-gun（会話） 2016年4月1日 (金) 06:43 (UTC)
コメント 本来は「アップロードボタンを押す」→「警告画面」→「アップロード」の順番なんですが、Firefox42（私は45ですが）では「警告画面」、つまり「エラーの内部判断を行おうとするステップ」でエラーを引き起こしていると考えられます。ほかにも事例があればバグ（特定環境でのバグ？）と断定できるのですが、まだこのファイルだけですので様子を見る方向で・・・。--アルトクール（会話） 2016年4月1日 (金) 06:50 (UTC)

なんか時間が違います[編集]

自分の投稿履歴を見ていたら、５分前ぐらいに投稿したばかりなのに、PCの時間と投稿された時間が全く違います。家の時計でも確認しましたが、やっぱり違うように思えます。確認をお願いします。 PCは、Win8.1、EnternetExplorer11で見てます。----以上の署名のないコメントは、浦賀真希（会話・投稿記録）さんが 2016年4月8日 (金) 11:33 (UTC) に投稿したものです。

  • ウィキペディア日本語版では、時間は日本標準時ではなく協定世界時をシステムで採用しています。日本時間から-9時間したものが表示されていれば正常です。なお上部に表示されている「個人設定」で+9時間に設定すると日本時間で表示されます。--Vigorous action （Ｔａｌｋ/History） 2016年4月8日 (金) 11:46 (UTC)

長澤和輝のページ[編集]

個人成績のところがおかしいです。Ｊ２リーグのはずがドイツになってしまいます。--以上の署名のないコメントは、Tanayu 12（会話・投稿記録）さんが 2016年4月9日 (土曜)18時59分 (UTC) に投稿したものです（221.118.39.112による付記）。

  • ここは記事の間違いを指摘する場所ではありません。 「長澤和輝」のノートでおねがいします --221.118.39.112 2016年4月10日 (日曜) 03時30分 (UTC)

whois[編集]

解決済み

前提として私はISPに詳しくありません。ISPを調べる時に[2]を使っています。ここではISPはわかりますが、都道府県はわからないようです。ですので、私が貼るISPタグはOCNまでです。しかし他の方は、何か他の方法を使って、ISPと都道府県まで調べて、ISPタグに反映されています。利用者‐会話:153.149.239.146での会話によれば、この件で「whois」という単語が出てきました。whoisとはIP:153.149.239.146（会話 / 投稿記録 / 記録 / Whois）のIPv4とかIPv6の事でしょうか？以前よりリンク先をクリックしても「Validation Required」と表示されるので（今回も確認しました）、この機能は使えないのかと思っていました。荒らし（行為で過去2回ブロックされている）の言う事なので信憑性はわかりませんが、本来は使えるのに、私の環境からは使えない、であれば、環境に依存するバグの報告かと思い、こちらに参りました。opera12.系です。--JapaneseA（会話） 2016年4月10日 (日) 08:32 (UTC)

どうみても MediaWiki 関連のバグではないですよね…。オフトピ気味な気もしますが、"Validation Required" は私の環境でも表示されます。ここの CAPTCHA （チェックマークかもしれません）をクリアすれば、結果が表示されます。これ以上は完全にオフトピになるので避けておきます…。--rxy（会話） 2016年4月10日 (日) 09:23 (UTC)
すみません、これ、Wikipediaと無関係リンクでした。ですので、仰るようにオフトピでした。なお、私の環境では、画面がどこもクリックできず動作しないのですが、オフトピですので解決とします。なお、余談ですが、[3]でやれば、都道府県も表示される事がわかりました。以上、ありがとうございました。--JapaneseA（会話） 2016年4月10日 (日) 10:03 (UTC)脱字修正--JapaneseA（会話） 2016年4月18日 (月) 05:24 (UTC)


標準名前空間で"*"による箇条書き末尾がテンプレートのときに次段落の冒頭がリンクだと間の多重改行が無視される[編集]

表題の通り、例えば

文頭がリンクで始まる、字下げ（:）の無い段落。

↑このような構成の編集を標準名前空間で行いますと、間の改行がすべて無視されてしまい、次段落が箇条書きと繋がって

  • 箇条書き[要出典]文頭がリンクで始まる、字下げ（:）の無い段落。

のように表示されてしまいます。多重改行を行っても効果なしです。Wikipediaでは年号を先頭に持ってくる文章が頻繁に見られ、しかも年号には慣習的にリンクを付けることが多いので厄介です。

どういうわけか、この現象の発生は名前空間に依存する様子です。この場（Wikipedia名前空間）はもちろん、ノートページや利用者サブページでは再現できない様子です。今のところ標準名前空間でしか確認できていませんが、標準名前空間のテスト投稿は禁止されていたかと思うので、私もプレビューでしか確認していません。

Javascriptの有無は関係なく、スキンはベクターとモノブックを試しましたが変わりません。非Windows環境の異なるブラウザでも同様でした。

テンプレートによっては{{sup}}のように大丈夫なものもありましたので、もしかしたらテンプレート側のバグも考えられますが、{{要出典}}以外にも{{要説明}}や{{要検証範囲}}などを使っても同じでしたので、メディアウィキ側のバグの可能性も考えられます。そうでなければ同じようなバグテンプレートが量産されているということになってしまいますので厄介です。実用上はテンプレートの直後では改行せず、空白なり無意味なコメントなりを入れてから改行すれば回避はできるようですが、不可解な問題ですので一応ご報告しておきます。--Gwano（会話） 2016年4月17日 (日) 12:50 (UTC)

報告 一部のテンプレートに起こりうるバグだと思います。まずMediaWikiでは「カテゴリの前後にある改行を含む空白が無視される」という仕様があり、要出典ではテンプレートの最後にカテゴリを挿入する形になっているものと思います。ご指摘の状況に照らし合わせると、要出典にあるカテゴリが直後の改行を無視してしまい、前後の文章をつなげる役目を果たしてしまっていたものと思われます。取り敢えず、処置[4]を行いましたのでご確認下さい。--Frozen-mikan（会話） 2016年4月17日 (日) 13:13 (UTC)
（確認） 手早い対処に感謝します。取り急ぎ、{{要出典}}・{{要説明}}・{{要検証}}あたりでプレビューを見る限りは改行されていることを確認いたしました。しばらく様子を見てみたいと思います。--Gwano（会話） 2016年4月17日 (日) 16:33 (UTC)

カテゴリが設定されないことがある[編集]

問題内容はTemplateのカテゴリが設定されないこと。

方法１、Templateを書いてから 新規に/docを作ってカテゴリを設定する
方法２，既にあるTempalteからカテゴリを削除し、新規に/docを作ってカテゴリを設定する

このいずれかの方法で、カテゴリが設定されないテンプレートが出てきます。 修正方法は、Templateを１文字だけ空白を削除して再登録するとカテゴリが登録されます。 /docをいじってもカテゴリには登録されません。おそらくデータベースのトリガの設定だとは思いますが、あまりに頻度が高いので気になります --にょろん（会話） 2016年4月25日 (月) 10:15 (UTC) これは仕様なのでしょうか？

Help:キャッシュ破棄は試されましたか？もしまだなら一度試してください。--Vigorous action （Ｔａｌｋ/History） 2016年4月25日 (月) 10:43 (UTC)
キャッシュ破棄は、Templateの/docはやってます。Categoryはキャッシュを破棄を入れてやってます。また、空編集とおなじことは結果的にやってますが全く無効です。通常であれば時間が経てば反映されることもあるのですが、これについては一度反映されなくなったら二度とカテゴリーに載ることはない種類のものと思われます。誰かがそのテンプレートに書き込まないかぎり。--にょろん（会話） 2016年4月25日 (月) 12:54 (UTC)
コメント MediaWikiではテンプレート呼び出しとカテゴリとの相性はあまり良くないようですが、テンプレート本体のカテゴリが表示されないのであれば、テンプレート本体のキャッシュ破棄（空編集）をお試しください。参考までに、長らく反映されてないテンプレートやカテゴリは有りますでしょうか。--Frozen-mikan（会話） 2016年4月25日 (月) 13:48 (UTC)
私が気がついているものは昨日のうちに直してしまっているので、また現象が起きたらここに報告させていただきます。--にょろん（会話） 2016年4月26日 (火) 13:56 (UTC)

記録の閲覧について[編集]

数時間前からか昨日からか定かではありませんが、ページの履歴が表示できません。おそらく標準空間、ノート、Wikipedia空間等、どこのページでもそうです。ウォッチリストも閲覧できません。リンクをおすと途中で読み込みが停止し、ブラウザが動作停止を起こします。

環境はiOS7.1.2、ブラウザはSafari、Google検索アプリ等を試しましたが、何れも同じ症状が現れます。ログオフ状態でも同様なため、外装設定の問題ではないかと思われます。--Karasunoko（会話） 2016年4月29日 (金) 15:37 (UTC)

Windows環境（Firefox45.0.2）は問題ありません。読み込みが停止するという症状から考えて、使っている端末（iSO7.1.2ということはiPhoneを使ってるんだと思います）のメモリ不足か容量不足あたりが考えられます。端末の再起動とアプリそのもののキャッシュを破棄してどうなるかを確認した方がいいと思います。--アルトクール（会話） 2016年4月29日 (金) 15:44 (UTC)
再起動は既に試しましたが解決しませんでした。メモリ不足が原因では無いようです。--Karasunoko（会話） 2016年4月29日 (金) 15:46 (UTC)
ちなみにWi-Fiでもデータ通信でも同様です。--Karasunoko（会話） 2016年4月29日 (金) 15:49 (UTC)
かなり限定的な症状だと思われます。iOS9.3.1のSafari（iPad）では症状が再現されません。特別:バージョン情報を見る限り、MW1.27.0-wmf-22にアップされたのは4/26なので、そこからなら話はわかるのですが・・・他の人が再現できる環境ならいいのですが、iOS7.1.2という最新ではないiOSでの動作になるとそこまでサポートできないかもしれません。他にiOS7の実機をお持ちの方の報告がほしいところです。バグか端末かは判断がこの場ですぐにはできかねます。--アルトクール（会話） 2016年4月29日 (金) 15:58 (UTC)
若干不便ですが、この端末でないとアクセスできないというわけでもないので、しばらく他の端末から閲覧しようと思います。ただ、できれば原因を明らかにしたいですね。--Karasunoko（会話） 2016年4月29日 (金) 16:05 (UTC)
iPad Air(iOS7.1.2)のSafariで、デスクトップビューで履歴、ウォッチリストなどの表示で発症します。読み込み中にブラウザが応答不能、端末も操作不能になり、強制タスクキルとなります。モバイルビューでは発生しません。また、まれに正常表示されることがあります。正確な発生時期は覚えていませんが、4月末頃からです。なお、iPad Pro(iOS9.3.1)のSafariやWindows 8.1のIEでは発生しないことも確認しています。 --Yhiroyuki（会話） 2016年5月7日 (土) 04:07 (UTC)
どちらかというとMW側の問題ではなくて、iOS7.1.2の固有の問題な気がします。モバイルビューで問題がないとするならば、デスクトップ版というモバイル版よりも重い処理が「iOS7.1.2の想定を超える処理」を行おうとして、iOS側で強制的に落としているんじゃないでしょうか。だとすると、iOS7.1.2以前でも症状が再現するかもしれません。申し訳ないんですが、もう少し情報が集まらないと報告が厳しいです。症状が出ている方でPhabricatorで依頼できる方がいれば依頼してもらえると対応してくれるかもしれません。（手持ちの環境では再現できないので今は私のほうで依頼が難しいです・・・症状とか詳細に伝えられないので）--アルトクール（会話） 2016年5月28日 (土) 04:44 (UTC)
自分の環境ではいつの間にか改善したようです。お騒がせしました。--Karasunoko（会話） 2016年6月6日 (月) 09:46 (UTC)

「ページのカテゴリ追加・除去」のメッセージ[編集]

解決済み

ウォッチリストなどで表示できる「ページのカテゴリ追加・除去」のメッセージについてのバグ報告です。テンプレート呼び出しされているページが対象の場合、「（対象のページ名）と他$2ページをカテゴリに追加」と表示されています。金曜日の未明には、「$2」の部分にページ数が表示されていました。優先度は低めだと思いますが、状況を把握されている方、対処できる方がいらっしゃいましたら、よろしくお願いします。--Frozen-mikan（会話） 2016年4月29日 (金) 17:09 (UTC)

MediaWiki:Recentchanges-page-added-to-category-bundledで使用されている$2が廃止されたようです。トランスレートはとりあえず修正しておきました。--Vigorous action （Ｔａｌｋ/History） 2016年4月29日 (金) 18:17 (UTC)
調査、修正していただき、ありがとうございます。前回の投稿時には気が付かなかったのですが、除去時のメッセージにも同様の問題が発生しているものと思います。お手隙な際にご確認していただけると有難いです。--Frozen-mikan（会話） 2016年4月30日 (土) 15:38 (UTC)
MediaWiki:Recentchanges-page-removed-from-category-bundledをトランスレートでとりあえず修正しておきました。--Vigorous action （Ｔａｌｋ/History） 2016年5月1日 (日) 02:53 (UTC)
ありがとうございます。日本語版の方でも修正されたものに置き換わっているのを確認しました。--Frozen-mikan（会話） 2016年5月2日 (月) 03:01 (UTC)

Template:Valとリンク[編集]

解決済みWaiesu（会話） 2016年6月23日 (木) 11:11 (UTC)

例えば

  • [https://ja.wikipedia.org/ {{Val|1000000}}本以上の記事があります]

と入力すると、

となり、{{Val}}が開けた3桁区切りのスペースのとこに(リンクを示す)下線が引かれないのですが(IE11やFirefox 46で確認)、これはどうしようもないのでしょうか？--Polyester（会話） 2016年5月8日 (日) 05:57 (UTC)

コメント モジュール:Valを書き換える必要性があると思いますね。ちなみに{{Nts}}で代用したら
と表記出来ました（Chromeでのみ表示確認）。--Nami-ja（凪海） （会話 / 履歴） 2016年5月8日 (日) 06:13 (UTC)
コメント{{Val}}を使ったとこの(HTML化された)ソースを見たら、
  • 1<span style="margin-left:.25em">234</span><span style="margin-left:.25em">567</span>
とかやってスペースを開けてました。スクリーンリーダー等での利用や、掲載された数値をそのままコピーするには、ノーブレークスペースよりも好都合ですね（やるな！（感心））。
…現状ではどうしようも無いのかもですね。--Polyester（会話） 2016年5月8日 (日) 07:40 (UTC)
コメント Module:Valを書き換えなければダメそうですね。例えば、右から4, 7, 10, ...ケタ目を<span style="letter-spacing:.25em;"></span>で囲うようにすればいいのではないでしょうか（1234567こんな感じ）。もし編集したいのならば提案は別途該当ノートページにお願いします。--Waiesu（会話） 2016年5月8日 (日) 08:35 (UTC)
コメントモジュール‐ノート:Valに書いてきました。--Polyester（会話） 2016年5月8日 (日) 11:11 (UTC)

編集ツールバーが表示されない[編集]

解決済み

WindowsvistaでInternet Explorer 9を使用しています。編集ツールバー有効になっているかどうかは、『編集』タブを押しても、編集設定画面が表示されないため確認できませんでした。他のユーザーもそうなっているのでしょうか。--Tikin★（会話|投稿記録) 2016年5月27日 (金) 11:01 (UTC)

先日のビジュアルエディター導入時にツールバー周りも更新され、IE9以下は動作環境から外れています。VistaにIE10以降は導入できないので、ツールバーを使うにはChromeかFireFoxを用いるしかありません。--58.98.205.40 2016年5月28日 (土) 04:55 (UTC)

Category:Pages using invalid self-closed HTML tags[編集]

解決済み翼のない堕天使（会話） 2018年1月29日 (月) 14:34 (UTC)

しばらく前に告知がありましたが、一部のウィキテキストの解釈が変更されます。<div/> のような、HTMLとして誤りである空要素タグは、開きタグとして処理されるようになります。空要素であることを示すためには、<div></div> のように記述してください。このようなタグを含むページに「特別:追跡カテゴリ」の一つである「Category:Pages using invalid self-closed HTML tags」が付与されるようになります。--Frozen-mikan（会話） 2016年7月17日 (日) 05:45 (UTC)

質問 これはページごとに修復したほうがよいのでしょうか？（修復するならばbotに依頼することになると思いますが）--Waiesu（会話） 2016年7月17日 (日) 15:06 (UTC)
コメント この問題が特に重要ということではありません。よほど変な記述をしていなければ、何とか読める程度で収まっているはずです。なお、Botでも不可能では無いと思いますが、それぞれに様々な事情があるかもしれません。--Frozen-mikan（会話） 2016年7月18日 (月) 01:55 (UTC)
コメント コメントありがとうございます。気がついたときに記事ごとに問題がないか検証して修正したいと思います。--Waiesu（会話） 2016年7月18日 (月) 02:16 (UTC)
質問 モジュール側に自己完結しないタグが含まれていた場合は必然的にそれを読み込んでいるページがすべてカテゴライズされるわけですが、モジュールであるかどうかは一つずつ調べるしかないのでしょうか。例えばモジュール:URLの場合は<wbr/>が含まれているのでこれを読み込んでいるページすべてがカテゴライズされていて、修正する作業が大変になっています。--Mirinano（会話） 2016年7月22日 (金) 13:12 (UTC)
コメント <wbr />については<br />などと同様に空要素のタグですので、Category:Pages using invalid self-closed HTML tagsには当てはまらないと思われます。--Waiesu（会話） 2016年7月22日 (金) 13:31 (UTC)
報告 Mageiaで集積されていましたのでなぜだろうと思いこのモジュールかなと思いましたが、今回はTemplate:Versionが原因でした。Diff/60519935で修正しましたが、このテンプレートはCategory:Pages using invalid self-closed HTML tagsにある、PetScanに表示されていなかったので、もしかしたら同様の追跡されないけど自己完結しないタグを使用しているテンプレートが他にもあるかもしれません。モジュールもあるかもしれませんね。今回のwbrは確かに空要素でした。申し訳ありません。--Mirinano（会話） 2016年7月22日 (金) 13:54 (UTC)

節名が重複する記事における節編集時の要約欄[編集]

節名が重複する記事において、例えば

  1. 見出し
  2. 見出し

とある場合、それぞれアンカーは

  1. #見出し
  2. #見出し 2

のようになりますよね。しかし、それぞれを節編集すると、要約欄には

  1. /* 見出し */
  2. /* 見出し */

となり、履歴表示からのアンカーがどちらも上の節を指してしまいます。

気づくことができれば手動で要約欄を/* 見出し 2 */と直せますが、なかなか気づけないものです。なんとか自動で対応できませんでしょうか。--Waiesu（会話） 2016年7月18日 (月) 08:56 (UTC)

 追記 別の問題かもしれませんが、要約欄が同じになるだけでなく、例えば2つ目の見出し（見出し 2）を節編集すると、編集後に1つ目の見出しにリダイレクトされるようです。--MawaruNeko（会話） 2018年1月29日 (月) 13:58 (UTC)

画面上部の通知アイコンのバグ[編集]

解決済み

通知アイコンが変更されたようですが、それに伴い2つバグがあります。1点目、まるでF5を連打しているように、高速でWEBアクセスしているようです。2点目、「履歴表示」や「話題の追加」を押しても、特別通知ページが表示されます。ブラウザopera12系。--JapaneseA（会話） 2016年8月5日 (金) 06:45 (UTC)

情報 当方の環境は、Windows 10 / Opera 12.18です。1点目について、当方ではページ読み込み直後とアイコンホバー時にアイコンが点滅するのを確認しました（ご指摘の通りまるでF5連打のよう）。ただし、当方がOpera上でリクエストを監視する限りは、実際には何度もリクエストをしているわけではないようです。アイコンの形式がsvgなのでそれが関係しているかもしれません。2点目については当方では再現できませんでした。--Waiesu（会話） 2016年8月5日 (金) 07:56 (UTC)
ありがとうございます。現在は、両方とも治っているようです。またおかしくなったら報告します。--JapaneseA（会話） 2016年8月5日 (金) 13:15 (UTC)

報告 と思ったら、両方ともまた再現しました。Waiesu様の仰るように、当方の環境でも実際にWEBへ接続しなおし続けてはいないようです（FireWallのログで確認）。2点目は、「履歴表示」や「話題の追加」やその周辺が、特別通知ページへのリンクとなっているようです（つまり見た目と違う）。--JapaneseA（会話） 2016年8月5日 (金) 19:14 (UTC)

報告 再現性がわかりました。通知を1度でもクリックするとこの現象が起こります。ブラウザを起動しなおすまで、この現象は続きます。--JapaneseA（会話） 2016年8月7日 (日) 22:50 (UTC)

当方Windows Vista、Opera 12.12でも、新しくなってから未読があるとアイコンが点滅したり、アイコンから離れた場所をクリックしても特別通知ページが表示されてましたと思います(ログアウトしている状態だと起こらない？(要検証)) --6411inoino（会話） 2016年8月13日 (土曜) 03時51分 (UTC)

コメント 今のところ報告にあるのはOpera12.xだけのようなので、Opera12固有の問題のように思えます。Firefox48.0/Windows10-64bitでは現象の再現が見られません。MediaWiki側で実装した新しい概念がOpera12で処理できてない可能性も否定はできません。Windows10-64bitのFirefox48、IE11、Chrome52では再現しません。なお、通知に関しては「アカウント」に対して行われる機能ですので、ログアウトした状態では通知は機能しません。--アルトクール（会話） 2016年8月13日 (土) 07:32 (UTC)

報告 皆様コメントありがとうございます。再現しなくなりました。--JapaneseA（会話） 2016年8月19日 (金) 13:33 (UTC)

NumBlkを使用した数式がモバイルビューで表示されない[編集]

失効2017年12月を最後に議論停止。現在は表示に問題がないとみられる。--アルトクール（会話） 2018年8月25日 (土) 10:20 (UTC)

式番号を割り当てるために{{NumBlk}}を使用している数式が、モバイルビューだと全く表示されない状態になることを発見しました。

当方が確認した環境はWindows 10, Firefox 48 と iOS 9.3.4, Safariの2種類です。よくわかりませんが、{{NumBlk}}を使ってますが表示される記事もあります。

正確な記憶ではありませんが、半年前あるいは一年前くらいに見たときははこのようになっておらず、モバイルビューでもNumBlk付き数式は正常に表示されていたと記憶しています。参考として英語版でNumBlkを使用している記事を先ほどいくつか見てみましたが、これらはモバイルビューでも正常に表示されていました。--Yapparina（会話） 2016年8月6日 (土) 12:59 (UTC)

NumBlkを使用した事例ではありませんが、水酸化ナトリウムでも数式が表示されないようです。本件では、Android端末のモバイルビューにおいて<math> </math>でくくられた数式が表示されませんが、Android端末におけるデスクトップビューや、PCにおけるモバイルビューでは問題なく表示されていました。今日たまたま見かけた事例であり、いつ頃までは大丈夫だったか分からないのですが、取り急ぎご報告申し上げます……。--Assemblykinematics（会話） 2016年8月7日 (日) 02:23 (UTC)
すいません、上記の「水酸化ナトリウムについての指摘ですが、Android端末のモバイルビューでは数式が極端に小さく表示されていただけだったようです。いろいろ確認してみますと他の記事でも同様で、数式が行列などの場合は、拡大しても読めないケースもありました。端末やブラウザの問題と言われればそれまでですが、以前はここまでひどくなかったように思いますので、合わせて確認いただけると幸いです……m(_ _)m。
なお、Yapparina様が指摘されている状況は、Android端末やWindows7・Firefox環境のモバイルビューでも見受けられましたので、合わせて補足申し上げます……。--Assemblykinematics（会話） 2016年8月7日 (日) 02:40 (UTC)
NumBlkの方は私が確認した範囲ではリードにあるもののみきちんと表示されるようです．新規作成 (利用者名) （会話） 2016年8月19日 (金) 07:44 (UTC)
ここに報告されている現象は、現在でも再現しますでしょうか。私の環境(Android/Chrome)では再現できませんでした。--翼のない堕天使（会話） 2017年12月13日 (水) 05:23 (UTC)

モバイルビューでテンプレート内節編集ができない[編集]

モバイルビューで、Wikipedia:井戸端や削除依頼のようなサブページを読み込む形式の（個々の節がテンプレートになっている）ページにおいて、節編集ができないようです。具体的には、編集アイコン（鉛筆）は出てきますが、タップしても編集画面に移りません。ただしURLは、Wikipedia:井戸端においては、https://ja.m.wikipedia.org/wiki/Wikipedia:井戸端#/editor/T-1 となります。

Opera 37 Android版、Chrome Dev 54 Android版で確認しています。

日本語版に限らないかもしれませんが、対処法などあればご教授願います。--Waiesu（会話） 2016年8月14日 (日) 02:30 (UTC)

・Chrome iOS版ですが、長押し→新しいタブで開く でひらけます。

TeXによる数式前後にモバイルビューで改行が入る[編集]

解決済み現時点で問題動作を確認できず、2016年を最後に議論停止--アルトクール（会話） 2018年8月25日 (土) 10:01 (UTC)

TeX（<math>タグ）によって記述されている数式において、モバイルビューでは数式前後に意図していない改行が入ることを発見しました。自分が確認した環境はWindows 10, Firefox 48 と iOS 9.3.4, Safariの2種類です。別行立てする数式に対しては問題ありませんが、文中で使われている場合、レイアウトをかなり崩しています。

通常ビュー環境で問題の表示を再現してみると、

まず、たわみ、たわみ角、曲げモーメント、は、それぞれ、、、、せん断力という関係があることを確認しておく。 — モールの定理

が

まず、たわみ

、たわみ角

、曲げモーメント

、

は、それぞれ、

、

、

、せん断力

という関係があることを確認しておく。

というような表示になるということです。

よくわかりませんが、英語版ではそういう症状は見られません。英語版でも同じ症状が見られました。一部は正常どおりに表示されるようです。

上のNumBlkの報告に続いてヤレヤレという気分ですが、とりあえず情報共有としてご報告まで。--Yapparina（会話） 2016年8月18日 (木) 09:10 (UTC)　訂正--Yapparina（会話） 2016年8月19日 (金) 01:42 (UTC)

情報 画像を囲む span 要素に .lazy-image-placeholder のクラスが付与されており、display: block; が適用されているようです。英語版の例としてご提示されている記事のフランス語版[5]でも同様の現象が確認できました（「Pour certaines conditions sur」から始まる箇所）。--Frozen-mikan（会話） 2016年8月19日 (金) 00:14 (UTC)
Frozen-mikanさん、ありがとうございます。もう一度見直したら英語版の閲覧でも同じ症状が起きているようでした。上の報告も訂正しておきました。--Yapparina（会話） 2016年8月19日 (金) 01:42 (UTC)
その程度でいちいち<math>を使うのはやりすぎであって，たいていの記事では大きな問題は無いのではないかと思いますが，これも同じくリードのみちゃんと表示されるのでしょうか．いくつものバグが何か月も放置されている現状はどうかしています．新規作成 (利用者名) （会話） 2016年8月19日 (金) 08:01 (UTC)

タイムスタンプが重複するときのページ送り[編集]

私の投稿記録ですが、以下に挙げたものをご覧ください。

  1. 2016-08-24T06:49:09より前の54件を表示
  2. 上記1の「以前の54件」をクリックして表示されたページ
  3. 2016-08-24T06:49:09より前の100件を表示

1の最下行の項目は「利用者‐会話:Ciolar」への投稿となっております。次に2の最初の項目は「利用者‐会話:210.4.242.26」への投稿となっております。しかし3で「利用者‐会話:210.4.242.26」のひとつ前にある項目は「利用者:Gihoig」への投稿です。タイムスタンプを比較するとわかりますが、1から2にページ送りを行った段階で12項目ほどすっ飛ばされた状態になっております。

2016-08-11T17:33:36いうタイムスタンプの項目が13もある上、投稿記録のoffsetパラメータに渡される文字列が重複項目を想定していないため、おかしな事態になっているようです。通常の編集では起こりえませんが、移動や一括削除など、一回の操作で複数のページを処理したときに発生すると思われます。phabへのバグレポの投げ方がわからないといいますが、このような難解な事情を説明できないため、どなたかお願い致します。既知の問題で報告不要でしたらご容赦ください。--Marine-Bluetalk✿contribs✿mail 2016年8月31日 (水) 17:35 (UTC)

  • コメント 本当の特殊状況下でしか起こりえないもののようです。現在もリンクをたどったときに現象は再現します。これ、1→2に送ってから「以後の54件」で戻ってもおかしな表示するんですよね（これがページの履歴だと「履歴錯綜」になるんですけど）。おそらく、Marine-Blueさんの言ってる通りだと思います。ただ、起こりえる状況というのが、「同一タイムスタンプ」のときだけで、操作としてはロールバック、一括削除、自動メッセージ（CUによる同一メッセージ投稿など）になります。一応phab:T200354に投げてみました。--アルトクール（会話） 2018年7月25日 (水) 17:07 (UTC)

サッカー関連のTemplate及びNavboxesの枠表示について[編集]

件の不具合報告を以下に記述いたします。

解決済み

以上が不具合内容ですが、発見から2週間以上経過しても改善はされていません。ちなみにWiki英語版は正常に表示されています。使用環境によるものなのか、もしくはプログラム上の問題なのかは分かりませんが、正常に戻ることを望みます。--Kvjz8516（会話） 2016年9月1日 (木) 11:30 (UTC)

コメント 確かに表示が英語版とは今は異なっています。今まで問題がなかったのにということであれば、これらのテンプレートが呼び出しを行っているTemplate:Navboxが8/11に更新された影響かと思われます。クラブテンプレートは直接Navboxを、代表テンプレートはTemplate:National squad経由でやはりNavboxを呼び出してテンプレートを構成しています。現在、NavboxはLuaで書かれているので、おそらくモジュール内での何らかの表記が不具合を起こしているものと推測します。なぜか、borderを1pxで指定すると上下だけは表示されていない（あるいは上下の線がtitleのbackgroundの下に隠れている？）状況になりますが、2pxで指定すると当たり前ですが1px指定よりも太い枠線が上下左右に表示されます。Navboxを構成するモジュールあるいは構文での問題の線が高いため、Navbox側でLuaを書ける方に内容を確認してもらうのが一番早いかと思われます。--アルトクール（会話） 2016年9月27日 (火) 08:16 (UTC)
返信 正常に表示されていることを確認しました。解決の糸口を探って下さったアルトクールさん、そして解決して下さったWaiesuさんに感謝致します。ありがとうございました。--Kvjz8516（会話） 2016年10月2日 (日) 01:20 (UTC)

「このウェブページを表示中に問題が発生しました」と出て閲覧できない記事がある[編集]

失効2017年1月を最後にコメントがないため失効扱い--アルトクール（会話） 2018年8月25日 (土) 10:06 (UTC)

SRWare Iron 53.0.2800.0で水樹奈々を開こうとすると記事が表示された瞬間に「このウェブページを表示中に問題が発生しました。」というエラーメッセージが出て全く閲覧することができません。拡張機能を全部削除しても同様です。バイト数の問題かと思い水樹奈々よりバイト数が多いアンパンマンの登場人物一覧を見てみましたが正しく表示されていて、水樹奈々以外の記事でエラーメッセージが出て閲覧できないという事例は確認できません。Firefox、IEの最新バージョンでも正しく閲覧できます。同様の症状に見舞われた方はいらっしゃいませんでしょうか？--K-iczn（会話） 2016年9月27日 (火) 07:37 (UTC)

コメント ほかのブラウザでは問題がないのであれば、SRWare Iron固有の問題かと思われます。Chromeの派生ブラウザのようですが、Chromeでは問題ないので大元のソースに起因するものでもないと考えられます。バイト数というよりも、出典テンプレートの読み込み回数か何かの問題かと思われます。水樹奈々のページは読み込みが多いのでタイムアウトしているように思われます。AKB48や南京事件論争あたりでも動作がおかしくなれば読み込みがしきれないことによるタイムアウトの線が濃厚になります。--アルトクール（会話） 2016年10月1日 (土) 15:46 (UTC)
ありがとうございます。SRWare IronでAKB48も南京事件論争も問題なく読み込めます。なぜか水樹奈々だけ読めないので記事固有の問題に思えてしまいます。私以外で「このウェブページを表示中に問題が発生しました」が出る方がいらっしゃらない限り難しい問題でもありますが・・・。--K-iczn（会話） 2016年10月1日 (土) 16:19 (UTC)
コメント 先ほど、SRWareIronを入れて確認してみましたが、水樹奈々でエラーは出ず、ページが表示されました。ソフト自体を一度再インストールしてみてはどうでしょうか。MW側のバグではないようです。--アルトクール（会話） 2016年10月2日 (日) 06:49 (UTC)
コメント ありがとうございます。再インストールしてみます。--K-iczn（会話） 2016年10月2日 (日) 15:17 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ 再インストールしても読み込めませんでした。何とか水樹奈々の編集画面（ソースを編集）を開いて内容を削りながらプレビュー（編集はしていません）してみると最下部のナビゲーションテンプレートのみを除去したらプレビューながら見ることができました。試しに{{水樹奈々}}などナビゲーションテンプレートを1つでも入れたら読み込めなくなります。一方で同じく20万バイト以上で最下部にナビゲーションテンプレートが6つもあるロンドンは正常に読み込めます。調査は続けたいと思います。--K-iczn（会話） 2016年10月3日 (月) 06:33 (UTC)

コメント そうなると、Navboxの問題でもなさそう・・・。再現しないのでこちらで検証できないのですが、差分で「最初にこの問題が出た版」が特定できれば何か解決の糸口になるかもしれません。あとは空編集をしてみるのも手です。ほかに報告がないので何に起因するのかが特定が難しいです。--アルトクール（会話） 2016年10月3日 (月) 12:23 (UTC)
コメント アルトクールさん様々なアドバイスを本当に有難うございます。差分で「最初にこの問題が出た版」を特定する事ができましたが、編集した方に悪いので具体的な差分は示せないもののログインユーザーの方による出典の脚注を追加した編集で特に変な編集をしたようには見えませんでした。最初に書き忘れましたが、OSはWindows 10、SRWareIronは64bit版の方で、正常に表示できたFirefoxも64bit版です。--K-iczn（会話） 2016年10月5日 (水) 11:27 (UTC)
コメント 追加されたのがテンプレートであれば、自分の利用者ページ配下で構わないので、「現在の最新版」を作成（後で即時削除するにしてもライセンスは一応継承してください）して、そのうえで「問題の記述やテンプレート」を除去して、「現在の最新版」と「除去した版」で問題が出るかを確認してください。除去した版で問題が発生するのであれば、水樹奈々のページ自体に問題があることになるのでバグの公算が高くなります。問題が発生しないのであれば、追加されたテンプレート（もしくは引数等）に問題がある可能性があるので、テンプレートや記述を見直することになります。--アルトクール（会話） 2016年10月5日 (水) 14:18 (UTC)
度々お手数おかけして申し訳ございません。特定したと書きましたが、最新版が表示できないことに変わりはないとはいえその後の差分を表示してみると記事を表示できたり出来なかったりという事態になってはっきりとしなくなり特定したことは撤回せざるを得なくなりました。話は少し変わりますが以前編集画面を開いた時使用テンプレートや隠しカテゴリの下にメモリとかの消費量の表が出ていた記憶があるのですがご存じないでしょうか？--K-iczn（会話） 2016年10月5日 (水) 15:04 (UTC)
コメント おそらくですが、消費云々というのはプレビュー時に一番下に出てくる「構文解析のプロファイリングデータ」ではないでしょうか。応答速度などを表示する都合上、編集画面への遷移だけでは表示されなかったかと思います。--アルトクール（会話） 2017年1月14日 (土) 12:12 (UTC)

Template:Infobox Singleのリリース日の不具合[編集]

解決済み

{{Infobox Single}}のリリース日に| Released = {{Start date|1963|11|}}と指定した場合、異常表示します。

エラーの状況です。

リリース日を| Released = {{Start date|1963|11}}と修正しても改善しません。

以上、よろしくお願いします。--ワーナー成増（会話） 2016年9月29日 (木) 14:39 (UTC)

コメント どうもTemplate:Infobox Single内でTemplate:Start dateを使用し、かつ年月（第一及び第二引数）までの指定に限って、テンプレートが吐き出すコードの一部がおかしくなっているようです。第三引数以上を指定すると問題は再現しません（正しい結果を返す）。ただ、単体でStart dateを使って表示する分には問題がないので、Infobox内のコードの何かが干渉している可能性があります。同じような構成のTemplate:Infobox Songで{{Start date|1963|11}}をリリース日に入れてもおかしな表示にはなりません（Infobox SongではもともとStart dateは使うような指定がありませんが）。
そもそもですが、Infobox SingleでStart dateを使わなければいけない特別な理由がないのであれば、テンプレートにテンプレート重ねてエラーが出る可能性を排除するために使用を中止してもいいのかもしれません。--アルトクール（会話） 2016年9月29日 (木) 15:21 (UTC)
コメント 私の編集が原因のようです、ご迷惑をおかけしてすみません。出力がおかしくならないように修正させていただきました（差分）。
問題の原因は、仕様変更の際、{{start date}}の使用を考えていなかったことです。解説に{{start date}}についての記述があるのにも関わらず、それに気付かずに編集してしまったのは当方の過失で、反省しております。なお、アルトクールさんの末尾のご意見につきましては、私もメンテナンス・仕様変更のしやすさの面から賛成します。--Waiesu（会話） 2016年9月29日 (木) 16:06 (UTC)
修正を確認しました。「ウナ・セラ・ディ東京」 ありがとうございました。--ワーナー成増（会話） 2016年9月29日 (木) 20:32 (UTC)

Infobox Albumのビジュアルエディター編集での表示の不具合[編集]

解決済み

ビジュアルエディターの編集を選択すると、{{Infobox Album}}のタイプにmetaタグが表示されます。

『オペラ座の夜』を例に取ると、「クイーンのスタジオ・アルバム<meta itemprop='albumReleaseType' content='アルバム' />」と表示されます。

ビジュアルエディター側の不具合かもしれないと思いましたが、英語版で不具合が出てないようなので、一旦、バグ報告に投稿しました。--ワーナー成増（会話） 2016年10月1日 (土) 08:46 (UTC)

別件ですが、『Taking Chances』の{{Infobox Album}}の時間の表示が乱れています。現状は、| Length = CD 73:39, DVD<small>豪華版</small> 25:00, DVD<small>ウォルマート版</small> 41:00となっています。Lengthに渡している値から<small>を除去すると正しく表示されるようです。--ワーナー成増（会話） 2016年10月1日 (土) 12:22 (UTC)

コメント 前者のmetaタグについては、{{rating-5}}でも表示されることから、ビジュアルエディターが対応していないようです。後者については、解説にあるとおり「m分s秒」というフォーマットで渡せば問題なさそうです。--Waiesu（会話） 2016年10月1日 (土) 13:25 (UTC)
返信 Waiesuさん、ありがとうございます。後者の『Taking Chances』と同様な症状だった『アルラー』、『カープランク』も直りました。--ワーナー成増（会話） 2016年10月1日 (土) 14:20 (UTC)


HTMLタグ補完機能の不具合を発見[編集]

解決済み

HTMLタグ補完機能の不具合を発見しました。発見場所はWikipedia:投稿ブロック依頼/Maddestmagician 20161008です。

<del>があるが</del>が無い段落（←意図としては後続段落まで続かせたい）が<div>の中にある場合、<del>が</div>まで有効になってしまっています。

恐らく、<p><del></p><p></del></p>という誤った順序を補完する機能が、<del>を<p>の外に出した時に、続く<p>の中で改めて開始／終了してしまう所為で、一度外に出された<del>が</div>まで回収されないままなのが原因と考えます。全域が<del>の影響下にあるのではない要素が現れたら、その直前で外に出された<del>を回収するように修正する必要があります。同じことが<ins>や<small>等のインライン要素全てで発生しそうなものですが、<ins>では発生しましたが、不可解なことに<small>では発生しませんでした。これはHTMLタグの種類に応じた特殊な分岐が存在する可能性を示唆しているので注意が必要です。

再現 （翻訳者様へ；以下は、意味がわからなくてもそのまま報告出来ると思います。ぶっちゃけ、再現さえあれば分かってもらえるような気もします。）

REPRODUCTION

<div>

In div

  • Case of okay.

A part of paragraph NOT deleted. <del>A part of paragraph deleted.</del> A part of paragraph NOT deleted. Okay.

  • Case of bug.

A part of 1st paragraph NOT deleted. <del>A part of 1st paragraph deleted but without closing del.

A part of 2nd paragraph deleted.</del> A part of 2nd paragraph NOT deleted. But the BUG delete here.

All of 3rd paragraph NOT deleted. But the BUG delete here.

</div>

Out div ( Already stopped running <del> by complemented </del> before </div> )

  • All okay.

A part of 1st paragraph NOT deleted. <del>A part of 1st paragraph deleted but without closing del.

A part of 2nd paragraph deleted.</del> A part of 2nd paragraph NOT deleted. Okay.

All of 3rd paragraph NOT deleted. Okay.

世界最狂の魔法使いＣray-Ｇ（会話） 2016年10月13日 (木) 02:22 (UTC)

（追加報告）その後、<del>を<s>にすることで意図通りの表示とする編集が行なわれました。伴って先のリンク先を旧版へのリンクに差し替えました。また、<small>に加えて<s>と<b>でも発生しなかったことを追加します。--世界最狂の魔法使いＣray-Ｇ（会話） 2016年10月13日 (木) 08:56 (UTC)

Monobook スキンを黒地に緑へ変更すると見出しが黒字のままになる[編集]

解決済み

Windows10 64bit環境でFirefox 49,Internet Explorer 11,Egdeの各ブラウザーで確認したのですが、モノブックスキンでガジェット→「Monobook スキンを黒地に緑へ変更する」をチェックして表示したとき、見出し（記事名）の文字が黒のままで、下地の黒と被って表示されていないかのような状態となります。確認していただけますか。--茂林寺たぬき（会話） 2016年10月13日 (木) 06:43 (UTC)

修正を確認いたしました。ありがとうございました。--茂林寺たぬき（会話） 2016年10月15日 (土) 06:28 (UTC)

すみません、見出しではないですが、ヘルプの検索ボックスと編集内容の要約ボックスで入力した文字が読めないという、同様の事象が発生しています。確認していただけませんでしょうか。--茂林寺たぬき（会話） 2017年2月17日 (金) 03:56 (UTC)

すいません、本件は解決済みとして、上記の件は別件として報告させていただきます。--茂林寺たぬき（会話） 2017年3月10日 (金) 13:38 (UTC)

スマホでの画像の大きさ[編集]

Wikipedia:表示改善依頼の方にも前に書いたのですが改善される気配がないのでこっちにも書いておきます．<math>～</math> だとか 賛成 のアイコンなどの表示サイズがおかしいです．いつごろからかは知りませんが半年くらい前もそうだった気がします．数式を読むのはあまりに小さすぎて拡大しないと不可能です．新規作成 (利用者名) （会話） 2016年10月15日 (土) 04:22 (UTC)

返信 (新規作成さん宛) 具体的な環境（ブラウザ・モバイルビュー/デスクトップ表示）を教えていただけませんか？ おそらく画像の大きさがpx指定になっているからだと思うんですけど。--Waiesu（会話） 2016年10月15日 (土) 05:15 (UTC)
私のスマホのデフォルトのブラウザ（バージョン5.0.2-F02G.20151215.022809）では，モバイルビューではmathタグの数式が句点よりも小さく，デスクトップ表示では句点よりやや大きいくらいです．また，Googleアプリ（バージョン6.5.35.21.arm）では，モバイルビューは問題ありませんが，デスクトップ表示では句点よりやや大きいくらいになります．なお，PCからのモバイルビューでも，Safari (5.1.7 (7534.57.2)) で同様の問題を確認しました．新規作成 (利用者名) （会話） 2016年10月15日 (土) 10:48 (UTC)
当方の環境（Android 6.0.1; Chrome Dev 55）では、数式はモバイルビューだと本文に比べ少し大きめ（これが通常の描写）に、デスクトップ表示だとかなり小さく（というよりは本文がかなり大きく）表示されます。ですから、環境によって表示が異なるのでないでしょうか。もしそうであるならばこちら側で対処できることはなさそうです。--Waiesu（会話） 2016年10月15日 (土) 12:13 (UTC)
「こちら側」というのは利用者サイドという意味でしょうか？英語版を含む他言語版でもやはり異常に小さくなっていますし，何かウィキペディアの方で（？）設定をミスってるのでしょうかね．それならそれで改善要望を出すべきだと思いますが．新規作成 (利用者名) （会話） 2016年10月16日 (日) 07:13 (UTC)
こちら側というのはサーバ（MediaWiki）サイドという意味でした。おそらく、スマホブラウザのおせっかい機能で文字が大きくなっているだけなんですよ。Special:MyPage/common.cssに以下を追加して様子を見てみてください。--Waiesu（会話） 2016年10月16日 (日) 07:41 (UTC)
body {
	-moz-text-size-adjust: none;
	-ms-text-size-adjust: none;
	text-size-adjust: none;
	-webkit-text-size-adjust: 100%;
	text-size-adjust: 100%;
}
上の方の節のと同じですがリードのは正しく表示されるようです．次元論 (代数学)などでご確認ください．取り急ぎ．（まだ個人CSSはいじってません．）新規作成 (利用者名) （会話） 2016年10月16日 (日) 13:53 (UTC)
報告 私の環境（iOS 10.0.2のSafariとChrome）でアイコンについてはTemplate:コメント2/docとTemplate:AFD/docで、mathタグはWaiesuさんのサンドボックスでそれぞれ見てみましたが、問題を見つけられませんでした。--Mirinano（会話） 2016年10月16日 (日) 07:25 (UTC)
私もスマホのデフォルトのブラウザのモバイルビューではそれらのページでは問題を見つけられませんでした．次元論 (代数学)などでご確認ください．新規作成 (利用者名) （会話） 2016年10月16日 (日) 13:59 (UTC)
私は正常に表示されましたよ。個人設定→表示から数式の表示の仕方を弄ってみてください。私はMathMLを選択しています。--Mirinano（会話） 2016年10月16日 (日) 14:06 (UTC)

書いておいた方がよかったのかもしれませんが上で確認したのは全部非ログイン状態です（スマホで編集することはないので）．ログインが必要なものは時間のある時にまとめて確認してみます．お二方にはログアウト状態でも確認してみていただきたいです．新規作成 (利用者名) （会話） 2016年10月18日 (火) 09:53 (UTC)

  • mathタグについてスマホのデフォルトブラウザのモバイルビューで確認してみましたが，MathMLだとやはり異常に小さいままで，WaiesuさんのおっしゃるようにCSSをいじっても，何も変わりません．PNGにすると大きさはいいのですが，上の節にあるようにタグ部分が全部改行されてしまいます．新規作成 (利用者名) （会話） 2016年10月22日 (土) 03:27 (UTC)
  • 参考に，（ここにあった外部リンクは過去ログに際して利用できなくなっているためコメントアウトしています）新規作成 (利用者名) （会話） 2016年10月25日 (火) 03:12 (UTC)
報告 手持ちの環境での確認結果です。
# iPod touch 第4世代(A1367) iOS 5.1.1 のSafari 、非ログイン状態で数式が小さく表示される事象を確認しました。モバイルビュー、デスクトップの両モードで発生しています。
# Windows8.1 IE11 では、2ビューX互換表示の有効・無効の4パターン全てで発生していません。
# iPad Pro iOS 10.0.2 のSafari では発生していません。
# 同じiPad で Puffin Web Browser (ストリーミング方式でPC環境を再現したブラウザー)、モバイルビューのみで発生しています。
# PlayStation 4 ではモバイルビューのみで発生しています。
--Yhiroyuki（会話） 2016年10月25日 (火) 11:38 (UTC)
コメント 報告ありがとうございます。もしかしてWebkitエンジン（Blink/Webkit2を除く）で問題が発生しているのかもしれません（Puffinは仕組みが特殊なので判断できませんが）。直接の原因はおそらくm:Tech/News/2016/23にある数式レンダリングの変更かと。--Waiesu（会話） 2016年10月25日 (火) 12:02 (UTC)

特別ページの検索の制限事項について[編集]

解決済み
  • Template transclusion countで{{ActorActress}}の件数を数えると22,757 件になります[6]。
  • 特別ページの検索で{{ActorActress}}の件数を数えると22,573 件になります[7]。

184件の違いはありますが、ほぼ同じくらいの件数です。

  • Template transclusion countで{{Sfn}}の件数を数えると8,909 件になります[8]。
  • 特別ページの検索で{{Sfn}}の件数を数えると9,373 件になります[9]。

特別ページの検索はコメントアウトされたものも検索するので多少の誤差は想定内です。1ページ内で複数使われることが普通の{{Sfn}}の件数もほぼ同じです。

ここからが、今回の問題なのですが、

  • Template transclusion countで{{Reflist}}の件数を数えると391,142 件になります[10]。
  • 特別ページの検索で{{Reflist}}の件数を数えると、たった69,995 件にしかなりません[11]。

特別ページの検索には、何か制限事項、または、バグがあるのでしょうか? --ワーナー成増（会話） 2016年11月7日 (月) 09:58 (UTC)

おそらくですが、reflistを含むテンプレートも数多くあるので、これら経由で記事に現れた場合に、insource:での検索にヒットしないの原因かと思われます。--Jkr2255 2016年11月7日 (月) 10:52 (UTC)
コメント 検索の方は単純にソース中で文字列としてヒットした数、ですよね。Template transclusion count の方は実行すると、「参照読み込みの回数 391151 件の参照読み込みが見つかりました。」というように結果が表示されます。ここで「参照読み込み」をどのようにカウントしてるかが問題になります。例えば、ある記事があるテンプレートを参照読み込みして更にそのテンプレートがTemplate:Reflistを参照読み込みしている場合、その記事を表示させた時のTemplate:Reflistの「参照読み込みの回数」は？２回？1回？私が試した限りでは、この場合2回になります。つまり「参照読み込みの総回数」をカウントしているようです。このため文字列のヒット数と異なるのでしょう。実際、Template:Reflistを参照読み込みしているテンプレートは多数あります[12]。多数の記事で参照読み込みされている多数のテンプレートで参照読み込みされているReflistの場合、文字列のヒット数より多くなることになります。一方、1ページ内に複数同じテンプレートを配置しても「参照読み込みの回数」は1回になる（内部的にキャッシュに1回だけ読み込まれる）ようですので、同一ページで複数回現れる可能性が高い（しかもテンプレートでの参照読み込み数が少ない）Sfnではヒット数の方が多くなったようです。--Penn Station (talk) 2016年11月7日 (月) 11:29 (UTC)
お二方、コメントありがとうございました。両者の違いについて、納得しました。--ワーナー成増（会話） 2016年11月7日 (月) 23:18 (UTC)

ISBNが[編集]

解決済み

Template:Cite bookや文中にISBNのリンクが表記されている項目にCategory:Pages using ISBN magic linksという未作成カテゴリが付加されています。カテゴリを見たら通常の項目だけでなくISBNリンクが使用されている利用者の会話ページやサンドボックスまで無差別かつ自動的に登録されているようです。通常の編集ではISBNを消す以外にカテゴリを除去出来ない状態です。どうもWikipedia全体の仕様変更みたいです。

現在、英語版[13]、セルビア語版、スウェーデン語版、ウクライナ語版に同名のカテゴリ "Pages using ISBN magic links" が既に作成されています。ISBNが載っている個人の会話ページやサンドボックスも無差別に収集されている現状では有用性は無いと思います。必要なら隠しカテゴリ化するか表示されないようにしていただきたいです。--M-sho-gun（会話） 2016年11月11日 (金) 03:29 (UTC)

報告 隠しカテゴリとして作成しました。カテゴリ名がローカライズされた場合には、移動してください。--Frozen-mikan（会話） 2016年11月11日 (金) 07:48 (UTC)
ありがとうございます。--M-sho-gun（会話） 2016年11月11日 (金) 08:44 (UTC)
コメント WP:NEWS#Tech News: 2016-46に来ていましたが、どうやらデフォルトで「ISBNへのリンク」を外す予定があるとのことで、その下準備として作成されたようです。--Jkr2255 2016年11月14日 (月) 23:08 (UTC)
コメント ありがとうございます。「将来マジックリンクが機能しなくなる可能性がある」という部分でしょうか。リンク先の「mw:Help:Magic links」にあるように、代替としては「en:Template:ISBN」のようなローカルテンプレートがお勧めされています。日本語版でもほぼ同等の（エラー処理が無い）「Template:ISBN」があります。なお、ウィキデータは分断されているようですが、同等物である判断が難しいのでそのままに。--Frozen-mikan（会話） 2016年11月15日 (火) 00:23 (UTC)

「迷子のリダイレクト」で、グローバル利用者ページ宛てのリダイレクトが赤リンクとなる[編集]

解決済み提案者による取り下げ --WwLMvm（会話） 2016年12月2日 (金) 10:23 (UTC)

こんにちは。WwLMvmと申します。

Special:迷子のリダイレクトで、グローバル利用者ページに置き換えられたページへのリダイレクト(たとえば、現在37番目に表示されている利用者:SpartacksCompatriotや、48番目に表示されている利用者:もまくる)が、赤リンクで表示されています。 --WwLMvm（会話） 2016年11月14日 (月) 08:44 (UTC)

取り下げ 今改めて確認しましたが、現状把握が間違っていたようなので取り下げます。ご迷惑おかけしました。 --WwLMvm（会話） 2016年12月2日 (金) 10:23 (UTC)

「ツキダタダシ」作成しても表示されない[編集]

解決済み

ツキダタダシのwikipediaを作成しましたが、何も表示されません。 --owaken4628（会話） 2016年11月23日 (水) 09:56 (UTC)

報告 wikiのバグではなく<ruby>タグの閉じ忘れが原因です。Wikipediaでは<ruby>タグの使用は推奨されていませんので、現在はWP:MOSに従った表記に改められています。--118.15.158.84 2016年11月23日 (水) 17:31 (UTC)

Sidebar with collapsible lists の不具合[編集]

未解決日本語版では NavFrame の expanded オプションに非対応。対応するためには仕様変更を伴う MediaWiki:Common.js の修正が必要。--Frozen-mikan（会話） 2016年12月5日 (月) 01:03 (UTC)

expanded が使えません．かなり前からです．例えば，Template:Lie groups（ノート）．新規作成 (利用者名) （会話） 2016年12月2日 (金) 09:08 (UTC)

「展開すると横幅が変わる問題」に関して、確認してみました。
まず、Template:Lie groupsに書かれている解説はTemplate:Collapsible lists optionから呼び出されていて、これは当該テンプレートの英語版でも同じです。英語版の『This template includes collapsible lists.』が、『このテンプレートには{{collapsible list}}が使われています』と訳されていますが、実際には両言語版とも{{Sidebar with collapsible lists}}を使用しています。
このテンプレート自体もそれぞれの言語のモジュール:Sidebarを#invokeしているだけなので、{{collapsible list}}を使っているわけではなさそうです。
そして本題ですが、モジュール:Sidebarでは<table>タグの作成と設定をしており、横幅に関する設定もおそらくこの時に行われています。ここで、日本語版モジュールでは、"width"属性（横幅の指定）の初期設定が"auto"(自動)と指定されていますが、英語版モジュールでは、"22.0em"(フォントサイズの22.0倍)と指定されています。そのため、同モジュールを使用しているテンプレートでは、特に設定を上書きしない限り、日本語版では要素（リストの中身）に応じてテンプレートの横幅が変わるのに対し、英語版では「フォントサイズの22.0倍」で固定されることになります。
Template:Lie groupsに関していえば、全て折りたたまれているときは、日本語版では画像ギリギリの横幅で表示される一方、英語版では画像の横に余白ができるくらいの横幅で表示されています。また、日本語版では{{仮リンク}}が多用されているため、要素の横幅が英語版より大きくなり、展開時の横幅変更が顕著にみられるのだと思います。
なお、「展開できない問題」に関しては、「表示ボタン」を連続してクリックしても反応しない現象が、日本語版テンプレートでは確認できました。英語版では発生しないようなので、上記問題と同様に、内部の設定の差異によるものかと思われます。
以上、長くなりましたがご報告まで。 --WwLMvm（会話） 2016年12月2日 (金) 10:10 (UTC)
なるほど，「{{collapsible list}}が使われています」は単純に誤訳ですね．節名が内容と合わなくなるので変えました．横幅についてはあまり大きな問題だとは思っていませんが（横幅が変わってほしくはないですけど），原因が分かってよかったです．ありがとうございます．
私の言っている問題は，expanded が機能していないということです．キリング形式と en:Killing form を比べればお分かりいただけるかと思います．（きちんと動作する環境では）後者では（本来なら両方とも）最初ページを開いたときには Lie algebras（リー環）のみ展開されます．新規作成 (利用者名) （会話） 2016年12月2日 (金) 11:55 (UTC)
返信 (新規作成 (利用者名) 氏宛) なるほど、失礼いたしました。確かに、日本語版ではexpandedが機能していないのが確認できました。
先ほどのモジュール:Sidebarの日本語版と英語版の差異は、上で示した"width"属性の指定の他には、単純なフォント指定の数値のみで、あとは両言語版とも同じソースコードでした。
少し気になっているのが、日本語版Template:Lie groupsでは{{仮リンク}}が使用されている点です。詳しいことはわかりませんが、en:Template:Lie groupsには対応するテンプレート({{Template:Interlanguage link multi}}など)が使用されていないので、これが原因かもしれません。もしくは、MediaWiki自体の設定の差異、とか。
それと、Template:Collapsible lists optionの修正、 ありがとうございます --WwLMvm（会話） 2016年12月2日 (金) 12:30 (UTC)
仮リンクを抜いてみましたが（テンプレート），変わらないですね……（テストページ）．新規作成 (利用者名) （会話） 2016年12月3日 (土) 07:07 (UTC)
モジュールとテンプレートは確実に正しく作動しています(リー環 は collapsed クラスを持ってない)。が、NavFrame ががが…--rxy（会話） 2016年12月3日 (土) 08:54 (UTC)
すみませんがおっしゃる意味がよく分かりません．英語版と同じ使い方ではだめということでしょうか？
余談ですが履歴をよく見ると上のは誤訳ではなく原文も間違ってました（翻訳時より後に修正された）．新規作成 (利用者名) （会話） 2016年12月4日 (日) 03:38 (UTC)
使い方の問題ではなくて…。バグなのか仕様なのかは存じませんが、英語版と日本語版ではそのテンプレートで折りたたみ機能を実装している "NavFrame" の既定動作が異なっており、英語版の NavFrame は既定で展開状態となっています。しかし、日本語版では既定で折りたたみ状態となっています。ご指摘のテンプレートで折りたたみ処理を行っている Module:Sidebar の function "p.collapsible" は、英語版 NavFrame の挙動を基に作られているため、expanded で特例指定されている場合を除き、各リストの見出しに対して「折りたたませる」ための処理を施しています（※）。ここで、expanded で指定されている場合、指定されたリストの見出しに対して「折りたたませる」処理をしないため、英語版であれば NavFrame の既定状態たる「展開」状態となります。ところが、日本語版の既定動作が「すべて折りたたみ」であるため、※ 部分の実装にかかわらず expanded で展開指定をしようとも、「日本語版 NavFrame の既定で折りたたむ動作」が優越してしまって機能していないのです。--rxy（会話） 2016年12月4日 (日) 04:05 (UTC)
なるほど，丁寧なご説明ありがとうございます．そうすると修正は容易ではなさそうですね……．新規作成 (利用者名) （会話） 2016年12月4日 (日) 11:00 (UTC)
関係あるかはわかりませんが、MediaWiki:Common.jsのNavFrame関連のコードに、
$(createCollapseButtons); // 応急処置
というように「応急処置」となっているので、まだ不具合が残されているのかもしれません。 --WwLMvm（会話） 2016年12月4日 (日) 03:53 (UTC)

コメント 英語版と同じ挙動をするテンプレートって作れないでしょうか？新規作成 (利用者名) （会話） 2017年3月25日 (土) 06:20 (UTC)

バックスペース毎に勝手にトップへスクロール[編集]

済み--アルトクール（会話） 2018年8月25日 (土) 10:10 (UTC)

WIN10かつIE11ですが、バックスペース毎に勝手にページのトップへスクロールされるため、長いページを編集することが、事実上無理になっています。--106.154.40.120 2016年12月3日 (土) 01:33 (UTC)

コメント 使用されている機器またはブラウザの問題と考えられます。--アルトクール（会話） 2017年1月14日 (土) 12:06 (UTC)

各項目の左に『・』がついてない[編集]

解決済み非バグ案件 --WwLMvm（会話） 2016年12月4日 (日) 23:21 (UTC)

：ページ→１２月５日、項目→記念日 各項目の左に『・』がついてないです。よろしくお願いします。--以上の署名のないコメントは、126.212.134.137（会話）さんが 2016年12月4日 (日) 21:32 (UTC) に投稿したものです（WwLMvm（会話）による付記）。 -- 記事へのリンクを追加 --WwLMvm（会話） 2016年12月4日 (日) 23:21 (UTC)

返信 (IP:126.212.134.137（会話 / 投稿記録）氏宛) 当該箇所は「定義の箇条書き」というものを使用しています。詳しい説明はHelp:箇条書き#定義の箇条書きをご覧ください。
また、これはバグではありませんので、何かありましたらノートページへ。 --WwLMvm（会話） 2016年12月4日 (日) 23:21 (UTC)

要約欄で、節名において山括弧に囲まれた部分が見えなくなる[編集]

済み仕様と考えられる動作--アルトクール（会話） 2018年8月25日 (土) 10:11 (UTC)

（注）報告された現象が本セクションでも発生するため、セクション名を変更。元のセクション名は『要約欄で、節名において<>に囲まれた部分が見えなくなる』です。 --WwLMvm（会話） 2016年12月25日 (日) 15:13 (UTC)

他の方の利用案内への投稿を見ていてたまたま気づいたのですが、節名において<>に囲まれた部分が要約欄では見えなくなることを見つけました。[14]をご覧いただくと分かるかと思います。単に要約欄に<hoge>と書いただけではこの現象は起こりません([15])。おそらくどのページでも再現性があるはずです。こちらの環境はOSがWindows 7、ブラウザはInternet Explorer 11です。--ドングリ（会話） 2016年12月25日 (日) 13:49 (UTC)

 再現確認 OSはWindows 10、ブラウザはSleipnir 6ですが、サンドボックスでの再現を確認しました。おそらく要約欄の自動入力機能による「セクション名の自動挿入」機能の不具合（もしくは仕様）が原因かと思われます。セクションの編集リンクをクリックすると、セクション名が抽出されて編集画面の要約欄に自動入力されますが、ここに<>が含まれていると、括弧内の文字を抽出することができないようです。
ただ、HTMLでは<や>をHTMLタグの指定に使用しているため（例: <ref>hoge</ref>）、本来は直接入力せずに&lt;や&gt;と入力する必要があります。この制約から考えると、セクション名には&lt;や&gt;を使用することが想定されていて、<や>を直接使用することは想定外だったのかもしれません。このように考えると、バグというよりMediaWikiの仕様かもしれません。
いずれにせよ、まずはこの現象が再現可能であることをご報告いたします。
なお、この現象が本セクションでも発生するため、セクション名を『要約欄で、節名において山括弧に囲まれた部分が見えなくなる』に変更いたしました。--WwLMvm（会話） 2016年12月25日 (日) 15:13 (UTC)
丁寧なご返答ありがとうございます。なるほど、MediaWikiの仕様かもしれないのですね。そこまでは考えていませんでした。
この節でも同じ現象が起こるところまでは頭が回りませんでした…ご修正ありがとうございます。--ドングリ（会話） 2016年12月26日 (月) 05:12 (UTC)
「https://ja.wikipedia.org/w/index.php?title=Wikipedia:バグの報告/2016年&oldid=86416013」から取得