Wikipedia‐ノート:表記ガイド/過去ログ13

このページは過去の議論を保存している過去ログページです。編集しないでください。新たな議論や話題は、Wikipedia‐ノート:表記ガイドで行ってください。

旧過去ログ1（2004-03～） - 旧過去ログ2（2006-12～） - 過去ログ1（2007-05～） - 過去ログ2（2007-06～）（数字のコンマ区切りについて - 単位の前の半角スペースについて - 姓名の順序とコンマのこと - 括弧の使い分け (約第4回)） -
過去ログ3（2007-12～） - 過去ログ4（2009-05～） - ~~過去ログ5~~ 表記の統一の指針関連（① - ②）（2009-06～） - 過去ログ6（2009-08～） - 過去ログ7（2010-02～）（西暦と和暦を併記する際の順序について - 「仮名」節の変更について（2010年） - 括弧の使い方について） -
過去ログ8（2011-01～） - 過去ログ9（2011-04～） - 過去ログ10（2012-11～）（文字コード関連 - 丸数字の使用基準作りの提案） - 過去ログ11（2014-04～） -
過去ログ12（2015-02～） - 過去ログ13（2016-01～） - 過去ログ14（2016-06～） - 過去ログ15（2017-05～） - 過去ログ16（2018-07～） -
過去ログ17（2020-06～） - 過去ログ18（2021-06～） (edit)

波ダッシュとチルダに追加文の提案

まず前提として、私の認識から述べます（誤解がありましたらご指摘ください）。また、ここでは字体の上下逆を問題にしているのではなく（そちらは将来的に解決の目処は付いているそうです）、純粋に文字化けせずに表示されるか否かを問題としていることにご注意ください。世の中には

全角チルダ「～」(U+FF5E)は表示できないけど波ダッシュ「〜」(U+301C)は表示できる環境
波ダッシュ「〜」(U+301C)は表示できないけど全角チルダ「～」(U+FF5E)は表示できる環境

の両方が存在するため、どちらかに統一して「代用」することができません。そこで、どちらも「（原則として）使用しないでください」となっているものかと思います。しかしWikipediaは百科事典ですので、必要な部分であれば機種依存文字であろうと「正しい表現」を使わなくてはなりません。そこで「やむを得ない場合」に限り、波ダッシュの使用が認められています。この結果、通常はマイナスハイフンで代用され、「やむを得ない部分」で波ダッシュが使われます。必然的に、全角チルダはほぼ例外なく使用が禁止されており、通常これらの波線類は雑草取りの対象と見なされているようです。なおアニメや特撮の記事では台詞の引用時に耳コピによって長音記号代わりに波線が書き込まれる場合も少なくないため、そちらはWP:JPE#長音記号にしたがって「ー」に置き換える場合もあるでしょう。

しかし現実には1.の環境に偏った不公平な運用が行われており、雑草取りによってほぼ機械的に全角チルダが波ダッシュに置き換えられているような状況です。雑草取りは通常、何か別の編集のついでに行われるものですので「波ダッシュでもやむを得ない場合」か「ハイフンマイナスで代用可」か「台詞内長音の耳コピ」かを判別するまで気が回らない場合もあるでしょう。しかしそのような状況なのであれば、そもそも波線の対処に手を付けるべきでは無いと思います。ところが現状では全角チルダは例外なく禁止と受け取れる旨が明文化されているのに対し、波ダッシュはそうでもないため、雑草取りのときにいちいち気を回している余裕は無い＝やむを得ない場合と解釈でき、「全角チルダ禁止令」を優先して「全角チルダを（本来のマイナスハイフンではなく）波ダッシュに機械的な置換」が行われている状態にあるのです。しかし、そのような編集が横行されますと、2.の環境の人にとってはただの迷惑でしかありません。2.のような環境は恐らくUnicode対応が不完全なので編集は推奨されないという意見もあるようですが（1.であっても対応が完全とは限りませんが）、閲覧のみの利用もあるので配慮は必要だと思います。いかがでしょうか。

とりあえずその観点から見える現状のガイドラインにおける問題点は、「全角チルダの禁止」を必要以上に強く訴えているがために「ハイフンマイナスで代用」が軽視されていること（むしろそちらが優先されるべき）、「必要な判断を省いた機械的な置換」が禁止されていないことと、そもそも字体が上下逆の問題だけが言及されていて1.と2.の両方が存在する問題に言及されていないことによる利用者の無理解があると思います。取り急ぎ、そのへんを目的とした改訂を提案します。

WP:JPE#波ダッシュの文の最後に、以下の文面を追加。

さらに、どちらの文字も環境によっては文字化けする問題があるためでもあります。

WP:JPE#チルダの最初の段落の最後（「使わないでください。」の後）に続けて、以下の文面を追加。

誤って使われている（全角）チルダを修正する際は#波ダッシュに準じます。したがってハイフンマイナスで代用可能であれば代用しなければならないため、暫定的に波ダッシュに置換することは推奨されません。どちらが妥当か判断できない場合は、急いで修正する必要はありません。

一例ですが、以上のような感じでどうでしょうか？ --Gwano（会話） 2016年1月22日 (金) 14:47 (UTC) - 後者の提案文を修正します。--Gwano（会話） 2016年2月2日 (火) 14:50 (UTC)

2番目の追記案には反対します。「波ダッシュ（〜）や全角チルダ（～）の一部がハイフンマイナス（-）や長音符号（ー）の代用になっていること」と「全角チルダ（～）が波ダッシュ（〜）の代用になっていること」は依存関係に無い個別の問題であり、後者の解決の前提条件として前者の解決を置くのは筋が違うように思います。--Yqm（会話） 2016年1月26日 (火) 00:49 (UTC)

思ったのですが、波ダッシュの一部をマイナスハイフン（一部は長音記号）で置き換えることは現行の表記ガイドで決まっているのに対し、少なくとも全角チルダの置き換え先として波ダッシュを使うかどうかについては規定されていません。現行の表記ガイドでは波ダッシュと全角チルダはあくまで「全く別の文字」として扱っており、PCのデフォルト入力で全角チルダが出てくる件も、それが間違いと強調するような形で強く否定されており、両者に関して「代用」という概念がそもそも無いのです。そうなると現行のガイドラインでは全角チルダの置き換え先として波ダッシュが適当かどうかは個別に判断せねばならず、だったら最初からマイナスハイフンも検討に含めて良いのではないか？とも言えそうに思います。結局のところ現行の表記ガイドをベースにするなら「全角チルダを使わない」と「マイナスハイフンで代用」はどちらが優先されるべきか？という問題に帰着できると思うのですが、どうでしょうか。--Gwano（会話） 2016年1月26日 (火) 14:51 (UTC)

ご指摘にもあったように、「前提」に対しては本来、提案の前に意見を募っておいたほうがスムーズだったかもしれません。今回は、現行の表記ガイドにはない私見である「前提」に対する意見募集と、改定案の提案を同時に行ったものですので、少々話を整理します。上記の通り私は「全角チルダを使わない」と「マイナスハイフンで代用」は、後者が優先されるべきと前提しましたので、その認識が正しいかどうかも検討する必要があるでしょう。そして上記のように全角チルダが「必要以上に」強く否定されているのが問題だという前提もありますので、それだけ強く否定する理由があるのでしたら、それも考慮しなければなりません。それと結果的にではありますが、今回の提案文では波ダッシュと全角チルダの代用関係という概念の導入自体が提案されていたとも言えます。

どちらにしてもチルダの提案文については作り直しになるとは思いますが、その前に上記の点について、より広くご意見を待ってみたいと思います。--Gwano（会話） 2016年1月26日 (火) 14:51 (UTC)

1週間経ちますが、後者の提案文が練れておらず、前提条件が多くてご意見しづらいと思いますので、以下のように改訂いたします。

WP:JPE#チルダの最初の段落の最後（「使わないでください。」の後）に続けて、以下の文面を追加。

間違って使われている（全角）チルダを修正する場合は、文脈上どの文字が適しているかを踏まえ、表記ガイドの他の取り決めに反しないように編集してください。特に、字形の似る#波ダッシュについてはやむを得ない場合のみ使用される点にも注意が必要です。

代用の概念という前提を弱くして、既存の方向性になるべく干渉しない無難な説明を意識したつもりですが、いかがでしょうか。--Gwano（会話） 2016年2月2日 (火) 14:50 (UTC)

そもそも入力リスクを抱えてまで波ダッシュ優先は妥当なのか？

多くの諸兄が長年にわたり激論を重ねて頭を悩ませてきた問題を、今さら（しかも素人が）蒸し返すのは非常に心苦しいこととは存じますが、予めご容赦ください。もともと波ダッシュと全角チルダまわりのガイドラインは9年くらい？前に決められたルールですし、今となっては素人目線では少々疑問もあるので、ついでながらお伺いしておきたいと思います。私自身、文字コードの問題に詳しいわけではありませんので、ここから先は提案というよりも、現時点で提案に値するか否か識者のご見解を伺いたいと思っております。当時の議論のログは関連議論も含めてかなり長いものであり、私も大雑把な斜め読みしかしておらず、そもそも先行議論の存在に見落としがあるかもしれないことは、あらかじめ断っておきます。以下、長文失礼します。

まず、1.（全角チルダ「～」(U+FF5E)は表示できないけど波ダッシュ「〜」(U+301C)は表示できる環境）というのは、今時どれくらいあるものなのでしょうか？

9年前の議論の発端は、とあるIP氏によりauのケータイで波線（全角チルダ）が文字化けする問題が報告されたことかと思います。よく考えてみると、当時の端末は2012年の800MHz帯の周波数割り当ての再編によってほぼ一掃されているはずなんですよね。私は新800MHz帯に対応したauの交換対象モデルとして2011年のPT002にしましたが、こちらでは波ダッシュも全角チルダも問題なく表示されています（下表のように半角チルダは文字化け）。そもそも現在は当時とはモバイル環境が大きく異なるはずなので再検証の余地があると思います。最近のスマホであれば自由度が高いと思うので、アプリ次第で解決できる可能性もあるのではないでしょうか？

もう一つの疑問は、2.（波ダッシュ「〜」(U+301C)は表示できないけど全角チルダ「～」(U+FF5E)は表示できる環境）について、古いWindowsやMS-DOSに固有の問題であるかのように認識されている点です。そのためか字体が上下逆になる問題のほうばかりがクローズアップされ、「問題のすり替え」が起こっていたような印象を受けるのです。実際には以下のように当方の環境で問題が確認できたのは非DOS/非Win環境（確認くん[1]の情報を信じるなら、恐らくLinux系と思われます。）における2.ばかりであり、全角チルダの表示されない環境は無かったため、そもそも1.に配慮する必要がどれだけあるのかがむしろ疑問に思える程です。最初のIP氏は1.の端末について（当時の時点で）軽く100万台はありそうに言っていましたが、2.については現時点で同じことが言えそうで、軽く100万台くらいはありそうに思えます。

製造年	製品	ブラウザ	波ダッシュ	全角チルダ	半角チルダ	備考
2006	ニンテンドーDSブラウザー	機器内蔵版Opera8.5	不可	可	可	＊1,4
2010	ビエラTH-L32R2（HDDテレビ）	アクトビラ機能	不可	可	可	＊2,3
2011	ブラビアKDL-46HX820（3Dテレビ）	機器内蔵版Opera9.8	不可	可	可	＊4
2011	PT002（携帯電話）	EZweb機能	可	可	不可	＊3

＊1 今となっては重い。また無線LANのセキュリティ面でも厳しい。

＊2 近年のMediaWikiのセキュリティ強化により直接閲覧はできなくなっているが、Wikipediaのコピペサイトを通じて問題となる可能性がある。

＊3 「不可」の個所はクエスチョンマークに化ける。

＊4 「不可」の個所は全角スペースに化ける。

個人的には編集時はPCを使うので問題は無いのですが、ウェブ閲覧だけならTV感覚で気楽に大画面を使用できて、起動時間もPCよりは恐らく速いブラビアをメインで使っているので、現在のWikipediaの波ダッシュ贔屓の習慣にはしばしば不便を感じることがあります。結局のところ積極的に編集、つまり発言される方々にとっては問題となりにくく、閲覧のみ利用されている方々で問題となりやすいため、あまり表面化しなかったのかもしれません。また家電内蔵ブラウザはモバイル機器と違ってアプリや端末そのものを頻繁に交換されるようなものではない点も厄介です。恐らくソニータイマーでも発動しない限り、東京オリンピックの頃までは使われ続けることになるでしょう。最近の機器内蔵ブラウザでは改善されているのかどうか分かりませんが。

Wikipediaは正しい表現を使う必要があると言っても、ローマ数字のように代用を認めている文字もあるので、波ダッシュと形の同じ全角チルダを避ける理由には弱いと思います（どちらも文字化けする可能性がある点は同じ）。当時の議論によれば他にも問題としてサブタイトルを囲う波線に全角チルダが使われていると、英語版に翻訳された際に（本来はハイフンマイナスであるべきなのに）半角チルダが不適切に使われてしまう、という指摘もありました。しかしこれも編集（移動）で対処可能な些細な問題であり、文字化けで何も表示されない問題に比べたら、どちらを採用しても大差ないと思います。そう考えると「やむを得ない場合」に、わざわざ逆字体問題や入力方法に不便を強いてまでして波ダッシュを優先させる理由が、どうにも素人にはよく理解できないのです。やむを得ない場合に全角チルダでは何がそんなに問題なのでしょう？過去ログでは全角チルダは「（本来の定義からして根本的に）間違っている」という論外扱いで済ます発言が目立ちますが、文字コードが正しくないこと自体は上記の通り「代用」が認められているWikipediaにおいては字体が同じであることのほうが「正しい表現」の理念に合うと思うので、理由にならないと思います。外部サイトでの波ダッシュと全角チルダの混在具合は調べてみなければ分かりませんが、少なくとも入力の時点で全角チルダがほぼデファクトスタンダードに近いような状況では、ウェブ上もそちらが主流であろうことは想像に難くありません。それに反してまで波ダッシュを優先されるのであれば、それを覆すだけの納得のいく（素人向けの）説明が欲しいところです。以上ご一考いただければと思います。

実際のところ波線が表示されないくらいでは意味が取れなくなるほどのケースはそう多くもないので優先度は低い問題だとは思いますが、それでも閲覧時に不自然な全角スペースや文字化けが頻繁に出現することから余計な詮索を生むので、機種依存文字の中でも特に使用例の多い波ダッシュの問題は無視できないと思います。そもそもハイフンマイナスを優先させる原則自体が充分に浸透していないことからして、どうにかできないものかと思います。波ダッシュにせよ全角チルダにせよ「できるだけ使わない」ことはそこまで徹底できないものなのでしょうか？その都度ハイフンマイナス（または長音記号）を優先してくださいと各所で説いてまわるのも正直疲れます・・・。とりあえず現状で問題があることだけはご認識を願います。--Gwano（会話） 2016年1月22日 (金) 14:47 (UTC) - 念のため型番追記。--Gwano（会話） 2016年1月26日 (火) 14:51 (UTC)

コメント 直接的な回答にはなっていないかもしれませんが、思うところを述べます。Wikipediaを閲覧する際に利用している端末・OS・ブラウザには多様性があると思います。とはいえ、それら全ての組み合わせを考えていてはきりがないと思います。

端末でいえば、フィーチャーフォン（ガラホは含みません。）は独自OSを搭載しているはずですが、それでネット閲覧が出来るからといっても、昨今の一般的なサイトの閲覧には非常に不向きとなっているのではないでしょうか。

Windows搭載PCでいうならば、セキュリティ上の問題もありますから、サポート中のOSかつブラウザで閲覧できれば良いのではないでしょうか。現に最新版のInternet Explorer（基本的には11だが、Vista・Server 2008は9、Server 2008 R2は10）しかマイクロソフトのサポートがなされなくなっていますから、そうではないOSやブラウザからの閲覧を想定した対応を行わず、サポート中のOSやブラウザで正常に閲覧できるようにしたほうが良いのではないかと思います。

本件に加え、セキュリティという面からも考えるならば、閲覧推奨環境をWinipedia側から提示する手もあろうかと思います。あまりにもマイナーな閲覧環境を想定した対応を行うのは現実的ではないのではないでしょうか。

過去の合意形成がなされた時点と現在のネット閲覧環境では違いが大きくなっていることもありますので、再考する余地はあるのではないかと思います。もっとも、全角チルダであろうと波ダッシュであろうとハイフンで代用できるところはこれまで通り極力そうしていくことで問題ないです。ただ固有名詞等でどうしてもそうは行かないという箇所を現行通りとするのか改訂するのかを検討する必要はありそうですね。--Don-hide（会話） 2016年1月27日 (水) 14:38 (UTC)

Help:MediaWikiに適応するブラウザに関する議論はこれまでにも何度かあったと思いますが、機器組み込みブラウザまで考えるとなると明確な結論は難しそうに思います。あえて言うならTLS1.0未満など機能やセキュリティの至らない環境では閲覧自体できなくなっているため、少なくともある程度古い環境は既に排除されています（なお上記ブラビアの場合はたまにTV側からのアップデートはある様子で、内蔵OperaによるYoutube閲覧はサポート終了処理が行われたりしていますが、Wikipediaは閲覧可能です）。ただ、いずれにせよそれはまた別の議論になるかと思います。

しかしおおむね妥当なご指摘だと思います。無視できない問題とは言いましたが大多数の環境には影響しない問題でもあり、多くの方に余計な負担を強いるような形となってしまっては望ましくありません。一種のバリアフリーのようなものですので、大多数の方々に負担にならない範囲で一部の環境に配慮するような枠組みでなくてはなりません。波線の用法の中にはいくらでも代替手段の存在する用法が少なくないため、そのような用法においてわざわざ波線が使われるようなケースを避けることができれば良いですので、どちらにせよなるべく（表現の自由を阻害しない程度に）使わない方向性は維持したいと考えます。そのうえで、やむを得ない場合に波ダッシュを使うべきか全角チルダを使うべきかを再検証できればと思います。

ここで問題となるのは、どちらであっても問題は残るため、現状で採用されている波ダッシュの問題点はいろいろ出てくるのですが、逆に波ダッシュ採用による実績（避けられた問題）がどの程度あったのかがよく分からなくなっている点です。長年Windowsにおいて全角チルダが標準的に用されてきた結果なのか、組み込み機器の独自OSですら近年は全角チルダが優先されているように思われる上記の現状において、未だに「全角チルダが表示できない環境」がどの程度あるかという点と合わせ、識者のご見解が欲しいのです。そのうえで、それぞれのメリットとデメリットを天秤にかけることになると思います。

ところで過去ログで波ダッシュの利点として挙げられていた「翻訳の際に外国語版でチルダが不正に使われることを避ける」という点については、個人的に少々疑問があります。外国語版まで考えるのであれば、そもそも日本語版の取り決めだけでどうにかなる問題では無いですよね。私は中国語は分からないので違っていたらすみませんが、恐らく中国語では基本的にチルダ（U+FF5E）が用いられることになっているのではないでしょうか。zh-wikiでも波線は推奨されていない様子ですが、やむを得ない場合は当然そちらが使われるわけですよね（zh:维基百科:格式手册/标点符号#连接号）。もし仮にja-wikiだけが世間の風潮に反してU+301Cを使っているのであれば、かえって混乱を助長しているようにも思えるのですが、そのへんはどうなのでしょう？

ちなみに上記リンク（中文wikiの表記ガイド）をGoogle翻訳にかけると中国語のU+FF5Eは日本語のU+301Cに対応している様子でした（そのため記号の説明としては間違ったものになってしまう様子ですが）ので、Google翻訳ではU+301Cが採用されているのかもしれません。このような対応関係がはっきりしていればまだ良いのですが、現実はそうもいかないわけで、中国語版の記事で日本の作品のタイトルリスト類を見ても大多数がU+FF5Eなのに一部U+301Cが混入するような混乱もしばしば見られるようでした（例）。

なんにせよ、このままでは波ダッシュU+301Cの使用についてほぼ「百害あって一利なし」ということになってしまいますので、波ダッシュの利点についてのご意見を待ちたいと思います。--Gwano（会話） 2016年2月2日 (火) 14:50 (UTC)

コメント 現状では「波ダッシュを優先」しているわけではなく、むしろ波ダッシュをできるだけ避けている、というほうが正確だと思います。

Unicodeにおいて、波ダッシュと全角チルダは異なる文字である（「表示・入力上の問題で全角チルダを避けている」あるいは「全角チルダのかわりに波ダッシュを使用している」わけではない）。
Unicodeの半角・全角形 (Halfwidth and Fullwidth Forms) は基本的に「その文字コード自身」以外の意味はない（ウィキペディア日本語版では和文中の欧文約物に全角形を使用している場合が多いが、#丸括弧・波括弧・角括弧では「目下の合意はない」としており、この点は本来MediaWikiやレンダリングエンジンなどの役目だとも考えられる）。
仮に引用元の電子テキストがUnicodeを使用しており、かつ全角チルダで表記していても、意味に応じてチルダ、U+223C、U+223D、波ダッシュなどに修正しなければならない（日本語の場合はおおむね波ダッシュ）。
波ダッシュには表示・入力上の問題があるので、範囲を示す記号としては使用しない（範囲を示すのに「半角スペース + ハイフンマイナス + 半角スペース」を用いるのは日本語において一般的ではないうえ、負号と紛らわしく、むしろ波ダッシュを使ったほうがよい、という議論は私自身の賛否はさておき、一理あると思われる）。

類似するケースとして、ダブルハイフンの代用として全角等号を使用していますが、波ダッシュは避けつつも使用し、ダブルハイフンを使用していないのは問題になる環境のユーザー比率の違い、ということになると思います。

なお、Gwanoさんが例として挙げていらっしゃるローマ数字はUnicodeでは等価となっていますので（記事「Unicodeの互換文字」ではこれが批判されていますが）、そもそも「代用」ではない、ということになります。

どちらかというと、ダブルハイフンの扱いはそろそろ再考が必要かもしれません（今さら変更が可能かどうかはさておき）。 --KAWASAKI Hiroyuki（会話） 2016年2月4日 (木) 17:50 (UTC)

解説ありがとうございます。現状の表記ガイドでは波ダッシュとチルダが別の文字として扱われ、代用の概念が無いことは上の節でも後から気付いたところです。もともと代用されていた文字では無いのでしたら、もし提案するのであれば新たに代用を提案する形にしなければならないわけですね。ローマ数字については代用の例としてはあまり適当ではないということで了解しました。現状ではむしろダブルハイフンに代用がある状態なのですね。確かに、ダブルハイフンと比べたら波ダッシュの表示可能な環境は圧倒的に多いと思います。逆字体の問題を別とすれば、かつては95のIEですら波ダッシュが表示できていたような記憶があります（上記の通り現在はセキュリティ上アクセス不可のはず）。また、表記上の傾向としましては記号類は機種依存文字であっても次第に解禁される傾向にあるようで、できるだけ使わないでくださいとしながらも、Unicodeの基本多言語面内であれば一応は使って良いことになっていたと思います。前述のように一部の環境のために多くの環境で不便を強いては意味がありませんので、使える機能は使うべきでしょう。そのような発想からすれば、むしろダブルハイフンも使えるようになるのではないかと感じられるのかもしれません。

しかし、字体が同じで代用できる文字の問題に関しては、その傾向は適用されないのではないかと私は考えます。これまでのウィキペディア対応環境の議論では、「全ての（マイナーな）環境に対応する必要はない」というのが共通した見解であることに疑いの余地はありません。ではメジャーでない環境についてはどうなるかと言えば、「基本的なテキスト閲覧のみ保証すればよい」という方向性だったと思います。ここで確認しておきたいのは、本件は基本的に後者に属する問題ではないのか？ということです。文字の代用ルールというのは本質的に、より使いやすい文字で代用されるものです。利用者に特別な入力手順を強いるものではなく、ましてやMediaWikiの技術部に一部の環境のための余分な開発の負担を強いるわけでもありません。他所でも多くの採用例がある代用ルールであれば、恐らく実害は無いと思われるのです。代用を無くすことにどれだけの意味があるのかは存じませんが、少なくともWikipediaは百科事典なのであって、文字コードを教育・啓蒙する場とは違うように思います。文意の伝達が保証できてこそなんぼの世界です。

そういう意味で、個人的にはとりあえずダブルハイフンの代用については当面続きそうに思うのです。一方で、仮に波ダッシュの全角チルダによる代用を（新たに）議論する場合、どちらを選んでも文字化けの可能性があるため一筋縄ではいきません。しかし前述の通り、波線が読めないくらいで意味が取れなくなるケースは少ないというのが、不幸中の幸いであるように思います。そうであれば、基本的なテキスト閲覧をできるだけ提供するという理念から言って、より多くの環境で安定して表示可能であると思われる全角チルダによる波ダッシュの代用を（新たに）認めるほうが筋ではないかと思えるのです。というのも、将来的にセキュリティの問題からMediaWikiのサポートがInternet Explolerと同様に最新のアップデートしかサポートしないような方向に進んでいく傾向を想定するならば、「基本的なテキスト閲覧のみを提供する対象」としては、ほかならぬ上記の表に示したような機器組み込みブラウザのたぐいが最後まで残ると予想されるからです。--Gwano（会話） 2016年2月7日 (日) 14:45 (UTC)

返信正しい文字コードを使うのは「教育・啓蒙」のためではなくて、正しい電子テキストを作るためです。入力が多少面倒でもギリシア文字の“Α”をラテン文字の“A”で代用しない、というのと同じです。

もちろん、Gwanoさんが指摘していらっしゃるような表示環境・入力環境についても配慮が必要だと思います。要はバランスの問題だと思いますが、波ダッシュに関しては（Unicodeに収録されている文字を「機種依存文字」に含めるのは違和感がありますが、それはそれとして）、

やむを得ない場合にしか使用を認めていない。
使用可能な範囲が日本の作品名等の固有名詞と引用文にほぼ限定されている。
ここ10年間で波ダッシュの表示・入力に支障がある環境の比率はかなり下がっているはずで、今後も下がっていくと思われる。

ことを考えると、現時点においてあえて波ダッシュを避けて全角チルダで代用する、というのは適切だとは思えません。

なお、Wikipedia:表記ガイド#使用可能な文字における記述が「JIS X 0201のラテン文字類にもJIS X 0208にも規定されていない文字は、できるだけ使わないようにしてください」であって「使ってはいけません」ではないことを考えると、JIS第2水準までにしか対応していない環境にもできるだけ配慮することを求めつつも、問題なく表示できるようにすることを求めているわけではないと理解しています。この点がガイドラインとして合意形成された経緯は把握していませんが、たとえば英語版のHelp:Special charactersを読むと「できるだけASCIIの範囲で」というような配慮はないようです。他言語版からの翻訳や他言語版を参考とした加筆が行われることを考えると、JIS第2水準環境での表示を求めることは難しい部分があり、かつその必要も薄れつつある、と思います。

あと、MediaWikiやウィキメディアはセキュリティ上・実用上支障がない範囲である程度普及している（かつ、できればオープンな）標準を採用しているはずです。「最新のアップデートしかサポートしない」というような発想はないのではないでしょうか。 --KAWASAKI Hiroyuki（会話） 2016年2月9日 (火) 16:12 (UTC)

追記なお、（文字コードの問題はさんざん繰り返されているはずなので車輪の再発明的な部分もあるかとは思いますが）具体的に問題になるのは以下の場合だと思います。

スクリーンリーダーや点字ディスプレイなど、バリアフリー環境がJIS第2水準外に対応していない場合
- ダブルハイフンの全角等号での代用、ハイフンマイナスとハイフンと負号とダッシュの混用はテキストの正しい解読を難しくする部分もある
日本語入力システムやテキストエディターなど、入力時に使用するソフトウェアがJIS第2水準外に対応していない場合
閲覧者が記事等を再利用するソフトウェアがJIS第2水準外に対応していない場合
記事等の表示・印刷時に使用するフォントにJIS第2水準外が収録されていない場合

うち、現時点で配慮が必要なのは1だけだと思いますが、現在の対応状況などは把握していません。 --KAWASAKI Hiroyuki（会話） 2016年2月10日 (水) 04:01 (UTC)

お返事を考えているうちにより優先度の高そうな議論が発生し、こちらが長いこと放ったらかしになっており申し訳ありません。お返事が遅れていた理由は、おっしゃるような「正しい電子テキスト」の概念について詳しく考察する必要があると思ったからです。Wikipediaの方針的にはどのような経緯から「正しい電子テキスト」という理念ができているのか、それによってデファクトスタンダードとも言えるようなメジャーな代替すら禁止されるべきなのか否かの解釈も変わってくると思いますので。もし留意すべき関連文書の指南がありましたら紹介していただけますと幸いです。

テキストリーダに関しては全角チルダ代替を否定する有意な理由になるかもと思ったのですが、よくよく考えてみると本件の議論にはあまり影響しないようにも思えてきました。私もWindows 95時代にNECプレインストール版のテキストリーダを少々いじったことがあるくらいですが、確か「＃」を「井桁」と読み上げるようなものだったと記憶しています。恐らく当時のバリアフリー環境では「どのような字形か」を認識できることのほうが重要だったものと考えられるのです。もちろん20年も前の話ですので最近のテキストリーダがどういう挙動なのかは存じませんが、仮に文脈から記号の意味を判別できるほどAIが発達したのであれば、波ダッシュと全角チルダのようなメジャーな代替が判別できないとは考えにくいと思うのです。もし仮にテキストリーダの判別ルーチンがIMEの辞書に依存するようなものであれば、当然、波ダッシュ用途での全角チルダも登録されていると思いますし。まあ実際使ってみないと分かりませんが。--Gwano（会話） 2016年4月7日 (木) 11:58 (UTC)

返信こちらこそお返事が遅くなってしまい、申しわけありません。

上で挙げた「正しい電子テキスト」というのは Wikipedia や ~~MediaWiki~~ウィキメディアに限定した理念ではなく、より一般的な考え方のつもりです。もちろん個々の閲覧・編集環境に配慮することと矛盾する場合もありうるので、無条件で遵守するのではなく、折り合いをつけることも必要だと思っています。
全角と半角#文字コード規格における全角と半角やUnicodeの互換文字を読んでいただくと、全角形のラテン文字類は（別段の事情がないかぎり）あまり使用しないほうがよい、という考え方がありうることは理解していただけると思います。上と同様、これも絶対化するつもりはありません。
全角ダッシュを「デファクトスタンダード」としていらっしゃいますが、たとえばOS X、iOS、Androidでは（すくなくとも標準的な入力環境では）波ダッシュのほうが優先して入力されるのではないでしょうか。
誤解させてしまったのではないかとも思いますが、「追記」で挙げたのは全角チルダを使用することを肯定しうる理由のつもりです（JIS第2水準外に対応していない環境では全角チルダだけが区点コード1-33に変換され、波ダッシュはマッピングされない場合が多いようなので）。

以上、かならずしも議論を意図したものではありませんが、分かりにくい部分も多かったかと思いますので、補足させていただきました。 --KAWASAKI Hiroyuki（会話） 2016年5月26日 (木) 20:55 (UTC)、一部修正：2016年5月27日 (金) 06:07 (UTC)

コメント 「OS X、iOS、Android」を例示しておられますが、いわゆるMacあるいはタブレット・スマートフォンでの閲覧環境がWindows搭載PCでの閲覧環境に勝るということでしょうか？日本語版Wikipedia特有の問題を議論しているので日本語版Wikipediaに絞って考えますと、日本語版Wikipediaにおける閲覧時のOSのパーセンテージはどうか分かりませんが、PC（主にWindows・Mac・Linux）向けのページを用意しているサイト（スマートフォン等用のサイトも別途用意しているところを含みます。）であれば、多くのサイトではWindowsからの閲覧割合が非常に高いのではないでしょうか。--Don-hide（会話） 2016年5月27日 (金) 01:04 (UTC)

返信私がコメントしようとしたのは波ダッシュとして全角チルダを使用するのが「メジャーな代替」かどうかです。閲覧については、XP以前の（記事「MS 明朝」によれば98以降であれば）Windowsフォントでも字形の問題があるものの表示できるはずです。波ダッシュ#Wikipediaにおける注意点で挙げられているようなUnicode未対応のアプリケーションソフトは現在でもある程度は使用されていると思いますが、それほど一般的なケースではないと思います。なお、ウィキペディア日本語版に限定したブラウザシェアは確認していませんが、en:Usage share of web browsers#Wikimedia (April 2009 to present)によれば2015年3月の時点でのモバイルブラウザの比率は約38%で、しかも増加傾向にあるようです。ウェブブラウザの利用シェアでも似た傾向が確認できます。

ここで焦点が当てられているのは閲覧ではなく、編集です。モバイルブラウザからの編集の比率はかなり低いと推測します。マイナビニュースに掲載されている2016年4月のデスクトップOSシェア（ウェブアクセスベース?）によると、Windowsユーザーの比率が約90%とのことで、ご指摘のとおり「非常に高い」ようです。Windows上では個々のインプットメソッド、およびユーザーの問題ということになり、全角チルダがそれなりの比率で使用されているのは事実だと思いますが、とはいえ「デファクトスタンダードとも言えるようなメジャーな代替」とするのには違和感があります。

たとえば、引用符として「“」よりも「”」のほうが入力しやすい環境はそれなりに存在し、区別していないユーザーも多く、「“例文”」とせずに「”例文”」としているようなケースは各種の印刷物やウェブサイトなど、さまざまな場面で確認できます。だからといって、「左引用符としても『”』を使用するのはメジャーな代替だから制限する必要はない」というのには私は賛成できません（なお、両方「"」を使うことには賛否ともにあると思いますが、ここでは言及しません。あと、en:Quotation markによると、言語によっては左右で同じ引用符を使うようです）。「正しい電子テキスト」というのは、たとえば「“」と「”」は区別して使用すべきだという考え方で、広く共有されており、あらためて議論するまでもないと思っていました。ただ波ダッシュはUnicode未対応の閲覧環境で正しく表示できないケースがあるので、一定の配慮が必要だというのが論点だと理解しています。 --KAWASAKI Hiroyuki（会話） 2016年5月27日 (金) 06:07 (UTC)、一部加筆・修正：2016年5月27日 (金) 06:09 (UTC)、2016年5月27日 (金) 06:13 (UTC)、2016年5月27日 (金) 06:16 (UTC)

数字の書き方の、例の数について

桁の多い数字の書き方は、３つに分類して示されています。そして３つの書き方の例として、それぞれ３例が示されています。「３．整数部分、小数部分ともに、3桁ごとにスペースを入れます（例：科学技術分野など）。」の場合も、３例を示しました。２例で良いとの意見がありましたが、リバートしました。

理由１：１．２．の両方とも次のように、３例が示されています。

　例： 38万4400キロメートル・80兆0123億0022万0003円・π = 3.141 592 653 589 793 238 46

　例： 384,400キロメートル・80,012,300,220,003円・π = 3.141 592 653 589 793 238 46

理由２：３．の例のうち、光速度は整数の場合、プランク定数は小数の場合、リュードベリ定数は、整数・小数を兼ねている場合の例であり、この3例を示すことが適切と判断しました。 --Awaniko（会話） 2016年2月26日 (金) 14:53 (UTC)

コメント 編集の要約欄では意図を伝えきれず混乱を生み、失礼いたしました。こちらで改めて説明させていただきます。

今回私が疑問に思ったのは、リュードベリ定数の例が{{Val}}を使った記述である点です。記事中でこのテンプレートを使うのであればともかくですが、少なくとも本稿においては以下の理由から表記ガイドの他の部分の記述との整合が良くない部分があるため、ここでの例に用いるには向かないと思ったのです。これは同時に使われている{{sup-}}についても同様ですが。

これらのテンプレートは文字参照−の手間を省き、簡単にマイナス記号(U+2212)を記述できる機能を持つテンプレートです。しかしマイナス記号(U+2212)の使用はあくまでプロジェクト:数学/スタイルマニュアル (数式)で定められたローカルルールであるように思います。Wikipedia:表記ガイド上ではマイナス記号(U+2212)についての明確な言及は無く、Wikipedia:表記ガイド#使用可能な文字の「具体例」としては半角プラス「+」と共に半角の「-」が示されており、これは通常の半角ハイフンマイナス(U+002D)ですので、総論である表記ガイドの段階としてはこちらを例示に使うのが筋でしょう。実際に1番目の光速度の例では指数部に半角ハイフンマイナス(U+002D)が使われているため、3番目のリュードベリ定数の例として何の説明も無くU+2212が唐突に出現するのは、表記ガイドでの記述例としては整合がよろしくないと思うのです。これは本来の表記ガイドで言及のないマイナス記号(U+2212)の記述を新たに導入する形になるため、記述の再考の可能性が生じます。そのため事前に提案無く追加できる例とは思えなかったのです。

また{{Val}}は数か月前に英語版から導入されたばかりのようで、Template‐ノート:Valで導入された経緯を察する限りは恐らく翻訳時の利便性から生れたものと思います。日本語版での常用について充分な合意もしくは実績を経たテンプレートと見なせるかどうかは疑問が残ります。そのようなテンプレートの使用を表記ガイドにおいて議論なしに「好例」と推奨するように見える点でも、違和感があったのです。

とりあえず私としては{{Val}}や{{sup-}}を使わないで無難に半角ハイフンマイナス(U+002D)を用いた指数表記（もしくはプランク定数の例のようなtex表記）に変更していただければ依存はありませんが、いかがでしょうか。--Gwano（会話） 2016年2月27日 (土) 11:05 (UTC)

１）リュードベリ定数の数値の書式は、物理定数の中で使われていたものをそのままコピーしたものです。私自身は{{Val}}の記法（テンプレートともいうのですね？）のことは全くといっていいぐらい存じません。ただ、この記法を使うと、整数部・小数部とも3桁ごとに自動的に空白が入るようでして、科学技術分野での数値の書き方として便利なものであるということを知っているのみです。それから、この記法は物理定数の編集履歴を見ると、遅くとも2014.12.7から使われているようです。

２）私は詳しくないのですが、そもそも「表記ガイド」は、本文に表れる表現振りのみを規定しているのではないでしょうか。つまり編集に用いられる記法（tex表記のようなもの）までをも規定してはいないのではないでしょうか。例えば、この表記ガイドの「== 数式 ==」における記述を見ても、その記法を統一しようとの意図は感じません。数式や数学上の記法にはさまざまなものが存在していて、そのどれを用いても許されているのだと理解していました。　

３）上記の私の解釈が間違っており、数式の表記も統一するのが表記ガイドのメタ規則であるということならば、この部分（リュードベリ定数のところ）の記法を統一していただいても結構です。 --Awaniko（会話） 2016年2月27日 (土) 12:07 (UTC)

（追記）「⁻についても同様」・・・以降の１パラグラフの記述は、済みませんが私はよく知らないことばかりで、理解できませんでした。　--Awaniko（会話） 2016年2月27日 (土) 12:17 (UTC)

分かりにくい文章だったようで、申し訳ありません。分かりやすくなったかどうか自信はありませんが、また長文失礼します。

順番が前後しますが、結論から言いますと、３）について表現の統一を求めているわけではありません。その他の理解については全面的には否定しませんが、その前提となる根本的な部分で誤解があるようですので、それらについて述べます。

２）について、もちろん方針で禁止されていない限りは、記事中では様々な表現が許されています。ただ、現場で使われている表現だからと言って、それらすべてが推奨できる表現だとは限りません。

「表記ガイド」はWikipediaのガイドラインという位置付けであり、通常の記事とは扱いが大きく異なります。多くの利用者に手本を指南することになる文書ですから、それなりの合意を根拠とした、優先的に記述できる内容が求められます。表記ガイドの冒頭では大きな変更には提案が必要とありますが、だからといって小さな編集が自由とは限りません。例の追加程度であっても、議論の余地があるものは議論が必要です。ましてや本件には明確な異論が出ているのですから、結論が出るまでは独断で本文に反映しないでください。

表現の統一が目的というわけではないにせよ、同じ表記ガイド内に「-」（←これは「半角ハイフンマイナス」と言い、ハイフンとマイナスのどちらにも使われます。）と「−」（←これは単なるマイナス記号で、ハイフンとしては使えない文字です。）の2種類の表記揺れがあれば、当然、読者は疑問を覚えるでしょう。そうなるとそれについて表記ガイドに新たな補足説明を招くことに繋がります。そうなれば「大きな編集」に該当しますので、議論なしに追加する例としては不適当ではないかと言っているのです。なおプランク定数のtexによる表記例については画像で表示されますから、両者の区別が問題になることは無いと考えましたので、ここではtex表記は問題視しませんでした。

１）について、おっしゃるように{{val}}自体は以前から使われていますので、少々語弊がありました。補足しますと、現行の{{val}}の本体はモジュール:valであり、数か月前に置き換わったもので、以前のものとは内部的に別物なのです。ちなみに今日現在で{{val}}が使用されている記事（標準名前空間でのリンク元）は163件しかヒットせず、日本語版で優先されるべき記述法なのかどうか状況的には疑問です。もちろん、優先して使用されるべきという合意が確認できればよいのであって、マイナーであること自体は大きな理由ではありません。

個人的には{{val}}そのものではなく、その中で使われているマイナス記号そのものに少々疑問が残るのです。マイナス記号「−」の使用自体は上記の通りプロジェクト:数学側で規定されたローカルルールですので、そちらの取り決めに変更があった場合にこちらの記述が振り回される可能性がある点で、例としてはあまり気が進まないのです。

ついでに言えば、その規定では本来使用できるはずの「-」（半角ハイフンマイナス）を単に「ハイフン」と呼んで使用しないように記述されていたりと、その言い回しに少々疑問が残ります。これについてどのような合意があったのかプロジェクトのノートの過去ログを探したところ、私には該当議論が見付けられませんでした。つまり今回の追加例には、記述法の一部に、現時点で根拠が確認できない部分があるため、それについて確認が取れるまでは「表記ガイド」という「ガイドライン文書」での使用は保留していただきたいという理由もあるのです。--Gwano（会話） 2016年2月28日 (日) 14:41 (UTC)

情報プロジェクト:数学での議論の経緯は確認していませんが、英語版だと、Wikipedia:Manual of Style#Other dashesに「負符号や減算記号にはU+2212を使え」との記載があります。もちろん、一律に英語版に従うべきだとは思いませんが、「ローカルルール」とするのはやや矮小化しすぎかもしれません。「他言語版ではU+2212を使っている場合があるので、翻訳する場合等は確認のうえハイフンマイナスに修正してください」というような注意書きも必要かもしれません。

やや脱線しますが、ウェブサイトでハイフンであるはずのところになぜかU+2212を使っている例が気になっています（私が見つけたのは日本郵政の店舗地図の住所）。このあたりの混乱を避けるのはかなり難しくなっているのかもしれません。 --KAWASAKI Hiroyuki（会話） 2016年2月28日 (日) 16:34 (UTC)

確かに日本語版で議論が無いとなると、最初に英語版から導入されてそのままの可能性はありそうですね。日本語版内では状況的にプロジェクト側のルールという位置付けに取れるのですが、ローカルルールは少々大袈裟な表現ではあったかもしれません。しかしいずれにせよ日本語ローカライズについて再確認する必要はありそうに思います。

Unicode対応が不完全な環境では、その環境で元々使われている文字セットによってUnicodeへのマッピングが異なる関係だかで、マイナスやダッシュ等の横棒類は一般に文字化けしやすかったように思います。そのへんが英語版で当時問題にならなかったのか、少々不思議です。もしかして日本語に固有の問題なんでしょうか？

個人的に懸念しているのは、前節の機器内蔵版Operaのように、表示できない文字がスペースに化けるケースです。これは波線のような表示されなくても意味は取れるケースとはわけが違います。正負を示す個所ではマイナス記号が表示されないことにより正の数として表示されるわけですから、数値として完全に間違ったものになってしまいます。マイナー環境だとしても間違った情報の発信に繋がる見過ごせない不具合であり、波線よりも優先度が高い問題と言えます。

とりあえず本節の議論については、「整数・小数を兼ねている場合の例」について、半角ハイフンマイナスを用いた適当な例を探して置き換えることで一旦閉じるのが良いのではないかと思います。--Gwano（会話） 2016年2月29日 (月) 14:58 (UTC)

Gwanoさんへ：

１）議論が混乱していると感じています。

２）ノートのこの節の議論は、タイトルにあるとおり、「数字の書き方の、例の数」です。つまり、「桁数が多い数字列に3桁毎に空白をあける書き方」の例（現在は2例がある。）に、リュードベリ定数の例を追加することが適切かどうかについて議論をしようとしています。例を追加すること自体に反対されているのかどうか、そして反対されるのであればその理由をお知らせ下さい。

３）前に申し上げましたように、私の能力不足のために私自身がよく理解できないことをおっしゃってますが、その部分は、おそらく、上記の「例を追加するべきかどうか」には関係がないと思います。このことに加えて、マイナス記号うんぬんのことは私の全くの関心外でもありますので、これも前に申し上げましたが、Gwanoさんが良いと思われるように修正なりをお願いします。

４）valを用いることがいいかどうかの議論は、この節のタイトルとはかけ離れていますので、ノートのこの節には記述されないようにお願いいたします。別に節を設けてご議論ください。KAWASAKI Hiroyukiさんにも、このことをお願いします。

５）別の節で御議論なさって、もしvalによる表記が良くないということで決着したならば、その時にvalを用いない表記に修正をされればよいのでしょう。

６）なお、長文の記述をされる場合は、お互いの文章の引用が可能なように、番号を付していただけると助かります。 --Awaniko（会話） 2016年3月1日 (火) 13:50 (UTC)

私としてもマイナス記号の疑問は数学プロジェクトの側で確認すべき問題と考えているため、この場で深入りするのは本意ではありません。暫定的に、表記ガイドではハイフンマイナスを使った表記に編集しなおしておくということで良いのでしたら、ひとまずその話は置いておきたいと思います。

本題について、2例で充分か否かが論点なのでしたら、私としては前述の通り今のところ依存は無く、どちらでも構いません。もちろんリュードベリ定数以外にも条件を満たしそうな候補が見付かれば、それでも良いかと思います。--Gwano（会話） 2016年3月2日 (水) 13:07 (UTC)

＞リュードベリ定数以外にも条件を満たしそうな候補が見付かれば、それでも良いかと思います。

リュードベリ定数の記法を変更すれば済むことですよね？　したがって、本文中のリュードベリ定数の記法（notation）をvalを用いないものに変更しました。 --Awaniko（会話） 2016年3月6日 (日) 07:37 (UTC)

お手数かけてすみません。念のためこちらの議論の収束を待っていたのですが、このまま問題の切り分けに異論が無いようでしたら、マイナス記号については後でプロジェクト側のノートで質問しようと思っております。--Gwano（会話） 2016年3月6日 (日) 11:41 (UTC)

マイナス記号のガイドライン

1

前節のマイナス記号の扱いについてプロジェクト‐ノート:数学で確認しましたところ、明確な合意では無さそうとのことでした。しかし現状としては明示的に（ハイフンと）マイナスを区別するために使われる有意な記号であり、表記ガイドで具体的な記載が欲しいという旨の要望が寄せられました。

提案の背景として、まずこれまでの経緯を大雑把にまとめてみます。前述の通り英語版ではマイナス目的でマイナス記号「−」 (−, U+2212) が使われますが、日本語版では明示されておらず、半角記号の例として半角ハイフンマイナス「-」（U+002D）が存在する程度です（数式の例にもこれが使われています）。恐らくですが、Unicode対応が不十分な日本語環境でのマイナス記号は文字化けの可能性があったためではないかと思われます。マイナス記号の議論は井戸端の過去ログでも特に見当たりませんが、過去の議論としてはノート:1−2+3−4+…があり、2010年当時はまだマイナス記号の使用に異論があったようです（一旦は青子守歌氏により削除されたらしいですので、何らかの事情をご存知なのかもしれません）。しかし当時すでに文字化けする環境が少なくなっていたことや、マイナス記号が全角記号には当たらない（禁止はされていない）という認識から、特に合意と呼べるほどの議論なく自然に黙認されていったものと思われます。すでに{{val}}のようなテンプレートを用いた表記では強制的にマイナス記号が使われています。しかし禁止はされていない（基本的にはUnicodeであれば使える）というだけで、マイナス記号を標準的に使うというガイドライン上の根拠は、まだ無いものと思われます。

なおマイナス記号は環境依存文字の中では比較的文字化けしにくい部類かもしれませんが、私の知る限り機器内蔵版Operaの類では複数のバージョンでマイナスが空白に化けるケースを確認しています（ニンテンドーDSブラウザーおよび3DブラビアKDL-46HX820 ←2011年モデルです）。さすがに大型TVは何十万円もするだけに、最新の対応状況については家電量販店の店頭デモ機で検証するしかないとは思いますが、少なくとも2011年モデルの製品寿命（生産終了後7年間）を考えれば、まだUnicode普及の過渡期にある点に配慮する必要はありそうなのです。

具体的な表記ガイドの改定案として、利用者:ARAKI Satoruさんから以下のような候補文が提案されております。

*（候補1）負数や減算の表記にはハイフンマイナス - ではなくマイナス − (−) の使用が推奨されています。ただし、ハイフンマイナスをマイナスに変更するだけの編集は避けてください。

追加場所としてはWikipedia:表記ガイド#数字あたりでしょうか。Unicode普及の過渡期を踏まえ、落とし所としてはうまいところを突いているようにも思いますので、これについてご意見を伺っていきたいと思います。私としては、

リスクがゼロではないものを「推奨」とするほどの明確な利点なのか。
万一にも文字化けする環境への対策、もしくは言い訳。

あたりについて、それなりに議論を進める必要があると思います。

コメント 私自身は数学分野で特に貢献しているわけではないので利点について実感は無いのですが、それだけに貢献している方々の足を引っ張るのはあまり本意ではありません。文字化け対策としては、独立した式はtex表記を優先するとか、文中でどうしても誤認を避けたい部分はマイナスハイフンを残すなど運用面での工夫が考えられると思います。ただ、どのような部分の表記を優先的に配慮すべきなのか、具体的な使い分けを考えると少々無理があるように思いますので、現時点で賛否は控えます。

一般的な文字化け問題であれば単にその環境では読めないというだけなのですが、本件の場合はごく一部とは言え空白に化けて数値の正負が誤認されるという厄介な現象を確認しており、下手すれば第三者に誤情報が伝わる（ともすれば自分に帰ってくる）可能性を考えると、どうにも慎重に構えたいところです。--Gwano（会話） 2016年3月17日 (木) 14:54 (UTC)

コメント jawpの同様の問題として、波ダッシュと全角チルダの例がありますが―― 一部環境での文字化け（1〜10 が 1・10 になったり、あるいは疑問文になるような問題）は完全無視で、本来の・公式の（デジタルデータ上の）表記で全角チルダであってさえ勝手に波ダッシュ置換という乱暴が横行する現状を作った方々からすれば――きっとハイフンマイナスなどは排除対象なのでしょう。とはいえ、波ダッシュより桁違いに使用頻度の多く、数学分野に限らない（むしろ数学以外のほうが記事数では多い）マイナス（の意味での）記号の問題を、メリットはほとんどなく、少ないとはいえデメリットは存在するものを「推奨」はできません。「1〜10 が 1・10 になる」どころではなく負の数値が正の数になってしまうのですから大問題です。ハイフンマイナスにはマイナス記号としての役割が含まれていて、人間の視覚上でもあらゆる数式処理環境でもマイナスとして認識されるわけで、問題点はほとんどありません。強いて挙げるとすれば、ハイフンマイナスでもほとんどのスクリーンリーダーが（ハイフンではなく）「マイナス」と読むようですが、その確率が上がることでしょうか（10年前のソフトの話なので考慮に値しないかもしれませんが）。--Hisagi（会話） 2016年3月18日 (金) 16:38 (UTC)

コメント

私は数学の分野の記事にはあまり触っておりませんが、物理の分野の記事にはよく触らせて戴いております。やはり物理の分野の記事にも数学の数式は頻出しますので、数学記号は本文中でも多用しております。ですので、私もよく使わせて戴いているのですが、正直に申し上げまして、何度編集を重ねていても、未だに「–」「—」「−」の差異が分かっておりません。恐らく「ハイフンマイナス」「ハイフン」「マイナス」なのでしょうけど（順不同）、私には区別が付きません（因みにこれは右の図1.より打ちました）。これより以下に私個人の意見を述べさせて戴きますが、私は数式の編集そのものは頻繁にしながらも記号の表記揺れについてはほとんど無知で無理解な人間なのだと言う前提において述べますので、皆様方もそのことを念頭に置きつつお読みになって戴けると幸いに存じます。

まず、この3種の似た文字種を編集時に打ち出す時に関して私の個人的な所見を述べるとすれば、私がWindows7で使用しているGoogle 日本語入力とBaidu IMEや|Microsoft Office IMEと言った3つのエンジン（残念ながらATOKは使用しておりません）に関しては、3種の半角文字を全て出すのは不可能なようです。またスマートフォンで入力する際も、これらに文字入力画面で明確な差異は見当たりません。となると、合理的に全ての文字種を恣意的な選択で出すのであれば、図1.のような編集ボックス下の特殊文字リンクから打つのが妥当な方法となると思います。しかしながら、現状この編集ボックス下の特殊文字リンクと言うのは、スマートフォンでは表示されない環境になっている上に、表示される環境にあるPCでも、各記号が何を指し示しているのかについての説明文のようなものがなく、使う側からすると多少は不便なようにも感じます。この特殊文字リンクがどの様な方法で作成され、どの様に編集画面に読み込まれているのかは存じ上げませんが、この特殊文字リンクを改良すれば、「ハイフンマイナス」「ハイフン」「マイナス」の使い分けを編集者がより簡単に出来るようになるのではないでしょうか。因みに、このパラグラフの問題は丸々「全角チルダ」と「波ダッシュ」との問題にも当てはまるかと存じます。

ただ、この場所はあくまで「表記に関するガイドライン」を策定する為の場所ですので、「編集に関わる行為」について議論する場所ではない事は重々承知しております。ですので、あくまでも「ページの編集」や「特殊文字」と言ったヘルプページや数式表記に関連する数学や物理学と言ったプロジェクトページなどで、それぞれのノートページにて議論を重ねて結果が出た後で、こちらでも再度合意形成を得てガイドの本文を改定すると言った流れの方が良いのではないのでしょうか。--知識熊（会話） 2016年3月18日 (金) 21:44 (UTC)

返信その3つの記号は，それぞれエヌダッシュ，エムダッシュ，マイナスであり，欧文（英文の文章作法）に馴染みのない方だとご存じでない場合もあるようですが，ハイフンとは全く異なる記号です．それぞれ，文字実体参照で –, —, − としても入力可能です．編集ボックスについては，ダッシュ類はともかく，マイナスは記号の並びから明らかではないでしょうか．ハイフンマイナスはキーボードだと右上から普通に入力できるやつです．なお，エヌダッシュは日本語版ウィキペディアにおいても特に出典等でしばしば用いる記号です．新規作成 (利用者名) （会話） 2016年3月19日 (土) 08:10 (UTC)

コメント 文字化けする環境というのがどのくらいあるものなのか，考慮するほどのものなのか分かりませんが，今後減っていくでしょうし，そもそも正式な文書作成の観点からはマイナスにハイフンマイナスを用いるのは誤りであり，視覚的にも異なりますし，やはりマイナスにはマイナスを用いるべきだと思います．マイナスが抜けたくらいなら文脈から補えるでしょうし．どうしてもマイナスを使いたくない場合は，TeX を用いることになるでしょう．（ただし，言うまでもないですが，プログラミング言語のソースコードを書く場合（例えばPython#構文）などのように，ハイフンマイナスが正しい場合もあります．）新規作成 (利用者名) （会話） 2016年3月19日 (土) 08:10 (UTC)

波ダッシュとチルダを禁止しているせいで、例えば「1から10までの範囲」を「1-10」や「1 - 10」という風にハイフンで代用するのが日本語版ウィキペディアの慣習となっており、「1-10」が「1から10までの範囲」なのか「1引く10」なのか、（多くの場合文脈から明らかではあるものの）一意ではないんですよね。個人的にはマイナスはマイナス記号−で書きます。--Yapparina（会話） 2016年3月20日 (日) 03:01 (UTC)
- 私としては範囲を示す場合に「から」「まで」を使うとか、箇条書きの見出しや語句の一部省略といった用法には三点リーダ（…）とかを臨機応変に使っても良さそうに思います。現状では波線の代用が一律にマイナスハイフンしか示されていないという問題もありそうですね。まあそれは別の議論になりますが・・・。--Gwano（会話） 2016年3月20日 (日) 12:22 (UTC)

問題確認 マイナスが文字化けするというのがどれほど起こるのかと「マイナス　文字化け」で検索してみると、ほとんどが全角マイナスの文字化けに関するものでした。一応、確認しておきたいのですが文字化けは全角マイナスではなく本当のマイナスで起こっているのですよね？もし全角マイナスならば何の問題もなく一律にマイナスでもいいくらいに思えますが。 --ARAKI Satoru（会話） 2016年3月20日 (日) 03:36 (UTC)

（お返事）該当環境では実際にマイナス記号が表示されていませんので、U+2212が化けたのは間違いないと思います（TVの写真/DSの写真）。

全角マイナスについては私も昔Netscape4からメモ帳にコピペした際に化けた記憶があります。ただ、ここでは「全角マイナス」の表現に語弊があるのかもしれません。文字化けの原因はその環境本来の文字セットをUnicodeに変換する際のマッピングの問題でしょうから、どの変換段階の呼称を用いるかで変わってくるのかもしれません。例えば姉妹プロジェクトのウィキクォートの日本語環境の解説ページに「－」（Ux2212全角マイナス）という表現がありますが、これ（－）をコピペして日本語Wikipediaで検索するとハイフンマイナスに転送されましたから、もしかしたら「全角マイナスの文字化け」というのはUnicodeで言うところの全角ハイフンマイナス（－）の話かもしれません。プラス記号とマイナス記号の最後にある文章によればハイフンマイナスはISO/IEC 646においては（ハイフンも兼ねるが）正式なマイナス記号らしいですので、全角マイナスと呼ばれても不思議は無さそうです（もちろんこの場合に半角マイナスは半角ハイフンマイナス「-」を指すことになります）。一方で、別の解説では（全角の?）ハイフンマイナスはJIS X 0208に割り当てられていない文字とのことですので、機種依存文字となる可能性がありそうです（この場合でも半角ハイフンマイナス「-」はASCIIの範疇なので多分化けないと思われます）。

もっとも私はそのへんの文字化けの問題はあまり詳しくありません。上記の機器内蔵Opera類におけるマイナス記号の文字化けもどのような文字コードの変換メカニズムから生じているのか見当つきませんので、その他の環境でもある程度起こりうるものなのか、よほど限られた問題なのかは分かりません。ただ、PanasonicのHDD TV（2010年モデル）の独自ブラウザでは波ダッシュは表示できなくてもマイナス記号は表示できていたように思います。--Gwano（会話） 2016年3月20日 (日) 12:22 (UTC)

そもそも論として問題提起します。日本語でもwiki上でも、例えば、「寿司」でも「鮨」でも「すし」でもOKであり、「薔薇」でも「バラ」でも問題ありません。日本語自体にそういう許容度がある（又は正書法が確立されていない。）のに、波ダッシュとチルダを区別したり、マイナス記号としてどの符号のものを使うかなどといった区別にどれほどの意味があるのでしょうか。

検索する場合にも、先に挙げた例では、「寿司」でも「鮨」でも「すし」でも同じように検索が可能なはずです。波ダッシュでもチルダでも検索が可能なはずですし、翻訳の問題もその翻訳ソフトの性能の問題でしょう。

それに加えて、wikiの執筆者にあまりにも細かい書法を強いるのは、ハードルが高くなりすぎて、執筆意欲を削ぐことになるのではないでしょうか。なるべく多くの人たちにwikiに参加してもらうことの方が大事ではないでしょうか。--Awaniko（会話） 2016年3月20日 (日) 08:17 (UTC)

コメント 多くのユーザーにとっては、キーボード右上の0の右のキーを押して出てくる「-」の記号を単純に使っているというだけの話で、それがそれが「マイナス」記号なのか「ハイフンマイナス」記号なのかをいちいち意識して書いたりなんてしてないんじゃないですかね。マイナス記号は多くの場合半角で使用することになるかと思いますが、「まいなす」と打ち込んで変換しても普通のIMEじゃ全角しか出てきませんし、半角のマイナス記号を一発で出力しようとするとやり方をちょっと考えてしまいますよね。文字コードで変換とか文字実体参照とか辞書登録とかしないと普通に出てこないとなると、正直なところそれらの記号の使い分けを一般ユーザーに求めるのは無茶な話に思えてしまいます。ちょっと調べると、ハイフンマイナスはハイフンおよびマイナスを包摂する記号として広く使われているということみたいですし、基本ラインはマイナスもハイフンも意識せずとも簡単に入力できるハイフンマイナスで代用するということで何の問題もないと思います。数学記事であったり、ハイフンとマイナスを読み違えると文意が変わってしまうような、分野やケースを限定してハイフンとマイナスを厳密に区別する必要がある場面に限った話であれば特に反対はありませんが。ですが、そうでない場面でまで厳密な区別を求める必要はないのではないかと思います。そういう意味ではむしろ、そういう細かいところを気にする人が「ハイフンマイナスをマイナスに変更するだけの編集」でも構わないのでやってくださればいいのではないでしょうか。--重陽（会話）

反対文字そのものの記事やプログラムコードのような、厳密なコードポイントで書くことが必要になる場面はさておき、そうでない場所でのウィキペディアの文章は、基本的に人間が読んだり書いたりするものです。そのような環境で、「この文字を使う」と決めたところで見込めるメリットは、「意味論的により正しい」という程度で、特に閲覧者側からすればほとんど見当たりません（マイナスやハイフンの表示は、フォントによっても違ってくるでしょうし）。一方で、「英数字は半角にする」というようなルールとは、以下のような重大な違いがあります。

一般的な環境では入力が困難であり、コピペするか実体参照で書くかなど、入力に負担となる。
（少ないとはいえ）文字化けのリスクがあり、なおかつ文字化けると意味が取れなくなる危険性がある。

ハイフンマイナスという名前のとおり、この文字にはマイナスの意味も含まれていますので、あえて非推奨として、マイナス記号の入力をことさらに推奨させる必要もないと、自分としては考えます。--Jkr 22 55 2016年3月20日 (日) 23:48 (UTC)

2

&minus: が文字化けする環境はかなり少数である（と思われる）ことから，Windows が関わるような波ダッシュ問題と同列に語るのは無理がありますし，ハイフンマイナスがマイナス記号として「正しい」のは &minus が使えないときですから，− が使えるのなら使うべきです．桁区切りのスペースを入れるとスクリーンリーダーの読み上げに問題があるにもかかわらずこれは認めて − を認めないというのは奇妙に思えます．編集者の負担というのは少々的を外していると思います．それに，現在の表記ガイドにももっと細かいルールはいっぱいありますし，実際の入力では編集画面下部の記号をクリックするだけでもいいですし − と入力するにしてもたった6文字ですし携帯・スマホなら予測変換もあります．新規作成 (利用者名) （会話） 2016年3月24日 (木) 06:50 (UTC)

念のため確認しますが，−(−) の推奨に反対されている方はもちろん ·(·) や ⋅(⋅) のような記号の推奨にも反対ということでいいのですよね？（どうして以前の表記ガイドにはあった − はハイフンマイナスに代わったのに · は使われているのか謎です．）新規作成 (利用者名) （会話） 2016年3月23日 (水) 07:04 (UTC)

（追記）「以前の」表記ガイドというのは例えばこのあたり（2012年7月10日 (火) 18:01 の版）のことを言っています．新規作成 (利用者名) （会話） 2016年3月24日 (木) 06:50 (UTC)

なるほど「数式の例としてもともとハイフンマイナスが使われていた」というのは誤認でしたか。履歴を見ると該当部分は2007年11月25日23:03(JST)で追記され、2013年12月22日17:08(JST)でAwaniko氏により例が置き換えられたもののようです。いずれもノートの議論は経ている様子ですが、どちらも該当議論の論点は別のところにあり、マイナス記号の扱いについて特に方向性は無かったことに変わりは無いと思われます。

ドット類に関しては別の議論になると思います。文字化けの観点からすれば個人的には望ましくないとは思いますが、それでも乗算のドットであれば省略されることもありますし、少なくとも正負を間違えるほどの問題よりは優先度が低そうに思います。

なお仮にマイナス記号の推奨を反対される場合、表記ガイドにはどのような形で記載されるべきか、対案があるとありがたいです。少なくとも現状では前述のように

英語版ではマイナス記号が推奨されている
{{Val}}などのテンプレート経由で記載すると強制的にマイナス記号が使われる

という問題がありますので、両者の並存に対して疑問をもった利用者に何らかの説明は用意しておく必要はあると思います。結論次第ではそれらのテンプレート類の扱いについても考えなくてはなりませんし。--Gwano（会話） 2016年3月24日 (木) 14:09 (UTC)

コメント 意味も用途も全く異なる記号を単に字形が似ているといったような理由だけで全く別の記号の代わりに使っているようなケースなのであれば、新規作成さんがおっしゃるような「ハイフンマイナスをマイナスとして使って正しいのはマイナス記号が使えないときだけである」というような理屈も成り立つかとは思います。ですが実際には、ハイフンマイナスという記号そのものにマイナスの意味が包摂されているのですから、マイナス記号が使える環境であれ使えない環境であれハイフンマイナスという記号の持つマイナスの意味が無くなったりはしませんよね。そういう意味ではマイナス記号が使える環境でハイフンマイナスをマイナスとして使っても記号の意味として間違いではないのではないでしょうか。文字コードの事情にあまり詳しくないため変なことを言っているのかもしれませんが、マイナスの意味を持つ記号をマイナスとして使うのが正しくないというのはちょっと訳が分かりません。それと編集者の負担は明確なデメリットなのですから考慮するのは当然だと思います。「推奨」の強制度合いが「入力が面倒」ぐらいの理由で免れる程度なのであれば別に構わないかなとも思いますが、日本語版ウィキペディアでは「推奨」の言葉が持つ強制度合いを非常に強いものと考える方も多いのでかなり慎重に考えてしまいます。--重陽（会話） 2016年3月24日 (木) 17:11 (UTC)

簡単に言えば，使える文字の少なかった昔は，ハイフンマイナスがマイナスを含むいろいろな意味で使われていて，その名残で今もハイフンマイナスは残っていますが（そして無くなることはないと思いますが），今ではマイナスのための記号が用意されているのですから，きちんとそれを使いましょうということです．

＞日本語版ウィキペディアでは「推奨」の言葉が持つ強制度合いを非常に強いものと考える方も多い

なるほどこれは存じておりませんでした．会話が噛み合っていないと感じる部分があった原因の1つはそれでしたか．私は推奨は普通の意味でしか使っても読み取ってもいませんし，強制する気はないので，そういうことであれば，マイナス記号についてあえて明言せずに以前の版のようにしておく，つまり記号についての説明はしないが例の中で使う，というのもありだと思います．新規作成 (利用者名) （会話） 2016年3月26日 (土) 06:41 (UTC)

ご返答ありがとうございます。普通の意味での推奨であって強制する気はないということで、懸念していた部分は解消されました。それを踏まえてどういう風に書くのがいいかと考えると中々難しいですし、あえて明言しないというところが無難だろうと思います。例の中で使うというのは、数字節の例の単位のs^-1やm^-1をs⁻¹やm⁻¹に変えるということでしょうか？そのぐらいであれば、推奨と言う名の強要にはなりにくいでしょうし構わないと思います。

あと、その他節の紛らわしい文字に気をつけるという部分で「ダッシュ・全角ハイフン・全角マイナス・長音記号・罫線」の例示がありますが、その横の記号の文字コードを見ると3つ目の全角マイナスに対応しているのが半角ハイフンマイナスになってしまっているみたいで、この辺りは整理したほうがいいかもしれませんね。文字化けを理由に反対されている方との合意が取れるのであれば、ここにマイナス（−）を入れておくのもひとつかもしれません。

以下は本件の合意形成部分とはちょっとずれますが、疑問点として。その「きちんと使いましょう」という考え方にはどの程度のレベルのコンセンサスがあるものなのですかね？国際的な標準化団体で勧告されているレベルなのか、世間一般の常識なのか、単なる個人的主張なのか。ハイフンマイナスの記号の歴史的経緯は分かりますが、それは別として今現在どのように扱うべきなのかという部分ですね。Awanikoさんがそれは表記揺れの許容度の範囲内ではないのかと疑問を呈されていますけど、色々調べてもハイフンマイナスはそこら中で使われていますし、やはり私も許容度の範囲内の話ではないかと感じます。例えばエクセルのような表計算ソフトでは計算結果として出力されるマイナス記号もハイフンマイナスだったりします。きちんと使いたいというこだわりは十分に分かりますが、それは結局のところ世間一般に広く受け入れられているものではないのではないかという疑問ですね。色々お話を伺っていてもそこの部分がどうにも解消しないので、もやもやとしたものを感じてしまいます。--重陽（会話） 2016年3月27日 (日) 05:36 (UTC)

一段落目．はい，そういうことです．

二段落目前半，全く気付いていませんでした，修正する必要がありますね．後半については，特に賛成でも反対でもないです．

三段落目．「国際的な標準化団体で勧告されているレベル」なのかどうかは知りませんが（探せば見つかりそうなものですが），少なくともこのような表記について知っている人からすれば常識でしょう．グーグルブックスで調べてみると例えばこの本には HYPHEN-MINUS has no use in mathematical expressions とはっきり書かれています（斜体は私によるもの）．

「色々調べてもハイフンマイナスはそこら中で使われて」いるというのはどこを調べてのコメントでしょうか？エクセルもプログラミング言語の類（というと語弊があるかもしれませんが，どう言えばいいでしょうか，数式処理ソフトとでも言えばいいですかね（表計算ソフトですが））ですから，ASCIIで入れてASCIIで返ってくるのは当たり前ではないでしょうか．これはまさに本来のマイナス記号が使えない例です．そうではなく，例えば，きちんと組版された出版物でハイフンマイナスが使われるなんてことがあるでしょうか？マイナスにハイフンマイナスを使わないというのは，掛け算の記号に * を使わないというのと同じくらい当たり前のことなのです．新規作成 (利用者名) （会話） 2016年3月28日 (月) 05:06 (UTC)

ご返答ありがとうございます。数字節の単位の部分の変更ということで承知しました。本題の部分はそれで異論はありません。

疑問点の部分、エクセルの例示がよくなかったようですね。他に調べた場所としては科学技術振興機構のJ-Stageから日本の学術論文を色々と見ていました。分析化学や日本結晶学会誌、化学工学論文集、日本薬理学会誌など多くの学術誌でマイナス記号にハイフンマイナスが使われていました。化学工学論文集の執筆・投稿要領があったので確認してみると、要領書に例示された単位に付けられているマイナス記号の時点でハイフンマイナスになっているようです。同じJ-Stageに掲載されていた有機合成化学協会誌や日本金属学会誌ではマイナス記号が使われていたのでマイナス記号の使えない環境と言うわけではなさそうですし、年代は最も直近の2015年から2016年ぐらいのものを調べましたので古すぎてということもないと思います。学術文献レベルですらマイナスにハイフンマイナスが使われているものも多くあるという事実を考えれば、マイナスにハイフンマイナスを使わないという「当たり前」は、英語環境であったり、数学分野などの一部の特定分野でしか通じない「当たり前」なように見えます。新規作成さんから見ればそれは非常識で嘆かわしいことかもしれませんが、それが日本語環境における現状・現実なのではないかなと。そして学術誌でもまだその段階なのですから日本語版ウィキペディアの編集者の皆が皆きっちり使い分けようというのもまた、まだ早い段階なのかなと思いますし、これらの状況を踏まえてもハイフンマイナスをマイナスとして使う余地を残しておく必要性があるのかなと思いました。それと、示していただいた文献から引用された文にも「in mathematical expressions」とありますし、数式そのものではない単位中のマイナスや、科学分野でよく用いられる電荷を示すマイナスに関しては、ハイフンマイナスをマイナスとして使うことに関して「no use」とまではいかないのではないかなとも感じました。私が見た学術文献で使われているハイフンマイナスの例は、いずれも数式そのものではない単位や電荷などを示すマイナスでしたし。--重陽（会話） 2016年3月28日 (月) 22:35 (UTC)

ハイフンマイナスが使われているというそれらの例にURLを付していただけると助かります．J-Stageの使い方がよく分からないもので．（ハイフンマイナスの使用を疑っているわけではなく，単純にそれらの「非常識」な例を自分の目で見てみたいだけです．）お手数をおかけします．取り急ぎ．新規作成 (利用者名) （会話） 2016年3月29日 (火) 07:53 (UTC)

例えば化学工学論文集では、[2]では最終行の単位の部分のマイナスがU+FF0D（全角ハイフンマイナス）になっています。[3]や[4]でも、マイナスの部分が同じくU+FF0Dです。逆に有機合成協会誌の[5]では、旋光度の向きを示すプラスマイナスのマイナス部分はU+2212のマイナス記号が使われています。時間が取れなくて数例で申し訳ありませんがとりあえず。--重陽（会話） 2016年3月30日 (水) 22:38 (UTC)

お忙しいところお調べいただきありがとうございます．1つ確認したいのですが，他に調べた例ももしかして全角ハイフンマイナスでしょうか？（半角）ハイフンマイナス (HYPHEN-MINUS) でなく全角ハイフンマイナス (FULLWIDTH HYPHEN-MINUS) なのであれば，話が違ってきます．ユニコードにしたがって U+002D のことをハイフンマイナスと呼んでいますが混乱させたようなら申し訳ない．日本の特殊事情で，全角ハイフンマイナスはマイナス記号として使われてしまっているのです．新規作成 (利用者名) （会話） 2016年3月31日 (木) 05:33 (UTC)

調べた例はU+FF0DだけでなくU+002Dも相当数ありました。U+FF0Dの全角ハイフンマイナスにそのような事情があるのであれば、文字化けせず、入力が容易で、日本語環境でマイナス記号として常用されているU+FF0Dで今挙がってる問題は全て解決してしまうような気もしますが。それはさておき、U+002Dの半角ハイフンマイナスを使っている例であれば、日本材料学会誌の[6]や[7]、[8]、素材物性学会誌の[9]、[10]、[11]、エアロゾル研究誌の[12]、[13]、[14]などがありました。見回った範囲での使用状況は、全角ハイフンマイナスは半角ハイフンマイナスよりもさらに多く、U+2212のマイナスは半角ハイフンマイナスよりもさらに少なかったです。全体数からすれば調べた範囲はごく一部でしょうけども参考まで。--重陽（会話） 2016年3月31日 (木) 12:43 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘文字化けのリスクはあるはずです．マイナス記号U+2212の入力については編集者の負担になると言っていた方が全角ハイフンマイナスU+FF0Dの入力は容易と言い出すのはちょっとよく分かりません．なるほど確かに半角ハイフンマイナスが使われているようですね．失礼ながら文章の見た目に気を使っていない（と思える）ものが多いですが．数学とか物理とかから離れた分野だとそういうこともあるのですね．（ちなみに物理だと例えば日本物理学会誌があります．）新規作成 (利用者名) （会話） 2016年4月1日 (金) 05:19 (UTC)

「あるはずです」と漠然と言われても困りますが、下でGwanoさんがお調べいただいたようにU+2122のマイナスが文字化けするような環境でもU+FF0Dの全角ハイフンマイナスは文字化けしないようですから、ないことを提示するのは難しいですけど少ないということはいえそうです。U+FF0Dの全角ハイフンマイナスはキーボード右上の0の右のキーから普通に変換で出せるのですから、実体参照云々が必要なU+2212のマイナスとは比べ物にならないほど入力は容易ですよ。新規作成さんのように十分に知識があり慣れている方からすれば些細な差かもしれませんが、多くのユーザーにとって実体参照云々はハードルが高いですし入力の負担は天と地ほどの差があると思います。論文誌での記号の使われ方というのは、確かに数学物理に近い分野でU+2122のマイナス記号を使ってるケースが多かったように思います。これらの例示で、「ハイフンマイナスをマイナスとして使わないのは当たり前」というような常識は数学や物理のような特定分野にしか浸透しておらず、そこから離れた分野ではハイフンマイナスをマイナスとして使っている事例が多々あるという認識は共有できたかと思います。これを踏まえれば、やはり数物分野から離れた分野にまで影響のある表記ガイドでU+2122の使用を推奨をするのは現状の日本語環境における状況に合致していないということになるのではないかなと思います。そしてそのような状況の中で数物分野以外の分野にまでマイナス記号にU+2122を推奨していこうというような動きをすることは、ウィキペディアの分を超えていると思います。--重陽（会話） 2016年4月2日 (土) 03:09 (UTC)

困ると言われても困りますが，文字化けする環境がないならそもそも全角マイナス文字化け問題なんて起きてないでしょう．「U+FF0Dの全角ハイフンマイナスはキーボード右上の0の右のキーから普通に変換で出せる」というのはあなたの環境ではそうなのでしょうとしか言えません．Macのパソコンだとマイナス記号を簡単に出せたような記憶があります（今すぐには確認できませんが）．数式入力時は普通半角なのだから全角ハイフンマイナスの方が入力の手間がかかります．上にも書いたようにマイナス記号は（デスクトップ表示だと）編集画面下部にある記号をクリックしても入力可能です．実体参照がハードルが高いというのはによる上付き添え字がハードルが高いというのと同じくらい馬鹿げています．もっと言えばウィキ独特のマークアップの方がハードルはかなり高いです．というかこんな数回使えば覚える程度のことでハードルとか言い出すのは編集者を馬鹿にしているとしか思えません．「数学や物理のような特定分野にしか浸透して」いないのではなく重陽さんに探していただいたような特定分野に浸透していないのでしょう．新規作成 (利用者名) （会話） 2016年4月2日 (土) 06:13 (UTC)

文字化けについては確かにそうですね。Gwanoさんの調査でU+2122が文字化けする機器内蔵版Operaを使った環境でもU+FF0Dは文字化けしないという結果があったので、だったらこれなら大丈夫じゃないかという思いつきレベルの話でして、すみません。入力の難度に関しては簡単と難しいの2つにきっちり分かれるようなものではなく相対的な話ですし、半角ハイフンマイナスを使えるならそれが一番簡単であって後は程度問題でしょう。「こんな数回使えば覚える程度のことでハードルとか言い出すのは編集者を馬鹿にしているとしか思えません」と言っても私以外にも複数の方がそうおっしゃっているのですし、そういう部分は数学分野で記号の使い分けが身に染みている方とそうでない方との埋めがたい感覚の差なのかなと思えてしまいます。マイナス記号はきっちりU+2122を使わなければならないということが浸透しておらず、そのことに必要性も使命感も何も感じないような分野の人間にしてみれば、半角ハイフンマイナスを使っていれば「数回使って覚える」必要すらそもそもないのですから。浸透云々に関しては、はじめに新規作成さんがおっしゃった「マイナスにハイフンマイナスを使わないのが当たり前」というお話に対する反例として、そのような「当たり前」が浸透していないケースを例示したわけですから、その時点であらゆる分野にそのような「当たり前」が浸透しているというわけではないということははっきりしたかと思います。その調査の過程で、数学や物理などの数式を多用する分野においてはきっちりマイナスにU+2122の記号が使われていることも確認しました。しかし確認できた数物分野以外の分野で日本語環境においてマイナス記号にU+2122を使うことが当たり前であるということについては例示も何もないわけですから、現状では新規作成さんがおっしゃることは新規作成さんの個人的な感覚・想像・予測の範囲でしかないわけですよね。そのような状況で、浸透していないのは私が調べた分野だけと断言されましても同意のしようがありません。これでは、前言を翻すことになってしまいますがガイドライン中の例示のマイナス表記をU+2122に変えるという部分への賛成も取り下げて反対せざるを得なくなってしまいますよ。マイナス記号にはU+2122を使うということが浸透しているわけではない化学系の分野においても例示と同じように単位の部分にマイナス記号を使いますから、そのような例示は「当たり前」が浸透していない分野に対する流儀の押し付けになってしまいかねませんからね。--重陽（会話） 2016年4月2日 (土) 09:45 (UTC)

＞浸透していないのは私（重陽さん）が調べた分野だけ

などと発言した覚えはありません．落ち着いて私の書いた文章を読み直した方がよいと思います．さらに

＞はじめに新規作成さんがおっしゃった「マイナスにハイフンマイナスを使わないのが当たり前」というお話

そんなことを言った覚えもないんですよね．おそらく「マイナスにハイフンマイナスを使わないというのは，掛け算の記号に * を使わないというのと同じくらい当たり前のこと」を曲解してるのでしょうけど．ここまで発言を改竄されると返信する気も失せますね．とりあえずこの2点はどうしても気になったので取り急ぎ返信しておきます．新規作成 (利用者名) （会話） 2016年4月2日 (土) 10:38 (UTC)

ご迷惑おかけしてすみません。曲解や改竄のつもりはありませんでしたが、1点目の方に関しましては新規作成さんの文章を誤って読んでいました。確かに、他の分野に関することが調査できていない以上は「特定分野にしか浸透していない」とはいえず、「数物分野」では浸透しているということと、「私の調べた分野で浸透していない」ということがはっきりしているだけですね。申し訳ありません。そうしますと、例示の単位のマイナスにどの記号を使うかというところは、結局どの記号を使ってもどちらかの分野の流儀の押し付けになるということになってしまいますし、マイナス記号が必要になる例を避けて別の例に変えるという所になるのかなと思います。

「マイナスにハイフンマイナスを使わないというのは，掛け算の記号に * を使わないというのと同じくらい当たり前のこと」に関しては、私の「それは結局のところ世間一般に広く受け入れられているものではないのではないかという疑問」に対するお返事なので、「掛け算の記号に * を使わない」ということは世間一般に広く受け入れられているものなのであって、それと同じぐらいに「マイナスにハイフンマイナスを使わない」ことは「当たり前」なのだというようにおっしゃっていたのだと思っていました。確かに掛け算の記号に * を使っているような文献や論文を見た記憶はなかったので単純にそういうものなのかなと。そのご発言に対して「マイナスにハイフンマイナスを使わないという「当たり前」」という言い回しを使ってご返答した際にもそうじゃないという指摘もありませんでしたし、以降もそれを前提に対話に続けていて齟齬も感じなかったため、今まで新規作成さんの意図と異なる前提で対話していたことに気が付きませんでした。色々と調べたときに「マイナスにハイフンマイナスを使う例」がいくつもあったので、「マイナスにハイフンマイナスを使わないというのは，掛け算の記号に * を使わないというのと同じくらい当たり前のこと」ではないのではないかと思いそういう流れで話をしてきましたが、そもそもその流れ自体が根本からおかしいということなのでしょうか？改めて読み直しても新規作成さんの意図と私の理解がどう違っているのかよく分からないのでちょっとどう修正すればいいのか分かりませんでした。--重陽（会話） 2016年4月3日 (日) 01:02 (UTC)

まず，2016年4月2日 (土) 10:38 (UTC) での発言が必要以上に強い口調になってしまったことをお詫びします．また，急いで返信したため言葉足らずな部分もありますから，それを補っていきます．

「マイナスにハイフンマイナスを使わないのが当たり前」と私が言っていないというのは，私とあなたで「当たり前」を異なる意味で使っているということです．たとえて言うならば（適切なたとえではないかもしれませんが他にいい例が思い浮かばないもので），私は赤信号では停まる／横断しないのが当たり前だと言っているのに対し，あなたは信号無視してる人はたくさんいるよと言っているのです．（蛇足ですがプログラミング言語は救急車といったところですかね．）私の主張は「− が正しいマイナス記号でありそちらを使うべき」であって，それが「世間一般に広く受け入れられている」かどうかはメインではなかったのです．そういうわけで，実際の使用例を出したところで，（重陽さんの調査自体は有用ではあるけれど）私の主張に対する反論にはならないのですよね．ハイフンマイナスを使っているのが意図的にそちらを選んだ結果なのかそうでないのか分からないからです．「そうじゃないという指摘」をしなかったのは，単にそのときは特に問題ないと思ったからです．

例からマイナス記号を除くには，光速度については単位を m/s にすれば済みますね．あるいは TeX で書くか．新規作成 (利用者名) （会話） 2016年4月3日 (日) 07:45 (UTC)

ご返答ありがとうございます。詳しく説明していただきましたおかげで新規作成さんのお考えが分かりました。私の方の考えとしましては、同じ信号機の例で言えば、確かに日本のルールでは赤信号では横断しないのが当たり前ですがアメリカ（正確には州によって異なりますが）では赤信号でも（条件付で）右折可というルールが運用されているように国によって信号機の運用に差があって、アメリカでアメリカのルールに沿って赤信号を右折している車に対して日本のルールでもって赤信号を横断するなんて非合法じゃないかとおっしゃられているように感じているのです。つまり、新規作成さんは私の意見を「信号無視は非合法である」という前提の上で「信号無視してる人はたくさんいるよと言っている」というように受け取られていますが、私としては「本当に信号無視は非合法なのか」という疑問の上で「信号を無視していいという運用がされている場所もありますよね」と言っているつもりなのですね。新規作成さんのご主張の意図がそういうところにあるのであれば確かに私の調べたことは反論にはならないですけれど、私の主張をサポートする裏付けにはなると考えています。ハイフンマイナスを使っているのが意図的にそちらを選んだ結果なのかそうでないのかは分からなくても、査読誌においてハイフンマイナスを使った論文がハイフンマイナスの記号のままで掲載されているのですから「ハイフンマイナスを使っていい」という運用ではあるわけですから。新規作成さんのお考えがよくわかりまして感覚のずれの原因はつかめたように思いますが、そうするとお互いに自身の意見をサポートする根拠を並べても相手の意見に対する反論にはなり難いかなと感じます。--重陽（会話） 2016年4月6日 (水) 22:33 (UTC)

＞私としては「本当に信号無視は非合法なのか」という疑問の上で「信号を無視していいという運用がされている場所もありますよね」と言っているつもり

ええ分かってますよ．ですが例を挙げるだけではそういうルールがあるのかルール無視が横行しているのかルールが無いのか分からないわけです．おそらくお互いの意思疎通はできたのではないかと思いますがどうでしょうか．新規作成 (利用者名) （会話） 2016年4月8日 (金) 08:55 (UTC)

ここまでお話にお付き合いいただきましてありがとうございます。これでお互い意思疎通ができたかと思います。確かに現状としては「分からない」としか言いようがない状況ですね。ルールの有無は分からなくても少なくともハイフンマイナスをマイナスとして使っているという学術文献レベルの実例が分野単位でいくつも存在している以上、たとえそれが仮に「ルール無視の横行」であったとしても、ウィキペディアは率先してそれを是正していくことを試みる場ではありませんし、我々ができることは分からないなりに実情を追従するしかないかと思います。そう言う観点から考えますと、下の3の節の新規作成さんの文案は、マイナス記号に関する実情の提示のみに留めて指示はしないという形で、落としどころとして非常にいいのではないかと思いました。--重陽（会話） 2016年4月11日 (月) 21:57 (UTC)

どうも重陽さんは重大な勘違いをしている気がするので補足しておきますが，「学術文献レベルの実例」で誤りが散見されているからと言ってウィキペディアは同じ誤りを広める場ではないですし，私の案は文字化けの方を考慮したものです．（endash と hyphen の誤りなんかはそれこそ英語論文や書籍で頻繁に目にしますが enwiki ではきちんと正しく使うよう書かれていますね．）新規作成 (利用者名) （会話） 2016年5月28日 (土) 07:09 (UTC)

そもそもこの話題で、「きちんと組版された出版物」って言葉が出てくること自体が間違いでしょう。MediaWikiのTeX出力の出来を議論しているのならともかく、その逆です。我々はそんなものを作っている訳ではなく、また目指すべきでもありません。紙面にするとかPDFにしてしまうことを前提としたモノづくりではなく、文章一般においては、志向するのは未だに「機種依存文字」を極力回避するような昔ながらのメールやらウェブページの考え方です。「文字コードにある正しい文字だから」「印刷で綺麗な字形になるから」「組版では使うのが常識だ」といって Ⅱ や ② を使うようなところではないのです。「きちんと組版された出版物(笑)」なら決して「II」なんて使わせませんし、fi なんかは全部リガチャにしないとですね。--Hisagi（会話） 2016年3月29日 (火) 15:27 (UTC)

それはあくまで例であって，例としては悪かったかもしれませんが，ただの HTML のウェブページとかであっても同じことで（というよりはパソコン等で入力・表示するこのような場合についてこそ言うべきことですが），何度も言っているように − が正しいマイナス記号なのであって，ハイフンマイナスはそれが使えないときの代用でしかないのです．機種依存文字を回避したいなら極論全部 ASCII で済ませばいいのです．機種依存文字を避けたいというのは分かりますし私もなるべく避けてはいますが．残念ながら「きちんと組版された出版物」でも「II」は普通に使われますしそもそもローマ数字はIやVを並べて書くのが正しいです．新規作成 (利用者名) （会話） 2016年3月30日 (水) 05:16 (UTC)

話の流れを切って恐縮ですが、取り急ぎ「その他」節の全角マイナスの記述だけ確認してみました。ひとくちに「全角マイナス」と言ってもプラス記号とマイナス記号#マイナス記号の符号位置を見る限り、単に「全角マイナス」と呼ばれる記号は（Unicodeには?）見当たらないようですので、ここで言う「全角マイナス」が何なのかをはっきりさせておく必要があると思います。履歴を見る限り「その他」節が追加されのは恐らく2006年11月22日(UTC)の版で、このときは「全角マイナス」として「－」が使われていました。これは恐らく全角ハイフンマイナスかと思われます。これが半角に変更されたのは2007年5月30日(UTC)の版で、恐らく大規模整理の際の単純ミス（もしくは全角マイナスハイフンが文字化けする環境での編集？）かと思われます。なので、「全角マイナス」という記述自体も正確には「全角ハイフンマイナス」とするか、あるいはカッコ付きで併記すべきかもしれません。ご参考まで。--Gwano（会話） 2016年3月29日 (火) 13:14 (UTC)

全角マイナスと言えば普通全角ハイフンマイナス U+FF0D のことだと思いますが，U+2212 = − のことを指すこともあるようですから，はっきりさせておいた方がいいでしょう．新規作成 (利用者名) （会話） 2016年3月30日 (水) 05:16 (UTC)

符号位置を見る限りJIS X 0213ではハイフンマイナスに全角と半角の区別はないようですので、もしかしたらJIS X 0213ベースのブラウザかエディタで編集した際に、全角ハイフンマイナスが勝手に半角ハイフンマイナスとして扱われた可能性も考えられそうです。もしそのようなことがあるなら念のため、表記ガイドの説明文では全角ハイフンマイナスのソースを文字参照（－か－）にしておいたほうが無難かもしれません。--Gwano（会話） 2016年3月30日 (水) 10:02 (UTC)

ところで − が空白になってしまう環境で全角ハイフンマイナスはどのように表示されるでしょうか？新規作成 (利用者名) （会話） 2016年3月31日 (木) 05:33 (UTC)

はい。当方で確認した機器内蔵版Operaの2例については、どちらも全角ハイフンマイナス（U+FF0D）とされる表記「－」は正常に表示できています（前述のDSの写真←映りが悪くて恐縮ですが、下のほうにU+FF0Dも映っています）。恐らくハイフンマイナスの説明にある「ASCII、JIS X 0201などのISO/IEC 646系の文字コード」を機器側が持っていることによる、Unicodeへのマッピングの都合なのでしょうけど、詳しいことは存じません。--Gwano（会話） 2016年3月31日 (木) 07:30 (UTC)

そうですか，全角ハイフンマイナスは表示できているのですね．ありがとうございます．新規作成 (利用者名) （会話） 2016年4月1日 (金) 05:19 (UTC)

記号の正しさの方にばかり話が行ってしまってメリットやデメリットについてあまり強調されてない気がするので（一部は繰り返しになりますが）一応書いておこうかと思います．マイナス記号のデメリットは一部環境での文字化けがあります．ハイフンマイナスのデメリットは，ハイフンマイナスが様々な意味で用いられてしまうため，可読性が落ちます（単項演算子の場合はまあフォントによってはそうでないこともありえますが）．それはもちろん，ハイフンマイナスはマイナス記号より短いからというのもあります（どれくらい違うかはフォントによって異なるかもしれませんが）．マイナスのための記号とそうでない記号で見た目が違うのは当然といえば当然ですが，正しい記号を使わないと，見た目のキレイさとか電子文書としての正しさとかも損なわれることになりますが（それらを気にするのはそれはそれで大事なことですが）それだけでなく可読性が落ちます．見た目がちょっと悪くなるだけではなく可読性が落ちます．編集者の怠慢あるいは無知のせいで閲覧者の可読性を損なうべきではありません．誤字の類ですから記事の質や信用度も落ちます（これはマイナスを一律ハイフンマイナスにでもしない限り不可避です）．新規作成 (利用者名) （会話） 2016年5月11日 (水) 12:21 (UTC)

一応、マイナス記号のデメリットとしては入力の手間というご意見もありました。このへんの見解は各々によって異なる部分なのかと思います。

一方でハイフンマイナスのデメリットとしては可読性の観点は当然あるかと予想していたのですが、思ったよりそのような意見は少なかった印象です。一部の欧文フォントではハイフンマイナスを上付き文字にした際にドットと紛らわしく見えるほどのケースもありますので、英語版ではマイナス記号が積極的に使われてハイフンマイナスがハイフンとして使われるのも仕方ないのかもしれません。一方で日本語フォントのハイフンマイナスには一般にある程度の長さがあるようで、マイナス目的でも充分通用するように見えます。日本語ではハイフンマイナスがマイナス目的でも多く使われるという背景に合ったフォント事情もあるのかもしれません。--Gwano（会話） 2016年5月15日 (日) 13:21 (UTC)

ですから「入力の手間」は執筆者のわがままですから（平方メートルを m2 と書くのがめんどうだからといって m2 あるいは m^2 と書いていいことにはならないのと同じです），デメリットにはなりえません．（それに，表記ガイドは通常の編集に大して影響があるわけでもないですし．（例えば半角括弧（括弧内に半角のみでも全角が使われる）とか半角括弧の前後や単位の前のスペース（がない）とか見れば明らか．））

「ある程度の長さがある」だけでは「マイナス目的でも充分通用する」とは思えません．マイナス記号と（ほとんど）全く同じ長さの場合があるならそれは別として，ハイフンマイナスはいくつもの意味で用いられるのですから読者に余計な負担をかけることになりますし，ハイフンマイナスがハイフンと認識されるような環境を完全に無視することになります．（もちろん正しいマイナス記号を使うと一部環境で表示されないのでどちらをより考慮するかという問題になるわけですが．）新規作成 (利用者名) （会話） 2016年5月20日 (金) 04:47 (UTC)

3

次のような感じに書き換えようかと思いますがどうですか？

案1a: 例：光速度 c = c₀ = 299 792 458 m/s; 例：プランク定数 $h=6.626\,070\,040(81)\times 10^{-34}\,\mathrm {J\,s}$; 例：リュードベリ定数 $R_{\infty }=10\,973\,731.568\,508(65)\,\mathrm {m^{-1}}$

新規作成 (利用者名) （会話） 2016年4月8日 (金) 08:55 (UTC)表示がうまくいってないので修正．新規作成 (利用者名) （会話） 2016年4月8日 (金) 09:01 (UTC)

例の中でマイナス記号を使わない分には個人的には構わないのですが、結局のところ「1. 表記ガイド内ではマイナス記号 (U+2212) はとりあえず使わない」、「2. 表記ガイドではマイナス記号 (U+2212) の具体的な扱いについては言及しない（禁止も推奨もしない）」という形になるのでしょうか？

一応、事の発端としては記事中でマイナス記号とハイフンマイナスが混在されていることに対して疑問を持った利用者に何らかの回答を用意する意図もあったので、禁止も推奨もしないのであれば、

減算や負号としては一般的な半角ハイフンマイナス - (U+002D) が使えますが、英語環境や数学・物理の専門分野などではマイナス記号 − (−, U+2212) が使われる場合もあります。

……くらいの、それなりに当たりさわりの無い説明があっても良い気はしますが、どうでしょう。できればオプションとして、

ただし、機器組み込みブラウザのようなごく一部の環境ではマイナス記号 − (U+2212) が表示されないケースが確認されており、正負を誤認する可能性が指摘されています。

……にも、個人的には言及したいところです。最近の表記ガイドではマイナー環境の文字化けに関してはあまり言及しない傾向があるようですが、本件は単なる文字化けでは済まない部分がありますので、例外的に。それとも、あまり細かいことはプロジェクト側で考えるべきでしょうか？ --Gwano（会話） 2016年4月8日 (金) 12:50 (UTC)

1については案1aでそう提案してみた，2については議論が停滞中，というところでしょうか？なんらかの言及をしてもいいかもしれませんが……うーん．

マイナスを表す記号には、マイナス記号「−」(−, U+2212)、（半角）ハイフンマイナス「-」(U+002D)、全角ハイフンマイナス「－」(U+FF0D) があります。ただし、ごく一部の環境ではマイナス記号あるいは全角ハイフンマイナスは正しく表示されない場合があります。

という案を置いておきます．新規作成 (利用者名) （会話） 2016年4月11日 (月) 08:14 (UTC)

言われてみれば確かに全角ハイフンマイナスにも同様の懸念がありました。一応この手の記号は半角を使うことになっていたかと思いますので（Wikipedia:表記ガイド#具体例による説明）、それを考慮するなら本来ここで全角ハイフンマイナスに触れる必要は無いと思われるところなのですが、実際には四則演算に関しては文中のちょっとした用途で全角の＋－×÷も結構使われているように思います。実状としてほとんど黙認状態のようですので（よく見るとWikipedia:表記ガイド#ハイフンにも文中では全角プラス"＋"が使われています）、これも表記ガイドのほうが現状に合っていない気がするのですが、どうしたものでしょう。日本語環境において文中での式と言うほどでもないようなちょっとした用途であれば恐らく全角の演算記号ほうが見やすいと思うのですが、環境によって全角ハイフンマイナスが表示されない可能性があるとなると如何ともしがたいところです。もっとも、そこまで考えるとなると別の議論かもしれませんが。--Gwano（会話） 2016年4月12日 (火) 14:10 (UTC)

「表記ガイドのほうが現状に合っていない」ということでいいんじゃないでしょうか．そのような場合のプラスは別に全角でも半角でもいいんじゃないかと個人的には思います．新規作成 (利用者名) （会話） 2016年4月17日 (日) 12:26 (UTC)

案1aについては，反対は無しということで，書き換えを実行しました．新規作成 (利用者名) （会話） 2016年4月17日 (日) 12:26 (UTC)

いずれ全角でのプラスとマイナスを表記ガイドに記載するか否かの議論は必要になるとは思いますが、その結論が出ないうちは、やはり今回の提案文の中での全角ハイフンマイナス(U+FF0D) の記述はとりあえず伏せておいたほうが良いように思います。文字コードを略して単にハイフンマイナスとだけ表現しておく手も考えられますが、まだ決まっていない部分に触れるのはやはり良くないでしょう。--Gwano（会話） 2016年4月24日 (日) 12:01 (UTC)

ちょっと意図がよく分かりませんが，この際ついでに（プラスとハイフンマイナスの全角についても）決めてしまえばいいのでは（節は分けた方がいいでしょうが）．新規作成 (利用者名) （会話） 2016年4月26日 (火) 10:18 (UTC)

あまり案件を広げますとコミュニティの疲弊を招きますので、こちらはこちらで一旦まとめたほうがスムーズに思った次第です。個人的には全角の四則演算を記載するのはそれなりに議論が必要な問題と考えています。--Gwano（会話） 2016年5月7日 (土) 11:07 (UTC)

全角の四則演算というか，正確には，全角のプラスと，全角のハイフンマイナスと，全角の等号ですよね．全角のスラッシュもでしょうか．新規作成 (利用者名) （会話） 2016年5月11日 (水) 12:21 (UTC)

話が進まないのも何ですので、とりあえず節を分けて提起いたしました。--Gwano（会話） 2016年5月13日 (金) 10:26 (UTC)

TeXにおける数値や単位のスペース

現状のプランク定数の例の \ による区切りから \, への区切りに訂正すること，つまり

<math>h = 6.626\,070\,040(81)\times 10^{-34}\,\mathrm{J\,s}</math>

に修正することを提案します．§単位では数値と単位記号のスペースは \, とすることになっています．新規作成 (利用者名) （会話） 2016年3月23日 (水) 07:04 (UTC)

少し説明を補います．単位の節で述べられている空白はもちろん数値と単位記号の間のスペースのみですが，それと整合性を取る意味で桁区切りおよび単位間のスペースも \, にすることを提案しています．なお，\, によるスペーシングは，例えば siunitx パッケージにもみられるように，TeX において一般的なものです．新規作成 (利用者名) （会話） 2016年3月24日 (木) 06:50 (UTC)

特に反論も無いようなので書き換えました．ガイドにはスペースとしか書かれてない（具体的な幅が書かれていない）ですから実際の編集では各自常識的な範囲内でやってくれればいいのではないかと思います．新規作成 (利用者名) （会話） 2016年4月6日 (水) 09:14 (UTC)

数式の節

現在の版では以下のようになっています．

基本的には、アルファベットにはイタリック体を用います。例えば、変数、関数一般を指す記号、物理定数などはイタリック体を用います。ただし、固有の関数名、単位、数字、括弧、等号などは立体を用います。
例： $f(x)=x^{2}$ 、光速度 $c$ 、 $2\log |x\sin x|$ 、行列の転置 $A^{\mathrm {T} }$
- TeX（math mode）を用いる場合は単にアルファベット文字を書けばイタリック体になります。立体にすべきアルファベットに注意すればよいです。
  - ただしギリシア文字の大文字の変数はイタリック体でなく立体で構いません。例：\Sigma
  - ギリシャ文字の小文字をウィキペディアで立体にすることはできません。
- TeX中でアルファベットをローマン体にするには、関数名には \log, \sin, \operatorname{Li} 等を用い、それ以外は、数式に属するものは\mathrmを用い、テキストに属するものは\textを用います。ただし、日本語（全角文字）を使用することはウィキペディアでは出来ません。
ベクトル変数・数の集合はボールド体（太字）かつイタリック体を用います。
例： ${\boldsymbol {r}}=\left(x,\,y,\,z\right)$
- TeXを用いる場合は\mathbfではなく\boldsymbolを用います。
行列変数は大文字かつ単なるイタリック体を用います。（ボールド体にはしない）： ${\boldsymbol {y}}=A{\boldsymbol {x}}$

以上コメントアウトを除いて引用．まだ改善の余地はありますので何かありましたら編集するなり意見を述べるなりしてください．新規作成 (利用者名) （会話） 2016年3月24日 (木) 06:50 (UTC)

全角チルダは使用しないでください？

全角チルダ「～」(Unicode: U+FF5E)・チルダ「~」(Unicode: U+007E)は使用しないでください。
って文は必要なんですか？書くとしても
波ダッシュの代わりに全角チルダ「～」(Unicode: U+FF5E)を使用しないでください。
ではないでしょうか？今の文だと全角チルダやチルダが使えないように読めてしまいます（というかそうとしか読めません）．新規作成 (利用者名) （会話） 2016年4月6日 (水) 09:19 (UTC)

私も（記号の説明でもない限り）実際にチルダは使わないものと捉えておりました。そのルールができた2007年ごろの議論では「一部のauのケータイで閲覧すると全角チルダが文字化けする」と主張される方がいらっしゃいましたので、もしかしたら文字化けを理由に使用自体を禁止する意図が込められていたという可能性も疑われます。現行の「使わないでください」を言葉通りに捉えるなら、チルダは（波ダッシュの代替以外には）日本語では特に使う必要の無い文字であるかのように解釈できます。そうであるなら、波ダッシュ以外で具体的にどういう目的でチルダが使われうるのか（どうしてもチルダでなくてはならないのか？）をまず例示したうえで、改訂提案を行う必要があると思います。

なお全角チルダと波ダッシュの改訂文は数節ほど上のスレでも提案中ですので、そちらとの兼ね合いもあるかもしれません（本当は議論の分散を避けたいのでマイナス記号の議論が終わるまで中断していたかったのですが…）。他節でも述べましたように、そもそもauのケータイは2012年の800MHz帯の電波割り当て変更があったため当時の端末はとっくに使えなくなっているハズですし、いくつかの機器内蔵ブラウザを見た限りではむしろ逆に波ダッシュのほうが化けやすく全角チルダのほうが安定して表示できています。いろんな面で全角チルダと波ダッシュまわりについては議論の余地が残るものと思います。--Gwano（会話） 2016年4月7日 (木) 11:58 (UTC)

チルダは数学や物理ではよく使いますが（ある種の二項関係，比が1に収束，オーダーが等しい，等々）&sim; なんですよね．全角チルダを使っていいのかどうか私は知りませんが．（全角チルダで書かれていたものを波ダッシュに（おそらく機械的に）置換する人をこの前見かけて表記ガイドを見てみたところ上掲の一文を見つけました．）新規作成 (利用者名) （会話） 2016年4月8日 (金) 08:55 (UTC)

履歴を見ますとチルダの節は2013年6月1日の編集で波ダッシュの節から分けられたもののようです。以前の記述では「全角チルダ「～」 (Unicode: U+FF5E) は、非Windows環境の場合には表示されないことがあるので使用を推奨しません。」とありましたので、このとき拡大解釈されてチルダ自体が禁止されたのかもしれません（余談ですが上記の通り非Windows環境であっても逆に波ダッシュのほうが表示できない環境が珍しくありません）。とは言え、チルダの節は波ダッシュ節の下位節に位置しており、恐らく本来の意図としては波ダッシュの代用法に限った話だったようで、チルダ自体のガイドラインは特に無かったものと考えられます（強いて言うならこの手の記号は半角を使うことになっていたかと思います）。具体的な用例も示されましたので、今回の改訂案に反対する理由は無さそうです。

考えてみれば波ダッシュの下位節にあるというだけで単にチルダだけの節タイトルが紛らわしいのであり、「チルダでの代用（について）」くらいにするか、そもそも下位節に分ける必要もなかったのではないかと思います。上のほうの節でも話題になりましたが、現状の表記ガイドでは全角チルダによる「代用」の概念自体を廃する傾向があるようですので、結果的に言葉が足りなくなってチルダ自体が使えないかのような誤解を招いているようにも思えます。そこまでして代用の概念自体を廃するのも本末転倒かと思いますので、「チルダでの代用（について）」程度の節タイトルのほうが親切かと思いますが、いかがでしょう。--Gwano（会話） 2016年4月8日 (金) 12:50 (UTC)

なるほど，お調べいただきありがとうございます．下位節に分ける必要が無いあるいは節タイトルを変えるという点について私も同意します．新規作成 (利用者名) （会話） 2016年4月11日 (月) 08:14 (UTC)

とりあえず「波ダッシュの代わりに」をつけておきました．新規作成 (利用者名) （会話） 2016年4月17日 (日) 12:27 (UTC)

プラスとマイナスの全角に含みを持たせる提案

上記#マイナス記号のガイドラインの議論を受けて節を分けます。現行の表記ガイドでは「+」「-」は原則半角と読めるのですが、現状では全角の表記で黙認されているケースも少なくありません。視認性の観点からは、「!」「?」のケースと同じように、「場合によっては全角が使われることがある文字」に分類するほうが妥当に思われます。現状に合わせてこれらを表記ガイドに反映しておくことを提起します。なお「=」については別件で全角を用いる場合がある文字に含まれていますので、説明の追加で済むと思います。

具体的にはWikipedia:表記ガイド#具体例による説明のところで「次の記号は、いわゆる全角を用いる場合があります。」に「+」と「-」を追加し、その下（「下記」のリンク）の「全角形も用いるかどうかについて、意見が分かれている文字もあります。 」のところに具体的な説明を一文程度書く形になると思います。

ここで具体的にどう説明するかが問題です。少なくとも「!」「?」のケースと同じような具体的な使い分けの目安まで議論するなると、個人的には良いアイディアが見えて来ません。例えば「×」「÷」と共に使われている場合は全角にそろえたほうが見やすいと思われますが、視認性を言うならそれ以外でも全角のほうが見やすい場合はいくらでもあると思います。これまでは数式・方程式の類は原則半角ということでしたから、例外を認めるとなるとどういうことになるか、関連記事での表記の習慣や事情をよく把握していらっしゃる方々のご見解が重要になると思います。

とりあえず具体的な目安までは言及せず、意見の別れている部分として「プラスとマイナスの全角に含みを持たせる」ことを追加する程度の当りさわりの無い文言としては、↓こんな感じでどうでしょうか？

候補1

式の中で使われる+-=については原則として半角ですが、「×」や「÷」と共に使われている場合などのように、全角に統一したほうが見やすいケースもあります。なお全角マイナスとして使われる全角ハイフンマイナス「－」は、一部の古い閲覧環境では正常に表示されない問題が知られています。

「/」についても追加したほうが良いでしょうか？ --Gwano（会話） 2016年5月13日 (金) 10:26 (UTC)

コメント 全角イコール（人名表記の問題）や全角コロン（ウィキマークアップの誤動作防止）のように個別具体的な問題があれば別ですが、もしも単なる一般論として例示の説明をされているだけであるなら、表記ルール全般について例外的対応がありうることは既に言及されているので、その中で特に四則演算子に限定してあえてそれを強調する必要はないと思います。これはそもそも記事執筆時の書式統一について確認するための指示文書なので、表記ルールを知ろうとしてこの文書を見た編集者が余計に迷いかねないような記述は必要最小限の諸注意・解説以外は極力避けたほうが良いと思います。

もし当該のご提案が具体的な問題意識に根ざして「×」や「÷」との統一性をはかることを念頭に置いたものであるなら、

全角文字しか存在しない演算記号「×」や「÷」が混在する箇所では、「＋」や「ー」などその他の演算子も全角文字で統一したほうが良い場合もあります。ただし、全角文字の例外的使用は必要最小限として下さい。特に、全角ハイフンマイナス「－」は一部の古い閲覧環境では正常に表示されない問題が報告されています。

のようにその趣旨・選択の優先順位を極力具体的に書いたほうが良いと思います。でないと、最初のご提案の文面だと2文目の解釈が釈然としないのではないかと思います。普通に考えるなら、字形の統一感の問題と一部環境での表示エラー回避とどちらが優先されるかといえば後者が優先ということになってくると思いますので、そうすると、事実上マイナス記号だけは半角のまま×÷＋だけ全角で統一することに意味は無いですからこの説明文の想定ケース自体が有名無実になってしまいます。もしも、そうではなくて四則演算の表記統一に限っては（一部環境の表示エラー問題が発生することがわかっていたとしてもそれよりも優先して）全角文字を使用することも認めるという文意と解釈するなら、そこの点が一番重要なので誤解の無いようにもう少し明確に言及しておく必要があると思います。--ディー・エム（会話） 2016年5月14日 (土) 03:09 (UTC)

もっともなご意見であり、恐れ入ります。表記ガイドでは「Unicode対応の過渡期」の観点からか（基本多言語面内であれば）文字化けについて言及しない傾向があるように思います。一方で、マイナス記号には万一表示されない場合に正負誤認のリスクがあることから、例外的に「留意」という意図で言及を残しておいてはどうかと考え、中途半端な表現になってしまいました。（自分の立場としては）両者のジレンマが解消されておらず、落としどころが難しかったのです。主題としてはプラスとマイナスの全角使用を認めるほうの話ですので、ただし、全角文字の例外的使用は必要最小限として下さい。と付け加えるのであれば、後者に言及しないのも手かもしれません。

問題意識としてはイコールやコロンほどのものではなく、疑問符・感嘆符やカッコの全半角と同様に、主に視認性というか見栄えの問題になります。「×」「÷」を含むケースもそうですが、前述のようにWikipedia:表記ガイド#ハイフンにあるような「半角スペース＋ハイフン＋半角スペース」を用います。みたいな用法も対象になりうると考えています。おおむね「全角文字が混在する場合」といったところでしょうか。これはカッコの全半角に近いかもしれません。原則として半角でも、全角が混在する場合は意見が分かれている（どちらでもよい）と読めます。

文字化けまで言及する場合は確かに全角マイナス（ハイフンマイナス）に対して代用を認めるか否かの問題が残ります。今回新たにご提示いただいた例文では長音記号「ー」での代用が示唆されているように読めます。仮に代用するとした場合の候補としては横棒やダッシュ類がいろいろ存在するとは思いますが、かつて名前空間の区切り記号（‐）が決められた時のように、それなりの議論が必要に思います。

一方で波ダッシュの例に倣えば、文字化けが多いからといって代用を認めるべきでは無いということになってしまいます。しかしマイナスは表示されない際のリスクが大きいため波ダッシュと同列に比べられるとは限らないのが難しいところです。

ひとまず代用については後回しとして、波ダッシュと同様に最小限の使用にとどめる形であれば、↓このくらいでどうしょうか。

候補2a

全角文字が混在する個所では、「＋」や「－」などその他の演算子も全角文字で統一したほうが良い場合もあります。ただし、全角文字の例外的使用は必要最小限としてください。

--Gwano（会話） 2016年5月15日 (日) 13:21 (UTC)

まだ完全に議論を追えていないのですが，『「×」「÷」と共に使われている場合』というのは通常の数式にまで影響が及んでしまうので反対です．候補2aみたいのならいいと思います．「ー」はさすがにただの誤字でしょう．半角で書かれていて読みづらくなっている例として，「利益」なんかは <pre> に入っているせいで（何を思ってそんなことをしたのか知りませんがそれはおいておいて）ひどく読みづらいです．全角ハイフンマイナスが正常に表示されない（現役の）環境が本当にあるのかは調べる必要があると思います．新規作成 (利用者名) （会話） 2016年5月16日 (月) 11:03 (UTC)

書き忘れ：スラッシュについては，割り算だけでなく普通の和文中にも用いられると思いますが，それも関連して議論しておくといいかもしれません．（上のコメントの補足で，候補2aも「通常の数式にまで影響」すると解釈できますがそんな曲解をする人はいないだろうと思ってそう書きましたがもう少し"正確"に書いた方がいいかもしれません．）新規作成 (利用者名) （会話） 2016年5月20日 (金) 04:47 (UTC)

確かに本格的な数式・方程式などへの影響は気になるところですが、そこをはっきりさせるとなると「通常の（本格的な）式」と「そうでない式」の定義が必要になると思います。単独であってもごく簡単な四則演算程度では全角に揃えたほうが見やすい場合もあるでしょうし、文中であっても複雑な式はプロジェクトに倣うなり半角に揃えるべきでしょうから、両者に明確な境目を見出すことは難しい気がします。うまい定義があれば良いのですが。

全角のマイナスについてはその経緯から化けやすいことは確かだと思うのですが、先日古いMac(OS 8.6)で試しましたところ、IE for Mac(5.1)という既にWikipediaにアクセスできないような古い環境でも、"－"や"～"の表示は問題無いようでした。現役環境で問題があるとすれば、ちょっと古いケータイ内蔵ブラウザなどの特殊な環境での潜在的影響が心配ですが、実際に不便を感じている方が声を上げない限りは、私からは何とも言えません。

全角スラッシュについては和文中の用法まで考えるとなると、議論を分けたほうがよい気がします。--Gwano（会話） 2016年5月21日 (土) 13:26 (UTC)

私は「通常の数式」に「本格的」なんてつけてないですし，

3 + 4 = 7

(3 + 4 = 7) 程度でも半角を用いるべきだしその方が見やすいと思います．

「（具体例）のように、和文中に用いる場合など、全角文字云々」みたいな感じで書くのが無難かと思いますが．新規作成 (利用者名) （会話） 2016年5月25日 (水) 12:23 (UTC)

うまい定義かどうか分かりませんが全角を使ってもいい場合の1つとして「いわゆる日本語同士を演算子で結ぶ場合」というのはどうでしょう．新規作成 (利用者名) （会話） 2016年5月28日 (土) 07:09 (UTC)

文例ありがとうございます。なるほどそれも1つの手かもしれませんね。私としては文脈内で×÷が混在している場合は、例えば「(8×3 + 1)色」のように書くよりは「（8×3＋1）色」としたほうが見易いかと思ったのですが、考えてみれば文脈の一部と見なせるような式であれば「8パレット×各3色＋透明1色」みたいに書きなおすという手も考えられそうですので。

ただ具体的に「日本語」と限定してしまうと、例えば全角文字を用いる外国語において単語を＋で結んで構文や熟語を説明する記述なんかには適さないと思いますので、多少工夫は必要かもしれません。 --Gwano（会話） 2016年5月29日 (日) 14:28 (UTC)

フォントと個人の感覚に依るところが大きいので，あの文は，おそらく多くの人に納得してもらえるであろうかつ実際の使用が多いであろうと思ったケースを書いてみたものです．あくまで全角を使ってもいい場合の1つですし，「のように」とか「など」とか「例えば」とかで適当につないでおけばいいんじゃないかと思いますが．新規作成 (利用者名) （会話） 2016年6月3日 (金) 05:15 (UTC)

著作物名について

かなり以前にも『』と「」の約物の使い分けについて、Wikipedia:井戸端/subj/小説における著作物名の表記の『』と「」の区別の仕方についての流れから、改訂案を掲げたことがありますが、やはり本来のガイドラインの意図や、文芸評論での通例に反し、「常に長編小説は『』で囲み、常に短編小説は「」で囲む」という判断を招くようですので（利用者‐会話:エヴァンズの秘書#「伊豆半島#伊豆地方を舞台にした小説」の表記について）、説明の文言を簡潔にしておきたいと考えております。エヴァンズの秘書さんにも改訂に同意していただけたので、今回再提案いたします。

私は文芸評論や作家論を読むのが好きなので、多くの文献を目にする機会が多いですが、作品が単体で解説されている場合でも、収録本との兼ね合いで、作品名を「」にする評論家もありますが（一般的にはこの場合は作品名を『』に統一する人が多い）、そんな論者でも、単品で刊行されなかったものは長編でも「」表記にしており、長編だから『』、短編だから「」という基準ではありません。その点に関しては小説も戯曲も同じ扱いです。

また、そういう細かいやり方を採用しながら、同じ条件下でも「楢山節考」のような著名な作品名は『』表記にしていたりすることもあり、それぞれ作品の特質などを考慮に入れて、フレキシブルな判断が常識の範囲内でなされています。なので、こういう約物は、短編だから必ずどんな時でも何がなんでも「」じゃなくちゃいけないということはなく、そんなことをガチガチに決めつけること自体が、はっきり言って実体にそぐわないことなんです。短編だろうが単品で刊行される時もありますし。

そもそも長編と中編、中編と短編の境目もあいまいですから、小説の長短で表記を変える明確なボーダーラインの定義などできませんし、そんなことで表記を変えること自体に何の意味もありませんから、誰もそんな酔狂なことやらないのです。上で説明した几帳面な方法を採用する人でも、あくまでも書籍との比較でやっているわけで、小説間同士の長短の比較でやっているわけではないことは自明のことです。

過去ログのこの件についての話合いでも「『　』と「　」の使い分けに関して、短編か長編か、ということは何ら意味がありません。この使い分けは、あくまでも発表されたときの形態に即したもので、作品の長さには関係ありません」という出版に詳しい方の意見があり、単に「短編か長編か」という理由の元での使い分けには意味がないことが指摘され、それに沿った形でのガイドラインの経緯となっています。

なので、本来の意図に反する「常に長編小説は『』で囲み、常に短編小説は「」で囲む」という誤った「固執」を生む原因となっている「比較的長大な作品」「比較的短小な作品」というあいまいな前置きを無くし、入れ子の構造をベースにしていることを示すシンプルな言い方に変えたいと思います。

私は、以前に利用者:Uaauaaさんが提案してくださった改訂案（[15]）が良いと考えていますので、そこに少し例目を補足した以下のような改訂を提起いたします。何かご意見があれば承ります。

作品及び作品群（書名・雑誌名・交響曲などの曲名・組曲などの名称・CDなどのアルバム名・映画名・戯曲名・小説名・テレビの番組名・イベント名・大会名など）の名称は、和文では『』で囲み、欧文では（入力を''……''として）イタリック体にします。

例：『海辺のカフカ』・『坊ちゃん』・『動物の謝肉祭』・Yesterday ... and Today・『ローマの休日』・『報道ステーション』

作品中の小題（書中の章名や見出し名・小説の章名や話名・戯曲の幕名や場名・交響曲などの楽章名・テレビ番組の企画名や話名など）は、和文では「」、欧文では、英文における “...” または各言語においてそれに相当する括弧で囲みます。

単独の作品でも、作品群中の一作品として表わす場合（雑誌中の収録論文名・作品集や全集中の収録作品名・詩集中の詩名・組曲中の曲名・シングルやアルバム中の曲名など）は同様とします。

例： Nature “Molecular Structure of Nucleic Acids”・『展覧会の絵』「プロムナード」・Yesterday ... and Today “Yesterday”・『古畑任三郎』「ラストダンス」

--みしまるもも（会話） 2016年5月15日 (日) 02:09 (UTC)

賛成ご提案いただきありがとうございます。賛成いたします。1点だけ、「作品及び作品群」の「及び」は仮名書き指定語なので「作品および作品群」にしてください。--エヴァンズの秘書（会話） 2016年5月15日 (日) 21:19 (UTC)

賛成標記ご提案について賛成いたします。また約物の使い方のかぎ括弧からも、「比較的長大な作品などの名称（詳細は#著作物名を参照してください）」との記述を変更しておくべきかと思量します。--LudwigSK（Talk/History） 2016年5月16日 (月) 00:32 (UTC)

コメント 短編や長編で扱いを分けないのは当然の処置なので、『』への統一そのものには賛成です。しかし、これはこれで別の問題が発生しています。実は、そもそも括弧を使用する必要がないケースも数多くあります。例えば、スポーツの大会や、国際博覧会に「必ず」逐一括弧を付けるものではありません（オリンピックが近いので、感覚的にはそちらの報道を見ると判りやすいかと）。これは、主題や文面から自然に判明するためです。ですが、この文面ではそういった無意味な括弧付与に走る事態が確実に発生します。それは、非常に申し上げにくいのですが、「荒らしの武器」になってしまいます。かつて問題になった『』「」の使い分けのようなスタイル強要という問題ユーザーの行動パターンが存在することを忘れないで下さい。この問題は、「作品名に対して括弧を『使用する』場合」に限定すれば、解消できます。

ついで、イタリックは環境面から問題があります。小さい画面ですと表示が潰れますし、フォントがイタリックを保有しているとは限りません。スタイル的に2バイト・1バイトで表記を変えるべきかどうかも問題です。さらに、日本の作品でたまたまラテン文字だけで構成されている、本質的には「和文」であるものまでイタリックにしなければならないのは不自然です。これは、括弧で対処することを可能とすることで対処できます。以下に修正案を示します。

括弧を使用する場合の使用法は、以下のようになっています

固有名詞でないものは括弧など特別な修飾を付けないでください。

例：交響曲第9番作品95 『新世界より』

作品および作品群（書名・雑誌名・曲名や組曲などの名称・CDなどのアルバム名・映画名・戯曲名・小説名・テレビの番組名など）の名称を括弧で囲む場合には、『』で囲みます。欧文では（入力を''……''として）斜体とすることもできます。ただし、環境により斜体は反映されない場合もあります。

例：『海辺のカフカ』・『坊ちゃん』・『動物の謝肉祭』・Yesterday ... and Today・『ローマの休日』・『報道ステーション』・『ONE PIECE』

作品中の小題（書中の章名や見出し名・小説の章名や話名・戯曲の幕名や場名・交響曲などの楽章名・テレビ番組の企画名や話名など）は、「」で囲みます。日本語以外の言語に対しては、英文における “...” など各言語において「」に相当する括弧で囲むこともできます。

単独の作品でも、作品群中の一作品として表わす場合（雑誌中の収録論文名・作品集や全集中の収録作品名・詩集中の詩名・組曲中の曲名・シングルやアルバム中の曲名など）は同様とします。

例： Nature “Molecular Structure of Nucleic Acids”・『展覧会の絵』「プロムナード」・Yesterday ... and Today “Yesterday”・『古畑任三郎』「ラストダンス」

リンクに『』や''などの記号を含めないよう注意します。

みしまるももさんの提案からの主な変更点

括弧を使用する場合の使い分けなので、冒頭で宣言。
エヴァンズの秘書さんの指摘通り、「および」に変更。
イベントや大会は著作物の節にあるべきではありませんからこれらを外します。
作品および作品群では交響曲に限定する必要はありませんし、中黒が不自然な位置にあるので修正。
現在**ではなく::を使用していますので、そちらに合わせました。またこの場合に、 は不要です。
和文・欧文の記法統一を可能として、現行の分離式との選択にします。
- これに対応して例を追加。漫画がなかったので、漫画から『ONE PIECE』を。
ビジュアルエディター、ソースを編集の双方で「斜体」とされているので、イタリック体から斜体へ変更（実は、イタリックと思われているものの一部は、イタリックではなく斜体です）。
斜体は反映されない場合もあることを注記として付加。
「!」「?」の扱いを切り離す。これだけ別のものが紛れ込んでいますし、「疑問符・感嘆符」の記載と矛盾するので、外します。

こんなところでどうでしょうか。--Open-box（会話） 2016年5月16日 (月) 15:20 (UTC)

コメントご提案者さんの、「フレキシブルな判断が常識の範囲内（で行われる）」「そんなことをガチガチに決めつけること自体が、はっきり言って実体にそぐわない」というのもっともです。また、Open-boxさんの修正案もベターだと思います。Open-boxさんご指摘のように、ヘタに（安易に）「このように統一すべし」という文言は、機械的に書き換えていく「荒らし」状の行動を誘発しかねませんよね。

一つ気になったのは、“固有名詞でないものは括弧など特別な修飾を付けないでください。”というところです。言いたいことはわかるのですが、これだと、Open-boxさんのご発言中の下記のような用法もダメということになってしまいます。

国際博覧会に「必ず」逐一括弧を付けるものではありません
「荒らしの武器」になってしまいます。
本質的には「和文」であるものまで

これらは今のWikipedia:表記ガイド#かぎ括弧において、“特に地の文と分けたい言葉”に使うことが可であり、かぎ括弧の説明部分で“言葉を地の文から際立たせるだけのために、二重かぎ括弧『……』で囲まないでください。”などの指示がありますから、それでいいはずです。
WP:BRACKETで、括弧類の種類と名称を定義しているので、鉤括弧（かぎ）・二重鉤括弧（二重かぎ）などの呼称を慎重に使い分ける必要があります。
なんというか、「こうしろ」という簡潔なガイドラインが、かえって「そればっかり機械的に書き換えることに起因するトラブル」を招いている面もあります。ガイドラインや指示などがシンプルなのは必要なことではありますが、「その意図するところは」「これに関してはいろいろ議論がある」ということを少し具体的に解説したほうがいい場面もあるように思うんですよね。「シンプルな指示部分」「解説部分」を明確に色分けするとかなんとかで、うまくできないもんでしょうかね。--柒月例祭（会話） 2016年5月16日 (月) 18:28 (UTC)

コメント 少なくとも1つ目の案には問題が多いので

反対ですが、Open-boxさんが修正された案ではかなり実用的なものになってきていると思います。

複数巻からなる図書・映像作品などについて、そのうちの一巻はどちらに該当するのか（一作品といえるのか、作品の一部分なのか）明示的ではありません。（巻次を鉤括弧の外に出せるケースだけとは限りません）
「CDのアルバム」に「シングル」も加えて良いのでは。
作品名の一部にもともと鉤括弧または二重鉤が含まれる場合の指示も必要ではないでしょうか。

--Hisagi（会話） 2016年5月16日 (月) 20:51 (UTC)

コメント みなさんご意見ありがとうございます。Open-boxさんが細かな配慮を加えてくださった案で概ね賛成です。冒頭文は、一応念のために「著作物の括弧類を・・・」としておいた方がいい気がしました。あと、次の「固有名詞でないものは・・・」の固有名詞という文言は避け、以下のような文にしたらどうでしょうか。これなら、柒月例祭さんの懸念も解消されるかと思われます。クラッシックの正式名称には明るくないので、間違っていたら修正してください。

作品名称とまではいえないもの（副題など）は、特に括弧類を付ける必要はありません。

Hisagiさんの1番目の件ですが、全集の各々の巻は通常『』で表記するので、上の部に「巻次名」を入れておけば判断可能になると思いますが、「巻次を鉤括弧の外に出せるケースだけとは限りません」というのは具体的にどのようなものでしょうか。

シングル曲については、その分野の方たちの合意で、単独でも「」表記になっているようです。

タイトル中すでに括弧が包含されている場合（論文などによく見受けられますが）は、それが作品名だけならば、どちらに変わってもあまり問題無いと思いますが、例えば、三島由紀夫の『仮面の告白』、『憂国』と『奔馬』における「純粋」と「不純」のような場合ですと、安易に会話文・引用符内の処理法（括弧の入れ子）を順守し、『純粋』『不純』にすると概念と作品名が混同しますので、基本的には論者が付けたタイトル名そのままの状態を維持するのが無難だと思います。ポジネガで規則化してしまうととても複雑になるし、これもまた機械的統一の温床となる気がします。--みしまるもも（会話） 2016年5月17日 (火) 03:36 (UTC)

Open-boxさんの案から少し補足したものを示してみました。

著作物の括弧類（鉤括弧・二重鉤括弧）を使用する場合の使用法は、以下のようになっています。

作品名称とまではいえないもの（副題など）は、特に括弧類を付ける必要はありません。

例：交響曲第9番作品95 『新世界より』

作品および作品群（書名・巻次名・雑誌名・曲名や組曲などの名称・CDなどのアルバム名・映画名・戯曲名・小説名・テレビの番組名など）の名称を括弧で囲む場合には、『』で囲みます。欧文では（入力を''……''として）斜体とすることもできます。ただし、環境により斜体は反映されない場合もあります。

例：『海辺のカフカ』・『坊ちゃん』・『動物の謝肉祭』・Yesterday ... and Today・『ローマの休日』・『報道ステーション』・『ONE PIECE』

作品中の小題（書中の章名や見出し名・小説の章名や話名・戯曲の幕名や場名・交響曲などの楽章名・テレビ番組の企画名や話名など）は、「」で囲みます。日本語以外の言語に対しては、英文における “...” など各言語において「」に相当する括弧で囲むこともできます。

単独の作品でも、作品群中の一作品として表わす場合（雑誌中の収録論文名・作品集や全集中の収録作品名・詩集中の詩名・組曲中の曲名・シングルやアルバム中の曲名など）は同様とします。

例： Nature “Molecular Structure of Nucleic Acids”・『展覧会の絵』「プロムナード」・Yesterday ... and Today “Yesterday”・『古畑任三郎』「ラストダンス」

なお、楽章などでも特別に著名性が高く単独で扱われる機会の多いものや、歴史的に単独で歌い継がれてきた民謡などは、『』でも許容されます。

例：『歓喜の歌』・『おてもやん』・『蛍の光』

作品タイトルの中に括弧類が包含されている場合には、基本的には作者が付した状態を保持することを念頭に置きながら適宜対応します。括弧類が著作物名だけなら#括弧の入れ子に準じてもよいですが、著作物名と一般語（概念など）が混在する場合は混同を避けるため、そのままを維持することが望まれます。

例：夏目漱石「文鳥」について → 「夏目漱石『文鳥』について」

例：三島由紀夫の『仮面の告白』、『憂国』と『奔馬』における「純粋」と「不純」 → 「三島由紀夫の『仮面の告白』、『憂国』と『奔馬』における「純粋」と「不純」」

リンクに『』や''などの記号を含めないよう注意します。

異動は以下の点です。

冒頭文の出だしに付加→「著作物の括弧類（鉤括弧・二重鉤括弧）」を付加しました。
2行目を変更→「作品名称とまではいえないもの（副題など）は、特に括弧類を付ける必要はありません。」
作品および作品群の項目に付加→「巻次名」
すでに括弧類が包含されている場合の対応例を加筆。
CDシングルはアルバムとの入れ子の関係上で常に「」で合意されているようですが、歴史的に古く、単独で長く歌い継がれてきた民謡などは、何がなんでも「」でなくてはならないということもないと思いますので、そのへんのことを加筆してみました。--みしまるもも（会話） 2016年5月20日 (金) 01:35 (UTC)

条件付賛成 「なお、楽章などでも特別に著名性が高く単独で扱われる機会の多いものや、歴史的に単独で歌い継がれてきた民謡などは、『』でも許容されます」については、「特別に著名性が高く」や「歴史的に単独で歌い継がれてきた」の基準というかそれに該当するかしないのかの線引きが分かりにくいので、この記述はない方がいいと思います。他は賛成です。--エヴァンズの秘書（会話） 2016年5月20日 (金) 23:01 (UTC)

コメント　エヴァンズの秘書さん、ご意見どうもありがとうございます。確かにご指摘の記述は人によって受け止め方の幅が出てくる可能性があり、特に前半の記述はやめておいた方がいいですね。民謡については元がCDアルバムの一曲として成立したわけではないので、一筆補足してみたわけです。以下の文ならあいまい性はなくなると思うのですが、どうでしょうか。でも、この補足事例は特記する必要もないかもしれないので、反対ならば無くてもかまいません。

なお、元がCD発売などではなく口承で伝わった民謡などは、『』でも許容されます。例：『おてもやん』・『蛍の光』--みしまるもも（会話） 2016年5月22日 (日) 00:54 (UTC)

コメント　みしまるもも様、修正いただきありがとうございます。修正内容に異存はありませんが、例示されている『蛍の光』はスコットランド民謡『オールド・ラング・サイン』に稲垣千穎が日本語歌詞を付けたもので、「口承で伝わった民謡」の例としては適切ではないと思います。かといって『オールド・ラング・サイン』はそのタイトルが一般的とは言い難いです。『グリーンスリーブス』（イングランド民謡）・『一週間』（ロシア民謡）・『ロンドンデリーの歌』（アイルランド民謡）・『もみの木』（ドイツ民謡）などに変えられてはいかがでしょうか。この中では『グリーンスリーブス』が最もポピュラーではないかと思います。よろしくお願いいたします。--エヴァンズの秘書（会話） 2016年5月22日 (日) 21:29 (UTC)

コメント　エヴァンズの秘書さん、ありがとうございます。ご指示のように当該部の例を変えておきました。それから、冒頭2行目のところで私の勘違いがありましたので「作品番号」に修正し、あとは事例の作品に内部リンクを付けました。これらの点を異動した改訂案をガイドラインに反映いたします。Wikipedia:表記ガイド#かぎ括弧の方もこれに準じて「比較的長大な作品」という箇所を変更いたします。ご意見をいただいた皆さま、どうもありがとうございました。--みしまるもも（会話） 2016年5月23日 (月) 00:46 (UTC)

人名における旧字体記載について

Wikipedia:コメント依頼/60.35.30.54ほか関連の話題です。Wikipedia:表記ガイド#漢字には、「歴史的文書の引用と固有名詞の表記に際しては、常用漢字以外の漢字を使用してよい場合があります」「旧字によるものと常用漢字によるものと2通りの表記が可能である場合については、どちらを正式名称とすべきかについてはまだ議論がまとまっていません」とあります。これを逆手にとってかどうかは分かりませんが、件のコメント依頼の可変IPユーザーの方が、「1945年以前生まれは1945年までの法的な正字体（での記載が妥当）」と主張し、曖昧さ回避ページにおいて、パイプの裏技とTemplate:Langのzh-Hant（中国語繁体字用）を使って、旧字体をわざわざ盛り込む編集を続けています（ [[川越藤一郎|川越 {{lang|zh-hant|藤}}一郞]]のような感じで。編集の例として[16]、[17]など）。繁体字用であるzh-hantを使うのは、「微妙に字体が違う」からと繁体字では無く旧字体に使うものだと解釈しているようです。

このような件について、人名に関する旧字体記載はどの程度まで許容するべきでしょうか。ただ、件の方は「1945年」を境目と主張されていますが、国立国会図書館の漢字解説ページによれば、当用漢字導入の際の「簡易字体」告示は1946年11月と1949年4月で、1945年ではないですし、そもそも生年・生存年代によって字体を変えるという基準はこちらでは示されていないわけですし、パイプの裏技を用いてまで旧字体記載リンクを付ける必要性があるのかどうか…。--松茸（会話） 2016年5月19日 (木) 14:05 (UTC)

コメント パイプの裏技→パイプ付きリンクとしてコメントします。基本的に信頼できる情報源に記載されている内容が正式名称となるでしょう。それに基づくパイプ付きリンクは問題ないと思います。ちなみに人の名が当用漢字に制限されたのは1948年からのようです。姓にそのような制限はありません。--Waiesu（会話） 2016年5月19日 (木) 15:01 (UTC)

「、」「。」の強制は妥当か？

表題の通りです．過去にも議論はあったようですがどうも決定的な根拠が見つかりません．直近のものは「Wikipedia‐ノート:表記ガイド/過去ログ10#特定分野の記事において、句点の代わりにピリオドを使用することを許容すべきか」でその前が「Wikipedia‐ノート:表記ガイド/過去ログ8#日本語の読点について」でしょうか．分野によっては（特に数式を多用するような分野だと）「、。」はほとんど全く使われないですから，「、。」の強制は適当ではないと思います．例えば東北大黒木玄氏のウェブサイトには『数式を多用する文書では「、」「。」を使わない。』と書かれています．

別にそのような分野で「，．」あるいは「,.」を強制しようとかいうわけではなく，（微分の d やかんすうの表記のように）各編集者がある程度自由にやればいいのではないかと思います．まあ1つの記事内（あるいはセクション単位）では統一されていた方がいいかもしれませんけど．それとこれらの記号類の書き換えだけの編集も推奨されないでしょうから基本的には新しい記事に対してということになりますが．

それで，何がしたいかというと，Wikipedia:表記ガイド#句読点では『原則として句点は「。」、読点は「、」を使い、「，」「．」（全角）「,」「.」（半角）は和文中に使わないでください（欧文においては「,」「.」（半角のカンマおよびピリオド）を用いることとします）。』となっていて，Wikipedia:スタイルマニュアル#日本語表記では『句点は「。」を、読点は「、」を用います。』となっていますが，これらをカンマ・ピリオドも許容するように書き換えられないかと思っているのです．

表記ガイドの初版では既に『句点「。」や読点「、」・中黒「・」などをまとめて約物（やくもの）という。約物は縦書き・横書き両方に対応するものを使うのを原則とする。』および『句点は「。」、読点は「、」を使い「，」「．」を使わない。』と書かれています．もっと古いのだとこれでしょうか．がなぜそのようなガイドができたのかは分かりませんでした．ウィキペディアは横書きで読まれますしどこか別の縦書きの文書に引用されるにしても句読点は変えるなり横書きのまま埋め込むなりすればいいじゃないかと思うのですが．（そもそも欧文（単語）や数式が入ってる時点で縦書きとは相性が悪いわけですが．）

なお，カンマ・ピリオドが一般的な理由の一つは，一つの文章の中でカンマ・ピリオドと「、」「。」が併用されるのが変だからですが，カンマ・ピリオドに全角を用いるか半角を用いるかは人によるようです．(2016-05-10)

（以上少し前に書いて置いておいたものですがそのまま投稿します．）新規作成 (利用者名) （会話） 2016年6月8日 (水) 13:09 (UTC)

コメント多人数で同じ記事を編集することもある（というか、それが前提）ので、「表記の統一を強制したい」という人が出るのは理解できます。しかしまあ、実際にその記事で十分な、一定以上の、有益な編集をしている人が複数いて、その当事者同士で話し合うならともかく、その記事にほとんど貢献していない人がやってきて「、」「，」を書き換えていくだけの編集というのは、いい印象は持ちません。過去の議論でも同じようなことを表明サれている方が複数いらっしゃいますが、そんな編集は非生産的です。もしもそのことによって「十分な、一定以上の、有益な編集をしている人」の編集意欲がいくらか削がれるとしたら（そういう気持ちはわかります）、利益と損失を天秤にかけると損失のほうが大きい。私は「執筆者の意欲を減衰させてまで表記の統一に拘ること」には共感しません。--柒月例祭（会話） 2016年6月8日 (水) 13:21 (UTC)

コメント それを言い出したらきりがないというか、表記ガイドが成り立たないと思います。

ある分野では「キログラム」とか「メートル」とう日本語表記は見慣れないから「kg」とか「m」を積極的に使って良いことにしましょうとか、西暦より元号を使いたいから年表記の原則を廃止しようとか……そして書式の優先順位を決めずに「好き好きの表記で書いてください」となってしまうと、別の人が編集する度に役物が句読点になったりカンマ、ピリオドに変わったり、年表記が西暦になったり元号になったり（表記の書き換えだけの編集がよく思われないのは周知のことなのでとって付けたような申し訳程度の加筆修正の応酬が延々繰り返されると）面倒この上ないので表記の優先順位はできるだけ決めてあるほうが良いと思います。

冒頭の説明に「ウィキペディア全体の表記の一貫性を目指し、コンピュータ上で作られる文書であることに配慮しながら、印刷物の慣行に近づける意図があります。記事執筆の際は、できるかぎりこのガイドラインに従うことが推奨されます。ただし、このガイドラインはすべての記事に絶対に適用しなければならないものではありません。ここに掲載されている表記法と異なる表記を分野ごと、記事ごとに使用する場合、関連分野のウィキポータル・ウィキプロジェクトや、個別記事のノートで合意形成をし、合意事項をわかりやすい形でまとめておくとよいでしょう。」とあり、その趣旨に沿って判断・対処すればまず問題ないでしょう。--ディー・エム（会話） 2016年6月8日 (水) 14:43 (UTC)

コメント基本的には、どのような書き方をするにも強制力のある根拠はないと考えます。背景を知る上で[18]というのを見つけました。

まず、ウィキペディア日本語版では、「強制」は現在もされておらず、「統一」が図られている、と理解しています。少なくとも書き手がピリオドやカンマを使うのは自由だけど、統一したい人が、表記ガイドに従って統一している。統一のためのコストを下げるために句読点にしてくれる方が助かるし、揃えてくれないかとお願いするのはいいけれども、書き手の側に「強制」するのはやりすぎだと思ってます。

ウィキペディアの表記ガイドの類では、「、。」を用いるとされ、その後幾度か議論にはなったけれども覆すには至らない程度に同意があった、あるいはカンマやピリオドへの移行や併記への移行を認めるだけの合意は得られなかった、というのが「根拠」でしょう。「、。」以外を用いるとか、複数の表記法を共存させるという選択肢もあるけれども、それではなく、コミュニティは「、。」による統一を支持している。なので、根拠がどうとか、強制が妥当か、とかいう問いの立て方をされるとしたら、合意が根拠であり、強制はされておらず、統一は妥当だと思います。

手続き論的なところとか、「、。」側の妥当性を問うとかではなくて、あらためて（表記ガイドの過去ログを引き継ぐ形で）合意を取り直そう、合意を探るとしたらどのようなものが好ましいか考える、ということなら、検討の余地はあると思います。難点としては、その項目にきちんと貢献している人同士で使いたいスタイルが食い違った時に解決が難しくなることが挙げられるでしょうか。執筆者意欲に関しては、書くところは書く側の問題として自由、しかしその後の統一については、個人の「執筆」から離れた話、ウィキペディア全体の話として、区別しないと、と思います。

個人的には、百科事典の記述は数式を用いた論証ではなく、歴史や概念を言語により説明するものとして、「カンマ・ピリオド」よりも「カンマ＋句点」または「句読点」による統一が好ましく、縦書きへの変換の容易さから句読点を支持しますが、他の書き方でも強く反対はしません。--Ks aka 98（会話） 2016年6月10日 (金) 07:48 (UTC)

みなさま，コメントありがとうございます．私のはじめのコメントの「強制」は「統一」と書いた方がよかったかもしれませんがまあそれはいいとして，思ったほど否定的な意見が出ていなくて驚きました．私ももちろん無意味な表記の書き換えだけの編集はよく思っていなくて，表記ガイドの役割の一つはそれを防止することだと思っていますが，確かに「その項目にきちんと貢献している人同士で使いたいスタイルが食い違った時」は難しいですね．

ただ一点気になったのは，Ks aka 98さんの最後の一文で，数式は論証のためだけに用いるものでは全くなく，「歴史や概念を言語により説明する」ときに必然的に使われます．新規作成 (利用者名) （会話） 2016年6月16日 (木) 07:53 (UTC) 微修正．新規作成 (利用者名) （会話） 2016年6月16日 (木) 07:57 (UTC)