Wikipedia:バグの報告/MediaWiki1.25

メインページで外装が崩れる

外装の個人設定に初期値「ベクター」を使用してウィキペディアを閲覧しています。普通問題はありませんが、なぜかメインページに行くとトップにはそのページの内容のみ表示されてしまい、外装が崩れてしまいます。OSはOS X 10.6.8、ブラウザはFirefox 30.0です。--カンザス（会話） 2014年10月5日 (日) 07:32 (UTC)

ブラウザのバージョンを更新したりOSを再起動したりした結果、元に戻りました。--カンザス（会話） 2014年10月5日 (日) 07:40 (UTC)

Vertical images list

解決済み

{{Vertical images list}}を用いた表示に於いて、テキストの折り返しが効かなくなってしまったために固定幅の画像の左右に無駄な余白が生じるようになっています（以前はその用は症状はありませんでした）。ユニクロ、中島町 (広島市)、平和大通りなどで確認しています。ちなみに当方、Windows7でブラウザはFirefoxとChromeの両方で不具合を確認しています。--Bsx（会話） 2014年10月14日 (火) 14:04 (UTC)

報告 申し訳ありません。先ほど修正いたしました（編集差分）。--Frozen-mikan（会話） 2014年10月14日 (火) 16:30 (UTC)

確認しました。ありがとうございます。--Bsx（会話） 2014年10月14日 (火) 22:12 (UTC)

ログインできなくなった？

最初に断っておきますが、IE7(Server2008)やIE9(Vista)では大丈夫でしたので、古い環境だけの問題と思われます。ただ当方でXPは検証できる環境が無いので2000のみの確認になります。それでも複数のPCで同様の症状が確認できます。

2k上のIE6やFirefox12にて通常のページは表示できるのに、ログインページだけが見付からない・表示できない旨のエラーが出て、ログインできない状態です。したがってスキンはデフォルトのままですし、セキュリティソフトやJavaScriptも関係ないようでしたので、Wikimedia自体に何らかの変更があったものと思います。なぜかOpera12では今のところ大丈夫なのですが、キャッシュの可能性も捨てきれないので断言はできません。

IE6では「ページを表示できません（略）サーバが見付からないかDNSのエラーです」というネットに繋がっていない時の見慣れたエラー画面でした。Firefoxのエラー文言は以下の通りです。--Gwano（会話） 2014年10月18日 (土) 10:34 (UTC)

安全な接続ができませんでした
ja.wikipedia.org への接続中にエラーが発生しました。
Cannot communicate securely with peer: no common encryption algorithm(s).
(エラーコード: ssl_error_no_cypher_overlap)
・受信したデータの真正性を検証できなかったため、このページは表示できませんでした。
・この問題を Web サイトの管理者に連絡してください。あるいは [ヘルプ] メニューの [不具合のあるサイトを報告] でこのサイトについて報告してください。

IE6 という開発元が「腐った牛乳」と呼んでしまうようなブラウザのご利用はご遠慮ください。ウィキペディア日本語版を含むウィキメディアのウィキでは、ログイン時に https を使用します。しかし先日、POODLE と呼ばれる SSL 3.0 に関する脆弱性が発見されたため(InternetWatch,CNET Japan,IPA,Microsoft Technet)、これに対する対応としてウィキメディアのサーバー側にて SSL 3.0 の対応をやめることになりました([1],m:Tech/News/2014/43/ja)。この措置に伴い、 TLS 1.0 以降の接続しか受け付けなくなっていますので、TLS 1.0 以降での接続に対応しない「レガシーブラウザ」（古いブラウザ）による https 接続が不可能になっています。もしかすると、インターネットオプションの詳細設定で TLS を有効化すれば接続できる可能性もありますが、何れにしてもサポートが打ち切られたブラウザや OS の使用は別の脆弱性が悪用されて利用者のコンピューターがマルウェアの感染を許すことにつながりますので、レガシーブラウザのご利用はご遠慮いただきたく思います。--rxy（会話） 2014年10月18日 (土) 10:54 (UTC)

素早いお返事、感謝いたします。そういうところに記載されていたのですね、失礼しました。何はともあれ家じゅうの端末のSSLを無効に変更しているところです。

もともと私は上のスレにありますようにHelp:MediaWikiに適応するブラウザの観点から、古い環境での制限事項の確認に興味があったのです。いきなりIE6を引き合いに出すのは少々乱暴だったかもしれませんが、確かに私も他者に対しては同じような注意をしたかもしれません。お気遣いに感謝しております。やはり実機での確認は控えたほうが良さそうですね。とにかくTLSに対応しない環境ではログインできない制限が仕様になったという情報が確認できたことですっきりしました。

設定を確認しましたところ、おっしゃるようにIE系は5.0SP4/5.5/6ではいずれもTLS1.0までは対応しているようですがデフォルトで無効になっているようでした。さすがにそこまで古いものであれば当然でしょうけど、それより10年以上も新しいFirefox12（これもとっくにサポート終了ですが）でもデフォルトでTLSが無効だったことのほうが驚きでした。もしかしたら旧バージョンからのアップデートの際に設定が引き継がれていたのかもしれません。だとすれば今回の変更の影響は意外に大きなものかもしれません。--Gwano（会話） 2014年10月19日 (日) 07:39 (UTC)

詳細は私がメンテしているTemplate:ウェブブラウザにおけるTLS/SSLの対応状況の変化などをご覧いただいた方が良いかと思いますが、Firefoxはバージョン1.0の頃からTLS 1.0に対応しており、既定で有効になっています（たしかNetscape 6の頃にTLS 1.0には対応済み）。また、現時点でサポートが継続しているデスクトップ向けOSで利用可能なブラウザは、すべてTLS 1.0が既定で有効であり、SSL 3.0以下での接続しかできないのは一部の古いガラケーやPS3に搭載されたブラウザなどごく一部に限られます。--Claw of Slime (talk) 2014年10月23日 (木) 04:15 (UTC)

なるほどこのような素晴らしい一覧があったのですね。たいへん興味深く拝見させていただきました。今後ともメンテに期待しております。

それにしてもFirefoxでTLSはデフォルトで有効なのですか。なぜ当方では無効になっていたのか気になるところです。もしかしたら旧バージョンの設定ではなく、IE6あたりの規定の旧ブラウザから設定が引き継がれてしまったのかもしれません。もちろん人為的な設定ミスの可能性も否定はできませんが。

ところで細かいことですが、テンプレートにある一覧ではWindows Server 2003とそれ用のIEが赤表示（サポート終了扱い）になっていたようでしたが、これは注釈にあるような部分的サポートの関係で意図的にそう表示しているのでしょうか？ 建前としてはServer2003(R2)およびそれ用のIE6/7/8は2015年7月14日までサポート中かと思います（その意味ではIE6も2003向けに限り、まだサポートが終わっていません）ので、念のため・・・。--Gwano（会話） 2014年10月23日 (木) 13:06 (UTC)

亀レスですが、Server 2003についてはミスでした。サポート継続中として既に修正済みです。--Claw of Slime (talk) 2014年11月30日 (日) 05:07 (UTC)

今更ですが、もうログインとかは関係ないようですね。2000のIE6(SSL2/3無効・TLS1.0有効)について確認してみたところDNSエラーが出て完全にWikipediaを閲覧できなくなっている様子でした。モバイル版も同様です。「プライバシーの強化」でIPからのテキスト閲覧すらできなくなる意味は分かりませんが、もしもこれがOSやブラウザ側の設定変更などで簡単に対応できるようなものでないとしたら、もはや「MediaWikiに適応するブラウザ」とは言えなくなったということかと思います。--Gwano（会話） 2015年7月5日 (日) 09:38 (UTC)

モバイル版の検索

動作環境:Android 2.2 標準ブラウザ (Softbank 003Z)

モバイル版画面上部で検索はできるが、検索候補が表示され検索候補を選択しても何も反応しません。 （例:「スバル」を入力--->「スバル・インプレッサ」「スバル・レガシィ」など検索候補が表示--->選択（反応なし）

他環境でも起こるのでしょうか？--Fmtw2cx40（会話） 2014年10月23日 (木) 01:41 (UTC)

報告 iPhone5、iOS7.1.1上のSafariで、ログイン状態で同様の操作をした場合、候補をタップすると正常に反応します。一度キャッシュを削除して読み込んで見てはいかがでしょうか。（ただ当方Android端末がないのでキャッシュの削除方法についてはお答え出来ません。悪しからずご容赦ください。）--Hokkaido-sm（会話） 2014年10月23日 (木) 03:16 (UTC)

返信ありがとうございます。返信でご指摘いただいてキャッシュの削除を試みましたが、変わりませんでした。その後cookieやフォームデータも消去したり、電源offを試みましたが変化ありませんでした。検索候補を長押しして、ブラウザのメニューが表示されて「開く」をタップすると表示されるのはわかったのですが。--Fmtw2cx40（会話） 2014年10月23日 (木) 03:45 (UTC)

報告 Docomo（N-04E）のAndroid4.1.2の標準ブラウザではモバイル版ウィキペディア日本語版の検索候補に関して問題なく動作することを確認しました。今までできていたのにできなくなったということでしょうか。原因の切り分けの手段として、お使いのモバイル端末で別のブラウザソフトをインストールしてそちらでどうなるかを確認してみてはいかがでしょうか。ここにいる方がSoftBank 003Zで検証できるとは限らないので･･･。もし、別ブラウザで問題がないのであれば、標準ブラウザ側に何かしらの問題があるかもしれません。同様に検索候補の出るサイトで動作を確認して問題がるようであれば、キャリア側に相談したほうが良いかもしれません。--アルトクール(話/歴) 2014年10月23日 (木) 03:56 (UTC)

返信ありがとうございます。（最近wikipedia使ってなかったので）確かではないのですが、検索候補の出方が変わってからのような気がします。（「スバル」で検索すると、今はスバル車関係ばかり表示されますが、前は「スハルト」「スパルタ」などが出ていました。）返信でご指摘いただいたように別ブラウザ(Boat Browser mini)をインストールしてみましたが、標準ブラウザと同様で変化ありませんでした。ありがとうございました。--Fmtw2cx40（会話） 2014年10月23日 (木) 07:36 (UTC)

003Z本体には問題ないようです。他のサイトではタップなど全く問題はないので、Wikipedia内部の問題のようです。--Fmtw2cx40（会話） 2014年10月28日 (火) 01:16 (UTC)

モバイル版のプレビュー表示

解決済み

今日索引ページを編集している時に気づいたのですが、ページを編集した後「次へ」ボタンを押すと表示される画面に、編集のプレビューが一切表示されなくなっています。他のページでも試してみたのですが、すべて表示されませんでした。再起動してみても同じでした。今の編集でも表示されません。AndroidでChromeからのアクセスしか確認できていません（OperaMiniからも確認しようとしましたが、そもそも編集ボタンが押せないようです）が、対応をお願いします。

なお編集要約ではすぐ上の節を編集したことになっていると思いますが、これは仕様です（前々回の更新から要約に自動で編集した節が表示されるようになりました）。--花が凄奴（会話） 2014年10月24日 (金) 09:45 (UTC)

現象が起きている環境の情報が不足しています。使用機材、OSソフト、使用ソフト（バージョンを含めて）、編集内容の詳細（索引の個別ページ？索引そのもの？）、現象の起きた時刻（10/24からは大きく外れることはないと思いますが）を添えてご報告いただけませんか。--アルトクール(話/歴) 2014年10月27日 (月) 07:04 (UTC)

報告 現時点でも上記モバイル版の検索と同じ環境で編集のプレビューが表示されません。他ブラウザ(Boat Brower mini)でも同様です。通常に記事を編集し「次へ」を押してもプレビューが表示されず編集内容の要約入力画面になります。「保存」はできます。--Fmtw2cx40（会話） 2014年10月28日 (火) 01:16 (UTC)

報告 数を検証するしかないかもしれません。Docomo（N-04E）のAndroid4.1.2の標準ブラウザで、自身の会話ページとWikipedia:索引 にほんしをモバイル版でプレビューしたところ、プレビューは正常に行われました。Androidのバージョン違いによる可能性もあるので、Bugzillaにあげるにしてももっと情報が必要です。現在明確な違いはAndroidの4.1.2で動作OK、2.2で動作不良ということぐらいになります。--アルトクール(話/歴) 2014年10月28日 (火) 06:15 (UTC)

報告返信が遅くなってしまい申し訳ありません。今確認してみたところ、プレビューが正常に表示されるようになっていました。適当に数ページを選んで編集してみてもきちんと表示されています。なお機種はdocomoのF-02E、OSはAndroid4.1.2、ブラウザはChrome36.0.1985.131です。--花が凄奴（会話） 2014年10月29日 (水) 12:09 (UTC)

報告 上記報告を受けてこちらでも確認したところ、プレビューは正常に表示されました。--Fmtw2cx40（会話） 2014年10月29日 (水) 23:25 (UTC)

携帯版

Wikipedia編集しても携帯版では何日経ってもなかなか更新されませんが。--ほらー イサムン まん（会話） 2014年10月26日 (日) 14:38 (UTC)

質問 「なかなか更新されません」と言われても困惑するばかりです。更新されないのは、どのページを何時頃に編集した際のことでしょうか。また、「携帯版」とありますが、モバイル版またはアンドロイド用公式アプリのことでしょうか。いずれにしましても、これらにお答え頂いても解決できるとは限りませんのでご了承下さい。--Frozen-mikan（会話） 2014年10月27日 (月) 06:25 (UTC)

地方公共団体関連記事のインフォボックスやテンプレートについて

日本の地方公共団体の記事は、大体右上にインフォボックスがあって、文末にその記事が関連するテンプレート（熊本市であれば熊本県など）があったと思いますが、いつの間にか、記事の文頭左上にインフォボックスがあって、文末のテンプレートの幅も従来の半分のようになっていますが、だれか、大元をいじったんでしょうか?見づらく仕方がありません。

すべての記事に目を通すのは不可能なのですが、日本の地方公共団体関連記事やオーストラリアの地方公共団体関連記事、世界遺産関連記事で発生しているようです。

使っているブラウザは、Google Chromeです。--Tantal（会話） 2014年11月9日 (日) 00:50 (UTC)

表記がなおったみたいです。お騒がせしました。--Tantal（会話） 2014年11月9日 (日) 01:30 (UTC)

コメント 恐らく、サーバーもしくは通信経路上に問題があり、CSSファイルが読み込まれていなかったのだと思います。それらが一時的なものであれば、キャッシュを使わない再読み込み（スーパーリロード）で解決することがあります。--Frozen-mikan（会話） 2014年11月9日 (日) 06:21 (UTC)

画像募集中テンプレが原因の表示ずれ

愛知県道246号刈谷大府線でのテンプレートの表示がおかしくなっており、追いかけたところ{{画像募集中}}の11月20日の修正が原因らしいことが解りました（2014年7月24日の版では異常無し）。

ただ、同日夜に「条件文の展開」を含めた修正が行われてしまったため、普段テンプレートを触っていない当方としては何処を修正する必要があるのか皆目見当がつきません。--KAMUI（会話） 2014年11月21日 (金) 23:05 (UTC)

確かに私の編集が原因でした。虫眼鏡がある方の画像にマウスカーソルを合わせると{{{size}}}と書かれたバルーンが出て奇妙に見えたので修正した次第ですが、思わぬ形で不具合を出してしまい大変申し訳ございませんでした。修正した結果表示は直りましたのでご確認下さい。--K-iczn（会話） 2014年11月22日 (土) 03:47 (UTC)

バグの再現例

[[ファイル:Example.png	50px]]

情報 ご指摘いただいた情報を元に検証を行いました。ご提示いただいたページでは{{Infobox road}}の引数に{{画像募集中}}が使われています。Infobox road では「パイプ構文」でテーブルが記述されています。これらの情報を元に、再現例を作成しました。推測できる仕様として、パイプ構文の中にある二重パイプは他のウィキテキスト部品より処理優先度が高いと思われます。このような出力を回避するためには、二重パイプを記述しないように注意するとともに、テンプレートではパイプ構文を使用しない方が望ましい、と言えます。--Frozen-mikan（会話） 2014年11月22日 (土) 06:06 (UTC)

確認しました。ありがとうございます。--KAMUI（会話） 2014年11月22日 (土) 09:14 (UTC)

分割されている節を1つにまとめると編集フィルターに抵触

聖ヤリマン学園シリーズで2014年11月30日 (日) 02:50の版のうち、ストーリー節のレベル3の見出しを解除して定義の箇条書きで1つにまとめようとすると、編集フィルターに抵触してしまいます。それ以外には特に凝った編集はしていないので、首を傾げるばかりです。--58.98.249.215 2014年11月30日 (日) 03:19 (UTC)

コメント 節レベルを書き換えると、段落ごと動くので大きく書き換えたのと同じ扱いとなります。そして、折悪く「ヤリマン」などと書きまくる荒らしがいるために、それが原因で編集フィルターに引っかかってしまっています。--Jkr2255 2014年11月30日 (日) 03:29 (UTC)

そういうことでしたか。登場人物節との見出し名の被りを解消する意味でもまとめたかったのですが、残念です。--58.98.249.215 2014年11月30日 (日) 03:33 (UTC)

位置情報の表示

ウィキペディア本体ではなくWikipedia:ウィキメディア・ラボの問題なのかもしれませんが・・・

ツールサーバー時代にGeoHackで表示されなくなっていたマピオンの地図へのリンクが（今月に入ってから？）復活していたのですが、位置が北西に450メートルほどずれているようです。--KAMUI（会話） 2014年12月5日 (金) 21:36 (UTC)

とりあえずリンクされないようにしました。--K-iczn（会話） 2014年12月6日 (土) 02:03 (UTC)

報告 この報道でもあります通りリニューアルで世界測地系に対応したためリンクを復活させました。正しい地点を示せていると思いますのでご確認よろしくお願いします。--K-iczn（会話） 2015年2月26日 (木) 12:13 (UTC)

〈ref〉｛｛Cite 判例検索システム｝｝〈/ref〉使用箇所以降で脚注ポップアップが無効になる

記事中に <ref>{{Cite 判例検索システム}}</ref> が使われている記事で、それ以降（正確にはそれを含まずその次から）の脚注ポップアップ（Reference Tooltips）が無効になります。たとえば記事「全日空機雫石衝突事故」では「刑事裁判」節に上記 <ref>{{Cite 判例検索システム}}</ref> が埋め込まれているため、その後にある「民事裁判」節以降は脚注ポップアップが働きません。記事「著作権」では一番最初のref[1]がこの構造になっているためポップアップが働くのはこのref[1]のみで、ref[2]以降はポップアップしません。なお、refに囲まれていない場合（裸の{{Cite 判例検索システム}}）は、その後のrefでもバグを起こさずポップアップするようです。--Starchild1884（会話） 2014年12月15日 (月) 21:49 (UTC)

報告 不具合が出ていると思われるテンプレートの方を修正しました[2]。私の環境において、ご指摘のページでは表示が改善されているように見えますが、いかがでしょうか。--Frozen-mikan（会話） 2014年12月16日 (火) 07:34 (UTC)

コメント 修正ありがとうございます。こちらの環境でも問題が解決しているのを確認しました。

条件文に尻込みして自分で修正するのを投げてしまいましたがただのタグ閉じ忘れとは。どうやらテンプレート読み込みにかかわらず、ref内にインライン要素（span要素を除く）のタグ閉じ忘れがあるとそれより後の脚注ポップアップが働かないようです。ウィキペディア内で使われる可能性が比較的高い sup や s などはフォントの表示が変わるので誤りに気付きやすいですが、今回のような cite (font-style:normal) や、他にはほとんどのブラウザで表示が変わらない abbr などでは気付かれず長く放置されるおそれがありますね。--Starchild1884（会話） 2014年12月19日 (金) 23:23 (UTC)

通知について

通知画面

以前は左上にある表示が画像のように「通知」だったのですが、現在は「警告」になっています。通知内容には感謝やメッセージなど警告に分類されないものが多いですので、以前の表示である「通知」あるいは「お知らせ」に類する表現がふさわしいと思いますが。--Degueulasse（会話） 2014年12月28日 (日) 09:27 (UTC)

報告念のため報告しておきます。Android端末からChromeブラウザで確認してみると、モバイル版表示では今のところ「通知」のままとなっています。一方同じ環境でパソコン版表示についても確認すると、確かに「警告」になっていました。おそらくモバイル版には反映されないか、時間差で反映されるものと思われます。--花が凄奴（会話） 2014年12月29日 (月) 02:22 (UTC)

対処 当該部分を「アラート」に修正しました。原文が当初の「Notifications」から「Alerts」に変更されたのですが、これが「警告」と訳されていたようです。通常alertは「警報」と訳されるかと思いますが、昨今のネットにおける同様の機能は「アラート（機能）」と呼ばれており、「警報」よりもっとカジュアルな意味で使われているため、それを採用しました。「Notifications」から変更されたのは、どうやらFlow（開発中の新しい会話システム）にもメッセージ通知機能があり、その「メッセージ」と「アラート」をタブで切り替えるインタフェースを目指しているようです（mw:Echo (Notifications)/status#2014-08-monthly参照）。このように意図的な変更のようですので、少なくとも全貌が見えるようになるまでは、「通知」「お知らせ」等の意訳より原文を尊重した「アラート」の方が良いと考えました。--Penn Station (talk) 2015年2月4日 (水) 13:22 (UTC)

ありがとうございました。アラートに変更していただいて、とてもよいイメージになりました。確認とお返事が遅くなり申し訳ありませんでした。--Degueulasse（会話） 2015年2月13日 (金) 18:26 (UTC)

新幹線200系電車の画像がおかしい

はじめまして。新幹線200系電車のページで、雪切り室への外気取り入れ口の画像、元々は縦に撮影されたものですが、被写体の200系新幹線電車が垂直に向いてしまっています。問題の画像、クリック→詳細ではちゃんと車輌が水平になっているのですが、どうしたらよいやら…。OSは、Windows7 HomeEdition。プラウザは、Mozilla Fox23です。--おたふくえりす byともみ（会話） 2015年1月5日 (月) 13:27 (UTC)

報告こんばんわ。opera12系の私の環境では次の結果でした。記事では垂直、画像をクリックしても垂直（[3]）、更に画像をクリックすると水平（[4]）。--JapaneseA（会話） 2015年1月5日 (月) 13:35 (UTC)

報告Win7上のFirefox 34、IE 11、Chrome 39、Opera 26、すべてにおいて「記事では垂直、画像ページでも垂直、メディアビューアでは水平」という結果でした。メディアビューア以外ではexifに記録されている画像方向「時計回りに90°回転」が無視されているようです。--Claw of Slime (talk) 2015年1月5日 (月) 13:44 (UTC)

報告おもむろにiPhone5(iOS7系)SafariでPC表示にしますとJapaneseAさんの報告で水平表示となった[5]もビューアも垂直（正しい向きではない）となりました。モバイルビューでは「記事内」「ビューア」「画像詳細ページ(ファイル:Snow_Separate_Room.jpg)」「画像元データ」いずれも垂直です。--Hokkaido-sm（会話） 2015年1月5日 (月) 14:30 (UTC)

filepathとBASEPAGENAMEを組み合わせるとバグ？

Wikipedia:管理者伝言板/各種未処理案件#未対処の即時削除対象ページに報告が上がっていますが、以下の様に"が含まれた状態でBASEPAGENAME経由でfilepathに渡すと正常に取れないようです。

• OK: {{filepath:Admin mop.PNG}} -> "//upload.wikimedia.org/wikipedia/commons/9/96/Admin_mop.PNG"
• OK: {{filepath:{{BASEPAGENAME:File:Admin mop.PNG}}}} -> "//upload.wikimedia.org/wikipedia/commons/9/96/Admin_mop.PNG"
• OK: {{filepath:"BUNGO" type"URAGA".JPG}} -> "//upload.wikimedia.org/wikipedia/commons/2/2a/%22BUNGO%22_type%22URAGA%22.JPG"
• NG: {{filepath:{{BASEPAGENAME:File:"BUNGO" type"URAGA".JPG}}}} -> ""

ただ、{{#ifeq:"BUNGO" type"URAGA".JPG|{{BASEPAGENAME:File:"BUNGO" type"URAGA".JPG}}|True|False}}はTrueを返すので、BASEPAGENAMEが失敗しているようにも見えません。

とりあえず報告まで。何か変な使用をしている場合は指摘下さい（間違ってなさそうならphabricator:行きですかね？）。--青子守歌（会話/履歴） 2015年1月14日 (水) 09:15 (UTC)

情報 BASEPAGENAME関連では以前にも似たような話「Wikipedia‐ノート:即時削除の方針#テンプレート（ファイル1-5）の誤作動？」があり、未解決のままです。--Frozen-mikan（会話） 2015年1月14日 (水) 09:33 (UTC)

BASEPAGENAMEが特定の文字をパーセントエンコードではなく数値参照でエンコードするせいですかね？ここにもPage titles containing certain characters, such as apostrophes ' or asterisks *, may produce unexpected resultsってありますし。全然関係なかったらごめんなさい。--にょきにょき（会話） 2015年1月14日 (水) 12:34 (UTC)

リンク先を参考にして#titlepartsで括ってみました。

• {{filepath:{{#titleparts:{{BASEPAGENAME:File:"BUNGO" type"URAGA".JPG}}}}}} -> "//upload.wikimedia.org/wikipedia/commons/2/2a/%22BUNGO%22_type%22URAGA%22.JPG"

いかがでしょうか。問題がないようでしたら、先の{{Ifexistfile}}の方にも反映したいと思います。--Frozen-mikan（会話） 2015年1月14日 (水) 16:40 (UTC)

報告 {{ifexistfile}}の変更を行いました[6]。--Frozen-mikan（会話） 2015年1月19日 (月) 13:59 (UTC)

ページの下に表示される最終更新の表示がおかしい

解決済み

各ページの下の方で例えば（メインページの例です）、

「最終更新 2014年6月30日 (月) 04:08 （日時は個人設定で未設定ならばUTC）。」

と表示されるべきところが、Google Chromeでは

「最終更新 2014年6月30日 (月) 04:08 （日時は<a href="/wiki/%E7%89%B9%E5%88%A5:%E5%80%8B%E4%BA%BA%E8%A8%AD%E5%AE%9A" title="特別:個人設定">個人設定</a>で未設定ならば<a href="/wiki/%E5%8D%94%E5%AE%9A%E4%B8%96%E7%95%8C%E6%99%82" title="協定世界時">UTC</a>）。<br />」

のようにHTMLのタグがそのまま表示され、リンクが機能しません。OSはWindows Vistaでブラウザのバージョンは39.0.2171.99 mです。スキンをベクター、モダン、モノブック、ケルンブルーのいずれにしても同様の症状が発生することを確認しています。「テキストは〜」以下の文章は正しく表示されています。一方IE9では最終更新日時の部分も含めて正しく表示されます。--以上の署名のないコメントは、本日晴天（会話・投稿記録）さんが 2015年1月15日 (木) 05:52 (UTC) に投稿したものです（本日晴天（会話）による付記）。

Firefox 35、Opera 26、IE 11でも同様です。

送られてくる HTML のソースレベルで < > & " が &lt; &gt; &amp; &quot; と文字参照になっているのが原因ですので、これを「正しく」表示できてしまうIE 9の方がおかしいです。

最終更新 2015年1月15日 (木) 05:54 （日時は<a href="/wiki/%E7%89%B9%E5%88%A5:%E5%80%8B%E4%BA%BA%E8%A8%AD%E5%AE%9A" title="特別:個人設定">個人設定</a>で未設定ならば<a href="/wiki/%E5%8D%94%E5%AE%9A%E4%B8%96%E7%95%8C%E6%99%82" title="協定世界時">UTC</a>）。<br />

すぐ下のライセンスに関する表記は問題ないのですが。

テキストは<a href="//ja.wikipedia.org/wiki/Wikipedia:Text_of_Creative_Commons_Attribution-ShareAlike_3.0_Unported_License">クリエイティブ・コモンズ 表示-継承ライセンス</a>の下で利用可能です。追加の条件が適用される場合があります。詳細は<a href="//wikimediafoundation.org/wiki/%E5%88%A9%E7%94%A8%E8%A6%8F%E7%B4%84">利用規約</a>を参照してください。<br />

--Claw of Slime (talk) 2015年1月15日 (木) 07:01 (UTC)

追記。それぞれの元になっているMediaWiki:Lastmodifiedat、MediaWiki:Wikimedia-copyrightではどちらも正しく < > & " が表記されていますので、MediaWiki自体の不具合のように思えます。--Claw of Slime (talk) 2015年1月15日 (木) 07:07 (UTC)

IE9において例の部分のソースコードを確認したところ

最終更新 2014年6月30日 (月) 04:08 （日時は<a href="/wiki/%E7%89%B9%E5%88%A5:%E5%80%8B%E4%BA%BA%E8%A8%AD%E5%AE%9A" title="特別:個人設定">個人設定</a>で未設定ならば<a href="/wiki/%E5%8D%94%E5%AE%9A%E4%B8%96%E7%95%8C%E6%99%82" title="協定世界時">UTC</a>）。<br />

テキストは<a href="//ja.wikipedia.org/wiki/Wikipedia:Text_of_Creative_Commons_Attribution-ShareAlike_3.0_Unported_License">クリエイティブ・コモンズ 表示-継承ライセンス</a>の下で利用可能です。追加の条件が適用される場合があります。詳細は<a href="//wikimediafoundation.org/wiki/%E5%88%A9%E7%94%A8%E8%A6%8F%E7%B4%84">利用規約</a>を参照してください。<br />

になっていますね。ブラウザ側が文字参照を勝手に変換したんでしょうか？--本日晴天（会話） 2015年1月15日 (木) 07:46 (UTC)

（編集競合）こちらで確認してもIE9では確かにメインページではフッターが正しく表示されていました。しかし、IE9がおかしいわけではないようです。HTMLソースを確認したところ、メインページに対して送られてきたソースは問題個所が文字実体参照になっていない正しいものでした。本ページでは他のブラウザと同様に不正表示となっており、ソースでは問題個所は文字実態参照になっています。--Kusunose（会話） 2015年1月15日 (木) 07:51 (UTC)|

MediaWikiのアップデートの影響みたいですね（phab:T86702）。WhymさんがMediaWiki:Lastmodifiedatに応急処置をしてくださり、現在は（リンクがされていないことを除いて）正しく表示されています。--本日晴天（会話） 2015年1月15日 (木) 15:43 (UTC)

署名日時と記録日時に時間差がある

最近気付いたことですが、署名の日時と記録日時に大きな時間差が生じる場合があります。私が把握したものでは最大約4分異なる場合がありました。

以下に実例を示します。記録の方は署名と比較しやすいように既定の形式にしていますが、便宜上秒を追記しています（日時は全てUTCです）。

時間差約4分（約3~4分） 事例4分-1 記録：2015年1月24日 (土) 14:44:02 署名：2015年1月24日 (土) 14:40 (UTC) 事例4分-2 記録：2015年1月30日 (金) 18:01:02 署名：2015年1月30日 (金) 17:57 (UTC) 時間差約3分（約2~3分） 事例3分-1 記録：2015年2月4日 (水) 13:44:25 署名：2015年2月4日 (水) 13:41 (UTC) 時間差約2分（約1~2分） 事例2分-1 記録：2015年1月28日 (水) 14:33:03 署名：2015年1月28日 (水) 14:31 (UTC)

事例2分-2 記録：2015年2月3日 (火) 15:35:01 署名：2015年2月3日 (火) 15:33 (UTC) 時間差約1分（約0~1分） 事例1分-1 記録：2015年1月18日 (日) 09:05:08 署名：2015年1月18日 (日) 09:04 (UTC) 事例1分-2 記録：2015年1月30日 (金) 11:59:02 署名：2015年1月30日 (金) 11:58 (UTC) 事例1分-3 記録：2015年1月31日 (土) 18:16:03 署名：2015年1月31日 (土) 18:15 (UTC)

想像ですがこれらの原因として、システム内部で署名を展開してから最終的に記録をコミットするまでに高負荷のためキューで処理待ちになった、あるいは署名を展開するサーバと記録をコミットするサーバとの間で時刻の不整合がある、といったことが考えられます。その原因は、コーディングのミスなのか、運用上の問題（設計上の問題、何らかの設定ミス、想定を超えるトラフィック、等）なのか、分かりません。

事例2分-2の直後（実感として1~2秒後、記録日時では2015-02-03T15:35:01→2015-02-03T15:35:08）の編集[7]では署名日時と記録日時が一致（少なくとも分レベルでは）していますので、キューの処理待ちがはけて処理が一気に進んだ、あるいは事例3の署名展開がたまたま時刻が遅れているサーバで処理された、といったことが想像できます。同様の現象は、事例3分-1とその直後の編集[8]でも見られました。

いずれにしても、署名日時が記録日時と最大4分も違うというのは結構大きな問題で、投票等で問題が生じる可能性があります。--Penn Station (talk) 2015年2月3日 (火) 18:32 (UTC) 追記・事例番号更新：Penn Station (talk) 2015年2月4日 (水) 14:17 (UTC)

報告 再び4分差の事例がありましたので追加報告します。

時間差約4分（約3~4分） 事例4分-3 記録：2015年2月17日 (火) 12:11:19 署名：2015年2月17日 (火) 12:07 (UTC)

これも直後（記録日時では2015-02-17T12:11:19→2015-02-17T12:11:44）の編集[9]では署名日時と記録日時が分レベルで一致しています。--Penn Station (talk) 2015年2月18日 (水) 09:46 (UTC)

全ての処理が重い状態が24時間以上継続している件

こちらへ報告するのが適切かどうか分かりかねますが、昨晩（2月13日）よりページ表示・遷移など全ての動作が非常に重くなる現象が現在まで続いている件を報告させていただきます。Windows7 SP1環境にてFirefox35.0.1 / Chrome40.0.2214.111 / IE11.0.9600.17633の3つのブラウザで確認しましたが、全てのブラウザで再現しました。現象は多少軽くなったり重くなったりを繰り返しつつ継続しており、酷い場合はタイムアウトエラーが出てページが全く表示されないこともあります。

簡単に検証してみたところ、端末にて何かしらの操作を行った場合、そのリクエストはサーバー側へ送られて正常処理されるものの、処理後のサーバー側からのリダイレクトが遅延している状態のようです。たとえば、とある記事の削除を行うとして、削除ボタンを押下すると削除処理自体は正常かつ迅速に行われるのですが、通常であれば処理後すぐに表示される「正常に処理されました」といった類のメッセージが出ず、処理を実行した時のページがずっと表示されたままになっている、といった具合です。

なお、同様の現象はWikipediaに限らずCommonsやWikinewsなどウィキプロジェクトに含まれる全てのウェブサイトにて発生しています。また、この現象は全ての利用者に共通するものではないようで、現状でも何ら問題なく閲覧・編集できている方も多くいらっしゃるようですが、仮にこの現象が私が使用するISPの経路障害などによるものでないとすれば、たとえばサーバーの内部処理に関するモジュールの更新に起因するものであるなど、サーバー側の原因によって引き起こされている現象なのではないかとも思われますので、こちらにて報告させていただきました。--MaximusM4（会話） 2015年2月14日 (土) 11:52 (UTC)

コメント MaximusM4様が上記でご報告されているその現象、私の方でも発生しております（当方もこのページに報告しようかと思っていたところでした）。私がWikipediaにメインでアクセス（編集）する環境はWindows 8.1、Firefox35.0.1で、JcomのCATV回線なのですが、Firefox35.0.1だとWikipediaになかなか繋がってくれません。Chrome40.0.2214.111だとこれが嘘のように軽くて普通にWikipediaにアクセス出来ます（この報告もChrome40.0.2214.111のプラウザで行っています）。私のFirefox35.0.1でのWikipediagへのアクセス不能状態は実は日本時間の2015年2月13日（金曜日）夜から発生しており、原因が不明でどう対処して良いか判らぬ状況です（Firefox35.0.1では、Wikipedia以外のサイトへのアクセスは普通に出来ます）。インターネット上の回線関連に詳しい利用者の方でこの問題を解決してくれる方がいらっしゃれば良いのですが……　この現象に関する対処関連についてご回答を戴ければ幸甚に存じます。--利用者:Geogie（会話 / 投稿記録 / 記録） 2015年2月15日 (日) 04:04 (UTC)

コメント ひとまず切り分けとしてブラウザの初期設定で試してみてはいかがでしょうか。Firefoxなら新しいプロファイルマネージャで新しいプロファイルを作成、Chromeならユーザーを追加するのが簡単でしょう。TLS/SSL絡みとかかもしれません。--Wolf359borg（会話） 2015年2月15日 (日) 07:58 (UTC)

私も2月13日辺りから同様の症状が出ています。普段はWindows 7 Internet Explorer 11.0.9600.17633からアクセスしております。一応、Google Chrome40.0.2214.111からもアクセスしてみましたが、私の場合ですとやはり重いですね。今使用しているInternet Explorerの方がまだ軽いと感じるくらいです。CommonsやWikinewsなどは普段使用しないので私の方ではよく分かりません。--赤羽さん（会話） 2015年2月16日 (月) 01:54 (UTC)

コメント 当方もFirefox35.0.1、Win8.1で同様の現象が発生していました。そこで、個人設定を「モノブック」から「モダン」に変更したところ、とりあえず解消したように感じます。もともと、Wikipediaのロゴ(?)のところで引っかかっているような感じがしたので。一応参考まで。--みそがい（会話） 2015年2月16日 (月) 05:49 (UTC)

追加報告　個人設定の変更は関係ないようです。やはり遅い状態は発生します。--みそがい（会話） 2015年2月16日 (月) 12:23 (UTC)

Win7 64bitです。Firefox35.0.1のプロファイル追加は解決になりませんでした。IE 11.0.9600.17633共々状態としては、軽々大きなページが読めたり、2Kもない記事が真っ白になったりと安定していないと言った方がいい状態です。Wikidata、Commons、他言語版でも同様の結果になります。--Open-box（会話） 2015年2月16日 (月) 11:21 (UTC)

コメント ページ表示が重い件、まだ継続しているでしょうか? もし、そうならば各自でどの通信で時間がかかっているのかを調べて情報をあげていただいた方がよろしいかと思います。私もですが、問題が出ていない環境では状況がまったくわかりませんので。調べ方ですが、Firefox、Chrome、IE11のどれもF12を押すと開発者用ツール画面が開くようになっています。そしてネットワーク（Network）というタブがありまして、その画面でリクエスト／応答の通信状況を調べられるようになっています。各ツールの使い方は下記を参考にしてください。

• Firefox - ネットワークモニタ - 開発ツール (MDN)
• Chrome - Web開発でよく使う、特に使えるChromeデベロッパー・ツールの機能 (Build Insider)
• IE11 - Web ページのネットワーク トラフィックを分析する (Windows)

--Wolf359borg（会話） 2015年2月18日 (水) 09:25 (UTC)

報告 私の環境（Windows 8.1、Chrome 40.0.2214.111 m、IE11）でもやはり先週土曜日からレスポンスが非常に遅い状態が続き、管理作業もままならなかったのですが、本日午後に（？）問題が解消しました。現在は以前よりむしろ速くなった気がします。サーバ側の問題だったのではないでしょうか。--Penn Station (talk) 2015年2月18日 (水) 09:27 (UTC)

報告 先ほどログインしましたが、現在私の環境下（Windows 7 Internet Explorer 11.0.9600.17633、Chrome 40.0.2214.111 m）でも問題が解消したようで、特にページが重いという事もなくスムーズに動作しております。どうやらWikipedia側でソフトウェアの更新を行った様なので、そこら辺の調整がうまくいっていなかったのではないかと思います。--赤羽さん（会話） 2015年2月18日 (水) 12:37 (UTC)

報告 今朝方の段階では不安定な状況だったものが、夕方頃にアクセスした際には今までの重さが嘘のように正常に戻っており、先に述べたいずれのブラウザでも正常動作を確認しました。Penn Stationさん・赤羽さんお二方のご報告によれば私以外の環境においても問題が解決したようですので、このまま数日以内に再発ないし不具合が継続中とのご報告がなければ、こちらの報告については解決済みとさせていただきたいと思います。--MaximusM4（会話） 2015年2月18日 (水) 14:44 (UTC)

報告 拙者の方の環境では昨日（2月17日午後11時頃 - 日本時間）の時点では、FirefoxでのWikipediaへのアクセスは不能状態でした。それが1日明けた、2月18日午後2時頃【日本時間】からFirefoxでも軽々とアクセス出来るようになっております。赤羽さんご指摘のように、Wikipedia財団側のサーバーソフトウェア更新の問題だったんでしょうかね…… このまま何事もなければ（最低でも2月21日土曜あたりまで）、本件は解決済みと見ても良かろうかと拙者も思っているところです。--利用者:Geogie（会話 / 投稿記録 / 記録） 2015年2月18日 (水) 14:56 (UTC)

コメント Special:Versionによりますと、現時点の日本語版WikipediaのMediaWikiのバージョンは「1.25wmf16 (63a4144) 2015年2月18日 (水) 03:32」（日時はJST）となっていて、概ね問題解消のタイミングと一致しています（Geogieさんの「午後2時頃」と若干ずれがありますが、バージョンで表示されるのは最終的に更新処理が終わった時刻？）。MediaWikiのロードマップと異なっていて更新前のバージョンがわかりませんが、少し前にも性能問題でMediaWikiのバージョンが戻された[10]ようですので、今回も赤羽さんさんご指摘のようにMediaWikiの何らかの不具合だった可能性がありますね（phabricatorで少し探してみましたが、原因を見つけきれませんでした…）。--Penn Station (talk) 2015年2月18日 (水) 16:21 (UTC)

あれ、すみません、MaximusM4さんは朝の段階では不安定だったんですね…。私は朝は未確認で、午後に解消していることを確認しました。キャッシュかCookiesか何かの影響が残っていたのかもしれませんね…。何はともあれ直って良かったです。--Penn Station (talk) 2015年2月18日 (水) 16:43 (UTC)

コメント 解消の要因かはわかりませんが、マイものはありません。ナーバージョンアップのロードマップを見る限り、2月11日の23時前後(UTC)にWikipediaが1.25wmf16、testwikiが1.25wmf17にVerUpしたあたりから問題が出ていると推測できて、2月17日21時前後(UTC)にWikipediaを除いた姉妹プロジェクトが1.25wmf17にVerUp、それの直後にWikipedia側でも何らかの更新（修正Up？）がされているようです。（現時点ならn:Special:VersionとSpecial:Versionを見比べればよいかと）

アナウンスがないので推測になりますが、wmf17が16と技術的な衝突を起こしたとか、Wikipediaにwmf16をUpする際に何らかの技術的な要因があったとかに原因がありそうな感じです。ロードマップを見ると、今後も細かなアップデートが予定されています（直近では今日、Wikipediaがwmf17に更新）ので、今後も重いと感じた際にはMediaWikiの更新情報を確認してみたほうがよさそうです。--アルトクール(話/歴) 2015年2月18日 (水) 18:22 (UTC)

どうやらロードマップに掲載されていない更新がありそうなのです。そう思う理由は、(1) 性能問題が発生したのは14日 JST（11-13日は問題なかった） (2) 18日 03:32 JSTに1.25wmf16 (63a4144)が配備された（その結果性能問題が解消）、の2点です。いずれもロードマップにはありません。(1)については、(a) 予定通り11日に配備した1.25wmf16に問題があり、14日になんらかのきっかけでそれが顕在化した　(b) 14日になんらかの更新を行いそれが原因で問題が発生した、の2通りが考えられると思います。私の翻訳したMediaWikiのメッセージ（translatewiki.net）が一度は反映されたのに、再び元の英語に戻ってしまった、ということもあるので、(b)を疑っています。いずれにせよ結果から推測すると、18日 03:32 JSTの更新は性能問題への対処を目的とする応急処置（リバート？）だったと思われます。

そして現在のバージョンは「1.25wmf17 (586b418) 2015年2月19日 (木) 09:23」で、昨夜（今日早朝）ロードマップ通り更新されたようですね。グローバル利用者ページが有効になっています。--Penn Station (talk) 2015年2月19日 (木) 13:42 (UTC)

CommonsがChromeでつながらない

実を言うと私も半年以上困っている問題があります。Windows7 SP1（64bit）およびChromeの組み合わせでCommonsが繋がらない。症状的にはオーバーフロー状態に少なくとも半年近く悩まされています。少なくとも同じパソコンでもIEでは普通に繋がります。また、ネットブック（Windows7 SP1（32bit）+Chrome）では異常は発生していません。尚、上記の全ての処理が重たいですが、個人的には発生していないようです。--Taisyo（会話） 2015年2月15日 (日) 12:36 (UTC)

PC側の条件はほぼ同等ですから、問題があるとすればChromeの64bitブラウザと何かが衝突を起こしてるような感じがします。IEは64bitOSで動作していても、拡張保護モードがONになっていなければ子プロセスが32bitで動作したはずですので「64bit版ブラウザ」として切り分けるならインターネットオプションから拡張保護モードをONにしてみてIEでも確かめてみてください。同様の問題でお困りの方や調査に協力してくれる方は以下の条件を検証してみてください。

検証環境A 64bitOSのユーザー

• Windows7 64bit (SP1が推奨) がインストールされている
• Chrome 64bit版がインストールされている
• IE10以上がインストールされている

検証環境B 32bitOSのユーザー

• Windows7 32bit (SP1が推奨) がインストールされている
• Chrome 32bit版がインストールされている
• IE10以上がインストールされている

検証項目

1. ChromeでコモンズとWikipediaにアクセスしていくつかのページを閲覧（メインページ、Wikipedia:方針とガイドライン、熊野三山本願所、コモンズ、c:Commons:Policies and guidelines、c:File:Myoshinji temple.jpg）。特に熊野三山本願所の中段にある「妙心寺」の画像はコモンズからの呼び出し画像です。これの表示に問題がないかを確認してください。
2. IEの「拡張保護モード」をOFFにしている状態でコモンズへアクセスしていくつかのページを閲覧。
3. IEの「拡張保護モード」（IE11の場合は拡張保護モードの64bit動作もチェック）をONにした状態でいくつかのページを閲覧（32bitOSでは必要なし）。

報告内容

1. 使用OS情報
2. 使用ブラウザのバージョン情報
3. 各動作環境における状況

手間でなければ、別のブラウザでも検証した情報を載せると原因追及がしやすくなります。場合によってはファブリケータに情報を提供して確認してもらうことも必要になります。コモンズ固有の問題だとしても、これを呼び出す各プロジェクトにも影響を与える可能性があります。プロジェクト間に問題がないようであれば、こちらでの検証結果をコモンズ側に持ち込んで、あちらで調査してもらったほうが良いかと思います。--アルトクール(話/歴) 2015年2月19日 (木) 03:28 (UTC)

---

Aに相当する環境で、いくつかのブラウザで検証してみました。

• Win7 x64 Professional SP1
• Google Chrome 40.0.2214.111 m (64-bit)
• Google Chrome 42.0.2308.0 canary (64-bit)
• IE 11.0.9600.17633（今月のアップデートまで適用済み）
• Firefox 35.0.1 x86
• Firefox 38.0a1 x86_64 (2015-02-18)
• Opera 27.0.1689.69
• Opera developer 29.0.1778.0

Chrome 40および42 canary（いずれも64ビット版）、IE 11（拡張保護モードON、OFFいずれも）、Firefox 35.0.1（32ビット版）および38.0a1（64ビット版）、Opera 27およびdeveloper 29（いずれも32ビット版）でテストページ（メインページ、Wikipedia:方針とガイドライン、熊野三山本願所、コモンズ、c:Commons:Policies and guidelines、c:File:Myoshinji temple.jpg）を閲覧しましたが、いずれにおいても繋がらない、アクセスが重い、コモンズ呼び出しの画像が表示されないといった問題は確認できませんでした。--Claw of Slime (talk) 2015年2月19日 (木) 04:32 (UTC)

---

私もAに相当する環境下で検証しました。

• Win7 64bit Pro SP1
• Google Chrome 40.0.2214.111 m (64-bit)
• IE 11.0.9600.17633

結果はClaw of Slimeさんと同じで問題は再現しませんでした。もしかするとクロームそのものが壊れているとか、インストールしている領域に不具合が出ているとかそういう可能性も考えたほうがいいかもしれません。ただ、今のところ検証環境のWin7のエディションがProfessionalなので、別のエディションで出る可能性も残されています。--アルトクール(話/歴) 2015年2月25日 (水) 13:32 (UTC)

「削除依頼/ログ/先週」の表示範囲が1日ずれている

Win7(32bit)/IE11環境でWikipedia:削除依頼/ログ/先週を閲覧したところ、表示範囲が1日ずれていました。具体的には「7日から13日前」を表示しなくてはならないところで「8日から14日前」を表示しているようです。--Mashir43（会話） 2015年2月23日 (月) 05:29 (UTC)

今見たら直ってました。最近重いっていうし、更新遅れとかあったんですかね？しばらく様子見てみます。ご迷惑おかけしました。--Mashir43（会話） 2015年2月23日 (月) 09:04 (UTC)

コメント ときどきキャッシュが残ってしまうことがあります。キャッシュを破棄して様子を見てみましょう。--Jkr2255 2015年2月23日 (月) 10:41 (UTC)

利用者単位でのリンクの下線表示

解決済み

;環境：PC（二台とも同様）

• Win7 Home premium

• IE11

環境：スマートフォン（ブラウザPC要求）

• Android 4.4.2

• CM Browzer

このアカウントにログインをすると全てのWikipediaのリンクに下線が付きます。一応確認の為にIEの設定を確認したところ、下線は付けない設定になっていました。さらに、Wikipedia:FAQ 特に多い質問#突然全てのリンクに下線がつくようになりましたの順をおってしてみても効果はなく、無駄でした。また、この問題が発生したのは別のPCで元は発生したものであり、これらからおそらくデバイス上の問題ではないと考えられます。発生までは個人設定をいじっており、それが原因かと思い設定を探しても無かった為知恵を貸して頂きたいと思った次第です。 ——以上の署名の無いコメントは、フルブル（ノート・履歴）さんによるものです。フルブル（会話/投稿）　早々ながら解決しました。設定を初期化することによりリセットしたようです。--フルブル（会話/投稿） 2015年2月25日 (水) 13:41 (UTC)

俳優のテンプレートの不具合

解決済み

剣幸を閲覧していましたら自動計算される年齢が反映されていません。不思議なことにログインすると正確になります。バグかどうか分かりませんが、ご報告まで。Windows7とAndroid4.2.2を使用しています。--アッコ（会話） 2015年3月2日 (月) 04:37 (UTC)

追記：3月2日が誕生日の方々を何人か見てみたのですが、ジャンルを問わず年齢が反映されている方と反映されていない方が入り交じり困惑しております。--アッコ（会話） 2015年3月2日 (月) 08:20 (UTC)

キャッシュが残っているのかもしれません。（ページを高速に表示するため、ページは毎回一から構築されているわけではなく、前回同じページを閲覧した際の内容を使いまわしているため、古い年齢が残っていると思っていただければ。）空編集によるキャッシュの破棄を試してみてください。--朝彦（会話） 2015年3月2日 (月) 17:10 (UTC)

ご回答ありがとうございます。空編集をしてみたら正確になりました。しかし再起動をすると間違ったものに戻ってしまいます。またモバイル版は空編集自体が出来ません。しばらく様子を見て次に編集する時に思い切って生年を除去するしかない様に思います。昨年までは全く問題がなかったので戸惑うばかりです。--アッコ（会話） 2015年3月2日 (月) 23:26 (UTC)

キャッシュにはウィキメディアのサーバ上のものと、あなたのお使いの端末上のものの二つがあります。あなたの端末のキャッシュもクリアしてみてください。いずれにせよキャッシュの問題は一時的なものです。次第に古いキャッシュはなくなり、数日から数週間もすれば全ての環境で正しい表示になるはずです。そもそも百科事典という都合上、日ごとのレベルで最新の情報であるとは限らない性質のサイトであることをご理解のうえ、一時的な問題のために情報を除去するなどという逆行的なことはなさらぬようお願いします。--朝彦（会話） 2015年3月2日 (月) 23:49 (UTC)

端末のキャッシュは使うたびに消去しております。言葉足らずでしたが、少なくとも1ヶ月は様子を見るつもりでした。キャッシュの問題は一時的なものとのことなので情報を除去する編集は、いたしません。この度は、ご教示ありがとうございました。これで解決済みとさせて頂きます。--アッコ（会話） 2015年3月3日 (火) 00:53 (UTC)

左メニューバーの文字化け

左のメニューバーの「他言語表示」のところにある国の名前がいくつか「□□□□□」のような表示になっています。約10時間前からずっとこうです。多分特殊文字の表示ミスだと思いますが…。--初音ミク初音ミク初音ミク（会話） 2015年3月2日 (月) 04:37 (UTC)

お使いの機器にその言語を表示させるためのフォントがインストールされていないか、その文字に対応していません。日本語環境が入っている機器で多いのは、韓国語やアラビア語などのアルファベット以外の文字を使用する言語の代替フォントの設定なしや、フォントなしが多いのでご確認ください。

状態としては「あ」を表示するために、機械の中に「あ」のフォントを探しにいくのですが、「あ」がある場所に「×」があって、それを機械が「あ」だと勘違いして「×」を表示しているものです。フォントが用意されていない場合、不明文字として「□」をあてるようにしている設定が多いため、文字化けしてしまいます。--アルトクール(話/歴) 2015年3月28日 (土) 08:39 (UTC)

iOS版Wikipediaアプリで、ログイン中の編集が匿名利用者となってしまう問題

• 問題のIPアドレスは103.5.142.30
• 編集ページ:閃光ライオット
  • 差分：閃光ライオット
• 編集時の状況:
  • スターバックスのフリーWi-Fi(at_STARBUCKS_Wi2)に接続
  • iOS版Wikipediaアプリからの編集
• 編集端末:
  • 第5世代iPod touch
  • iOS8.2
  • Safari

スキンは変更しておりません。SafariiOS版Wikipediaアプリのバージョンは確認方法がわからなかったため不明です。 --TDstar（会話） 2015年3月16日(水) 13:50(UTC)
3月16日のバグがiOS版Wikipediaアプリからの編集でしたので、報告内容を修正しました。また、同様のバグが再発したので、加筆します。

• 2015年3月27日(金) 8:16(UTC)に行った114.134.212.83によるSCHOOL OF LOCK!の編集(差分：SCHOOL OF LOCK!)。iOS8.2、iOS版Wikipediaアプリからの編集。

2件のバグ発生の日時から、iOS版Wikipediaアプリのバージョンは、4.0.6と思われます。再インストールにより、アプリからのバグ発生は無くなりましたが、原因は不明です。 --TDstar（会話） 2015年3月28日(土)1:28(UTC)

対象アプリはWikimedia Foundationが開発しているWikipedia Mobile (iOS版)でよろしいでしょうか。

推測になりますが、アプリ内でのセッション情報が切れた可能性があるかと思われます。閲覧段階、あるいは編集直後でウォッチリスト等が閲覧できないなどの問題が起こるなら、App内でのアカウント連携が解除されてしまった可能性もあります。再インストールにより問題が解消しているなら、インストール段階の不具合の可能性もあります。

しばらくそのまま使ってみて、サイド問題が発生するようならPhabricatorへバグの報告を行って解決を図ったほうがいいかもしれません。--アルトクール(話/歴) 2015年3月28日 (土) 08:29 (UTC)

コメントが遅くなり申し訳ありません。アプリケーションはご提示のものです。iOS8.2への更新後にトラブルが発生しました。再ログインで解決しなかったため、再インストールを行ったところ、改善された次第です。iOS8.2への更新後に問題が起きていることから、iOS8.2での変更が影響している可能性が考えられると思います。--TDstar（会話） 2015年4月1日(月) 13:34(UTC)

iOS8.2のSafariでの編集トラブル

iOS8.2のSafariにおいて、携帯機器版の編集画面がスクロール出来ないバグが発生しております。接続している回線、編集しているページに関係なく発生しています。編集端末は、第5世代iPod touchです。スキン等は変更していません。 --TDstar（会話） 2015年3月28(土)1:28(UTC)

SafariあるいはiOS側の問題の可能性があります。一度Appを終了させたり、再起動してみてください。iOS7.1.2の環境下でモバイル版、デスクトップ版ともに問題は再現しませんでした。別のプロジェクト（英語版や日本語版ウィクショナリーなど）、別運営によるMediaWikiのページ（アンサイクロペディア、ウィキトラベルなど）で問題が発生するかの検証も有効かと思われます。--アルトクール(話/歴) 2015年3月28日 (土) 08:34 (UTC)

コメント 同じiOS 8.2のiPod touchで確認しましたが、同様の問題が起きています。英語版（en:Wikipedia:Bug_reports_and_feature_requests）でも再現しました。--Jkr2255 2015年3月28日 (土) 12:01 (UTC)

言語間リンクの不具合

世田谷一家殺害事件において、Wikidataのページに日本語版と中国語版のページへのリンクが記載されているにもかかわらず、中国語版へのリンクがサイドバーに記載されません。しかし中国語版のページでは日本語版に飛ぶことができます。こちらの環境はOSがWindows7、ブラウザがIE11、外装はベクターです。--ドングリ（会話） 2015年3月30日 (月) 04:26 (UTC)

コメント 日本語版ウィキペディアでは、いくつかのページ（参考: APIによる検索結果）において他言語版へのリンクを非表示にしています。明確な規定は無いものと思いますが、主にプライバシーや名誉毀損の問題がリンクURLの文字列や他言語版の内容にも及ぶことを懸念しているようです。技術的にはソースの中にマジックワード{{noexternallanglinks}}を配置することで実現しています（参考: Help:マジックワード#ページ, mw:Extension:Wikibase_Client#noexternallanglinks）。このマジックワードを使用することについては、数カ所で議論が行われたことがあるようです（参考: [11]）。--Frozen-mikan（会話） 2015年3月30日 (月) 06:47 (UTC)

返信 そういった事情があるのですね。バグでなくてよかったです。丁寧な説明ありがとうございました。--ドングリ（会話） 2015年3月31日 (火) 05:01 (UTC)