コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

「Wikipedia:バグの報告」の版間の差分

削除された内容 追加された内容
360行目: 360行目:
::丁寧なご返答ありがとうございます。なるほど、MediaWikiの仕様かもしれないのですね。そこまでは考えていませんでした。
::丁寧なご返答ありがとうございます。なるほど、MediaWikiの仕様かもしれないのですね。そこまでは考えていませんでした。
::この節でも同じ現象が起こるところまでは頭が回りませんでした…ご修正ありがとうございます。--[[利用者:ドングリ|ドングリ]]([[利用者‐会話:ドングリ|会話]]) 2016年12月26日 (月) 05:12 (UTC)
::この節でも同じ現象が起こるところまでは頭が回りませんでした…ご修正ありがとうございます。--[[利用者:ドングリ|ドングリ]]([[利用者‐会話:ドングリ|会話]]) 2016年12月26日 (月) 05:12 (UTC)

== ウィキラブ 不具合 ==

[[ファイル:Wikipedia バグ.png|左]]
{{-}}
--[[利用者:Good2016hey|Good2016hey]]([[利用者‐会話:Good2016hey|会話]]) 2017年1月23日 (月) 13:08 (UTC)

2017年1月23日 (月) 13:08時点における版

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


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

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

他の相談場所
バグの報告の利用方法

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

  1. 問題が発生したページ
  2. 問題が発生したときの状況(可能であれば再現性と再現手順も記載してください)
  3. あなたが使用しているOSウェブブラウザおよびそのバージョン(例:Windows 10 Home 22H2(64ビット、OSビルド:19045.4780)、Google Chrome 128.0.6613.36(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)[返信]

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}}を使用している数式が、モバイルビューだと全く表示されない状態になることを発見しました。

当方が確認した環境は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)[返信]

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

モバイルビューで、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種類です。別行立てする数式に対しては問題ありませんが、文中で使われている場合、レイアウトをかなり崩しています。

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

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

まず、たわみ

、たわみ角

、曲げモーメント



は、それぞれ、





、せん断力

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

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

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

上の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-Bluetalkcontribsmail 2016年8月31日 (水) 17:35 (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)[返信]

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

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.

世界最狂の魔法使いCray-G会話2016年10月13日 (木) 02:22 (UTC)[返信]

(追加報告)その後、<del>を<s>にすることで意図通りの表示とする編集が行なわれました。伴って先のリンク先を旧版へのリンクに差し替えました。また、<small>に加えて<s>と<b>でも発生しなかったことを追加します。--世界最狂の魔法使いCray-G会話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)[返信]

スマホでの画像の大きさ

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/docTemplate: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)[返信]

報告 手持ちの環境での確認結果です。
# 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 件になります[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の「参照読み込みの回数」は?2回?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)[返信]
日本語版では 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)[返信]

各項目の左に『・』がついてない

ページ→12月5日、項目→記念日 各項目の左に『・』がついてないです。よろしくお願いします。--以上の署名のないコメントは、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>)、本来は直接入力せずに&lt;&gt;と入力する必要があります。この制約から考えると、セクション名には&lt;&gt;を使用することが想定されていて、<>を直接使用することは想定外だったのかもしれません。このように考えると、バグというよりMediaWikiの仕様かもしれません。
いずれにせよ、まずはこの現象が再現可能であることをご報告いたします。
なお、この現象が本セクションでも発生するため、セクション名を『要約欄で、節名において山括弧に囲まれた部分が見えなくなる』に変更いたしました。--WwLMvm会話2016年12月25日 (日) 15:13 (UTC)[返信]
丁寧なご返答ありがとうございます。なるほど、MediaWikiの仕様かもしれないのですね。そこまでは考えていませんでした。
この節でも同じ現象が起こるところまでは頭が回りませんでした…ご修正ありがとうございます。--ドングリ会話2016年12月26日 (月) 05:12 (UTC)[返信]

ウィキラブ 不具合

ファイル:Wikipedia バグ.png

--Good2016hey会話2017年1月23日 (月) 13:08 (UTC)[返信]