「Wikipedia:井戸端/history20230304」の版間の差分

リンクを追加
履歴の双方向閲覧
← 古い編集新しい編集 →
削除された内容 追加された内容
ビジュアルウィキテキスト
編集の要約なし
bot: 掲載期限切れの話題の除去
5行目: 5行目:
{{ 井戸端サブページ | title = 曖昧さ回避の対象が外国語版のみの場合 }}
{{ 井戸端サブページ | title = 曖昧さ回避の対象が外国語版のみの場合 }}
{{ 井戸端サブページ | title = ネーミングライツを記事名へ反映するかしないか }}
{{ 井戸端サブページ | title = ネーミングライツを記事名へ反映するかしないか }}
{{ 井戸端サブページ | title = 寄付お願いのメール等に関するjawpからの要望など（あれば）2020 }}
{{ 井戸端サブページ | title = LTA:NDBTKによる動物虐待にかかわる書き込みについて }}
{{ 井戸端サブページ | title = LTA:NDBTKによる動物虐待にかかわる書き込みについて }}
{{ 井戸端サブページ | title = 過去の慣例はどこまで重視されるべきか }}
{{ 井戸端サブページ | title = 過去の慣例はどこまで重視されるべきか }}
16行目: 15行目:
{{ 井戸端サブページ | title = 「Wikipedia‐ノート:記事名の付け方」について }}
{{ 井戸端サブページ | title = 「Wikipedia‐ノート:記事名の付け方」について }}
{{ 井戸端サブページ | title = 「Wikipedia:連絡先/記事の問題/本人より」について }}
{{ 井戸端サブページ | title = 「Wikipedia:連絡先/記事の問題/本人より」について }}

{{ 井戸端サブページ | title = テンプレートの活用度合いを把握するにはどうすればいいですか }}
{{ 井戸端サブページ | title = テンプレートの活用度合いを把握するにはどうすればいいですか }}

{{ 井戸端サブページ | title = 返信ツールをベータ機能として導入する提案 }}
{{ 井戸端サブページ | title = 返信ツールをベータ機能として導入する提案 }}

2020年8月17日 (月) 15:15時点における版

井戸端は、ウィキペディア日本語版について、運営、方針、新しいアイディアや作業の仕方、その他様々な事で質問や提案、議論、意見交換を行う場所です。詳しくはWikipedia:井戸端/ヘルプをご覧ください

This page is for discussion of Japanese Wikipedia, normally in Japanese. But see also Help for Non-Japanese Speakers. If you want to just inform Japanese Wikipedians of something, you can use Wikipedia:お知らせ.

ここに質問を投稿する前に
他に適切な場所があるもの
ウィキペディア全体に関して
個々の専門分野に関して
個々のページに関して
個々の利用者（アカウント）に関して
以前の議論を検索する
  • 井戸端タグについては井戸端タグの説明文書をご覧ください。
  • 井戸端ウォッチリストではサブページを含めた井戸端の投稿状況が確認できます。
  • 以下は、►（右向き三角）のクリックによって期間ごとの話題がツリー表示されます。
運営方針
  • 投稿された全ての話題はサブページに移動し、Category:井戸端の話題にカテゴライズされています。
  • サブページは、最新の投稿から10日間経過するか、最初の投稿から30日が経過すると、井戸端への読み込みが解除されます。
投稿しましょう
新しい話題を投稿する
最後にもう一度「ここに質問を投稿する前に」を確認して問題がなければ、初心者は新しい節を追加して、経験者は新しいサブページを作成して投稿してください。

Botで大量にコモンズへ移動された画像のファイル1-5による即時削除への対応について

MGA73さんが運転しているMGA73botによって、大量の画像がウィキペディア日本語版からコモンズへ移動されています。移動自体は方針に適合したものですが、その結果、非常に大量の画像が即時削除依頼されており、この非常に大量の即時削除依頼にどう対処したらいいか、いいアイデアはないでしょうか？

状況としては、

  1. Category:コモンズへの移動により即時削除対象となったファイルには、現在 2,277 ファイルあります。今回の件と無関係の依頼も一部含んでいますが、ほとんどがMGA73botによるものです。
  2. 移された画像の投稿者は、Bakkaiさん、Tokatsu Kokubuさん、Qwert1234さんの3人のよう。
  3. 移動は、FileImporter (mw:Extension:FileImporter, commons:Commons:Upload tools#FileImporter) というエクステンションを使っているので、初版投稿からの履歴含めて丸ごとコピーされています。
  4. 元々の画像は{{GFDL}}でライセンスされています。ファイルインポートに伴ってコモンズ側のページでは cc by-sa 3.0 も付加されています。何件か確認しましたが、ライセンス更新条件は問題なく満たしているようです。

考えられる対応策としては、

  1. 機械的に即時削除要件を満たしているかジャッジできそうなので、Botや(もしあるなら)その他自動機能を使って対応する。ただし、現在のウィキペディア日本語版で削除権限を持つBotは存在していないのでどうするか。
  2. 管理者と削除者のみんなで、人力でコツコツ対応する。この井戸端の話題提起は、そのお願いというか告知みたいなものも兼ねています。

--Yapparina（会話） 2020年7月26日 (日) 23:13 (UTC)[返信]

  • コメント 元々から、WP:CSD#ファイル1-5は機械判別＆対応しやすいように単純化した条項を目指していたのもあり、技術的には自動化が可能だと思います。それがBotアカウントなのか、権限持ちに提供されるガジェットなのか何が良いかという問題は別途ありますが多分些細なことです。FileImporterが登場したおかげで、より判別しやすくなった（FileImporterを使っていればほぼ自動的にSD要件は満たされている）とも言えます。一方で、「技術的には可能」と言ったのは、そのようなツールが今現時点では存在していないという意味でもあります。時間さえあれば私でもできるんですけどね…。誰か作って欲しい…。--青子守歌（会話/履歴） 2020年7月26日 (日) 23:24 (UTC)[返信]
  • コメント 確かにBotでチェックできるのが一番楽ですが、現状それができないので、臨時の削除者を置くのがいいのではないでしょうか。--Mario1257（会話） 2020年7月27日 (月) 16:19 (UTC)[返信]
  • コメント 自分も臨時削除者を置くのがいいと思います。通常削除依頼への対応、次々と現れるソックパペットの駆逐、etc...対処すべき問題を常に多数抱えていらっしゃるのに、さらに2350ファイルを四十数人力を合わせて地道にコツコツ消していく、というのはかなり酷だと思うんです。ぷりぷりむすめ 2020年7月28日 (火) 05:40 (UTC)[返信]
  • 大量にあるということは分かりましたが、大量にあってもあまり気にしなくていいのではないでしょうか。具体的に何か弊害があるのでしょうか。移動されたファイルは権利侵害等と違って緊急性はないので、できる人ができる時にできる範囲で、ということで、長期間かかったとしても誰も困らないのではないかと思います。特に、「臨時削除者」の措置が必要なほどの緊急性があるかどうか疑問です。もし「Category:コモンズへの移動により即時削除対象となったファイル」のなかにも、特別に緊急性の高い案件があってそれらが埋れてしまう、といった問題があったりするのであれば、必要なのはサブカテゴリかもしれません。 --2001:240:2413:C90A:E80D:A3B5:C9D8:CC09 2020年7月28日 (火) 10:21 (UTC)[返信]
はい、特に緊急性はないです。「機械的に判別できそう + 大量にある」という案件なので、普通に対処する以外の何かうまいやり方があったりしないかなと思いまして、相談を立ち上げてみました。
そういうわけで、臨時削除者という案をいただきましたがその案は難しいと思います。臨時削除者というのが具体的にどういうものか次第な部分もありますが、緊急性がない案件なのでビューロクラットが手続きすっ飛ばして裁量で権限を付与するといったような行動は取れないでしょう。--Yapparina（会話） 2020年7月28日 (火) 12:57 (UTC)[返信]
  • コメント 少し気になった動作がありました。例としてファイル:NTT west japan kyushu hospital 1.jpgなのですが、2009年以降にカテゴリーの追加した関係で、ライセンスの判定テンプレートを入れました。その後、画像情報を概要枠に入れ込むのは問題ないのですが、ライセンス判定テンプレートをあえて外すような動作が見られます。ライセンス判定テンプレートをあえて外すような動作は余りよろしくないのではと思うのですが。--Taisyo（会話） 2020年8月2日 (日) 22:45 (UTC)[返信]
返信 (Taisyoさん宛) コモンズ側の方針によりjawpから移籍されるファイルはGFDL単体の場合GFDL-jaに置き換えなければならないこと、コモンズでの再ライセンス対象（条件は日本語版ウィキペディアと同じ）となっているファイルは{{GFDL-ja|migration=relicense}}にしておけばコモンズ側で最初からcc-by-sa3.0とのマルチライセンスにできるという都合上、あえてこっちで更新判定のテンプレートを外しています。ぷりぷりむすめ 2020年8月5日 (水) 03:44 (UTC)[返信]
もう一つ、利用者:Saigen Jiroさんのノートで、「ローカル版の即時削除を望まない」と明言がありました。このような希望を取り入れるのか、説得してまで消すのか。ライセンス問題だけではなく感情的なトラブル回避もある程度はと思うのですが。私は聞き入れて、削除しない方を取りたいですが。--Taisyo（会話） 2020年8月2日 (日) 22:53 (UTC)[返信]
Saigen Jiroさんの例を一般化するなら、そういう意志を表明するファイルページ用のテンプレートを作って、カテゴリ分類もして、それらのファイルは即時削除対象外という運用にしたらいいんじゃかな。そういうファイルについては、もしコモンズにアップしたい人がいるなら、別名でコモンズへアップロードしてもらうと。ファイル1-5に、感情的軋轢を生んでまで削除するほどの必要性は存在してないでしょう。--Yapparina（会話） 2020年8月3日 (月) 12:33 (UTC)[返信]
わたしも、行きがかり上この話題を立ち上げたけど、実際のところわたしはファイル1-5による即時削除に意義を感じないタイプの人間なので、もう手を出すの止めようかなと正直思っています。(；´д｀) --Yapparina（会話） 2020年8月3日 (月) 12:33 (UTC)[返信]
  • コメント この手の処理は管理者や削除者の負担を考えると削除者権限を付与したbotにやってもらうのが一番良いかと思いますが、運用を引き受ける方がいないのであれば難しいかもしれませんね。最初のころは手動で削除の対応をしておりましたがさすがに1000件超えたあたりから諦めております。もしbot対応するのであれば即時削除に新たに「FileImporterによってコモンズに移動されたファイル」を追加したほうが手動で移動した場合（今はあまりないかもしれませんが・・・）と判別出来て自動化しやすいのではないでしょうか。--Sakoppi (会話・投稿記録) 2020年8月8日 (土) 00:58 (UTC)[返信]
  • コメント Bot運用者です。WP:CSD#ファイル1-5による即時削除依頼が出されているファイルを削除するスクリプトを書いてみました。現在のところ、コモンズへの移行にFileImporterを用いており、インポート以後のローカルでの編集が{{NowCommons}}や{{即時削除}}の貼り付けのようなもののみというケースに限って削除操作を行うという動作になっています。シミュレートした感じではこの条件でもカテゴリ内の大半のファイルはbotで削除できそうです。削除権限がないので実際に削除するところまでは確認していませんが、Pywikibotのインターフェースを使用しているので権限さえあればうまくいくと思われます。--本日晴天（会話） 2020年8月23日 (日) 13:25 (UTC)[返信]
  •  追記 上記スクリプトで削除操作を行う条件に、ローカルの画像が最新版の時点でCategory:屋外美術を含む画像、Category:屋外美術写真の利用方針に違反している画像、Category:日本ではパブリックドメインにあり、米国でパブリックドメインにない画像、Category:削除依頼中のページ、Category:即時削除対象のページのいずれにもカテゴライズされていないというものもあります。--本日晴天（会話） 2020年8月23日 (日) 13:44 (UTC)[返信]
    • 屋外美術や米国著作権継続のファイルは考慮しなくて大丈夫です(file importerが使えないので)。あとはno source、no licenseも同様。代わりに、移動のため一時的に付与されていたカテゴリ(Category:Files uploaded by だれだれ、user:MGA73/Status参照)や移動推奨タグを除去する、というパターンがあるので、そこをお願いしたいところです。これがないと、多分4000近くの画像が弾かれます。 ぷりぷり娘 2020年8月23日 (日) 17:23 (UTC)[返信]
    • あとは、改名して移動されたファイルの扱いについて。現在、Wikipedia‐ノート:即時削除の方針にて、改名して移動されたファイルの削除後に投稿者が追えなくなるという分からなくなるという事態を避けるための議論が行われているところです。移籍時に改名すると移籍元は削除後赤リンクとなってしまうので。(移籍後にコモンズ側で変える分にはリダイレクトが生成されるので問題ない) ぷりぷり娘 2020年8月23日 (日) 17:39 (UTC)[返信]
      • 返信 移動推奨タグの件に対応しました。カテゴリの除去については書き忘れていましたが上でコメントした時点で対応していました。削除時のログには常にコモンズのファイル名を記載するようにしてあるので、ファイルの改名の件についても大丈夫かと思います。ちなみにコモンズとファイル名が異なる場合は、ローカルのファイル名で読み込んでいるページが存在すれば削除しない仕様にしてあります。--本日晴天（会話） 2020年8月27日 (木) 13:26 (UTC)[返信]

「初版投稿者が明示的にローカル版の即時削除を望まない」場合の扱い

  • 「初版投稿者が明示的にローカル版の即時削除を望まない」場合を除き、今のところBotによる対処に反対する利用者はおらず、合意が概ね成立したものとみられますが、権限申請と稼働の予定はあるのでしょうか？--ネイ（会話） 2020年9月4日 (金) 10:41 (UTC)[返信]
    • @本日晴天さん、通知を飛ばし忘れました。失礼いたしました。--ネイ（会話） 2020年9月13日 (日) 16:01 (UTC)[返信]
    • 返信 すみません、返信が遅くなりました。「初版投稿者が明示的にローカル版の即時削除を望まない」場合についてどうするか意見が分かれているので、これが解決すればすぐにbotに対する削除者申請とフラグ申請を行う予定でいます。TaisyoさんおよびYapparinaさんの立場を採用して初版投稿者の意思を尊重するのであれば、削除してよいか判定する方法が必要になります。あるいはネイさんおよびMario1257さんの立場を採用して、初版投稿者の意思については考えないことにするというのも手だと思います。--本日晴天（会話） 2020年9月14日 (月) 10:17 (UTC)[返信]
Saigen Jiroさんのファイルであれば、{{注意|この画像投稿者は、コモンズ移行後の即時削除を望んでいません。}}というタグが全部のファイルに入れらているようなので、それが判定に使えます。私は変わらずに、嫌がる利用者を無視してまで削除する意義をファイル1-5に感じませんが、削除すべきだと思う人は削除すればいいんじゃないですかね、現行の方針の許容範囲なんですから。botによる削除範囲もお好きに結論してもらえればと思います。いや、投げやりに言っているわけでなく、本当に。
言い損ねておりましたが、スクリプトを書いて本件の処理を提案してくださった本日晴天さんに感謝申し上げます。ありがとうございます。--Yapparina（会話） 2020年9月15日 (火) 15:33 (UTC)[返信]
  • コメント ローカルで残した場合、(コモンズで)改名した場合や説明を変更した場合に反映されなく、仮に合わせるとしても労力がかかってしまいます。「自由に利用できる観点」を踏まえると、変わらず削除すべきだと思います。ただ一つの手段として、ローカル削除を望まない場合の専用テンプレートを作成(上記{{注意|…の場合、誤字などがあると判別できない可能性があるので)し、後からこの議論を適用するという方法もありだと思います。
また議論が一区切りしていると判断したため、議論を区分させていただきました。--Mario1257（会話） 2020年9月15日 (火) 16:25 (UTC) codeタグの内部にnowikiタグを追加。--本日晴天（会話） 2020年9月19日 (土) 10:47 (UTC) インデント変更(返信に当たらないため)--Mario1257（会話） 2020年9月23日 (水) 17:43 (UTC)[返信]
  • 記事の所有権の観点、およびローカルおよびコモンズでのファイル管理の複雑化（ウィキメディア・コモンズでは写真の説明やバージョンが高頻度で変わるため、説明をその都度合わせる必要がある）防止のため、移動元のファイルを残しておくという意見には 強く反対します。 ぷりぷり娘 2020年9月16日 (水) 05:25 (UTC)[返信]
    •  追記本来だったら消せるものをあえて「残しておく」という選択肢をとる以上、最低限更新内容ぐらいは合わせるべきです。でないと、jawpのみ説明不足とか、コモンズでライセンス変更（ex:{{GFDL-ja|migration=relicense}}としてあげた画像が著作権発生の資格がないと判断された）があった際jawpのみ違うライセンスとなっている、などという事態が起きかねません。また、内容を転記する際に「コモンズのだれだれのいついつの版から転記」という情報が欠けていたり、間違ってたりすると、著作権侵害となる恐れも出てきます。後者の「ファイル管理の複雑化を避ける」というのはそういった余計な面倒事を避けよう、ということです。 ぷりぷり娘 2020年9月16日 (水) 06:17 (UTC)[返信]
  • 私が一番心配しているのが、Saigen Jiroさんの様な例で、明確にローカル版の削除に反対しているのに、削除を強行したことで、利用者がウィキペディアから離れてしまわないかです。削除賛成者がしっかりフォロをして、継続して参加してもらえる。モチベーションがこのことで落ちないように持っていけるのであれば安心できるのですが。コモンズにアップロードした画像でローカル分を削除しなくてもたちまちは問題になることは実際には殆ど無かったりします。私の画像も知らない内にコモンズに持って行かれた後でローカルも残っていたりするのですが、問題になった認識はないです。よって、消すリスクより、残すリスクが低いのではと判断したからです。
    改めて、削除賛成者が、削除を希望しない利用者に手厚いフォロをして頂き、ウィキペディア離れ回避が出来るのであれば、削除反対する理由は無くなるのかなと思います。--Taisyo（会話） 2020年9月16日 (水) 06:24 (UTC)[返信]
  • 情報 コメントありがとうございます。Yapparinaさんがご提示のタグについてですが、1400以上のファイルで使用されているものの、ファイル1-5による即時削除依頼が出されているものは現時点で1つもないようです（petscan:17409831）。また、例に上がっているSaigen Jiroさんについてですが、特別:差分/78715339のようにファイルによっては即時削除を希望されているようです。
  • 本題については、即時削除を望まないことを表明されていればbotによる削除の対象としないという方向で行こうと思います。ぷりぷり娘さんがおっしゃるように、コモンズと重複したファイルを残すことにデメリットがないわけではないため、FileImporterで適切に移行されているケースについては、投稿者の希望が特になければローカルのファイルはなるべく削除した方がいいと考えます。即時削除を望まないことを表明する方法についてですが、{{注意|…だと判定・追跡しづらいので、{{ファイル存続希望}}のような名前でテンプレートを作成し、そちらを使用するというのはいかがでしょうか。--本日晴天（会話） 2020年9月19日 (土) 10:47 (UTC) 打消し線を引いた部分について一旦撤回します。--本日晴天（会話） 2020年9月27日 (日) 16:11 (UTC)[返信]
  • {{ファイル存続希望}}の考え方は賛成します。ただ、投稿数が元々多い利用者の場合、テンプレートをいちいち張るのも正直かなり負担になると思います。テンプレート作成後に、一定期間は削除までの猶予期間を置き、削除しないことを希望する利用者は猶予期間中に宣言。その後、BOTによる一律テンプレート添付（ファイルにより対応を変える場合は、その分は手動）。私の場合、クロスライセンスの過去動画への対応でBOT依頼をしましたので、同様の対応はできるはずです。落ち着いてから、残存希望が無い画像を消していく形にしていくのかと思います。--Taisyo（会話） 2020年9月19日 (土) 13:24 (UTC)[返信]
  • 情報 Hi! Sorry to write in English. I made a comment at Template‐ノート:NowCommons#Files_that_user_requested_to_keep about files where someone asked not to delete the file even if it has been moved to Commons. Personally I think that IF it is decided to keep files locally then it is better to use {{ファイル存続希望}} or change {{NowCommons}} than to add a comment in {{注意}}. I have tried not to request a speedy deletion on files where the uploader have asked that the file is not deleted. But it is hard to find such files if there is no standardized way to mark the files. --MGA73（会話） 2020年9月23日 (水) 09:54 (UTC)[返信]
  • 私が{{ファイル存続希望}}の作成に反対しているのは先に主張した通りですが、2点補足します。
    • 初版投稿者の私的な理由による希望である{{ファイル存続希望}}がWikipedia:記事の所有権に違反するのは、これまでにぷりぷり娘さんと私が主張した通りです。Wikipedia:記事の所有権#私有化の振る舞いの例のような行動をした利用者の「ウィキペディア離れ」を回避するために私有化が容認されることはありません。したがって、「削除賛成者が、削除を希望しない利用者に手厚いフォロをして頂き」と責任を押し付けることはできません。逆です。「削除を希望しない利用者が方針・ガイドラインに従うよう手厚いフォローをして」ください。これは削除賛成・反対者にかかわらずそうすべきであると考えます。それとも、仮に私が「ジョン・コンデュイットを他人に編集されたら、ウィキペディアを離れます」と主張したとして、私がウィキペディアを離れないようジョン・コンデュイットが編集保護されるのでしょうか？
    • 「Wikipedia:記事の所有権に違反しない」との反論がない以上、{{ファイル存続希望}}を作成する前に記事の所有権のガイドライン（「ファイルページの存続を希望する」を例外とする）およびWikipedia:即時削除の方針#ファイル1-5（初版投稿者からファイルページの存続が要望されている場合、即時削除の対象外とする）の改定が必要であると考えます。当然ながら、ボットによる対処にのみ反対する場合、後者の改定は必要ありません。--ネイ（会話） 2020年9月23日 (水) 17:17 (UTC)[返信]
  • ネイさんもおっしゃっていますが、「ファイルページの存続を希望する場合」のガイドライン類の改定が必要になってくると思います。また、「コモンズとローカル間で記述やバージョンが変更になった場合の対処方法」も考えておく必要があるのではないでしょうか。--Mario1257（会話） 2020年9月23日 (水) 17:43 (UTC)[返信]
    • When I move a file to Commons I make sure to update the file and description on Commons at the time of the tranfer. I do not think that anyone check and make sure that files and descriptions on Japanese Wikipedia and Commons continue to be the same after the transfer.
As I understand it only a few users have asked to keep the local files. Perhaps the bot could start to delete the files uploaded by all other users now so the deletion of those files do not have to wait for the discussion to end? That could be a good test of how the bot work. --MGA73（会話） 2020年9月23日 (水) 20:09 (UTC)[返信]
  • The bot is now deleting files (except the files on 利用者:SeitenBot2/即時削除を見送ったファイル that admins need to delete). My question is how to know if any files should not have a "SD f1-5". I know that Saigen Jiro requested to keep the files local but are there any other users? If I move a file and add the "SD f1-5" then the bot will delete the file automatically unless someone does anything to prevent it.
Personally I think we should delete all files that is also on Commons because all files and all text that is uploaded to Wikipedia is free for everyone to use and change. But unless there is concensus to delete all files I will try not to request deletion of files that should not be deleted. --MGA73（会話） 2020年10月24日 (土) 15:47 (UTC)[返信]

Bot運用の進捗状況

「Template:孤立」は、リンクしている記事が存在しない場合に使用するものではないのか？

質問 ジュピターテレコム（@NetHome）の回線を使用する59.166.155.104氏の言動、および、「Template:孤立」の使用法について質問いたします。

さきほど59.166.155.104氏が、ある記事に対して執拗に繰り返し「Template:孤立」を貼り付けているのを拝見しました。その記事は既に他の記事からリンクされているためノートにその旨記載したうえで除去しましたが、59.166.155.104氏はノートに何の意思表明もしないまま再び「Template:孤立」を貼り付けています。会話ページに質問を投げたりしたところ、59.166.155.104氏からようやく意思表示があったのですが「1ページからしかリンクされておらず、孤立している」「1ページからしかリンクされてないなら「全く」リンクされてないですよね」などと主張しています。

「Template:孤立」の解説には、はっきりと「標準名前空間のどのページからもリンクされていない、孤立しているページであることを告知するためのテンプレート」と明確に書いてあります。ですので、当然リンクしている記事が存在しないときに使用するテンプレだと理解していたのですが、そういう理解でよいでしょうか？　それとも、59.166.155.104氏が主張するように、他の記事からリンクされていたとしてもリンク元がひとつだけの場合は貼っていいのですか？　こんなくだらないことで編集合戦するのはばかばかしいので、念のため確認させていただきたいです。--126.189.141.127 2020年8月3日 (月) 10:13 (UTC)[返信]

  • docには、「どのページからもリンクされていない」と書かれているので、一応リンクされていれば貼り付けて良いと思います。ここで、「全て」の意味を論じるつもりはありませんが、手元の辞書で調べたところ「完全に」と表記がありました。-- LILOBJTOFU123 (Benutzer / erzählen) 2020年8月3日 (月) 12:33 (UTC)[返信]
質問 LILOBJTOFU123氏の発言内容の意味が全く分からないので、説明していただけますか。「どのページからもリンクされていない」場合に使用するテンプレなのに、なぜ「リンクされていれば貼り付けて良い」という結論に至るのですか？　「どのページからもリンクされていない」場合に使用するテンプレならば、リンクされていないときに限って使用すると考えるのが自然ではないのですか？　また、「「全て」の意味を論じるつもりはありませんが」云々という主張に至ってはわけがわかりません。なぜ唐突に「全て」という単語の意味が関係してくるのですか。「Template:孤立」とdocのページには、「全て」なんていう単語はありませんよ。「Template:孤立」には「全くリンクされておらず、孤立している」と書かれています。もしかして、「全て」（＝すべて）という単語と「全く」（＝まったく）という単語を取り違えておられるのでしょうか。「全て」と「全く～ない」では日本語としての意味が全然違うでしょう。--126.192.31.186 2020年8月4日 (火) 01:08 (UTC)[返信]
  • コメント - Template:孤立/doc#このテンプレートの説明にあるように、このAmboxは「特別:孤立しているページ」に該当することを示すためのテンプレートです。つまりここに掲載されていないページには無用な存在ですが、この特別ページはリンク元が標準名前空間以外（Wikipedia名前空間、ノート名前空間など）からのみだとしても対象外となるようなので、Wikipedia:記事どうしをつなぐの観点から標準名前空間（＝記事）からのリンクがないものに対して使うことは許容されるでしょう。
正直、このテンプレは一時的に貼られるようなものであって、孤立に気づいた人がこれを貼るよりも、そのまま関係する記事に一つくらいリンクさせて問題を解消させればそれで良いような気もします。削除や統合など単独記事として成立しえないようなページならともかく、単体で記事が成り立つような題材ならどこか繋がるでしょう。--ButuCC+Mtp 2020年8月3日 (月) 13:32 (UTC)[返信]
ありがとうございます ButuCC氏から「記事）からのリンクがないものに対して使うことは許容される」との説明がありました。ということは、他の記事から既にリンクがあるものに対して使うことは許容されないということでよいですよね。解説ページに「標準名前空間のどのページからもリンクされていない、孤立しているページに貼り付けます」とはっきり書いてあるにもかかわらず、
の四人衆のように、「他の記事から既にリンク済みだったとしても貼り付けてよい」と主張する人たちが意外に多く、びっくりしておりました。そんなこと解説ページに一言も書いてないのに。解説ページの文章を読んでそのような理解に至るのだとしたら、そもそも日本語でのコミュニケーションに難があると言わざるを得ないと思いますが……。常軌を逸した主張であり、明らかに悪戯目的だと思うのですが、この四人衆が今後も解説ページの説明を無視して勝手な運用を続けた場合どのように対応すればよいのでしょうか。--126.192.31.186 2020年8月4日 (火) 01:25 (UTC)[返信]
まず、私はウィキペディアに常駐しているわけではありませんので、すぐに返信ができないの点はご留意下さい。そして、混乱を招いてしまい申し訳ありません。まず、「全て」と記載したのは「全く」の表記ミスです。全くというフレーズはdocではなくテンプレート本体に書かれています。又、 「一応リンクされていれば貼り付けて良いと思います 」というのは、「剥がして良いと思います」の表記ミスです。私が前に投稿していた文章の辻褄が合わないのを見れば分かると思います。私に意見が支離滅裂になっていましたので、このテンプレートに対する考えを正しく述べると、「どのページからもリンクされていない…」と書かれているので、取り敢えずリンクされていれば記事から剥がして良いと思います。ご迷惑をおかけし申し訳ありません。今後気をつけます。-- LILOBJTOFU123 (Benutzer / erzählen) 2020年8月4日 (火) 03:01 (UTC)[返信]
返信 なるほど、ご説明ありがとうございます。タイプミスということですね。承知いたしました。--126.149.76.222 2020年8月9日 (日) 22:30 (UTC)[返信]
返信 6144氏がおっしゃっているのは具体的に誰のことですか。59.166.155.104氏のことでしょうか？　それとも、59.166.155.104氏、2001:268:9b1f:d51f:5cb2:d907:79b7:4ba9氏、LILOBJTOFU123氏、オーディンもご照覧あれ氏の全員ということですか？　こちらの削除依頼でのご発言を読む限り、59.166.155.104氏に対するご意見かなと思いますが、念のためはっきりとご説明いただきたいです。--126.149.76.222 2020年8月9日 (日) 22:30 (UTC)[返信]
  • 結果的に3点リンクがなされた[2][3][4]、テンプレートは外された……結局、この現状にどなたか不満があるのでしょうか？ 不満のある人がいないなら、それで終わりではないでしょうか。なお、私なら、閾値は0か1か等と突き詰めることにあまり意味はないと考え、異論が出ればとりあえず相手の希望を通しておき、明らかに十分な数になったら外す、という行動を取ります。 --2001:240:2404:1C79:6864:AF85:CF74:4530 2020年8月4日 (火) 03:53 (UTC)[返信]
コメント 3つの記事からリンクされているにもかかわらず、それ以降もテンプレをわざわざ貼り付けているので、2001:268:9b1f:d51f:5cb2:d907:79b7:4ba9氏とオーディンもご照覧あれ氏は不満があるのでしょう。また、59.166.155.104氏も、他の記事からリンクされているにもかかわらずテンプレを貼っていたわけですから、やはり不満があるのでしょう。また、このような運用を継続される方がいる以上、この記事に限らず他の記事でも同様の問題を起こす可能性がありますので、井戸端で議論することは必要でしょう。さて、2001:240:2404:1C79:6864:AF85:CF74:4530氏は「明らかに十分な数になったら外す、という行動を取ります」と主張していますが、それでは「Template:孤立」のdocのページに従うつもりは全くないということでしょうか？　docのページの何を根拠にした主張なのか、ご説明いただけますか。--126.149.76.222 2020年8月9日 (日) 22:30 (UTC)[返信]
コメント へのいちと申します。どの参加者でもウィキペディアでの活動はボランティアですから、誰かの編集の後始末を別の誰かに要求するのはいきすぎでしょう。例えばＡさんが説明書きとは違った状態にしたものをＢさんがそのままにしておこうとしたからといって、Ｂさんに対して「従うつもりはないのか、根拠は何か」などと問いただす必要はないでしょう。ましてや、この方の場合は何もしないというわけでもなくて、十分な数までリンクが増えたら外すといってくれているのに。--へのいち（会話） 2020年8月15日 (土) 10:14 (UTC)[返信]
コメント 2001:240:2404:1C79:6864:AF85:CF74:4530氏は「私なら、閾値は0か1か等と突き詰めることにあまり意味はないと考え、異論が出ればとりあえず相手の希望を通しておき、明らかに十分な数になったら外す、という行動を取ります」と述べているわけですから、自分がテンプレ貼った場合は他の記事から十分にリンクされない限りは剥がさないぞという意思表明をしてるわけですよね。へのいち氏は「この方の場合は何もしないというわけでもなくて、十分な数までリンクが増えたら外すといってくれている」と擁護しておられますが、「明らかに十分な数になったら外す」という条件自体がそもそも間違いなのですから、擁護の余地は全くないでしょう。「私なら、閾値は0か1か等と突き詰めることにあまり意味はない」という個人的な思想に基づいて、「Template:孤立」のdocのページに従うことなく「明らかに十分な数になったら外す」と宣言してるわけですから。「テンプレの解説ページに説明が書かれているけど、気に食わないから解説ページ無視して勝手にテンプレ使うぞ！」と言う人がいたら、テンプレの意味がないでしょう。テンプレの使用条件が人によってばらばらだったら、汎用的に使用できませんよね？　--126.197.46.72 2020年8月19日 (水) 09:10 (UTC)[返信]
コメント へのいちです。えーっと、「自分がテンプレ貼った場合は」ですか？ この方はとりたてて自分が貼った場合の話をしていたのではないと思ったのですが。誰が貼ったかとは関係なく、例えば、リンクがあるのに気づいてこの方が剥がすようなことがあったときに、他の誰かにまた貼り直されてしまうようなことがあるかもしれません。そのような場面が「異論が出る」ということでしょう。で、その場合、躍起になってすぐに再び剥がしたりする気はないといっているだけですよね。--へのいち（会話） 2020年8月19日 (水) 13:48 (UTC)[返信]
コメント - {{出典の明記}}みたいに「どこまで出典を充実させれば外せるか」が人によって閾値が異なるタグは確かに存在しますが、このタグはそういう類のものではなくないですか。このタグの場合はまさにリンク元が0か1かで雲泥の差ですので、そもそも「十分」という表現に出番はありません。そのページの特別:リンク元を確認して「○×にリンクしているページはありません。」となっていなければ機械的に外せるものです。私はその上で記事をつなぐ観点からリンク元の中に記事ページが必要だという考え方には賛成できるとしただけで、標準名前空間へのリンクが1ページか2ページかなどを議論する余地は無いでしょう。
なお、リンク元が全くないと特別:孤立しているページの対象になるように、リンク元が「0」であることはメンテナンスの点で修正対象となりますが、リンク元が1、2、3…といった「少ない」状態を問題視する方針文書は存在しません。{{孤立}}はリンク元が無いことを指摘するテンプレートなので、少ないことを指摘するなら別のテンプレートを作るべきと思いましたが、そもそもリンク元が少ないことはタグで注意するような問題点であるか、という点から考える必要がありそうです。--ButuCC+Mtp 2020年8月10日 (月) 12:37 (UTC)[返信]
  • 結論が出ているようですが、これって、本文中にリンクがあればよいのではなくて、他の記事からリンクされていることが必要なのでは？（新規記事A→他記事Bではなくて、新規記事A←他記事Bということ。）--Kodai99（会話） 2020年8月6日 (木) 14:48 (UTC)[返信]
コメント Kodai99氏の「本文中にリンクがあればよいのではなくて、他の記事からリンクされていることが必要なのでは？」というのはおっしゃる通りだと思いますし、他の皆さんもその前提で議論していると思います。冒頭にも「その記事は既に他の記事からリンクされているためノートにその旨記載したうえで除去しました」「他の記事からリンクされていたとしてもリンク元がひとつだけの場合は貼っていいのですか？」と書いているとおり、他の記事からリンクされているのに、わざわざテンプレを貼る人がいる点について議論しています。--126.149.76.222 2020年8月9日 (日) 22:30 (UTC)[返信]
{{コ]]申し訳ない。「リンクされている」と書かれているところを読み飛ばしたか、誤読したようです。--Kodai99（会話） 2020年8月20日 (木) 14:58 (UTC)[返信]

過去に在籍していた経歴を載せる必要があるのか

お世話になります。
BEYOOOOONDSの記事についてご相談したく記述します。
ノート:BEYOOOOONDS#編集についてにて議論していましたが平行線のため井戸端へ場所を移したいと思います。
具体的には以下の2つの点になります。
1 BEYOOOOONDS加入以前の個別の経歴(ハロプロ研修生に在籍時の経歴)を記載する必要があるか。
BEYOOOOONDSのメンバーである一部がBEYOOOOONDS#メンバー詳細このように記載されております。ここで書かれている経歴はBEYOOOOONDSに入る以前のハロプロ研修生というグループに在籍してきたという記載になります。明らかに重複記載でありますし、グループ加入以前の活動を別のグループに記載すると言う主張に疑問があります。
2 出演での演劇女子部の記載は必要があるのか。ハロー!プロジェクトの作品・出演一覧#演劇女子部で一覧化されている。
演劇女子部という名で「ハロー!プロジェクトの作品・出演一覧#演劇女子部」で舞台がまとめられています。Wikipedia:一覧記事というのはわかりやすくするものと捉えていますが、一覧記事のリンクを貼っただけでは気がつかない人がいる為リンクは貼らずに記事に記載するという主張をされています。
以上のことに関して過去の経歴を載せるのかと出演はリンクではなく記述する必要があるのかを教えていただきたいと思います。--Nocto（会話） 2020年8月4日 (火) 13:16 (UTC)[返信]

報告ノート:BEYOOOOONDS#編集についてと同時にノート:モーニング娘。#重複記載の削除、ノート:アンジュルム#重複記載の削除、ノート:つばきファクトリー#重複記載の削除、ノート:Juice=Juice#重複記載の削除も関連してくるので同一議題を出させていただいてます。--Nocto（会話） 2020年8月6日 (木) 16:31 (UTC)[返信]

  • まず前提として、BEYOOOOONDS#メンバー詳細の記載内容はBEYOOOOONDSのメンバー紹介ではなく一個人の人物記事です。人物記事であってグループ記事ではないという体裁なので、ハロプロ研修生としての経歴も掲載する必要がありますし、演劇女子部としての出演歴も個人の出演歴として記載することになります（なお、「記事の存在に気付くとは限らない」という主張に対しては{{main|ハロー!プロジェクトの作品・出演一覧#演劇女子部}}で閲覧者に気づかせることも可能だというのが答えになります）。
  • 「特筆性の基準を満たさないことを理由にグループ記事に一個人の人物記事を記載する」ことに違和感をおぼえるのであれば（私も違和感だらけです）、BEYOOOOONDS単体ではなくアンジュルム#メンバー詳細、こぶしファクトリー#メンバー詳細、Juice=Juice#メンバー詳細なども含める形でアイドルグループ記事全般に対して議論提起が必要かと思われます。--106.154.132.102 2020年8月5日 (水) 10:35 (UTC)[返信]
  • お考えありがとうございます。
私もグループ記事に一個人の人物記事を記載するに違和感を感じた一人でございます。アップフロント系(ハロプロの所属事務所)の記事で個人の独立記事がないメンバーに対して問題定義をした次第ですが、今までそうやってきたとういう恒久的なローカルルールが形成されている模様です、--Nocto（会話） 2020年8月6日 (木) 05:34 (UTC)[返信]
  • まず、一般論として、グループの各メンバーの来歴に関する記述については、その他多くのグループ活動をされている方の記述としてごく普通にみられますので、Wikipediaで広く受け入れられているかと思います。一方で、グループ記事はグループ記事であって、個人記事ではありません。グループの所属前・脱退後の情報をグループ記事に記載すべきではありません。以前に活動していたグループがあるのでしたら、その以前のグループの記事において記載すべきであり、その記載を新たなグループに持ち込むべきではありません。「加入以前の活動はXXX参照」とし、そちらの方で記述すべきです。あくまで、グループ在籍時の当人の活動記録に限るべきです。--devicehigh（会話） 2020年8月6日 (木) 04:26 (UTC)[返信]
    • そのうえで、BEYOOOOONDSの記事を拝見しましたが、まるで個人記事を無理やりグループ記事に押し込んだ感じですね。これはひどい。異質であり、全てを編集除去すべきなレベルですが、最低限、グループ在籍時の情報に限って、グループ活動をする他の芸能人記事（歌手やお笑い芸人など、参考になる記事は多数あります）の体裁を参考に記述を改めて頂く必要があると思います。--devicehigh（会話） 2020年8月6日 (木) 04:26 (UTC)[返信]
      • 返信 (devicehigh様宛) お考えありがとうございます。
私もあくまでグループの記事であってメンバーの記事ではないため、前所属先はリンクのみの参照で良いと考えておりました。アップフロント系(ハロプロの所属事務所)のページ全てに同じ方法で記載されており、他の記事と比較するわけではないですが他の研修生(研究生)があるグループも編集している私からすると異質でしかありませんでした。分割記事の手間を省くための記述としか見えないのです。一方でこの方法に異を唱えるガイドライン的な根拠がなく、同一内容の記載による重複という考えでしか言えませんでした。重複自体もWikipedia:ウィキペディアでやってはいけないこと#重複した記事をつくることやWikipedia:井戸端/subj/重複記事であるのか？違うのか？ぐらいしか記載がなく同じ文ではないから重複ではないと言われてしまうと弱いところがあります。同一案件でノート:つばきファクトリー#重複記載の削除でも議論しましたがローカルルールとして合意形成が出来ていると言うのには一定の理解をしつつも、違和感を感じずには居られません。根拠となるような事案があれば教えていただきたく存じます。--Nocto（会話） 2020年8月6日 (木) 05:34 (UTC)[返信]
  • 読者視点に立って考えるといいと思います。BEYOOOOONDSの記事を読みに来るのは、「BEYOOOOONDSってどんなグループなんだろう」と調べに来た、BEYOOOOONDSのことを知らない人です。そのような人にBEYOOOOONDSというグループについて説明する際に必要な事柄であれば書くべきです (わたしはBEYOOOOONDSのことをよく知らないので必要か否かの判断はできません)。Wikipediaはアイドルのデータベースを作る場所ではないので、そのアイドルの経歴すべてを書く必要はありません。WP:NOTやWP:NOTFANSITEも参照してください。 --Kto2038（会話） 2020年8月6日 (木) 15:28 (UTC)[返信]
  • そのような視点からすると、現状のBEYOOOOONDSの記事は全体的に情報量が多すぎると思います。もっと要点を絞った方が読者にとって読みやすい記事になるのではないでしょうか。たとえば公演履歴はWikipediaに記載する必要はありますか? Wikipedia外のサイトでまとめを作ってもいいのではないでしょうか。 --Kto2038（会話） 2020年8月6日 (木) 15:28 (UTC)[返信]
  • もしアイドルの経歴の記載についてガイドラインを作りたいのであれば、プロジェクト:芸能人あたりで提起するといいと思います。 --Kto2038（会話） 2020年8月6日 (木) 15:28 (UTC)[返信]
  • 「重複記載」を気にされていますが、同じ内容のことが複数の記事に重複して書いてあること自体は問題はないです。それぞれの記事に記載しておく必要があるのであれば「重複記載」になっていてもいいと思います。ただ一箇所に寄せておいた方がメンテナンスはしやすいです。(重複記事はまた別の話です。重複記事についてはノートでMetal-metal-metalさんが書いた加山雄三/弾厚作の例のとおりです。) --Kto2038（会話） 2020年8月6日 (木) 15:28 (UTC)[返信]
    • 返信 (Kto2038様宛) お考えありがとうございます。
BEYOOOOONDSの記事は全体的に情報量が多すぎると違和感を感じ私も今回の議論を始めたわけですが、私の知識不足で重複とういう考えしか浮かばなかったしだいです。一番の議題はタイトルにもあります「過去に在籍していた経歴を載せる必要があるのか」というところになります。記載していただいたWP:NOTやWP:NOTFANSITEを提示してもどこまでの情報量が適切かが指摘できないため厳しいかと感じました。また同一議案をノート:つばきファクトリー#重複記載の削除にて議論しましたところ編集者の合意形成ができているすなわちローカルルール化されているとの話になりました。他に指摘できる事案があれば教えてください。--Nocto（会話） 2020年8月6日 (木) 16:18 (UTC)[返信]
  • 「グループ記事に一個人の人物記事を記載する」件について述べさせて頂きます。ガイドラインでは個人の人物記事は所定の手続きを経ないと作成できない規定ですが、個人記事をグループ記事に内包させることで手続きを免れるようにしている意図が伺えます。またグループ記事に複数の個人記事が内包される訳ですから記事は長大になり非常に見辛くなります。従ってメンバー詳細は最低限の記述とし、略歴や出演などは個人記事が正式に作成されてから記載すれば良いと思います。--Asasdc（会話） 2020年8月6日 (木) 16:41 (UTC)[返信]
    • 返信 (Asasdc様宛) お考えありがとうございます。
私は、現在の編集を分割ありきので将来的に分割する手間を省く為の記載ではないかと考えておりました。メンバー詳細は最低限と同じ考えでおりました。--Nocto（会話） 2020年8月6日 (木) 17:33 (UTC)[返信]
  • ちなみに「記事未作成のメンバーの解説をグループ記事中で行う」のはKis-My-Ft2の2012年頃～2014年頃の版でも行われていました。この程度であれば最小限の記述といえそうですが、赤リンクだからという理由で別枠を用意している点に違和感があります。よって「メンバー詳細は一切記載しない」か「個人記事の有無に関わらず簡易なメンバー詳細を記載する」が適切ではないでしょうか。--106.154.139.184 2020年8月7日 (金) 13:55 (UTC) 固定リンクの誤りを修正--106.154.138.252 2020年8月9日 (日) 00:13 (UTC)[返信]
    • 返信 お考えありがとうございます。
わたしが一番気になってる点でいえば経歴の書き方が研修生からメンバーになるまでなんですよね。ジャニーズでいうJr時代からグループメンバーとなるまでの経歴と言うところです。Kis-My-Ft2の例ありがとうございました。--Nocto（会話） 2020年8月7日 (金) 15:51 (UTC)[返信]

報告 皆様ご意見ありがとうございました。各記事のメンバー詳細を整理したことを報告します。--Nocto（会話） 2020年8月13日 (木) 17:21 (UTC)[返信]

  • ハロープロジェクト、iDOL Streetなどのアイドルプロジェクト内での所属の異動についての議論とは思いませんでした。このようなケースについての議論について、単に、「過去に在籍していた経歴を載せる必要があるのか」という井戸端会議のタイトルとするのは、ミスリーディングではと憂慮いたします。また、同一アイドルプロジェクト内の異動については、異動前の活動を書くことは容認してもよいと考えます。--Uminokawauso（会話） 2020年8月17日 (月) 14:16 (UTC)[返信]
    • コメントこの議論が起きる以前からiDOL Streetは異動以前の内容の記載はされていませんので確認していただきたいと思います。--Nocto（会話） 2020年8月17日 (月) 14:34 (UTC)[返信]
    • コメントまた、現在の編集の状態が何を根拠になったのかは、おそらく内々で編集していった際のローカルルールであろうと聞いております。「同一アイドルプロジェクト内の異動については、異動前の活動を書くことは容認してもよい」という考えの理由をお聞かせできますでしょうか。--Nocto（会話） 2020年8月17日 (月) 15:12 (UTC)[返信]
    • GEM (アイドルグループ)の例を確認いたしました。メンバー節は、表形式になっていて、単独立項されているメンバー、されていないメンバーどちらも、GEM以前のキャリアは「備考」に書かれていました。このiDOL Streetの書き方であれば、表にとどまっているので、「記事IN記事」とみられる余地はないと思います。現状において、ハロプロでは、メンバー情報は表形式になっておりませんが、これを変えるとこれまでの表記に慣れた利用者に不便を感じさせることになると思います。--Uminokawauso（会話） 2020年8月17日 (月) 15:28 (UTC)[返信]
    • ハロープロジェクトは、冬と夏に全体のコンサートツアーを行っており、ひとつのアイドルグループであると考えられるからです。もし、ハロー!プロジェクトのなかにメンバー詳細があるのであれば、清野桃々姫さんのところには、ハロプロ研修生当時からのできごとが書かれるはずです。BEYOOOOONDSが単独記事となっていても、その中にあるメンバー詳細にハロプロ研修生当時のことまでまとめて書くことは、ハロー!プロジェクトという主題をどのように記事を分割して書いていくかに過ぎないと考えるからです。--Uminokawauso（会話） 2020年8月17日 (月) 15:28 (UTC)[返信]
      • 返信 (Uminokawausoさん宛) すみません。主張したい事がよく理解できないので確認したいのですが、こちらでは「記事IN記事」ではないとおしゃっていますが、上記では「(書き方を)変えるとこれまでの表記に慣れた利用者に不便を感じさせる」と書いてあるのみなんですが、「記事IN記事」状態になっていないと言う事は主張しないということでしょうか。また、後述は記事名がBEYOOOOONDSだとしても上位にハロー!プロジェクトががあるわけでその分割だからハロプロのことならどこに書いても大丈夫と読んだのですがあってますか。--Nocto（会話） 2020年8月17日 (月) 16:42 (UTC)[返信]
        • GEM (アイドルグループ)のメンバー節は、表形式になっていて、これであれば、「記事IN記事」になることは、まずもってないだろうということをいいました。BEYOOOOONDSのメンバー詳細節は、編集において十分な注意を払わないと「記事IN記事」になる可能性があると思っています。記載するにあたって「ハロー!プロジェクト」と「BEYOOOOONDS」への理解を深めるためのものであるか、常に考えながら編集していくべきであるということです。例えば、清野桃々姫さんのハロプロ研修生になる前のアイドル活動[5]につき、詳細な記載をするのは、慎むべきだと思います。現状において、メンバー詳細節での清野桃々姫さんの記載は、「ハロー!プロジェクト」と「BEYOOOOONDS」への理解を深めるためのものになっており、「記事IN記事」になっていないと考えます。上位にハロー!プロジェクトがあるからかということについては、単にBEYOOOOONDSが、ハロー!プロジェクトに含まれるということだけでなく、ハロー!プロジェクトがひとつのアイドルグループとしての実態があるということを申しておきます。Hello! Project2019WINTERが22公演[6]、Hello! Project2019SUMMERが20公演[7]開催されています。これに対して2020年に予定されていた最初の2019年に行われたBEYOOOOONDSの単独ツアーは、ツアー回数こそ24回を数えるものの、その大半は、小規模なライブハウスでの公演です[8]。清野桃々姫さんは、ハロー!プロジェクトというアイドルグループのメンバーだという実態があると考えています。個々のアイドルグループを包含する大きなくくりには、「Stardust planet」などもありますが、単に包含するくくりであるということだけではなくて、全体としての活動実績がどのくらいあるかなど、個別に検討する必要があると考えています。記載個所について述べます。清野桃々姫さんは、2016年にハロプロ研修生となり、2017年にハロプロ正規メンバーへ昇格、2018年にBEYOOOOONDS結成されそのメンバーになったという時系列です。ハロプロ内の清野桃々姫さんの活動につき、時期によってハロプロ研修生、ハロー!プロジェクト、BEYOOOOONDSに分けて書くよりも、一か所にまとめて書いた方が、百科事典の読者に親切だと考えます。まとめて書く場所もどこに書いてもよいということではなくて、どこに書くのが百科事典の読者に一番親切なのかということで決めるべきと思います。--Uminokawauso（会話） 2020年8月18日 (火) 13:06 (UTC)一部修正--Uminokawauso（会話） 2020年8月18日 (火) 13:14 (UTC)[返信]
          • 返信ありがとうございます。この井戸端に関連してこちらでアドバイスいただいたのですが、Wikipedia:ページの分割と統合#分割の検討こちらの文を読むと、見出し語の解説としては不要な記述もしくは見出し語との関係が不明確な記述であるが、百科事典の情報としては有用な場合は分割ができるとなっております。よって記事に記載すべき部分と言うのは見出し語(記事名)に対する解説だけで良いとなる思います。なのでハロプロ研修生の内容はBEYOOOOONDSを解説する内容ではないし、またメンバー詳細についても分割協議がおきている内容ですので記事の解説として不要部分と考えてよいと思います。よって「記事IN記事」と言われるかも知れない内容ですし、整理すべき内容かと思います。--Nocto（会話） 2020年8月18日 (火) 15:00 (UTC)[返信]
            • Wikipedia:ページの分割と統合#分割の検討のご案内ありがとうございます。読ませて頂きました。ハロー!プロジェクト#現メンバー-｢メンバー詳細」節-｢清野桃々姫」節の構造で清野桃々姫さんのハロプロでの事績が記載されるのであれば、ハロプロ研修生当時からBEYOOOOONDS在籍中の現在まで、一貫した記載が可能という認識でよろしいでしょうか。--Uminokawauso（会話） 2020年8月19日 (水) 12:58 (UTC)[返信]
              • 分割のイメージとしては、ハロー!プロジェクトから分割されたハロプロ研修生やBEYOOOOONDS。ハロプロ研修生やBEYOOOOONDSから分割されたメンバーページのイメージとなると思います。上記で紹介したページの下部に分割の手順が書かれていると思いますが、そこを読むと元のページから分離すべき部分を除去し、新規ページのリンクを作る等の修正することなどが書かれていると思います。なので、BEYOOOOONDSで記載できない情報をハロー!プロジェクトでまとめて書くことはできないと思います。やはり経歴をすべて1つの記事に書くのは、メンバーが見出し語になる独立ページが立ち上がらないと厳しいかと思います。独立ページが立てれない場合は独立ページを作成できるようになった際に各ページから情報を収集して書くことになるかと思います。--Nocto（会話） 2020年8月19日 (水) 15:27 (UTC)[返信]
                • お考えをお示しいただきありがとうございます。ハロー!プロジェクト#現メンバー-｢メンバー詳細」節-｢清野桃々姫」節に清野桃々姫さんのハロプロでの事績をまとめて記載するべきではないとお考えだと理解いたしました。私は、百科事典において、読者が自分の知りたい情報に容易にたどり着く配慮が大切だと思っております。ウィキペディアの編集者の視点では、清野桃々姫さんが個人として独立記事の基準に達してから、ハロプロ研修生、ハロー!プロジェクト、BEYOOOOONDSの各ページから情報を収集して書くということで十分かもしれません。読者の視点に立つのであれば、BEYOOOOONDS-｢メンバー詳細」節-｢清野桃々姫」節にハロプロ研修生、ハロー!プロジェクトに書かれた情報へ誘導するような案内を置く配慮も必要ではと思われます。--Uminokawauso（会話） 2020年8月20日 (木) 12:13 (UTC)文章の修正--Uminokawauso（会話） 2020年8月20日 (木) 12:19 (UTC)[返信]
  • ここでは「分割か転記」になっているようですが実際には削除のみされているようです。それは合意した内容に沿ったものでしょうか。そしてその変更はたとえばBEYOOOOONDSのページを見に来た人にとって便利な変更と言えるのでしょうか。 --61.205.89.39 2020年8月23日 (日) 20:52 (UTC)[返信]
    • モーニング娘。の岡村ほまれさんの項目がまるまる消されてるし、こぶしファクトリー浜浦彩乃さんの解散後の活動も消されてる。 --61.205.101.253 2020年8月23日 (日) 22:13 (UTC)[返信]
      • コメント 少なくともこの井戸端での議論は、グループ記事にほぼ個人記事状態の個人項を掲載することの是非が主題であり、議論開始から1週間（分割提案の議論期間と同等の期間）に渡り、それに対しては「非」というのが概ねの合意事項となっていたかと思います。ウィキペディアはファンサイトではないので、便利かどうか、という点は執筆の基準には残念ながらありません（便利だから、を許すと、Wikipedia:独立記事作成の目安が有名無実化してしまいます。）。ご指摘頂いた解散後の活動はまさにこの議論において問題とされた箇所ですので、どうしてもウィキペディアに掲載されたいのでしたら、独立した個人記事を立項されるのがよろしいかと思います（ただし、記事を作成される際は、対象者がWikipedia:独立記事作成の目安を満たしていることが必要です。）。一連の対応の中で、Nocto00氏に転記まで実施頂けなかった点は大変残念ではありますが、現状、過去の編集履歴から追うことは可能ですので、情報として有用とお考えでしたら、過去の版を参照頂き、ご自分で執筆頂くのも一案です（記事ノートで意見しておいて何ですが、当方はハロプロには詳しくないので、当方が対応するのは難しい状況です。）。--devicehigh（会話） 2020年8月30日 (日) 15:29 (UTC)[返信]

曖昧さ回避の対象が外国語版のみの場合

Wikipedia:削除依頼/競合しない曖昧さ回避のページを見て思ったのですが、他言語版へのリンクであり単に日本語版が作成されていない曖昧さ回避についてどうすればいいのか意見を求めたいと思います。

  • コメント 個人的な意見としては日本語版に複数の記事がない(ゆんなど直接記事名に使われているかは問わない)ものに関しては不要と思いますが…。もし2記事あれば有用と思いますが、参考としてWikipedia:削除依頼/化学 (曖昧さ回避)もご覧ください。--Yosizuya（会話） 2020年8月5日 (水) 09:56 (UTC)[返信]
  • 日本語版に現存する記事を口実とするのは先の依頼のような荒らし行為を正当化するために用いられるものであり、検討の余地はありません。この種の提案は中立性を積極的に毀損する問題行為であることに留まらず、早い者勝ちで記事名を占有できる過去の悪しき慣習を復活させ、そのために削除依頼→リンク調整→記事作成に伴う改名提案→リンク再調整という無用な手間をかけさせて正常な利用者の手を塞ぐ害は、早い者勝ちで他の事象を考えずに記事名を決められる僅かな利益でまかなえるものではありません。たまたま成功した一例にしても邦題未定ならば転写のケミストリーだろうという前提がある時点でこの例に適すると考えることはできず、論拠にしようとする時点で論ずるに値しません。赤リンクが気に入らない？　仮リンクだから削除したい？　そんなことを考える暇があるなら記事を書きなさい。それが赤リンク（仮リンク）のみの状態を解消するためにできる唯一のことです。実例がないというなら実例は差し上げましょう。Wikipedia:削除依頼/ベイズ湖（仮リンクのみで存続）、Wikipedia:削除依頼/同名の人物の曖昧さ回避（リンク先0のまま存続）、Wikipedia:削除依頼/佐々木秀一Wikipedia:削除依頼/PAI（リンク先0から執筆で解消してリンク先1として存続）。Wikipedia:井戸端/subj/記事が一つしか作成されていない曖昧さ回避は必要かも参考になるでしょう。--Open-box（会話） 2020年8月5日 (水) 12:18 (UTC)[返信]
    • コメント 先の依頼とはWikipedia:削除依頼/競合しない曖昧さ回避のページのはずだと思いますが、この依頼に問題点はありますが、不備といいますか、そういうのであってなんだか過度な言葉が飛び出しているように思われます。提起された内容には同意する点もあるのですが、あまり受け付けられない姿勢に感じます。先の依頼では他のノートであった他者の発言が根拠として挙げられいるのですが、引いてはそのコメントやそれをした利用者も同類なんだろうかと。本当にそうならその人たちを引っ張り出すためにも削除依頼や会話ページに考えを表明しておくことも必要かもしれません。--主水（会話） 2020年8月5日 (水) 15:46 (UTC)[返信]
  • 「削除すべき」とする理由は何かありますか? そのような曖昧さ回避ページが存在することで何かデメリットはありますか? --Kto2038（会話） 2020年8月5日 (水) 17:17 (UTC)[返信]
    • 削除されないと、その先例を錦の御旗にして喜んで粗製濫造する、私みたいなキチガイが出るからじゃないですかね。私は有用でない曖昧さ回避記事集めるの趣味なんで喜んで作りますよ。 --（あ）（会話） 2020年8月7日 (金) 14:20 (UTC)[返信]
      • 本当に「有用でない」ならば削除されるでしょうし、他の利用者が何かしら手入れして「有用なもの」になるかも知れません。また、本当に「有用でない」ものを濫造してたら投稿ブロックなどの対処が取られるだけの話じゃないでしょうか。ましてや「有用でない」ことを意図して行うのであれば尚更。--KAMUI（会話） 2020年8月8日 (土) 09:13 (UTC)[返信]
  • (コメント)Wikipedia:曖昧さ回避に「近い将来執筆される可能性がある主題については曖昧さ回避のページに記述しておいて構いません。」とあります。他言語版に記事がある以上「可能性がない」といは言えません。記事の存在そのものがUSPOVとしか思えない場合はこの限りではありませんが、メジャーリーグ経験者に向かってそのような主張をするつもりならどうぞご自由に(対象者のうち、en:Chet Nichols Sr.のみメジャーリーグ歴が明確ではありませんがこのデータベースに出場歴が明記してあります。このデータベースは日本の運営者が定かでないデータベースではなく、Sports Referenceによるものです。また、レジオンドヌール (曖昧さ回避)に含まれるfr:Palais de la Légion d'honneurは10言語版あり、このような主張は不可能と思われます)(また、上にもありますが、日本語版において記事名をそのまま適用したら独自研究になると思われる場合もこの限りではありません)。--6144（会話） 2020年8月8日 (土) 10:19 (UTC)[返信]

ここにあった6144のコメントは除去しました。--6144（会話） 2020年8月9日 (日) 04:45 (UTC)[返信]

ネーミングライツを記事名へ反映するかしないか

競技場関連の記事を見ていて気になったのですが、ネーミングライツを記事名に反映するかしないかがバラバラになっているように思います。同じ京セラがネーミングライツを持っている競技場でも、大阪ドームは正式名（ネーミングライツによる名称は京セラドーム大阪）、京都府立京都スタジアムはネーミングライツのサンガスタジアム by KYOCERAになっており、競技によるのかというとそうでもなく日立柏サッカー場は正式名（ネーミングライツによる名称は三協フロンテア柏スタジアム）となっています。そのため、統一した基準が必要なんじゃないかと思っているのですが、それらの議論を行うにしても、ネーミングライツは競技場に限らないのでスポーツ関連のウィキプロジェクトにするのは違うし、と困っているところです。まずは井戸端で、議論する価値があるかの判断と、議論する場をどこにするかの検討をしたいので、コメントを頂けると助かります。--devicehigh（会話） 2020年8月6日 (木) 15:55 (UTC)[返信]

コメント （前置き）ウィキペディアには容易に改名できる移動機能とリンク切れを起こさせないリダイレクトの自動生成がありますので、[[新名|旧名]]といったリンク元修正などをせずにリダイレクト[[旧名]]経由のリンクのままにしておけば、2回目以降の改名や間違いによる改名戻しも楽に作業できます（某ラジオ番組における改名とリンク元修正の苦悩の歴史）。
記事の書き方は、参考にする文献に記載されている名称をそのまま使用します（つまりリダイレクトの積極活用）。なので、記事の実体が正式名・命名権の名称のどちらにあっても編集作業上ではさほど問題にはなりません。
もし記事名に統一感を持たせるのであれば、公共施設のウィキプロジェクトの新設か（PJ図書館にレベルを合わせてPJスタジアムか？）、サッカーと陸上とコンサートなど各PJ間プロジェクト:スポーツ施設で調整していただくことになります。--Triglav（会話） 2020年8月6日 (木) 17:42 (UTC) すみません見落とし--Triglav（会話） 2020年8月7日 (金) 04:23 (UTC)[返信]
コメント 公立図書館の場合、記事名は条例に基づくこととなっています（プロジェクト:図書館#記事名の付け方）。従ってネーミングライツが愛称に関するものであり条例の改正を伴わない場合は改名せず、条例で定められた名称を用いることになります（例えば大阪市立中央図書館）。例示されたスポーツ施設の場合、既に記事名の名称で通用・定着していたか（大阪ドーム、日立柏サッカー場。福岡ドームも同様）、いなかったか（サンガスタジアム by KYOCERA―開場時点で既にネーミングライツによる名称）の違いということはないでしょうか（現時点でそうした取り決めがあるわけではない以上、そうなっていない例もあることと思います）。--Whatsfb（会話） 2020年8月6日 (木) 22:38 (UTC)[返信]
コメント MAZDA Zoom-Zoom スタジアム広島はプロジェクトルールですね。私を含めた「殴り合いレベル」の議論を行った記憶があります。プロジェクト‐ノート:スポーツ施設/過去ログ1#命名権についてが根拠なのですが、そのルールが10年過ぎても浸透していないのは問題に思います。そして、もし「MAZDA Zoom-Zoom スタジアム広島で無くなったらどうするのか」の決め事も存在しません。正式名称が分かりにくい施設を想定してのルールなのですが、マツダスタジアム自体はっきりわかっている（広島市民球場）。その後新たなネーミングライツ名称を継続して使うのか、その時に正式名称に戻すのか、ルールが整備されていない以上トラブルの原因になりかねないです。ネーミングライツ名称を率先して使うのであれば、他の施設にも拡大して使う。正式名称を率先して使うのであれば、その原則に戻していく。最初に言った「殴り合いレベルの議論」の様に、ルールをしっかり整備する。皆が知っているルールにする。そうしていかないと、またトラブルが起きるように思います。--Taisyo（会話） 2020年8月7日 (金) 03:30 (UTC)、一部修正--Taisyo（会話） 2020年8月7日 (金) 03:32 (UTC)[返信]
コメント どちらがいいとも言い難いのでコメントで。公共施設の場合は条例上の名称を「正式名称」として記事名に採用するのが一番説得力があると思います。比較的短期の改名であっても。ただ条例上の正式名称よりもネーミングライツの名前やネーミングライツ由来の通称が広く使われているようならネーミングライツを採用する方が妥当だと思います。全体での統一ルールは困難だと思いますがプロジェクト単位では命名ルールを作るのが望ましいと思います（プロジェクト内では正式名称、ネーミングライツどちらかに統一しろという意見ではありません）。--Monaneko（会話） 2020年8月7日 (金) 13:06 (UTC)[返信]

様々なご意見や過去の議論履歴、特定プロジェクトにおけるルールをご提供頂きありがとうございます。個人的にはウィキペディアとしての統一ルールが出来れば良いと思っていたのですが、よほどのトラブルに発展しない限りは都度対応のほうがよさそうに感じましたので、当方から議論提起を行うことは一旦取りやめることにします。皆さまご協力ありがとうございました。--devicehigh（会話） 2020年8月10日 (月) 15:38 (UTC)[返信]

LTA:NDBTKによる動物虐待にかかわる書き込みについて

先日（8/6）にLTA:NDBTKによる複数のアカウントにてネコや猫食文化、ノート:ネコなどで動物虐待を示唆する書き込みがありました。また、昨日（8/8）にもやはりLTA:NDBTKと思われる利用者により猫およびCAT、Wikipedia:サンドボックスにて同様の書き込みが行われました。悪戯の範疇といわれればそれまでですが、もし内容が事実であれば、動物の愛護及び管理に関する法律（動物愛護法）に反する行為であり、れっきとした犯罪行為であると考えられます。 一連の書き込みについて、

  1. 警察などに通報すべきか。
  2. WP:DP#Bとしての削除対象であるか（Wikipedia:サンドボックスについては別件で初期化依頼を行っております）。
  3. 仮に通報の対象かつ削除対象の場合、警察等へ通報を行った場合は削除依頼は保留とすべきか。

以上の3点について確認を取りたいと思いますのでよろしくお願いします。--Daraku K.(Talk/Contributions) 2020年8月8日 (土) 17:04 (UTC)（typo.--Daraku K.(Talk/Contributions) 2020年8月8日 (土) 19:08 (UTC)）[返信]

  • とりあえずあれはゲームの中の話だと思います。 荒らし行為だとしても、現役の虐待どうこうではないかと。--2001:268:C05F:9501:F95C:4AF3:E011:7A35 2020年8月8日 (土) 23:32 (UTC)[返信]
    • コメント 今朝出現した同様の荒らしは確かにアメーバピグの中での話のように書かれていましたが、6日に出現したものと、昨日出現したものの内容を見る限り、アメーバピグの中での話ではないような感じで書かれておりました。仮に今回のケースが本当にアメーバピグの中での話であればそれはそれで構わないのですが、（今回のケースはひとまず様子見とするとしても）今後また別のケースで動物虐待にかかわる書き込みが行われた場合における対処の方法にもかかわってくると思われますので、通報や削除の必要性について確認を行いたいところです。--Daraku K.(Talk/Contributions) 2020年8月9日 (日) 01:16 (UTC)[返信]

過去の慣例はどこまで重視されるべきか

ウィキペディアのシステム更新で日本語に対応した2002年以降、約18年に渡りウィキペディア日本語版は活動を行っている為、その間に様々な議論が重ねられ、その結果が方針やガイドラインとしてウィキペディアの運営の基本を形作っている状況であるかと思います。その一方、それらの基本的な方針から外れたまま長年執筆が進められている記事があり、それらの執筆の問題に対して他の記事を先例として持ち出されることがあります。この先例はどの程度尊重する必要があるのでしょうか？

以下は当方で現在議論へ参加している先例を挙げられた事例です。

  • 例1：ハロープロジェクトのグループ記事における各メンバーの記述について、記事本題のグループとは無関係な部分まで経歴を詳報する執筆に対して、他のハロプロ記事を先例として挙げられた事例（ノート:BEYOOOOONDS#編集について）
こちらは当方にてWikipedia:ページの分割と統合#分割の検討のガイドラインを提示し、議論参加者から理解を得た為、現時点ではガイドラインに沿った内容へ変更される見込みです。
こちらは現時点では方向性が定まっておりません。

当方は先例よりも方針やガイドラインを優先すべきと考えており、それらに当たる場合は方針やガイドラインに沿うよう積極的な対応を行うべきと考えているのですが、その様な記事に対しても、明確に合意形成が必要で、合意形成とならない場合は先例が優先されるようなこともあり得るのでしょうか？--devicehigh（会話） 2020年8月10日 (月) 16:18 (UTC)[返信]

「【先例や慣習】と、【方針やガイドライン】の条文が一致していない場合においては、合意形成を軽視して、方針やガイドラインに沿うよう積極的な対応を行うべき」と言われるなら、その考えはウィキペディアとして明白に間違いである以外にないと思います。「ウィキペディアは規則主義ではありません」や「Wikipedia:ルールすべてを無視しなさい」にある通りであって、「方針やガイドライン」と「先例や慣習」はどちらも合意形成をする上での重要な判断材料であるけど、どちらを優先すべきか（あるいは折衷するか）はケースバイケースです。
基本的な考え方としては、その方針やガイドラインが規定されているのは、それなりの理由（ルールの精神）があるはずであって、そこを考慮した上で、明らかに引き合いに出された慣例とぶつかるのであれば、「方針やガイドライン」が優先されるパターンだと思います。逆に、たまたま個別条文にはそうとも書かれている程度であれば、これを引用してそれ以外の見解を認めないというのは、明白にWikipedia:腕ずくで解決しようとしないにある法律家ごっこであって問題行為でしょう。先例や慣習が成立していて、方針やガイドラインの条文と反しているという場合は、それを単に「先例や慣習が誤っている」と判断するのではなく、「方針やガイドラインが適切に保守されていない」という可能性もあって、その場合の解決策は、合意形成を軽視して方針やガイドラインを優先することではなく、方針やガイドラインを改定することです。あるいはその分野に関するウィキプロジェクトのルールとして、その分野の場合の特別な判断基準を設けるなどの流れになるのが、ウィキペディアで想定されているものでしょう。
ついでに言えば、どのようなケースの場合には「方針やガイドライン」を積極的に適応すべきかも慣習や先例に基づくものであって、場合によっては雪玉条項を適応しても良いという合意ができる場合もあるでしょう。今回の、その削除依頼の議論の進展に不満があっても、その結論は先例になって以後同様のケースを判断する場合のモデルになるはずなので無駄にならないです。--EULE（会話） 2020年8月11日 (火) 09:29 (UTC)[返信]

軽く崩れたTemplate

Template:皇位継承順位で表の右上部分が微妙に崩れている部分(今上天皇から見た続柄、摂政就任順位の下の空白)が気になるのですが、これってどうにかなるでしょうか？些細なものですみません。--Tachi L（会話） 2020年8月11日 (火) 11:53 (UTC)[返信]

会話でよく使うアイコン

続けて失礼します。会話系のページで 賛成 反対 コメント 提案 対処などといったアイコンを見かけますが、これらの全アイコンを一覧にしたページはあるのですか？--Tachi L（会話） 2020年8月11日 (火) 12:18 (UTC)[返信]

ローカルアップロードしているファイルの名前について

「Wikipedia:井戸端/subj/Botで大量にコモンズへ移動された画像のファイル1-5による即時削除への対応について」も参照

現在、ウィキペディア日本語版にローカルアップロードしている画像がbotなどによって大量にコモンズに移動されつつあります。ローカルアップロードされている画像は特別:メディア統計から確認できますが、数字だけだったり、特定の固有名詞(例:File:西大津駅.jpg,File:1600系.jpg[補 1]など)だけで、一意とは言えないファイル名だったりすることがかなり多いことが判明しました。 そこで、ファイル名の見直しを行っていくことを提案します。事前に改名しておくことにより、コモンズ移動後の改名提案を提出しなくても良くなり、他プロジェクトへの影響も少なくなると考えています。 また、bot等がどのような計画で画像移動を行っているかは分かりませんが、次のようなファイル名は早めに変更しておいたほうがいいと思います。

  1. (特に)Category:コモンズへの移動推奨に分類されているファイルのうち、コモンズの改名すべき事案に該当するようなファイル名
  2. 数字だけや極めて単純な英数字で構成されているファイル名

もちろん、その他のファイルについても適宜改名が必要なものもあると思います。まずはファイル名の見直し案について、必要性や議論の行い方等のご意見をいただけばと思います。--Mario1257（会話） 2020年8月11日 (火) 16:20 (UTC) -下線部を一部修正追加。--Mario1257（会話） 2020年8月12日 (水) 16:00 (UTC)[返信]

コメント - Category:コモンズへの移動推奨を確認しましたが、とりあえず以下については対応した方が良いと思いました。

File:西大津駅.jpgは西大津駅時代の写真なのでファイル名は正当です。他のファイル名との競合を考慮するなら撮影年月を加え「File:西大津駅 200703.jpg」とでもしておれば問題ないでしょう。--ButuCC+Mtp 2020年8月12日 (水) 13:38 (UTC)[返信]

  • (コメント)了解しました。…とすると、File:西大津駅.jpgで何ら問題ありませんよね(大津京駅に出口は1個しかない)。「特定の固有名詞だけのファイル名」の何が問題なのかわかりません。ButuCC氏には同意します。--6144（会話） 2020年8月12日 (水) 13:45 (UTC)修正--6144（会話） 2020年8月12日 (水) 13:45 (UTC)[返信]
    • 返信 (6144さん・ButuCCさん宛) 「特定の固有名詞だけのファイル名」の意味は、ButuCCさんがおっしゃるように日付等が必要なのではないかという意味です。説明が曖昧で申し訳ございませんでした。説明のほうも、修正・追加させていただきました。--Mario1257（会話） 2020年8月12日 (水) 16:00 (UTC)[返信]
※ 素のrefだと表示個所がややこしい（このサブページが呼び出されるWikipedia:井戸端では他のサブセクションを跨いで最下部へと移動してしまう）ので展開先を移動させました。基本的に議論ではrefを使わず括弧などにした方が無難です。（{{Reflist}}を{{Reflist-talk}}に替えさせて頂きました。議論ページの場合、この方が脚注部分を区別し易いと思います。--野良人（会話・履歴） 2020年8月18日 (火) 15:47 (UTC)）[返信]
「特定の固有名詞」というのはコモンズの改名すべき事案にある「2.無意味であるか曖昧な名前」のうち「広範囲な地名のみ」のことだろうと思っていました。その観点から言えばFile:西大津駅.jpgは被写体が想像し難いほど曖昧な名称ということはなさそうです。これも駅の規模よりけりで、「File:東京駅.jpg」は問題でしょうね。
ただ、以前コモンズ側の改名（commons:File:Mikakino station-2.JPG.JPG→commons:File:Mikakino station-2.jpg）によって日本語版ローカルファイル（File:Mikakino station-2.jpg）と被ってしまったことがあり、ローカルファイルをFile:Mikakino Footbridge.jpgに移動することで対応しました。ローカルファイルがコモンズに移動されるより前に同名の別ファイルがコモンズ側で新規アップロードされる可能性は常にあるので、識別性の乏しい文字列のファイルはそれだけリスクがあります（最近は日本語名でのコモンズアップロードも珍しくないです）。File:西大津駅.jpgについてはその点から日付併記などで差別化を図った方が安全ではあります（まぁ事前に想定するのは限界があるので、その点での改名は急ぐ必要は無く被った時の事後対応で十分とは思います）。--ButuCC+Mtp 2020年8月12日 (水) 16:27 (UTC)[返信]

画像改名の今後

当ノートで提起した改名提案が完了しましたが、Category:コモンズへの移動推奨のほか、改名すべき案がいくつかあると思います。今後も必要に応じて、当ノート等を利用して、議論していただけばと思います。なお必要に応じて(ファイルが利用されているサイトがないなど)、リダイレクトを作成しないようにしたほうがいいと思います。--Mario1257（会話） 2020年8月26日 (水) 17:05 (UTC)[返信]

補足

  1. ^ 画像は名鉄のものだが、1600系は近鉄などにも存在する。

すいとんについて

多分直っていると思います。今後も同じ問題が起こりうるため原因と対処法を書いておきます。
記事中に[[en:○○]]というリンクがあると、そのページの言語間リンクはWikidataの物ではなく「○○」になります。これを[[:en:○○]]にすれば問題は起きなくなります。--PuzzleBachelor（会話） 2020年8月13日 (木) 03:40 (UTC)[返信]
  • コメント 原則として受け入れたい側に翻訳依頼を提出の件、了解しました。ちょっと自分の英語力に自信がなくなっており、英語版でのen:Wikipedia:Pages needing translation into Englishを読んで、ニュアンスを正しく理解して正しい場所に依頼できるか心配でした。時間と労力をかければ読み込むことができるのですが、現在それが少し困難な状況のため、それよりも、ボクより英語力がより優れている利用者の方の助けを借りたほうがよいかなと思って、日本語版で英語版への翻訳を依頼できる場所があったらいいのにと、ふと井戸端に書き込んでしまいました。次にこのような機会がある時には、英語版での依頼に挑戦してみたいと思います。ありがとうございました。--tail_furry（会話） 2020年8月14日 (金) 15:25 (UTC)[返信]

「Wikipedia:リダイレクト」の「正式名称に記事名に使えない文字が含まれる場合」節にあるリダイレクト先の改名

標記について、Wikipedia:記事名の付け方の改定に伴い文字「②」「ö」「Ö」の使用が可能になりましたので(ちなみに「Ⓐ」は使えないようです)、以下の通りの改名を提案します(あわせて、当該文面の改定をWikipedia‐ノート:リダイレクトで提案しています)。

--6144（会話） 2020年8月13日 (木) 03:02 (UTC)Wikipedia:記事名の付け方の制約により先頭を小文字にはできないため「ö」→「Ö」に変更--6144（会話） 2020年9月21日 (月) 12:48 (UTC)[返信]

「IBM拡張文字」にある項目の改名提案

標記について、Wikipedia:記事名の付け方の改定に伴いIBM互換漢字「髙」「德」の使用が可能になりましたので、以下の改名を依頼します。なお、「手塚治虫」の「塚」はCJK互換漢字であり、システム上で勝手に手塚治虫になってしまいますので対象に含めません。

--6144（会話） 2020年8月13日 (木) 06:45 (UTC)タイトル修正--6144（会話） 2020年8月13日 (木) 06:51 (UTC)[返信]

「Wikipedia‐ノート:記事名の付け方」について

標記について、当該ガイドラインの改定を主導した利用者:Monaneko（会話 / 投稿記録 / 記録）さんが、「文字化けが起きようが別に構わない」という理由で、使用禁止文字を追加するというそもそも制限緩和以前は普通に禁止だったものであり、再び禁止にしても誰も困らない提案を拒否しています(そもそも「文字化けが起きようが別に構わない」ならなぜ「制限撤廃」でなく「緩和」だったのか疑問ですが…)。この提案は、ある記事に化ける可能性がある文字を含むリンクがあって、そのリンクが古いブラウザ上で機能しない可能性を理由としたものです。たとえば削除依頼で「アイヌ・イタㇰ」(※捨て仮名「ㇰ」が化ける可能性のある文字に該当)へのリンクが動作しませんなんて事態になったら各依頼ページおよび全プロジェクトを巻き込む大事になります。これに対しMonanekoさんは、「自身も似たような経験があったにもかかわらず、そのような現象の発生が想定できないのでそっちで条件を教えてくれ」と発言しており、事態をあまり理解していないようです。よって、皆さんの参加を希望するものです。よろしくお願いします。--6144（会話） 2020年8月14日 (金) 01:33 (UTC)[返信]

「Wikipedia:連絡先/記事の問題/本人より」について

Wikipedia:投稿ブロック依頼/長谷川豊 他を眺めていて気が付いたのですが、Wikipedia:連絡先/記事の問題/本人よりに、「ご自身による修正」「「編集」ボタンをクリックし、あなたの望むように変更をしてください。」とあり、Wikipedia:自分自身の記事をつくらないに完全に反していますので、この部分を「自分自身による修正は歓迎されません。Wikipedia:自分自身の記事をつくらないを参照してください。」に置き換えることを提案します。--6144（会話） 2020年8月14日 (金) 13:27 (UTC)[返信]

テンプレートの活用度合いを把握するにはどうすればいいですか

Template:Infobox イラストレーターとその解説サブページを加筆したのですが、このテンプレートの必要性は横に置いておくとして、どの記事で使われているか調べることはできますか？Template:廃止されたテンプレートで廃止するとCategory:廃止されたテンプレートを使用中のページから見えるようですが…。--ガッチャ366（会話） 2020年8月14日 (金) 20:05 (UTC)[返信]

返信ツールをベータ機能として導入する提案

導入提案

Phabricatorで追跡中
タスク T261654
解決済み

具体的にはmw:Talk pages project/replying（英語）のツールをベータ機能として導入します。このツールを有効にした場合、下記のような動きになります。

  • ノートページのコメントの末尾に「返信」のリンクが表示されます。これをクリックすると、コメントの直下に返信の編集画面が表示されます。
  • 編集画面ではソースエディターとビジュアルエディターの切り替えができ、これを利用してプレビューを表示できます。
  • 返信内容を入力した後、返信ボタンをクリックすることで投稿できます。
  • インデントと署名は自動的に行われます。

このツールは2020年4月時点では ~~~~（半角スペースと時間付き署名）という書式でしか署名できず、日本語版で多用される--~~~~が使えないため、そのときは私の判断で導入を提案しませんでした（先行議論：mw:Topic:Vk5r8qy9o799ucnw（英語））。その後、phab:T249861の実装により、自動署名の書式を変更できるようになったため、提案する次第です。導入の利点としては「署名忘れやインデントミスを防ぐ」ことを想定しており、ベータ機能として早期導入する利点は「新機能がより早く使えるようになる」「ツールの開発が活発に進められている時期なので、日本語版で発生するバグが修正される可能性が高くなる」ことを想定しています。

あくまでもベータ機能としての導入で、使用を強制するわけではないので、合意形成の期間に1週間を想定しています。--ネイ（会話） 2020年8月17日 (月) 11:36 (UTC)[返信]

強く賛成 異論はありません。--Semi-Brace (会話 / 投稿) 2020年8月20日 (木) 15:17 (UTC)[返信]
賛成 この手のツールは長年研究されており、このベータ版は旧来のツールよりも使い勝手が良くなってきたので導入に踏み切っても良いと思います。--Marine-Bluetalk✿contribs❀mail 2020年8月21日 (金) 15:26 (UTC)[返信]
報告 合意が形成されたと判断してphab:T261654を提出しました。--ネイ（会話） 2020年9月1日 (火) 11:18 (UTC)[返信]
Phabricatorにおける対処の目処はまだ立っていませんが、とりあえずウィキペディア日本語版で試用したい方はURLの末尾に?dtenable=1を追加すれば使用できます。例：このページで試用--ネイ（会話） 2020年9月4日 (金) 17:20 (UTC)[返信]
Wikipedia‐ノート:サンドボックスで試してみました。(返信テスト用)とても便利だと思いますが、
  1. リンク化ボタン等のツールバーに有る機能が使えない点。
  2. インデント戻しが行われない為、インデント戻しが必要な場合には使えない。
のが個人的に気になりました。(英語は分からないので、フィードバック？も出来ず、、、)--お好み焼き星人（会話） 2020年9月8日 (火) 18:24 (UTC)[返信]
@お好み焼き星人さん: インデント戻しについてはmw:Topic:Vtun4m3f3bcpz5wdにて議論中なので、そちらでの結論次第となります。「リンク化ボタン等のツールバーに有る機能」についてはもう少し詳しい説明をお願いできませんでしょうか？--ネイ（会話） 2020年9月13日 (日) 16:00 (UTC)[返信]
僕は基本的にソース編集だったので分かりませんでしたが、ビジュアル編集で返信する際には有るボタン(リンク等)のことです。提案いただけたようで感謝します。ただ、リンク先とリンク文で違うテキストを指定したい場合に、難が有るみたい(リンク先の指定欄しかない)なので、そこを改善出来ないでしょうか？--お好み焼き星人（会話） 2020年9月14日 (月) 19:07 (UTC)[返信]
ビジュアル編集では「挿入」ボタンをクリックした後に文字列を編集できます。この挙動は現行のビジュアルエディターと同一なので、ビジュアルエディター側での変更になり、編集ツールの開発チームによる対応は難しいと推測します。一方、ソース編集での挙動については返信ツールではまだ実装されていないので、現時点では何とも言えません。--ネイ（会話） 2020年9月15日 (火) 05:15 (UTC)[返信]
文字列変更……なるほどです。ビジュアル編集における件は、『単純に、僕がビジュアル編集に慣れていないだけ』みたいですね。ビジュアル編集における件は、問題なかったと言えそうです。
ソース編集の方の実装待ちですね、とりあえず、個人的には。--お好み焼き星人（会話） 2020年9月15日 (火) 05:45 (UTC)[返信]
  • CharInsertは基本的に「マークアップ」固定で使っています。あくまで個人の使用例ですが、ノートページでは<code>...</code>と<nowiki>...</nowiki>を使う頻度が高いと思います（稀に<ref>...</ref>も使用）。キーボード入力と違って入力ミスをする心配がないので、全てのタグ名を完璧に覚えておけない私にはありがたいツールです。--Keruby（会話） 2020年9月19日 (土) 16:14 (UTC)[返信]
    ご返信ありがとうございます。Kerubyさんの返信を転記しておきます。code要素については返信ツールのビジュアルモードで使用できる（ツールバーの3番目から「コンピューターのコード」を選ぶ）ので、前出のmw:Topic:Vtyoeybmtt9a5gmgで対応されるだろうと思います。また、ビジュアルモードではHTML要素の直打ちなどマークアップとして解釈されそうなものにはnowikiタグが自動的に追加されます。--ネイ（会話） 2020年9月19日 (土) 17:03 (UTC)[返信]
@Kerubyさん:
  • 不要な空行：mw:Topic:Vtynpcw1wi94m75iにて報告しました。
  • CharInsert：ガジェットによる実装なので、まだベータ版である返信ツールに対応していないのはある程度仕方がないと思います。正式化されるまで仕様が変わる可能性もあるので、今すぐ対応しないほうがよさそうとも感じます。
  • 編集ツールバー：ビジュアルエディターであればある程度（太字などの文字修飾、リンク、利用者への言及）は表示されます。ソース編集でも同様に表示するようmw:Topic:Vtyoeybmtt9a5gmgにて提案しました。--ネイ（会話） 2020年9月14日 (月) 14:58 (UTC)[返信]
  • 不要な空行についてはWhatamidoing (WMF)さんから「想定された挙動である」（this is expected）との返答がありました。ウィキテキストにおける（コロンによる）インデントはHTMLでは説明リスト要素（dl要素）に該当し、Whatamidoing (WMF)さんはリスト要素の前に空行を1つ入れるべきとする利用者が大半（ただし、全員ではない）と返答しました。なお、（リスト要素の直前における）空行のあり/なしはソースでのみ表示され、実際の表示には影響しません。--ネイ（会話） 2020年9月15日 (火) 05:15 (UTC)[返信]
返信ツールがウィキペディア日本語版でベータ機能として導入されたことをお知らせいたします。--ネイ（会話） 2020年9月18日 (金) 01:39 (UTC)[返信]

既知の不具合・要望

  • （要望・実装済み）要約欄を編集できるようにしたい：返信画面の左下にある「詳細」をクリックすることで編集できます。
  • （要望・議論中）インデントを:か*で行うか選択できるようにしたい：現行の仕様では常に:となっていますが、mw:Topic:Vu8z37woqb5eit3eにて議論中
  • （要望・議論中）インデント戻しをできるようにしたい：mw:Topic:Vtun4m3f3bcpz5wdにて議論中
  • （要望・議論中）ソース編集で編集ツールバーが表示されるようにしたい：mw:Topic:Vtyoeybmtt9a5gmgにて報告済み
  • （仕様）返信するコメントにインデントがない場合、元コメントと返信の間に改行が入る：mw:Topic:Vtynpcw1wi94m75iにて報告したが、Whatamidoing (WMF)さんから「想定された挙動である」「リスト要素の前に空行を1つ入れるべきとする利用者が大半（ただし、全員ではない）」との返答あり
  • （仕様・解消済み）Help:UTCの時刻を地方時で表示するは署名日時の書式を変更するため、返信ツールと併用不可

ベータ版へのコメント

  • 報告および翻訳済みの件、ありがとうございます。字下げに関してもう1つ気になったのでコメントします。この井戸端のノート（私の勘違いで削除依頼を提出してしまいましたが取り下げました。失礼しました）の「テスト3」節で試してみたのですが、「**」で字下げしたコメントに返信ツールを使って「**:」で字下げして返信し、その後「**」で字下げしたコメントと「**:」で字下げしたコメントの間に「:*」で字下げした（追記などの）コメントを挿入すると、「**:」で字下げしたコメントの字下げレイアウトが崩れてしまいます。自分で書いておきながら「このようなケースはそれほど頻繁には起きないだろうな」とは思いますが、返信先の字下げがアスタリスクで字下げされていても「**:」ではなく「:::」のようにコロンだけで字下げして返信するように揃えれば、後から追加されたコメントを原因とする字下げのレイアウト崩れを未然に防ぐことができるのではないでしょうか。同様に今後、字下げのオプションにアスタリスクを選択できるようになった場合は「*」「:*」「::*」のように字下げの最後のみアスタリスクでそれ以外はコロンにすることで、後から追加されたコメントを原因とする字下げのレイアウト崩れを予防できると思います。ちなみに現在の返信ツールでは改行を行うと「1行目はコロン、2行目もコロン」で字下げされるようですが、字下げにアスタリスクを使用する場合は「1行目はコロン＋最後のみアスタリスク、2行目はコロンのみ」で字下げするようにすれば可読性が高くなるのではないでしょうか（改行ごとにアスタリスクで字下げすると別々のコメントに見えて可読性が低くなるので）。
話は変わりますが、このツールの名称が個人設定のベータ版機能ページでは「議論ツール」、mediawikiwiki:Talk pages project/Feature summary/ja#返信ツールでは「返信ツール」となっているのでどちらかに統一したほうが分かりやすい気がします（個人的には「返信ツール」のほうが好みです）。--Keruby（会話） 2020年9月19日 (土) 16:14 (UTC)[返信]
インデント：返信ツールを使用したコメントではレイアウト崩れが想定されていないと思います（実際、お示しした例では**:で正しく字下げしています）。この例では前後のコメントに揃えず、:*で字下げした利用者が悪い（＝返信ツールの問題ではない）と考えます。
ツールの名称：拡張機能名がDiscussionTools（議論ツール）で、議論ツールが提供する機能の1つがReply Tool「返信ツール」となっています。もう1つは開発中で現在使用できないNew Discussion Tool（新議題ツール）ですが、phab:T263054によれば返信ツールと新議題ツールは拡張機能内部でコードベースを共有しているようです。推測ですが、片方だけ使用することを想定していないという意味で拡張機能名を表示しているかもしれません（ただのバグである可能性もありますが）。--ネイ（会話） 2020年9月19日 (土) 16:54 (UTC)[返信]
  • Example Ex [返信]ample
  • Example E [返信]xample
のように末尾ではなく文字列の途中に表示されてしまう不具合があるようです（macOS v10.15.7のSafariとGoogle Chromeで確認）。このようなケースでも「[返信]」リンクが末尾に表示されたらいいと思います。--Keruby（会話） 2020年10月26日 (月) 08:22 (UTC) 修正。--Keruby（会話） 2020年10月26日 (月) 21:03 (UTC)[返信]
  • 情報 署名時刻の後に空白を含まない英字の文字列が記載されている場合でも「[返信]」リンクが末尾ではなく文字列の途中に表示されるケースがありました（ノート:ポケモンショックを参照）。--Keruby（会話） 2020年10月27日 (火) 16:40 (UTC)[返信]
    うーん、初心者によるミスであることが明らかであれば、その文字列を除去する形で修正したほうがよさそうだと思います。また、返信ツールを使用していれば起こらない問題（署名が常に一番後ろにつけられる）なので、返信ツール（+新議題ツール）が標準で使用できるようになったら解決するように思われます。--ネイ（会話） 2020年10月31日 (土) 09:33 (UTC)[返信]

インデント戻しについて

インデント戻しの機能についてですが、mw:Topic:Vtun4m3f3bcpz5wdにてWhatamidoing (WMF)さんより質問があったので、ここでも聞いてみます。具体的には、インデント戻しボタンの正しい挙動について知りたいです。たとえば、直前のコメントが:::::::::::と11段のインデントになっているものとします。そのまま返信した場合、返信コメントは12段のインデントになりますが、返信のときにインデント戻しボタンをクリックした場合の挙動は下記のどれにすべきでしょうか？

  1. インデント戻しボタンを1回クリックすると、返信のインデントが1段になり、もう一度クリックすると12段に戻ります。
  2. インデント戻しボタンを1回クリックするごとに返信のインデントが1段減り、11回クリックすると1段になります。1段になった状態でさらにクリックすると12段に戻ります。
  3. その他（欲しい挙動についてご説明いただけると助かります）。

--ネイ（会話） 2020年9月29日 (火) 12:53 (UTC)[返信]

  • （2）が柔軟性があって使いやすそうだと思います。あと「現時点で何段戻した状態であるか」を返信前に数値で確認できると便利な気がします。それから返信ツールの入力欄が空欄の時に表示される「〇〇（利用者名）に返信」の部分もインデント戻しの段階変更に合わせて変化すると、インデント戻しのミスを防ぐのに便利かもしれません。--Keruby（会話） 2020年9月29日 (火) 16:06 (UTC)[返信]
  • ２の派生？で、『12段→1段→2段→(略)→11段』が良いと思います。--お好み焼き星人（会話） 2020年10月1日 (木) 08:13 (UTC)[返信]
    　思うのですが、普通インデント戻しを行う時って、『本来であれば１２段とすべきだが、それでは視認性に支障が出るため、便宜上、１段に戻す』場合だと思うんですよね。
    　１月３２日と出来ないから、２月１日とする、みたいな感じです。なので、優先度としては、『(インデント戻しを行わない)１２段』が一番高く、次いで『(１２段に相当する)１段』となる筈です。
    　『インデントがＸ段のコメントに返信している』という情報を提示した上で、自由入力またはプルダウン式で『インデントをＹ段まで戻す(－Ｚ段)』という指定が出来たら良いかも知れません。
    　(自由入力の場合、{{インデント戻し}}は全角数字だと機能しない筈なので、全角数字は半角数字に自動変換。性質上、返信先コメントよりも深いインデントが指定された場合はインデント戻し処理を行わない。それ以外の文字列が指定された場合も処理を行わない、等が必要でしょう。)
    　(プルダウン式の場合は、テンプレート規格外の文字列が指定されることはないですし、『インデントが１１段のコメントへの返信』に対して『インデントを６段まで戻す(－５段)』というような選択肢名にすれば分かりやすい気がします。インデントは精々が十数段までで、２０段まで行くことも普通はないでしょうし)--お好み焼き星人（会話） 2020年10月3日 (土) 08:29 (UTC)[返信]
    場合によっては、特別:差分/78972542のような区切りを入れられるオプションが有った方が良いかも知れません。必要ないかも知れません。
    これに関しては、ふと思ったので、一応念のために言及しただけです。--お好み焼き星人（会話） 2020年10月3日 (土) 08:35 (UTC)[返信]

新議題ツールの設計への意見募集

新議題ツールのデザイン案がmw:Talk pages project/New discussion#Version 1.0で公開されました。現在mw:Topic:Vwpwr84naer42oviにて意見を募集していますが、英語によるコメントが難しい方は本節にて日本語でコメントできます。英語に翻訳して当該トピックに転記します。--ネイ（会話） 2020年10月31日 (土) 09:36 (UTC)[返信]

コメント （英語で直接コメントしようかと思ったのですが、色々難しかったのでこちらで失礼します。）新議題ツールや返信ツールの使用中は、ブラウザのタブ中に「話題を追加中」「返信中」のような内容を表示するようにしてもらえると便利ではないかと思います。複数のタブを開いて色々確認しながら作業していると、どのタブで話題追加・返信していたか分からなくなることがあるので。--Kyosu-tann（会話・投稿） 2021年3月13日 (土) 08:44 (UTC)[返信]
コメント はじめて使いました。プレビュー機能がない（または見つけにくい）のでどのように編集されるのか不安です。--築地川（会話） 2021年10月26日 (火) 12:40 (UTC)[返信]
築地川さんはソース入力を使用していらっしゃいますよね。それなら特に何もせずとも、入力しているテキストボックスの真下にプレビューが表示され、リアルタイムで更新されていくはずです。--McYata（会話） 2021年10月26日 (火) 13:46 (UTC)[返信]
McYataさんご指摘の通り「下に」プレビューが表示されているようですが、いつも私が使っている入力では「上に」プレビューが表示されるのとは違いますし、プレビューボタンがなくてボタンを押さなくても勝手にプレビューが表示されていくのでやはり違和感があります。また、返信機能を使うことでどんどん右にずれていくのはあまり好きではないので今後は返信機能を使わないことにします。--築地川（会話） 2021年10月28日 (木) 15:42 (UTC)[返信]
「https://ja.wikipedia.org/w/index.php?title=Wikipedia:井戸端/history20230304&oldid=79081511」から取得