Wikipedia:井戸端

ナビゲーションに移動 検索に移動
Balcón del Mediterráneo, Benidorm, España, 2014-07-02, DD 21.JPG
相談と質問
井戸端
利用案内
調べもの案内
執筆・翻訳者の広場
For Non-Japanese Speakers

井戸端は、Wikipedia日本語版について、運営、方針、新しいアイディアや作業の仕方、その他様々な事で質問や提案、議論、意見交換を行う場所です。詳しくは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:お知らせ.


ここに質問を投稿する前に
  • 下記の過去ログ検索機能にて、既に似た質問がないか質問前にご確認ください。
  • よくある質問(FAQ)もご確認ください。なお、この井戸端で頻繁にされている質問があれば、それをFAQに追加するよう、提案してください
  • ウィキペディア日本語版やウィキメディア・プロジェクトと関係のない話題を投稿するのはご遠慮ください。
  • 以下に当てはまるものは井戸端よりも適切な場所があるので、そちらにお願いします:
以前の議論を検索する
投稿しましょう

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

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

これですね。Wikipedia wordmark.svg英語バージョンも含めコモンズなども変わっています。いつか慣れますよ。--おかしなペディアン会話) 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)
「ベースライン」は(横書きの)日本語に適用することもありますが、異論もあるようです[1]。 --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)

文字の色[編集]

  • 少し時間をおきましたが、やはり文字の色は変更前の方が自然な感じがします。以前の色現在の色を比べると分かるように、左側のメニューバーの色はネズミ色のままです。そのため、不釣り合いな状態となっており、統一感がないのです。--126.247.84.18 2020年5月4日 (月) 06:50 (UTC)
  • 今になって気付いたのですが、モバイル版の履歴に表示される編集者のアイコンの色もネズミ色から黒色に変わっていますね。--126.152.206.249 2020年5月4日 (月) 17:03 (UTC)
  • コメント うーん、私も灰色の方がなんか見やすい気がしますね。わざとこうやったのでしょうか……。修正してほしいものですが……。--Tmv会話|投稿記録) 2020年5月6日 (水) 06:15 (UTC)
  • 何やら新しいフォントのままで色がネズミ色に戻っていますね。よくわかりませんが、めでたしめでたし?--126.35.158.223 2020年5月31日 (日) 03:29 (UTC)
  • いや、モバイル版には上下にウィキペディアの文字が表示されるのですが、よく見たら上の方はネズミ色に戻っているのに下の方は黒色のままですね…。不釣り合いなのはおかしいので、ネズミ色ならネズミ色に統一してほしいものですが…。--126.35.158.223 2020年5月31日 (日) 04:35 (UTC)
    • 横から失礼 横から失礼 確かに上はネズミ色に統一されているのに対し、下だけ黒色となっています。不自然ですね。
    両方この画像を使用していますが、上部の画像(の親要素のdiv)のopacity0.66となっているようで、これで(見かけ上)薄く見せているようです(先ほど試しに開発者ツールからopacity1(透明度ゼロ)にしてみたところ分かりました)。--Atmark-chan </稿> 2020年5月31日 (日) 09:07 (UTC) 修正--Atmark-chan </稿> 2020年5月31日 (日) 09:17 (UTC)
    Symbol comment vote.svg 追記 あ、これはどうやら日本語版だけの話ではないようですね。ざっと確認してみたところ、enでもdeでもfrでもそうなっています。これを変えるとなると全言語版に(MediaWikiにも?)影響してきますね…。私の印象では、上下ともネズミ色に統一されているほうが良いように思うのは変わらないのですが。--Atmark-chan </稿> 2020年5月31日 (日) 09:17 (UTC)
    コメント さらに追記 minerva.cssに追加すれば、モバイルでもMinervaNeueスキンでも下部のロゴをネズミ色に変えることができました。ですが、IPのままだと外装の詳細設定が使えないので、アカウントを取得していただくか全体での変更を待っていただくかになると思います…。--Atmark-chan </稿> 2020年5月31日 (日) 09:45 (UTC)
    コメント さっきUser:Tmv/minerva.cssに追加させていただいたのですが、確かにこれだと直りますね。日本語版ウィキペディアはまだMediaWiki:minerva.cssを作っていないようですけど、そこを編集していただくのが一番早い解決策ですかね。--Tmv会話|投稿記録) 2020年6月1日 (月) 00:56 (UTC)
    コメント 個人的に設定をいじって気持ちよく使いたいと言うよりは、大多数の閲覧者の方々に不自然なロゴを見せたくないという思いが強いので、その辺りは何とか直してもらいたいものですね。--126.35.221.150 2020年6月1日 (月) 03:51 (UTC)
    コメント とすると、Minerva.cssで日本語版だけでもそうするか、Phabricator とかに言って全体で直してもらうか、ですかね。--Atmark-chan </稿> 2020年6月1日 (月) 09:48 (UTC)
    情報Phabricatorで発言するにはアカウントを取得する必要があります。 --2001:240:2406:620A:81BB:C1A7:BAD9:B537 2020年6月2日 (火) 06:41 (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)
    Symbol comment vote.svg 追記 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)
    • コメント 意見をお聞きするということであれば、コメント依頼に出してみましょう。--Atmark-chan </稿> 2020年5月10日 (日) 03:09 (UTC)
      • 報告 コメント依頼に出しました。--Atmark-chan </稿> 2020年5月10日 (日) 05:06 (UTC)
  • 反対 井戸端に限定した検索や井戸端サブページへのリンクがちょっとだけ楽になる……という程度なので、もはや「気持ちの問題」かと。Help:名前空間での解説に合致しないという点は、すでに指摘されているとおり他にも同様の議論ページは多数ありますので的はずれです。該当の記述を「ウィキペディアのルール、ウィキペディア自身についての情報を記述したページ、ウィキペディア運用のための議論や告知などをおくのに使用されます。」と修正しておきました[2]。--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)

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)
グループ名に絵文字(というよりJIS X 0208外の文字)が入っている例としてはかつみ・さゆり(かつみ♥さゆり)などがあります。--Schwei2会話) 2020年5月8日 (金) 14:06 (UTC)
朝h偽新聞でも表記ゆれが起き始めているようです。例えば「『新しい地図』が基金設立 コロナ対策に3千万円を拠出」では、「草剛」表記で、「『新しい地図』基金、医療従事者らを支援 3千万円拠出、寄付も募集」では、「草なぎ剛」表記が使われています。大手メディアは、正しい文字が表示さえない環境に対する配慮が通常のウェブサイトよりも高いと思いますが、それでも「彅」表記が許容され始めているのだということだと思います。もはや、このような配慮は単なるお節介の意味を出ないものとなっていることから概ね同意いたします。
一方で、Monanekoさんが仰っている通り、一部の新しい文字については文字コードが割り当てられている一方でフォントが用意されていないがゆえに、文字が表示できないという事例もあります。皆さんの環境はわかりませんが、私の環境では、ビャンビャン麺の冒頭部が正しく表示されず、パソコンのブラウザで見ると四角い箱のようなものが表示され、iPhoneでは文字があることすらわからなくなっています。
ビャンビャン麺𰻞𰻞麺、ビャンビャンめん、中国語: 𰻞𰻞)は中国陝西省で一般的な幅広の
中国版ウィキペディアでは、新しく割り当てられた文字コードを使った記事名に移動している(𰻝𰻝面)ことから、iPhoneで見ると「」という記事と同じ記事として表示されています。そのため、使用できる文字を拡大するのであれば、文字が割り当てられてからX年が経過している、主要なフォントがサポートしているなどの条件に従って、使える文字の一覧のようなものを策定して、その中で記事名を付けるといった対応が必要だと思います。 片割れ靴下会話) 2020年5月8日 (金) 14:04 (UTC)
漢字の場合、原則としてCJK統合漢字および同拡張A、およびCJK互換漢字のうち実際には統合漢字として扱われる12字(﨎、﨏、﨑、﨓、﨔、﨟、﨡、﨣、﨤、﨧、﨨、﨩)は使用してよいでしょう。拡張Bも含めてよいと思いますが、基本多言語面でないことからWikipedia:井戸端/subj/Unicodeの基本多言語面にない文字をタイトルに含むページの作成解禁に向けての議論次第です。--Schwei2会話) 2020年5月8日 (金) 14:09 (UTC)
非漢字の基準は難しいですが(そもそも記号類を記事名に使用するのは推奨されることなのか?)、絵文字が収録される以前のUnicodeであるUnicode 5.2あたりまでの文字であれば何の問題もなく使用可能でしょう。--Schwei2会話) 2020年5月8日 (金) 14:21 (UTC)
記号や絵文字は芸名、グループ名であれば十分あり得るかなと。いま絵文字が使えないことで支障はないので、個別の議論で妥当性のない記事名をつけないようにするのではなく、包括的に一般的ではない記号や外国の文字を排除するような縛りを付けるならJIS X 0213の範囲の漢字(JIS X 0213漢字一覧の1面JIS X 0213漢字一覧の2面)および非漢字でも十分かもしれません。ただし、一部基本多言語面に含まれない漢字が一部含まれているので解禁が条件になります(解禁されないならJIS X 0213範囲かつ基本多言語面内で)。また、これだと彅、璐、﨑、Ø、♥は入りますが、髙、𠮷は入らないですね。--Monaneko会話) 2020年5月8日 (金) 16:09 (UTC)
個人的にはUnicodeの文字であればどのような文字であっても(互換文字や制御文字などは除く)記事名として適切であれば使用して構わないとは思います。「フォントを用意すればいい」といえばそれまでですし、世界的にもこのような規定があるのは日本語版のみでしょう(少なくとも同じ漢字圏である中国語版・韓国語版にはこのような規定はありません)。ビャンビャン麺にしたって中国語版で「𰻝𰻝面」なわけですからWikipedia全体としては問題ないのでしょう(ただ、「𰻞」という文字は一般的な日本語話者には馴染みがないので、この記事に関しては改名は反対です)。--Schwei2会話) 2020年5月8日 (金) 16:29 (UTC)
  • どうもこの手の議論にはユニコードと環境について深刻な誤解があるようでして、ユニコードに対応していることは「フォント」を持っていると言うことではありません。特にこの場合の問題点は、Schwei2さんの意見に裏付けが全くないんですよ。なんとなく、みんな対応してるんじゃないの? ガラケーが原因じゃないの? 旧いOSなんてもういいんじゃいの? 多数じゃないからもういらないんじゃないの? という思い込みで進めることはできません。この議論、過去にもあったのですが(直近は2017年のこれです。Wikipedia‐ノート:記事名の付け方/過去ログ15)この検証フェイズを飛ばしていることと、少数を無視していることから失敗しています。他言語版が配慮していないことは理由にはなりません。それは他言語版の見落としであり、これに合わせることはできません。文字を使いたいから少数を切り捨てることが許容されるかという深刻な問題に対抗するのに「使いたいから」だけでは足りないのです。なお今のところ難しいだろうと判断するのは、mw:Compatibilityを見る限り、 Chrome 1+、IE 6+、Firefox 3+、Safari 3+、Opera 15+、Mobile Safari 5.0+ (iOS 4+)、Android 2.0+、WebOS < 1.5、PlayStation、Symbian-based browsers、NetFront-based browser、Opera Mini、Nokia's Ovi Browser、MeeGo's browser、Google Glass、UC Mini (speed mode on)がGradeC=Basicに残っていまして、単に少数(GradeX)に配慮するよりも強い要請となっているからです。[3]からある程度環境が見えますが、いまだにWindows98が0.2%残っていたり、IE6すらまだ0.1%出てくる。この環境下でWikipediaとして切ることは難があります。この問題は{{小文字}}的な解決ができるといいのですが(対応している場合に記事名を置き換える)。--Open-box会話) 2020年5月8日 (金) 18:33 (UTC)
    • リンク先を見る限りではStartup Module内には確かにIE6が残っているものの、実際にはIE6とIE7のサポートは打ち切られているようです。0.1〜2%の環境への配慮よりは、現にJIS X 0208外の文字を記事名にする需要があるわけですからそちらを重要視すべきでしょう。--Schwei2会話) 2020年5月9日 (土) 00:32 (UTC)
    • それはMediaWikiの対応の話であって、Wikipediaの話ではないように思います。MediaWikiであれば社内イントラネットで使われる場合もあるので古い環境での対応も必要に思いますがインターネットであれば配慮する必要はないと思います。あと古いブラウザがサポートしていないHTML5やCSS3を使ってる時点で動作保証していないような。そもそもそれらブラウザでマトモにWikipediaって見えるのでしょうか。--Monaneko会話) 2020年5月9日 (土) 00:53 (UTC)
    • もう一つ、このサイトはHTTPS必須で暗号方式がTLS1.2とTLS1.3しか対応していないため[4]、TLS1.1までしか対応していない環境からのアクセスができません。Transport_Layer_Security#ウェブブラウザを見ると、Windows 7以降のブラウザでなければそもそもアクセス出来ないと思います。サイト自体が古い環境を切り捨てている以上配慮の意味はないと思います。--Monaneko会話) 2020年5月9日 (土) 02:25 (UTC)
      • ついでに手元にある環境で試しました。いずれもJIS X 0208外文字です。PlayStation4はJIS非漢字の一部が表示されず(表示されるもの:㊿、されないもの:⤴)、第4水準漢字もCJK統合漢字 拡張Bに割り当てられている一部漢字は表示されませんでした(表示されるもの:𠮷、𠀋、表示されないもの:𠂉、𠂢)。絵文字は表示されず。手元のAndroid 7.1.1の入ったタブレット(NEC製)はCJK統合漢字 拡張Bの全ては網羅していないものの、第4水準文字は網羅しているようです。絵文字はEmoji ver.4までなら表示されるようです。--Monaneko会話) 2020年5月9日 (土) 02:25 (UTC)
      • 前回この提案が潰れたのは、検証どころか反例が突きつけられたからです。ここから逃げ続けてもいつまでも解決できません。実は、Windows 8.1ですら問題があり、Windows 7と合わせて実はまだセキュリティサポート中(合計5.6%)って時点で、あと3年ほどはBMPの全面実装はできませんから、その間に集めるってのはありでしょう。それが、Monanekoさんの後段の「マトモにWikipediaって見えるのでしょうか」の疑問に対する回答を集めることにも繋がります。
TLS1.2だとXPまでは対応パッチ出てます(IE8を残したのは恐らくこれです。Safari 3とかOpera 15が残ってるのは意味不明ですが)。
せっかくなのでこちらもチェックしました。割と知られているのですが、PSP、PS3はアクセスできません(TLSの問題が2015年から知られていますが5年間放置されているので改善の見込みはほぼなさそうです)。iOS12、オランウータンはダメです。LGのAndoroid 9.0タブレット、表示に問題はありません。Vista IE9、TLS1.2有効でも接続できず。
今のところ欲しいのは、WindowsXP IE8(TLS1.2をサポートする最も古いIE、ただし標準で対応しない)、Firefox、Chrome(TLS問題が発生した当時IE8代替とされていたブラウザ群、OperaはChromeベースなので略)、Android4.4(TLS1.2をサポートする最も古いAndroid)、iOS5(TLS1.2をサポートする最も古いiOS、初代iPadがこれ)。OS X Mavericks~OS X El Capitan(TLS1.2をサポートするMacOSで販売時期が最も古い)、ニンテンドー3DS、Wii U(TLS1.2をサポートするゲーム機、裏技になるがSwitchも含めるべきか?)。このあたりが共通で表示できるもの(アクセスできなければバージョンを上げていく)が限界になると思われます。--Open-box会話) 2020年5月9日 (土) 04:23 (UTC)
文字が表示できない環境への配慮としては、記事名を代替表記にするよりは、本文中に文字の解説を入れた方がよいと思われます。また検索時の入力が多少困難になるためJIS X 0208内の文字を使用したリダイレクトの設置は必須でしょう(現にその逆のリダイレクトは多数設置されています)。--Schwei2会話) 2020年5月9日 (土) 04:39 (UTC)
残念ながら正→代替のリダイレクトは機能しますが、代替→正のリダイレクトは機能しません。というよりもですね、機能するならそもそも制限はいらないんです。だから「記事名を代替表記にするよりは、本文中に文字の解説を入れた方がよい」ができず、「記事名」だけ厳しいんです。表示が優先的な問題であれば記事本文にも制限が掛かるのですが(ビャンビャン麺はこのケースで、zhの様に画像を使う手もありました)、表記ガイドではそこまで縛らずに来ているので、今更かたかな・ひらがなに置き換えていくのも難ですしね(オフライン版を出力してもらう手はあるので記事名ほど深刻ではありません)。実際代替→正が文字ではなくコード表記や版であればあるいは? ってところはあるんですが、それはそれで普通に使う利用者に悪影響がありそうです。--Open-box会話) 2020年5月9日 (土) 05:07 (UTC)
すみません。「代替→正のリダイレクトが機能しない」というのがどういう現象を指しているかわかりません。たとえば、BOØWYが代替のBOOWYになっているものをBOØWYを本文にしてBOOWYをリダイレクトにした場合に非対応環境では記事名が表示されない以外にどういった不具合が起きるのでしょうか?--Monaneko会話) 2020年5月9日 (土) 05:21 (UTC)
記事の閲覧時よりも、一部の環境で見れない文字を使った記事へのリダイレクト作成時に問題が発生するものと思われます。記事名とリダイレクトで使える文字の範囲が違っており、リダイレクトのほうが広い範囲の文字を使えるようになっている場合、「代替」での記事作成時に記事名の制限(現状はJIS X 0208内の文字)のチェックが可能です。しかし、その逆はチェックが極めて困難になります。リダイレクトに使える文字範囲の拡張はWikipedia:井戸端/subj/Unicodeの文字をリダイレクトとして作成できるかでも議論中ですが、「リダイレクトで使える文字の一部は、記事名には使えない」ことに変わりはありません。--茶でもすするか会話) 2020年5月9日 (土) 06:08 (UTC)
補足しますと、リダイレクト先の日本語アドレスを解決できない状況も想定されます。これはただの夢なんですが、ガジェットで代替と正を置換できないかって期待するんですよね。記事名の制約の所に正の記事名を置いてそれを拾って代替表示と差し替え、制約の方は代替表示としてXXがありますみたいに紹介する内容に変わるってできれば、ビャンビャン麺すら使えるんじゃないかなって考えるんです。--Open-box会話) 2020年5月9日 (土) 06:14 (UTC)
なるほど、編集時に壊れた文字で投稿されることを気にしているんですね。マイナーな環境での編集が可能であることを考慮すべきか否かは考えの違いもあると思いますので置いておきます。リダイレクト先の日本語アドレスが解決できないについては杞憂に思われます。リダイレクト元の記事名を指定した際、サーバが302 Foundなどを返して本来の記事にリダイレクトさせる処理をしていると思いましたが、リダイレクトさせずにデータを表示して、JavaScriptでアドレスバーを書き換えているようです。JavaScriptを無効化するとアドレスが変わらなくなります(内部リンク外部リンクで試しました)。JavaScriptがおかしな処理をしてアドレスバーに正しいURLが表示されない可能性はありますが、そこまで対応しなくてもいいのではないかと思います。--Monaneko会話) 2020年5月9日 (土) 07:37 (UTC)
情報 Grade Cはそもそも(MediaWikiにおける)JavaScriptが無効になっています。したがって、上記のJavaScriptによる書き換えも起こらなければ、ガジェットもJavaScriptを使えません(ガジェットのCSSが使えるかどうかは未確認ですが、少なくともOpen-boxさんが述べた処理は不可能でしょう)。Grade AならばJavaScriptが使えますが、ここではGrade Aのブラウザが要点ではないと思います。--ネイ会話) 2020年5月9日 (土) 07:58 (UTC)
  • 情報 下記にMediaWikiにおけるブラウザへのサポートに関する情報を提供いたします。
    • IE6とIE7のサポート打ち切りの経緯はphab:T232563にありますが、提案者は「IE6とIE7がウィキメディア系サイトへのリクエストの0.1%と0.07%しか占めていない」ことを理由に挙げており、議論ではTLS1.2必須のためそもそもアクセスできないことも理由として挙げられています。
    • IE8のサポート打ち切りは現在phab:T248061にて議論中ですが、この議論では(ウィキメディア全体への)アクセス数が提出されています。今年3月15日から4月15日までの間、リクエスト数の合計が約188億回でうちIE8からのアクセスが1750万回(約0.1%)となっています。編集数については今年1月においてIE8から編集画面が開かれた回数が273回で、投稿が試みられた回数が5回となっています。Android 2.xのサポート打ち切りもphab:T249788にて議論中でアクセス数が理由となっています。(いずれも、サポート打ち切りにより使えるようになる機能があったり、CSSが軽くなったりします)
    • ニンテンドー3DS、Wii Uが使用するNetFront Browser NXmw:Compatibility#Browser support matrixではサポート対象外となっています。要は、「使用できる可能性もありますが、使用できなくても文句は言えない」状態です。
  • 以上です。--ネイ会話) 2020年5月9日 (土) 05:59 (UTC)
ありがとうございました。IE8打ち切りならIE9も打ち切りになりそうですね。今のまま打ち切りを進めるなら、3年後にBMPを解放できそうな気はしますが、iOSやAndroidで解放が止まったらそこはそれと言うことで。--Open-box会話) 2020年5月9日 (土) 06:14 (UTC)

IE8(Windows XP)やiOS、Androidであれば少なくともBMP範囲であれば使えるはずです。今後3年間もJISX0208範囲内に留めておくのはやりすぎ感は否めません。--Schwei2会話) 2020年5月9日 (土) 06:37 (UTC)

BMP解放とCJK等の一部に限定しての解放を取り違えてはいけません。XPどころか8.1でもBMPは扱いきれません。これは既知の問題であり、反論するには相応の証拠が必要です。この提案はシステムに触れることになるので、思い込みではなくちゃんと確認取ってまとめる必要があります。「できるはずだ」と主張してもそれでは根拠になりません。だからこそ、他の方が確認作業をやっているんですよ。ここまでの例ですと、MonanekoさんのAndroid 7.1.1の例からX0213になる可能性がある気はします。--Open-box会話) 2020年5月9日 (土) 07:02 (UTC)
あとなんでもありにした場合に考えられる問題としては、閲覧・編集がバグる以外にはこんな感じの制御コードを駆使したおかしな記事を作ることが可能になるということでしょうか(BMPの範囲内で記述していますが、Chromeは一部表示できないようです)。こういう類の記事名は妥当ではないものとして使われることはないでしょうが、フィルターで自動的にブロックしているのであれば管理上面倒になる可能性はあります。--Monaneko会話) 2020年5月9日 (土) 07:56 (UTC)
  • (コメント)私は2006年に項目名がJIS X 0208外であったことを理由にいくつかのキリル文字、例えばҺフ (キリル文字)に、Ѵイジツァに移動させましたが、これこれこれを経て、文字名で記事にするのが困難であることから文字そのものの記事についてはJIS X 0208縛りの例外とされたようです。あまりこのような例外は望ましくないので、記事名の制約はできるだけ大きくとってほしいです。…しかし、マイナーなブラウザの対応も忘れてはいけません。ここによると、メジャーなものを除いてwebOS1.5以上(<1.5になってるのは誤記か?)、Symbian OSのブラウザ、NetFront BrowserOpera Minien:Ovi (Nokia)のブラウザ、MeeGoのブラウザ、Google GlassUC Mini(スピードモード)が挙げられています(日本語圏ではほぼ使われないと思われるものも混ざってますが…)。--6144会話) 2020年5月9日 (土) 09:30 (UTC)

情報 Android 4.4.2、Google Chrome 81 で表示の確認をしてみました。漢字については以下の通りです。「彅」「璐」「髙」「﨑」については正しく表示されます。CJK統合漢字拡張AにあるものはUnicode 13.0で追加された10文字を除き表示されますが、CJK統合漢字拡張B(「𠮷」など)にあるものは表示されません。

絵文字についてはコード順で🛋(U+1F6CB)以降は全て縦長の四角形に化けます。それ以前は大半は表示できますが⌨(U+2328)など一部の絵文字は化けます。Unicode6.0の携帯電話の絵文字の一覧にあるものはすべて表示されますが、0⃣(U+0030 + U+20E3)や🇯🇵(U+1F1EF + U+1F1F5)といった結合文字(?)については2文字のように表示されます。なお、このコメントはAndroid端末ではなくPCから投稿しています。--本日晴天会話) 2020年5月9日 (土) 10:31 (UTC)

Symbol comment vote.svg 追記 CJK互換漢字についてはU+FA2Fまでは表示されます。U+FA30からU+FA6Fについては「爫」(U+FA49)・「艹」(U+FA5D)・「艹」(U+FA5E)・「辶」(U+FA66)の4文字だけが表示されず、残りは表示されます。「恵」(U+FA6B)と「舘」(U+FA6D)は表示されますが、「𤋮」(U+FA6C)は表示されません。U+FA7DからU+FAD9については表示される文字とされない文字が混在します(この範囲についてはWindows 10、Google Chrome 81のPC環境でもいくつか化けます)。
CJK統合漢字 (8D00-9FFF)についてはAndroid 4.4.2でU+9FA5まで、Windows 10でU+9FD5まで表示されますが、それ以降はだめです。--本日晴天会話) 2020年5月9日 (土) 13:03 (UTC)
Symbol comment vote.svg 追記 JIS X 0212についてはJIS X 0212コード表(全コード)をAndroid 4.4.2で閲覧したところ、「Ǐ」(U+01D0)・「Ǒ」(U+01D1)・「Ǔ」(U+01D3)・「Ǚ」(U+01D9)・「Ǖ」(U+01D5)の5文字は表示されませんでした。残りは漢字も含めて表示されます。JIS X 0213についてはJIS X 0213漢字一覧の2面の1区と94区をAndroid 4.4.2で閲覧したところ、UnicodeでBMP内のものは表示されますがBMP外のものは表示されませんでした。--本日晴天会話) 2020年5月10日 (日) 08:32 (UTC)

情報 iOS13.4.1のSafariにて絵文字は正常ですが、CJK互換漢字U+FA70以降が四角形の中にXに文字化けします。CJK統合漢字拡張Aは表示されますがBはだめです。絵文字は問題ないと思われます。iOS12.4.6、AのUnicode 13.0で追加分が表示できません。互換漢字FA2EとFもだめです。統合漢字、数え間違えていなければCJK統合漢字 (8D00-9FFF)の末尾付近で9文字が表示されません。絵文字、携帯電話の絵文字の一覧は問題なし、Emoji一覧は後半を中心に相当数が欠けます(画面が小さいので数えきれません)。--Open-box会話) 2020年5月9日 (土) 11:53 (UTC)

提案 皆様ご検証ありがとうございます。「髙」はJIS X 0212や同0213の対象外ですが、IBM拡張漢字に入っているため多くの日本語環境で表示されるものと思われます。それでは、現在一般的な日本語環境で表示ができる「JIS X 0212・JIS X 0213・IBM拡張漢字のいずれかに収録されている文字(そのうち﨎﨏﨑﨓﨔﨟﨡﨣﨤﨧﨨﨩以外のCJK互換漢字を除く)」を使用可能にするというのはどうでしょうか。--Schwei2会話) 2020年5月9日 (土) 12:08 (UTC)

コメント その提案だとCJK統合漢字 拡張B(U+2xxxx)にあるJIS X 0213の漢字が含まれますが大丈夫でしょうか?また保守的に行くならば非漢字について、カ゚(U+30ab U+309a)のような2つの文字コードで定義されているものについても除外したほうがいいかもしれません。Wikipedia:井戸端/subj/Unicodeの文字をリダイレクトとして作成できるかを見て思いましたが、異字体セレクタの使用は禁止を明示したほうがいいと思います。U+2665は非漢字に含まれていますが異字体セレクタでテキストスタイルと絵文字スタイルが定義されているため、♥︎(テキストスタイル)と♥️(絵文字スタイル)で違う扱いになります。疑問点をあげただけですのでJIS X 0213かつCJK統合漢字 拡張B、Unicodeでは複数文字であらわすJIS X 0213非漢字については特に反対意見がないようでしたら賛成に回ります。--Monaneko会話) 2020年5月10日 (日) 06:16 (UTC)
拡張Bの漢字に関してはWikipedia:井戸端/subj/Unicodeの基本多言語面にない文字をタイトルに含むページの作成解禁に向けての議論次第といった所ではありますが、技術的制約が無ければ含めるべきだと考えます。カ゚(U+30ab U+309a)などはJIS X 0213の範囲内であることを考えると本来含まれるべきだと考えますが、環境によっては未だに「カ゜」のような表示になってしまいます。「どうせ分離することもあるならば許容した方が良い」「どうせ分離するならば初めから分けた表記で良い」と二つの考えが存在しうるので難しい状態です。異体字セレクタは制御文字などと同様、禁止した方がよいでしょう。--Schwei2会話) 2020年5月10日 (日) 08:02 (UTC) 微修正 Schwei2会話) 2020年5月10日 (日) 08:05 (UTC)
JIS X 0213で規定されている漢字の中には、Android4.4.4のブラウザ(Chrome81.0)では表示されない「𠀋」(「丈」の右上に点がついた文字、U+2000B、1面14区02点)などが含まれますね。これまでのご意見をまとめますと、一般の記事名で使用できる文字は、
  • JIS X 0201のラテン文字類。
  • 罫線素片・私用領域の文字(いわゆる外字)・異体字セレクタを除いたJIS X 0208で規定JIS X 0212・JIS X 0213・IBM拡張漢字のいずれかに収録されている文字、かつUnicode基本多言語面に配置されている文字
のような感じになりますでしょうか。--茶でもすするか会話) 2020年5月10日 (日) 08:10 (UTC)一部修正。--茶でもすするか会話) 2020年5月10日 (日) 08:18 (UTC)
当面はそれが無難でしょうかね。--Schwei2会話) 2020年5月11日 (月) 07:08 (UTC)

流れを読まずにすみません。『ビャンビャン麺』の漢字表記?ですが前2文字が表示されません(■■麺みたいになります)。Android版Firefox最新版、OSバージョンは8.1.0のG03(au)です。--2001:268:C05F:8921:C837:D43A:DD0F:2290 2020年5月11日 (月) 13:17 (UTC)

「𰻞(ビャン)」は今年に入ってUnicodeに収録されたばかりの文字です。対応環境はまだ少ないでしょう。--Schwei2会話) 2020年5月11日 (月) 14:20 (UTC)

情報 JIS X 0213非漢字の対応状況を調べてみるべく、JIS X 0213非漢字一覧を元にAndroid4.4.4のブラウザ(Chrome81.0)で表示可能な文字を以下にまとめました。

これを見る限り、記事名には使わない文字も多いとはいえ非漢字については「JIS X 0213掲載の文字」という条件でも危ういのではないかと思われます。また、もしJIS X 0208規定の撤廃をするのであればWikipedia:表記ガイド#使用可能な文字の内容も見直しの上、非漢字についての情報も加えたほうが良いかもしれません。--茶でもすするか会話) 2020年5月17日 (日) 11:32 (UTC)一部の文字が表示されていたため修正 --茶でもすするか会話) 2020年5月17日 (日) 22:08 (UTC)
※レイアウトに不具合・重なっている部分を見つけたため、一部修正させていただきました。また、量が多いので折り畳みができるようにさせていただきました。--Mario1257会話) 2020年5月18日 (月) 15:55 (UTC)

他の方の検証結果が出てきたので折りたたみを標準とし、更新版を作りました。--Open-box会話) 2020年5月20日 (水) 09:58 (UTC)
見た限り、記事名に使わない文字の方が多いと思われます。²や³などはISO 8859-1にもあるのですが、それでも表示されないのでしょうか?--Schwei2会話) 2020年5月17日 (日) 13:45 (UTC)
あれ、Schwei2さんのコメントの²や³はちゃんと表示できていますね。JIS X 0213非漢字一覧の表には表示されませんでしたが、上記の表を改めてAndroid4.4.4のブラウザで確認しましたところ、以下の文字は表示できていましたので修正いたします。
  • ς (0x83d7)
  • ² (0x854b)
  • ³ (0x854c)
  • ͡ (0x8671)
  • ̏ (0x867c)
それでも、5年以上前にリリースされたOSバージョンとは言え、表示できなかった文字が予想外に多かったことに驚いた次第です。もし、記事名における日本語表示を最大限に配慮するならば、デスクトップOSやモバイルOS端末だけでなく、ゲーム機などの組み込み機器搭載ブラウザの表示状況も確認した方が良いものと思われます。--茶でもすするか会話) 2020年5月17日 (日) 22:08 (UTC)

議論から1週間経過したため、本日から上記の条件(JIS X 0201のラテン文字類+罫線素片等を除くJIS X 0212・JIS X 0213・IBM拡張漢字のいずれか、かつBMP面に配置されている文字)に緩和しようと思っていたのですが、どうしましょう?しかし98/Meならともかく、Android4.4でも表示されない文字が多いとは…(おそらく初期のAndroidではフォント容量を節約するために文字を減らしていたのでしょうけど)--Schwei2会話) 2020年5月18日 (月) 05:09 (UTC)

情報 Android 6より、日本語の標準フォントがモトヤフォントからNoto Sans CJKに変更されました。これにより、CJK統合漢字 拡張Bのうち、JIS X 0213に含まれる文字、および茶でもすするかさんが表示できないとした非漢字も表示されるようになっています。--Likibp会話) 2020年5月18日 (月) 15:35 (UTC)
コメント 参考 Android4.2.2,Chrome71のタブレット端末を所有しているので、上記表を参考に確認しました。その結果、表示されないのは紫色になっているのに加え、♫(0x81f9)のみでした。--Mario1257会話) 2020年5月18日 (月) 15:55 (UTC)
  • Android4.0.4における最終版のFirefoxで確認したところ、紫枠以外でも
    ⤴⤵◉〽﹆﹅゠
    が非対応でした。--お好み焼き星人会話) 2020年5月19日 (火) 16:27 (UTC)
  • 情報 PlayStation4で確認しました。--Monaneko会話) 2020年5月20日 (水) 01:03 (UTC) --一部修正Monaneko会話) 2020年5月20日 (水) 01:08 (UTC)
    • 上記表の紫網掛け以外で表示されないもの:⊄⊅∉≅⤴⤵゠◐◑⁇⁈ḾḿǸɱʋɾɬɮɹʈɖɳɽʂʐɻɭɟɲʝʎɰʁʕʔɦʘǂɓɗʄɠɨʉɘɞɐɯʊɤɒʍɥʢʡɕʑɺɧˈˌˑ0x8680のうち̈以外、0x8690のうち̃❶以外
    • 上記表の紫網掛け内で表示されるもの:〳〴〵〻ゟ⊖⦅⦆≃♮∓ℏ㏋ゕゖ〠☂☃ヷヸヹヺ⅕㉑㉒㉓㉔㉕㉖㉗㉘㉙㉚㉛㉜㉝㉞㉟㊱㊲㊳㊴㊵㊶㊷㊸㊹㊺㊻㊼㊽㊾㊿Ǎ⓫⓬⓭⓮⓯⓰⓱⓲⓳⓴ⅺⅻ㋐㋑㋒㋓㋔㋕㋖㋗㋘㋙㋚㋛㋜㋝㋞㋟㋠㋡㋢㋣㋺㋩㋥㋭㋬
    • 上記表の紫網掛け内で表示されないもの:⊊⊋⌅⌆∦≢≶≷⦿℧⧺⧻か゚き゚く゚け゚こ゚カ゚キ゚ク゚ケ゚コ゚セ゚ツ゚ト゚⓵⓶⓷⓸⓹⓺⓻⓼⓽⓾☖☗▱ㇰㇱㇲㇳㇴㇵㇶㇷㇸㇹㇷ゚ㇺㇻㇼㇽㇾㇿ⎾⎿⏀⏁⏂⏃⏄⏅⏆⏇⏈⏉⏊⏋⏌⋚⋛⌘␣⏎◒◓Ɠ˥˦˧˨˩˩˥˥˩、‿̌ ̂0x8680のもの、⁑⁂
コメント 参考 いくつかのOSの検証が穴だらけってのが困りますね(多分問題ないでしょうが、実は誰もOS XやWindows 7で確認していない問題が。iOSも私がやってるiOS12はあるんですが古いのがない)。今のうちにできることは文字表の整備と言語化です。例えばここまでの話でも、パ行以外の半濁音、ヵとヶ(カタカナ限定)・ッ・ア行・ヤ行以外の小書き、丸で囲んだカタカナ、21以上の白丸数字、11以上の黒丸数字、二重丸数字は使用不可になります。単に「JIS X 0201のラテン文字類+罫線素片等を除くJIS X 0212・JIS X 0213・IBM拡張漢字のいずれか、かつBMP面に配置されている文字」だけでは理解が及ばないので、こういった言語化は必要になるでしょう。
iOS12.4.6、IE11(Windwos Server 2012 R2)上記の表示に問題ありません。表を更新しました。--Open-box会話) 2020年5月20日 (水) 09:58 (UTC)
情報 Windows Vista SP2, IE9の環境でJIS X 0213の文字が表示できるかを[5]のページで確認しました(長年使っておらず、TLS1.2非対応のためウィキペディア日本語版のページが表示できなかったので、前掲サイトで確認)。フォントが不揃いになることを無視すればJIS X 0213のすべての文字が表示できましたので、WindowsにおいてはVista以降のOSならば表示に特段の問題はないものと思われます。
これがWindowsXP SP3, IE8の環境では、「㐂」(喜→七七七)「㓛」(功の右側が刀)など、JIS第3水準の漢字で表示できなかった文字が多数あった他、非漢字につきましても多数の表示できなかった文字がありました(表示できなかった文字は、Open-boxさんが2020年5月20日09:58 (UTC)の編集で更新した紫網掛けの中にすべて含まれています)。
MacOSXでは、MacOSX 10.11.6, Chrome81.0でJIS X 0213のすべての文字が表示できたことを確認しました。MacOSX 10.3, Firefox2.0で確認した結果は、Android4.4で表示できなかった非漢字に加え、トランプ記号、ローマ数字、丸数字などの丸囲み文字、「㍉」(ミリ)などの組文字も表示されないか文字化けしました。ただし、さすがに古すぎるOSのためここまで考慮する必要性は薄いでしょう。--茶でもすするか会話) 2020年5月24日 (日) 01:17 (UTC)

議論が停滞してしまいましたが、公式な方針に「○○で表示できる基準の文字」とするのはやや苦しい気がします。やはり前述の「JIS X 0201のラテン文字類+罫線素片等を除くJIS X 0212・JIS X 0213・IBM拡張漢字のいずれか、かつBMP面に配置されている文字(カ゚などの二文字で表す文字を除く)」とするのが良いと思われますがどうでしょう?--Schwei2会話) 2020年6月1日 (月) 07:18 (UTC)

縦型ナビゲーションの是非(横型との使い分け)[編集]

周知の通り、現在のナビゲーションテンプレートには、縦型と横型があります。すなわち、{{sidebar}}を使ったものと{{navbox}}を使ったものです(例外してこれらを直接使わないものもあります)。例はいくらでもありますが、縦型のものは{{権利}}・{{再生可能エネルギー}}・{{量子力学}}など、横型のものは{{中日ドラゴンズ}}・{{日本語}}・{{データ構造}}などです。

注意:縦型ナビゲーションには基礎情報テンプレート(例えば{{Infobox お笑い芸人}}など)は含まれていません

このうち、前者について縦型のナビゲーションはなぜ横型ではないのでしょうか?というのも、横型のものは記事末尾、==関連項目==の中に入っており、なるほど確かにナビゲーションテンプレートの役割である「関連した記事へのリンク集」になっています。しかし、縦型ナビゲーションは記事冒頭に置かれていることが多いわけですが、関連項目を記事冒頭に挙げる意義があまり見いだせません。リンク数を稼ぎたいアフェリエイトサイトならともかく、「Aとはなにか?」を調べたい時にその中身より先に「A1やA2もありますよ」と言われても、はっきり言って邪魔です。Aについてある程度読んで理解した後に「もっと知りたいならA1やA2もありますよ」なら分かります(それが関連項目の意義でもあり、スタイルマニュアルにおいて関連項目(付録部)が本体部の後に置いてある意味でもあります)。

それでもまだ、ナビゲーションが縦か横=冒頭か末尾のどちらかに固めてあるならマシです。しかし、多くの記事で縦型と横型が混在しています。例を挙げれば連続体力学などがそうです。 そのような記事では、読者が関連項目を知りたい=ナビゲーションがほしい場合にどこを見れば良いか分かりません。縦型のもの(冒頭にあるもの)のほうが重要かと言われると必ずしもそうではないです(そもそも各記事の事情を鑑みずに重要度を統一して決めるのはほぼ無理)。

加えて、記事冒頭には先述の基礎情報テンプレートが入る記事がたくさんあります。基礎情報テンプレートの下に更に縦長の表が続けば、本文の幅を狭めて読みづらさが増します。

というような事情を考えると、縦型ナビゲーションテンプレートは不要ではないか?つまり、全て横型に置き換えて記事末尾に置いてしまえばいいのでは?という気持ちが湧いてくるわけです。

いかがでしょうか。今は別にいきなり縦型を廃止しろという話ではなくて、どちらかというと、縦型の良いところ(横型にすると不都合なこと)を中心に、代替案・修正案があれば募りたいという段階だと思ってください。--青子守歌会話/履歴 2020年5月14日 (木) 09:15 (UTC)

はて、言われてみれば確かに混在していますね。自分はいつも横長のディスプレイで見ているせいか、縦型が邪魔だと思ったことは特にありませんでした。英語版でもそういう状況で、日本語版の現状の多くは何も考えずに輸入しているだけのようなので、ここだけで議論しても仕方ないのかな、と思います。自分の印象では、縦型は広い概念の大本の記事でよく使われている気がしていましたが、青子守歌さんの挙げた例を見ると、必ずしもそうではなさそうですね。例えば{{量子力学}}は量子力学にはあってもいいけど、シュレーディンガーの猫の冒頭には別にいらんでしょうと思います。その末尾に{{ネコ}}が貼ってあって噴き出した。 --白駒会話) 2020年5月15日 (金) 18:48 (UTC)
コメント 確かにそんな気がします。冒頭に縦型、末尾に(関連項目と)横型となりますと、関連する事柄を知りたい読者の目は、冒頭と末尾を両方探すことになりますね。不便といえば不便です。
白駒さんの例を使わせていただきますと、{{量子力学}}は量子力学を見た人にとっては冒頭にあったほうが便利かもしれませんが、シュレーディンガーの猫の場合、それについて知りたくて記事を開いたのに冒頭から関連項目を並べ立てられてもはっきり言って邪魔です。そもそも関連項目というのは、その記事について知ってからこそのもので、本来末尾にあるべきものです。
ただ、{{sidebar}}だけでもかなりの数のテンプレート(一部doc、sandbox、testcasesを含みます)から呼び出されており、末尾に置き直すのはWP:BOTREQがあるのでともかく、ひとつひとつ修正or新設するのは結構な時間と労力が必要そうですね。--Atmark-chan </稿> 2020年5月16日 (土) 00:25 (UTC)
報告 試しに、{{権利}}を{{Navbox}}で書き換えたらどうなるのか、テンプレートのサンドボックスで試してみました。--Atmark-chan </稿> 2020年5月16日 (土) 00:48 (UTC) 修正--Atmark-chan </稿> 2020年5月16日 (土) 00:50 (UTC)
コメント 英語版のen:Wikipedia:Navigation templateには「2つは補完的であり、状況によっては...両方が適切な場合がある」とあります(具体論はないですが)。私自身が思ったのは体系的なものと網羅的なもの(大枠的)、縦串と横串という感じなのかなと。縦型Naviが適するのはたぶん学問的記事とかで、記事は限定されるように思います。また「冒頭から関連項目を並べられて邪魔」という意見もありましたが、この記事じゃない場合末尾までスクロールするのは面倒ってこともありますから‥(状況、感性による)。あと{{権利}}を見て思うのはinfoboxよりも幅広で、縦型はサイズの規制も必要かと思います。--115.39.237.111 2020年5月16日 (土) 02:16 (UTC)
コメント #TypesThe two types are used interchangeably, and either or both may be appropriate in different circumstances. という部分のことですか?(念のため確認だけ。)--Atmark-chan </稿> 2020年5月16日 (土) 03:06 (UTC)
その前段(The two are complementary and either or both may be appropriate in different situations. )。(それ以上突っ込まれても答えられないので..)--115.39.237.111 2020年5月16日 (土) 13:22 (UTC)
コメント ありがとうございます。一応どこの記述か確認だけしておきたかっただけなので、これ以上特に何か言うことはありません。--Atmark-chan </稿> 2020年5月16日 (土) 14:54 (UTC)
  • コメント基本的には、『記事の内容から、更に細分化されたページへの誘導』の場合は冒頭が、『それ以外の誘導』の場合は末尾が、それぞれ望ましいのではないでしょうか?
    {{量子力学}}で言うと、シュレーディンガーの猫等で使う(末尾使用の)為の横型タイプ、量子力学等で使う(冒頭使用の)為の現行(縦型)タイプ、の二種類有った方が良いような気がします。
    ※あくまでも『ちょっと思っただけ』のコメントですので、アレでしたらスルーしてくださいませ。--お好み焼き星人会話) 2020年5月17日 (日) 03:00 (UTC)
  • コメント 横型と縦型のナビゲーションテンプレートは、確かに重複しており、同一分野でも記事によって「横だけ」「縦だけ」「両方」など不統一ですが、経緯と目的は少し違うと思います。横は通常「関連項目」と「カテゴリー」の間にあり、複数記事で共通する関連項目を一括管理でき、カテゴリーより整然と並べられて、幅があるのでTemplate:政治思想のような少し複雑な表も作れるので、ウィキペディアの初期から使われていると思います。これに対して縦は、比較的最近増えて来たもので、国際主義指導者原理など記事名だけでは何の話かわかりにくい記事も一目で分野と位置付けが判り、スクロールせずに別の関連用語へ飛べます。縦は記事自体を読むには邪魔なのも判りますが、縦があると記事の先頭だけ読んで重複記載する困った編集が減る印象もあります。いわば、基本・安定・古典の横、一見・安直・新参の縦です。なおWikipedia:方針とガイドラインナショナリズム共産主義などは縦横両方あります(縦はコンパクト重視)。Template:北朝鮮の大量破壊兵器は英語版を参考に横から縦に変えました。翻訳を含めると各国語版の動向も影響します。当面併存が現実的と思いますが、分野ごとにプロジェクトなどで標準化を進めても良いのではないでしょうか。基本的には115.39.237.111さんに賛成です(縦横は補完的、個人の趣味や感覚にもよるので一律の合意は困難、縦の横幅は注意すべき。)--Rabit gti会話) 2020年5月20日 (水) 15:46 (UTC)

各位コメントありがとうございます。縦型にする記事冒頭のナビゲーションはある記事の大元から細分化するための案内で、横型の関連項目のような記事同士の水平なつながりとは違う意味を持つという考え方は、なるほど一理あるなと思います。また、{{五十音}}のように、一般的な形として縦型(≒横長になりにくい)のほうが良いものも一部にはありそうです。ただ「記事名だけでは分かりにくいので関連分野と位置づけを表す」というのは、気持ちは分かるのですが、記事の(冒頭の)質の問題で、本文中に組み込んだりそもそも説明を分かりやすくできないのが根本的な問題であって縦型の長所というにはちょっと及ばないかなと思いました(特に、先の2つに比べて)。先の2つも、下位分野へのリンクということであれば、他の複数の記事で使われることは想定されないと思うので、テンプレートではなく、本文中に表なり他の方法で埋め込むのが正しそうな気がしますし、五十音表のような例外的なものは特例として扱えば済むだけかなと思います。

というわけで、まだちょっと「縦型が優れている!」という話になるには、ふわっとしているなぁという印象です。歴史的経緯と他言語版の状況などありますが、各分野PJで決めるというのは必要そうですし、そのための原則的な指針をWikipedia:ナビゲーションテンプレートか関連する辺りに具体的に整備し始めてもよいのかなと思いました。提起したらここやWP:Nなど各所でもお知らせします。--青子守歌会話/履歴 2020年5月27日 (水) 05:24 (UTC)

  • 1. 相対的な概念を解説する記事の場合、関連概念を目立つように並べることでその相対的な立ち位置を理解しやすくする、見通しをつけさせる、という意義があるのではないかと思います。「左翼」記事に、「左翼・右翼」「左翼 - 極左」「中道左派 - 中道 - 中道右派」などがあるのはその良い例だと思います。こういったものは箇条書きにするのが自然ですが、箇条書きは本文ではあまり推奨されない(特に冒頭部ではまずない)ので、冒頭付近に別枠で、となるのではないでしょうか。これは非記事ページですが、Help:セクション等の目次的な縦型テンプレートは典型的だと思います。同じようなものを横型で一行目やその付近に置くと、本文の流れが分断され過ぎて、邪魔に感じると思います。ページ下の方に置くことが想定されている縦型テンプレートに関しては、この理由では説明できませんが。それと推測ですが、短い記事の場合は冒頭部のスペースを使うまでもなく、上でも下でもすぐに目に入るため、縦型にする必要がないということで、横型が(横型だけが)多いような気がします。逆に、長い記事だと、「関連項目」があまりに下すぎて見落とされやすいので上の方にも案内を置きたい、という意識が働くような。こういう意味では「縦」であるというより、上の方に置いても邪魔になりすぎないことがポイントのようでもあります。
  • 2. 全く別の観点から、モバイル版で横幅が非常に小さい画面では、縦型も横幅一杯になり、ほとんど横型のようになっていたりします。ちなみに連続体力学はそうなっていて、左翼の場合は縦型テンプレートがモバイルでは消えているようでした。これは、狭い画面が縦に分割されると非常に読みにくいのでそうせざるを得ないという苦渋の結果ですかね。モバイル版の読者の方がそうでない読者より多い昨今では、画面幅に応じてフロート型になったり横幅一杯になったり位置が変わったりするような、新しい統合型のレスポンシブなものを考えてもいいのではないでしょうか。

--2001:240:241F:7274:7C89:B2F3:7B48:CA8E 2020年5月28日 (木) 03:20 (UTC)

「RFD notice」テンプレートのデザイン変更提案[編集]

Template:RFD noticeの変更に関する提案ですが、当該ノートページで提案しても気づかれない可能性が高いため、井戸端にて提案致します。

Template:RFD noticeは現在、削除依頼のテンプレートと同じ色・画像を使用しております。しかし、前者が「その記事へのリダイレクトを削除すること」なのに対し後者は「その記事そのものを削除すること」を告知するものであり、少し意図が違います。あと、あくまで私自身の感想ですが、削除依頼に出されるわけもないような記事で削除依頼の色とこの画像Icono aviso borrar.svgを見ると正直ギョッとします(例えば、2019新型コロナウイルス固定版))。

このようなことから、Template:RFD noticeを、削除依頼のテンプレートと異なるもしくは画像、又はその両方で変更する提案にいたします。

一つ補足しておきますと、色を変える場合はモジュールに変更を加えることとなり、手間を要します。--Atmark-chan </稿> 2020年5月14日 (木) 13:49 (UTC)

仮に画像を変えるとしたら、RFD icon sample-01.svgみたいなのはどうでしょう。矢印がリダイレクトを表現しています。--Atmark-chan </稿> 2020年5月14日 (木) 14:14 (UTC)
  • コメント 変更案件に賛成です。Atmark-chanさんがおっしゃるように、現状のマークの見た目だと「その記事を削除をするのかな」と思ってしまいます。アイコンに関しては、(個人的には)ゴミ箱がメインではないほうがいいと思います。--Mario1257会話) 2020年5月14日 (木) 17:53 (UTC)
  • コメント 私も賛成です。画像も「立て看板に斜線」とか「立て看板とゴミ箱」みたいな、明らかに記事削除のゴミ箱とは違うアイコンのほうがドキッとしないで済みます。--Licsak会話) 2020年5月15日 (金) 06:45 (UTC)
    • 返信 (Mario1257さん、Licsakさん宛) 確かにゴミ箱メインではないほうが良いですね。
    @Licsakさん ちなみに、「立て看板」というのはなぜですか?--Atmark-chan </稿> 2020年5月15日 (金) 09:38 (UTC)
  • 工事中道路の「まわり道」案内をイメージしました。しかしプラカードや道案内の立て札のほうが分かりやすかったかもしれませんね。--Licsak会話) 2020年5月15日 (金) 09:50 (UTC)
  • コメント 変更自体には賛成ですが、これって一つのアイコン、一つの意匠でないとダメなものでしょうか。動作や作業を示す意匠(例として削除ならゴミ箱)とその対象を表す意匠(リダイレクトなら丸に曲がり矢印など)を分離して、上下や左右に並べるような方法はどうでしょうか。そのようにしておけば、今後、削除だが対象が違うものや、リダイレクトを対象とするが作業が違うようなものに応用が利く気がします。また、アイコンの理想としては、シルエット(白黒画像)でもはっきり分かるものが望ましいように思います。--219.102.85.242 2020年5月16日 (土) 01:50 (UTC)
    • コメント 確かにその方法もありますね。とすると、Symbol redirect blue.svgIcono aviso borrar.svgを左右に配置するというのはどうでしょうか。--Atmark-chan </稿> 2020年5月16日 (土) 02:04 (UTC)
  • コメント 変更案に賛成します。上記の方がおっしゃるようにアイコンはゴミ箱以外のアイコンが良いと思います。--リボンちゃん会話) 2020年5月16日 (土) 02:17 (UTC)
  • コメント 画像はあくまでも簡易的なサインのはずです。変えるのは良いと思うのですが、なぜわざわざ新しい画像を作ったり、画像を並べたりして全ての情報を詰め込もうとするのでしょうか。また、英語版のリダイレクトの削除依頼で使われているアイコンとか、そのアイコンと同じカテゴリの画像なども参考にした上で、参考事例として挙げた方が良いと思います。変えるなら幾つかのアイデアを示して、そこを手掛かりに知恵を出し合うとより良い結果が得られるはずです。--Marine-Bluetalkcontribsmail 2020年5月16日 (土) 13:17 (UTC)
    • 横から失礼 横から失礼 英語版の画像とおっしゃられていますが、何も英語版に合わせなくてもいいではないですか。ここは日本語版なのですから。--Tmv会話|投稿記録) 2020年5月17日 (日) 05:21 (UTC)
      • コメント 別に合わせろと言っているわけではなく、いろいろな事例を参考に最良の択を導き出してはどうかと言っているのです。--Marine-Bluetalkcontribsmail 2020年5月17日 (日) 06:43 (UTC)
        • 情報 英語版はどんな画像を使っているかとリダイレクトの削除依頼を見たら、画像がないんですね(リダイレクトの削除対象の "Anime and Manga")。日本語版は日本語版独自で進めても良さそうな気がします。--Licsak会話) 2020年5月17日 (日) 15:46 (UTC)
  • コメント - この提案の主旨は「リダイレクトの削除が検討されているだけなのに記事本体が削除されるかのようで目立ちすぎる」という点ですので、英語版のようにアイコンを取っ払ってしまったほうが差別化という点では有効でしょう。その一方で目立つと言えど削除に関する案内であることは示したいので、他の注意系Amboxに混じらないよう赤色は維持すべきと考えます。--ButuCC+Mtp 2020年5月17日 (日) 16:11 (UTC)
    • コメント 今のアイコンがゴミ箱にエクスクラメーションマークIcono aviso borrar.svgです。この画像はcommons:Category:Waste container iconsにカテゴライズされています。同じカテゴリを見ると標識とゴミ箱を合わせた画像Attention IfD.svgなんかもあります。標識の中のゴミ箱の中身を差し替えるというのも一案です。ゴミ箱にこだわるなら、空のゴミ箱Nuvola filesystems trashcan empty.pngの中にリダイレクトのサインを突っ込むほうがシンプルです。リダイレクトのサインにしてもcommons:Category:Redirect arrowsという画像があります。ゴミ箱を使わず、リダイレクトのサインにバツを重ねるような発想もあります。このバツを重ねるとしても、commons:Category:Oblique_crossなんてものがあります。何が言いたいかというと、もっと既存のデザインを見たほうが良いんじゃないかなーと思うわけです。--Marine-Bluetalkcontribsmail 2020年5月17日 (日) 17:34 (UTC)
      • コメント Nuvola filesystems trashcan empty.pngにリダイレクトのサインを突っ込むのが一番いいかも知れませんね。シンプルですし、Attention IfD.svgは中に何が書いてあるのかよくわからない・リダイレクト感がないという欠点があります。リダイレクトのサインにバツをつけるのもありですがこのウィキペディアだと削除=ゴミ箱みたいな感覚なのでからのごみ箱 + リダイレクトマークでいい気がします。--Tmv会話|投稿記録) 2020年5月17日 (日) 23:55 (UTC)
        • コメント ゴミ箱にリダイレクトのサインを突っ込むのが分かりやすくかもしれませんが、ゴミ箱の印象をどうするかと言う問題は残ります。標識の中にリダイレクトのサインを入れても良いし、標識の中にゴミ箱だけ入れるって方法もあるし、リダイレクトのサインにバツもやり方次第です。バツマークの使用例を調べるとわかりやすい伝え方があるかもしれません。オリジナルのアイデアに拘らなくて良いのです。--Marine-Bluetalkcontribsmail 2020年5月18日 (月) 10:33 (UTC)
  • コメント しばらくコメントしておらず、また、それにより皆様のコメントを拾い切れておらず、申し訳ございません。
確かに、他の用例(他言語版等々)を調べたほうが良いですね。全ていちから考えるのは時間も手間もかかりますし。
個人的な意見としましては、「リダイレクトの矢印+ゴミ箱」か「リダイレクトに×」が分かりやすい気がします。--Atmark-chan </稿> 2020年5月18日 (月) 12:30 (UTC)
  • コメント ×マークの場合の使用例はcommons:Category:Red X iconsなどを参考にどうぞ。--Marine-Bluetalkcontribsmail 2020年5月18日 (月) 17:08 (UTC)
    • 感謝 ありがとうございます。--Atmark-chan </稿> 2020年5月19日 (火) 01:02 (UTC)
    • コメント 既存のアイコンでいくつか例を出してみますと、
      • Symbol redirect arrow blue.svgArbcom ru withdrawn.svgを重ねる
      • Nuvola filesystems trashcan empty.pngSymbol redirect arrow blue.svgを入れるor上から重ねる
      • (それでゴミ箱が目立ちすぎる場合は)Symbol redirect arrow blue.svgの右下あたりに小さくNuvola filesystems trashcan empty.pngを添える
    とかどうでしょうか。
    現段階では色合いとかは考慮していません。--Atmark-chan </稿> 2020年5月22日 (金) 11:44 (UTC)
コメント ゴミ箱の横にアイコンを添えているものはゴミ箱に対する補足的な情報を示すことになると思います。--Marine-Bluetalkcontribsmail 2020年5月22日 (金) 14:12 (UTC)
コメント いくつか作ってみました( {{RFD notice}} に合わせて 40px 表示):
RFD icon 01.svg - 「Symbol redirect arrow blue.svgArbcom ru withdrawn.svgを重ねる」
RFD icon 02.svg - 「Symbol redirect arrow blue.svgの右下あたりに小さくNuvola filesystems trashcan empty.pngを添える」
Nuvola filesystems trashcan empty.pngSymbol redirect arrow blue.svgを入れるor上から重ねる」は少々難しかったので作っていません。--Atmark-chan </稿> 2020年5月31日 (日) 12:37 (UTC)
Redirect deletion icon01.svgRedirect deletion icon02.svgRedirect deletion icon03.svg
どうぞ。あと、File:Nuvola filesystems trashcan empty.pngはLGPLライセンスなので、クリエイティブ・コモンズライセンスはNGです。--Marine-Bluetalkcontribsmail 2020年5月31日 (日) 14:05 (UTC)
ファイル:RFD icon 02.svgは少し削除のごみ箱のアイコンが目立たない気がするので、他のの方が良いかも知れません…。--Tmv会話|投稿記録) 2020年6月1日 (月) 08:39 (UTC)
返信 (Marine-Blueさん宛) RFD icon 02.svgのことかと存じますが、SVGにしたかったのでNuvola filesystems trashcan empty.pngではなくIcono aviso borrar.svgの一部を使用しています。…と思ったら、Icono aviso borrar.svgもLGPLでした。すみません。どう変えればよいでしょうか? RFD icon 02.svgのみでなく、ついでがてらにWaste-container empty.svgWaste-container exclamation-mark empty.svgも同じように投稿してしまっています…。
あと、私の作ったRFD icon 02.svgより、同じ系統で言えばMarine-BlueさんのRedirect deletion icon02.svgとかRedirect deletion icon03.svgのほうが良いですね。矢印と×印のカクカク感が合っているような気がします。Redirect deletion icon01.svgも良いと思います。--Atmark-chan </稿> 2020年6月1日 (月) 09:20 (UTC)
返信 (Tmvさん宛) RFD icon 02.svgは確かにゴミ箱が目立ちませんね…。--Atmark-chan </稿> 2020年6月1日 (月) 09:20 (UTC)
返信 (Atmark-chanさん宛) ライセンスは基本的に、元となったファイルと同じにする必要があります。また、他の人が作った画像を組み合わせて使う場合、基本的にはどの画像を組み合わせたかをテンプレートに記入してください。ファイル:RFD icon 02.svgは画像のライセンスをLGPLにして、矢印部分を自分で作り直したほうが良いです。レイアウト調整の名目で上書きアップロードしてください。元画像がLGPLライセンスの物は全て同じライセンスの適用と、LGPLの画像同士で組み合わせて作っていただきますようお願いします。--Marine-Bluetalkcontribsmail 2020年6月1日 (月) 13:25 (UTC)
返信 (Marine-Blueさん宛) 分かりました。取り急ぎ作成して上書きアップロードしようと思います。Waste-container empty.svgWaste-container exclamation-mark empty.svgももう一度アップロードし直す形でしょうか? あと、RFD icon 01.svgはどうしましょう。--Atmark-chan </稿> 2020年6月1日 (月) 15:51 (UTC)
Symbol comment vote.svg 追記 あと、「テンプレート」ってどれでしょうか? いつもアップロードウィザードからやっているのですが。それに、アップロードウィザードからだとLGPLの選択肢出てなかった気がします。--Atmark-chan </稿> 2020年6月1日 (月) 16:02 (UTC)
コメント 元となった画像のライセンスを確認して対応してください。そして、ファイルページを直接修正してください。
本件はもう進行中なので継続していいと思いますが、ライセンス関係などプロジェクト運営における重要な事柄が分からないようであれば、提案関係には当面関わらないほうが良いと思います。度重なる問題を引き起こすと後々自分で自分の首を絞める事になります。--Marine-Bluetalkcontribsmail 2020年6月1日 (月) 16:12 (UTC)
コメント ありがとうございます。File:RFD icon 02.svgを上書きアップロード、File:Waste-container empty.svgFile:Waste-container exclamation-mark empty.svgはライセンス間違いとして変更しました(要約欄の英語がヘンかもしれません)。--Atmark-chan </稿> 2020年6月2日 (火) 01:49 (UTC)

テンプレート名の変更のやり方を教えてください

井戸端には初書き込みです。 「Template:日本作詞家協会会長」というテンプレートがありますが、正しくは「作詞」ではなく「作詩」のようですので変更したいのですがやり方がわかりません。やり方の書いてあるページなどを教えていただけると助かります。--ねこざめ会話) 2020年5月16日 (土) 15:59 (UTC)

Wikipedia:ページの改名Help:ページの移動をご覧ください。 片割れ靴下会話) 2020年5月16日 (土) 16:22 (UTC)
ありがとうございます。今から見てきます。ただ、読んでもよくわからない場合は再度ご質問させていただく場合もあるかも知れません。そのときはまたここを利用しようと思いますので、よろしくお願いします。--ねこざめ会話) 2020年5月16日 (土) 16:46 (UTC)
いま提案が終わりました。初めてのことなので1週間待つという正式なやり方でいくことにしました。テンプレート名の変更もページ名の変更の一種なのだということに、言われてみるまでまったく気づいていませんでした。これでまたWikipediaでできることが一つ増えました。ありがとうございました。--ねこざめ会話) 2020年5月16日 (土) 17:30 (UTC)

山手線と京浜東北線のページをスマートフォンで見ると折り畳まれない件について[編集]

山手線と京浜東北線のページをスマートフォンで見ようとすると、本来あるはずの折り畳み機能が使えなくなります。何が原因ですか?どう対処すれば良いですか?--以上の署名の無いコメントは、日本戦士会話投稿記録)さんが 2020年5月17日 (日) 18:07 (UTC) に投稿したものです(ホーリーブライト会話)による付記)。

コメント 10日程前のWikipedia:井戸端/subj/オリンピックマルセイユの記事についてにもありましたが、モバイルビューでは折畳みは機能しないようです。Wikipedia:バグの報告か、Wikipedia:表示改善依頼あたりで気長にお願いする案件のように思います。--115.39.237.111 2020年5月18日 (月) 00:12 (UTC)
コメント 日本戦士さんが困っているのは、個別の折り畳み表示の話ではなく、モバイル版特有の節を折り畳む機能の話ではないですか? モバイルビューでは、どの記事でも節名をタップ(クリック)することで折り畳むことができます(例えば[6]で試してみてください)。しかし、山手線の記事のモバイルビュー([7])では節名をタップしても折りたためません。原因はおそらく山手線#駅一覧の部分で乗り換え路線のロゴを画像として大量に読み込んでいるためだと思います。参考になるかどうかは分かりませんが、モバイル端末に適したウィキメディアwikiの記事の書き方には、「モバイル用サイトでは画像の遅延読み込み (lazy load) を行うため、大量の画像がある記事をモバイル端末で開こうとするとタイムアウトが発生することがあります」と記載があります。いくつかの記事で確認してみたのですが、画像が多い記事では節の折り畳みが機能しなくなる現象を確認できました。解決方法は僕には分かりません。編集で路線のロゴを全部消してしまえば節の折り畳みはできるようになると思いますが、そうすると記事の分かりやすさが大幅に減ってしまいます。--Takayasu会話) 2020年5月19日 (火) 02:52 (UTC)
駅一覧を消すとモバイルビューで節折り畳みが機能するようになることを確認しました[8]。やはり原因は駅一覧の画像ロゴのようです。とはいえ必要なものなので消すわけにはいかないですね・・・。--Takayasu会話) 2020年5月19日 (火) 03:11 (UTC) 一部修正--Takayasu会話) 2020年5月22日 (金) 11:40 (UTC)

テンプレート内に置くNavbarの改行位置を調整するには?[編集]

表題について、プロジェクト‐ノート:ウィキ技術部#テンプレート内のNavbarの改行位置を修正したいで質問していますが、なかなか回答がつきません。原因を究明し、修正できる技術をお持ちの方はご教示いただけますと幸いです。--Doraemonplus会話) 2020年5月18日 (月) 11:39 (UTC)

モジュール:Navbarを編集して「style="display: inline-block;"」を追加すれば直せると思いますが管理者の人しか編集できないようになってました:( 応急措置としてモジュール:Medical cases chart/sandboxの編集で無理矢理直したんですが、僕は詳しくないので間違えてるかもしれないです…。もし問題があったら戻してください。--Takayasu会話) 2020年5月19日 (火) 10:14 (UTC)
ウィキ技術部のノートの方でも display: inline-block; の追加が必要との回答がありました。MediaWiki:Common.cssを直すにせよ、モジュール:Navbarを直すにせよ、他のページに多大な影響を及ぼすことになるため、とても私の手には負えません。当面の間は、Takayasuさんに直していただいたモジュール:Medical cases chart/sandboxのソースコードで運用していくことにしようと思います。ありがとうございました。また、マルチポストにて失礼いたしました。--Doraemonplus会話) 2020年5月19日 (火) 13:09 (UTC)
コメント別件と言えば別件なのですが、関連する話なのでここですみません。このテンプレートのNavbarで表示するリンク先がバグってるのにさっき気付いたので勝手に直しました。英語版ではテンプレートのページ名が「Template:[outbreak]_data/[location]_medical_cases_chart」に統一されているみたいで、モジュールでも決め打ちになっていて、そのせいで日本語版のモジュールも「Template:[outbreak]データ/[location]/症例数の推移図表」の決め打ちになってました。だけど、実際のテンプレート名を見るとTemplate:2019-nCoV Data/日本の感染確認事例数の推移/都道府県別/東京都/図表Template:2019-nCoV Data/アメリカ合衆国の感染確認事例数の推移/図表みたいに名前がバラバラになってたので、Navbarのリンク先が正しく出ないバグが発生してました。なのでoutbreakを消してnavbartitleという引数を追加しました。navbartitle={{subst:PAGENAME}}とするだけで正しく表示できます。サンドボックス版を正式版にするときに、Template:Medical_cases_chart/docの「|outbreak = name of the main outbreak (for link of the {{navbar}})」というとこを「|navbartitle={{subst:PAGENAME}}」に書き換えてもらえると助かります。--Takayasu会話) 2020年5月20日 (水) 02:56 (UTC)
コメント navbartitle={{subst:PAGENAME}}とするアイデアは名案だと思いますが、テンプレートのページ名をどうするか(決め打ちにするか完全に任意のタイトルにするか)は実は未検討事項(これから詰めていくつもり)でして、個人的には、標準化のためにも「Template:[outbreak]データ/症例数の推移/[location3]/[location2]/[location]/図表」のような形式に収めたいと考えています。現状のテンプレートのタイトル形式とは異なりますが、むしろテンプレートのタイトルの方を一斉改名することを提議しようかと考えているところです。--Doraemonplus会話) 2020年5月20日 (水) 03:37 (UTC)
コメント テンプレートを改名するにしてもしないにしてもnavbartitle={{subst:PAGENAME}}のほうが柔軟性が高く確実なのでモジュール部分はこのまま正式版にしていいのでは?柔軟性というのは例えばMedical cases chartが将来的にA国のみの小規模な疾病のグラフに使用された場合に/症例数の推移/A国/のような細かいサブページを作るのは迂遠ということがありうるのでモジュール部分で決めてしまわないほうが便利ということ。--219.104.100.128 2020年5月20日 (水) 04:53 (UTC)
コメント あまり細かすぎると迂遠かも、との意見も理解できますが、一連の図表ページ群のテンプレート化/モジュール化においては、標準化という側面も重要だと考えます。もともとあった「Template:2019-nCoV Data」をベースに、現在の「Template:2019-nCoV Data/日本の感染確認事例数の推移/都道府県別/東京都/図表」のようなページ名形式を考案したのは他でもない私ですが、その経験から言わせていただくと、ページ名の規格化には結構な苦労が伴います。完全に自由に決めてよいとすれば、今以上にページ名がバラバラになることが懸念されます。可能であれば、事前に十分な議論をして、サブページ構造を含めたテンプレート名を決めたかったのですが、今般のCOVID-19の流行情勢は目まぐるしく変化し続けているため、その余裕がありませんでした。徹底的なモジュール化を構想している今こそ、標準化を再検討してみる好機だと捉えています。一連のCOVID-19テンプレート群のページ名の整理は、既存のTemplate:2019-nCoV_Data/直下の図表テンプレート群も含めて検討する必要があるため、結論を出すのを急ぎはしません。近日中にTemplate‐ノート:2019-nCoV Dataで正式に提議したいと思います。--Doraemonplus会話) 2020年5月20日 (水) 07:46 (UTC)
コメントそういうことだったんですね。Template:2019-nCoV_Data/日本の感染確認事例数の推移/都道府県別/北海道/図表を見て表示がおかしいなと思って直しただけなので、僕は決め打ちにしたらダメと思ってるわけではないです。なので、テンプレートのページ名の統一が終わった後でやっぱり決め打ちにすべきと判断した場合はモジュール部分を元に戻してもらえると助かります。もちろん219.104.100.128さんが言ってるようにsubst:PAGENAMEのままで運用していくのでも大丈夫です。僕はどっちがいいかよく分からないのでDoraemonplusさんにお任せします。感染数データをたくさん更新してくれてありがとうございます!--Takayasu会話) 2020年5月20日 (水) 13:11 (UTC)
当面はnavbartitle引数で運用していきます。標準化はじっくり考えます。また、激励のメッセージをありがとうございます!少しでも力になれたなら、大変嬉しく思います。--Doraemonplus会話) 2020年5月22日 (金) 09:27 (UTC)

コメント お知らせ Template‐ノート:2019-nCoV Data#改名提案を提起しました。皆さまのご意見をお待ちしています。--Doraemonplus会話) 2020年5月26日 (火) 13:18 (UTC)

生年月日の記述スタイル 括弧の表記[編集]

著名人のページの導入部などにある生年月日の和暦が、山括弧〈 〉で括られる表記を多からず最近見かけるように感じるのですが、

何かそのようなルールが作られたのでしょうか?

それについて言及されているような議論したページはどこかにありますか?


例:

山田 太郎(やまだ たろう、○○○○年(昭和○年)○月○日 - )は、~~である。

山田 太郎(やまだ たろう、○○○○年〈昭和○年〉○月○日 - )は、~~である。


--126.118.66.204 2020年5月19日 (火) 09:15 (UTC)

  • 日頃、前者の丸括弧の表記を何となく見慣れているせいか、Sqlspcさんの答えた回答内容で一応納得しました。
    このような表記揺れが起きることについて多分編集者はマニュアルをご覧になってないからだと思われますが、後者の山括弧の表記が今後多くなっていった場合どうなるのでしょうか?(個人的に後者も見栄えも含めて一理あると思いましたが。)--126.118.66.204 2020年5月23日 (土) 13:13 (UTC)
  • 後者例の山括弧で人物記事を執筆しております。126.118.66.204さんがご覧になった山括弧の記事は私が書いたものかもしれず、責任を感じる次第です。実はこの間、初版投稿した記事の生年月日表記を、他の利用者様により山括弧から前者例の丸括弧に変更されたことがありました。以前にWikipedia:表記ガイドWikipedia:スタイルマニュアル (人物伝)を拝見したときは、確か双方とも入れ子は山括弧だったと記憶しており、また今まで山括弧使用について特にご指摘をいただいたこともありませんでしたので、「あれ?」と思って確認し直しますと先述の通りで、「以前は確か、山括弧でなかったか?」と疑問に思っておりました。この機に過去の履歴を確認しますと、
  1. 2004年3月 - Wikipedia:表記ガイドの初版が作成され、括弧の入れ子に山括弧を用いるようご案内がありました[9]
  2. 2005年2月 - Wikipedia:スタイルマニュアル (人物伝)で、西暦と和暦の併記例の登場し、括弧の入れ子に丸括弧が用いられていました[10](夏目漱石の箇所、現在のものとスタイルは異なりますが)。表記ガイドの方では山括弧のままでしたので[11]、表記の異なりが生じていました。
  3. 2007年9月 - スタイルマニュアルで、Wikipedia‐ノート:スタイルマニュアル (人物伝)/過去ログ4#生没年の元号併記についてに基づいて、西暦の隣に和暦を併記するスタイルが生まれ、やはり入れ子は丸括弧でした[12](野口英世の箇所)。
  4. 2010年10月 - その入れ子が表記ガイドに沿って、山括弧に変更されました[13]
  5. 2014年1月 - その山括弧が「括弧の変更は影響が大きいため」との理由で差戻され、丸括弧に戻りました[14](私が確認したのはこの差戻し前だったか?)
といった経緯で現在へ至るようですが、スタイルマニュアルの改訂での過程において「入れ子の括弧にどの記号を用いるか」について、Wikipedia‐ノート:スタイルマニュアル (人物伝)での議論や提案の形跡は確認できませんでした。115.39.237.111さんのご案内の昨年1月のノートの他、Wikipedia‐ノート:表記ガイド#人物記事における存命期間の括弧表記についてでも一昨年に同様の指摘がありましたが、「双方の表記を統一しよう」「改訂しよう」といった動きには至っていないようです。個人的には、導入部以外の記事本文でも括弧の入れ子を用いることもありますので(岡上菊栄など)、迷いどころです。--逃亡者会話) 2020年5月27日 (水) 03:15 (UTC)
    • 山括弧派側の経緯・理由と、マニュアルの変遷について知れてよかったです。
      「責任を感じる」程、この事に関して私はそこまで大事とは思っていません。まあ素朴な疑問程度です。
      厳密にしても表記揺れはキリが無いと思いますので。Wikipediaのこういう場合はどうなんだろうと思った次第です。(あとどれくらい気付いている人がいるか。)

      こういうのは細かい事で、地味な問題だと思っています。
      些細な表記揺れについてなかなか目立つ程問題が大きくならないと思いますし、
      それで今後仮に、明らかな不都合が見つかり、それがある程度周りに認知されていった時に 議論され、統一されそうな気がしました。
      個人的にこの表記揺れについて意見を聞けて知れたのでひとまず済みました。そうした上で、表記統一までは慣習的に倣ったり様子を見たりして倣うものなのかなと思いました。--126.118.66.204 2020年5月28日 (木) 09:31 (UTC)


自費で電子出版された書籍の信頼性について質問[編集]

ノート:デジタルミレニアム著作権法に質問をまとめていて疑問に思ったのですが、amazon上で自費出版(電子出版)された書籍は自己公表された情報源とみなして信頼性がないものと判断して良いのでしょうか。—Osumi Akari会話) 2020年5月20日 (水) 06:26 (UTC)

一般論として、Wikipedia:信頼できる情報源#自己公表された情報源:二次資料としての使用で「個人のウェブサイトやブログ、そのほかの自己公表物あるいは自費出版物は、二次資料として使用できません」として示されている通り、自費による電子出版は二次資料として使用することはできません。 片割れ靴下会話) 2020年5月20日 (水) 07:06 (UTC)
  • 電子書籍であっても自費出版物であることに変わりはないので、一般的にはWikipediaの出典として利用できません。--Loasa会話) 2020年5月20日 (水) 08:34 (UTC)
片割れ靴下様、Loasa様、素早いご返答ありがとうございます。やはりそうですよね。--Osumi Akari会話) 2020年5月20日 (水) 13:23 (UTC)


()付きのリダイレクトのルールの改定について[編集]

先行議論としてWikipedia:井戸端/subj/()付きのリダイレクトについてもご覧ください。()付きのリダイレクトについておおむね残すべきもしくは残してもいいという意見が占めたため以下のように提案させて頂きます。

  1. Wikipedia:即時削除の方針#リダイレクト3の廃止
  2. Wikipedia:リダイレクト削除の方針#削除してはいけないものに「重複立項予防のために作られた()付きのリダイレクト」を追加

いかがでしょう?ほかに修正すべきところなどの意見があれば教えてください。--Yosizuya会話) 2020年5月20日 (水) 10:28 (UTC)

反対 ()付きリダイレクトには有用なものもあれば有用でないものもあります。無条件に認めることには反対です。
1. Wikipedia:即時削除の方針#リダイレクト3の廃止
→リダイレクト3は改名提案を経てかつ存続意見のないものが対象であり、現状特に問題があるとは思っていません。
2. #Wikipedia:リダイレクト削除の方針#削除してはいけないものに「重複立項予防のために作られた()付きのリダイレクト」を追加
→「リダイレクトが不慮のwikiリンクの補助となっていて、重複記事が作成される可能性を減らしている場合」との違いが分かりません。
以上です。--Penn Station (talk) 2020年5月20日 (水) 17:15 (UTC)
  • コメント 意見を踏まえて少し修正と補足。1は、リンク元が残っていて(特に利用者ページに多い)厳密にいえば即時削除できないケース(それが原因で短期ブロックを受けた人もいる)との混同やトラブルを避ける意味合いもあります。一つの方向性としてこの規定を残したうえで、「リダイレクトの削除で合意された場合」に修正したほうがいいかもしれません。2は例えば本田圭佑 (1986年生のサッカー選手)(平等な曖昧さ回避にした時のタイトル)や木村義雄 (政治家)(意図的に曖昧さ回避にリダイレクトかつ重複立項予防「別の政治家を作るときに誤ってこの記事名でさくせいしないようにする」)を想定しています。--Yosizuya会話) 2020年5月25日 (月) 13:17 (UTC)

機械翻訳の活用について[編集]

井戸端でのこれまでの議論などを見ていると、機械翻訳を使って翻訳記事を作成することについて否定的な見方をしておられる方が少なくないように思います。

特に、高い語学力を持っていて、機械翻訳を使うまでもなく翻訳を行うことができる方にそのように考えている方が多いように思います。

しかし、機械翻訳の進歩・一般化により、以前とは少し状況が変わってきているように思われるので、高い語学力の方をお持ちのかたも交えて機器翻訳の活用についてお考えいただければと思います。

本題に入る前に、念のため、Wikipedia日本語版における機械翻訳のルール上のあつかいについて整理しておきます。

以前は、機械翻訳を用いて作成した文章をそのままWikipediaに投稿することは、機械翻訳を運営する事業者の権利を侵害することになるので違法でした。しかし、現在はウィキメディア財団と事業者との間の契約により、いくつかの機械翻訳については、他言語版の記事を翻訳して日本語版に投稿することができるようになっています。使用が認められているインターネット上の機械翻訳はWikipedia:翻訳のガイドラインによると、Google翻訳、ヤンデックス翻訳、有道翻訳、LingoCloudの4つです。

この他にコンテンツ翻訳ツール(mw:Content translation/ja)の中で、機械翻訳を使うことができます。コンテンツ翻訳ツールについては色々と批判があり、英語版では投稿数が少ない利用者は通常空間への投稿はできませんし、中で機械翻訳を使うことはできません。(ただし、DRAFT空間、利用者空間への投稿は可能ですしツールの外で機械翻訳を使うことは可能です。)

使ったことのない方はご存じないでしょうが、実のところコンテンツ翻訳ツールは色々なバグを解決できないでいる状態で、バグの報告場所であるmw:Talk:Content translationを見ればバグがいかに多いかわかります。私がコンテンツ翻訳を使って作成した記事のいくつか([15]など)にカテゴリーがないのもコンテンツ翻訳のバグによるものです。(ちなみに、phab:T212083によるとこのバグは以前より知られており2018年12月(!)から修正作業を行っていますが、いまだに解決できていません)

いささか説明が長くなりました。ここで、本題に戻ります。

私が皆さんにご検討いただきたいことは、非常に単純なことです。

それは、「翻訳記事はそれ以外の記事と同じように扱えばよい」という提案です。

以下説明します。

以前だと、出来が悪い翻訳記事について、翻訳元言語に関する知識のない利用者は「出来が悪い」ということは分かるものの、記事の修正をすることができず、自然、修正作業は翻訳元言語に関する知識がある一部の利用者に集中することになりました。

しかし、現在は、機械翻訳が進歩した結果、翻訳元言語の知識がなくても翻訳元の記事がはっきりさえしていれば、(そして修正者が十分な日本語の知識を持っていれば)修正者に翻訳元言語の知識がなくても元の記事と作られた翻訳記事のおかしいと思う箇所を比べて修正することが可能です。この状況は、ネット上の情報などを元にして最初から日本語で作成された出来が悪い記事とほとんど変わりません。

機械翻訳そのままで、日本語としてこなれていない記事についてもこのへんの事情に変わりはありません。

そこで、翻訳記事だからと言って特別の扱いをするのではなく、最初から日本語で書かれた記事と同じように扱えばいいというのが私が提案したいことです。

よろしくご検討ください。

--HaussmannSaintLazare会話) 2020年5月20日 (水) 14:32 (UTC) (「修正者に翻訳元言語の知識がなくても」を追加しました。)--HaussmannSaintLazare会話) 2020年5月20日 (水) 14:41 (UTC)

コメント 機械翻訳そのままの記事については、別の問題点があります。読者にとって、その記事が存在する価値があるのかどうかという観点です。一般の読者も他言語のページを機械翻訳して読むことができます。つまり、機械翻訳そのままの記事ならば、日本語版に記事が存在しなくても、読者は読むことができるという事です。機械翻訳そのままの記事が存在する価値はあるのでしょうか?--aki42006会話) 2020年5月20日 (水) 21:48 (UTC)
コメント Aki42006さんのご指摘通り、他言語版のWikipediaをGoogle翻訳などを用いて日本語で読むことは一般の利用者にも可能です。日本語版に機械翻訳そのままの記事が存在する価値は私としても疑わざるを得ません。もちろん、日本語版に「とりあえず」記事を作ることでその後の活発な編集活動を期待することは出来るでしょう。多くの言語版に存在する記事が日本語版にはないような場合、特筆性について見逃していた可能性が高く、早急に記事を作成する必要が生じているケースもあるでしょう。ですが、たとえば機械翻訳を認めるガイドラインなどが作成されて他言語版の機械翻訳記事が乱立すれば、やはり関心を集めない記事は質の悪いまま放置され――これは現状、機械翻訳を抜きにしてもある問題のような気もしますが――それに拍車をかける不安があります。Wikipedia日本語版には非日本語話者、全く日本語を書けない・話せない利用者もいます。最近も新規記事で他言語版を拠点に活動する利用者が機械翻訳した記事を見ましたが、そもそも記事名の付け方から問題があり、本文中の説明も理解しがたく、骨が折れすぎて修正作業を断念するようなものでした。機械翻訳の技術が向上しているのは確かですが、Wikipediaの記事として読むに耐える自然な翻訳が可能になったかと言えば話は別なように感じます。HaussmannSaintLazareさんのご意見ですが、(こちらの理解不足で申し訳ないのですが)「翻訳記事はそれ以外の記事と同じように扱えばよい」というご提案は概ね同意できます。私の理解ですが、たとえば翻訳記事には語尾や主語の置き方にWikipediaにおける日本語表記に馴染まないものがありますが、そういったものの修正は翻訳元の言語に明るくなくても出来る。また、明らかな誤訳についてもやはり翻訳元の言語に明るくなくても出来るだろう、といったところでしょうか。「翻訳記事だからと言って特別の扱いをすべきでは無い」というご意見がこういうことであれば、賛同いたします。しかし、「翻訳」が「機械翻訳」を前提とするならば上記の理由で消極的です。もちろん、翻訳作業の一助として機械翻訳を用いることにはなんら問題ないと思いますが、繰り返しになりますが日本語版に機械翻訳そのままの記事が存在する価値は疑わざるを得ません。--しんぎんぐきゃっと会話) 2020年5月20日 (水) 22:36 (UTC)
コメント 結論部分で「翻訳記事だからと言って特別の扱い」と機械翻訳と翻訳記事のすり替えを行っています。現在日本語版では「翻訳記事」と「日本語版独自の記事」の区別はありません。翻訳元、特に英語版を丸呑みするという点では翻訳記事に甘いとすら言えます。ですから結論部分に関しては現状と同じか翻訳記事に多少厳しくなるのであって提案する意味がありません。他の部分では機械翻訳の自由化を求めていますが、これについては過去の議論(Wikipedia:井戸端/subj/コンテンツ翻訳ツールにおける日本語への機械翻訳をツール側で禁止する提案)にある通り、「機械翻訳で読める」=「機械翻訳そのままでの記事作成解禁」とする主張には説得力がありません。これは、機械翻訳でよいのであれば日本語版を読む必要が無い、日本語化されていない機械翻訳を乱造して日本語版を破綻させることを正当化できる理由はない、機械翻訳やるなら少なくとも日本語化する校正の労を省くべきではない(他者に労苦を押しつけ自分は初版に名前を残したいだけでは?)、そしてなにより機械翻訳そのままで良いとするのは、機械翻訳の精度はいまなお低いことを無視している=実際には読めている気分になっているだけ(精度が高い、そのまま読めるとするのは、定型部分が多いことが原因です。今のところGoogle翻訳、みらい翻訳、DeepLのような比較的利用されている機械翻訳でも、定型を外れるとまだまだろくなもんじゃありません)であって、肝心の日本語力が足りないんです。そして、実際に機械翻訳の容認で問題を起こす中心は日本語を解さず訳文の検討ができない他言語版利用者であり、発生する現象は今でも見られる「日本語になっていない記事」の乱造です。低品質な記事を乱造し、修正可能な利用者に作業を押しつけ(なお修正作業を誠実に行うと訳の点検と再訳になるので、機械翻訳による記事が存在している方が労力は大きくなります)、結果訂正が追いつかない記事を多数残る状況を発生させることは「記事の集合」としての日本語版に対する明白な破壊行為ですから、校正も検証もせず機械翻訳で記事をばらまくことは決して正当化されません。将来的に精度が向上するんだからとする方もおられますが、それこそ「何も考えずに適用しても問題が多発しないほど」精度が向上してから提案してねってことなんです。なお、機械翻訳の校正は「データ量の変化」「データの変化」は少ないのですが「結果としての訳文の変化」は多いので、%足切りが上手く働かない原因であったりもします。--Open-box会話) 2020年5月21日 (木) 01:48 (UTC)
コメント 下記の英語の文を日本語にGoogle翻訳で変更してみました。理解できますか?--YOUJI会話) 2020年5月21日 (木) 05:52 (UTC)
英語:Severe acute respiratory syndrome coronavirus 2 (SARS-CoV-2) is the strain of coronavirus that causes coronavirus disease 2019 (COVID-19), a respiratory illness. Colloquially known as coronavirus, it was previously referred to by its provisional name 2019 novel coronavirus (2019-nCoV).As described by the National Institutes of Health, it is the successor to SARS-CoV-1.SARS-CoV-2 is a positive-sense single-stranded RNA virus.It is contagious in humans, and the World Health Organization (WHO) has designated the ongoing pandemic of COVID-19 a Public Health Emergency of International Concern.
日本語:重症急性呼吸器症候群コロナウイルス2(SARS-CoV-2)は、呼吸器疾患であるコロナウイルス疾患2019(COVID-19)を引き起こすコロナウイルスの株です。通称コロナウイルスとして知られ、以前は仮称2019小説コロナウイルス(2019-nCoV)で呼ばれていました。国立衛生研究所によると、SARS-CoV-1.SARS-CoV-2の後継です。ポジティブセンス一本鎖RNAウイルス。ヒトに感染する可能性があり、世界保健機関(WHO)は、COVID-19の進行中のパンデミックを国際懸念の公衆衛生緊急事態に指定しています。
一口に機械翻訳と言っても色々あって、少なくとも上の例文に関しては「みらい翻訳」だとかなりマシですよ。--157.147.154.197 2020年5月21日 (木) 11:44 (UTC)
コメント 私もOpen-boxさんと同様、HaussmannSaintLazareさんの御提言では機械翻訳と翻訳記事が混同されている印象を受けました。入念な翻訳・編集工程を経て制作された翻訳記事と機械翻訳のみで自動生成された(まともな日本語として読めるかどうかも怪しいような)低水準の文章とを同列に扱うべきではありません。技術的にも、基本的に機械翻訳は入力した原文を自然言語テキスト処理プログラムに通して訳文を出力することしかできません。これはつまり、原文に明示されていない文意を汲み取る仕組みがないため、定型的な文はそこそこの品質で訳出できても、行間を読んだり、訳文の作成や推敲に予備知識や専門知識(時に出典の読み込み)が必要となるような内容の文章は機械翻訳が不能(あるいは不適)であることを意味します。また、原文に紛れ込んでいる可能性のある誤り(語法・文法的には間違いがなかったとしても内容的に誤謬のあるもの)を検出するのも困難です。人間が丁寧に翻訳すれば、これらの課題は一定程度クリアできます。なお、日本語の参考文献が十分にあるテーマについては、他言語からの翻訳に頼るよりも、初めから日本語で考えて執筆した方が優れた記事が書けるであろうことは言うまでもありません(これまで少なくない翻訳記事を手掛けてきた私も、最近はこのことを再認識・評価しています)。このように翻訳記事の執筆時における機械翻訳の使用には依然として課題が山積しているため、HaussmannSaintLazareさんの御提案内容は、あえて変更するべき理由がないと考えます。--Doraemonplus会話) 2020年5月21日 (木) 08:00 (UTC)
コメント 機械翻訳が進歩した結果、翻訳元言語の知識がなくても翻訳元の記事がはっきりさえしていれば、(そして修正者が十分な日本語の知識を持っていれば)修正者に翻訳元言語の知識がなくても元の記事と作られた翻訳記事のおかしいと思う箇所を比べて修正することが可能です(太字部分を引用)について。他の方が翻訳記事と機械翻訳を混同されていることを指摘しているので翻訳記事→機械翻訳と解釈します。さて 翻訳元の記事がはっきりさえしていれば というのは他言語版をあてにして翻訳してしまうと他言語版で誤った情報があった場合日本語版も誤った情報を載せてしまうということでしょうか。もしこの解釈なら私も理解できます。そりゃあ、他言語版が間違っているのにそれを訳した日本語版が合っているなんて逆にそれは誤訳です。ですがそれはすなわち出典を見ずに独自解釈をすることにつながります。これは逐語訳をする方によく見られます(機械翻訳もだいたい逐語訳です。DeepLは多少意訳っぽいですが)。私もかつてはこの英語版さえあてにしてその箇所に出典をつけさえすればいいという立場でした。でも記事の編集を続けていくと英語版にもあからさまな間違いが存在することもあることに気づくと思います。英語版(または他の言語版)が絶対に正しいと過信することはいけません。著作権侵害に巻き込まれることもあったようです。機械翻訳を使用した執筆では出典まで目に通す人はそこまでいないと思います。楽だから。しかもその場合Wikipedia:検証可能性は考えられていないでしょう(出典まで確認できるのなら機械翻訳なんて使わないはず)。以上から私の意見をまとめますと、機械翻訳の活用が活発になるとそれは他言語版が合っている上で使用していることになりWikipediaで非常に大事な検証可能性を考えないようになる(=出典を確認しなくなる)ため機械翻訳に頼りきるのは反対。ただ参考程度ならいいかなという感じです。ここからはYOUJIさんが持ってきてくださった文について。全文読んでいませんがnovelが小説と訳している時点で機械翻訳が使えないことを示しています。novelは目新しいという意味もふつうにあるのにnovel coronavirusを新型コロナウイルスと訳せないのはちょっと驚きです。--洗糄会話) 2020年5月21日 (木) 11:01 (UTC)
返信 (洗糄さん宛) 私の提案はどちらかというと「翻訳元言語の知識がない」場合の話が中心なので、YOUJIさんが示しておられる文例についての議論に深入りするのはよくないように思います。何か文例を探すことにします。--HaussmannSaintLazare会話) 2020年5月23日 (土) 03:33 (UTC)
もういいです。あなたはなぜことに巻き込まれているか考えた方がいいですよ。脅しとか個人攻撃とかではなく方針理解と他人の意見の要旨を捉えるために、です。理解できないなら理解できないと言っていただければ良いのですが。理解できないものを曲解するのはもってのほかです。私の意見では「翻訳元言語の知識がない」なら機械翻訳を頼る→機械翻訳にはnovelのような誤りを含む(+出典の閲覧を杜撰にする)→機械翻訳で修正は反対と言っているのが分かりませんか。--洗糄会話) 2020年5月23日 (土) 05:06 (UTC)

コメント

私の提案に関心をお持ちいただきありがとうございます。

皆さんのご意見を読んでいると、提案の中で「機械翻訳」と「翻訳記事」を混同しているというご意見の方が何人もおられます。

「翻訳記事」という言葉を何か所かで使っているので、ここでは洗糄さんが太字で引用された「機械翻訳が進歩した結果、翻訳元言語の知識がなくても翻訳元の記事がはっきりさえしていれば、(そして修正者が十分な日本語の知識を持っていれば)修正者に翻訳元言語の知識がなくても元の記事と作られた翻訳記事のおかしいと思う箇所を比べて修正することが可能です」について説明します。(洗糄さんご指摘の通り、この箇所は私の提案のポイントです。)

「混同している」と書いておられる方はこの文章の「翻訳記事」を「機械翻訳を使って作成された翻訳記事」に限定して考えておられるように思うのですが、私はそういうつもりで書いているわけではなく単に「おかしな箇所がある翻訳記事」の意味で使っています。 引用箇所の説明をする前に、自分自身がコンテンツ翻訳ツールと機械翻訳を使って翻訳記事を作成するときの手順を書きます。少し長くなるので引用の形にしておきます。

まず、最初にコンテンツ翻訳ツールにある「Google翻訳」の機能を使って、日本語の原文を作ります。ざっと見ていくと大体どこかおかしな日本語になっているので、まずはそこを修正します。とりあえず、「読める」状態になったところで、文章の意味を考えながら読んでいき、どうも意味が通じないなと思う箇所があるときは、そこの箇所の意味を把握する努力をします。このときに、翻訳元の記事を英語に機械翻訳した文章を読んで文意を把握することもあります。英語訳を参考にするのはGoogle翻訳の提供元がアメリカの会社であるせいか、日本語訳では意味が通じないと思った箇所でも英語訳では意味が通じることがあるためです。

このような作業を繰り返いした後、大体いいかなと思った時点で「公開」します。

実際には、修正作業が不十分で他の方から何度か指摘を受けているわけですが、そのことは「混同」の説明とは別の話なのでここではこれ以上書きません。

さて、なぜ長々と「翻訳記事の作り方」について書いたかというと、機械翻訳を使った翻訳記事作成作業の大部分が「修正」作業だからです。

そして、その過程で使っているのは日本語の知識であり翻訳元言語の知識ではありません。(英語訳を補助に使うので英語の知識を少し使いますが、せいぜい中学1年生レベルのものです。補足すると、英語版から翻訳するときでも機械翻訳を使っています。それは、私の英語力が「その程度」だからです。)

これは、他の方が作成した翻訳記事であっても同じことだというのが洗糄さんが太字で引用された箇所の趣旨です。

提案のタイトルに「機械翻訳の活用」とあるので、翻訳記事作成を勧めているととらえる方があるかもしれません。しかし、私が活用を勧めているのは「翻訳記事の修正」です。そのことを念頭に置いて、もう一度私の提案を読み返していただけるとありがたく思います。--HaussmannSaintLazare会話) 2020年5月21日 (木) 14:16 (UTC)(「翻訳記事作成の方法」に加筆しました。--HaussmannSaintLazare会話) 2020年5月21日 (木) 14:19 (UTC))(「補足すると」以下加筆しました。--HaussmannSaintLazare会話) 2020年5月21日 (木) 14:31 (UTC))

コメント 全く逆です。「混同」を指摘した方は、「翻訳記事」は「機械翻訳を使って作成された翻訳記事」に限定されないと考えています。「機械翻訳を使わないで作成された翻訳記事」も翻訳記事です。両者をすり替えないでいただきたい。私の経験上、大本が機械翻訳頼みの粗製記事は、HaussmannSaintLazareさんがおっしゃるところの「修正」という名の、ちょっとした文章校正程度では品質の改善に限界があることが多いと思います。YOUJIさんが持ってきてくださった機械翻訳の訳文例については「修正」でどこまで推敲できるとお考えですか。一度、粗製濫造記事を修正する側の身にもなって、機械翻訳の有効な活用法について考えてみてください。--Doraemonplus会話) 2020年5月21日 (木) 14:53 (UTC)
返信 (Doraemonplusさん宛) 私の勘違いをご指摘いただきありがとうございます。ただ、そこのところは私の説明のポイントではありません。私がこの提案で主張しているのは、Doraemonplusさんのように「这位用户不懂或很难理解中文。」と利用者ページに書いておられる方でも、機械翻訳を使えば私が今作業している中国本土のホットスポットイベント一覧のような記事の修正作業に参加できるということです。実際に修正作業に参加するかどうかは、つまりのところその記事に書かれていることに興味があるかどうかなのでDoraemonplusさんに「是非ご参加ください」と書くつもりはありません。ところで、「粗製濫造記事を修正する」と書いておられますが、どのような記事でしょうか。面白そうな記事なら私も修正作業に参加したいのでお教えください。このページの話からは脱線するので、利用者‐会話:HaussmannSaintLazareにお書きいただけると嬉しいです。--HaussmannSaintLazare会話) 2020年5月21日 (木) 16:16 (UTC)(表現を修正しました。--HaussmannSaintLazare会話) 2020年5月21日 (木) 16:20 (UTC))
追伸 順番が逆なのでしょうが、Doraemonplusさんご指摘のYOUJIさん作成の翻訳文を読んでみました。「小説コロナウイルス」には驚きました(後述)が、そのほかはだいたいフンフンという感じです。さすがにこれを「書く」というのはダメと思いますが、自分でGoogle翻訳をして「読む」分には「ま、いいか」というところです。というのは、最近コロナウイルス関係の日本語版の記事を読んでいてある程度の知識があるからです。「小説」については「nCoV」の「n」が「novel」で「新しい」ということを初めて知りました。これを書いていて「Time flies like an arrow」の「光陰矢の如し」ではない訳文のことを思い出したのですが、ご存じですか。--HaussmannSaintLazare会話) 2020年5月21日 (木) 16:39 (UTC)
コメント まさに中国本土のホットスポットイベント一覧のような記事が粗製乱造的といえます。タイトルからして違和感があります。ホットスポットと聞いて、こちらのことかと思いましたよ。正しくは「中国本土のインターネット上で話題沸騰となった事件の一覧」といったところでしょうが、「ホットスポットイベント」では、日本語として普通その意味にはとれません。本文も全般的に意味不明です。助詞も接続詞も文節も正しく表現できておらず、また文体も整っておらず、用語・用字法も的外れ、そのうえ直訳調と来たもので、筆舌に尽くしがたい滅茶苦茶な文章になっています(あまりに酷いので、まともに読んで推敲する気さえ起きませんね)。もしもあの文章を読んで「だいたいフンフンという感じです」とおっしゃるとしたら、もはやその方の日本語能力を疑わざるを得ません。第三者の編集者が原文を一切参照せずに、機械翻訳ベースの誤訳満載の文章を下地にして、この記事の「修正」を試みるのは不可能に近いと思います。そもそも当該一覧記事の内容の百科事典的適性と特筆性も疑わしいですがね(詳細はWikipedia:削除依頼/中国本土のホットスポットイベント一覧に譲る)。--Doraemonplus会話) 2020年5月22日 (金) 00:13 (UTC)
コメント 翻訳記事の修正に活用すべきとありますがそれは逆に誤訳を生む可能性もあります。翻訳記事の修正ということは人が翻訳した文章の修正でしょう。そこに英語無知の方が機械翻訳で「機械翻訳はこう翻訳してるからこっちに修正」なんて言い始めたら合っている文章が誤った文章になります。正直私の翻訳に対するカギは翻訳した人物がちゃんと出典まで目を通しているか?です。機械翻訳を使用する人物が出典まで目を通すとは私には思えません。だって楽だから。機械翻訳の使用理由ってだいたい「楽だから」なんです。私はこの「楽だから」という考え自体wikipediaには向いていないと考えています。もし執筆者が自分は楽していると思っても出典を確認している人は楽はしていないと思います。文献に該当する部分があるかを探す、この作業は機械翻訳をしている方にはない作業です。その点で何度も言いますが出典を見ない時点で機械翻訳はアウト、機械翻訳するならちょっと参考程度で、という考えは曲げません。
あとHaussmannSaintLazareさんがおっしゃる "英語の知識は中1程度のもの" という発言は翻訳している方にとってはかなり常識外れな発言だと思います。せめて高1ぐらいはあってほしいです。関係代名詞とか受動態とか分詞構文も分からないようなら翻訳にチャレンジはやめていただきたいです。--洗糄会話) 2020年5月21日 (木) 22:09 (UTC)

コメント私のノートページにHaussmannSaintLazareさんから議論への参加のお誘いがあり議論に参加させていただきましたが、みなさんの議論を見てだいたいの流れが分かりました。 まず中国本土のホットスポットイベント一覧には(あまり悪く言いたくはないですが)、正直驚かされました。「中国大陆网络热点事件列表」をどう訳せば「中国本土のホットスポットイベント一覧」になるのでしょうか。「网络wǎngluò」は網状のもの、ここではインターネットのことを指すのはそれこそ機械翻訳でもすぐに分かるでしょう。試しにGoogle翻訳で「中国大陆网络热点事件列表」を日本語に変換すると「中国本土でのインターネットホットスポットイベントのリスト」と出ました。英語に変換すると「List of Internet Hotspot Events in Mainland China」。それをさらに日本語に変換しても「中国本土でのインターネットホットスポットイベントのリスト」です。なぜか「インターネット」という一番重要な部分がごっそり抜けています。率直に申し上げて中国本土のホットスポットイベント一覧の記事が機械翻訳を活用した記事作成の実例にはなりえません。 細かなことを申し上げれば、「热点rèdiǎn」について。「ホットスポット」とも訳せますが、「热点话题」であれば「注目の話題」、「东京晴空搭为旅游的热点」であれば「東京スカイツリーは観光名所になった」と、それぞれ適切な訳をしなければなりません。試しに「东京晴空搭为旅游的热点」をGoogle翻訳で日本語に変換すると「東京の空は観光のホットスポットです」となりました。英語に変換すると「Tokyo skies are hot spots for tourism」、それを日本語変換すると結局「東京の空は観光のホットスポットです」でした。やはり機械翻訳の技術向上とWikipediaの記事として読むに耐えるかはまた全くの別の話なわけです。「中国大陆网络热点事件列表」には「中国本土のインターネットで話題になった出来事の一覧」くらいの訳がいいでしょう。 さて、ここからは洗糄さんのご指摘とも重複するところがあると思いますが、他の言語版が絶対に正しいとは限らないということ。さらに元の言語版で価値が認められている記事か、見極められるかどうかということについて指摘させていただきます。私は日本在住で、ある程度の中国語は理解しますが中国のインターネットにはまったくもって疎いです。ですから、中国のインターネット事情がいかなるものかは分からないのですが(そもそもアクセスが難しい)、中国語版において「中国大陆网络热点事件列表」という記事は存在意義があるのでしょうか。いえ、存在意義の有無を判断できますか?私の知る限り日本語版に「日本のインターネットで話題になった出来事」という記事はありません。あったとすれば膨大な記事になって日々編集合戦になりそうなものです。「中国大陆网络热点事件列表」は見る限りそこまで膨大な記事ではないですが、日本語版であれば「要出典」のオンパレードです(そもそも「中国大陆网络热点」という大きな話題を扱っていながらこのくらいの記事に収まっていること自体が当該記事が中国語版でさして重要視されていないことを表しているような気もします)。 以前あまり考えずに中国語版の記述を日本語版に移したところ、出典がないとのご指摘をいただき全て削除された経験があります。ならばと出典を探そうとしましたが、どこを探しても中国語版の記述を検証できる情報はありませんでした。これだけの経験を踏まえて中国語版の質が低いと言うのは短絡的ですが、洗糄さんのご指摘のように「他の言語版が絶対に正しいとは限らないということ」、どころか圧倒的に質が低いことも想定しなければなりません。他の言語版でも記事の存続理由がいまいちで、かつ質の低い記事を大量に日本語版に移入することは日本語版全体の質を落とすことです。このあたりはOpen-boxさんも指摘されてる通りです。HaussmannSaintLazareさんの提案はやはり「機械翻訳を積極的に使っていこう」というものに写ります。もしそれが中国本土のホットスポットイベント一覧のような記事の乱立に繋がるならご提案には反対させていただきます。--しんぎんぐきゃっと会話) 2020年5月22日 (金) 02:04 (UTC)

私の知る限り日本語版に「日本のインターネットで話題になった出来事」という記事はありません。と書きましたが、インターネット現象の一覧という記事があるようですね。記述がずいぶんと古いようにも見受けましたが……--しんぎんぐきゃっと会話) 2020年5月22日 (金) 08:57 (UTC)
コメント しんぎんぐきゃっとさんのコメントに関連して、私の利用者会話ページにもコメントの投稿がありましたので、参考のためにリンクを貼っておきます。--Doraemonplus会話) 2020年5月23日 (土) 08:04 (UTC)

コメント これはもう一目見てWikipedia:井戸端/subj/コンテンツ翻訳ツールにおける日本語への機械翻訳をツール側で禁止する提案Ferrovia della Mendolaが名前を変えて戻ってきたものだと思いましたが、実際にHaussmannSaintLazareさんにはFerrovia della Mendolaと同じくLTA:SUZUの疑いでブロック依頼が提出されています。--219.102.85.242 2020年5月22日 (金) 15:49 (UTC)

「知らない言語」の文例として、朝鮮語とタガログ語について原文、日本語へのGoogle翻訳、英語へのGoogle翻訳を示します。「どちらも知っている」という方は、何か名前だけ知っている言語をお示しいただければ作成します。出典は[16][17]です。

(朝鮮語原文)

SARS-CoV-2(영어: Severe acute respiratory syndrome coronavirus 2)[3][5] 또는 이전 이름 2019년 신종 코로나바이러스(영어: 2019 novel coronavirus, 2019-nCoV)[6][7][8]또는 COVID-19는 유전적 배열(DNA sequencing)상 전도(傳導) 기능(Positive sense)[9][내용주 1] 단일 가닥 RNA(single-stranded RNA) 코로나바이러스로서[10], 인간에게 전염성이 있고 코로나바이러스감염증-19의 원인이다[4].

(GOOGLE翻訳による日本語訳)

SARS-CoV-2 (英:Severe acute respiratory syndrome coronavirus 2)[3] [5]または以前の名前 2019年新型コロナウイルス(英:2019 novel coronavirus、2019-nCoV)[6] [7] [8]またはCOVID-19は、遺伝的配列(DNA sequencing)上伝導(傳導)機能(Positive sense)[9] [内容注1]一本鎖RNA(single-stranded RNA)コロナウイルスとして[10]は、人間に伝染性、コロナウイルス感染症-19の原因である[4] 。

(GOOGLE翻訳による英語訳)

SARS-CoV-2 ( English : Severe acute respiratory syndrome coronavirus 2 ) [3] [5] or former name 2019 new coronavirus ( English : 2019 novel coronavirus , 2019-nCoV ) [6] [7] [8] or COVID-19 is genetic array ( DNA sequencing ) phase conductivity (傳導) function (Positive sense) [9] [Description Note 1] as a single-stranded RNA (single-stranded RNA) coronavirus [10] and are infectious to human It is the cause of coronavirus infection [19 ] .

(タガログ語原文)

Ang SARS-CoV-2 (mula sa Ingles: Severe acute respiratory syndrome coronavirus 2),[1][2] na dating kilala bilang 2019 novel coronavirus, 2019-nCoV at Wuhan virus,[3][4] ay isang positive-sense single-stranded RNA virus.[5][6][7] Ito ay nakakahawa sa tao at ang sanhi ng sakit na coronavirus (COVID-19).[8]

(GOOGLE翻訳による日本語訳)

SARS-CoVの-2 (から英語:重症急性呼吸器症候群コロナウイルス2)、[1] [2]は、以前として知られている2019年新規コロナウイルス、2019-nCoVと武漢ウイルス、[3] [4]であるポジ一本鎖RNAウイルスを感知する。[5] [6] [7]ヒトへの伝染性が高く、コロナウイルス(COVID-19)を引き起こします。[8]

(GOOGLE翻訳による英語訳)

The SARS-CoV-2 (from English : Severe acute respiratory syndrome coronavirus 2 ), [1] [2] formerly known as 2019 novel coronavirus , 2019-nCoV and Wuhan virus , [3] [4] is a positive- sense single-stranded RNA virus . [5] [6] [7] It is highly contagious to humans and causes coronavirus (COVID-19). [8]

--HaussmannSaintLazare会話) 2020年5月23日 (土) 03:58 (UTC)

コメント HaussmannSaintLazareさんは、フランスの鉄道路線であるセルネー-セウエン線の記事をフランス語版からの翻訳で立項した際、日本語版で廃止状態の{{Infobox Ligne ferroviaire}}(フランス語版からの移入)を、日本語版で対応する項目がないという理由で、スタイルの破壊を一切修正しないまま復活させています。記事はおろかテンプレートまで巻き込んだ翻訳元の丸写しと機械翻訳であり、記事破壊抑制のため一度は当方がコメントアウトしましたが、当人により「テンプレートを修正する能力がない」にもかかわらず使用した改悪状態に戻されています。確かに廃止議論を経てないことで私の対話ページに連絡があったとはいえ、なぜ廃止状態にあったのかも考えず、復活事由としては不当です。Infoboxでよくある「翻訳用」テンプレートが「翻訳に便利」「英語版との互換性」という編集者の個人的理由で多数使われていますが、結果として機械翻訳記事の濫造と日本語テンプレートへの否定意見も多く見られ、翻訳ありきのテンプレートの運用に疑問を感じています。セルネー-セウエン線の記事とこれまでのテンプレート扱いの前例からして、HaussmannSaintLazareさんの望まれる機械翻訳による修正投稿への活用には賛成しません。
コンテンツ翻訳は、翻訳に自信のない初心者が気軽に使うための手軽な道具ではなく、Wikipediaの翻訳の方針を熟知した上級者向けのツールと認識すべきです。初版から無理して翻訳元の版に合わせる必要もないですし、言語版に関係なく初版から完璧な記事は滅多にありません。翻訳はあくまで手段としてあくまで日本語版の記事を書くべきであり、自分の書ける範囲内から日本語版記事として検証な可能な出典を付けて育てた方が有益です。--MAYA08会話) 2020年5月25日 (月) 08:30 (UTC)

翻訳したい記事の参考文献を入手・閲覧できない際の対応について[編集]

はじめまして。Eugene Ormandyと申します。翻訳について質問なのですが、翻訳したい記事の参考文献が入手・閲覧できない場合、翻訳は避けるべきなのでしょうか。それとも、「プロジェクトに携わる人々は、たいていの場合、それを台無しにしようとしているのではなく、手伝おうとしているのだ」という善意にとるの精神に則り(翻訳元記事の作成者を信頼して)翻訳を行うことができるのでしょうか。関連する過去の議論がありましたらご教示いただけると幸いです。FAQガイドライン翻訳者の広場や井戸端の過去ログなどを概観しましたが、この話題は登場していなかったので質問させていただきます。よろしくお願いいたします(なお、ウィキペディア全体に関わる話かと判断したので井戸端に投稿いたしましたが、場違いでしたら申し訳ありません)。--Eugene Ormandy会話) 2020年5月22日 (金) 11:59 (UTC)

コメント 私は「翻訳元記事の作成者を信頼して翻訳を行」ってしまっていますが…。興味とある程度の知識がある分野のものを翻訳しているので、おかしかったら多分違和感を感じるでしょうし、ウィキペディアの別の記事などでも色々と確認をとるようにはしています。ですので今のところ特に問題は起きていないと思います。仮に「翻訳したい記事の参考文献が入手・閲覧できない場合、翻訳は避けるべき」であるとすれば、私はほぼ何も翻訳できません…。--Atmark-chan </稿> 2020年5月22日 (金) 14:17 (UTC)
コメント すべての文献を集めて裏を取ってから翻訳記事を書くのは困難で、多くの場合非現実的です。ほとんど外国の文献でしょうし。また逆にすべての文献を集めることができるなら、それはもう翻訳に頼らず自分で一から記事を書いてしまうほうが手っ取り早いし正確でしょう。ある程度自分で関係資料を読んで理解することは大事ですが、結局はAtmark-chanさんのおっしゃるように翻訳元を信頼するしかないです。ちなみに、研究論文レベルの文書でも「○○氏によれば、『』である。」という引用的な書き方も参考文献さえ明記すれば認められますよね。その内容が実は間違っていたとしても、ある範囲の○○氏の記述が原因である、と遡って突き止められるわけです。実はWikipediaの翻訳における履歴継承も同じことをしているわけで、翻訳記事に内容的な誤りがあればそれは翻訳元に問題がある、翻訳元を見れば元の作成者が文献を誤解したのか文献自体が間違っているか確認できる・・・という論理で、形式的には責任の所在を明確にできるようになっています(機能しているとは言い難いですが)。ですから翻訳者は、翻訳元に自分の確認できる範囲で誤りがないか、履歴を見て荒らしの編集が残っていないか程度を確認したら、現行の手続きにのっとって翻訳記事を作って構わないのではないでしょうか。--McYata会話) 2020年5月22日 (金) 18:31 (UTC)
コメント Atmark-chan様、McYata様、ご教示ありがとうございました。参考文献を確認できない状態での翻訳も、「履歴継承」を根拠として容認されると理解いたしました。一定のクオリティが担保されている記事を中心に翻訳を行なっていこうと思います。ありがとうございました。--Eugene Ormandy会話) 2020年5月23日 (土) 02:04 (UTC)

ウィキペディア日本語版にてウィキメディア・コモンズ側の不適切な画像を発見したときの削除手続きの簡易化について[編集]

質問 さきほど、ウィキペディア日本語版の記事に不適切な画像を掲載している方を見つけました。具体的には、ウィキメディア・コモンズに虚偽ライセンスで画像をアップロードし、ウィキペディア日本語版の記事にて「[[ファイル:ファイル名|オプション]]」とマークアップしてその画像を表示する、というものです。

この場合、ウィキペディア日本語版の記事から画像へのマークアップを編集除去したとしても、画像そのものが削除されるわけではありません。ですので、ウィキメディア・コモンズ側において、別途あらためて削除依頼を提出しなくてはなりません。別プロジェクトだから仕方がないと言えばそれまでかもしれませんが、もう少し効率的なよい方法はありませんでしょうか。

たとえば、当該画像について散々ウィキペディア日本語版側で議論を重ねてきたのに、ウィキメディア・コモンズの削除依頼でまた一から議論をやり直す、……というのは、過去の議論の知見や蓄積が全然生かされないように思います。もちろん、別プロジェクトなので同時に議論できるようなシステム的な対応など不可能なのだろうと思いますが、もしベストプラクティスとかライフハックのような便利なやり方などあればアドバイスいただければと思います。自分としては「ウィキメディア・コモンズにて削除依頼を提出する際、ウィキペディア日本語版で先行議論があればそのページへのリンクを貼って案内する」程度の案しか思いつかなかったので……。--Nnkrkrhhdi会話) 2020年5月23日 (土) 01:55 (UTC)

具体的にはFile:Kurokawa Hiromu 2019-01-29.jpgのことだと思いますがまだ発見されてすぐのようですから、もうしばらく待ってはどうでしょうか。{{LicenseReview}}が付いているため、いずれ管理者がライセンスを判定し、不備があればその場で即時削除されます。その場合Wikimedia Commons側で削除依頼の必要はありません。速いに越したことはないですが誰もがボランティアであるという性質上、あまり結論を急がず様子を見ることも大事ではないかと思います。現時点では、何も追加ですることはない、ということです。(削除依頼をする必要もありませんでした。) --2001:240:241C:59CB:ECAD:3BDC:67DC:A13C 2020年5月23日 (土) 06:04 (UTC)
もうしばらく待ったほうが良かったと思います。ちょうど今の時期だと、この記事にアクセスする方がまだたくさんいるでしょうから、その間だけでもせめて待ってほしかったと思います。公益性を考えれば、この写真が記事に掲載されていることに意義はあると思います。ライセンスに違反するとかどうとか細かい些末な話をするのではなく、もっと大局的な見地から社会の役に立つのかどうかを考え、結論を急がずに様子を見ることも大切だと思います。ライセンスに違反することが明るみになったら、もう記事で画像を使うことができません。現時点での画像の削除は、閲覧者に不便を強いるだけであり、なおかつ政権側にメリットをもたらすという効果しかありません。つまり、ライセンス違反だとわかったとしても、削除依頼をする以外に何かほかに方法はなかったのでしょうか。--126.196.226.9 2020年5月23日 (土) 08:10 (UTC)
この件にもWikipediaの記事全般にも政局的な事情は対処方法に関係しません。 --2001:240:241C:59CB:7C89:B2F3:7B48:CA8E 2020年5月23日 (土) 08:47 (UTC)
ナニコレさんが主体的に整備する大前提の話ですが、プロジェクト:画像を利用しCommonsの過去の削除依頼をまとめて、利用者間で随時情報共有できる環境を作ってはいかがですか?過去の案件がまとまっていれば類似案件が発生時に対応しやすいでしょう。現在はいつどのような依頼があったかすら利用者間で全く共有できていません。またCommonsの削除依頼に精通したUserに声を掛けて丁寧に下から協力をお願いして(断られても丁寧にお礼を言うくらい常識的にお願いし)、削除案件に対応できるネットワークの構築を図ってみては?まずは過去の案件を洗い出してくだされば、将来の利用者が助かるでしょう。--126.163.68.124 2020年5月23日 (土) 08:57 (UTC)
06:06の投稿者=08:47の投稿者である事を書き添えます。IPが変動していたようで失礼しました。 --2001:240:241C:59CB:7C89:B2F3:7B48:CA8E 2020年5月23日 (土) 09:06 (UTC)
コメント そもそも目的外利用が多すぎます。ライセンスに違反していようが、とにかく自分の目的(たとえば政権批判など)のためなら関係ないという発想の利用者を何とかすべきだと思います。そもそもこの緊急事態宣言が発令されている状況であるにもかかわらず(一部解除はされましたが)、政権批判をしたいからといって政権に都合の悪いような画像をライセンス無視して掲載するという行為を許すべきではありません。そういう利用者はさっさとブロックすることによって、そのような問題行為が減り、その結果手間が軽減される、というふうに思いますがいかがですか。--126.197.208.231 2020年5月23日 (土) 09:12 (UTC)
(反対)削除依頼には厳正な審議が不可欠であり、簡易化なんてとんでもない。不都合な画像は今すぐにでも削除したいのでしょうが、そのような意図で手軽に削除されては困ります。--126.198.227.80 2020年5月23日 (土) 10:54 (UTC)
コメント なぜか「政権に都合が良い」とか「政権に都合が悪い」とか、ずれた観点の意見が多い様ですが、ウィキペディアを含むウィキメディア・プロジェクトにとって「どこかの政権の都合」など全く関係のない話だと思います。そんな事より、違法な画像はそもそもアップロードすべきではないし、アップロードされた違法な画像は出来る限り速やかに削除されるべきでしょう。その認識が、この議論の出発点のはずです--aki42006会話) 2020年5月24日 (日) 00:32 (UTC)
返信 (aki42006宛) 「違法な画像はそもそもアップロードすべきではないし、アップロードされた違法な画像は出来る限り速やかに削除されるべき」という意見は、単なる空虚な理想論だと思います。今回の件についていえば、もうしばらく待てばあちらの管理者が判断するのですから、「何もする必要がなかった」というのがいちばん正しい解だと思います。あちらの管理者が判断するまでの間はウィキの記事で画像が掲載できるわけですし、その後で管理者が画像を削除する頃にはウィキの記事も落ち着いているでしょうから、そうすれば結局何も実害はないのです。また、もしまちがえてあちらの管理者がライセンス上問題なしと判断すれば、以降はウィキの記事で大手を振って使えるようになるわけですから、いちいち削除依頼を出すのは寝た子を起こすような行為だと思います。「違法な画像はそもそもアップロードすべきではない」というのはそのとおりですが、だからといってそういう画像をアップロードする人がゼロ人になることはないでしょう。とすればそのような画像について議論が発生するのは、必然です。ですから、必然である以上、違法な画像のアップロードゼロを目指すのは無理だと思うので、なるべく社会全体の労力、つまり、コミュニティに負荷をかけないような方法で削除できるような検討をすべきでしょう。結局、今回の件は、放っておいてもあちらの管理者が削除してくれたのに、ナニコレさんがわざわざ削除依頼を提出した分余計な労力がかかってしまっています。「アップロードされた違法な画像は出来る限り速やかに削除されるべき」なのは確かでしょうが、一秒早く削除するために一時間余計な労力をかけるというのでは、社会が、そしてコミュニティが疲弊してしまいます。「アップロードされた違法な画像は出来る限り速やかに削除されるべき」であるが、そのために極めて甚大な労力を投入せざるを得ないというなら、若干の削除の遅れも許すべきです。今回は、放置の一択でしょう。--126.165.101.243 2020年5月24日 (日) 04:37 (UTC)
横から失礼 横から失礼 「もしまちがえてあちらの管理者がライセンス上問題なしと判断すれば、以降はウィキの記事で大手を振って使えるようにな」ってしまってはそれこそ問題では? ライセンスの問題は法的な問題ですから、そんな判断ではいけないと思います。問題があると薄々気づいておきながら見て見ないふりというのは無責任になってしまいますが…。--Atmark-chan </稿> 2020年5月24日 (日) 04:58 (UTC)
コメント 126.19x変動IP氏にはc:Commons:First_steps/Contributing/jac:Commons:First_steps/License_selection/jac:Commons:Deletion_policy/jaでも読んでもらうとして、依頼者126.163.68.124様が提案された、コモンズ削除依頼判例集を整備することに賛成します。現状、AFDにおいてYouTuberのAFD判例集などのページが役に立っていることから、有効ではないでしょうか? --Semi-Brace会話) 2020年5月24日 (日) 03:33 (UTC) 修正 --Semi-Brace会話) 2020年5月24日 (日) 05:59 (UTC)
質問 ナニコレさんはどうするつもりなのでしょうか。提案するだけしておいて、これほど多数の反論が集まったらだんまりですか? 撤回するならするできちんとナニコレさんは意思を表明してください。そのうえで、これはご本人の気持ち次第ではありますが、もし仮にナニコレさんが謝罪すべきとお考えになったのであれば、この場で謝罪すべきかと思います。あるいは、もし仮にナニコレさんが反論すべきとお考えになったのであれば、この場で反論すべきかと思います。--126.165.101.243 2020年5月24日 (日) 04:37 (UTC)
「ナニコレさん」って誰の事かと思ったら、本件の提案者であるNnkrkrhhdiさんのことですか。ご本人がそう名乗っているわけでもないのに失礼過ぎますよ。--ホーリーブライト会話) 2020年5月25日 (月) 06:26 (UTC)
  • (コメント)IPの方々に警告します。これ以上ライセンス違反画像の放置を容認するような発言をしたら直ちに管理者伝言板に通報します。--6144会話) 2020年5月24日 (日) 12:22 (UTC)
  • コメント そもそもコモンズでは明確にアウトなら大抵のものが即時削除できるルールになっています。皮肉ではなく真面目な話として、一度Commons:削除の方針に目を通すことをお勧めします。--Marine-Bluetalkcontribsmail 2020年5月24日 (日) 16:30 (UTC)
  • 【コメント】コモンズの管理者は(ウィキペディア日本語版に比べると)割といい加減です。即時削除すべきものを削除しなかったり、削除してはいけないものを即時削除したりすることも多々あるため、そういう場合は削除依頼を提出するしかないでしょう。(向こうの管理者は、転載元が日本語ページだった場合はわりと判断いい加減ですよ。日本語理解できないのに削除可否を判断してる人が多いですからね。はっきり言って勘で削除してるような輩もいます。しかも判断間違えても「日本語話者じゃないから、日本語ページの内容理解できなかったんだもん」って開き直りますからね。周りも「日本語話者じゃないからしょうがないよ。判断ミスを責めるのをやめましょう」みたいな甘いこと言ってますが…でも、転載元の内容が理解できないなら、そもそも削除に手を出すなよと思います。ほかの日本語わかる管理者に任せればいいのに、なぜ日本語わかりもしない人が頼まれてもいないのに突撃してるのか意味がわからない……。同じことをウィキペディア日本語版でやったらどうなるでしょう。ウィキペディア日本語版の管理者が「転載元が英語ページだったから意味わからなかったので、勘で削除しました」とか言ったら、袋叩きだと思いますけどね。)--126.162.31.104 2020年5月26日 (火) 08:26 (UTC)

日本の公務員の職務著作物について[編集]

議論しているのはこの画像のことですか?
  • 質問 議論しているのはこの画像のことですか? この画像は公務員が職務上作成し、かつ、それを職務の一環として公開しているわけですが、それに著作権が生じますか? --126.189.92.157 2020年5月28日 (木) 01:09 (UTC)
    • 公務員の作成した画像であっても当然、著作権は生じ、職務著作物であれば、著作権者は帰属先の組織となると思います。検察庁ホームページ利用規約で「準拠」と言及されている「政府標準利用規約(第1.0版)」の画像をコモンズで受け入れ可能かについての議論が過去にあったはずです。探して後ほど紹介します。--miya会話) 2020年5月28日 (木) 02:56 (UTC)

ここで問題とされている検察庁由来の画像は、とりあえずライセンスタグをc:Template:Gjstu-2.0からc:Template:GJSTU1に変更すべきと考えます。--miya会話) 2020年5月28日 (木) 03:54 (UTC)微修正--miya会話) 2020年5月28日 (木) 03:56 (UTC)

  • 質問をする時点で職務著作物の概念を根本的に勘違いしていますので、当該項目を熟読してください(職務著作物は著作権が免除になるような概念ではない)。また、miyaさんが提示された議論によっても、サイトによって使用できる画像と使用できない画像が存在することが明らかです。ちなみに対象の画像については[18]に「政府標準利用規約(第1.0版)」とあるので議論の結果NGと結果が出ているようです(「政府標準利用規約(第2.0版)」ならOKのようです)。--6144会話) 2020年5月28日 (木) 11:24 (UTC)修正--6144会話) 2020年5月28日 (木) 11:24 (UTC)
  • Scanyaroさんに「粗雑な要約」とご指摘いただいた問題のある個所を取り消し、打消し線を入れました。--miya会話) 2020年6月2日 (火) 01:38 (UTC)
  • (コメント)c:Commons:井戸端/過去ログ14#明らかに受入不可なファイルについてで一括削除されていたので間違えました。申し訳ありません。ということは当該黒川弘務はOKって理解でいいのでしょうか。--6144会話) 2020年5月28日 (木) 13:39 (UTC)
    • 返信 (6144さん宛) 、私個人としてはYasuさんのc:Special:Diff/196883377の意見に同じで、大丈夫じゃないかと思うけど懸念があれば削除依頼(即時削除じゃなく)を出して下さい、というものです。◇c:Commons:井戸端/過去ログ14#明らかに受入不可なファイルについてで「一括削除されていた」のは「第三者が著作権を有している」もの・「政府標準利用規約がまだ導入されていない」(1.0すら未導入)もの・「出典元が不明な」ものであり、「政府標準利用規約(第1.0版)適用のため移行不可」なものは「削除依頼を提出」(実際にはcopyvioのsdタグ貼り付け)なさったようですが、いま二つほど履歴をみたところ、あっさり差し戻されてそのまま、削除はされてないようです。--miya会話) 2020年5月29日 (金) 04:48 (UTC)
      • (コメント)了解いたしました。--6144会話) 2020年5月29日 (金) 12:57 (UTC)修正--6144会話) 2020年5月29日 (金) 22:00 (UTC)

コメント とりあえず下記の削除依頼にライセンスタグのエラーであるとコメントをつけてきました。--miya会話) 2020年5月29日 (金) 06:27 (UTC)

(追記)c:Category:GJSTU(1.0)の画像が多数コモンズで受け入れられていることが確認できましたので、あらためて存続意見をつけてきました。--miya会話) 2020年5月29日 (金) 07:02 (UTC)

コメント 「不適切な画像を発見したときの削除手続きの簡易化」という大そうな話題になっていたので、気になりました。アメリカ合衆国職員の著作物については、フェアユースという考え方以前に、パブリック・ドメインで公表されているので問題ありません。一方、日本の中央官公庁の作成した著作物は、かなり昔、著作権表示されて自由に使うことを禁止していました。政府標準利用規約(第2.0版)が平成28年5月18日に制定されたという情報をここで知ることができたので、みなさんに感謝します。--Green会話) 2020年5月29日 (金) 11:48 (UTC)

コメントmiyaさんありがとうございます。政府標準利用規約1.0だから削除しろ、そのような了見の狭いことをいうような人がこれで駆逐されることを願います。公益のため黒川前検事長の画像が削除されずに存続となることを願っています。また、かつて政府標準利用規約1.0はウィキペディアコモンの規約上受け入れられない!ウィキペディアに本番でEDPというのをを作成して運用する以外方法ない、オープンデータ周辺の人の間では政府標準利用規約1.0ではウィキペディアコモンに投稿できないのが常識、とのたまっていたKs aka 98さんなど一派は全員ブロックしていただきたい。miyaさんの言っていることが正しければ、Ks aka 98さん一派は嘘をついていたことになります。こんなことが許されるのでしょうか。黒川前検事長の画像など貴重な画像がどんどん削除されようとしています!!!!--126.162.253.138 2020年5月29日 (金) 13:06 (UTC)

すみませんが、話をややこしくしないでください。どんなに貴重な画像であれ、コモンズの方針に反する画像は受け入れられません。--miya会話) 2020年5月29日 (金) 14:48 (UTC)
質問 「ウィキペディアコモン」じゃなくて、「ウィキディア・コモン」じゃないんですかねぇ……。それはともかく、「ウィキペディアに本番でEDPというのをを作成」との話が気になり検索すると「Commons:井戸端/過去ログ11」がヒットします。かつてmiya氏はコモンズで同様の主張を展開していたようですが、Ks aka 98氏に「政府標準利用規約(第1.0版)は、オープンデータ周辺の人の間では、「3) 禁止している利用について」にある「コンテンツに関し、以下のように利用することは禁止します。/ア 法令、条例又は公序良俗に反する利用/イ 国家・国民の安全に脅威を与える利用」によって、CC-BY非互換であり、厳密にはオープンライセンスではない(したがってオープンデータでもない)と理解されています。同様に、自由文化作品とも言い難く、現状、コモンズには取り込めないリソースと捉えるのがよい」と指摘されてしまい、以降はぐうの音も出ず反論できずそのまま議論がまとまってしまってますね。江戸の仇を長崎で取るって気持ちかもしれませんが、コモンズ側で議論に参加し自分の主張が否定されるからって、こんどはウィキペディア日本語版の井戸端で反論するってのは何の生産性もないと思いますけど。miya氏がコモンズの受け入れ方針にケチ付けたいんだったら、だったらコモンズ側で再提案すべきでしょ? こっちの井戸端で自説主張しても意味ないと思いますけど。--126.215.184.48 2020年5月30日 (土) 05:31 (UTC)
コメント 誰だかわからないと言われたので、アカウント取りました!ウィキペディアコモンズの話題だとは言っても、ウィキペディア日本語版に関係のある話題なのだから、日本語版で議論しても何の問題もないでしょう。意味がないことはありません!ウィキペディア日本語版に関係があっても、ウィキペディアコモンズでしか議論できないのだとしたら、そちらの方が問題でしょう!それから、ウィキペディアコモンズでmiyaさんが反論できなかったとか言ってますが、そういう揚げ足とるのはやめてください。結局今になって振り返ってみれば、1.0をアップすることに肯定的だったmiyaさんの意見が正しく、1.0をアップすることに否定的で2.0ならアップしてよいという方向で発言していたKs aka 98さん、KAMUIさん、VZP10224さん、Scanyaroさん、Kkairriさん、Dwyさん、Sakoppiさんの意見が間違っていた、というただそれだけのことだと思います!あと「ウィキペディアコモン」じゃなくて、「ウィキメディア・コモンズ」じゃないのかとか、いちいち揚げ足を取るのはやめてください!過去の履歴を晒して批判するのはマナー違反じゃないでしょうか。--AgainstSPRetirementAgeExtension会話) 2020年5月30日 (土) 06:16 (UTC)
返信 揚げ足を取るななどと言っていますが、そもそもコモンズの前述の議論はオープンな場でなされており、かつ、ライセンス等の注意喚起等も読んだうえで投稿されてるんですから、他人の目に晒されるなんて承知の上でみんな投稿してるんでしょ。それを提示しただけで、揚げ足取り呼ばわりはおかしいでしょう。miya氏がコモンズの井戸端で上記のような主張をし、それに対してKs aka 98氏から前述の主張がなされ、その結果miya氏は何も反論できず議論が終結したのですから。miya氏がこの結論に納得できず、別プロジェクトからコモンズの議論内容を否定するなら、いつまでも納得しないに該当するだろうからさっさとブロックすればいいでしょう。それに、Ks aka 98氏、KAMUI氏、VZP10224氏、Scanyaro氏、軽快氏、Dwy氏、Sakoppi氏は、いずれも2.0からコモンズ受入可能であることで一致してるわけですから、多くの利用者からもコンセンサス得ていると言えるんじゃないでしょうか。miya氏が独りで主張するのは勝手でしょうけど、コモンズの井戸端で議論の結論に不満があるからと言って、別プロジェクトで自分の主張を広めようと画策するのはばかげていると思う。あと「ウィキディアコモンズ」じゃなくて、「ウィキディア・コモンズ」だと言ってるでしょうが。--126.197.190.87 2020年5月30日 (土) 08:48 (UTC)
(コメント)警告します。「バカげている」で終わりなら個人攻撃です。面倒でも「コモンズ側で再提案すべき」と明示してください。--6144会話) 2020年5月30日 (土) 11:35 (UTC)
返信 個人攻撃だなどと言っていますが、別にmiya氏がバカだと言ってるつもりは全くなく、miya氏の言動がバカげていると言っているんでそこはわかってほしい。別に人格そのものを攻撃してるわけではなく、この井戸端のページでの言動について批判しているだけ。反対意見を言われて個人攻撃だといきり立つのでは議論にならない。たとえば、ちょっとよく考えてほしいんですけど、miya氏は「c:Category:GJSTU(1.0)の画像が多数コモンズで受け入れられている」からセーフだと主張してます。かつてここまで「ガバガバ理論」を展開した人がいたでしょうか。やってる人が多いからセーフ、と言いたいんでしょうけど、自分で「これこれこうだからセーフ」とロジカルに語るのではなく、ただ単に「やってる人が多いからセーフ」なんて理由は、そもそも理由になってない。だったら、ウィキペディア日本語版に他文献からまるごと転載して記事を作る人は後を絶たないわけですが、「他文献からまるごと転載する人が多数いる。多数いるので転載はセーフ」とはならんでしょ? 当たり前の話ですよ。信号無視する人が100人いたら違法だが、信号無視する人が1億人になったら合法、とはならんでしょ。よく考えてください。仮に「c:Category:GJSTU(1.0)」に多数1.0の画像が存在したとしても、ただ単にコモンズの規約を無視している人が多数いるだけかもしれない。それなら多数画像が存在してもアウトでしょう。仮にあるカテゴリ内に画像が少ししかなかったとしても、これから画像がアップされていく発展途上なだけかもしれない。それなら画像が少なくてもアウトとは限らないでしょう。数で左右されるわけないじゃないですか。1.0画像をアップする人が少ないならアウトだけど、1.0画像をアップする人が増えてきたからセーフ、なんて言う理屈が通用するとでも思っているんでしょうか。単に迎合してるだけじゃないですか。たとえば、ウィキペディア日本語版である行為が方針やガイドラインに抵触するかどうかが議論になった場合に、「やってる人が多いからセーフ」なんて言う人がいましたか? それに、コモンズの井戸端での議論の結論に不満があるからと言って、別プロジェクトで自分の主張を広めようと画策するのは全く理屈にあわない言動でしょ。だって、その議論にmiya氏自身も参加してたわけですよね。自分が参加する議論で思い通りの結論にならなかったからといって、数年後に別プロジェクトでブツブツ文句を言ったり自分の主張を広めようとするのが正当な言動とは思えません。だったらmiya氏自身が議論に参加してた時点で、反論すればよかったわけですよ。--126.250.205.119 2020年5月31日 (日) 05:25 (UTC)
コメント 個人攻撃だと勘違いされてしまうかもしれませんから、もう一度言っておきますね。別にmiya氏がバカだと言ってるつもりは全くない。miya氏自身が議論に参加してた時に、ご自分で反論すべきでした。反論が一切できなかったなら、議論の結果を受け入れてください。ガバガバでゆるゆるな理屈を振りかざして、別プロジェクトで文句言っててもしょうがないでしょ。それだけのことです。--126.250.205.119 2020年5月31日 (日) 05:34 (UTC)

政府標準利用規約第1.0版について[編集]

Scanyaroさんへ:長くなるのでここに小見出しをいれてインデントを戻させていただきました。ご了承いただければ幸いですが、不適切だとお考えなら取り消していただいても、あるいは別の小見出しに変更していただいても結構です。--miya会話) 2020年6月2日 (火) 02:09 (UTC)

コメント 勝手に名前を出され通知が届きましたので、少しコメントさせていただきます。ウィキメディア・コモンズでの議論に参加させていただく機会があり、Ks aka 98さんたちのお話しを伺い、少なくとも政府標準利用規約(第2.0版)であればアップロードしてもよいとの考えに至った者です。こちらでmiya会話 / 投稿記録 / 記録さんは「1.0はCC互換とはいえない、という議論はありましたが、別にCC互換じゃなくてもOK」と仰っていますが、あちらではCC互換か否かという点だけが問題となっていたわけではありません。そのほかの発言含め、誠実性に欠けた乱暴な要約かと思います。「Template:GJSTU1」については、削除依頼を提出した私の拙い英語もあり削除に至っておらず、お恥ずかしい限りですが。--Scanyaro会話) 2020年5月30日 (土) 15:01 (UTC)

返信 「削除依頼を提出した私の拙い英語もあり削除に至っておらず、お恥ずかしい」とのことですが、なら無理して削除依頼を出さなくても他の人に削除依頼を出させればよかっただけでは。英語がわからないなら、そもそもそういうことをやるべきじゃないでしょ。別に依頼提出の義務があるわけじゃないので、誰かがだすでしょ。--126.250.205.119 2020年5月31日 (日) 05:27 (UTC)
  • (コメント)「miya氏がバカだと言ってるつもりは全くなく、miya氏の言動がバカげている」「miya氏がバカだと言ってるつもりは全くない。miya氏自身が議論に参加してた時に、ご自分で反論すべきでした。」(←過去形)は明らかに詭弁なので管理者伝言板に通報…と行きたいところですが、IPを調べると126.192.0.0/10とあまりにも広く、ホスト名としても*.access-internet.ne.jpとなりソフトバンクのモバイルルーター網全部がブロックとなってしまい影響が大きすぎるので保留します。--6144会話) 2020年5月31日 (日) 06:03 (UTC)
    返信 (6144さん宛)  当時の過去ログを読んだ方にはお分かりいただけると思いますのでどうぞおかまいなく。--miya会話) 2020年5月31日 (日) 06:38 (UTC)
  • (コメント)ご厚意感謝します。--6144会話) 2020年5月31日 (日) 08:24 (UTC)修正--6144会話) 2020年5月31日 (日) 08:25 (UTC)

返信 (Scanyaroさん宛) :「誠実性に欠けた乱暴な要約」とのご批判は真摯に受け止めます。c:Commons:井戸端/過去ログ11#日本の省庁が公開しているコンテンツのコモンズでの利用について」の最後の印象が強くて上のように要約してしまいましたが、確かに迂闊で乱暴な要約でした。申し訳ありません。過去ログをリンクすれば皆さんが直接確認してくださるだろうと乱暴にはしょってしまいましたが、ここであらためて詳しくご紹介したほうが良いでしょうか?--miya会話) 2020年5月31日 (日) 07:09 (UTC)

コメント 言葉足らずで誤解を与えたのなら申し訳ありません。私は、miya会話 / 投稿記録 / 記録さんに対して詳しく紹介してほしいとお願いしているつもりはありません。議論の根幹にかかわる点についての粗雑な要約などを拝見するに、誠実に議論に参加するような態度とは思えませんので、おやめになった方がよいのではと老婆心ながら申し上げた次第です。また、当該トピックの最後の印象が強かったからだ、と釈明しておられますが、あちらで最後に発言されたVZP10224さんもCC互換か否かだけに主軸を置いて論じているわけではないでしょう。miya会話 / 投稿記録 / 記録さんは、こちらで「1.0はCC互換とはいえない、という議論はありましたが、別にCC互換じゃなくてもOK」と仰るなど、あたかもCC互換か否かが主要な論点であるかのような発言をなさっていますが、これはやや誤解を招く発言ではないかと危惧します。あちらの議論では「CC互換か否か」だけを問題視していたわけではありません。「利用条件が付いているからオープンライセンスではないのでは」という点が主要な論点だったと記憶しておりますが、miya会話 / 投稿記録 / 記録さんはいかがお考えでしょうか。CC互換でなくとも受入可となる場合もままありえるでしょうが、フリーライセンスでなければそもそもあちらでは受け入れられないでしょう。--Scanyaro会話) 2020年6月1日 (月) 07:48 (UTC)
「粗雑な要約」とご指摘いただいた箇所について、確かに粗雑であったと反省し、取り消し・打消し線を入れました。ほかにも不正確な個所がありましたらどうぞご指摘ください。よろしくお願いします。◇ただ、私は自分がライセンスについて議論するのに向いているとは自分でも思っていません。自身の会話ページに知らせがあり、だれもコモンズの議論を紹介していないので、紹介に至ったのです。◇「フリーライセンスでなければ」という点については、あらためて確認します。--miya会話) 2020年6月2日 (火) 02:09 (UTC)
情報 なお、政府標準利用規約の取り纏めにあたっては、高度情報通信ネットワーク社会推進戦略本部の電子行政オープンデータ実務者会議が中心的な役割を担っています。第2.0版へのバージョンアップの際、その趣旨説明において「国際的にオープンライセンスとみなされるよう、禁止条項を削除し」たと述べています。つまり、ライセンスの作成者自身が、以前はオープンライセンスではなかったが第2.0版からオープンライセンスとなったことを認めているのです。第2.0版の審議過程においても、以前の版はオープンライセンスではなかったとの指摘がなされています。一例として、電子行政オープンデータ実務者会議の審議において、電子行政オープンデータ実務者会議構成員の渡辺智暁氏が、第2.0版以前の版について「政府標準利用規約には制約がついており、国際的にオープンなライセンスには該当しないため、その条件で提供されるデータもオープンデータとはみなせない」(『高度情報通信ネットワーク社会推進戦略本部第9回電子行政オープンデータ実務者会議議事要旨』2015年2月10日。)と発言していることも申し添えておきます。--Scanyaro会話) 2020年6月1日 (月) 08:51 (UTC)
コメント オープンでないからと言って、それが何か問題なのですか? 議事録とか趣旨説明とかを片手に相手をやりこめようとするのは感心しません! miyaさんの揚げ足とるのはやめてください。いつまでも納得しないのはScanyaroさんのほうでしょう!(パスワード忘れにより、新アカウントです。)--アゲいんすと会話) 2020年6月2日 (火) 01:04 (UTC)

Some CSS for Vector has been simplified[編集]

こんにちは!

I'd like to make a double-check about a change that was announced in Tech/News/2020/21.

Over-qualified CSS selectors have been changed. div#p-personal, div#p-navigation, div#p-interaction, div#p-tb, div#p-lang, div#p-namespaces or div#p-variants are now all removed of the div qualifier, as in for example it is #p-personal, #p-navigation …. This is so the skins can use HTML5 elements. If your gadgets or user styles used them you will have to update them. This only impacts the Vector skin.

On this wiki, this impacted or still impacts the following pages:

How to proceed now? Just visit all these pages and remove div before these CSS selectors if it hasn't been removed so far.

お願いします! SGrabarczuk (WMF)会話) 2020年5月25日 (月) 12:59 (UTC)

チェック done. Thanks for your notice! --Marine-Bluetalkcontribsmail 2020年5月25日 (月) 15:22 (UTC)

他言語版へのリンクが表示されない[編集]

記事の左下に他言語版の記事と紐づけができる項目が表示されないのですがどうしたらよいですか?既に紐づけされている記事は表示されますが、そうでない記事が表示されません。--玄海093会話) 2020年5月26日 (火) 13:26 (UTC)

どの記事で表示されないのか、具体的に教えていただけると助言しやすいです。よくある現象としては、ウィキデータを編集したばかりでウィキペディア側に反映されていない場合、その記事を空編集してキャッシュを破棄すれば表示されます。--Doraemonplus会話) 2020年5月26日 (火) 13:35 (UTC)
  • コメント 具体的にどの記事でしょうか?まず他言語版にない記事は当然紐付けはありません。仮に他言語版にあるのに紐付けがない場合は作業が必要になります。具体的に言うと、その紐づけ、と言うのはウィキデータ、と言うのを使用して行われます(全言語版統一)。
例えば、日本という記事はウィキデータの「Q17」番と紐づいており、その「Q17」と日本語版での「日本」、英語版での「Japan」、スペイン語版での「Japón」、アイルランド語のAn tSeapáin・・・が紐づいている、と言う形です。
仮に日本、の左下にそのリンク群が表示されないのであれば、原因として考えられるのは
  • 日本語版の日本がウィキデータのQ17と紐づいていない
  • 他の言語版(例えば英語)のJapanがウィキデータのQ17と紐づいていない
  • そもそも他の言語版に「日本」に相当する記事がない
のどれかです。具体的にどれなのかは、調べてみないとわかりません。--Q8j会話) 2020年5月26日 (火) 13:40 (UTC)
金春燮は朝鮮語版に記事がありますが表示されませんでした。(ほかの方が追加してくださいましたが)他言語版にその記事がなくても、他言語版を検索する機能があったのですがそれが表示されません。空編集してみてもだめです。--玄海093会話) 2020年5月26日 (火) 13:43 (UTC)
  • 今までは他言語版への紐づけはWikipediaで完結したと思うのですが、既に他言語版へリンクされている記事(朝鮮労働党中央軍事委員会)などで編集してみるとウィキデータへ飛ばされました--玄海093会話) 2020年5月26日 (火) 14:01 (UTC)
    • コメント (日本語版基準で)ページ左側のメニューリスト下にある「他言語版」表記については、ウィキデータから情報提供できる言語間リンクがある場合に表示されます。ウィキデータ上にリンクされるべき情報がないが、項目自体が存在している場合は、ツール内に「ウィキデータ項目」が表示されます。ウィキデータ項目もない場合は、ウィキデータ上に項目そのものがないということになります。項目そのものがない場合は、ウィキデータ上で新しい項目を作成し、その後他言語リンクをウィキデータ上で行います。かつては[[en:hogehoge]]を本文内に追加して、言語間リンクをしていたこともありますが現在は特別な事情がない限りはウィキデータ経由でのリンクを行っています。金春燮d:Q20445128ko:김춘섭から移入された項目が既に存在していたところを、本日有志の方がウィキデータで追加作業を実施してくれています。ウィキデータ項目とウィキペディア日本語版のページで紐づいたものがない(jawiki側を追加しよう)とするのであれば、ウィキデータ上で行うか、すでに他言語のリンク展開が行われている別言語版のページから行うかのどちらかで追加を行うということになります。--アルトクール会話) 2020年5月26日 (火) 14:33 (UTC)
    • ウィキデータで紐づけを行う件よくわかりました。皆様わかりやすい解説ありがとうございました。--玄海093会話) 2020年5月26日 (火) 14:51 (UTC)

(インデント戻します)

たった今、「en:Royal Hotel, Great Yarmouth」からの翻訳により「ロイヤル・ホテル (グレート・ヤーマス)」を作成したのですが、左サイドバーの「他言語版」欄が表示されず、「ツール」欄にも特段の表示がありません。英語版でも同様です。どう対処すれば良いのかわからないので、こちらにコメントしております。最近仕様の変更があったのか、同様のことが他の記事でもあったように思いますが、どなたかがその後リンクをつないでいただいたので、そのまま放置しています。以前は、他言語版へのリンクがない場合は、提案が表示されていたかと思います。

少し調べて見たのですが、「Help:言語間リンク#他言語版リスト」などにも、現在の形への対処の方法は記載がありません。

わかっている人がわかっていれば良い、という事かもしれませんが、翻訳を手がけることが多い者としては、言語間リンクの結びかたは弁えておきたいので、分かりやすい対処法をご教示いただき、また、Helpか、どこか適切な場所に説明が欲しいように思います。あるいは既にそのような説明があるようでしたら、所在をご教示ください。--山田晴通会話) 2020年5月27日 (水) 21:31 (UTC)

en:Royal Hotel, Great Yarmouth の左側にある Tools の Wikidata item をクリックしてウィキデータに行って入力しておきました。--Jgmo30会話) 2020年5月27日 (水) 22:02 (UTC)
ご対応ありがとうございました。今後は自分でできるように心がけます。自分では十二分に理解していないので具体的な提案はできませんが、やはり、Helpか、どこか適切な場所で説明しておくべきかと思います。--山田晴通会話) 2020年5月27日 (水) 22:22 (UTC)

仕様変更ではなくバグのようです。直るまでウィキデータで直接編集してください。--Afaz会話) 2020年5月28日 (木) 10:00 (UTC)

URLが一部省略されて「...」となっている[編集]

「http://www.allmusic.com/.../roll-over-beethoven-mt00023971...」といったように外部リンクのURLの一部が「...」と省略されている例が散見されます (例1例2例3)。なぜこのような省略されたURLが貼られるのか奇妙なのですが、原因に何か心当たりのある方はいらっしゃいますか? 特定の編集ツールの問題なのでしょうか。省略前のURLが推測できたものについては修正を進めてきましたが息切れしてきました。できれば根本から対処したいところです。--Kto2038会話) 2020年5月26日 (火) 22:59 (UTC)

コメント ぱっと思いついたのは、ある種のサービス(Twitterなど)やある種のブラウザ(例えばいわゆる2ちゃんねるブラウザのようなもの)は投稿内の長いリンクを自動的に変換する場合がある事です。Twitterではいわゆる短縮URLになり、その短縮されたURLをそのままコピーして貼り付けても有効なリンクになりますが、個人開発の2チャンネルブラウザなどではわざわざ短縮URLサービスと連携を取らず単に「...」で中抜きするようなものもあると思います。そんな時、そのブラウザ内でクリックする分には有効だが、文字列自体は有効なURLではない、という事が起こり得るのではないでしょうか。これが根本的な原因だとするなら、対処といっても、投稿者に気をつけて貰うしかないのではないかと思います。--219.102.85.242 2020年5月28日 (木) 07:27 (UTC)
ご意見ありがとうございます。わたしも投稿者の作業環境の問題ではないかと推測しています。検索エンジンで画面に表示された検索結果をコピペしてしまった、などの線もあるのかもしれません。完全になくすことは無理でも、どういうケースでこのような現象が起きるのか特定できれば編集時の注意点としてどこかで呼び掛けることもできるかと思います。--Kto2038会話) 2020年5月28日 (木) 09:17 (UTC)

関連ページの更新情報について[編集]

以前先行議論で、青子守歌さんがおっしゃっていた、特別:関連ページの更新状況/Category:井戸端の話題についてです。
先日、ある投票とコメントを行いました。しかし、こちらがその前述の関連ページの更新情報に反映されませんでした。おそらくですが、サブページのサブページ("Wikipedia:井戸端/subj/~/○○○"より下層のページ)は、カテゴリ化されていないことが多いため、反映されないのだと思います。
上記の流れから今回、井戸端名前空間の提案が見送られると思います。ただこの点については、何らかの対策をして、しっかりとサブページの更新情報も出るようにしたほうがいいのではないでしょうか。--Mario1257会話) 2020年5月26日 (火) 18:10 (UTC) 文の一部修正・分割に伴う修正--Mario1257会話) 2020年5月27日 (水) 18:32 (UTC)

確かにそうですね。井戸端サブページが、すべて同じところにリンクしていればいい、ということだと思います。で、そのページが関連ページの更新状況に入っていなかったのはおそらく通常はTemplate:井戸端サブページ/ヘッダを先頭に貼るので自動的ににカテゴライズされるのが、Wikipedia:井戸端/subj/保護アイコン一新の提案/調査投票では先頭に貼られていなかった、ということが一番の問題だと思います。ですから、対策というと、すべてのサブページにそのテンプレートを張ることを強制する、忘れないようにする、とかそんなことになると思います。--Tmv会話|投稿記録) 2020年5月26日 (火) 23:28 (UTC)
コメント {{井戸端サブページ/ヘッダ}}を貼るのでも良いには良いと思うのですが、ただでさえ多い井戸端のサブページが多いのに、カテゴリページ(例えばCategory:井戸端の話題やそのサブカテゴリ)の見通しが悪くなってしまう気がします。
{{subpages}}を設置したページを作るというのも考えましたが、確か200件までしか表示されないんでしたね。…と思い、サンドボックスでダメ元で試してみましたが、{{subpages}}が特別:前方一致ページ一覧を利用したもので、その関係なのか(?)関連ページの更新状況ではそもそも使えないことがわかりました。--Atmark-chan </稿> 2020年5月27日 (水) 01:22 (UTC)
おそらく{{subpages}}は{{特別:前方一致ページ一覧}}といった感じで作られていると思うので、限界があります。カテゴリが醜くなることを防ぐのであればもう技術的専用のページを作るという方法もありますね。そして井戸端に必ず張り付けるテンプレートがそれにリンクするようにすれば一応そのページの特別:関連ページの更新状況でみんな見れるようになるはずです。或いはみんなWikipedia:井戸端にリンクさせる。その場合、特別:関連ページの更新状況/Wikipedia:井戸端ですべてのサブページの更新状況が見えます。例えば「このページは井戸端のサブページです」みたいな文を書けば井戸端にリンクできますね。ただこれだと井戸端サブページ以外のページの井戸端にリンクしているところも含まれてしまいます。やはりそれ専門のページを作るくらいしかカテゴリを免れる方法はないのでは?--Tmv会話|投稿記録) 2020年5月27日 (水) 01:32 (UTC)
コメント あと考えられるのは、Category:井戸端の話題とは別途でサブページも入れたカテゴリを作成することですね。
あと一つ思ったのですが、現在のCategory:井戸端の話題には「Wikipedia‐ノート:井戸端/subj/○○」が入っておらず少し不便かなと思ったので、上記のようにカテゴリを別途作成するのであれば、ノートページも入れたほうが便利だと思います。
ところで、(カテゴリにしても専用ページにしても)新たにサブページを作る際に「忘れないようにする」ことについてですが、編集フィルターとかが使えるのではないでしょうか。--Atmark-chan </稿> 2020年5月27日 (水) 13:00 (UTC)
コメント 隠しカテゴリを活用できないのでしょうか。ウィキメディア・コモンズでライセンス別のカテゴリが登録されるようなことは可能なのでしょうか。また仮に、サブページに統一のカテゴリを付与させる場合、井戸端の整理(読込除去・自動分割)がbotで行われているように、botを活用すれば編集フィルターも必要ないと思います。
  • @Atmark-chanさん 最初書いたときに忘れていましたが、「Wikipedia‐ノート:」もカテゴリを付与しないとだめですね。補足ありがとうございます。--Mario1257会話) 2020年5月27日 (水) 18:32 (UTC)
井戸端だけのために編集フィルターを使うよりはbotの方が良いですね。隠しカテゴリにしてもいいのですが、その隠しカテゴリのページを開くととんでもなく重い、みたいな状況が想定されますよ。その分Wikipedia名前空間であればそこにリンクしているページはリンク元ぐらいでしか見れませんから、重く成んなくて済むのかな、と。まあどちらでもいいのですが。--Tmv会話|投稿記録) 2020年5月27日 (水) 23:01 (UTC)
コメント まあ確かにBotの方が手軽ではありますね。だとすると、すべてBot任せにしてしまうとBotが反映してくれるまで関連ページの更新状況からは見えないので、やはり「忘れないようにする、万一忘れてしまったらBotの出番」というのが良いですね。既にヘッダがあるページ(「Wikipedia:井戸端/subj」直下のページ)の場合はヘッダにリンクを加えてしまえば良いと思います。
あと、関連ページの更新状況ではリンク元の変更とリンク先の変更が見られますので、専用ページに井戸端サブページへのリンクを集めておくのでも良いのでは。…と思ったのですが、隠しカテゴリの場合と同じように「開くととんでもなく重い、みたいな状況が想定され」ることに変わりはないですね。
「リンク元」で見る(専用ページリンクする)場合は、手軽にリンクを作れる長所の一方で、井戸端サブページ以外からリンクされてしまった場合にそこも映ってしまう短所もある;「リンク先」で見る(専用ページをリンク集にする)場合は、含まれるページを確実に特定できる長所の一方で、ページそのものを開こうとすると重い(可能性がある)短所もある…ということですね。--Atmark-chan </稿> 2020年5月28日 (木) 00:07 (UTC)
コメント 何も深いことを考えず、井戸端のサブページであればどれだけ深い階層であっても {{井戸端サブページ/ヘッダ}} を貼れば済む話じゃないですか?Tmvさんから「カテゴリページ(例えばCategory:井戸端の話題やそのサブカテゴリ)の見通しが悪くなってしまう」という主観的な意見が出ていますが、私はそれ以外のデメリットは思い浮かびません。少なくとも、新しくカテゴリなどを整備するために手間をかけるよりかは格段に合理的な方法だと思います。それから、カテゴリにどれだけ多数のページが入っていても、カテゴリページ自体が分割されるのでページの重さには直結しません。Category:井戸端の話題 には4000以上のページが入っていますが、カテゴリを開いても重くないですよね?--Yuukin0248[会話/投稿記録] 2020年5月28日 (木) 01:33 (UTC)
コメント まあそういうことになりますね。「カテゴリにどれだけ多数のページが入っていても、カテゴリページ自体が分割されるのでページの重さには直結し」ないのは、言われてみれば確かにそうでした。--Atmark-chan </稿> 2020年5月28日 (木) 07:00 (UTC)
コメント もしbotを使うのでしたら、井戸端サブページでヘッダを張っていないやつは自動的にはる、とかそういう動作でいいのかもしれませんね。まあその手間をかけるかどうかは運用者の方にお任せいたします。専用ページもリンク元さえ開かなければ重くないと思うのですが、まあそれを作るほどの労力を使うべきかと言ったら必ずしもそうではない、というのは確かにそうですので、新しいページも作らなくていいですね。--Tmv会話|投稿記録) 2020年5月30日 (土) 01:06 (UTC)
コメント あ、でもアレですね、Category:井戸端の話題で今まで
  • Wikipedia:井戸端/subj/hoge
  • Wikipedia:井戸端/subj/fuga
  • Wikipedia:井戸端/subj/piyo
となっていたのが、サブページを含めると
  • Wikipedia:井戸端/subj/hoge
  • Wikipedia:井戸端/subj/fuga
  • Wikipedia:井戸端/subj/fuga/foo
  • Wikipedia:井戸端/subj/fuga/bar
  • Wikipedia:井戸端/subj/fuga/baz
  • Wikipedia:井戸端/subj/piyo
  • Wikipedia:井戸端/subj/piyo/foo
となってしまうような状況も考えられるので、やはり既存のCategory:井戸端の話題に無闇に追加せず、別途作成(Category:井戸端の話題/サブページ含む(仮)のような感じの)の方が良いのでは。Category:井戸端の話題にそのまま追加した場合、(まだちゃんと確認していないので"目分量"ですが)少なくとも1.5〜2倍くらいには膨れ上がってしまう(「次のページ」を押す回数がかなり増える)気がします。
その場合、サブページでも{{井戸端サブページ/ヘッダ}}を貼るとして、カテゴリ貼付を{{井戸端サブページ/ヘッダ}}内で条件分岐させて
を貼るようにすれば良いのでは。それなら、(既存のサブページへの{{井戸端サブページ/ヘッダ}}の貼付を除けば)整備といっても{{井戸端サブページ/ヘッダ}}の中をいじって新しいカテゴリ作るだけで済むので。--Atmark-chan </稿> 2020年5月30日 (土) 04:11 (UTC)
コメント 確かに {{井戸端サブページ/ヘッダ}} を貼れば一番楽ですが、Atmark-chanさんが言うように無闇に追加すると、カテゴリのページが分かりにくくなると思います。また、サプページのサブページ(以下、話題下層ページ)およびノートページに張り付けた際、Template自体の文章が矛盾し、不自然になってしまうと思います。なので、話題下層ページおよびノートページ用に、新たなテンプレートを作成するのがよいかと思います。--Mario1257会話) 2020年5月30日 (土) 17:30 (UTC)
コメント ちょっと待ってください。新しいカテゴリを作ったとしても、そこには井戸端の直下サブページとそのさらに階部分のサブページが入ることになるわけですよね。そしたら逆効果じゃないでしょうか?つまり今度はCategory:井戸端の話題/サブページ含むがめちゃくちゃな量膨れ上がってしまいませんか?それならば普通のページ(カテゴリページでないページ)へリンクさせた方がリンク元を見なければ重くならないのでいいと思います。第一ヘッダを張るのを忘れたというのがこの議論が始まった根本的な問題なのですからそこに何か対策しないといけませんよね。それはbotということで合意したのでしょうか?してたらすみませんここでの議論は要は関連ページの更新状況に井戸端以下のすべてのページが表示されるようにしたいわけですから、リンク元(とかカテゴリページとか)で井戸端のサブページの名前を全て見る、というのは少し違う気がします。もしそれを議論するなら、この井戸端サブページに新しい節でも作って別途議論するべきでしょう。--Tmv会話|投稿記録) 2020年5月31日 (日) 01:42 (UTC)
コメント リンク元で見る(井戸端サブページから専用ページへリンクする)場合には、井戸端サブページとは関係のないページからその専用ページへとリンクされてしまった際に不都合なのではないかというのが一つ懸念です。例えば、Wikipedia:共有ウォッチリストの解説内でリンクされた場合などもこれに含まれてしまうので、このような場合を避けるには、やはり「リンク集のような専用ページ」か「カテゴリページ」にするしかないような気がします…。
「今度はCategory:井戸端の話題/サブページ含むがめちゃくちゃな量膨れ上がってしま」うのはまあそうなのですが、関連ページの更新状況のためということなので、あまり開くことはないと思いますし。
サブページすべてを表示する「関連ページの更新状況」的な機能がMediaWikiにあっても良いと思うのですがね…。--Atmark-chan </稿> 2020年5月31日 (日) 08:53 (UTC)
作れないものでしょうかね…。phpとかで。まあ確かにリンク元に出るページはみんな「関連ページの更新状況」に表示されてしまうので、Categoryの方が意図的にカテゴライズしなければ出ないという面では良いかも知れませんね。重くならない為にもそのカテゴリはこれからできるだけ開かないようにしましょう。--Tmv会話|投稿記録) 2020年6月1日 (月) 23:38 (UTC)

加筆依頼の除去について[編集]

Wikipedia:加筆依頼における依頼の除去について皆さんにお伺いしたいことがあります。

ある方(以後Aさん)がマンガUP!というweb漫画のサービスに関し、連載されている漫画について最新の情報に更新するよう加筆依頼を提出していました。 これに対し別の方(以後Bさん)が公式サイトの中から連載中の作品のリストが乗っているページのアドレスを載せ、記事内に加筆する必要があるのか?と質問しました(この方は、このページへの外部リンクだけで十分ではないかと仰りたかったのではないかと思います)。 Aさんは少年ジャンプの記事にも同様のリストが存在するため、マンガUP!の記事にもあった方が良いと主張しています。 この状態で、依頼はおよそ半年間放置されていました。(リンク

連載中の漫画の一覧というのは定期的に変更されるものです。 もし仮に、自ら変更に追随し細かく更新していこうという意欲的な方がいらっしゃる場合は、敢えてその方をお止めしようというつもりは私にはありません。 しかし自分ではやる気が全くなく他人に加筆させようという姿勢では、変更に追随するのは不可能です(現に半年放置されているわけです)。

  • 定期的な更新が必要な内容を依頼ページを通じて他人に加筆させようとする行為は、本質的にガイドラインWikipedia:すぐに古くなる表現は使わないに反する
  • Bさんが提示したページへのリンクがあれば、最低限の代用にはなる
  • Aさんは無期限ブロックされているため、この依頼がご本人によりクローズされる目途が無い

こう考えた私はこの依頼をWikipedia:加筆依頼/古い依頼へと転記することなく、直接除去しました。 しかしこれについてIP利用者の方から、(必ず)古い依頼へと移動させるべきだとして差し戻しを受けています。

  1. 例え不適切な依頼であっても、形式的に古い依頼へと転記させる必要があるのか?
  2. 当該の依頼を不適切だとする私の判断に問題は無かったか?

この2点について皆様のご意見をお聞かせ願えないでしょうか。--おいしい豚肉会話) 2020年5月27日 (水) 22:44 (UTC)

コメント まず2.について。「不適切な依頼」という主観的な判断を元に押しきろうとしているので話がこじれているようです。主観的な判断で行動すること自体が悪いわけではありません (なんでも合意をとっていたら作業が進まない) が、その行動に対し物言いがついたのなら、いったん立ち止まり、ノートページなどで議論を提起し、合意を得て、「加筆依頼の取り下げ」をする、という方向に切り替えるべきだったと思います。現在はWikipedia:加筆依頼#マンガUP!111.239.164.66さんが取り下げを提起しているので、これで反論が来なければWikipedia:加筆依頼から除去、と進めていけばいいでしょう。
1.について。Wikipedia:加筆依頼には「加筆されたものや加筆の必要がなくなったものは、リストから除去してください。」「依頼より3か月以上進展のないものは一旦除去され、Wikipedia:加筆依頼/古い依頼へ移動されます。」とあります。「加筆依頼の取り下げ」という結論に至ったのであれば、加筆の必要はなくなったので前者に該当し、ある種の進展があったということですから後者には該当せず、古い依頼への移動ではなく単に除去で問題ないと思います。
最後に。Wikipedia:加筆依頼の履歴を見ましたが、要約欄は議論の場所ではありません。自分の編集内容について見解を述べたり他の利用者に対して意見を述べたりしたい場合はノートページなどをお使いください。--Kto2038会話) 2020年5月28日 (木) 03:34 (UTC)
  • コメント 確かに「常に最新状態に保つように編集を依頼する」というのは加筆依頼の本来の使い方ではないかもしれません。しかし、「更新=追加で手を入れる」ことなのでこれは「加筆」には当たります。つまり、加筆依頼で本来依頼されるべきものの想定が(あいまいにでも)明記されていないから、「加筆」という言葉の意味を取って「更新を依頼」しているとも考えられます。この場合、直ちに除去したとして「差し戻された」のであれば、その点についてノートで議論を起こして(状況によってはWikipedia:コメント依頼も使って)、加筆依頼の想定する依頼とは何ぞやというのを議論深めればよいのでは?Wikipedia:利用案内Wikipedia:調べもの案内Wikipedia:井戸端の使い分けと同じで、最初から明らかに「加筆依頼の対象ではない」と言い切れるものを加筆依頼のヘッダなどに追加するような合意を取るとか、簡単な「依頼の例」でも載せるようにすると少しは違うんじゃないでしょうか。--アルトクール会話) 2020年5月28日 (木) 13:51 (UTC)
  • (コメント)確かに、Wikipedia:加筆依頼には「依頼より3か月以上進展のないものは一旦除去され、Wikipedia:加筆依頼/古い依頼へ移動されます。」としかありません。これではたとえ(某野球選手の記事にホモビデオの詳細を追記してくれみたいな)明らかな荒らしであっても、Wikipedia:加筆依頼/古い依頼に移動しなければならないことになります。ルールの不備と思われますので、必要だと思うならノートで提議した方がいいと思います。--6144会話) 2020年5月30日 (土) 02:12 (UTC)

ラジオ放送局の番組表[編集]

MBSラジオ文化放送ニッポン放送エフエム東京各局の番組一覧の項目にて、過去数年分の番組表が掲載されていますが、最新分のみに絞る事が出来ないのかとつくづく思います。
特に、上記の中のエフエム東京以外の番組一覧の項目ではナイターシーズンとナイターオフシーズンの分が掲載されていて、今年は新型コロナウィルスの影響で日本プロ野球の開幕日が来月19日に決まり、何時閉幕するのかが分からない中で、其の思いが一入強くなっています。--101.142.245.117 2020年5月28日 (木) 23:06 (UTC)

  • (コメント)明らかに過剰記述ですので、気になるようならそちらで消して構わないと思います。--6144会話) 2020年5月30日 (土) 02:18 (UTC)
  • コメント テレビ放送のタイムテーブルと異なって、ラジオ放送のタイムテーブルはその期間内は基本変更されることが少ないものです。レギュラー放送の一覧とみるなら有益の可能性もあります。もし、タイムテーブルを乗せるべきではないとするなら、過去のものか最新のものかに関係なく、「タイムテーブルは載せない」ほうがいいですし、最新版はそれこそ公式サイトへ適切なリンクを促せばいいでしょう。ただ「内容過剰」で除去するべきかではなく、タイムテーブルの記載が百科事典として必要か不必要か(載せるなら載せる理由が示せるのか)という点で議論を深めるほうが良いかと。タイムテーブルは確かに内容過剰で除去してしまっても個人的には構わないと思うのですが、タイムテーブルにはその時期にどの放送がレギュラーであったかを示す一覧記事の性質も持ち合わせるため、資料として有益ならば除去するよりも整備方法を議論したほうが良いかと考えます。--アルトクール会話) 2020年5月31日 (日) 15:31 (UTC)

ABEMA TIMESは信頼できる情報源か[編集]

AbemaTVの番組情報やニュースなどを配信する「ABEMA TIMES」は信頼できる情報源に当たるか、もしくは当たらないのか、という話題です。

現在議論中となっている「Wikipedia:削除依頼/ツイフェミ」にて、Aiwokusaiさんtottiさんは同サイトを信頼できる情報源にあたると見ている一方で、さえぼーさんTakabegさんは信頼できる情報源には当たらない、タブロイド新聞やゴシップ誌、バイラルメディアのようなものであるなどと判断しており一種の食い違いが生じています。私個人としては、出典として使われている同サイトの記事が、在京キー局であるテレビ朝日サイバーエージェントが出資しているAbemaNewsにおいて放送されたものをまとめたものであることから([19][20][21])、信頼できる情報源にあたるといえると判断し当該削除依頼において意見を投じましたが、今回のツイフェミにおける場合に限らずABEMA TIMESは果たして信頼できる情報源にあたるのかどうか皆さんの意見をお聞ききしたく井戸端に投稿させていただきました。

  1. 基本的には信頼できる情報源にあたる
  2. ニュースなどはあたるが、それ以外の場合は状況によって異なる
  3. 基本的にゴシップ誌などと同様で信頼できる情報源にはあたらない

こういったケースがあると思いますが、みなさんの意見をお聞かせください。--333223wid会話) 2020年5月29日 (金) 14:00 (UTC)修正--333223wid会話) 2020年5月29日 (金) 14:03 (UTC)--333223wid会話) 2020年5月29日 (金) 16:28 (UTC)

コメント 私しんぎんぐきゃっとはツイフェミにてABEMA TIMESをソースにした編集を加えた当事者であり、「Wikipedia:削除依頼/ツイフェミ」にて議論が起こった原因は私にあります。私がそれを引用に足るソースと考えた理由を述べたいと思います。 ( 感謝 その前に、有用な議論の場を作ってくださった333223widさんに感謝します)

まず、信頼出来る情報源かどうかについて。 333223widさんも指摘されるようにAbemaTVは在京キー局であるテレビ朝日とサイバーエージェントが出資している、「インターネットのテレビ局」です。視聴者目線では既存のテレビとの違いは地上波かネットか、という点に限られるように思います。ニュースもANNの素材を用いており、編集中にも閲覧しましたところ報道ステーションが放映中でした。細かく見れば違いはありますが、ほとんどテレ朝のネット版と言っていいでしょう。AbemaTVの信頼は親会社のテレビ朝日が保証していると見ていいはずです。

次に、検証可能性について。

上の論拠から、AbemaTVについては既存のテレビ局と同じ扱いでいいでしょう。既存のテレビと同じく、WP:TVWATCHで示されているように「AbemaTVで観た」は当然検証不可で情報源に相応しくありません。しかし、AbemaTVのユニークな点は「テレビ局」でありながらネットメディアであることを生かし、過去の放送のアーカイブ化、記事化に積極的である点です。私が「ツイフェミ」の記事において情報源として引用したのも、AbemaTVで放送された、同じくテレビ朝日とサイバーエージェントが出資するAbemaNewsが作成した番組の概要を文字起こししたもので、ニュースサイト「ABEMA TIMES」にて配信されたものです。「ABEMA TIMES」はAbemaTVが設置するサイトです。たしかに、「これはAbemaTVで放送された内容です」と言われても、過去の放送内容であれば検証不可でしょう。しかし、「 ABEMA TIMES」は記事として残るので、過去の放送内容であっても検証可能です。このあたりはNHK WEB NEWS日テレNEWS24テレ朝newsTBS NEWSテレ東NEWSFNNプライムオンラインを引用するのとあまり事情は変わらないだろうと思います。 以上を踏まえて、私はAbemaTVが放送した内容を自社が文字起こしした記事については、

  1. 基本的には信頼できる情報源にあたる

Wikipediaで情報源として引用するに足ると判断しております。--しんぎんぐきゃっと会話) 2020年5月29日 (金) 15:48 (UTC)

該当の削除依頼でコメントしているので、ABEMA TIMESが信頼できる情報源かどうかについて私の考えを述べます。

  • まず、大元のAbemaですが、これは、333223widさんがおっしゃる通り母体がサイバーエージェントとテレビ朝日ということもあり、既存のTV局同様の信頼性があると考えます。
  • 次に、ABEMA TIMESの検証可能性ですが、現時点では特にログイン無くとも閲覧可能ですので問題ないでしょう。ただし、最近保管の形式が通常のHTMLから変わっている気がしますので将来に渡って保証されるものではありません。
  • 記事による特筆性の立証についてですが、Abemaの番組の特筆性を立証するためには自己言及となりますので使えません。具体的には、ABEMA TIMESを用いてMリーグの特筆性の立証は不可ということです。それ以外は問題ないでしょう。

以上より、基本的には信頼できる情報源に足ると考えてますが、 AbemaNewsの書き起こしには、①発言者が議論している題材にとって特筆性ある人物か? ②ワイドショー的な番組なので発言者が伝えたいことを話せているか? を考慮して慎重に取り扱うべきです。もし、発言者の著書等があればそちらを出典として置き換えた方が良いと思います。--たびびと551会話) 2020年5月29日 (金) 20:15 (UTC)

井戸端で議論されているということは、一般論としてABEMA TIMESに信頼性があるかどうかということだと思いますが、個人ブログのようなまったく使用不可というものではない反面、専門家の手によって書かれた学術論文のような権威あるものではなく、使用の可否は分野(記事主題や記述)の性質を考慮して考える必要がありそうです(なお、例えばサイバーエージェント運営のバイラルメディアとかは信頼性のあるものとは言えないでしょうし、サイバーエージェントの関与が信頼性の証拠になるかと言えば微妙な気がします)。例えば、医学のような分野では基本的に使用するべきではないでしょうし、逆に大衆文化に関する記事では使用できることもあると思われます(Wikipedia:検証可能性#信頼できる情報源Wikipedia:信頼できる情報源#分野ごとのアドバイス)。また、たびびと551さんのおっしゃっているとおり、書いている(発言している)人物についても考慮する必要があり、ABEMA TIMESに載っているものでも無署名記事の信頼性は相対的に低く、専門家の手によって書かれたものがあるとすれば、その専門家の専門分野に関するかぎり、信頼性は相対的に高くなると考えられます(Wikipedia:検証可能性#何を信頼できる情報源とするか)。--伊佐坂安物会話/履歴) 2020年5月29日 (金) 23:39 (UTC)

  • (コメント)記事内の株主構成を見るとサイバーエージェント55.2%なのでみなさんのおっしゃる通りだと思います。--6144会話) 2020年5月30日 (土) 01:37 (UTC)
  • コメント AbemaTV特定地上基幹放送事業者であるテレビ朝日が出資した株式会社です。また、テレビ朝日はAbemaTVの30%以上の株式を保有する主要株主であるため、テレビ朝日がAbemaTVに深く関与していることは明白です。電波法の規定によって免許を受けた特定地上基幹放送事業者が深く関与した組織が発表した情報ですからね。信頼性は高いと言えます。--イトユラ会話) 2020年5月30日 (土) 03:09 (UTC)
    • コメント その理論に基づくと、「講談社系列の日刊ゲンダイは信頼性の高い情報である」が成立してしまいますが、日刊ゲンダイは基本タブロイド紙として扱われるので、方針上は信頼できる情報源になりません。故に、主要株主に信頼できる情報源として成立しうる企業が入っているかどうかは勘案するべきではなく、あくまでその企業・発行媒体が単体で信頼できる情報源かどうかで判断されるべきです。--アルトクール会話) 2020年5月31日 (日) 15:22 (UTC)
      • コメント 「その理論」とは一体どう言った理論でしょうか?具体的な例や根拠を明示し、説明をして頂けると嬉しい。あと「日刊ゲンダイ」は国や地方自治体等の公益性の高い組織或いはそれが認定する組織などとは一切関連しませんし、日本新聞協会にも加盟していない主にゴシップネタを扱う週刊誌です。そんなものは比較対象にならないような気がします。--イトユラ会話) 2020年6月1日 (月) 12:42 (UTC)
        • (コメント)日刊ゲンダイが週刊誌になってしまわれた…まあそれはともかく(まああと講談社だと週刊現代FRIDAYは許されないでしょうね)、例えば徳間書店だとアニメージュがNGだとアニメの記事が大惨事になりますがアサヒ芸能は当然NGなわけです。メディアによってOKとNGが分かれることは当然あり得ます。しかし私の場合、基本的にある会社内でOKとNGが分かれると考えられる場合はNGの方を例外としています。--6144会話) 2020年6月1日 (月) 12:57 (UTC)
  • 元となった削除依頼にも少し書いておいたのですが、私見を書きます。ABEMA TIMESによる番組書き起こし記事を出典とすることは、基本的には推奨されないものと考えます。と申しますのも、それは媒体の信頼性以前に、番組からの孫引きになってしまうからです。しかし、どうもAbemaTVの番組はそのほとんどが放送後無料公開されているようです。ペイウォールに覆われていないインターネット動画を出典とすることは問題はないと記憶しています。従って、原則としては動画の方を第一の出典として時間を指定し他者による検証を容易にしつつ、仮にサービス終了などの要因で動画の視聴が不可能になった場合に備えてABEMA TIMESのアドレスも添えておく、としておけば孫引きの問題については解消されるかと思います。さて、局や個々の番組が信頼できるかという点に移りますが、これは残念ながら現時点では評価が定まっていない、としか言えないのではないでしょうか。従って信頼性は局や番組ではなく、番組内の発言者によって担保する形となるかと思います。今回問題となったツイフェミに関して言うなら、フェミニズムの専門家である千田有紀氏の発言を出典とすることに問題はありませんが、共演者の発言を出典とすることは慎重になる必要があると考えます。--おいしい豚肉会話) 2020年6月1日 (月) 14:42 (UTC)

匿名の作品も著作権で保護されているので、File:2ch AA Characters.gifを削除するかもしれません[編集]

ノート:2ちゃんねる § File:2ch AA Characters.gifの削除される可能性で討論に参加するよう招待されています。Psiĥedelisto会話) 2020年6月1日 (月) 01:42 (UTC)

  • コメント ファイル:2ch AA Characters.gifの画像には「どーもくん」の二次的著作物が含まれているように見えるのですけど、PDとして許容できるものなのでしょうか。どーもくんの記事で使われているような写真はWikipedia:屋外美術を被写体とする写真の利用方針で判断されるのでしょうけど。--Strangesnow会話) 2020年6月1日 (月) 03:16 (UTC)
  • @Strangesnow: ご意見ありがとうございます。問題はどーもくんや個性的なキャラクターではありません。すべてのキャラクターは非常にシンプルで、著作権で保護されているのではなく、パブリックドメインであると思います。それぞれが独創性のしきい値を満たしていません。ただし、それらは商標、特にどーもくんです。それらは単純な幾何学的形状のみで構成されています。問題は合成です。アーティストは、これらのキャラクター、表現、言葉を選びました。1個のタイルは著作権で保護されていませんが、壁画は著作権で保護されています。Psiĥedelisto会話) 2020年6月1日 (月) 05:26 (UTC)
    • あなたの重視している問題点、つまり著作権の存在しないパブリックドメインであろうキャラクターを並べたデザインには独創性があり著作権が発生するのではないか、という議題には個人的には強い意見はありません。ただ、ACCS(社団法人コンピュータソフトウェア著作権協会)やCRIC(著作権情報センター)などは「複雑に構成されたアスキーアート作品には著作権が発生する場合もある」という見解のようです。ただ、どーもくんは著作権法だけではなく、デザインが商標登録されているので、commonsでは登録できてもjawpではどうなのでしょう、日本国内では使用できないかもしれませんね。--Strangesnow会話) 2020年6月1日 (月) 06:35 (UTC)


「被依頼者」という言葉[編集]

主に投稿ブロック依頼、コメント依頼で「被依頼者」という言葉をよく見かけます。投稿ブロック依頼であれば、ブロックしたい利用者を、コメント依頼であれば、コメントの対象となる(たいていの場合、何か問題のある行動をした)利用者を指す場合がほとんどです。しかし「被依頼者」という言葉は本来、依頼を受ける側を指す言葉ではないのでしょうか。ブロック依頼であればブロックを実行できる管理者、コメント依頼であればほとんどの利用者こそが、本来の被依頼者であるはずです。私自身もかつて「被依頼者」という言葉を使ったことがあるかもしれませんが、こうした考えもあり、最近は使わないように心がけています。言葉の本来の意味に背いてまで「被依頼者」という言葉を使うよりも、その方の利用者名をきちんと呼ぶほうが、「礼儀を忘れない」の観点からも良いのではないか、と思った次第です。井戸端での雑談のタネとして、ひとつ皆さまの考えもお聞かせ願えれば。--Bellcricket会話) 2020年6月1日 (月) 10:50 (UTC)

私も昔から (被依頼者ってコミュニティのことでは?) と思ってましたが、まぁ合わせて使ってますね…。言い換えるなら、対象者とか該当利用者とかでしょうか。(言い換えずアカウント名を使うか)--Hisagi会話) 2020年6月1日 (月) 11:40 (UTC)
違和感のある表現ですが、やむを得ない面もあるのでは。日本語の文章の書き方として、なるべく主語を書かずに文脈から動作主が読み取れるように文章を書くという方法はあると思いますが、ここではあまり推奨されず、主語を明示した書き方のほうが好ましいのかなと。かといって対象者の性別もわからないのに「彼は」とも「彼女は」とも書けませんし、利用者名を何度も書いたらくどくなる感じはしますね。--Muyo会話) 2020年6月1日 (月) 12:43 (UTC)
コメント Bellcricketさんの、「被依頼者」という言葉を使うよりも、その方の利用者名をきちんと呼ぶほうが良いのではないか、とのご意見に私も同感です。こと日本語では「被依頼者」という硬さを感じさせる呼称であったり、一般的には同等または目下を対象とした「あなた」などの人称代名詞を用いるよりも、そのかたの名前で呼びかけるほうが、敬意や親密さをこめられるように個人的に感じております。相手がどのようなかたであろうとも、またどのような状況で用いるかにかかわらず、ひとを指し示すにあたっては、私は基本的に「利用者名にさん付け」でいきたく考えております。--もかめーる会話) 2020年6月1日 (月) 13:09 (UTC)
あまりにも長すぎる利用者名や、他人を誹謗中傷していたり政治的主張が入っていたりするような利用者名など、依頼文で頻繁に使いづらいという場合もありますね。利用者名に特段の問題がなければ「利用者名にさん付け」でいいと思いますけど。--Muyo会話) 2020年6月2日 (火) 01:40 (UTC)
コメント 言われてみれば確かに「被依頼者」っておかしいですね。私も何も考えず何回か使いましたが、依頼時の形式ばったときとかのみで、普通にコメントするときは(文中でも、{{返信}}の引数にするとき等も)「Exampleさん」みたいにすることがほとんどですね。--Atmark-chan </稿> 2020年6月2日 (火) 02:12 (UTC)