コンテンツにスキップ

Wikipedia:井戸端/履歴20200123

リンクを追加
< Wikipedia:井戸端

これはこのページの過去の版です。Hman (会話 | 投稿記録) による 2017年9月17日 (日) 14:54 （個人設定で未設定ならUTC）時点の版 (→‎"真夏の夜の淫夢"系統に関する記事について: 資料を集め、執筆の準備を行って下さい。)であり、現在の版とは大きく異なる場合があります。

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

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

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

「Fack」は不適切な利用者名に該当するのか

2006年、利用者:Fack~jawiki（会話 / 投稿記録 / 記録）（当時: Fack）さんが不快な利用者名（offensive username）として無期限ブロックされました。しかし、Fackは「ファーク」という人名であり、「事実を述べる」を意味する単語でもあります。ファークさんがウィキペディアにアカウントを登録したら不適切な利用者名としてブロックされた、もしこれがこのような事例であったとすれば、問題ありとせざるを得ないでしょう。なお、その後「Fack」という利用者名はフランス語版ウィキペディアで問題なく使用されております。

過去にWikipedia:投稿ブロック依頼/Fack 解除依頼が提出され、「FackはFuckの婉曲表現として利用される以上、不適切と判断すべき」として解除見送りとなりましたが、実際に「Fack」という単語が「Fuckの婉曲表現」以外の意味で用いられている以上、このブロックは不適切ではないでしょうか。

なお、この件については、過去にWikipedia:井戸端/subj/Usernameblockと言葉狩りにて問題提起がなされています。--Qweft（会話） 2017年8月22日 (火) 12:20 (UTC)[返信]

  • コメント 試しに「fack」をGoogleで検索してみたところ、ニコニコ大百科[1]ではネットスラングおよびNGワード回避目的で「fuck」の意味で使われていると書かれていました。また、Weblio[2]によれば、Weblio英語表現辞典では英国で「fuck」の意味で使われていること、Wiktionary英語版ではやはり英国やコックニーで「fuck」の意味で使われていることが掲載されていました。一方、goo辞書[3]ではランダムハウス英和大辞典で米国黒人の俗語で「真実」の意味で使われていることが掲載されていました。個人的な意見としては、この程度の微妙なラインの単語であれば積極的にブロックする必要はないかと思われます。仮にいたずら等が目的でわざと紛らわしい利用者名をつけたのであれば、その内に他の方針違反でブロック対象になるのではないでしょうか。Wikipedia:利用者名#不適切な利用者名の「他者を不快にさせるような名前」に該当するかどうかは日本語（英単語など日本語でなくアルファベット表記の場合はアメリカ英語がよさそう）で暴言や差別用語など不適切な意味合いの方が一般的かどうかで判断すべきではないでしょうか。--SilverSpeech（会話） 2017年8月23日 (水) 07:45 (UTC)[返信]
  • コメント人名に使われる単語で有る以上、それをブロックするというのは、『特定の名前を持つ人に対する差別』のように、僕には思えます。
というか。例えば、その名前を本名とする人が、どこかの国の大臣あるいは総理(に相当する役職)についた場合、どうするのでしょうか。
『○○の婉曲表現だから』という理由で、違う名前に置き換えて記事を作ったり、そもそも記事作成を禁止したりするのでしょうか。
このページに有るように、日本語では下品だとされる名前であっても、Wikipediaにおいては本名で立項されています。
であるなら、『人名である』という時点で、認めるべきではないでしょうか。上記リンクのような聞き間違えが有るからと、『麻生』という単語を禁止するようなものですから。
加えて言うならば、スウェーデン語では、fackはトレイという意味です。Wikipediaにも記事が有り、グーグル翻訳からもそれは明らかです。
人名で有り、有る言語においては日常用語である文字列を、変な使い方をされる事も有るからとブロックするのは、誤った判断だと僕は思います。--ただのしかばね（会話） 2017年8月29日 (火) 18:36 (UTC)[返信]
  • コメント - 問題無しと考えます。別に「Fuck」でも構わないでしょう。いっそ日本語で「バカ」さんがいても「アホ」さんが居ても構いません。お前がバカなどと言われている訳では無いからです。これを不快に感じる方などはごくごく僅かであり、そんなものをいちいち気にしていては、おちおち筆名を付けられません。さすがにいわゆる「18禁」用語をモロに使っているケースには、まあぶっちゃけ、筆名が「ちんぽ」とかですね。これには抵抗を感じる方が多いでしょうから、適切とは言いがたいでしょうけど。まあ、余程の余程で無い限り、筆名にシステム的な制限を設けるべきではありません。いわゆる所の表現の自由を最大限尊重すると言う奴です。昔も似たような事件がありましたが（よりにもよってわざわざコメント依頼で）、呆れて声も出ない様なネタでした。不快かどうかは所詮、個人の価値観です。余程出ない限りネタにする事自体が馬鹿げていますし、相当に強力な合意が無い限り、改名を強いたりブロックしたりとそう言った事は行ってはいけません。よって当該ブロックは不適切と考えます。現在の基準で言えば、管理者の裁量権を大きく逸脱したブロックです（ただし10年前にこのブロックを担当した管理者に文句は言えません。10年前は、これが普通であったかもしれないからです）。コミュニティのリソースが許すのであれば、実効性は無いかもしれませんが（アホらしくなってjawpなど見限っていると言う可能性が高そうですが）、ブロックを解除し名誉の回復を行うべきでしょう。また、今後は、100%と言えないのであれば管理者は独断で判断せず、投稿ブロック依頼でコミュニティの審議を仰ぐべきです。軽率な管理者や名目だけの管理者などは不要で、むしろ害悪です。同時に、不当である可能性のあるブロックを見かけた利用者はお時間が有れば、解除依頼を提出すべきです。もし見付けたのが管理者なのであれば、裁量での解除や、担当管理者への苦言等を積極的に行って頂きたい。争いになればブロックまたは解除依頼に投げればよろしい。お忙しい事とは思いますが、相互監視は大切な事です。--Hman（会話） 2017年9月10日 (日) 00:21 (UTC)[返信]
  • コメント Category:不適切として投稿ブロックを受けたユーザー名を見ると、この利用者名に限らず本当に不適切と言えるのか疑問に思われる利用者名が散見されます。例えば、利用者:DEFAULTSORTは何が紛らわしいのか理解不能ですし、利用者:いんきんたむしも不適切と言えるほどなのか疑問です。--新幹線（会話） 2017年9月11日 (月) 03:37 (UTC)[返信]
    • 少なくとも新幹線氏ご指摘の2アカウント名について、ユーザーネーム事由でのブロックは不適切と考えます。投稿ブロックの方針には「明白な誤りが無い場合は、"他の管理者によってなされたブロックを、事前の議論なしに解除してはなりません。"」とあります。すなわち、明白な誤りと認められる場合には事前の議論無しに解除しても問題はありません。また、ブロック担当管理者と連絡が取れない場合などもこれに該当します。そもそも従来より、特に議論無く事後報告のかたちで管理者Bが管理者Aの決定を覆す権限行使を行った事はいくらでもあるはずです。こちらをご覧の現役管理者の皆様方におかれましては、お時間がございましたら、不当にブロックされ汚名を被った過去の利用者諸兄の名誉回復について、ご一考頂けたらと思います。--Hman（会話） 2017年9月11日 (月) 21:39 (UTC)[返信]

糸魚川市大規模火災の記事を見て思った素朴な疑問

事件を百科事典にするのはありなのでしょうか？東日本大震災などの災害や事件は全国的に有名ですし、百科事典になるに値すると思うのですが、去年の12月に起きた糸魚川市大規模火災の記事を見て思った素朴な疑問ですが、単なる火災は百科事典に載せるに値するのでしょうか？あのような大規模の火災になったのには住宅が密集していることなどから、炎が燃え広がり大規模な火災につながったと思うのですが、この程度なら東京都心や地方中枢都市でも起こりうると思います。住宅密集地では。このような程度で百科事典にするほどのものなのか気になりました。ご意見聞かせてください。--S2AP1（会話） 2017年8月24日 (木) 11:50 (UTC)[返信]

（題名を補強しました）確かに東京都心や地方中枢都市でも起こりうると思います。でもここ数十年はこれほどの大規模なものは起きていませんでした。各地の防災関係者は現行の防火体制で満足していたかもしれません。そこに今回の火災によって、悪い条件が重なれば、現代でも大規模になってしまうのだということがわかりました。今回の件は、今後の防災の強化のために記録に残しておきましょう。
火災の規模で考えれば、ご指摘のとおり震災によるもののほうが遥かに大きいです。現在は震災記事の中の記述に留められていますが、特定の都市の火災に関する資料が揃いましたら、記事を分割することも可能かと思われます。--Triglav（会話） 2017年8月24日 (木) 12:35 (UTC)[返信]
火災の規模もさることながら、火災による地域への影響、国の対応、報道の量なども百科事典的な記事を書くために重要となりますので、糸魚川市大規模火災は特筆性があると思いますが、火災によってはこれより大きな規模の火災、あるいは死傷者が発生した火災であっても特筆性がない場合もあるでしょう。--Muyo（会話） 2017年8月24日 (木) 13:01 (UTC)[返信]

今回の糸魚川市の大規模火災は特筆性がある規模の火災だったということですね。--S2AP1（会話） 2017年8月25日 (金) 07:52 (UTC)[返信]

コメント 少なくとも、災害救助法と被災者生活再建支援法が適用され、かつ糸魚川市の大町と本町のほぼ全域で30時間ほど燃え続けた火災は単なるボヤではないと考えられます。つい先日起きた火災で全国ニュースになった築地の場外市場火災とは規模も被害も異なります。現在の消防法では大火を10件以上の火災を指すと定義されてはいますが、その中でもとりわけ（人的被害が無かったにせよ）被害が大きかったものといえるでしょう。現在でも補償問題等で取り上げられることもあるので、著名性や特筆性がない火事とは言えないでしょう。--アルトクール（会話） 2017年8月25日 (金) 14:18 (UTC)[返信]

コメント アルトクールさんが指摘しているところが難しいのではないでしょうか？、災害救助法と被災者生活再建支援法が適用され、「糸魚川市の大町と本町のほぼ全域で30時間ほど燃え続けた火災」単なるボヤではないのは事実だと思います。客観的に見ても規模の大きい火災であることに変わりはないと思います。「現在の消防法では大火を10件以上の火災を指すと定義されている」や「補償問題」が疑問に思う部分です。消防法に基づいた場合、10件以上で大火なので特筆性・著名性があると判断するのか、補償問題が取り上げられているので特筆性・著名性があるのかの判断が難しいと思います。大規模火災において補償問題が絡んでしまうのは必然的なことではないでしょうか？前述で東京都心や地方中枢都市の住宅密集地でも起こりうると述べましたが、確かに今回の火災は尋常なものではないのは明らかです。唯一疑問に思うのは、どの部分が特筆性や著名性を持っているかが気になります。--S2AP1（会話） 2017年8月26日 (土) 06:01 (UTC)[返信]

コメント 一部訂正します。消防法で大火を10件以上の火災と書きましたが、消防法ではなく、消防庁告示の「消防に関する都市等級要綱」によるものでした[4]。なので、上記の私の発言を受けた「消防法」を「消防庁告示の消防に関する都市等級要綱」と読み替えてください。以下では「消防庁告示」とします。
補償問題というのはこうした災害には付きまといますが、それが大きくクローズアップされて、少なくない媒体が報じていることが重要になります。「消防庁告示で大火に分類されるから著名性がある」ではなくて、人的被害が無かったにせよ被害面積が大きく、多くの報道機関が取り上げ、かつ補償問題（出火元の責任だけなのかという責任論から、被災者生活再建支援法でどこまで補償できるのかまでさまざまありますが）もクローズアップされている件ですので、第三者出典が集められるので著名性があるといえるのではないか、という結論に達しているのです。大火だから、補償問題があるから、という単独だけで著名性をはかっているのではありません。大火に分類され、多くの被害を出し、補償問題が取り上げられていることが、複数の信頼できる第三者による情報源で示せているから、著名性や特筆性があるでしょうと帰結するのです。
大火というのはものによって評価方法が異なり、焼失面積によるもの（分類のために基準を作ったという後付け）もあれば、被害建物数から算出しているがその数値が消防庁告示とは異なるもの（『大火調査資料』、損害保険料率算定会）もあります。いずれも東京消防庁からの引用です。なので、最終的には「どれだけその火災が注目されたのか」を証明できれば書けるとするべきです。
例えば、ホテルニュージャパン火災は1件の宿泊施設が焼けたものです。単に説明すれば「ホテルニュージャパンが燃えて、人的被害が出た」というものです。消防白書の大火の分類（330,000平方メートル以上の延焼免責）を取り出しても、類焼面積が5,000平方メートル以下ですので大火にはあたりません。しかし、こうして記事として存続しているのは、少なくない媒体がこの火災を取り上げ特集を組んだり、これをきっかけとして東京消防庁の対応が変わったり、最高裁判所まで争われてホテル側の人間に実刑判決が出たりした「内容がある」から著名性があるといえるのです。--アルトクール（会話） 2017年8月26日 (土) 08:39 (UTC)[返信]

ホテルニュージャパン火災の記事を熟読しました。まぁこれは私の単なる疑問ですので、不思議なことが解けたらそれで十分です。今回の糸魚川市大規模火災では、最高裁判所まで争われることは何も起きていません。それに、「糸魚川市大規模火災」にはこれといった事件性はないですし、記事名自体も暫定的なものになっています。例として挙げていたホテルニュージャパン火災ですが、これは事件として立件されているから著名性もある。従って、事件の記録を残す意味も兼ねて百科事典の記事になるのには意味があったのでしょう。ですが糸魚川市大規模火災は何者かが放火したりした訳でもないですし、あくまで住宅密集地で1軒の建物から火がでて広まり大規模な火災につながっただけではないでしょうか？糸魚川市大規模火災の記事も熟読しましたが、あまりにも暫定的すぎて、単なる報告書に過ぎないような感じがしました。いずれにしても私の疑問ですので。--S2AP1（会話） 2017年8月26日 (土) 11:58 (UTC)[返信]

>東日本大震災などの災害や事件は全国的に有名ですし、百科事典になるに値すると思うのですが、
その考え方でいくと、糸魚川市大規模火災も「全国的に有名」なので、「百科事典になるに値する」ことになりますね。
>この程度なら東京都心や地方中枢都市でも起こりうると思います。…このような程度で百科事典にするほどのものなのか気になりました。
その考えで行くと、大震災も「東京都心や地方中枢都市でも起こりうる」ので、「百科事典にするほどのものなのか」ということになりますね。
この点については、「起こりうる」と「実際に起こった」では大きな違いがあるわけです。
つまるところ、東日本大震災に特筆性が認められるのであれば、糸魚川市大規模火災にも十分な特筆性があるということになるでしょう。--2400:4021:9DF4:E400:B58D:A5C4:59B9:CEF0 2017年9月3日 (日) 09:33 (UTC)[返信]
報道はいくら寄せ集めても報道以上のものにはなりません。百科事典がしなければいけないのは、報道ではなく記事の主題に対する分析や解説です。ウィキペディアにおいては、それらが既に存在していて、それらを元に記事を書くのが本来の姿だと自分は考えます。ただし、あまりにも甚大な出来事であって、将来的にその出来事が十分に解説されることが明らかであれば、その時点ではWikipedia:独立記事作成の目安#ニュース報道等は満たせるということだと思います。ただし、もし実際に時間が経過してもそのようなことが起きなかった場合は、その記事の特筆性を再考する必要があります。--有足魚（会話） 2017年9月9日 (土) 09:34 (UTC)[返信]

東日本大震災は、市町村、県全体がやられるほどの災害ですので、特筆性はあるのはたしかです。糸魚川市大規模火災は家が数十棟燃えただけで、記事自体も暫定的で、火災事件の記録を残す意味合いも兼ねているのであれば、中途半端になっています。--S2AP1（会話） 2017年9月9日 (土) 11:46 (UTC)[返信]

コメント 酒田大火も記事になっています。削除しますか？--アーカマ（会話） 2017年9月27日 (水) 11:43 (UTC)[返信]

「Template:Wikidata」の利用について

初めて投稿します。ウィキペディア記事内の事実情報をウィキデータから参照できるTemplate:Wikidata（en）について、以前はエラーが出ていたのですが最近アップデートされたようで動作するようになっています。 （利用例） 個人的にはウィキペディア内の変わり得る値（自治体の人口や市長の名前など）はウィキデータで一元的に更新して、ウィキペディアはそこから参照する形にできると良いなと思っていたので、このテンプレートを使って行きたいのですが、実際の記事に使い始めても良いものでしょうか。 enではコミュニティ内で長所と短所を検討しながら進めているようですがinfoboxの内容を完全にウィキデータで置き換えた記事は1000件を越えています。-- Higa4（会話） 2017年8月25日 (金) 22:19 (UTC)[返信]

Wikidataの利用自体は、日本語版でもすでに広く行われています。たとえばモジュール:Wikidataへのリンク（特別:リンク元/モジュール:Wikidata）はすでにかなり多いです。そちらのテンプレートで使用されているモジュール:Wdはまだあまり使用されてないようですが、出典付きで数値を呼び出せる機能があるのですね？すごい便利そうです。ただひとつ気になるのは、モジュールやテンプレートの解説がまったく何もない点です（そのページに限った話ではないですが・・）。これだと日本語しか読めない人はまったく何なのか理解できなくなってしまいますから、「これはこういうことをしてるテンプレートです、モジュールです」ぐらいの簡易な解説は必要だろうと感じます。「詳細は英語版を参照」でもいいので。日本語で機能が解説されていれば、日本語版内での利用の普及、改良のスピードなども上がりやすくなります。--Was a bee（会話） 2017年8月26日 (土) 11:26 (UTC)[返信]
既に使われ始めているモジュールもあるんですね。また、文書化のご助言ありがとうございます。英語版を元に翻訳なり要約なりまとめてみます。不慣れなため1点教えて頂けるとありがたいのですが、英語版ではテンプレート名の後に/docをつけてTemplate:Wikidata/docにドキュメントを置いているようですが、日本語版の同じところTemplate:Wikidata/docに置こうとするとTemplate:Wikidata value/docにリダイレクトされてしまいます。これはどうしたら良いでしょうか。-- Higa4（会話） 2017年8月26日 (土) 13:37 (UTC)[返信]
何の症状でしょうかね。Template:Wikidataにドキュメントを作成してみました。これで編集できると思います。--Was a bee（会話） 2017年8月26日 (土) 14:27 (UTC)[返信]
ありがとうございます。ひとまず英語版をコピーして見出し部分を訳しました。Template:Wikidata本文も順次訳してみます。--Higa4（会話） 2017年8月26日 (土) 23:39 (UTC)[返信]
ここでいいんでしょうか？　これ運用考えますとちょっと制限をかけてもらいたいんです。Wikidata側が間違っている場合に修正するのが手間な上、他言語版と編集合戦が発生する可能性が無視できないってのは本質的にWikidata側の問題のため置いておくとして（英語版の議論では済まない点として英語話者の声が異常に大きくなると言う問題は、参加者の少なさと相まってWikidataに限らずプロジェクト全体が抱える深刻な欠陥ですが、英語資料が間違っているなんてのは普通に発生します）、Wikidataと便宜的に結びつけられているだけの記事で問題が生ずるのは明らかです（間違った結びつけなら解除や移動で済みます）。さらに、出典が異なる場合Wikidata側からの表示は誤りとなるか記事を破壊して適用することになりますが、これはどちらも問題があります。Wikidataには情報源を欠く記載も多く、存在していてもPOVや大本営発表の可能性は否定できませんし、Wikipediaを典拠とする場合もあり、そこまで信用を置いてよいものではないのです。このような問題を回避することを考えると{{Template名}}だけで機能させてしまう英語版方式は問題が多いです（理解していない人が多用したり、パラメータを意図的に削除することが想定される。誤情報・典拠なしでも表示されるが、そういった利用者はパラメータの追加すら難しいと考えられます）。そこで明示的にWikidataを参照するように限定できませんか？　誤っていてもその部分だけ調整するなら、パラーメータを記述する以外のスキルは必要ありません。またWikidata側を反映すると問題のある部分であれば、明示的に除去することも必要になります。呼び出しているテンプレート側の調整になると考えますが、今の数なら間に合いそうです。--Open-box（会話） 2017年8月28日 (月) 01:24 (UTC)[返信]
当方、ウィキペディアの経験が浅いため、経験者のみなさまでご判断頂ければと考えておりますが、データの入力元がウィキデータという別プロジェクトになるということは影響が大きいと思われるため、慎重なご意見はあって当然かと思います。技術面もよく分かっていないのですが「明示的にWikidataを参照するように限定」する、というのは具体的にどのような進め方をすれば良いでしょうか。「Template:Wikidata」を直接使うのではなくて、もっと限定したテンプレートを作って、それを使うというイメージでしょうか。あるいは、本文内で使う前にまずはウィキデータを参照するinfoboxを作って（enでの世界遺産infoboxとその利用例）そのinfoboxを利用したい人が利用することから始める、といった進め方などはご指摘の意図に適いますでしょうか。--Higa4（会話） 2017年8月28日 (月) 11:08 (UTC)[返信]
コメント Open-boxさんがご懸念の点はまさに大切な点です。ただ、多分ですが、二つ上の節で「Template:Infobox gene」の話題が出てたので、Wikidataを利用したテンプレートとしてあれが一般的なものと想定してコメントされたのかな、と思いました。しかし Infobox_gene は、英語版の中でもかなり（というかダントツに？）異色な設計のテンプレートで、一般的なものではないです。あのテンプレートは英語版でもちょこちょこ「扱いにくい」という趣旨の投稿がありますので、Infobox_gene の仕様に関しては、基本的にあのテンプレートの問題として考えれば良いと思います。より一般的な Wikidata の用法としては Higa4さんが例に出されたようなものが、現状の主流かと思います。数多くある情報の内、論争が起きる余地がないような情報に関して、Wikidataから自動で情報を引っ張ってくる、というような利用法です。たとえば「en:Template:Infobox_World_Heritage_Site」を見ると、ウィキペディア側で何も入力がない場合に、「世界遺産に登録された年」とか「遺産の場所の地理座標」とか、基本的に編集合戦になりにくいようなタイプの情報に関して、ウィキデータから自動で情報が引っ張ってこられる、という仕様になってます。今のところ、こういう使い方がほとんどだと思います。--Was a bee（会話） 2017年8月28日 (月) 16:54 (UTC)[返信]
コメント Infobox_geneではありません。それは、構造上は{{Normdaten}}（これはパラメータ指定が例外）に性格が近いテンプレートで、まともにメンテナンスできないとか、wikidata側が空だったり間違ってたら面倒だという問題はあるものの、「Wikidataから引っ張ってくる」ためのテンプレートと考えれば、「出来が問題だから作り直そう」「パラメータ指定型の同等テンプレートを作ろう」と考えることはあっても、「テンプレートの機能上の問題」ではないのです。想定したのは{{月のクレーター}}です。これは、パラメータを指定して使用するタイプのテンプレートですが、画像パラメータの場合「記載されていない」と自動で読みに行き、「空」だと空になります。このような挙動に対して、意図的にWikidataを読ませる／「記載されていない」場合は空にする挙動を可能にしたいんです（編集合戦が起きないと見込まれるようなケースなら、記載されていない場合に読み出すのはありでしょう）。これは、{{Wikidata}}ではなく、利用するテンプレート側の問題になると想定しています。Was a beeさんが挙げられた例ですと、登録年は争いがないでしょうが、座標は実は結構争いの余地があります。分散しているものや広域を指定する場合はもちろん、特定の建造物や地点の座標ですら結構ずれが発生します。これは「どこを基準点にするか」「どこまで記載するか（例えば「秒未満を書かない」選択肢もありますが、Wikidataには結構載っていたり）」という2点の争いが発生するためです。物品の開発者、施設の建造年など、あまり相違がなさそうなものでも意外に発生しますので、「判ってない人がやらかす」「善意によって引き起こされる問題」の手当てをしておくべきだと考えるのです。--Open-box（会話） 2017年8月30日 (水) 15:38 (UTC)[返信]
コメント 画像の読み出しが自動化されてるのは良くないかも、というのは自分も感じる所があります。たとえば「日本語の文字で解説を入れた図」が日本語版の読者にとって最適でも、ウィキデータでそれが代表画像として登録される可能性はまずないでしょうから。具体的に思いつく技術的解決としては・・・テンプレートに「条件分岐 (if文)を明示的に入れること」で解決できるかと。たとえば
  • image = で無指定だと、画像は何も表示されない。
  • image = File:hogehoge.png のように画像を指定すると、その画像が表示される。
  • image = wikidata と入力すると「ウィキデータに登録されてる画像を表示」する。
このようにしておけば、「何も知らずに、どこから来たのか良く分からない画像が勝手に表示される」という事態は避けれるのでは。--Was a bee（会話） 2017年8月30日 (水) 19:57 (UTC)[返信]
ちなみにこの場合のテンプレートの具体的な変更内容としては、Help:条件文#ifeqを使って、{{月のクレーター}}の image = の行を次のように変えれば良いです（動作確認はしてませんが）。
| image = {{#ifeq: {{{image}}} | "wikidata" | （ここにwikidataから画像を呼び出すコード） | {{{image|}}} }}
--Was a bee（会話） 2017年8月30日 (水) 22:05 (UTC)[返信]
Open-boxさんの問題提起から、ちょっと色々考えました。記事内部で内容と関わる場合は、日本語版では「ウィキデータからの情報を利用する場合は、明示的に呼び出す」みたいな決まりがあった方がいいのかもしれません。というのも、「ウィキデータは議論から何から全て英語で行われているサイト」なので、たとえば編集合戦が起きたら、「英語で議論できない編集者は何もできなくなる」からです。たとえば仮に「ウィキデータのページが荒らされてるから、保護を依頼する」という場合だけでも、（建前としてどうか知りませんが、現実的には）英語で依頼しないと反応は得られない現状があります。たとえば日本語版でいうところのWikipedia:管理者伝言板は、ウィキデータではココです d:Wikidata:Administrators' noticeboard。見れば分かりますが100%英語です。また読者の立場から考えても、英語がスラスラ読めないと、過去の履歴を追いかける事は難しくなります（このデータに落ち着くまで、かつてどういう議論があったか、どういう人が編集したかといった事は、英語をスラスラ読める人以外には分からなくなる）。こう考えると、日本語版で何かルールを作って自衛した方がいいのではないか、と。--Was a bee（会話） 2017年9月1日 (金) 16:01 (UTC)[返信]
この前は{{基礎情報 書籍}}をウィキデータから情報を引き出せるように編集しました。その時は引数で上書きできるようにしました。引数が指定されていない時だけ、ウィキデータの情報を引き出します。こんな設置はいかがでしょうか。 --Kanashimi（会話） 2017年9月2日 (土) 11:34 (UTC)[返信]
現在進行しているのは、そのような実装で問題が発生するという話です。出典が異なる場合に衝突が生じる、Wikidataは出典が怪しいものまで取り込んでる、Wikidataが間違っている場合の対処に問題がある（英語の壁がそこに加わります）、1:1でWikidataと結びついていない場合がある、省略で参照可能にすると必ずパラメータ除去が発生する（置換荒らしも想定されます）、Wikidata以外を意図的に指定することが適切な場合もある等は今までに上がっています。--Open-box（会話） 2017年9月4日 (月) 01:04 (UTC)[返信]
{{wikidata}}自体は、「Wikidataを指定、読み出すパラメーターを指定、出典も取得」など高機能なのですが、それがWikidataに記載されている内容を担保するものではないので「ウィキデータからの情報を利用する場合は、明示的に呼び出す」は、簡便な対処としては有効と考えます。明示的に呼び出す手法として、設定されているWikidata以外（複数の記事が未分割だったり、統合されている場合には必要になります）から呼び出す事を考えて、"QXXXX"を書けばそこを参照する・Wikidataだけなら設定されているWikidataを自動でとは思いつきましたが、本来のコードとしてQXXXXが入る場合に面倒ですね。「明示的に呼び出す」はあえて不便にして乱用を防ぐ手法なので、その延長で素直に書いてもらう（あえて書く人は判っているだろうと想定）のも手です。--Open-box（会話） 2017年9月4日 (月) 01:04 (UTC)[返信]
コメント 議論が英語で行われているのは、英語版ウィキペディアやコモンズも同じだと思います。日本語版が発足してから今まで（そしてこれからも）、これらのサイトから得られている恩恵を考慮すれば、英語で議論が行われているというだけで拒否してしまうのは、臆病に過ぎるのではないでしょうか。明らかな間違いがある時など、ウィキデータの値を修正する際に議論が必須ではありません。日本語版の方で通常のテンプレート引数を使って上書きする仕様にもできます。色々な問題が起きるとは思いますが、テンプレートの整備が進められていますし、一つ一つ解決して、ガッツリとウィキデータの恩恵を得る方向に進むことを期待しています。--Frozen-mikan（会話） 2017年9月4日 (月) 05:23 (UTC)[返信]
根底からひっくり返すようで申し訳ないんですが、「確実なところから」と考えてWikidataを導入しようとしているのに本当に有益なのは変動する不安定かつ信頼性が低く使えないところになるので、ガッツリ恩恵を得るのはこの議論とは無関係に難しいです（確実な値は書き忘れのカバーって方向性になるので、恩恵は小さいのです）。
Frozen-mikanさんの案の問題は、Wikidataに強制的に置換され、記事が毀損されたりWikidataが保有する問題点が反映されることにあります。これは、疑問を差し挟む余地がありません。なぜなら、日本語版のテンプレート周りで発生する問題の一部は、（誤っていたり劣っていても）「英語版に合わせればいいや」と気軽に導入することにあるからで、引数を書かないことで反映することはその一環になるからです。テンプレートの導入は一瞬ですがその後始末には多大な労力を要します。一つのテンプレートを除去するには、使用目的に問題が無ければ代替テンプレートを整えるか改訂し、英語版を使いたい利用者のために引数を使用可能にし、問題のあるテンプレートを差し替えて旧式を使用停止にするか削除し、導入されてしまった個々の記事を調整する。書いてしまうと簡単ですが、これにはとてつもない労力が必要となるのです（航空分野はLTAが英語版から導入した問題あるテンプレートの差し替え作業が頻繁に発生していました。今でもその影響はあります）。これは通常の引数を使用して上書きすることでは、決して対処できません。むしろ、引数を書かなくても機能するなら積極的に削除される可能性があります。そして、それは悪意がない利用者ほど「軽量化」と称して手を出しやすいところになります（記事単体の問題であれば、発覚しなければそれまでです）。ですから、「異論の発生する余地がない」場合以外は（なおこの場合でも引数の設定は必要です。省略したい場合、例外的に怪しい場合、結びついている記事の違い等に対応する必要があります）、明示的に呼び出して使用せざるを得ないのですし、この方法であれば今でも可能です（{{wikidata}}は単独で機能します）。また、infoboxのような基本的な道具は「日本語」しか解さない不慣れな人でも問題なく使用できる必要があります。この場合、議論は苦手、英語も自信ない（つまり引数が日本語化できないテンプレートは本質的には全部問題ありです。日本語だけですと今度は運用上の不都合が発生しますが）、だから英語で議論なんてとんでもないって利用者が使用しても問題がないところを目指すものです（この種の想定をする人が自身を最低ラインに置いて考えると、想定できてないって指摘されるのはよくあることです）。黙って修正すれば大丈夫って発想に至るには、不慣れな人ほど心理的に無視できない壁があるのですし（いきなり乗り越えちゃう人ってのは、それはそれで問題を起こすことに）、明らかな間違いと考えてもそれが通用するとは限りません。まして英語版やコモンズは利用側が可否を選択するため議論不要ですが（「英語版使えない、書き下ろす」ってのはありがちです）、これと異なりデータは、観点が反映されやすいにもかかわらずWikidataにまとめることで問題が発生しやすい性格があるのに、英語で進行します。それを黙って変更するか英語で議論しろと万人に要求するのは不当ではないが無茶な要求であり、それらを懸念することを臆病と評するのは、楽観的に過ぎ妥当ではないと考えます。日本語版側で独自に対処するには、利用側が黙示の同意ではなく可否を選択できるようにする必要があるのです。--Open-box（会話） 2017年9月4日 (月) 12:17 (UTC)[返信]
コメント 長過ぎるので何が主旨なのか理解しにくいです。Open-boxさんの根底にあるのは「ウィキデータが信用できない」ということでしょうか。そういうことであれば恩恵は全く無いと思いますので、議論の余地もないでしょう。--Frozen-mikan（会話） 2017年9月4日 (月) 13:49 (UTC)[返信]

(段落戻す) 考えていくとウィキデータの利用に関して論点は色々あります。そして多くは、分野やデータごとの個別の話し合いになるような事が多そうです（たとえば「政治的に荒れそうなトピックでは避けよ」等々）。ただ「取り返しが付かなくなるから、現時点でとりあえずストップをかけといた方がいい」ことは、一点だけあるかと思います。ルール風に書けば...

  • 「テンプレートでウィキデータから情報を呼び出すようにしたからといって、日本語版の infobox内 に記述されているデータを、（考えなしに）機械的に一斉除去するようなことはしないでください」

これは結構起きそうなことなので、注意した方がいいかと。この背景としては5年-１０年という先を考えたとき、「ウィキデータが、最終的に全てのデータ領域で標準のツールになることはない」という事があります。{{Normdaten}}に代表される識別子（ID）のような定型的なデータ領域ではウィキデータは非常に優秀なツールになります。しかし自然言語による記述が必要なデータなどは、ウィキデータの有用性は限定的です。つまり、識別子（ID）のような領域ではウィキデータはすばらしいデータベースになるでしょうが、別の領域ではひっくり返したおもちゃ箱（または最悪の場合はゴミ箱・・）のようなものになってしまう、という可能性は現時点でおおよそ予測がつきます。つまり起きうる最悪の事態は「日本語版の infobox内 に記述されているデータを除去したのに、ウィキデータがゴミ箱になってしまった・・・」というものです。こうなると復旧するのも恐ろしい手間になります。ということで、この一点だけ注意しておけば、とりあえず「取り返しがつかないこと」はないかと思います。どうでしょうか。--Was a bee（会話） 2017年9月8日 (金) 23:29 (UTC)[返信]

議論・運用の開始地点としては妥当と考えます。自動的に一意に定まるようなものであればWikidataは省力化に有用ですが、回線負荷の問題があるのでわざわざWikidataに任せるのもどうかという別の問題もあります。ですから、「除去しないでください」ぐらい強くてもいいのではないかと思いますが、現在存在するテンプレートのいくつかは機械的な除去を推奨しかねない仕組みになっていることを考慮すると運用が逆になるのですから、経過措置で軽めにすることはできるでしょう。モジュール:Wikidataとモジュール:Wdを利用している現存するテンプレートの挙動をざっくり分類してみました（いくつか切り分けられなかったものもあります）。
挙動 テンプレート
Wikidataに依存、特定のWikidata指定可 {{Infobox_gene}}、{{Normdaten}}
Wikidataに依存、パラメータ追記可 {{望遠鏡}}、{{Infobox 天文台}}
Wikidataに依存、変更不可？ {{Infobox anatomy}}
パラメータ優先、省略可、Wikidata自動補充 {{テニス選手}}、{{月のクレーター}}、{{Infobox medical condition}}、{{Infobox Chess player}}、{{Infobox Award}}、{{スキー選手}}、{{Infobox sportsperson}}、{{Infobox football official 2}}
パラメータ優先、省略不可、Wikidata自動補充 {{Infobox Australian Place}}
パラメータ優先、省略可、Wikidata指定補充 なし
画像が無い場合にWikidata経由で補充するテンプレートが目立ちます。人物画像で、そりゃないよって画像が指定されるケースもあったのでパラメータ優先は必須でしょう。ただ、これら以外にもモジュール:Uses Wikidataを使用しているケースもあり、doc込みではありますが200件以上ありましたので、想定以上に広がっています（サンフランシスコ (セブ州)で気が付きましたが、Wikidata任せによる誤表示が発生していました）。恐らくこれ以外にも特化したWikidataを使用するモジュール・テンプレートの存在は予想されます。また、意図的に呼び出さなければならないものは少なくともモジュール:Wikidataとモジュール:Wdには見つかりません（モジュール:Uses Wikidataですと、例えば{{PH wikidata}}はフィリピンに特化した{{Wikidata}}的な性格があり、意図的に用いる事が必要なタイプです）。英語版からの翻訳で悪意無く導入されるのでしょうが（悪意を持って導入するケースもありえます）、このままでは問題の拡大を止められません。「とんでもない画像を引く可能性がある」というこの議論では完全に予想外の問題も発生したため、これは早急に対処しないとまずい状況ではないかと。「出典が得られないデータをウィキデータから呼び出さないでください」も必要だと思うのですが、画像のように問題がないものやテンプレート側が対応していないケースが考えられますね。--Open-box（会話） 2017年9月11日 (月) 12:50 (UTC)[返信]

コメント ウィキデータの話をされているのでコメントさせて下さい。以前に外部リンクテンプレートでウィキデータがあるものをCategory:ウィキデータを利用しているテンプレートに入れて利用出来るようにしました。英語版にあるこのen:Template:Sports links（en:Module:External links/conf/Sports）の導入を考えているのですが、問題があるでしょうか。複数の外部リンクをウィキデータを利用してまとめて呼び出すことが出来るようになります。ウィキデータを利用しているTemplate:Twitter、Template:Facebook、Template:Instagramなども一つのテンプレート（Template:SNS）を作ってNormdatenのようにまとめて呼び出せれば便利だと思います。

Infoboxもコモンズに画像はあるけど、日本版の記事で画像が入っていない記事がたくさんあります。画像が削除された場合あれば別の画像を入れてほしいです。ウィキデータを利用して表示出来れば便利だと思います。指定がある場合はパラメータ優先にするのは適切でしょう。ウィキデータを利用してTemplate:テニス選手を改訂したいのですが、上手くいきませんでした。受賞d:Property:P166に国際テニス殿堂d:Q52454がある人物の殿堂入り年d:Property:P585を表示出来るように改訂したいのですが、難しいでしょうか（例ピート・サンプラス）。--Rain night 2017年9月12日 (火) 07:50 (UTC)[返信]

Category:ウィキデータを利用しているモジュールもありますし、増えたものを考慮すると一度Wikipedia:ウィキデータにサブページでも作って調査から入る必要がありそうです。明白に使用されていないものや問題があるものは修正・削除依頼・廃止による対処も必要でしょう。{{テニス選手}}でWikidataから画像を表示するには、引数ごとパラメータを除去すれば表示されます。引数なし＝ウィキデータ、パラメータなし＝画像無し、パラメータ指定＝指定画像なので、これを自動化することはパラメータ優先との兼ね合いで難しいです。Wikidataを意図的に呼び出すようにすれば、botで空欄→Wikidataに画像指定があれば呼び出しという作業は可能になるでしょうが、呼び出された画像が適切なのかという別の問題があり、自動化にはあまり向いていないのかも知れません。SNSは同種を複数持つことが少なからずあるため、Wikidataとは無関係に一括してまとめるには向いていなかったり。--Open-box（会話） 2017年9月12日 (火) 22:44 (UTC)[返信]

冒頭の方でOpen-boxさんより出典についての問題提起もありましたが、Wikidata Statsによれば2017/9月現在ウィキデータにある約2億4千万件の文のうち、出典が無いものが約9千万件、出典をウィキペディアとしているものが約4千万件となっています。（なお、出典が無いものの中には明らかすぎて出典がみつけづらいもの、例えばドナルド・トランプは「ヒト」である、などの文もあり、必ずしも「出典が無い＝信頼できない」ではないものもあります。）出典に関する運用方針も必要ではないかと思い、以下に私から見えている範囲での出典に関する現状と課題を、WPとそれに対応するWDの有無のパターンごとにまとめてみました。どちらかといえばウィキデータ側でちゃんとやるべき話ですが（ウィキデータコミュニティ内でも出典としてのウィキペディアはその元になった二次資料に書き換えることが推奨されています）、ウィキペディアの執筆と関係する部分があるのでたたき台としてご参考までに。

ウィキペディア(WP)日本語版記事 ウィキデータ(WD)項目 現状 出典 WPでWDを参照読み込みする際の留意点 想定される課題とその対策例
有 有 WP側のinfoboxの内容がbotによりインポートされることが多い。その上で人間の手でメンテナンスされる。 「WP日本語版」となっていることが多い WD側の出典（移入元）欄が「WP日本語版」となっている場合は、WPに出典表記されている二次資料に書き換える。 WP側の出典（二次資料）は個々の事実情報（例：生年月日、所在地、人口）単位ではなく、文や段落単位に（場合によっては複数）示されていることが多いので、事実情報ごとの出典が正確には読み取れないケースが想定される。→WP記事執筆時など、できるだけ二次資料を参照できるタイミングでWD項目側にも個々の事実情報（プロパティ）単位の出典を同時に登録できると良い。
有 無 比較的新しい記事など。 - WP記事を見ながらWDの項目を新規作成し、個々の事実情報（WDで云うプロパティ）の出典欄に「WP日本語版」ではなく、WPに出典表記されている二次資料を登録する。 同上
無 有 WP日本語版以外のソースからのインポートなど。独立記事作成のルールが似てはいるが一部異なるため、WPでは独立記事として認められないものがWDでは存在する場合がある。またWDは物事や概念ひとつずつに項目がひとつ作成されるが、WPでは違う物事であっても関係の深い内容が同一記事内に書かれていることがある。 WP各国語版、書籍、Webサイト等 WP記事を書きつつ、事実情報（例：生年月日、所在地、人口）についてはWD項目を充実させて事実情報ごとに出典を記載。 同上
無 無 - - WP記事を新規作成しつつ、事実情報（例：生年月日、所在地、人口）についてはWD項目を新規作成して事実情報ごとに出典を記載。 同上

--Higa4（会話） 2017年9月13日 (水) 02:57 (UTC)[返信]

ハイフンマイナスへの置換

（先行議論は利用者‐会話:新規作成#表記方法です。）ハイフンマイナス「-」とマイナス「−」、どちらを使うのかは表記ガイドには載っていません（ハイフンマイナスが記載はされてはいますが）。表記ガイドの過去の議論でも決着がつかなかったようです。まず、現時点でわかったメリット・デメリットを記載します（他にもメリット・デメリットがあるのかもしれませんが）。

  • ハイフンマイナスのメリット。キーボードから簡単に入力できる。
  • マイナスのメリット。環境によっては、ハイフンマイナスの見た目が圧倒的に悪い場合があるので、マイナスを使うのが自然。
ハイフンマイナスとマイナスの見た目がほとんど変わらない閲覧者の環境（私はこれです）の場合。閲覧者が、「いつも使っているマイナス」（実際はハイフンマイナス）に似て非なる入力できない（実際にできないかどうかはともかく）文字が記載されている事になり、「-123」（ハイフンマイナス）で画面内を検索しても、「−123」（マイナス）にヒットしません。この環境の場合、マイナスはデメリットのみです。
一方、ハイフンマイナスの見た目が圧倒的に悪い環境の場合。閲覧者はハイフンマイナスとマイナスを明確に区別しているはずであり、ハイフンマイナスで検索などしないでしょう。ただしどうやって、マイナスを検索するのかは疑問ですが。この環境の場合、疑問点を抜かせば、マイナスは見やすくなるのでメリットがあります。

と、このように一長一短あり、またどちらの環境が多いのかわかりません。どちらかに決めたなら、それに従うだけですが、多分決まらないでしょう（私も決めるのには反対です）。初版投稿なら好きな方を選べば良いだろうけど（分野毎である程度統一したいという問題はありますが、それは置いとく）、草取りで誤字脱字修正のようなつもりで気軽に編集しないで欲しいです。複数記事でこのような置換を行うのであれば、編集する前には、そのプロジェクトのノートや井戸端などで合意を取ってからにすべきでしょう。また、数学記事の数式部分はマイナスを使うとか、このプロジェクトはこっちを使うとかそういう合意はあっても良いと思います。ここで提起したのは、この問題を知らない人への周知と、この件に関する情報・意見の募集です（何もないならそれでも構いません）。以上、宜しく御願いします。--JapaneseA（会話） 2017年8月27日 (日) 04:59 (UTC)[返信]

コメント 半角ハイフンマイナスとマイナス記号は書くのが長いのでハイフンとマイナスと書くことにしますが，ハイフンは閲覧する側からすればほとんどデメリットしかないです．違いの目立たないフォントは別として，まず見た目の違いがあります．違いの目立つフォントの1つは（斜体の件でも出てきた）メイリオですが，math テンプレートなどでフォントを指定することでも確認できます．Math テンプレートでハイフンとマイナスはそれぞれ -, − と表示されます．ハイフンを自動でマイナスに変える val や gaps や e のようなテンプレートや，マイナスの入力を補助する e- や sup- のようなテンプレートも古くからあります．また，ハイフンは乗算のドットと見間違える可能性もあります．さらに，ハイフンは様々な用途（範囲や対（たい）やダッシュの代わりとかいろいろ）で用いられているので，例えば 2-3 を「2引く3」「2の3」「2から3」「2対3」等々のどれなのか形式的に区別することができません．一方マイナスを用いるデメリットとして，ごく少数ながら文字化けする環境が存在することや，ハイフンで検索するとヒットしないことが挙げられますが，マイナス付き文字列を検索したい閲覧者がどれだけいるかは微妙なところだと思います．ハイフン/マイナスなしで検索したり，記事中のマイナスをコピペで利用することもできますし．

仮に見た目が大きく変わる閲覧者が全体の 5% であったとしても（実際はもっと多いと思いますが）これは結構な人数になり，相対的な多い少ないは判断材料にするべきではなく，上記メリット・デメリットを総合的に考えると，ハイフンを使う弊害の方がかなり大きく（マイナスを使うメリットが十分にあり），ハイフンのマイナスへの置換は合理的なものと考えます．新規作成 (利用者名) （会話） 2017年8月27日 (日) 06:24 (UTC)[返信]

  • きっとお二方の話は数学的な記述についての文脈なんだろうな？と思いながら。
全然別の場所でアクセシビリティの話をしているときに、目の不自由な方が使う読み上げソフトの話題になりました。その文脈では、「減算（引き算）」の意味ではマイナス記号（ハイフン、マイナス問わず）を使うことはよい。しかし、「1から10まで」という意味でマイナス記号を使うのはアカン。という事になっていました。（趣旨はわかりますよね？）で、「1から10まで」を表したいときは「1～10」と書くべきなんですが、今度は全角チルダがウィキペディア的にはNGです。読み上げソフト的に理想的なのは、「1から10まで」を表したいときは「1から10まで」と略記せずに書くべし、というのが結論のようなんですよね。（読み上げソフトの種類によって挙動が違うようなんですが。）たとえばよく見る、人物の生没年なんかは（1525-1583）はダメで、（1525～1583）か、最強なのは（1525年生まれ、1583年没）と書くやり方。
このアクセシビリティの観点だけでいうと、{{マイナスキゴウ}}、{{生没年略記}}みたいなテンプレートを作り、文字の表示は「1910-1985」とテキストは表示し、よみかたを「1910年生まれ、1985年死没」と詠ませるようなギミックを作る、という方法が考えられます。が、そんなの面倒くさくて誰も使わないでしょうねえ。--柒月例祭（会話） 2017年8月27日 (日) 16:56 (UTC)[返信]
数学的というよりは算数的な，引き算や負の数を表す記号をどう書くかという話です．
が，範囲のハイフンも気になっていることなのでコメントしておくと，これを表す一番適切な記号は〜と – ですが，～や - も結構使われてますね．～はハイフン vs マイナスに比べれば（表示上）大した問題ではないと思っていますが，- は個人的に非常に気持ちが悪いし，おっしゃる通り読み上げソフトの問題や私が上に書いた問題（他の用法と混乱が生じる）もあるので，他の編集ついでに – や「から」に直すことはしていますね．新規作成 (利用者名) （会話） 2017年8月28日 (月) 03:20 (UTC)[返信]

コメント （私もハイフンとマイナスで表記します。）どちらかといわれればハイフンを支持しますが、（取り消しました。Yuukin0248 2017年8月29日 (火) 05:03 (UTC)）決着するというのはあまり賛成できません。なお、「雑草取り」でハイフンからマイナスに変更するのは望みません（もちろん逆への変更もだが、記事内でどちらかには統一すべき）。「東京と大阪の間」という意味で「東京 - 大阪」と使うのは私が出入りする道路分野ではもはや常識となっています。また、キーボードでハイフンを打つには半角にして「ー」のキーを押すだけです。しかし、先行議論でのJapaneseAさんと同じく私が使うPCの場合マイナスを入力することがほぼ不可能のようです。閲覧に関しては、私の環境では二つともほぼ同じです。1pxほどマイナスのほうが長いようですが…。--Yuukin0248[会話/履歴] 2017年8月28日 (月) 04:51 (UTC)[返信]

なぜその例を出したのか分からないので念のため先に書いておきますが，「東京と大阪の間」という意味での「東京 - 大阪」のようなハイフンは今回の議論の対象外です（議論対象は引き算や負の数などを表すときに用いるいわゆる「マイナス」です）．
さて，ハイフンで閲覧に支障をきたす環境についてはどのようにお考えでしょうか？　この部分が一番の問題だと私は思っているので，それに対する言及なしにハイフンを支持・変更は望まないと主張されても，議論になりません．
マイナスの入力については，ウィキペディアではパソコンだと編集画面の下（投稿とかプレビューのボタンよりも少し下）に「マークアップ」「記号」「ギリシャ文字」というのが（少なくとも私の環境では）あって，その「記号」のところに +, −, ×, ÷ が並んでいるので，そこの − をクリックすればいいです．あるいは，文字実体参照で &minus; と書くこともできます（区別しづらい編集者のことも考えるとこちらの方がいいのかもしれませんが，ソースが変わるだけで表示は同じです）．あるいは，− を辞書登録するという方法もあります（私はこれ）．
それから，これは JapaneseA さんもですが，使用しているフォントを書いていただいた方がよいかと思います．新規作成 (利用者名) （会話） 2017年8月28日 (月) 08:41 (UTC)[返信]
コメント 「MS Pゴシック」です。メイリオで試してみましたが、マイナスとハイフンマイナスの区別はつきませんでした。なお、-, −の表示はフォントに関係なく、顕著な差になりました（マイナスハイフンが極端に短く表示される）。そう仰る新規作成様の環境はメイリオですか？また、mathテンプレを使用せずとも、「-」と「−」で明確な差が出るのですか？--JapaneseA（会話） 2017年8月28日 (月) 10:19 (UTC)[返信]
メイリオですよ．Math テンプレに近い差が見て取れます．ハイフンとマイナスをいくつか並べてみます．
  • -, −, -, −, -, −, -, −.
4回並べましたが，最初から順にデフォルト，ＭＳ Ｐゴシック，メイリオ，math テンプレート (Nimbus Roman No9 L, なければ Times New Roman, etc.) です（スクショをアップロードするのが一番確実なんでしょうけど）．2倍以上は違っているメイリオで違いが分からないというのはさすがにありえないので，デフォルトと同じに見えるなら対応していないということだと思います（あるいは他の原因があるのかもしれませんが私には分かりません）．
メイリオでは違いがはっきりしているものとすると，Google Chrome のデフォルトがメイリオであることからも，ハイフンを用いるデメリットの大きさは容易に想像がつくと思います．ちなみに自分のスマホ（あるアンドロイド）のデフォルトのブラウザでも違いははっきりしています [5]（フォントは知りませんが）．iPhone だとどうなんでしょうか．新規作成 (利用者名) （会話） 2017年8月29日 (火) 03:10 (UTC)[返信]

コメント あー、すいません。いくつか説明しておきます。最初のやつはすいません。議論の最初のほうを読んだ限り「マイナスの意味で使うハイフンはどうなのか」のみの議論、という意味だとは感じませんでしたので。次に、投稿ボタンの下に表示されるやつでマイナスを入力、ですが私はガジェットを使用して表示させるものをカスタマイズしているのでまったく考えていませんでした。使用しているフォントはMS P ゴシックです。

さて、「ハイフンで閲覧に支障をきたす環境」になったことがなかったので、いろいろフォントを変えて調べてみました。すると「祥南行書体」というフォントでマイナスが表示できませんでした。まぁ、さすがにこのフォントで閲覧している人はほとんどいないと思いますが…。

また、話題に上がっているメイリオですが、メイリオを持っているにも関わらず表示はMS Pゴシックと一緒でした。 {{Math}}使用時はハイフンの差が出ています。それで、私が調べた範囲では皆さんの言う結果にならなかったので、（脳内のシュミレーションで）私の環境のうち「ハイフンの表示」だけを変化させてみたところ、「ハイフンは気持ち悪いから普通にマイナスを入力して検索」しようとしても文字参照とか以外では無理？状態に陥ってしまったわけです。ですから、ほとんどの場合はマイナスを使うのは「ハイフンの表示が悪くて、キーボードで簡単にマイナスを入力できる人」に限られます。その環境がどれだけいるのかわかりません。

ということになりましたので、どちらがいいというのはまだ判断できません（「ハイフンを支持します」も理由がなくなったので撤回します）。最後に思ったことなのですが、メイリオ（今年からのChrome56で標準）でハイフンの表示が悪いのなら、それは算数的なものに関わらず全ての表示に影響するのではないでしょうか。--Yuukin0248[会話/履歴] 2017年8月29日 (火) 05:03 (UTC)[返信]

コメント マイナスが表示できない環境が存在することは承知していますが（祥南行書体は公式サイトのフォントシミュレーションで試すときちんと表示されていますが，本物だと表示できないんでしょうね），このデメリットと，マイナスの意味で用いられているハイフンがとてもマイナスには見えないというデメリットは，同程度のデメリットであり，後者の影響を被る人の方がはるかに多いのでマイナスにはマイナスを使うべきである，というのが私の考えです．（検索についてはこの2つに比べれば些細な問題だと思います．）
メイリオはどうやら端末によって表示が変わるようです．いくつかのパソコンで試してみてもハイフンとマイナスは明確に違うのですが，自分のスマホではあまり違いません（がそもそもＭＳ Ｐゴシック，メイリオ，Meiryo UI の3つのフォントが区別できなくて，わけが分かりません）．
最後の部分は，別にハイフンの表示が悪いわけではなくて，マイナスの意味でハイフンを使うのがまずいという話です（一般的な状況での話で，例外はありますが）．（正しい）マイナスはユニコードに20年以上前からある記号で，プラス記号と見比べるとマイナスの形がどうあるべきかは分かります．マイナスの意味以外でのハイフンについて議論することもできるでしょうけど本題ではないのでやめておきます．新規作成 (利用者名) （会話） 2017年8月30日 (水) 05:16 (UTC)[返信]
えっと、Chromeをアップデートしたらメイリオが区別されてますね。ハイフンが著しく見辛いとは感じません。
メイリオで10-5,10−5と並べてみましたが、どちらでも問題なく感じました。マイナスよりハイフンが2,3pxほど短いように感じましたが、どちらの10引く5も普通に問題なく感じます。なにが問題なんでしょうかね…。--Yuukin0248[会話/履歴] 2017年8月30日 (水) 07:42 (UTC)[返信]
いや，ですからそんな微妙な違いではないんです．上にも書きましたが2倍以上は違って見えます．やっぱり各自スクショを上げた方が確実なんでしょうね．端末レベルの問題でしょうけど（Chrome のアップデートで端末に入っているメイリオフォントが変わるわけがないです），一体どんな端末で見てるんですか？　新規作成 (利用者名) （会話） 2017年8月30日 (水) 08:45 (UTC)[返信]
コメント 新規作成さんがおっしゃる話の本筋は、ピクセルの差とかフォントによる見えやすさとかは枝葉のことですよね？「たまたま字形が似ているという理由で、別の字を使うべきではない」ということでしょう？
たとえば「にのみやさん（二宮）」を書くにあたって、漢字の「二」の代わりにカタカナの「ニ」や記号の「＝」を使ったり、「愛（love）」と書こうとして「|ove」（縦罫線）や「Iove（iove）」とするのはダメでしょう、という話ですよね？
それはその通りだと思います。が、「入力のし難さ」の大きさの割には、「見かけ上のちがい」が小さい、というところが困りモノです。
私が思うには、新規作成さんの主張は正論ではあるけれども、この「困りモノ」要素のために、多くの利用者から「じゃあ直ちに代用マイナスは全面禁止し、すべて置換しよう」という合意を得にくいというところだと思います。（全面禁止というのは、「減算の意味で使う場合」です）
当座のこと・過渡期的な対応として、WP:HYPHENや表記ガイド#数式あたりに加筆し、「ハイフンとマイナス記号の違い」「本来、減算の意味で使うべきは正しいマイナス記号であること」「その入力方法」あたりを説明して注意喚起を行うというのはどうでしょう。私としてはそのうえで、「とはいえ、現実問題としてはハイフンによる代用が（入力の簡便さなんかもあいまって）（たぶん無自覚に）広く行われており、これをすべて置き換えるべきだという意見と慎重意見があって決着に至ってない」的なことを書くといいと思います。--柒月例祭（会話） 2017年8月30日 (水) 09:33 (UTC)[返信]
  • Unicodeの仕様的にはマイナス記号に軍配が挙がりそうです。フォントによって状況が違うので見た目上仮に区別できないとしても、マイナス記号（引き算・負数の記号）を使う意義は大きいです。ハイフン・マイナスは名前の通り、単語と単語の繋ぎ（つまりハイフン）と負（つまりマイナス）のどちらの意味にでも使える記号であるため、Unicodeで引き算や負数の意図を表現したいときは、ハイフン・マイナスを避け、曖昧性のないマイナス記号を使うほうがよいとされています。 ("The unary and binary minus sign is preferably represented by U+2212 minus sign rather than by the ASCII-derived U+002D hyphen-minus"、Unicode のTechnical Reportより) そして、WikipediaはUnicodeに従って作られています。面倒な場合にハイフン・マイナスで書く執筆者がいるのは構わない、それしか入力できない環境もあるので責めるべきではない、というのは前提として、できる人がハイフン・マイナスからマイナス記号に適切に置き換えする（もちろん引き算や負数でない場合はだいたい不適切でしょうからそれは除くとして）のは好ましいかと。 --210.138.176.73 2017年8月30日 (水) 09:49 (UTC)[返信]
コメント 歴史的にみてASCIIコードの影響が大きいのでしょうね。「ハイフンとマイナスは同じ」「ハイフンマイナスって何？」という認識の方も多いかと思います（自分も最近までそうでした……(>_<")。）。そのせいか、MicrosoftのOffice製品における数式エディタや数式ツール、LaTeXでは、ハイフンマイナスは自動的にマイナスになります。Microsoft IME でも変換候補に半角マイナスは標準では表示されず、「記号」からUnicode（環境依存文字）を選択する必要があります（一度使うと、以後は表示されますが……）。
なお表記上の違和感は、Times New Romanで顕著でした。Wikipediaではありませんが、数式ツールに頼らずWordで数式を直打ちしようとしたときに、ハイフンマイナスが何故こんなに見にくいのかと困ったことがあります（ちなみにその時はハイフンとマイナスの違いが分からず、全角のマイナスを使いました）。
本題の対策としては、基本的には柒月例祭様や210.138.176.73様がおっしゃる方向性に賛成でしょうか。具体的には、
  • 数式のマイナスはハイフンマイナスではなく、マイナスが好ましい。
  • そのため、雑草とりで数式のマイナスをハイフンマイナスからマイナスへ置き換えることは推奨される。
  • しかし、ハイフンマイナスを使う人がいても、それは歴史的経緯を考慮し、致し方ないとする。
  • 事情をよく分からない人のために、Wikipedia:表記ガイド#数式に説明を追記する。（セクション「数式」の中に、サブセクション「マイナス」を作ると良いのかもしれません。また、書く場所はWikipedia:表記ガイド#数字とも迷いましたが、「数字」節に「数式」節への誘導を作れば問題なさそうです。）
  • 雑草とり時は黙って置き換えず、「ハイフンマイナスをマイナスへ変更。・・・も参照。」のように説明を加える。
  • 表記ガイドの該当箇所へのショートカット「WP:MINUS」を作っておき、要約欄からもリンクしやすくする。
などが考えられそうです。
あと、UnicodeのマイナスはANSIコードのテキストファイルでは保存できず、エディタで保存する際にUnicodeを選択する必要があります。Wikipediaのソースをテキストで一時保存する際、通常はUnicodeを選択して保存するのですが、たまに操作を誤ってANSIコードで保存してしまうことがあります（その場合、マイナスは「?」になってしまいます）。そのため、
  • {{Math}}テンプレートでは、なるべく「&minus;」を使った方が良い。
とすると良いのではないかと思った次第です……m(_ _)m。--Assemblykinematics（会話） 2017年8月30日 (水) 22:22 (UTC)[返信]
コメント 「マイナスが正規だ」という話は理解しますが、IIを「I」2つで表現するような話と同じで代替があれば別に問題はありません。そういう「正規」かどうかという話よりもメリット・デメリットで判断すべきでしょう。なお、強調しますが、私はハイフンマイナスが良いとは言いません。両者にメリット・デメリットがあるので、「単純に置き換えないでくれ」が私の主張です。勿論Mathテンプレートはマイナスを使うべきですが、だからといって、計算式でもない単なる値として使用されている「-2」（ハイフンマイナス）のような箇所を「mathテンプレとマイナス」に無理矢理置き換えるような編集には強く反対します。--JapaneseA（会話） 2017年8月30日 (水) 22:47 (UTC)利用者‐会話:JapaneseA#ローマ数字についてにての御指摘により取消線--JapaneseA（会話） 2017年9月8日 (金) 09:08 (UTC)[返信]
  • コメント 単なる文字の入力と言う点に絞ってコメントすると、実体参照を使えば入力も簡便化されるので、それを使えば良いだけの話です。「実体参照」のリンク先の記事や（手前味噌になりますが）当方の作った利用者:知識熊/実体参照に、よく使う記号が羅列してあるので、参考になるかと思います。
    また、ここでの主な論題である修正に関してですが、数字に関するものに関しては一律にマイナス記号にするべきだと思います。たとえ数値のみであっても、記号に関しては計算式に使用するものと同じものを使用しなければ、数学的に整合性が取れていないと考えられます。実際、（増加や正数を強調する為の+1など）プラス記号は同じものを使用しているわけですから、マイナス記号も同様にすべきだと思います。これは表記ガイドよりもプロジェクト:数学やプロジェクト:天体等の専門的な場で別個に議論して制定すべき案件だとも思いますが。
    いずれにしても、数学やカリグラフィを詳細に学んでいない大多数の閲覧者からすればどうでも良い話です。私自身も、表記ガイドのノートページで議論が起きるまでは、違いなど全く知りませんでした。それでも、jawpでプロジェクトに参加するほど数学に心得があったり、カリグラフィに心得があったりする人がそれなりの閲覧環境で閲覧すれば気付くものです。その時に、その閲覧者が編集で修正してしまった場合、この行為の是非が決まっていなければ、差し戻したり注意したり、逆に感謝したりと言った事が容易に出来ないので、何らかの方針なりを決めておいた方が良いかも知れません。--知識熊（会話） 2017年8月31日 (木) 01:00 (UTC)[返信]
  • コメント （短めにコメント．）あまり Unicode 的な視点を前面に押し出す気はなかったのですが，もちろんそういう視点もありますね．本筋かと言われると，そのつもりではなかったのですが，もちろんマイナスの使用の強力な根拠になります．ＭＳ Ｐゴシックは標準的なフォントの1つなので，違いに気づかない利用者が閲覧者がいることは理解できますが（実際私もかつてそうだった），そうでない環境が多くあることは既に何度も言っていますし，こちらの方が Unicode どうこうよりも合意を得られやすいと思ってわざわざそうしているわけです．マイナスへの置換は「当座のこと・過渡期的な対応」と考えています．表記ガイド等での注意喚起には賛成します．少なくとも現時点で，置き換えを妨げる十分な理由は挙がっていないものと思います．新規作成 (利用者名) （会話） 2017年8月31日 (木) 05:47 (UTC)[返信]
  • （小まとめ）おおむねマイナスへの置換は認められる方向で合意が得られたのではないかと思います．つまり（マイナスを用いることは強いないけれども）ハイフンをマイナスに書き換える編集は草取りとして妥当なものであるということですね．メイリオについては Windows で6台，Mac で3台試しましたがすべて明瞭にハイフンとマイナスが区別されていましたので，パソコン環境でメイリオで2つが区別しづらいというのはあまりないのではないかと思います．マイナスの入力の手間は基本的には編集者側の問題であって，可読性への影響が明白でユニコード的にも好ましくないハイフンにこだわるメリットは乏しいと思います．新規作成 (利用者名) （会話） 2017年9月5日 (火) 02:31 (UTC)[返信]
そんな合意は得られていないでしょう（そういう御意見があるのは認めますが）。Yuukin0248様「「雑草取り」でハイフンからマイナスに変更するのは望みません（もちろん逆への変更もだが、記事内でどちらかには統一すべき）」「どちらがいいというのはまだ判断できません」、柒月例祭様「これをすべて置き換えるべきだという意見と慎重意見があって決着に至ってない」的なことを書くといいと思います。」。と、このように慎重意見をお忘れなく。--JapaneseA（会話） 2017年9月5日 (火) 06:37 (UTC)[返信]
そういう御意見の方が多数なうえに反対派は根拠を示していないですよね．Yuukin0248 さんは「望みません」から「判断できません」に変わっているので実質反対しているのは JapaneseA さんだけなんですが．新規作成 (利用者名) （会話） 2017年9月5日 (火) 07:32 (UTC)[返信]
Yuukin0248様の「どちらがいいというのはまだ判断できません」は、慎重意見と捉えるべきでしょう。ちなみに私も慎重意見です。貴方の会話ページでのやり取りも含め、最初から論点は「ハイフンマイナス化するvsマイナス化する」ではなく、「マイナス化するvs安易にマイナス化するな（慎重意見）」です。検索しにくい、保存しにくい（これは閲覧者ではなく編集者としてですが）が反対の根拠です。賛成の根拠はメイリオ環境での見た目、本来そうあるべきの2点ですか。そもそも貴方自身も「デメリットとして，ごく少数ながら文字化けする環境が存在することや，ハイフンで検索するとヒットしないことが挙げられますが，マイナス付き文字列を検索したい閲覧者がどれだけいるかは微妙なところだと思います」と仰っていますよね。これが「文字化けする環境は存在しない。マイナス付き文字列を検索したい閲覧者はいない」のであれば、（それが事実かどうかはともかく）主張としては理解できます。しかし自分でも多少なりともデメリットがあると認めているものを、「必ずマイナス化する」のはいかがなものでしょうかね。プロジェクト‐ノート:天体#マイナスの表記方法でも「ハイフンマイナスのほうが都合が良い」という御意見があります。自身がほとんど編集に参加していない他プロジェクトの執筆者の意見は重視すべきでは？--JapaneseA（会話） 2017年9月5日 (火) 08:39 (UTC)[返信]
可読性に影響があるのはメイリオだけではない，「必ずマイナス化する」なんて言ってない，ハイフンのデメリットはマイナスのデメリットに比べれば些細（なのでマイナスを使うべき），「都合が良い」は執筆時の話で別に後からマイナスに書き換えて都合が悪くなるわけじゃない，書き換えは執筆者とあまり関係ない．ついでに言えば，日本語に斜体を用いようとしているJapaneseAさんが読者のことを考えているとはあまり思えない．新規作成 (利用者名) （会話） 2017年9月5日 (火) 11:05 (UTC)[返信]
  • コメント （私が長文なせいで、このコメントを書く時点では新規作成さんによる2017年9月5日 (火) 07:32 (UTC) のコメントまでしか見てません。すいません。）どうやら私の立場が微妙になっているようで…。これは私の説明が不足していることが原因ですので、改めて意見を書きます。まず、新規作成さんが最初にしたいのは「マイナスを使うことを方針なりに文書化したい」のか「マイナスへ置き換えたい」のか、あるいは両方なのかが分かりません。方針なりの文書がない時点で「置き換えてもいいよね？」と言われたら反対します。
  • さて、私が「望みません」というのは「現段階でのマイナスへの置き換え」についてです。「判断できません」は「ハイフンではなくマイナスを使うこと」についてです。マイナス自体に反対しているのではなく現状での置き換えに反対、というところです。

以下、置き換え反対の理由

  • （雑草取りとか置き換えについて）さて、私としては問題は「マイナスへの置き換え」についてではなく「ハイフンではなくマイナスを使う」ことについてだと考えます。マイナスへ置き換えたところで編集者全員が積極的にマイナスを使うとは限りません。私はこれも考えて「雑草取りで変更はしないで」と言ったわけです。明確な差が出る「メイリオ」でハイフンとマイナスが混在した記事を見るのは閲覧者が変に感じるでしょう（雑草取り時に「記事内ではそろえる」のは最低限だと考えます）。そのため、積極的な置き換えには消極的、ということです。
  • （方針とガイドラインについて）それで、明確にマイナスを使うようするために「方針化」するなら「雑草取りでマイナスに変更」ができます。しかし逆に言えば、ハイフンを使う利用者は「方針に違反」するわけです。こうすると、ハイフンとマイナスの差があまり感じられない人からすれば「えぇっ」ってなるかもしれません（「困りモノ」）。また、WP:JPEへの記載が多く挙がっていますが、これはガイドラインです。これも方針同様のことが起きるかもしれません。方針にせよガイドラインにせよ、特に「ハイフンは絶対ダメ」とかはやめといたほうがいいと思います。これも「困りモノ」によるものです。
  • （PJ指針について）PJの指針（WP:PJ#ガイドラインによる）とすることですが、これは合意のレベルが低いため、「置き換えをどうするんだ」ということの説明がつかないと思います。

以上、置き換え反対の理由

  • 個人的な意見ですが、「特定の環境で顕著に違いが出ている」から「どちらかに決めよう」となったのに「結局ハイフンで書く人の方が多い」という結果にならないようにしてほしいです。
  • 文章でまとめられなかったので箇条書きにしたところもっとゴチャゴチャしてしまいましたので、かなり縮めて要約します。
    • 新規作成さんは「置き換え」を主張されていますが、これは「ハイフンではなくマイナスを使う」ことを合意した場合ですよね？「置き換えて終わり」ではないですよね。
    • 私は「置き換えに反対」ですが、マイナスを使うことを否定しません。
    • 方針あるいはガイドライン（=合意事項）をもとに置き換えするのは問題ありません。
    • ただし、「困りモノ」のせいで、方針あるいはガイドラインとすること自体に問題があります。
    • PJ指針は合意のレベルが低いと考えます。
  • （合意について）新規作成さんが仰るのは「おおむね合意が得られた」程度ですからね…。「合意ではない」という意見がある以上、そこは合意云々言わずに、マイナスをどのような位置づけにするかを決着つけるべきでしょう。--Yuukin0248[会話/履歴] 2017年9月5日 (火) 08:54 (UTC)[返信]
    • なーんかやたら問題が大きくなってませんかね．こんな大事に巻き込まれたくなかったのですが．読んでいくつか思ったことをまとまっていませんが書いてみますね．混在に問題を感じるなら，上に書いたようにハイフンを自動でマイナスにするテンプレートがあるので，マイナスで統一した方がいいとも言えます．ガイドラインに「ハイフンは絶対ダメ」などという強制力はありません．ガイドライン化するならIPさんやAssemblykinematicsさんが言っているような方向（表記ガイドに適切に説明を加え，マイナスを推奨する（がハイフンを強く否定もしない））に持っていくのが妥当だと思います．誤字修正や校正の類なので「置き換えて終わり」だと思っていました．新規作成 (利用者名) （会話） 2017年9月5日 (火) 11:05 (UTC)[返信]
「日本語に斜体を用いようとしているJapaneseAさんが読者のことを考えているとはあまり思えない」、ノートでの引用と記事は全く別です。それとも私が記事で斜体を使いましたか？（学名とか斜体にして然るべきものを抜かして）。こういう善意に取れないコメントは止めてください。次に、「執筆時の話で別に後からマイナスに書き換えて都合が悪くなるわけじゃない」、記事をテキストエディタで保存する際にやりにくくなります。天文分野は人が少ないので、2～3日保存してからアップロードしても競合する事は滅多にありません（競合チェックは必要ですが）。「「必ずマイナス化する」なんて言ってない」、「なのでマイナスを使うべき」と言っているじゃないですか。勘違いしないで欲しいのですが、「マイナス化」＝「マイナスへの移行」を指しています。デメリットがある時点で、誤字脱字の類ではありません。貴方の守備範囲の数学分野だけにして下さい。他の分野まで独善的に判断されるのは迷惑です。--JapaneseA（会話） 2017年9月5日 (火) 12:13 (UTC)[返信]
  • コメントJapaneseAさんへ。 この話は今の議論の本筋から逸れてしまうので、簡単に指摘するにとどめますね。新規作成さんがおっしゃる「斜体」の話は、こういうことです。（ここ参照）
  • 今のPC環境では、日本語テキストに対して斜体を指定しても、今の日本語フォントはたいてい斜体（イタリック体）を持っていないので、斜体で表示されません。（昔のPC環境では斜体で表示されました）私もXP機では斜体がみえますが、新型機では斜体にはみえません。
  • 一方、アルファベットだとかはイタリック体をもっているので、普通に斜体で表示されます。
  • 「斜体で表示しろ」という指示と、「引用部なのでほかと区別できるようにしろ」という指示は、その性格が異なります。
  • ウィキペディア内で「''ほにゃらら''」と記述すると、html的には「<i>ほにゃらら</i>」と出力されます。「i」は「斜体（イタリック）で表示せよ」という指令ですが、日本語フォントが斜体を持っていないので、いまどきの標準的なPC環境では、結局見かけ上なにも変化が起きません。
  • 「標準的な環境では」「見かけ上」なにも起きないのであって、実際には何かが起きています。上の方で話題に出した視覚障害者用の読み上げソフトだとかでは、htmlをみてそのテキストがノーマルでないことを悟って何か別の手段で訴えようとしたりします（その部分を読むときだけ声色を変えたりとか。）。
  • 似ているようで大きく違う指令として「<em>ほにゃらら</em>」というのがあります。これは「この部分を他の部分と区別できるようにしろ」という指令です。標準的な環境下では、普通は区別のために斜体で表現しようとします。ですが日本語フォントが斜体に対応していないので、結局は、見た目は何も変わりません。しかし個別の環境設定によって、「区別するときは赤文字にしろ」というように設定しておくと、斜体ではなく赤文字になります。
  • なので、いまどきの標準的なPC閲覧環境下では、読者に対して「このテキスト部分はほかと区別してね」（なんのために区別するのかはケースバイケースですが、今回は「引用部を示す」のが目的）という意図を相手に伝わるようにするためには斜体指定では目的が果たせません。斜体で表示されないのですから。なので、たとえばこうする（太字指定）「'''ほにゃらら'''」とか、或いはほかの引用テンプレートを利用するとか、目的に適った手段を講じるべきなのです。
  • ここまで説明すると、新規作成さんが「斜体」の話をした意図はご理解いただけるかと思います。記事内だろうとノートだろうと、日本語テキストに対して斜体指定をしても、いまどきの環境ではもう（ほぼほぼ）効果が得られないのです（古い環境なら効果はあります）。日本語以外のフォント、たとえば学名のようなラテン文字列に対する斜体指定は有効です。しかしそのときの斜体は「引用だから他と区別しろ」ということではなく、「ラテン語（学名）なので、他と区別しろ」ということです。（蛇足ですが、日本語文章のなかでは放っておいたってラテン文字列は他と区別されるわけですが、英文の中ではラテン語の単語を混ぜても目立たないので、この単語は英語じゃなくラテン語だよ、ということを知らせるために斜体を使うわけです。だから「de facto」みたいな成句の場合も（学名ではないけど）斜体を指定したりします。）今回のように「引用部を他の部分と区別できるようにする」意図を果たすための手段は、斜体指定ではなく、別の手段を講じるべきなのです。
  • たしかに、ハイフンとマイナスの話はこれに通じる面はあるでしょう。「見かけ上は同じように見えるかもしれないが、意味はぜんぜん違う」（小文字のLの代用として大文字のiを使うのはあかん）--柒月例祭（会話） 2017年9月5日 (火) 13:27 (UTC)[返信]

コメント話を本筋に戻します。正直、私は数学や天文学や・・・そうですね、理系の分野は全部、関心がないので、積極的な・能動的な・方向性を動かそうとする見識や意見や主張はないのです。ただ傍観者として、「意見が分かれているなあ」ぐらいにしかみえていません。少なくとも「対立する2つ（？）の意見がある」ということは事実として間違いないと思うので、まずはそのことを文書化してはどうかなあ、と思うのです。たとえばWikipedia:空が青いということに出典は要らないVSWikipedia:空が青いということに出典は要る、Wikipedia:配色の変更の有用性VSWikipedia:配色の変更は控えめに、のように。

  • 多くの実直な編集者にとっては、対立する2つの考えかたを知ることは有益です。ハイフンを使うとこういうメリットが有る、こういうデメリットが有る、マイナスではどうか、ということをまずは文書化する。「だからこっちにしろ」というところまでは踏み込まない。
  • まずはそこまで進めることはできるだろうし、それを読めばほかの多くの利用者も、なるほどと思うかもしれません。いちばんダメなのは、そういう背景や経緯を説明しないまま「マイナスに統一するって決まってるんだからマイナスにしろ」と言い放つことです。--柒月例祭（会話） 2017年9月5日 (火) 13:42 (UTC)[返信]
  • 蛇足ですが。新規作成さんのおっしゃることは、たぶん今のhtmlの考えかたからすると「正しい」ものであり、先進的な改善ではあるのだろうと思います。（知識がないのでテキトーですけどね。）ですが、たとえそうであっても、きちんと説明するべきだし、たとえ「実は正しく先進的」であっても、「先進的」でない多くの人からは「破壊」「間違っている」とみなされることもままあります。先進的なものが常に正しいとは限りませんしね。特にウィキペディアはいろいろな考えの人がいる場所なので、「これは正しいはずだから何の説明もなくやっちゃってもいいんだぜ」みたいな行動は、衝突や摩擦を起こしたりしがちです。＜誤字修正や校正の類なので「置き換えて終わり」＞というわけにはいかなかったりします。たとえば、新規作成さんは句読点「、。」のかわりに「,.」をお使いですよね。いまや世の中ではそういうスタイルの方がいるということは半ば常識ですし、「そういうやり方もあるよ」ということは多くの人が認めているでしょうけれども、小学校の国語の時間にやったら先生にダメ出しされるでしょうね。そこらへんで、新規作成さんの発言の「,.」をいちいち「、。」に書き換えていく人がいたら、その人が「、。が正規表現だ」といったら、ちょっと鬱陶しいでしょう。そこらへんの「いろんなやりかたがあるよね」感を汲んでいただくこともあっていいかな、とは思います。--柒月例祭（会話） 2017年9月5日 (火) 14:09 (UTC)[返信]
柒月例祭様へ。私が腹を立てたのは、記事に関係ないノートの編集を以って「JapaneseAさんが読者のことを考えているとはあまり思えない」です。もしこれが「斜体を使うJapaneseAは間違っている」であり、柒月例祭様のような説明があれば、それは正当な批判として受け止めましたが。さてここで質問なのですが、「今回のように「引用部を他の部分と区別できるようにする」意図を果たすための手段は、斜体指定ではなく、別の手段を講じるべきなのです。」について何か良い方法をご存知でしょうか？シングルクォーテーション3つだと強調しすぎて、他者コメントを悪目立ちさせるように思い、気が引けます。また、quotationで囲むのもオーバーな気がしますし。HTMLのemタグを使用するのもなんかしっくりきません（Wikipediaの機能でやりたい）。長くなるようであれば、この質問についてはノートでも構いません。（と、このように私の環境ではシングルクォーテーションを排除すると、どこまでが他者コメントの引用なのかさっぱりわかりません。）
では、本題ですが「対立する2つの考えかたを知ることは有益です。ハイフンを使うとこういうメリットが有る、こういうデメリットが有る、マイナスではどうか、ということをまずは文書化する。」には賛成します。
--JapaneseA（会話） 2017年9月5日 (火) 14:48 (UTC)[返信]
返信 脱線するのでノートにしましょうか。--柒月例祭（会話） 2017年9月6日 (水) 00:19 (UTC)[返信]
コメント 本題の「文書化」には賛成します。既出の「VS」系でもいいですが、この問題では一体的に説明したほうが分かりやすいので、Wikipedia:ハイフンマイナスとマイナスとかはどうですかね。
さて、私は、新規作成さんを主とした皆様により「マイナスを使う理由」は説明されたと考えています。これを覆すつもりはありません。しかし、「現状、多くの執筆者がハイフンを使っている理由」も説明されたと考えています。いってしまえば、私の環境でWikipediaを書く人からすれば「なんでわざわざマイナスを入力しなければならないんだ」と感じます。しかし逆もあって、メイリオの環境でWikipediaを見る人からすれば「なんでマイナスの表示が変なんだ」と感じます。この問題はおそらく半永久的に解決しないでしょう。
（一文ずつ独立したコメントです。）ハイフンを自動でマイナスに変換するテンプレートを利用するのは一手ですね（記事内での統一がかなり楽です）。「マイナスを推奨する」のであればなおさら記事内で統一する必要性がある気がします（メイリオではさらに変に見える）。「私論として文書化」するのであれば、表記ガイドとは矛盾ができてしまいます（落としどころをみつけて、「ガイドラインとして文書化」するのも一案かもしれません）。
「置き換えて終わり」とするのであれば、結局はハイフンを使うという執筆者が必ずいます。「メイリオ」という一つの環境で問題になっているのであれば、それは継続的に置き換えをしなければ意味がないのではないでしょうか。--Yuukin0248[会話/履歴] 2017年9月6日 (水) 08:43 (UTC)[返信]
コメント でいつ「必ずマイナス化する」なんて私が言いました？　多くの環境での可読性（とほぼすべての環境での正確性）を犠牲にしてまでハイフンにこだわる理由は何かと暗に再三聞いているわけですが，JapaneseAさんはそれに答えてないですよね（少なくとも十分な回答をしているとは思えません）．可読性に関わる問題で読者のことを考えていない人の意見を聞いてもしょうがないので，ああいうことを言ったわけです．（HTML的なことまでは考えてないですよ．斜体にしても何も変わらない環境があるのに斜体にして何がしたいんだというレベルの話です．）「記事をテキストエディタで保存する際に」どう「やりにくく」なるのかさっぱり分かりません．競合はいつでもおこりうるし，文字化けは &minus; で対処できるし，そもそも文字化けはマイナスだけではないし．マイナス記号に他の分野とか意味が分かりません．独善的にハイフンにこだわっているのはJapaneseAさんの方でしょう．きっとかけ算の * を ⋅ に書き換えるのさえ反対するのでしょうね．数値はそんな頻繁にいじるようなものじゃないし，編集者側から見ても（統一という点でも）マイナスに書き換えられるデメリットはほとんどないですよね．英語版ならほとんどマイナスが使われているので翻訳するとほぼマイナスになりますね．新規作成 (利用者名) （会話） 2017年9月6日 (水) 09:25 (UTC)[返信]
コメント 草取りの如く、数値のハイフンマイナスをマイナスに置き換えようとしている＝「必ずマイナス化する」としか聞こえませんが。もし、何かしらのケースで数値のハイフンマイナスをマイナスに置き換えないつもりなのであれば、話は違いますが。⋅は私の環境では「.」のように見えます。何か他の記号と間違えていませんか？「数値はそんな頻繁にいじるようなものじゃないし」いいえ、天文分野では頻繁にいじるんですよ。これはsimbadがしょっちゅう数値を最新にするせいもあります。赤緯が0h0m付近の場合に値が変われば、また絶対等級が0.0付近の星の視差が変わればプラスとマイナスが入れ替わるのはよくある話です（意味がわからなければ、「他の分野に首を突っ込むな」です）。--JapaneseA（会話） 2017年9月6日 (水) 10:00 (UTC)[返信]
この話をしても脱線にしかならない気がしますが，あまりにも論理が飛躍しすぎていて何をおっしゃっているのか分かりません．なんであなたは記号を調べることすらしないんですかね．別に冪の ^ と <sup> で置き換えてもいいですよ（むしろこっちの方がいいかもしれない）．「頻繁にいじる」のであれば「天文分野は人が少ないので、2～3日保存してからアップロードしても競合する事は滅多にありません」と矛盾しますね．仮にそういうことがあったとして，正負が頻繁に入れ替わるようなことが本当にあるんですかねえ．新規作成 (利用者名) （会話） 2017年9月7日 (木) 05:53 (UTC)[返信]
コメント 「^ と <sup>」？？、何の話ですか？私の環境では「＾と＜ｓｕｐ＞」を半角にした状態に見えますが。「⋅」の話ですか？？批判ではなく、本当に意味がわかりません。さて「矛盾」との事ですが、simbadが「頻繁にいじる」頻度は1つの天体に対し、数ヶ月に1度（あるいはもっと早いのかもしれませんが）です。数ヶ月に1度×天体記事の数なので、1日1つ修正しても、とてもじゃないが追いつきません。これを1つの記事で見れば、数ヶ月に1度なので、2～3日保存しても問題はないわけです。1つの記事で見れば、「正負が頻繁に入れ替わる」という事はありません。しかし、数百あるいは数千の記事でみれば、「正負が頻繁に入れ替わる」というわけです。なお、絶対等級の実際の値が頻繁に変わる事はありません。それこそ数万年単位でしょう。絶対等級の元となる計測値が頻繁に変わるのです。視差の値が1.0±2.0のような誤差値が大きい場合さえも別に珍しくありません。「正負が頻繁に入れ替わるようなことが本当にあるんですかねえ」というセリフに「調べることすらしないんですかね」をそっくりそのまま返します。こっちは批判です。--JapaneseA（会話） 2017年9月7日 (木) 06:32 (UTC)[返信]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ あなたは入力の簡単な 10^6 を適切な 10<sup>6</sup> に書き換えるのを反対するのかという話です．一応言っておきますが私のスタンスは初めから「ハイフンを使うのは勝手だけど，それを適切なマイナスに書き換える行為に文句をつけたりまして書き換えるなと言ったりするのはおかしいでしょ」というものです．正負が頻繁に入れ替わるようなことがあろうがなかろうがどうでもいいですから調べる気はないですよ．新規作成 (利用者名) （会話） 2017年9月7日 (木) 08:50 (UTC)[返信]

コメントまあもうちょっと落ち着いてお話しましょうよ。
  • 「掛け算記号」の話は×に説明があります。（「3かける2」は3×2か3*2か3・2か）
  • 「べき乗の表記方法」は冪乗に説明があります。（「2の5乗」は25か2^5か）
  • このどちらも、確かに今回のハイフンマイナスの話と近い話ではありますが、またちょっと事情が違うようです。なので捨て置きます。
記事を鵜呑みにする形で申し訳ないのですが、ハイフンマイナスにはこうあります。
「・・・派閥の問題などにより一方だけに絞ることができなかった。」
現実問題としてこういうバックボーンがあるならば、それはしょうがないでしょう。
  • 「マイナス」は減算の意味だけに用いる
  • 「ハイフンマイナス」は減算の意味の場合と「ハイフン」の意味の時がある
  • 減算の意味で「ハイフンマイナス」が使われている場合、別に間違いじゃない
  • これを直ちに「マイナス」に書き換えないとあかんのか。ちなみに「マイナス」は入力がすごく不便です。
・・・というときに、「別に間違いじゃないし、便利だからハイフンマイナスでいいじゃない」という人と、「紛れがないマイナスにするべきで、その重要性に鑑みれば入力の不便さなど大した問題じゃない」という話ですよね？
新規作成さんはマイナスを「適切」とおっしゃいました。これは「減算を表す以外の解釈の余地がない」という観点では「適切」でしょう。ですが、「不便だ・便利だ」「一般的だ」「通用している」というのも、また「適切さ」を考慮する要素にはなるでしょう。[プラス記号とマイナス記号]]にもあるように、実際の現実世界で「ハイフンマイナス」も引き算を表す意味があると認められており、「ハイフンにこだわるのはJapaneaseAさんだけ」といのはちょっと行き過ぎと思います。
「どちらもありえるもの」でして、少なくとも、問答無用で書き換えることが絶対的に是認される、という性格のものではありません。「どちらもありえるもの」を「それだと不便だからどちらか一方に統一しよう」と発想すること自体はわかるのですが、そうやって統一化の合意が得られたものではない場合には、「書き換える行為に文句をつけたり、書き換えるなと言ったりする」のはおかしいことではありません。--柒月例祭（会話） 2017年9月7日 (木) 09:29 (UTC)[返信]
やたら極端な言い方をされていますが，誰もそんなことは思っていないと思いますよ．また，置き換えについては「入力の不便さ」は初めから問題になり得ません．新規作成 (利用者名) （会話） 2017年9月9日 (土) 07:00 (UTC)[返信]
「～反対するのかという話です」、それには別に賛否はありません（これは当件に全く関係しない話ですね）。「適切なマイナスに書き換える行為に文句をつけたりまして書き換えるなと言ったりするのは」別におかしくありません。むしろ「～言ったりするのはおかしいでしょ」という意見がおかしいです。また、それを言うなら「適切な」ではなく「本来あるべき姿の」でしょう。「本来あるべき姿」だとしてもデメリットがあれば検討の余地があるという事です。アルファベットのI3つでIIIとするのは、本来あるべき姿ではありませんよね。ちなみに私の環境はブラウザではメイリオが有効にならないようですが、他のアプリはメイリオが有効になります（ちゃんとハイフンマイナスが短くて見づらくなります）。（勿論フォントに関係なく）EXCELやlibreOfficeでは「−1」（マイナス）と入力すると、文字列扱いで、「-1」（ハイフンマイナス）と入力すると、数値扱いです。--JapaneseA（会話） 2017年9月7日 (木) 10:12 (UTC)>利用者‐会話:JapaneseA#ローマ数字についてにての御指摘により取消線--JapaneseA（会話） 2017年9月8日 (金) 09:08 (UTC)[返信]
私は同レベルの問題と思います．「デメリットがあれば」と言いますがろくにデメリットを挙げていなかったじゃないですか（検索のみ，03:02 (UTC) でやっと他のデメリットを挙げた）．新規作成 (利用者名) （会話） 2017年9月9日 (土) 07:00 (UTC)[返信]

ハイフンマイナスをハイフンと書く方がいらっしゃるようですが、「-」（ハイフンマイナス）・「−」（マイナス）とは別に「‐」（ハイフン）という記号も用意されているため、そのような省略はWikipediaをWikiと略すのと同様に不適切です。入力の手間がかかるのは議論しつくされている通りなのですが、{{#expr:}}を用いたテンプレート内ではそもそも書き換えが不可能ですよね。TeXやWordの数式入力でハイフンマイナスを入力すると内部でマイナスに変換されるように、{{math}}にハイフンマイナスからマイナスへの置換機能を追加（フォントを変更せずにハイフンマイナスをマイナスに書き換える新たなテンプレートも用意）すれば、入力困難な問題もパーサー関数も含め全て解決するのではないかと考えてみたのですがいかがでしょうか。--119.242.9.158 2017年9月8日 (金) 11:12 (UTC)[返信]

コメント たしかに「ハイフン」というのもありますね…。完全に考慮してませんでした。IPさんが仰る{{Math}}への機能追加はモジュール:Stringあたりを使えば可能です。置き換えできる新たなテンプレートも簡単に作れます。さて、これは編集する人にも閲覧する人にも優しいやりかたですので、これであれば問題はないと思います。しかし、素の文で「ハイフンマイナス」を使う場合には置き換えても無力となりますし、結局はWikipediaの編集がされなくなるまでハイフンを使う人は残り続けるのではないでしょうか。--Yuukin0248[会話/履歴] 2017年9月9日 (土) 00:00 (UTC)[返信]

コメント ハイフンマイナスは世間の中でプログラミング（特に8bitマイコン）を中心に永遠に残るでしょうし、記事「ハイフンマイナス」をご覧にならない方も多いでしょうから、まずは「Wikipedia:表記ガイド」の「数字」や「数式」の節で違いを解説するのが第一ステップではないでしょうか。メリット・デメリットを元にどういう指針を作るかは、その次かと思います。その際は井戸端ではなくガイドラインのノートページで実施するか、「私論」を作ってそこのノートページで、という形が望ましいと考えます。また、{{Math}}テンプレートへの機能追加は並行して進められると思います。なお{{Math|-6}}は「-6」と表示されてしまいますが、<math>-7</math>は「」のようにハイフンマイナスをマイナスで表示してくれます。
あとローマ数字ですが、ローマ数字が表記ガイドで規制されているのは、Wikipedia外でも文字化けするからではないでしょうか。テキストメールで携帯アドレスに送り（Step-A）、携帯アドレスからPCアドレスに転送（Step-B）してみたところ、ローマ数字の小文字はStep-A・Bともに、大文字はStep-Bで文字化け（表示が?になる）という現象が見られました。ちなみにマイナスでどうなるか試したところ、Step-A・Bともに文字化けは起こりませんでした。（Step-Bのメールでタグを確認したところ、文字コードは「iso-2022-jp」（JISコード）でした。）---Assemblykinematics（会話） 2017年9月9日 (土) 01:45 (UTC)[返信]

コメント （上記Assemblykinematics様のコメントを拝見する前に書いたコメントです）技術的な事はよくわかりませんが、各記事はハイフンマイナスのままだとして、別のところで吸収するという事でしょうか。その場合、編集という点での問題は解決しますが、「-」（ハイフンマイナス）の検索にヒットしないという欠点が残ります。ちなみにオリオン座の恒星の一覧のような表をコピーして、EXCELやlibreOfficeに貼ると、ハイフンマイナスの場合だとマイナス値扱い、マイナスだと文字列扱い、なので（逆ならわかるのですが）、この点からも一律のマイナス表示に反対します。で、解決案を調べてみました。

@font-face { font-family: Meiryo; src: local('MS UI Gothic'); unicode-range: 'U+002D-002D';}

とWikipediaの大元のスタイルシートに指定しておけば、メイリオ環境でもハイフンマイナスが別フォントでマイナスのように表示されるはずです（なぜか私のブラウザでは、Meiryoがうまく動作しないのと、unicode-rangeが動作しないので、予想に過ぎませんが）。 --JapaneseA（会話） 2017年9月9日 (土) 03:02 (UTC)[返信]

コメント ユニコードのハイフンがあることはもちろん知っていますが一番最初に断っていますし誤解の恐れはない（なかった）と思います．Math 内のハイフンは真のハイフンの意味で使われているほうが多いと思います．あたり前ですが「すべて」のハイフン（の表示）をマイナスに変えるのは論外です．新規作成 (利用者名) （会話） 2017年9月9日 (土) 07:00 (UTC)[返信]

追記．上記「Math 内」はもちろん「Math テンプレート内」を指しています．ハイフンをマイナスに置換するだけのテンプレートを作るのはありだと思います（たいていの場合実体参照の方が楽な気がしますが）．Math テンプレートにそういう機能を導入するのは反対です（上記理由のため）．表示はマイナスでコピー時はハイフンがいい，みたいな記事があるのでしたら，そういうテンプレートを作るのもありだと思います（がこれを広めるのは難しいんじゃないですかね）．新規作成 (利用者名) （会話） 2017年9月10日 (日) 07:14 (UTC)[返信]

報告 置換用テンプレート {{Number}} を作ってみました．新規作成 (利用者名) （会話） 2017年9月20日 (水) 04:01 (UTC)[返信]

有償の寄稿の開示について

こんばんは、User:Hmanと申します。Wikipedia:有償の寄稿の開示の解釈について、皆様のご意見を伺いたく、書き込ませて頂きます。

まず大前提として、私はこれまでに企業・組織・著名人の記事を、当事者との連絡・資料提供の上で、先方の書き込みの監修、または私自身で書き込みを行うと言うことを、複数回行っています。何分、ものごとについて一番知っているのは当事者でございましょうから、この点については特に問題はないと考えて居ます。もちろん、厳正に中立性は守ってきたつもりです。むしろ非中立的なものを中立に戻そうと活動した感じです。そしてそうして編集した記事が問題とされたことは、恐らくないようです。また報酬については、現在までの所全くのゼロです。記念グッズを貰った事すらありません。むしろ私の方が電話代等を持ち出しているほどです。

さて、現在まではこれでよかったのですが、今後とも常にそうとは限りません。やや遠方になれば、正直、交通費も滞在費も個人で支出するには少々辛い額となることは、想像に難くないでしょう。そしてこの際に、必要経費（の一部または全部）を先方の組織から受け取ったとします。・・・これは報酬を得た事になるのでしょうか？

まず前提として、私はこの場合、1円も得をしません。むしろ可処分時間を取られたと言う意味で、損をしています。一般的な勤め人であれば、「必要経費」は申請すれば所属組織から出る場合が多いでしょうが、これは所得ではなく、所属組織に貸し付けていた必要経費と言う金員を請求の上で払い戻させただけに過ぎません（出張費などは一応所得でしょうかね）。また、二次創作の界隈などでは伝統的に、「商用利用は不可、ただし必要経費や手間賃の回収については商用利用とは見なさない」と言う概念がございます。

そう言った意味では、必要経費を受け取ると言う行為は「報酬」を得ているとは見なせないと考えるべきと思います。例えば「コトバンク」で各辞書の提議を確認した限り[6]、必要経費の受取は報酬には該当していません。まあ、とかく全く特をしていないのですから当たり前と言えば当たり前です。恐らくは労働契約も請負契約も成立していないかたちになるでしょう。

しかしながらウィキペディアは「無償のボランティアだ！！」と言うことで長くやってまいりました。よって、必要経費すらも違和感を覚える方も多くいらっしゃると想像できます。2017年夏現在のjawpでは、皆さんがどの様に考えていらっしゃるのか、もしよろしければごお聞かせ頂きたいと思います。

もしこれが認められるなら、個人レベルでは無理であった範囲まで行動範囲も広がり、重要な文献も参照しやすくなります。必然的により活発な執筆または記事の改善活動がいささかなりとも進むと期待出来ます。認められないなら従来のままとなります。またこれは強調してもし足りませんが、私はjawpでの執筆で1円でも金員を得ようとは全く思っておりません。純粋に記事・記述の正確性・中立性や網羅性の向上、いわば全体の品質の向上のみを目的としています。jawpはあくまで趣味です。どこまで言っても趣味です。ですが報酬を受け取ってしまっては、趣味ではなくなります。必要経費の受取が報酬と見なされるのであれば、私はそれは絶対に行わないでしょう。--Hman（会話） 2017年8月27日 (日) 19:14 (UTC)[返信]

コメント 利用規約の日本語翻訳版 (wmf:Terms_of_Use/ja) では「報酬」として訳されてしまっていますが、日本語版は参考訳に過ぎないので、「報酬」の辞書的な意味についての考慮をしないものとします。正文たる英語版 (wmf:Terms_of_Use/en) では "compensation" となっており、「代償」「補償」だとか「有償」("paid") という日本語を辞書で引いた際の意味に近いように思います。また、「招聘ウィキペディアン」や「プロジェクト:GLAM」、「インターン」等も適用対象であることを考慮すると、「必要経費」と解されるものであっても、Wikipedia:有償の寄稿の開示 の適用対象となるものと私は現時点において解釈しています。別に現時点では利用規約や方針として「報酬を受け取って編集をすること」自体を禁じているのではないので、例え編集の対価として数十万円・数百万円の現金や物品、サービスの供与を受けていたとしても、利用規約や他の方針等に反しないで、その旨を開示さえすれば現行方針上は問題ないのです（それをコミュニティが受け入れるかは別ですが）。特定記事の編集に際し、それとの利害関係者から金品や資料提供、人員提供、サービスの提供等を含め、人との接触により当該記事編集でのバイアスがかかりうる可能性がある状況が発生したのなら、当該記事のノートで開示された方が各人の活動に対する透明性の向上につながるものと考えます。--rxy（会話） 2017年8月27日 (日) 20:58 (UTC)[返信]
「必要経費を受け取ると言う行為は「報酬」を得ているとは見なせないと考えるべきと思」うと仰っているということは、当該行動が問題なければぜひ（あるいは要請に従って）実施していきたい、とお考えなのだろうと推察いたします。
（読み飛ばし可）置戸町という貧しい町がありました。その町では昔から「置戸町立図書館」という名前の図書館を運営しており、成功例として図書館界から注目を受けていました。その後老朽化のために新しい図書館建設計画が出てきました。しかし、財政難からそんなお金はどこにもありません。そこで、置戸町は「過疎債」を使ったのですが、この再建では「図書館」の建設は認められていませんでした。苦肉の策で、「置戸町生涯学習情報センター」という名前で運営を始めましたとさ。
という話があります。しかし、「図書館」という名前がなくとも実態としては図書館だったわけです。Hmanさんも「有償寄稿開示法では報酬扱いされてしまうため、仕方なく開示を行ったけど、心の底では『報酬』とは思っていません！」という態度で望んでいけばいいのではないでしょうか？
ちなみに、この物語には続きがあります。その後の過疎債特別措置法改正で、図書館建設に当該債権を使うことが認められるようになったのです。現在は、名実ともに「図書館」として運営しています。
WMFの規約には「プロジェクトが別の開示方針を採用する場合、そのプロジェクトに寄稿する際には、本項の要件ではなく、その採用される方針を順守することができます。」とあります。つまり、「jawpはWikipedia:有償の寄稿の開示を「別の開示方針」に採用します！」と宣言し、その中で、必要経費については「報酬」と扱わない旨を示しておけば、名実ともに報酬とはみなされなくなるわけですね。Hmanさんが、自分の態度にかかわりなく、「公的に報酬とみなされるのが嫌」なのであれば、そういう方法をとってもいいかもしれません。
最後に、「どの様に考えて」いるのか、という質問ですが、細かい規約などを無視して考えるのであれば、必要経費は報酬に入れるべきではないと思います。もちろんこれはただの感情論なので、規約上どのように解釈されるべきなのか、という点からは離れますが。--Kkairri[話][歴] 2017年9月2日 (土) 06:54 (UTC)[返信]
質問 「私はこれまでに企業・組織・著名人の記事を、当事者との連絡・資料提供の上で、先方の書き込みの監修、または私自身で書き込みを行うと言うことを、複数回行っています」とのことですが、記事原案作成者、資料提供者、記事ドラフト作成者、校閲者、監修者などがチームを組んで共同で記事を完成させ、それをHman（会話 / 投稿記録 / 記録）という利用者アカウントを使って投稿しているなら、それは共有アカウントにあたりませんか？　もしそうならブロックして話は終わりだと思いますが……。--126.250.154.14 2017年9月2日 (土) 17:05 (UTC)[返信]
コメント 上記の「……先方の書き込みの監修、または私自身で書き込みを行う……」については、
  • Hman様監修の元、先方の方ご自身がアカウントを取得して、もしくはIPでWikipediaに書き込んだ。
  • Hman様が先方の方から提供された資料を元に、and/or連絡を受けた内容についてHman様自身が検討して、Wikipediaに書き込んだ。
と解釈できないでしょうか。もっとも、前者はWikipedia:自分自身の記事をつくらないに準拠した上でということになりますが……。
なお本論としましては、rxy様の指摘に基づくとWikipedia:有償の寄稿の開示における「報酬」を「代償（資料代や交通費など必要経費、および謝金や報酬）に改訂した上で、「・・・から必要経費（写真撮影のための交通費）提供を受けての編集」などと提示されると、「無報酬」で堂々と活動できるような気がします。--Assemblykinematics（会話） 2017年9月3日 (日) 06:54 (UTC)[返信]
まとめてのレスとなります点、ご容赦ください。
まず私もその一人なのですが、「○○と言う団体から必要経費を受け取り、××と言う記事を書きました（または修正しました）。」と開示する行為。これは誰しも抵抗が有る物と思います。熟練した善良なウィキペディアンであれば断じてそういった事は無いのですが、本当に妥当な執筆/編集なのであろうか、金を貰っていいように書いているのではないか、と言う疑惑は当然生じます。もしその団体が、政治・宗教団体だとしたら、さらにひどいことになりそうです。よって、恐らく多くの方はこの様な事は行おうとはしないでしょう。なお、私自身がこのような事を行った時、が最もありそうだと想定しているのは、団体や著名人の記事に、ひどい間違いがあるケースです（これは実際、これまでに自腹で行ったケースが何件かあったと記憶しています）。この場合はウィキペディアン以前のお話になります。善良な一国民が、jawpにデタラメを書かれて難儀している状況を見た。しかし手元および近隣には資料が無い。しかし遠方にあるその団体や、著名人本人は資料を持っている。こう言ったケースにおいて、開示をしたくないのであれば、交通費・滞在費を自腹で払うよりありません。しかしやはりほとんどの方はこのような事はなさらない筈です。大抵は見て見ぬ振りをされるでしょう。最低限の必要経費については開示を義務付けないと言うアイディアは、益するところの方が多いものと私は考えます。
また、私のこれまでの活動について、これを共有アカウントと取られるのかどうかは、これは皆さんの判断に一任します。ただ、そもそものお話なのですが、私はこれまでにまあ、10人か20人かはわかりませんが、多くの、主に新規・ライトユーザーの方と、メール等でやりとりを行い、ここは違う、ここは書きすぎだ、この資料ではそうは読み取れない・・・などと言った、監修と申しますか講座と申しますか指導と申しますか、そう言った事をしております。また、逆に私の書いた草稿を、より専門的な知識をお持ちの方にお見せして、駄目出しをして頂いた事、これも当然ございます。・・・・・・この様な相談ごともNGとされているのでしょうか？ちょっとした相談でも共有アカウントだと言われかねないのですが。それはそれで無茶苦茶なんじゃないですかね・・・。連絡の取れる詳しい方に心当たりがあるなら、場合によっては相談くらいしますでしょう。ほとんどのケースで品質の向上に繋がると見て良いでしょう。そして、倫理的にこれのどこに問題があるのか全くわかりません。
ちなみに、共有アカウントの定義は、Wikipedia:投稿ブロックの方針においては「不特定多数の人々によって共用されるためのアカウント」です。これは公共の施設などで使用されるもの等の感覚ではないかな、と考えます。Wikipedia:多重アカウントにおいては、「ロールアカウント」と定義されていますが、法人等はアカウントを作れない、法人等に所属する人物は所属法人等の記事を編集できない、と解釈してよいのでしょうか？（その際に相談事が発生しないとは考えにくい）
率直に申し上げて、財団レベルのお話につきましては、あまり詳しくありません。お詳しい方がいらっしゃいましたらご教授頂きたいと思います（そしてできましたら、方針・ガイドライン・Help等に明記して頂きたく思います）。
なお、ブロックがどうこうと言うのは失当です。もしNGだと言う合意が得られたなら、今後私は誰の相談にも乗りませんし、誰にも相談しません。よって今後問題行為を続くと言う危険性はないため（私の人間性そのものがとんでもなく低く評価されたなら別ですが）、ブロックの対象とはなりません。
まあ、いずれの場合もアカウントは独立しており、著作権は投稿を行ったアカウントの所有者に期す形になっております（2度ほど共著と明記して記事を書いた事があったように記憶していますが）。実際に編集画面に内容を書き込み投稿ボタンを押すのはアカウント所有者です。たまに何らかのかたちで協力し合う事はありますが、少なくとも私が使用しているHmanアカウントについては、私以外が書き込みボタンを押す事はありませんし、99.9%は私の筆によるもので、各種の責任は全て私に帰す物と認識しております。--Hman（会話） 2017年9月3日 (日) 20:06 (UTC)[返信]


コメント　まず最初に。僕はライトユーザーであり、経費の掛かるような寄稿をするつもりは有りません。その上で、私見というか愚考というかを、コメントさせていただきたいと思います。尚、特に強い意志があってのコメントでは無いので、スルーされても構いません。
  • 最低限の必要経費については開示を義務付けないと言うアイディア
　個人的には、賛成です。というのも、もし仮に『ワイロを貰って、その相手の都合の良いように記事を書く』人がいたとして、彼はそのことを明かすでしょうか。否、絶対に隠し通すはずです。直接受け取れば記録に残りませんし、口座に振り込まれたとしても、リアルで特定し記録を開示させない限り分からないからです。(別件で近くに行く用事が有ったので、ついでに取材したなどと言われれば、それまでです)つまり、そういった編集を警戒しても意味はなく、各自の善良性を信じるしかないと思うのです。もちろん、何らかの経緯でそれが発覚した場合は、投稿者のブロックや場合によっては法的措置も有りうるかも知れませんが。
　義務づけたところで、それに従うのは善良なユーザーのみと考えると、最低限の必要経費に関しても開示を義務付けるのは、善良なユーザーの前にカベを作っているだけではないでしょうか。そして、ここからが今回言いたかった事なのですが、『最低限の必要経費は開示しなくてもよいとすれば、ワイロを貰って書かれた記事が有った時に、今よりも不適切な記事で有る事を、証明しやすくなるのではないか』という事です。あるユーザーがワイロを貰って、事実を捻じ曲げた記事を書いたとしても。ある程度の実績のある、複数のユーザーが事実を確認し、それを指摘すれば、事実に則った記事に直せるはずだと思います。(実績云々は、靴下で捻じ曲げようとする人がいるかもという意味での対策のつもりです)
  • 共有アカウントと取られるのかどうか
　実際に、そのアカウントでログインしているのが一人だけならば、共有アカウントには当たらないかと。代表では有るかも知れませんが。そして、執筆に関わった人すべてがそれを承知の上で、なおかつ実際に投稿する人が全ての文責を負うのであれば、なんの問題も無いと思います。
　どこかのサブページ上で完成させ、記事に反映させるのも。メール上で完成させ、記事に反映させるのも。権利的には、大差ないのではないでしょうか。
　むしろ、仮に『その記述の仕方だと、場合によっては侮辱に当たる』などと言ったケースが有った場合に、メールで有れば公開されないから投稿前に直せば良いのに対して、サブページ上で有れば、特定版削除等の処置が必要になります。そういった意味でも、禁止する意味は無いと思います。
　というか、つい最近ある人に、『会話ページやノートが有る理由と使い方を、よく考えろ』という意味の忠告をされたのも有って、思ったのですが。今あげたような問題を解決するために、メール機能は用意されているのではないでしょうか。(それ以外の理由も有るにせよ)

--ただのしかばね（会話） 2017年9月4日 (月) 00:20 (UTC)[返信]

コメント規定の趣旨と目的を踏まえたうえで、「有償」「報酬」「必要経費」の解釈を行えばいいでしょう。

  • 常識的には「報酬」は金銭の授受によるものと解釈するのでしょうけど、程度によっては金品やサービスの提供も報酬とみなされるでしょうね。そこらへんは常識の範疇じゃないでしょうかねえ。
  • たとえば『角川日本地名大辞典』なんて古本だと下手すりゃ1冊300円の値打ちしかないし、多くの人にとってあんなものカサバルだけの粗大ごみでしょう。ですが、もしあれを無料であげると言われれば、中には小躍りして喜ぶ人もいるでしょう。最近行われているウィキペディアタウンとかも、見方によっては、何らかの便宜を図ってもらっている、といえなくもないでしょうねえ。（常識的にはそれを報酬とはみなさないでしょうけど。）
  • Hmanさんには釈迦に説法になるでしょうけれど、要するに中立性を損なうことがないようにせよということであり、それは執筆者側が気をつけることであると同時に、読者側が執筆者のバックボーンを知ることで、その書いたものがどの程度中立的であるのかを推測する手がかりになるものです。（報酬などなくても中立的でない編集をする人はたくさんいますし、中立的に書いているつもりでも、知らないうちに情報源自体が中立的でなかったということもあるでしょう。）
  • 現在の日本の制度、おそらくふつうは税務署による税務上の文脈ということになるでしょうけれど、「必要経費」は「報酬」ではありません。が、じゃあどこまでを「必要」な「経費」と認め、どこからはそうでないのかは、線引されていません。東京から上野までの電車賃数百円を負担したぐらいでは誰もなんにも言わないし、喫茶店で数百円のコーヒーをおごってもらったぐらいでもなんにも言われません。たぶん（実際には乗っていないのに）タクシー代として3000円もらったぐらいでもなんにも言われません。しかし沖縄から札幌まで飛行機で往復して10万かかったといえば、それ本当に必要だったのかという話になるし、1泊5万の宿に泊まればそれ本当に必要だったのかという話になります。
  • ただしそうやって「報酬」と「必要経費」を（いわば勝手に）区別することは、rxyさんが指摘なさったように、本来の英語版の趣旨を逸脱しているんじゃないか、という疑念をもたらす余地にはなると思います。「報酬」「必要経費」の区別なく、なんであろうとも対価を得たならば開示するというのが理想的ではあるでしょう。まあそれをガチガチにやれば水飲ませてもらっただけで対価ってことにもなる（砂漠の国だったら貴重かも）のですが、まあそこらへんは常識の範囲で判断すればいいと思いますが、不安ならば全部開示すればいいでしょう。少なくとも現段階ではそれで義務を果たしたことにはなります。--柒月例祭（会話） 2017年9月4日 (月) 10:03 (UTC)[返信]
  • コメント - 皆様、様々な角度からのご意見、大変ありがたく存じます。総合し考えますところ、現在のところ、「必要経費の受取は報酬とはみなさない」と言う見解については、五分五分よりは有意に否定的であると解釈しました。このため、まあ私個人の話ですが、有意な必要経費がかかる執筆活動は少なくとも当面は行わない事と致しました。もちろん必要経費を受け取ろうが、例え有意な報酬を受け取ろうが、私の書く記事は従来と同程度には中立であり、その他各方針・ガイドライン等にも十分配慮したものとなるのでしょうが、いかんせん印象が悪すぎます。これは私・Hmanにとっても、記事の対象となる何らかの組織等にとってもです。「必要経費は報酬とは見なさい」と言うアイディアについては、機会がございましたら時と場所を改めて検討が行われるのが好ましいのでは無いかと思料致します。コメントを頂いた皆様に重ねて御礼申し上げます。--Hman（会話） 2017年9月16日 (土) 15:48 (UTC)[返信]

モバイル版Wikipediaでの節ごとの転記について

普段、モバイル版Wikipediaを利用している者なのですが、とある議論にて、最初の編集で「○○から転記」と書き、その後節ごとに区分して転記(統合)した編集に対して「履歴不継承ではないか」という疑問がかけられました。モバイル版Wikipediaの使用上、PC版のように一括編集が出来ず、こういう転記の場合、どうしても複数の版に分けて編集しなければなりません。この場合、全ての版に「○○から転記」と書かなければならないのでしょうか。今後の編集に役立てたいのでどなたか教えてくだされば幸いです。--Tama.Kyu（会話） 2017年9月3日 (日) 09:38 (UTC)[返信]

コメント　個人的には。ＰＣ版でまとめて行うのが望ましいですが、モバイル版でせざるを得ない場合、毎回記述するべきだと思います。というのも、要約欄に書くべき事を書かなかった事が原因というか発端になり、トラブルになったりするからです。『○○から転記』『××へと転記』を一時的にユーザー辞書に登録しておき、済んだら解除すれば良いのではないでしょうか。(アイウエオ順に並ぶなら、『ああま』で前者を、『ああば』で後者を、登録すると良さそうです。)--ただのしかばね（会話） 2017年9月4日 (月) 00:57 (UTC)[返信]
コメント 転記を実施する前に転記先ノートページに転記の旨をリンク元（転記版日時）と共に記しておき、転記先の各節編集要約欄で「転記元の詳細はノートへ」と誘導しても構いません。最初に編集先がひと手間増えますが、やり方はどうであれ、適切に転記元へ誘導出来れば目的（クリエイティブ・コモンズ・ライセンスが求める帰属表記義務）は果たされます。
考え方は「要約欄に記入可能な文字数で著作権者名を全て書ききれない場合に、別所に先に記載しておくやり方」と同じ意味です（Wikipedia:ウィキペディア内でのコピー#c) 投稿者一覧を記載を参照）。
◆蛇足ながら、要約欄に誘導を忘れて転記を実施してしまった場合で「転記内容に著作性がある場合」は『厳密に言うと著作権侵害を引き起こしている虞』が発生しますので、最新版で『履歴補遺』を行った上で間の記入忘れ版を中抜き削除、という対処が必要になる場合があります（Wikipedia:翻訳のガイドライン#要約欄への記入忘れ・誤記入、Wikipedia:削除の方針#著作権侵害への対処方法などをそれぞれ参照）。
しかしWikipedia:削除依頼は初心編集者には処理が大変ですから、ご心配でしたらノートなどにその旨の懸念を書き残しておけば手慣れたベテランの方が対処して下さるかもしれません。--Nami-ja（凪海） （会話 / 履歴） 2017年9月8日 (金) 17:07 (UTC)[返信]

リンクのページプレビューにより本来隠してあるはずの写真が見えてしまう

最近プレビュー機能が新しくなったようですが、これにより一部ページのリンクにポイントしたときに問題が生じます。 例えば凌遅刑（ポイントするのはお勧めしません）というページがありますが、このページにはその実例の写真がトップ近くに貼ってあります。 ページ内では「注意：凌遅刑執行写真をご覧になる方は右端の「表示」をクリックしてください。」という形の配慮がなされているのですが、 これが他のページにリンクとして存在するとポイントしたときに配慮が活きず写真が表示されてしまいます。 今後ページの作成・編集時にはこれを考慮に入れないといけないのではないでしょうか。--210.165.135.5 2017年9月4日 (月) 08:59 (UTC)[返信]

コメント それはもともと隠し方が不適切だったのです。そこで使われている{{Hidden}}の解説文にも載っている{{折り畳み注意}}に簡単に書いておきましたが、要するに折り畳み機能は不快画像を隠す目的には適しませんので、このような場合は画像を表示しないファイルページへのリンクを検討することになります。また、「右端の「表示」をクリックしてください。」という表現も、自己言及の一種として抵触する可能性があるのです。--Gwano（会話） 2017年9月4日 (月) 09:23 (UTC)[返信]
凌遅刑は{{external media}}を使ってワンステップ置かせるようにしました。今なら、カーソルをホバーさせてもグロ中尉とはなりません。ホバー対策だけなら、トップにダミーの画像をおいておくなどの対策が取りえますが、この際不適切な{{hidden}}にはメスを入れていきましょう。--Kkairri[話][歴] 2017年9月5日 (火) 09:38 (UTC)[返信]
コメント Wikipedia:免責事項#提供する情報についてに在る通り、本来的にウィキペディア上にあるあらゆる「不快画像」を「不適切画像」として編集者が隠す編集を施す義務がないことをウィキペディア自身がはじめに言及しているので、{{Hidden}}（{{Hidden begin}}）の用法を明確にする必要があるような気がしますね（私など黒くてすばしっこいアイツの記事は（当然詳細画像があるであろうことを予測して）決して開いたことがありませんけども）。--Nami-ja（凪海） （会話 / 履歴） 2017年9月5日 (火) 22:22 (UTC)[返信]
多くの読者にとって不快になるであろうコンテンツの取り扱いに関しては、Wikipedia:不快なコンテンツをご参照ください。ウィキペディアが検閲を禁じている以上、不快なコンテンツであっても完全に利用するか、完全に利用しないかのどちらかを選択せざるを得ません。そのコンテンツを利用することで得られるものと、失われるものをよく吟味したうえで議論を行うことが求められます。--有足魚（会話） 2017年9月6日 (水) 10:55 (UTC)[返信]

Wikipwdiaに寄付をする時にカードからではなく、振込も取り入れる必要はありませんか？

　個人情報を守るために銀行口座の情報を入力する事には抵抗があります。銀行からWikipwdiaの口座に匿名で寄付が出来る様にしてはどうでしょうか？ 2017年9月6日　室田　辰彦--以上の署名のないコメントは、125.206.103.70（会話）さんが 2017年9月06日 (水) 00:53 (UTC) に投稿したものです（コメントの最後に--~~~~と書くだけで自動的に署名できます。--Triglav（会話） 2017年9月6日 (水) 12:13 (UTC)による付記）。[返信]

コメント 匿名性を重視したいのであれば、ウィキメディア財団はビットコインによる寄付も受け付けています。--Jkr2255 2017年9月6日 (水) 11:27 (UTC)[返信]

曖昧さ回避のソートキーについて

曖昧さ回避ページは（漢字表記のものの場合）表記を基準に作るので、どうしても読み方の違うものが集まってきてしまいます。濁音の違いだけでソートキーを統一できればいいのですが、たとえば

  • 小林修（こばやししゅう/こばやしおさむ）のように意味の区切れまでが同じ読み方の場合
  • 柏原駅（かしわらえき/かいばらえき/かしわばらえき）のように、1文字目だけが同じ場合
  • 南牧村（みなみまきむら/なんもくむら）のように、1文字目すら一致しない場合
  • 板橋駅 (曖昧さ回避)のように、多言語での曖昧さ回避の場合

それぞれソートキーはどのように設定するのが適切、ということになるのでしょうか。--Jkr2255 2017年9月7日 (木) 11:20 (UTC)[返信]

いっそのこと曖昧さ回避ページにはデフォルトソートキーを設定しないというのはいかがでしょうか。Category:曖昧さ回避、Category:すべての曖昧さ回避、Category:人名の曖昧さ回避のような曖昧さ回避ページを収集するためのカテゴリにおいては読みでソートしたところで個人的にはメリットを感じません。このようなカテゴリ内では表記でソートしてしまっても構わないと思います。--本日晴天（会話） 2017年9月7日 (木) 12:29 (UTC)[返信]
ソートキーに漢字表記そのものを指定する方法もあります。個人的には代表的な読みをソートキーにする方が好きですが、漢字がソートキーになっているページもすでにかなり存在しています。--アルビレオ（会話） 2017年9月8日 (金) 23:11 (UTC)[返信]

翻訳記事作成時の出典の書き方（互換性なし）について

近頃、日本語Wikipediaにない英語記事を新規で和訳しました。その際、元となった英語ページの出典 {{Cite web}} の引数の書き方が日本語と互換性がないため、コピペするとエラーになってしまいました。出典数が膨大だったため、手直しにかなりの労力がかかってしまったのですが、記事翻訳の熟練者の皆さまはどのような対応をされ、作業効率化を図っておられますでしょうか？　私が気づいた範囲で、互換性のない引数は以下の通りです。

  • accessdate、archiveurl、archivedate（英語版ではそれぞれaccess-date、archive-url、archive-dateとハイフンを入れてもOK）
  • 日付のフォーマット（英語版ではYYYY-MM-DDではなく、ベタ打ちでSeptember 10th, 2017のように書かれもOK）
  • accessdateが必須か任意か（英語版では任意です）

引数にハイフンが入っている問題は、文字列の自動置換で対応できますが、日付フォーマットの変更は手作業なのでかなりしんどかったです。--Mis0s0up（会話） 2017年9月11日 (月) 05:06 (UTC)[返信]

英語版以外からも手がけることがありますが、まず「他言語版のテンプレート」が翻訳されずにそのまま使える方が例外です。日本語版は英語版の影響力が強いため、英語のままで機能させたり日本語版による発展を排除することすらありますが、本来は例外的な措置なのです。
「互換性がないものはない」のですから、そこは受け入れるしかありません。むしろ一部がそのまま使えるので、楽ができると前向きに考えましょう。
日付のフォーマットについては、英語版について一切考慮する必要はありません。正しいのは日本語版であり、直接記入が蔓延している英語版に問題がありますし（英語版でもYY-MM-DDが正です）、それをYYYY年MM月DD日と書き直すよりはYY-MM-DDが楽ですから。September 10th, 2017なら、2017の後から書き足していけば、書き間違い防止にもなります。
accessdateについては翻訳元に追加された日付を記載したいところですが、これは労力的に難しいことも多いでしょう。ですから、編集時点でも使えるリンクなら再確認してその日付を記載、使えないリンクなら移動やアーカイブを探索して置き換える、accessdateが不要なテンプレートで代替する、テンプレートを解除してaccessdateを回避するといった手があります。楽なのはテンプレートの解除ですが、できれば探索したいですね。
last2、first2、authorlink2等は、まとめてcoauthorsかauthorに追加し、直接リンクを張ります。この時authorに複数人並べるなら、last、first、authorlinkも解除してauthorに変更する必要がありますし、coauhtorsに突っ込む場合でもauthorに変更する方が見た目がきれいになります。editorの場合も同様です。
seriesはtitleに含めてしまいます。適切なものがないなら次善に含めるか、省略で対応するしかありませんから。
コメント 英語版以外からの翻訳も手掛けておられるとのこと。体験談ありがとうございます。私は現状を受け入れるのではなく、日本から改善の声を上げていくべきと考えます。ウィキメディア2030で「真にグローバルな運動」とのテーマで改革・改善の意見を募っています（Cycle 2完了）。このような文脈を通じ、言語間での互換性を持たせていったり、他言語版でお作法を守っていないユーザーに注意を促すなど、グローバルで互換性プロジェクトを走らせるべきでは？--Mis0s0up（会話） 2017年9月12日 (火) 01:23 (UTC)[返信]
コメント 英語版では過去にCite newsとCite webの使い方が混乱していたようです。本来は、Cite newsは紙媒体の新聞ニュース報道に、Cite webはオンライン媒体の全ての記事に対して使うのがルールです。Accessdateが不要だからと言って、紙媒体でないのにCite newsを使うことはNGです。オンライン記事は、執筆後に更新可能なのでいくつもバージョンが存在しうることから、Accessdate（どの断面のバージョンを閲覧したか）を必須にしているわけですし。--Mis0s0up（会話） 2017年9月12日 (火) 01:23 (UTC)[返信]
{{cite web}}を英語版に合わせて使用可能な範囲や表記を増やすように変更することは可能ですが、これをやるまえに日本語化して日英どちらでも機能させることでしょうね。英語版は引数を過剰に設ける傾向があるので、必ずしも1:1にすることは正しくないことに留意してください。--Open-box（会話） 2017年9月11日 (月) 14:07 (UTC)[返信]
コメント accessdateは「WEB出典が確かにWEB上に存在したことを（編集者が）アクセスして確認した日時」なので、これを英語版と同様に任意に変えることで発生すると考えられる弊害の方が大きいと思います（閲覧毎に全員が逐次存在確認せべば実在が確認出来なくなる、消えた場合アーカイブ化しづらい）。個人的対処としては、『現時点で閲覧不能なWEB出典を元に書かれた部分は翻訳移入せず、部分的に捨ててしまう』『現時点で閲覧可能であれば自分がアクセスした日時に付け替えた上で、（元の英語版著作者の訳文を使用せずに）原文から日本語版に直接翻訳移入する』という方法で翻訳しています。
どうしてもaccessdateを入力したくないということであれば、情報源の性質に合わせて{{Cite news}}や{{Cite journal}}、{{Cite book}}などに適時置き換えたり（Category:出典テンプレート参照）、そもそも消えたり移動、移転が発生しリンク切れしやすい不安定なWEB出典ではなく紙媒体に資料を求めて付け替える方法もあります。
あとは、英語版と日本語版で仕様が違うといえば|language=もそうですね。英語版では定型文言入力で定型句が表示されるようになっています（see en:Template:Cite web/doc#Foreign language and translated title）が、日本語版では{{en icon}}を入力するような方法が一般化しているように思われ、これをやると（（英語））といった風にかっこが二重化するので英語版（というか他言語版）と仕様を合わせて翻訳の労力軽減を図るならこちらの方が先では？　と思いました。--Nami-ja（凪海） （会話 / 履歴） 2017年9月11日 (月) 14:54 (UTC)[返信]
コメント Nami-jaさんの方針・個人的な対処に概ね賛同です。私は必ず出典元のオンライン記事を閲覧して、論拠になっているか確認しているため、Accessdateの日付更新が必要となります (そして英語Wikiの記述が間違っていることが多く、日本語化の際にちょこちょこ訂正してます)。ですが英語版がベタ打ちでSeptember 10th, 2017と書かれていると、文字列の長さが一定ではないため自動置換できず、手動で消すのが面倒なのです。何か作業効率をアップさせるツールなどはないものかと探しています。--Mis0s0up（会話） 2017年9月12日 (火) 01:23 (UTC)[返信]
  • こちらで確認したところ, accessdateでもaccess-dateでも作動します。同様に1 Jan 2001でも適切に表示することを確認いたしました。また, cite webではaccessdateの指定は必須です。 --eien20（会話） 2017年9月11日 (月) 23:00 (UTC)[返信]
コメント 具体例のご提示ありがとうございます。ハイフンありでも作動するのですね。サンドボックスでプレビューすると、エラーメッセージが出るのでイライラしておりました（笑）。自分が翻訳時に出典元の内容を確認しているので、Accessdateを翻訳日に更新しています。その際、英語版がYYYY-MM-DD形式でないため自動置換が使えず、古いAccessdateを上書きする作業が手動になってしまい困っています。--Mis0s0up（会話） 2017年9月12日 (火) 01:23 (UTC)[返信]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ コメント それ、「ベタ打ちのままでaccrssdateに転記しても自動的に日本語版書式に変換されます」よ。◆{{Cite}}系テンプレートには日付入力に関して英語版との互換性を維持する{{Citation/showdate}}という内部テンプレートが実装されとりますので、実例を出すと

  • {{Citation/showdate|September 10th, 2017}} ⇒ 2017年9月10日
  • {{Cite web |url=http://hoge.jp/ |title=hogehoge |publisher=[[test]] |date=2017-9-10 |accessdate=September 10th, 2017 }} ⇒ “hogehoge”. test (2017年9月10日). 2017年9月10日閲覧。
  • {{Citation/showdate|17 Jul 2008}} ⇒ 2008年7月17日
  • {{Cite web |url=http://hoge.jp/ |title=hogehoge |publisher=[[test]] |date=2017-9-10 |accessdate=17 Jul 2008 }} ⇒ “hogehoge”. test (2017年9月10日). 2008年7月17日閲覧。
  • {{Citation/showdate|Apr 2003}} ⇒ 2003年4月
  • {{Cite web |url=http://hoge.jp/ |title=hogehoge |publisher=[[test]] |date=2017-9-10 |accessdate=Apr 2003 }} ⇒ “hogehoge”. test (2017年9月10日). 2003年4月閲覧。
  • {{Citation/showdate|2001}} ⇒ 2001年
  • {{Cite web |url=http://hoge.jp/ |title=hogehoge |publisher=[[test]] |date=2017-9-10 |accessdate=2001 }} ⇒ “hogehoge”. test (2017年9月10日). 2001年閲覧。accessdateの記入に不備があります。

となります。大抵の日付を扱うテンプレートには殆ど全てに実装済みになっておりますので、これでご質問の「いちばんめんどくさかった点」は全て解消されたものと思いますが、どうでしょうか？--Nami-ja（凪海） （会話 / 履歴） 2017年9月12日 (火) 13:29 (UTC)[返信]

コメント 詳しいコードの解説、大変勉強になりました。ありがとうございます。Cite webのDataは自動的に変換できるとのこと、コピペのままで大丈夫そうですね。ただしAccessdateは将来的に更新される可能性があるので、自分が新規翻訳する際に原則に則りYYYY-MM-DD形式で記述しようと思います。--Mis0s0up（会話） 2017年9月14日 (木) 07:17 (UTC)[返信]
コメント YYYY-MM-DD形式は「原則」ではありませんし、そのような決まり事も存在していません。Template:Cite web#全ての引数の date の項目説明の通り、英語版の日付形式も含むどの形式で書いても構わないと明記されています。上述の通り、表示は全て同じになるのですから、読者に見えない部分で拘っても無駄で無意味なひと手間でしかないです。--Nami-ja（凪海） （会話 / 履歴） 2017年9月22日 (金) 16:20 (UTC)[返信]

バイト数の大きな記事の場合、日付はYYYY-MM-DDに書き直した方が良いという結論に達しました。日付の自動変換により、サーバーへの負荷が相当に高まることが判明しましたので、他言語記事を翻訳されている方の一助になればと思い、備忘録を投稿致します。現在、出典数が400を超える一覧系の記事を翻訳中なのですが、「エラー: #time の呼び出しが多すぎます」というエラーになってしまいました。調べてみたところ、他の記事でも同様の引数エラーが発生しているものがあり、だいたい出典数が200本を超えると発生しやすいようです。

そのため、翻訳前の日付がSeptember 10th, 2017や10th September, 2017と表記してあったものを全てYYYY-MM-DDに書き換えたところ、サーバーが読み込む引数の数が2割減となり、「エラー: #time の呼び出しが多すぎます」も解消されました。ページの描画速度も若干上がりました。呼び出し数エラーに関してですが、テンプレートの引数読み込みには上限数が設定されています。詳細はHelp:テンプレートの制限をご参照下さい。--Mis0s0up（会話） 2017年10月3日 (火) 02:16 (UTC)[返信]

コメント 遅レス …たまたま気づいたので遅レスです。当方も似たような状況に陥っているページで2017年の日本を手掛けているのですけども、{{Cite web}}をLuaを用いて軽量化した{{Cite web2}}というものがありまして、こちらに変更しますと同時テンプレート使用数が相当に軽減されますので参考までに（ごく簡単に説明すると、Cite web2は日付入力をテンプレート変換せずにそのまま出力します）。同じテンプレート制限値に引っかかってCite web2を代替使用して回避した前例には2017年の日本の他に熊本地震 (2016年)などがあります。--Nami-ja (会話 / 履歴) 2017年11月19日 (日) 19:56 (UTC)[返信]
コメント {{Cite web2}}のご紹介、ありがとうございます。サンドボックスで実験してみたところ、引数の呼び出し数が約8割減でした。描画スピードも速くなることが期待されるので、Cite webからCite web2に置換したいと思いつつも、現時点では見送ろうと思います。理由は、Template:Cite web2のページが完全にTemplate:Cite webのミラーリングになっていて、Cite web2の説明を読めないためです (自分で確認できないものは採用しない主義)。今後のテンプレート解説ページの立項を待ちます。--Mis0s0up（会話） 2017年11月24日 (金) 13:43 (UTC)[返信]

Wikipedia:サンドボックスの利用者サンドボックスの解説、及び誘導について

Wikipedia:サンドボックスの「ログインすれば利用者サンドボックスも使えます。」の「利用者サンドボックス」の部分をクリックすると、閲覧しているアカウントの利用者サンドボックスに飛びます。しかし、その前後にHelp:利用者サンドボックスへの誘導がありません。飛ばされた先の各アカウントの下書きページの書き込み欄最上部にある（自動的に貼られているであろう）Template:User sandboxに一応Help:利用者サンドボックスへの誘導があるのですが、その表記が小さな文字で「登録利用者は自分用の利用者サンドボックスを→こちらから作成できます（解説）。」の「解説」の部分にHelp:利用者サンドボックスへのリンクが貼ってある、という、少々不案内な気がする表記です。Wikipedia:サンドボックスの説明文からHelp:利用者サンドボックスへ飛べるようにしてほしいです。--RJANKA（会話） 2017年9月11日 (月) 13:52 (UTC)◆以上の内容はWikipedia:井戸端 2017年9月11日 (月) 13:52‎ (UTC) の版末文に誤って記入されていたものをuser:Nami-jaが転記したものです。--Nami-ja（凪海） （会話 / 履歴） 2017年9月11日 (月) 14:15 (UTC)[返信]

コメント ご提案の変更はHelp‐ノート:サンドボックスの方へ議論提起し合意することが必要かと思います。が、RJANKAさんは現在ご自身の今後の編集行為の是非に関わるWikipedia:投稿ブロック依頼/RJANKAが審議中でありますことから、議論途中で議論参加が不能になる可能性もありますことですし、先ずは現時点でご自身最大の問題でありますブロック依頼審議の終了を大人しく待ち、審議終了後に仰る提案に取り掛かる順序で行動を起こされた方が誰にとっても利になるものではないかな、と思います。--Nami-ja（凪海） （会話 / 履歴） 2017年9月11日 (月) 14:21 (UTC)[返信]

報告 RJANKAさんは投稿ブロック依頼の審議の結果、無期限ブロックに処されました。--Nami-ja（凪海） （会話 / 履歴） 2017年9月11日 (月) 15:04 (UTC)[返信]

「著名人（内）の記事」の謎

削除の方針のケースB-2の一部が「著名人の記事（内）で」と場所を限定する理由は何ですか? これらは記載された場所に関係なく問題となり削除対象になるのではないでしょうか。--BU100（会話） 2017年9月12日 (火) 07:12 (UTC)[返信]


"真夏の夜の淫夢"系統に関する記事について

真夏の夜の淫夢やそれを元にしたものは、2ちゃんねるやニコニコ動画を始めとした場所において文化といえるレベルにまで達していると個人的には思っています。そして特筆性は非常に強いように見え、しかし意外にも井戸端や編集方針の過去ログで"真夏の夜の淫夢"及び"淫夢"のどちらで検索を行っても一件もヒットせず、右上の検索バーでも3件("真夏の夜の淫夢"のみ、"淫夢"はノイズが多いため不明)の、どれも単独記事ではないものしか出ませんでした。しかしWP:CENSORに基づくと単独記事としての立項は可能であるように思えます。なお検証可能な情報源に関しては、詳細は失念しましたが東京工業大学で何らかの発表があったと記憶しております。

また、本当に東工大もしくは東工大生によって作られたものであるかは定かではありませんが、このような[7][8]Twitterのアカウントを確認しました。 --ikabomb（会話） 2017年9月17日 (日) 14:33 (UTC)[返信]

えーとまずなんですか、jawpにおいては、立項基準はwikipedia:独立記事作成の目安およびwikipedia:信頼できる情報源をご参照頂くとなんとなくわかると思います。また、wikipedia:削除の方針によって、百科事典的な記事になる見込みの無い記事は削除対象となります（著名性については問題はございませんため、それ以外の部分のお話です）。
このため・・・現実的にかみ砕いて申し上げますと、いわゆる「まともな文献」（通常は二次資料）において、淫夢が有意に触れられていると言う事実が必要となります。できれば複数がよろしいです。でないと、百科事典記事な記事にはならず、「辞書」の域を出ないものになります。まずは何とかして、一冊でもよいので、イカ爆弾氏の方で、まともな文献を入手できるよう、行動してみてください。その内容と、コートコーポレーション内の記述からの一部転記で、十分「百科事典的になり得る記事」になると判断できるのであれば、その時にwikipedia:保護解除依頼に、立項が可能となるだけの資料を集めたとし、くだんのページの保護解除を要請してください。そしてその後保護が解除されたのであれば、さすがにまあ、保護解除を申請した人がちゃんとしたものを書かないとな、と言う事になります。書いて頂ける事が前提でなければ、作成保護は解除されないでしょう。
正直まあ、書いてくれ書いてくれでは、どうしようもないです。ご自身で文献を収集され、ご自身での執筆を勧めてください。ローカルのテキストファイルなどで。私も淫夢は大好きですから、書けるものなら書いています。コートコーポレーションには私もそれなりに手を入れているのです。ですが、田舎住まいではなかなか、有意な資料が見付からず、私と致しましてもただただ、了簡の思いにございます（他にはノーパン喫茶、ノーパンしゃぶしゃぶなどが懸案ですが、これも田舎住まいではなかなか・・・）。--Hman（会話） 2017年9月17日 (日) 14:54 (UTC)[返信]
「https://ja.wikipedia.org/w/index.php?title=Wikipedia:井戸端/履歴20200123&oldid=65562419」から取得