Wikipedia:バグの報告

ここバグの報告ページは、不具合がウィキペディア自体のバグなのかどうかはっきりしない時、または英語でのバグ報告に不安がある場合などに、ウィキペディア日本語版の利用者が日本語で報告・相談する場です。

---

ウィキペディアでの閲覧・編集に不具合が生じている場合、いくつか原因が考えられます。一時的なエラーなどの場合は、しばらくすれば解決されますが、ウィキペディアが使用しているソフトウェアであるMediaWiki本体のバグやその設定ミスの場合、MediaWikiに修正を依頼しなければなりません。MediaWikiの修正・機能追加の要望は、専用サイトのPhabricatorにて英語で行われています。直接英語でやり取りしたい方は、Phabricatorの説明をご覧ください。

モバイルビューでの表示について「仕様として」一般に表示されるテンプレートが減らされています（機能厳選）。モバイル用に小さなテンプレートを用意できればいいのですが、デスクトップとモバイルとで表示を別にする機能は開発中（2018年初頭）で、実装が待たれます。

他の相談場所

• Wikipedia:利用案内 - ウィキペディアの使い方について
• Wikipedia:調べもの案内 - ウィキペディア内のリファレンスデスク
• プロジェクト:ウィキ技術部 - TemplateやLuaなどのウィキで使われる技術について
• Wikipedia:表示改善依頼 - 個別の記事にてデザインや機能がおかしいとき
• Wikipedia:ビジュアルエディター - ビジュアルエディター機能に関すること

バグの報告の利用方法

日本語での新しいバグの報告・相談はこのページの最後に書き加えてください。その際は、以下を必ず明記してください。

1. 問題が発生したページ
2. 問題が発生したときの状況（可能であれば再現性と再現手順も記載してください）
3. あなたが使用しているOSとウェブブラウザおよびそのバージョン（例：Windows 10 Home 22H2（64ビット）、Google Chrome 123.0.6312.123（64ビット））
4. 外装（スキン）などのウィキペディアの個人設定（例：ベクター (2022年版)）

バグの報告における議論でPhabricatorにおけるタスクが作成された場合、{{Tracked}}を付けてください。

問題が解決したら、節の冒頭に{{解決済み}}を付けてください（議論に参加していない方でも、どなたが付けてもかまいません）。修正・解決されたなど一段落しているバグについては、このテンプレートを目印にして過去ログに移動しています。

ただし、以下のようなものをこのページで報告しないでください。

• 記事内容の誤り：記事内容の誤り、スペルミス、誤字・脱字などはバグではありません。あなたが自分で記事を直すか、その記事のノートページで記事の執筆者たちに呼びかけてみてください。Wikipedia:連絡先/記事の問題もご覧ください。
• 一時的なサーバの問題：アクセスが過剰な時などに表示が遅くなったり、一時的に接続できずエラー画面が表示されたりすることがあります。通常は数分から数時間で復旧しますので、しばらく待ってから再接続してみてください。エラー画面は英語で表示される場合もあります。
• 一時的な表示不具合：サイドバーの表示などが一時的におかしくなることがありますが、しばらくすると通常に戻ります。ただし何日もそのままで直らない場合は、このページで報告してください。
• 履歴・署名の時刻のずれ：ページの履歴や署名の時間があなたの時計とずれているのはバグではありません。ウィキペディア日本語版の時刻表示は協定世界時 (UTC) を標準としていますので、履歴や署名などの時刻表示は日本標準時（日本時間、JST）より9時間前を示しています。
• ほかのプロジェクトに関して：ウィクショナリーやコモンズなどの姉妹プロジェクト、他言語版に関するバグと思われる報告はこちらでは受け付けしていません。それぞれのプロジェクトかPhabricatorにて報告してください。
• 個人設定画面へのリンクが効かない：外装とウェブブラウザの相性によっては個人設定画面へのリンクが効かなくなることがあります。その場合は、次に示すリンクをクリックすると外装が初期値「ベクター (2022年版)」に一時的に戻るので、そこで他の外装を選び直し、設定を保存してください：ベクター (2022年版) で個人設定を表示

---

過去ログの検索

/過去ログページ

---

　

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

解決済み

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)

• 済 すみません。しばらく待っていたら編集ツールバーが表示されるようになっていました。ありがとうございました。--Tikin★（会話|投稿記録) 2016年5月28日 (土) 07:14 (UTC)

Category:Pages using invalid self-closed HTML tags

しばらく前に告知がありましたが、一部のウィキテキストの解釈が変更されます。<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つバグがあります。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を使用した数式がモバイルビューで表示されない

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

• 例：二項係数（右側に番号を振っている数式に注目ください）
  • 通常ビュー：https://ja.wikipedia.org/wiki/%E4%BA%8C%E9%A0%85%E4%BF%82%E6%95%B0
  • モバイルビュー：https://ja.m.wikipedia.org/wiki/%E4%BA%8C%E9%A0%85%E4%BF%82%E6%95%B0

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

• 例：ベルグマン核（番号(1)を振っている数式に注目ください）
  • 通常ビュー：https://ja.wikipedia.org/wiki/%E3%83%99%E3%83%AB%E3%82%B0%E3%83%9E%E3%83%B3%E6%A0%B8
  • モバイルビュー：https://ja.m.wikipedia.org/wiki/%E3%83%99%E3%83%AB%E3%82%B0%E3%83%9E%E3%83%B3%E6%A0%B8

正確な記憶ではありませんが、半年前あるいは一年前くらいに見たときははこのようになっておらず、モバイルビューでも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)

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

モバイルビューで、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)

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

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

• 例：モールの定理（概要節辺りが分かり易いと思います。）
  • 通常ビュー：https://ja.wikipedia.org/wiki/%E3%83%A2%E3%83%BC%E3%83%AB%E3%81%AE%E5%AE%9A%E7%90%86
  • モバイルビュー：https://ja.m.wikipedia.org/wiki/%E3%83%A2%E3%83%BC%E3%83%AB%E3%81%AE%E5%AE%9A%E7%90%86

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

まず、たわみ$v$、たわみ角$\theta$、曲げモーメント$M$、$Q$は、それぞれ、$v'=\theta$、$\theta '=-M/EI$、$M'=Q$、せん断力$Q'=-p$という関係があることを確認しておく。 — モールの定理

が

まず、たわみ
$v$
、たわみ角
$\theta$
、曲げモーメント
$M$
、
$Q$
は、それぞれ、
$v'=\theta$
、
$\theta '=-M/EI$
、
$M'=Q$
、せん断力
$Q'=-p$
という関係があることを確認しておく。

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

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

• 例：Bernoulli differential equation（Solution節辺りなどに注目ください）
  • 通常ビュー：https://en.wikipedia.org/wiki/Bernoulli_differential_equation
  • モバイルビュー：https://en.m.wikipedia.org/wiki/Bernoulli_differential_equation
• 正常に表示される例：Riccati equation（導入部最初の数式のwhere以下などに注目ください）
  • 通常ビュー：https://en.wikipedia.org/wiki/Riccati_equation
  • モバイルビュー：https://en.m.wikipedia.org/wiki/Riccati_equation

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

情報 画像を囲む span 要素に .lazy-image-placeholder のクラスが付与されており、display: block; が適用されているようです。英語版の例としてご提示されている記事のフランス語版[1]でも同様の現象が確認できました（「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-Blue^{talk✿contribs✿mail} 2016年8月31日 (水) 17:35 (UTC)

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

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

• 不具合内容 - サッカー関連のテンプレート (Template) 及びNavboxesにおいて、枠表示に不具合が発生している。具体的には上下横線が反映されていない現象（縦線は反映されているが、一部表示に不具合有り）です。
  • 代表テンプレート
    • Template:UEFA EURO 2016ポルトガル代表 - 枠色 (bordercolor= #006600, 緑色系)
    • Template:UEFA EURO 2016フランス代表 - 枠色 (bordercolor = #EF4135, 赤色系)
    • Template:リオデジャネイロオリンピック サッカーブラジル代表 - 編集では枠色設定はされていないが、National squad式の場合は#aaaaaa（灰色系）が自動表示される。
  • クラブテンプレート
    • Template:FCクロトーネのメンバー - 枠色 (border:1px solid red, 赤) ※1px solidは線の太さを表す。
    • Template:インテルナツィオナーレ・ミラノのメンバー - 枠色 (border:1px solid #5A8AFA, 青色系) ※「選手欄」の縦線の入り具合がおかしい（太さが均一でない）。
    • Template:ガンバ大阪のメンバー - 枠色 (border:2px solid #000;line-height:120%, 黒) ※上記2つのテンプレートと太さが異なるため、正常に反映されているに見える。しかしインテル同様、「選手欄」の縦線の入り具合がおかしい。
  • Navboxes - 同種類のテンプレートがある場合、Navboxesを追加することで、それらのテンプレートを収納させることができるが、Navboxesも上下横線が反映されていない。
    • クリスティアーノ・ロナウド参照 - 「ポルトガル代表 - 出場大会」 (border:1px solid #006600, 緑色系)
    • アントワーヌ・グリーズマン参照 - 「フランス代表 - 出場大会」(border:1px solid #EF4135, 赤色系)
• 発見日 - 2016年8月13日
• 発生している使用環境 - OSはWindows7、ブラウザはGoogle Chrome及びInternet Explorerで発生

以上が不具合内容ですが、発見から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)

• 報告 Template‐ノート:Navbox#不具合の報告に基づき、モジュール:Navbox/formerを修正しました（差分）。ご確認くださいますようお願いします。不具合が継続しているようでしたら、お手数ですがお知らせください。--Waiesu（会話） 2016年10月1日 (土) 16:54 (UTC)

返信 正常に表示されていることを確認しました。解決の糸口を探って下さったアルトクールさん、そして解決して下さったWaiesuさんに感謝致します。ありがとうございました。--Kvjz8516（会話） 2016年10月2日 (日) 01:20 (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)

• 報告 返信 (茂林寺たぬきさん宛) 修正しました（差分）。反映されない場合は、個人設定でガジェットをオフ→保存→オン→保存をしてご確認ください。それでも反映されない場合は再度お声かけください。--Waiesu（会話） 2016年10月15日 (土) 05:35 (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)
• 参考に，twitter ウィキペディア 視力検査，ウィキペディア 数式．新規作成 (利用者名) （会話） 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)

• 結局，この問題への対処はどうすればいいのでしょう？新規作成 (利用者名) （会話） 2016年10月27日 (木) 06:38 (UTC)
  • 情報 MediaWikiの問題だと考えられるので、日本語版でできることはないと思われます。phab:T149568にて似たような報告がされているようなので、ここで得られた情報を提供すれば解決が早まるかもしれません。--Waiesu（会話） 2016年11月8日 (火) 13:58 (UTC)

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

解決済み

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

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

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

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

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

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

特別ページの検索には、何か制限事項、または、バグがあるのでしょうか? --ワーナー成増（会話） 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を参照読み込みしているテンプレートは多数あります[8]。多数の記事で参照読み込みされている多数のテンプレートで参照読み込みされている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全体の仕様変更みたいです。

現在、英語版[9]、セルビア語版、スウェーデン語版、ウクライナ語版に同名のカテゴリ "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)

バックスペース毎に勝手にトップへスクロール

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)

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

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

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

 再現確認 OSはWindows 10、ブラウザはSleipnir 6ですが、サンドボックスでの再現を確認しました。おそらく要約欄の自動入力機能による「セクション名の自動挿入」機能の不具合（もしくは仕様）が原因かと思われます。セクションの編集リンクをクリックすると、セクション名が抽出されて編集画面の要約欄に自動入力されますが、ここに<>が含まれていると、括弧内の文字を抽出することができないようです。

ただ、HTMLでは<や>をHTMLタグの指定に使用しているため（例: <ref>hoge</ref>）、本来は直接入力せずに<や>と入力する必要があります。この制約から考えると、セクション名には<や>を使用することが想定されていて、<や>を直接使用することは想定外だったのかもしれません。このように考えると、バグというよりMediaWikiの仕様かもしれません。

いずれにせよ、まずはこの現象が再現可能であることをご報告いたします。

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

丁寧なご返答ありがとうございます。なるほど、MediaWikiの仕様かもしれないのですね。そこまでは考えていませんでした。

この節でも同じ現象が起こるところまでは頭が回りませんでした…ご修正ありがとうございます。--ドングリ（会話） 2016年12月26日 (月) 05:12 (UTC)

ウィキラブ 不具合

解決済み直しました--rxy（会話） 2017年1月23日 (月) 14:32 (UTC)

--Good2016hey（会話） 2017年1月23日 (月) 13:08 (UTC)

対処 gerrit:111741 でファイルパスが変更となっていたため、読み込まなかったようです。Special:Diff/62755004 で修正しました（ついでに花が大きすぎるので、ほかに合わせて 53 px にしました）。クライアント側のキャッシュによって数日間同じ現象が続くかもしれませんが、いつか直ります。--rxy（会話） 2017年1月23日 (月) 14:32 (UTC)

本来等価であるべきタグの挙動が異なる

解決済み非バグ案件 --Momijiro（会話） 2017年2月3日 (金) 11:53 (UTC)

en:wikipedia:HTML5#fontによれば本来等価であるべきですが挙動に食い違いが出ています

• fontタグ はリンクに着色可能
  • <font color="red">[[日本]]</font> → 日本
• spanタグ はリンクに着色不可
  • <span style="color:red;">[[日本]]</span> → 日本

plain textだと二者の挙動は一致するので、あるいはMediaWiki側の問題かと考え、こちらに報告します。 なお英語版で試しても同様。--Momijiro（会話） 2017年2月2日 (木) 10:02 (UTC)

コメント 生成したHTMLを見ると、<font>ではどういうわけか<a>の内側に<font>が入るような挙動となっています。--Jkr2255 2017年2月2日 (木) 11:12 (UTC)

コメント 多分なんですが、fontの指定の時は文字に対するタグなので、文字の「日本」に対して効果がかかるように処理されている、つまり<font color="red">[[日本]]</font>をHTMLに変換するときに、まず「日本」という文字列を抽出させ、それに文字に対する処理（font color="red"）が行われて、それに対して日本へのリンク（aタグ）を「赤文字の日本」に対して付与していると思います。

一方で、spanタグはインライン要素タグなのでそのまま処理されてしまう（つまり、文字に限定するタグではないから、処理が最後になる）ので、<span style="color:red;">[[日本]]</span>をHTMLに変換するときに、「日本」という文字列に日本へのリンク（aタグ）を付与、インライン要素であるspanについてはそのままの位置を保持（<span style="color:red;"><a href="/wiki/%E6%97%A5%E6%9C%AC" title="日本">日本</a></span>）すると思います。

そうすると、動作の違いが判ります。spanタグを使った場合は、spanタグの指定のあとにaタグがくるので、aタグが元々持っている文字色指定が有効になります。fontタグを使った場合はあくまで文字の「日本」に対しての装飾タグなので、aタグの後にfontタグの文字色指定が有効になります。

たぶん、意図させた動作だとおもうので、MWで修正するのは難しいかと思います。英語版のWikipedia:HTML5はおそらくなんですが平文（黒文字）の変更に関しての説明をしていて、リンクの変更についてまでは考慮してないと考えられます。（spanは文字専用ではないから処理としては正常と考えられる）--アルトクール（会話） 2017年2月2日 (木) 15:09 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ ありがとうございます 明解な説明でよく理解できました。

パイプリンクのラベル部をspanで修飾するしかウィキリンクに着色できないようです（一見、分かりにくいので出来れば使いたくないのですが…）。

• [[日本|<span style="color:red;">日本</span>]] → 日本

--Momijiro（会話） 2017年2月3日 (金) 11:53 (UTC)

opera系ブラウザでの記述重複バグ

数年前にも報告していますが、相変わらず修正されていない、という事を報告しておきます。こちらの意図しない記述が任意の位置にコピーされます（コピーされる位置は文末が多いです）。[12][13]は、下の記述はバグです。バグが発生した場合は、<の次の文字からコピーされるようです。編集後の確認を怠ったのは私の落ち度ですが、これはプレビューでは確認できません。なお、今のところ私とKiruria281様以外にはこのバグは聞いていません。頻度は多くても100回に1回程度に感じています。--JapaneseA（会話） 2017年2月4日 (土) 14:58 (UTC)

2010年以降で見たところWikipedia:バグの報告/MediaWiki1.20#余計な文字列が付いてしまう、Wikipedia:バグの報告/MediaWiki1.20#Operaで執筆時に余計な文字列が発生するの2件ですね。前回報告があったときは全部で3名が同様の現象がでると報告していますね。

現象を鑑みるとOpera（たぶんVer.12系列）もしくはElektra/Prestoエンジン特有の問題なのかなぁと。WindowsOSのVerは関係ない問題といえます。プレビューで問題がないということは投稿が確定する直前に変更されるんだと思います。原因は『<』に反応しているのだろうというのは推測できますが、一見して問題はランダムにみえますから、Phabに送っても「？？」になってしまうかと。

実際に再現させていないので推測ですが、更新をするときに「ソース編集画面上にカーソルがあり」「そのカーソルに一番近い『<』」に反応」「反応した『<』より後からカーソルのある位置までをコピー」「それを編集中のページあるいはセクションの最下部にペースト」しているんじゃないかなぁと思います。そう考えると、今回の報告の前者は「カーソルがテンプレート呼び出しの一番後ろにある状態で、コメントアウトの『<』より後からテンプレート呼び出しまでのすべてを編集画面上の一番下にペーストした」と考えられますし、後者は「ページ全体を編集中に偶々カーソルがページ先頭にあるInfobox内の{{SWE}}の後ろにある状態で編集した結果、以下前者と同様の結果」と考えることができます。

なので、発生したときの詳細を検証していただければ、Phabへ持っていける・・・かもしれません。前回も今回も検証されたわけではないので、詳細情報が不明です。これだとjawikiから持って行ってないのでしょうし（元々英語で報告できるひとが少ないっていうのも一因かもしれませんが）、他言語のwikiで発生していればそちらで報告が上がっていそうなものなので、もしかするとjawiki独自のガジェットが問題を引き起こしている可能性もあります・・・。--アルトクール（会話） 2017年2月4日 (土) 16:07 (UTC)

ありがとうございます。カーソル位置は意図していませんでした。今後はカーソル位置に注目しようと思います。--JapaneseA（会話） 2017年2月4日 (土) 16:13 (UTC)(Sutepen angel momo)

ビジュアルエディターでの「初心者向け」お知らせで、欄の表記が実際と異なる。

再現しようとしても初心者向けではないお知らせが出てきてしまうので正確な文言は判らないのですが、「Subject」欄を指している部分が日本語で表記されていました。たったそれだけではありますが、「初心者向け」としては好ましくないのではないでしょうか。Hiroes（会話） 2017年2月5日 (日) 09:48 (UTC)

追記：「New Section」欄については「下の部分」という表記だったので問題ないかと思います。Hiroes（会話） 2017年2月5日 (日) 09:52 (UTC)

半保護されているはずなのにIPユーザーが編集している

夏川椎奈（ノート / 履歴 / ログ / リンク元）→夏川椎菜（ノート / 履歴 / ログ / リンク元） リダイレクトページの夏川椎奈で起こった現象です。移動荒らしを差し戻したとき、移動先を間違えたらせいでIPユーザーにsdを貼られたのですが、半保護を設定したはずのページなのにIPユーザーが編集しています。移動作業を行う時点で半保護が有効であることは確認しているし、リダイレクトページも現在確認したら半保護設定が有効です。ビジュアルエディターの不具合ではないかと思いますので、こちらに報告を投げておきます。--Marine-Blue^{talk✿contribs✿mail} 2017年2月12日 (日) 02:55 (UTC)

なんか動作がおかしいというのはわかるんですが・・・。移動は「夏川椎菜」→「除去されたページ名」→「夏川椎奈」→「夏川椎菜」ですよね？で、「夏川椎奈」で特定版削除→半保護と移動保護→「夏川椎菜」へ移動ですよね。そうなると、本来保護の設定を引き継ぐのは「夏川椎菜」で、「夏川椎奈」は保護設定がなしになるように思うのですが。そっちのほうがバグのような気がします。IE11で確認してみましたが、半保護は正しく動作しているようなので一時的なものだったのかもしれません。他に報告例があれば検証しやすいかもしれませんが・・・。--アルトクール（会話） 2017年2月17日 (金) 05:15 (UTC)

Template:Shogi diagramで複数の「」パラメータエラー

左美濃のページ編集を開始して、なにも変更せずにプレビューをすると

警告: 左美濃は複数の「」パラメータを伴ってTemplate:Shogi diagramを呼び出しています。提供されている最後の値のみが使用されます。

というエラーが上部に出ます。 Template:Shogi diagramを使っている全てのページでこのエラーが出るようです。Template:Shogi diagramの使い方に問題はないと思うのですが。。。 いったい何が問題なのでしょうか？直していただけるとありがたいです。

コメント 行末が「|=」になっていますが、これが問題です。全部撤去すれば解決します。--Jkr2255 2017年2月20日 (月) 03:20 (UTC)

ああ、それが問題でしたか。まったく気づきませんでした。。。ありがとうございます。後はこちらでなんとかします。「|=」撤去でプレビューすると、正常にエラーも発生しないことを確認いたしました。--bcxfu75k（会話） 2017年2月20日 (月) 04:30 (UTC)

コモンズからのファイルページに掲載されたgalleryタグの引用について

ウィキペディアコモンズ上に掲載されたファイルページ（例えばc:File:WikipediaTownSummit2017Kyoto flyer.pdf）の中に、galleryタグを用いて並べられた画像リストがあるのですが、ウィキペディア上に読み込まれたファイルページ（ファイル:WikipediaTownSummit2017Kyoto flyer.pdf）にはそれが反映されずリスト形式で掲載されております。こちらの報告ページが対象として正しいのかという点はありますが、報告・ご相談ということでお願いいたします。--S.Arai(talk) 2017年3月1日 (水) 11:21 (UTC)

コモンズでは表示が問題ないので、ウィキペディアに読み込んだ時にギャラリータグの読み込みがおかしくなっていると考えられます。英語版などの他のウィキペディア、ウィキニュースやウィキバーシティの日本語版でも現象が確認できました。と確認したところ、phab:T124876などで報告されているので、修正の優先度が低いか、修正するのに時間のかかる部類のものになっているのだと考えられます。現状、表示が大きく崩れる（例えば、ファイルが原寸で表示されるとか）といった深刻な問題は起こしていないといえますので、「バグの一つだけど、深刻な問題ではないので対処街になっている案件」になっているのかと思います。--アルトクール（会話） 2017年3月1日 (水) 11:46 (UTC)

返信 ご返信いただきましてありがとうございます。この状況ですと、辛抱強く待つことしかできないような気がしています。議論が昨年で止まっていることも優先度の低さが表れているのかもしれません。条提示ありがとうございました。--S.Arai(talk) 2017年3月1日 (水) 22:51 (UTC)

「井戸端」の議論が途中までしか表示されないのは仕様でしょうか？

解決済み

まだ状況を確認したばかりで、本来なら当の井戸端で聞くレベルなのですが、それで状況が悪化しても困りますので、こちらで質問です。

IE11とChrome56で同じ表示ですのでブラウザの問題とも思えません。 段落ごとのプレビューやサブページ単体では正常に表示されているので総量規制のようなものだと思っているのですが、これは仕様でしょうか？--Hiroes（会話） 2017年3月1日 (水) 11:32 (UTC)

えっと、状況がわかりません。現在、井戸端に読み込まれている話題は11のサブページです。最低限「どこまで読み込んでいるのか」をはっきりさせてください。Firefoxを使っていますが読み込みは正常に行われています。--アルトクール（会話） 2017年3月1日 (水) 11:48 (UTC)

「多数の言語版にあるが日本語版にないカテゴリ」が最初の質問だけ表示された状態でした…が、再度確認したら正常に表示されていました。単にIncludeしているわけではなく、若干タイムラグがあるという事でしょうか？いずれにせよお騒がせしました。--Hiroes（会話） 2017年3月1日 (水) 11:58 (UTC)

キャッシュが残っている状態だと、以前の状態で表示されることがあります。--アルトクール（会話） 2017年3月1日 (水) 12:00 (UTC)

了解しました。お騒がせしました。--Hiroes（会話） 2017年3月1日 (水) 12:11 (UTC)

編集の要約記述欄で padding がオーバーライドされず入力文字が隠れる

過剰な padding で要約記述欄の文字が隠れるバグ。

開発ツールで padding を無効にした場合。要約記述欄の必要ない padding が無くなる。

Firefox バージョン 52.0 (Release) 編集の要約記述欄で本来、paddingは0 emであるべきなのに padding が継承され、要約記述が padding で隠れます。要素を調査するとスタイル https://ja.wikipedia.org/w/load.php?debug=false&lang=ja&modules=ext.echo.badgeicons%7Cext.echo.styles.badge%7Cext.gadget.OldDiff%2CScrolledReflist%7Cext.uls.interlanguage%7Cext.visualEditor.desktopArticleTarget.noscript%7Cext.wikimediaBadges%7Cmediawiki.action.edit.styles%7Cmediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.sectionAnchor%7Cmediawiki.skinning.interface%7Cskins.vector.styles&only=styles&skin=vector の指定がそのまま継承されているようです。開発ツールで " padding: 0.625em 0.546875em 0.546875em;" の行を無効にすると padding が 0 em になり文字が隠れなくなります。なお、Google Chrome では起きないようです。--Licsak（会話） 2017年3月7日 (火) 16:50 (UTC)

MediaWiki 本体の編集画面が UI ガイドラインへの準拠を目的に、phab:T152025, gerrit:337470によって mw:MediaWiki 1.29/wmf.12 でスタイルが変更となっています。標準環境（非ログイン状態 or アカウント作成直後）では発生しません。で、ご報告の不具合が発生した原因としては、WikiEdwikEd が干渉しているために起きているようです。WikiEdwikEd を無効にするか、enwp の WikiEd 不具合報告 (固定版) に書かれた 緩和策をご自身の責任で任意の値に変更の上、適用なさってください。--rxy（会話） 2017年3月8日 (水) 03:18 (UTC)WikiEdwikEd--rxy（会話） 2017年3月8日 (水) 03:22 (UTC)

ありがとうございます rxyさん、誠にありがとうございます。ご指摘のとおりwikEdを使わない画面では発生せず、ある意味、場違いな報告に対しても回避策のご教示とともに回答下さり、感謝申し上げます。--Licsak（会話） 2017年3月8日 (水) 14:02 (UTC)

太枠の入力ボックスで文字が表示されない

モノブックスキンでガジェット→「Monobook スキンを黒地に緑へ変更する」をチェックして表示したとき、ヘルプの検索ボックス、題名ボックス、編集内容の要約ボックスなど太枠の入力ボックスに入力した文字が読めないという事象が発生しています。左側の細い検索ボックスでは読めています。確認していただけませんでしょうか。--茂林寺たぬき（会話） 2017年3月10日 (金) 13:47 (UTC)