コンテンツにスキップ

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

MediaWiki‐ノート:Common.js/記事名チェッカ

ページのコンテンツが他言語でサポートされていません。

このページでは、記事名チェック機能についての議論をしています。

記事名チェッカー

[編集]

Titewさんによる編集[1]ですが、 

if(wgTitle.match(/ \([^\)]*\)([^ ]|$)/))
	reason.push('カッコの前にスペースがありますが、カッコの後ろにスペースがありません');

これの意図がわかりません。普通のあいまい回避系ページ（神 (神道)など）で警告が出ます。修正をお願いします。

PS.というか、せめて、ご自分のユーザスクリプト空間で1ヶ月程度の試用を行い、不具合が出ないことを確認後に移入していただけませんでしょうか？--Masao 2007年5月3日 (木) 05:45 (UTC)[返信]

そもそも、「半角括弧で囲んだ両側にはスペースを入れ、全角括弧で囲んだ両側にはスペースを入れない」という基準自体が、個人の独自解釈だろうとおもいます。実際には、半角全角の使いわけともからんでいろんな流儀があります (当ノートだけ見ても、各人ばらばらです)。ガイドラインやそのノートを見てもさまざまな意見がでていますし、どれに統一するときまったわけでもないようですし。 --Hatukanezumi 2007年5月25日 (金) 18:03 (UTC)[返信]

記事名チェッカー Safari 対応

[編集]

どうやら井戸端での報告1,2をみてますと、SafariのJavaScript実装で古いもの（1.x以前）にはバグがあって通常の記事を編集できなくしてしまっているようですので、見逃してあげる必要がありそうです。 外部サイトの情報[2]などから、UserAgentを頼りにして回避してあげるとよさそうです。

function checkTitleConvensions(title) { の直後に以下を追加でいかがでしょうか？ 

if(navigator.userAgent.indexOf("Safari/1") != -1 or navigator.userAgent.indexOf("Safari/3") != -1) return false;

ご検討お願いします。--Masao 2007年5月4日 (金) 13:47 (UTC)[返信]

確認なのですが、
  1. Safari/1.x 以前 で問題が起こり、Safari/2.0 以降では問題が起こらない、という理解で間違いありませんか？
  2. 提示いただいたコードで何故Safari/1.x以前が判断できるとする根拠は何ですか。示していただいたブログのエントリでは明らかではないように見えます。もう少し確実な情報はありませんか。
Tietew 2007年5月5日 (土) 02:08 (UTC)[返信]
1.はそのとおりだと理解しています。これまでの報告例を見る限りでは 1.x 以前では警告表示となるという報告が出ています。
2.に関してはApple.comに技術資料がありました。→ FAQ 2.Safariのユーザエージェント文字列を教えてください, Safari and WebKit Version Information
これらを見る限りでは、SafariのBuild IDが3xx(.*)?のものからが Safari 2.x に対応すると考えて構わないと思います。--Masao 2007年5月5日 (土) 12:36 (UTC)[返信]

記事名チェッカー バグ

[編集]

Wikipedia:井戸端#「記事名の付け方に反する記事の削除依頼」の編集についてより。

240行目: 

  if(nc[0] == 'forbid' || nc[0] == 'warn') {
    switch(wgNamespaceNumber) {

ここの条件文は、 

  if(nc[0] == 'deny' || nc[0] == 'forbid' || nc[0] == 'warn') {
    switch(wgNamespaceNumber) {

と 'deny' を対象にするのを忘れているだけだと思います。バグだと思うので修正をお願いします。--Masao 2007年5月4日 (金) 23:34 (UTC)[返信]

バグではありません。denyは「絶対禁止」の扱いです（そうじゃなきゃifを入れている意味がない）。ただ、全角空白がdenyでいいかどうかは判断の分かれるところか。削除依頼だけ別枠にするかなあ。Tietew 2007年5月5日 (土) 02:10 (UTC)[返信]
禁止指定された文字のうち、制御コード・不可視文字の類は分かりますが、全角空白はちょっと疑問です。どこかに「絶対禁止」とする方針があるのでしょうか？WP:NCは記事名前空間についてのものであると理解していますし、特にWikipedia名前空間や利用者名前空間での記事に対し「絶対禁止」というのは合意となっていないように思います。特に削除依頼のように期間を定めて審議を行うものに対して今回のような編集禁止措置がかかるときわめて不都合です。また、運用としては記事移動を行えば良いというご意図でしょうか？どのような心積もりであるかお示しいただけませんでしょうか？--Masao 2007年5月5日 (土) 12:38 (UTC)[返信]
そもそもこの記事名チェッカーは(仕様上の問題ですが) JavaScript をオフにすれば意味がないなどすべての環境で動作することは想定されていませんよね(JavaScript に非対応な環境もありますし<-ただしこれはそもそもそんな環境で Wikipedia への投稿は非推奨でしょうけど)。あと、リダイレクトを作成したい場合など投稿できた方がいいときもありますので、完全に投稿不可にしてしまうんじゃなくて編集時の警告と投稿時の警告の警告二段構えだけでもいいような気もします。 --Mzm5zbC3 2007年5月5日 (土) 13:11 (UTC)[返信]

記事名違反記事に表示されるボタン「即時削除にマークする」について

[編集]

今の状態では2度押してしまったら、取り消しができずに即時削除タグが2つ付いたままになってしまいます。なので、もう即時削除タグが付いている場合は、そのボタンが表示されないようにして欲しいのですが可能ですか?--Kazutoko (会話｜履歴｜保管倉庫) 2007年5月13日 (日) 10:16 (UTC)[返信]

記事名チェッカー　バグその2

[編集]
     // 削除依頼・ブロック依頼は無警告
     if(wgTitle.match(/^(削除依頼|投稿ブロック依頼|管理者への立候補)\//)) return;

全角英数字を用いたアカウント名のサブページを作成する必要のある「コメント依頼」と「管理者の解任」も付け加えたほうがいいのではないでしょうか？今のままではWikipedia:管理者の解任/ＮｉＫｅ 20070510を編集するときに警告が出てしまいます。--《蒼輝煌》春野秋葉 2007年5月15日 (火) 12:12 (UTC)[返信]

警告文について

[編集]

警告文が目立ちすぎだとおもいます。

自己の会話ページに新規メッセージがあったときの表示に合わせた体裁にするのは、利用者にあたえる印象が強すぎると思います (編集を断念するひとも出そうです)。過去の版を編集しようとしているときに出る表示に合わせた体裁にする程度で、よいのではないでしょうか。

警告を無視して編集するのに正当な理由が存在する場合だってあるわけですし、仮にそうでなくても、あとで移動すればよいことですし。 --Hatukanezumi 2007年5月15日 (火) 13:36 (UTC)[返信]

警告を無効化するタグもあるべきだと思います。現在警告が出る記事のすべてが不適切だという保障はないわけで、警告が出る記事にも適切な命名理由のあるものが少なくないはずです。不適切な警告のせいで編集意欲を阻害されたり、命名理由を理解しない方が警告を理由に改名する可能性もあります。--micro 2007年5月15日(火) 23:03 (JST)

どういうもののがいいと思いますか？ Tietew 2007年5月16日 (水) 03:15 (UTC)[返信]

「タグ」については、本文中に特定のテンプレートがあったら警告表示を抑制する、というような実現方法でいいのではないでしょうか (可能なら)。ウィキペディアではコードを見ないことに決めているので、中途半端な意見ですみません。
あと、ついでの要望ですが、できたら、記事名チェッカの仕様を文書化していただきたいです。システムがブラックボックスになるのはよろしくないとおもうので。 --Hatukanezumi 2007年5月16日 (水) 03:31 (UTC)[返信]

「違反」という表現は、明らかに誤りなので訂正していただきたいです。「考慮すべきガイドライン」に「違反」しているというのは意味が通りませんから。 --Hatukanezumi 2007年5月17日 (木) 16:51 (UTC)[返信]

「ガイドラインに違反」という言葉はおかしいのですか？ググって みたらYahoo! JAPAN、Amazon.co.jp、京都大学なども「ガイドラインに違反」という言葉を使っていましたが。「考慮すべき」というのが頭についているから「考慮すべきガイドラインであるWikipedia:記事名の付け方を考慮していない」などの表現が正しいという意味でしょうか？--《蒼輝煌》春野秋葉 2007年5月17日 (木) 17:17 (UTC) 一部修正済み[返信]
「違反」というのは規定に対して使われる言葉でしょう。だからそもそも、ウィキペディアのいかなる方針やガイドラインにもつかわれないはずですが、ことガイドラインにつかわれるのは問題外だとおもいます。 --Hatukanezumi 2007年5月17日 (木) 17:52 (UTC) そうです。--Hatukanezumi 2007年5月18日 (金) 03:03 (UTC)[返信]

抑制タグについては当初から思いついていたのですが、「警告の意味を理解しない人によって埋め込まれる」懸念があることと「節編集」の時に認識ができないことから見送っていました。というか、「どういうもののがいいと思いますか？」に対するお答えはいただけないのですね。残念です。Tietew 2007年5月18日 (金) 02:14 (UTC)[返信]

では、もう少し詳しく書きます。
記事名の付け方がなんらかの事情でガイドラインを外れることを示すテンプレートを定めておいて、本文のはじめのほうに「{{なんとかかんとか」が含まれているかどうかを識別して判断する、というのはどうですか。パラメタを読んで字種の判定をしたりするところまでは、必要ないようにおもいます。コメントアウトされてる場合とかまで考慮すると面倒になりそうですが、レアケースでしょうから無視してさしつかえないでしょう。 --Hatukanezumi 2007年5月18日 (金) 03:03 (UTC)[返信]
過去の版を編集する際に出てくる体裁の警告では編集者が気が付かない可能性が高いのではないかと考え、現状の体裁をちょっと弄る方向で提案してみます。こんな感じにするのはいかがでしょう。

このページの項目名は次にあげる理由によってWikipedia:記事名の付け方に沿っていない可能性があります。特別な理由（[[ノート:MediaWiki‐ノート:Common.js/記事名チェッカ]]参照）がない場合には、記事を移動することを検討してください。移動しなくても編集を続けることは可能です。

  • 全角英数 または 全角記号を含んでいます

項目名を変更した場合は、このページのリンク元を参照して、リンクを差し替えていただきますようお願いします。不明な点があればWikipedia:井戸端で質問してください。

文面に関してはあまり考えずに書いてますが、編集者に与える印象が和らぎつつ、かつ注意を促すことが出来るのではないかと思います。--Swind 2007年5月18日 (金) 03:38 (UTC)[返信]
そういえば、チェックの仕様を突然入れたのはここにいるかたがたではないですね。八つ当たり申し訳ない。 過去の版の警告にあわせた案です。ほかの警告とならべてみます。

警告: このページの項目名は次にあげる理由により、Wikipedia:記事名の付け方に違反している可能性があります。記事名の付け方に違反している場合は、移動することを検討してください。

  • 理由の説明文

項目名を変更する場合は、このページのリンク元を参照して、リンクを差し替えていただきますようお願いします。不明な点があればWikipedia:井戸端で質問してください。

警告: あなたはこのページの古い版を編集しています。もしこの文章を保存すると、この版以降に追加された全ての変更が無効になってしまいます。

警告: 編集中のページまたは節のサイズは XX キロバイトです。一部の古いブラウザ（Netscape Navigator 4.x 等）の中には 32 キロバイト以上のテキストを編集すると問題が起きるものがあります。このページを節に分けることを検討するか、節単位の編集を利用しましょう。詳しくは、Wikipedia:ページサイズを参照してください。

文章はとりあえず現行のままです。全部太字にしてしまうと、かえってめりはりがなくなって読まれにくいようにおもうので、最初だけ太字です。 --Hatukanezumi 2007年5月18日 (金) 08:12 (UTC)[返信]

記事名チェッカ差し戻しの依頼

[編集]

とにかく、実装者のひとりからはなにひとつ反応さえなく、もうひとりからは「ミスリーディングである」という意味のぶっきらぼうなコメントをいただくだけ、というのでは話になりません。そういうひとたちが、不用意にシステム全体に影響する変更を行っては困ります。話し合う気がないか、その暇がないのでしたら、とりあえず実装を差し戻してください。 --Hatukanezumi 2007年5月25日 (金) 18:03 (UTC)[返信]

いくら実装者が要望に返事する義務も対応する義務もないとはいえ、#記事名チェッカー　バグその2のように一切黙殺するというのもかなり不思議な話です。私は記事名チェッカーの差し戻しを特に要求しませんが（その趣旨には賛同するし、警告を無視してまで編集することが必要な機会はかなり限定されているから）、少なくともこのノートに記載されたことについての返事くらいはいただきたいものです。--春野秋葉 shining blue 2007年5月26日 (土) 00:50 (UTC)[返信]

補足。あるいは、MediaWiki:Common.jsの内容に意見がある全ての利用者に、内容を編集できる権限を与えるか、です。そうなっていないのですから、「実装者は要望にこたえる義務はない」とか「意見を述べるときはミスリーディングしてはならない」などとは主張できないはずです。

感想ですが、ある程度技術力のある sysop が、システムにちょっとしたギミックを入れて悦に入る、という感覚は、とってもよくわかるし、わたしももし sysop ならやっちゃいそうだとおもう (できなくても、少なくともそういうことに憧れはある)。でも、いまのJAWPは、そういうお遊びが常に許されるような小さなコミュニティではないとおもうのね。説明のできない (または説明のための時間をさけない) システムの変更は、基本的に行ってはいけないとおもうんです。

こういう状態が続くと、そのうち勘違いした輩が「SuisuiとTietewの不当な管理者権限行使の件について」とか騒ぎだしかねないんで、あまり長引かせず、対話を成立させるか、さもなければ差し戻して要求仕様から議論しなおし、としていただきたいんですが。ほかの管理者のかたはどうお考えですか。—以上の署名の無いコメントは、Hatukanezumi（会話・履歴）さんが[2007年5月26日 (土) 02:36 (UTC)]に投稿したものです（emkによる付記）。[返信]

> MediaWiki:Common.jsの内容に意見がある全ての利用者に、内容を編集できる権限を与える
これは絶対にできません。開発側にそんな提案をしたら一笑に付されるでしょう。詳しくはクロスサイトスクリプティングをどうぞ。Tietew 2007年5月27日 (日) 06:55 (UTC)[返信]

とりあえずWikipedia:合意形成の手順にしたがって記事名チェッカの一時差し戻しを提案して、合意が得られたら「コミュニティの合意に従って」一時差し戻しを要求してみるというのはいかがでしょうか。井戸端#記事名チェック機能についてを見ても、議論の余地なく差し戻した方がいいに決まっているという合意が成立しているようには見えませんでした。

なお、個人的には一時差し戻しに賛成しています。--emk 2007年5月26日 (土) 05:40 (UTC)[返信]

全角英数や半角ｶﾅでこそ意義を持つ項目名もあります。これらが半角英数や全角カナの項目名で作られたり、変更したりしているのは、飽く迄もウィキペディアのルールに則るためのものであって、正しく無い表記法を是認している事にはなりません。リダイレクトが消されている状況は、明らかな破壊行為です。合意無き、このような改悪は受け入れられません。--٢١٩.١٧٤.١٥٨.٢٢٥ 2007年5月28日 (月) 03:59 (UTC)[返信]

その件についてはWikipedia‐ノート:記事名の付け方で戦う議論するほうがいいとおもいます。 --Hatukanezumi 2007年5月28日 (月) 04:38 (UTC)[返信]

記事名チェック機能の扱いについての提案

[編集]

Emkさんからの提案を受けて、以下提案します (なんか変)。

ウィキペディアが採用しているMediaWikiのユーザインタフェイスでは、JavaScriptを使ってさまざまな機能を実現することができます。たとえば、検索ページで外部の検索エンジンを利用できるようにする機能も、JavaScriptで実現されています。

JavaScriptで実現される機能には、つぎのような種類があります。

  1. MediaWikiに標準で装備されているもの。
  2. プロジェクトごとに実現や変更が可能なもの。
  3. プロジェクト内の、各利用者ごとに実現や変更が可能なもの。

ここでの提案に関係するのは 2. のもので、MediaWiki:Common.jsというページを編集してJavaScriptのプログラムを記述することで機能を実現したり変更したりできます。

日本語版ウィキペディアのMediaWiki:Common.jsに記述された機能は、日本語版ウィキペディアのすべての利用者に (使っているブラウザでJavaScriptの使用を認めていれば) 影響します提供されます。また、このページは、通常の利用者には編集することができず、管理者だけが編集できます。

この間、このCommon.js に、利用者が記事を編集または作成しようとしたときに記事名をチェックし、チェックの結果プログラムが適切でないと判断した場合には警告が表示される機能 (以下「記事名チェッカ」と呼ぶことにします) が追加されました。しかし、これについて、つぎのような問題が指摘されています (これまでにあった指摘から一部を例示します)。

  • 期待しない場面でも動作してしまう (標準名前空間以外のページを編集しようとしたときも動作することが報告されています)。
  • 記事名チェッカがどういうチェックを行っているのかわからない (できること、できないことの説明が利用者に対してなされていません)。
  • 警告文やそのデザインが適切かどうかについての疑問。
  • 以上のような事柄に関しての説明の不足 (Common.jsが一部の利用者だけに編集可能であるにもかかわらず、編集した利用者に向けて疑問や要望をのべても、返答やプログラム修正によるレスポンスがないことがある)。

記事名チェッカに関する以上のような問題は、利用者間の議論と合意に基づいて決定し、解決するべきであると考えます。そのようなことが可能となる前提をつくるために、まずは、つぎのことを提案します。

  • MediaWiki:Common.jsのうち、記事名チェッカのために追加されたプログラムの記述については、いったん差し戻す。

この提案で合意できるようでしたら、管理者に差し戻しを依頼したいとおもいます。なお、合意形成までの期間は5日から7日程度をめどに考えています。ご意見をお願いします。 --Hatukanezumi 2007年5月26日 (土) 13:57 (UTC) 微修正 --Hatukanezumi 2007年5月27日 (日) 02:25 (UTC)[返信]

差し戻し提案に賛成いたします。導入初期に井戸端での不具合対応、ユーザ対応を行った経験等から、Hatukanezumiさんの問題点指摘に以下を付け加えます。

  • 拙速な導入はWeb上における多様な利用者環境への配慮に欠けます。
    • ブラウザ上で動作するJavaScriptは全ての利用者の環境で有効とは限りません。このため、JavaScript未対応ブラウザやJavaScriptを無効にしたブラウザにおいては記事名チェックは全く働きません。この場合の対応をどう考えているのか提案者からの説明はありません。また、ブラウザ・プラットフォームの組み合わせは多様で、現にSafariユーザの一部からは記事名チェッカが誤作動を起こして全ての記事で編集ができなくなってしまうとの報告があり、当該環境においては記事名のチェックを行わないようにする暫定措置をお願いしました。このような種々の環境でのテストや、それらにどう対応するかを検討・議論する時間もとらず、さらに合意形成のプロセスを省いてまで、こういった機能を拙速に導入する必要は認められません。むしろ混乱を招いてしまう害の方が大きいように思います。

導入初期のころに苦言を呈しましたが、繰り返します。「せめて、ご自分のユーザスクリプト空間で1ヶ月程度の試用を行って不具合が出ないことを確認し、かつ、コミュニティに提案を行い、合意形成を確認後に移入していただけませんでしょうか？」その後の議論から下線部追加。 十分な議論と検討、説明があれば、テスト・バグ修正等にも協力できるでしょうし、導入そのものにもそれほど反対しませんが、そのような状況に無い現段階ではまずは差し戻してから議論を進めたほうがよいように思います。以上です。--Masao 2007年5月26日 (土) 14:38 (UTC)[返信]

  • （賛成）すでに上で賛意は示していますが念のため。システム全体に影響を与えるMediaWiki:Common.jsが保護されている管理者にしか編集できない仕様になっていることは理解できますが、だからこそ管理者はコミュニティの合意なしに安易な編集を行うべきではないと考えます。
    管理者はたまたま保護されたページを編集するeditinterface権限を技術的に持っているに過ぎず、保護されたページMediaWiki名前空間の編集に関して一般利用者より大きな決定権は持っていないはずです。--emk 2007年5月26日 (土) 20:31 (UTC)[返信]
いいえ。MediaWiki名前空間は現バージョンでは「保護」されていません（故に保護の解除もできません）。MediaWiki名前空間の編集は、sysopに与えられているeditinterfaceという別種の権限です。Tietew 2007年5月27日 (日) 06:55 (UTC)[返信]
ご指摘に従って修正しました。この指摘によって論旨が変わることはないので、反対意見ではないと理解してよろしいでしょうか?--emk 2007年5月27日 (日) 14:07 (UTC)[返信]
全面的に賛成します。#記事名チェッカー バグにも記述しましたが、そもそも編集できなくするのはやり過ぎだと思います。せめて警告だけにしてはどうでしょうか。すべての環境において正常に動作するとは限らない(実際に不具合報告などが多数ある)、リダイレクト記事の作成の需要などからもWikipedia:記事名の付け方に反していても何らかの方法で編集可能にする必要はあるでしょう。単に知らずにそういう記事名で立ち上げようとしたならまだしも、編集せざるを得ない状況も多々ありますので、編集の強制無効は何とかして欲しいです。何の告知もなくいきなり実装しているので、合意形成できていないとしかいいようがありません。一般利用者の手本となるべき管理者がそれを破るのはまずいですよね。 --Mzm5zbC3 2007年5月26日 (土) 21:03 (UTC)[返信]
多数ですか？　環境による不具合報告は一個しか受けていません。ミスリーディングは止めていただきたい。Tietew 2007年5月27日 (日) 06:55 (UTC)[返信]
  • クロスサイトスクリプティングだけが問題なのではありません。逆にいえば、sysopの編集であればそれを避けられるという保証があるのでしょうか。保証できるとして、どうやってそのことを証明しますか。
  • 仕様上「保護」されているかどうかが問題なのではありません。編集権限にeditInterfaceという呼称があるのなら、その権限のことを述べていると考えればよいのではないですか。
  • 「すべての環境において」という言葉尻をとらえてソフトウェア環境の問題に限定すべきではありません。そもそも、ソフトウェア環境、予想される利用者の反応、対象データの吟味といった面において、すべてどころか、十分な検討と検証もなされていない (すくなくとも、なされていると説得するに足るエビデンスは示されていない) ことが指摘されているのではないですか。
ミスリーディングに陥っているのはどちらでしょうか。 --Hatukanezumi 2007年5月27日 (日) 09:26 (UTC)[返信]
横からすみません、Hatukanezumiさん、具体的にはどんな「不具合」がおきているのでしょうか。--miya 2007年5月30日 (水) 05:41 (UTC)[返信]
（賛成）違反、あるいは違反の可能性などと説明がありますが、そもそもそれが基準としているルールはあくまで草案であって拘束力はないはずです。それほどまでにチェック機能を付けたいのであれば、Wikipedia‐ノート:表記ガイドでの議論に積極的に参加して、確かなルールを作るべきではないですか？ それともすでに拘束力のあるルールがあるのでしょうか？ チェック機能を付けるに当たって、きちんとした話し合いが行われたんですか？--micro 2007年5月31日(木) 18:35 (JST)

ええと。ぼちぼち提案から5日たつわけですが、提案についてコンセンサスでの合意は得られていると見るべきでしょうか。どなたかご判断をお願いします。まだ合意は得られていないとの意見がありましたら、7日めまで議論を継続したいとおもいます。 --Hatukanezumi 2007年5月31日 (木) 04:53 (UTC)[返信]

Tietewさんのコメントが反対なのかどうかよく分からないのが困ります。私の問いかけは無視して別の編集をしているので自分で考えろということだと思いますが、反対意見だとみなす合理的な理由は見あたらないので反対意見ではないのでしょう。
Mzm5zbC3さんへのコメントも反対意見ではないような気がしますが、「ミスリーディングによって得られた不当な合意だから無効」とか理由を付けて編集依頼を却下するための布石だったらいやすぎます。
MediaWiki:Common.jsの編集開放なんかありえない、つーか不可能というコメントに関しては、この提案とは全く関係ないので明確に反対意見ではないとみなしていいでしょう。
Help:項目名チェッカが提示されていますが、現物の動作のほうが「正確」らしいので仕様書として意味をなしていないことは明白です。Help:項目名チェッカとの違いをバグや不具合とみなすことはありえないからです。しかし何のために提示したのか深読みすると、やっぱり「仕様を提示したにもかかわらず仕様がないという理由で差し戻しを要求している」とか言いがかりを付けられて編集依頼を却下されたりしないか心配になります。
とりあえずmiyaさんの再反論がないか待った方がいいかもしれません。--emk 2007年5月31日 (木) 17:14 (UTC)[返信]
とりあえず、明確な反対意見は出ていないので現状で行けば一旦差し戻しのコンセンサスはとれていると見て良いのではないかと。公式方針やガイドラインといったプロジェクト全体に関与する文章は、合意なしの編集は慣例として、合意を経るために一旦リバートしてもよいことになっていますよね。Common.jsもそれに準ずる扱いでよいと私は考えます。--spirituelle 2007年5月31日 (木) 18:03 (UTC)[返信]
他の方も仰っているように、記事名チェッカの存在自体を反対しているわけではありません。「告知なしにいきなり実装されて本運用されたことが問題なのでいったん戻して合意形成を行ってから再度実装しよう」というだけです。また、そもそも環境によっては正常に動作しない(JavaScript を無効にしたり対応していないブラウザやクライアントでアクセスした場合、一部のブラウザで誤動作があったこと他)などの問題もあり、もう少し煮詰める必要があると思います。 JavaScript 実装は明らかにクライアントサイドの実装に影響されますので本来、ユーザビリティの観点では間違っていると思いますが。いざとなったら Bot などで編集を強行することもできますし(ワザとそういうことをする人も現れないとは限りません)。どうも、記事名チェッカは管理者が楽をするためだけに利用者のことをまったく考えずに実装したとしか考えられません(この場合の利用者とは Wikipedia のユーザー登録者ではなく、 Wikipedia で調べ物などをする利用者を含)。いろいろな削除依頼だとかなんかで管理者の負担が大きいことは事実ですし、それをできるだけ軽減したいという気持ちも分かりますが管理者として一般利用者第一に考えて欲しいです。 JAWP の投稿者は(荒らしたり Wikipedia の基本方針などに疎い者が多い) IP ユーザーが多いってのも管理者に負担をかけている一つの理由なのかも知れませんね。 --Mzm5zbC3 2007年5月31日 (木) 18:31 (UTC)[返信]
一時差し戻しには賛成だが、Tietew氏は一度こうすると決めたことにはテコでも動かない・編集合戦すら厭わない方だ。以前Template‐ノート:TOCrightでお話したときと同じだ。たとえMediaWiki名前空間であっても、たとえ他の管理者の誰かが差し戻したとしても、それは変わりないと思う（MediaWiki名前空間での管理者同士の編集合戦というのも余興としては面白いかもしれないが）。これはもう Safari 1.x 以前のユーザにはあきらめてもらって、Safari 1.x 以前は使うなと言う方が早い。OSのバージョンなど環境によっては 2.x 系にアップデートできないらしいが、時にはあきらめも必要だろう。というわけでWikipedia:メディアウィキに適応するブラウザを少し書き換えた。必要があれば使用してはならないブラウザに移動しても良いかもしれない。--ラッキースター・キッド ◆Luck.w.AEQ 2007年5月31日 (木) 21:23 (UTC)[返信]
一旦差し戻します。議論・合意の後に記事名チェッカを導入することへの反対はみられないものの、現状では仕様等が独断・不十分であるという意見があり、このままなし崩し的な導入はできないと思われます。（参考:Wikipedia:保護の方針#半永久的な保護およびWikipedia:管理者の手引き#インターフェースを修正する）--co.kyoto 2007年6月1日 (金) 07:40 (UTC)[返信]

差し戻しを確認しました。書き忘れていたのですが、Kahusiさんの2007年5月7日 (月) 04:04の編集[3]がいっしょに差し戻されてしまっています ("Technical restrictions" title fix)。これについては英語版での実績があるものを利用者の要望によって移入したものであり、機能追加のアナウンスもなされていますので、復元してもよいのではないかとおもいます。お手数ですが、Kahusiさんか、ほかのeditInterface権限をお持ちのかた (つまりsysop) に復元していただくことになるかとおもいます。 --Hatukanezumi 2007年6月1日 (金) 08:35 (UTC)[返信]

Kahusi氏の編集を復元しました(これで問題ないでしょうか、すみませんがご確認下さい)。大変失礼しました。--co.kyoto 2007年6月1日 (金) 08:53 (UTC)[返信]
co.kyoto さん、管理者になったばかりなのにお手数かけてすみません。で、差し戻しにだけ参加してこれからのチェッカに関する議論に参加しないのはあまりにもあれなので一応、いくつかいっておきます。まず、Help:項目名チェッカによると「Project名前空間(警告のみ)と利用者名前空間、画像名前空間」のみチェックの例外になっているという風に書かれていますがぼくは通常名前空間(記事)以外の名前空間はすべてチェックする必要はない(通常名前空間のみのチェックでいい)と思います。あくまで、Wikipedia:記事名の付け方は記事名の指針であり、それ以外の名前空間には効力は及ばないはずです。特に Template 名前空間や Wikipedia 名前空間、会話名前空間、ノート名前空間はどんな名前でも(MediaWiki の仕様上、不可能な名前以外は)投稿可能にすべきです。あとは、 Wikipedia:記事名の付け方 にもいろいろ不備があるように思えますので今後、改訂を提案したいなと考えています(正式な名称を使うこと、日本語を使うことなど)。あと、関連する話題として井戸端で話題になったリダイレクトに関してもやはり指針を作成すべきだと思います(これは明らかにおかしかったり、冗長なリダイレクトとか以外は全角英数字記号などが含まれていたりしても基本的にユーザービリティなどの問題から許可すべきだと思います)。 --Mzm5zbC3 2007年6月1日 (金) 11:26 (UTC)[返信]
co.kyotoさん。わたしの提案に不備があったため、二度手間になってしまって申し訳ありませんでした。問題なく動作していることを確認しました。ありがとうございました。
なお、これはみなさんにお知らせですが、Help:項目名チェッカをとりあえずMediaWiki‐ノート:Common.js/Help:項目名チェッカ (案)へ移動しました。今後の議論の叩き台とはなり得るものの、現時点で有効ではない機能の解説であるため、Help名前空間に置いておくべきではないと考えたためです。 --Hatukanezumi 2007年6月1日 (金) 14:33 (UTC)[返信]

記事名チェッカのメリットとデメリット

[編集]

Hatukanezumiさん、差し戻し提案の前に、どうか、冷静にこの「記事名チェッカ」のメリットとデメリットを見積もってみてください（私もまだ把握し切れていませんが）。 「記事名チェッカ」を「薬」になぞらえて考えれば、「不具合がおきる」「頓珍漢な案内が出る」というのは「副作用」に当たると思うのです。で、薬は良い作用と副作用を天秤にかけて、使うか使わないか、判断するように、「記事名チェッカ」もメリットとデメリットを秤にかけるべきだと考えます。

ご存知だとは思いますが、不適切な記事名のせいでハード面・ソフト面（管理者の手間と時間）のリソースがずいぶん浪費されてきました。進んで就任した管理者ではありますが、「半角スペースがある/ない」「半角/全角違反」などの後始末はおよそやり甲斐のない、賽の河原での石積みのような消しゴム作業です。これがスクリプトで半分でも減らせれば、非常に大きなメリットであると思います。実際、この手の消しゴム作業のうち、チェッカではじける分についてはなくなったような感触があります（昔とちゃんと比較はしていないので感触だけですが）。個人的には、修正すべき点は修正するとしても全面差し戻しはご堪忍ねがえないかと思います。

で、ここまででどんな「不具合」があるのか、具体例がよくわからないのですが、どんなものがあるか、具体的にリストしてみてもらえませんか。--miya 2007年5月30日 (水) 05:41 (UTC)[返信]

議論するために、いったん差し戻しをしようという提案です。記事名チェッカをやめさせるための提案ではありません。
現在問題になっているのは、もっとメタな話です。不具合かもしれない例を挙げてみます。
  • 全角英数字が含まれているリダイレクトを編集しようとしてもできず、即時削除テンプレートを貼り付けるボタンをクリックする以外のことができないのは、不具合でしょうか? 不具合ではないでしょうか?
  • 「そうですね (笑)。」という記事を編集しようとしたときに「カッコの前にスペースがありますが、カッコの後ろにスペースがありません」という警告が出ます。このとき、利用者は警告文のとおりに修正をすればいいのでしょうか? それとも、別の行動を期待されているのでしょうか?
  • 記事名前空間以外のページでも、ページ名に全角英数記号や半角仮名が含まれていると警告がでるのは、不具合でしょうか? そうではないでしょうか?
  • 記事名チェッカがなにをチェックしているのか (逆に言うと、どういうものは見逃すのか) は、普通のユーザにはわかりません。したがって、WP:NCと整合するのかどうかもわかりません。不具合があるどうかを判定できるのでしょうか?
  • 以前、Safariの特定のバージョンではまったく編集ができなくなるという不具合がみつかり、該当するブラウザに対してはチェック機能を働かなくしてあります。こういう不具合はほかにもあるのでしょうか? もうないのでしょうか?
現在では、どちらともいえないのです。なぜなら、「不具合があるかどうか」というのは、仕様が決まっていてこそ議論できることだからです。
Miyaさんが上記のようなメリットをお感じなら、そのようなメリットを発揮できるものをつくっていくための議論をすればよいとおもいます。議論の結果、「そんなことは不可能だ」となるかもしれませんし、「実はもっといいやりかたがある」ということになるかもしれませんし、「すでにあったものでよかった」ということになるかもしれません。
差し戻しを提案し、一部のひとが支持している最大の理由は、そのような議論ができていず、記事名チェッカがどうあるべきかの合意がないにもかかわらず、記事名チェッカのようなものが稼動してしまっていることですだとおもいます。
繰り返しますが、記事名チェッカをやめさせるための提案ではありません。ご理解いただけましたでしょうか。 --Hatukanezumi 2007年5月30日 (水) 06:41 (UTC) 微修正 --Hatukanezumi 2007年5月30日 (水) 15:06 (UTC)[返信]
編集競合しました…。Hatukanezumiさんが書かれたことでほとんど言い尽くされてしまったような気もしますが、念のため書いておくことにします。
メリット
  1. 全角・半角など一般利用者の気付きにくいミスを機械的にチェックし、未然に防ぐことができる
  2. 頻繁に生じている誤り・ミス等に対して機械的にチェックすることで、ミスをなくして、それに対応する人的リソースを節約できる
デメリット
  1. 機械的なチェックをどの項目・記事名を対象に行うのか仕様が明らかでない。説明文書が存在しない（しいて言えばソースコードのみ）
  2. ブラウザ毎のJavascript実装系そのものの不具合（おそらく）に起因して、全ての記事の編集を不能としてしまう場合あり（Mac OS X + Safariなど）。→ マイナーなブラウザなどで不具合を起こさないようにするためのテスト期間が必要。
  3. JavaScriptを有効にしている利用者にのみ効果がある（JavaScriptが無効もしくは未対応の環境には無意味）
  4. 記事標準名前空間以外においても他の利用者による編集を排除してしまうため、移動・削除などの手間が増える
  5. 機械的なチェックによりWP:NC違反とされてしまった場合、記事内容の修正ができない
以上は、既にあがっている議論から推察したあくまでも個人的な見解です。個人的には、デメリットのうち1番目を特に気にしています。説明さえきちんとされれば、導入に異を唱えません。
Miyaさんがおっしゃることは良く分かりますが、この節での提案は「いったん差し戻す」です。単に議論や説明があまりに足りないので、一時的に差し戻そうという意図だと理解しています。恒久的にこの機能を否決しようという提案ではありません。副作用があるので、いったん差し戻した上で、「副作用を甘受しても受け入れたい」もしくは「副作用が無くなるまで臨床試験を繰り返してから導入する」のかを議論したほうが良いと思います。
記事の内容とは無関係に編集ができなくなってしまうと不便なケースが多々あります。また、名前空間によって許される項目名の範囲は異なるでしょう（そもそも本機能は記事名前空間以外には適用すべきではないと思いますが）。現在の記事名チェッカにはそういった配慮が欠けています。--Masao 2007年5月30日 (水) 07:01 (UTC)[返信]

井戸端告知で「コンセンサスを得られた」と書かれたのを拝見しました。まるで反対意見が全く無かったみたいですね。　

上で不具合（かもしれない）例を挙げてくださいましたが、チェッカを実行しながら一つずつ手直ししていくのではダメな理由が分かりません。ウィキペディア上なら、実用に供しながら修正していけますが、チェッカを止めたら、どこでだれが「試行」することになるのでしょうか。 止めたら、こんどは「バグがなくなりました」と言えるまで、再開できないのではないでしょうか？

Hatukanezumiさんの指摘
＞全角英数字が含まれているリダイレクトを編集しようとしてもできず、即時削除テンプレートを貼り付けるボタンをクリックする以外のことができないのは、不具合でしょうか? 不具合ではないでしょうか?
  • 全角英数リダイレクトを許容するならともかく、今は許容しないルールなのだから即時削除でいいでしょう。
＞「そうですね (笑)。」という記事を編集しようとしたときに「カッコの前にスペースがありますが、カッコの後ろにスペースがありません」という警告が出ます。このとき、利用者は警告文のとおりに修正をすればいいのでしょうか? それとも、別の行動を期待されているのでしょうか?
＞記事名前空間以外のページでも、ページ名に全角英数記号や半角仮名が含まれていると警告がでるのは、不具合でしょうか? そうではないでしょうか?
  • 警告があって良いでしょう。警告が出て困る具体例があれば挙げてください。
＞記事名チェッカがなにをチェックしているのか (逆に言うと、どういうものは見逃すのか) は、普通のユーザにはわかりません。したがって、WP:NCと整合するのかどうかもわかりません。不具合があるどうかを判定できるのでしょうか?
＞以前、Safariの特定のバージョンではまったく編集ができなくなるという不具合がみつかり、該当するブラウザに対してはチェック機能を働かなくしてあります。こういう不具合はほかにもあるのでしょうか? もうないのでしょうか?
  • 見つかってから対処すれば良いでしょう。
デメリット（Masaoさん指摘）
（Masaoさん、メリットの明確化をありがとうございました）
  1. ＞機械的なチェックをどの項目・記事名を対象に行うのか仕様が明らかでない。説明文書が存在しない（しいて言えばソースコードのみ）
  2. ＞ブラウザ毎のJavascript実装系そのものの不具合（おそらく）に起因して、全ての記事の編集を不能としてしまう場合あり（Mac OS X + Safariなど）。→ マイナーなブラウザなどで不具合を起こさないようにするためのテスト期間が必要。
    • 不具合が報告されたマイナーなブラウザについては、動作しないようにすればいいでしょう。利用者も少ないはずですし、無効にしても影響は大きくはないと思います。マイナーなブラウザの分までテストしてからというのは、実践的ではないように思います。
  3. ＞JavaScriptを有効にしている利用者にのみ効果がある（JavaScriptが無効もしくは未対応の環境には無意味）
    • オフにしている人・未対応の環境の人（PC熟練者？）は多くないと思われます。
  4. ＞記事標準名前空間以外においても他の利用者による編集を排除してしまうため、移動・削除などの手間が増える
    • 記事標準名前空間以外で、どんな記事名が排除対象ですか？具体的に教えてください。Help:項目名チェッカを見ると、記事標準名前空間以外についてはいろいろ設定を変えているようです。
  5. ＞機械的なチェックによりWP:NC違反とされてしまった場合、記事内容の修正ができない
    • 記事名を修正してから記事内容を修正すれば良いのでは？

以上、お二人の挙げてくださったデメリットに、素人意見をつけてみました。--miya 2007年6月1日 (金) 17:16 (UTC)[返信]

私も文字コード系統は素人ですが、コメントさせていただいてもいいでしょうか。

WP:NC違反のリダイレクトにdbタグが貼られるだけならいいのですが、WP:NC違反の記事 (即時削除対象でない) までdbタグが貼られてしまいます。簡単に移動できる例ならそれでもかまわないのですが、私が関与した案件のノーマン・Y・ミネタ・サンノゼ国際空港（ノート / 履歴 / ログ / リンク元）(Yが当時全角だった) では本来の記事名に履歴がありすぐには移動できず、またdbタグもはずせず、結局管理者の方の対処を待つまでdbタグ付きの記事がしばらく残ってしまいました。スクリプトで記事種別 (記事かリダイレクトか) を判別し、それによって対応を変えるということが可能かどうかは私には判断できませんが、一応問題点として指摘しておきます。

今回の差し戻しに問題があったとは思いません (差し戻しに合意があったうんぬんというより、もともとの導入に明らかなコンセンサスが得られていないということだと解釈しました) 。ただ、チェッカーが起動しなくなって早速WP:NC違反の記事名が出てきたようで、そういう意味ではきっちりと仕様 (警告のみにするか、禁止するかの議論も含む) を固めて再始動に向けてみてはと思います。あと、思ったのですが、即時削除の対象となるのは厳密にいえばWP:NC違反ではなく、WP:CSD#リダイレクトの2.違反です (慣例的に{{db|[[WP:NC]]違反}}で運用されていることは承知していますが) 。 --Happy B. 2007年6月2日 (土) 01:39 (UTC)[返信]

「コンセンサスを得られた」は自分でも変かなーと思っています。「コンセンサスを得られていないというコンセンサスが得られたと見られる」ということかな。でもそうすると「見られる」かどうかにもコンセンサスが必要かな。まあコンセンサスってそういうものですね。
Miyaさんの、メリットを積極的に評価する立場もわかるのですが、大半の利用者に影響をあたえる機能である以上、十分な説明と合意が必要とおもいます。そして、「説明と合意」は仕様だけではなく、利用者するひとに対しても必要です。たとえば、「そうですね (笑)。」が「へんな項目」とおっしゃいますが、そのような操作をした利用者にたいして、「これはへんな項目です」ということを説明し、同意してもらえるように仕向けなければなりません。そういう点でも、現在の記事名チェッカは不十分なものだと考えています。
たとえば、「そうですね_(笑)_。」や「そうですね_(笑)」(_は半角スペース) に訂正して編集を続けられても困るわけです。
また、だれかが「こんな記事名は変だ」と指摘したときに「記事名チェッカの指摘のとおりに修正してある」とか言われても困るわけです。
Miyaさんの意見でだされている論点については個別に検討していくべきだとおもっているので、ここでは一点だけを例として応答しました。
「同意」ということについて付記。Help:項目名チェッカに「ここに記載されている仕様の正確性は無保証です」という記述がありますが、ほとんどすべての利用者に影響するものを「無保証」と言いながら同意を得ずに適用する、というのは、おかしいと思うんですよね。……利用するたびに「仕様の正確性は無保証です。同意しますか?」と表示して、[同意]ボタンをクリックしたら利用できるようにするとかしないと (そんなの意味ない(笑))。 --Hatukanezumi 2007年6月2日 (土) 02:38 (UTC)[返信]
私が気になったのは「仕様の」正確性が無保証という点です。技術的制約その他の理由で仕様が正確に実装されているかどうかが無保証という話ならまだ分かるのですが、MediaWiki:Common.jsやMediaWikiそのもののソースを参照しろと言われてしまうと、記事名チェッカーにバグはありえないということになってしまいます。
おそらくJavaScriptが読めない利用者にとって何がチェックされているのか分からないという批判に応えるために作成されたのだと思いますが、JavaScriptのコードをそのまま日本語に書き下したような「仕様書」で十分に応えられているとは思えません。たとえば「そうですね (笑)。」という項目でエラーが出たときどうしたらいいのかは、Help:項目名チェッカを見ても結局分かりません。
WP:NCに反する、もしくは反する可能性がある項目名をチェックするそうなのでWP:NCのほうを見ろということなのかもしれませんが、
  • Wikipedia:記事名の付け方に反する可能性があるもののチェックなのになぜ(記事名前空間にない)項目名までチェックの対象なのか
  • WP:NCに反するように見えるけどチェックされないのはバグなのか、技術的に不可能なのか、意図的にチェックしていないのか
  • WP:NCには反しないはずなのにチェックに引っかかるのは意図的なのか、チェッカーのバグなのか、反しないけど反する可能性はあって機械的に判定できないから警告を出しているのか
とか即座にいろいろ疑問が浮かんできます。「仕様書」であるなら、これらの疑問に答えられるように(つまり少なくともWP:NCに書かれていることと想定している動作との違いとその理由について)書かれるべきです。--emk 2007年6月2日 (土) 04:46 (UTC)[返信]

Unterschwelligen Probleme

[編集]

この節では、個々に節を割り当てるには些細にすぎる、いわば「サブリミナル（なんちゃって）な諸問題」について扱っていったらどうか、と思います。万一話が大きくなったら、切り貼りなどを。

関数 checkTitleConvensions() ですが、wgTitle を使うのをやめるのかどうなのか、どっちつかずの不思議な状態に見えるのです。加えて wgArticleId も気になります。さあ。どうです、サブリミナルでしょう（なんちゃって）。Mulukhiyya 2007年5月27日 (日) 09:20 (UTC)[返信]

あぁっ、ついつられてコード読んじゃったよ。しまった。
で、U+FEFFをはじいているのはBOM挿入によるXSS脆弱性への対策なのかとおもいますが (ZWNBSPとして使うことは推奨されてないからはじいても実害ないだろうし)、MediaWikiってそんな場合の対処もできてないシステムなんですか? だとしたらそっちをなんとかするほうが急務ではないかとおもう。
それに、U+200C ZWNJやU+200D ZWJをはじくのは、パス名偽装対策の例から引っ張ってきたんだとおもいますが、ペルシア語やヒンディ語の語を含んだ項目名を作るようなことって、絶対ないと言い切れるんでしょうか。どうも、「日本語環境で使える文字種だけ通す」としたいのか、「日本語環境で問題になりうる文字種を通さない」としたいのか、コード見てもよくわからなかったです。U+200E LTRM、U+200F RTLMは、まあいらないような気もするけど。
あまりサブリミナルでなくてすみません。 --Hatukanezumi 2007年5月28日 (月) 08:56 (UTC)[返信]
脆弱性のあるバージョンのFirefoxだと、ZWNBSPはJavaScriptに渡される時点ですでに「消えている」のでJavaScriptでのチェックは根本的に不可能です。そもそもオフにできるJavaScriptでのXSS「対策」なんてほとんど意味ありませんから、単にエラーメッセージが示すとおり不可視文字を弾いてるだけじゃないですか?--emk 2007年5月28日 (月) 12:04 (UTC)[返信]
考えすぎですかね。BOM(もどき)を記事名に入れておいて脆弱性のあるFirefoxにアクセスさせる、というシナリオなのかと。それでXSSができてしまうのなら、MediaWiki側の問題です (たしかに、BOMはあまり関係ない)。 --Hatukanezumi 2007年5月28日 (月) 14:52 (UTC)[返信]

ほかに目についたことをメモっときます。ぜんぜんサブリミナルじゃない。ごめん。

  • CJK ideographsについては、BMP内に限っても、JIS X 0208の漢字だけでなく、同0212、そして同0213の大半、を通してますが、MicrosoftのNEC/IBM拡張のようなものが無警告というのは、やむを得ないと見るべきなのか。
  • いま気づいたけど、サロゲートははねてませんね。UTF-8 では認められていないというだけで、そういうシーケンスを作ることはできるのだけれど、やらなくて大丈夫だろうか。あと、見た感じ、PUAの範囲も通ってしまいそうです。
  • さらに、JavaScriptでどうするのかよく知らないんですが、UCS-2の範囲内のチェックだけでいいんでしょうか。 --Hatukanezumi 2007年5月28日 (月) 14:52 (UTC)[返信]
仮に攻撃可能だとしたらZWNBSPを記事名に入れようとする側にとってこんなオモチャは妨げになりませんし、攻撃される側のFirefoxではチェックできないので、どう考えても(攻撃対策としては)意味ありません。
漢字についてはJavaScriptでJIS X 0208のレパートリに限定するためのポータブルかつ効率のいい方法がない以上、やむを得ないでしょう。
JavaScript文字列はUTF-16なのでサロゲートを弾けば結果的にBMP外の文字も全部弾けます。--emk 2007年5月28日 (月) 19:37 (UTC)[返信]
そうなんですか>>UTF-16。では、サロゲートとPUAをはじけばいいですね (17面以降のことは知らない)。サロゲートペアがSIPの範囲だったら警告に「漢字」と表記してあげる程度の親切はあってもいいかもしれません。
漢字については、統合漢字拡張A、互換漢字、加えてIBM/NEC拡張の360字 (互換漢字にあるもの含む) をチェックする、くらいがせいぜいでしょうか。これでは中途半端なので、警告にとどめるしかないとおもいますが。
もうコードを見てしまったので、非漢字もおいおい見てみようとおもいます。 --Hatukanezumi 2007年5月29日 (火) 09:51 (UTC)[返信]
UTF-16ですから17面以降はハナから表現不能なので少なくとも入力チェックで気に掛ける必要はありません。SIPのHigh SurrogateはU+D840～U+D87Fになりますね。
IBM/NEC拡張は弾くのに中国の簡体字とか通しちゃうのはチェックのバランスがいまいち悪い気がします。個人的にはむしろWP:NCの制限を緩和したい気分です。あまり厳格に作ってしまうとWP:NCのほうが変わったとき面倒です。MediaWiki:Common.jsは保護されているためいちいち管理者に編集依頼を出さないと変更できないので、ある程度ルーズに設計しておいたほうがいいと思います。--emk 2007年5月29日 (火) 12:16 (UTC)[返信]
漢字については、「勝手に印刷標準字体に変わってしまうから、『正しい』字体を使わせろ」(例) なんて言って暴れるひとはあまりいなさそうですしね。個別の記事やプロジェクトで用字を決めてもらえばいいのかもしれません (いまこのへんですこし議論になってますが、いまのことろ心配なさそう)。
それはともかく、個々の字種の前に、先に書いた「『日本語環境で使える文字種だけ通す』としたいのか、『日本語環境で問題になりうる文字種を通さない』としたいのか」をはっきりさせたほうがいいようにおもいます (禁止するか警告にとどめるかのさらに前の前提。やるなら節をあらためてのほうがいいでしょう)。
たとえば前者の場合、本文での{{Unicode}}テンプレートの文言に相当するようなものを表示する、といったことも考えていいのかな、とゆうべ寝ながら思いつきました。 --Hatukanezumi 2007年5月30日 (水) 05:35 (UTC)[返信]

仕様の調査

[編集]

alpha版でどのようなチェックが行われているのかを調べました。

User:Hatukanezumi/titlechecker_alpha.json
利用者:Hatukanezumi/記事名チェッカ/alpha版仕様調査.js

を参照。なんだか釈然としない部分もありますし、「括弧」を一貫して「カッコ」と表記してたりするのはいやんな感じですが、意見はまたあとで。なお、文中のコメントは、一部を想像で補っていますので、間違いがあるかも。

<del>ドキュメントの完備してないコードを解析して仕様を調べるなんていう「汚れ仕事」は、普通はお金払ってもなかなかやってもらえないもんです。だれかウィキマネーでもいいからくれ (たぶん使わないけど)。</del> --Hatukanezumi 2007年6月2日 (土) 15:28 (UTC) 資料を復元。今後移動あり。--Hatukanezumi 2007年6月6日 (水) 06:45 (UTC)[返信]

記事名チェッカーの仕様について

[編集]

Wikipedia:記事名の付け方には「このページはウィキペディア日本語版の考慮すべきガイドラインです。多くの利用者が基本的に同意しており、従うことが推奨されますが、公式な方針ではありません。」と記述されています。つまり、強制ではなく例外はOKなのですよね。

現状の記事名チェッカーでは、新規作成時に警告だけにとどまらず阻害するようなシステムになっていますが、これを警告だけに留めるよう仕様の変更をしていただけないでしょうか。

よろしくお願い致します。--Yellow Submarine 2007年5月29日 (火) 04:03 (UTC)[返信]

んで、許容してほしい例外はどんなものでしょうか。こんなことに例外を作っても、混乱するだけだと思うのですが。例外を作るメリットはなんでしょうか。--ゆきち 2007年5月30日 (水) 05:12 (UTC)[返信]

記事名チェッカalpha版

[編集]

Tietewさんの書かれたコードを「alpha版」ということにして、User:Hatukanezumi/titlechecker_alpha.jsに置きました。各人がユーザスクリプト空間に置いてテストしはじめると無数のブランチができてしまいますので、これを今後の議論の叩き台なりとっかかりなりにする、ということで。

記事名チェッカalpha版を働かせるには、[[利用者:自分のユーザ名/monobook.js]]*(特別:Mypage/monobook.js - このリンクから作成できます) に、次の記述を追加します。この方法は、先の提案で述べた「JavaScriptで実現される機能」のうち3.の「各利用者ごとに実現」にあたりますので、記述を追加した利用者にだけ働きます。 

// 記事名チェッカalpha版
document.write('<script type="text/javascript" src="'
+ 'http://ja-two.iwiki.icu/w/index.php?title=User:Hatukanezumi/titlechecker_alpha.js'
+ '&action=raw&ctype=text/javascript&dontcountme=s"></script>');

*外装にMonobookを設定している場合 (ウィキペディアでは現在これが標準ですので、自分のオプションを変えていなければそうなっています)。「monobook.js」の「m」は小文字なので注意。

このページが編集されるかどうかについては未定です。いずれにしても、予想しない動作をしたりすることはありえます。不都合があったりして記事名チェッカalpha版を働かせなくしたいときは、上記の記述を削除すれば働かなくなります。 --Hatukanezumi 2007年6月2日 (土) 01:44 (UTC) 文意を変えずリンクを補足させていただきました--Happy B. 2007年6月2日 (土) 02:51 (UTC)[返信]

ユーザスクリプト空間へ移動しました。すでに上記の設定をしているかたは、monobook.jsの内容を上記のものに変更してくださるようお願いします。 --Hatukanezumi 2007年6月5日 (火) 09:53 (UTC)[返信]

alpha版に対する意見

[編集]
私の指摘したことが全く理解できていなかったようですね。誰もが編集できるスクリプトを任意の人に使わせるなど危険この上ありません。Tietew 2007年6月5日 (火) 02:23 (UTC)[返信]
まったく、困った方だなあ。
alpha版については、「予想外の動作をする可能性はあります」と断ったうえで、機能を有効にする方法だけでなく無効にする方法も説明しているのですよ。Common.jsであなたが行った編集行為とはちがって、この機能を働かせたいかそうでないかを、個々の利用者が選択できるんです。
だいたい、おっしゃるようなつっこみを入れるのなら、上でわたしが書いている「JSONオブジェクト(…)として読めるようになってる」(だから、自由に編集させてそのまま読み込もう) のほうでしょうが。
申し訳ないのですが、あなたのこの間の言動は (チェック機能を実働するコードとして実現した、という一点を除いて) 有意義な結果を生んでいないので、もう黙っていていただけませんか。 --Hatukanezumi 2007年6月5日 (火) 03:02 (UTC)[返信]
気づいてから無効にしては遅いのです。あなたはスクリプトの怖さを全く解っていない。JSONのほうも削除しておきますね。Tietew 2007年6月5日 (火) 03:36 (UTC)[返信]

alpha版の削除の差し戻しの提案ほか

[編集]

Tietewさんの行ったMediaWiki‐ノート:Common.js/alpha.jsの削除の差し戻しを提案します。

もともと、「ユーザスクリプト空間で十分なテストを行ってから供用すべき」との意見もでていたことから、Common.js での差し戻しのあともテストが可能な方策として、alpha.jsを作成したものです。また、利用にあったって予想外の結果を生むことがあること、利用は各利用者の自己決定の下に行われ、また任意に利用を中止できること、さらにそれぞれの方法についても説明しております。Tietewさんの行った削除処理は失当かつ不当なものと考えます。

さらに、User:Hatukanezumi/titlechecker alpha.jsonの削除に至っては、議論の参考資料(単独で動作するプログラムではない) を削除しており、議論の妨害であると考えます。速やかな復旧を要求します (こちらは提案ではありません)。 --Hatukanezumi 2007年6月5日 (火) 03:41 (UTC)[返信]

あなたは自分のアカウントが、またはあなたの泥縄勉強を信じた人のアカウントが、乗っ取られても良いと言うのですね。もう一度言います。気づいてからでは遅いのです。Tietew 2007年6月5日 (火) 03:53 (UTC)[返信]
それは曲解というものです。titlechecker alpha.jsonについてはただちに復元しなさい (「泥縄」は当然、謙遜が入ってますがね)。
だいたい、あなたが設計段階から十分な説明と意見聴取を行い、ほとんどのひとにとって満足のいくものを作り上げていれば、こんな手間をかける必要はなかったのです。しかたがないから、みんなで仕様確定、テスト、デバッグをしてあげようと言っているのです。あなたには感謝と謝罪の言葉を期待することはあっても、「わかっていないやつらだ」といった意味の非難を受けるいわれはありません。 --Hatukanezumi 2007年6月5日 (火) 04:03 (UTC)[返信]
中身についてはとやかく言うつもりはありませんが、スクリプトを会話用名前空間のサブページなんて危ない場所に置かないでください。なんで利用者サブページに置かないんですか？json にいたってはそれこそ MediaWiki名前空間にでも置かないと危なくて使えません。--端くれの錬金術師 2007年6月5日 (火) 04:38 (UTC)[返信]
ドキュメントが整備されていない以上、コードを見て動かせるようになってないと、とっても困ります。
利用者名前空間に置いてもスクリプトの存在は周知しなければならないんで、わかりやすい場所に置いても同じじゃないでしょうか。複数のコピーができるよりもましだし、安全でもあるでしょう。
それに、Tietewさんの主張にそった方法としては、単に保護することだってできるわけでしょ。
あと、JSONはプログラムじゃないです。読み込むコードを書かないと動かないです。そのうえ利用者名前空間にあったわけで、Tietewさんのやったことは二重に的外れです。
個人的には、自分の書いたコードを他人に使わせないという行動に出るような人は、相手にしてもしかたがないという感を強くしています。 --Hatukanezumi 2007年6月5日 (火) 04:56 (UTC)[返信]
JSONは立派なプログラムです。理解していないなら使わないでください。Tietew 2007年6月5日 (火) 04:57 (UTC)[返信]
根本的にずれてるな。どこに置いたってソースは見れるしリンクさえ貼っとけば存在の周知など容易いことです。問題なのは「会話用名前空間にあるスクリプトや利用者サブページにある json は誰でも改変可能だ」ということです。悪意ある改変をどうやって防ぐんですか？
たとえば A さんが alpha.js のソースを見て「これなら問題ない」と判断して自分のスクリプトに include したとします。A さんはまさか alpha.js が改悪されることがあるなど考えもしませんでした。ちょっと見た限りではそんなことどこにも書いてませんしね。ところが B さん（もともとの alpha.js を書いた誰かとは別）が alpha.js を改変して編集した項目すべてを白紙化するスクリプトに書き換えたとします（簡単ですよねこんなの）。それを知らない A さんはいつものように記事を編集しました。すると驚くことに編集したはずの記事は白紙化され、直そうとしても直せず、挙句の果てには「白紙化荒らしはやめてください」とブロックされてしまいました。
さてこのとき、責められるべきは誰でしょうか？まず悪意ある改変をした B さんは当然ですね。A さんはどうでしょうか？知らなかったとはいえ MediaWiki の仕様として誰でも改変できる場所にあったスクリプトを include してしまったことを責めるべきでしょうか？それよりは誰でも改変可能な場所であることを知った上でそんな危険な場所にスクリプトを置いた誰かのほうがよっぽど重大な責任を負うべきだと思いませんか？自分一人じゃできもしないのに「保護すりゃいい」なんて逃げの手打って責任回避したつもりにはならないでくださいね。--端くれの錬金術師 2007年6月5日 (火) 05:26 (UTC)[返信]
ふと思ったのですが、もしかして、MediaWikiでは、ユーザスクリプト空間に置いたものはユーザ自身しか編集できなかったりしますか? だとすれば、わたしは無知からうかつなことをしたとおもうので、お詫びします。 --Hatukanezumi 2007年6月5日 (火) 05:50 (UTC)[返信]
てっきりご存知なんだと思ってました。どこに説明があるか忘れましたが、仕様として利用者名前空間のサブページにあるスクリプト (*.js) およびスタイルシート (*.css) は当該利用者しか編集できません（管理者が編集可能かどうかはわかりませんが）。ためしに利用者:Hashikure/monobook.jsの編集を試してみてください。これは僕の利用者名変更に伴う跡地ですが、端くれの錬金術師名義では編集できません。Hashikure としてログインする必要があります。--端くれの錬金術師 2007年6月5日 (火) 07:11 (UTC)[返信]
alpha.jsの削除差し戻しの提案を撤回します。なお、titlechecker alpha.jsonについては、後に述べる方法での復元が可能ならお願いします。理由を述べます。
わたしは、クライアント側で実行されるコードが含まれたファイルを、だれでも改変可能な領域に置きました。すなわち、利用者が潜在的に蒙る危険に対して十分な安全措置をとっていませんでした。このことについて、皆様にお詫びいたします。
また、それに対してTietewさんが取った措置について十分な理解がないまま、数々の非礼な発言をしました。このことについてTietewさんに深くお詫びするとともに、一連の発言を撤回します。また、alpha.jsの削除差し戻しの提案は撤回します。
  • alpha.jsは、あらためてHatukanezumiのユーザスクリプト空間に設置します。
  • しかし、titlechecker alpha.jsonについては、ローカルに最新のバックアップがありません。したがって、復元した上で拡張子を.jsに変更 (移動) することが可能なのでしたら、そのように措置いただきたく、お願いいたします。
皆様には大変ご迷惑をおかけしました。とりわけTietewさんに対する非礼な発言について、重ねてお詫び申し上げます。無思慮によって彼がJAWPに必要な人材であるという見解を捨て去ってしまうところでした。 --Hatukanezumi 2007年6月5日 (火) 09:26 (UTC) バックアップなし。作り直しかな。--Hatukanezumi 2007年6月6日 (水) 03:47 (UTC)[返信]
Hatukanezumi 氏より titlechecker alpha.json の復帰および移動の希望が出ていますが、代替手段として内容を削除版より確認し Hatukanezumi 氏宛にメールにて送信しました。以上、報告のみ。--co.kyoto 2007年6月6日 (水) 06:10 (UTC)[返信]

記事名チェッカ: これからどうするか

[編集]

記事名チェッカの機能について、いったんの差し戻しはなされました。で、今後どのようにすすめていけばいいでしょうか。

とりあえず、課題となりそうな点を書き出してみました (適宜補足ください)。

  1. そもそも、クライアントサイドでの解決策は適切なのか (JavaScript実装の差異による不具合、JavaScriptが利用できない環境への考慮)。
  2. チェックの仕様と対象について。
    1. WP:NCとの関係をどう考えるか。
    2. チェック対象とする名前空間をどうするか (現在、記事名前空間以外でも対象になることがある)。
    3. 字種のチェックにふくめるもの/ふくめないものの決定が必要。
    4. 括弧とスペースに関するチェックのバグ (一部修正されたがまだ不適切な動作がある)。
    5. 記事ごとにチェックを無効化する手段の提供が必要ではないか。
  3. チェック結果について。
    1. 編集禁止対象に、即時削除タグを貼る以外のことができない問題 (例: タグを2つ貼ってしまっても直すことさえできない)。
    2. 編集禁止か警告にとどめるかの方針 (個別チェック項目、および全体について)。
    3. 警告文が適切な誘導になっていないこと。
    4. 警告文の文言やデザインについて合意がないこと。
  4. デバッグ体制。または、どのような状況になったらリリースしてよいのか。
  5. 文書化の必要性 (WP:NCとの関係や、適切な誘導を含むべき)。

--Hatukanezumi 2007年6月3日 (日) 11:52 (UTC)[返信]

とりあえず前半3つに関してコメント。
  1. いったん差し戻し(または導入自体には反対しないが拙速)ということで合意がなされた以上、できるだけ導入する方向で検討すべきだと思います。本来MediaWikiのBugzillaに投げてサーバ側にカスタマイズ可能なチェック機能を導入すべき事案だとは思いますが、それはクライアント側スクリプトの導入と並行して行えます。MediaWikiが更新された時点でクライアント側スクリプトは差し戻せば済みます。
    1. WP:NCと矛盾する動作を行うべきではありません。そういう動作はバグとみなすべきです。技術的制限などによりWP:NCに忠実なチェックが不可能であるなら、そのことを明言すべきです。
    2. 同様の理由から、記事名前空間以外のチェックは行うべきではありません。ただしWP:CSD#リダイレクトのほうでは「項目名」になっているので、この条項に従って記事名前空間以外での即時削除も実際に行われているなら、WP:CSD#リダイレクトに含まれ、かつリダイレクトであるものに限ってチェックを行ってもいいかもしれません(技術的な実現可能性はとりあえずおいておきます)。
--emk 2007年6月3日 (日) 17:57 (UTC)[返信]
議論に参加した以上、最後まで付き合う義務があるので、書いておきます。この件に関してぼくの意見はだいたい emk さんと同様で、やはり差し戻しの条件として実装そのものに反対ではないことがあり、その上チェックなしの状態では違反している記事名の氾濫で管理者に対して相当な負担がかかっているということからも最終的には(なるべく早めに)実装しなおすべきでしょう。ただし、やはりクライアントサイドの技術である JavaScript に依存しているのはすべての環境で同様の動作が保証されていない以上、憂慮すべき事態でもあります。なので、本当に最終的な理想はやはり MediaWiki 側でサーバサイドの記事名制限を可能にすることですね(実装されても管理者以上の権限が必要でしょうけど)。また、制限は具体的には通常の記事のみに限定すべきで、それ以外の名前空間及びリダイレクトには適用すべきではないでしょう。明らかに滑稽なリダイレクトはまずいですが利用者の利便性などの点から必要なリダイレクトもありますので、それらは作成可能である必要があります。まあ、機械的にそれを判断することは不可能なので何らかの方法により制限を解除する手段も実装すべきです(MediaWiki 側への要望になってしまいますがリダイレクト専用の Redirect 名前空間を実装して検索の際は Redirect 名前空間も対象にするとか)。まあ、警告だけでもある程度は効果あるとは思いますが。外部スクリプトで警告が見えないという人もいるようですができるかどうかは分かりませんができるならば上部ではなく投稿ボタンの近くに表示するようにすれば解決のような気も(こちらの方が見逃しにくいですし)。 --Mzm5zbC3 2007年6月3日 (日) 18:36 (UTC)[返信]
チェッカ自体は非常に有用であるので導入には反対していない。だが、再度導入するに当たっては、バグが発生し編集作業に支障が出ていることが確認された場合には即時対応・対応に時間がかかる場合には即時差し戻しを行なうことが絶対条件だと思っている（先日一時差し戻しに賛成したのは、Safari 1.x にて Common.js が原因と考えられるバグが発生し編集に支障を来たしているにもかかわらず一向に対策する気配が見えなかったからだ）。とりあえずは Safari 1.x 以前を弾く設定にさえしてくれれば再導入して構わないと俺は思う。今後 Safari 1.x にも記事名チェッカを導入する際には、井戸端告知などで事前に告知し「（発生が予想される症状を羅列した後）このようなバグが発生する可能性があります。発生した場合はxxxに報告してください」等と書く必要があるだろう。--ラッキースター・キッド ◆Luck.w.AEQ 2007年6月3日 (日) 22:06 (UTC)[返信]
えと。
  • 1. は課題整理の体裁を整えるために一応書いたようなもんで、わたしも現在のJavaScriptによる実装は生かすべきだと思ってます。
  • 2.1. について、どなたか、現在のチェック仕様とWP:NCの比較をしてまとめてくださるかたはいますか (けっこう大変かもしれないですし、だれもやらないならわたしやりますけど)。
  • 2.2. ですが、チェック対象を記事名前空間に限るかどうかについて、「限る」という意見が強いようですね。それでよいでしょうか?
    • 加えて、リダイレクトの扱いをどうするかということがあります。現在はWP:NCに合致しないものは即時削除、というのがコミュニティで合意された方針となっていると理解していますが、つぎのいずれかが考えられるとおもいます。
      1. 方針どおり即時削除へ誘導する (現在のように強制とするかどうかは別途考えるとして)。
      2. チェック対象からはずす。
ということで、とりあえず 2.2 まで。 --Hatukanezumi 2007年6月4日 (月) 03:47 (UTC)[返信]

ガイドライン等との関係の検討

[編集]
ざっと検討してみました。
  • まずチェッカで調べているのは、「1.1 全角と半角の使い分け」、「1.7 特殊記号の使用は慎重にすること」、「3.3 小説・詩・映画・舞台・音楽・絵画など芸術作品のタイトル」(一部)のみで、これ以外は機械的なチェックが困難なのでチェックの対象になっていないようです。少しでもコードが読めると常識過ぎて見落としがちですが、ちゃんと明記しておくべき事項だと思います。
  • チェッカは制御文字と不可視文字を問答無用に弾いていますが、実はWP:NCには明記されていないようです。まあ明記されていないからって制御文字や不可視文字を記事名に使っていいという合意があるとはさすがに思えませんが。
    一部の文字はペルシア語などの表記で必要なようですが、「1.3 日本語を使うこと」があるのでペルシア語の記事名が付けられなくてもいちおう問題にはならないでしょう(1.3で例示されているのはラテン文字のケースのみですが)。
  • ＃：＜＞［＼￥］｛｜｝あたりを使うとWP:NCを参照してほかの項目名を使えないか検討してくださいと出るようですが、WP:NCを見ても「使用には注意」と書いているだけで検討の材料としては不足してる気がします。
  • ＝は人名・地名の区切りとして使われているかどうか機械的に判断するのが困難なので、無条件にスルーしているようです。
  • ￦がスルーされている理由はよく分かりません。Shift_JIS(ベンダ拡張も含めて)で表せない文字はチェックの対象にしていないのかもしれませんが、\u3300-\u33F0は弾かれているようなのでそれも違うようです。
  • カッコの使い方は曖昧さ回避の場合を除いて合意がないにもかかわらず何か複雑なチェックをしているようですが、これはおそらくWP:CSD#リダイレクトを根拠としています。したがってリダイレクトの場合に限ってチェックしてもいいかもしれません。
  • 連続スペースをチェックしていますが、WP:NCでは曖昧さ回避のカッコ直前を除いて明記がないようです。
  • いわゆる機種依存文字の中では\u3300-\u33F0を弾いてローマ数字と丸付き数字を警告しているようです。これもWP:CSD#リダイレクトを根拠にしている気がします。WP:NCではJIS X 0208にない文字は人名のところでしか触れていませんし、しかも漢字のみです。おまけにそれはチェックされていないようです。#Unterschwelligen Problemeで触れたとおり、バランスの取れたチェックにはなりそうにないので漢字をチェックしないのはそれなりに妥当だとは思いますが。
  • 即時削除に誘導するならWP:CSD#リダイレクト違反のリダイレクトのみであるべきでしょう。通常の記事でも即時削除しか選べないというのは論外だと思います。
--emk 2007年6月4日 (月) 18:34 (UTC)[返信]
検討どうもです。
  • ガイドライン外のコード範囲のもの
    • ウォン記号「￦」の件: U+FFE0 - U+FFE7 はもともと、メインフレーム由来の全角通貨記号を分離したものだと聞いています。ですんで、この範囲は全部チェック対象にしたほうがいいでしょうね (ウォン記号を使いたいのなら半角の ₩ を使うべきでしょう。KOWPはそうみたいです[例])。
    • U+3300 - U+33F0 の CJK Compatibilityの件: ここだけをはじいている理由はよくわかりませんでした。丸付き英数字やローマ数字なんかをみると、はじきたい文字を含むブロック単位ではじいてるのかとおもいます。漢字Talk由来の縦書き用約物なんかもはじいたほうがよいわけですから、単にすべての presentation forms や compatibility forms のブロックをはじく、としたほうがいいようにおもいます (たぶんそれで問題ないよね?)。
以上、とりあえずのコメント。WP:NCとの関係について説明でクリアできる点については、別に節を設けて文案でも検討しましょうか。 --Hatukanezumi 2007年6月5日 (火) 10:28 (UTC) 誤読に基づく記述を削除 --Hatukanezumi 2007年6月7日 (木) 05:40 (UTC)[返信]
  • WP:CSD#リダイレクト関連のもの
    • 上記を読むと、リダイレクトの即時削除は「どこからもリンクされていないもの」かつ「項目名の書き誤りは除く」かつ「有用な履歴のないもの」に対して適用されることになっています。リダイレクトであるかどうかまではなんとか判定できるでしょうけれど、それ以外の条件を機械的に判定するのは不可能ですね。そういうわけで、リダイレクトの場合に限ってチェックするとしても、即時削除しか選べないというわけにはいきません。 --Hatukanezumi 2007年6月7日 (木) 09:49 (UTC)[返信]
  • 1.7 特殊記号の使用は慎重にすること関連のもの
    • # < > [ ] { } |。これらの半角記号を使おうとすると、#については期待しない動作、それ以外については[4]のようなエラーになります。ですのでむしろ、全角形を通さなければいけません。WP:NCで「使用には注意」との表現がありますが、これは[5]で加筆されて以来そのままのようです (注記: この差分では、現在よりも、システム上の制約から使えない文字が多いです)。記事名チェッカがガイドラインの特定の解釈を与えてしまうのは避けるべきですが、それでもここはおそらく「間違って半角記号を使用してしまうことには注意」という意味でしょう。
    • また、_ は記事名の中では半角空白と同一視されますが、これはチェックしようがありません (MediaWikiを通った時点で半角空白になってしまうため)。ただ、ガイドラインには全角下線を使ってよいという記述はないので、全角はチェック対象にするべきでしょう。
    • 実体参照、数値参照は、現在のalpha版でもチェック対象(禁止)です。 --Hatukanezumi 2007年6月7日 (木) 15:20 (UTC)[返信]
  • 1.6 使い方に注意すべき記号関連のもの
    • 「:」コロンは名前空間の区切りになりえますが、MediaWikiが名前空間の区切りかどうかを判定していますので、そうでない場合は通常の記事でも使えます。
    • 「:」「/」は「記事名と副題との区切り」に用いるべきではないとされていますが、これをチェックするのは不可能です。
    • 現在の仕様は全角の場合を、コロンについて警告、スラッシュについて禁止としていますが、むしろ1.1 全角と半角の使い分けにしたがって、両方とも全角は禁止とすべきなのではないでしょうか。 --Hatukanezumi 2007年6月8日 (金) 05:13 (UTC) コロンは記事名の先頭などで使えませんから、やはり警告にとどめるべきですね。中途半端だけど。 --Hatukanezumi 2007年6月10日 (日) 07:54 (UTC)[返信]
  • 3.3 小説・詩・映画・舞台・音楽・絵画など芸術作品のタイトル関連のもの
    • 「記事名自体に「」や『』は付けない」を調べているようですが、曖昧さ回避の括弧がある場合がチェックされていません (例: 『ひまわり』 (映画))。
    • 当然のことながら、邦題があるかどうかはもちろん、記事名が作品タイトルであるかどうかさえもチェックできません (芸術作品でなく、鈎括弧がある表記が正式な事物かもしれない)。したがって、警告にとどめるべきでしょう。
  • 円記号問題関連
    • ＼￥はいずれも「全角記号を含んでいます」という警告となりますが、1.1 全角と半角の使い分けにしたがって禁止とすべきなのではないでしょうか。
    • 半角の \ REVERSE SOLIDUS と ¥ YEN SIGN は環境によっては混同されます。しかし、ガイドラインでは全角を使うとはされていません (現実に問題になるのは、円記号に移動する前の￥記号くらいしかないと思われます)。 --Hatukanezumi 2007年6月10日 (日) 07:39 (UTC)[返信]

以上で、現行のチェックの仕様をひととおり検討できたとおもいます。これをうけて、どのような仕様にすべきかの提案を作成したいとおもいます。しばしお待ちを。 --Hatukanezumi 2007年6月10日 (日) 07:39 (UTC)[返信]

チェックを無効化する手段

[編集]

利用者ごとに無効化する手段と、記事ごとに無効化する手段が必要でしょう。

  • 利用者ごとの無効化については、適当なフラグ変数を定義して利用者のmonobook.jsに記述させる、でよいでしょう (title fix機能では、「disableRealTitle = 1;」と記述すれば無効になるようです)。
  • 記事ごとの無効化については、実現方法含めて要検討。「無効にできなくてよい」という意見もありえます。 --Hatukanezumi 2007年6月7日 (木) 05:55 (UTC)[返信]

バグ対応

[編集]

ラッキースター・キッド ◆Luck.w.AEQ 2007年6月3日 (日) 22:06 (UTC)への返答。[返信]

ラッキースター・キッドさんのおっしゃることはもっともですが、おそらく記事名チェッカ供用後も、即時の不具合修正というのは難しいと思われます。人手が足りないです。ですので、つぎのような方針でいかがでしょうか。

  1. 供用開始前に、(時間が許す範囲で) なるべく多くの環境でのテストを行っておく。
  2. 説明文書 (Help:項目名チェッカなど) に、テストした環境を明記する。
  3. 利用者からなんらかの不具合が報告され次第、管理者のだれかができるだけ速やかに記事名チェッカの機能を差し戻し、不具合が解消したことを確認してから復元する。この差し戻しには合意を要しないこととする。

1.、2. ですが、上記の#記事名チェッカalpha版がテストベッドとなるのかとおもいます。

「Hatukanezumiでは信用できない」って? 利用者パスワードはある程度の強度のあるものとしており、比較的安全な端末から定期的に変更します。

3. についてですが、この間、まったく編集ができなくなる不具合も報告されていたという経緯があります。したがって、記事名チェッカの稼動を持続させることよりも、不具合による被害を短期間、最小限に抑えることを優先するほうが、コミュニティの理解を得られやすいでしょう。また差し戻しであれば、コード内容に関する知識のない管理者でもかなり安全に実施できます。

以上で異論ないようでしたら、このようにすすめます。3. に関しては、管理者のかたがたの間で、体制づくりが可能かどうか協議してくださいますか>>当ノートを読んでいる管理者のかた。 --Hatukanezumi 2007年6月7日 (木) 09:05 (UTC)[返信]

管理者の皆さんに監視を要求するより、あらかじめバグ報告時の差し戻しに関しては合意を得ているということにして保護ページの編集依頼に出すのが現実的かと思います。MediaWiki名前空間のページは保護されているわけではないそうですが、"Technical restrictions" title fixの導入はここで依頼されて受理されましたから、「保護されていないからここでは受け付けない」などという屁理屈で却下されることはさすがにないでしょう。--emk 2007年6月7日 (木) 10:44 (UTC)[返信]
現実として即時対応というのは無理だろうから、即時差し戻しが妥当だろう。基本方針としてはHatukanezumi氏の意見に賛成する。
ところで、これらの意見（節#記事名チェッカ: これからどうするか内の意見）に関してそろそろTietew氏の意見が欲しいところなのだが、Tietew氏はどのようにお考えかな。「JavaScriptを書ける人」「MediaWiki名前空間を編集できる人」はそれぞれ何人も居るだろうが、日本語版では「JavaScriptを書けるMediaWiki名前空間を編集できる人」は実際問題としてTietew氏しか居ないのが現状。コードを英語版などからの輸入ではなく新規に書き換えるとなればそれはTietew氏による作業になると思うので、ここらではっきりと管理者Tietew氏の意見を聞いておきたい。--ラッキースター・キッド ◆Luck.w.AEQ 2007年6月7日 (木) 21:04 (UTC)[返信]

意見がつきませんね。では、差し戻しに関しては

  • 不具合があったら保護ページの編集依頼に差し戻しの依頼を出す。このことはあらかじめ合意されているとみなす。

ということでよろしいでしょうか。 --Hatukanezumi 2007年6月15日 (金) 16:21 (UTC)[返信]

仕様の確定

[編集]

#ガイドライン等との関係の検討の議論に基づいて、仕様書らしきものをつくってみました。議論しながら修正を加えていっていただきたいです。

MediaWiki‐ノート:Common.js/記事名チェッカ/仕様

文字種の検査について、Unicodeの全ブロックについて記載したので、長くなっています。ポイントと思われる点を挙げます (適宜補足ください)。

  • 概要:
    • 処理の根拠となる方針やガイドラインを明確にしました。
    • 即時削除しかできない場合を判定することは不可能だとわかったため、編集拒否の仕様はなくしました。拒否するのは、技術的な考慮から記事名を作成するべきでない場合と、MediaWikiの仕様によって拒否される場合のみです。ほかは警告だけです。
    • 機能の無効化について述べました。
  • 処理の内容
    • 標準名前空間のページのみを対象にすることとしました。
  • 書式の検査
    • どうも中途半端な検査になっているように思います。
  • 使用文字種の検査
    • 特殊なスペース、特殊なハイフン、制御文字や書式文字が含まれていれば編集を拒否します。それ以外は、警告にとどめます。Safariのバグ対応はあとで追記します。
    • 囲み英数字: 丸数字の扱いが中途半端かなあ。白丸数字以外も機種依存文字と言えば言える。
    • 和字間隔: ガイドラインに明記がないので警告もしません。
    • 漢字互換形、互換漢字とその他の互換文字: 全部機種依存文字扱いです。互換漢字だけ小細工してますが、バランスが悪いことに変わりはない。統合漢字は全部通します。
    • ハングル: ハングル互換字母も通してます。もしかするとハングル字母のほうだけ通すべきなのかもしれませんが、現在JAWPでは、単独のハングル字母を記事名とする場合はハングル互換字母を使っています。

寝よ。 --Hatukanezumi 2007年6月12日 (火) 17:43 (UTC)[返信]

検査内容

[編集]
とりあえずコメント。
  • 解決済み
    連続空白はMediaWikiの側で強制的に空白1つに置き換えているような気がします。なぜ記事名チェッカーがチェックしている(いた)のかよく分かりません。MediaWikiのバグで見落とす場合があり得るのでしょうか。--emk 2007年6月12日 (火) 23:17 (UTC)[返信]
    • うーん。SPACE、%20、+、_、%5F のいずれでやっても、ちゃんと空白ひとつに置き換えられますね。Bugzilla を見てもそれらしいreportはありませんでした。ここは、MediaWikiのチェックをあてにする、ということでいいような。 --Hatukanezumi 2007年6月14日 (木) 03:58 (UTC)[返信]
  • 解決済み
    ソフトハイフンを使っている場合ハイフンマイナスを使うように促されますが、この警告は適切でしょうか。もしドイツ語の記事名を付けようとしているなら、警告は「記事名には日本語を使ってください」のほうが適切です。--emk 2007年6月12日 (火) 23:17 (UTC)[返信]
  • 断定はできないので「もし」と書きました。少なくとも一律にハイフンマイナスに誘導すべきではないでしょう。文脈を推定するのは困難なので単に「使うべきではありません」でいいと思います。--emk 2007年6月13日 (水) 11:51 (UTC)[返信]
  • 解決済み
    取り下げ
    いわゆる全角空白についてはWP:NC#全角と半角の使い分けで「半角にあるものは半角を使用」と書かれています。和字間隔は欧文間隔の全角互換形ではないという主張なのかもしれませんが、そう解釈するとここで他の記号と並べて「スペース」が明記されている理由が分かりません。そもそもここを編集した人がそこまでの技術的厳密さを持って文案を練ったとも限りません。「半角を使用」と書いているのだからU+2000 EN QUADを使うべきだという曲解さえできるかもしれません。
    この部分は和字間隔の代わりに欧文間隔を使うと解釈するのが自然だと思います。--emk 2007年6月12日 (火) 23:17 (UTC)[返信]
  • 「WP:JPEに従う」と言いつつその直後に矛盾したことが書かれているのはWP:NCのバグのような気がします。もっともここはそれについて話す場ではありませんし、まして記事名チェッカーが特定の解釈を押し付けるべきでないのは確かなので、この件はいったん取り下げて気が向いたらWP:NCのノートにでも投げてみます。--emk 2007年6月13日 (水) 11:51 (UTC)[返信]
  • 解決済み
    利用者:𥝱というページが実在するように符号位置としてサロゲートがMediaWikiの仕様で拒否されてもBMP外文字の記事名は存在可能であって、JavaScriptで実装されている記事名チェッカーの入力に符号単位としてサロゲートペアが渡されることはあり得ます。--emk 2007年6月12日 (火) 23:17 (UTC)[返信]
    • そうですね。ここをMediaWikiに頼るのはやはりまずいので、入力チェックしましょう。あと、整型なUTF-8でないものが渡される可能性もあるんですが、どうやったらチェックできるのだろう。 --Hatukanezumi 2007年6月12日 (火) 23:52 (UTC)[返信]
  • BMPのチェック仕様を準用すると、3～13面は許可、14面以降は拒否でいいでしょうか。%C2%A1とか突っ込むとちゃんと弾いてくれるようなので、不正なUTF-8に関してはMediaWikiのチェックを当てにしていいと思います。JavaScriptではチェック不可能ですし。--emk 2007年6月13日 (水) 11:51 (UTC)[返信]
    • 追記しておきました。MediaWikiのチェックは、ためしたところ大丈夫みたいです。UTF-8でないシーケンス (たとえば 1%80 など) についてはわたしの勘違いで、ISO-8859-1 (のようなもの) とみなして処理してくれているようです。サロゲートの範囲がUTF-8エンコードされている場合にどうなるかは、後ほど確認してみます。
    • で、結局、BMP外もPUAも通っちゃうんですね (編集の場合だけでなく新規作成の場合も)。検査対象に含めましょう。--Hatukanezumi 2007年6月14日 (木) 03:58 (UTC)[返信]
  • 解決済み
    Combining Half Marksはなぜ許可しているのでしょうか。
--emk 2007年6月12日 (火) 23:17 (UTC)[返信]

追加のコメントです。

  • 解決済み
    Unicodeブロックをすべて列挙するのは仕様の検討段階では検討漏れがないか確認するのにいいかもしれませんが、最終仕様にそのまま含めても(ご自分でおっしゃっているように)長くなって要点が把握しにくくなると思います。また、現時点のUnicodeで未使用な符号位置に対してどういう動作をするのか明記されていません。「ここに書かれていない文字は許可する」のようにまとめられないでしょうか。--emk 2007年6月13日 (水) 11:51 (UTC)[返信]
  • そろそろこの節は終わりかな。
    囲み英数字、囲み漢字等ですが、白丸数字1-20だけを警告としており、とっても中途半端です。漢字Talk7のいわゆる「通産省外字」や、JIS X 0213で追加された文字なども含んでいますので、いっそ全部「機種依存文字」として警告にしてしまおうかとおもいます。根拠としてはつぎのものが挙げられるかとおもいます。
--Hatukanezumi 2007年6月16日 (土) 03:19 (UTC)[返信]
  • こまごまとした話。
    • 書式の検査ですが、alpha版では括弧の左右対称性のチェックが不十分です。括弧の中に括弧があるときにうまくいかない (キュリロス (スラヴの（亜）使徒)は偶然うまくいきます)。入れ子になった括弧をまじめに検査するのは大変なので、「最低限、2重の入れ子まではチェックする」、ということにしたいとおもいます。
    • また、上のチェックでは同時に、開き括弧に対応する閉じ括弧がない場合をチェックしていますが、閉じ括弧に対応する開き括弧がない場合をチェックしていません (ほかの書式の検査もそうですが、alpha版ではどうも、記事名を左から右へサーチしていって矛盾が生じる場合しか想定していないようです) 。括弧が片方しかない場合の検査をすべきなのかどうかガイドライン等から明確に読み取れませんでしたので、この検査はしないことにしたいとおもいます。
    • 半角丸括弧の前にスペースがあるかどうかの検査ですが、やはりalpha版では、開き丸括弧の直前にほかの開き括弧がある場合もチェック対象となります。この点についてガイドライン等には明確な記述はありませんが、括弧の間にスペースを入れるのは常識的におかしいので、開き丸括弧の直前にほかの開き括弧がある場合は警告しないようにしたいとおもいます。 --Hatukanezumi 2007年6月18日 (月) 08:30 (UTC)[返信]

機能の無効化

[編集]
  • 解決済み
    機能の無効化ですが、記事ごとの無効化の方式がきまっていません。「記事本文中に特定のタグがあれば無効」という方法になるとおもいますが、これだと、節単位編集のときにきかなくなります。うまいアイディアはないものでしょうか。 --Hatukanezumi 2007年6月14日 (木) 22:15 (UTC)[返信]
    • 機能を無効化しなければならない記事の数が少なければ、Common.js側に除外リストを作ればいいのかなと思うのですが。素人考えですみません。--Happy B. 2007年6月16日 (土) 03:55 (UTC)[返信]
      • あ、そうか。なにも、なんでもプログラム的に解決しなければならないわけではないですね。少なければ除外リストを用意しておけばいい。
      実際のところ、無効化が必要な記事にどんなものがあるのか、わたしも思いつきません。また、現在行っている仕様の確定の過程で、機能を無効化したいという要求は激減しているのではないかとおもいます。以前とくらべると (ちょっと語弊がありますが)「理不尽に編集を禁止されている」という印象を抱かせる場面は減っているとおもわれるので。
      具体的に「このようなものは無効化しなければならない」という指摘がでてきて、それがかなり多いのであれば、プログラム的な対策を検討する必要があるかとおもいます。そうでなければ、Happy B.さんの意見のように除外リスト (それも最初は空) をCommon.jsに用意しておくだけでよいとおもいます。 --Hatukanezumi 2007年6月16日 (土) 10:10 (UTC)[返信]

記事名チェッカ 説明文の体裁

[編集]

上ではマニアックな会話がつづいていますが、記事名チェッカで警告を出すときの説明文の体裁を決めたいとおもいます。これを決めるについては、文字コードだとかプログラムだとかに詳しくないひとの提案や意見のほうが重要です。

とりあえず、現状を元にした案をつくってみました。ほかの案や、修正の意見をお願いします。ある程度でたところで、投票かなんかで決定すればいいとおもいます (恐れ入りますが、Swindさんが上で出していらっしゃった案は、あらためて出してください)。 --Hatukanezumi 2007年6月15日 (金) 16:15 (UTC)[返信]

体裁案

[編集]

必ず入れなければならないのは、

  1. 警告や拒否をするときの「説明文」と、それぞれの警告の根拠となる「ガイドラインなどへのリンク」。これらはチェックの結果によって変わりますし、複数になることもあります。入れる場所を決めてください。
  2. 記事名チェッカのヘルプ (いまのところHelp:項目名チェッカ) へのリンク。

です。また、リダイレクトである場合は、別途リダイレクトの即時削除についての説明が追加されます。

それ以外の箇所の文章は、わかりやすくなるよう工夫すればいいとおもいます。

(A) 現状を元にした案

[編集]

新規ページ作成時

このページの項目名は次にあげる理由により、記事名の付け方に違反している可能性があります。このページを作成する前に、以下の説明を再度確認し、ほかの項目名を採用できないか検討してください。

項目名を変更する場合は、このページのリンク元を参照して、リンクを差し替えていただきますようお願いします。記事名チェック機能の詳細は、Help:項目名チェッカをご覧ください。

既存ページ編集時

上記の

このページを作成する前に、以下の説明を再度確認し、ほかの項目名を採用できないか検討してください。

が

記事名の付け方に違反している場合は、移動することを検討してください。

に変わります。 --Hatukanezumi 2007年6月15日 (金) 16:15 (UTC)[返信]

(B) ほかの警告とそろえる案

[編集]

警告: このページの記事名の付け方は、当ウィキペディアのガイドラインなどにそっていないかもしれません。理由は以下のとおりです。

ガイドラインにそっていないときは、記事名の変更を検討してみてください。なお、記事名を変更したときは、このページのリンク元を調べて、新しい記事へのリンクに変更するようにしてください。

記事名チェック機能の詳細は、Help:項目名チェッカをご覧ください。

囲み枠は実際にはつけません。体裁は、ページサイズの警告など、編集時に記事本文の上に表示される警告とそろえてあります。 --Hatukanezumi 2007年6月16日 (土) 07:39 (UTC)[返信]


コメント

[編集]
  • やっぱり、実際に動いているものを見て考えたほうがいいでしょうか。あと2、3日待ってもあまりコメントがつかないようでしたら、デバッグをはじめてしまって、その中で説明文の体裁についても決めていきたいとおもいます (説明文の体裁を除いては、仕様にそったコードはほぼできつつあるので)。 --Hatukanezumi 2007年6月18日 (月) 03:54 (UTC) 修正。下記参照 --Hatukanezumi 2007年6月19日 (火) 03:02 (UTC)[返信]
  • 「ご意見はこちらへ」というように、意見がある方をこの会話ページなどの適切な場所へ誘導する記述があるべきだと思います。また、「チェックが無効となる記事の一覧」への誘導も行うべきでしょう。--micro 2007年6月21日(木) 01:17 (JST)
    • 質問なのですが、「チェックが無効となる記事の一覧」というのは、具体的にはどういったものでしょうか。--Hatukanezumi 2007年6月20日 (水) 23:50 (UTC)[返信]
      • 変な表現で失礼しました。「除外リスト」を指しています。--micro 2007年6月21日(木) 18:26 (JST)
        • 除外リストにどういうものを入れるかの方針は別途議論したほうがいいとおもうので、「一覧」に関する誘導はそれをきめてからにしたほうがいいかな、とおもっています。とりあえず意見やバグ報告は、このノートに誘導することでどうでしょう (サブページを切ったほうがいいとおもいますが)。 --Hatukanezumi 2007年6月21日 (木) 13:37 (UTC)[返信]

記事名チェッカのデバッグ

[編集]

デバッグの日程を提案しておきます。

デバッグ期間
2007-06-23 00:00 (UTC) から、
バグが最後に修正された後 7日間後まで。
  1. beta版は今週なかばにはアナウンスします。それから上記のデバッグ期間開始までは、コードの目視と仕様の確認に基づく不具合修正とします。この期間中は、仕様の修正がありえるものとします。
  2. 上記デバッグ期間にはいったら、仕様は凍結し、説明文の体裁の変更を除いて変更は行いません。beta版のコードを実際に実行して、仕様どおりの動作をするかのテストをしていただきます。
  3. デバッグ期間中に発見されたバグは修正します。7日間以上バグが発見されなかったら、正式公開とします。
  4. 以上の日程に並行して、ヘルプの編集を行う必要があります。

したがって、正式公開は最短で2007-06-30 00:00 (UTC) となります。

以上で特に異論なければ、そのようにすすめます。 --Hatukanezumi 2007年6月18日 (月) 14:27 (UTC)[返信]

デバッグ期間中にWP:NCやWP:JPEが変更されたらどうしましょうか。現在Wikipedia‐ノート:表記ガイド#和字間隔の使用についてを提案していてモロに影響します。--emk 2007年6月18日 (月) 20:48 (UTC)[返信]
うーん、それは「バグ」ではないですね。仕様が前提にしている「世界」が変わってしまうのだから。
デバッグ期間中にガイドライン等が変更された場合は、仕様の変更を議論して必要なら変更し、上の「7日間」にその議論にかかった日数分を加算する、ということでどうでしょうか。 --Hatukanezumi 2007年6月19日 (火) 03:07 (UTC)[返信]

記事名チェッカbeta版

[編集]

以下をbeta版とします。

記事名チェッカbeta版
User:Hatukanezumi/titlechecker_beta.js
記事名チェッカ仕様書
MediaWiki‐ノート:Common.js/記事名チェッカ/仕様

まずは、コードを読めるかたが、コードの目視によって、実行しても問題はなさそうか、仕様のとおりでないことや仕様に書いてないことをやっていそうにないか、を確認していただくようお願いします。それから、動作させてのデバッグに移りたいとおもいます。 --Hatukanezumi 2007年6月19日 (火) 20:27 (UTC)[返信]

  • 解決済み
    新しく追加したチェックがSafari/1.xを除外していませんが、Safari/1.xで問題ないことが確認できない限り拒否系のチェックはすべて除外すべきだと思います。速やかな差し戻しが実際に行われるのか大いに疑問なので。--emk 2007年6月20日 (水) 11:07 (UTC)[返信]
    • 補足特殊用途面の文字、ソフトハイフン、私用領域の文字、の3種ですね。デバッグの際は、当然だれかが Safari 1.x でのテストを行ってくれるとおもってるんですが…。見込みがないのなら、安全策で除外したほうがいいでしょう。 --Hatukanezumi 2007年6月20日 (水) 12:11 (UTC)[返信]
  • 解決済み
    WP:CSD#リダイレクトには確かに左丸括弧とは明記されていませんが、だからといって「括弧の種類を問わず」と解釈するのは無理があると思います。左右対称のチェックは丸括弧しか調べていないこととも整合しません。どうしても「括弧の種類を問わず」と解釈するなら(私は反対ですが)、せめて解釈は統一してください。--emk 2007年6月20日 (水) 11:07 (UTC)[返信]
    • もしかしてわたし、なにか間違えてます? 基本は、「半角の左括弧」つまり半角丸括弧の直前に、半角スペースがあるかどうかを検査しています。が、半角スペースのかわりに開き括弧 (種類を問わず) がある場合も通す、ということです。たとえば、【(...)】に対して「【 (...)】 にしなければならない」という意味の警告がでるのはおかしいですから。 --Hatukanezumi 2007年6月20日 (水) 12:11 (UTC)[返信]
  • 解決済み
    リダイレクトに関するメッセージは、記事にリダイレクトの可能性があるときだけ表示するようにできないでしょうか。
document.getElementById('wgTextbox1').match(/^#redirect/i)
みたいな。--emk 2007年6月20日 (水) 11:07 (UTC)[返信]
  • 記事名チェッカの動作には影響ないことですが、記事名チェッカで警告されないことがガイドライン等への準拠を保証するわけではないので、その旨「処理の前提と制限」の節に加筆します。 --Hatukanezumi 2007年6月21日 (木) 03:28 (UTC)[返信]
  • 解決済み
    いわゆる「不可視文字」ですが、Firefoxでは、ソース中の文字列定数にこれらの文字が含まれていても無視するようです (「技術的な考慮」で「制御文字」にしているもののほとんどがそう)。たとえば[http://ja-two.iwiki.icu/w/index.php?title=%E2%80%8C&action=edit] (ZWNJ) などとすると、FirefoxのJavaScriptではこの文字を認識できないのにMediaWikiでは認識できるので、警告もでずにページが作れてしまいます。
    MediaWikiで対策をするしかないとおもいますが、どうしたもんでしょう。 --Hatukanezumi 2007年6月21日 (木) 15:32 (UTC)[返信]
    • ゆうべ寝ながら対策を考えた[8]ですが、強い反対があればこの件はあきらめます。 --Hatukanezumi 2007年6月22日 (金) 03:54 (UTC)[返信]
      • Bugzilla@Mozilla Bug 274152ですね。Firefox 3から修正されます。Gecko 1.9以前のGeckoエンジンブラウザはすべて同様のバグを抱えているはずです。基本的にはwgTitleにフォーマット文字を入れるときUnicodeエスケープしてくれるようMediaWiki側で対応してもらうしかないと思います。それまで処理の前提と制限あたりに特定のソフトウェア環境での制限事項として追加するのはいかがでしょうか。ECMA-262 Edition 3に従おうとした結果を特定のソフトウェア環境の問題と言っていいものかどうか微妙ですが。--emk 2007年6月22日 (金) 11:54 (UTC)[返信]
        • ちょっと考えすぎになっていました。MediaWikiのほうでエスケープするようになれば、すむ話ではあります。format characterの検査は環境によってはできない旨書いときましょう。あと、Safari 1.x は「技術的な考慮 (拒否)」の検査はすべてしないことにしときましょう。 --Hatukanezumi 2007年6月22日 (金) 16:04 (UTC)[返信]
  • 「#」以降は無視されるので数値文字参照のチェックは無意味です。もうデバッグ期間に入っているし実害はなさそうなので修正は不要ですが、報告だけしておきます。--emk 2007年6月23日 (土) 02:41 (UTC)[返信]

バグ報告と対処

[編集]

デパッグ期間に入りたいと思います。

MediaWiki‐ノート:Common.js/記事名チェッカ/バグ報告を作成しました。バグの報告と、それへの対処報告は、左記のページで行ってください。 --Hatukanezumi 2007年6月22日 (金) 23:53 (UTC)[返信]

確定後の仕様変更

[編集]
  • 解決済み
    WP:JPE#波ダッシュで、波ダッシュと全角チルダについてのガイドラインが加筆されています。全角チルダについての警告文を以下のようにしたいとおもいます (プログラムの動作に影響を与える変更ではありませんので、特に議論がなければ、上で述べているデバッグ日数の加算は行いません)。
    全角チルダを含んでいます。この文字は、一部の環境で正しく表示されません。波ダッシュ (〜) か、できればハイフンマイナス (-) を使ってください。詳しくは、Wikipedia:表記ガイド#波ダッシュを参照してください。
--Hatukanezumi 2007年6月23日 (土) 01:27 (UTC)[返信]
  • メッセージを「曖昧さ回避の括弧である場合は、括弧の前に半角スペースを入れてください」のように変更したほうがリーズナブルではないでしょうか。--emk 2007年6月24日 (日) 12:42 (UTC)[返信]
    • WP:CSD#リダイレクトでの記述は、(A)曖昧さ回避の括弧についての記述、(B)半角括弧すべてについての記述、のふたつが混合しているようにおもいます(*)。検査の対象を記事名の末尾のみに限ったうえで、「曖昧さ回避の括弧である場合は、」を説明文に追加する、ということでどうでしょうか。酸化鉛(II)のようなものの数がそれほど多くなければ、将来除外リストに入れることを検討すればよいとおもいます。
      (*)初期は(B)で、全角の使用や前後のアキについての議論があったため(A)が加えられたが、結局、現時点まで全角と半角を使い分ける (もしくは半角のみにする) ことに明確な合意が形成されていないために、どっちつかずの表現になっているんじゃないかと。 (Wikipedia‐ノート:記事名の付け方/過去ログ4#正式名称に丸カッコを含む場合の議論を参照。 --Hatukanezumi 2007年6月25日 (月) 04:29 (UTC)[返信]
  • あるいは、「括弧の前に半角スペースを入れてください。ただし塩化銅(I)のように名称自体に括弧を含んでいる場合はこの限りではありません。」などという表現もありですね。--朝彦 2007年6月26日 (火) 09:42 (UTC)[返信]
    • ほとんど余談ですが。
      「曖昧さ回避の括弧とまぎれないように」ということで括弧の前後を空けないという考えかたもあるようですね。しかし、曖昧さ回避の括弧の前にスペースが必要なのはパイプの裏技のためだけなので、曖昧さ回避でないものには裏技を使わなければよいだけのことではないか、とも感じます。個人的には、半角括弧の前後は基本的に空けるべきだという考えをもっているんですが、そうしてよいとも悪いともガイドライン等には明記がないようにおもいます。
      いっぽうで、殺菌剤 (農薬その他)に対する殺菌剤 (農薬その他)の一覧のように、「曖昧さ回避の括弧についてのシステムの要求事項が、記事名の付け方全般に適用される」という誤解によるものとみられるものも生じています。ですんで、ここの説明は、「曖昧さ回避の括弧の場合は前を空ける」と限定したほうがいいかな、とおもっています。
      ということで、つぎのようでどうでしょうか。
      曖昧さ回避の括弧である場合は、括弧の前に半角スペースを入れてください。名称自体に括弧を含んでいる場合はこの限りではありません。
      --Hatukanezumi 2007年6月26日 (火) 11:32 (UTC)[返信]
    • 特に異論ないようですので、仕様を変更します。なお、説明文だけでなく動作も変わりますので、デバッグ期間に日数を加算します。 --Hatukanezumi 2007年6月28日 (木) 13:30 (UTC)[返信]
    • Wikipedia‐ノート:記事名の付け方/正式名称に丸カッコを含む場合で提示されているのですが、カッコ内に全角文字を含むときは全角カッコを用いるべきだと思います。こんな例はめったにない（というかこれ以外に見たことがない）のですが、たとえば[10]という記事も必要になると思いますし。--micro 2007年6月28日(木) 23:03 (JST)
      • なるほど。ドラえもん（大山のぶ代版テレビアニメ）が作品の正式名称だということですね (しかし、主演声優の名前を冠したのが正式名称というのはどうも…まあいいや)。
        記事名チェッカの動作については、基本的に、既存のガイドラインや方針文書にないことはしない、ということがこの場の合意となっているとおもいます。括弧の全角半角の使い分けについては、明確な合意がないようにおもわれるので、「こういう場合は全角を使う」「半角を使う」というような説明文を表示する動作はしていません。どちらが使われていても警告せず通しています。
        逆に言うと、ガイドラインや方針文書が変わったら、記事名チェッカの動作もそれにあわせて変えなければなりません。括弧の全角と半角の使い分けについては、上で挙げておられるガイドラインのノートで議論してみていただけないでしょうか。 --Hatukanezumi 2007年6月28日 (木) 15:00 (UTC)[返信]
  • バグ報告のDEAR My SUN!!～ムスコ★育成★狂騒曲～の件ですが、WP:JPE#波ダッシュで全角チルダを含むリダイレクトを「作ることを強く推奨」(新規記事の場合) および「当面の間存続」(既存記事を移動した場合) としています。現状の仕様だと、全角チルダを含むリダイレクトを残すぺきだという趣旨が利用者に伝わらず、単に移動とリダイレクト削除が行われる可能性があります。したがって、つぎのように仕様を変更し、動作も変更します。
    全角チルダの検査は、記事がリダイレクトでない場合のみ行う。 --Hatukanezumi 2007年6月29日 (金) 03:24 (UTC)[返信]
    • 動作修正を確認しました。新規作成の場合の対策として「波ダッシュ (〜) か、できればハイフンマイナス (-) を使ってください。波ダッシュを使った記事名へのリダイレクトを作成しようとしている場合は、この限りではありません。」とメッセージを変更するのはどうでしょうか。--emk 2007年6月29日 (金) 11:37 (UTC)[返信]

ヘルプ

[編集]

MediaWiki‐ノート:Common.js/Help:項目名チェッカ (案)を書き直しました。いちおう仕様にそった内容にしましたが、あまり専門的なことは省きました。加筆、訂正をお願いします。

項目名ですが、Help:記事名のチェックではどうでしょうか (記事名チェッカで実現される機能だけでなく、MediaWikiの仕様によるチェックも含んでいますので)。 --Hatukanezumi 2007年6月24日 (日) 02:17 (UTC)[返信]

とりあえず、リダイレクトを作成しました。現在の「(案)」を最終的にここへ移動します。 --Hatukanezumi 2007年6月29日 (金) 03:46 (UTC)[返信]

Safari 1.xのバグ

[編集]

/バグ報告にプログラム的なことを書いていいものかどうか判断が付かなかったのでこっちに書きます。

Safari 1.xでは、正規表現の文字クラス中で\u0100以上のUnicodeEscapeを使うとクラッシュすることがあるようです。このバグはSafari 2.0.2で修正されました[11]。

--emk 2007年6月25日 (月) 13:30 (UTC)[返信]

これはちがうような気がします。すくなくともbeta版では、unicode escapeを正規表現中に直接書いていないので。これかもしれません (ちょっとちがうような気もするが)。
いずれにしても、これだけ不安定だと、Safari の 1.x2.0.1 (Webkit 412.7) 以前では記事名チェックの機能そのものを無効にしたほうがいいのかもしれません。まいったな。 --Hatukanezumi 2007年6月25日 (月) 15:25 (UTC) 勘違い修正 --Hatukanezumi 2007年6月25日 (月) 15:36 (UTC)[返信]

いろいろ小細工を考えたけど筋が悪いので、Safari 2.0.1 以前 (AppleWebkit 416.x より前の実装) では、U+0100以降の文字種のチェックをやめるよう、仕様を変更します。 --Hatukanezumi 2007年6月26日 (火) 08:10 (UTC)[返信]

文字参照（実体参照、数値参照）のチェックについて

[編集]

何をチェックしているか自分自身の整理のために確認させてください。

  1. [[あああ&hearts;]]という記事名を作ろうとしてあああ♥という記事名になることを避けるため、[[あああ&hearts;]]を抑止する
  2. あああ♥という記事名を作ろうとして誤って[[あああ&hearts;]]と作るのを抑止する

1,2とも結果としてチェックする部分は一緒だと思うのですけれども、記事名のつけ方から察すると仕様としては1を想定してチェックしていると考えてよいでしょうか。また、2の方はあああ♥が記事名として有効だとしてもあああ♥は記事名と使用できないと誤認識（実際に自分も勘違いしてましたが）する可能性が懸念されます（桃色片想い等）が、これは記事名チェッカより記事名のつけ方の説明の問題と考えてよいでしょうか。--Mikipedia 2007年6月28日 (木) 16:30 (UTC)[返信]

「WP:NC#特殊記号の使用は慎重に」の現在の版で、だいぶ理由が明確になっているとおもいます。6/26の改訂 (「実体参照」の段落を参照) がある前は、わたしもこれが書かれている理由がはっきりわからなかったのでした。
1.、2. のどちらの意図であるかにかかわらず、記事名に実体参照を含めると期待しない動作をすることがあるので、記事名に実体参照を含めるべきではない、ということではないでしょうか。 --Hatukanezumi 2007年6月29日 (金) 11:23 (UTC)[返信]
返答ありがとうございました。とりあえず、自分の中で整理・理解ができました。--Mikipedia 2007年6月29日 (金) 13:36 (UTC)[返信]
いずれにしても、♥はある種の機種依存文字と言えますから、記事名には使わないほうがいいでしょうね。 --Hatukanezumi 2007年6月30日 (土) 03:24 (UTC)[返信]

サブページ化

[編集]

記事名チェッカについての議論がノートの大半を占めてしまっていますので、これまでの議論をMediaWiki‐ノート:Common.js/記事名チェッカに移動して、そちらを常設の場所としたいとおもいます。関連ページとして、つぎのものがあります。

1週間ほどして特に異論なければ、今後の投稿もふくめて記事名チェッカ関連の発言の移動を実施します。 --Hatukanezumi 2007年6月30日 (土) 04:08 (UTC)[返信]

記事名チェッカ 1.0版のリリースについて

[編集]

現在の状況ですと、本日2007-07-06 の 12:38 (UTC) でデバッグ期間は終了し、記事名チェッカ 1.0版をリリースできる見込みです。

  • 重要 Special:MyPage/monobook.js に記事名チェッカbeta版の記述をしておられるかたは、除去しておいてください。リリース版とbeta版の両方が読み込まれると、不具合が発生するかもしれません。
  • リリースは、WP:AN#保護ページの編集依頼に、MediaWiki:Common.jsへ記事名チェッカを追記するよう依頼することで、行います。追記された時点で、記事名チェッカはすべての利用者 (JavaScriptを有効にしている利用者) に働くようになります。

以上、よろしくです。 --Hatukanezumi 2007年7月6日 (金) 03:49 (UTC)[返信]

WP:AN#保護ページの編集依頼に作業を依頼しておきました。 --Hatukanezumi 2007年7月6日 (金) 13:06 (UTC)[返信]

追加しましたので、ご確認ください。--co.kyoto 2007年7月8日 (日) 04:47 (UTC)[返信]
確認しました。問題なく動作しているようです。どうもありがとうございましたm(_ _)m。 --Hatukanezumi 2007年7月8日 (日) 05:13 (UTC)[返信]

1.0版のまとめなど

[編集]

記事名チェッカ1.0版はリリースされました。ご意見、ご協力いただいた皆さん、お疲れさまでした。

で、これまでの議論の過程でいくつか課題もでてきているとおもいます。気づいた点などあればお書きください。また、感想などもあればどうぞ。 --Hatukanezumi 2007年7月8日 (日) 05:40 (UTC)[返信]

井戸端でこんな話が出ていました。alpha版なみに目立たせるのはやり過ぎにしても、今の警告はさりげなさ過ぎるかもしれません。--emk 2007年7月9日 (月) 19:54 (UTC)[返信]
うーむ。気がつかないですか。1.1版 (あるのか?) で変えましょうか。
ついでに、Help修正ありがとうございました。betaテスト時にやったことをそのまま書いていました。 --Hatukanezumi 2007年7月10日 (火) 03:42 (UTC)[返信]
今は削除済みで履歴が確認できませんが、問題の記事の初版は7月5日で、1.0リリース前だったようです。--Happy B. 2007年7月10日 (火) 04:25 (UTC)[返信]

記事名チェッカの警告が理由と思われる記事名の変更が見られるようになってきましたが、半角チルダ (~) に改名していたり[12]、固有名詞に使われているケースでハイフンマイナス (-) に改名していたり[13]、移動の残骸が即時削除に出されたり[14][15]と、必ずしもガイドラインの趣旨に沿った行動に誘導されていないようです。--emk 2007年7月12日 (木) 12:25 (UTC)[返信]

波ダッシュの入力方法がわからないのでほかのもので代替しているのでしょうかね (チルダに置き換えるというのは予想外でした)。編集画面下部の「記号」にも入っているのですが。 --Hatukanezumi 2007年7月13日 (金) 05:12 (UTC)[返信]
半角チルダに置き換えるのは私も予想外でしたが、WP:NC#全角と半角の使い分けだけ見ていると確かにそういう解釈もできそうだったので明確化してみました。--emk 2007年7月13日 (金) 19:47 (UTC)[返信]

特異事例?

[編集]

備忘。

1.0版の作業当時から気になっていたんですが、\(^o^)/チエはどうするのがいいんでしょうかね。現在はこの記事名で{{統合文字}}が貼られています[16]。が、散発的に＼(^o^)／チエへの移動が行われたりします。当否は別にして、そうしたくなる気持ちはわからなくもないので、もしも当該記事やWP:NCのノートで後者の記事名でよいという合意が得られたなら、除外リストへ登録して警告を出さないようにすることになるとおもいます。 --Hatukanezumi 2007年12月7日 (金) 04:25 (UTC)[返信]

BMP外の文字が記事名に使われた場合

[編集]

文字コードに関しては相変わらず素人ですので的はずれな指摘でしたらすみません。比較的最近のWP:NCの改訂で、BMP外の文字は使わないようにという方針がWP:NC#システム上の使用可能文字の制限に示されましたが、このチェックは現行のチェッカでされていますでしょうか。もしされていなければ追加が望ましいと思います。--Happy B. 2008年2月2日 (土) 08:30 (UTC)[返信]

現状では1〜13面の文字はほぼ素通しです。チェックを追加した方がいいですね。--emk 2008年2月2日 (土) 09:14 (UTC)[返信]
ありがとうございます。システムの復旧に影響を与えるそうなので、警告よりも抑制の方がよさそうですね。--Happy B. 2008年2月2日 (土) 15:58 (UTC)[返信]
Title blacklist機能が導入されたので、JavaScript版記事名チェッカからの移行と合わせて検査の対象に追加することをMediaWiki‐ノート:Titleblacklistで提案しました。--emk 2008年3月11日 (火) 12:04 (UTC)[返信]

改修およびサブページ分離の予告

[編集]

記事名チェッカーの作成から10年が経過しており、今となっては見通しが悪く保守しづらいコードになってしまっているので、近々改修したものに差し替える予定です。また、テスト項目の記述が多いためCommon.js内全体でも見通しを悪くする原因となっているため、MediaWiki:Common.js/titleChecker.jsに分離して本体から読み込む形式に変更する予定でいます。

作業は現在利用者:Cpro/TitleChecker.jsで行っています。何か問題があればお知らせください。--cpro（会話） 2017年11月7日 (火) 06:51 (UTC)[返信]

報告 MediaWiki:Common.js/titleChecker.jsにサブモジュール化しました。また、disableTitleCheckerによる機能無効化はだいぶ前から使えなくなっていましたので、この機会に廃止しています（MediaWiki‐ノート:Common.js#ユーザースクリプトによる無効化オプションが使えない参照）。--cpro（会話） 2017年11月15日 (水) 06:15 (UTC)[返信]

カギカッコについて

[編集]

メッセージの中に、「鉤括弧（カギカッコ）」の他に「鈎括弧（カギカッコ）」というあまり使われない字が混在していますのでお知らせします。個人的にはカタカナかひらがなで「カギカッコ」のほうが読みやすいんじゃないかとも思っています。--Foomin10（会話） 2018年1月12日 (金) 14:52 (UTC)[返信]

Titleblacklistに移行済みのものの除去

[編集]

「技術的な考慮 (拒否)」に含まれている下記の9件はMediaWiki:Titleblacklistに移行済みのため、記事名チェッカからの除去を提案します。

  • 制御文字を含んでいます
  • ノーブレークスペースを含んでいます
  • ソフトハイフンを含んでいます
  • 特別な幅のスペースを含んでいます
  • 書式制御文字を含んでいます（2種類）
  • 特別な幅のノーブレークスペースを含んでいます
  • 私用文字を含んでいます
  • 不可視な文字を含んでいます

特に問題がなければ、1週間後に編集します。--ネイ（会話） 2020年4月25日 (土) 08:33 (UTC)[返信]

記事名チェッカで拒否しているものをTitleblacklistに移行する提案

[編集]

具体的には「文字でないものを含んでいます」の1件をMediaWiki:Titleblacklistに移行することであり、移行による影響は「JavaScriptが無効になっているブラウザでも拒否されるようになる」となります。--ネイ（会話） 2020年6月4日 (木) 03:36 (UTC)[返信]

  • 移行しようとしたとき、\x{DFFE}または\x{DFFF}を含む正規表現がTitleblacklist拡張機能で拒否されました。こちらでその正規表現が一致するページ名で記事を作成しようとしても失敗しているので、おそらくは不要の検査ではないかと思います。つきまして、記事名チェッカから除去することにしました。--ネイ（会話） 2020年6月18日 (木) 10:35 (UTC)[返信]

「その他のガイドライン等 (警告)」に含まれる検査の一部をTitleblacklistに移行する提案

[編集]

題名通りの提案をMediaWiki‐ノート:Titleblacklist#titleCheckerに含まれる検査の一部をTitleblacklistに移行する提案にて提起したことをお知らせいたします。--ネイ（会話） 2021年4月7日 (水) 06:39 (UTC)[返信]

廃止提案

[編集]

記事名チェッカは、現時点で下記の検査を行っています。

  • 記事名が鈎括弧でくくられている場合
  • 記事名の最後の左括弧の前に半角スペースがない場合
  • 括弧の左右が対称ではない場合
  • 全角チルダを含む場合

しかしながら、下記の問題点もあります。

したがって、記事名チェッカを廃止して、今後必要があれば編集フィルターかタイトルブラックリストで改めて警告・禁止を提案する形にしたいと思います。--ネイ（会話） 2021年9月25日 (土) 16:32 (UTC)[返信]

チェック 済 廃止しました。先週にも述べた通り、今後は何らかの形で警告または禁止が必要の場合、編集フィルターかタイトルブラックリストの議論ページにて提案してください。--ネイ（会話） 2021年10月3日 (日) 07:22 (UTC)[返信]
「https://ja-two.iwiki.icu/w/index.php?title=MediaWiki‐ノート:Common.js/記事名チェッカ&oldid=85861540」から取得