コンテンツにスキップ

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

削除された内容 追加された内容
38行目: 38行目:


:{{賛成}}基本的に賛成です。[[草なぎ剛]](草彅剛)、[[朴ロ美]](朴璐美)のような混ぜ書き、[[高梨沙羅]](髙梨沙羅)、[[種崎敦美]](種﨑敦美)、[[吉田恵輔]](𠮷田恵輔)、[[BOOWY]](BOØWY)のような代え字を避けることが可能になります。ただ、完全撤廃すると妥当性があれば絵文字でも何でもありになります。😀(スマイル)は出る環境が多いと思いますが、たとえば🦧️(オランウータン)はやや古いスマホでは出ないかもしれません。いまのところ芸名やグループ名に絵文字が入った方は知らないですが。--[[利用者:Monaneko|Monaneko]]([[利用者‐会話:Monaneko|会話]]) 2020年5月8日 (金) 13:36 (UTC)
:{{賛成}}基本的に賛成です。[[草なぎ剛]](草彅剛)、[[朴ロ美]](朴璐美)のような混ぜ書き、[[高梨沙羅]](髙梨沙羅)、[[種崎敦美]](種﨑敦美)、[[吉田恵輔]](𠮷田恵輔)、[[BOOWY]](BOØWY)のような代え字を避けることが可能になります。ただ、完全撤廃すると妥当性があれば絵文字でも何でもありになります。😀(スマイル)は出る環境が多いと思いますが、たとえば🦧️(オランウータン)はやや古いスマホでは出ないかもしれません。いまのところ芸名やグループ名に絵文字が入った方は知らないですが。--[[利用者:Monaneko|Monaneko]]([[利用者‐会話:Monaneko|会話]]) 2020年5月8日 (金) 13:36 (UTC)
: 朝h偽新聞でも表記ゆれが起き始めているようです。例えば「[https://digital.asahi.com/articles/ASN4S7FMSN4SUCVL021.html 『新しい地図』が基金設立 コロナ対策に3千万円を拠出]」では、「草'''彅'''剛」表記で、「[https://digital.asahi.com/articles/DA3S14456907.html 『新しい地図』基金、医療従事者らを支援 3千万円拠出、寄付も募集]」では、「草'''なぎ'''剛」表記が使われています。大手メディアは、正しい文字が表示さえない環境に対する配慮が通常のウェブサイトよりも高いと思いますが、それでも「彅」表記が許容され始めているのだということだと思います。もはや、このような配慮は単なるお節介の意味を出ないものとなっていることから概ね同意いたします。
: 一方で、Monanekoさんが仰っている通り、一部の新しい文字については文字コードが割り当てられている一方でフォントが用意されていないがゆえに、文字が表示できないという事例もあります。皆さんの環境はわかりませんが、私の環境では、[[ビャンビャン麺]]の冒頭部が正しく表示されず、パソコンのブラウザで見ると四角い箱のようなものが表示され、iPhoneでは文字があることすらわからなくなっています。
:: '''ビャンビャン麺'''({{拡張漢字|G|𰻞𰻞}}麺、ビャンビャンめん、{{lang-zh|{{拡張漢字|G|𰻞𰻞}}麵}})は[[中華人民共和国|中国]]の[[陝西省]]で一般的な幅広の[[麺]]。
: 中国版ウィキペディアでは、新しく割り当てられた文字コードを使った記事名に移動している([[:zh:𰻝𰻝面|𰻝𰻝面]])ことから、iPhoneで見ると「[[面]]」という記事と同じ記事として表示されています。そのため、使用できる文字を拡大するのであれば、文字が割り当てられてからX年が経過している、主要なフォントがサポートしているなどの条件に従って、使える文字の一覧のようなものを策定して、その中で記事名を付けるといった対応が必要だと思います。 [[利用者:片割れ靴下|片割れ靴下]]([[利用者‐会話:片割れ靴下|会話]]) 2020年5月8日 (金) 14:04 (UTC)

2020年5月8日 (金) 14:04時点における版

井戸端は、ウィキペディア日本語版について、運営、方針、新しいアイディアや作業の仕方、その他様々な事で質問や提案、議論、意見交換を行う場所です。詳しくは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日が経過すると、井戸端への読み込みが解除されます。
投稿しましょう

スマホで見ると欧州連合がおかしい

スマホで欧州連合を見たら公用語表記と地図の間に謎の大きな空白ができてしまいます。この前見た時も同じだったので通信環境は関係ないと思います。どなたかなんとかしてくれると嬉しいです。--以上の署名のないコメントは、126.236.105.17会話/Whois)さんが 2020年4月17日 (金) 15:34 (UTC) に投稿したものです(ホーリーブライト会話)による付記)。[返信]

コロナウイルスに関する根拠なき主張を展開する者

  • コメント Wikipediaにおいて、コロナウイルス感染症に関してどさくさに紛れて根拠のないでたらめを主張する者が見受けられます。ただでさえ出典を重視するwikipediaで、ましてこのご時世に正確性が必要となるコロナに関する記事に関して、根拠のないいいかげんな発言をすることは慎んでいただきたいと思うのですが、何かそのようなことを徹底するすべはないでしょうか。もちろん、もともと出典を重視するのがwikipediaではあるのですが。--126.198.197.59 2020年4月21日 (火) 04:19 (UTC)[返信]
  • コメント - お怒りのようですが、この場合、「書く人」に腹を立てたり苦言を呈したりしてもしょうがないのです。システム上、誰でも書けて編集できることになっているので、中にはWikipediaの理念や規則を理解していない人もいるでしょうし、事実と妄想を区別する能力がない人もいるでしょうし、完全に悪意で編集する人もいるでしょう。怒っても仕方ありません。善意の編集者にできることは、おかしな記述を見つけて修正する、削除要請を出す、議論する、などです。--Adan会話2020年4月21日 (火) 05:13 (UTC)[返信]
  • コメント もしそういう行為ばかりを続け、投稿ブロックされていないのでしたら、管理者に報告してブロックしてもらった方が良いと思います。ブロックしてもブロックしてもそういう利用者が出てくるのは、仕方がないことです。地道に編集の取り消し・報告などを続けるしかありません。--Tmv会話|投稿記録2020年4月22日 (水) 04:56 (UTC)[返信]
  • 報告 ただ、Muyoさんの「記録」を見るとそれなりに活動歴の長い人のようですし、Wikipediaが出典を重視していることを知らなかったとは考えにくいと思います。そんなベテランの人が「今後注意いたします」などと発言しているわけですから、当然「今後? 今後注意するの? じゃあ貴方は今の今まで出典には全く注意を払っていなかったの? 出典皆無の根拠なき出鱈目を書き込んでも許されると思って今まで活動していたの?」と不可解な思いを抱く方も多いと思います。ですので、いったんは様子を見るものの、もしMuyoさんが出典皆無の根拠なき出鱈目を再度書き込んだ場合は、Tmvさんからのアドバイスに従い即座に「管理者に報告してブロックしてもら」えるよう依頼を出そうと思います。--126.146.222.56 2020年4月30日 (木) 02:06 (UTC)[返信]

────────────────────────────────────────────────────────────────────────────────────────────────────(インデント戻し コメント コメント (主に126.146.222.56さん宛) 確かにでたらめを書くのは方針に反していますから、投稿ブロックの対象ともなりえるでしょう(そう思ったので投稿ブロックについて上で言及いたしました)。ただ、Muyoさんくらいの利用者さんとなると、他のコミュニティの利用者さんからも色々とあるかもしれないので、コメント依頼の「利用者についてのコメント依頼」のところでコメントを依頼した方が良いかも知れません。コメント依頼は投票資格とかコメント資格とか制限が全くないので、126.146.222.56さんでも提出できると思いますが、投稿ブロック依頼はIPさんは提出できないのでどなたか「依頼時点で編集50回以上、かつ活動期間1ヶ月以上の被依頼者でないログイン利用者」に当てはまる人にお願いした方が良いかも知れません。--Tmv会話|投稿記録2020年4月30日 (木) 05:55 (UTC)[返信]

  • コメント Tmvさんの主張は全く馬鹿げた主張だと思います。「Muyoさんくらいの利用者さんとなると、他のコミュニティの利用者さんからも色々とあるかもしれない」などと主張していますが、人によって対応を変える必要があるのでしょうか。少なくとも、コロナウイルス感染症に関して出典皆無の根拠なき出鱈目を故意に書き込んでいくような人は、誰であれWikipediaにとって存在価値はゼロだと思います。Muyoさんの行為は、出典を重視するWikipediaにおいては看過できない極めて悪質な行為であり「Aさんだったら許されるが、Bさんだったら許されない」とか「Cさんだったらコメント依頼でよいが、Dさんだったら即時ブロックでよい」とかそういう類の問題ではないでしょう。出典皆無の根拠なき出鱈目を故意に投稿するというのは、誰がやったとしても重大な迷惑行為であり、人によって迷惑の影響度合が変わるわけではありません。--126.151.33.138 2020年5月2日 (土) 01:27 (UTC)[返信]
    返信 (126.151.33.138さん宛) しかし、今まで別の分野に多大な貢献をしてきた利用者の方なら、その方がブロックされるのはその分野の編集者にとってとても悔やまれることですし、もったいないことと思うでしょう。そういう意味で上のコメントをいたしました。経験がない利用者さんなら出典のない記述(=あなたの言うでたらめ)を書いた→すぐブロックということになるでしょうけれども、もしも経験があり、他の場所で貢献している利用者さんならまた別の視点でのコメントもあるでしょう(経験のない方はそんなにあっちの方面でもこっちの方面でも活動するということはあまりありませんし、あったとしても貢献といえるような活動があるのは非常にまれでしょう)。そういった意味でわたしは「Muyoさんくらいの利用者さんとなると、他のコミュニティの利用者さんからも色々とあるかもしれない」と申しました。つまりは、他の利用者さんにも意見を聞くべきだ、と言っているわけです。--Tmv会話|投稿記録2020年5月2日 (土) 04:11 (UTC)[返信]

コメント ページを完全に保護してお偉い方々にのみ編集を依頼してみては?状況が状況ですし、このページだけは依頼しても良いのではないでしょうか?—TRAMPJP会話2020年5月7日 (木) 15:24 (UTC)[返信]

質問 TRAMPJPさん) このページというとコロナウイルスの記事ですか?依頼する場合、保護の依頼理由のどれに当てはまるかが微妙ですね。Wikipedia:保護の方針#保護をかけてもよい場合の2あたりを見てもMuyoさんは対話拒否をしているわけではありませんし。あと、「お偉い方々」というのは間違っていると思います。たとえ管理者さんでもIPの利用者さんと同じで、上下関係はない、はずでしたが。--Tmv会話|投稿記録2020年5月10日 (日) 02:10 (UTC)[返信]

コメントちょっと意味が分からないのですが、立項者が問題にしているのはMuyoさんがWikipedia:削除依頼/アベノマスクにて存続票を投じた際のコメントですよね?そこは自身の意見を自由に書いてよい場所であって、記事の正確性とか出典重視とかまるで関係ない話だと思いますが、この話題に参加している皆さんは本当にそれが問題だと思ってらっしゃいますか?ざっと見た限りコロナ関連の「記事」対して実際にMuyoさんが行っているのは不適切編集の巻き戻しだけで、特に根拠なき主張の展開もデマの拡散も記事の破壊も無いと思いますがどう思われますか?--219.102.85.242 2020年5月12日 (火) 04:32 (UTC)[返信]

コメントそもそも、なんでこの話題が一番上にあるんですか。悪意あるいちゃもんにみえますが。 --ねこぱんだ会話2020年5月12日 (火) 12:21 (UTC)[返信]

ごめんなさい。いつのまにかこれが一番古い話題になっていたのですね。上記発言を取り消します。 --ねこぱんだ会話2020年5月12日 (火) 12:25 (UTC)[返信]

「Wikipedia:中立的な観点」の大幅改訂に関する調査投票を実施中です!

今年の2月中頃より、Wikipedia‐ノート:中立的な観点#大規模な改訂提案にて「Wikipedia:中立的な観点」の方針文書の改訂が審議されています。この度、その改訂草案「Wikipedia‐ノート:中立的な観点/草案2020年版」について、変更内容の賛否を問う調査投票「Wikipedia:中立的な観点/草案2020年版/調査投票」を4月20日(月)から5月20日(水)まで実施する運びとなりました。出来るだけ多くの利用者の方々にご参加いただくべく、多くのアクセスがある、ここ井戸端にて告知をさせて頂きます。皆様のご投票、ご意見・ご感想をお待ちしています。--Doraemonplus会話2020年4月21日 (火) 14:00 (UTC)[返信]

コメント 見ました。過去非常に多くの各議論で「記事名は中立的の対象外」「いや記事名も完全中立にすべきだ」とか、「併記には内容の重要度(特筆性?)に応じたバランスも必要なのか」となどの話がようやく含まれたようで、しかも整理されていて、個人的には大賛成です。賛否にかかわらず、是非多くの方に見て頂きたい重要な内容かと思っています。--Rabit gti会話2020年4月23日 (木) 04:26 (UTC)[返信]
返信 改訂内容についてご好評いただき、ありがとうございます。改訂手続きに瑕疵のないよう着実に改訂を進めて参る所存です。--Doraemonplus会話2020年4月28日 (火) 03:47 (UTC)[返信]

過去に改訂議論はあったのか

調査投票ページのコメント欄で、中立的な観点の方針に関して「過去に改訂の意見が出たかどうか(改訂議論の有無そのもの)」について調査して提示するよう、ご依頼がありましたが、あいにく私は過去の議論に通じていないため、思うように調査が進んでいません。過去に行われた改訂議論をご存知の方がいらっしゃいましたら、そのリンク先とともにご一報いただけると助かります。よろしくお願い申し上げます。--Doraemonplus会話2020年4月28日 (火) 03:47 (UTC)[返信]

画像提供依頼で写真が古いという理由で新しい依頼を出したほうがよいのか

コメント こんばんは。Portal:日本の都道府県/青森県/画像提供依頼利用者:切干大根会話 / 投稿記録 / 記録さんが野辺地駅について、10年以上前の写真しかないという理由で画像提供依頼を出されていたのを確認したのですが、駅舎が変わったなどという理由ではなく、ただ単に画像が古いからという理由で依頼を出してよかったものかどうか、気になったので井戸端に投稿しました。野辺地駅の画像を見る限りは、はっきり駅舎が写っていますし、とくに駅舎が変更になっていない限りは、変えなくてもいいものではないかという気がします。青森県内で画像を提供していただける方が見つかれば容易いのかもしれませんが、もし青森県内に提供する人がなかなか見つからなくて青森県外から取材して取ってこようとする場合、野辺地駅までのアクセスが難しいことも考慮に入れていただきたいと思います。仮に、古いから画像を変えるということになると、10年くらいのスパンで写っているものが古くなったものについては画像提供依頼を出して誰かに提供していただくということになるかと思いますが、極端に背景が変わったとかいう理由がない限り、メンテナンスの面でそれはいいのかどうか、心配です。(最近、新潟県内の道の駅でも画像が古いからという理由で張り替えられていた方がいて、その方の画像に不安があったため、じゃあ場所の近いボクさらに新しい画像撮ってくるという感じで張り替えてみたりしてたのですが、以前の外観と比べてほとんど変わっていない状態で画質だけ良くなっている状態のため、わざわざそこに行って撮る意味あったのかな、と思うことは何度かありました。)新しい画像は画質が良くなっているからよりよい条件になるとは思いますが、今の所、ボクはアクセスしにくい箇所に関しては無理に変えなくてもいいのではないかという意見です。(提供依頼は残して置いてもいいとは思います。切干大根さんの主観なので。)--tail_furry会話2020年4月23日 (木) 15:21 (UTC)[返信]

  • 現在の写真はJR時代のものです。青い森鉄道移管後の写真の依頼しております。移管後、駅看板が変わっており、JRの企画きっぷ案内の看板も取り外されております。--切干大根会話2020年4月23日 (木) 15:32 (UTC)[返信]
コメント 画像提供依頼での補足ありがとうございます。必要性があることを了解しました。ただ、同じ場所の写真について、古くなったという理由での、あまり景色が変わらない画像への貼り替えについては、必要性がないのではないかと考えていることは表明しておきます。--tail_furry会話2020年4月24日 (金) 12:04 (UTC)[返信]
コメント 「古い」というのは表現としては曖昧なところがありますよね。単に時間が経過しているというだけの場合と、「現状とは違う」という場合と。
単に時間が経過しているだけの場合には「何年以上だと古いということになるのか」っていう結論のなさそうな話になりそうです。これは被写体によりけりの面もあり、たとえば「国宝の茶碗」の写真の場合には、50年前の写真を使ってもあまり問題はないでしょう。屋外の情景などでは、主題そのものに手が加わってないとしても周囲の景色が変わってるみたいなこともあるでしょう。「あまり景色が変わらない」画像の場合には、更新の必要性(優先度)は低いでしょうね。
大原則として、ここは百科事典であって、「最新状況まとめサイト」ではありません。なので、画像の主要な役割は、記事本文を理解するための手助けとなることでしょう。記事の中でその画像を必要とするような記述があるならば「最新状況」を反映した画像はあるといいでしょう。逆に、たとえばですけど、昭和30年代に廃止された駅の記事で、記事中に「令和2年の現況」の記述がないのに「令和2年の画像」は必要ないでしょう。もちろん、廃止後の駅やその周辺に関する記述があるならば、「今はこうなった」という画像はあっていいと思います。
Wikipedia:画像利用の方針は専ら著作権などの法的問題の注意点に終始しています。文書の効力がどうかというのはありますが、Wikipedia:百科事典向け写真撮影のガイド/説明写真あたりがひとつの指針でしょう。
既にtail_furryさんも納得されてらっしゃるようですが、野辺地駅の場合には「青い森鉄道移管後」の写真がほしいというのは、合理的な要請でしょう。
似たような画像が複数ある場合にどれを使用するか、という選択については、しばしばトラブルの発端になっていますね。むずかしい。とくにinfoboxなどに使用する「1枚」を選ぶのはむずかしい。たとえば野辺地駅の場合、私だったら「野辺地駅の最盛期の画像」(おそらく昭和期かそれ以前)を選びたいなと思います、が、他の方は「現在の写真」を好むかもしれません。今回の話題とは逸れますが人物記事などは余計難しいですね。
画像提供依頼については、これは個人的な印象ですが、記事全体における重要さの観点で「依頼」が不必要に目立っているというようには感じています。その結果として、求める画像の入手難易度もあわせて考えたときに、ネガティブな印象を抱くことがあるな、とも思います。--柒月例祭会話2020年4月25日 (土) 04:05 (UTC)[返信]
コメント 例えば、改築で建物の形状が大きく変化したのなら、新しい方の画像に差し替えたらいいでしょう。一方で本件のように単に経営媒体が変わって建物が変化していないだけなら、善意側に寄せて言うなら「差し替えるかどうかは、人の好き好き」、きつめに言うなら「建物変わってないから差し替え不要」というところではないかと思います。野辺地駅のケースのように「看板だけ変わって建物自体は変化していない」パターンは後者だと私は見なすので、当面は差し替えの必要もなく依頼も不要不急じゃないかなとは思います。「青い森鉄道移管後」の写真を求める気持ちは理解できなくもありませんが、依頼に出さないといけないほど緊急性の高いものでもないでしょう。
それと、㭍月例祭氏も最後の方で触れていますが、(㭍月例祭氏同様に、あくまで個人的な印象と前置きしますが)日本語版は他言語版と比較して画像提供依頼が無駄に目立つという印象があります。先刻もこういう衝突がありましたが、画像提供依頼には一定の制限や時限を設けたり、依頼削除のルールを緩めるべき(現状は依頼者の圧倒的有利と感じます)ではないかとも思っております。--Ogiyoshisan会話2020年4月26日 (日) 22:58 (UTC)[返信]
画像提供依頼は緊急性を求める性格のものではなく、すべて不要不急なものであると理解しております。ただし、当該ノートで申し上げている通りの理由で、依頼削除のルールのハードルを下げることについては同意です。--切干大根会話2020年4月26日 (日) 23:20 (UTC)[返信]

名前空間と統計について

標記の件について、3点ほど疑問・提案をさせていただきます。もし、賛同いただけるなら議論の進行をその方にお任せします。初学者&あまり活動しなく、投げやりな者が、このような提案をすることが不適切かもしれませんが、一つの改善案になればと思います。

また、利便上、各項目別に署名をさせていただきました。

統計について

特別:統計で、記事数と総ページ数を閲覧することが可能ですが、Help:名前空間#名前空間別の閲覧用ショートカットにて「一覧」などの機能があるのを見た際、各名前空間別でどれほど記事数があるのか気になりました。なので、Help:名前空間上だけでも名前空間別の統計を見れるようにしてみてはどうでしょうか。--股志会話2020年4月25日 (土) 07:30 (UTC)[返信]

コメント 良いと思います。が、それが技術的にどのように可能になるか分からないので、詳しい方のご意見をお待ちしましょう。--Atmark-chan </稿> 2020年5月2日 (土) 23:55 (UTC)[返信]
コメント 良いと思います。
あと、統計を取る項目についてですが、
  • 名前空間別のページ数(リダイレクト含むのと除くのとあると良いと思います)
のほか、何かありますでしょうか? 日本語版の統計に倣って、名前空間別で「閲覧回数の多いページ」とかも入れてみましょうか。--Atmark-chan </稿> 2020年6月7日 (日) 10:21 (UTC)[返信]
記事数の推移についても知りたいときにいちいち計算するの大変ですから、統計を取っておいたらどうですか?取り方は計算するだけです。--Tmv会話|投稿記録2020年6月7日 (日) 23:57 (UTC)[返信]
統計を取るページは Wikipedia:日本語版の統計 の「記事数の推移」の下に項目を設ければ十分と考えます。all-titles.gz は名前空間のインデックスとページ名の table なのでリダイレクトかどうかは判別できませんから、redirect.sql.gz を処理する必要がありそうです… (データベース関係は疎いのですぐには対応できません)。名前空間別で「閲覧回数の多いページ」を入れるにしても、自動更新する方法は見当もつかないので手動が前提になると思います。というか、名前空間別で「閲覧回数の多いページ」のデータを収集するというのは、百科事典の人気項目を把握する意義がある「Wikipedia:日本語版の統計#閲覧回数の多いページ」と同列に扱う必要性を感じません。記事数の推移は既にあります…。--Yuukin0248[会話/投稿記録] 2020年6月8日 (月) 05:00 (UTC)[返信]
コメント まとめてのコメントをご容赦ください。
まず、名前空間別でページ数の推移を掲載することに賛成いたします。それと、閲覧回数の多いページは言われてみれば確かに需要がないかなぁと思うので、掲載しないことに異論はありません。
掲載先については、あまり幅を取らないようであればWikipedia:日本語版の統計でも問題ないかと思います。
あと、ページ数の推移については、このように 年・月の配列にしてしまうと名前空間ごとにまとめられなくなるので、こんな感じで直近だけ、になりますかね。--Atmark-chan </稿> 2020年6月8日 (月) 07:40 (UTC)[返信]
皆様の意見に賛成いたします。掲載先も、言われてみればWikipedia:日本語版の統計でいいですね。--Tmv会話|投稿記録2020年6月8日 (月) 08:32 (UTC)[返信]
コメント 皆さんがおっしゃるように、掲載場所は、「Wikipedia:日本語版の統計」でいいと思います。4年たっても、履歴から確認できるようですし。--股志会話2020年6月13日 (土) 07:02 (UTC)[返信]
コメント 確かに履歴から確認できますね。これこそ通常のページである強みかもしれません。--Atmark-chan </稿> 2020年6月13日 (土) 08:17 (UTC)[返信]
コメント とりあえず、上記内容でおおよそ合意できたと思います。ただ、私はあまり統計の取り方が分からないので、また作成代行をお願いをできないでしょうか。お手数お掛けしますが、よろしくお願いします。--股志会話2020年6月20日 (土) 08:06 (UTC)[返信]
報告 Wikipedia‐ノート:日本語版の統計に、協力要請(当該ページの議論の紹介を)しました。--股志会話2020年6月27日 (土) 07:59 (UTC)[返信]
感謝 ありがとうございます。--Atmark-chan </稿> 2020年6月27日 (土) 08:54 (UTC)[返信]

データの取得方法について

議論の内容を整理するため、節を区切らせていただきました。--股志会話2024年1月20日 (土) 07:41 (UTC)[返信]

  • コメント 情報提供ありがとうございます。シンプルで分かりやすくて、月々の統計情報を示すには、とても良い内容だと思います。
@Atmark-chan, Tmv, Yuukin0248, and 片割れ靴下 議論が長期間止まっていましたが、昨年7月にAmayus様が取得方法について、新たに提案をしていただきました。この案をベースに、もう一度議論を再開したいと思いますが、いかがでしょうか。
@Doraemonplus Wikipedia:井戸端/subj/名前空間別のページ数の統計を見る方法はないかをきっかけに、この新しいコメントに気づきました。ぜひ、Doraemonplus様にも、どのようにまとめ方が分かりやすいか、ご意見を頂けばと思います。--股志会話2024年1月20日 (土) 07:41 (UTC)[返信]
私が興味を持っているのはCategory名前空間のみですので、限定的な意見にはなりますが、基本的な要望としては、
  • 統計作業者の負担が最小になる方法(プログラムが自動的に取得して表示するか、Botで自動化する仕組み)でお願いしたいこと。
  • 見つけやすいページに置くこと(理想は特別:統計Wikipedia:日本語版の統計)。
  • (もし可能であれば)マジックワード化して、{{NUMBEROFARTICLES}}同様、他のページにも掲示できると統計の活用の幅が広がること。
の3点ですかね。
Wikipedia:日本語版の統計に掲載する想定ならば、表の形式はAmayusさんがお示しになった1つ目の表が見やすくてよいと思います。あとは、過去データを何年分(何月分)まで保存して残すかです。記事以外の各名前空間の総ページ数に関して、利用者の関心の的は専ら最新の統計値だと思いますので、それほど詳細に過去分をアーカイブする必要はないんじゃないかと思います。
以下は統計のまとめ方とは関係ない話ですが、昨年7月時点でCategory名前空間の「リダイレクトのみ」が1200件も存在しているのが気になります。というのも、日本語版では現在、カテゴリ間のリダイレクトの作成はカテゴリの方針により認められていないためです(根拠:WP:CR)。もし統計の作成と併せて該当ページ一覧の提供が可能であれば、メンテナンスに役立てられるので非常にありがたいです。--Doraemonplus会話2024年1月20日 (土) 09:30 (UTC)[返信]
  • 議論を再開されるかもということで、当方の下書きに統計の更新分と、追加でカテゴリのリダイレクト一覧を参考まで配置しました。見せ方や必要な情報、過不足等あればご意見頂ければ対応可否を検討します。取得処理は現状全自動とはなっていませんが、継続的に更新することとなるようであれば自動化を検討します。データはページの履歴にも残りますし、表示は1年分もあれば十分ではないかと思います。元データをダウンロードできる期間は4か月ほどなので、それくらいでもよいかもしれません。--Amayus会話2024年1月20日 (土) 22:05 (UTC)[返信]
    • コメント サンドボックスでの下書きを確認致しました。必要な情報や、表のまとめ方としては、いいと思います。細かいことを言えば、「リダイレクトを含む」「リダイレクトを除く」の節では、最後の月でも前月比の値を掲載してほしいことです。また、「全名前空間」の「種別」にて、「リ(ダイレクトを)含む」だと分かりにくいと思います。下2つの合計値ですので、「小計」などの何か言い方を変えてみてもいいと思います。
    また、統計の掲載期間は、1年でも問題ないと思います。情報の更新も、Botが使えるといいと思いますが、困難な場合は、Wikipedia:日本語版の統計のように、手動で更新する手もあると思います。ただ、量がそれなりにあるので「Wikipedia:日本語版の統計/名前空間別」のようなサブページを作成する手も、ありだと思います。--股志会話2024年1月27日 (土) 07:53 (UTC)[返信]
    感謝 質問 Amayusさん、ありがとうございます。早速、プロジェクト:カテゴリ関連/カテゴリ間のリダイレクト一覧で利用させていただきます。下書きの統計表の形式も満足しています。ところで、「名前空間と統計について」がテーマということで、もう一つお尋ねしますが、特別:使われていないカテゴリ特別:使われていないテンプレートについても、ページ数の統計やページ一覧を出せたりしますか?いずれも数が多すぎて、全部で何件あるのか特別ページから見通せなくて困っています。--Doraemonplus会話2024年1月27日 (土) 08:42 (UTC)[返信]
    • 下書きを更新しました。何かの気づきになったと思われるものがカテゴリリダイレクトの件でしたので、リダイレクトの増減も表示しようと、試案として名前空間ごとの表を提示します。議論再開にあたっては改めて議論場所を設けるかコメント依頼を出すかというところですが、今のところ取得内容についての意見はなさそうで、提案時に求められていたものは満足するということでしょうか。個人的にはこの記録にどのような意義が見出せるかがまだ判然としておらず、どのような形がよいのかはっきりしていません。すぐには不要と思いつつ日本語版の統計の自動化を準備していることもあり、表の形式は流用できる現状のバリエーションでは考えたいです。眺めるとWP:CSD#G10の実行やプロジェクト:カテゴリ関連/議論の開始時期、先月にファイルのリダイレクトが一掃されたことなどが概観できますが、労力のわりに大したことはわからないなという印象です。
    2023年4月分に前月との差分がないのは、データがないためです。当面現状のままか2023年4月分を削るかしかできません。ラベルは少し変えてみました。
    未使用のカテゴリやテンプレートの列挙ですが、増減や一覧を把握することの意味がよくわかっておりません。0件のカテゴリでも意味があるものは存在しますし、テンプレートも未使用だから廃止といったものでもない気がします。それでも件数を出すならカテゴリであれば比較的すぐに取得可能だと思います。category.sqlからcat_pagesが0であるカテゴリの件数を出すと下記となりました。「使われていないカテゴリ」では私が確認すると4,455件が表示されましたが、下位カテゴリもページとしてカウントされていそうだったので、差分が何かは確認してもいいかもしれません。
2023年11月 6,995
2023年12月 6,754
2024年1月 5,568
2024年2月 5,658
テンプレートについては計算が必要なのですぐには出せません。--Amayus会話2024年2月4日 (日) 02:51 (UTC)[返信]
Amayusさん 集計ありがとうございます。使われていないカテゴリのページ総数は、Category:未使用のカテゴリで管理対象となり得るページの全体的な現況を簡単に把握する上で意味があります。また、その一覧は、Wikipedia‐ノート:即時削除の方針#空のカテゴリの即時削除基準の創設を検討してはどうかに関連して、「0件のカテゴリでも意味があるもの」を「未使用のカテゴリ」とは区別して適切に管理するために、{{possibly empty category}}を貼り付ける作業用リストとして使えます(特別:使われていないカテゴリはUnicode順なので使いにくい)。
使われていないテンプレートについては、そこまで深い考えはありません。単に技術的に可能かどうかをお聞きしたかっただけです。--Doraemonplus会話2024年2月4日 (日) 04:30 (UTC)[返信]
財団の提供するSupersetで遊んでいたらいい感じのダッシュボードを作れそうだったので紹介しておきます。
https://superset.wmcloud.org/superset/dashboard/jawiki
(仕様上SULでログインが必要です)
まだいじってる途中なんで空のカテゴリしか集計していないですがテンプレートなどもまとめてみますね。鏡華会話2024年2月4日 (日) 05:39 (UTC)[返信]
コメント 統計の自動化と聞きまして全ウィキの即時削除カテゴリの統計を思い出しました.ボットのリポジトリを見ると,どうやらToolforgeで定期的にスクリプトを実行できるようです.Wikitechでもこれを見つけましたがこの辺りには疎いので情報のみで失礼します.--Tmv (会話) 2024年2月4日 (日) 12:41 (UTC)[返信]
コメント 表の形式については、この数週間で特に反対意見等が無いことから、現状のものをベースにして問題ないかと思います。他の方の合意を求めるなら、コメント依頼等が必要になってくると思われますが、現状の合意で問題なければ、ここでの合意ありと考え、実際の運用に入っても問題ないのではないでしょうか。とりあえず、現状のAmayus様のサンドボックスのページで、どのように更新されるか様子を伺ってみるのもありだと思います。--股志会話2024年2月10日 (土) 07:58 (UTC)[返信]
コメント 前述のコメントから、月が変わり3月となりましたが、情報更新の件について何か進展があるでしょうか? (@Amayus): 自動化について言及があってから、暫く経っていますが、自動化は、難しいのでしょうか?--股志会話2024年3月2日 (土) 07:10 (UTC)[返信]
  • 出してはみたものの、何かの役に立つといった具体的な理由がないため、Bot運用の申請に消極的になっています。記録するだけであればということで全名前空間について出力することにしました。フォーマットは期間を半年にして形式1形式2で出し分けまして、個人的には後者が好ましいように思います。集計期間の長短や、以前に提示したいずれかの形式の方がよいといった意見もお待ちしています。定期実行をするのであれば、トラブルがなければ出力タイミングを毎月2日の1時(UTC)頃で考えています。--Amayus会話) 2024年3月3日 (日) 00:58 (UTC) 取り消し線を追加 --Amayus会話2024年3月3日 (日) 07:46 (UTC)[返信]
    (追記) モバイルでの表示も考え、行・列の入れ替えを試していましたが、あまり見やすくはなっていないですね。以前に提示した表形式(形式3)での提示の方がよさそうです。この内容で異論がないようであれば、それなりの分量となったので、ご提案頂いた「Wikipedia:日本語版の統計/名前空間別」に出力するという形で申請したいと思います。数年前に一度合意があった内容ではありますが、本議論に際してあらためて周知が必要かはご意見を伺いたいです。このまま更新を開始してよいものか迷っています。--Amayus会話2024年3月3日 (日) 07:46 (UTC)[返信]
    • コメント ご対応のほう、ありがとうございます。表の形式については、既存の日本語版の統計に合わせて、月は縦方向のほう(形式3)が望ましいと思います。それ以外の点については、特に異論はございませんし、更新日も問題ないかと思います。
    周知が必要かについては、私としては、「当議論に参加いただいた方から、今回議論した内容について、ある程度合意が頂ければ、改めて取る必要がないのでは無く、不十分であれば、Wikipedia:コメント依頼等で、追加で聞いてみることを検討する」という考えです。先行議論参加者以外にも合意が欲しいのであれば、追加で取ってもよい思います。
    @Atmark-chan, Tmv, Yuukin0248, 片割れ靴下, and Doraemonplus:名前空間別の統計について、内容が固まり、再び合意を得たいと考えていますが、上記の議論および表のまとめ方について、ご意見等はございますでしょうか。--股志会話2024年3月9日 (土) 07:45 (UTC)[返信]
    コメント 名前空間別の月別の表形式については異存ありません。ただ、それとは別に、各名前空間の最新月のデータを一つの表にしたものが冒頭に掲げてあると、全ページの概略が一目で把握できて有用そうな気がします。--Doraemonplus会話2024年3月9日 (土) 08:52 (UTC)[返信]
    コメント いいと思います。この統計を何に使うのかは今のところ見当がついていませんが、まぁ (Wikipediaの内外どちらにおいても) そういう種の統計はありますし、「あったら便利だな」的な物として十分価値がありそうですね。Amayus さんがお示しのサンドボックスも秀逸で分かりやすいです。当月分の集計表については後者の方が分かりやすいと思います。--Yuukin0248会話 / 投稿記録 2024年3月23日 (土) 07:20 (UTC)[返信]
    • 報告が遅くなりましたが、当月分の更新を全自動で行い、下書きに反映させております(特別:固定リンク/99859100)。出力結果については想定通り行われたこと、以前の議論参加者であるYuukin0248さんからも特に反対等はなかったことから、この内容でBotでの定期更新のための使用申請に進みたいと思います。更新内容や表示内容に関しては、当方の提案内容でほぼまとまっている認識ですが、追加で変更すべき箇所やお気づきの点がございましたら、お知らせいただければ幸いです。申請の準備も進めつつ、1週間ほどお待ちしたいと思います。よろしくお願いいたします。--Amayus会話2024年4月4日 (木) 10:26 (UTC)[返信]
      賛成 Botでの運用準備のほう、ありがとうございます。更新内容を確認致しましたが、特に問題なく、内容等も現状のままで問題ないかと思います。--股志会話2024年4月6日 (土) 07:15 (UTC)[返信]
      報告 Wikipedia:Bot/使用申請#Amaybot_20240412を提出しました。承認されましたら定期更新を開始する予定です。--Amayus会話2024年4月12日 (金) 11:08 (UTC)[返信]

井戸端について

この井戸端は、名前空間上「Wikipedia」になっていますが、井戸端専用の名前空間を作成してもいいのではないかと思いました。理由としては、3点あります。1点目は、Wikipedia:井戸端/subj/拡張半保護の導入(再提案)/決選投票を見た際、議論の場所がノートと分散していて分かりにくいと思いました。2点目は、常にサブページ化を行っているので、サブページ数も4月25日16:15(UTC+9)現在、4,446件もあり、一つの名前空間として十分成り立つのではないでしょうか。3点目として、ページ名に「subj」が常に入るので、長くなりがちだなと思ったからです。

井戸端独特のシステムの導入・議論の場所を一か所に集中させるためにも、ノート(議論)がない、井戸端専用の名前空間を作成してもよいのではないでしょうか。--股志会話) 2020年4月25日 (土) 07:30 (UTC)大変勝手ながら誤字を修正いたしました--Tmv会話|投稿記録2020年4月25日 (土) 08:01 (UTC)[返信]

議論場所がノートと分散している、ということについてですが、原則井戸端のサブページの方は取り上げられている問題についての直接的な意見を書くところで、ノートページはその意見を書くところに関して、だとか少し話題から離れてしまうけど関連するからここに書いておきたい、という風に定義されているのではなかったでしたっけ。Wikipedia‐ノート:井戸端のヘッダに書いてある気がするのですが。ページ名にsubjが入ることについては、入れないようにすればいいのではないでしょうか(ページを移動するなど。ただ、その場合編集量についてはbotなどを使うなど検討しなくてはいけませんが)。ノートページとの役割があいまいということについては新しい名前空間を作って改善できるように思えませんし、名前空間をわざわざ作らなくてもいいのではないかな、と思いますが。--Tmv会話|投稿記録2020年4月25日 (土) 08:01 (UTC)[返信]
コメント 特別:最近の更新などで検索した際に、矛盾点(このページは検索上本文扱い)の解消できる点や、ページ数が多いので、区分け(最近の更新の名前空間の絞りでの結果等)がはっきりする点ではいいのかもしれません。しかしTmvさんが仰るように、名前空間を作ったからといって、あまり改善ができるとは言えないと思います。--Mario1257会話2020年5月1日 (金) 18:06 (UTC)[返信]
返信 お二方様、コメントありがとうございます。「井戸端は議論」だとハッキリ区分したほうがいいと思い、提案してみたのですが、あまり意味がなさそうですね。もし、他の利用者さんも何か意見があれば、コメントいただけばと思います。--股志会話2020年5月2日 (土) 05:37 (UTC)[返信]
コメント 井戸端のサブページに関しては、「Wikipedia:井戸端」のサブページ一覧を見て頂けると分かるとおり、
Wikipedia:井戸端
|- subj
|  '-(それぞれの議論)
|- Template
|  '-(井戸端内で使用するテンプレート)
|- 整理ログ
|  '-(月ごとのページ)←2008年まで使用されていたよう
|- 過去ログ
|  '-(月ごと or 10日ごとのページ)←2008年まで使用されていたよう
|- 話題一覧
|  '-(年ごとのページ)←2008年まで使用されていたよう
'- history〜〜 及び 履歴〜〜 ←履歴の過去ログ化に使用しているよう
のような構造になっているようです。ですので、例えば{{fullurl|n=特別:前方一致ページ一覧|p=prefix=井戸端/subj/&namespace=4|s=「Wikipedia:井戸端/subj」のサブページ一覧}}とすることで「Wikipedia:井戸端/subj」のサブページ一覧のように井戸端の話題ページ一覧へのリンクを作れるなどといった利点があります。
このようにページをツリー構造にしておくことで様々な利点があるので、それは崩さないほうが良いと思います。
しかし、井戸端専用の名前空間については、検討する価値は十分にあるのではないかと思います。そうすることによって、今までWikipedia:井戸端/subj/(ページ名)となっていたのが井戸端:subj/(ページ名)のように、仰るとおりページ名を短くすることができます(名前空間名はあくまで例です。英語名とかでも良いですし)。あと、詳しいことは分かりませんが、「井戸端名前空間では署名をせず投稿しようとすると警告が出る」といった設定も可能になるのではないかと思います。--Atmark-chan </稿> 2020年5月2日 (土) 23:55 (UTC)[返信]
コメント ところで、名前空間の追加というとても大がかりなことですので、本格的に提案するのであれば単独で再度サブページを設けたほうが良いかと思います。それとも、私が行いましょうか?--Atmark-chan </稿> 2020年5月6日 (水) 03:44 (UTC)[返信]
報告 Wikipedia:井戸端/subj/井戸端名前空間の提案を提起しました。ぜひご意見ください。--Atmark-chan </稿> 2020年5月6日 (水) 12:41 (UTC)[返信]
返信 議論の進行、ありがとうございます。できれば、そちらにも参加したいと思います。--股志会話2020年5月9日 (土) 08:04 (UTC)[返信]
情報 Wikipedia‐ノート:井戸端/ヘルプWikipedia:井戸端/ヘルプに関しての提案・議論が行われております。よければそちらもご覧ください。--Tmv会話|投稿記録2020年5月10日 (日) 01:09 (UTC)[返信]

会話ページについて

これについては単純なことですが、会話ページのタブの表示がノートになっていることが気になります。利用者名前空間が「利用者ページ」になっているように、会話ページも「会話」と表示されるようにしたほうがいいのではないでしょうか。--股志会話2020年4月25日 (土) 07:30 (UTC)[返信]

// User talk のタブの文字列を変更:

// 利用者名前空間もしくは利用者会話名前空間か?
if (mw.config.get("wgNamespaceNumber") == 2 || mw.config.get("wgNamespaceNumber") == 3) {
	// 要素取得
	var userTalkTab = document.getElementById('ca-talk').children[0];
	// 文字列を変更
	userTalkTab.textContent = '会話';
}
と追加することで、利用者名前空間と利用者会話名前空間でのみ、「ノート」が「会話」になると思います。ただし、読み込むのに少し時間がかかり、一度「ノート」と見えた後に「会話」に変わるのが見えてしまいますが。--Atmark-chan </稿> 2020年5月6日 (水) 07:54 (UTC) インデント修正--Atmark-chan </稿> 2020年5月6日 (水) 07:55 (UTC)[返信]
コメント 詳細な情報ありがとうございます。CSSの知識があまりないので、Atmark-chan様のUser:Atmark-chan/common.jsをコピペ→自分の名前にさせていただき、私も導入させていただきました。--股志会話2020年5月9日 (土) 08:04 (UTC)[返信]
コメント Wikipedia:カスタムJS/一覧に載せる、といった件ですが、あそこは利用者独自の開発js一覧みたいな感じになっているので、作者であるAtmark-chanさんのサブページが適切かもしれません。--Tmv会話|投稿記録2020年5月10日 (日) 01:14 (UTC)[返信]
Atmark-chanさんにより、利用者:Atmark-chan/custom/User-Kaiwa.jsが作られたようです。ありがとうございます。--Tmv会話|投稿記録2020年5月10日 (日) 03:03 (UTC)[返信]
 すみません 言っていなかったのですが、利用者:Atmark-chan/custom/User-Kaiwa.jsをつくってUser:Atmark-chan/common.jsに読み込んでみたのですが、なぜか急に動かなくなってしまいました。原因究明のためもう少しお待ちください。--Atmark-chan </稿> 2020年5月10日 (日) 03:12 (UTC)[返信]
コメント コメント Atmark-chanさん宛) 「importScript」の「S」が小文字になっているからでは?小文字大文字の区別で変わるのか知りませんが。--Tmv会話|投稿記録2020年5月10日 (日) 23:57 (UTC)[返信]
感謝 本当にありがとうございます、仰るとおりです。Tmvさんのご指摘がなかったらずっと気づかなかったかもしれません…。--Atmark-chan </稿> 2020年5月11日 (月) 00:07 (UTC)[返信]

────────────────────────────────────────────────────────────────────────────────────────────────────(インデント戻し よかったです。今気づいたのですが、Help:名前空間#詳細の表にページのタブに書かれる文字が載っているので、ここにも注釈をつけなくてはなりませんね。--Tmv会話|投稿記録2020年5月11日 (月) 00:11 (UTC)[返信]

報告 注釈をつけました。--Tmv会話|投稿記録2020年5月11日 (月) 00:16 (UTC)[返信]
感謝 報告 注釈ありがとうございます。Wikipedia:カスタムJS/一覧に載せてみました(差分)。--Atmark-chan </稿> 2020年5月11日 (月) 00:32 (UTC)[返信]
報告 ベクター外装以外の保証はないと書かれていましたが、私はTimelessスキンですが正常に動作していますので、書き替えました。その後、調査してみたところ、MinervaNeueスキンで動作しないことがわかりましたが、他のスキンでは動作していることが確認できました。よって、再び書き換えまして、現在「※MinervaNeue外装では動作しませんが、他の外装の場合正常に動作します。」という文体になっております。一様報告だけしておきます。--Tmv会話|投稿記録2020年5月11日 (月) 01:00 (UTC)[返信]
メモ 少し話がそれますが、MinervaNeueスキンの場合下のcssも効かないようです。(meta:User:Tmv/global.css
/* 会話ページの不要なタブを消す */
#ca-nstab-user { 
	display:none!important;
}
つまり、MinervaNeueスキンは原因はわかりませんが、タブのカスタマイズができないようです。--Tmv会話|投稿記録2020年5月11日 (月) 01:07 (UTC)[返信]
コメント まだ詳しくは見ていませんが、id名が違うのではないでしょうか?
あと、Wikipedia:カスタムJS/一覧の修正ありがとうございます。--Atmark-chan </稿> 2020年5月12日 (火) 02:19 (UTC)[返信]
報告 MinervaNeueスキンでidが設定されていないことが分かりました。それを踏まえ、MinervaNeueスキンにも対応できるよう修正いたしました。--Atmark-chan </稿> 2020年5月12日 (火) 06:47 (UTC)[返信]

移動について

今まで私は、明らかに正式名称が変更されている場合は議論をすっ飛ばして移動していました。…というより少し前まで改名提案の存在自体を知りませんでした。まあそれはこちらの落ち度ですが、Wikipedia:ページの改名を見ると「明らかに、ページ名が記事名の付け方のガイドラインに沿っていないとき」はその場で移動してかまわないと明記されています。これは「明らかに正式名称が変更済みの場合」を含むと解釈しましたがこの認識で合っているでしょうか。Wikipedia:改名提案にある下関大丸マックスバリュ東北をこちらで移動したいのですが…--6144会話2020年4月26日 (日) 04:38 (UTC)[返信]

Wikipedia:記事名の付け方にある通り、「『記事名を付けるには』にある基準を考慮し、正式名称ではない記事名となっているものも」あるのですから、正式名称が変更されたからといって直ちに改名することが妥当とは限りません。議論の余地がある以上は通常の改名提案の手順を踏むべきであり、手順の省略は認められないと解釈するべきでしょう。--Rasalghul会話2020年4月26日 (日) 05:20 (UTC)[返信]
その通りです。--Rasalghul会話2020年4月26日 (日) 05:38 (UTC)[返信]
また、Wikipedia:井戸端/subj/項目で説明している事象自体の名称が変更された場合に改名提案しなくて良いのかWikipedia:井戸端/subj/ページの改名のタイミングについてWikipedia:井戸端/subj/組織等の改称に伴う即時改名についてとあり、おおむね明らかに正式名称が変更されており異論がありえないと確信を持てる場合には即時変更してよい…との意見が大勢のようです。確かに、私もケンコーからケンコー・トキナーに移動したとき、ノート:ケンコー・トキナーでの議論を見つけて、合併で企業名が変わっているのに記事のバランスが云々とか根本的におかしな議論をしていたのでさくっと無視して即時移動させたことがあります(これによる警告の類は来ていないはずです)。…と、ここまで長々と語っていましたが、ノート:下関大丸およびノート:マックスバリュ東北を見てみると反対論が噴出した状態で議論が止まっていますので、この2件については撤回します。お騒がせして申し訳ありません。--6144会話2020年4月29日 (水) 07:23 (UTC)[返信]

横から失礼 横から失礼 こんにちは。ちょうどこの議題と関係する行動をしようとしていたところなのでぶら下がりで失礼します。

以前からウォッチリストに入れていたドラ・ダンカンが先日突然ドラ・ダンカンに事前の議論なく「人名の発音表記が明白に不適切であるため」と要約欄に記載されたのみで移動されていてびっくりしました。本文中の「イサドラ」表記をすべて「イザドラ」に変更してから移動されたようで、外部リンク節に記述のあるお弟子さんのウェブサイト名までリンク先の表記と異なる「イザドラ」表記にされてしまっています。いくら本来の発音に近くないからといって、現状国会図書館サーチでも「イサドラ・ダンカン」表記のほうがかなり優勢(「イサドラ」表記「イザドラ」表記)など議論なしの移動は疑問に感じこれはせめて追認議論くらいはすべきだろうと準備を始めていたところでした。

これまでの議論を拝見すると、やはりこれも手順を省略すべきではなかった例にあたるのだと思いますが、改めて改名の是非から検討する場合でも、一旦元の記事名に戻してしまってから議論を立ち上げるのはやはり移動合戦になりかねないという意味で望ましくないでしょうか?こういう案件に関わるのは初めてなので、追認議論を提起するにはどうしたらよいかと迷っています。利用案内で行うべきなのかもしれませんが、皆様からご助言をいただけると幸いです。--にび三郎会話2020年4月27日 (月) 03:36 (UTC)[返信]

改名できないほど広く知られているわけではなく(例:作家のアンデルセンはいまさらアナスンにはできないでしょう)、本来は誤記ですから即時改名は責められません(Wikipediaでは、ほとんどの場合がこちらになるぐらいには、信頼の置ける日本語転写で「知られていない」ものです)。この件はこれら一般例と異なる中間に位置する(古くから使用されている誤表記)ケースです。このように「誰でも知ってるわけじゃないが、事典には載るぐらい分野でよく知られている」かつ「表記ブレではなく間違いは確定」ですと「これ間違ってるから、誤表記が広まるより直しておこう」って一般的な発想は当然出てきますし、「え? 昔からこれだしこの表記でいいんでしょ」って反応もまた当然ですが、どちらにせよ違和感があるなら依頼や追認出した方が無難ですね。ただ、この件ですともう少し別の事情が出てきます。この件だけで検討しますと、
  1. 転写として間違いかどうか→議論の余地がない間違い(リーダーズ、ランダムハウス、グローバル、オックスフォード全てが「イザドラ」では、本来の発音に近くないでは済まされません)。
  2. 使用例はどうか→間違った表記での使用例が十分にある(古いものなので間違った表記で定着してしまうことは考えられる)。
  3. 記事の存在期間はどうか→16年もあり十分に長い、というより長すぎて「イサドラ」表記はエコーチェンバー効果が否定できない(検索が「イサドラ」表記の根拠としては弱くなる)。
  4. 知名度はどうか→間違った転写で精選版日本国語大辞典に掲載され(広辞苑、ニッポニカ(参考文献は「イサドラ」表記)、マイペディア、ブリタニカは名前の読みが載っていませんでした)、組織名としても使用されているが(ただこれ[2]では、弟子とはいえません。実は英語版[3]だと4代目の名乗りもしていないし、創設者本人・・・・・・私なら根拠としては使いません)、[4][5][6]あたりを見ると切り替えが始まっている気配もある。
「誤った転写が定着していたが、訂正が進行している」記事として考えます。このような事例は時折あるので、記事は「イサドラ・ダンカンとしても日本では知られるイザドラ・ダンカンは(以後XXと表記する)・・・・・・」って書き出しでどちらかに統一すればいいだけですから、「もう切り替えちゃっていいの? それともまだ?」って問題なのです。差し戻さず追認するか時期尚早として戻すかの議論を始めた方がよろしいでしょう。ただし(残すかどうかと言う別の問題もありますが)リンク先だけは「イサドラ」に戻して良いはずです。これは改名の如何にかかわらずリンク先の名称ですから。--Open-box会話2020年5月1日 (金) 10:48 (UTC)[返信]
返信 コメントありがとうございます。「映像の世紀」など今まで私が知っていた限りでは「イサドラ」表記しか見たことがなかったので早合点してしまっていたところもあったのですが、なるほど、思っていたほど単純な問題ではなさそうですね。まず当該項目ではリンク名を修正するのみとして、いただいたコメントを踏まえたうえで追認議論を開始したいと思います。詳しく検討していただきありがとうございました。--にび三郎会話2020年5月7日 (木) 08:22 (UTC)[返信]


保護アイコン一新の提案

提案 先日、拡張半保護の方針が制定されました。これを機に、保護されているページを示す鍵のアイコンのデザインを一新する提案を致します。

現状では、同じ半永久的保護でも半永久的全保護アイコンには「∞」のマークがついているのに半永久的半保護アイコンにはついていなかったり、色が多種多様で分かりづらかったりといった問題があります。

今回提案するにあたっての要点は以下の通りです。

  1. 直感的なデザインにする。 - アイコンを初めて見ても、すぐに理解しやすい。
  2. 一貫性のあるデザインにする。 - 法則性があるようにすることで、アイコン色などを丸暗記しなくてもわかる。
  3. 他の多数の言語版に合わせ2次元のデザインにする。(参考:
    • 例:

ここで、変更案を示します:

  • 全保護拡張半保護半保護の順に、金・銀・銅の色を用いる。
  • 半永久的な保護の場合は「∞」マークをつける。
  • 保護の種類は、固有の印で判別する。
    • 移動保護: 緑色の「→」
    • 作成保護: 桃色の「+」

また、イメージが付きやすいよう一覧を示します。なお、組み合わせとして使用しないものや方針に定義されていないもの(例えば、移動は自動承認された利用者以上でないとできないので、現状ではすべてのページに移動半保護がかかっているような状態)などもありますが、便宜的に表示しています。

※アイコンの表示に表を使用しているので、かなりカクカクしていたり、見づらかったりします。(移動保護の緑の部分は「→」マークを、作成保護の桃色の部分は「+」マークを意図しています。)

表だけでは分かりづらいので、近く画像の例を作成したいと思います。--Atmark-chan </稿> 2020年4月26日 (日) 11:20 (UTC) 太字追加ほか--Atmark-chan </稿> 2020年4月26日 (日) 12:04 (UTC) 曖昧な記述を訂正--Atmark-chan </稿> 2020年4月27日 (月) 08:23 (UTC)[返信]

  • コメント 追記 上記の作成保護のアイコンなのですが、よく考えたら、鍵が「」マークに物理的におかしな引っかかり方をしていたので、別のデザインに変えたいと思います。(近々画像で載せます。)--Atmark-chan </稿> 2020年4月26日 (日) 12:04 (UTC)[返信]
    •  作業中 現在、例としての画像を作成しておりますので、完成し次第載せようと思います。--Atmark-chan </稿> 2020年4月26日 (日) 13:48 (UTC)[返信]
      • コメント 平面的なデザインが近年のトレンドなので、平面的な錠前のアイコンを使うこと自体は賛成です。しかしながら、幅20px程度で表示するにはデザインが複雑過ぎます。こういうものは欲張って情報を詰め込んでも意外と分かりにくくなります。英語版同様に錠前の色と錠前の中の記号で識別するくらいが丁度いいと思います。--Marine-Bluetalkcontribsmail 2020年4月26日 (日) 14:25 (UTC)[返信]
        •  となると……。
           移動保護の場合は『』を、作成保護の場合は『』を、鍵部分に表示する。無期限の場合は、鍵の輪っか部分を上の方に表示する(今と同じ)。時限式の場合は、鍵の輪っか部分を下の方に表示する(鍵を外すのに鍵本体を持っている状況をイメージ)。
           ……位の方が良いのかもしれないですね。--お好み焼き星人会話2020年4月26日 (日) 14:44 (UTC)[返信]


 (別タブで文章を作成中に状況が進んだみたいですが、そのまま)保護アイコンの一新や、金銀銅の色設定そのものは、大賛成です。
 ですが、できることならば、三次元の画像アイコンの方が良いと思います。三次元から二次元へと変更されると、少なくとも僕の個人的な感想としては、ダサくなったと感じてしまいます。とはいえ、僕に三次元の画像を作るスキルはないため、そのスキルがあり、なおかつ僕と同意見の方がいらっしゃらなければ、二次元に反対はしません。
 ただ個人的には、鍵の後ろにマークを表示する今の例は、ちょっと分かりにくいのではと思います(種類が『なし』の例はそのままでいいと思います。∞の大きさは、もっと大きい方が目立って良いかもですが)。
 移動保護の場合、通常の場合は無期限全保護(なし)の∞のように、右矢印を。無期限の場合は鍵部分を上下に分け(横線で区切りを入れ)、上部に∞を、下部に右矢印を。
 作成保護の場合は、通常の場合は無期限全保護(なし)の∞のように、+を。無期限の場合は鍵部分を左右に分け(縦線で区切りを入れ)、左側に∞を、右側に+を。
 というデザインの方が良いのではないでしょうか? なお、∞を上や左にしたのは、日本語では縦書きの場合は上から下に、横書きの場合は左から右に、と読んでいくからです(つまり、∞を先に意識しやすくした)。区切り方を変えたのも、上下と左右どちらでの区切り方をされているかで、ぱっと見てわかりやすくという意味もあります。蛇足ながら、移動保護の方を上下に分けたのは、鍵の上部分がある関係で、鍵そのものは横長になると思うからです。『∞』と『→』なら縦の幅が狭くても構わないですが、『∞』と『+』の場合はできるだけ縦と横の幅が近い方がいいと思いますし。
 今の僕に表で細かいデザインを作る余裕はありませんし、実際の画像を作ることもできないので、アレではあるのですが。ご検討いただければ幸いです。
 それでは、失礼いたします。--お好み焼き星人会話2020年4月26日 (日) 14:26 (UTC)[返信]

  • コメント 好みの問題に関しては個人の意見ですが、一点だけ。作成保護に関してはテンプレートの貼り付け先がなく、主に保護依頼で使用されるアイコンとなるため、無期限とそれ以外を区別する必要性がないと思います。技術的な問題により、保護期間の設定はガジェットで読み取ることもできません。--Marine-Bluetalkcontribsmail 2020年4月26日 (日) 15:16 (UTC)[返信]
  • 返信 (お好み焼き星人さん、Marine-Blueさん宛)
    • お好み焼き星人さん宛) 確かに3次元の方が「手の込んでいる感」があります。しかし、私にも三次元画像を作るスキルはないので、仮に議論終了までに三次元画像を作れる方がいらっしゃいましたら、検討してみても良いと思います。
    「無限大」マークの大きさについては、表を使って言わば「無理やりアイコンを作り出している」状態で、少しそれとの兼ね合いで小さめになっております。実際に画像にする際にはもう少し大きくできると思います。
    また、マークが後ろ側に来るということに関しては、私も画像を作る際に少々分かりづらい・作りづらいと感じ、位置を変えようと思っておりました。ですので、お好み焼き星人さんの仰る、鍵の上に書く案でも良いと思いますが、実際に画像を作ってみないと分からないので、今しばらくお待ち下さい。
    • Marine-Blueさん宛) あと、無期限作成保護アイコンについてですが、保護解除依頼のほうで使用されることはないのでしょうか?完全に私の勝手な推測で申し訳ないです。--Atmark-chan </稿> 2020年4月26日 (日) 22:46 (UTC) 修正--Atmark-chan </稿> 2020年4月27日 (月) 14:42 (UTC)[返信]
      • コメント 二次元か三次元かですが、例えばパソコンやスマートフォンの画面デザインは以前なら立体感のあるデザインが主流でしたが、近年は平面的かつシンプルなものが主流であるためです。確かに立体的なデザインのほうが格好良いですが、複雑化しないほうがカラーバリエーションを増やしたり、細部に変更を加えることが容易になります。
      • 保護依頼や保護解除依頼ですが、依頼する人は主に無期限かどうかを焦点に依頼するわけではなく、保護されること/保護が解除されること自体を第一目的に依頼を出します。また、最近の保護依頼を見てもコメントアイコンの使用率はさほど高くはありません。削除やブロックと違って投票形式のような依頼ではないこともアイコン使用率が低い一因でしょう。このため保護依頼関係専用のアイコンを増やしてもあまり活用されないと思います。--Marine-Bluetalkcontribsmail 2020年4月27日 (月) 03:28 (UTC)[返信]
        • 横から失礼 横から失礼 横から失礼します。皆さんの案に賛成なのですが、一つだけ気になったので言わせてください。一番上のところで「現状では、半永久的全保護アイコンには「∞」のマークがついているのに半永久的半保護アイコンにはついていなかったり」と書いてありますが、この記述だけだと鍵にマークがついているものとついていないものがあるから統一しよう、的な感じにもとらえられてしまうため、その記述の前に「同じ半永久的保護でも」という文を追加した方が良いのではないでしょうか。--Tmv会話|投稿記録2020年4月27日 (月) 05:40 (UTC)[返信]
  • コメント 私の意見としては、そもそも国際化の観点からも、全保護=金色系、半保護=銀色系というのは崩すべきでないと考えています(特にコモンズや英語版等はjawp利用者もよく目にしますので、色が異なるとかえって混乱のもとかと)。また、そもそも英語版には「半永久的な保護」にあたるアイコンが定まっていないようです。再び議論分岐のようになってしまい申し訳ないのですが、個人的には半永久的保護と、無期限保護の違いが曖昧になっていると思え(現にPadlock-red-inf.svgの使用状況を見ると、方針ページ以外にも「爆破予告」など通常記事や利用者ページでも使用されている)、この際半永久アイコンを通常アイコンと統合しても良いのでは?とも感じています。--Y-route会話) 2020年4月27日 (月) 07:38 (UTC) - 修正--Y-route会話2020年4月27日 (月) 07:39 (UTC)[返信]
    •  返信:
      平面的デザインのほうが編集が容易になるというのは仰る通りだと思います。
      また、作ったところで使用するシチュエーションがないもの(移動半保護や無期限作成保護など)は、削っていくようにしたいと思います。
      • Tmvさん宛:
      仰っていた文を追加しました。
      確かに、他の多数の言語版で 全保護=金・半保護=銀 となっているようですので、混乱の元となる可能性はありますね。であれば、半保護=銀は維持して 拡張半保護=銀色に金枠、というのはどうでしょう?そちらも検討したいと思います。
      半永久的保護と無期限保護の違いは曖昧となっているかもしれませんが、「期間」として考えると半永久的も無期限もそれほど変わらないような気がします(勿論目的は違いますが)。半永久アイコンと通常アイコンとの統合については、あまり保護について詳しくないので意図がよく分からず、申し訳ございません。もう少々詳しく説明をお願いいたします。
      --Atmark-chan </稿> 2020年4月27日 (月) 08:23 (UTC)[返信]
  • 簡単に言えば、「半永久的な保護」「半永久的な半保護」のアイコンをこの際廃止して、通常の保護・半保護アイコンに統一すれば、デザインの検討を省けるんじゃないかという話ですが…これは別の議論にすべきだったかもしれません。--Y-route会話2020年4月27日 (月) 09:13 (UTC)[返信]
  • 私としては、全体的に日本語版ローカルで独自の色やデザインを策定するのはあまり望ましくなく、基本は他言語版や、コモンズ等の他プロジェクトと揃える形でデザインを決定したいです。そのうえで、Wikipedia‐ノート:拡張半保護の方針でも述べましたが、問題は英語版のように全保護や拡張半保護に「F」「E」と言った文字を使うのか、中国語版やコモンズのようにピクトグラムを使うのかを決めていきたいと思っていました。(後々比較表を用意します)--Y-route会話2020年4月27日 (月) 09:30 (UTC)[返信]
  • 報告 いくつか画像を作成してみましたのでご覧ください。なお、作成に少々時間を要しており、皆様のご意見を反映しきれていない可能性がございます。
--Atmark-chan </稿> 2020年4月27日 (月) 12:35 (UTC)[返信]
  • 返信 (Y-routeさん宛) {{保護運用}}はWikipedia:保護の方針#半永久的な保護を意図したものなのに、アイコンを省略する目的だったり単純に無期限だからという理由でこのテンプレートを貼り付けているのがそもそもの間違いです。半永久的な保護のアイコンは扱いをもう少し厳格にしたほうが良さそうです。半永久的な保護の区別自体は英語版由来であり、変なところから湧いてきたおかしな発想の類ではないため、今この場の流れで廃止するのは難しいと思います。
  • 返信 (Atmark-chanさん宛) アイコンを20pxで使うことを考えたほうが良いと思います。錠前の中に「∞」と「→」や「+」を2つ同時に入れたり、錠前の外に記号を入れても縮小すれば分かりにくくなるだけです。英・仏・中・韓の各言語版が使用している画像で錠前の中に文字やピクトグラムが白抜きで入っている理由もおそらくは縮小時の見やすさ優先です。あと、需要がないと言ったのは作成保護の期限付きと無期限を区別することであり、作成保護と作成半保護は別に区別しても構わないと思います。参考までに申し上げますと保護記録参照ガジェットでも作成保護と作成半保護は区別しています。
  • 一般的な話として、安易に「他言語版がやらないような新しいアイコンを作って使おう」というのは、デザインスキルに圧倒的な自信でもない限り難しいものなのです。なので、一旦元のアイデアをまるごと流用してからそれをベースに都合の悪いところを変えていったほうが上手くいくと思います。--Marine-Bluetalkcontribsmail 2020年4月27日 (月) 13:14 (UTC)[返信]
コメント - Template:保護など実際に保護されているページの右上に表示されているのが20px、Template:RFPが15pxですのでそれらに使われる場合の視認性は次の通りです。
  • 20px: / 参考:
  • 15px: / 参考:
拡張半保護をこのように表現するなら銀(半保護色)をもっと明るくしたほうが良さそうですね。それと錠前に何か書くとしたら他言語版のように白抜きの方が明瞭で、この大きさで図形2つ入れるのはちょっと窮屈だと感じました。ただピンク色の+を鍵の外に置くのは小さくても意外と目立つので、半永久と組み合わせるならを組み合わせれば何とかなりそうな気もしました。ただ、錠前の色自体は従来通り独自の色にした方が差別化できるので、変えた方が良いと思います(半永久版が必要ないなら他言語版同様の独自色+わかりやすくするための記号でいいと思います。鍵の外に記号を置くというのはあくまで錠前に「∞」を付けるバージョンを作る必要があった場合の策としてですね)。--ButuCC+Mtp 2020年4月27日 (月) 13:28 (UTC)[返信]
  • 返信 (Marine-Blueさん宛) 保護記録参照ガジェットのご提示ありがとうございます。そちらに掲載されている色を参考に色を変えたいと思います(移動は緑系、アップロードは赤系、作成は青系)。また、∞マークは白抜きに変更したいと思います。
返信 (ButuCCさん宛) 15pxでのご提示ありがとうございます。銀色はを参考にもう少し明るくしたいと思います。記号を2つ入れた場合はかなり見づらくなっていましたが、右上の記号は目立っていたので、右上につける方向にしたいと思います。また、黄緑が若干見づらく感じたので、特に目立っていたピンクに合わせて鮮やかさを調整したいと思います。
コメント 総合いたしますと、
  • 保護の種類を表す記号:
  • 半保護の銀色を明るくする。
  • ∞を白抜きにする。
  • 無期限作成保護のアイコンは需要なし。
となりますでしょうか。--Atmark-chan </稿> 2020年4月27日 (月) 14:40 (UTC)[返信]
  • コメント 保護記録参照ガジェットは暫定的な対応で、合意に基づくものではないため一例としてください。一旦他言語版の使い分け例を仮で割り当ててみて、どこを変えたほうが良いと思ったか、ご自身や周囲の意見を元に変更していったほうが分かりやすいと思います。ピンクの「+」を右上に置くアイデアなどはそこで活用していただければ。良いと思ったアイデアをあちこちから盗みましょう。--Marine-Bluetalkcontribsmail 2020年4月27日 (月) 15:36 (UTC)[返信]
  • コメント 拡張半保護ですが、あえて日本語版オリジナルの色にする理由がよく分かりません。他言語版(英・韓)の拡張半保護を見ても、英語版の青系 Extended-protection-shackle.svg(※投稿時点でコモンズの同名ファイル は色が不安定なので英語版を参照。作成保護より藍色に近い青)と一緒にした方が整合しそうです。細部をローカライズするにしても、色はなるべく揃えるべきでは。
    • 参考までに、デザイン制定時の英語版・中国語版議論へのリンクを付します。 en:Wikipedia:Village_pump_(proposals)/Archive_155#Proposal/RFC:_Redesigning_page-protection_padlock_icons_to_be_more_accessible zh:Wikipedia_talk:投票/更新Wikipedia:保护方针的图示 --Y-route会話2020年4月27日 (月) 16:04 (UTC)[返信]
      • 英語版や韓国版の拡張半保護は「30日以上経過/500回以上編集」と日本語版に運用予定のそれとは条件が違うので、ある意味独自色を出した方が良いような気もします。どのみち青系は作成保護関連に割り当てられていて紛らわしいというのもありますし、Extendedの「E」を表示したところで日本語版としてわかりやすくなるとも思えないですし(これはFullの「F」も同様)。なのでゼロベースで考え、規制の大小で同じグループとなる保護・半保護と関連を持たせたカラーにするいうのは十分理由になるでしょう。一方で半保護の銀は維持したいとなると、Atmark-chanさんのミックス案は方向性としてはありだと思いますね(色分けの仕方は他にも考えられます)。--ButuCC+Mtp 2020年4月27日 (月) 16:52 (UTC)[返信]
        • 提案:拡張半保護のアイコンです。Extendedの「E」ではなく拡張をイメージし広がる矢印にしたアイコンを作ってみたのですがどうでしょうか?
  • 20px: /
  • 15px: /

金銀ミックス案のパターンを色々考えてみたので視認性の参考にどうぞ(半保護の銀は前掲の明るい灰色に変更)。また、右上に記号というアイデアから「半保護に+記号で“拡張”半保護」というのはどうかなと思ってこちらも試作してみました(記号の色は視認性優先の赤色とExtended色の2種)。この場合、例えば移動拡張半保護の場合はに「+」記号を付加するといった感じになります。--ButuCC+Mtp 2020年4月28日 (火) 14:12 (UTC)[返信]

情報 日本語版英語版中国語版、及び保護記録参照ガジェットの保護アイコンをまとめてみました。
(なし) 移動保護 作成保護 アップロード保護
日本語版(抜粋)
(暫定)
- -
英語版(抜粋)
中国語版(抜粋) - Silver padlock
保護記録参照ガジェット - -
備考 金色が多数。 言語により多様。 銀色が多数。 緑系が多数。 青系が多数。 赤・紫系が多数。
こちらも参考になると思います:en:WP:Protection policy/Padlocks --Atmark-chan </稿> 2020年4月29日 (水) 01:33 (UTC)[返信]
1. 保護の段階に応じて、
  • 全保護:
  • 拡張半保護:
  • 半保護:
の色を用いる。
2. 保護の種類に応じて、
  • 移動保護:
  • 作成保護:
  • アップロード保護:
を右肩に表示する。
3. 無期限/半永久的な保護の場合、「」を白抜きで表示する。
※微妙な色味などについては、再現しきれていない可能性があります。ご容赦ください。
これが、一貫性があり、かつ体系的で分かりやすいと思います。--Atmark-chan </稿> 2020年4月29日 (水) 02:50 (UTC)[返信]

上の様な色に一貫性があり賛成です。上のような色に従って色を変更しました。--Kocgs会話) 2020年4月29日 (水) 03:17 (UTC)訂正--Kocgs会話2020年4月29日 (水) 03:18 (UTC)[返信]

  • コメント ガジェットのアイコンはアップロード保護と拡張半保護が合意に基づかないものですが、何か設定する必要があったという事情から割り当てています。それと色に関しては、本来なら半永久的な保護に対して赤系が割り当てられています。拡張半保護は赤系で良い色がなかったので取り敢えずミント色になっています。
  • あと、画像の決定稿はSVGでお願いします。PNGよりも高解像度にできる上、加工して再利用しやすくなるためです。--Marine-Bluetalkcontribsmail 2020年4月29日 (水) 03:35 (UTC)[返信]
コメント - 右上の記号は小さく視認性に難があるので、様々な色やバリエーションを持たせられる余裕はなさそうです。そうなると、半永久か否か(「∞」か否か)の二択を右上に任せた方が良いと思いました。つまり「全保護」に対する「半永久的全保護」という関係です。
こうすれば錠前に記号を入れる余裕ができるので、仮に支持があった対角線パターンを拡張半保護として全保護・拡張半保護・半保護のアイコンをそれぞれ「」にするとして、移動保護の場合はそれぞれに記号を付けて「」とすることで規制範囲別の移動保護アイコンが作れます。もちろん、従来の色を踏襲した「」とすることもできます。そしてこれらの半永久版が必要な場合は「」といった形で作れます(応用パターンとして図示しただけで半永久移動拡張半保護というものが必要か否かは考慮していません。必要ないものは作らなければいいだけですし)。
私の意見を総括すると「1.保護の段階はAtmark-Chanさんと同意見、または従来の色の濃淡で指定」「2. 保護の種類は錠前に白抜きで表示」「3. 無期限/半永久的な保護の表示は右上に∞を加える」となります(ミックスパターンや∞記号の色・サイズ・大きさ等は素案でありより見やすい形態への変更は歓迎します)。--ButuCC+Mtp 2020年4月29日 (水) 11:39 (UTC)[返信]
支持 もう一度よくよく考えて思ったのですが、保護の期限よりも種類(移動・作成等)のほうが重要ですね。アイコンを見た人がすぐに知りたいのは 保護の「段階」と「種類」であり、「期限」は付加的な情報に過ぎないと思いました(あくまでそのような場合が多いということです)。
であれば、当初の私の案では「種類」の情報を外側に出して「期限」の情報(∞マーク)を優先し過ぎており、これでは利便性や見やすさを欠いてしまうということになります。
一方でButuCCさんの案では「種類」を中心に表示することで分かりやすく、かつのようにそれぞれの色系統のなかで濃淡を使うことで、「ぱっと見で重要な情報を取り出せる」理想的な案に感じます。色系統を残しつつ濃淡で区別するというのは、非公式ながら現に保護記録参照ガジェットでも採用されている方式です。しかも、保護記録参照ガジェットでは多いと3段階の濃淡を見分けなければならないのに対し、この「濃・半々・淡」方式では見分けるのも簡単にできます。
(「半々」を斜めに分割することに関しても明確な理由を提示したく思いますが、現在事情によりあまり凝ったものを作れないので、それはのちほど。)
また、∞マークを右上に表示するというのは、アイコン全体が小さくても「何か付いている」というだけで無期限だということを知ることができ、これまた使いやすいと思います。
これらのことから、(色やサイズはButuCCさんも仰っているとおりこれから詰めていくとして)ButuCCさんの意見に支持を表明いたします。--Atmark-chan </稿> 2020年4月29日 (水) 15:18 (UTC)[返信]
  • コメント 色を分けるのは「ひと目で種類を識別できるようにすること」が目的であるはずです。このため、なるべく保護の種類で色を統一してあとは全て記号orピクトグラムで区別するというのは、アイコンを作る側からすれば劇的に手間が減りますが、見る側からすれば視認性は悪くなります。半永久的な保護でアイコンが赤くなっていたのも視認性の問題でしょう。色を分けることでチラッと目に写っただけで通常の全保護か或いは半永久的な全保護か、半保護か或いは移動保護かが分かります。私達はついつい管理する側の問題で考えがちですが、受け手を意識したデザインと配色が求められます。
  • まずパッと見て最初に伝わる情報は大まかな色と形です。右肩のアイコンの右上にアイコンを添えてもアイコンを注視しないと意外と目立ちません。対角線デザインも秀逸だと思ったのですが、注視しないと思ったより目立たない気がしました。
  • なので、アイコンの色分けをまずは上手い具合に活用していくことが望ましいと考えます。何かしら保護されていることだけ分かればいいというのであれば、極端な話全部統一すれば良いということになってしいます。もちろん、全統一という案は私も一切考えておりません。
  • 余談ですが、カラフルなアイコンを並べると結果的に綺麗に見えますが、単品で見るとしけた色合いに見えることがあります。逆に並べて見るとしけた色でも単品だと気にならないというパターンもあります。なるべく単品で見たり、サンドボックスにアイコンを単品で置いてみたりすると分かりやすいと思います。<indicator name="foo">[[File:Foo.svg|20px]]</indicator>のウィキ構文で画像を右上に置くことができるので、試したほうが良いと思います。--Marine-Bluetalkcontribsmail 2020年4月29日 (水) 16:05 (UTC)[返信]
    • 返信 (Marine-Blueさん宛) 対角線の案については、特に分かりづらいとは思いません。が、確かにの薄緑の部分は少し見づらいかもしれません。具体的な色につきましては、ButuCCさんも仰っているように後で詰めていきましょう。
    あと、<indicator name="foo">[[File:Foo.svg|20px]]</indicator>の件につきましては情報いただきありがとうございます。早速いくつか試してみました。--Atmark-chan </稿> 2020年4月29日 (水) 23:25 (UTC)[返信]
  • 返信 (ButuCCさん宛) ←の記号は小さく視認性に難があるというご指摘を受け記号の拡大とMarine-Blueからのご指摘していただいた、SVGにいたしました。どうでしょうか?--以上の署名のないコメントは、Kocgs会話投稿記録)さんが 2020年4月30日 (木) 02:42 (UTC) に投稿したものです。[返信]
    • Atmark-chanさんやKocgsさんが作成されたsvg画像はファイル形式こそsvgですが実態はpngと同じラスタ画像であり、ベクタ形式であるにもかかわらず拡大縮小でぼやけない特性が生かせていません。加工再利用の観点からも劣るので、SVG編集ソフトによる作成をおすすめします(まだ試作段階だし本採用時に直せばいいかと思っていましたが、お二方とも画像作成の意欲がありそうなので指摘させていただきました)。--ButuCC+Mtp 2020年4月30日 (木) 09:48 (UTC)[返信]
      • 返信 (ButuCCさん宛) ご指摘ありがとうございます。SVG編集ソフトを利用してみたいと思います。確かに本採用時に直せばいいとは思いますが出来るだけ今直したほうが今後無駄な作業が減ると思います。ありがとうございます--Kocgs会話2020年4月30日 (木) 10:00 (UTC)[返信]
      • 返信 (ButuCCさん宛) ご指摘ありがとうございます。確かに、これまではpngを変換サイトでsvgに変換するという方法を用いておりました(今考えれば、それで本当のsvgになったと考えるのはおかしな話ですね、お恥ずかしい)。
      私、残念ながら勝手にソフト等をインストールできない事情がありまして、編集ソフトを使うのは難しそうです。が、svgはHTMLと造りが似ておりテキストエディタでも編集可能とのことを知りました。HTMLにはある程度慣れておりますので、そちらでの作成・編集も検討できるかもしれません。試してみて可能であればご報告申し上げます。--Atmark-chan </稿> 2020年5月1日 (金) 01:14 (UTC)[返信]
      • 報告 テキストエディタで編集が可能でしたのでご報告申し上げます。
      試しに、アップロード半保護のアイコンを作ってみました(お試しとして作成しただけですので、実際に使うシチュエーションがあるかどうかは考慮しておりません)。 20px / 15px
      拡張半保護系の斜め分割については、現在試行錯誤中です。--Atmark-chan </稿> 2020年5月1日 (金) 12:46 (UTC)[返信]
      • 色々と作成してみました。
段階→ 全保護 拡張半保護 半保護
↓種類
(なし) 無地
記号つき
移動保護
作成保護
アップロード保護
20px
15px
一部、既存のものや他の方に作成いただいたものが含まれております。
  • は、薄緑の部分が少々薄すぎるかと思いましたので、もう少し濃くしてみました
  • は、svgの「拡大縮小でぼやけない特性」を生かして再作成してみました
「種類」のない単なる全保護・拡張半保護・半保護に関しては、図を入れるパターンと入れないパターンの両方が考えられますので、どちらも表に入れております。--Atmark-chan </稿> 2020年5月3日 (日) 12:11 (UTC)[返信]
 追記 今見ていて思ったのですが、「『種類』のない単なる全保護・拡張半保護・半保護」は図なしのほうが良い気がします。図入りだと、白抜きが範囲を占めてしまって小さくしたときに色が見えづらく感じたので(/)。--Atmark-chan </稿> 2020年5月3日 (日) 12:15 (UTC)[返信]
 追記 (連続投稿となってしまいすみません。)上記に補足します。「『種類』のない単なる全保護・拡張半保護・半保護」は図なしのほうが良いと書きましたが、移動・作成・アップロードに関しては、色が比較的鮮やかでもありますし、もちろん図ありで問題ないと思います。--Atmark-chan </稿> 2020年5月3日 (日) 12:19 (UTC)[返信]
報告 案が固まってから投票に移るまでに時間がかかっては良くないので、あらかじめWikipedia:井戸端/subj/保護アイコン一新の提案/調査投票(及びWikipedia:井戸端/subj/保護アイコン一新の提案/調査投票/コメント)を作成しました。構成は、Wikipedia:中立的な観点/草案2020年版/調査投票を参考に一部変更させていただきました。投票自体に関する議論(投票資格をどうするか等)は、/調査投票 のノートページにて行いましょう。--Atmark-chan </稿> 2020年5月3日 (日) 13:29 (UTC)[返信]
  • 了解しました。svgの特性を生かしたアイコンをお作りして頂きありがとうございます。しかしAtmark-chanさんが作成したは記号が小さいく見ずらいのではないのでしょうか?ButuCCさんSVG化した20xpを元に修正した記号の大きいはどうでしょうか?--Kocgs会話) 2020年5月4日 (月) 01:30 (UTC)訂正--Kocgs会話2020年5月4日 (月) 07:03 (UTC)[返信]
コメント うえの調査投票場所へのリンクが井戸端から見ると「Wikipedia:井戸端/調査投票」のページにリンクしているように見えてしまっていたので勝手ながら修正いたしました。--Tmv会話|投稿記録2020年5月4日 (月) 05:11 (UTC)[返信]
返信 (Kocgsさん宛) 記号が小さいのは確かにそうだなと思いました。の作成ありがとうございます。
そのなのですが、他の画像と比べて少し全体の大きさが違うことに気が付きました。拡大してみると分かると思います:
サイズは統一したほうが良いと思いますので、全体のサイズと記号のサイズを考慮してこちらで再度作成してみたいと思います。--Atmark-chan </稿> 2020年5月4日 (月) 12:57 (UTC)[返信]
返信 (Tmvさん宛) 修正いただきありがとうございます。--Atmark-chan </稿> 2020年5月4日 (月) 12:57 (UTC)[返信]
返信 (240B:253:44E0:DD00:2480:620D:5027:4F4Dさん宛) 確かにその通りだと思います。個人の方々の色覚などを考慮すると、色だけでは区別が不十分かもしれません。こちらはあまり良いアイデアが思い浮かばないのですが、どのような区別が良いですかね?--Atmark-chan </稿> 2020年5月4日 (月) 12:57 (UTC)[返信]
  • 返信 (利用者:Atmark-chanさん宛) 私も投稿時に気がついたのですがそのままにしていました。申し訳ありません。こちらでも修正したいと思います。又、 は良い案だと思いますが、確かに色だけで区別するのはあまり良くないかもしれません。--Kocgs会話2020年5月5日 (火) 01:00 (UTC)[返信]
    • コメント そもそも英語版や中国語版では作成保護などの全保護・拡張半保護・半保護はアイコン上区別されていませんし、運用的にも作成半保護等は多くないと思います。そのためそこまで考慮する必要性は薄いのでは…?--Y-route会話2020年5月5日 (火) 02:24 (UTC)[返信]
    • コメント 移動半保護とアップロード半保護のアイコンを作っておられますが、そもそも規定で全ページが移動半保護・アップロード半保護(新規及び上書き)です。作ったところで一切使われることはありませんが、ご理解いただけていますでしょうか。ガジェットでアイコンを設定していない理由も使われないためです。
    • 色分けに関しては視点の導線が保護アイコンをすっ飛ばしてもある程度識別できるようにするのが理想的だと思います。「半保護だと思ったけど、よーく見たらこれは拡張半保護だ!」とか、「通常の半保護だと思ったけど、よーく見たら半永久的な半保護じゃねえか!😠」といった事態を起こすのは良くないです。
    • 無期限保護の類に関しては、現行ののような形式で錠前の中で「∞」のピクトグラムを目立たせて良いのではないでしょうか。方針ページで移動のみを半永久保護という形で規制するというシチュエーションはあまりと思います。ページ名を含めたテキストを誰かに書き換えられて困るのであれば半永久な全保護になるだけだし、一過性の移動荒らしによる保護であれば保護の方針に基づく半永久的な保護であるとは言えません。
    • 作成保護の全保護・半保護・拡張半保護のアイコンはTemplate:RFPHelp:保護記録参照ガジェット用ですね。アップロード保護に至っては使われるであろう場所がHelp:保護記録参照ガジェットしかありません。アイコンがあれば活用はできますが、どちらかと言えば優先度は下げたほうが良さそうです。--Marine-Bluetalkcontribsmail 2020年5月5日 (火) 09:38 (UTC)[返信]
      • 返信 (Marine-Blueさん宛) 移動半保護・アップロード半保護が使われる機会がないということに関しては、はじめのうちは考慮していたのですが、ここ最近忘れておりました。ご指摘いただきありがとうございます。
      あと、「色分けに関しては視点の導線が保護アイコンをすっ飛ばしてもある程度識別できるようにする」べきだということについては同意しますが、保護アイコンが目に入ったら、ぱっと見くらいはするものではないでしょうか。そして、その「ぱっと見」があれば上記の案でも十分に識別が可能だと思います。
      それから、無期限の保護のことですが、仰るとおり、右肩に表示するだけでは目立たないと思っておりました。そこで問題になるのが、元々アイコン内にある記号(→・+・↑)との兼ね合いですね。いっそ →・+・↑ を書かず∞のみを入れるということも考えられますが、いかがでしょうか。
      最後に、作成保護・アップロード保護のことですが、確かに優先度が低いことは事実だと思います。ですが、それだけ変えないというのは一貫性を欠いてしまうと考えられますので、他のもののデザインを変えるのであれば同時に変えてしまったほうが良いと思います。(そもそも「一貫性を持たせる」というのも本提案の動機の一つだったので。)--Atmark-chan </稿> 2020年5月5日 (火) 10:18 (UTC)[返信]
    • コメント 議論上で「半永久的な保護」と「無期限保護」が混同されてきてますので、一応念の為に明確な区別を…。先のMarine-Blueさんのコメントのように、「{{保護運用}}はWikipedia:保護の方針#半永久的な保護を意図したもの」ですので、荒らし等に起因する無期限保護(沈静化後に保護解除される可能性がある)に∞等のアイコンは使うべきでないです(現状でそのように使われているページは、後々保護編集依頼にて通常アイコンへ変更を求めようと思います)。--Y-route会話2020年5月5日 (火) 11:37 (UTC)[返信]
      • コメント 了解いたしました。ありがとうございます。--Atmark-chan </稿> 2020年5月5日 (火) 12:04 (UTC)[返信]
        • コメント 優先度が低いというのは、別に対応するなというわけではありません。ただ、編集保護の関係に重きを置いていただければ。
        • 改めて、半永久的な保護の類に関しては通常の保護と事情が違うことから意図的にアイコンを別の色にしているので、引き続き色は明確に分けたほうがいいと思いますがいかがでしょうか。ちなみに現在の全保護と半保護のアイコンは明暗差や色調の差が大きいため、現状のアイコンは多少の色覚以上があってもある程度見分けられるようです。
        • 現状の色分けの方向自体は特に問題ないと思うのですが、アクセシビリティを考えた場合は明度差や色調の差を意識したほうが良い気がしました。編集保護の3種類のアイコンは色調の差が大きく、多少の色覚異常があっても見分けが付きそうです。
        • 移動保護とアップロード保護は半保護を意識しなくていいので、全保護と拡張半保護の明暗差を大きくすると識別しやすくなると思います。例えば左上の色調を強めて右下を全保護のような灰色にしても大丈夫だと思います。しけた色になりますが、単品で見るとそうでもないはずです。
        • 不適切な保護運用が貼られたページは技術的な問題(テンプレート)という名目で全保護も含めて一先ず幾つか編集してみましたが、数が多いので途中でやめました。丁寧に見ていったほうが良さそうです…。--Marine-Bluetalkcontribsmail 2020年5月5日 (火) 12:55 (UTC)[返信]
          • コメント 半保護を意識しなくて良いものに関しては、正直なところ実物がないことには判断がつきませんが、現時点では賛成寄りで考えさせていただきます。ところで、色覚異常#デザイン・ウェブサイトに、明度差・色差の推奨される数値と算出方法が掲載されておりましたので、参考までにご報告申し上げます。ですので、作成保護については、それを意識しつつ色の差を大きめにする方向でいきたいと考えております。
          • あと、不適切な{{保護運用}}については、編集お疲れ様です。標準名前空間で保護運用というのはそもそもおかしいと思いますので、ひとまず標準名前空間のものに限定してWP:BOTREQに出してみてはいかがでしょうか(私もBotを持っているので対応可です)。--Atmark-chan </稿> 2020年5月6日 (水) 12:24 (UTC)[返信]
            • コメント カラーシミュレーションに関しては取り敢えず、仮ということでスクリーンショットをTwitterにあげてみました[7]。よろしければ参考にどうぞ。
            • ボットは私が何年も使っていないので考えていませんでしたが、何件か見てみた結果、個別に判断したほうが良さそうだと思いました。例えば荒らされやすいページはプロジェクト文書へのリダイレクトで、半永久的な保護の意図する理由により保護されているようです。どっちにしろ全件見なきゃいけないので、別に手作業でも良いかなというのが私の感覚です。--Marine-Bluetalkcontribsmail 2020年5月6日 (水) 13:40 (UTC)[返信]
              • コメント カラーシミュレーションのご提示、ありがとうございます。拝見しましたところ、作成保護とアップロード保護がともに青系統に見えてしまっているようですね。
              • あと、保護運用の件、了解いたしました。--Atmark-chan </稿> 2020年5月6日 (水) 14:53 (UTC)[返信]
  • コメント 一般的な話ですが、地下鉄の路線図などは色分けに加えて点線や実線の使い分けによってユニバーサルデザインを実現しているようです。しかし、今回の錠前アイコンで点線や実線の使い分けはできないと思うので、ピクトグラムの活用がその点線や実線の代わりになります。
  • それと、こちらでも念のために補足しておきますが、例えば色覚異常の人というのは赤や緑を単体で見れば赤や緑として認識できるそうです。しかし、これが並んで敷き詰められていると同色に見えてしまうとのことです。カラーシミュレーションはその、並んでいると見分けが付かなくなるという状態のテストです。色覚異常があると世界全体にカラーフィルターが掛かるというわけではないため、誤解のないようにお願いいたします。--Marine-Bluetalkcontribsmail 2020年5月6日 (水) 15:44 (UTC)[返信]
  • コメント Help:保護記録参照ガジェットについても修正が必要なのでは?--Tmv会話|投稿記録2020年5月10日 (日) 02:50 (UTC)[返信]

コメント 説明するより実演したほうが分かりやすいと思いましたので、少し画像を編集してみました。色などは調整するとして、大まかなところを見ていただければ。

移動とアップロードの拡張半保護
半永久的な保護・拡張半保護・半保護

先にも申し上げましたとおり、移動とアップロードの半保護アイコンが不要であるため、右下をグレーにすれば左上の色との色調の差を付けやすくなります。それと、拡張半保護系を2色のデザインとすることで統一性が取れます。半永久的な保護の類は通常の保護と区別する意図があるものとして、赤系統で作ってみました。これ以外は2020-05-03T12:11:46‎の案で良いのではないかと。--Marine-Bluetalkcontribsmail 2020年5月10日 (日) 14:13 (UTC)[返信]

コメント 良いと思いますが、移動・アップロードの右下部分をもう少しだけ色をつけても良いと思います。
半永久的な保護は、明度もはっきりとなっているためで良いと思います。
あと、[8]を見る限り、作成保護はかなりはっきりと区別できているようなので、そちらは大丈夫ですね。--Atmark-chan </稿> 2020年5月10日 (日) 14:31 (UTC)[返信]
コメント なぜグレーになっているのかをご理解いただけていますでしょうか…。多少の色覚異常があっても見分けが付くよう、意図的に色調の差を付けております。ユニバーサルデザインに求められているのはカラフルさではありません。最初の画像のように同色寄りにすると同化することがあったため、その対策です。
アップロードに関してはシミュレータでテストしたところ、見分けが付きにくくなるケースがあったので紫の部分をディープトーン寄りにしてみました。拡張半保護の画像は上書きを行い、アップロードのほうは新規に画像を作成しました。
それと、編集保護のアイコンはピクトグラムありとなしのどちらでも大丈夫だとは思いますが、ありのほうが無難かもしれません。--Marine-Bluetalkcontribsmail 2020年5月10日 (日) 15:45 (UTC)[返信]
コメント グレーを使用している理由について、もう少し補足しておきます。
  1. アップロード拡張半保護の紫色が色のシミュレータで引っ掛かりやすい(ユニバーサルデザインにならない)
  2. 移動とアップロードの半保護アイコンが不要である
  3. 拡張半保護のアイコンはなるべく、斜めで分割した二色のデザインで統一したい
  4. 1-3の解決策として、半保護アイコンが不要な移動とアップロードの右下をグレーにした
カラフルでないアイコンはこのような理由に基づくものです。
それと、調査投票のページを用意しておられますが、はっきり言ってしまえば「調査投票」は不要です。拡張半保護は選択肢が幾つもあり、それを絞り込む必要があったことから投票を繰り返しました。しかし今回は「アイコンを新しいものに変える」か「或いは現行のデザインを継続的に使用するか」の二択です。調査投票とは言いません。
それと投票ページに英語を併記していらっしゃいますが、これも不要です。拡張半保護の決選投票はシステム管理者(英語圏の人)に申請を行う必要があったため、投票内容が分かるように英語を併記しました。保護のアイコンはウィキペディア日本語版のユーザー、すなわち日本語を読める人だけが対象です。
投票を行うとすれば、シンプルに現行案と改定案を並べて変更への賛否を問うだけです。投票資格をそこまで厳格に定める必要もありません。アイコンのデザイン案に関する方向性は良かったと思いますが、投票の進行には慣れていらっしゃらないという印象を受けます。
投票に関しては私が進行を行ってもよろしいでしょうか。大規模な投票は何度も進めたことがありますので、お役に立てるかと思います。--Marine-Bluetalkcontribsmail 2020年5月11日 (月) 13:14 (UTC)[返信]
  • コメント - 他言語版でも使用されている「全保護」「半保護」の記号ですが、全保護は鍵アイコン自体が制限を象徴しているのに重ねて禁止を意味するだけの記号を付けるのは蛇足感があり、半保護のそれはおそらく利用者(厳密には自動承認された利用者)を表現した意匠で、利用者は規制にかからない(≒鍵を開けられる)ということを意味しているのかなと漠然と考えたのですが、20pxとか15pxにするとユーザーアイコンというより鍵穴とか別物にも見えてきてあまり効果的と思えませんでした。
以上から私は基本となる編集保護については無地を支持したいのですが、識別の観点から記号を入れた方が良いということであればそこまでこだわりません。個人的には記号がなくとも金・銀の色で全保護・半保護を識別でき、ミックスパターンがその中間だなと思えるのですが、それは単に私が現行アイコンの色遣いを知っているからこその先入観かもしれませんし。--ButuCC+Mtp 2020年5月11日 (月) 13:58 (UTC)[返信]
  • 斜めで分割した二色のデザインは境目が分かりにくく混同しやすい。どちらの系統とも違う色で境界線を入れることができないか?
  • 『変更自体には賛成だがデザイン案には反対』ということもありえるので調査投票は必要かと思います。
  • 投票資格には一定の制限を設けないと賛成にしても反対にしても靴下攻撃されかねません。最低でも『この議論が開始されるよりも前に作られたアカウントで、50回以上の編集をしている』くらいは必要なのではないでしょうか?

--2001:268:C05F:33AD:FCC2:7F20:8242:470F 2020年5月11日 (月) 13:39 (UTC)[返信]

    • コメント ちょっと説明が悪かったですね。というか端折りすぎました。
    • 色合いに関しては私自身も、もう少し調整する余地はあると考えています。なので、これを確定として一切変えないという考え方ではないです。変更自体は投票形式でざっくりとした賛否を取って、デザインの詳細は更なる意見募集という形でブラッシュアップを行っていくのがベターかな、と。
    • ピクトグラムに関しても、素直に無地とピクトグラム有りを投票で形式で問うほうがスマートだったなと思っていたのですが、説明をすっかり忘れておりました。
    • 調査投票不要とするところの意図は、拡張半保護の投票よりもシンプルな形式で良いと考えた次第です。ただ、確かに投票を一度で済ませる必要はないかもしれません。成り行きを見ながら柔軟にと行ったところでしょうか。
    • 投票資格は「拡張半保護の投票並の厳格さがなければ良い」というのが私の意図するところです。このように言えばご理解いただけるでしょうか。--Marine-Bluetalkcontribsmail 2020年5月11日 (月) 15:21 (UTC)[返信]
コメント (編集競合してしまいましたが、とりあえずこのまま:)
返信 (Marine-Blueさん宛) グレーの意図については理解いたしました。ありがとうございます。
「『アイコンを新しいものに変える』か『或いは現行のデザインを継続的に使用するか』の二択」と仰っておられますが、これに関しては、2001:268:C05F:33AD:FCC2:7F20:8242:470Fさんのご指摘のとおり「変更自体には賛成だがデザイン案には反対」もありうるので、選択肢として置いておいても良いと思います。あと、英語併記の件については了解いたしました。
投票の進行についてですが、是非よろしくお願いします。仰るとおり私は投票に慣れておらず(というより一回もありません)、Wikipedia:井戸端/subj/保護アイコン一新の提案/調査投票も、Wikipedia:中立的な観点/草案2020年版/調査投票を適当にいじくって作成しただけといった感じなので。--Atmark-chan </稿> 2020年5月11日 (月) 15:49 (UTC)[返信]
返信 (ButuCCさん宛) 記号については、ユニバーサルデザインの意図もあるにはあるので、つけたほうが良いかもしれません。
半保護の記号は、多分「自動承認された利用者」ということなのだと思いますが、既存のアイコンを持ってきているので私にはわかりません。が、他に良い記号があれば、変更しても良いと思います。--Atmark-chan </稿> 2020年5月11日 (月) 15:49 (UTC)[返信]
返信 (2001:268:C05F:33AD:FCC2:7F20:8242:470Fさん宛) Marine-Blueさんは「投票資格をそこまで厳格に定める必要もありません」と仰っているので、勿論それくらいの制限は考えておられると思います。靴下攻撃の可能性は十分あるので。
あと、境界線を入れる件ですが、確かに黒などで多少はっきりめに入れても良いかもしれません。保護記録参照ガジェットのアップロード拡張半保護にも斜めの線は入っていて、以前からガジェットを使っている人にはより分かりやすくなるかもしれません。詳細は要検討で。--Atmark-chan </稿> 2020年5月11日 (月) 15:49 (UTC)[返信]
コメント コメントMarine-Blueさん宛) 「変更自体は投票形式でざっくりとした賛否を取って、デザインの詳細は更なる意見募集という形でブラッシュアップを行っていく」こと、「無地とピクトグラム有りを投票で形式で問う」こと、「(投票の回数などについて)成り行きを見ながら柔軟に」すること、「拡張半保護の投票並の厳格さがなければ良い」ということ、いずれも同意いたします。--Atmark-chan </稿> 2020年5月11日 (月) 16:03 (UTC)[返信]
コメント 以前のですが、もう少し記号を大きいものを作ってみました
20px
15px
--Atmark-chan </稿> 2020年5月13日 (水) 10:05 (UTC)[返信]
コメント Wikipedia:井戸端/subj/保護アイコン一新の提案/調査投票を大幅に書き換えてみました。一覧は02のアイコンを元に作成していますが、なんとなく伝わればいいので差し替えません。全体としてはこれでいいと思うのですが、細かい部分は修正の余地があるかもしれません、確認をお願いいたします。--Marine-Bluetalkcontribsmail 2020年5月13日 (水) 12:48 (UTC)[返信]
感謝 色々とありがとうございます!
少し質問があるのですが、それはWikipedia talk:井戸端/subj/保護アイコン一新の提案/調査投票にて。--Atmark-chan </稿> 2020年5月13日 (水) 13:10 (UTC)[返信]
 告知 2020年5月17日より一週間、Wikipedia:井戸端/subj/保護アイコン一新の提案/調査投票にて投票を行います。奮ってご意見ください!
今回は「現行案寄り」「改訂案寄り」と大勢把握を主な目的としており、細かいところは投票後に詰めていくことになります。
詳細はWikipedia:井戸端/subj/保護アイコン一新の提案/調査投票での説明をご参照ください。--Atmark-chan </稿> 2020年5月14日 (木) 16:40 (UTC)[返信]
コメント 長くなってきていい加減見づらいのでサブページでも切りましょう。Wikipedia:井戸端/subj/保護アイコン一新の提案/改定案についてで改定案をまとめていきます。--Marine-Bluetalkcontribsmail 2020年5月24日 (日) 16:35 (UTC)[返信]

Unicodeの基本多言語面にない文字をタイトルに含むページの作成解禁に向けて

現在関連議論として通常記事名においてもJIS X 0208以外の文字を使えるようにすべきではないかという議論を行っております。是非ご参加ください。--Schwei2会話) 2020年5月8日 (金) 14:01 (UTC) リンク修正 Schwei2会話2020年5月8日 (金) 14:37 (UTC)[返信]


先行議論はWikipedia:井戸端/subj/Unicodeの基本多言語面にない文字をタイトルに含むページの作成禁止は継続すべきかです。

現在のところ日本語版ウィキペディアではページ名にはUnicodeの基本多言語面(BMP)にある文字のみが使用できることになっており、「𠮷」(U+20BB7)や「🌰」(U+1F330)といった基本多言語面にない文字(追加面にある文字)は例外なく(記事以外であっても)ページ名に使用してはいけないことになっています。この規定は2017年12月にあったWikipedia‐ノート:記事名の付け方/過去ログ6#基本多言語面にない字の使用制限での議論により追加されたもので、追加された理由はHelp:ページ名#Unicode文字の使用可能範囲にも書かれている通り、当時のデータベース管理システムに使用されていたMySQLに存在した制約によるものです。

しかしながらBMP外の文字をタイトルに使えないとなると、𠮷野家𠮷野家) → 吉野家のように本来の表記にBMP外の文字を含むケースでリダイレクトを作成できないという弊害があります。また、ウィキメディアの仕様上BMP外の文字を含むアカウント名は取得可能ですが、そのようなアカウントの利用者ページや会話ページを日本語版ウィキペディアでは作成できないという問題もあります。

2019年になって先述の規定を継続すべきか意見を求めたところ、MySQLに存在した制約は今はなくなっており、BMP外の文字をページ名に使用してもシステム上問題は生じないだろうという結論に至りました。引き続いてBMP外の文字をページ名に使用可能にする提案を出したところ複数の賛成あり、反対なしの状況でした。

その後Wikipedia:即時削除の方針のリダイレクト2-4(Unicodeの基本多言語面(BMP)(U+0000からU+FFFFまで)に含まれない文字を使用しているもの)を廃止(特別:差分/73427404)したところで放置してしまいました。当初私が想定していた作業内容を一部変更・追加した上で実施することを今回改めて提案します。提案する作業内容を以下に示します。

  1. チェック Help:ページ名#Unicode文字の使用可能範囲を丸ごと除去
  2. チェック Wikipedia:記事名の付け方の改訂
    1. Wikipedia:記事名の付け方#記事名に使用できる文字にある「システム上の使用可能文字の制限」のリンク先をHelp:ページ名#制限へ変更
    2. Wikipedia:記事名の付け方#システム上の使用可能文字の制限を丸ごと除去
  3. チェック Wikipedia:表記ガイド#項目名にある「システム上の使用可能文字の制限」のリンク先をHelp:ページ名#制限へ変更
  4. BMP外の文字を使用しているという理由で個別に作成保護されている(と推測される)ページについて保護の解除を依頼
  5. チェック タイトルにBMP外の文字を含む標準名前空間のページを追跡するためのモジュール、テンプレートおよびカテゴリを作成
  6. 新たな編集フィルターの作成を提案
  7. MediaWiki:Titleblacklistにある.*[\x{10000}-\x{10FFFF}].*ならびにMediaWiki:Titlewhitelistにある利用者(‐会話)?:.*[\x{10000}-\x{10FFFF}].*のエントリの除去を依頼
  8. Wikipedia:リダイレクト#正式名称に記事名に使えない文字が含まれる場合にBMP外の文字を含むリダイレクトの例を追加
  9. Wikipedia:お知らせにタイトルにBMP外の文字を含むページが作成可能になった旨の報告

いくつか補足します。4についてですが、今年の4月20日時点のダンプデータを用いて、作成保護されているページ名のうちBMP外の文字を含むものを検索したところウルトラマン😛🙁Xノート / 履歴 / ログ / リンク元𠮷ブーノート / 履歴 / ログ / リンク元𠮷野家ノート / 履歴 / ログ / リンク元の3つが見つかりました。このうち1つ目は将来も含めて作成する必要は生じないと考えられます(削除記録もないのにどういうわけか「度重なる荒らし」を理由に作成保護がかけられている)ので、残り2つに対して保護解除依頼を出します。

5についてですが、モジュールおよびテンプレートの試作品をそれぞれモジュール:サンドボックス/本日晴天/Title with non-BMP利用者:本日晴天/sandbox/Template:Title with non-BMPに作成しました。使用例についてはtest2wiki:辰𠮷𠀋一郎test2wiki:辰𠮷𠀋一郎2ご覧ください。テンプレートを使用したページがリダイレクトであるか否かにより異なるカテゴリを付与するという仕組みになっています。

6についてはタイトルにBMP外の文字を含む標準名前空間のページでは5で作成したテンプレートの使用を強制するという仕様を考えています。あと私としては迷っているのですが、タイトルにBMP外の文字を含む標準名前空間のページについてはリダイレクトとしてのみ作成・編集を許可するように制限してもいいかもしれません。リダイレクトでない標準名前空間のページとして考えられるのは曖昧さ回避ページ、あるいは文字そのものについての記事です。この点についてもよろしければご意見をお願いします。

合意が得られた場合は1から6まで順次実施し、6の編集フィルターがWikipedia:編集フィルター/提案#提案から正式稼動までの流れに書かれている試験運用に入ったら7を実施、そして編集フィルターが正式稼働となったら8と9を実施する予定です。

先の議論でも述べましたが、今回の提案は一般的な記事名に使用可能な文字の範囲を変更するものではない点をご留意ください。BMP外の文字をページ名に使用可能にするという方向性については先の議論で合意が得られていると思われますが、合意不十分だと考える方、反対される方がいらっしゃいましたらその旨の表明をお願いします。--本日晴天会話) 2020年4月26日 (日) 14:59 (UTC) 下線部を追記。--本日晴天会話2020年4月26日 (日) 15:01 (UTC)[返信]

 追記 7についてですが、Wikipedia:バグの報告由来でMediaWiki:Titlewhitelist利用者‐会話:.*[\x{10000}-\x{10FFFF}].*のエントリが追加されていたので、これを除去する依頼を出すことも追加します。あと、追加特殊用途面(U+E0000 - U+EFFFF)と私用面(U+F0000 - U+10FFFF)にある文字の使用については引き続き禁止するものとします。これらはMediaWiki:Titleblacklistによって、7で提示したエントリとは別に規制されています。--本日晴天会話2020年4月27日 (月) 05:27 (UTC)[返信]

  • ウルトラマン😛🙁Xの作成保護に対するご指摘についてですが、同じ管理者による同日中の公開記録を見るとLTA:203らしき利用者によって作成された特撮関連記事が削除・作成保護されているので、それと関係があるかもしれません。--Keruby会話2020年4月27日 (月) 01:22 (UTC)[返信]
  • 賛成 とりあえず、本日晴天さんが提示した作業内容で進めていいと思います。BMP外の文字は入力が困難であろうと思料しますので、入力の利便性を考えてリダイレクトとしてのみ作成すべきであると考えます。文字そのものについての記事はWikipedia:独立記事作成の目安をクリアできそうな例が現時点で思いつきませんので、将来そのような文字が現れた場合に例外として許可すればいいでしょう。--ネイ会話2020年5月4日 (月) 14:50 (UTC)[返信]
  • コメント 前回の議論でも指摘しましたが、この案では荒らしに新しい玩具を与えるだけです。この提案が問題を引き起こす原因は、BMP範囲外の文字が「必要ではない」状況でも無制限に解放しているところと、単にBMP外の解放とするだけで精査を欠くところにあります。
まず絵文字(とそれに類するもの)、漢字、その他の言語は分けて考えなければなりません。ブロック (Unicode)を参照するなら、以下の3パターンに分けられると思います。
  1. 追加漢字面:おそらくこの提案で最も意味があるのがこちらです。リダイレクトではあっても作成できるのであれば、「制限の理由を知らずに作れずに行き詰まる」ケースへの対応が可能となります。
  2. その他の言語類:リダイレクトとして可能性は皆無ではありませんが、大半は不要でしょう。おそらく「文字そのものについての記事」と「翻訳」でしか使えません。
  3. 絵文字類:ページ名として解放する利点を解放しない利点が上回ると考えます。
これは、絵文字以外についてはページ名側からは「文字それ自体」を除けば即時改名してリダイレクト化するだけで現状と全く変わりが無いからです。ただ、文字そのものについての記事には何らかの方法で回避記事は必要になるのですが、それは既存の記事についても同様なので置いておくことはできると考えます。しかし、絵文字は別です。絵文字は確実に子供っぽいいたずらや荒らしの武器になります(上記のウルトラマンの例)。加えて見落とされているのは、絵文字の入力はモバイルから安易にやってしまうことも考えられることです。そのため単純に解除することは害が利点を上まわるでしょう。既に別途話題(Wikipedia:井戸端/subj/Unicodeの文字をリダイレクトとして作成できるか)が提起されていますが、以下のような対処であるべきと考えます。
  1. 必要ではないページ名には使用できない状況を維持する(技術的に無理ならリダイレクトはSD対象とする)。リダイレクト設定となる標準(まだ存在しませんがDraftを含む)、他言語版で作成されたユーザーを含む範囲外の文字を想定する利用者ページや会話ページ。これ以外の空間では不要でしょうし、通常の記事で使用される可能性のあるカテゴリ・テンプレートや、これらに対する依頼を想定するWikipediaについては、むしろ積極的に対象外にする必要があります。
これをベースに考えると提案は補助私用領域まで含みブラックリストから外す範囲が広すぎますので、
  1. U+20000 - U+2FA1Fを外す(追加漢字面のみ解除案)
  2. U+10000 - U+2FA1Fを外す(絵文字を含む解除案、絵文字を含まない解除案とリダイレクトが両立しない場合)
  3. 上記からU+1F000 - U+1FAFFをブラックリストに残す(絵文字を含まない解除案)
  4. さらに記事名になるとは考えられないものを個別にブラックリストに加える
この4案のいずれかになると思われます。厳しさでは、1→4→3→2の順で緩くなっていきます。運用としては、
  1. 標準空間の単独の絵文字は全てリダイレクトして保護するか作成保護とする。絵文字そのものについての記事は、「絵文字名 (絵文字)」の形式。
  2. リダイレクト以外の絵文字は引き続き使用不可とする
  3. 絵文字以外はリダイレクトに限定する。曖昧さ回避は許可せず、無期限の移動保護。文字そのものについての記事は例外とするが、前述の通り回避方法は検討が必要。
  4. これを受けて保護済みの記事については保護を解除せず保護中の記事の編集依頼としてリダイレクト化。
これぐらいの制限があれば、荒らしによって記事名として乱用される・移動荒らしによってリダイレクトへ移動されるといった事態はある程度阻めるでしょう。--Open-box会話2020年5月6日 (水) 12:09 (UTC)[返信]
  • Open-boxさんのコメントは、本日晴天さんの作業手順のうち4、6、7のみに対する反論とみられます。
    • Open-boxさんの4案にしてもそれ以外の案を採用するにしても、ブラックリスト入りの理由が「システム上の制限」ではなくなり、「荒らし対策」あるいは「記事名として使用されることのない文字」が理由となります。したがって1から3の改訂とは矛盾しないようにみえます。5はむしろ荒らし対策の一環として役に立つ(荒らしが今回の解禁で新しく作成できるようになったリダイレクトを作成した場合、当該カテゴリに含まれ、検出がより容易になる)ため、積極的に進めるべきでしょう。9は今回の改訂を告知するだけで、1から8が完了した後にあえて告知しない理由がないと考えます。
    • つきまして、荒らし対策に関する議論が続いている間でも手順1、2、3、5は進めることができると考えます(「システム上の使用可能文字の制限という記述が誤りでも、荒らし対策に関する議論が終わるまでは誤りのままにすべき」という意見ならば別ですが)。
  • 本題についてですが、絵文字でもUnicodeブロック記事へのリダイレクトか、絵文字が表すものの記事へのリダイレクトとして作成されるべき(これは絵文字1文字に限ります)と考えます。追加多言語面の文字についても、ショー文字など文字体系の記事へのリダイレクトになると思います。つきまして、「標準空間の単独の絵文字・追加多言語面の文字は全てリダイレクトのみ許可」「リダイレクト以外は引き続き使用不可とする」「文字そのものについての記事は例外とする」に賛成します。
    • 追跡カテゴリのページ数が多すぎるという問題は、ページ名が1文字のものをサブカテゴリに移すことで解決できます。
  • ただし、絵文字そのものについての記事名は「絵文字名 (絵文字)」にならないものも多い(例としては怒りマーク温泉マークがある)ので、これを現時点で定めるのは慎重であるべきと考えます。
  • なお、「補助私用領域まで含みブラックリストから外す範囲が広すぎます」は本日晴天さんが述べた通り、「MediaWiki:Titleblacklistによって、7で提示したエントリとは別に規制されています」ので、「補助私用領域まで含み」は誤りです。
  • 技術的に可能・不可能の話は、基本的にTitleBlacklistより編集フィルターのほうができることが多いと考えてください。たとえば、TitleBlacklistはリダイレクト以外を禁ずる機能はありません(名前空間はページ名の指定により可能)。人手が足りない状況の中即時削除依頼の数を増やしたくないという考えから、規制を「TitleBlacklist+即時削除」ではなく、「編集フィルター(+補助私用領域はTitleBlacklist)」で行うのが得策であると考えます。この考えに同意した場合、7の手順に反対しないことになります(意見の異なる事柄が編集フィルターの内容に絞られるため)。--ネイ会話2020年5月8日 (金) 09:59 (UTC)[返信]
    • (構成の都合上、間に入ります)Schwei2さんが別途出されたような提案が出てくるから、安易に広げるのはやめとけって感触はあるんです(「記事名」だけ厳しい理由が知られてないなぁと)。自由に使わせろ・困る人なんていない・かっこ悪い・我慢するのは嫌だ・コードについて考えたくない・荒らしなんて出てこない、だから解放しろとなるのは当然の要求なので、下準備をしっかりしないとこの変更は危険です。本文との不一致が原因の一つで、本文に使えるなら当然記事名にもとなりますからね。
ブラックリストのその部分に手を付けないなら問題はおきないでしょう
実は一番問題が大きいのは9です(この発表では自由に使用できるため)。ただこれは、「リダイレクト」を作成できると公表すればいいので微調整の範囲でしょう。
絵文字の記事については、「XXマーク」は確かにありますね。これは「絵文字」を記事名に使用してはならないぐらいにまで広げても対応できると考えます。
編集フィルター:現状でこんなことはできますか? 作成済みの絵文字1文字のリダイレクトに影響を及ぼさず絵文字入りのページ名を禁止する、名前空間依存でBMP範囲外のページ名を禁止する、移動や編集を阻止する。執筆者への通知や作成されたページの発見するだけで阻止する機能は無いのでは意味がありません。通知を無視して作られてからフィルターで報告が飛んでも一般利用者にはほとんど価値はありません。
どうもリダイレクト設定で満足しているのではないかというのが引っかかります。先に述べたとおり次に起きることの一つのは移動荒らしですが、リダイレクトを設定するだけですとかえって悪影響があります。「コピペ移動」という度々問題を起こしているケースを忘れないで下さい(これがあるので絵文字は保護を提案しています)。また、これらに対する依頼は必然的にBMP範囲外のページ名を伴いますからさらなる悪影響を伴います。即時削除依頼の数を増やしたくないどころか、通常の依頼すら増えそうなんです。--Open-box会話2020年5月8日 (金) 19:13 (UTC)[返信]
  • 編集フィルターの内容は下記のようなものが考えられます。(詳しい解説はmw:Extension:AbuseFilter/Rules_format/jaにて)
    • 「ページ編集(作成を含む)の場合」かつ「ページ名にBMP範囲外の文字を含む場合」かつ(「リダイレクトでない場合」または「リダイレクトであり、追跡用テンプレートがない場合」または「リダイレクトで、ページ名が2文字以上、かつ絵文字入りの場合」):「対処操作:不許可」
      • or文を「または」で、and文を「かつ」で表現しています。「BMP範囲外の文字を含む」は正規表現による検出になります。
    • 「ページ移動の場合」かつ「移動先のページ名にBMP範囲外の文字を含む場合」:「対処操作:不許可」
  • 技術上は上記のフィルターが可能だと判断しています(上記リンクに日本語の仕様書があるので、ほかの方もご確認いただければ幸いです)。--ネイ会話2020年5月9日 (土) 05:19 (UTC)[返信]
    • ありがとうございます。一通り確認してきましたが、page_namespaceを使えば名前空間別の処理も可能になりそうです(もっとも避けたいのはテンプレートとカテゴリ)。これで阻止できないのは、リダイレクトを通常の記事名に移動するぐらいですね。誤記がありうるのでこれを編集フィルター対応とすると不自由すぎるかも知れません。他の部分はフィルターでの解決が可能と考えますから、ここだけ何とかしていただければ賛成となります(全部先に作って保護だと多忙すぎますかね)。--Open-box会話2020年5月9日 (土) 05:44 (UTC)[返信]
    • Schwei2さんのコメントは冒頭に移動させました。編集フィルターの内容1つ目についてなんですが、最後の「リダイレクトで、ページ名が2文字以上、かつ絵文字入りの場合」は必要か、というかそもそも実現可能なんでしょうか。mw:Extension:AbuseFilter/Rules_format/jaを見た感じだとページ名が1文字だけなのであれば絵文字かどうかはpage_title in "(絵文字を並べた文字列)"で判定できそうですが、2文字以上の場合に文字列中の全部の文字について同様の判定を行うことはできないという気がします。BMP外の絵文字を含む2文字以上のリダイレクトは作品名とかで需要がありそうです。単独記事にはなっていませんが、まんがライフMOMO#創刊以後の連載作品に初恋💔症候群(シンドローム)という作品名が書かれています(「💔」(U+1F494)を含む)。あと、ページの冒頭に{{即時削除}}などを貼った結果リダイレクトでなくなった場合は例外的に許可した方がいいですね。--本日晴天会話2020年5月10日 (日) 03:37 (UTC)[返信]
      • 自己レスになりますが、絵文字入りかは正規表現を使えば複雑にはなりますができなくはないですね。そうなると「ページ名にBMP範囲外の文字を含む場合」の部分と合わせて正規表現を2回も使うことになり、コスト面からあまり好ましくないように思えます。--本日晴天会話2020年5月10日 (日) 04:34 (UTC)[返信]

報告 ここに書かれていた、Uminokawausoさんと私のやり取りについてはノートに転記しました。--本日晴天会話2020年5月29日 (金) 11:34 (UTC)[返信]

報告 当初の提案から3週間以上経過しましたので、とりあえず一度も反対意見が出なかった1・2・3・5の作業については実施しました。作成したモジュールはモジュール:Title with non-BMP、テンプレートはTemplate:Title with non-BMP、カテゴリはCategory:Unicode基本多言語面外の文字を含むページ名Category:Unicode基本多言語面外の文字を含むリダイレクトです。--本日晴天会話2020年5月21日 (木) 11:45 (UTC)[返信]

報告 コメント 6の作業に関して、Wikipedia:編集フィルター/提案にてネイさんご提示の内容のうち1つ目のフィルター(作成・編集)について提案を出しました。 2つ目のフィルター(移動による作成)についてですが、その内容でしたら代わりにTitleblacklistの.*[\x{10000}-\x{10FFFF}].*にmoveonlyを付けるというのはいかがでしょうか。この場合、Titlewhitelistの利用者(‐会話)?:.*[\x{10000}-\x{10FFFF}].*はそのまま残します。デメリットとしては管理者であれば規制をすり抜け可能なことでしょうか。--本日晴天会話2020年5月29日 (金) 11:51 (UTC)[返信]

Linking Nobelprize.org using a template

Sorry writing in english but we have now spoken with Nobelprize.org people about all the Link rot we have linking them. They have now created an unique id that for every prize winner that we now also store in Wikidata P8024 - (P8024) that can be used for linking Nobelprize.org. Dont hesitate to contact me if you have questions

see also Task T251055 - Salgo60会話2020年4月27日 (月) 11:00 (UTC)[返信]

(抄訳) Nobelprize.org(ノーベル財団ウェブサイト)に関して発生してきたリンク切れについて、ノーベル財団職員と話し合いを行ったそうです。それで、受賞者一人ひとりにユニークなIDを割り当て、WikidataでもP8024として管理するそうです。なにか疑問があれば、遠慮なく聞いてくださいとのことです。片割れ靴下会話2020年4月27日 (月) 17:07 (UTC)[返信]
コメント もう少し噛み砕くと、ノーベル財団ウェブサイトの受賞者リンクが変更となったので、各受賞者記事のリンクを変更して下さい。リンクにはwikidataのプロパティP8024が使えますよ ということですね。作業としてen:Template:Nobelprizeを移入してリンクの置換が必要ですね。--115.39.237.111 2020年4月28日 (火) 01:41 (UTC)[返信]
Let me know if you need help creating the template you must help me with the translation - Salgo60会話2020年4月28日 (火) 09:20 (UTC)[返信]

「発達障害」ポータルの提案

私は、にゃんこと申します。本題に移りますと、私は「発達障害」というポータルがあればいいな、と思います。理由を説明しますと、実際のところまだ発達障害や自閉症などへの理解がない人も多く、私自身も発達障害を抱えていて、散々ひどい目にあった過去があります。最近アスペルガーの記事への荒らしが起きていますが、これはアスペルガーのことを「もっと理解してくれ」「こんな記事が誤解を生んでいるんだ」などという思いの裏付けなのだと思います。こういう理解を深めるためにも、日本最大の情報源であるwikipediaからまずは変えて行こう、というのが目的です。 まだWikipediaの経験も浅く、私に言う資格はないかもしれませんが、一応参考程度に、検討して戴けると幸いです。(--Nyankotrain会話2020年4月29日 (水) 13:43 (UTC))[返信]

分割が競合してしまったときは?

先ほど、Wikipedia:井戸端から「新しいポータルの提案」を「Wikipedia:井戸端/subj/「発達障害」ポータルの提案 ‎」に改名の上、自ら手動で分割を行った(特別:Permalink/77294638)のですが、Botによる作業(Wikipedia:井戸端/subj/新しいポータルの提案)と重なってしまい、同じ内容のページが2つできしてまいました。なお、前者に返信のコメントをいたしました。

一応、Botが作成したほうのページを転送ページにしたのですが、このようなケースの場合、削除依頼などを出したほうが良いのでしょうか。それとも、リダイレクト(化)でOKなのでしょうか。--Mario1257会話2020年4月29日 (水) 15:58 (UTC)[返信]
一応紛らわしいのでまとめますと、

となります。一部修正・追加--Mario1257会話2020年4月30日 (木) 17:14 (UTC)[返信]

コメント 推測ですが、ページ名として少々問題を生む可能性があったのでBot側が名前を変更したのだと思います。
それはさておき本題に入りますと、Wikipedia:井戸端/subj/「発達障害」ポータルの提案にはカテゴリづけや返信などの有用な履歴があるのに対し、Wikipedia:井戸端/subj/新しいポータルの提案にはそれがありません(初版作成とリダイレクト化しか行われていない)。
さらに、差分を確認したところ前者の初版後者の初版には相違点がなく全く同じ内容でした。
以上のことから、削除しても議論の進行や著作権等で影響する恐れはないと思います。
しかし、リダイレクトの削除関連については、私あまり詳しくありませんので、詳しい方のご意見を待つのも手だと思います。それまでの間は 現状維持(リダイレクトのまま)としておいたほうがよろしいかと。--Atmark-chan </稿> 2020年4月30日 (木) 00:09 (UTC)[返信]
  • 返信 コメントありがとうございます。勘違いされているかもしれませんが、名前を変えたほう=自分で分割しました。説明のほうが紛らわしく、申し訳ございません。とりあえず、リダイレクトのまま様子を見ます。--Mario1257会話2020年4月30日 (木) 17:14 (UTC)[返信]

複数記事で「出典の無い記述追加」と「出典のある記述除去」

ヨグ=ソトースの編集について「やきそば飲みたい」さんにコメントしたところ、白紙化されました。あらためてこの人の編集履歴を見ると4月28日から、出典のある記述を消して出典の無い記述を足す、という連続投稿をクトゥルフ神話関連の記事で繰り返してます。もっと対話とか議論をしようにも、こういう場合ヨグ=ソトースのノートや「やきそば飲みたい」さんのノートでするのは不適切かと思ったのですが、どうしたらいいでしょうか?--153.205.161.242 2020年5月1日 (金) 04:04 (UTC)[返信]

百科事典づくりをしているのだから、記述を除去したりまとめたり当然ありますが。杓子定規に仕切られても、基礎知識自体無い人が百科事典作りという大前提無視して口を挟んできているだけで、上滑りにしかなりませんが。--やきそば飲みたい会話2020年5月1日 (金) 04:31 (UTC)[返信]

作品タイトル明記しています。そもそも出典の一つである『図解 クトゥルフ神話』、この本はあくまで事典・入門本・ガイドブックの類ですからね。一次資料を編纂し直した二次資料です。そこから逆に調べて一次資料の出典たる個別作品を特定して書いているので、むしろ出典は強化されています。--やきそば飲みたい会話2020年5月1日 (金) 04:48 (UTC)[返信]
コメント まず、そういう話はやきそば飲みたいさんの会話ページでするものです。これから同じようなことがあった場合はそちらでお願いします。それと、基礎常識がない人には親切に教えるというものが礼儀です。さらに「一次資料の出典たる個別作品を特定して書いている」といわれていますが一次資料は信頼できる情報源にある通り使用できるところが限られています。こちらの方針もよくお読みください。編集についてコメントしたら白紙化された、これが事実ならやきそば飲みたいさんの行動は個人攻撃にあたります。貴方はその白紙化について説明責任を果たせますか?力ずくで解決しようとしないでください。--Tmv会話|投稿記録2020年5月1日 (金) 04:58 (UTC)[返信]
 追記 やきそば飲みたいさんの会話ページを拝見いたしました。153.205.161.242さんはしっかりと方針やガイドラインを踏まえたうえで注意されていて、おっしゃっていること、もっともだと思います。もしこれで当人の行動が改善しなければ、コメント依頼に出した方が良いかも知れません。--Tmv会話|投稿記録2020年5月1日 (金) 05:10 (UTC)[返信]
報告 利用者‐会話:やきそば飲みたい#複数記事で「出典の無い記述追加」と「出典のある記述除去」に議論場所を移しました。今後はそちらにコメントをお願いします。--Tmv会話|投稿記録2020年5月1日 (金) 05:14 (UTC)[返信]

では具体的に何をどう編集すればよいのですか。不満なら加筆していただいてかまいません。--やきそば飲みたい会話2020年5月1日 (金) 10:33 (UTC)[返信]

第三者意見をください

建設的にWikipediaのクトゥルフ記事の質を上げたい。未熟ですがルールは書きながら学習中。

スキルや知識の及ぶ範囲で出典は示しています。ヨグ=ソトースなら今のやり方ができる限りのもの。出版元・書籍名・タイトルまでは提出可能。それすら書いていなかった箇所に、新たにつけています。ここまでわかれば、あとはフリー百科事典として第三者による検証および訂正を可能にしています。

第三者意見ください。偏らないように、できれば執筆者といえるタイプの方。個人会話ページでの対話者二名は、Wikipediaにおいて記事を書かず議論を重視するタイプ(投稿履歴参照)なので、前提が異なり、対話・意思疎通不可能です。彼らは目的が異なり、執筆よりも議論のためにWikipediaにおり、ルールに詳しいが具体的な書き方はできないよう。--やきそば飲みたい会話2020年5月3日 (日) 02:31 (UTC)[返信]

○○の歴史というカテゴリについて

総合スーパーのカテゴリを見てふと思ったのですが、○○の歴史というカテゴリはなんかふさわしくないような気がします。簡単に言うと閉店した店舗や廃止されたブランドなどが入っています。もっといい名前がないかもしくは削除して大元のカテゴリに統一したほうがいい気がしてなりません。(もしマイカルみたいに潰れてしまったら不要になってしまう。)ちなみに、Wikipedia:削除依頼/Category:イトーヨーカ堂の歴史を出した際は私以外に票がつかず存続終了となっています。(その後様子を見ていましたがやはり最近になってやっぱり違和感を感じました。)--Yosizuya会話2020年5月2日 (土) 13:02 (UTC)[返信]

モバイル版の「ウィキペディア」の文字

モバイル版で閲覧した際、画面の上下に「ウィキペディア」という文字が表示されます。しかし、これまでネズミ色だったにも関わらず、昨日から黒色に変わっています。一昨日の時点ではネズミ色だったのですが、これは何故でしょうか。これまでの方が背景の色と調和しており、いたずらに目立つ今の表示は良いとは思えません。--126.35.31.170 2020年5月2日 (土) 13:41 (UTC)[返信]

これですね。英語バージョンも含めコモンズなども変わっています。いつか慣れますよ。--おかしなペディアン会話2020年5月3日 (日) 02:21 (UTC)[返信]
他の言語版でも変わっているのですね。てっきり日本語版でのみ起きていることだと思っていました。不満はありますが、財団側で変えているのであれば仕方ないのかもしれません。教えて頂き有り難うございます。--126.35.31.170 2020年5月3日 (日) 06:53 (UTC)[返信]

色はまぁ良いのですが、ィがちょっと大き過ぎないかなぁと前から気になっています。これはイの90%くらいでしょうか。--Hisagi会話2020年5月3日 (日) 07:25 (UTC)[返信]

というか、ベースライン (書体#欧文書体における並び線の種類) がおかしくないですか。日本語の本来あるべき文字の下揃えではなく、中央揃えか上揃えになっているようにみえて、個人的には醜悪なデザインに見えます。--rxy会話2020年5月3日 (日) 07:34 (UTC)[返信]
同じことを同時に気づいて別の節↓に立ててしまいました(こういう時、競合しなくなったんですね・・・ほんとか?)。文字の大きさもそうですが、ベースラインも確かに変ですね。--青子守歌会話/履歴 2020年5月3日 (日) 07:40 (UTC)[返信]
ちなみに和文組版の場合はベースラインではなく仮想ボディ (詰め組み#種類と方法) が基準となります。現在のphabの表現だと非日本語話者のデザイナーに誤解されてしまう可能性もあるので念のため。--106.154.130.91 2020年5月5日 (火) 01:36 (UTC)[返信]
「ベースライン」は(横書きの)日本語に適用することもありますが、異論もあるようです[9]。 --2001:240:240A:5B92:2DAB:1954:7CA0:C65B 2020年5月16日 (土) 09:47 (UTC)[返信]

ウイキペデイア?(イが大文字?)

モバイル版で表示されているワードマーク(の複製)
いつものロゴはちゃんと小文字になっている

↑の色の話を見てて別のところ気づいたのですけど、このワードマークロゴ、ウィキペディアのイが大文字に見えます。

これ、誰がどこでどうやって作ったんでしょうね?v1ロゴのワィの時と同じで日本語がわからない人が適当に作ったロゴなんだろうなぁとは推察できるんですけれど。

少なくとも普段見慣れた(ベクター外装だと左上に出てくる)ロゴではちゃんとィ(小文字のイ)になっているので、これを切り出したわけではないんでしょう・・・。

コモンズに元画像があって修正できるのかもと思ったんですが、そうでもなさそうです。phabricator:にバグ(?)を出すべきか、そもそも意図的にイになっているのか。 みなさんどう思われますか?--青子守歌会話/履歴 2020年5月3日 (日) 07:38 (UTC)[返信]

情報 phab:source/mediawiki-config/history/master/static/images/mobile/copyright/wikipedia-wordmark-ja.svg 履歴。gerrit:336466 初稿。phab:T157476 根拠タスク。--rxy会話2020年5月3日 (日) 07:57 (UTC)[返信]
情報 phab:T251693 が提出されています。--rxy会話2020年5月3日 (日) 12:55 (UTC)[返信]
ベースラインの話だけで「ィ」の大きさには触れてない…? --Hisagi会話2020年5月3日 (日) 15:07 (UTC)[返信]
  • macOS Catalina (v10.15.4) およびiOS 13.4.1のSafariブラウザでモバイルビューを表示してみました。文字色は特に問題ないと感じますが、「ィ」が小書き文字ではない半角カタカナの「イ」に見えてしまって違和感があります。キヤノンのように歴史的仮名遣で表記されていた経緯があるなら話は別ですが、ウィキペディア日本語版にそのような歴史があったと聞いたことはありません。あとこれは私の閲覧環境の問題なのか、それとも目の錯覚なのかはわかりませんが「ペ」だけ文字の書式が細字に見えるというか、やや大袈裟に表現すると「ウイキデイア」のようなバランスの悪さを感じます。--Keruby会話2020年5月4日 (月) 06:21 (UTC)[返信]
  • 「ペ」は、ひらがなの可能性あるかも。240B:253:44E0:DD00:2480:620D:5027:4F4D 2020年5月4日 (月) 11:48 (UTC)[返信]
  • コメント 「ペ」ですが、大きくしてみると「ペ」(かたかな)「ぺ」(ひらがな)みたいな感じでひらがなの方が右側の線が沿っていますね。あと、カタカナは山の頂上がひらがなより左に行っている気がします。細字かどうかについてはよくわかりませんがフォントの問題でこういうところは変わるもんですからわかりませんね。ただ、文字の太さに関してはわたしも「ペ」だけ何か違和感を感じます。--Tmv会話|投稿記録2020年5月6日 (水) 06:20 (UTC)[返信]

チェック phab:T251693phab:T252143を経て、gerrit:595014で修正されたようです。まだウィキ上に展開されていませんが、待ってれば直りますね。--青子守歌会話/履歴 2020年5月14日 (木) 10:08 (UTC)[返信]

チェック 展開されて https://ja.m.wikipedia.org/static/images/mobile/copyright/wikipedia-wordmark-ja.svg も修正されました。ちゃんとウィキペディアって読めますね(地球儀ロゴとほぼ一致するのでちゃんとここから持ってきたものっぽい)。めでたしめでたし。--青子守歌会話/履歴 2020年5月15日 (金) 17:18 (UTC)[返信]

  • なにやら線が細すぎませんか?スマートフォンの画面で見るとウィキペディアの表記だけ変に浮いてしまっています…。イが小文字として分かりやすくなったのはいいと思うんですが、文字全体をもう少し太めにはできないものでしょうか…。他言語版をチラリと見てみたところ、中国語版や朝鮮語版なども含めて英語のWikipediaロゴを使っているところが多いようです。一方、ヘブライ語版はヘブライ語で表記しているので、日本語版はこれと同じですね。ただ、英語にせよヘブライ語にせよ、文字の線は太いので、今の日本語版の線は細過ぎると思います。--126.33.217.52 2020年5月20日 (水) 15:33 (UTC)[返信]
上:デスクトップ版、下:モバイル版
たしかに、デスクトップ版のよりもやや細い気がしますね。まぁ色も黒くなりましたし読むには支障ないレベルですが。--Hisagi会話2020年5月24日 (日) 15:56 (UTC)[返信]

文字の色

複数の問題等の除去

はじめましてみなさん。今回革新的な提案をさせていただきます。記事に問題がある場合、{{複数の問題}}関連のテンプレートが貼り付けられます。これはどんな記事であっても同じでたとえ存命人物の記事であってもその記事とその状態にあったものが貼り付けられます。今回提案したいのは存命人物の記事において複数の問題関連のテンプレートが問題の解決や除去の提案なしに除去された場合です。通常であれば取り消しや注意、保護で対応しているようです。しかし、除去した利用者がその記事の主題本人であった場合どうでしょう。正直複数の問題等の問題のある記事テンプレートはあまり見栄えのいいものではなく、その内容も読んだ人の気をよくするものではありません。これが自分に関する記事に貼り付けられていたらどう思うでしょう。自分だったら嫌です。誰が読むかわからないものに貼り付けられているわけで、取引先や契約先の人が見た場合活動に影響を及ぼす可能性があります。自分でそのまま除去できるのであれば除去したくなるでしょう。こう考えたときにこれをそのまま取り消すのはどうなのでしょう。特筆性に問題があるのであれば、削除依頼に出して削除することができます。wikifyや脚注の使い方などのその場で修正可能なものは修正することができます。出典不足のものは出典を補うことができます。特筆性に問題がないのであればある程度の出典は追加できるはずです。取り消し以外の対応をするべきではないでしょうか。その除去した方にとっては、勝手に自分のまとめが作られてそれに否定的ともとれるテンプレートが貼ってあったのをとっさに除去しただけなのです。そういった善意の除去に対しては真摯に対応するべきです。ただ取り消していつ除去できるかもわからない状態に戻すのはおかしいです。除去があった際の対応について方針として厳格に定めてはどうでしょう。除去した本人かもしれない利用者をブロックしたり記事を保護して編集を禁止したりするのではなく、除去への対応の方針を守れない利用者の方をブロックするべきです。--おっぱっぴーす会話2020年5月3日 (日) 05:59 (UTC)[返信]

  • コメント 複数の問題関連のテンプレートが、実際にはそのような問題がないのに貼られることもありえます。このような場合は、むしろ「問題の解決や除去の提案なしに除去」してしかるべきものです。--Jkr2255 2020年5月3日 (日) 06:47 (UTC)[返信]

たこ焼きの項目で、謎の広告があることについて

Twitterの書き込みがありたこ焼きの項目に行ったところ、上半分をクリックするとwhite-lightwhite-heatというsoundcloudのページに意図せずに誘導されるようになっているのですが、これはどういうことかわかりますか?--舌先現象になります会話2020年5月4日 (月) 07:00 (UTC)[返信]

Unicodeの文字をリダイレクトとして作成できるか

MediaWiki‐ノート:Common.js/記事名チェッカ#Titleblacklistに移行済みのものの除去の議論にあたって聞きたいことがありますので、こちらにて投稿いたします。

  • ここで検討したいのは(漢字以外の)Unicode一文字をリダイレクトとして作成する場合です。下記に例をいくつか挙げます。
    • は過去に機種依存文字を含むリダイレクトが即時削除の対象だったときに削除されたことがありますが、現在は当該条項が廃止されており、即時削除の対象に該当しません。
    • は「『文字そのものについての記事』として、WP:NCの例外」という要約で株式会社 (日本)へのリダイレクトとして作成されています(恥ずかしながら、わたしが数年前に作成したものであり、今だと作成する前にコミュニティに相談しただろうと思います)。
    • Wikipedia:リダイレクト#正式名称に記事名に使えない文字が含まれる場合に該当します。
  • Wikipedia:記事名の付け方#記事名に使用できる文字では一般の記事名においてJIS X 0201とJIS X 0208にない文字を使用しないことが規定されており、その例外として(漢字を除く)文字そのものについての記事はUnicodeの基本多言語面にある文字を使用できます(基本多言語面にない文字は別の議論があり、ここでは検討しません)。
  • MediaWiki:Common.js/titleChecker.js(記事名チェッカ)においては「ローマ数字を含んでいます」「丸数字を含んでいます」「組文字を含んでいます」という3種類の警告があり、いずれも機種依存文字を理由としています。
  • 他言語版をみると、英語版と中国語版にはen:Template:R from Unicode characterというテンプレートがあり、このようなリダイレクトが許容されています。それ以外の言語版でもfr:✆のようなリダイレクトは存在しますが、専用のテンプレートがある英語版と中国語版と比べて数がかなり少なくなっています。
  • ここからはわたしの意見です。Unicodeの1文字をリダイレクトとして作成する場合、「(漢字を除く)文字そのものについて記事」はグレー(「記事」ではないが、文字そのものについてではある)で、「機種依存文字だから削除」は適用しないと思います。「(漢字を除く)特定のUnicode文字について調べたい」という需要はあると思いますので、Unicode一文字のリダイレクトに限って作成を許可してもいいのではないかと思います。この場合、リダイレクト先にその文字についての記述があることが望ましいでしょう。
  • このようなリダイレクトを作成してもいいかについて、ご意見をお聞かせいただければ幸いです(あるいは、当方のほうで方針・ガイドラインの見落としがある場合でも教えていただければ幸いです)。--ネイ会話2020年5月4日 (月) 16:22 (UTC)[返信]
コメント ウィキペディアのテキストコンテンツはUTF-8でエンコードされているので、「①」「㈱」「Ⓐ」については機種依存文字とはいえないでしょう。似たような話題として、丸数字#文字としての丸数字には以下の記述があります(出典が付いていませんが)。

丸数字はJIS X 0208では規定されておらず、WindowsとMacintoshで実装されているものの、それぞれ別の符号位置であるため、機種依存文字として情報交換で使用するには不適切であるとされることが多かったが、JIS X 0213ではJIS規格に含まれるようになったため、コード名を正しく提示する限りにおいて、機種依存文字として不適切視しない考え方も徐々に増えている。

そもそもブラウザがUTF-8でエンコードされていると解釈しなければ日本語版ウィキペディアの記事はまともに読めないはずです。例えばエンコーディングが正しくはUTF-8なのに誤ってShift_JISと解釈した場合、上のネイさんのコメントの1行目
MediaWiki‐ノート:Common.js/記事名チェッカ#Titleblacklistに移行済みのものの除去の議論にあたって聞きたいことがありますので、こちらにて投稿いたします。
MediaWiki窶舌ヮ繝シ繝・Common.js/險倅コ句錐繝√ぉ繝・き#Titleblacklist縺ォ遘サ陦梧ク医∩縺ョ繧ゅ・縺ョ髯、蜴サ縺ョ隴ー隲悶↓縺ゅ◆縺」縺ヲ閨槭″縺溘>縺薙→縺後≠繧翫∪縺吶・縺ァ縲√%縺。繧峨↓縺ヲ謚慕ィソ縺・◆縺励∪縺吶€・
と表示されます(手元のテキストエディタで確認しました)。
したがって「①」「㈱」「Ⓐ」のようなものであればタイトル中にいくつ含んでいようがWikipedia:リダイレクト#リダイレクト作成の基準に照らし合わせて有用なのであればリダイレクトとして作成していいと思います。
Wikipedia:記事名の付け方#記事名に使用できる文字にある「文字(漢字を除く)そのものについての記事」というのはאのようなものを指しており、ネイさんが作成されたのようなリダイレクトは該当しないと思われます。--本日晴天会話2020年5月5日 (火) 04:26 (UTC)[返信]
コメント 絵文字(emoji)についてはどうお考えでしょうか。個人的な意見としましては、「💩」→うんこマークのように、絵文字そのものの記事へのリダイレクトを作ることには賛成しますが、「🚀」→ロケットのように、絵文字が指し示す物事の記事へのリダイレクトを作ることに対しては悩む所です。積極的には作る必要がない気もいたしますが、本題の記事内に絵文字の説明が過度に展開されるよりは良い、という考え方もできますし、英語版では「en:🚀」→en:Rocketなど、絵文字→指し示す物事の記事へのリダイレクトが作られておりました。--茶でもすするか会話2020年5月6日 (水) 13:16 (UTC)[返信]
そんなに難しく考えず、「その単語(あるいは文字)で検索・リンクされることが予想されるか」という観点で考えれば良いと思います。ロケットについて調べたい人が「🚀」で検索するでしょうか?これは技術的な問題というよりかは、運用上の問題です。 片割れ靴下会話2020年5月6日 (水) 20:13 (UTC)[返信]
片割れ靴下さんがご提示された観点で考えますと、ロケットについて調べたい人がいきなり「🚀」で検索することはおそらく無いと思われますが、「🚀」が何を示す絵文字であるかを検索することはありそうです。--茶でもすするか会話2020年5月9日 (土) 05:31 (UTC)[返信]
コメント 文字自体の意味を調べたい場合はウィクショナリーでしょうね。すでにWikt:🚀があります。🚀が登録された経緯、各ブラウザにおける対応状況などを解説するならウィキペディアが妥当だと思いますが。--Monaneko会話2020年5月9日 (土) 06:31 (UTC)[返信]
絵文字1文字のリダイレクトについてはちょっと迷うところもありますが、転送先の記事の性質で決めればいいかと思います。転送先が絵文字そのものの記事(うんこマーク(en:Pile of Poo emoji)については英語版ではemojiの1つと定義しているが、日本語版の記事の定義文では絵文字ではなくあくまで「マーク」としているゆえ、今のところ日本語版には1つも存在しない?)であればリダイレクトの作成に強く賛成します。温泉マークハート (シンボル)のようなマークやシンボルについての記事を転送先とする場合もリダイレクトを作成した方がいいでしょう。それ以外の一般名詞(ロケットなど)を転送先として作成するのは有用性および一意性の観点から控えた方がいいかもしれません。一人や二人程度の意見を基に絵文字と転送先のリストを作り、それをWikipedia:Bot作業依頼に持ち込んで「この通りにリダイレクトを作って」と言われても、私だったら合意不十分とみなしてすぐには着手しないでしょう。--本日晴天会話2020年5月9日 (土) 12:07 (UTC)[返信]

「☠︎」(U+2620)を検索していて気が付いたのですが、現行では異体字セレクタをページ名に含めることができるようです。異体字セレクタなしのノート / 履歴 / ログ / リンク元ハザードシンボルへのリダイレクトですが、絵文字スタイルであることを示すU+FE0Fを後ろに付けた☠️ノート / 履歴 / ログ / リンク元髑髏と骨へのリダイレクトになっています。(私のPCでは)見た目で区別がつかないのに、ページを別々に作られてしまうと非常に紛らわしいです。異体字セレクタはページ名に使わないなどの対策を取った方がいいように思います。--本日晴天会話2020年5月9日 (土) 12:07 (UTC)[返信]

報告 当該記事については {{混同}} を用いて案内を追加しました。--Semi-Brace会話2020年5月15日 (金) 15:25 (UTC)[返信]

井戸端名前空間の提案

先日、Wikipedia:井戸端/subj/名前空間と統計について#井戸端についてにて、股志さんより「井戸端」名前空間を作成する提案がなされました。

その際は本格的な提案に向けた事前議論のような形になったのですが、名前空間の新設という非常に大掛かりな提案となるため、最初の提案者の股志さんに代わって新たに議論の場を作成させていただきました。

ここで、井戸端名前空間を作成した場合の利点を、再度提示させていただきます。

  • H:NS#Wikipedia名前空間には「ウィキペディアのルール、公表文書など、ウィキペディア自身についての情報を記述したページをおく」とあり、そもそも少し目的が違うので、名前空間を分けることではっきりと区別することができる。
  • 井戸端に限定した技術的な設定が可能・容易になる(のではないかと思います)。
  • Wikipedia:井戸端/subj/(ページ名)となっていたのが井戸端:subj/(ページ名)となり、ページ名が短縮される。

よろしくお願いいたします。--Atmark-chan </稿> 2020年5月6日 (水) 12:40 (UTC)[返信]

  • 反対  反対します。他言語版でも井戸端にあたるものはen:Wikipedia:Village_pumpなど、ほぼWikipedia名前空間にあるかと思います。もし日本語版だけ別の空間に置くとすると、混乱するかと思います。--さえぼー会話2020年5月6日 (水) 12:48 (UTC)[返信]
  • コメント うーん・・・拡張半保護でさえ導入までにかなり時間がかかりました。拡張半保護は英語版などで既に導入されていたのに、です。他言語版にないものを追加するのはかなり労力を要し、それに見合うだけの効果があるのだろうか、と・・・
    • Wikipedia:保護依頼Wikipedia:投稿ブロック依頼とか、RFA、コメント依頼。Wikipedia名前空間にあるのに「ウィキペディアのルール、公表文書など、ウィキペディア自身についての情報を記述」以外の目的で使われているものは数多くありますし、それらで特段問題が生じているとも思いません。
    • 二点目は、えっと、すみません、どういうことでしょうか?どういう「技術的な」設定が必要なのか、ご説明いただければと思います。
    • ページ名はsubjを抜いても構わないと思います。つまり、Special:Diff/77344937で仰った構造から、subjがついているものをなくして、[[Wikipedia:井戸端/サブページ名]]とする。で、他のものを移動。例えば[[Wikipedia:井戸端/Template:○○]][[Wikipedia:井戸端××/Template:○○]]。この形ならWikipedia:井戸端/から始まるページで検索すれば済むのでは?
この提案によるメリットは確かに一つ一つはなるほどな、と思うものもありますが、労力に見合うものか、と問われると疑問です。今のところは反対、とも言いませんが・・・--Q8j会話) 2020年5月6日 (水) 13:51 (UTC)修正。割と間違えた・・・みにくくなるのでdel、insは引きません。履歴からご確認ください--Q8j会話2020年5月6日 (水) 13:54 (UTC)[返信]
コメント 確かに労力に見合うことか、と言われるとそこは課題だと思います。が、あえて現時点では提案は取り下げず、もう少し意見を待ってみようと思います。--Atmark-chan </稿> 2020年5月6日 (水) 14:46 (UTC)[返信]
コメント 賛否ないのですけど情報として。最も直近で新設されたカスタム名前空間であるウィキプロジェクトの時を思い出すと、頻繁にリンクされる割には長いというのと、検索など各種特別ページでウィキプロジェクトに限定した機能を使いたいという需要があったことが名前空間の新設に至った大きな理由だと思います。よく参照されるenwikiにはウィキプロジェクト名前空間ありませんが、frwikiなどにあったので他言語版での前例もあったと言えます。議論や手続きをすすめるなら(bugzillaがphablicatorになってるとか些細な違いはありますが)、基本的にはあの時と同じように進めれば良いと思います(逆に言えば、最低でもあれぐらい手間はかかるということです)。--青子守歌会話/履歴 2020年5月6日 (水) 15:11 (UTC)[返信]
  • 質問 Wikipedia:お知らせWikipedia:利用案内Wikipedia:調べもの案内Wikipedia:バグの報告Wikipedia:表示改善依頼なども「Wikipedia名前空間」にあります。また他のプロジェクトで井戸端に相当するページを見ても井戸端専用の名前空間になっている例を知りません。何故ウィキペディア日本語版の井戸端だけを別の名前空間にしようと思ったのでしょうか?--aki42006会話) 2020年5月6日 (水) 23:41 (UTC)他のプロジェクトで相当するページ名は「談話室」など様々なので修正--aki42006会話2020年5月7日 (木) 00:15 (UTC)[返信]
  • コメント コメント (反対より) 多言語版にあるとかないとかは正直どっちでもいいのですが(そんなにも多言語版に似せたいのか?という感じになってしまう)、Wikipedia:井戸端/subj/名前空間と統計についてでも申しました通り、それによってどれだけの成果が得られるか考えると、新しい名前空間を作る労力のほうが勝ってしまうと思います。また、股志さんの挙げておられた問題の中には名前空間を新設したところでどうにもならぬものもあり、そういったものを除くと、利益はあまりないかと思います。--Tmv会話|投稿記録2020年5月6日 (水) 23:59 (UTC)[返信]
    • コメント
      確かに後の3つは元々のWikipedia名前空間の用途からは外れているかもしれませんが、前の2つは「ウィキペディア自身についての情報を記述したページ」に当てはまります。第一、井戸端と比較してサブページ数は大きく異なる(というより桁が2つくらい違う)と思います。近く、それらのWikipedia名前空間のページ数、及び既存の他名前空間のページ数との比較を表にしたいと思います。--Atmark-chan </稿> 2020年5月7日 (木) 00:53 (UTC)[返信]
      • 他言語版との比較:
      Tmvさんの仰るとおり、他言語版に似せる意図は特にないと思います。それに、ページを移動したら、ウィキデータのほうも勝手に変わるはずですし、Wikipedia:井戸端以下の各サブページに関しては、他言語版と連携する必要もありません。仮に他言語版の利用者が誤ってWikipedia:井戸端にアクセスしても、リダイレクトで新しいページに飛ばされるだけです。私としては、むしろ日本語版が井戸端名前空間を作る前例になっても良いのではないかといった感じです。
      • 労力と成果の比較:
      労力の感じ方は、正直なところ人それぞれなので(無論、私が井戸端名前空間の新設に労力を感じないわけではありません)、労力と成果の比較はそもそも難しいことだと思います。
      • 股志さんの挙げておられた問題について:
      たぶん「ページ名に『subj』が常に入るので、長くなりがち」のことを仰っているのだと思います。名前空間を新設することで直接解決には至らないのはその通りですが、ある程度の改善はあります。あと、名前空間を移すのと同時に「井戸端:」直下にしてしまえば良いのではないでしょうか。
      Wikipedia:井戸端/subj/(ページ名)
      井戸端:(ページ名)
      と並べてみれば、短くなるのは一目瞭然です。
      • あと、最後にもうひとつ。青子守歌さんの発言で、今回のケースにも言えることを引用させていただきます。
        名前空間を分離することで、特別:最近の更新などいくつかの特別ページで「名前空間を限定して」の機能を使うことができるようになり、本来のプロジェクト文書(方針やガイドラインなど)とは切り離して利用することもできるようになります。 — 青子守歌さん、プロジェクト名前空間新設の際の議論、2010年4月18日 (日) 07:29 (UTC)
    --Atmark-chan </稿> 2020年5月7日 (木) 00:53 (UTC) 敬称が抜けておりました。大変失礼いたしました。--Atmark-chan </稿> 2020年5月7日 (木) 12:42 (UTC)[返信]
    コメント 「議論の場所がノートと分散していて分かりにくい」ということについても井戸端名前空間を作ったところで改善できるとは思えませんよ(まあ井戸端・ノート名前空間をわざわざ作らないようにすればこの問題が解決できるかもしれませんが、井戸端についての議論を井戸端でやるのはいいとして井戸端で議論されていることについての議論を別の井戸端名前空間で行うのは少し変だと思います)。いちよう井戸端ページとそのノートは役割が分かれていますが、初心者の方などにはその2つの違いは分かりにくいかも知れません。--Tmv会話|投稿記録2020年5月7日 (木) 01:12 (UTC)[返信]
    コメント 井戸端・ノート名前空間を作らないのも考えられることのひとつではありますが、それでは既存の「Wikipedia‐ノート:井戸端/…」の行き先がなくなってしまいます。初心者の方などに分かりにくいのであれば、井戸端についての解説ページを作るというのはいかがでしょうか(ページ名は「井戸端:ヘルプ」なんかが適当ですかね)。--Atmark-chan </稿> 2020年5月7日 (木) 01:40 (UTC)[返信]
    あと、ひとつ気づいたのが、Wikipedia:井戸端の行き先です。「井戸端:」は無理なので、「井戸端:トップ」「井戸端:トップページ」などが良いでしょうか。--Atmark-chan </稿> 2020年5月7日 (木) 01:40 (UTC)[返信]
    コメント ping飛んできたので一言だけ書いておくと、上記の私の当時のコメントは私は今回は当てはまってないと思います。少なくとも「最近の更新」は、井戸端のsubj以下サブページは全部カテゴリに入っているので、特別:関連ページの更新状況/Category:井戸端の話題で確認できます(ウィキプロジェクトのページはカテゴリに入っていないこともあるので無理でした)。--青子守歌会話/履歴 2020年5月7日 (木) 11:58 (UTC)[返信]
    返信 (青子守歌さん宛) 「最近の更新」に関してはそうかもしれませんが、「いくつかの特別ページで『名前空間を限定して』の機能を使うことができる」こと、「本来のプロジェクト文書(方針やガイドラインなど)とは切り離して利用することもできる」ことは今回のケースにも言えることだと思います(特に後者)。
    それと、2020年5月7日 (木) 00:53 (UTC) の私の発言において、青子守歌さんのお名前に敬称が付いていない部分がございました。大変失礼いたしました。
    特別:関連ページの更新状況については、存在を知りませんでした。教えていただきありがとうございます。今後の参考に致します。--Atmark-chan </稿> 2020年5月7日 (木) 12:42 (UTC)[返信]
  • ここにあったコメントは無関係なのでノートに転記しました。--Q8j会話2020年5月7日 (木) 11:29 (UTC)[返信]
    コメント なんかどんどん議論場所が広がっていってよくわからなくなってきてしまいました。議論が行われているのはこのページ及びそのノート、さらにWikipedia‐ノート:井戸端/ヘルプということでいいですか?まず、Wikipedia:井戸端/ヘルプ(または井戸端:ヘルプ)を導入するか議論をしていった方が良いと思います。それについてはWikipedia‐ノート:井戸端/ヘルプで議論されているようですので後程そちらにコメントします。井戸端名前空間についてですが、私は今も反対寄りな気持ちです。反対、とはっきりとは言いませんが新しい名前空間の新設によってもたらされる利益が本当に新名前空間を作るに値するほどあるのかどうか、未だにはっきりしていない為です。数については大げさに言うと標準名前空間にゲームの記事が多いからゲームという名前空間を作ってしまおう的なそんな感じの理由みたいで、少し解せぬところがあります(数が多いからというのはあまり新名前空間を設ける理由にならないのでは、と)。そういうところがまだあまり納得のいく(つまり「ああ、それなら新しい名前空間を作った方が良い!」)感じになっていない気がいたします。--Tmv会話|投稿記録2020年5月9日 (土) 01:25 (UTC)[返信]
     追記 Wikipedia:井戸端/subj/名前空間と統計についてでの議論も一様ありましたね。--Tmv会話|投稿記録2020年5月9日 (土) 01:30 (UTC)[返信]
    報告 Wikipedia‐ノート:井戸端/ヘルプで長文ですがこちらにもかなり関連することをコメントいたしました。できればご意見いただけると嬉しいです。--Tmv会話|投稿記録2020年5月9日 (土) 01:53 (UTC)[返信]
    コメント ページ数についてですが、それはあくまで補足のようなもので、メインの理由ではありません。ただ「ページ数を見ると一つの名前空間として十分に成立します」というだけで。--Atmark-chan </稿> 2020年5月9日 (土) 10:34 (UTC)[返信]
  • 情報 Template‐ノート:井戸端#井戸端のヘッダ変更の提案で井戸端のヘッダの改変も提案されています。併せてごらんください。--Tmv会話|投稿記録2020年5月10日 (日) 02:04 (UTC)[返信]
  • 上で井戸端のホームの行先について少し議論が出ていますが、まずは井戸端名前空間を作るかどうかについて議論したいと思います。できれば、もう少しいろいろな人の意見が聞きたいところではありますが、もしこのまま意見が出なかった場合、井戸端名前空間を新設するのは厳しいのではないでしょうか。--Tmv会話|投稿記録2020年5月10日 (日) 02:32 (UTC)[返信]
  • 反対 井戸端に限定した検索や井戸端サブページへのリンクがちょっとだけ楽になる……という程度なので、もはや「気持ちの問題」かと。Help:名前空間での解説に合致しないという点は、すでに指摘されているとおり他にも同様の議論ページは多数ありますので的はずれです。該当の記述を「ウィキペディアのルール、ウィキペディア自身についての情報を記述したページ、ウィキペディア運用のための議論や告知などをおくのに使用されます。」と修正しておきました[10]。--Hisagi会話2020年5月10日 (日) 10:40 (UTC)[返信]
  • コメント 前の議論でもコメントしましたが、矛盾点を解消できる点(井戸端はどちらかというと議論に分けられる)では、いいと思います。また余談となりますが、井戸端の内容は、全てサブページ化が行われており、最大30日間は読み込みがされていますが、読み込みされている話題の履歴やページ情報などを閲覧したい際に、節単位の「編集」を経由しないと見れないのが不便だなと感じたことがあります。Atmark-chanさんがおっしゃっている、「名前空間別の技術的な設定」を活用することができるかと思います。--Mario1257会話2020年5月14日 (木) 13:54 (UTC)[返信]
    • 質問 (Mario1257さん宛) 1つ質問させてください。井戸端が議論に分けられるのにそのノートがあるという矛盾点が解消できるとおっしゃられていますが、井戸端名前空間を作っても井戸端・ノート名前空間もできますから、結局その問題は解消されないと思います。矛盾点が解消できるとは、具体的にどのようにしてでしょうか?--Tmv会話|投稿記録2020年5月15日 (金) 00:07 (UTC)[返信]
      • 返信 (Tmvさん宛) 「井戸端‐ノート:」についてですが、付随させなければいいのではないでしょうか。ノートに該当する部分は、全て下位ページに置けばいいのではないかと思います。既存のノートページは、「(Wikipedia名前空間での記事<話題>名)/note」等に移動させればいいのではないでしょうか。--Mario1257会話2020年5月16日 (土) 14:19 (UTC)[返信]
        • コメント 確かにノート名前空間を作成しないよう設定すればいいですね。もし井戸端名前空間を作るのであれば現在のノートについては「/ノート」(英語ではなく日本語)に移動した方が良いと思います。ここは日本語版なので。ただ新しく名前空間を作るのには労力がかかりますし、労力は人によって違うとは言えども少ない労力での新規名前空間作成は厳しいものと思います。もしその点の問題を克服できる(あるいは少しでもましにできる)方法があるのであれば私は新規名前空間作成に賛成します。--Tmv会話|投稿記録2020年5月17日 (日) 03:06 (UTC)[返信]
        • 賛成 ノート名前空間を付随させないことに賛成いたします。「/note」「/ノート」などの名称については、特にどちらでも構わないと思います。
        最初は、
        1. ノート上での[[/hoge]]のようなリンク
        2. {{SUBJECTPAGENAME}}{{ARTICLEPAGENAME}}{{TALKPAGENAME}}
        で不都合が起きるのではないかと思ったのですが、そのようなパターンを検索したところ(1.2.)数件しかヒットせず、リンク修正にあまり手間はかからなさそうです。--Atmark-chan </稿> 2020年5月17日 (日) 03:42 (UTC) 誤解を招く表現の明確化ほか--Atmark-chan </稿> 2020年5月17日 (日) 03:44 (UTC)[返信]
  • コメント プロジェクト名前空間の時のことで1つ思い出したので追加で。あの時は別の事情からショートカットが先に作られていたので、その対になるものとして名前空間もというのが自然な考え方で受け入れられたという経緯もありました(とはいえ、一方でLTA名前空間があるわけではないですが)。というようなことを考えると、方法論や進め方はともかく、今回の井戸端名前区間(?)で、名前空間新設の理由を同じように引っ張ってくるのは無理筋なんじゃないかなという気がしますね。まぁそもそも合意形成できそうな雰囲気はないのでもう諦められたのかなとは察しますが・・・。--青子守歌会話/履歴 2020年5月18日 (月) 01:18 (UTC)[返信]
  • コメント う~ん… 井戸端名前空間を作ることにより、より分かりやすく・便利になるかと思いましたが、今回、合意形成に至らず厳しそうですね。--股志会話2020年5月30日 (土) 07:45 (UTC)[返信]

井戸端:ヘルプ(仮称)について

報告 Q8jさんのご指摘がありましたので、Wikipedia‐ノート:井戸端/ヘルプへ転記いたしました。--Atmark-chan </稿> 2020年5月7日 (木) 12:32 (UTC)[返信]

関連ページの更新情報について

報告 長くなりそうなので、「Wikipedia:井戸端/subj/関連ページの更新情報について」へ分割しました。--Mario1257会話2020年5月27日 (水) 18:19 (UTC)[返信]

オリンピックマルセイユの記事について

スマホ版でマルセイユの記事を見ると、折りたたみ機能(?)が使えない状態です。というのも、そもそも折りたたみ機能がついてない所もあれば、歴代所属メンバーのところの折りたたみ機能が全く意味のないものになっていたり、空白ができてしまっているという状況です。--Zessded会話2020年5月7日 (木) 14:27 (UTC)[返信]

  • コメント オリンピック・マルセイユの記事のことでしょうか。MediaWikiで提供しているの機能での折り畳みは、主にパソコン向けブラウザで動作するもので、モバイルビューでは折り畳みが無効になります。Template:Hiddenの注意事項も併せて確認してください。また、当該記事で表の機能として折り畳みが指定されているのはアウェーとサードのユニホームに対してであり、選手一覧については元々指定されていません。デスクトップからのモバイルビュー(Windows10/Firefox76.0)では問題ありませんので、お使いのブラウザアプリ特有の問題の可能性もあります。システム面での修正が必要と考えられる場合はWikipedia:バグの報告へ利用環境等を添えて報告してください。--アルトクール会話2020年5月8日 (金) 11:55 (UTC)[返信]
コメントアルトクールさんは質問内容を誤解していませんか?Zessdedさんが言ってるのは、表の折り畳みではなく、モバイルビューでの節の折り畳み機能(すべての記事で動作する節のタイトルをクリックすれば節を折りたたむことができる機能)が動作していないという問題だと思います。これはおそらくユニフォームのとこで画像をいっぱい使ってるからです。Wikipedia:井戸端/subj/山手線と京浜東北線のページをスマートフォンで見ると折り畳まれない件についてを見てください。--Takayasu会話2020年5月19日 (火) 02:59 (UTC)[返信]

Category名前空間における「カテゴリー」表記

かなりどうでもいい話なのですが、Category名前空間内で「~に関するカテゴリー。」のように長音をつけた表記が散見されます(簡単な検索で1837件Help:カテゴリにも一か所「カテゴリー」表記があるようです)。ほぼ定型があるカテゴリの文章としては「カテゴリ」表記で統一した方が良いのでは。--McYata会話2020年5月7日 (木) 15:14 (UTC)[返信]

1837件も修正するの大変なのでは?—TRAMPJP会話2020年5月7日 (木) 15:19 (UTC)[返信]

数は膨大ですが、bot作業依頼に出せばそこまで面倒ごとにはならないと思います。カテゴリ名で使っているこちらの9件を除けば、Category名前空間内で「カテゴリー」と書かなければいけない理由がある場所は無いのではないでしょうか。--McYata会話2020年5月7日 (木) 15:37 (UTC)[返信]
修正可能であれば揃えてあげる方が良いですね。修正に賛成です!—TRAMPJP会話2020年5月7日 (木) 16:04 (UTC)[返信]
報告 カテゴリ名で使っている「Category:文法カテゴリー」については、カテゴリ名を親記事に合わせるという理由で改名提案を提出しました(改名先は「Category:文法範疇」)。McYataさんのご提案には影響しないと思いますが、一応ご報告まで。--ネイ会話2020年5月8日 (金) 04:02 (UTC)[返信]
コメント どちらでも良いですが、外来語カタカナの長音符有無の表記揺れは、基本「つける」方が現在の傾向です(カテゴリーは「イ列」で終わるタイプで、Help:カテゴリ等がありますが、長期的な話として)。--Rabit gti会話2020年5月8日 (金) 09:45 (UTC)[返信]
横から失礼 横から失礼 基本つけるのが現在の傾向のようですけれども、日本語版Wikipediaでは「カテゴリ」の方がなじみもありますし、カテゴリで検索すると200件以上ヒットします(なお、[11]で分かるように500件以上はあるようです(当該ページは少し重いのでご注意を))。隠しカテゴリとは言いますが隠しカテゴリーというのはあまり耳にしませんし、カテゴリでいいのでは?--Tmv会話|投稿記録2020年5月10日 (日) 02:41 (UTC)[返信]
コメント Tmvさんの示して頂いた検索ページのヒット数を見ると、Category名前空間で「カテゴリ」表記を使っているページは208,724件あるようですね。方針文書や各種テンプレートなどでも原則「カテゴリ」となっており、日本語版の慣用として根付いていますし、これを今からすべてひっくり返すのはさすがに無理があるように思います。統一することを前提とすると、たしかに「カテゴリー」表記の方が時流に合っているのかもしれませんが、「カテゴリ」でも許容範囲なのでは。--McYata会話2020年5月11日 (月) 07:59 (UTC)[返信]
コメント 蛇足ながら、私は不統一は良くないと思いますが、統一先はどちらでも反対しません。ウィキペディア日本語版では、立ち上げ時に当時の古典的なコンピュータ用語表記(JIS用語集など、特に国産・電電各社)を使うユーザーが支配的だったからと思います。ただ(記事名のガイドですが)「日本語話者の大多数にとって、最も曖昧でなく、最も理解しやすいもの」は現在では長音ありかと[12][13][14][15][16]。長音なしは消滅傾向のため、今回片方に統一後、将来長音ありに再検討でも良いかと。(ウィキペディアでは完全統一は困難。ところで「Category:ユーザー」や記事ユーザーは長音ありで、各ガイド中の表記も分かれていますね)--Rabit gti会話2020年5月11日 (月) 09:52 (UTC)[返信]
すみません、長らく放置してしまいました。統一したほうが良いという点では皆様一致しており、またRabit gtiさんも暫定的に「カテゴリ」にまとめることは認めてくださっているということですね。「カテゴリ」に統一するなら現在の日本語版の慣例に合わせるだけですが、「カテゴリー」に統一するとなれば日本語版全体に影響が出て各種方針も見直さなければならないため、改めて大々的に議論される場を設け「Wikipediaの用語は時勢に合わせ長音ありを原則とする」、というようなルールを新規に作るなどしてから移行するべきかと思います。ということで、1週間後をめどに上で提案した通りの変更をbot作業依頼に提出しようと思うのですが、いかがでしょうか。--McYata会話2020年5月29日 (金) 00:54 (UTC)[返信]
報告 Wikipedia:Bot作業依頼#Category名前空間内でのカテゴリ表記統一を提出しました。--McYata会話2020年6月5日 (金) 01:22 (UTC)[返信]
報告 botによる修正が終了しました。ありがとうございました。--McYata会話2020年6月5日 (金) 13:26 (UTC)[返信]

有名人の出身地について

明日花キララの出身地が記載の内容と出典としている内容が異なります。 ウィキペディア記載の内容の方が正しそうなのですが出典ふくめ公式ブログでは東京都となっています。 また、「本人が積極的に公開していないと思われる事項の記述」で前回削除されているようでした。(出身地についてかどうかはわかりません)

本人が出演している動画(ttps://youtu.be/STscIv4pTBg?t=380 6分20秒あたり)では、隠してはいないものの積極的に出身を公にしていない旨の発言をしています。 このような場合どうすればよいですか?東京になおしてもいいですか? --240B:253:2A60:3A00:B970:CC4:8858:8FD7 2020年5月8日 (金) 05:05 (UTC)[返信]

WP:NCにおけるJIS X 0208規定の撤廃について

Wikipedia:記事名の付け方においては、「一般の記事名で使用できる文字」について「JIS X 0201のラテン文字類」および「罫線素片・私用領域の文字(いわゆる外字)を除いたJIS X 0208で規定されている文字」となっています。この規定が定められた当時はUnicodeに対応していないWindows 98/MeMac OS 9といった古いOSや、フィーチャーフォン(俗にいうガラケー)が多数使用されていたゆえにこのように定められたものと思われます。しかし2020年現在前者はとうの昔にサポートを終了し、利用者もほとんどいないと思われます。後者もその数を近年大きく減らしています。したがってこの規定を撤廃し、Unicode文字を通常の記事名に使用できるようにする時期が来ていると考えますが、いかがでしょうか?--Schwei2会話2020年5月8日 (金) 11:56 (UTC)[返信]

賛成 基本的に賛成です。草なぎ剛(草彅剛)、朴ロ美(朴璐美)のような混ぜ書き、高梨沙羅(髙梨沙羅)、種崎敦美(種﨑敦美)、吉田恵輔(𠮷田恵輔)、BOOWY(BOØWY)のような代え字を避けることが可能になります。ただ、完全撤廃すると妥当性があれば絵文字でも何でもありになります。😀(スマイル)は出る環境が多いと思いますが、たとえば🦧️(オランウータン)はやや古いスマホでは出ないかもしれません。いまのところ芸名やグループ名に絵文字が入った方は知らないですが。--Monaneko会話2020年5月8日 (金) 13:36 (UTC)[返信]
朝h偽新聞でも表記ゆれが起き始めているようです。例えば「『新しい地図』が基金設立 コロナ対策に3千万円を拠出」では、「草剛」表記で、「『新しい地図』基金、医療従事者らを支援 3千万円拠出、寄付も募集」では、「草なぎ剛」表記が使われています。大手メディアは、正しい文字が表示さえない環境に対する配慮が通常のウェブサイトよりも高いと思いますが、それでも「彅」表記が許容され始めているのだということだと思います。もはや、このような配慮は単なるお節介の意味を出ないものとなっていることから概ね同意いたします。
一方で、Monanekoさんが仰っている通り、一部の新しい文字については文字コードが割り当てられている一方でフォントが用意されていないがゆえに、文字が表示できないという事例もあります。皆さんの環境はわかりませんが、私の環境では、ビャンビャン麺の冒頭部が正しく表示されず、パソコンのブラウザで見ると四角い箱のようなものが表示され、iPhoneでは文字があることすらわからなくなっています。
ビャンビャン麺𰻞𰻞麺、ビャンビャンめん、中国語: 𰻞𰻞)は中国陝西省で一般的な幅広の
中国版ウィキペディアでは、新しく割り当てられた文字コードを使った記事名に移動している(𰻝𰻝面)ことから、iPhoneで見ると「」という記事と同じ記事として表示されています。そのため、使用できる文字を拡大するのであれば、文字が割り当てられてからX年が経過している、主要なフォントがサポートしているなどの条件に従って、使える文字の一覧のようなものを策定して、その中で記事名を付けるといった対応が必要だと思います。 片割れ靴下会話2020年5月8日 (金) 14:04 (UTC)[返信]