メインメニューを開く

Wikipedia:井戸端

ここ井戸端は、ウィキペディア日本語版について、運営や方針、新しいアイディアや作業の仕方、その他様々なことで質問や提案、議論、意見交換を行う場所です。

  • 下記の過去ログ検索機能にて、既に似た質問がないか質問前にご確認ください。
  • よくある質問(FAQ)もご確認ください。なお、この井戸端で特に多くされている質問があれば、その内容をFAQの適切なサブページに追加するようにお願いします。
  • ウィキペディア日本語版やウィキメディア・プロジェクトと関係のない話題を投稿するのはご遠慮ください。

This page is for discussion of Japanese Wikipedia, normally in Japanese. But see also Help for Non-Japanese Speakers.


次のような内容には、ここ井戸端でなく別の専用のページがあります。適切な場所に投稿が移動される場合があります。

ウィキペディア全体に関して
個々の専門分野に関して
個々のページに関して
個々の利用者(アカウント)に関して

過去ログ検索

井戸端の話題タグとは、既に分類された単語によるページのカテゴリのことです。

最近の更新

以下は、►のクリックによって期間ごとの話題がツリー表示されます。

運営方針
  • 投稿された全ての話題はサブページに移動し、Category:井戸端の話題にカテゴライズされています。
  • サブページは、最新の投稿から10日間経過するか、最初の投稿から30日が経過すると、井戸端への読み込みが解除されます。

目次

先代次代系テンプレートの再編編集

割と大掛かりな提案ですが、Category:先代次代系テンプレート内のテンプレートの一部再編を提案いたします。提案の骨子は肩書きが1つだけの場合は{{Succession}}を、より複雑な場合は{{Succession box}}のテンプレート群を推奨することです。できるだけこれまで通りにテンプレートを使える(テンプレート名、引数名などをできるだけ変更しない)ようにし、過去版の表示への影響は閲覧に支障が出ない程度に限定しています。もしよろしければ、ご意見をお聞かせください。

最終的にはen:Wikipedia:WikiProject Succession Box Standardizationのように完全標準化({{Succession box}}系への一本化)を目指したいところですが、{{Succession}}を非推奨にするなど影響が大きいので、ひとまずは下記から始めます。(一本化を支持する方が多かった場合、実施に移す用意はあります)

個別テンプレートの扱い編集

使用数はTemplate transclusion countに準拠。また、下記で触れられていないテンプレートについては変更が必要な場合に別途議論を提起します。

合意が必要なポイント編集

  1. 先代次代系テンプレートを{{Succession}}と{{Succession box}}に二本化すべきか。
  2. 個別テンプレートの扱いにコメントはあるか。(1の合意が得られた場合、個別に削除依頼や改名提案などを提出するので、ここでコメントせずそちらで改めてコメントしてもかまいません)
  3. 上記の「要議論」で言及された問題はどうすべきか。
  4. {{Succession box}}系への一本化についての考えはどうか。

コメント編集

  •   合意が得られましたら、1月に実施に移ります。また、影響を受けるテンプレートが多いので、個別テンプレートには告知を貼らず、代わりにコメント依頼、コミュニティ・ポータルのコメント依頼リスト、お知らせに貼ります。
    なお、私は4には賛成で、現行の{{Succession}}系の使用は全てボット置換で解決できると考えています。テンプレートを削除するわけでもないので、過去版への影響はゼロです。--ネイ会話) 2018年12月23日 (日) 11:09 (UTC)
    •   ボクシング関連の先代次代テンプレートを追加しました。ほか提案の内容を一部修正しました。--ネイ会話) 2018年12月23日 (日) 16:51 (UTC)
  •   変更する意図というか、メリットとか必要性は何でしょう?たとえば「先代次代上人」では「廃止してSuccession boxを呼び出すべき」とおっしゃいますが、「べき」なのはどうしてなのでしょう?既存のものに不具合とかがあるのでしょうか?
  • 「1月に実施」とおっしゃいますが、あと10日もありません。1月のいつなのかにもよりますけど・・・。広範囲ですし、告知期間や合意形成期間をもっと長くとられては?後になって「知らなかった」という方が出てくるよりは。
  • ほかにも、プロジェクト:人物伝プロジェクト:歴史プロジェクト:イギリス・アイルランドあたりでも告知しておくべきと思いますよ。頻繁に使う分野と思いますから。告知して意見が付くかどうかはわかりませんが、できる限り広く告知したという実績は積み重ねておくに越したことはないでしょう。
  • 存廃について個別に言及なさっていないようなのですが、(実は競馬関係かな?と思ったのでクビを突っ込んだのですけれど)「前後レース」もありますね。使用0件ですけれど。作成者さんの履歴を眺めると[1]、モータースポーツ用だったんですねえ。その後、2008年から2009年頃に除去されています。作成者さんは無期限ブロックになっちゃっていますし、その後も使われていないみたいで、10年経っていますから、廃止ないし削除でもいいのでは・・・。(「廃止」でじゅうぶんで、別に削除まではしなくてもいい、って考えもあるでしょうね)。それにしてもモータースポーツはPJとかPortalは無い?ようですね。ねんのため、Portal自動車とPJスポーツあたりで告知してはどうでしょう。--柒月例祭会話) 2018年12月23日 (日) 18:38 (UTC)
  •   返信 実際に実施するときはさらに削除依頼などで少なくとも+7日になります。提案を行う日付として、3週間後の1月14日としましょう。
  • 他プロジェクトへの告知は後ほど(今日のうちに)行います。(追記:柒月例祭さんが言及した3プロジェクトに告知を行いました。)
  • {{前後レース}}はすでに{{Succession}}を使っていて、少なくとも「先代」の文字を変えているので、大きな問題はないとして見逃していました。使用数が0件なので、廃止していいかもしれません。削除については、10年前の版の閲覧をどこまで重要視するかになります(前後レースのテンプレートで表示されていた部分が表示されなくなります。ソースにはきちんと残りますので、完全に見られないほどではありません)。個人的にはそこまで重要ではないとは思いますが、柒月例祭さんの考えもお伺いしたいところです。
  • 「べき」というのは避けるべきかもしれません(今すぐ廃止しなければ駄目、というニュアンスを含む意味で)。提案全体の目的は「標準化」で、「見た目の統一」「メンテナンスの容易さ」(例えば、何らかの変更を行うときに10のテンプレートを変えなくても済むようになる)が考えられます。もっとも、前者に関しては完全に実現するのは英語版のウィキプロジェクト並の仕事量ですが。また、これはついでですが、全く使われていないテンプレートを廃止する機会(これをテンプレートのメンテコストを減らすという意味で有用)にもなります。--ネイ会話) 2018年12月23日 (日) 23:58 (UTC)告知について追記しました。--ネイ会話) 2018年12月25日 (火) 05:51 (UTC)
  返信 ありがとうございます。「いいね、ぜひやろう!」と賛成するほどのアレは感じないのですが、かといって「やめといたほうがいい」と反対する理由も思い浮かびません(たぶん私が自分であまりこのテンプレートを使ったことがないから。)。汎用性のあるものをつくり、様々な亜種をそれに統合することで「メンテナンスをまとめてできる」というのは確かにメリットにはなると思います。メンテナンスをすることがどれぐらいの頻度であるのかよくわからないので、「まとめてできる」ことが実際どの程度のメリットなのかも想像がつかない、というのもあります。「見た目の統一」は、私はメリットとは思いませんが、デメリットも思いつかないかな。
  • お示しの各種テンプレートと使用実態をみると、カスタマイズ版が普及しているのはボクシング分野と、「先代次代上人」(仏教のうち特定の宗派?)、あとは「歴史的地名」(中国の○○省)に限られていますから、そこらへんの分野から理解が得られればよさそう、ではありますね。いまの「Succession box」には「外交職:S-dip」「ビジネス:S-bus」だとかが何種類か用意されていますよね。ここに「ボクシング用」(スポーツ用?)とか「地名用」も予め用意しておいてあげるなどすると、一番カスタマイズが進んでいるボクシング分野の理解も得られやすいのかな?とも思います。(自分たちで「S-なんちゃら」を作るのはそう難しくもなさそうですけどね。)
  • 「べき」云々について。問題が起きる前から不安を言うのは心配しすぎなのかもしれませんが、今回、亜種の廃止も含めて「標準化・推奨化」を行ったとして、いずれ誰かがまたカスタマイズ版を作り始めたときに「やめて、標準版以外は使わないで」って強制力を発揮できるだろうか?というのが課題でしょうかねえ。
  • あとはもう枝葉の部類なのですが、「Succession box」の一番下の使用例なんですけど、年・日付に[[2013年]][[1月2日]]のようにリンクが入っていますよね。私はこれは気になる、というか反対ですねえ。WP:OVERLINKING(リンクすべきでないもの)あたりに照らして、「年や日付にいちいちリンクをしないほうがよい」と私は思うので。少なくとも使用例からはリンクは外しておいてほしいかなあ。まあこれは「リンクしたほうがいいだろ」という人もいるでしょうけれど。
  • もひとつ枝葉。「S-yea」の配色。コントラスト比が3.8:1になっていて、これダメなやつです。「S-hou」の背景色(「#FFD700」黄色?)も標準的なリンク色(青系や赤系)とは相性悪く、コントラスト比がNGになりがち。「S-hou」の黄色は今まで議論にならずにこれで定着していたのかもしれないですが・・・この際「標準化」に際して適切な配色に修正してはどうでしょう。(うっかりするとWikipedia:テンプレートの色で編集合戦をしないになりそうでアレですけどね。単なる感想なんですが、「Succession box」の下部の見本「もげもげ」にいろんな色が並んでいるのを見ると、なんかざわざわします。たぶん私たちがWP:COLORのガイドライン化に関わったからでしょうね。)--柒月例祭会話) 2018年12月24日 (月) 02:30 (UTC)
  • 一度にたくさん議題を出しすぎても仕方ありませんので、今回は再編の第一歩として、Succession boxとSuccessionへの変更(と一部テンプレートの廃止)に絞っています。日付のリンク付け、配色、ボクシング用などのS-xxxテンプレートについては第二歩でいかがでしょうか。(別に意見自体に反対しているというわけではありません)
  • なお、配色に関しては、en:Template:S-houが美観とコントラスト比をバランス良く配慮しているのではないかと思います。すなわち、文字が表示される部分は浅い背景色にし、黄色は上に装飾線として配置しています。
  • 強制力はガイドライン化まで漕ぎ着けるかの話で、各分野がバラバラという実態が存在する以上は難しいでしょう。しかし、最終的にガイドライン化するかはともかく、標準化の方向に進んでいいのかという意味で広く諮問して一度合意を形成することが大事だと思います。--ネイ会話) 2018年12月24日 (月) 02:58 (UTC)
  •   議論以前のところで恐縮ですが、パラメータを英語「のみ」のまま放置しているのは要改善です。編集コストを下げるためには日本語も使えた方がいいでしょう。
現段階での見通しですと、英語版の傾向の一つにテンプレート構造の細分化と限度を超えた標準化、そして両者に付随する肥大化があり、{{Succession box}}にも同じ問題があります。簡単に言えば、「問題点を発見した利用者がテンプレートに手を加えることを考えていない」「ミスが発生しやすい」ことが問題です。つまり「テンプレートの運用コスト」=「記事の執筆、メンテナンスコスト」については、この手の統一をすると「上がります」。メンテナンスコストは、「テンプレート編集作業者」の観点であって「記事執筆者」の観点ではありません。執筆者をテンプレートに使われる状態にするべきではないのです。また、英語版の人物記事や{{S-start}}を眺めてみると、「まとめる」効果よりも「何でも載せちゃう」マイナス面が発生する予感はあるんです。なので、一本化するよりも余計なものを見せない{{Succession}}を基本としたほうが無難かなと考えます。
「『先代』と『次代』の文字が太字でなくなる」のは、テンプレート側を編集するだけで事足りるので、標準で太字にしちゃえば? って安易な解決法もありますが、これは後から変えられることですね。--Open-box会話) 2018年12月24日 (月) 04:32 (UTC)
  •   返信 日本語の引数名は1、2日間待って、特に反対がなければ提案に追加します。
  • 太字はおっしゃる通りで、後から変えても特に支障はありませんので、現時点ではSuccession boxに合わせて太字とせず、提案を変更しません。
  • それ以外の内容は、「一本化」への反論と見受けします。では、SuccessionとSuccession boxの二本立てはどうでしょう。すなわち、内容が少ない場合は前者を、多い場合(ベンジャミン・ディズレーリなど)は後者を、という風に使い分けます。これならばテンプレート編集者にとって実質的にはテンプレート2つのメンテナンスだけで、執筆者にもできるだけ簡潔なインターフェースを提供できます。(要するに、議論項目の4番目だけ外します)--ネイ会話) 2018年12月24日 (月) 09:05 (UTC)
  •   報告 日本語の変数について、提案に追加しました。引き続きコメントを募集します。--ネイ会話) 2019年1月3日 (木) 08:42 (UTC)
  報告 {{Succession}}と{{Succession box}}の議論と関係のない{{東京ディズニーランドスペシャルイベント}}と{{東京ディズニーシースペシャルイベント}}の改名提案、{{講道館長}}の削除依頼は特に反対が出なかったため正式に提出しました。--ネイ会話) 2019年1月7日 (月) 11:56 (UTC)

モバイル版テンプレート編集

 
アイコンが表示され、補足情報の表示/非表示をタグ付けできるようになった。

(追記)目的はモバイル版用のテンプレートの対応を進めるということです。--タバコはマーダー会話) 2018年12月28日 (金) 01:56 (UTC)

記事冒頭に表示されるので、以下以外のテンプレートでも全体的に「この文書は」という部分を、モバイル版では非表示にしようと思います。モバイル版では特に画面の小さなスマホではまだ画面サイズが限られていますので。このように変更されます。

  • この文書は解説ページです。(変更前)
  • 解説ページです。(変更後)
ページの問題点テンプレート

モバイル版の「ページの問題点」の表示改善 (Mediawiki) のアップデートが12月半ば過ぎに適応されました。(技術/ニュース/2018年/51週

このアップデートによって、「タグ付けの変更による重要度を反映したアイコン表示」と「モバイルでは文字を削って表示する」ことができるようになったようです。詳しい仕様はまだ着手していないので分かりません。着手していきたいと思うのでよろしくお願いします。上記Mediawikiに文書があるのでそれに従っていきます。「重要度」の分類、文章の2行への圧縮などになると思います。

Wikipedia空間のテンプレート

方針ガイドラインのテンプレートである以下の文面を、モバイル版では非表示にしようと思います。

  • {{policy}}、{{guideline}}、{{文書の要旨}}の「この文書は」「この文書の」
  • {{policy}}の「多くの利用者に支持されており、」
  • {{guideline}}の「多くの利用者が基本的に同意しており、」

以上です。年が明けたらぼちぼちモバイル対応を勧めていきたいと思います。--タバコはマーダー会話) 2018年12月27日 (木) 01:05 (UTC)

関連文書などに目を通さないと理解しにくい説明が多く、何を目的にテンプレートを弄るのかも冒頭で述べていないため、非常に分かりにくいです。誰かの意見に対してコメントするのであれば問題のないコメント内容ですが、話を切り出す場合の説明としては好ましくないと思います。意見を募集したいのであれば、まず提案内容の要約を添えたり、技術ニュースなどを読まなくても大雑把な内容を理解できる説明を心がけていただけるとありがたいです。殊に技術関係は、どんなに良いことを言っても説明が悪ければスルーされがちですので。よろしくお願いします。
さて、提案内容についてですが、概要としては「記事冒頭などで使用するテンプレートがモバイル版向けの表示に対応したため、順序モバイル対応を行う」。具体的な方向性(細かい作業内容の話は端折る)として「モバイル版限定で文章量を削減、重要度の分類表示など」ということで間違いないですよね?これについては賛成致します。テンプレートの言わんとするところを大きく変えないのであれば、細かく事前合意を求めなくても特に問題はないかと思いますが、経過報告や意見募集をどこかで行えるようにすると、ミスのフォローやより良いアイデアが得られるかもしれません。--Marine-Bluetalkcontribsmail 2018年12月27日 (木) 16:42 (UTC)
私は技術的な説明を省いていますし技術ニュースに書かれていない、大雑把な説明をMarine-Blue氏はカッコを使った部分で理解されていますので、まったくの当方の落ち度というよりは自己矛盾をはらんだWikipedia:礼儀を忘れない#例に該当する行為だと思います。--タバコはマーダー会話) 2018年12月28日 (金) 01:56 (UTC) 理解が得られたので削減しました。--タバコはマーダー会話) 2018年12月30日 (日) 15:43 (UTC)

#将来的な話題に少し確認のやり取りが続いていますが、提案事項以上の話題が続いていますのでここで区切ります。

本筋の話題としては、まずテンプレートの状況調査が必要です。記事空間用のテンプレートに対して日本語版ではtext(表示する文章)、smalltext(小さく表示する文章)の引数が指定されていますが、この慣行は英語版では古くなっており、代わりにissue(簡単な問題の説明)、fix(修正方法)が指定されています。後者の引数(issue,fix)の場合にモバイル版のシステムとして簡単な表示を行うようです。英語版や中国語版では記事の問題系テンプレートの9割がこの引数で対応しているけれど、日本語版では僅かだということです。--タバコはマーダー会話) 2019年1月4日 (金) 01:25 (UTC)

記事空間用のテンプレートで issue(問題の説明)だけを表示するというのが新しいモバイル用の仕様で、「text」に「issue(問題の説明)とfix(修正方法)」にあたるものが入っていて文章の変更不要なテンプレートの方が多いので、近々機械的にやっていきます。その際に少しでも重要な説明分の文字数を確保したいので「この記事は」「このページは」「この項目は」という先頭の主語はモバイル用でのみ非表示にしていきます。「このフィクション記事は」みたいな説明がかかっているものは残します。仕様が提示されているアイコン指定についてざっと見たところ、中立的な観点テンプレート以外は既に反映されている感じがありますので、あまりやることはないかもしれません。--タバコはマーダー会話) 2019年1月4日 (金) 16:17 (UTC)

「issue」「fix」について、よくわかりません。もう少しご説明いただけますか?
「issue」(問題の説明)=「この文書はウィキペディア日本語版の方針です。多くの利用者に支持されており、すべての利用者が従うべきだと考えられています。」
「fix」(修正方法)=「必要に応じて編集することは可能ですが、その変更はコミュニティーの合意を反映している必要があります。大きな変更を加える場合は、先にノートページで提案してください。」
こういう分け方であっていますか?--柒月例祭会話) 2019年1月4日 (金) 16:52 (UTC)
明けましておめでとうございます。policyテンプレートはWikipedia空間用テンプレートなのでtextをissueとfixに分ける調整はありません。--タバコはマーダー会話) 2019年1月5日 (土) 02:01 (UTC)
  返信 なるほど、ではこうですよね?
  • (例){{出典の明記}}
  • 「issue」(問題の説明)=「この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。」
  • 「fix」(修正方法)=「出典を追加して記事の信頼性向上にご協力ください。(____年__月)」
思うに、「(____年__月)」部はissue側にいれたほうがよいのでは?
いま{{出典の明記}}の英語版、en:Unreferencedを眺めたのですが、確かに引数が「issue」「fix」になっていますね。「(____年__月)」部は「date」になっているのでしょうか?(英語版では、「出典を追加してください」のほか「吟味(be challenged)の上、除去してください」ともあるので、英語版と日本語版は単純には一致しないですけれど。)
これはもしお分かりでしたら意図をご教授いただきたいのですけれど、モバイル版では「fix」を表示しないということは、モバイル端末からは「閲覧」のみを想定し、「編集」はあまり想定に入れていないということでしょうか?--柒月例祭会話) 2019年1月6日 (日) 04:45 (UTC)
今まで「問題点がある」とだけ表示されたものが、「詳細」(未訳)を押すとこれまででも全文が表示されました。仕様の改定でissue(問題点)のみを表示し、詳細を押すと「fix」(修正方法)も表示するつまり全文表示という仕様が提示されています。
(____年__月)部分はご覧になったen:Template:Unreferencedでも表示上fix部分に表示されています。日本語版では表示上fix部分に入っています。ただ英語版ではAmboxのdate引数を使っているので、date引数を指定すると仕様上fixの後ろに入ってしまうんでしょう。日本語版ではdate引数の挙動がおかしいという報告もあり動作確認をしていないので、issue該当部分に入っていればそのままissue部分に入れておくといいでしょう。
>思うに、「(____年__月)」部はissue側にいれたほうがよいのでは?
ということで、年月の移動の理由の合理的な説明がなく、提案にも見え、突如パッと出の思い付きに見えます。理由がないので、いいのかどうかについての判断材料がないです。当方は文章に変更のない部分に手を入れるので当方の修正後に、後から決定してもいい性質かと思いますがいかがでしょうか。理由は述べた以外にも色々ありますが、まずもって「問題点のテンプレート」全てにおいて移動しないといけないので当方は反対でもあります。
最後の行の質問に適したヘルプは、Help:MediaWikiに適応するブラウザ#対応するブラウザです。--タバコはマーダー会話) 2019年1月6日 (日) 06:38 (UTC)
  返信 わかりました。まあ(年月)がissueかfixかというのはこの際さほど重要な問題であるとは思いませんし、仕様や動作に任せます。
あとは、対象となる「問題点のテンプレート」は、(さほど数が多くないなら)ここで列記していただけますか?もしくは、どこかで一覧できますか?Wikipedia:Template メッセージの一覧/問題のある記事あたりが網羅的かな?とも思うのですが、この中でも{{出典の明記}}や{{単一の出典}}は対象になるでしょうし、{{要出典}}などは対象外ですよね。今回のissueとfixへの修正作業にあたり、修正を施したものだけを格納するカテゴリを新設してはどうでしょう。将来のメンテナンスのために。--柒月例祭会話) 2019年1月8日 (火) 04:01 (UTC)
>{{要出典}}などは対象外ですよね。
既に、記事冒頭に表示されるページの問題点系のテンプレート、のようなことでは理解できないんですか?というか理解しているので、この質問が出るんですよね。そしたらこの質問は不要ですよね。
そちらで見たen:Template:Unreferencedの実情と反する突発的な意見とかですね。常々、前後の論理的な確認がないんですよ。
Wikipedia:Template メッセージの一覧/問題のある記事にありますが、漏れているのがあればやってきいます。
それで列記する理由はなんですか?
>修正を施したものだけを格納するカテゴリを新設してはどうでしょう。将来のメンテナンスのために。
手順を事前に決める必要があるんですかね。根拠はなんですか?する際としない際のメリット・デメリットが提示されていませんので議論できません。Wikipedia:編集方針#多様な参加姿勢が受け入れられます上、自由なんですが。
反対意見なら反対と先に行って、脈絡のない質問のような後からでも決められるようなものなら分離してください。
Wikipedia:編集方針#多様な参加姿勢が受け入れられますWikipedia:ノートページのガイドラインの脱線しないや理由を説明するがありますよね。
そちらのやり方で統一化したいのであれば、個人に対するしつこい妨害的な議論ではなくて、ガイドライン化してください。--タバコはマーダー会話) 2019年1月9日 (水) 05:32 (UTC)
  返信 あなたがこれからやろうとする事柄についてコミュニティの合意を取り付けるに当たり、事前にきちんと説明することをなぜそのように嫌悪なさるのか、私にはよくわかりません。
丁寧に説明することで、他利用者からの意見が付きやすくなり、健全な議論が容易になり、より広い合意が得られやすくなります。
あなたの個人サイトならば思うママ好きになさればいいでしょう。ですが共同作業の場です。こういうことをします、目的はこうです、手段はこうです、こういう影響があります、範囲はこうです、といったことを予め明瞭にわかりやすく示すことの大切さがわからないのでしょうか。それを尋ねる行為を「妨害」などとは。--柒月例祭会話)2019年1月10日 (木) 01:39 (UTC)
>あなたの個人サイトならば思うママ好きになされば…事前にきちんと説明することをなぜそのように嫌悪なさるのか
当方は手順を踏んでいますよね。当方がこれらを守っている点について適切に発言し歪曲発言を修正し、そちらの私的見解について注釈を加えてください。㭍月例祭氏個人に対して、ノートページのガイドライン個人攻撃はしないに従って歪曲や消耗させるような行為をやめてくださいということです。理解していることをなぜいちいち聞いてくるのか、矛盾した意見を控えてください、背景となる文書、議論経過を読んでくださいという基礎的なことです。関連した7ページは以下です:123456 コメント依頼/㭍月例祭
こういう前例があり、事前に列記する必要性がきちんと説明されていない、
「格納するカテゴリ」について、きちんと説明されていないのが、㭍月例祭氏でありガイドライン上の意見方法を説明しています。
>コミュニティの合意を取り付けるに当たり
Marine-Blue氏の意見として、「テンプレートの言わんとするところを大きく変えないのであれば、細かく事前合意を求めなくても特に問題はないかと思いますが、経過報告や意見募集をどこかで行えるようにすると…」とありますが、個人的にはそれくらいの想定ですね。
ただし、㭍月例祭氏が過去に議論の進行妨害となるような議論放棄を行ってきている上記123という過去の事例があり、「コミュニティの合意」に問題が生じているというよりは、㭍月例祭氏のWikipedia:論争の解決#ステップ2の議論参加の仕方によってスムーズな議論進行が妨害されていると感じているところです。当方もいきなりそんなことを言っているわけではないですよ。
まず質問であれば分離し、反対なら反対と述べてどこに反対しているのか明瞭にし、手順に議論があるならば方針を示し明瞭な説明を行い、最後まで責任をもって議論参加してください。--タバコはマーダー会話) 2019年1月13日 (日) 07:19 (UTC)

将来的な話題編集

  •   趣旨はわかったような気がするのですが、「その理解で合ってる」とか「違う」とかご指摘いただけると、賛否を述べやすいです。
  • 従来は、モバイル環境ではテンプレート類が表示されていなかった/表示場所が違っていた
  • 具体的には、記事の冒頭にある「出典の明記」など、「この記事にはこういう問題があるから気をつけてくださいね」という類の重要なメッセージも表示されていなかったり、一番下の方になっていたりしていた
  • これらが、限定的だけども、表示されるようになる
  • 小さなアイコン画像と、短いメッセージは表示可能。メッセージは長いと省略される(「続きはここをクリック」みたいになる)
  • 「短い」というのは、具体的には「2行」とされている。(「設計目標とウィキ横断的な互換性」)
  • なので、メッセージを短くして、一発で全文が表示されるようにする。そのために今のメッセージ文を簡潔に短くする。
  • 結局は、各利用者の環境設定しだい(文字の表示サイズとか)に委ねられてしまうのかもしれませんが、この際「2行」とするよりは「○文字」と決めちゃったほうが話がしやすいのではないでしょうか?
  • タバコはマーダーさんのほうで、「2行」が何文字程度になるのかの想定がおありでしたら、「30文字くらい」だとか提案いただけると助かります。
  • 「どこを削るか」よりは、削ったあとの完成形の文章をお示しくださると、皆意見を言いやすいと思います。
原文 この文書はウィキペディア日本語版のガイドラインです。多くの利用者が基本的に同意しており、従うことが推奨されますが、方針ではありません。必要に応じて編集することは可能ですが、大きな変更を加える場合は、先にノートページで提案してください。
モバイル版 ウィキペディア日本語版のガイドラインです。従うことが推奨されますが、方針ではありません。必要に応じて編集することは可能ですが、大きな変更を加える場合は、先にノートページで提案してください。

--柒月例祭会話) 2018年12月28日 (金) 02:36 (UTC)

  コメント 具体的な文字数がみえないうちは結論に至りにくいのですが、私だったらこんぐらいシンプルにしちゃいますね。
  • <ガイドライン>多くの利用者の同意により、従うことが推奨されています。大きな変更の際には事前にノートページで提案してください。
--柒月例祭会話) 2018年12月28日 (金) 03:04 (UTC)
全て合っています。ありがとうございます。”2行”はMediawiki側から仕様が提示されているためです。
文字数は決めない方がいいです。”出典”や”テンプレート”など、テンプレートによって必要な用語の長さが違うので文字数を決めると後々大変でしょう。文字数が長い単語が複数必要な文章があるかもしれない。文字数を決めると固定的(ソリッドデザイン)、そうでないものは柔軟的(リキッドデザイン)です。WEBデザインの根底的な考え方が、特にモバイル対応では画面サイズが多様すぎるので柔軟にするということになっていますから。
最初は「この文書は」を削っていきます。それ以上は全体像が分かっていないのでそれから考えます。その作業をしながら、”中心的で反復的な文章”か、”短いか”を考えます。
共通項的な"反復的な文章"がテンプレートにあれば、別のテンプレートに同じ文が後ろの方にあれば、省略されていても予想できるようになります。こういう認識性も考えた方がいいということです。ただこういう共通項があるのかもまだ分からないところですが。
手を入れていきますよと最初はこうして告知しつつ、変形の少ない部分に手を入れつつ、全体像・共通項を把握していきます。表になっている方のモバイル版程度の変化を目指します。いきなり「こんぐらいシンプル」の方の例を目指すと、個々の議論が出てきて議論の収集がつかなくなり、結局モバイル対応ができないということが考えられます。--タバコはマーダー会話) 2018年12月28日 (金) 03:53 (UTC)
  返信 ありがとうございます。文字数とソリッド/リキッドの件はわかりました。このメッセージは(1)文書の効力の説明、(2)修正変更の注意喚起、の2点を示しています。そこが大きく逸脱しなければ、まあいいかな、と思います。
これは元の文がそうなってるのでしょうがないのですが、そのつもりでよくよく読むと、(1)が「ほにゃららだが、方針ではない」という構成になっているのが気に食わないです。「方針ではないが、従うことが推奨」という順序で書くべきかなあと思います。そこらへんのどこに力点を置くかで伝わり方が違う気もしますが・・・まあ置いときましょう。--柒月例祭会話) 2018年12月28日 (金) 07:37 (UTC)
  いま手持ちのiPhone6+SAFARIで試したところ25文字x20行でした。ので、我が家でモバイル版ウィキペディア日本語版を見た場合:

ウィキペディア日本語版のガイドラインです。従うことが推奨されますが、方針ではありません。必要に応じて編集することは可能ですが、大きな変更を加える場合は、先にノートページで提案してください。

…になるようです。㭍月例祭さん案で:

<ガイドライン>多くの利用者の同意により、従うことが推奨されています。大きな変更の際には事前にノートページで提案してください。

ですね。個人的には2~3行以下に集約して欲しいと思います。より古い携帯端末になると更に幅・行数共に少なくなり縦長化するだろうとも。--Nami-ja [会話 履歴] 2018年12月28日 (金) 10:11 (UTC)
デスクトップとモバイルで共通の文章を削る方式でないと確認やメンテナンスまた技術的にも難しいと思います。
この文書は方針です。これに従ってください。」
同じ文章をベースにモバイルでは打消し部分を見えなくするということです。--タバコはマーダー会話) 2018年12月30日 (日) 15:43 (UTC)
  コメント {{Policy}}について「この文書はウィキペディア日本語版の方針です多くの利用者に支持されており、すべての利用者が従うべきだと考えられています。必要に応じて編集することは可能ですが、その変更はコミュニティーの合意を反映している必要があります。大きな変更を加える場合は、先にノートページで提案してください。」(取り消し線の部分をモバイル版で非表示)。{{guideline}}について「この文書はウィキペディア日本語版のガイドラインです多くの利用者が基本的に同意しており、従うことが推奨されますが、方針ではありません必要に応じて編集することは可能ですが、大きな変更を加える場合は、先にノートページで提案してください。」(取り消し線の部分をモバイル版で非表示)。で、どうでしょうか?方針についてはモバイル版で変更することを考慮してません。ガイドラインについて「方針ではありません」という文はモバイル版では必要ないと判断しました--aki42006会話) 2019年1月2日 (水) 03:14 (UTC)

ガイドラインの文面を決定していきます。モバイル版も類似した文章を見ていた方がいい、メンテナンスが容易ということから、ベース文章は共通の方がいいですね。ベース文章を同じとすると、文章の構造的に今出ている2案の大きな違いは一点で、「多くの利用者が基本的に同意しており、」を削るか残すかになります。柒月例祭氏とaki42006氏は、これを削るか残すかについてのご意見はいかかでしょうか?この部分を残す削るの議論が発生すれば、既に存在するベース文章をどれだけ削るかということなので一旦残す案に決定しましょう。どちらへも反対の意見が出れば、全体から見て「この文書は」だけを削ることになることもありえます。

  • 多くの利用者が基本的に同意しており、従うことが推奨されます。大きな変更を加える場合は、先にノートページで提案してください。(ベース未変更のまま構造的に柒月例祭案)
  • 従うことが推奨されます。大きな変更を加える場合は、先にノートページで提案してください。(aki42006案)

「ウィキペディア日本語版のガイドラインです。」を「ガイドライン」とする案。これは実行力を持つ文書のテンプレートに「ウィキペディア日本語版の」とついていて、テンプレート間で全て残すか無しで統一するかにした方が認識性がいいと思います。

削るのではないガイドラインの文面変更については、柒月例祭案は変更点が複数あり文字数が増加している部分もあります。現行の「多くの利用者が基本的に同意しており」よりも提案の「多くの利用者の同意により」の方がスムーズな言い回しです。「大きな変更を加える場合」よりも提案の「大きな変更の際には」の方が短いです。モバイルだけの対応ではなく複雑な意見調整が必要になるかもしれないので後回しにした方がいいでしょう。先に、当方から文字サイズの調整を提案します。--タバコはマーダー会話) 2019年1月5日 (土) 03:40 (UTC)

  コメント「多くの利用者が基本的に同意しており、」の部分について、私の案ではモバイル版で非表示にしていますが、特に拘りはありません--aki42006会話) 2019年1月5日 (土) 04:20 (UTC)

カテゴリを集めるカテゴリの整理編集

現在カテゴリを集めるカテゴリがCategory:コンテナカテゴリCategory:カテゴリを集めたカテゴリの2つあり、重複するカテゴリだと思われます。使い分けもうまく行っていないようで、両カテゴリのサブカテゴリCategory:カテゴリを集めたカテゴリ (分類指標別)のサブカテゴリCategory:分野別に分類したカテゴリがCategory:コンテナカテゴリのサブカテゴリになっていたりします。またCategory:記事を収集しないカテゴリというカテゴリがあり、これはCategory:コンテナカテゴリの他にはサブカテゴリを持たず、不要なカテゴリだと思われます。この状況を整理するため、Category:コンテナカテゴリとCategory:カテゴリを集めたカテゴリを統合し、Category:記事を収集しないカテゴリは削除するのが良いと考えています。カテゴリツリーのかなり上位にあるカテゴリかつツリーが複雑なため、統合提案削除依頼に出す前に意見を集めたいと思います。--プログラム会話) 2018年12月28日 (金) 09:27 (UTC)

  現状こんな感じみたいですね。「カテゴリを集めたカテゴリ」の定義を見るに『原則的に「〇〇のカテゴリ」の名称を持つカテゴリのみ』として分類種別ではなくカテゴリ名そのものを分類対象としているようで、あからさまに特定個人の独自視点によって個人のカテゴリ分類欲求を満たすためだけに作成された非合意作成カテゴリなのではないかな、という印象を持ちました。なお作成者は頭痛会話/投稿記録/記録さんです。--Nami-ja [会話 履歴] 2019年1月11日 (金) 01:52 (UTC)

  ひょっとすると、Category:カテゴリを集めたカテゴリは(Nami-jaさんも仰るように)「カテゴリ名そのものを分類対象としているよう」であることから、en:Category:Eponymous categoriesのような立ち位置を指向して作られたカテゴリだったのかもしれません。ただ、そのカテゴリの名称(の非論理的な感じ)はともあれ、肝心のカテゴリの目的と定義が明確でないまま放置された結果、外見も中身も意味不明な存在になってしまっている感があります。 "Eponymous categories" (試訳:Category:それ自体の名を冠したカテゴリ)はノートを見ると過去に3度削除が審議されたようで、不要なカテゴリの候補に挙げられるでしょう。--Doraemonplus会話) 2019年1月16日 (水) 14:21 (UTC)

内部リンクにカーソルを合わせた際の概要表示やモバイルビューについて編集

いつ頃からか、内部リンクにカーソルを合わせるとポップアップ(?)で概要が表示されるようになっています。導入部の文章や写真が表示されて便利になっているのですが、導入部の段落が2つ以上でInfoboxがある場合に、導入部の第1段落しか表示されないという問題があります。

これに対し、導入部全てが表示されるようにシステム側で改善していただくことは可能でしょうか?それとも導入部の段落構成を編集で改善するしかないのでしょうか?導入部全体を見れば主題について適切な紹介文が書かれているのも関わらず、第1段落が定義文のみで、第2段落にある重要なキーワードが目に入らない記事も多く見受けられ、気になっています。

なお、これに関連してモバイル端末でモバイルビューを閲覧した際に、

  • 導入部第1段落
  • Infobox
  • 導入部第2段落以降

という順番で表示されるという現象があります。以前は

  • Infobox
  • 導入部

という順番で表示されていましたが、いつの頃からか変更されています。

単にWikipedia:表示改善依頼で改善提案をしようかとも思ったのですが、モバイルビューの変遷があったため、井戸端で望ましい改善策や過去の議論や経緯を教えていただければと思った次第です……。--Assemblykinematics会話) 2018年12月29日 (土) 22:48 (UTC)

  ポップアップでの概要は、ページプリビュー(または旧来のナビゲーション・ポップアップ)により表示が行われており、mediawiki側ですので、簡単に改善とはいかないんじゃないかと思います。ナビゲーション・ポップアップに手を加えるという方法もあるとは思いますが、Wikipedia PEEKなどのブラウザアドオンを使うのが簡単かと思います。--115.39.251.95 2018年12月30日 (日) 03:19 (UTC)
  日本でもガイドラインは用意されているので、編集で対応していくのがベストだと思います。
要約を先にという情報デザインの考えがあって、Mediawikiの仕様がこれに従っています。新しい機能が増えてもベースの考え方になるでしょう。Help:MediaWiki#ユーザー・インターフェースにそのことについて以前に書きました。
モバイル版に関しては仕様です。第一段落の情報がないとInfoboxが先に存在しても不便だということです。Mediawikiに文書を翻訳しました。閲覧/Web/プロジェクト/導入段落の移動です。
ポップアップもMediawikiの機能なので、おそらく同様の考えがベースでしょう。
英語版は導入部を集めたDVD版Wikipediaのため、導入部の品質管理プロジェクト(en:Wikipedia:Version 1.0 Editorial Team)まであるので貫徹されています。日本のWikipedia:スタイルマニュアル (導入部)も英語版のガイドラインを結構反映しています。ガイドラインに従っていれば、ある程度問題のない表示になっているかと思います。--タバコはマーダー会話) 2018年12月31日 (月) 01:24 (UTC)
  ありがとうございます! Mediawikiには疎く、大変勉強になりました。改善要求ではなく編集対応で対処していきたいと思います。ただ、「織田信長」のように導入部に定義文程度しかない場合や「吉田茂」のように第1段落が定義文のみという場合など、Wikipedia:スタイルマニュアル (導入部)#導入部(第1段落)の例にそぐわない著名な記事も見受けられます。また、下手に導入部を充実させてしまうと「概要」節に分割されてしまう場合も多く、悩ましいところです……。--Assemblykinematics会話) 2019年1月4日 (金) 10:40 (UTC)
ウィキペディアの一行目は「辞書未満の抽象的な説明」を目指しているので、織田信長の第一段落は、ポップアップで出ても「辞書未満の説明」ですから既にある程度知っている人にしか役に立ちません。織田信長(2018年10月28日08:18)で編集されていますが、桶狭間の戦い、親族との関係、政権関係といった適切な導入部があるのようなので、単に非常に長くなった概要節と重複して、元の導入部があってもいいと感じますね。しかし、その前から辞書未満なので再編した方がいいでしょうね。
Template:導入部が短い/doc/listもあります。--タバコはマーダー会話) 2019年1月9日 (水) 07:33 (UTC)
  情報IP 115.39.251.95 様が吉田茂で編集してくださったのですが、導入部で段落の区切りに改行2回ではなく<br />を使うと、ページプリビューやモバイルビューで段落をまたいで表示されるようです。導入部の書き換えはよい文章が思い浮かばないとなかなか手を出せないのですが、前述の対処ですと応急処置として良さそうです。--Assemblykinematics会話) 2019年1月11日 (金) 14:33 (UTC)


全保護記事が編集出来る権限について編集

最近ずっと多忙で、議論を引っ張る余力が無い件について予め謝っておきます。

先日、アスペルガー症候群の無期限全保護を見まして、確かに仕方ないと感じました。そもそもLTA:ASPE自体、かなり粘着性を持って特定記事を荒らす傾向があり、しかも半保護すらかいくぐる事を複数回繰り返しています。つまりは、厳しいとは感じつつも全保護仕方無しと思う次第です。

そうなったときに、管理者のみに許された全保護記事の編集出来る権限があるのが良いのではと思いました。拡張半保護(重半保護)の本採用も何時になるか不明ですし、ある程度身元がしっかりした利用者が、特定の目的で、一定期間全保護記事の編集を出来る様にするのも有りでは無いかと思い、意識調査的な要素を含めて提案しました。とりあえず、以下の様な条件を想定した上で、「全保護記事が編集出来る権限」を与えることを提案します。

  • 目的とする記事、編集目的を明言した上で編集権限を申し込む。
  • 期間は基本1ヶ月とし、必要に応じて最長3ヶ月延長出来る、延長に関しては自動延長は無く、随時申し込む。
  • 編集が終わったときは編集完了報告をするのが望ましく、宣言時は速やかに権限削除を行う。
  • 権限フラグは、管理者により付け外し出来る様にする。
  • 権限を与えられた利用者が一定期間以上のブロックを受けたときには即時権限剥奪出来る。
  • 権限を与えることが出来る利用者については、月間新記事賞ノミネート以上の利用者については無条件で与えることが出来、それ以下は議論の上で与えるかどうか決める。
  • 元々管理者が特定記事を大修正したいときも、同様の手続きを踏んで編集出来ることとする(権限条項はその場合は無視することになる)。

以上で考えています。導入に対するハードルなど意見あればお願いします。--Taisyo会話) 2019年1月3日 (木) 03:43 (UTC)、修正--Taisyo会話) 2019年1月3日 (木) 03:51 (UTC)

議論編集

  •   コメント 例として、アスペルガー症候群の編集をするために権限を申し込むと仮定した場合、「アスペルガー症候群を最近の医学指針改訂に則った形で修正したいと思います。その際に、節構造など大幅に改訂することになりますので、管理者による編集代行は困難に思います。個人的に編集した○○が良質記事に選ばれていますので、編集権限を下さい」の様になるかと思います。緩めるべきか締めるべきか、意見も貰えたらと思います。--Taisyo会話) 2019年1月3日 (木) 03:48 (UTC)
  •   コメント 確かにLTAにより荒らされている記事は半保護逃れも行われ、半保護と全保護の中間の保護対処が欲しい、というのはよくわかります。アスペルガー症候群ノート / 履歴 / ログ / リンク元については荒らしとその差し戻し以外の適切な編集も見受けられますので、全保護は適切な編集も妨げることとなり、特に注意を要するようには思います(私自身はLTA:OYAKO対策でいくつかの記事の全保護を依頼し管理者による全保護対処もありますが、ケースB案件が絡まない荒らしで依頼した背景として、荒らしと差し戻し以外の編集がないことを考慮しています)。
提案には概ね賛成ですが、いくつか気になったところがあるのでコメントします。
  • 荒らしに伴う長期全保護期間中でも、ノートによるコミュニティの合意のもと、 Wikipedia:管理者伝言板/保護ページ編集 で大きな編集を依頼し対処できるようにするのはどうか(長期荒らしの被害を受けているページに限る。編集合戦による全保護は保護解除依頼へ)。現行規定上は不可能であるものの、コミュニティの合意(記事の場合はノート合意)があれば、全保護ページでも管理者が大きな編集を行うのに私はあまり違和感を覚えません。しかし、管理者の負担が増えることは心配です。管理者の立場から見て負担が大きい(管理者以外の利用者に委ねたい)ところなのでしょうか?
  • 「月間新記事賞ノミネート以上の利用者」(これは月間新記事賞受賞記事の立項者のことを意味したいのでしょうか、単に月間新記事賞候補に入るならメインページ新着記事に選ばれれば無条件に候補になります)の基準にもよりますが、管理者はともかく、それ以外の利用者に対し無条件にしてしまうと、他の分野の記事でLTA:SHINJU(例えば良質な記事に選出されている御土居下御側組同心ノート / 履歴 / ログ / リンク元オキチモズクノート / 履歴 / ログ / リンク元はLTA:SHINJUが立項)のような善玉悪玉荒らしに乱用されるおそれが出ないか心配です(関連分野でそれなりに実績のある利用者であれば議論でも通るかとは思います。その手間を省くために無条件と考えられたのかもしれませんが)。ただし、この運用をLTA:ASPE出現記事に絞ることで合意するならそれほど心配しなくても良いのかもしれません。--郊外生活会話) 2019年1月3日 (木) 05:07 (UTC)
  •   コメント 新しい利用者グループの創設を検討するのであれば、より使い道の広い拡張半保護の正式採用を目指したほうが無駄が少ないと考えます(ただし、全保護記事編集権限の創設にも反対しません)。また、当面の対処として、ノート合意に基づき管理者伝言板で依頼を受け付けることに賛成します。--ネイ会話) 2019年1月3日 (木) 06:02 (UTC)
  •   コメント 郊外生活さんの懸念と重複しますが「月間新記事賞」を判断起点に置きますと、現在ブロック解除依頼中のLTA:DARUなど「ソックパペット活動期間中に(バレにくくするために)方針ガイドラインを熟読した結果として無期限ブロック時点より飛躍的に執筆力が向上する荒らしがいる」という点、そして初版で115KBの英語版翻訳記事抗酸化物質を執筆するなど元々無期限ブロック時点で高い執筆力を持っていたLTA:AKANEなどのWP:SNEAKYが素通りする可能性が高まるのではないでしょうか。そうしなければ何らかのデメリットが発生するのでなければ、特権利用者を制度として設けるでなく平均化、申請必須の手順を設けワンクッション置いた方が面倒事が少ない気がします。--Nami-ja [会話 履歴] 2019年1月4日 (金) 00:34 (UTC)
  •   コメント いくつか纏めてレスをしたいと思います。想定内ではありましたが、概ね賛成としつつも荒らし利用者による悪用を危惧する声が多く聞かれました。
  • 管理者伝言板に大規模編集依頼を設置する。 - 一番現実的な印象があります。それでしたら荒らしの問題は極力無くなる様に思います。ただ、ドラフトを元に管理者が転記する訳ですから、主筆者が誰になるのかの問題があるかもしれません。まあ、元々の文章を書いた利用者であるのは間違いないのですが、履歴上は出てこない様に思います。執筆者の手法にもよるのですが、細かく版を重ねていく執筆者もそれなりにいます。その様な場合にやりやすい方法の選択肢が有った方が良いのではと思う部分もあります。編集時に一時的に全保護を解除してしまうのもありかもしれません。とは言いつつも、管理者伝言板依頼は当面の解決策に有用に思います。
  • 無条件での権限取得条項を無くす - 確かにそうですね。一度届けを出して議論した方が安全の様な気がします。長期荒らしの中には編集能力があるのもありますし。
  • 拡張半保護導入を先行するべき - それも納得しています。今のドラフトを出してそのまま承認に持って行けるのかなと思う点。また、私が元となる重半保護を出して5年以上過ぎていますので、まだ掛かるのかもと思う部分と、今全保護編集権限を提案しておけば、将来的に導入出来るまでの期間が短くなるのでは(年単位で)と思う次第です。
  • まだまだ意見募集中です。本採用提案には多分ならないと思います。メタに強い利用者の協力も必要になりますので。--Taisyo会話) 2019年1月4日 (金) 13:51 (UTC)
  •   コメント ざっくりとですがコメントしておきます。現状の全保護は方針上「管理者も単純な修正しかできない」ものであり、言わば「最も重い編集禁止状態」で、「誰も編集できない」のはある意味で最も平等と言えるものですが、その重さの対応ができる保護レベルが存在したほうがよいと思うのです。半保護逃れを行う荒らしに対して有効なのはわかるのですが、その他のたとえば編集合戦によるものなどを想定すると「誰も編集できない」保護レベルを設定できなくなることはデメリットであると思います。「管理者も単純な修正しかできない」からこそ、全保護を掛けた時点で編集合戦の継続が不可能になるわけです。悪用しない利用者に権限付与すればよいのですが、その選定にかかるコストがメリットより重くないでしょうか。全保護の重さを下げるよりも、全保護と半保護の中間の重さにあたる拡張半保護の導入を目指すのがより望ましいと感じます。--Y-dash 2019年1月4日 (金) 14:49 (UTC)
  • 「全保護の重みと穴明することのリスク」ですよね。確かにその通りに思います。昨今の妙に重たい全保護対応とかありますし、色々課題も多いのかなと思います。LTA:ASPEの様に白黒はっきり付く様な例なら問題ないのですが、グレーゾーン事案が多く出てきそうです。全保護編集権限の基礎研究程度は続けるとしても、実際のルール面での整備については、全保護ページに関する管理者による大規模編集代行ルール整備と、一昨年の段階で決選投票直前で中断している拡張半保護導入投票再開でしょうか。前者については大まかなルールを考えるとして、後者は現状確認と議論を引き継ぐ対応とかしないといけないと思います。そこからやり直すかの問題もある様に思います。アスペルガー症候群について、今年4月頃に大きな改正がある様なことを議論されていますので、そこまでにどちらかのルールを整備出来るのであればする。ルール整備が出来なくて、大きな改正が行われたときはこの記事限定での特別対応になる様に思います。今日も例の荒らしが出ていますので、全保護解除は困難に思いますので、ドラフトページを何処かで作成したら、このページ限定ルールで転記になると思っています。とりあえず、管理者伝言板での大規模編集代行依頼整備と拡張半保護整備に軸足を蛙でよろしいでしょうか。--Taisyo会話) 2019年1月5日 (土) 12:54 (UTC)

代案について、まずWikipedia:井戸端/subj/全保護ページの管理者による編集代行依頼についての議論を開始しました。--Taisyo会話) 2019年1月12日 (土) 12:21 (UTC)

コメントの訂正について編集

コメントを後になって訂正する際、取り消し線で消し<small>(コメント訂正、--~~~~)</small>のように末尾に記します。一方で、コメントを丸ごと書き換えて署名時間も上書きで変更する利用者もいます。普段はあまり機会がなく気にしませんが、皆様はどのように訂正するのでしょうか。--BR141会話) 2019年1月3日 (木) 14:16 (UTC)

  Wikipedia:説明責任(自身の編集に対する説明責任)の観点からは、前者の方式がベターでしょう。特に、自身のコメントのあと、それに対して別の利用者が何らかのリアクションを行った後は、前者の方式に限るべきです。なぜならば、誰かがあなたに対して返答したあとに、自身のコメントを修正すると、あとから見た第三者が事の経緯などを読み誤ることになりますよね。逆に言えば、自身のコメントのあと、まだ別の利用者がなんのリアクションを返していない場合には、後者の方式も許容されると思います。--柒月例祭会話) 2019年1月3日 (木) 18:12 (UTC)

  数分以内なら後者、時間経過後なら前者ですかね。何れにせよ要約欄に「署名変更せず」「内容刷新」「改訂追記」などの文言は残します(公式ガイドラインWP:ES)。--Nami-ja [会話 履歴] 2019年1月4日 (金) 00:18 (UTC)

すぐやる軽い修正ではないならコメントの改ざんに当たるのかなと、あとすこしだけ思うのは真ん中の取り消し線だと元の文章がわかりにくかったり、非対応のUAだと取り消しだとわかりにくい[2]のが気になったり -- 221.118.96.231 2019年1月4日 (金曜) 10時04分

  コメント 「てにをは」や誤字の修正、軽度の文言修正(文意を変えない程度)ならば、他利用者のコメントが付いていない限り、後者をよく使います。コメントが付いていたり、大幅な修正であるときは前者のみですね。どちらにせよ、修正した旨文末に補記したり、修正した旨要約欄に残します。「コメントして抗議を受けて元のコメントを修正した」という場合、後者の方法で修正した場合、皆が変更履歴を一つ一つ確認していれば経緯はわかりますけど、皆が皆変更履歴を見るわけではありません。なので、変更履歴を見ない人から見れば「何故このような抗議をしているのだろう? 抗議で指摘している部分はないのに。」となり、公正ではありません。抗議を受けて自分の元のコメントを修正する際に後者の方法を使う方は、不公正な行いを行っている可能性を意識していただきたいですね。--森藍亭会話) 2019年1月4日 (金) 12:23 (UTC)

  コメント HTML5およびXHTML1.0でセマンティックウェブの観点から言えば取り消しにはdelタグ、追加にはinsタグを使うのがよさそうです。このあたりの記法は時代や観点によって推奨されるものが変わると思います。テキストで説明するやり方は時代を隔てても問題が少なそうです。本題のコメントの変更については、他の方が既に述べているように、投稿直後の修正で他の人のコメントが無い場合以外では過去のコメントを変えるべきではありません。 --Naggy Nagumo会話) 2019年1月5日 (土) 00:04 (UTC)

  コメント 場所・内容・状況などにもよると思います。取り消し線などで訂正の履歴を残す方法は正確で誤解を招きませんが、多用されると視認性が悪くなり逆にコミュニケーションの妨げになったり誤読を誘引する場合もあると思います。意見対立を含む議論の中で、既に話題の焦点となっている箇所を遡って訂正するような場合には、取り消し線で直さないと訂正箇所以降の議論が意味不明に見えてしまい、対話相手から抗議される場合もあります。しかし明らかに単なる誤字脱字や、多少の表現見直し、複数列挙した出典を見直して増減させたい場合などで、特に書いた直後などは、私は取り消し線などは使用せずに修正して、要約欄に「失礼、誤字訂正」などと書いています(しかし稀に抗議され謝った事もあります)。つまり機械的なルール化は困難で、程度問題で、個人により幅もあるのが実際かと思っています。Rabit gti会話) 2019年1月12日 (土) 16:44 (UTC)

モジュールのカテゴリ編集

モジュールカテゴリをつけるとき、サブカテゴリの整備ができておらずほとんどの場合Category:ウィキペディアのモジュールを付けざるを得ない状況になっています。そこで、Category:ウィキペディアのテンプレートWikipedia:テンプレート・モジュール作成の目安を参考にサブカテゴリを作ろうと考えています。影響が大きくなりそうなので皆様の意見を募集します。--プログラム会話) 2019年1月4日 (金) 02:02 (UTC)

  具体的にどういう階層でやるのかを提案しないとコメント付かないかと思います。--アルトクール会話) 2019年1月9日 (水) 11:59 (UTC)
  そもそもカテゴリを付記したモジュール自体がごく少数ですから、先に全モジュールにドキュメント(と、カテゴリ)を付記するところから始めないと始まらないと思いますけども。参考:特別:前方一致ページ一覧/モジュール: / 言っちゃなんですけどケタ違いの数がありますよ?--Nami-ja [会話 履歴] 2019年1月9日 (水) 15:42 (UTC)
  追記 ちょっと舌足らずでしたので追記しますが:
  1. 基本的にモジュール(Wikipedia:Lua)はmw:Extension:Scribuntoの仕様により単独で動作する汎用モジュールはごく少数に留まり、殆どが既存テンプレートから呼び出されて使用されている
    • 殆どのモジュール/サブモジュールが特定テンプレート専用として設計されており、汎用化する意図が最初からない場合が多い(Wrapperが固定で他から呼び出せない仕様など)
  2. モジュール自体が上述のように莫大な数が既存であり、またモジュールページにカテゴリを記入してもカテゴリリンクとして機能しないため/docページを作成しそちらにカテゴリを付記する必要があり、数が多くまたdocページが既存でもカテゴリが付記されていないものが大半でカテゴリ付与対象を精査する必要性もある
    • つまり個人でせこせこ作成して実現可能な分量を大幅に超過しており、実現前提の全モジュールカテゴリ付与自体が難事、bot作業を視野に入れる必要あり
  3. 1.の通り、既存テンプレートカテゴリと密接に関係しているためカテゴリツリー自体をテンプレートカテゴリと相互化する必要があるかもしれず、カテゴリ分類しても特定テンプレート専用モジュールではカテゴリ分類する意味そのものが不明で作成・付与する目的が曖昧
…という感じの提案実現に対する問題(障害)が割とたくさんあるように思われ、ここら辺の実現に向けての問題点をクリアするための方策を「提案者さんの方から率先して」先ず雑感などで結構ですので「実現に向けて他の方の合意を得るために」説明するのが筋ではないかな、と思います(Wikipedia:説明責任)。--Nami-ja [会話 履歴] 2019年1月10日 (木) 03:00 (UTC)

モバイル版メインページ編集

以前ノート:メインページで類似提案があった模様ですが、長すぎるという理由がありましたので、風物詩コーナーを掲載終了し、強化記事を新規連載することにしませんか?長さ的には短い英語版よりは長いものの、フランス語版とドイツ語版よりは短く収まる模様です。--126.199.129.88 2019年1月4日 (金) 03:21 (UTC)

モバイルでだけ非表示にすることもできますよ。--タバコはマーダー会話) 2019年1月4日 (金) 03:39 (UTC)

休刊した雑誌の連載中テンプレート編集

自分が気がついた範囲で、Template:ARIA連載中Template:コミック・ダンガン連載中は休刊しているのですが、連載中ではなくなった雑誌・サイトの連載中テンプレートはそのままにしていてよかったですか?対処する決まりはありますでしょうか?--240B:12:3180:5B00:B952:E889:3CBA:CBEE 2019年1月4日 (金) 07:42 (UTC)

  ざっと運用方法がどこかにないかを探してみたんですがないんですよね。2008年ごろに現在の「書式フォーマット」が話し合われた形跡(プロジェクト‐ノート:漫画/連載中テンプレートのフォーマット)はみつけたのですが。対処方法については決められてはいませんが、ほかのナビゲーションテンプレートの運用から考えて、ナビゲーションの役割を終えた→テンプレートの廃止({{廃止されたテンプレート}}の付与)となると思われます。廃止されたテンプレートの運用上、議論先付与が必ず必要となるため、まずプロジェクト:漫画で休・廃刊された雑誌の連載中テンプレート運用について議論を行って(PJ漫画はノートをサブページ化する決まりになっています)、合意形成後に議論先をすべてそこにリンクするようにしてしまえば休・廃刊が行われた段階で自動運用にしても問題ないかと思われます。--アルトクール会話) 2019年1月4日 (金) 08:44 (UTC)
  コメント - 素朴な疑問なのですが、連載中の一覧テンプレートが休廃刊によって無用になるというのがよく分かりません。別に休刊になったとしてもそれはそれで「休刊時の連載作品一覧」になるだけですし、その時点での雑誌の陣容を示すナビゲーションとしての役割は失っていないのでは。休廃刊後に連載作が別雑誌に移籍を繰り返してテンプレートが増えることを懸念しての対応なのでしょうか(スポーツの団体テンプレートとかはそれで選手記事にテンプレがどんどん増えていくことが想像できますが、漫画作品だとそこまで膨れ上がることはそうそうないような)。--ButuCC+Mtp 2019年1月4日 (金) 10:32 (UTC)
  コメント そもそも、「連載中」テンプレートは連載終了作品が除去されます(Template:週刊少年ジャンプ連載中Template:アフタヌーン連載中などをご確認ください)。また、ナビゲーションされなくなるので連載終了後には作品ページでも連載中テンプレートは除去されます。連載中テンプレートは「全作品一覧」ではないので、連載作品がゼロ(休・廃刊)になれば「テンプレート内に表示するものがない」ことになります。連載中テンプレートの存在意義が特に何か議論されて定義されているわけではありませんが、現状の運用方法では「その時点において同一雑誌内で連載されている作品を横つなぎで案内する」のが目的です。その時点で雑誌が存在しえないなら、そもそも存在意義がありません。仮に「休刊時の作品一覧」としてのナビゲーションに存在意義をみるならば、例えば少年 (雑誌)など、ウィキペディアのページがつくられた時点で雑誌自体が休刊しているもので、Template:少年連載中が作れるという話になってしまうので、それはそれでおかしな話になりませんか?--アルトクール会話) 2019年1月4日 (金) 10:50 (UTC)
なるほど、つまり少なくとも現行PJでは「その時点において同一雑誌内で連載されている作品を横つなぎで案内する」を「休刊時点において同一雑誌内で連載されてい作品を横つなぎで案内する」に置換えて残す方針ではないという事ですね(全作品一覧を求めるのはまた別の話だと思います(そしてそれはカテゴリでいい)。私が着目したのはあくまで休刊時の「一時」の状態だけですから、「少年」休刊時の一覧テンプレを作ること自体は特に問題はないと思います。もちろんPJの方針としてカバーするなら、という話なので、現行そういうのは作らないという事に異論はありません)。--ButuCC+Mtp 2019年1月4日 (金) 11:09 (UTC)
  PJ漫画自体で運用方法が議論されているわけではありません。ただし、現行運用方法がそのようになっている以上は、休刊時点では「連載ゼロ」になるから、テンプレートとして役目を終えてますよね?という話です。この手のナビゲーションで別分野でいくと、日本のプロ野球の監督・コーチ・選手のナビゲーション(例:Template:東京ヤクルトスワローズ)がありますが、例えば、2019年にその球団がNPBから脱退して、チームとして廃止されたときに「廃止時点の監督・コーチ・選手」のナビゲーションとして存置させるの?という話と近いです。現状の運用方法では各年のナビゲーションを用意するのもおかしな話ですから、「休止段階に限って」特別措置のように存置させるのはおかしいでしょう?となるわけです。もちろん、各プロジェクトが何らかの意図をもって「休・廃止段階でのナビゲーションは、ほかの時点におけるナビゲーションよりも優越しなければならない理由がこれだけある」と結論付けて存続させるなら話は別です。--アルトクール会話) 2019年1月5日 (土) 04:39 (UTC)
質問者です。どういう形で合意形成をとればいいのかよくわかっていないのですが、プロジェクト:漫画のノートページでサブページ化して議論するとしてその後にどこからその議論にリンクをはったらいいですか?{{廃止されたテンプレート}}を貼るのには(同時にCategory:連載中のテンプレートの撤去するのには)前段階として議論が必要だと解釈したのですが(そもそもこの解釈であってますか?)、その議論で合意形成後に議論先をすべてそこにリンクするというのがどうしたらいいのでしょう。自分としては{{廃止されたテンプレート}}を貼るという方法が知れたのでそれだけならできそうですが、そのための議論だとか、休刊時のテンプレとして残すかどうかの議論だとかは、ちょっと自分のできる編集能力でカバーしきれないことであると感じます。--240B:12:3180:5B00:24B9:48B5:8008:D7BD 2019年1月5日 (土) 10:28 (UTC)
  サブページ化についてはPJのほうでもやってくれるので、まず議論としてプロジェクト‐ノート:漫画に新しいセクションで「旧・廃刊された雑誌の連載中テンプレートの扱いについて」の議論を立ち上げて議論を行ってください。誘導は{{告知}}を使って、ひとまず対象テンプレートに告知を出して議論誘導してください。提案内容はお任せしますが、廃止されたテンプレートの付与が前提であれば、「テンプレートの廃止・除去手順、現段階における対象テンプレート、なぜ廃止されたテンプレートで対応するべきなのか、廃止後のテンプレートのカテゴリをどうするか」が提案内容に含まれる必要があります。そこで、Wikipedia:合意形成を行ったら、適当な場所にその合意内容をまとめて、廃止されたテンプレートの引数「議論ページ」で誘導できるようにします(例:Template:セ・パ交流戦優勝監督)。議論を進めていくにあたって、実際の廃止となった段階で、議論参加者など誰かに手伝ってもらうというのもありです(記事の改善につながるため)。継続的に利用できるルールを作るのであれば、Category:連載中のテンプレートの上部にそのルールを告知して、休・廃刊されて以降に適用できるようにしておけばよいでしょう。--アルトクール会話) 2019年1月5日 (土) 12:00 (UTC)
告知案を考えてみたのですが、質問時より後に気づいたこともあったのでそれを加えてみたら、やや何を議論したいのかわかりにくくなってしまった気がするので、確認していただけませんでしょうか。以下の文面です。「旧・廃刊になった雑誌・サイトの連載中テンプレートについて、対処法を井戸端で相談したらこちらでの議論を推奨されました。連載中ではなくなったということを鑑みるに、ナビゲーションの役割を終えたことからテンプレートを廃止にするという意図で、{{廃止されたテンプレート}}の付与が妥当だとご指導いただきました。付与の際には、Category:連載中のテンプレートも除去がふさわしいと思うのですが、{{連載中のテンプレート注意}}についても同様の対応でいいものでしょうか。廃止されたテンプレートのカテゴリを辿ったら、前例としてすでにTemplate:月刊IKKI連載中Template:月刊コミックブンブン連載中Template:週刊コミックバンチ連載中Template:スーパージャンプ連載中Template:ビジネスジャンプ連載中が{{廃止されたテンプレート}}を付与されており、Category:連載中のテンプレートも除去されていましたが、{{連載中のテンプレート注意}}については対応が統一されていませんでした。前例の5カテゴリの他に、新たに旧・廃刊になった雑誌・サイトはTemplate:ARIA連載中Template:コミック・ダンガン連載中Template:月刊少年ライバル連載中Template:コミックガム連載中があります。」--240B:12:3180:5B00:24B9:48B5:8008:D7BD 2019年1月5日 (土) 14:31 (UTC)
  インデント整理しました。その文案でよいかと思います。最終的に「休・廃刊された雑誌の連載中テンプレートの運用方法を決めたいのでコメントください」というのが伝わればOKです。あと、議論するときにはIPだと遷移してしまうので、アカウントを取得してからのほうが、よいかもしれません(アカウント取得は任意です)。--アルトクール会話) 2019年1月9日 (水) 11:57 (UTC)
質問者です。確認ありがとうございます。少し修正して「プロジェクト‐ノート:漫画」に話題を追加し、告知貼りました。目にとまった方はコメントよろしくお願いしますm(_)m(アカウントの作成は議論するときは役に立つと思うのですが、普段はちょっと加える程度の編集しかしないので任意であればやめておきます。お気遣いどうもです。)--240B:12:3180:5B00:A4C7:3DBB:922F:566D 2019年1月9日 (水) 13:14 (UTC)

最近まで公開していた生年月は個人情報か編集

記事竹下誠二郎の話です。記事本人の家族を称する利用者が、生年月を初めとする幾つかの記述を除去する編集を行っています。

この人物の生年月は、勤務先HPのプロフィールページに記載されていたのを確認したのですが、今年になって削除されているようです。疑問が2つ--

  1. 生年月(日は不明)は保護すべき個人情報なのか
  2. 最近まで公開していた情報を情報出典元が削除した場合、本人が公開していない個人情報としてwpの記事も削除(あるいは除去)すべきか

以上どうでしょうか。--Asgawaji会話) 2019年1月5日 (土) 12:50 (UTC)

2について、情報出典元から該当情報が引っ込められた以上は、検証可能性に欠くことになりますので、除去する他はないと思います。家族を称する利用者は、現在のところ削除まで望んでいるわけではなさそうなので、そのままでよいと思います。--ZCU会話) 2019年1月6日 (日) 11:32 (UTC)
コメントありがとうございます。ウェブアーカイブサイトでは検証可能性は満たさないでしょうか。--Asgawaji会話) 2019年1月6日 (日) 11:39 (UTC)
  コメント Wikipedia:存命人物の伝記#誕生日のプライバシーに則って編集すれば良いかと思います。1としては、「保護すべき個人情報」には入るかと思います。ただし本人が積極的に公表していることが確認できるのであれば(本人や所属機関の公式Webページに掲載されている、著作の著者略歴に記載されている等)、根拠となる信頼できる情報源を示したうえで載せるべきかと思います。2についてですが、Wayback Machineに残っているのであれば検証可能性上は問題ないように思います(Wikipedia:出典を明記する#リンク切れの回避と修復の記述でも、リンク切れで検証不能とみなすのはアーカイブも存在しない場合に限られる)。過去に本人が積極的に公開していたことがWayback Machineで検証できるのであれば、過去の公表されていたこと自体に問題点があった場合(本人の意に反して過去の所属機関に公表を強要させられたなど)がない限り、当該個人情報の削除は不要と考えます。ただ、勤務先のWebページで公表されなくなったという背景には、何らかの理由で本人または関係者が公表を控えているというわけでしょうし、その後も別の場で積極的に公表していることが明白ではない限り、編集除去はすべきと思います。--郊外生活会話) 2019年1月6日 (日) 12:17 (UTC)
除去すべきかどうかも状況次第と思います。本人は何とも思っていないが、組織の方針で所属者全員分のページから生年月日の欄がなくなった、というような状況もあるでしょう。「公式サイトから消えた」というだけでは、理由が分かりません。「非公開としました」と明言しているのであれば、多分除去すべきなのでしょうが。 --2001:240:2407:B43A:D1DF:814F:7F60:F26E 2019年1月7日 (月) 13:51 (UTC)
  コメント おっしゃるようにその可能性もあるかと思いますが、安全側に倒した判断です。当該組織以外の信頼できる情報源において(本人のパブリックなものであると確認可能なら本人のSNSなどでも構わないでしょう)しっかり言及されているなど本人が積極的に公開していることがわかるなら、そのままでも問題ないはずです。そのことが分からない限り、BLPの立場から安全側に倒すことは必要かと考えます。--郊外生活会話) 2019年1月7日 (月) 14:15 (UTC)
  コメント 非公開の希望があるのであれば、生年月日は除去がいいと思います。ただ、百科事典として考えた場合、1960年代生まれといった年代表記はできないものかとも思います。(出典提示の点が課題ではありますけど)--115.39.251.95 2019年1月8日 (火) 00:29 (UTC)

オフラインイベントの開催について(2019年1月20日)編集

今回、ウィキペディアの18回目の誕生日にあやかって、オフラインイベントを開催する運びとなりました、これまでウィキペディアの学際的な発表を中心としたWikimedia Conference Japanやウィキペディアタウンなどの地域に着目したエディタソンは多く開催されてきました。しかしながら、執筆者であるウィキペディアンにフォーカスがあてられることは多くありませんでした。今回は、そんなウィキペディアンが思い思いの「本」を紹介する、シンプルかつディープな内容で企画を1月20日に東京ミッドタウンにて開催いたします。詳細につきましてはWikipedia:オフラインミーティング/東京/ウィキペディアンが「棚から一掴み」してみたらをご覧ください。--Araisyohei (talk) 2019年1月10日 (木) 15:06 (UTC)

Template:Copyrights docの修正編集

先行議論Wikipedia:利用案内#Template:Copyrights/docの解釈。版指定削除がなく特定版削除しか方法がなかった頃の方針文書であるため、Template:Copyrights/doc#問題の無い部分まで削除されるの?の修正または除去を提案します。ライセンスについてはあまり詳しくないので、恐縮ですが皆様より広く御意見を頂きたく思います。--JapaneseA会話) 2019年1月12日 (土) 04:54 (UTC)

  コメント 修正は必要でしょうね。
  • 「GFDLライセンスで提供」⇒「GFDLとCC-BY-SA3.0のデュアルライセンスで提供」
  • 「やむを得ず一緒に削除される」⇒「版指定削除により問題記述が残る版のみ削除される(まあ、殆どの場合で連続版削除ですが)
  • 「GFDL違反後(A)の無問題編集となる投稿(B)の編集内容を他人が書き戻すと著作権侵害になる」⇒「(B)の加筆版が削除版に含まれなかった場合(滅多にありませんが)、誰でも書き戻せる」
と、仰る通り当時と現在では結構変わってるとは思います。
あと、質問にありませんがTemplate:Copyrights/doc#削除されないことになった時はどうなるの?節内に記載のある「削除依頼終了後、審議中の編集加筆内容は無視して削除依頼貼付直前版に一律的に戻される」「削除依頼審議中には一切の編集加筆を行ってはならない」も現状と異なるんじゃないかな、と思います。これは現在では単に{{sakujo}}の除去のみで対処している実態があるのではないかなと(ほんとにそうなら削除依頼提出直後に同時に全保護依頼の必要性が発生する+誰でもいつでもただ削除依頼提出するだけで記事内容の更新を全停止することが出来てしまう=一般編集者に全保護権限を与えるのと同義)。◆ただし節ごと全除去は明確に反対しておきます。明らかに弊害の方が大きいです。--Nami-ja [会話 履歴] 2019年1月13日 (日) 00:13 (UTC)
  1点。少なくはなっていますが、場合によっては特定版削除で対応する場合もあるので、ケースバイケースで文章を改めてもらったほうが良いかと思います。--アルトクール会話) 2019年1月14日 (月) 21:46 (UTC)

全保護ページの管理者による編集代行依頼について編集

Wikipedia:井戸端/subj/全保護記事が編集出来る権限についてのスピンオフ議論になります。元々、全保護ページを編集出来る権限の提案をしていたのですが、それよりも代行依頼をの意見があったので、そちらの議論を行いたいと思います。

元々、LTA:ASPEによる特定記事への粘着荒らし問題があり、アスペルガー症候群が無期限全保護。今年に入って20以上はアカウントを作っている印象で、保護解除は難しい(と言うよりも無期限全保護の正当性が成り立っている)状態です。

何処で、どの様に依頼をするべきなのか議論を行いたいと思います。とりあえずのドラフトは以下の通りです(ドラフト次第で、議論場所が変わるかもです)。

  • Wikipedia:管理者伝言板/保護ページ編集に節を設けて依頼を行う - ページ新設も手間でしょうから間借りが楽でしょう。
  • 承認済みLTAサブページがあるLTAが荒らした記事全般とする - 何処まで広げるかですが、汎用性を持たせる意味でこうしました。
  • 編集内容はLTAが荒らしている内容と無関係な物とする。 -
  • ドラフトを何処かに作成後に、管理者が転記を行う。
  • 転記した後の主筆者は、転記した管理者ではなく、元文を作成した利用者とする。

ドラフトを考える暇が無かったので、さっくりですが意見集約したいと思います。目標は今年の4月頃実施です。--Taisyo会話) 2019年1月12日 (土) 12:19 (UTC)

ウィキデータにおいて異なる用語が混同している場合の対応について編集

Wikipedia:良質な記事/良質な記事の選考/公海 20181226でも相談させていただいた件なのですが、少し話題になったというだけで明らかにあちらの議論には無関係でありましたので、再度こちらで相談させていただきたいと思います。現在日本語版の国際水域を管理しているウィキデータのd:Q25855に、日本語で言うところの国際水域に該当する用語と公海に該当する用語が混在していて、私一人では正確な分類ができない、という件です。きわめて雑な形ではありますが機械翻訳を用いてこちらに分類をしてみたのですが、ご覧いただけますとお判りいただけます通り正確な分類には程遠く、私ではどちらとも分類不能な言語まで相当数ある状況です。また仮に正確な記事名の分類ができたとしても、現にこうして混同が発生している以上「公海」という記事名で「国際水域」に関する記述をしてしまっている言語、あるいはその逆のことをしている言語が存在する可能性も否定できません。またこれだけ多くの言語となると、語学の上では「国際水域」と翻訳される言葉で日本語で言う「公海」について述べることが正しいとされている言語、またはその逆の言語が存在している可能性も否定できないように思います。その場合に厳密に正確な分類をしようとするとそちらの言語の記事内容とその単語の使用状況までを把握して改名を要するという理屈になってしまうのでしょうか。全言語あわせると当該ウィキデータの項目には47言語あります。さすがにこれを全部解する人はそうそういるものではないと思うのですが(少なくとも私には不可能)、こうした場合にどのように対処すればよいものか、皆さまのご意見をうかがうことができればと思い話題を提起させていただきました。--Henares会話) 2019年1月13日 (日) 08:54 (UTC)

  コメント とりあえずWikipedia:ウィキデータを読み解きますと日本語版での相談場所はこちらの井戸端が指定されておりますけども、ウィキデータ側にもd:Wikidata:井戸端がありまして、ウィキデータ上のリンク問題かつ修正内容の過半が他言語版リンクとなる作業でしたら日本語版の枠を超えてそちらメインの案件になるのではないかな、と感じますのでご案内差し上げておきます。──予め申し上げておきますがこちらのページは日本語が使える代わりに更新頻度はそれほど高くなく、やはり英語前提のd:Wikidata:Project chatの方が活発に意見交換されています。--Nami-ja [会話 履歴] 2019年1月13日 (日) 14:10 (UTC)
  相談先はd:Wikidata:Interwiki conflict(英語)がおすすめですが、公海(High seas)と国際水域(International waters)は英語版では同じもの扱いの記述がされていますので、違いを説明しないと反応はないかと。File:Zonmar-ja.pngに各国の訳語が記述されているので分類の参考になるかもしれませんが、図が正しいかどうかはわかりません。--Afaz会話) 2019年1月15日 (火) 02:29 (UTC)
お二人とも、ご意見ありがとうございます。私がまずJAWPの井戸端を相談の場として選びましたのは、JAWPにおいては公海国際水域の項目が数年間並立し続けていますので、Afazさんがおっしゃるような違いの説明をこの場では省くことができると思ったからです。機械翻訳でも判然としないことがある用語を、混同しているかもしれない相手に外国語で説明する、というのは面倒そうに感じましたので、この場で済ませられる手立てがもしあるのであれば話がはやいのかな、と。しかしやはりウィキデータのほうで相談しなければならないということとなりますと、"High seas"と"International waters"について英語で書かれた出典を用意しなければならないということになってしまうのでしょうか。日本語版の公海に記事には私自身がある程度かかわりましたので公海の英語の出典にはいくらか心当たりはありますが、国際水域についてはこれから調べてみますが、果たしてどうなることやら。またAfazさんにご提示いただきましたFile:Zonmar-ja.pngについて、私も良い案だと思って少し見てみたのですが、commons:Category:UNCLOS sea areasでの画像群を見てみますと、あちらでもウィキデータと同じような混同が起きているようです。ウィキデータのページにある言語の機械翻訳を眺めていると「国際海域」や「外海」といった用語との混同まで見られるような気がしてきたのでもはや私にはわけが分からなくなってきましたが、ひとまずウィキデータでの説明に必要そうな資料の調査を試みてみようと思います(コモンズでの混同は・・・ひとまず見なかったことにします)。このページにおいても引き続きご意見を募集させていただきたいと思います。--Henares会話) 2019年1月15日 (火) 10:47 (UTC)

Google翻訳の利用について編集

ウィキメディア財団がコンテンツ翻訳ツールでのGoogle翻訳の利用についてのリリースを出しています。どうやらGoogle翻訳から出力される翻訳結果が「フリーライセンス」になったという話らしいのですが・・・従来、jawpではGoogle翻訳によるものを「ライセンス違反」として受け入れて来ませんでしたが、jawpでの対応(と言うか文書などの整備)状況はどうなっているのでしょうか? それ以前に、日本語訳はまだ品質的に厳しそうですけど。

なお、Google翻訳のライセンスページを見ると言語ごとにライセンス表示が違っているようです・・・--KAMUI会話) 2019年1月13日 (日) 10:34 (UTC)

音楽作品の表記について編集

音楽作品の表記についての質問です。韓国の音楽家の楽曲などのタイトルの場合多くは

  • A:アルファベット表記
  • B:タイトルがハングル表記で副題としてアルファベット表記が括弧書きで併記されている

のどちらかのことが多く、日本語の表記などは特に決められてはいません。

この時ウィキペディア日本語版における表記としてはAの場合はそのままでいいと思うのですが、Bの場合

  1. ハングル表記を先に、アルファベット表記を括弧書きで併記(そのまま)
  2. アルファベット表記を先に、ハングル表記を括弧書きで併記(アルファベットを優先)
  3. 音楽家および所属レコード会社とは無関係な日本の販売会社などが決めた非公式な日本語訳のタイトルを使用

のうちどれが最も適切と言えるでしょうか。

私は1で構わないと思うのですが、現状では3のようになっている記事も多いです。しかし芸術作品の訳などは特にですが様々な異なる訳し方もあるというのは普通のことであり、それを個別輸入の販売会社、あるいは特定のメディアなどの表記に従って決めてしまうというのはWikipedia:独自研究は載せないWikipedia:中立的な観点に反しているのではないかと思います。

皆様のコメントをお待ちしています。--Miraburu会話 / 投稿記録 2019年1月13日 (日) 17:10 (UTC)

  • 音楽についてならばPJ:MUSIC#記事名に規定されています。--KAMUI会話) 2019年1月14日 (月) 10:23 (UTC)
    • コメントありがとうございます。タイトルという言い方が誤解を招いたかもしれないのですが(曲名/アルバム名等のことです)、今回のケースは記事名というより本文中の表記についてを想定しています。--Miraburu会話 / 投稿記録 2019年1月14日 (月) 10:56 (UTC)
      • そもそも「元の音楽家なりレコード会社と契約して日本で販売してる時点で公式」だと思いますので、3番の「無関係な〜非公式な〜」てご意見はいささか腑に落ちません(例えばAC/DCのアルバム「Flick of the Switch」の日本語タイトルは「征服者」です)。--KAMUI会話) 2019年1月14日 (月) 11:52 (UTC)
        • SONYやAvexのような感じの場合はそれでいいとお餅のですが、タワーレコードのような個別輸入の販売会社による訳の場合など元の音楽家やレコード会社の意思とは関係なく決定された邦題は正式とは言えないのではないかと思います。--Miraburu会話 / 投稿記録 2019年1月14日 (月) 14:36 (UTC)
      • 「無関係な日本の販売会社などが決めた非公式な日本語訳のタイトル」でも別に検証可能性が満たされていれば何も構うことはないと思いますが。その事例を地で行く前例に坂本九の楽曲「上を向いて歩こう」のヨーロッパ+アメリカタイトル「SUKIYAKI」があります(上を向いて歩こう#日本以外でのヒット)。まあこれは全米1位を記録した伝説の楽曲ですけど。--Nami-ja [会話 履歴] 2019年1月14日 (月) 13:43 (UTC)
        • コメントありがとうございます。ただ問題は、非公式な訳の場合は複数ある訳のうちどれを選ぶかを決めるのが困難になってしまうのではないかと言う点です。例えば適当な例でLABOUMのアルバムI'm Yoursの楽曲だとアマゾンの商品紹介ページでは「1.火をつけてくれ」「2.流れるこの歌が止まれば」「3.体温」、タワーレコードの商品紹介ページでは「1.火を付けて」「2.流れるこの歌が止まったら」「3.体温」というように微妙な違いがあり、販売会社の間などでも統一されていません。出典を付けて複数の表記の例を併記するというのも考えられますが、それは見映え的にもどうなのかなと言う点が懸念します。--Miraburu会話 / 投稿記録 2019年1月14日 (月) 14:36 (UTC)
          • 「販売会社の間などでも統一されていない事実」=「特筆性」ではないかと思うのですが。我々、どこの誰とも解らぬ匿名編集者ですから「日本音楽史上どれが真に相応しいタイトルか」の決定は外部の識者にお任せして、複数のタイトルがあり統一されていない状態が検証可能な事実として現に存在しているのであれば単に{{暫定記事名}}を貼付し「日本公式では未だ統一されていないことを読者に先ず解説すること」(両論併記)が妥当かな、と思います。 / 見栄え云々で検証可能な事実/日本公式名称決定に関する歴史的経緯(の最中)を隠蔽しちゃダメではないですかね?--Nami-ja [会話 履歴] 2019年1月14日 (月) 15:38 (UTC)
            • Miraburuさんが挙げた「I'm Yours」ですが、LABOUMのそれはアルバムじゃなく「シングル」では? jawpのグループ記事では「シングルアルバム」とかいう謎の言葉になってますけど。
              なお、ジェイソン・ムラーズの2008年のアルバム「ウィ・シング。ウィ・ダンス。ウィ・スティール・シングス。」からシングルカットされた同名曲があり、日本語版では単独立項されていませんがアメリカのビルボードだけでなくフランスやイスラエル、スウェーデンやベネズエラなど9カ国で週間チャート1位、イタリアとスウェーデンで年間チャート2位という大ヒット曲です。PJなどを考慮するなら曖昧さ回避でアイム・ユアーズを作成してこちらへのリダイレクトとしてI'm Yoursを設置、そのシングル記事については(エルヴィス・プレスリーの曲やリンダ・クリフォードの1980年のアルバム、リンダ・デイビスの1998年のアルバムが存在するので)もし作成するならアイム・ユアーズ (LABOUMのシングル)を当てるべきでしょう。
              ただし、朝鮮語版を見ても単独立項されてないので(グループ記事で言及)、jawpでも単独立項の必要性が無いのでは無いかと思いますけど。--KAMUI会話) 2019年1月14日 (月) 21:47 (UTC)
  • 議論がずれています。まず、Kpopは少女時代の「소원을 말해봐」(英語題:GENIE)のように、韓国語と英語の両方で曲名が付けられることが多く、最初から正題が複数存在するという前提があります。そして、提案者がもっとも主張したいのは日本で正式発売されておらず、邦題が存在しないはずのKpopの楽曲に対して、wikipedia日本語版編集者の判断で勝手に邦題がつけられてしまう現状を憂慮してのものであると考えられます。また、提案者のいう販売会社(Amazon・楽天などの輸入盤販売ページ、iTunesなどの音楽配信サイト)や、wowkorea・KstyleのようなB級韓流メディアが便宜上勝手に付けた邦題が出典として認められるかも問うているのだと思われます。例としてAileeのディスコグラフィに 「첫눈처럼 너에게 가겠다(初雪のように君に行く)」「노래가 늘었어(歌がうまくなった)」「손대지마(触らないで)」と記述されていますが、JASRACに副題として登録されている「初雪のように〜」以外は公式な邦題ではなく読者向けの翻訳であり、本来ならTemplate:翻訳を用いて「노래가 늘었어 →歌がうまくなった」とするか、「손대지마」(日本語で「触らないで」の意)のように記述するなど、読者が公式な邦題と誤認しないよう配慮する必要があります。あるいは多くの日本語話者が理解可能な英語題のみで「Singing got better」「Don't Touch Me」、JASRACに登録された副題「ノレガヌロッソ」「ソンデジマ」を用いる案もあります。--Hirewean会話) 2019年1月16日 (水) 01:32 (UTC)
    • Hirewean様、論点をまとめて頂き本当に感謝します、ありがとうございます。Template:翻訳については初めて知りましたが、確かにこれらの方法であれば読者向けの翻訳でも誤解はなくなると思います。一方でJASRACの邦題を用いるのも良案だと思うのですが、副題が登録されていない曲も多いのが難点のように思います。またハングル表記が正題のものも多いため、一応ハングル表記も残しておいた方がいいようにも思います。--Miraburu会話 / 投稿記録 2019年1月17日 (木) 09:23 (UTC)

他人の編集の修正について編集

  質問 ある利用者が出典を挙げたうえで記事を執筆しておられたのだが、内容が明らかに事実と異なる場合、どうすればよいかご教示いただきたい。その利用者が執筆しておられる内容は、現行法令上、明らかに事実と異なっている。また、その利用者が挙げている出典元には、そもそもそのような内容は全く書かれていなかった。私はその記事の記述を基に戻したうえで、その記事の上部の「ノート」と書かれているタブのような部分をクリックし、「Template:報告」というアイコンマークを付け、なぜこの執筆内容が問題なのかについて、現行法令上、事実と異なる記述であることと、出典元にそのような記述はないことの2点を挙げて説明させていただいた。このような対応に問題はありますでしょうか、また、より望ましい対応があるでしょうか。ご教示いただきたい。--さたでーないとふぃーばー会話) 2019年1月14日 (月) 05:45 (UTC)

訂正した内容も、またノートにその旨を告知したことも問題ありません。むしろ見習うべき適切な対処であったと考えます。--240F:65:8556:1:45B4:B2E1:45B2:31B3 2019年1月14日 (月) 15:01 (UTC)

これらはチェックユーザーの対象になりますか編集

サブページ作成の都合でセクション名の変更と構成を変更しています。また、絵文字を記号に置き換えしています。--アルトクール会話) 2019年1月17日 (木) 03:55 (UTC)

「ログインしただけ」もチェックユーザーの対象になりますか?編集

サブページ作成の都合でセクション名の変更と構成を変更しています--アルトクール会話) 2019年1月17日 (木) 03:55 (UTC)

私はスマホを使えるようになり、スマホから編集しようとしました。ところがwifiも使えることから、それを利用してログインして編集しようとした矢先に、「このipはブロックされています」という表示を見ました。その時点では気にせず、ログインしましたが、土壇場で「あれ?もしかしてブロック回線にログインってやばいんじゃね?」と弱気になり、編集する前にすぐにログアウトしました。

元々、ウィキペディアが創設されてから長らくサイトを見てきただけに、それなりにシステムに詳しいほうだと自負していますが、わからないところも流石にあります。

特にブロックされた回線は記録に残りやすいシステムがあるもわかっています。ブロックされたアカウントがその回線を使用したら自動ブロックで引っかかるなど。

そこで思ったのですが、ブロックされた回線にログインしただけでも完全にアウトでしょうか?

チェックユーザーと呼ばれる方が、特に詳細に調べているというのも知っていますが、

チェックユーザーの説明文では、

チェックユーザーが知るのは ある利用者が編集に使用した接続元の IP アドレス ある IP アドレスから行われた編集(ログイン状態での編集を含む) ある利用者がウィキメールを他の利用者に送信したかどうかとその日時。相手先のメールアドレスと利用者IDは見えません。

と書かれていますが、第一項目の「ある利用者が『編集に使用した接続元の IP アドレス』」という部分が引っかかりました。 これは「編集をするために『ログインさせてもらったIPアドレス』」という意味になり、何度も述べた「ログインしただけでアウト」ということになるでしょうか?

ログインしたのは事実なので「それだけでアウト」になるなら構いません。ただ、やはり自分としては気になってしまいます。 チェックユーザーは「この回線に利用者Aが(編集はしてないけど)ログインしたのはチェックユーザーでわかる!」みたいになるでしょうか?

今までは自動ログイン状態にしていましたが(ただし、何らかの微異なエラーでログアウトされていることがあり、今回の事例でもあります。)、wifiを使うようになったのはごく最近のことで、またこれからはwifiを利用する機会は非常に多いので、其のたびにブロック回線に引っかかり、「この回線にログイン記録があるから、こいつ怪しい!」みたいに逐一疑われると、正直怖いので・・・。

個人的に不安がありすぎて私情を挟みすぎ、冗長になっている自覚はありますが、率直に私が知りたいのは「チェックユーザーは編集をしていなくても、その回線にログインしただけで、その回線から利用者を確定することができるか、どうか」です。「編集すればIPアドレスの記録に残り、チェックユーザーは調べることができるけど、ログインだけならIPアドレスの記録に残らず、チェックユーザーは調べもしないし、引っ掛からないから大丈夫。だから自動ログイン状態でも平気だよ」となるなら、気は楽になります、もちろん事実が事実なら、たとえ自分に都合が悪くても受け入れますが。--12連想マグア会話) 2019年1月16日 (水) 09:17 (UTC)

  •   コメント MediaWikiのWikiにCheckUserツールの詳細がありますが、「scans recent changes」ということで、編集に伴うログしかチェックユーザーでは拾えないようです(そもそも、「閲覧をブロック」という制度もありませんし)。--Jkr2255 2019年1月16日 (水) 11:06 (UTC)

コメントありがとうございます。 「編集しなければ大丈夫」と受けとりました。 あと、ついでなのでもう1つ質問します。--12連想マグア会話) 2019年1月17日 (木) 03:30 (UTC)

これもチェックユーザーは調べることが出来ますか?編集

私はアカウント作成をするときに「アカウントエラー」の表示が出て驚きました。 調べてみると、そのIPアドレスはブロックされていたものでした。

けれど、契約会社の関係でIPアドレスが二つあったこともあり、実際にブロックされていない、もう1つのIPアドレスでアカウントを作成しようとしたら

「この IP アドレス (二つ目のIPアドレス) を含む、IP アドレス範囲 (最初にアカウントを作ろうとしたIPアドレス) からのアカウント作成は、○○○によってブロックされています。」

という表示が出ました。

驚いて数日間はそのままにしてましたが、たまたま、このことを忘れている状態でアカウントを作る気になり、1つ目のアドレスではアカウント作成が出来なかったから、二つ目のアドレスで作ろうと思い、アカウントを取得するに至りました。

唐突に言っても伝わらないと思ったので、長々しくなりながらも前説をしましたが、

一番思ったのが 「この IP アドレス (二つ目のIPアドレス) を含む、IP アドレス範囲 (最初にアカウントを作ろうとしたIPアドレス) からのアカウント作成は、○○○によってブロックされています。」という経緯から

私のしたことは 「一番目のアドレスでアカウントエラーした状態で二番目のアドレスからアカウント作成しようしたことで接点を作ったこと」になってしまい

上の質問でも述べたような、チェックユーザーが調べたら「アカウントエラーの経緯から一番目のアドレスと二番目のアドレスに接点があるのが分かった」みたいになりますか?

もし、わかったら 「ただでさえ、ブロックされた一番目があるのに、この経緯で二番目も一番目の関係者みたいに思われたらどうしよう・・・」となりました。

最初に述べたように私自身がブロックに迷惑をかけられましたが その私が「他者がブロックされる切っ掛けを作ってしまったかも」となり怖くなりました。

上でも言いましたのを要約すると 「一番目でアカウントエラーした状態で二番目のアドレスからアカウント作成しようとした事実」はチェックユーザーが調べたら分かることでしょうか?

チェックユーザーの方々は接点を見付けるのが上手いと聞きます。

それで自分がブロックされたIPから違うIPに接触したことで、本来関係ないはずの違うIPにチェックユーザーから白い目で見られて迷惑をかけてしまったとなりそうで。--12連想マグア会話) 2019年1月17日 (木) 03:32 (UTC)

あまりにも独特的な状況なのは認めています。 なので、実験的な感じでブロックされているwifiからアカウント作成のボタンを押してエラーをした状態で違うIPアドレスからアカウント作成のボタンを押せば表示が出てくるので、おそらく言いたいことが伝わると思います。--12連想マグア会話) 2019年1月17日 (木) 03:38 (UTC)