MediaWiki‐ノート:Common.js

記事名チェック機能についての議論は/記事名チェッカで行っています。

mw.loader.loadのローカル版(document.writeの呼び出し対策など)

Wikipedia:バグの報告#ページが真っ白になることがある (MediaWiki 1.17)にあるように、1.17ではdocument.writeが不具合を起こす可能性があるとして非推奨になりました。

しかし、document.writeは、大昔にスクリプトやスタイルシートの読み込みとして、利用者スクリプトで広く使われたこともあり、依然として多くの利用者スクリプト中に紛れ込んでいます。

スクリプトとスタイルシートを読み込む手法として、代わりに推奨されているのが、mw.loader.loadメソッドですが、これは(第一)引数がURLではなくてはならず、ローカルのスクリプトやスタイルシートを呼び出すのには少々面倒です。 一方、従来からある方法としてはimportScriptが第一引数にページ名を指定できますが、こちらもmw.loader.loadへの移行を推奨されているものです。

ということで、主にdocument.writeからの移行促進(と、あとは簡便さ)のために、mw.loader.loadを簡単に呼び出せるヘルパーを組み込むことを提案します。内容としては

// ローカルのスクリプトを読み込む
//  pagename: 呼び出すスクリプトのページ名
//  使用例:mw.loader.loadScript("利用者:ウィキ助/example.js");
mw.loader.loadScript = function(pagename) 
{
	// "サーバー + スクリプト + action=raw&ctype=text/javascript&title=pagename"をスクリプト呼び出し
	mw.loader.load(mw.config.get("wgServer") + mw.config.get("wgScript") + "?action=raw&ctype=text/javascript&title=" + mw.util.wikiUrlencode(pagename), "text/javascript");
}

// ローカルのスタイルシートを読み込む
//  pagename: 呼び出すスタイルシートのページ名
//  使用例:mw.loader.loadStyleSheet("利用者:ウィキ助/example.css");
mw.loader.loadStyleSheet = function(pagename) 
{
	// サーバー + スクリプト) + action=raw&ctype=text/javascript&title=pagename"をスタイルシート呼び出し
	mw.loader.load(mw.config.get("wgServer") + mw.config.get("wgScript") + "?action=raw&ctype=text/css&title=" + mw.util.wikiUrlencode(pagename), "text/css");
}

もしかするとこの先、ライブラリとして追加されるかもしれませんが(c.f. bugzilla:25845)、少なくともそれまでの間はあった方が良いと思います。

問題はメソッド名で、案としては

  • mw.loaderにloadScript/loadStyleSheetを新しく追加する(先述の例はそのような感じ)
  • グローバルにloadScript/loadStyleSheetを新しく追加する
  • 既存のimportScriptやimportStyleSheetに上書きしてしまう

の3つがあると思います。

ヘルパーを追加することの賛否およびメソッド名をどうするか、ご意見よろしくお願いします。--青子守歌会話/履歴 2011年2月17日 (木) 17:53 (UTC)[返信]

コメント まず、ヘルパーの追加はしたいところですが、名称について。3つ目の場合は、現在すでにimportScriptを使っている人もmw.loader.load機能を使えるようになるという長所はあるものの、既存のものを上書きする(名前を衝突させる)のは、思いがけない不具合を引き起こす可能性もあるので、個人的にはあまり推したくはないです。となると1か2ですが、前者は既存のライブラリを独自拡張することになる、後者は(せっかくmwにまとめられてきれいになった)グローバルに新しいグローバル関数を追加することになり、保守性あるいは名前の衝突回避という点であまりよろしくない、という欠点をそれぞれ抱えていると思います。なので、あとは好み?の問題にもなってくるかもしれませんが、私自身はどちらかというと1でいいのではないかなと考えています。で、もし2にするぐらいなら、jawpのような新しい名前空間(クラス)を作って、そこに追加した方が設計的にはよいように思いました。--青子守歌会話/履歴 2011年2月17日 (木) 17:53 (UTC)[返信]
コメント 青子守歌さんが提案している jawp のような新しい名前空間を利用することに賛成します。mw や mediawiki は、MediaWikiが公式的に提供してるライブラリで使われており、拡張を推奨するような記述が無い限り、それらの名前を使うことは避けるべきです。また、MediaWiki1.17 では importScript, importScriptURI, importStylesheet, importStylesheetURI の4つの関数が非推奨になっており、これらのグローバル名前空間にある関数を上書きすることは避けたほうが良いと思います。しかし、これらの関数と同等の名前と機能を持つ関数を mw.loader.load 対応の関数として jawp のような新しい名前空間に作成することは許容されるのではないかと思います。この方法であれば、最小限の変更で以前と同様の機能を利用することができるようになります。--Frozen-mikan 2011年3月16日 (水) 15:22 (UTC) 紛らわしい部分を修正。--Frozen-mikan 2011年3月16日 (水) 16:18 (UTC)[返信]
コメント いろいろ考え、当初は「mw.loaderにloadScript/loadStyleSheetを新しく追加する」で良いのではないかと考えていましたが、今は「jawpのような新しい名前空間(クラス)を作って、そこに追加した方が設計的にはよい」という案に賛成します。jawpのメソッド名としては、たぶんFrozen-mikanさんと異なる意見ですが、「jawp.loadScript」「jawp.loadStyleSheet」といったような名前がよいのではないかと思います。理由としては、従来の「importScript」「importScriptURI」「importStylesheet」「importStylesheetURI」と同じ実装のものは提供するべきではなく、実装としてはmw.loader.loadのラッパーにするべきであり、その場合、まったく同じ機能となることを保証するのは難しそうに思うからです(実装例)。--mizusumashi(みずすまし) 2011年3月18日 (金) 12:02 (UTC)[返信]

「Complete list」

以下の、miyaさんによる発言(提案)はTemplate‐ノート:メインページ言語間リンクからコピーしたものです。--氷鷺 2011年11月26日 (土) 10:57 (UTC)[返信]

ところで英語版にはもう一つ、「Complete list」というリンクがあって en:List of Wikipediasに飛べます。読者にとってかなり便利だと思います。追加しませんか?--miya 2011年11月25日 (金) 15:25 (UTC)[返信]

賛成 賛成ですが、実際には Common.js を編集することになりますので、こちらのノートに場所を移しましょう。で、具体的な編集内容は以下のようなものを追加することになります。
if (wgPageName == 'メインページ') {
    $(function () {
        mw.util.addPortletLink('p-lang', '//ja.wikipedia.org/wiki/Wikipedia:%E5%85%A8%E8%A8%80%E8%AA%9E%E7%89%88%E3%81%AE%E7%B5%B1%E8%A8%88',
            '全ての言語', 'interwiki-completelist', '全ての言語');
    });
}
リンク先はとりあえずWikipedia:全言語版の統計にしていますが、重いですし、言語系統的な一覧でも新たに作った方が良いかもしれません。--氷鷺 2011年11月26日 (土) 10:57 (UTC)[返信]
賛成 先日もタイ言語版へのリンクが無いとの指摘が有ったばかりです。リストが部分的なものであることを示すためにも、このような補足があって良いと思います。また、ソースについて、以下の案を提示します。
if (mw.config.get('wgPageName') == 'メインページ') {
    $(function () {
        var listPageName = 'Wikipedia:全言語版の統計';
        mw.util.addPortletLink('p-lang', mw.util.wikiGetlink(listPageName),
            '全ての言語', 'interwiki-completelist', listPageName);
    });
}
変更内容は以下の通り。MediaWiki1.17以降で推奨されている書き方にしました[1]。また、ツールチップはリンク先ページのタイトルにしました。--Frozen-mikan 2011年11月26日 (土) 13:02 (UTC)[返信]
提案 言語系統ごとの一覧「Wikipedia:ウィキペディアの一覧」を作成しました。リンク先はこちらでどうでしょうか。--氷鷺 2011年12月4日 (日) 09:13 (UTC)[返信]
素晴らしいページです。リンク先を変更することに賛成します。--Frozen-mikan会話2012年4月3日 (火) 14:46 (UTC)[返信]
実際に試してみたのですが、クラシック(standard)、ノスタルジア、ケルンブルーの3つのスキンでは、言語間リンクとは別の所に「全ての言語」が挿入されてしまいます。場所が違うと不自然ですし、かといってそれらのスキンでは利用できそうなクラスやIDもなく(少なくともスマートな方法では)対応しづらいように思います。この3つのスキンを対象外とするか、それとも別に対応を考えましょうか。さほど利用があるとは思えないですし、ベクターやモノブックで動作するならその辺だけでも良いような気がしますが。--氷鷺 2011年12月5日 (月) 15:40 (UTC)[返信]
提案 3つのスキンに対応したスクリプトを作ってみました。2ヶ所に追加する都合上、id は省略しました。
/* 言語間リンクの最後に、リンク「全ての言語」を追加する。 */
if (mw.config.get('wgPageName') == 'メインページ') jQuery(function ($) {
    var listPageName = 'Wikipedia:ウィキペディアの一覧';
    var href = mw.util.wikiGetlink(listPageName);
    var text = '全ての言語';
    switch (mw.config.get('skin')) {
    case 'standard':
    case 'cologneblue':
    case 'nostalgia':
        var $link = $('<a>')
            .attr({'href': href, 'title': listPageName}).text(text);
        var $top = $('#topbar').find('a.external').last();
        var $bottom = $('#footer').find('a.external').last();
        if ($top.length == 0) return;
        var separator = $top.get(0).previousSibling.data;
        $top.add($bottom).after($link.clone()).after(separator);
        break;
    default: 
        mw.util.addPortletLink('p-lang', href,
            text, 'interwiki-completelist', listPageName);
        break;
    }
});
以上。(過剰対応な気もしますが。)--Frozen-mikan会話2012年4月3日 (火) 14:46 (UTC)[返信]

廃止される予定の関数を更新する

MediaWiki1.17 で ResourceLoader(RL) が導入されたことに伴い、新しいライブラリ群が登場しました。この際、以前からあった関数群が一斉に廃止される予定になりました。移行案内は[2] にあります。ここに書かれている中で、簡単な置換えの部分から変更したいと思っています。今回は1件だけですが、少しずつでも変更して行ったほうが良いと思っています。ご意見をお待ちしています。--Frozen-mikan会話2012年4月3日 (火) 13:02 (UTC)[返信]

関数群の隠蔽について

現在、このCommon.jsではほとんどの関数と変数が、windowオブジェクトに紐付けされ公開された状態になっています。この状態を改善するため、mw.loader.using('mediawiki.util', function(){}); による明示的な遅延処理と、そのコールバック関数による隠蔽を行ないたいと思います。遅延処理の方は不要かもしれませんが、ライブラリに依存する場合の安全な書き方のお披露目行為も兼ねています。隠蔽するに際し、グローバルとして公開し続けるものについては明示する必要があります。以下の関数を公開する予定です。

  • getURLParamValue (mw.util.getParamValue に置き換え可能)
  • hasClass (jQuery の .hasClass() やクラスセレクタで置き換え可能)
  • collapseTable
  • toggleNavigationBar

また、以下の変数は利用者によって変更される可能性があるため、明示的に公開する必要があります。

  • disableTitleChecker (window. を付ける)
  • disableRealTitle (window. を付ける)

以下の変数は存在しない可能性も考慮して書かれているため問題ありません。

  • moveEditsectionDisable (typeof)
  • expandEditsectionDisable (typeof)
  • summaryEnterRejectDisable (typeof)
  • disableUsernameReplace (window.)

以上です。ご意見をお待ちしております。--Frozen-mikan会話2012年4月6日 (金) 18:02 (UTC)[返信]

MediaWiki:EnhancedCollapsibleElements.js の読み込み条件について

現在、MediaWiki:EnhancedCollapsibleElements.js (ECE) は全てのページで読み込まれています。これを条件付きで読み込む形に変更してはどうかと思っています。このスクリプトはDOM構築時に使われるかどうかを判別できるため、使われない場合は読み込みを行わない方が閲覧者にとってメリットになると思います。ただし、使われる場合に折りたたみが開始されるタイミングが少し遅くなるデメリットはあります。皆様のご意見はいかがでしょうか。--Frozen-mikan会話2012年4月6日 (金) 19:01 (UTC)[返信]

節単位編集リンクを左右に移動する機能の廃止

meta:Change to section edit linksプロジェクト‐ノート:ウィキ技術部#Common.jsの修正が必要そうです(modifyEditsection)への対応の一環として、節単位編集リンクを左右に移動する機能はなくしたほうがいいのではないでしょうか? 移動機能は、過去のMediaWikiにおいて節の名前の左側に出ていた節単位編集リンクを右側に移動するものでしたが、現在は何もしなくても節の名前の直後にリンクが置かれるので、この移動は不要になったはずです。なお、冒頭部分の編集リンクを追加する機能と節単位編集リンクに「閲覧」「ウォッチ」等を追加する機能は、これまでどおりでいいと思います。 --whym会話2013年5月11日 (土) 14:17 (UTC)[返信]

以下は廃止の背景と方法の説明です。廃止により大多数の人は特に影響を受けませんが、これまで移動が無効になる(つまり節編集リンクを左側におく)よう設定(MediaWiki:Gadget-MoveEditsectionDisable)していた人は影響を受けます。後者の人数は非常に少なかったようです。ToolServer でガジェットの利用者数を調べてみたところ、MediaWiki:Gadget-MoveEditsectionDisableを有効にしていたアカウントの数は 21 だけでした(比較対象として、Help:ナビゲーション・ポップアップは2000以上です)。利用者ごとの設定に記入している人もいないようです。左側に移動させるには新たな実装が必要になりますし、いずれにしても利用者数の実態からみて全利用者が全ページでロードする Common.js に記載すべき機能ではない気がします。要望があった場合に新しいガジェットとして作成するのがいいかもしれません。廃止する場合、Common.js から該当部分を除去するのに加えて、MediaWiki:Gadget-MoveEditsectionDisableスクリプト を削除することになります。おそらく MediaWiki:Gadget-MoveEditsectionAntiJumpスタイルシートも不要になるかと思います。 --whym会話2013年5月11日 (土) 14:17 (UTC)[返信]
新CSSクラス名(mw-editsection)等への対応と上記の廃止を行ったソースの例として利用者:Whym/editsectionenhanced.jsを作ってみました。 --whym会話2013年5月11日 (土) 14:17 (UTC)[返信]

Give search results even when page doesn't exist

Screenshot of the Earth test search, with this script adding links to Wikidata, Reasonator, Commons, and Wikipedia.

Hello, I propose to enable the tool created by Magnus Manske (creator of MediaWiki) to provide results from other languages and Commons (via Wikidata) when a page doesn't exist here: links are added to Special:Search and noarticletext. This helps to encourage translation and to make readers use your wiki more, because they can be sure to find something even if it's not local (rather than searching directly on the biggest wiki). The Italian and Polish Wikipedias, among others already enabled it by default.
Examples: [3] [4] [5]. More information: Magnus blog.
How to: just add the following line at the end of Common.js.

// Results from Wikidata
// [[File:Wdsearch_script_screenshot.png]]
if ( mw.config.get( 'wgCanonicalSpecialPageName' ) === 'Search' ||  ( mw.config.get( 'wgArticleId' ) === 0 && mw.config.get( 'wgCanonicalSpecialPageName' ) === false ) ) {
	importScriptURI("//en.wikipedia.org/w/index.php?title=MediaWiki:Wdsearch.js&action=raw&ctype=text/javascript");
}
--Nemo 2013年12月12日 (木) 08:56 (UTC) (comments, translations and last instructions)[返信]

他言語版の秀逸/良質記事へのリンク装飾

他言語版の秀逸な記事へのリンクに星を付ける処理ですが、言語間リンク部分のクラス名が変更された影響で動かなくなっています。ドイツ語版を参考に修正したコードが 利用者:Fryed-peach/FA.js にありますので、これを反映させることを提案します。--fryed-peach [会話] 2013年12月20日 (金) 05:39 (UTC)[返信]

報告 ご提案の内、最低限必要な部分は修正しました[6]。--Frozen-mikan会話2013年12月20日 (金) 09:07 (UTC)[返信]

未定義値の可能性があるグローバル変数に対する簡易処置の提案

しばらく前から「Wikipedia:バグの報告#古いブラウザでの動作確認報告」で報告がありますように、ブラウザによって jQuery や mw を未定義値 (undefined) のままにする分岐処理が行われています。しかし、既存のスクリプトは、これらの値が必ず存在するものとして書かれており、未定義値のままになっているブラウザではエラーが発生しています。よって、その簡易的な対策として、大雑把では有りますが、以下のスクリプトを差し込みたいと思います。同時に関数 toggleNavigationBar が暗黙のグローバル関数として使われていますので、その部分を修正したいと思います。その他、グローバル変数として見えていたものが隠れますので、他のスクリプト(ガジェットを含む)で何らかの問題が発生する可能性は否定できません。

typeof mw != 'undefined' && (function() {
/* mw に依存する部分の始まり */

/* 既存のスクリプト (この行は追加しません) */

/* mw に依存する部分の終わり */
}());
(解説)前半の typeof mw != 'undefined' の部分は window.mw !== undefined とほぼ同じ動作になります。この部分が mw が未定義値だった場合のエラーを回避する本体です。後半の無名関数 (function() {}()); は、内部に既存のスクリプトを配置します。関数にまとめることで、mw が未定義値だった場合、既存のスクリプトを実行させません。
// 修正前
  function toggleNavigationBar(indexNavigationBar)
// 修正後
  window.toggleNavigationBar = function(indexNavigationBar)

問題がないようでしたら、1週間後、日本時間の19日夜以降に反映する予定です。ご意見やお気づきの点などがありましたらお知らせください。--Frozen-mikan会話2014年8月12日 (火) 03:03 (UTC)[返信]

コメント 無名関数の中に封じ込めるスクリプトの範囲をどのようにお考えなのか確認しておきたいところです。たとえば記事名チェッカは処理内でwgで始まるグルーバル変数を使用していますが、disableTitleCheckerTitleChecker_excludeというグローバル変数を定義しているのでこれは範囲外に出す必要があるでしょう。ところで英語版を見たのですが、特に対策はしてないようですね。--Wolf359borg会話2014年8月12日 (火) 11:56 (UTC)[返信]
「無名関数の中に封じ込めるスクリプトの範囲」については、既存の全てを入れる予定です。「mw に依存」とは言うものの、同様に $ (jQuery) 変数に依存する部分も回避しなければならないので、全体を囲っておきたいのです。「varで宣言すればグローバル変数ではない」と保証されるようになるメリットも有ります。また、ご指摘にある2つのグローバル変数(計7箇所)については、var を除去し、window. を前置することでグローバル変数を維持しようと思いますが、いかがでしょうか。--Frozen-mikan会話2014年8月12日 (火) 12:25 (UTC)[返信]
基本的に全体を囲って、必要なグルーバル変数については維持するように配慮ということですね。了解です。--Wolf359borg会話2014年8月12日 (火) 12:38 (UTC)[返信]

報告 提案の通り、先ほど Common.js を編集しました(差分)。議論の中では「グローバル変数」を選んで残す予定でしたが、全てのグローバル変数(関数)を残すようにしました。提案に無い部分としては、関数宣言を関数式に変更した箇所は、式の最後にセミコロンを追加しています。出来る限りエラーが起きないように編集しましたが、何か有りましたらお知らせ頂けるようお願い申し上げます。--Frozen-mikan会話2014年8月19日 (火) 13:33 (UTC)[返信]

報告 Vector.js についても同様の編集を行いました(差分)。--Frozen-mikan会話2014年8月19日 (火) 14:04 (UTC)[返信]
Frozen-mikanさん:mw:Manual:Coding_conventions/JavaScript#Closureにはクロージャ引数((function(mw, $){/*本体*/}(mediaWiki, jQuery)))を利用するやりかたが書かれています。未定義の場合に何も実行しないようにするという効果は同様だと思いますので、こちらのやりかたのほうが一貫性の点で好ましいかもしれません(同様の方法で書かれたスクリプトはc:MediaWiki:Gadget-AjaxQuickDelete.jsなど、他ウィキでしばしば見かけます)。それほど大きな違いはなさそうですので、強く提案はしませんが。 --whym会話2014年8月23日 (土) 12:33 (UTC)[返信]
ご指摘の点、誤読があるかもしれませんが、以下の様に考えています。ご指摘のコード自体には「未定義の場合に何も実行しない」や「未定義エラーを回避して後続のスクリプトの実行を妨げない」という効果は無いように見えます。恐らく、mediaWiki や jQuery に比べて短い名称の mw や $ が、事前に実行されたスクリプトによって上書きされている可能性を考えているように思います。もちろん、無名関数で囲みスコープを作る事は必須にして良いと思いますし、ご指摘の方法は、防御的プログラミングとして有用であると思います。--Frozen-mikan会話2014年8月23日 (土) 13:29 (UTC)[返信]
補足します。引数として値を渡すタイミングに "mediaWiki" が未定義であればそこでエラーとなり関数の中身は実行されない、というように上記のコードを読んでいました(この点ですでに誤解がありましたらこの提案はなかったこととしてご容赦ください)。このセクションで提起された問題に関して、実質的に害があるのは未定義エラーが出る箇所までコードが中途半端に実行されることだと思っていたので、何も実行しないのであれば未定義エラーはでてもよい(むしろ十分に対応していない環境を使っている証拠なので、でたほうが注意喚起になる)のでは、というのが私の考えでした。--whym会話2014年8月23日 (土) 13:48 (UTC)[返信]
事の発端、Wikipedia:バグの報告#古いブラウザでの動作確認報告の報告者です。JavaScriptのエラーが注意喚起になるのはそれなりの知識がある人だけで、一般の利用者にはなぜか読み込みスタータスがreadyにならないおかしな状態に過ぎず対処不能です。でも英語版では特に対処されてなくて普通にエラー出てしまうんですよね。対応していない環境への注意喚起に関しては、もうIE6以前などisCompatible()で未対応判定される環境は非推奨であるとはっきりHelp:MediaWikiに適応するブラウザに書いておくべきだと思うのです。関連してこういう提案もさせて頂いています。--Wolf359borg会話2014年8月23日 (土) 14:32 (UTC)[返信]
なるほど。未定義であれば、エラーが発生し無名関数内部は実行されない、ということですか。個人的には可能な限りエラーを出すべきではないと思っており、現状では同意しがたい部分です。--Frozen-mikan会話2014年8月23日 (土) 16:02 (UTC)[返信]

報告 別の話をしていた所、気になり、IE11によるIE5相当で実行しなおしてみたら、どうやらスクリプトを読み込まない形に切り替え(一箇所だけ mw の未定義エラーが起きていますが)、Common.js なども読み込まれていないようです。ログインしていても、ガジェットの方は、[ResourceLoader|dependencies=mediawiki.util] など英語版[7]のように依存関係が書いてあれば、読み込まれずに問題が起きないようです。他の方にもご確認いただけるとありがたいです。--Frozen-mikan会話2014年8月23日 (土) 16:02 (UTC)[返信]

あらら、今確認(IE11およびIETesterでIE5/IE6エミュレーション)してみたらエラーが出ないように対策されてますね。なお、IE11でmwの未定義エラーが起きたというのは、たぶんドキュメントモード5だけ設定してユーザーエージェント文字列が規定のままだったんじゃないでしょうか。--Wolf359borg会話2014年8月23日 (土) 23:07 (UTC)[返信]
ご確認いただき、ありがとうございます。一度出る mw の未定義エラーに関しては、仰るとおりユーザーエージェント文字列の設定が規定のままでした。ガジェットの方は「MediaWiki‐ノート:Gadgets-definition」で作業管理し、対処したいと思います。--Frozen-mikan会話2014年8月24日 (日) 03:48 (UTC)[返信]
報告 ガジェットについて「MediaWiki‐ノート:Gadgets-definition#ResourceLoader への依存を明示する提案」を提出しました。こちらの方もよろしくお願いします。--Frozen-mikan会話2014年8月24日 (日) 07:49 (UTC)[返信]

Announced JavaScript change for badges implementation

Hi! I want to let you know that in near future badges will be deployed on Wikidata and the Wikipedias. They help us with displaying the good and featured article icons next to the sitelinks and will replace the javascript hack which is used at the moment together with the Link GA and Link FA templates. To avoid an overlap where the current system and the new feature conflict, I will add a minor fix to your Common.js which adds the class names to the interwiki links. This is part of my task as a global edit interface editor for the Wikidata team. Thanks, Bene*会話2014年8月18日 (月) 20:27 (UTC)[返信]

wgから始まるグローバル変数について

しばらく前から確認している現象ですが、廃止が予定されている「wgから始まるグローバル変数」を参照すると、コンソールに警告 (console.warn) が出るようになっています。正式に廃止される時期は不明ですが、早い内に対処しておいた方が良いと思います。対処法については、変数表記そのものを置き換えるのではなく、使用されているグローバル変数と同名のローカル変数に mw.config.get を用いて事前に値を用意する形を考えています(wgScript であれば、var wgScript = mw.config.get("wgScript"); の1行を事前に挿入)。ご意見をお待ちしております。--Frozen-mikan会話2015年3月14日 (土) 15:47 (UTC)[返信]

  • 賛成 たまたまコンソールを見ていたらwarningだらけになっていたので気づきましたが、これらの変数をmw.config経由で呼び出してローカルで持つ、という対応で問題ないと考えます(動的に変わるものでもないですし)。--Jkr2255 2015年4月6日 (月) 12:17 (UTC)[返信]

コメント しばらく間が空きましたが問題点のご指摘が無かったので、数日中に上記の通りに変更を行う予定です。なお、この期間中に importScript なども同様の状態になりました。そちらの方は別途変更提案をしようと思っています。--Frozen-mikan会話2015年4月27日 (月) 07:15 (UTC)[返信]

報告 編集しました[8]。直ぐには反映されないようですが、ガジェット等を含まない状態で importScript の警告が何件か出るだけになるはずです。なお、この編集による不具合あれば、「Wikipedia:管理者伝言板/保護ページ編集」に差し戻しの依頼を行って下さい。よろしくお願いします。--Frozen-mikan会話2015年4月29日 (水) 04:17 (UTC)[返信]
報告 類似のグローバル変数である skin をローカル化しました(差分)。--Frozen-mikan会話2016年4月14日 (木) 16:00 (UTC)[返信]

秀逸な記事への言語間リンクに付く星アイコン

現在ではこの処理はウィキデータのバッジを利用するようになっているので、この関数は除去して問題ありません。--fryed-peach会話2016年9月30日 (金) 13:31 (UTC)[返信]

昔 {{Link FA}} とかのテンプレートと一緒に使われてたやつですよね。廃止になっていたのを知りませんでした。情報ありがとうございます、処理を除去しました。--cpro会話2016年11月8日 (火) 01:12 (UTC)[返信]

WithJS withCSSの対象に利用者名前空間を含める提案

提案 現状、MediaWiki名前空間のみが対象になっているWithJS withCSSを、利用者名前空間も対象とするように変更することを提案します。理由は、スクリプト/CSSの提案をしやすくするためです。カスタムJSの体験も可能になります。

1週間ほど意見を募集し、反対がなければ、変更作業を行いたいと思います。よろしくお願いします。--Waiesu会話2016年11月7日 (月) 05:05 (UTC)[返信]

反対 提案やカスタムJS体験の容易化という主旨には共感するんですが、悪意あるスクリプトを容易に実行させられるため、残念ながら無理だと思います。--cpro会話2016年11月7日 (月) 05:28 (UTC)[返信]
返信 (Cproさん宛) ご意見ありがとうございます。利用者名前空間の場合は、confirmでその旨を警告し、自己責任でOKを押した場合のみスクリプトを読み込ませるというのはどうでしょうか。--Waiesu会話2016年11月7日 (月) 05:51 (UTC)[返信]
コメント 自己責任としてしまうと、利用前にロード対象のカスタムJSの内容を見て悪意あるコードが含まれていないことを各自確認するところまで利用者に責任を負わせることにならないでしょうか。やはり積極的な賛成はできないです。
可能性があるとすれば、たとえば各自の利用者サブページに[[利用者:Cpro/withjsoptin.js]]のようなオプトインページ(.jsは改竄防止のため)を作らせて、そこに名前がある利用者のカスタムJSのみ許可するような仕組みでしょうか。名前がない場合confirmダイアログでOKするとオプトインページの編集画面に飛ぶようにすれば多少は利用者負担も減るかなと。結構大がかりな改造になってしまいますが。--cpro会話2016年11月7日 (月) 07:41 (UTC)[返信]
反対 それは誰も幸せにならないと思うのです。自己責任にするなら console から読み込み文を打たせるか、個人用 js / CSS に入れればいいと思うのです。わからない人が下手に触ると碌なことにならない類のものですし。--rxy会話2016年11月7日 (月) 09:44 (UTC)[返信]

──────────────────────────────────────────────────────────────────────────────────────────────────── 返信 (cproさん、rxyさん宛) ご意見ありがとうございます。やはりカスタムJSを対象とするには、安全性の面にかなりの配慮をしなくてはならず、難しいようですね。JSについては取り下げます。

さて、CSSについてはどうでしょうか。現在、Template‐ノート:Reflist#列数指定時の列幅に下限を設定する提案においてMediaWiki:Common.cssの変更を含めた提案をしていまして、なにせ影響が大きいですから、より多くの方に体験をしてもらうために、こちらのスクリプトの変更の提案したわけであります。cssについてもご意見お願いします。(上記提案にもご意見をくだされば光栄です。)--Waiesu会話2016年11月7日 (月) 14:34 (UTC)[返信]

そういう用途であれば MediaWiki 名前空間にテスト用 CSS / js を置けばいいだけなのでは。不必要にリスクをとってまで現行 js を変更する必要性が全く分かりません。--rxy会話2016年11月7日 (月) 22:09 (UTC)[返信]
返信 (rxyさん宛) 今回の件に関して言えば、それで済む話かもしれませんが、この先、MediaWiki名前空間を編集できない方が提案する際の補助になります。cssにはセキュリティ上のリスクもありません。--Waiesu会話2016年11月8日 (火) 09:27 (UTC)[返信]
コメント 例えば、MediaWiki名前空間にテスト用JS/CSSを置いて、必要があればそこから管理者/インターフェース編集者が操作を行って、期間限定で一時的に利用者名前空間のJS/CSSをインポートしたほうが良いと思います。利用者名前空間のJS/CSSは基本的に本人しかいじれないので、利用者名前空間のJS/CSSをロードするとしてもリスクは大きく下がるはずです。
とは言え、この対処法を推しているわけではありません。不正目的の申請を誤って許可すれば不特定多数が危険なコードを実行する結果にはなりますので、やはり一定のリスクは伴います。権限申請の類と比較すると、不正申請を誤って許可するリスクは高いと思います。実施を必ずしも推すわけではないが、もし実施するならこれぐらいの手の込んだシステムは必須である、という主旨で捉えていただければ幸いです。--Marine-Bluetalkcontribsmail 2016年11月10日 (木) 08:22 (UTC)[返信]
返信 (Marine-Blueさん宛) コメントありがとうございます。JSについて、セキュリティ上の観点から特別な配慮が必要なことは理解しています。CSSに限定すると、特にそういった配慮・対処をせずとも問題は発生しないと考えますが、どうでしょうか。--Waiesu会話2016年11月10日 (木) 14:20 (UTC)[返信]

取り下げ 提案について賛同が得られなかったため、取り下げます。代わりにMediaWiki:Common.cssの提案用にMediaWiki:Test/common.cssを作成したことを報告します。 --以上の署名のないコメントは、Waiesu会話投稿記録)さんが 2016年11月18日 (金) 14:46 (UTC) に投稿したものです(whym会話)による付記)。[返信]

WikiEditorで挿入されるbig/smallタグの置き換え提案

Wikipedia:井戸端/subj/入力補助における、文字の大きさに関する仕様についてより。WikiEditorの入力補助機能を用いると、HTML5で廃止された<big>...</big>とタグの意味に変更があり文字サイズ変更だけの用途としては非推奨となった<small>...</small>が挿入されるため、mw:Extension:WikiEditor/Toolbar customizationの方法で{{larger|...}}{{smaller|...}}が挿入されるようにしていただけないでしょうか。--126.144.37.127 2017年3月1日 (水) 17:43 (UTC)[返信]

extParamの未定義エラー

Wikipedia:秀逸な記事の選考Wikipedia:良質な記事/良質な記事の選考で、以下のJavascriptのエラーが発生しています。

Uncaught ReferenceError: extParam is not defined

ブラウザのデバッガの内容から推察すると、Common.jsのl.783,790のextParamではないかと推察され、前後のコードから、他の記事を表示している記事のうち、特定の条件を満たす記事でこの問題が発生するのではないかと推察されます。 現在のところ、このエラーでUIの動作不良などは確認できておりませんが、ご修正をお願い致します。 --MawaruNeko会話2017年11月6日 (月) 14:56 (UTC)[返信]

コード見直しの過程で改名前の変数名および不要になった処理が残ったままでこれがエラーの原因でした。失礼しました。修正しましたのでご確認ください。--cpro会話2017年11月7日 (火) 00:20 (UTC)[返信]
ご対応ありがとうございました。エラーが修正されていることを確認いたしました。--MawaruNeko会話2017年11月7日 (火) 13:40 (UTC)[返信]

ユーザースクリプトによる無効化オプションが使えない

ユーザースクリプトでwindow.disableSomeFeature = true;などとしておくとCommon.jsの機能を無効化するオプションを提供しているものがいくつかありますが、ResourceLoaderが導入されてからはロードのタイミングが変わって、Common.js上の$(Func)が実行される時点(DOM構築完了時実行)ではまだユーザースクリプトがロードされておらず(少なくともロードされることが保証されていない)、無意味になっています。

この手の無効化オプションはガジェットがない時代にユーザー側で有効化/無効化を選択できるようにしていた慣習によるもので、ユーザーによる選択が妥当なものであればガジェットで実装するのが本来あるべき状態ですし、選択させる必要がなければオプションは廃止してよさそうに思います。以下、現状をまとめてみます。

機能 内容 対処
TitleChecker 改名時や新規作成時に記事名がWP:NCに沿っているかチェックする機能。特に無効化する意味もなく、無効化オプションは不要か。 チェック サブモジュール化の際にオプション廃止
modifyEditsection 井戸端などでトランスクルードされたサブページへの節編集リンクを拡張する。必ずしも全員に必要なものではなく、ガジェット化が妥当か。 チェック ガジェット化
summaryEnterReject 要約欄でエンターキーを押した際に投稿されないようにする。ガジェットGadget-SummaryEnterSave.jsで無効化できるようにしているので現状でOK?既定で有効なガジェットに変更する方が自然かも(参考: Wikipedia:井戸端/subj/要約記入欄でエンターキーを押したときの動作 チェック ガジェット化
UsernameReplace 投票ページなどで、<span class="insertusername"></span> の中身を利用者名で置き換える。ガジェットから移行した経緯もあり(参考)、特に無効化する意味もなく、無効化オプションは不要か。

ご意見をお寄せください。--cpro会話2017年11月8日 (水) 07:16 (UTC)[返信]

自分で言うのもなんですが何の意見を求めてるのかよくわからないので、個別具体にということで、まずはmodifyEditsectionおよびsummaryEnterRejectについてWikipedia:ガジェット/提案にガジェットへの移行を提案しました。--cpro会話2017年11月10日 (金) 01:46 (UTC)[返信]
報告 TitleCheckerについては、MediaWiki‐ノート:Common.js/記事名チェッカ#改修およびサブページ分離の予告MediaWiki:Common.js/titleChecker.jsにサブモジュール化したのを機に、無効化オプションを廃止しました。--cpro会話2017年11月15日 (水) 06:18 (UTC)[返信]
報告 modifyEditsectionとsummaryEnterRejectのガジェット化を完了しました。--cpro会話2017年11月17日 (金) 08:02 (UTC)[返信]

強制プレビューの更新

掲題について、不具合が発生したため MediaWiki‐ノート:Vector.js#強制プレビューの更新 にて改廃の提案をしております。--rxy会話2017年12月8日 (金) 15:37 (UTC)[返信]

withJS・withCSS機能の更新(2020年4月)

表題の機能ですが、mw:Snippets/Load JS and CSS by URLにある最新版への更新を提案します。変更点は「importStylesheetとimportScriptからmw.loader.loadへの移行」の1点であり、理由は下記の通り。

特に問題がなければ、1週間後に更新します。--ネイ会話2020年4月17日 (金) 04:00 (UTC)[返信]

Dynamic Navigation Barsの更新

Dynamic Navigation BarsはMediaWikiが既定で折り畳み機能を提供していない時代の産物であり、ウィキペディア日本語版では2007年に導入されました。しかし、2011年末のMediaWiki 1.18にてmw-collapsibleクラスが導入されたため、Dynamic Navigation Barsを廃止すべきであると考えます。ただし、mw-collapsibleで表示される折り畳みボタンの表示が未調整のため、現時点ではまだ移行できていません。つきまして、まずはDynamic Navigation Bars側を(英語版から再移入して)更新し、コードを整理してから移行を考えたいと思います。現時点でCommon.jsに出ているWarning 3件が全てDynamic Navigation Bars由来となっているため、リファクタリングの面からも更新すべきと考えます。目立った変更点としてはa.hrefによるリンクからonclickイベントへの移行が挙げられます。特に問題がなければ、1週間後に更新します。--ネイ会話2020年4月25日 (土) 06:12 (UTC)[返信]

リファクタリングの提案

下記のリファクタリングを提案します。

  • チェック importScriptからmw.loader.loadに移行:Common.jsにおいて3か所で使用されているimportScriptをmw.loader.loadに移行します。#withJS・withCSS機能の更新(2020年4月)と同じく、mw:ResourceLoader/Migration guide (users)#MediaWiki 1.29の手順によるものです。
  • wgから始まるグローバル変数の除去:2015年に#wgから始まるグローバル変数についてにより追加された変数ですが、Common.jsはできるだけ軽くすべきという視点から、ウィキペディア日本語版における全てのスクリプト(利用者スクリプトを含む)を修正した上でそれらの引数を除去したいと思います。これらの変数を使用している箇所を全てmw.config.getで取得するよう変更する形となります。
  • チェック sourceタグの除去:phab:T237267によると、sourceタグは2009年5月より非推奨とされています。Common.jsでは2007年6月に英語版からの移入という形で追加されたようです(英語版では2007年5月に追加、6月末に除去)。現時点では必要性がなくなったと思われますので、置換ではなくそのまま除去してよいと考えます。

--ネイ会話2020年5月4日 (月) 12:38 (UTC)[返信]

  • 1と3は編集しました。
  • 2については、スクリプトを10件ほど編集したところで上記の説明の間違いに気づきましたので、一旦作業を止めています。具体的には、Common.jsにおけるwgから始まるローカル引数は利用者スクリプトで参照できるわけではなく、利用者スクリプトのほうで利用しているのはmw:ResourceLoader/Migration guide (users)#Global wg variablesにて非推奨とされたグローバル引数のほうです。これらのグローバル引数は2011年6月のMediaWiki 1.17より非推奨となっていましたが、phab:T72470により2019年10月から順次除去される予定となっており、ウィキペディア日本語版を含むgroup2のウィキは現時点で今年6月の除去を予定しているようです。つきまして、改めて「ウィキペディア日本語版における全てのスクリプト(利用者スクリプトを含む)において、wgから始まるグローバル変数をmw.config.get経由に変更する」ことを提案いたします。これは、先立って行われた10件ほどの利用者スクリプトの編集の追認も含みます。なお、提案の性質上ボット作業依頼は難しいと考えられるため、手動での作業を予定しています。--ネイ会話2020年5月13日 (水) 08:47 (UTC)[返信]
    • コメント Sourceタグはプレビュー時にコードハイライトが出来なかった時代の名残ですね。能動的にハイライトを行わないとプレビュー時に通常のウィキ構文として扱われていました。なので、既に除去されていますが、問題ないです。
    • 非推奨変数はどうも他社のユーザーJSの編集をためらっていたようですね。当時の事情はよく覚えていませんが、インターフェース管理者の権限でユーザーJSのコード置換を行うのは問題ないと思います。というか、そのような運用を意図して他のユーザーJS/CSSの編集権限が与えられているはずです。--Marine-Bluetalkcontribsmail 2020年5月14日 (木) 09:57 (UTC)[返信]
  • 合意が成立したものとみなします。ぼちぼち作業を行います。--ネイ会話2020年5月23日 (土) 12:11 (UTC)[返信]

SpecialSearchEnhancedをガジェットあるいはカスタムJSに変更する提案

Common.jsの初版(2007年2月20日 (火) 04:29 (UTC)の版)より存在するSpecialSearchEnhancedの機能ですが、下記の理由により、ガジェットあるいはカスタムJSに変更することを提案します。

  1. SpecialSearchEnhancedのスクリプト内でエラーが生じており、検索ページを表示するごとに"TypeError: nsCheckBoxs[i] is undefine"のエラーがコンソールに表示される。また、少なくともFirefoxではドロップダウンメニューが表示されると検索ボタンの位置がズレる(他ブラウザでは未確認)。(これらのバグを直すことは可能だと思います)
  2. 2007年当時ならともかく、現在の特別:検索の機能は大幅な改良がなされ、特定のカテゴリやテンプレートを含むページなど外部サイトより高機能となっている。
  3. 検索ページの機能拡張は、Common.jsを通じて全ての利用者に強制すべきものではない。すなわち、少なくとも「使用しない」という選択肢を提供する必要がある。

上記3点目により、ガジェットあるいはカスタムJSに変更すべきと考えます。そして、2点目の理由により、現時点では需要が少ないと考えられ、ガジェットを導入する手間をかけずカスタムJSに変更したほうがよろしいかと思います。--ネイ会話2020年5月14日 (木) 07:41 (UTC)[返信]

これは検索機能を拡張するもののようですが、どういう使用手順で使えばいいのでしょうか。私がLinux+Firefox、Linux+Chromiumの環境で試したかぎりでは、検索窓に何かを入力して遷移するページ()には、それらしいものが表示されませんでした。ここから再度「検索」ボタンを押すと、Altavisaなどを含むプルダウンメニューが表示されました。外装には無関係にこうなるようです。ちょっと分かりにくくなっているのはたしかだと思うので、Help:検索#外部の検索エンジンを使用してウィキペディアを検索するの内容は更新が必要ですね(ここには「詳細」を押す、と書かれていますが、今の画面にはそれがありません)。新規の利用者は想定せず、かつて使っていた人(使い方が分かっている人)のためだけに残すものと割り切って、あまり説明しないという手もあるかもしれませんが。使っている人が少なそうだというのは同感です。 --whym会話2020年5月16日 (土) 01:49 (UTC)[返信]
当時は特別:検索に遷移すると検索窓の横に自動でプルダウンが出ていたような記憶があります。この頃は検索機能が日本語に正式対応しておらず、MediaWiki検索があまりにも当てにならなかったことも一因だと思います。現在はクローラー避けの機能などやソースコード検索などがあるため外部検索よりも内部検索のほうが目的の情報を得やすくなりました。また、ボタンを二度クリックしないと検索できないことについて、SNSなどで不満の声を聞くこともないため、おそらく殆ど使われていないはずです。カスタムJSとして残す程度で良いのではないでしょうか。--Marine-Bluetalkcontribsmail 2020年5月16日 (土) 04:56 (UTC)[返信]

NormalizeCharWidthを既定で有効なガジェットに変更する提案

MediaWiki‐ノート:Common.js/過去ログ1#検索時の全角・半角を正規化するスクリプト(2007年12月 – 2008年1月)およびWikipedia:井戸端/subj/検索時の全角・半角文字をスクリプトで正規化(2009年10月)を経て導入されたMediaWiki:Common.js/NormalizeCharWidth.jsについてですが、Common.jsに含まれているためオフにする機能がありません。しかし、今ではMediaWiki側で正規化がある程度行われるようになったため(たとえば、特別:検索/アメリカ合衆アメリカ合衆国がヒットする)、すべての利用者に適用を強制しなければならないほどの機能ではなくなり、ガジェットへの変更を提案します。新規利用者に影響を与えないよう、既定で有効にします。(余談:NormalizeCharWidthは現時点ではモバイルビュー非対応のようです。)--ネイ会話2021年4月7日 (水) 06:38 (UTC)[返信]

ガジェット化自体には賛成です。半角カナの使用率も下がった現在であればいっそのこと無効化しても著しい影響はないのでは…とも思いますが、俄かには検証できないので積極的にデフォルト無効化を主張するつもりはないです。--Marine-Bluetalkcontribsmail 2021年4月12日 (月) 13:36 (UTC)[返信]
チェック ガジェットに移行しました。今回の提案では既定で有効にしましたが、私はデフォルト無効化には賛成です。--ネイ会話2021年4月18日 (日) 07:23 (UTC)[返信]

古いブラウザへの対応措置の除去提案

Wikipedia:バグの報告/MediaWiki1.24#古いブラウザでの動作確認報告(2014年)を受けた、#未定義値の可能性があるグローバル変数に対する簡易処置の提案の議論を経て追加された処置(冒頭のtypeof mw != 'undefined')についてですが、動作確認報告にてJavaScriptエラーが指摘されたブラウザ(IE5.5からIE8まで)はMediaWikiの対応ブラウザから外されており、現在ではTLS 1.2強制によりウィキペディア日本語版にアクセスできません。したがって、不要になった処置として除去を提案します。

また、「wgから始まるグローバル変数をローカル変数とする」で定義されたローカル変数は使用されていないので、これも併せて除去する予定です。--ネイ会話2021年7月14日 (水) 16:32 (UTC)[返信]

いつもお疲れ様です。上記提案について賛成します。--Semi-Brace (会話 / 投稿) 2021年7月19日 (月) 06:05 (UTC)[返信]
チェック 編集しました。--ネイ会話2021年7月22日 (木) 12:42 (UTC)[返信]

UsernameReplaceの再ガジェット化提案

UsernameReplaceの導入経緯:

  1. Wikipedia‐ノート:管理者への立候補/投票システムの改編・バージョンアップ(2008年5月 – 6月)でガジェット(MediaWiki:Gadget-UsernameReplace.js)導入。
  2. Wikipedia‐ノート:管理者への立候補/投票システムの改編・バージョンアップ#暫定措置運用期間の終了提案(2011年7月)でCommon.jsに導入。
  3. MediaWiki‐ノート:Gadgets-definition#UsernameReplaceを廃止しました(2016年4月)でガジェット廃止。
  4. MediaWiki‐ノート:Common.js#ユーザースクリプトによる無効化オプションが使えない(2017年11月)の議論では無効化オプションの廃止も提案されましたが、実施されずそのまま失効しました。

提案:

  • UsernameReplaceの無効化は利用者スクリプトにwindow.disableUsernameReplace = true;と記述する必要があり、一般利用者にはとっつきにくいので、やはりガジェットに戻したほうがいいのではないかと思います(ガジェットの場合は個人設定で無効化できます)。
    • 導入時の提案では無効化できるようにする理由として「よく投票するユーザーのみ機能を有効にしてスクリプトを読み込むようにすることで、機能が不要なユーザーまで無駄に読み込まなければならない事態を回避します」が挙げられているので、今回の提案では無効化機能の廃止を提案せず、あくまでも無効化機能を使いやすくすることに重点を置きます。
  • ガジェット化が合意された場合、Common.jsからMediaWiki:Gadget-UsernameReplace.jsにコピーして、ガジェットを既定で有効にします。
  • IP利用者は有効にする意味がないので、ガジェット設定でminoredit権限を有する利用者(=登録利用者)に限定します。ガジェット内容とは特に関係のない権限ですが、ガジェット設定では「登録利用者に限定」のオプションがないため、その代用として使用しています。--ネイ会話2021年7月27日 (火) 13:37 (UTC)[返信]

EnhancedCollapsibleElementsの廃止、collapsibleの統合

現在、ウィキペディア日本語版では折りたたみ要素が4種類もあります(EnhancedCollapsibleElements、mw-collapsible、collapsible、NavFrame)。mw-collapsibleはMediaWiki本体から提供されており、collapsibleとNavFrameは他言語版からの輸入、EnhancedCollapsibleElementsは日本語版独自となっています。今のウィキペディア日本語版には機能の重複が多い要素を4種類もサポートする余力がないので、将来的にはMediaWikiのデベロッパーからのサポートを受けられるmw-collapsibleに一本化したいと思いますが、今回はまずEnhancedCollapsibleElementsを廃止してmw-collapsibleに移行することと、collapsibleをmw-collapsibleに統合することを提案します。

  • collapsible:機能がmw-collapsibleとほとんど同じであり、統合にはそれほど手間がかかりません。具体的には、英語版などで使用されているスクリプトを移入して、collapsibleとcollapsedクラスをmw-collapsedとmw-collapsibleに自動変換します。なお、{{Navbox}}における使用はmw-collapsibleに移行済みです。
  • EnhancedCollapsibleElements:現在、MediaWiki:License(除去提案中)、{{Delete}}、{{即時削除/エラー}}、{{編集フィルターの警告}}系で使用されています。mw-collapsibleより高機能ですが、使用数が少なく、現時点での使用が除去提案中のMediaWiki:Licenseを除きいずれもmw-collapsibleで代替できると判断します。
  • NavFrameもできれば移行したいところですが、標準名前空間における使用が5,000ページ以上であり、移行に時間がかかるので、今回はいったん見送ります。

--ネイ会話2021年9月18日 (土) 05:03 (UTC)[返信]

合意成立と判断して、collapsibleの統合を実施しました。EnhancedCollapsibleElementsについてはMediaWiki:Licenseにおける使用が除去済みで、それ以外は後ほど作業に取り掛かります。--ネイ会話2021年9月25日 (土) 16:16 (UTC)[返信]
チェック 作業が完了しました。--ネイ会話2021年9月26日 (日) 05:50 (UTC)[返信]

記事名チェッカ廃止提案のお知らせ

MediaWiki‐ノート:Common.js/記事名チェッカ#廃止提案にて、記事名チェッカの廃止を提案しています。--ネイ会話2021年9月25日 (土) 16:33 (UTC)[返信]