コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

「Wikipedia:井戸端/履歴20200123」の版間の差分

リンクを追加
履歴の双方向閲覧
← 古い編集新しい編集 →
削除された内容 追加された内容
ビジュアルウィキテキスト
Trvbot (会話 | 投稿記録)
27,980 回編集
市原 (会話 | 投稿記録)
2,621 回編集
11行目: 11行目:


{{ 井戸端サブページ | title = これは荒らし行為に該当するのか？ }}
{{ 井戸端サブページ | title = これは荒らし行為に該当するのか？ }}

== 千葉市立大椎中学校 ==

[[千葉市立大椎中学校]]の私の編集が差し戻されました。差し戻さなくてよいと思うのですが--[[利用者:市原|市原]]（[[利用者‐会話:市原|会話]]） 2017年9月1日 (金) 09:19 (UTC)

2017年9月1日 (金) 09:19時点における版

井戸端は、ウィキペディア日本語版について、運営、方針、新しいアイディアや作業の仕方、その他様々な事で質問や提案、議論、意見交換を行う場所です。詳しくは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日が経過すると、井戸端への読み込みが解除されます。
投稿しましょう
新しい話題を投稿する
最後にもう一度「ここに質問を投稿する前に」を確認して問題がなければ、初心者は新しい節を追加して、経験者は新しいサブページを作成して投稿してください。

キャッシュを破棄

保護機能の仕様変更について

提案の形式ですが意見募集です。保護機能の変更について、皆様のご意見を伺いたく思います。一定数の賛成意見があった場合、今後改めて具体的な変更提案や運用案の提起を行う予定です。あくまでも今回は大まかな方向性を決めることが目的ですので、ご了承いただければ幸いです。--Marine-Bluetalk✿contribs❀mail 2017年8月17日 (木) 16:32 (UTC)[返信]

概要

提案の趣旨
現在、ウィキペディア日本語版ではアカウント作成から4日と10編集という条件を満たすことで半保護されたページを編集することができます。しかし、この条件は荒らし利用者による寝かしアカウントに対して無力です。
寝かしアカウントによって半保護を突破する荒らしが多発する場合、全保護を余儀なくされ、荒らしのみならず無害な利用者の編集も抑制せざるを得ません。
今回は、このような荒らしによる寝かしアカウントの編集を抑制しつつ、長期的に活動を行っている一般利用者の編集を抑制しない方法の実現を目標としております。

既に運用例があり、実現可能な対策として考えられるのは以下の2つであると考えます。

自動承認の条件を引き上げる。
例えばアカウント作成から30日と100編集によって自動承認される（半保護されたページを編集できる）ように設定を変更するという方法です。やたら条件を引き上げると思わぬところで巻き添えを食う利用者が出てくるかもしれませんが、救済策として「承認された利用者」というグループが利用可能です。ビューロクラットがこの権限を付与できます（今週から解禁）。自動承認と同等の資格を能動的に付与できるものです。
条件の数字はあくまでも一例です。合意が得られるのであれば10日20編集でもいいし、15日30編集でも良いし、60日100編集でも構いません。「救済策を用意した上で自動承認の条件を引き上げる」ことが重要です。
通常半保護の上位互換となる半保護を新たに導入する。
英語版で運用されているExtended confirmed protection（訳語は拡張半保護で良いかな？）という機能を導入する方法です。英語版では30日と500編集以上という条件を満たすとExtended confirmed editors（拡張承認された利用者？）に自動昇格（自動的に権限を付与）するようになっています。条件を満たさなくても能動的に付与する、逆に条件を満たしていても能動的に剥奪することが可能となりますので、加筆量が大きく編集回数が少ない優良編集者を締め出すような自体は回避できるでしょう。与奪のルール設定は色々と難しそうですが、話が複雑化するため、ひとまず今回は触れません。
簡単に説明すると、「長期的に活動を行っている利用者は抑制を受けず、半保護突破目的でアカウントを作成した利用者や長期荒らしの寝かしアカウントに対して効果を発揮する」「拡張承認された利用者が不適切な行動を繰り返す場合、拡張承認を取り消す（半永久的に拡張承認を剥奪する）こともできる」ということです。

意見募集

皆様のコメントはこちらにお願いします。

賛否表明

賛否表明という見出しですが、極めて単純なアンケートであるとお考えください。大まなか方向性として賛成するかどうかです。一定数の賛成があれば今後何日何編集が良いかを具体的に決定します。変更の余地がある/導入の余地があると思う方は賛成、そう思わない方は反対の意見を表明していただければ幸いです。書式は # --~~~~ でお願いします。

自動承認の条件引き上げに賛成
  1. --統一理論者（会話） 2017年8月29日 (火) 15:31 (UTC)[返信]
自動承認の条件引き上げに反対
  1. --Infinite0694（会話） 2017年8月17日 (木) 17:36 (UTC)[返信]
  2. --SilverSpeech（会話） 2017年8月18日 (金) 08:25 (UTC)[返信]
  3. --Hiroes（会話） 2017年8月18日 (金) 09:00 (UTC)[返信]
  4. --Kkairri[話][歴] 2017年8月18日 (金) 18:37 (UTC)[返信]
  5. --Open-box（会話） 2017年8月19日 (土) 01:30 (UTC)[返信]
  6. --夜（会話） 2017年8月19日 (土) 03:18 (UTC)[返信]
  7. --rxy（会話） 2017年8月19日 (土) 13:34 (UTC)[返信]
  8. --ただのしかばね（会話） 2017年8月29日 (火) 17:45 (UTC)[返信]
拡張半保護の導入に賛成
  1. --Infinite0694（会話） 2017年8月17日 (木) 17:36 (UTC)[返信]
  2. --SilverSpeech（会話） 2017年8月18日 (金) 08:25 (UTC)[返信]
  3. --Hiroes（会話） 2017年8月18日 (金) 09:00 (UTC)[返信]
  4. --Kkairri[話][歴] 2017年8月18日 (金) 18:37 (UTC)[返信]
  5. --Open-box（会話） 2017年8月19日 (土) 01:30 (UTC)[返信]
  6. --夜（会話） 2017年8月19日 (土) 03:18 (UTC)[返信]
  7. --Karasunoko（会話） 2017年8月19日 (土) 04:51 (UTC)[返信]
  8. --rxy（会話） 2017年8月19日 (土) 13:34 (UTC)[返信]
  9. --Yuukin0248[会話/履歴] 2017年8月20日 (日) 08:56 (UTC)[返信]
  10. --Knoppy（会話） 2017年8月21日 (月) 17:54 (UTC)[返信]
  11. --Nami-ja（凪海） （会話 / 履歴） 2017年8月22日 (火) 09:34 (UTC)[返信]
  12. --統一理論者（会話） 2017年8月29日 (火) 15:32 (UTC)[返信]
  13. --ただのしかばね（会話） 2017年8月29日 (火) 17:45 (UTC)[返信]
拡張半保護の導入に反対

コメント

何か思うことがあればこちらにコメントを頂けると幸いです。こういう理由で自動承認の条件を引き上げと拡張半保護導入を両方実施すべき、拡張承認のみを導入すべき、などと言ったコメントでも構いません。「私にいい考えがある」と別のアイデアを出したり、「あれれ～おかしいぞ～」と疑問をぶつけたりしても大丈夫です。--Marine-Bluetalk✿contribs❀mail 2017年8月17日 (木) 16:32 (UTC)[返信]

コメント 自動認証条件の引き上げには反対です。その代わりに、2段階と申しますでしょうか、拡張半保護の導入に 賛成 です。特に、拡張承認された利用者の導入は私も以前から検討しておりました。というのも、「本多陽子」において、全保護の更新をしていた際に[1]、LTAの半保護破りを理由に事実上の無期限全保護を設定するのはあまり得策ではないと感じていました。また、「ノート:奈良騒音傷害事件#無期限全保護実施の提案」において、MaximusM4さんが、全保護の更新制は管理者への負担が大きいと述べられています。そこで、例として「30(-90)日・500編集」を必要とする拡張半保護を設定できれば、強力なソックス対策にもなりますし、何よりも、全保護による巻き込みが最小限で済むものかと思われます。ソックパペットを3体用意するにしても、合計1500回の編集が必要ですし、LTAにとっては拡張半保護破りはそう容易いものではなくなるでしょう。それによって、ソックパペットの数が少なくなれば無論、その間に投稿ブロックをする余地もありますし、全保護にしないまでの対策を講じることができます。-- Infinite0694（会話） 2017年8月17日 (木) 17:36 (UTC)[返信]

コメント 仕組みに詳しくないので拙いアイデアだけで失礼します。寝かしアカウントの抑制が目的であるなら、最終編集からの経過時間とかをパラメータに加えられないでしょうか。--Hiroes（会話） 2017年8月18日 (金) 07:43 (UTC)[返信]

と、これだとダミーで編集すれば簡単に抜けられますね。直近の数時間を除いた編集からの経過時間に訂正します。--Hiroes（会話） 2017年8月18日 (金) 07:51 (UTC)[返信]
これもどちらかと言えば拡張半保護のひとつの形になりますね。票を投じました。--Hiroes（会話） 2017年8月18日 (金) 09:00 (UTC)[返信]

コメント 　WP:UAL#自動承認された利用者を確認してみましたが、自動承認の条件を引き上げるとファイルのアップロードなどにも影響が出ますので拡張半保護の方がよいのではないかと思います。--SilverSpeech（会話） 2017年8月18日 (金) 08:25 (UTC)[返信]

（原則として、）ファイルのアップロードはコモンズにすれば良いですから、そういう意味ではどうでもいいといえるかもしれません。それよりも、「CAPTCHAが必要な場面でCAPTCHAをスキップして操作を実行 (skipcaptcha)」、この権限は新参さんでも早いうちに手に入れたいでしょう。とある外部ウィキで新規登録したとき、キャプチャを入力しないと編集できない状態が不便だったので、ビューロクラットさんに頼み込んで「承認された利用者」にしてもらった、ということがありました。そのウィキも jawp と同じように4日・10編集で「自動承認された利用者」になれるのですが、jawp のキャプチャスキップに慣れてしまうと、それですら苦痛でしょうがないのです。
「能動的に付与できる」と仰りますが、実際の付与対象者は、他言語版やコモンズ、姉妹プロジェクトでの編集実績がある人辺りに限定されてしまうと思います。なんせ、本当の新参さんは、キャプチャがスキップできるようになるビジョンなんて思いつきもしないでしょうから、「『承認された利用者』にしてくれ」という発言が出てくるわけがありません。ビューロクラットさんが自発的に、キャプチャから開放されたがっていそうで問題ナッシングな利用者を探し回り、勝手に付与することもできますが、jawp にそんな余裕が無いことは自明です。
さて、面倒なキャプチャから解放される術を知らずに、2回と言わず20回（URLの追加を伴う編集が10回に2回と考えた場合）も味わう利用者の立場に立ってみましょう…… 私なら、「ウィキめんどい」で即完全引退ですね。以上の理由から、自動承認の条件引き上げには Stringy Oppose です。--Kkairri[話][歴] 2017年8月18日 (金) 18:37 (UTC)[返信]

コメント いくつか思いついたことを並べてみます。まず、日本語版でやるべきは「（利用者グループの権限ではなく）投票権限を含めたユーザー権限の整理・見直し」であり、本来はこのようにつぎはぎしていくような方法はまずいので、一度投票資格も含めてまとめた方が良いと考えます。
新規どころかIPでも広範な権限を有している、自動承認は容易に得られるという現状を踏まえた場合、自動承認と新規の差はKkairriさんの指摘されているキャプチャとページの移動にあると考えます。キャプチャは既に説明されていますが、ページの移動も単純な書き間違いを修復できる利点を考慮すると比較的早めに使用できるようにしておきたい権限です。ですから、自動承認を引き上げるなら2段階化してキャプチャスキップと移動や半保護の編集権限を分離するのが望ましいのですが、いずれにせよ早期に取得する権限のためあまり効果が無いと思われます。自動承認の2段階化を行うよりは現状で（2段階化するなら各種投票権限の50編集でしょうが）。
現在の半保護の上位互換となる保護の導入は必要と思われます。現在の半保護は機能する場合がIPによるいたずら防止でしかなく、ミートパペットを含む論争用アカウントには無力です（導入意図は「荒らしによる寝かしアカウント」とのことですが、こちらが発生しやすいと考えます）。Extended confirmed usersは利用者グループなので、編集に当たって経過時間などのパラメータによる制御は好ましくないと考えます。また、一過性のいたずら防止に強固な保護は適切ではないため、現在の半保護も維持すべきと考えます。
名称ですが、仮保護（現在の半保護）と半保護を考えてみました。拡張半保護は英語版の表現に引っ張られて違和感がありますが、それ以上に上下を作りにくくなるので、予防線を張っておくのがよいと考えます。Extended confirmed editorsも上下が発生する可能性を考慮する必要はありますが、自動承認と申請を分けない・新規の利用者グループ・要点は権限拡大なので「拡張権限利用者」（登録利用者に合わせてみる）とか「権限が拡張された利用者」（自動承認された利用者に合わせてみる）ぐらいでどうでしょう？　
自動承認条件で30日かつ500編集は少し甘いと考えます。英語版のNew page reviewer立候補資格を参考に60日・標準名前空間500編集ではどうでしょうか。個人的にNew page reviewer（レビューやってるわけじゃないんで、記事承認者ぐらいかな？）は早晩必要になると考えているのもありますが、編集数って争ってる人ほど標準名前空間以外で稼いじゃう・議論期間が1月ぐらい取られるので、四半期は長くても30日では有効に機能しないと考えるのです。また与奪は出来ることになっていますが、付与は容易でも剥奪は難しいと考えますので、自動承認は少し高めに設定してもよいのではないでしょうか。--Open-box（会話） 2017年8月19日 (土) 01:30 (UTC)[返信]

コメント この場で条件設定を決定するつもりはないため、取り敢えず英語版の30日500編集を提示したまでです。別に60日でも90日でも、それで上手くまとまれば何の問題もないと考えます。色々なご意見を伺った上で、今後具体案を提示出来ればと考えております。また、最初に提示したとおり永久剥奪は分かりやすく説明すべく提示したのですが、実は永久剥奪をせず自動再昇格できるような設定も可能です。当然ながら、ここら辺も詰めていく必要があります。--Marine-Bluetalk✿contribs❀mail 2017年8月19日 (土) 08:56 (UTC)[返信]
失礼、自動再昇格は読み違えたかもしれません。一応訂正しておきます。--Marine-Bluetalk✿contribs❀mail 2017年8月19日 (土) 12:24 (UTC)[返信]

コメント いいんじゃない? --rxy（会話） 2017年8月19日 (土) 13:34 (UTC)[返信]

コメント 極めて単純なアンケートとした考えても、現状等を深く吟味して考えても、拡張版保護の導入には賛成します（自動承認の条件引き上げの賛否なし）。自動承認の条件を引き上げた場合、ビューロクラットに「承認してください」と申請することが想定されますが、そこで荒らしが普通の利用者を装って申請した場合にそれをビューロクラットが承認すると、半保護が荒らし放題となります。当然これを想定して、相当なこと（他wikiで広く認められている場合など）でない限り承認しないでしょう（ここまでは上で述べられています）。また広く認められている利用者だとしても、承認するビューロクラットの判断に委ねられるため、ビューロクラットの仕事も増えてしまいます。他にも、上で述べられている移動とかの問題もあります。

対して拡張半保護の場合は、今までと同じ「保護依頼」で管理者に認められた場合は任意の期間の拡張半保護が可能になります。これは、「自動承認された荒らし」に対して極めて有効だと思います。拡張半保護の編集条件はデフォルトを設定した上で、上限下限の範囲内で自由に変更できる、というのもありかもしれないですね。--Yuukin0248[会話/履歴] 2017年8月20日 (日) 08:56 (UTC)[返信]

コメント 移動荒らしなどの例を見ていると、現状の自動承認では緩いのではないか、と思わないこともないのですが、少し基準を上げるくらいでは突破する側は突破するわけで、デメリットの方が大きくなってしまうのかなと。ただこれは拡張半保護についても同じで、この提案の対象であろう長期全保護されている記事は特定の荒らしが特定の記事に執着しているので、基準の高低に関わらず自動で付与されるような条件だと効果があるのか、むしろ生体bot的編集で回数稼ぎが行われて違った弊害が出てくるのではないかという懸念があります。とはいえ、更新制全保護で通常利用者が編集できない弊害というのは非常に大きいため、中間の制度を作るという趣旨には賛成です。--Knoppy（会話） 2017年8月21日 (月) 17:54 (UTC)[返信]

コメント　半人前の戯言な気もしますが、参考になるかも知れませんので、コメントしますね。
  • 巻き添えが多い上に、善良を振舞って救済策を適用される荒らしも考えられる為、『自動承認の引き上げ』は無力だと思います。なので、反対します。
  • 半保護と全保護の間に、もう一段階、保護レベル(拡張半保護)を追加するというのは、拡張半保護までは必要ない半保護記事が巻き込まれない為、デメリットは最小限になっていると思います。
加えて言うなら、拡張半保護にも、幾つかランクを設定してはどうでしょうか？
理由としては、巻き添えで編集できなくなる人を、出来るだけ少なくする為です。また、日数や編集回数を、任意に設定するよりは、管理者側の負担が少ないのではないかと思います。(５０日と６０日、どちらが適切だろうかとかではなく、直観的に設定できる為)
  1. レベル０：現状の半保護
  2. レベル１：３０日１００編集（一か月経過で、多少は編集している）
  3. レベル２：３０日５００編集（一か月経過で、ある程度の編集をしている）
  4. レベル３：６０日５００編集（二か月経過で、ある程度の編集をしている）
  5. レベル４：１８０日５００編集（半年経過で、ある程度の編集をしている）
  6. レベル５：３６０日５００編集（一年経過で、ある程度の編集をしている）
  7. レベル６：３６０日１０００編集（一年経過で、多くの編集をしている）
  8. レベル７：７２０日１０００編集（二年経過で、多くの編集をしている）
  9. レベル８：７２０日２０００編集（二年経過で、かなり多数の編集をしている）
  10. レベル９：７２０日３０００編集（二年経過で、非常に多くの編集をしている）
  11. レベル１０：全保護
みたいな感じです。(もちろん、全保護を編集できる権限を持つ人は、仮に日数が足りていなかったとしても、編集可能。)
レベル７とかは結構厳しいように一見見えますが、全保護よりはずっとマシな筈です。(ちなみに僕の場合、この例だと、レベル７は編集できますが、レベル８は編集できません)
少しでも、参考になれば幸いです。それでは、長文駄文、失礼しました。--ただのしかばね（会話） 2017年8月29日 (火) 17:45 (UTC)[返信]
コメント 現状では細かく分けるとその区分の数だけ利用者グループの区分を作る必要があります。半保護を四段階も五段階も分けた事例はさすがにないだろうし、運用例のないものを導入するのはかなり手間がかかるでしょう。全くの新機能を提案しているわけではなく、他言語版で使われている機能の導入提案なのです。拡張半保護にせよ、廃案とする半保護基準の引き上げにせよ、実際の運用例などを考慮し、合意があれば実現できる可能性が高いと考えて提案しております。どうしても保護よりも細かい区分が必要であれば、そのときはひとまず編集フィルターによる対応を検討したほうが良いのではないでしょうか。--2017年8月29日 (火) 18:39 (UTC)
返信
ブレインストーミング的な感覚で、言ってみた感じです。段階を少なくして採用するなり、そこまでは不要と却下するなり、先達の皆様の判断で良いと思います。
……というか、利用者グループによる区分と、編集フィルターの違いが、よく分かっていません。各利用者のステータスを参照して、自動的に権限の変化に対応できると思っていましたが、それが有っているのかもわかりません。
なので、『半人前の戯言な気もしますが、参考になるかも』というだけで、それ以上の他意は有りません。--ただのしかばね（会話） 2017年8月29日 (火) 18:50 (UTC)[返信]
ログを見ると、『英語版の30日500編集』と有りますね。
  1. 現状の半保護（通常なら、これで十分）
  2. ３０日５００編集（↑では不足な場合に設定する）
  3. ３６０日１０００編集（↑でも執着する人も、一年も有れば平常心に戻る筈）
  4. 全保護（↑をすれば、後は個人のブロックで十分だろうけれど、それでもダメな場合に設定する）
位なら、どうでしょうか？
尚、先述の通り、あくまでも参考になるかも程度で、主張するというほど強い意志は有りません。--ただのしかばね（会話） 2017年8月29日 (火) 20:57 (UTC)[返信]
コメント 詳しくないのであれば是非、こういうことは実現できるかと尋ねてください。例えば「拡張半保護でも不安なのだ！」として具体的な理由を挙げていただければ、私は少しでも配慮する手立てはないかと考えます。しかし実現可能かどうかも分からないまま、原案からかなり飛躍した案を投げられても汲み取りきれません。アイデアを募って新機能開発を頼むのは手が掛かると考え、既に運用例があるものの導入を検討しております。つまり採用可能なアイデアにはある程度の限度があると言うことです。ご理解いただければ幸いです。--Marine-Bluetalk✿contribs❀mail 2017年8月30日 (水) 15:47 (UTC)[返信]
コメント このセクション冒頭であなた自身が『「私にいい考えがある」と別のアイデアを出したり』と書いておきながら、ここであなたがこの時点において否定的意見を出されることに私は違和感があります。本セクション冒頭の書き方であれば、ブレーンストーミングかと思われても仕方がありません。この書き方をしているのなら、アイデアを書くことくらいは好きにさせればいいと思いますし、この段階では否定的意見を書くべきではないと考えます（そもそも本提案時にスルーするか、条件がややこしくなるから見送りとすれば済む話; 否定的意見を書いてもいいのなら、このコメント欄に反対意見としては弱いと思うものすべてに反論を書いちゃいますが、よろしいですか）。私としては面白い案だと思います。また、『詳しくないのであれば是非、こういうことは実現できるかと尋ねてください』と仰っておきながら、その場所を指定していないし、それをここでやることも問題ないのではないですか。Special:Diff/65304464 は、『原案からかなり飛躍した案』でもないと私は思います。ついでに、いくつか矛盾や平然と技術的に間違ったことを述べられているので、次のとおり指摘しておきます。『細かく分けるとその区分の数だけ利用者グループの区分を作る必要』があるのは【保護レベルを mw:Manual:$wgRestrictionLevels で設定し、権限参照を mw:Manual:$wgGroupPermissions に基づく場合】であって、これは「全くの新機能」ではありません。半保護レベルを複数段階に分けた事例は確かに私が知る限りありませんが、保護レベルを数段階に分けている事例は英語版の "templateeditor" や、ヘブライ語版ウィキペディアの "autopatrol", "templateeditor" などがあります。また、「編集フィルターによる対応を検討」ができるということは、それを mw:Manual:Hooks/EditFilter や mw:Manual:Hooks/getUserPermissionsErrorsExpensive, mw:Manual:Hooks/ProtectionForm::buildForm 辺りを使えば保護レベルの扱いとして追加の権限区分を作る必要なく実装することも可能です（この手法は明らかに『新機能』で、実質 Extension を書くことと等価ですが、WMF は設定ファイルにフックを利用する設定を結構書いてあります）。--rxy（会話） 2017年8月30日 (水) 19:07 (UTC)[返信]
コメント 失礼致しました。当初予定より大幅増と言われて驚き、反射的に拒否してしまいました。ご指摘ありがとうございます。
つまり、あれれおかしいぞを華麗にセルフでフラグ回収するというアホなことを…とまぁそれはさておき。区分を増やす発想がなかったのでどういう風に需要を汲めば良いのか、俄かには分かりません。半保護よりも上の区切りがひとつあれば、不適切な寝かしアカウントを十分に遮断できると考えていたものでして。
ただ、さすがに選択肢を増やしすぎると、方針提案のとき、提案者たる自分が議論をまとめきれない気がします。対処者にとっても選択肢を際限なく増やされれば却って面倒になるでしょう。やるなら5-6段階くらいが無難かもしれません。--Marine-Bluetalk✿contribs❀mail 2017年8月31日 (木) 06:48 (UTC)[返信]

小まとめ

皆様コメントありがとうございます。クローズではありませんが、いったんまとめとしてコメントします。拡張半保護に賛成が多いため、今後導入提案を進めて行こうと思います。自動承認引き上げはあくまでも選択肢としての一案だったので、別にこだわりはないです。賛成意見もないため素直に廃案で。

30日500編集などの承認条件などを次回の提案時に確定させたいところです。また、方針運用案の議論を新仕様提案と一緒に行うと話がまとまらないため、いったんある程度の仕様を決めてから方針を固める予定です（大まかな仕様の決定→方針運用案を策定）。

なにかご意見があれば引き続き、#コメント節にコメントをいただければ幸いです。--Marine-Bluetalk✿contribs❀mail 2017年8月22日 (火) 01:23 (UTC)[返信]

「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で検索してみたところ、ニコニコ大百科[2]ではネットスラングおよびNGワード回避目的で「fuck」の意味で使われていると書かれていました。また、Weblio[3]によれば、Weblio英語表現辞典では英国で「fuck」の意味で使われていること、Wiktionary英語版ではやはり英国やコックニーで「fuck」の意味で使われていることが掲載されていました。一方、goo辞書[4]ではランダムハウス英和大辞典で米国黒人の俗語で「真実」の意味で使われていることが掲載されていました。個人的な意見としては、この程度の微妙なラインの単語であれば積極的にブロックする必要はないかと思われます。仮にいたずら等が目的でわざと紛らわしい利用者名をつけたのであれば、その内に他の方針違反でブロック対象になるのではないでしょうか。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件以上の火災と書きましたが、消防法ではなく、消防庁告示の「消防に関する都市等級要綱」によるものでした[5]。なので、上記の私の発言を受けた「消防法」を「消防庁告示の消防に関する都市等級要綱」と読み替えてください。以下では「消防庁告示」とします。
補償問題というのはこうした災害には付きまといますが、それが大きくクローズアップされて、少なくない媒体が報じていることが重要になります。「消防庁告示で大火に分類されるから著名性がある」ではなくて、人的被害が無かったにせよ被害面積が大きく、多くの報道機関が取り上げ、かつ補償問題（出火元の責任だけなのかという責任論から、被災者生活再建支援法でどこまで補償できるのかまでさまざまありますが）もクローズアップされている件ですので、第三者出典が集められるので著名性があるといえるのではないか、という結論に達しているのです。大火だから、補償問題があるから、という単独だけで著名性をはかっているのではありません。大火に分類され、多くの被害を出し、補償問題が取り上げられていることが、複数の信頼できる第三者による情報源で示せているから、著名性や特筆性があるでしょうと帰結するのです。
大火というのはものによって評価方法が異なり、焼失面積によるもの（分類のために基準を作ったという後付け）もあれば、被害建物数から算出しているがその数値が消防庁告示とは異なるもの（『大火調査資料』、損害保険料率算定会）もあります。いずれも東京消防庁からの引用です。なので、最終的には「どれだけその火災が注目されたのか」を証明できれば書けるとするべきです。
例えば、ホテルニュージャパン火災は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)[返信]

なぜその例を出したのか分からないので念のため先に書いておきますが，「東京と大阪の間」という意味での「東京 - 大阪」のようなハイフンは今回の議論の対象外です（議論対象は引き算や負の数などを表すときに用いるいわゆる「マイナス」です）．
さて，ハイフンで閲覧に支障をきたす環境についてはどのようにお考えでしょうか？　この部分が一番の問題だと私は思っているので，それに対する言及なしにハイフンを支持・変更は望まないと主張されても，議論になりません．
マイナスの入力については，ウィキペディアではパソコンだと編集画面の下（投稿とかプレビューのボタンよりも少し下）に「マークアップ」「記号」「ギリシャ文字」というのが（少なくとも私の環境では）あって，その「記号」のところに +, −, ×, ÷ が並んでいるので，そこの − をクリックすればいいです．あるいは，文字実体参照で − と書くこともできます（区別しづらい編集者のことも考えるとこちらの方がいいのかもしれませんが，ソースが変わるだけで表示は同じです）．あるいは，− を辞書登録するという方法もあります（私はこれ）．
それから，これは 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 のデフォルトがメイリオであることからも，ハイフンを用いるデメリットの大きさは容易に想像がつくと思います．ちなみに自分のスマホ（あるアンドロイド）のデフォルトのブラウザでも違いははっきりしています [6]（フォントは知りませんが）．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円も得をしません。むしろ可処分時間を取られたと言う意味で、損をしています。一般的な勤め人であれば、「必要経費」は申請すれば所属組織から出る場合が多いでしょうが、これは所得ではなく、所属組織に貸し付けていた必要経費と言う金員を請求の上で払い戻させただけに過ぎません（出張費などは一応所得でしょうかね）。また、二次創作の界隈などでは伝統的に、「商用利用は不可、ただし必要経費や手間賃の回収については商用利用とは見なさない」と言う概念がございます。

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

しかしながらウィキペディアは「無償のボランティアだ！！」と言うことで長くやってまいりました。よって、必要経費すらも違和感を覚える方も多くいらっしゃると想像できます。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)[返信]


これは荒らし行為に該当するのか？

最近自動車関連の記事で、事実とは異なる記述を書き加えたり、個人的な考えを記述する利用者がいたため管理者伝言板へ報告。その後3日ブロックされました。1つ気になったのですが、SUVと書いてあるのをクロスオーバーSUVとするのは荒らし行為なのでしょうか？--S2AP1（会話） 2017年8月29日 (火) 11:18 (UTC)[返信]

こんにちは。おもな荒らしについてはWP:VANDALに載っているとおりです。SUVをクロスオーバーSUVに変更する行為を、荒らしの意思をもって行った場合は荒らしと認めます。今回の場合はWP:SNEAKYに当てはまるのではないでしょうか。--Yuukin0248[会話/履歴] 2017年8月31日 (木) 04:38 (UTC)[返信]

千葉市立大椎中学校

千葉市立大椎中学校の私の編集が差し戻されました。差し戻さなくてよいと思うのですが--市原（会話） 2017年9月1日 (金) 09:19 (UTC)[返信]

「https://ja-two.iwiki.icu/w/index.php?title=Wikipedia:井戸端/履歴20200123&oldid=65331915」から取得