コンテンツにスキップ

「Wikipedia‐ノート:表記ガイド」の版間の差分

ページのコンテンツが他言語でサポートされていません。
削除された内容 追加された内容
Waiesu (会話 | 投稿記録)
1,900行目: 1,900行目:


*{{取り下げ}} 議論を終了します。ありがとうございました。--[[利用者:Waiesu|Waiesu]]([[利用者‐会話:Waiesu|会話]]) 2016年7月7日 (木) 16:30 (UTC)
*{{取り下げ}} 議論を終了します。ありがとうございました。--[[利用者:Waiesu|Waiesu]]([[利用者‐会話:Waiesu|会話]]) 2016年7月7日 (木) 16:30 (UTC)

== 著作物名の約物についての補足 ==

今年の5月に改訂が済んだ[[Wikipedia‐ノート:表記ガイド#著作物名について]]からの補足になりますが、あえて[[約物]]を付す必要性のないケース(リストの羅列やテンプレートInfobox内の表題)にわざわざ鉤括弧を付けていらっしゃる方がいるようなので、無用なトラブルを避けるために、そのことに関して一筆補足を加えておきたいと思います。

例えば、[[Template:Infobox Film]]や[[Template:基礎情報 書籍]]内で映画や小説のタイトル名を入れる場合、他の語句との区分の必要性は発生していないわけで、こういったケースには通常は約物類は付けないのが、表記の使用法、ひいては書誌表記の通例となっています。これは世に溢れている映画パンフや本の見出しや目次、[http://ci.nii.ac.jp/books/]、[http://iss.ndl.go.jp/]をご覧になればお判りになると思いますが、作品名に余計な記号(鉤括弧)を付けないことが妥当な記載法となっております。本来、約物とは必要にかられて始めて使用する類の'''記号'''ですから、いらない所では付けないのが日本語表記の常識的な使い方であり、多くの現場で実際に行われている慣習です。

これは理由なくそうなっているわけではなく、「純粋な作品名」を記載しなければ、誤解や間違いの元になるためです。こういった、文章内ではなく単語同士の区別の記号のいらない場所において『』を付してしまうと、その'''『』込みの作品名'''だと混同されるため(稀ですが、そういうものもあります)、'''「純粋な作品名」以外の記号'''は付けないことになっているわけです。

このような一般的な常識中の常識のことまで、表記ガイドにいちいち書き加えて反映しなければならないWikipediaの現状には本当に疲れてしまうことですが、このサイトの事典上では様々な方が誰でも参加していらっしゃいますので、一応基本の約物というものの使用の妥当性を明記しておき、約物が強制荒らしの道具に使われないよう、このガイドラインの冒頭あるいは最後に以下のような一筆を加えたいと思います。
{{Quotation|*作品リストや、[[Template:Infobox Film]]・[[Template:基礎情報 書籍]]などのテンプレート内のタイトル名のように、他の語句との区別が生じていないケースでは、特に括弧類を付す必要はありません。}}
これでも、どうしても付けたい方はいるとは思いますが、一応は約物の基本ですので、ここでも多くの方が実際に採用している慣習をガイドラインに反映させておきたいと思います。何かご意見があれば承ります。

なお、楽曲名に関しても、[[Template:Infobox Single]]と[[Template:Infobox Album]]は別個のテンプレートに明確に分けられて「○○のシングル」「○○のアルバム」という説明も直下にあるので、余計な記号をタイトル名に付す必要はないと思いますが、ローカルルールでそう決まっているようですので、今回この楽曲のケースにはタッチするつもりはありません。

2016年10月12日 (水) 01:38時点における版

Archive過去ログ

過去の議論

Wikipedia:表記ガイドは、Wikipedia:日本語表記法、Wikipedia:日本語環境を引きついでいます。統合前の議論については、以下のそれぞれの場所をご覧下さい。統合後の過去ログは右側のサブページをごらんください。


検索できるのは、統合後の (= サブページ化された) 過去ログのみです。

このページでは SpBot による過去ログ化が行われています。解決済みの節に {{Section resolved|1=--~~~~}} というテンプレートを設置して過去ログ化を提案すると、その節は 7 日後に過去ログ化されます。

単位の片仮名表記

現在、単位の節では「単位は原則として片仮名・漢字」となっていますが、これには何か合理的な理由が存在するのでしょうか。個人的には「cm」「kg」を「センチメートル」「キログラム」に直されるのは鬱陶しいことこの上ないのですが…--Ltsc2335会話2012年11月10日 (土) 23:34 (UTC)[返信]

確かにそうなっていますが、それに続けて「単位がその項目内でリンクとなっており、リンク先に説明がある場合」は「アルファベット(半角)などによる単位記号を用いることができます」となっているのですから、大した支障はないのではないでしょうか。単に初出時に「全長300 [[メートル|m]]」のようにしておけば、その後は「m」とだけ書いてもこの規定上は問題ない訳ですから。--Tam0031会話2012年11月11日 (日) 12:35 (UTC)[返信]
それならば、文章を少し変えたいと思います。今の文章では、積極的な書き換えを推奨しているように読めてしまいますので。「原則として」という表現を削った上で、表記例の「m → メートル」などを修正しても構わないでしょうか。--Ltsc2335会話2012年11月11日 (日) 13:42 (UTC)[返信]
反応遅くなりすみません。具体的な改定文面案があれば何らかの助言ができるかもしれません。--Tam0031会話2012年11月13日 (火) 14:05 (UTC)[返信]
とりあえず、次のような案を提示します。--Ltsc2335会話) 2012年11月15日 (木) 07:49 (UTC) 一部修正--Ltsc2335会話2012年11月16日 (金) 04:07 (UTC)[返信]
  • 単位は片仮名・漢字、またはアルファベット(半角)で書きます。
    • アルファベット表記の場合は次のようにします。
      • 項目内で初出の単位には、その単位の項目への内部リンクを設けます。
      • 物理単位(半角)と数値(の数字)(半角)との間には半角スペース1つ(TeX表記する場合は「\,」)を入れます。
    例:(長さ) 1メートル または 1 m ・(角度) 30度 または 30 °
  • できるだけSI単位系メートル法を含む)を用います。
    • 慣例ある分野では尺貫法ヤード・ポンド法などを用いることができます。
      • この場合でも、できるだけSI単位系での換算を併記します。
  • 温度は、摂氏度またはケルビンを用います。
    • 摂氏30度を30 ℃とすることもできます。

Wikipedia:記事どうしをつなぐ#内容に関連するリンクだけを作成というガイドラインがあり、「項目内で初出の単位には、その単位の項目への内部リンクを設けます」はそれと矛盾しますので反対いたします。単位を記号で書きたいがため、あらゆる項目での初出に内部リンクを設けるのは本末転倒と考えます。--立花左近会話2012年11月15日 (木) 11:16 (UTC)[返信]

その場の流れで改定案を上げてしまいましたが、私は別に表記ガイドを改定したいわけではないのです。ただ、「単位は原則として片仮名・漢字」ということに対する合理的な説明がなく、過去ログにもこれに関する議論がなかったので疑問に思っただけなのです。何か理由があるのなら教えていただけないでしょうか。--Ltsc2335会話2012年11月15日 (木) 12:15 (UTC)[返信]
私も過去ログを見ましたが、理由は分かりません。必要とお考えなら、単位を内部リンクを設けずにアルファベット表記できるように提案してはいかがでしょうか。しかしながら、これまで長年にわたり改訂の提案もされずに残ってきた箇所であり、多数の記事がそれに従って表記されているわけですから、提案する場合は広く告知をした上で議論し決定すべきではないかと思います。私自身は、現段階ではアルファベット表記の賛否は保留します。--立花左近会話2012年11月15日 (木) 13:13 (UTC)[返信]
そこまでして内部リンクを忌避する必要もないと思います。単位は記事の内容に十分関連していると思いますよ。私は、Ltsc2335さんの改定案でよいと思います。--Tam0031会話2012年11月15日 (木) 13:57 (UTC)[返信]
反対 例えば建物の記事に高さが書かれていたり、河川の記事に長さが書かれていたりしたとして、それらの単位がどう記事の内容に関連しているのでしょうか。私は今回の改定案には明確に反対いたします。--立花左近会話2012年11月15日 (木) 15:04 (UTC)[返信]
立花左近さんはWikipedia:記事どうしをつなぐ#内容に関連するリンクだけを作成の内容に少しこだわり過ぎではないでしょうか。ベクレルとかパスカルとかアンペアとか、いろいろな単位が使われるときに、その単位の記事にリンクしておくことは読者の理解を助けるではないですか。誰もが単位を見ただけですぐに理解できるわけではないのです。現状広くみられる、年月日を何でもかんでもリンクしているのはやりすぎだと思いますが、単位をリンクにするのは読者の役に立つことだと思います。原則リンクするというのが気になるならば、リンクを推奨する文章でも構わないと思います。--Tam0031会話2012年11月15日 (木) 16:23 (UTC)[返信]
コメント メートルとかキログラムといった義務教育レベルならまだしも、高校以上の(選択・専攻してないと学ばないような)単位や接頭辞、ヤード・ポンド法や尺貫法、過去の単位系などについては、「原則リンク必須」に近いレベルが望ましいでしょう。--氷鷺会話2012年11月15日 (木) 16:42 (UTC)[返信]
コメント 以前、/過去ログ2#単位の前に半角スペースを入ると文章が間延びするので反対ですで(議論から半年ほど遅れて)書いたのですが、文章中では単位に記号を使用しない、数字と単位の間には空白を入れる、というのは欧文で一般的なルールなので、英語版等を参考にしたのではないかと思っています。ただし、実際の経緯は確認していません。
単位については、文脈上明らかであれば、記号を使用したほうが読みやすい場合もあるはずです(その際に内部リンクを条件とするのはおかしい、というご指摘はもっともだと思います)。
ただ、これも以前に書いたのですが、スクリーンリーダー(音声ブラウザ等)に配慮し、記号の使用を避けている場合があるようです(たとえば秋田県湯沢市京都府向日市三井住友銀行など)。なお、現在のスクリーンリーダーの対応状況は把握していません。漢字かな交じり文がちゃんと読めるソフトなら、単位記号を読むのは難しくなさそうですが……。 --KAWASAKI Hiroyuki会話2012年11月15日 (木) 15:31 (UTC)[返信]

コメント項目内で初出の』の部分について、反対します。スクロール0回で済むサブスタブならまだしも、記事の規模に関わらずそのようなことを書いてしまっては、2回目以降のリンクを(重複リンク禁止などと言いながら)削るような輩も出てきます(今も居ますが)。ごく基礎的な義務教育レベルの単位を除き、基本的には単位は「毎回」、あるいは「随所に」(読んでいる途中でリンク箇所を探さなくても済む程度に)リンクを張るべきだと考えます。--氷鷺会話2012年11月15日 (木) 16:51 (UTC)[返信]

前述の通りアルファベット表記の単位にリンクを設けるのをルーチン化することそのものに反対ですが、念のため。氷鷺さんのご提起されたWikipedia‐ノート:内容に関連するリンクだけを作成#重複リンクのガイドラインの議論は中断してしまったようですが、こちらでそれよりも緩い基準を設定することにも(アルファベット表記の単位限定とはいえ)反対いたします。また、スクリーンリーダーへの配慮の可能性があるとすれば、アルファベット表記の単位の使用の可否は、より慎重に議論すべきと考えます。これは提案中の段階に過ぎませんが、Wikipedia:アクセシビリティ#リンクというのもあります。--立花左近会話2012年11月16日 (金) 01:21 (UTC)[返信]

コメント スクリーンリーダーを考慮しないで済むのであれば,アルファベットの単位表記は導入してもいいと思います。次に文案についてですが,初出の~の内部リンクの件については除去を要請します。単位系の記事とかで内部リンクを貼るというのであれば理解はできますが,まったく関係のない記事で単位にわざわざ内部リンクを貼る必要はそもそもないでしょう。また,慣例的にSI単位系と違う単位を用いているのは,すでに紹介されている2つだけではないので,「など」の文言を入れて幅を持たせた方がいいです。例えば,栄養学の分野であれば,普通にカロリー(cal)を使いますから。--かげろん会話2012年11月16日 (金) 03:03 (UTC)[返信]

「初出の~」については反対意見が多いようですので、除去しておきます。--Ltsc2335会話2012年11月16日 (金) 04:07 (UTC)[返信]

コメント 単位の記号表記が自明かどうかは文脈によりけりだと思いますが、説明が必要な場合は“V”より、「V(ボルト)」や「V(ボルト)」と単位の名称を本文中で記述するほうが分かりやすいと思います。いかがでしょうか。 --KAWASAKI Hiroyuki会話2012年11月16日 (金) 08:23 (UTC)[返信]

コメント 私もこのような単位を用いる記事を多く編集している立場としては個人的には「cm」「kg」を「センチメートル」「キログラム」に直されるのは鬱陶しいは全く同感ですが、内部リンク云々については各々の記事の事情に応じてリンクを行う、行わないを臨機応変に選択できる余地は残すべきと考えます。SI単位もなるべく用いるのが望ましい程度で、例えば華氏なども文脈によっては使用を妨げるべきではありません。--As6022014会話2012年11月20日 (火) 10:25 (UTC)[返信]

HTML5 化に伴うruby要素許容の提案

「読み仮名には丸括弧()を用い、<ruby>……</ruby> は使わないでください。」という文言について、Template‐ノート:ルビにおいて提案をしていますのでぜひご覧ください。MediaWikiの出力がXHTML 1.0からHTML5に変更された今や、rubyを禁止する技術的な制約はなくなり、少なくとも現状{{ルビ}}を呼び出しているような用法はruby要素に切り替えるべきです。表記ガイドがこれに矛盾するので変更を提案するものです。 とはいえ表記ガイドとして積極的にrubyを使えと主張するものではなく、読み仮名の表記法は慣例通り丸括弧を原則としつつも、執筆者がルビの方が適切だと思う場合は必要に応じて{{ルビ}}を使用しても構わない、とガイドすることになるかと思いますが、具体的な使い分けはケースバイケースになるかもしれません。私見での一例(現状{{ルビ}}を使っている記事からの例)はリンク先にてあげております。ご意見を頂戴できれば幸いです。--朝彦会話2012年12月28日 (金) 19:02 (UTC)[返信]

同じ意味で複数の漢字が使われる場合

「漢字」節には「漢字の字体は、原則として常用漢字表に従います。」と記述されていますが、厳密にはこの表現だと、同じ文字に複数の字体がある場合だけを指していて、「長編」と「長篇」のように自体の違いではなく文字そのものが違う場合までは規定していないことになります。そこで、「漢字の字体は、原則として常用漢字表に従います。同じ意味で複数の漢字が使われる場合もこれに準じます。」とすることを提案します。なお、Wikipedia:記事名の付け方でも同様の提案をしています。--アルビレオ会話2013年1月19日 (土) 20:40 (UTC)[返信]

コメント 「編」と「篇」は意味が違うという論[1]もあるようで、全く同一の意味で用いられる別の漢字というのは相当まれだと思います。単に「同音の漢字による書きかえ」を意味するのであれば積極的には賛成いたしかねます。「銓衡」→「選考」のように慣用が久しいものについてはまだしも、「毀損」→「棄損?」、「激昂」→「激高?」、「鳥瞰」→「鳥観?」のような稚拙な書き換えを潔しとはしない編集者も多いと思われ、無用の編集合戦を招くだけに思えます。--Damena会話2013年1月31日 (木) 05:54 (UTC)[返信]

「ハイフン」について加筆を提案します

「ハイフン」について、現状を追認し、ルールを広く周知するために、以下の加筆を提案します。

「ハイフン」

;(現行)

アルファベットのハイフンには、いわゆる半角マイナス(ハイフンマイナス)「-」を用います。いわゆる全角ハイフン(または2分ダッシュ)「‐」は用いないでください。

  • 期間を表すときには、ハイフンを用います。
    例: 1990年 - 1999年

(提案)

アルファベットのハイフンには、いわゆる半角マイナス(ハイフンマイナス)「-」を用います。いわゆる全角ハイフン(または2分ダッシュ)「‐」は用いないでください。

  • 期間を表すときには、ハイフンを用います。
    例: 1990年 - 1999年
  • 原語にハイフンが入る人名を片仮名書きする場合には、=(全角等号)に置き換えます(#日本名以外の人名)。
  • 鉄道関係の事項を片仮名書きする場合は、原語にハイフンが入る箇所でそのままハイフンを用いるべき場合があります(プロジェクト:鉄道も参照してください)。

万一、現状認識に誤りがあるようでしたら、具体的にご指摘ください。よろしくお願いいたします。 また、文章表現上の改善提案も歓迎します。--山田晴通会話2013年3月16日 (土) 12:24 (UTC)[返信]

コメント さらにシンプルにしてもよいのではないでしょうか。
;
  • 期間を表すときには、ハイフンを用います。
    例: 1990年 - 1999年
  • 原語にハイフンが入る人名の片仮名書きについては#日本名以外の人名も参照してください。
  • 原語にハイフンが入る鉄道関係の事項の片仮名書きについてはプロジェクト:鉄道も参照してください。
いずれにしても正確な内容を知るには結局リンク先をあたらなければならないので、ここでは簡潔にとどめてもよいのではと思います。
また一般論として、同じことを複数の箇所に記載すると、あとで改訂が必要になった場合に手間や取りこぼしの可能性が発生すると思うためです。--Rinopo会話2013年4月7日 (日) 04:21 (UTC)[返信]
コメント 鉄道以外の分野でも、原語にハイフンが入る固有名詞等があるので、ことさら鉄道に言及するのは適切だとは思いません。
;
  • 個人名以外で、原語にハイフンが入る名称等の片仮名書きについては各分野のウィキプロジェクトでの合意、(ウィキプロジェクトでの議論がなければ)学術用語や慣習に従ってください。
とするのはどうでしょうか。
ただ、現実問題としては、学術用語はハイフンの表記は対象としていなそうで、議論もあまりなされていないと理解しています。ぱっと思いついたコーシー=シュワルツの不等式南部陽一郎を見るとハイフンの扱いは統一されていないようなので(それぞれの分野で慣用が確立しているわけでもないと思います)、むしろ人名に限定せず、原語でのハイフンは原則として全角等号とする方向で考えたほうがいいのかもしれません(この場合は鉄道関係は例外になるので、言及する必要があると思います)。 --KAWASAKI Hiroyuki会話2013年4月20日 (土) 11:04 (UTC)[返信]

丸数字の使用基準作りの提案

提案 前議論にて丸数字の使用基準が曖昧という話が出ました。確かにアラビア数字、漢数字、ローマ数字にはそれぞれ使用例や例外ケースなどが書かれていますが、丸数字に関しては「丸の中に数字が入った丸数字は使用せず、代わりに (1)・(2)・(3) を使用します。」という文言だけで、丸数字を使うか否か参考にならないと思います。丸数字を全面的に禁止し(1)・(2)・(3)で代用するのであれば、その旨を記すべきだと思いますし、他の数字類と同じく例外が認められるのであれば具体例を記すべきです。私個人は、数字を丸で囲むことに大きな意味(代用数字ではカバーできないほどの意味)がある場合を除き、全面的に(1)・(2)・(3)での代用もしくはただ単にアラビア数字の1・2・3で統一し、丸数字は禁止しても構わないと思います。皆さんのご意見をよろしくお願いします。-Elma会話2013年6月16日 (日) 12:59 (UTC)[返信]

賛成 そうですね。基本的には禁止ということで、例外を具体的に列挙する形にしましょう。ただの番号を通常のアラビア数字に代替する場合は但し書きは書かない、そして例外の場合は必ず「①(丸1)」などと併記または但し書きをするということで。個人的には
  • 丸数字という「文字」そのものに言及している場合。「丸数字」の記事など。
  • 固有名詞で、番号などではなく意図的に丸数字を使用している場合。読み方が「マルイチ」などと「マル」が入るものなど。(問題なく代替できる場合は括弧数字を使用する)
  • 規格、法令、巻次、ページなどで、通常のアラビア数字、漢数字などと区別して丸数字が使われている場合。(問題なく代替できる場合は括弧数字を使用する)
  • その他。たとえばアスキーアートやギャル文字などの事例で使用される場合や、推理小説の暗号で丸数字が特別な意味を持つ場合など。
あたりは例外で良いと思います。--氷鷺会話2013年6月16日 (日) 13:22 (UTC)[返信]
コメントご意見ありがとうございます。私自身「具体的な例外」が殆ど思い当たらなかったので例外を挙げていただき感謝します。ガイドラインに直接関わる編集ですので、お知らせなどで告知したいと思います。他のウィキペディアンの皆様のご意見もよろしくお願いします。--Elma会話2013年6月16日 (日) 14:28 (UTC)[返信]
コメントただの番号を通常のアラビア数字に代替する場合は但し書きは書かない、←これを適用した場合、問題なく代替できる固有名詞において、丸数字かどうかの判別が不可能になりませんか?()付き数字に代替した場合の但し書きも必要だと思うのですが。--相田佳彦会話2013年6月16日 (日) 20:12 (UTC)[返信]
コメントそうですね。公の情報が丸数字であるものをアラビア数字あるいは(1)に代替した場合は節の冒頭などで「本来は丸数字が使用されているが当記事ではWikipediaのガイドラインに沿ってアラビア数字(あるいは(1) )で代替する」という旨の但し書きがあったほうがいいでしょうね。ただ単に数字(カウントや丸数字を意識していない番号付けなど)を意味する場合は但し書きは必須ではなくてもいいと思います。--Elma会話2013年6月17日 (月) 14:43 (UTC)[返信]
コメント - 丸数字のものを括弧付き数字に代替した場合に、WP:JPEによる事情を本文に書く(進撃の巨人#各話リストのようなやり方)というなら反対します。その方法は自己言及的で、読者視点としては避けたいところです(編集者への対応ならコメントアウトで示す方法があります)。そもそも、丸数字かどうかを判別する必要があるような案件こそが所謂例外事項にあたるような事例であって、ただの番号で例外とみなされないような「問題なく代替できる」場合だと、丸数字とそれ以外を判別する必要も発生しないのでは。--ButuCC+Mtp 2013年6月17日 (月) 15:23 (UTC)[返信]
コメント 固有名詞において、例外を除いた場合に但し書きが必要あるか、無いのかについての議論だと考えますので、但し書きの記述方法(WP:JPEによる事情を本文に書くなど)については、とりあえず置いておきます。議論を戻しますが、例えば、ドリムス。(1)という記事において、上述の固有名詞の定義を適用すると、ここに含まれる丸数字の意味は一枚目のオリジナル・アルバムという順番を表す数字だと容易に考えられるため、()付き数字で表記し、本来の表記は~などという但し書きは必要ないというお考えでしょうか。--相田佳彦会話2013年6月19日 (水) 11:19 (UTC)[返信]
コメント氷鷺さんのコメントのその部分は例外に当たらない場合、すなわち元が丸数字であっても特に意味がないただの番号に過ぎない場合のことです。ですので丸数字がどうかを判別する必要がないわけです。--Wolf359borg会話2013年6月17日 (月) 16:26 (UTC)[返信]
私としては、こういうのも「信頼できる情報源」に準拠して判断すべきだと思うので、具体的事例をいちいち列挙していくのではなく、例外規定としては「信頼できる情報源(特にウェブ上の情報源)において丸付き数字の使用が一般的な場合」を例外とする規定が1つだけあれば良いと思います。--Dwy会話)(信じられない誤読をする人がいるので発言の表現を一部修正(下線部追加)--Dwy会話2013年6月17日 (月) 21:31 (UTC))[返信]
あくまで「ウィキペディア日本語版においての丸数字表記の取り扱い」の問題ですから、「信頼できる情報源(特にウェブ上の情報源)において丸付き数字の使用が一般的な場合」とは関係無い(それらの情報源で丸数字が使われていても、代替可能であれば括弧数字等にすべき)と思います。代表的な例外事例を列挙でよいでしょう。--Wolf359borg会話2013年6月16日 (日) 15:56 (UTC)[返信]
コメント それ(「信頼できる情報源」が丸数字かどうか)を基準に含めることには反対です。むしろ考慮すべきすではないでしょう。--氷鷺会話2013年6月16日 (日) 16:18 (UTC)[返信]
多数派の専門家たちが信頼できる情報源において「代替不能」あるいは「代替しない方が良い」という判断を示しているときに、たかが素人に過ぎないWikipediaの編集者の判断の方を優先させるべき理由はないと思いますが?--Dwy会話2013年6月16日 (日) 16:46 (UTC)[返信]
コメント その『多数派の専門家たちが信頼できる情報源において「代替不能」あるいは「代替しない方が良い」という判断を示している』が独自研究でなければ良いのですけどね。この意味が分かるでしょうか。要するに、丸数字の使用を原則的に避けることにしている専門家・情報源であれば、その判断は考慮に値するでしょう。しかし、丸数字の使用を特に問題視せず「当然のように使う」のかもしれない専門家・情報源であれば、その判断はウィキペディアンの勝手な想像・独自研究に過ぎないのですよ。それこそ結局『たかが素人に過ぎないWikipediaの編集者の判断』になってしまいます。--氷鷺会話2013年6月16日 (日) 17:02 (UTC)[返信]
丸数字の使用を特に問題視せず当然のように使う専門家の見解は、無視して良いということですか?それはおかしいでしょう。技術的制約が解消しつつある現在、そういう立場の人がいてもおかしくないですし、「信頼できる情報源」だと判断した以上は、そういう意見も当然(その勢力に応じて)尊重すべきです。丸数字禁止は何も不磨の大典というわけではないのですから。--Dwy会話2013年6月16日 (日) 17:39 (UTC)[返信]
コメント ここはウィキペディア日本語版における表記のガイドラインを定める話をしているのですが、話が逸れていませんでしょうか。丸数字の記事にWEBにおける丸数字表記の取り扱いの基準についての記述を書く話をしているわけではありませんし、WEBにおける一般的なルールを作ろうとしているわけでもありません。そもそも主張の内容が変わってきていませんか?最初はWEB上の信頼できる情報源で丸数字表記が一般的な場合を1つ示せば良い、ということだったはずです。それがいつのまにか多数派の専門家たちが信頼できる情報源において「代替不能」あるいは「代替しない方が良い」という判断を示しているという話にすり替わっています。つまり、丸数字表記の取り扱いに関する研究をしている専門家の多数派が発表している「代替不能」あるいは「代替しない方が良い」という判断、なるものを持ち出しているわけですが、それは存在するのでしょうか?ぜひ具体的に提示をお願いいたします。そういう多数派判断があれば参考にはなるでしょうから。しかし、それはウィキペディア日本語版の取り扱う記事や閲覧の事情を考慮したものでは無いはずです。それ1つだけではウィキペディア日本語版における表記のガイドラインになり得るわけがないのは解説するまでもないかと思います。--Wolf359borg会話2013年6月16日 (日) 22:23 (UTC)[返信]
私が言いたいのは、素人にすぎないウィキペディアンが2〜3人集まって、個人的な思い込みや嗜好であれこれ議論しても、将来の編集者を真に納得させるようなガイドラインはできないということ。ガイドラインを決めるなら、まず他の百科事典や学術論文等における「慣行」を充分調査して、それに準拠して議論を進めるべきです。そして、そういう「慣行」の調査を予め網羅的に行うのが難しい場合は、「例外は、個々の事例毎に、参考にすべき事例(=記事を編集するときに参考にした「信頼できる情報源」)に準拠して判断する」というガイドラインにしておくのが一番便宜に適うのではないかと言っているのです。--Dwy会話2013年6月17日 (月) 23:03 (UTC)[返信]
コメント 素人の個人的な思い込みを述べているのはあなたでしょう。「丸数字の使用を特に問題視せず当然のように使う専門家の見解」は考慮に値しません。「原則不使用」というルールの中での運用を考えているのですから、「普通に使用する」ルールの中での専門家の表現は考慮に値しません。そもそもそれは「専門家の判断」ですらないのですよ。あなたが架空の「専門家の判断」というものに囚われているだけの話で。本当にその専門家が表記について言及していない限り、それは専門家の見解でもなんでもないのですが、この点について、まだお分かりにならないのでしょうか。--氷鷺会話2013年6月18日 (火) 18:13 (UTC)[返信]
丸数字禁止はあくまで「原則」であって、金科玉条ではないと言っているのですが、わかりませんか?
丸数字を使わないことにしたのは、それがウェブ上のメディアでの一般的な慣行だからです。もしある特定の分野あるいは特定の事柄の表記において、ウェブ上のメディアでも気にせずに丸数字を使うのが一般的な慣行であれば(そういうことは滅多にないでしょうが、仮にそういうことがあった場合には)、ウィキペディアでもその慣行に従うのが当たり前です。
なお、私の主張は「専門家が(どのように判断して)どのように表記しているか『慣行』を調べて、その『慣行』に従え」というものですが、大事なのは「慣行に従え」の部分ですから、括弧の中の(どのように判断して)の部分が引っかかるなら、その部分は省いて考えて下さい。--Dwy会話2013年6月18日 (火) 22:52 (UTC)[返信]
コメント 上の話でもそうでしたが、そういう風に都合よく曲解してしまう方に対しては「禁止」とでも説明した方が良いのかもしれませんね。そもそも外部の慣行に従うのが当然というのもDwyさんの勝手な思い込みに過ぎません。記事内容にしろ表記にしろ一般とウィキペディアとで異なるものはいくらでもある訳で、要するに「慣行に従う」という単純な発想そのものが間違いです。--氷鷺会話2013年6月21日 (金) 16:31 (UTC)[返信]
メモ この位置にあったコメントは氷鷺さんのコメントに対する質問でしたので、適切な位置に移動させていただきました。--Wolf359borg会話2013年6月17日 (月) 16:26 (UTC)[返信]

(インデント戻す)氷鷺さんのご意見を支持します。ここで論じられているのは所詮ウィキペディア日本語版のローカルルールに過ぎず、専門家の見解は関係ありません。

仮に「専門家の慣行を調べて従え」とお考えなのであれば、ぜひとも調査結果をご披露ください。ここで決めているローカルルールが、「専門家の慣行」とやらに合致しているかもしれないし、合致していないかもしれない。当の「慣行」を確認できる文献も無い、今の時点では「専門家の慣行」を云々したとしても、「かもしれない」に過ぎない「素人の空想」以上でも以下でもありません。

さて、それではどんなものがあるか。個人的な関心も無いではないので、簡単にいくつか思いつくものを調べてみました。

国立国会図書館による書誌データ作成上の規則が公開されており、その一部に文字種の取り扱い基準と題するページで公開されている2012年1月以降の基準の「2. Unicode基本多言語面(U+0000-FFFF)内のコード値を持つ文字の取扱い」では

Unicode基本多言語面内のコード値を持つ文字でも、下記①~③のいずれかに該当する場合は、当該文字を使用しない。(中略)②Unicode基本多言語面内のコード値を持つ文字が、○や□で囲まれた合成文字である場合は、○や□の中の文字を( )、「 」で囲んだ形に置換える。 — 国立国会図書館による書誌データ作成上の文字種の取り扱い基準2012年1月以降

丸数字にある通り、丸数字はUnicode基本多言語面(U+0000-FFFF)の範囲に収録されていますが、国立国会図書館による書誌データ作成に際しては()[]囲いへの置き換えが規定されています。なおかつ、この置き換えを行った場合、日本目録規則適用細則の例えば「第2章 図書」では2.0.6.3項で上記基準に従うことを前提とし、

タイトルと責任表示に関する事項においては,数字は原則としてそのままの形で転記する。漢数字とアラビア数字等,情報源により表示の文字種が異なる場合,原則としてアラビア数字を記録する。表示の違いについては注記しない。その他の書誌的事項においては,数量や順序などを示す数字はアラビア数字とする。 — 国立国会図書館 日本目録規則適用細則 第2章 図書2.0.6.4項

としており、「表示の違いについても注記しない」「数量や順序などを示す数字はアラビア数字」としています。本件の発端となったエピソードの添え数字について関連する部分として挙げられるのは、同文書の「2.1.6 巻次,回次,年次等及び部編名」というセクションにある2.1.6.2(記録の方法)項でしょう。

所定の情報源に表示されている形で記録する。巻次等については,数字はアラビア数字を用いる。 — 国立国会図書館 日本目録規則適用細則 第2章 図書2.1.6.2項

国立国会図書館がその蔵書目録に対する検索サービスをウェブで公開しているのは言うまでもなく、そして日本で唯一の納本図書館として日本における全国書誌の専門機関であるのは無論のことです。

科学技術振興機構による科学技術情報流通技術基準SIST)事業の成果が公開されています。「学術論文の執筆と構成」と題されたSIST08では「5.構成要素の記載要領」の下位に「5.6.2 用字用語,記号等」「5.6.3 見出しの番号付け」「5.6.4 図・写真・表の番号付け」などがあります。「5.6.2」では

用字用語,記号,符号,単位,並びに学術用語及び学術的名称(動植物の学名,病名,化合物名等)の表記は,ISO等の標準化関連国際組織及び国内組織による基準に従う。 — SIST08

とあり、次の「5.関連基準」にJIS Z 8202シリーズ:2000が挙げられています。JIS Z 8202シリーズ:2000はやはりウェブで公開されており、日本工業標準調査会で閲覧することができます(検索語は「Z 8202」)。量及び単位-第0部:一般原則を見ただけですが、丸数字が用いられている(まして丸数字が原則)とは理解できませんでした。

同じくSISTの「参考文献の書き方」と題されたSIST02の「3.3 表記法」には、

3.3.1 言語及び文字
書誌要素は,そこで用いられている言語及び文字で記述することを原則とする。 — SIST02

とある一方で、次の「4.書誌要素の記述と構成」セクション配下では

4.3.5 雑誌の巻数・号数
(1)巻数・号数は,アラビア数字で統一する。 — SIST02

と述べられています。「そこで用いられている言語及び文字で」という文言から、丸数字が用いられた場合は従うことを求めていると理解できますが、丸数字が原則であるというのとは別のことです。

日本心理学会の学会誌投稿規程である2005年版 執筆・投稿の手びき<修正版>はその点明快であって、「1.4 数字・数式」において

1.4.1 数字 数を表示する場合は,原則として算用数字を用いる。 — 2005年版 執筆・投稿の手びき<修正版>

と明言しています。

これらは「専門家の慣行」の全量ではありえませんが、専門家集団ごとにブレがあるという傾向は推定できるでしょう。逆に、丸数字が原則というものはこの範囲には見当たりません(これは完全な不在証明ではなく、一定の範囲での限定的な不在証明であり、「全く存在しない」という全称命題とは異なります。しかし、同時に「丸数字が原則」という慣行が「存在する」という命題を立証するものでもありません)。したがって、実用的な水準で一貫性があり、各種の機器での表示・閲覧に支障が無いことに配慮されており、規格・法令など表記法と文書の体系性が関連している場合を例外とするなど、適切な例外が考慮されている限り、「丸数字を用いない」という原則にしたがった表記のガイドラインを採ることに何か問題があるかといえば無く、単に決め事の範囲でしかありません。こうした観点から、例外まで含めて現時点では氷鷺さんの案は(最善かどうかは分からないが)適切であると判断し、支持します。

さて、これらに限らず学会誌の投稿規程の類や各大学ごとの論文執筆のガイドラインなどは、「投稿規程」「文献参照法」などといった類の適切なキーワードにより多数が容易に発見できます。「ウェブ上のメディアでも気にせずに丸数字を使うのが一般的な慣行」であるような慣行を持つ専門家集団がいるのであれば、それは大変興味深い事柄であり、 ぜひともかかる専門家集団の慣行を示す文献をご提示いただきたいと思います。具体的な探索もせず、提示も出来もしないのにあれこれ言っているのだとすれば、それこそ「素人の空想」で議論に容喙しているに過ぎませんので、議論の妨げはお控え願います。なにより、そもそも原則を論じようとしているところで例外を先行させるのも意味が分かりませんし、記事を書かない人にとっては原則がどうなっていようが困りもしないのに容喙する意味がよく分からないのですが。--ikedat76会話) 2013年6月19日 (水) 14:04 (UTC)一部修正。--ikedat76会話2013年6月19日 (水) 17:19 (UTC)[返信]

ここでは、どのような場合に「例外」を認めるのかを議論しています。「原則」について長々と論じられても全く何の役にも立ちません。「議論の妨げはお控え願います」というお言葉を、そっくりそのままikdat76さんにお返ししましょう。
それから、ikdat76さんの頭の中には「読者」というものが全く存在しないようですね。ikedat76さんのご発言は、「記事を書かない読者の評価や要望なんかに耳を貸すつもりはないから、黙っていろ」と言っているように聞こえます。私からみれば、信じられないくらい独りよがりな態度と言わざるを得ません。--Dwy会話2013年6月19日 (水) 22:58 (UTC)[返信]
例外は原則に伴ってしか発生し得ません。したがって、例外を論じるのであればまず原則がどこにあるのかを考えなければなりません。したがって、原則がどこにあるかを確認する作業は例外の確定の上で、論理的に必須であり、だからこそ上のような投稿をしております。
原則であれ例外であれ、ルールを決めるのであれば「素人にすぎないウィキペディアンが2〜3人集まって、個人的な思い込みや嗜好であれこれ議論しても」意味が無く、「専門家の慣行」を調べて従うべきだ、という考えを表明されたのは何よりDwyさんご自身です。私が上に挙げた例は極めて限られたものであっても、いずれも専門家によるものですが「慣行」のような曖昧さの残るものではなく、明文規定のものばかりです。こうしたものを調査することは、何よりDwyさんご自身のお考えを尊重したものに他なりませんが、その調査結果について一言も言及が無いのは訝しいことです。
「「読者」というものが全く存在しない」と仰せですが、私は氷鷺さんの案に賛同を表明するにあたり「各種の機器での表示・閲覧に支障が無いことに配慮されており」という観点を含めており、失当と考えます。考慮漏れが存在するというのであれば、それは具体的にご教示いただきたく存じます。
お気づきでないようですが(記事を書かないから具体的に把握できないのでしょうが)表記ルールがいかに整備されたところで、表記ルールそれ自体が読者のためになるわけではありません。読者に届くのは書き手たちのアウトプットであり表記ルールではありません。書き手たちアウトプットを生成する上での補助を与えるのが表記ルールであり、書き手たちが実務上運用し得ないようなルールでは無意味です。もちろん、日本語をクリンゴン文字で書けとかそういう理不尽な表記ルールは論外です。私が申し上げていることも氷鷺さんの案も、せいぜい読者への配慮と書き手の実務との妥協点として実務的なものと言ってよいでしょう(上の例で言えば、SISTと日本心理学会を足して2で割った、とでも例えられましょうか)。それに何よりもここで問題となっているのはたかだかウィキペディア日本語版の表記ルールというローカルなルールに過ぎず、ウェブ上で?の理想的な表記ルールを定めることではありえませんし、そのような概念に「専門家」たちとって一致しえるものではありますまい。
さて、何よりも「素人」の考えを廃し「専門家の慣行」を推されたのはDwyさんご自身でしょうし、確かに数時間程度の調査結果でしかありません。しかしながら、私の報告に対し、当方に対する非難のみに終始されたようで残念でなりません。私の考えや調査結果などというものは、自覚しておりますが確かに素人のそれでしょう。であるならば、ぜひとも「ウェブ上のメディアでも気にせずに丸数字を使うのが一般的な慣行」であるような慣行を持つ専門家集団も含めて、ご自身の見識と調査結果に付きご教示いただけませんでしょうか。
なお、当方個人について云々することは議論と無関係ですので、Dwyさんは私の調査結果を無視していただき、ご自身の見識と調査結果について投稿をお願いいたします。当方個人についてさらに何か述べることをお望みであれば、Wikipedia:コメント依頼なりいずこかの適切な場所をご利用いただき、議論の妨げを生じさせないよう重ねてお願い申し上げます。--ikedat76会話2013年6月20日 (木) 10:59 (UTC)[返信]
  • コメント丸の中に数字が入った丸数字は使用せず、代わりに (1)・(2)・(3) を使用します。」から変える必要性を感じません。例外は「丸数字という「文字」そのものに言及している場合。「丸数字」の記事など」だけで良いと思います。ページ番号などに数字をまるで囲んだデザインがあったとしてそれを一つの文字だと思うのは妥当ではありません。大体マル123とかはコードがないわけです。--T6n8会話2013年6月20日 (木) 15:27 (UTC)[返信]
    • コメント丸数字にも文字コードはあります。でなければ、機種依存だろうがなんだろうが、表示できるわけがないのです。いい加減な理解で適当なことを言っても意味がありません。--ikedat76会話2013年6月20日 (木) 22:35 (UTC)[返信]
      • コメント落ち着いてください。T6n8さんが例に上げているのは123(百二十三)を丸で囲ったページ番号の表記の話だと思います。私の理解が正しければ丸50までしかなかったはずです。--Wolf359borg会話2013年6月20日 (木) 22:53 (UTC)[返信]

正直なところ、Dwyさんが何に対して異論を唱えているのかよくわかりません。

  1. 順序を表す数字であれば、○囲みに意味は無いので、数字だけを示せばよい
  2. 順序を表す以外に数字を〇で囲む用例はありうる(し、実際に存在する)ので、その場合には○囲み数字の使用を許容する
  3. 順序以外での○囲み数字の使用例を、許容される使われ方として列挙してみた

という論旨と理解していました。最初にDwyさんが異議を唱えられたのは3番目の点だったように解釈しています。「列挙が網羅的でないから意味がない」ということで良かったのでしょうか? 「列挙されているのが順序以外に有意な用例のすべてである」とは言われてないし「その他、〇で数字を囲むことが有意な事例では許容する」と容易に解釈しうるとおもうのですが。明言されていないのが不安ということであれば「その他、〇で数字を囲むことが有意な事例では許容する」と付記すればいいだけの話ですよね。--Cossy会話2013年6月21日 (金) 12:37 (UTC)[返信]

コメント実際の用例で該当する箇所があるため、本議論の推移を見守っています。札幌市営地下鉄#乗車料金の運賃表で、区分に「②区」があります。丸囲み数字は札幌市交通局発行の案内などにも使われておりますが、記事では丸囲みを使わないように「(2)区」と置き換えています。ここに関しては使用に問題がないようであれば変更を考えていますが、Cossyさんが例示した2番目にあたるものと考えており、これが採用されれば変更したいところではありますが。議論中の案件であることもありそのままにしておりますが、推移を見守りたいと思います。--HOPE会話2013年6月21日 (金) 13:00 (UTC)[返信]
コメント議論が白熱しているようですね。当初の提案は「丸数字の使用基準」を明確にすることです。前議論での経緯もあり、またHOPEさんの事例のようなケースも多く存在します。cossyさんも挙げられていますが、「丸数字は原則禁止としておくが、丸数字そのものに意味を有する場合については丸数字の使用を該当記事のノートページ等で検討をしてもよい」ということです。
実際、現状の表記ガイドでは丸数字と同じ文字化けの理由で、ローマ数字についてはアルファベットで代用することが決められています。これに倣って丸数字も代用を原則としてはどうかということです。ただし丸数字は多くの場所で使われており、また数字を丸で囲むことに大きな意味を持つ場合もあるため、例外を作って丸数字使用の基準を明確にしよう、ということです。まとめると
  1. 丸数字を使用せず代替文字で対応するケース
    対象の出典等で丸数字が使われているものの、その丸数字が単なるカウント・数字としての意味しか持たないもの(例えば本編とは別の口絵のページ数や、本の巻数など)
  2. 丸数字の使用を検討するケース
    対象の出典等で丸数字が使われており、その丸数字に固有の意味が含まれているもの(例えば丸数字を利用したボードゲームや、技術・工業的に丸数字が重要な意味を持つ場合など)
であり、丸数字の使用を検討するケースの例を何個か挙げて、ある程度の丸数字のガイドラインを提示できれば混乱も少なくなるのではないか、ということです。--Elma会話2013年6月21日 (金) 14:08 (UTC)[返信]
コメントまず具体例で判断するのは良いことですね。HOPEさんの示された例だと市の料金表ページに従って「マル2区」としておくので良いと思います。
話はそれますが、ローマ数字をアルファベットで書くのは代用ではなくて本来のやり方に従うということだと理解するほうが良いと思います。縦書きの活字を入れるときは、合字に対するコードポイントとして一定の意味はあったかもしれないけど、ローマ数字は本来アルファベットをならべるもので、横書きで考えるときは中途半端なまとめ文字は不必要です。--T6n8会話2013年6月21日 (金) 14:47 (UTC)[返信]
コメント どんな場合に「〇で数字を囲むことが有意」かどうかについては、様々な意見がありえます。一方の極端には「原文を忠実に転記することには常に意味がある」という見解があるでしょうし、反対の極端には「文字化けしてしまったら何の意味もありえないのだから、そういうリスクは常に避けるべき」という見解があるでしょう。私から見ればどちらにも一理あって、どちらが正しいとは言えないように思います。更に、その両極端の間に無数の立ち位置がありえて、それらの無数の立ち位置の一つ一つが(少なくともその論者にしてみれば)それなりの根拠と説得力を持っているはずです。そういう状況では、何を例外にすべきかを直接議論しても、将来の編集者を納得させるコンセンサスはなかなかできないような気がする。これが私の懸念です。だから、参考になりそうなメディアがどのように表記しているか「慣行」を調べて、その「慣行」に従うことにしようよと提案したわけです。
その意味で、上でikedat76さんが「慣行」を調べてくださったのは大変ありがたかったです。ただ、どのような「慣行」になっているかについては、ikedat76さんと、ikedat76さんの跡を追って検証してみた私とでは、かなり認識に違いがあります。
まず、国会図書館の「慣行」についてですが、こちらの検索結果を見る限り、実際にはikedat76さんのおっしゃるような運用にはなっていないようで、どちらかといえば「数字は原則としてそのままの形で転記する」を実行しているように見えます。大体、上で引用されている「下記①~③のいずれかに該当する場合は、当該文字を使用しない。(中略)②Unicode基本多言語面内のコード値を持つ文字が、○や□で囲まれた合成文字である場合は、○や□の中の文字を( )、「 」で囲んだ形に置換える」自体が、「下記①~③」とか丸数字使いまくりで、ちょっと笑ってしまいます。私もちょっと意外でしたが、国会図書館の人たちは「ウェブ上のメディアでも気にせずに丸数字を使うのが一般的な慣行」であるような慣行を持つ専門家集団かもしれません。
意外な結果に驚いて、ついでに科学技術振興機構と日本心理学会のサイトにおける「慣行」もググって調べてみました。こちらが科学技術振興機構の検索結果。こちらが日本心理学会の検索結果。どちらも丸数字を避けているようには見えません。
検索方法等に間違いがあるならご指摘いただきたいのですが、そうでないなら、元が丸数字の場合、書き換えずにそのまま転記しても良いような気がしてきました。--Dwy会話2013年6月21日 (金) 15:56 (UTC)[返信]
コメントまず、国会図書館の「慣行」についてですが、こちらの検索結果を見る限り、実際にはikedat76さんのおっしゃるような運用にはなっていないようで、どちらかといえば「数字は原則としてそのままの形で転記する」を実行しているように見えます。』とのことですが、まさか検索結果が意図するものか確認もせず、ただ最初の件数だけを見て、自分に都合が良いと誤解でもされたのでしょうか。まさかこれで騙せると思ったわけではないでしょうが、杜撰な調査で虚偽の報告をするような真似はやめてください。--氷鷺会話2013年6月21日 (金) 16:15 (UTC)[返信]
コメント国会図書館の立ち位置はよくわかりませんが、科学技術振興機構と日本心理学会はインターネット上での文字表記に関心を持っている専門家集団とは思えないです。さまざまな組織や専門家集団の慣行を参考にして議論するのもよいとは思いますが、再度申し上げますけれども、それはウィキペディア日本語版の取り扱う記事や閲覧の事情を考慮したものでしょうか?議論の混乱を招いた発端の2013年6月16日 (日) 15:44 (UTC)の発言を、そろそろ撤回する頃合いではないでしょうか。--Wolf359borg会話2013年6月21日 (金) 16:44 (UTC)[返信]
コメント国会図書館の文字種取り扱い基準を再確認しましたが、上記まとめは私の誤読を含んでいたので該当部分に抹消線を追加しました。もっとも、国会図書館の書誌データは確かに丸数字を使っていますがUnicode多言語面の範囲内に収まる限りのことであって、多言語面に収録されない文字は「私用面(U+E000-F8FF)」を使用しないとも明言しています。「気にしない」のではなく、Unicode多言語面の範囲の文字種であることを「気にして」使っているというのが正しい要約でしょう。
心理学会の投稿規程は学会誌への投稿論文に対するもので、それ以外に適用されるものではありませんから、投稿論文(なおかつ件の投稿規程にしたがって査読がなされるようになって以降に査読されたもの)でなければ何が出てきようが、そうですかとしか言いようがありません。SISTのものは提案であって、強制ではないのですから、それに従っていないものが出てこないところで不思議ではありません。どちらにせよ、文書の性格を全く理解せずにググっただけで異論を言えたつもりになっているだけ、「杜撰な調査で騙し」という言葉の通りですね。
どちらにせよ、これらは全量調査でも何でもありませんし、原則の上でブレがありそうだという推定にさして影響はありません。
さて、「影響はありません」と書きました。これ、ほんとでしょうか。そもそも上記3つの機関の公表物だけを見て云々することの適切さはどうなんでしょうか。ひょっとしたら、これも「素人の~」かも知れませんね。であるとすれば、そこで「気にしない」例が見つかったからとしもて、それこそ「素人の」適当な調査結果かも知れませんよね。Dwyさんが突っ込むべきところって、ここじゃないんですか?
で。ご自身の調査結果と見識はいつ示していただけるのでしょうか。私の調査結果ではなく、Dwyさんご自身の調査結果をです。それとも自分では調査もせず、「ウェブ上のメディアでも気にせずに丸数字を使うのが一般的な慣行」(国会図書館のそれはこれとは違います)とかいう空想上の存在を云々して、いつまでも納得しないおつもりでしょうか。まあ、理想の表記法とやらを求めたければ勝手にやっていればいいんじゃないでしょうか。ここで必要なのは、今記事を書こうとしている人が実務的に使うことが出来て、読者の閲覧性を確保できるルールでしかありません。--ikedat76会話2013年6月21日 (金) 17:42 (UTC)[返信]
いちおう念のためお聞きしますが、これの2・3頁目やそれ以降、それぞれの書誌情報や、資料種別を切り替えた表示を確認されました?(されていたらすみません) --氷鷺会話2013年6月21日 (金) 18:05 (UTC)[返信]
私が調べたところでは3ページ目の途中までマル数字が出てきていて、つまり37件くらい処理が漏れたという状況と認識しました。全体の件数に比べれば、まあ、がんばったけど残ってしまった程度と理解するので良いと思います。--T6n8会話2013年6月21日 (金) 21:08 (UTC)[返信]
コメント氷鷺さん、T6n8さん、お二人ともフォローありがとうございます。早朝に寝ぼけながら書くもんじゃありませんね。ああ、それから、「文字種取り扱い基準」、それ、書誌データじゃありませんから、そりゃあ適用対象外でしょう。丸数字が出てこようが外字が出てこようが驚くところじゃありません。
Wolf359borgさんの「インターネット上での文字表記に関心を持っている専門家集団」のご指摘はその通りといえば、まあその通り。でも、それってどんな人たちなんでしょうね。具体的に示されるおつもりはさっぱりないようですので、「専門家の慣行」と思えるものを見繕ったのですけれど。そもそも、それってDwyさんが本当はつっこまなきゃいけないところですけれど、これっぽっちもお気づきいただけませんでした。まあ、自分では調査もしない、意見も無いけれど文句だけは言いたいっていう姿勢に見合ったやり方で、はあ、そうですかっていう程度のものでしかありませんが。「ウィキペディア日本語版の取り扱う記事や閲覧の事情を考慮した」っていうのであれば、もう原則禁止、これでたくさんだと思うんですが。--ikedat76会話2013年6月22日 (土) 09:09 (UTC)[返信]
(氷鷺さんへ)「最初の件数」のことなんか私は何も言っていませんし、最初の2・3頁だけでも無視できないくらいの件数が確実にあるわけですから、「杜撰な調査で虚偽の報告」のような非難を受けるいわれはありません。私としては「どちらかといえば…に見える」という感想を述べただけですし、「検索方法等に間違いがあるならご指摘いただきたいのですが」と言っているのだから、異論があれば穏やかに指摘すれば済むことで、 あなたがなさったような無礼な言いがかりは不愉快です。
(T6n8さんへ)私が確認しているところでは、37件より、もう少したくさん丸数字が使われています。まず、「タイトル」の欄に丸数字を使っているのが少なくとも80件弱あります。それから、「要約・抄録」欄に丸数字が使われているデータも何十件かは存在しそうな感じです。更に、「目次」データ等のなかにも丸数字が使われているものがあります。検索システムの詳細がわからないので正確な総件数は把握できませんが、その存在を見逃すほど小さい数ではないと思います。「処理漏れ」の可能性は否定しませんが、そう考えるには多すぎる件数のような気がしています。--Dwy会話2013年6月22日 (土) 17:09 (UTC)[返信]

コメント確かにそれぞれの立ち位置で見解が変わるという意見は理解できます。私は「丸数字は文字化けの可能性があるから使わないほうがいい」という立場の意見を持っており、その意見は変わっていませんが「原文を忠実に再現する」「出典を元に記述する」という意見も十分考えられますし、納得できます。その中で大方の人間が満足するであろう「妥協点」(言い方が不適切かもしれませんが)を見つける必要があると思います。以下はOSシェアでのMacなど細かい部分を無視した粗い意見ですが

  • 丸数字を認めるとするなら
    • 情報処理推進機構によって配布されているIPAフォントでは丸数字は50まで対応している
    • WindowsXP以降のOS(Vista、7)では標準で50までの丸数字が収録されている
    • 2013年4月時点でのOSのシェアはWindowsが約90%を誇り、内45%がWindows7である(標準で丸数字の環境が整っている)
  • 丸数字を規制し続けるとするなら
    • Android4.1のFirefox20.0では丸数字は21以上は表示できない。スマートフォンの普及でAndroid端末から閲覧するユーザーも相当数いると思われる
    • 2013年4月時点でのOSのシェアではWindowsの90%の内38%はWindowsXPである(標準では丸数字は20までしか見ることができない)
    • 文字化けの可能性が捨てきれない

OSシェア参考情報(マイナビニュース)
改めて非常に難しい問題だと思います。20までは表示できる環境が多いですので、20までに限って緩和するということを考えてもいいのではないかと思います。--Elma会話2013年6月21日 (金) 17:00 (UTC)[返信]

コメント 妥協点を探るというのももちろんアリですが、適切に表示されるか不確かなものということには変わりはなく、そもそも現状jawpで丸数字の使用を主張する方もあまりおらず、「もしかしたら伏線があるかもしれない」「出典で専門家が使っている」などと無闇に使いたがる方々に対して譲歩する意味があるのか、疑問に思います。世の中の使用例の大半は、わざわざ丸数字を「使わなければならない」意味というのはない訳で、それをわざわざ使う「書く側の迷惑な自己満足」を許容する気にはなれません。言ってしまえば、少し前にあった「或いは」とか「然し」の表記を認めろといった主張と似たようなものかと。--氷鷺会話2013年6月21日 (金) 17:23 (UTC)[返信]
コメント 例外を含み文字コードとして丸数字の使用を完全に禁止しないのであれば、そのような流れで「丸数字を使用する場合は20まで使用しても良い」とすることは可能だと思います。ですが、現状は原則がどのような形になるのか、例外はどのように認めるのか、という段階であると思います。--Frozen-mikan会話2013年6月21日 (金) 18:48 (UTC)[返信]

コメント何度か書き込んでいますが、私は「20までに関わらず全面禁止(例外あり)」という形の原案が最善と考えています。その中で、使用賛成派の立場も考えて可能性を述べているまでです。端的に言えば「意味があるなら使い、ただの数字ならアラビア(代替)を使う」ということです。具体的な例外としては、「各対象(工業や医療など)において丸数字が重要な意味を持っており、それを記事上で記述しなければならない場合のみ」です。改めて確認しますが、「丸数字は原則使うべきでない(例外を認める)」という意見には賛成と考えてよろしいのでしょうか。--Elma会話2013年6月21日 (金) 23:38 (UTC)[返信]

少なくとも私は、一番上で表明したとおり、「全面禁止(例外あり)」を支持しています。--氷鷺会話2013年6月22日 (土) 07:18 (UTC)[返信]
同じく。そもそもが原則禁止なのです。妥当な例外だって定めてあるのだから、理想のウェブ上での表記法とか専門化がどうとかいう訳の分からない茶々が入っていなければ、もう結論なんか明らかだと思うんですけれども。--ikedat76会話2013年6月22日 (土) 09:09 (UTC)[返信]
原則禁止については、最初から誰も異論を唱えていません。「ここでは、どのような場合に『例外』を認めるのかを議論しています」と申し上げたのに、意味もなく余計な原則論を語り始めたのはikedat76さん自身であることを自覚してください。
それから、随分簡単に「妥当な例外」などと言ってくれてますが、その例外が「妥当」だと言う根拠は何ですか?これまでの議論の中で、根拠らしいものは何も出ていませんよ。ピント外れな無駄話ばかりしていないで、そこのところをはっきりさせてください。--Dwy会話2013年6月22日 (土) 17:09 (UTC)[返信]
コメント 本筋から大分離れていますが、話を元に戻すと丸数字については基本的に使用禁止で例外があるというのが皆さんの共通認識であると思います。あとは、例外の定義について明確にする必要があると考えます。上述しましたが流れてしまったため再掲させて頂きますが、例えば、ドリムス。(1)という記事において、上述の固有名詞の定義を適用すると、ここに含まれる丸数字の意味は一枚目のオリジナル・アルバムという順番を表す数字だと容易に考えられるため、()付き数字で表記し、本来の表記は~などという但し書きは必要ないというお考えでしょうか。--相田佳彦会話2013年6月22日 (土) 11:13 (UTC)[返信]
コメント - 記事名の時点で実際とは異なる場合、{{記事名の制約}}がつくことで結果的に「本来の表記の但し書き」を済ませていることになるでしょう。ドリムス。(1)の場合はAmazon等で(1)に代替される例もありますし、マルイチではなくワンと読むっぽいので、本文上も(1)でいい気がします。--ButuCC+Mtp 2013年6月22日 (土) 15:03 (UTC)[返信]
コメントドリムス。(1)の記事については、一通りの方が閲覧したと思いますので、本文中の丸数字について正しい表記へと修正しました。--相田佳彦会話2013年6月23日 (日) 16:00 (UTC)[返信]

丸数字の改定案

コメント明らかに順序を表す意図(ただの数字)の丸数字であれば、但し書きは必要ないでしょう。丸数字の全面禁止(例外あり)は皆さん共通して意見していますので、現状での書き換え案について提示します。

;現在

丸の中に数字が入った丸数字は使用せず、代わりに (1)・(2)・(3) を使用します。

;提案

丸の中に数字が入った丸数字は原則使用せず、代わりに (1)・(2)・(3) を使用します。

以下のケースに該当し、かつ(1)・(2)・(3)で代替ができない場合は丸数字を用いてもよいとしますが、該当記事のノートページでの議論を心がけてください。また、下記に該当するケースで丸数字を使う際は「①(丸1)」というように代替表記との併記をしてください。

  • 丸数字という「文字」そのものに言及している場合(例えば「丸数字」の記事など)。
  • 固有名詞で、単なる番号などではなく意図的に丸数字を使用している場合。
  • 規格、法令、巻次、ページなどで、通常のアラビア数字、漢数字などと区別して丸数字が使われている場合。
  • アスキーアートやギャル文字などで使用されている場合。
  • 対象の記事にとって丸数字が重要な意味を持つ場合(例えば推理小説の暗号など)。

特に「対象の記事にとって丸数字が重要な意味を持つ場合」は様々なケースが考えられますので、適用の際はノートページで使用の提案を行うようにしてください。

他にご意見があればよろしくお願いします。--Elma会話2013年6月22日 (土) 13:36 (UTC)[返信]

質問 まず、原則である使用禁止の根拠は、何でしょうか? 私はUnicode以外の符号化文字集合(主にJIS系)に含まれない文字を使用することによる弊害(閲覧時における文字コード変換による「文字化け」)を防がなければならないため、と認識しています。次に、例外について。「代替ができない場合」とは、誰がどのように判断するのでしょうか? また、記事「丸数字」のケースを含め、例外には原則である使用禁止の根拠を乗り越えるだけの根拠があるのでしょうか?--Frozen-mikan会話2013年6月22日 (土) 16:26 (UTC)[返信]
コメント 使用禁止の根拠は、おっしゃる通り「文字化け」のようです。現在の環境においてはJIS X 0213に規定されており、win、mac共に文字化けは起こりません、当然unicodeにも登録されています。しかし、一部の環境(JIS X 0208以前)では文字化けを起こしてしまいます。あとは、私の憶測になりますが、箇条書き等の表記の統一という意味も含んでいるのではないでしょうか。「代替ができない場合」については、どんな考え方の人物でも、全員が同一の回答ができる定義作りが必要であると考えます。使用禁止の根拠を乗り越える根拠を持つ、所謂例外となる記事については、現状挙げられていませんね(丸数字の定義の記事除く)。実態としては原則禁止でありながら、丸数字が使用されているケースがいくつか見受けられます。--相田佳彦会話2013年6月23日 (日) 12:33 (UTC)[返信]

コメント 氷鷺さんの当初の文にあった(問題なく代替できる場合は括弧数字を使用する)が適用されない例が本当にあるのか疑わしく思っています。そもそも「JIS X 0201のラテン文字類にもJIS X 0208にも規定されていない文字は、できるだけ使わないようにしてください。」が効いていて、マル数字なんかは実際に使わないことが可能であるから具体的に、「丸の中に数字が入った丸数字は使用せず、代わりに (1)・(2)・(3) を使用します。」となっているんだと思います。これを超えてマル数字が本当に重要なところは画像をつけるくらいのことをしないと特にアスキーアートなど正しく伝わらないと予想されます。「 丸数字という「文字」そのものに言及している場合(例えば「丸数字」の記事など)。」以外の例外についてはその例外にあたる実例が見つかるまで加えないほうが良いと思います。マル数字がゲタやトウフになっても理解できるように併記をしてある状態でもマル数字を書く意味が有りそうな例は他に思い浮かびません。思い浮かばないので、実例が出てからと思います。--T6n8会話2013年6月22日 (土) 14:52 (UTC)[返信]

ほらね。ちゃんと議論をしていれば、こういう方が出てきて何を例外にするのか合意できなくなる。最初から分かっていた当然の流れです。だからこそ、「(Wikipedia外の信頼できるメディアで例外処理をしている)実例が出ていることを確認した上で(Wikipediaでも)それを例外にする検討をするのが一番の早道なのでは?」と言っていたわけです。
アスキーアートについては(信頼できるメディアでの違う慣行があれば話は別ですが)私も個人的にはT6n8さんと同じく、アート自体は文字化けしない画像として示すほうが良く、地の文で機種依存文字を使う必要はないと思っています。
とりあえず「実例が出てから」に賛成を表明しておきます。--Dwy会話2013年6月22日 (土) 15:29 (UTC)[返信]
「ほらね」とか小賢しい後知恵をいってないで、さっさと実例を出せば?「専門家の」云々って言ったの自分でしょう?それとも文句を言うだけで手は何も動かさない、と?いやはや…--ikedat76会話2013年6月22日 (土) 16:41 (UTC)[返信]
予め実例を出すのが難しいから、「世間で例外となる実例が見つかったら、ウィキペディアでもそれを例外にしよう」という規定にしたらと提案していたんですけどね。寝ぼけてて人の言うことをちゃんと読んで理解ができないのなら、目が覚めるまで引っ込んでいて欲しい。(ああ、言っちゃった。お互い様なんでこちらだけ一方的に謝るつもりはないけど、熱くなってきたんで、しばらく休みます。)--Dwy会話2013年6月22日 (土) 17:09 (UTC)[返信]
コメント例外の定義になると、やはり上手にまとまりませんね。丸数字においては、文字化けを起こす環境が存在するという事実を考えると極力使用を避けるべきであると考えます。例外の中に、
  • 規格、法令、巻次、ページなどで、通常のアラビア数字、漢数字などと区別して丸数字が使われている場合。
とありますが、この例外は必要無いと考えます。前の方の議論でもありましたが順番を表すために丸数字を用いている場合には、丸数字を使用せず、代替すべきだという結論に達したはずです。この例は、まさしくそれに当てはまります。代替方法としては、今私が思いついた限りでは、丸数字の1であれば、二重括弧((1))や(i)などを用いる、などです。もちろん、これ以外の代替の表記でもっと適当なものがあれば、それらの表記を定義し、統一すべきだと思います。代替表記と更に被るような表記が存在した場合において、例外としておき、その際には議論が必要だと思います。--相田佳彦会話2013年6月23日 (日) 12:58 (UTC)[返信]
返信 (T6n8宛)
  • そもそも「JIS X 0201のラテン文字類にもJIS X 0208にも規定されていない文字は、できるだけ使わないようにしてください。」が効いていて、マル数字なんかは実際に使わないことが可能』――そうでない場合のための「例外」です。たとえばマルイチなどと読ませるような固有名詞や、規格などの原文で 1 と (1) と ① と I がそれぞれ別の意味で使われているような面倒な場合……そのようなレベルのお話です。
  • マル数字が本当に重要なところは画像をつけるくらいのことをしないと特にアスキーアートなど正しく伝わらないと予想されます。』――そもそもアスキーアートに限って言えば、フォントの問題もありますから、「正しく伝える」のが元々困難であって、化けるくらいのことは仕方の無いことです。
  • マル数字がゲタやトウフになっても理解できるように併記をしてある状態でもマル数字を書く意味が有りそうな例は他に思い浮かびません。』――思い浮かばないのならそれで結構ですが、実例が思い浮かばなくてもそれを想定して例外を具体的にしようというのがここの主旨でしょう。そうでもしないと、「架空の伏線」とか「架空の専門家の判断」を根拠に丸数字を使われてしまうようですから。いつも誰かがそういう彼らを根気強く説得し教えてあげられるのなら良いのですが、そうもいきません。--氷鷺会話2013年6月23日 (日) 13:19 (UTC)[返信]
返信 (氷鷺宛) 「 1 と (1) と ① と I がそれぞれ別の意味で使われているような面倒な場合」具体性がこのくらいあがれば話がわかりやすくなります。ここで、1とIは関係ないので、本質的には「(1) と ①」が両方別の意味で使われているときにどのように表記するかが問題であるわけですね。このときは、(1)への代替ではいけないのは納得できますので、「(1)と丸1」、「(1)と丸1(①)」、あるいは「(1)と①(丸1)」の三通り(さらに丸でなくマルと書く可能性で6通り)ある組み合わせからどれかを選べということですね。でも、ガイドとしては「(1)と丸1」あるいは「(1)とマル1」を推奨すれば、丸数字を使ってよい例外とする必要はないと思います。
「丸の中に数字が入った丸数字は使用せず、代わりに (1)・(2)・(3) を使用します。」と明確に使うなと書いてあるのに、わけのわからんことをいって丸数字を使おうとするひとは、例外の例が示されていても、さらにわけのわからん理由で使おうとするものだと思いますが、意外と効果があるんですか?
なるべく適切に代用表記を選択してもらうためには、例外の例を示して丸数字を使うハードルを下げるより原則に従って代用表記する例を示したほうがいいんじゃないでしょうか?例『ドリムス。①』->『ドリムス。(1)』; 札幌市営地下鉄の区間「マル2区」。
「丸の中に数字が入った丸数字は使用せず、代わりに (1)・(2)・(3) を使用します。(1)・(2)・(3) が異なる意味に使われているときは丸1・丸2・丸3またはマル1・マル2・マル3などの表現を使用します。丸数字の文字・文字コード自体を例示する場合は例外的に、丸1などの表記と合わせて丸数字を『丸1(①)』のように示すことがあります。」くらいの内容は同意できそうです。そんなに遠い位置にいるわけではないと思います。--T6n8会話2013年6月23日 (日) 14:51 (UTC)[返信]
コメント - 上節で取り上げた「③頁の件」に当たるものですが、実際は「p.1とp.①」が並立している状況で「p.①」をそれ以外の表現に変える場合、「p.マル1」や「p.丸1」と代替するならともかく(こういう場合に括弧よりこの方法が推奨なら明記すべき)として、「p.①→p.(1)」という代替をやった場合、典拠元のページ数が丸文字であることを注記しないと、ページを参照する側に混乱が生じないでしょうか?(どう考えているか確認したいだけです。意見を強く推す気はありません)--ButuCC+Mtp 2013年6月23日 (日) 15:29 (UTC)[返信]
返信 なかなか難しいですね。考慮したい要素は、ページ番号を丸で囲ったものがその文献では24までであっても、印刷技術としては51とか100だって十分ありうるのですから、一貫した表現方法にしたい。実物を見たときは、候補が2箇所以下になるので、p.(1)はまあ問題ないけど、複写依頼を出すことを考えるとマルで囲ってあるところというのを明示できたほうが安全そうという点も配慮したい。「p.(51) ((51)はマルで囲まれた数字)」にすると括弧が集まりすぎて美しくない。丸(51)頁が簡潔な気がする。「丸の中に数字が入った丸数字は使用せず、代わりに (1)・(2)・(3) を使用します。丸が特に重要なときは、丸(1)・丸(2)・丸(3)、丸1・丸2・丸3、またはマル1・マル2・マル3などの表現を使用します。丸数字の文字・文字コード自体を例示する場合は例外的に、丸1などの表記と合わせて丸数字を『丸1(①)』のように示すことがあります。」のほうがいいですね。--T6n8会話2013年6月23日 (日) 22:53 (UTC)[返信]

とりあえず、Dwyさんは個人的な主張ばかり繰り返されているので、仕方ありませんから彼の主張は却下ということで話を進めましょう。ここでは「例外」についてどういった指針を示すのか議論している筈なのですが、どうも根本的なところから変えたいようですし、しかしそれは話題のレベルが違いますし(加えて言うならつい先日それは無しになった話で)、それに対する他の方の支持もないのですから、これ以上相手をしてあげる必要はないでしょう。しばらくと言わず、できればもっとごゆっくりお休みいただいたほうが助かるのですが。--氷鷺会話2013年6月23日 (日) 13:19 (UTC)[返信]

コメント前の議論においても注意しましたが、そういった人を逆撫でするような発言(どの部分かご自分でよく考えてください)をしていては冷静な議論にはなりませんので避けるべきです。他にいくらでも表現方法はあります。これは価値観等の違いではありません、一般的なモラルの問題です。--相田佳彦会話2013年6月23日 (日) 13:54 (UTC)[返信]
コメント気持ちは分かりますが、熱くならず落ち着きましょう。Wikipedia:議論が白熱しても冷静にウィキペディアは何ではないかなどで示されるように感情的にならず冷静にいきましょう。お互いの粗探しではなく「例外」について議論をしましょう。--Elma会話2013年6月23日 (日) 14:59 (UTC)[返信]

賛成 そういえば、Elmaさんの改定案についての議論から遠ざかってしまっていましたね。私はElmaさんの案で良いと思います。強いて言うと、『規格、法令、巻次、ページなどで、』の箇所は、その前の行との対応を考えて『番号などを意味するものだが、』にするのもアリかなと思いました。--氷鷺会話2013年6月23日 (日) 15:27 (UTC)[返信]

コメントElma氏の案には、

  • 固有名詞で、単なる番号などではなく意図的に丸数字を使用している場合。

とありますが、意図的というのは定性的な表現なので混乱を招く可能性があると思います。また、意図的に丸数字を使用しているかどうかの判別方法についての具体例(実例)が一切無いので理解不能になります。前述にあった判別法だと、読みが「マルイチ」なら意図的という意味もよく分かりません。私は、丸数字の読みは一般的に「マルイチ」、「マルニ」だと認識しております。この項の内容と前述の意図的という意味の判別方法を適用すると、丸数字の読み方が示されていない場合は、固有名詞においては全て例外として記述できると解釈できると思います。このような解釈ができるような曖昧な定義は避けるべきです。 固有名詞については例外を設けず、この項については削除で良いのではないでしょうか。必要であれば、

  • 対象の記事にとって丸数字が重要な意味を持つ場合(例えば推理小説の暗号など)。

で適用すればよく、冗長であると考えます。必要であるなら、その実例と曖昧になっている意図的の定義付けについて述べて頂きたい。 --相田佳彦会話2013年6月23日 (日) 17:16 (UTC)[返信]

そこまで「理解できない」場合を想定するのもどうかと。もう少し頭を使っていただかないと、会話が成立しないのでとても困ります。たとえば『丸数字の読みは一般的に「マルイチ」、「マルニ」だと認識しております。』は誤りです。それは丸数字の記号単独について言及する場合や、それこそ「意図的」な場合、そして表記を厳密に・正確に伝えようとする(たとえば市立をイチリツ、(1)をカッコイチカッコトジと読むような)場合です。『進撃の巨人①』は、その読みが「マルイチ」である必要はまったくありませんよね?(まさか、これが必ずマルイチと読むものだという主張をするつもりではないでしょう)――そして、読みが「マルイチ」ということを判断材料のひとつにするのは、そもそも「その読みの根拠」「その表記である理由」が想像や推測ではなく実在するということであり、そもそも「その読み方でなければならない理由がある」ということです。そういうわけで、丸数字がすべて意図的だというあなたの主張は詭弁であり、検討の余地はありません。--氷鷺会話2013年6月24日 (月) 15:34 (UTC)[返信]
コメント細かいことにコメントしてると長くなるので、触れません。私が確認したいのは意図的の判断基準についてです。結局のところ、意図的の判断材料は、丸数字が用いられたものにおいて「その読み方でなければならない理由がある」、つまり丸数字について「読み方が、公式に示されている」ことが前提条件で、「丸数字そのものを指し示す読みである」、この2条件を満たした場合という解釈でいいですか?特殊な読みを持つ丸数字、例えば①と書いて「パン1」という読み方が示された単語を含む固有名詞(例えば楽曲名)が存在したとします。この例においては丸数字の読みが「パン」と定義されているので丸数字の記号そのものを指し示す、つまり括弧付き数字では代替できない、としていいのですか。--相田佳彦会話2013年6月24日 (月) 23:42 (UTC)[返信]
コメント丸数字は原則禁止という方向であり、意味があったとしてもシンプルな表記を心がけるべきだと思います。その点に関しては「対象の記事にとって丸数字が重要な意味を持つ場合(例えば推理小説の暗号など)。」の1本に絞って提示するのもいいとは思いますが、具体例が推理小説のみでは編集者が判断材料にできるレベルではないと思います。1本に絞る場合はもう少し具体例を列挙するべきだと思います。--Elma会話2013年7月1日 (月) 14:30 (UTC)[返信]

見落としていましたが、「アスキーアートやギャル文字などで使用されている場合。」には、代替表記を(すぐ隣に)併記してはマズイですね。使用例とは分離して①=マル1などと書くのであればともかく、併記だと説明すべき使用例の説明の邪魔にしかならない訳で、本末転倒です。というか、そういうケースはフォント・フォントサイズに依存するところも大きいので、もはや併記不要で良いように思います。ところで、現状、Elmaさんの案に対する検討すべき点・反対というのはありますかね…? --氷鷺会話2013年7月5日 (金) 17:04 (UTC)[返信]

  • 議論が発生していた例は、例外に当たるという結論にならず、代替表現という結論になっているのだから、ガイドにどういう代替表現をするのかの実例を加えることこそが重要と思います。例外は、無理に考えた実例のない例外の例を挙げる必要はないと思います。
;対案

丸の中に数字が入った丸数字は原則使用せず、代わりに (1)・(2)・(3) を使用します。丸が特に重要なときは、丸(1)・丸(2)・丸(3)、丸1・丸2・丸3、またはマル1・マル2・マル3などの表現を使用します。置き換えの例

  • 『ドリムス。①』->『ドリムス。(1)』
  • 札幌市営地下鉄の区間「マル2区」。
  • p.① -> p.(1)または丸1頁 (ページ番号に普通の数字と丸付き数字があって区別する必要があるとき)

丸数字の文字・文字コード自体を例示する場合は例外的に、丸1などの表記と合わせて丸数字を『丸1(①)』のように示すことがあります。他に代替不能で必要がある場合には、丸数字を用いることは可能ですが、該当記事のノートページでの議論を行うようにしてください。

--T6n8会話2013年7月6日 (土) 02:22 (UTC)[返信]

新しい用例を発見しました。ハイパー演算子で、用いられているマル数字、マルnはやっぱり、最初から括弧数字、括弧nになおして、マル数字ですの注記が望ましいですよね。--T6n8会話2013年7月19日 (金) 22:46 (UTC)[返信]

コメント原則として丸数字の使用は禁止ですので、修正を加えるべきです。文中に表記の制約のため、以後丸囲み文字~という記述があるため、冗長にならないように注意して但し書きを加えれば良いと思います。--相田佳彦会話2013年7月27日 (土) 09:42 (UTC)[返信]
コメント数学者ではないので英語版ウィキペディアの情報を鵜呑みにしますが、別に丸数字が一般的な表記法というわけでもなさそうです。記事の表記法を切り換えれば良いだけかと。--朝彦会話2013年7月27日 (土) 18:36 (UTC)[返信]

感嘆符のダブル使用について

Wikipedia:表記ガイド#疑問符・感嘆符では、感嘆符を使用するにあたって、直前の文字が全角なら全角を、半角なら半角を使用するよう推奨しています。

ですが、記事名ではなく、記事中「大改造!!劇的ビフォーアフター」と書く場合、この感嘆符は全角で「!!」とすべきなのか、半角で「!!」とすべきなのか、現在のガイドラインでは判別しかねます。また、記事によっては台詞を引用として「!?」あるいは「?!」とする場合もありますが、これは「?!」「!?」(全角)とするべきなのか、「!?」「?!」(半角)とすべきなのか、判別しかねます。

現在のガイドラインを文面通り理解すれば、「大改造!!劇的ビフォーアフター」は「大改造!!劇的ビフォーアフター」になるかと思いますが、、、、、(自信はあまりありませんが)。

以上の件について、皆様のご見解を頂けたらありがたく存じます。よろしくお願い致します。--Megevand (会話) 2013年8月1日 (木) 12:37 (UTC)[返信]

コメント 連続して使用される場合、擬似的に組み文字とみなして「!!」でよろしいのでは。「!!」だと間延びしますからね。--禁樹なずな会話2013年8月1日 (木) 12:39 (UTC)[返信]
  • 早速のコメントありがとうございます。ダブル疑問符と感嘆符は擬似的に組文字とみなして「!!」「!?」(「?!」)とする。いいアイディアですね。他の方のコメントも待ってみて、後にこれを表記ガイドにのせる提案をしてみたいなと思います。でないと、あまり顕在化はしておりませんが、いずれ編集上の問題となると思いますので。重ねがさね、コメントありがとうございました。ちなみに、現在では上記の通り解釈できますので、例えばあまちゃんでは全角で表記していることをご報告しておきます。--Megevand (会話) 2013年8月1日 (木) 12:52 (UTC)[返信]

ダブル感嘆符・疑問符の使用について、ガイドラインに推奨事項を新規盛り込みの提案

提案 直近で禁樹なずなさんが提案されているように、Wikipedia:表記ガイド#疑問符・感嘆符に以下の文面を追加することを提案します(赤字部分が追加文面です)。

  • 全角・半角のどちらを使うかは直前の文字に従います。ただし、記事名に使う場合は、常に半角を使用します。
    例: あれ? Are?
    例(記事名):太陽にほえろ!パタリロ!
  • 符号をふたつ連続で使用する場合、直前の文字が全角であっても半角で使用します(半角2つで全角とみなします)。
    例 : 「参った!!」「それ、おかしいんじゃない!?」「じぇじぇ?!」

以上です。皆様のご意見をお待ちしております。--Megevand (会話) 2013年8月2日 (金) 10:58 (UTC)[返信]

現行の「全角には全角使用」の推奨事項と整合性をもたせるため、「(半角2つで全角とみなします)」を追記しました。--Megevand (会話) 2013年8月2日 (金) 18:37 (UTC)[返信]

報告 1週間の期間中異論は出ませんでしたので、合意に至ったものとし、上記提案(赤字部分)をガイドラインに追加記載いたしました(参照 : [2])。--Megevand (会話) 2013年8月9日 (金) 20:18 (UTC)[返信]

今更かもしれませんが、「半角2つで全角とみなします」というのはちょっと意味がわかりません。半角は半角ですので。不要な一文だと思います。そもそもが例外規定ですので、「全角には全角使用」をオーバーライドするための項目です。整合性を考慮する必要はありません。--朝彦会話2014年2月16日 (日) 21:36 (UTC)[返信]

数式の記述方法について質問

「ウィキペディアの記事における表記方法の慣習」を説明してあるはずのWikipedia:表記ガイド#数式にはTeXの書き方のみ記述してあって、プロジェクト:数学#数式を組むでは「なるべくHTMLを用いるようにしてください」と書いてあるのですが、どちらを優先すればいいのですか?--Meniv会話2013年8月30日 (金) 08:24 (UTC)[返信]

複数の字体がある人名用漢字の字体について

Wikipedia:表記ガイド#漢字より引用

2000年(平成12年)12月時点で「人名用漢字別表」に字体が掲載されていた漢字は「表外漢字字体表」に示されていないので、現在の「人名用漢字別表」にある字体に従います。複数の字体がある場合は簡略なほうの字体を用います。 例(括弧外の字体を用います):亘(亙)・凜(凛)・尭(堯)・遥(遙)

これだけでは説明が漠然としてわかりにくいと思いますので、参考までに現在の人名用漢字別表にある漢字の中で複数の字体が示されているもののうち、表記ガイドの原則ではどの字体を用いるとしているのかを具体的に挙げておきます。結論として、JIS X 2008に印刷標準字体がある檜・禰の2字以外は「簡略なほう」を用いることになります。

  • 亘‐亙 → 亘 ★
  • 凜‐凛 → 凜 ◎
  • 尭‐堯 → 尭 ◎
  • 巌‐巖 → 巌 ★
  • 晃‐晄 → 晃 ◎
  • 桧‐檜 → 檜 ◆
  • 槙‐槇 → 槙 ◎
  • 渚‐渚 → 渚 ★
  • 猪‐猪 → 猪 ★
  • 琢‐琢 → 琢 ★
  • 祢‐禰 → 禰 ◆
  • 祐‐祐 → 祐 ★
  • 祷‐ → 祷 ※
  • 禄‐祿 → 禄 ★
  • 禎‐禎 → 禎 ★
  • 穣‐穰 → 穣 ★
  • 萌‐萠 → 萌 ◎
  • 遥‐遙 → 遥 ◎

【凡例】

  • ◎=表外漢字字体表制定以前より人名用漢字別表に掲載されていたほう
  • ★=旧・人名用漢字許容字体でないほう
  • ◆=印刷標準字体
  • ※=が印刷標準字体だがJIS X 2008外のため、簡易慣用字体の祷を使用

--2001:CE8:96:1:4B2:AB07:1933:C243 2013年9月3日 (火) 20:39 (UTC)[返信]

著作物名の表記について

現在、上記のガイドの説明の中にある「比較的長大」「比較的短小」という文言を根拠として、長編小説は『』、短編小説は「」と表記しなければいけない短編小説はどんな時も「」と表記しなければいけない、と主張される方(利用者:新続頭痛さん)がいたので(ノート:坂口安吾)、その主張が本当に「表記ガイド」が意図している指針なのかを井戸端で広く意見を募りました。私の解釈では、「比較的短小な作品」というのは、小説に対する「」、戯曲に対する「」、交響曲に対する「楽章」のことであり、「作品群に含まれる単一の作品」というのは、全集に対する「収録作品」、アルバムに対する「シングル曲」のことだと認識していたので、同じ個別の独立作品であり同格でもある長編小説と短編小説の表記を変えなければいけないという解釈はとても違和感がありました。井戸端での他の方々の意見も、短編小説はどんな時も「」と表記しなければいけない、というふうに捉えている方は見受けられませんでした。

雑誌新聞掲載時の状況を示すときなどは、長編小説も短編小説も「」と表記するというご意見は、ねこぱんださんやMEGEVANDさんから寄せられ、それに関連するご意見としてikedat76さんから、学会誌の中の論文と、文学作品の性質の違いについて以下のようなご意見がありました。

  • 「そうした物理的な出版形態とは相対的に独立して存在している作品を指すときにどうするのか」
  • 「文学作品について言えば、定期刊行物の連載から始まって単行本化され、文庫になり、作品集や全集に収録され…等々と多様な・物理的な出版形態で刊行されるというのは、ある意味で文学作品特有の事情とも言えるように思います。そうした事情がある以上、それを出版物一般に拡大してガイドラインを左右するというのが適当かどうか。物理的な出版形態とは独立に作品を指す表記法について考えていくのが方向としては適切でしょう。」

これは例えば文学作品の記事の冒頭文などで、その作品の出版形態を説明する時に

  • 『○○』は、誰々の小説である。1987年に文芸雑誌『××』に掲載された。
  • 『○○』は、1987年に文芸雑誌『××』に掲載された後に、▼▼社から単行本刊行された。現在は◎◎社から刊行されている。

というふうに、出版形態に対して相対的に独立している「作品そのもの」を指し示すときには、やはり『』が妥当だと私も思いますので、ikedat76さんの意見は参考になりました。そして一方で、作家の「年譜」のように、複数の作品のその時の状況を時系列を追って説明されるような場合には、

  • 1987年に文芸雑誌『××』に「○○」が掲載、1989年には新聞『▼▼』に「◎◎」が連載。

と、「」の表記でいいかと思います。これは、ねこぱんださんもおっしゃっていたように、長編小説、短編小説にかかわらず「」表記になるのが妥当だと思います。そして、この雑誌掲載の場合の三人の方のご意見内でも、長編だから短編だからという区別でないという認識は共通でした。現在、新続頭痛さんが表記編集した坂口安吾の版では、雑誌掲載時・単独説明に限らず、ただ単に長編小説は『』、短編小説は「」の基準となっており、書き下ろしで単行本刊行された中編小説も「」になっていますので(短編小説と同じ扱いなのかな?)、やはりとても違和感があります。代表作を連ねているテンプレ内でも、長編小説だけが『』になってます。

短編小説は、長編小説と同じように独立発表されている同格の単独作品ですので、それを単独で説明記述する際には、どちらも同様に『』で表記するのが当然だと私は思っています。例えば、三島由紀夫の代表作を文章内で列記する時に、

  • 三島由紀夫の代表作は、『仮面の告白』『潮騒』『金閣寺』「憂国」『鹿鳴館』『サド侯爵夫人』である。

と、同じ作家の同じ著作物なのに『憂国』だけを「」で表記するなどという変な書き方は、文芸評論でも見たことがありません。そして、『鹿鳴館』『サド侯爵夫人』は戯曲ですが、これらは長編ではなく、長めの短編もしくは中編の戯曲ですので、もしも作品の長さで表記を区別しなくてはいけないというと、これらも「鹿鳴館」「サド侯爵夫人」と表記しなければいけないのでしょうか。「表記ガイド」では、『』表記のカテゴリーの方に「戯曲名」があるから『』でいいということなら、同じ文学作品である「小説名」が、何故そこの範疇にならないのか不思議です。短編小説は戯曲や映画の原作になっているものが無数にあり、長編小説と同格の一個の文学作品で、単独で単行本になっている短編小説や中編小説も沢山あります。

そして小説は、長編、中編、短編というふうに長さによって便宜上分けたりしますが、実際にはそれぞれの間の境界はあいまいです。例えば、『真夏の死』は、全集や作品集などに分類する際には短編小説とされていますが、作者の三島由紀夫本人はノヴェレット(短編を意味するShort storyではなく、中編小説に相当する意味)だと言ってます。また、長編小説と中編小説との境界もあいまいです。全集で長編小説として分類されていても、評論家によっては中編小説と呼んでいる小説もあります。このように短編、中編、長編と名付けてられていても、その境界ぎりぎりのところでは実際にはあまり変わらない長さだったり、ほんの少しの長さに違いで、長編小説に区分けされたり、短めのものは短編小説となったりします。戯曲にはそんな区分けがないので、全部「戯曲」と呼んでいるだけです。

なので、このような便宜上の長さの分類を根拠にして、『』と「」の表記を区別するなどというのは、文学作品の個別記事作成の上で意味がなく、長編も短編も質的には何ら変わらない同格の小説です。この点に関しては、uaaさんやJkr2255さんも以下のようなご意見でした。

  • そもそも、「長編小説は『』、短編小説は「」で表記しなければいけない」なんて現実的に無理でしょう。「長編小説」と「短編小説」ってどこで線引きするんですかね?ガイドラインの記述にそう解釈できる余地があるのなら、文面を改正すべきだと思います。
  • 多数の作品が列挙される場面でカッコを使い分けるということは、カッコの違いによって、その内容について何かしらの質的な違いがあることを(少なくとも)暗示することになります。「短篇集の1作品」と「単体で発表された作品」を区別するならまだ意味はあるのですが、単体作品の中で「比較的長いもの」と「比較的短いもの」について違いを示さなければならないほど、両者に質的な違いがあるのかは疑問に感じます。

新続頭痛さんは、ある「短編小説名」と、それと同名タイトルの「短編小説集名」を区別するために、短編小説の表記を常に「」とするのは有効という意見を井戸端でおっしゃってましたが、その違いをどんな時でも(その小説そのものについて語っている時でも)、どんな場面の記述内でも保っていなくてはいけないという必要性が両者の間にそんなにあることなのか、そこまで重要性のあることなのか疑問です。もしも両者が混同されかねない場合や、収録作品全部を包括した同名の書籍を同時に示したい場合は、作品集『○○』というふうに、前に一言「作品集」と書き加えたり、「同名作品集」という文言で対処するなり、ケースバイケースで対応すればいいだけのことだ思います。同名タイトルの作品集があるというだけの理由で、その個別の「小説名」を常にどんな場面においても絶対に「」表記にしなければいけないというのは、何か小説そのもの、一個の文学作品そのものに主眼をおいていないで、どっちを主体にして考えているのか甚だ疑問です。

それに、そういった「作品集名」と「同名作品」の事例は短編小説以外にもあり、長編小説『女神』もその作品以外に数点の短編と同時収録されている同名タイトルの本もありますし、長編の戯曲も他の戯曲と同時収録されている本もあります。中編小説なら尚更、複数収録で同名タイトルの本は多くありますので、短編小説だけをそのような理由で、短編小説はどんな時も「」と表記しなければいけない、とするのは、論点がズレていると思います。そういう「作品集名」と「同名作品」の違いを示す意味においては、短編小説も中編小説も同じです。

なので、「表記ガイド」の説明の『』のカテゴリーに「小説名」という文言を加えた説明文にして、わずかな長さの違いで小説の表記が変えなければいけないかのような錯誤が生じないようにしてもらいたいと思います。また、「比較的長大な作品」「比較的短小な作品」という文言も、「同じ性質の作品の間での長短」というふうに捉えられてしまうと、例えばテレビドラマの場合でも、大河ドラマに比べれば、単発ドラマは短小作品ということも言えますし、交響曲に比べれば、ショパンの『子犬のワルツ』は短小な作品とも受け取られてしまい、上記の小説の場合のように、それぞれ独立した同格のドラマ作品や楽曲にもかかわらず、長さで表記を変えなければいけないかのような誤解が生じますので、この言い回しにも何か工夫が必要だと思います。--みしまるもも会話2014年4月14日 (月) 03:59 (UTC)[返信]

現行ガイドラインの問題箇所と具体的な改正内容を示していただけないと、議論が進まないと思います。--uaa会話2014年4月16日 (水) 09:22 (UTC)[返信]

改定案

私の改訂案としては、「小説名」という一句も入れた上で、以下のようにしたらいいのではないかと思います。「比較的長大」という文言の方は、上記の説明のように、同格同質の作品間でも長さで表記を変えなければいけないかのような誤解の元になるので省きました。

  • 作品あるいは作品群(書名・雑誌名・交響曲などの曲名・組曲などの名称・CDなどのアルバム名・映画名・小説名・戯曲名・テレビの番組名・イベント名・大会名など)は、和文では『 』で囲み、欧文では(入力を''……''として)イタリック体にします。
    例: 『海辺のカフカ』・『憂国』・『動物の謝肉祭』・Yesterday ... and Today・『ローマの休日』・『報道ステーション』
  • 比較的短小な作品(書中の章名や見出し名・小説の章名や話名・戯曲の幕名・交響曲などの楽章名・テレビ番組の企画名や話名・CDなどのシングル名など)や、
    作品群に含まれる単一の作品(雑誌中の収録論文名・全集中の収録作品名・詩集中の詩名・組曲中の曲名・シングルやアルバム中の曲名など)は、和文では「 」、欧文では、英文における “...” または各言語においてそれに相当する括弧で囲みます。
    例: Nature “Molecular Structure of Nucleic Acids”・『展覧会の絵』「プロムナード」・Yesterday ... and Today “Yesterday”・『古畑任三郎』「ラストダンス」
    ※ ただし文学作品記事の冒頭説明文などで、過去に掲載された雑誌媒体などの物理的な出版形態とは相対的に独立して存在している作品を指すときには、その小説名などは『 』のままでもよい。また、作家の年譜など、複数の作品のその時の状況を時系列を追って説明されるような場合には、その掲載作品名は「 」で囲むことが望ましい。
    例: 小説『○○』は、1987年に文芸雑誌『××』に掲載された後に、▼▼社から単行本刊行された。現在は◎◎社から刊行されている。
    例: 1987年に文芸雑誌『××』に短編「○○」が掲載、1989年には新聞『▼▼』に長編「●●」が連載。

--みしまるもも会話) 2014年4月16日 (水) 11:22 (UTC) 修正--みしまるもも会話2014年4月16日 (水) 11:30 (UTC)[返信]

(コメント)
  • 「作品あるいは作品群」(『』)と「比較的短小な作品」および「作品群に含まれる単一の作品」(「」)では、前者で「作品」と言ってしまっている以上、言葉の上で両者をきちんと仕分けすることができていません。
  • 「書中の章名や見出し名・小説の章名や話名・戯曲の幕名」というところは概ね「一つのまとまった作品の一部分」のような言葉が該当すると思いますが、これを「(作品全体に対して)比較的短小な作品」と言い表すのは自然な日本語の使い方ではありません。
  • 提案の趣旨は、「」を使うのは収録などの包含関係を示していることが自明な場合や章題など作品の一部の題の場合に限り、包含・収録関係を離れてまとまった一作品の題名に言及するときには『』を使う、ということだと思います。
  • これだと例えば「CDなどのシングル名」は「」を使うとなっていますが、シングルやアルバムといった収録媒体から離れた「楽曲そのもの」を指す場合には『』を使うことになるのだと思います(そう考えないと一貫性がない)。同じ記事中の同じタイトルの楽曲がシングル名にもアルバム名にもなりうるところで、『』を示すものが場所によって楽曲自体になったりアルバム名になったりするのは、たとえ前に「アルバム」とか「楽曲」といった言葉を入れたとしても視覚的にわかりにくさを招きます。
  • 論文の場合も収録関係を離れて「論文そのもの」に言及するときには『』を使うことになるのだと思います(そう考えないと一貫性がない)。これは論文に言及する際の慣用からはずれるのではないかと思います。
  • 自分の過去の執筆記事を見返しても、現在のように「短い作品」、つまりなにかに収録されて受容されることが予想されるような形態のものに「」を用いる形が記事中で一貫していれば、わざわざ「書物である」「短編小説である」「記事またはエッセイである」といった前置きがなくとも、文脈と鉤括弧の使い分けでそのような情報が大雑把にではあれ読者に伝えられていることが多いです。この区別をなくしてしまうとそうしたものすべてにいちいち前置きを入れる必要が出てきてしまう。前置きをおいて正確に伝えるような場合でも、「短い作品は「」/そのまま書名になりうる長いものには『』」という使い分けには文章を読む上で視覚的な分かりやすさがあります。これは現状の表記方法のメリットです。
  • 対して、改定案に従って改訂することの明確なメリットは「中間的なものに対して迷う必要がなくなる」くらいだと思います。これは上で述べたようなことに代替できるメリットではありません。提案者が述べている、同じ文学作品であるのに「」が使われるものと『』が使われるものがあるのはおかしい、という意見は、実際にそのような使い分けが(日本文学を含めて)複数の資料で確認できる以上、個人の感覚という以外なにも客観的な根拠が示されていません。
  • 私は現在の表記ガイドおよびスタイルマニュアルは「短編小説に対しては一貫して「」を用いると考えるのが自然である」ということを言っているのです(井戸端でそう言っているのは私だけだった、ということを書かれていますが、私が順を追ってまとまった説明をした後でなお異議を唱えている人はいまのところ提案者だけです)。これを「短編小説はどんな時も「」と表記しなければいけない」と命令語法に書き換えて何度も掲載するのは悪質な印象操作だと考えます。表記ガイド自体がそもそも例外を許容しているのであり、例えば引用文中で『』が使われているなど、誰が見ても例外性が納得できるようなものであれば従う必要はないでしょう。--新続頭痛会話2014年4月19日 (土) 03:59 (UTC)[返信]

コメント「中間的なものに対して迷う必要がなくなる」メリットの方が「視覚的に分かりやい」なんて愚にもつかない理由よりはるかに大きいと思いますね。「短い作品は「」/そのまま書名になりうる長いものには『』という使い分け」が文章を読む上で視覚的に分かりやすいと言えるには、①短い作品と長い作品の定義が明確であり、②この使い分けが世間一般に広く認識されているということが前提となる筈ですが、いずれの条件も満たしてないでしょう。「短い作品」「長い作品」ってなんか決まりがあるんですか?作品名に括弧を付けるに際しては、『○○』<ref>長編とされている出典</ref>とか「××」<ref>短編とされている出典</ref>のように一々出典を付けなければならないのでしょうか?執筆者の判断で分けるなんて論外ですね。使い分けが一般的なものでなければ、作品タイトルを列挙したものに『』と「」が混在していても奇異にしか映らないでしょう。ウィキぺディアンが勝手に分類したものをウィキぺディアのローカルルールで書き分けるなんて「分かりやすい」どころか迷惑千万です。
みしまるもも氏の改定案ですが、「比較的短小な作品」のような後で揉めるような文言が残っていますね。

* 作品及び作品群(書名・雑誌名・交響曲などの曲名・組曲などの名称・CDなどのアルバム名・映画名・戯曲名・テレビの番組名・イベント名・大会名など)の名称は、和文では『 』で囲み、欧文では(入力を''……''として)イタリック体にします。
例: 『海辺のカフカ』・『動物の謝肉祭』・Yesterday ... and Today・『ローマの休日』・『報道ステーション』
  • 作品中の小題(書中の章名や見出し名・小説の章名や話名・戯曲の幕名・交響曲などの楽章名・テレビ番組の企画名や話名など)は、和文では「 」、欧文では、英文における “...” または各言語においてそれに相当する括弧で囲みます。
単独の作品でも、作品群中の一作品として記述する場合(雑誌中の収録論文名・全集中の収録作品名・詩集中の詩名・組曲中の曲名・シングルやアルバム中の曲名など)は同様とします。
例: Nature “Molecular Structure of Nucleic Acids”・『展覧会の絵』「プロムナード」・Yesterday ... and Today “Yesterday”・『古畑任三郎』「ラストダンス」

というのは如何でしょうか?タイトルは原則『』とし、収蔵する作品群と共に記述する場合のみ、作品群と区別するために「」を用いることとしました。この方がシンプルでいいのではないでしょうか?--uaa会話2014年4月19日 (土) 11:31 (UTC)[返信]

長編と短編の厳密な区分を要求した上で「いちいち出典をつけなければならないのか」などというのはおかしいと思いますよ。前の議論で少し触れたようにいくつかの指標に基づいて蓋然的に判断することは可能です。Wikipediaにおける表記のルールの話なのですからどのように決めても(共通の規則のようなものが外部にない以上)ローカルルールにしかなりえないでしょう。また短い論文でも著名なものであれば詳細な注釈をつけて単独で刊行されたりされうる、ということを考えれば「文学作品」「小説」であることはそれほど特別視すべきことでもないです。
「中間的なものに対して迷う必要がなくなる」メリットの方が「執筆の際、作品の性質を示すための手段を提供する」かつ「読者にとって視覚的に分かりやい」というメリットよりもはるかに大きい、とは私は思いません。--新続頭痛会話2014年4月19日 (土) 12:01 (UTC)[返信]
(追記)ああ、それから「世間一般に広く認知されている」かは知りませんが、Wikipediaでその表記体系を採用していることがおかしくないと言える程度にはそのような短編・長編の使い分けの例は散見するように思います。--新続頭痛会話2014年4月19日 (土) 12:11 (UTC)[返信]

井戸端で新続頭痛さんの意見の後に反論のコメントがついていないからといって、新続頭痛さんに同調したということにはなりません。特に強い興味がなければ、一回意見を入れて済ましておく人もいます。そして井戸端に寄せられた意見では、現在の表記ガイドおよびスタイルマニュアルは「短編小説に対しては一貫して「」を用いると考えるのが自然である。 というような表記ガイドの解釈をしている方はいませんでした。新続頭痛さんは坂口安吾で実際に、短編小説はどんな時も「」と表記しなければいけないという姿勢で巻き戻し、例外なく短編小説はどんな時も「」表記にしています。代表作を併記するところでさえも、長編小説だけを『』表記に新たに変えてしまいました。なので私は印象操作などしていません。事実を言っているだけです。

また、改定案のメリットが、「中間的なものに対して迷う必要がなくなる」だけとおっしゃってますが、そもそも「中間的長さの作品」や中編小説をどちらの表記にしたらいいかと迷うような解釈をしていたこと自体がおかしいのであって、同じ性質の作品を、その「長さを理由に」表記を変えるなどという発想自体が日本の文学作品にはありません。私は多くの文芸評論や解題などを読んでいますが、同じ独立した小説であるにもかかわらず、「長編小説と短編小説を区別するという理由」で表記を変えているものなど見たことがないです。「年譜」などで雑誌掲載を表わしている場合や、雑誌掲載時の受賞作を表わしている場合、収録作品を表わしている場合などで、書籍や雑誌と区別する意味で表記を変える時はありますが、それは「小説の長さ」を理由にした基準ではありません。

短編小説を『』に表記すると、その前に「前置きを入れる必要が出てきてしまう」と新続頭痛さんは言ってますが、「小説そのもの」の内容を説明している記述内では、おのずから「その小説そのもの」について語っていることは自明ですし、前後関係を見ても分かることですから、そこで「同名短編集の書籍」との区別の文言を入れる必要性は通常ありません。そんな前置きをいちいち入れている文芸評論もないです。「小説そのもの」にとっては、その小説が収録されている「書籍」は一過性のもので(初刊本がプレミアがつくというのとは別の話)、様々な多くの出版媒体によってその収録内容も変化するような類のものなので、そのような類の書籍に対して、「小説そのもの」を語っている時にも常に、「同名短編集の書籍」との区別を念頭に置かなければいけないということはほとんどありません。もしどうしても二者が同じ記述内において混同されるような場合には、書籍の方に「作品集」と前置きするか、「同名作品集」など付記すればいいだけのことです。それに、長編小説や中編小説にも「同名作品集」がありますので、短編小説に対しては一貫して「」を用いる というのは論点がズレています。

それから、私の改定案の書き方についてですが、「章」「楽章」「幕」「話」は、単独作品ではありませんが、これらも「作品」には違いありませんから、「一部分」よりもやはり、uaaさんの案のように「作品中の小題」にして()にきちんとその旨の説明をされていれば、上の「作品」との区別ができると思います。

CDシングルカット曲の問題については、歌手が定期的に発表する「アルバムという作品」との比較対象として区別をするために、シングル曲は「」表記することに決めているようなので、それは()内ではなく別個に説明してもいいかと思います。交響曲でもアルバムでは複数曲で収録されたりしますが、それは小説の作品集や全集と似たものであり、歌手が定期的に発表する「アルバム作品」とシングル曲との対応関係を区別する規準とは性質が違うものです。これはある意味、シングル曲の特殊な表記ですので、シングル曲が単独の時でも「」表記だからといって、文学作品分野の短編小説にまで、書籍に収録されるから「」という短絡的な方向づけで短編小説の概念を語られても困ります。小説は戯曲や映画と同じで、長さで質が変わるわけではありませんし、シングル曲も曲の長さで表記を変えているわけではないでしょう。

寄稿雑誌とそれに密着的な関係の各論文と、物理的に存立している性質の文学作品との違いについては、上記でも説明しているので、その上で改定案の例を書き、文学作品に適したガイドラインの例示の提案もしています。著名な論文などで単独で言及されることが多い論文は、文学作品と同じように表記してもいいと思いますし、そこらへんはその論文の性質によって臨機応変にすればいいんじゃないでしょうか。

あまりガチガチに、論文はこうだから、文学作品もそれと同じように表記を一貫性を持たせなくてはいけないかのような新続頭痛さんのようなガイドラインの解釈の仕方は、それぞれに分野に合った表記方法を考える上で、逆にその分野における一貫性を損なっています。その作家の代表作を記述する際に、短編小説だけが「」表記になってしまうような奇怪な解釈(短編小説に対しては一貫して「」を用いる )は、小説の分野にはそぐいませんし、そんなおかしな基準の表記方法は、日本文学の分野にはありません。中編と長編の境界線や、中編と短編の境界線があいまいなものも多いのは上記でも説明しており、戯曲にはそんな区別がないことも説明しました。なので、短編小説だけを「」にしなければいかないかのような不思議な錯誤が生じかねない現在のガイドラインの説明文はやはり書き変えておきたいと思います。--みしまるもも会話2014年4月19日 (土) 13:08 (UTC)[返信]

改定案2

uaaさんの案と、新続頭痛さんのシングル曲の指摘を受けて、少し書き直してみました。「CDなどのアルバム名」「CDなどのシングル名」という文言は、()説明文の後ろでもいいかもしれません。

  • 作品あるいは作品群、CDなどのアルバム名(書名・雑誌名・交響曲などの曲名・組曲などの名称・映画名・小説名・戯曲名・著名な評論名・テレビの番組名・イベント名・大会名など)は、和文では『 』で囲み、欧文では(入力を''……''として)イタリック体にします。
    例: 『海辺のカフカ』・『憂国』・『動物の謝肉祭』・Yesterday ... and Today・『ローマの休日』・『報道ステーション』
  • 作品中の小題、CDなどのシングル名(書中の章名や見出し名・小説の章名や話名・戯曲の幕名・交響曲などの楽章名・テレビ番組の企画名や話名)は、和文では「 」、欧文では、英文における “...” または各言語においてそれに相当する括弧で囲みます。
    単独の作品でも、作品群中の一作品として記述する場合(雑誌中の寄稿論文名・全集中の収録作品名・詩集中の詩名・組曲中の曲名・シングルやアルバム中の曲名など)も同様とします。
    例: Nature “Molecular Structure of Nucleic Acids”・『展覧会の絵』「プロムナード」・Yesterday ... and Today “Yesterday”・『古畑任三郎』「ラストダンス」
    ※ ただし文学作品記事の冒頭説明文などで、過去に掲載された雑誌媒体などの物理的な出版形態とは相対的に独立して存在している作品を指すときには、その小説名などは『 』のままでもよい。また、作家の年譜など、複数の作品のその時の状況を時系列を追って説明されるような場合には、その掲載作品名は「 」で囲むことが望ましい。
    例: 小説『○○』は、1987年に文芸雑誌『××』に掲載された後に、▼▼社から単行本刊行された。現在は◎◎社から刊行されている。
    例: 1987年に文芸雑誌『××』に短編「○○」が掲載、1989年には新聞『▼▼』に長編「●●」が連載。

--みしまるもも会話) 2014年4月19日 (土) 13:15 (UTC) 加筆--みしまるもも会話2014年4月19日 (土) 13:24 (UTC)[返信]

改定案2は、最初より大分明快にはなったと思います。趣旨自体は変わらないので反対理由も変わりません。
それで「そんなおかしな基準の表記方法は、日本文学の分野にはありません。」ということを繰り返しておられますが、現に確認できると言っているところでなぜそのような断言を続けられるのかわかりません。他の人も容易に確認できそうなところでは例えば新潮文庫『彼岸過迄』の柄谷行人の解説、『こころ』の三好行雄の解説にそのような使い分けが見られます。客観的な根拠をなにも示さずに「日本文学の分野ではそのような表記はされない」といったことを続けられては議論にも何にもなりません。
「寄稿雑誌とそれに密着的な関係の各論文と、物理的に存立している性質の文学作品との違いについて」というのも根拠がわかりません。論文雑誌にも文芸雑誌にもいろいろな性質のものがあります。
戯曲は上演されうるという性質もありますから、小説と同じように扱うことはしにくいかもしれません。気づかれなかったかもしれませんが、井戸端で紹介したPDFでは「一幕ものの戯曲」を区別して「」を使用するとしており、妥当な判断かと思います。
この調子で議論を続けられても、あまり生産的な結論は得られないと思います。--新続頭痛会話2014年4月19日 (土) 14:03 (UTC)[返信]
(追記)それで私のガイドラインの解釈が誤解である、という点ですが、上のようなかたちで抜本的な書きなおしをしなければその「誤解」が正せない、ということをご自分で示されている時点でほぼ説得力を失っていると思います。--新続頭痛会話2014年4月19日 (土) 14:29 (UTC)[返信]

新続頭痛さんの誤解を正せないと、改定案の意味がないということはありません。そもそも現在の「表記ガイド」も、短編小説に対しては一貫して「」を用いる という指針にはなっていませんし、そのような解釈をしている人も井戸端の意見を募ってみてもいませんでした。そして今回、説明文を改訂するのは、別に新続頭痛さんの誤解を解くためだけではなく、より分かりやすい説明文にするためであって、「表記ガイド」の指針自体は基本的には変わりません。井戸端で新続頭痛さんがリンクしたものも、短編が『』表記になっているものもあったので、短編小説に対しては一貫して「」を用いる という理由にはなってなく、論拠になってませんでした。

昨日新続頭痛さんが挙げた新潮文庫は今手元にないので、はたしてそれが本当に、短編小説に対しては一貫して「」を用いる という理由に基づいて「」表記になっているのかは、井戸端のリンクのようによく中身を確認しなければなりません。たまたまそこに短編の「」があるというだけでは、短絡的に(短編=「」)とも言えませんし、メインで語っている小説と区別する意味で表記を変えていたり、書籍になっていないから表記を区別している場合もあるので、よく前後関係を確認しないといけません。それと、短編小説が「」表記となっているものが一つや二つあるだけで、その評論家が、いつでもどんな時でも、短編小説に対しては一貫して「」を用いる という基準に基づいて、様々な作家の解説をしているとも限らないので、たったそれだけの短い解説や日報の中に、「」表記の短編小説の事例があったからといって、短編小説に対しては一貫して「」を用いるというのが、その評論家のスタンダードとは断定できません。

私が持っている評論本でも、三島由紀夫が10代の時に書いたものはなぜか「」表記にしている人もいますが、『憂国』や『英霊の声』は「」にはなってませんでしたので、短編小説に対しては一貫して「」を用いる という理由に基づてはいませんでした。また、三島由紀夫や川端康成の新潮文庫の解説「人と文学」や年譜は、一貫して「小説名」は全部同じ表記になってます。雑誌掲載時でも、雑誌と同じ『』表記になっており、長編だから短編だからという基準にはどれもなっていませんでした。その時々の解説者が書く解説内の表記も、短編だから長編だからという理由で表記を区別しているものはまず見当たりませんでした。安部公房の短編『水中都市』の解説をしているドナルド・キーンも、収録短編を『』表記にしてますし、三島由紀夫が自作解説している短編も全部『』になっており、雑誌掲載時のことを語っている時も表記は同じになってます。全集の年譜や書誌でも長編も短編も同じ表記で統一されており、「」表記ならばそれで統一されてます。なので全体から見れば、「小説の長さ」基準で表記を変えているものはほとんどないと言っていいものです。

それから、「戯曲は上演されうるという性質もありますから、小説と同じように扱うことはしにくい」という新続頭痛さんの主張は、両者を全く別の性質のものとする根拠になりません。短編小説も舞台で朗読劇のように上演されることもあり、朗読番組や朗読CDもありますし、安部公房の短編小説は、少し書き変えて戯曲になっているものが沢山あるので、両者はそんなかけ離れた性質ではありません。また、「一幕ものの戯曲」は、どんな時も「」で表記するなどという基準も、三島由紀夫や安部公房の戯曲を見るかぎり、そんな表記方法はありません、戯曲には「場」というものもあるので、それなら「5場」から成っている戯曲『班女』は、同じような長さの『卒塔婆小町』と表記を変えなければいけないのかという、新たな混乱が出てきます。井戸端で新続頭痛さんがリンクしたものを見ても、「戯曲集の中の一幕物」と書かれているだけで、「一幕ものの戯曲」とはなってませんでした。

そして、もしも「一幕ものの戯曲」は、どんな時も「」で表記するという基準と、短編小説に対しては一貫して「」を用いる という基準を同時並行させると仮定するなら、複数の「章」がある短編小説と、複数の「幕」がある戯曲で、表記がバラバラになり、それこそ混乱の元になります。このように、作品の「長さ」で表記を変えようと考えること自体が、日本文学の作品表記において全くそぐいませんので、新続頭痛さんの「表記ガイド」解釈にそって、「一幕ものの戯曲」は、どんな時も「」で表記するとか、短編小説に対しては一貫して「」を用いる などという基準は到底無理がありますし、一般的な日本の文芸評論や作家論、全集の書誌情報や年譜でも、そのような基準がスタンダードになってはいません。--みしまるもも会話2014年4月20日 (日) 02:58 (UTC)[返信]

(付記) 新潮文庫『彼岸過迄』の柄谷行人の解説と、『こころ』の三好行雄の解説を確認しました。
『彼岸過迄』の柄谷行人の方は、夏目漱石の小説『彼岸過迄』『それから』『吾輩は猫である』『三四郎』『門』『行人』の名称は出てきましたが、短編小説の名称はありませんでした。江戸川乱歩の「D坂の殺人事件」が一つ、「」表記になっていただけでした。たった一つの「D坂の殺人事件」表記だけをもって、、短編小説に対しては一貫して「」を用いる という理由に基づいて「」表記になっているのかは判断できません。夏目漱石以外の作品だから目立たなくしているのかもしれません。
『こころ』の三好行雄の方は、夏目漱石の小説『こころ』『彼岸過迄』『行人』『先生の遺書』の名称が出てきました。このうち『先生の遺書』については文中で
  • 数種の短編を書きつぎ、それをあわせて総題を『心』とする予定だったという。しかし、<某短編『先生の遺書』を書き込んで行くうちに、予定通り早く片が付かない事を発見したので>(初版序)、『先生の遺書』だけで連載を打切り、…
と書かれてあり、夏目漱石に関しては、短編だからといって「」表記となってはいませんでした。そして、森鴎外の「興津弥五右衛門の遺書」、阿部次郎の『三太郎の日記』、武者小路実篤の『友情』は、森鴎外だけ「」表記となってますが、これも森鴎外の短編は、書籍になっていないために「」表記にしたのかもしれませんから、これだけでは何を根拠にしているのか不明ですし、夏目の短編『先生の遺書』が『』表記になっていることも考え併せると、はっきりと短編小説に対しては一貫して「」を用いる 基準かどうかは分かりません。
そして『こころ』の巻末に載っていた年譜では、夏目漱石の長編小説も短編小説も評論も全部が『』表記に統一されてました。この表記の仕方は、三島由紀夫や川端康成の年譜の記載方式と同じでした。なので、新潮文庫の『こころ』を見ても、短編小説に対しては一貫して「」を用いる という基準がスタンダードになっているとはいえませんでした。--みしまるもも会話2014年4月20日 (日) 07:02 (UTC)[返信]
まず付記の部分について。『先生の遺書』というのは最初に漱石による序からの引用文中でこのような表記で出てきます。解説者が言及しているのはその直後でもあり、また長短のある作品として現存するものでもないから混乱を避けるために合わせたというだけでしょう。「森鴎外の短編は、書籍になっていないために「」表記にしたのかもしれません」「たった一つの「D坂の殺人事件」表記だけをもって、短編小説に対しては一貫して「」を用いるという理由に基づいて「」表記になっているのかは判断できません」というのは私には何を言っているのか理解できませんでした。年譜と解説は作者が違いますから表記は違うのは当然かと思います。新潮文庫のどれも年譜と解説の鉤括弧の表記方法は大抵一致していません。
私はそのような表記方法が現に使われている、ということの簡便に確認できる例として上の二つを挙げただけです。他の表記方法が存在することを否定しているわけではありませんので、みしまるももさんが持っている本のいくつかはこうなっている、ということを挙げられても反証にはなりません。これくらいのことは理解してほしいのですが。--新続頭痛会話2014年4月20日 (日) 09:01 (UTC)[返信]
段落を戻して反対理由についてもう少し説明しておきます(どちらかというと、uaaさん向けの説明です)。現状、長編小説のタイトルは雑誌掲載など、収録関係を明確に示しているような場合に「」、書名として、または単独で言及する際には『』を使う、というかたちが許容されています(前に述べたように私は一貫して『』を使っていますが)。しかし長編小説というのは連載のかたちであれ、書物のかたちであれ、基本的にそのタイトルが示すものは一つの同じ長編小説しかありません(単行本化の際に加筆修正されて別物になったりすることもありますが、それはとりあえずおいといて)。ですから「こころ」としていたものを文脈によって『こころ』に変えたとしても、ひとつの長編小説であり従って一冊の書物として普及することが多いものである、という情報さえ読者に伝えてあれば別に混乱は起きないのです。
短編の場合はそうではありません。小説にしろ論文にしろ音楽にしろ、ある短い作品を収録した作品集がその作品名をそのまま作品集のタイトルにする、ということは広く見られます。ですので区別のために『』は作品集名、「」は収録作品名に使う、という表記方法も広く見られます。こういう表記が広く見られるものに対して、たとえその名前を冠した作品集がないからといって、同じ記事内で同じ短編に対してある場合は「」、ある場合は『』を使ってしまうと、ぱっと見その名前の作品集があるのかと思われかねません。実際に表題作として収録されている作品集があるのであればなおさらで、文脈上明らかな場合でも視覚的に混乱を招きます。それを回避するためにはいちいち「短編『○○』」のように前書きをつける必要が出てきてしまいます。文章がくどくなるし、執筆者にも閲覧者にも不親切です。短編に一貫して「」を使う場合でももちろんそのような前書きをつけることがありますが、左記のように「つけなければわからなくなりかねない」状態に較べれば見て取りやすさも文章の自由度もこちらのほうが上です。
中間的な形態で迷いが出そうなもの、というのは例えば明らかに短編という長さのものだが単独で刊行されて広く普及している、とかそういったようなものだと思います。井戸端で意見があったように、鉤括弧というのはまず地の文と区別するために用いられます。『』と「」の区別は、その中でさらに区別をする必要がある場合に用いられます。その観点に立てば、作品集に収録される形態が一般的なものは作品集の形態と区別するために「」、一冊の書物の形態で読まれるのが一般的で、収録されるものは全集・選集くらいかあるいはあってもほとんど知られていないようなものは『』、というふうな使い分けが自然にできると思います。それでも迷うケースは出てくるでしょうが、執筆者が迷うようなものであれば現実問題として『』でも「」でも別にさしたる混乱は招かないでしょう。井戸端でその程度の表記ゆれは記事内で一貫してさえいれば問題ない、と言ったのはそういう理由です。
要は受容の形態を蓋然的に区別しているのであって、「長さ」でカテゴライズをする目的で括弧を使い分けるわけではありません。少しの長さの違いを判別して使い分けるのはおかしい、というような意見は観点がずれています。『』を使うか「」を使うか迷わないで済む、というのは執筆者の側の便宜であって、閲覧者の便宜ではありません。--新続頭痛会話2014年4月20日 (日) 09:01 (UTC)[返信]
(追記)長編か短編かに関わらずすべて『』でくくる、というのは、文章のスパンがあらかじめ予想でき、上のような使い分けの必要性がないとわかって書く解説文や評論などには適すると思います。不特定多数の執筆者が参加し、記事ごとのスタイルも一定の範囲内ではあれ不特定であるようなところでは上記した理由で(短編を一貫して「」でくくる方法に較べて)適するものではないでしょう。--新続頭痛会話2014年4月20日 (日) 09:23 (UTC)[返信]


『先生の遺書』の表記を引用符の中の表記に合わせたというなら、尚更、その解説文内で、短編小説に対しては一貫して「」を用いる というような、作品の長さで表記が変るという厳格な基準にはなってはいないことの証明になってます。それから、たった一つの江戸川乱歩の小説がそこで「」表記になっているからといって、即それが、短編小説に対しては一貫して「」を用いる という基準にならないという意味も、そのメインの作家以外の作品を強調させないために表記を変える人もいますので、たったそれだけでは、その評論家の意図は分からないということです。とにかく、その事例では夏目漱石の小説間で短編小説を「」としているものはありませんでした。

それと、新続頭痛さんが言っている、「長編小説というのは連載のかたちであれ、書物のかたちであれ、基本的にそのタイトルが示すものは一つの同じ長編小説しかありません」というのは違います。例えば、川端康成などは最初から長編のつもりで書いてはなく、短い断章のようなものを短編か長編になるかも分からないままに断続的に(連載ではない)書いていって、結果的に短編か中編か長編かになるだけです。『雪国』『千羽鶴』などはその一例で、雑誌掲載時には「雪国」というタイトルはありません。それに長編小説でも、他の作品と同時収録で本になっているものもありますし、長編だから、必ずしも単独本とも限りません。『千羽鶴』の最初の単行本も、『山の音』と同時収録になってます。ちなみに短編小説でも連載小説はあります。

それから、「『』を使ってしまうと、ぱっと見その名前の作品集があるのかと思われかねません。」というのも、そんな発想を先ず思うのは、Wikipediaの「表記ガイド」で「書籍名だけ」を『』と表記すると思い込んでいる人だけです。普通は、文学作品などの著作名は作品の長さに関係なく『』か「」で表記されているのが一般的ですので、『』を使っているから、即「書籍」だという発想などありません。「小説名」「戯曲名」という著作名を示しているんだと思うだけです。逆に同じ小説にもかかわらず、「」と『』が同時に混在している方が閲覧者にとって「視覚的に混乱」が起きてます。現に坂口安吾の表記を、私は一閲覧者として見て、違和感しかなく、とても変だと思います。なぜ新続頭痛さんは『二流の人』を「」表記にしているのか、納得のいく説明を私にしてください。百科事典の文学記事を見る時に奇妙でしかありません。

新続頭痛さんの主張していることは逆に、長年Wikipediaに居て「書籍名だけを『』と表記する」という考えに囚われている人の側の視点でしかなく、閲覧者のことを二の次にしています。それに、新続頭痛さんはこれまでいろいろなことを言ってますが、代表作を併記する時になぜ長編小説以外は「」表記にしなければいけないのか、正当性があるような説明はこれまで一切ありませんでした。長さでカテゴライズしているわけでないと言いながら、なぜ短編小説に対しては一貫して「」を用いるという結論になるんですか。 新続頭痛さんがこれまで根拠としいる話は、短編小説だけの事例ではなく論点がズレていることは前にも私は言っています。いったい短編小説と中編小説は何が違うんですか。長編小説と中編小説は何が違うというんですか。何度も言っているように、多くの文芸評論や全集の書誌情報でも、同じ作家の代表作をバラバラの表記方法で書いているものはまずありませんので、新続頭痛さんの主張する基準は、文学作品の表記上で全くそぐわない特異な考え方です。不特定多数の執筆者が参加し、多くの一般人が閲覧する記事なら尚更、普通一般に多く普及しているスタンダードな表記方法にするべきです。--みしまるもも会話2014年4月20日 (日) 13:12 (UTC)[返信]

「絶対」を強要しないということ

新続頭痛さんが言っているような、「短編小説」と「それが収録された同名作品集」を区別する際には、ガイドラインにもあるように、すでに「」表記が許容されていますので、どうしてもそういう混同のおそれ大きい場合には、その「」表記を採用するなりして対処すればいいことです。また、その名称の作品集がなく、書籍に一回しか収録されなかったような、あまり著名ではない短編小説の場合も、特にその作品が中心的な重きをおいていない場合の記述内では、「」表記にしてもいいんじゃないでしょうか。そういうのは記事内でケースケースで相応しいように考慮して書けばいいことです。

私が何度も言っているのは、そういったケースのために、川端康成や三島由紀夫や坂口安吾をはじめ、長編小説にも中編小説にも短編小説にも同じように重要性のある著名な文学作品が多く存在しているような作家のその作品名を書く際にも、短編小説に対しては一貫して「」を用いる というような基準を強制されては困るということです。そして、現にそのようなガイドラインの指針は現在もありません。短編小説に対しては一貫して「」を用いる などというような、日本の文学作品において無理な表記方法を主張をしているのは新続頭痛さんだけです。--みしまるもも会話2014年4月21日 (月) 01:34 (UTC)[返信]

すみません。お二人ともその分野に精通された方なので、何をどう申し上げても脇が甘い、筋が通ってないという批判をされそうで怖いので具体的な提案は避けますが(おそらくそう思っている方は多いはず)、要は、このウィキペディアで統一してどのように表記しようかというのがそもそもの主旨ですから、ここはお互いの価値観とか信念とかをいったん脇へ置いておいて、妥協できる道を探れませんか?そして、一回で完璧なガイドができずとも、長い目で良いものが出来るように考えていったら良いのではないですか?、、、、というコメントをするのも、本当は怖いのですが、もし参考になることがあれば幸いです。それでは。--MEGEVAND (会話) 2014年4月22日 (火) 20:48 (UTC)[返信]

この場に「その分野に精通」している人間は一人もいませんよ。今起こっているのは「価値観」とか「信念」とかいったことのはるか以前の、日本語や通念の理解とか論理的な意思疎通とかいったレベルでの齟齬です。--新続頭痛会話2014年4月23日 (水) 09:33 (UTC)[返信]

上に挙げたのと同じ柄谷行人は新潮文庫『堕落論』で同じ表記方法を取っていて、安吾の作品のなかでも「続堕落論」「イノチガケ」「織田信長」(『信長』ではなくて短編のほう)に対して、別に解説の主題でもなんでもない『吹雪物語』だけ二重鉤にしています。他にも日本文学に限っても対談、論文、解説ほかでこうした表記は一定数確認できます。大して量のない手持ちの文献だけでこれだけ見つかるのですから範囲を広げればいくらでも見つかるでしょう。しかしこの例だって「これだけでは長編を区別しているかどうかわからない」「特に重要な作品だからこれだけ二重鉤にしているのかもしれない」などということを言い出せばいくらでも言えてしまう。このような仕方で合わないものを排除したうえで「日本文学でこうした表記をしているのを見たことがない」などと主張されているわけですから、「その分野に精通」などしていなくてもなにか非常におかしなことを言っているのだということくらいはわかるでしょう。(「目立たせないために」って中学生の感想文の話じゃあるまいし)。話を合わせろというほうが無理です。

せっかく議題に上がったところですから、本来であればガイドラインの曖昧な部分を詰めたり、検討しなおしたりといったことにつなげるべきでしょうが、提案者の主張の様相や議論運びから考えて現実的に不可能でしょう。「二流の人」の判断についても他の人なら妥当性を検証できそうな理由に基づいて一重鉤にしているのですが、今それに言葉を費やしても生産的な議論に繋がるとは到底思えません。むしろ何か付け加えるたびにそれが結果的に脱線や議題拡散の材料になってしまう。提案者はどうもとにかくまくしたてて形の上で反論を「論破」すれば提案が通るとでも思っておられるようですが、Wikipediaはそのようには運用されていません。他の利用者も話についてこれていないようですし、このような状況で上の「提案」が通る見込みはないでしょう。現状の文言を触らずとしておく以外どうしようもない。--新続頭痛会話2014年4月23日 (水) 09:33 (UTC)[返信]


私やuaaさんが、ガイドラインの曖昧な部分を詰めたり、検討しているのに、それを一貫して反対しているのは、新続頭痛さんです。私は上記でも書いたように、「短編小説」と「それが収録された同名作品集」を区別する際には、ガイドラインでも「」表記が許容されていますので、両者が混同されるようなら、ケースバイケースで新続頭痛さんの裁量で、「」表記すればいい話だと言ってます。でも、だからと言って、そのケースのために、ガイドラインにもないような、短編小説に対しては一貫して「」を用いる などという新続頭痛さんの解釈を、他のところで強制するなということです。

それに、柄谷行人のように表記する人がいても、それは一般的ではありません。「これだけ見つかる」とか「一定数いる」と新続頭痛さんは言ってますが、たったの一人や二人の例で、「いくらでも見つかる」というのは、単なる新続頭痛さんの推測レベルの話です。三好行雄については、『先生の遺書』は「」表記になってませんでしたし、森鴎外も書籍でないから「」表記なのかもしれませんから、何が基準かははっきりしてません。また、個人の解説者が、その人の好きなように書いた個々の表記を出されても、あまり意味のないことです。私が言った「目立たせないために」というのも、人によっては、三島由紀夫の10代の作品を「」表記にしたり、どういう意図か理由もあいまいで「」表記にしている人もいますので、そんな場合もあります。新続頭痛さんは多くの文芸評論をお読みになっていないから、書き手によって特に基準もなく、好きなように変えている恣意的な表記があるのを知らないだけでしょう。ちなみに、柄谷行人も、294頁では『日本文化私観』を、『』表記にしていたり、302頁では「」表記にしていたりと、その時々によって好きなように変えており、一貫性はありませんでした。特にその両者を雑誌掲載時とか書籍で区別しているというわけでもなく、同じような語りにおいて『日本文化私観』の表記がバラバラです。

あと大事なのは、その新潮文庫の『堕落論』の巻末付録にある、出版社が作成した「年譜」では、やはり一般的な表記法にそって、短編も長編も区別なく、雑誌掲載時などは「」表記で統一し、書籍刊行時は『』表記になっていることです。こういうふうに長編も短編も区別なく同じように表記するのは、年譜や共通の解説文や全集の書誌情報ではスタンダードな表記方法です。だから、柄谷行人はこうだとか言われても、それは多数派ではないですし、一般的に多く使われているのは、この新潮文庫の年譜などの表記のように、長編も短編も同じように、雑誌掲載時は「」で、書籍は『』の基準であったり、あるいは、すべて『』になっていたりします。三島由紀夫や川端康成は後者の方になってます。いずれにしても、短編小説に対しては一貫して「」を用いる というのは、スタンダードな表記にはなってませんし、年譜、全集の書誌情報、百科事典には相応しくない表記です。

それから、『二流の人』も短編小説ではないのに、なぜ新続頭痛さんの基準では、「」表記にしているのか意味不明です。『二流の人』は中編小説だから「」だということでしょうか? 長さ的には長編小説の方に近いですが、新続頭痛さんの判断では短編小説と同じ扱いということになるんですか? 新潮文庫の年譜の基準では、執筆時や雑誌掲載時は、短編長編にかかわらず、「」表記にしてますから、それなりに統一されており、理由や基準ははっきりしてますから、他の長編や中編と同じようになっていているので納得できますが、新続頭痛さんは、そのスタンダードな表記法や、Wikipediaの表記ガイドとは違い、どんな時(雑誌掲載時)でも長編小説は『』表記にしているのに、ほぼ長編の『二流の人』が短編扱いに何故なるのか、いったいどんな理由なのかを説明してください。そうでないと、新続頭痛さんの基準での、「中編小説の表記の基準」が全く分かりません。まさか中編小説も、 中編小説に対しても一貫して「」を用いる なんて無理な表記の解釈をしているんでしょうか。--みしまるもも会話) 2014年4月23日 (水) 12:40 (UTC) 加筆--みしまるもも会話2014年4月24日 (木) 00:51 (UTC)[返信]

すでに議論が正常な形で成立していないことは他から見ても明らかだと思いますので、これ以上なにかを付け加える必要を感じません。あなたは自分で自分の提案を潰しにかかっているのと同じことだと思います。--新続頭痛会話2014年4月24日 (木) 08:45 (UTC)[返信]

新続頭痛さんは、私の真面目な疑問や質問には答えられない、説明できないということですね。承知いたしました。--みしまるもも会話2014年4月24日 (木) 08:59 (UTC)[返信]

合意形成や意見の整理・すり合わせができるような議論状況では到底ない、と言っているのです。--新続頭痛会話2014年4月24日 (木) 09:01 (UTC)[返信]


合意形成や意見の整理・すり合わせを最初から拒否しているのは、新続頭痛さんの方です。新続頭痛さんは、「改定案2」のところで、

  • 「最初より大分明快にはなったと思います。趣旨自体は変わらないので反対理由も変わりません」

と言い、結局、短編小説に対しては一貫して「」を用いる という中身にならなければ、反対することには変わりないという姿勢をただ貫いているだけですので、私やuaaさんが、「ガイドラインの曖昧な部分を詰めたり、検討して、文言を変えて、短編小説に対しては一貫して「」を用いる などという無理な解釈の意味に誤解されないようにすること自体」が嫌なだけです。これは井戸端のときから、新続頭痛さんが最初から「反対する」と明言してますので、明らかなことです。新続頭痛さんにしてみたら、今のままの方が新続頭痛さんの好きなように、いくらでも、短編小説に対しては一貫して「」を用いる という、新続頭痛さん独自の解釈がされやすいままになるからです。なので、いくら議論を重ねて、こちらが真面目に質問や疑問点(なぜ新続頭痛さんが『二流の人』を短編と同じ「」表記にするのか)を投げかけても、新続頭痛さんはそうやって、はぐらかし続けるだけです。

結局、短編小説に対しては一貫して「」を用いる という方針にならなければ、新続頭痛さんは、ガイドラインの文言を変えること自体を反対し続けるだけですので、とりあえず、「小説名」という一句を『』のカテゴリーに書き加えることだけはさせていただきます。同じ文学作品名の「戯曲名」が書いてあって、「小説名」があってはならないということは、どう考えてもありえませんので、これだけは書き加えさせていただきたいと思います。uaaさんやMEGEVANDさんの同意があれば、「小説名」を「戯曲名」の横に書き加えたいと思います。--みしまるもも会話2014年4月24日 (木) 11:16 (UTC)[返信]

そのような合意は形成されていません。合意なくガイドラインを書き換えてはいけません。--新続頭痛会話2014年4月24日 (木) 12:54 (UTC)[返信]

「戯曲名」の横に「小説名」を書き加えさせてください

現在のガイドラインでも、「著作物名」は基本的に『』表記にしていいことになってますので、そこのカテゴリーに含まれている「戯曲名」「映画名」と同じように芸術作品名・文学作品名である「小説名」を入れてはいけないというのは論理的にありえないでしょう。これは別に現状のガイドラインを変更することでは全くありません。「」表記にする場合の事例については、その下で説明されていますので、そのケースによっては小説名も戯曲名も「」表記になることは示されており、許容されています。短編小説集と、その個別作品を区別させたい時は、「」表記は十分許容されてます。

なので、私はなにも、小説に対しては一貫して『』を用いろ などという解釈を、新続頭痛さんのように他者に強制するつもりなど一切ありませんし、そんなガイドライン解釈にもなりえないのは、ガイドラインをよく読めば分かることです。「小説名」を書き加えたら、ガイドラインが変って、小説に対しては一貫して『』を用いる という基準になるなどと、怖れを抱いてビクついているのは新続頭痛さんだけです。

そもそも著作物名の表記というものは、そのケースバイケース(雑誌掲載関係、収録関係など)によって「相対的」に変わりうるものですので、新続頭痛さんのように、一貫して などという姿勢を貫き通すこと自体が、この表記ガイドの指針が逸脱した考えです。新続頭痛さんは今、短編小説に対しては一貫して「」を用いる長編小説に対しては、雑誌掲載時でも一貫して『』を用いるという基準の表記をしていますが、それこそ、現在の表記ガイドを無視していると言えます。井戸端のご意見でも、そのような特異な新続頭痛さんに賛同している方は誰もいませんでした。

なので、新続頭痛さんには現在のガイドラインをある程度、ちゃんと守ってもらい、短編小説に対しては一貫して「」を用いる長編小説に対しては、雑誌掲載時でも一貫して『』を用いるなどという、ガイドラインにないような手前勝手な表記は控えてもらいたいと思います。そうしないと、坂口安吾の現在の表記のように、同じように雑誌掲載時の経過を説明しながらも、長編小説だけが『』になっていたり、中編小説が「」表記になっていたりと、何が何だかごちゃごちゃで、非常に汚らしいバラバラ表記で、閲覧者にも執筆者にもわけが分かりません。新続頭痛さんのあの書き方は、一般的な表記どころか、このWikipediaの表記ガイドからも外れてます。--みしまるもも会話2014年4月25日 (金) 03:24 (UTC)[返信]

小説や戯曲の鉤括弧表記はどのようにするのが最適か、本来であれば検討に値する問題ですが、議論提起者がこのような状態ではどうしようもないでしょう。まくしたてれば意見が通るわけではない、ということを書きました。他の利用者をおいてけぼりで自分の考えだけ滔々と書き連ね、反論があればその趣旨と関係あろうとなかろうととにかく少しでもおかしなところを見つけ出して論難する、これで合意など成立するわけがない。本件の提起者は、Wikipediaの議論についてなにか重大な誤解をしているようです。--新続頭痛会話2014年4月25日 (金) 10:51 (UTC)[返信]

新続頭痛さんに対する私の真面目な質問や疑問点には、一切、真摯に説明・返答をせずに、そういうふうにはぐらかして、全て私が悪いから議論ができないかのようなレッテルを貼るんですね。本当に卑怯でずるい人です。

私が言っていることは、何も新続頭痛さんが、短編小説を「」表記するのを止めろなどということではありません。あなたが短編小説集と、それと同名の短編小説を区別する際には、今までのように、そのケースで適切なようにおやりになればいいことだと言ってるんです。

しかし、それを例えば、三島由紀夫や川端康成や坂口安吾のように、短編小説も中編小説も長編小説と同じように重要性が高く、代表作がある場合の作家の作品を同列で列記する場面においても、短編小説に対しては一貫して「」を用いるなどという無理な解釈を強制して「押しつけるな」ということです。

はっきり言うと、新続頭痛さんが今実行しているご自分の解釈(短編小説に対しては一貫して「」を用いる長編小説に対しては、雑誌掲載時でも一貫して『』を用いる)などという、表記ガイドの指針でもない、変てこりんで無理な手前勝手な絶対基準を、人にまで強制するなということです。--みしまるもも会話2014年4月25日 (金) 12:09 (UTC)[返信]

一人が言いたいことを一方的に言い続けるだけでは議論は成立しません。それがわからないのであれば、どうしようもない。--新続頭痛会話2014年4月25日 (金) 13:43 (UTC)[返信]

反対 現時点で、如何なる改訂も事態の改善に資するとは思えません。ことに例示の項目を足したり引いたりといった小手先の改訂に意味は無いでしょう。提案者は改定によって何がどう改善されうるのかを論理的に示していません。新続頭痛氏の解釈が間違っているだけで「ガイドラインをよく読めばわかる」のであれば、ガイドラインを改正する理由はないことになり、主張が矛盾しています。--Kojidoi会話2014年4月26日 (土) 10:49 (UTC)[返信]


(Kojidoiさんへ) 私は、「ガイドラインを改正」するつもりは全くありませんし、「ガイドラインを改訂しろ」とも主張してません。井戸端(Wikipedia:井戸端/subj/小説における著作物名の表記の『』と「」の区別の仕方について)でも、皆さん常識的にこのガイドラインを解釈しており、誰も新続頭痛さんのように、短編小説に対しては一貫して「」を用いるなどという判断をしている人はいませんでしたから、「ガイドライン」自体を変える必要性は今のところはありませんし、私も「ガイドラインを改正、改訂」しろとは、どこでも主張はしていません。そのことは、きちんと一番上の方から、順を追って全部を詳細に読んでくだされば、分かることだと思います。

私やuaaさんは、「解釈」の誤解を招きかねない記述があるので、その「説明の書き方」を少し変えて、分かりやすくした方がいいのではという提案をしていただけです。本当の案の一例、二例案は、上の方にあるので、それもあらためてよく見てくだされば意味がよくお分かりになると思います。でも、Kojidoiさんのように反対する人がいれば、私は無理強いすることはしませんし、新続頭痛さんも一切それに反対するだけですので、それが叶うことは現実的にはないでしょう。

とりあえずは、上でも言ったように、新続頭痛さんが今実行しているご自分の解釈(短編小説に対しては一貫して「」を用いる長編小説に対しては、雑誌掲載時でも一貫して『』を用いる)などという、表記ガイドの指針でもない、変てこりんで無理な手前勝手な絶対基準を、人にまで強制しなければ、基本的に済む話ですので。そんなことで、ねちねちと干渉されたり、強制されたりして記事執筆に費やす時間が削られたりしたら困りますので、それさえ無理強いされるようなことがなければ、もうどうでもいいです。--みしまるもも会話2014年4月26日 (土) 13:22 (UTC)[返信]

Wikipedia:コメント依頼/みしまるもも 20140429を提出しました。--新続頭痛会話2014年4月28日 (月) 20:21 (UTC)[返信]

楽曲タイトルの表記言語とテンプレートでの言語指定について

記事「マイケル・ジャクソン」において、原題である英語で記載されていた楽曲タイトルを私が公式の日本語題に変更したところ[3]、「日本語題での表記は義務付けられていないはず」[4]として差し戻しを受けた[5]。その後、私が導入部での人名の原語表記についてTemplate:Lang-enを用いて指定したところ[6]、「Wikipedia:スタイルマニュアル (人物伝)に違反している」としてこれも除去を受けた[7]。相手方のこのような編集はjawikiの方針・ガイドラインに適ったものであると言えるのであろうか。--114.149.247.179 2014年8月3日 (日) 18:34 (UTC)[返信]

人名のスタイルについて

この表記ガイドのルールには、「人名に肩書・敬称・学位・位階・勲などは付けないでくださいWikipedia:スタイルマニュアル#人物・人名によります)」とあり、私は一国の大統領や首相、さらには野球選手にまでこのルールを適用してきました。

× バラク・オバマ大統領、安倍晋三首相、星野仙一監督、嶋基宏捕手 (すべて敬称にあたる書き方)
○ 大統領バラク・オバマ、首相安倍晋三、監督星野仙一、捕手嶋基宏 (または役職と氏名の間に「の」を入れた表記)

しかし、uaa氏から私の会話ページに「執筆者は当マニュアルで規定するスタイルに絶対に従わなければならないわけではありません」の文言もあるので、がんじがらめに適用しなくてもよい、という趣旨のクレームがつきました。「じゃあ、何のためのガイドラインなんだ」とも言いたいですが。
ここで皆様からご意見を募りたいのですが、人名に敬称をつけるのは皇族・王族以外にも場合によっては適用しても問題ないのか、それともやはり人名に敬称はつけないのがベストなのか、どうお考えでしょうか。私は少なくとも、スポーツ選手やスポーツ監督には敬称にあたる書き方は慎むべきと考えます。実際に、新聞であってもコラムの場合は敬称をつけない文体になっています。--Fielder会話2014年8月17日 (日) 14:10 (UTC)[返信]

コメント 私の記事が一端緒になったようなので一言だけ。ガイドラインの最も重要な趣旨は「敬称等の使用による権威付けによって、記事の客観性を毀損することを防止する」ことだと考えます。「何某博士がこう言っている」というような例です。ただFielder氏が主張される「嶋基宏捕手のような表現が敬称に当たり避けるべき」というのは、さすがに一般社会では通用しません。属性あるいは職能を表わす表現と、敬称や肩書は別個のものです。「捕手」はチーム内での役割を明示するに過ぎません。あまり瑣末に流れずガイドラインを運用することを望みます。--TX2468会話2014年8月17日 (日) 15:37 (UTC)[返信]

第三者の方からのご意見がつく前のコメントで恐縮ですが、書かせていただきます。
百科事典では敬称はつけない、すなわち呼び捨てが原則でしょう。「一般社会で通用しない」と仰っていますが、一般社会で呼び捨てが通用しないのは当然であり、ここで一般社会を例に出すのは的外れです。新聞記事であってもコラムでは敬称略、すなわち呼び捨てで書かれているのに、百科事典でこういったガイドラインが守られていないのは稚拙すぎます。--Fielder会話2014年8月17日 (日) 15:50 (UTC)[返信]
追記。属性や職能を表す表現であっても、人名の後につければ(例:三木谷浩史オーナー)、それは立派な敬称です。--Fielder会話2014年8月17日 (日) 15:53 (UTC)[返信]
コメント 指摘の「首相」「監督」といった言葉は、一般にそういう地位にある人が敬意を払われる傾向にある、というだけであって、敬称ではなくどちらかと言えば肩書なのではないでしょうか。人名の前につけるか後につけるかで敬称であるかどうかが変化するとは、私には思えないです。私はこれまで、この規定のところを見落としていて、まさに指摘されるような表現を使ってきましたけど、これを制限されるのはさすがに違うように思います。人名を文中に記載するときに、どういう立場にある人であるかを一緒に書くことは読者の理解に資するわけですし、その際に人名の前に書くように制限するというのはあまり意味がないことだと思います。肩書を後に付けたからと言って、「記事の客観性を毀損する」とは私には思えないです。そのようにガイドラインを読めるならば、ガイドラインを改訂すべきだと思います。--Tam0031会話2014年8月17日 (日) 16:09 (UTC)[返信]
コメント 地の文での「人名+役職」の表記は他の百科事典、歴史書などでも普通に使われています。手元の『ブリタニカ』や『マイペディア』では、ニクソン大統領とか、福田首相とかの表記があります。Fielder氏の言われていることは敬語の使い方ですので、敬語を使わない百科事典の文章に適用する意味はありません。なお、敬語の文脈においては、「役職の人名」も中立的な表現ではないことを指摘しておきます。 --Yhiroyuki会話2014年8月17日 (日) 16:36 (UTC)[返信]
コメント 結論から先に言えば、名前の後に職位名をつける/つけないは、前後の文脈や内容で判断すべきものであって、杓子定規に適用するものではないでしょう。無論、つけない方が望ましいのですが(科学分野の記事なら例外なく敬称はつけないのですがね)。ただし、名前の後に職位名をつけることが「敬称に当たらない」とするのは誤りではあるので、「敬称に当たらない」と主張される方々においては、その点認識を改めていただきたく思います。--森藍亭会話) 2014年8月17日 (日) 17:40 (UTC) 下線部追記。--森藍亭会話2014年8月17日 (日) 18:00 (UTC)[返信]
Fielder2014年8月17日 (日) 15:50 (UTC)へのレス)話がかみ合ってませんね。TX2468氏が言ってるのは、「属性あるいは職能を表わす表現」を敬称扱いすることが「一般社会で通用しない」ということなんですよ。それと、氏の本ガイドラインの趣旨についての認識はWikipedia‐ノート:表記ガイド/過去ログ8#肩書についての結論とも共通してますね。要するに、あなたが本ガイドラインの趣旨も考慮せず、”敬称”を拡大解釈しているということです。[返信]
「属性」や「職能」は、本ガイドラインで「原則として付けない」とされている「敬称」や「肩書」には該当しません。過去の議論や趣旨を鑑みても、そう解すべきでしょう。そもそも、本ガイドラインは「ウィキペディアの記事における表記方法の慣習を説明」するのが目的ですよね。御自身がウィキペディアの記事に於いて広く使われている表記方法を否定するような解釈をしていることにいい加減気付いてくださいよ。「ただし、このガイドラインはすべての記事に絶対に適用しなければならないものではありません」ともあります。つまり、日本語として珍妙な表現にしてまで当ガイドラインに従う必要はないということです。だから、御自身でも「少々まどろっこしい」なんて思いながらそのような表現に書き換えるのが理解できませんね。更に、人名については「付けることが慣習となっているもの」には適用しない旨が明記されています。これは、文中で例示されている「皇族・王族」のみに限定されていません。
ところで、日本語の百科事典では全て「大統領バラク・オバマ」とか「首相の安倍晋三」という表現に統一されてるんですか?「バラク・オバマ大統領」や「安倍晋三首相」という表現は使われてないんですか?--uaa会話2014年8月17日 (日) 18:04 (UTC)[返信]
『ブリタニカ国際大百科事典(2013)』の「イラク戦争」の項にて、「オバマ大統領」の表記があります。最初は大統領選の文脈で「バラク・オバマ」、撤退の宣言の文脈で「アメリカのオバマ大統領」、2011年の撤退では2回登場し一度目は「オバマ大統領」、二度目は「オバマ」表記です。いずれも敬意を示すような使い方ではありません。--Yhiroyuki会話
敬称は厳密に言えば様、君などの接尾語で、閣下、陛下など代名詞としても使用される、いわゆる尊称も含みますが、ウィキペディアで使用される頻度はあまりないでしょう。問題のほとんどは、「敬意を払うに足る肩書」についての考え方だと思います。これには主計局長、陸軍大将といった職名や男爵などの栄爵が含まれます。実際のところ行政や軍事に関する記述でガイドラインを厳守することはなかなか困難です。肩書で回っている世界ですから。真崎甚三郎軍事参議官をを「軍事参議官の真崎甚三郎」と書くことはできますが、その方法で二・二六事件を詳述すれば文章がどうにもならなくなります。であればこそuaa氏の言われるガイドラインの例外規定があると考えます。「田中証人」、「鈴木研修員」、「近藤運転手」といった人の属性や職能に関する表現は、一般に敬意を払うものではないので問題はないでしょう。社会通念上、野球選手の守備位置も同じことと考えます。要はガイドラインの趣旨を理解し、可能な努力を払うことにつきると思います。--TX2468会話2014年8月18日 (月) 02:17 (UTC)[返信]

(第三者の方へ)これまでの経緯については、利用者‐会話:Uaauaa#マシュー・ペリーでの要約欄について利用者‐会話:Fielder#Wikipedia:表記ガイドの乱用について利用者‐会話:TX2468#敬称にあたる書き方は謹んでください。利用者‐会話:Fielder#「敬称にあたる書き方は謹んでください」へのご返事を参照してください。--uaa会話2014年8月17日 (日) 18:04 (UTC)[返信]

コメント 私が記事を執筆する際には原則呼び捨てにします。しかし機械的に敬称を修正して回るのは問題ありで、例をあげてみます。某壱太郎投手の記事として『某壱太郎の完全試合達成に対し、某弐次郎捕手は「スプリットが非常に良かった」、対戦相手の某参三郎監督は「スプリットを狙わせたが失敗だった」と語った』という記述から「捕手」と「監督」を機械的に削除したとすると、非常にわかりにくくなるのではないでしょうか。もちろん、『某壱太郎の完全試合達成に対し、バッテリーを組んだ某弐次郎は「スプリットが非常に良かった」、敵将の某参三郎は「スプリットを狙わせたが失敗だった」と語った』などとすることで対応できるわけですが。要するにケースバイケースであり、片っ端から敬称を削除して回ったり、他の利用者に「敬称を使うな」と要求するような性質のものではないと考えます。ガイドラインはあくまでも原則にすぎない、という点を忘れないでいただきたいと思います。なおFielderさんの投稿履歴を拝見しましたが、あらしへの対処などでお疲れなのでしょうか、「いい加減にせよ!」「ルール違反!」「時系列くらいしっかりまとめるべき」など要約の文が荒れ気味と感じます。他の利用者への敬意をもって行動していただきたいと思います。--143.90.212.40 2014年8月18日 (月) 09:55 (UTC)[返信]

簡単な返信で失礼しますが、143.90.212.40さんのご意見は非常に参考になります。私も『某壱太郎の完全試合達成に対し、バッテリーを組んだ某弐次郎は「スプリットが非常に良かった」、敵将の某参三郎は「スプリットを狙わせたが失敗だった」と語った』という言い回しに変えて対処するようにしていましたが、ご指摘の通り荒らしへの対処の疲れもあり、ここのところは要約文が乱暴気味になったり野球記事でポジションを機械的に削除するだけにとどめたりしてしまっていました。「ケースバイケース」ということは念頭に入れて編集に務めたいと思います。--Fielder会話2014年8月18日 (月) 10:36 (UTC)[返信]

コメント 今更すみません。Fielder様に強く同意します。桜井誠 (活動家)で「橋下徹大阪市長」を「大阪市長橋下徹」というような編集をしたら、Uaauaa様によってRvされ、この議論へ誘導されました。市長・首相・大臣などは政治家の役職を現すとともに、敬称に該当すると思います。TX2468様が仰っている「ガイドラインの最も重要な趣旨は「敬称等の使用による権威付けによって、記事の客観性を毀損することを防止する」ことだと考えます。「何某博士がこう言っている」というような例です。」に該当すると判断しました。「捕手」や「投手」の場合であれば、「~杓子定規に適用するものではないでしょう」(森藍亭様)「ケースバイケース」(143.90.212.40様)という御意見も肯けますが、政治家の場合は、敬称を除去すべきケースではないでしょうか? ましてや、私の編集をわざわざRvまでする必要があるのか疑問に感じます。--JapaneseA会話2014年10月26日 (日) 13:58 (UTC)[返信]

「政治家の役職は敬称に該当しない」という意見も複数出ており、「政治家の役職も書き方によっては敬称に該当する」という意見は一部ですね。御自分に都合悪い意見は無視ですか?これまで寄せられた意見は、「政治家の役職も書き方によっては敬称に該当するけど杓子定規に適用するものではなくケースバイケース」と「政治家の役職は敬称に該当しないから適用対象外」に集約されると思います。何れにせよ、「敬称を除去すべきケース」ではないでしょう。政治家の公人としての言動を記述する際に用いられた表現を、科学分野の記事で「何某博士がこう言っている」と書くのと同列に扱うことが無茶苦茶ですね。「当該部分に政治家の肩書きを入れと敬称になる」とする理論的な説明を求めたいです。実際、当該箇所に肩書きがあることが「記事の客観性を毀損」しているのですか?
そもそも、「大阪市長橋下徹」とか「首相安倍晋三」が日常的に多く使われる、自然な表現なんでしょうか?不完全な表記ガイドに書かれた一つの単語を振り回してまで、珍妙な表現に書き換える必要はないでしょう。それが「杓子定規に適用するものではないでしょう」ということですよね。それに、要約欄で「Wikipediaでは陛下でさえも呼び捨てです」と仰ってますが、「人名に肩書・敬称・学位・位階・勲などは付けないでください」の後に「皇族・王族などで付けることが慣習となっているものは例外とします。例: 後醍醐天皇 」とありますよね。要するに、ガイドラインを守るために習慣的に使われている表現まで排除しなければならないというものではないということです。「大阪市長橋下徹」とか、ウィキペディア方言とも言えるような表現であり、Rvすべきケースでしょう。--uaa会話2014年10月26日 (日) 16:06 (UTC)[返信]
コメント これまでの議論を見るに「「政治家の役職は敬称に該当しないから適用対象外」に集約される」とは解釈できませんでした。あとは合意形成のコメント依頼とします。--JapaneseA会話2014年10月27日 (月) 04:20 (UTC)[返信]
「政治家の役職も書き方によっては敬称に該当するけど杓子定規に適用するものではなくケースバイケース」と「政治家の役職は敬称に該当しないから適用対象外」に集約される」と言ったんですけどね。何れにせよ、「首相安倍晋三」なんて書き方に統一するべきという意見は無かったということです。コメント依頼の依頼文が「A大臣とするか大臣のAとするかで意見が分かれています」となってますが、そのような二者択一的な意見は出ていません。もし、ガイドラインの文章にそう解される余地があるなら、ガイドラインから当該部分を削除すべきでしょうね。--uaa会話2014年10月27日 (月) 12:26 (UTC)[返信]
情報 役職名が後置される例[8]。他、『百科事典マイペデイア』(2008)でも、政治家の役職を後置する例を確認しています。 --Yhiroyuki会話2014年10月27日 (月) 06:06 (UTC)[返信]
コメント コメント依頼からです。政治家であっても前後の文脈で判断するべきだと思われます。政治家の場合、氏名+役職名でも敬称と取られるかどうかは半々だと思われます。政治家にとって馴染み深い敬称って○○国務大臣とかではなく、○○先生とかじゃないでしょうか。国務大臣の○○先生と書いたら流石にダメだと思いますが、文の流れとして○○大臣のほうが自然ならそうするべきです。どちらかと言うと大臣とか市長とかはどちらかというと地位を示すものなので階級に近いものだと考えています。「首相安倍晋三」は何らかのサインや、公文書ではみかける書き方ですね。--アルトクール(/) 2014年10月27日 (月) 18:29 (UTC)[返信]
  • コメント依頼から参りました。
  • 論点が噛み合っていません。
  • ガイドラインは「肩書・敬称・学位・位階・勲」と言っています。字面通り解釈すれば、「社長」や「市長」が「敬称」に当たらなくても、「肩書」に該当してしまえば、やっぱりアウトということになります。
  • ガイドラインは、「肩書類」は人名の後だとダメだけど人名の前なら良いよ、とも言っていません。字面通り解釈するなら、前でも後ろでもアウトです。一番初めにFielderさんは肩書を後置すれば×で、前置すれば○であるかの様に示しましたが、ガイドラインを文字通り読めばどっちも×です。
  • したがって、論点は<「市長」「首相」や「役職」は「肩書」に該当するか、YES or NO>になるべきです。(私は該当するとおもいます)
  • 「肩書」がつくことが何が悪い、という論点にするのであれば、これはガイドラインを変更する議論です。(市長や首相は肩書ではない、という主張であればまた話は変わってきます。)
  • あまり論点になっていないようですが、「肩書とか」を前につけるか後ろにつけるかに関連して、「敬意」とは無関係に、次のようなことを指摘できると考えます。
Fielderさんが最初に提示したうち「捕手」とかまで「肩書」と言えるのか、これは悩みます。捕手だとややわかりにくいですが、「外野手」に置き換えるとわかりやすい。「外野手として選手登録されているから『外野手』も肩書だ」と主張することは、一応できそうです。しかしそれでは「左翼手」は?「内野手」で登録されている選手が、試合の途中で二塁手から左翼にまわり、さらに投手に交代したら?こう考えると、「捕手」は文脈によって単純に属性を表す肩書だったり、それ以上の意味を内包した説明だったり、変わります。次の2文を読んでいただくと意味が伝わるかなと思います。
  • 田中捕手がキャッチした。
  • 捕手の田中がキャッチした。
精緻に分析しようとすると、この2文は意味が異なります。こうするとその違いが明確になります。
  • 捕手がキャッチした。
  • 田中がキャッチした。
こうすると、「捕手」という語の位置は「敬意」とは無関係に文意を変えることがわかります。
ただまあ、ふだんはここまで厳密に文章を分析なんかしませんから、過度に気にすることもないようにも思います。
  • 私は、肩書や役職・役割が付記されることは、単純に文章をわかりやすくするために役に立つと思います。田中って誰だよ、って話になっちゃいますからね。「運転手の田中は」と書かないと、田中がどういう立場で文脈に関わってくるのかわからなくなってしまいます。たとえば「運転手の田中は」と「運転していた田中は」では、文に含まれる情報量が違いますよね。前者は田中が社会的に運転手という立場を有していることは示していますが、厳密には運転していたかは不明です。後者はその逆。推理小説のレトリックみたいなもんですね。しかしふつうは「運転していた田中運転手は」とは書きません。鬱陶しいですから。したがってガイドラインから「肩書」を除去しちゃえばいいな、と考えます。
  • 「肩書」・「役職」には「敬意」が含まれるからダメである、と主張するのであれば、やはりガイドラインの見直しが必要でしょう。
  • Wikipedia:表記ガイド#人名Wikipedia:スタイルマニュアル#人物・人名も、「敬意の存在を問題視します」とは明記していません。単に、名前に付加物をつけることで冗長になるのを回避しようとしているだけに見えます。現代の日本の我々にはあまり縁がないですが、王族にいろいろくっつけて正式に書こうとするとどえらい長いことになりますよね、ヒズマジェスティーなんちゃらかんちゃらオブなんちゃらアンドなんちゃら、みたいな。「正二位なんとか将軍なんたらのかみなんとか源朝臣なんとか三郎左衛門」みたいに書かずに「源頼朝」にしようね、というだけじゃないでしょうか。少なくともガイドラインは「意図」までは語っていません。
  • 敬意表現の存在が記述の中立性を妨げるからダメなんだ、という理屈は、(共感するかは別として)理解はできるものです。そうであるならば、そう明記する方向でガイドラインの修正を図るべきでしょう。
  • 敬称に詳述されていますが、「敬称」というのはその語に自動的に敬意が織り込まれているものです。「天皇」は敬称ではないですが「聖上」は敬称です。「社長」「部長」「首相」などはいずれも組織や団体における役割・役職を説明する中立的な語であり、敬称ではありません。その役割・役職に対して敬意が生ずるかどうかは相対的なものです。たとえば社員が自社の社長を外部に紹介するときは「これが社長のAです」とか社長が「○○部長を呼べ」といった場合に、これらの語には敬意は生じていません。「天皇」ですら、たとえばGHQ司令官が「天皇を呼んでこい」とか、アメリカ兵が「天皇を打倒するぞ」という場合があるわけで、「天皇」という語には自動的に敬意が織り込まれているわけではありません。これが「陛下を呼んでこい」「聖上を打倒するぞ」になれば、自動的に敬意が織り込まれています。「大臣」も「お前じゃ話にならん、大臣出せ!」と言った時にはここには敬意など存在しません。単に「話の通じるやつを出せ」といっているだけです。「お前じゃ話にならん、閣下を出せ!」だと敬意表現です。したがって「敬意を含む表現は中立的じゃないからダメよ」という主旨なのであれば、「社長」や「市長」はOKです。
  • しかし議論の出発点であるFielderさんの問題提起(「敬称にあたる表記だから後ろにつけちゃダメ」)の時点で、いろいろとガイドラインから飛躍があるということです。。
  • 参考までに。(英語版 - 私は英語版至上主義じゃないですが、英語版では細かい説明がたくさんあり、たくさんの場合に応じた解説があります。これらを参照するのも一つのヒントにはなりそうです。斜め読みした感じでは、敬称(サーネーム)や博士などは「完全否定」されていません。Mr.やMrs.にいたるまで、つけたほうがわかりやすいならつけろ、状況によって使い分けろと言っています。英語の場合は敬意に関係なく、「President Obama」という表記はあっても「Obama President」とは普通書きませんから、前か後ろかは大きな問題にはならないようです。「誰々,役職,役職,who isなになに,」のようにカンマや関係代名詞で並置していく文法もありますが、これも「敬意」とは関係ないでしょう。また、Honorific titlesでは「honorific titles should not be deleted when they are used throughout an article unless there is consensus」とあり、「第○代なんとか男爵」みたいなのを省略しろとは言っていません。トータルとしては、敬称を用いることで中立性がどうのこうのではなく、冗長性や、他の人物と区別するのに必要であるかどうかに応じて考えろ、と言っているようです。ただし、そもそも「敬語」というのは日本語の特徴的な概念で、英語には一般的にはそういう概念はないと言われていますから、英語版をそっくりそのまま適用するのがベストかと言えばそうとも言えないでしょう。)--柒月例祭会話2014年10月27日 (月) 19:06 (UTC)[返信]

コメント 色々言いたい事はありますが、その前に「A(総理大臣)」に反対の方はいますか?「A(総理大臣)」であれば「A総理大臣」のような敬称+役職ではなく、役職だけを表記している事がわかりますし、「総理大臣のA」よりは違和感もないと思います。--JapaneseA会話2014年10月29日 (水) 16:39 (UTC)[返信]

論外です。”ウィキペディア語”を創造するつもりですか?あくまでも通常の日本語で表記することを心がけるべきあり、現状のガイドラインによってウィキペディアの表記が普通の日本語から乖離してしまうのなら、ガイドラインを改定するべきです。--uaa会話2014年10月29日 (水) 17:42 (UTC)[返信]
そもそも、正常な日本語を歪めてまで「役職だけを表記している事」を分からせる必要性が理解できませんね。政治家の言動は、それが私的なものだとしても公人によるものと捉えられるので、野球選手より役職を付ける必然性は高いでしょう。ガイドラインの欠陥を悪用して言葉狩りに血道を上げるのはナンセンスです。ところで、「役職だけを表記している事」を示すために「A(総理大臣)」なんて表記をしている日本語文書の例ってあるんですかね?--uaa会話2014年10月29日 (水) 18:18 (UTC)[返信]
  • JapaneaseAさんの提案には反対です。JapaneaseAさん以外で、このご提案に賛成の方がいれば訊いてみたいのですが、「A陛下」を「A(陛下)」に変えると敬称ではなくなりますか?日本語の文法を解説した文献などで根拠になるものがありますか?
そもそも「総理大臣」が全く敬称ではない。ガイドラインは「肩書」もアウトだと明記しているのですから、それに従えばカッコで括ったってアウトです。基本的に、役職・役割を示す語は氏名に前置しようが後置しようが、その位置によって敬意が発生したり消滅したりということはありません。「受刑者のA」「A受刑者」、「B被告」「被告のB」、これらの表現で敬意の有無は変わりません。一般に「敬称をつけるな」というのは、例えば「Aさん」と書かずに「A」と書け、ということです。「さん」は役職や役割を示す語ではなく、まさに「敬称」そのものです。政治家の「議員」「大臣」「首相」「総理大臣」「代議士」といった語は敬称ではありません。これを「先生」や「閣下」と言ったら敬意が生じます。--柒月例祭会話) 2014年10月30日 (木) 00:51 (UTC) - 後述する提案を行って議論を前に進めるため、この発言は撤回します。--柒月例祭会話2014年10月30日 (木) 03:37 (UTC)[返信]
コメント そんな提案,日本語の文章としておかしくなりますね。原則としてはたしかに肩書きとかは不要かもしれませんが,文脈によっては肩書きを書かないと逆にはっきりしない文章になることもあります。立場も意識して文章を書く場合は,後ろに肩書き付記した方が簡潔・明瞭に書けるのではないでしょうか。例えば前置きだと「の」などを1字余分に書くことになります。簡潔・明瞭に文を書くように心がけなければならないのに,余計に煩雑にしてどうするんですか。考え直してください。ここで最初に提起されたFielderさんの意見も正直極端です。もっと柔軟な考え方をなされるべきです。--かげろん会話2014年10月30日 (木) 01:56 (UTC)[返信]
  • 次節の通り提案を行いました。
すべてが人名に関するものではないですが、英語版には分野別に78もの「記事名・本文中での表記ガイド」、さらにこれとは別に80の分野別の私案があるんですねen:Category:Wikipedia naming conventions。たとえばキリスト教聖職者の場合、聖人、教皇、枢機卿、などのそれぞれの場合で、記事名はこう、リダイレクトはこう、本文ではこう記す、と細かく決められています。整備が行き届いてすごいと感じるか、そこまで決めないとトラブルが起きるということなのか・・・。--柒月例祭会話2014年10月30日 (木) 04:57 (UTC)[返信]
これまでにYhiroyuki氏から「A総理大臣」式の表記例が複数提示されていますが、このように一般の百科事典で普通に使用されている表現が禁止されていると解釈できるようなら、それはガイドラインに欠陥があると考えるべきでしょう。これまでは、冒頭の「ただし、このガイドラインはすべての記事に絶対に適用しなければならないものではありません」と「人名」節の「~付けることが慣習となっているものは例外とします」を根拠に、柔軟に対応できると考えていたのですが、そうはいかないようですね。私も改訂が必要だと思います。
ところで、JapaneseAさんは『ブリタニカ国際大百科事典』や『百科事典マイペデイア』の記述が「敬称等の使用による権威付けによって、記事の客観性を毀損している」とお考えなんでしょうか?--uaa会話2014年10月30日 (木) 11:26 (UTC)[返信]

提案

ある程度、さまざまな見解が出揃ったと思います。簡単なまとめと提案を行ないます。

  • (1)現状のガイドラインを絶対視し不動のものとするか?
「肩書」「敬称」の中身の解釈や、前置・後置による効果の差異の解釈に関し、利用者ごとの意見の隔たり・揺れ幅が大きいです。(これは敬称だ、いや敬称じゃない。前ならいい、後ろでもいい、括弧をつければ、いやどっちもダメだ)
  • (2)したがって何らかの形で現状のガイドラインを修正したほうが、解釈の隔たりをなくしたり小さくできる。と考えます。
  • (3)ひとまず合意できそうな点(明らかに問題があると皆の見解が一致しそうなこと)
  • (3-1)敬意表現を使うことで生じる中立性の問題。
  • (3-2)肩書等をつけることで冗長になること。
(3-1)「○○は敬意表現にあたるかどうか」については見解がわかれていますが、尊敬語や謙譲語・丁寧語などの敬意表現を百科事典の記事として本文に用いるのは(戦前の百科事典は知りませんが)不適当だ、という点については大筋で合意をいただけるのではないかと考えています。
(3-2)に関しては、いまのところこれを言っているのは私だけかも。
  • (4)改訂案(たたき台)
「原則禁止」「避けるべき」「のぞましい」など、規定の強度の表現にはいろいろな幅があります。原案ではひとまずそれらを用いていますが、「原則禁止」では合意できないが「のぞましい」なら合意してもよい、というような場合には、合意を優先して「のぞましい」とすることは有りだと思います。
(1)敬意表現(尊敬語、謙譲語)や丁寧語は原則として行わない。原文の引用や、両者の関係性の説明に必要な場合はその限りではない。
〔例〕
  • 「鈴木さんは」→「鈴木は~」
  • 「召し上がった」→「食べた」
  • 「信者は神に羊を渡した」→OK「信者は神に羊を捧げた」
  • 「領民は領主に酒を渡した」→OK「領民は領主に酒を献上した」
  • 「秀吉は家康に刀を与えた」→OK「秀吉は家康に刀を授けた」
※「秀吉は家康に刀を献上した」では表記ガイド以前の問題として一般的に不適当。
(2)人物の肩書、立場、役割、役職、敬称、尊称、学位、位階、勲、爵位などは、冒頭や第1段落など早い段階で紹介するに留め、記事本文中では省略する。記事本文中で代名詞として用いたり、その都度人名と合わせて表記することは避ける。(Wikipedia:スタイルマニュアル_(人物伝)#敬称
*○ オバマはアメリカ大統領である。オバマは2013年にこれこれのことを行った。
  • × オバマはアメリカ大統領である。大統領は2013年にこれこれのことを行った。
  • × オバマはアメリカ大統領である。オバマ大統領は2013年にこれこれのことを行った。
  • ○ オバマはアメリカ大統領である。アメリカ大統領というのはアメリカ合衆国の最高責任者のことで、大統領は軍隊の統帥権を持っている。
  • ○ オバマはアメリカ大統領になり、オバマは軍隊の統帥権を持つことになった。
  • × オバマはアメリカ大統領になり。大統領は軍隊の統帥権を持つことになった。
(例のいくつかは肩書をつけるつけない以前の問題ですが。)
(2-0)歴史上の人物など、肩書、立場、役割、役職、敬称、尊称、学位、位階、勲、爵位なども含めてその人物の固有名詞として扱われているような場合には、この限りではない。
〔例〕
  • 聖徳太子、後醍醐天皇、後鳥羽上皇など
  • 大井夫人(武田信玄の母) - 「大井」「夫人」のいずれかでも省略してしまうと文意の把握が困難になる。
(2-1)文中においてその人物の立場・役割を明らかにしたほうが説明や文意の理解に寄与する場合にはこの限りではない。
*△ 佐藤は鈴木に責任があると言い、田中は佐藤の指示でやったと言い、鈴木は佐藤が責任を負うべきだと述べた。
  • ○ 佐藤部長は鈴木社長に責任があると言い、田中課長は佐藤部長の指示でやったと言い、鈴木社長は佐藤部長が責任を負うべきだと述べた。
(2-1)鈴木さんが、村議から県議、国会議員となり、同時に国土交通大臣と外務大臣を兼務した場合で、その行動が「大臣」としての立場に基づくものなのか、国会議員としてのものなのか、区別を要するような場合には、役職を明記したほうがよいこともある。
*○ 鈴木は建築計画を承認した。
  • ○ 鈴木国交大臣は建築計画を承認した。
  • △ 鈴木国交大臣は地元の村で餅つき大会に出た。
  • × 鈴木国交大臣は外務省の役人に指示した。
あまり上手な例じゃないですが、例えばイギリス貴族で複数の爵位を持っていて、状況によって爵位を使い分けている場合には、それに応じた記述を行うことは妥当。「ノルマンディー公リチャード1世はフランス王の臣下だが、イングランド王リチャード1世はそうではない。」→「リチャード1世はフランス王臣下である」とするとおかしなことになる。
(2-2)文意に直接関係ない肩書、立場、役割、役職、敬称、尊称、学位、位階、勲、爵位などを書き加えることは避ける。
*○ 教育委員会の会合で佐藤校長はこう述べた。
  • × その喫茶店のケーキの味を佐藤校長は高く評価した。 - 「校長」であることと「味の評価」の正当性に有意な相関関係があるとは普通は結びつかない。
  • ※鈴木が料理学校の校長であれば話は変わる。あるいは、鈴木が学校長の立場でこう発言したことで教員や生徒がその喫茶店に行くようになった、ということを説明しようとするなら妥当である。
*△~× 二死満塁の場面で鈴木外野手が代打で登場し、サヨナラホームランを打った。 - 「外野手」であることがほとんど文意に関係ない。しかしチーム内に鈴木が複数いて、片方が内野手だというような場合には区別のための記述としては役に立っている。「田中投手が代打で登場し」というように、ふつうは代打で登場しないと考えられている「投手」が代打で出たことが特徴的なのであれば記述は役に立っている。
*△~× レースの後、マーシャルは敗因はこれこれだと述べ、ホワイトは敗因があれだと述べた。
  • ○~△ レースの後、マーシャル騎手は敗因はこれこれだと述べ、ホライト調教師は敗因があれだと述べた。
  • × レースの後、ウィリアムは敗因がそれだと述べた。
  • △~× レースの後、ウィリアム調教師は敗因がそれだと述べた。
  • ○~△ レースの後、テレビ解説者のウィリアムは敗因がそれだと述べた。
  • ○ レースの後、テレビ解説者のウィリアム調教師は敗因がそれだと述べた。
じゅうぶんな知名度があるとか、既に記事中で繰り返し登場しているとかでなければ、役割を省略すると、どういう関係なのかわかりにくくなる。「ウィリアム」の事例では、「調教師」だけでは誤解を招くし、単に「テレビ解説者」とするより「テレビ解説者」かつ「調教師」であることを両方示せば、その見解の立場と信頼性が読み取れるようになる。
「ウィリアムテレビ解説者」のような書き方は日本語として一般的でないので、「テレビ解説者のウィリアム」のように前に置くしかない。英語の場合には、カンマや関係詞を用いて複数の「役職・肩書の類」を並置していくことができる。日本語では「作家で横綱審議委員の鈴木大臣」のように、前や後ろにつけるしか無いが、この例だと「大臣」がメインの肩書であるような扱いになるので、文意に応じた記述に配慮する。

ひとまず注釈・例文過多ですが、いかがでしょうか。--柒月例祭会話2014年10月30日 (木) 04:37 (UTC)[返信]


私も改定するべきだと思いますが、この案は率直に言って「注釈・例文過多」だと思います。私は、改定の目的として、ウィキペデイアの表記と他の百科事典をはじめとする文書との整合性を第一におくべきと考えています。その観点からすると、例文は少ない方がいいでしょう。全ての分野で共有できる表現を網羅できるわけ無いですから。あまり例文を細かく挙げると、それらに該当しないものは全てダメと解釈する人が出くるでしょう。現に、可能とされる例に無いからダメと主張した人もいますし[9]。また、各論を言うと、例えば「オバマはアメリカ大統領である。大統領は2013年にこれこれのことを行った。」は”あり”だと思いますので、このような表現が制限されるのは望ましくないと考えます。それと、(1)の「鈴木さんは→鈴木は~」以外は”人名の表記”の指針ではなく、”人物の扱い”ですね。当該節で扱うものではないと思います。そこで、私の案ですが、シンプルに

①原則として、人名に「~様」や「~さん」のような敬称は付けないでください(Wikipedia:スタイルマニュアル#人物・人名によります)。但し、これは付けることが慣習となっているものまで付けてはいけないということではありません。
②肩書、立場、役割、役職、学位、位階、勲位、爵位などは、その人物が記事中何度も登場するような場合、その都度人名と合わせて表記すると文章が冗長になるので、適宜いずれかを省略してください。但し、その人物の固有名詞として扱われているような場合など、文脈的に誰なのか分からなくなるようなものは省略しないでください。
③故人において、人名の前に故を付けたり、人名の後に(故人)や(物故者)を付けたりしないでください。

で如何でしょうか?細かい規制は無い方がいいと考えます。--uaa会話) 2014年10月30日 (木) 12:31 (UTC)案の一部を修正--uaa会話2014年10月30日 (木) 16:02 (UTC)[返信]

  • コメント 「A(大臣)」に反対が多く、論外だの、考え直せだの、えらい言われようですが、[10]で普通に使われています。それに役職A、A役職の両方を書いてもいますね。私の主張は、「A大臣」が必ず敬称になるとは言わないが、「A大臣」と書く事で敬称になる場合が多々ある。「大臣A」も「A(大臣)」も別におかしな表記ではない。Wikipediaでは敬称は例外(付けないと意味不明になるとか)を除いてつけるべきではない、です。さて、現状のガイドラインでは、不十分と判断し、改訂・追加に賛成します。文案は柒月例祭様の文案のように「例文が多い」方が良いと思います。ただし例文に載っていないものは、「×」ではなく、「〇でも×でもないもの」とすれば良いと思います。個別に言うと、(1)は家康と秀吉は判断つかず、他は賛成。(2)は賛成。(2-0)賛成。(2-1)は要検討。なおイギリス貴族の例は判断つかず、(2-2)は、「〇〇高校学校長佐藤××はこう述べた」にすべき。野球とレースは保留。なお、uaa様の文例では、「A大臣」なのか「大臣のA」なのかわかりません(「A総理大臣は慣習だ」という人と、「慣習でない」という人がいるはずです、私は後者ですが)。--JapaneseA会話2014年10月30日 (木) 14:25 (UTC)[返信]
この例示は、文脈的に「祖父は岸信介。総理大臣を務めた人物だよ。」ということであり、議論されているケース全般に通用するものじゃないでしょう。「岸信介首相が日米安保条約を締結した」と「岸信介(首相)が日米安保条約を締結した」のどちらが普通の表現だと思いますか?「「A大臣」が必ず敬称になるとは言わないが、「A大臣」と書く事で敬称になる場合が多々ある」という考えは支持を得られてませんが、根拠を理論的に説明してください。それ以前に、再度お尋ねしますが、『ブリタニカ国際大百科事典』や『百科事典マイペデイア』の記述が「敬称等の使用による権威付けによって、記事の客観性を毀損している」のか否かお答え願います。ブリタニカの記述を否定するからには、それなりに説得力のある説明が必要ですよね。それと、ついでに伺います。柒月例祭氏案について各個に賛否を表明されてますが、その理由は?理由が示されないと議論が進みません。「(2-2)は、「〇〇高校学校長佐藤××はこう述べた」にすべき」なんて個人的な感覚で言われても無意味です。
先ほどの提案への反対意見に対する反論と補足を。
>「A大臣」なのか「大臣のA」なのかわかりません。
そもそも、こういうのは文脈で判断すべきものであって、どちらかにしなければならないという考えがおかしいんですよ。「当時の大臣はAで、~した」というような文脈では、「大臣のA」でいいでしょう。故に、無い方が変な誤解を受けないという考えです。逆に、例文を入れるなら少なくとも両方のパターンを併記すべきですね。柒月例祭氏も、「前と後のどちらに付けても敬称や肩書きであることには変わらない」とお考えなら、そうすべきでしょう。
>「A総理大臣は慣習だ」という人と、「慣習でない」という人がいるはずです
私の案では、①にて原則として使用しないこととする対象を「「~様」や「~さん」のような敬称」に限定し、肩書き等については、②で冗長となることへの注意に止めることとしました。よって、「A総理大臣」が慣習か否かが問題になることはありません。
それと、柒月例祭氏案(2-2)に相当する規定を設けなかったのは、この規定自体に反対だからです。文意との直接関係の有無で揉めるだけです。そもそも、「ケーキの味をは高く評価した」のが「佐藤校長」だと不都合なケースが想像できません。--uaa会話2014年10月30日 (木) 16:02 (UTC)[返信]
コメント 直接内容に関係することではありませんが、重要な事なので。丸付き数字はなるべく使用しないでください。環境によっては表示がおかしくなります。--アルビレオ会話2014年10月30日 (木) 23:30 (UTC)[返信]
今後の議論の便宜上、柒月例祭氏の案の項と区別するために丸付き数字としました。反映させる際は普通の数字にします。ここでの議論を追うのに見苦しいのであれば、書き換えます--uaa会話2014年10月31日 (金) 09:31 (UTC)[返信]
コメント uaa様へ。「どちらが普通の表現だと思いますか?」について、どちらも「普通」だと思いますよ。ただし百科事典としては前者だと「なぜ敬称にする?」と思いますし、新聞ニュースであれば「なぜ敬称にしない?」と思います。「根拠を理論的に説明してください。」について。常識ですが、「人名+役職」は敬称を含むと判断されます。[11][12]など探せば出てくると思います。なので「可能な限り避けるべきだ」と主張します。「再度お尋ねしますが」について、ブリタニカなどを熟読していないので、わかりかねます。これらでは「A大臣」か「大臣A」かは、多分ケースbyケースなのでしょう。もしブリタニカ日本語版が全ての記述で(基本的に人名を呼び捨てにしているのに)「A大臣」と表記しているのであれば、「記事の客観性を毀損している」と判断します。「ケースbyケース」には、最初から異論はありません。争点は、「A大臣」とするべき(しても良い)ケースの範囲です。私は狭く、貴方は広いのでしょう。根本的な話ですが、私と貴方が今この場で議論しているのは、この編集です([13] )。この編集のケースでは、私は「A大臣とすべきではない」と判断したので修正しました。それをRvしたのですから、明確にこのケースでは「A大臣とすべきだ」と判断したのでしょう(どちらでも良ければRvなどしないはずです)。「各個に賛否を表明されてますが、その理由は?」議論の混乱を避けるため、回答を一旦保留します(ここを話す段階でない)。「どちらかにしなければならないという考えがおかしいんですよ。」との事ですが、ある程度、決めておかないと、今後様々な記事で、私と貴方が編集合戦や論争をする事になります。「A大臣」とするべき(しても良い)ケースの範囲考え方が大きく異なるのですから。それ以前に現在Wikipedia日本語版では、同じケースなのに「A大臣」と「大臣A」が混在しています。方針・ガイドラインを決めておくべきと判断します。--JapaneseA会話2014年10月31日 (金) 04:47 (UTC)[返信]
  • コメント いろいろ考えたのですが、以前に私が言ったことや提案内容と違うことを言います。(すみません)
  • 結論だけ言うと、「多様な表記スタイルを容認する」方向で合意はできないでしょうか。
私は「ガイドラインが厳密でない」ことよりも、「これはだめだろ、いやいいだろ」と言ってrv争いが起きることのほうが問題と感じるんです。だから「どっちもOK」で収められないかなと。
まず、「敬称」なる述語に難があるように思います。「敬称」には、「尊敬の念」を込めて用いるものと、「へりくだって」用いるものと、「礼儀作法」として用いるものがあるように思います。同じ語でも状況・読み手で変わります。「蔑称」も敬意の存否を示すと考えれば、語句はさらに増えます。
たとえば「さん」はふつうは礼儀作法だし、「閣下」は「尊敬の念」です。ところがある条件下では、たとえば旧日本陸軍では上官を「さん」付けしたら失礼だけど旧日本海軍なら「さん」付でも失礼じゃないとか、変わります。昭和天皇を「裕仁さん」と呼んだら「おれは天皇制なんて認めないんだぜ」という含意を持っていると看做されるでしょうけど、昭和皇后が昭和天皇を「裕仁さん」と呼んだら親愛の念でしょう。
たとえば、安倍首相を侮蔑している物凄い左翼の人がいたとして、その人がテレビに出たらやっぱり「安倍総理大臣は~安倍さんは~」と言うと思うんですよ。それは敬意を持っているからじゃなくて、テレビで「安倍は~」って呼び捨てしちゃうと自分が失礼な人・偏向した人・中立じゃない人というような印象を持たれてしまうからじゃないかなと。この場合は「礼儀作法」として添えられている。
NHKニュースでアナウンサーがこう言っても、きっと多くの人は何にも感じないと思うんです。
  • 今日の午後の記者会見で安倍総理大臣はこう言いました
ところが
  • 今日の午後の記者会見で安倍はこう言いました
って言ったら、支持政党とか関係なく、NHKちょっとそれはどうなの?と感じるんじゃないかと思うんですよね。いってみればこんな感じです。
  • 安倍大臣閣下 敬意 +1
  • 安倍総理大臣 普通 ±0
  • 安倍     失礼 -1
ここで基準を1つ下へスライドすると
  • 安倍大臣閣下 敬意 +2
  • 安倍総理大臣 敬意 +1
  • 安倍     普通 ±0
こうなります。こうみると、「総理大臣」がつくことで敬意表現だという主張もわかります。逆もまた然り。
  • 安倍大臣閣下 普通 ±0
  • 安倍総理大臣 失礼 -1
  • 安倍     失礼 -2
これは、同じ表現でも、状況や受け手によって「敬意の存在」を感じるかどうかが変わると思うんです。ある単語を付与することで敬意が表に出ると考える人・場面もあれば、それが無いことが侮蔑ととる人もいる。
たとえばエリザベス2世を「イングランド女王陛下」と表現すると、「スコットランドの女王じゃないんだぜ」ってことを含意していると感じるかもしれません。
紙の百科事典や論文が「敬称」を省いているのは、中立性や客観性を気にしているより、物理的な紙面の都合で「文字数」を気にしているだけかもしれません。減らした分だけ他の情報を詰め込めるわけですから。
難しいです。「さん」だけみても状況によって丁寧だったり無礼だったりするわけですから。
難しいんですが、しかしこうも思うんです。
  • A
  • A総理大臣
  • 総理大臣のA
  • A(総理大臣)
このどれを選んでも、実際のところ、中立性・客観性や冗長性は、そんな大して変わらないんじゃないかなと。だったら「どれでもOK」で合意することはできないでしょうか?どれでもOKならば、「そこだけを書き換える」ような編集合戦のようなものは回避できるでしょう?
肩書・役職を完全に除去すると、文意がわかりにくくなるのは自明だと思うんですよ。南北戦争の翻訳記事とかで、読んでいて途中から「この人は南軍だっけ?北軍だっけ?」ってなっていちいち戻って確認しないと意味がわからない、ってことないですか?だから極端に冗長になってしまうのでなければ、適度にはあったほうが意味がわかりやすい。
役職があると中立性が損なわれるから絶対にダメだよ、と感じる方もいるでしょうが、「役職」つけない事自体が対象に対する侮蔑の念を含意していると感じる方もまたいるでしょう。そうなるとやっぱり中立的じゃない。
「敬称」と一口にいっても、<A群>「さん」「様」「殿」みたいなもの、<B群>「閣下」「猊下」みたいなもの、<C群>「総理大臣」「社長」みたいなもの、いろいろなものがあります。蔑称も敬称の1パターンだと考えると更に広がります。
  • A群は冗長性の観点から原則使わない
  • B群は中立性の観点から原則使わない
  • C群は文意や文脈に応じて多様な表記スタイルを認める。著しく冗長だったり、著しく中立性を損なうということでもなければ、表現方法の一種として執筆者のスタイルを尊重する。
ちょっとまだこなれていないんですが、こんな雰囲気の方向性で合意することはできないでしょうか?
いや「社長」はB群だろ、というようなタイプの反論や、「とにかく敬称は一切合切除去しないと中立的でない」という主張をされてしまうとちょっとどうにもならないのですが、どうでしょう。--柒月例祭会話2014年10月31日 (金) 07:01 (UTC)[返信]
私の考えも柒月例祭さんと概ね同じです。故に、上記私の案では、①に於いて「原則使わない」とする対象をA群に限定しました。「「A大臣」が必ず敬称になるとは言わないが、「A大臣」と書く事で敬称になる場合が多々ある」なんて珍説を振り回して”敬称的ではない”用法で付されている役職名まで片っ端から書き換えるような編集も防げると思います。
件の編集は「Wikipediaでは陛下でさえも呼び捨てです」なんて、現行ガイドラインに照らしても間違いが明らかな理由でしたが、いずれにせよ、そのようなトンチンカンな理由での言葉狩りはRvの対象ですね。
JapaneseA氏の「「人名+役職」は敬称を含むと判断されます~ので「可能な限り避けるべきだ」」との主張は全く受け入れる余地がありませんね。「役職には敬称の意味が”含まれる”」から即「中立性を損なう」とするのは理論の飛躍であり、大きな間違いです。相手を呼ぶときの「○○部長」には敬称の意味があるでしょうが、全ての文脈に於いて敬称の意味があるとはいえないでしょう。現に、これまで議論に参加者した皆さんも、多少の認識の違いはあれ、中立性が損なわれるような敬称ではないという点では共通しており、「とにかく敬称となりうるものは一切合切除去しないと中立的でない」の如き主張をしているのは一人だけですよね。それに、文脈に関係なく「敬称の意味が含まれるものは一切ダメ」と言うなら、前に付けても同じことでは?あなたが示した”常識”とやら[14][15]でも、「役職名には敬称が込められています」とは書いてますが、「「人名+役職」だと敬称だ」とは書いてません。まあ、常識で考えて、「部長○○」が敬称とは思えませんけどね。逆に相手を「部長○○」なんて呼んだら殴られるでしょう。だとすると、新聞や一般の百科事典で「安倍晋三首相」と表記されているものを「首相の安倍晋三」とすれば、逆に筆者の悪意が感じられ、かえって中立性が損なわれるということになります。つまり、前に付けても中立性が損なわれるのですよ。そうなると、新聞や一般の百科事典に倣うのが無難でしょう。「百科事典としては~「なぜ敬称にする?」と思います」なんて個人の思い込みとしか言いようがありませんね。「もしブリタニカ日本語版が全ての記述で(基本的に人名を呼び捨てにしているのに)「A大臣」と表記しているのであれば、「記事の客観性を毀損している」と判断します」なんて言われても説得力を微塵も感じません。ブリタニカと一ウィキペディアンの”判断”のどちらが信用に値するかは常識で考えればわかりますよね。--uaa会話2014年10月31日 (金) 09:31 (UTC)[返信]
コメント 柒月例祭様へ。仮に「いかなるケースでも「大臣A」と「A大臣」のどちらを使用してもOK」としたとしましょう。そうなると私が「大臣A」に書き換える。で、相手が「A大臣」にRvする、と編集合戦になります(両者ともルールを守っていますよね、どちらを使用してもOKなのだから)。しかも合意点がありません。これを合意するために、このようなケースでは「A大臣」、このようなケースでは「大臣A」と決めるべきだと思います。また、「「役職」つけない事自体が対象に対する侮蔑の念を含意」との事ですが、Wikipediaでは「松田聖子は~をした」のように表記します。これが新聞ニュースなのであれば、どう考えても失礼です。つまりWikipediaでは「-1」状態を通常としているわけです。ですので、「Bさん」「A大臣」であれば中立的ですが、「B」「A大臣」では、不公平というものでしょう。「テレビで喋る人が、嫌いな政治家に敬称をつけるけど、そこに敬意はない」それは当然そうでしょう。私は「記述に敬意を込めるな」と主張しているのではありません。BさんをBと表記する以上「政治家という一部の記述にだけ礼儀的表現を持ち込むな」と主張しているのです。もし「Bさん」と表記する方針に変えるのであれば、勿論「A大臣」とすべきですが。--JapaneseA会話2014年10月31日 (金) 10:02 (UTC)[返信]
コメント uaa様へ。「もしブリタニカ日本語版が全ての記述で~」と申しましたが、「もしもブリタニカがそんなおかしな応対だったら」という仮定であり、実際にはそんな事はありません。その仮定に対して「説得力を微塵も感じません。~」と批判されても困ります。また、トンチンカンだの論外だの珍説だの、もう少し言葉使いはなんとかなりませんか?「それは貴方独自の考えであって」というような丁寧な表現でも全否定はできますよ。私は聖人君子ではないので、必要以上に攻撃的な言葉を言われると、その意見に耳が傾けるべきものがあっても、そこが見えなくなる恐れがあります。「”敬称的ではない”用法で付されている役職名」との事ですが、その判断が私と貴方、あるいは他の方で違うのでしょう。それを明確にすべきだと、申しているだけです。「「首相の安倍晋三」とすれば、逆に筆者の悪意が感じられ、」との事ですが、BさんをBと表記して、役職付の人だけ「A大臣」のように表記されるのは中立的でしょうか?なお、議論の白熱化を防ぐため御返事は24時間以上を置きます。--JapaneseA会話2014年10月31日 (金) 10:02 (UTC)[返信]
>BさんをBと表記して、役職付の人だけ「A大臣」のように表記されるのは中立的でしょうか?
>「Bさん」「A大臣」であれば中立的ですが、「B」「A大臣」では、不公平というものでしょう。
「不公平だから中立的ではない」というのも理論の飛躍ですが、役職付の人だけ「A大臣」のように表記ても不公平ではありません。公平と横並びを勘違いしているのでは?文章内で、属性を示す必要のある人物にだけ役職等を付すのは合理的ななことです。そもそも、役職付の人とそうでない人を列記する際に、無理矢理同じ扱いにすることの方が逆に不公平でしょう。人物の上下関係などを客観的に書き分けることこそ中立的な記述なんですよ。それ以前に、「さん」「様」と役職名を敬称としてひとくくりにし、同列に扱っているのは、それこそ「貴方独自の考え」ですね。他の人達の意見にも少しは耳を傾けてください。--uaa会話2014年10月31日 (金) 11:17 (UTC)[返信]
うーん。「どっちでもいいよ」というルールのもとで自分の好みに編集しあう合戦と、「ルールの解釈」を巡っておきる編集合戦とは次元が違う、と私は思ったのですが、ダメですか・・・。
もうひとつ私が言いたかったのは役職なんかは礼儀でつけているんじゃなくて、話をわかりやすくするためにつけていて、なおかつ「名前+立場」形式の場合には、その表現が日本語として有りの場合には「立場の名前」「立場である名前」形式よりも冗長でない、ぐらいの理由で選択しているだけじゃないのかな、ってことなんですよね。「歌手の松田聖子」はありでも「松田聖子歌手」という表現はないので、前者しか選択できない。「歌手の松田聖子さん」とするのは次のステップ。
どうやらここは価値観を共有できない点なのかな、と思うのは、<BさんをBと表記して、役職付の人だけ「A大臣」のように表記>しても、私は中立性には大して影響ない、と感じるところなんです。とか「オバマとエリザベス2世女王陛下」みたいに書いたらちょっと勾配を感じますけどもね。例示してるのが「大臣」だからアレなだけで、Cさんを「C」と書き、Dさんを「D運転手」としたってどうってことないかなと。この場合に実はCも運転手だ、というならまた傾斜が発生しますけども。(24時間以上置く、というのはいいですね。お互いに。私もそうすることにします。)--柒月例祭会話2014年10月31日 (金) 12:05 (UTC)[返信]
コメント こんばんは。知ったお名前がいくつか見受けられ、また時間が取れない中で、こうして議論に介入するのは躊躇するのですが、人物伝を中心に書いてきた一ユーザーとして一言。
発端であるFielderさんの編集[16]を拝見しました。この案件は、私でもRvしたうえで抗議したと思います。JapaneseAさんの「橋下徹大阪市長」→「大阪市長橋下徹」は微妙ですが、まぁそのままでも良かった気がします。あの怒号会談も、一応は市長としての公務として行った物ですから。
私がJawpに参加したのは2006年ですが、とにかく諸先輩方から散々に言われてきたことは、「方針・ガイドラインの字句に固執するな」「どのような意図・経緯で書かれたものかを見ろ」です。そりゃそうです。記事の「質」を高めるはずが、方針・ガイドラインに則ったら文章がおかしくなりました、では本末転倒です。
個人の役職を後ろに付けたら自動的に敬称になり、前に付けたらそうでない、などということはありません。全体の文脈から判断すべきです。
記事 "安倍晋三" の中で、「安倍総理大臣、安倍総理、総理」 と連発するのは避けるべきです。しかし他の記事中で、例えば「安倍晋三首相と習近平国家主席が会談した。会談で安倍と習は北朝鮮の核問題で意見の一致を見た。」 などと書いて、何の不都合がございましょうか。--Ashtray (talk) 2014年10月31日 (金) 12:42 (UTC)[返信]
  • コメント Ashtray様の文例は、2者が出ている事によって、敬称という意味合いが薄れています。一方、これが単独で出た場合は、(私は)違って見えると思います。柒月例祭様の仰る事も理解できますし、常に編集合戦となるとは思っていません。これが「異議を唱えられただけ」であれば、相手の顔を立てて今後はその手の編集(A大臣→大臣A)を控える・関らない(自分が記述する際のみ大臣Aとする)としても良かったのですが、Rvされた以上「自分が記述する大臣Aも許されないのか?、コミュニティで決めてくれよ」となるわけです。uaa様の「他の人の意見に耳を傾けろ」という主旨のコメントですが、柒月例祭様の文案について、私は「ここは賛成、ここは保留」のように表明していますが、他の人の意見に耳を傾けているとは判断されませんかね。貴方と私を除いて今のところコミュニティの総意は「A大臣も認める」ように感じますが、貴方のRv行為を「当然だ」とする程の強いものとは感じません(戦闘アカウントと揶揄される私に明確なNOを言いたくないだけかもしれませんが)。--JapaneseA会話2014年11月1日 (土) 17:46 (UTC)[返信]
>他の人の意見に耳を傾けているとは判断されませんかね。
他の人にされた指摘に対する理論的な反論や同意の意思表示などは録にせず、「ここは賛成、ここは保留」なんて言ってるようでは、「他の人の意見に耳を傾けているとは判断」できませんね。理由も述べずに賛否だけ表明するのは合意形成の妨害にも見えます。
>戦闘アカウントと揶揄される私に明確なNOを言いたくないだけかもしれませんが
意味がわかりません。
>貴方と私を除いて今のところコミュニティの総意は「A大臣も認める」ように感じますが、
私も「A大臣も認める」でしょう。「中立性が損なわれる」なんて言ってるのはあなただけです。
>貴方のRv行為を「当然だ」とする程の強いものとは感じません
件の編集では、要約欄のコメントが「Wikipediaでは陛下でさえも呼び捨てです」と、現行ガイドラインに照らして明らかな間違いがあり、文脈的に違和感が出るような形で「首相の安倍晋三」へ書き換えられていました。よって、「Rv行為は当然だ」と思っています。そして、あなたがFielder氏と同様の勘違いをしていると思い、ここに誘導した次第です。「陛下でさえも呼び捨て」からは、Fielder氏より重症だとも感じました。まあ、Fielder氏は「ルールだから」と編集を続けてたわけですが、書き換え後の文章に違和感を感じてたようなので、あなたよりは軽症でしょうね。それにしても、御自身の言語感覚が絶対的に正しく、他のウィキペディアンの方々やブリタニカが間違っているとでもお考えなんですか?--uaa会話2014年11月1日 (土) 18:41 (UTC)[返信]
コメント 「敬称だ」と判断し修正した私に、「敬称でない」という貴方の見解がコミュニティより支持されたと判断しています。要約欄については、A大臣が敬称であれば「陛下でさえも呼び捨てです」は適切であり、A大臣が敬称でなければ不適です。要約欄についても、コミュニティより同様の判断が下されたと思います。一方、「文脈的に違和感が出る」との事ですが、私はそうは思いません。貴方の版でも私の版でもどちらでも違和感を感じません。私の中では、今現在の論点は、Rvする程に「文脈的に違和感が出る」編集だったのか?です。「御自身の言語感覚が絶対的に正しく」またえらい言われようですが、「今のところコミュニティの総意は「A大臣も認める」ように感じます」と自身の反対意見を認めています。貴方のコメントには、私を悪者にする印象操作のようなものを感じますね。--JapaneseA会話2014年11月2日 (日) 19:35 (UTC)[返信]
>またえらい言われようですが、~。
複数の方から「中立性の問題など発生しない」と指摘され、あなたの意見を支持する人は皆無にもかかわらず、「一方これが単独で出た場合は、(私は)違って見えると思います。」の如き妄言を繰り返してるんだから、「御自身の言語感覚が絶対的に正し意図思ってるんだろう」と言われても仕方ないでしょう。
>「文脈的に違和感が出る」との事ですが、私はそうは思いません。
当方は既に2回以上は理由も述べているはずですが、あなたは「思います」とか「思いません」としか言ってませんね。いい加減、根拠を基に客観的事実を述べてくださいよ。あなたの脳内基準など聞くつもりは微塵もありません。
>「陛下でさえも呼び捨てです」は適切であり
Fielder氏は、当ガイドラインを額面どおりに受け止め過ぎていただけですが、あなたは当ガイドラインを録に読んでないことがこの発言にからよくわかりましたね。
>私の中では、今現在の論点は、Rvする程に「文脈的に違和感が出る」編集だったのか?です。
そんな下らないことにいつまで拘泥してるんですか?虚偽の理由に基づいた編集がRvされるのは当然です。そもそも、この節は問題が浮き彫りになった当ガイドラインの改定案のを目指してるんですよ。明らかに議論拡散行為です。これ以上、私怨に基づく合意形成の妨害を続けるのはやめてください。この発言により、あなたのウィキペディアへの参加姿勢に重大な疑念が生じました。「悪者」扱いされても文句言えない状態になってますよ。--uaa会話2014年11月3日 (月) 13:41 (UTC)[返信]
Rvされた事を恨んでいるのではなく、Rvされた理由を知りたかったのです。要は要約欄が不適切なのでRvという事でしょうか?で、あればそのRvには納得はしませんが、これ以上文句は言いません。「この節は問題が浮き彫りになった当ガイドラインの改定案」を目指すのであれば、それには賛成します。--JapaneseA会話2014年11月4日 (火) 08:41 (UTC)[返信]
無視できない発言があったので、利用者へのコメント依頼としました。--JapaneseA会話2014年11月4日 (火) 09:18 (UTC)[返信]

(インデント戻します)Rvや、それにともなう作法や礼儀に関しての問題と、この表記ガイドの議論はひとまず切り分けましょう。

ここまでのみなさんの見解で、「○○は敬称にあたるか」に関しては見解がわかれました。
(記事が完璧かどうかはさておき)敬称に列挙されているもののうち<A群:敬称#接尾詞型敬称#代名詞型敬称#接尾詞型かつ代名詞型敬称#「下」の付く敬称>までは、見解の相違なく、本文中で人名につけるのは不適当だ、と合意できるのではないかと考えています。
その次の<B群:敬称#職業で用いる呼称(肩書き)>が今回、見解がわかれたところだと思います。
しかし、11月2日(19:35 UTC)のご発言で、JapaneseAさんはこの点について譲歩をしていただいたと理解しています。
その結果として、「A群は不可、B群は許容範囲内」という方向でおおよその合意が得られそうではないでしょうか。
細かいことを言うと「尊」は神道や仏教系の記事とかではよく用いるように思うのですが、それが中立性を損なっているかといえばよくわからない。(「ヤマトタケル」はOKだけど「ヤマトタケルノミコト」と書いたら中立性を損なうかと言えば、そんなことはないように思いますが…。どうなんでしょう。)
私は10月30日のuaaさんの提案文は、シンプルでよい内容じゃないかなあと思います。JapaneseAさんは私の案との比較上、「例文の多いほうがよい」という趣旨のことをおっしゃっていますが、例文を提示するかどうかはおいといて、この文案はどうでしょう。
難点は(1)で「「~様」や「~さん」のような敬称」と表現しているところです。ここで「敬称」と言ってしまうと、「敬称」を広く解釈すると元の木阿弥になってしまいます。ここでいう「敬称」はA群のことだろうと思うのです。
なので、「敬称」という言葉を使わずにA群を表すことができれば、それに置き換えればよいのではないかと思いましたが、私にはいい言葉が思い浮かびません。
(2)について、「何度も登場する場合は」「適宜」「人名・肩書いずれかを省略する」部分の確認ですが、
  • 「何度も」は、記事全体の長さとも関わるでしょうから、ふんわりした規定ということでいいですよね?(短い間に3回登場すれば略した方がいいかもしれないが、長く多くの登場人物がいる記事では5回でも肩書をつけたほうがわかりやすい)
  • 「適宜」「いずれかを省略」というのは、「田中」「総理大臣」「田中総理大臣」(「総理大臣の田中」)のいずれもOKと解釈していいでしょうか?(必ずいずれかを省略せよ、ということではないですよね?)--柒月例祭会話2014年11月4日 (火) 09:44 (UTC)[返信]
(1)の「敬称」に代わる言葉については、敬称#現代の分類に準じる形で「原則として、肩書き以外の敬称は付けないでください。」で如何でしょうか。リンクを付けておけば、見た人にわかりやすいと思います。但し、「肩書き以外」で使用を規制すると不都合が生じるものが無いか検討が必要だと思います。敬称#現代の肩書き以外に挙げられている類例を見ると、「公」「卿」「殿下」「妃」が場合によっては肩書き的に用いられるようですが、とりあえずは「但し、これは付けることが慣習となっているものまで付けてはいけないということではありません。」で対応できるかなと思います。
(2)については、仰せの通りです。--uaa会話2014年11月4日 (火) 19:20 (UTC)[返信]
各位様、これで暫く静観します。私は文案があった方がわかりよいと思いますが、柒月例祭様が「やっぱり文案は不要」と御考えであれば、無理強いするものではありません。陛下の事を「天皇陛下と書いていない」からでなく(これは書いた方がおかしいでしょう)、(どこの記事かは忘れましたが)「「天皇は~」と書けば良いものを、「明仁は~」」と表記してあったので、あのような要約欄としましたが、「明仁親王は~」と書いてある記述も多々ありました。--JapaneseA会話2014年11月5日 (水) 13:40 (UTC)[返信]
  • 敬称#現代」については、敬称は方針文書ではなく普通の記事なので、内容が書き換えられてしまう可能性は常にあるので、そこを参照する形にするのはマズイんじゃないかなと思います。かといって、ここで全部を列挙するのも冗長な感じはします。
ちょっとわざと列挙しますね。
  • 接尾詞型 - 様、殿、さん、ちゃん、氏、女史、刀自、君(くん)、嬢、たん、タン、きゅん、キュン、卿(きょう)、公、夫人、御中、尊
  • 代名詞型 - 君(きみ)、貴方・貴男・貴女(あなた)、卿(けい)、貴官、貴職、その他(お父上、ご尊父、お母上、ご母堂、御一同様、お嬢様、ご子息、奥様、ご主人)
  • 接尾詞型かつ代名詞型 - 各位、主上・聖上、令息・令嬢、同志、貴下、先生・大先生(御侍史・御机下)
  • 「下」のつく敬称 - 陛下、殿下・妃殿下、閣下、聖下、猊下、座下、台下
  • 職業で用いる呼称(肩書) - 役職名、階級名、資格・職能を表す名称、選手、関取、師匠、丈
  • 接頭辞型 - 聖
必死で探せばほかにもなにか出てくるんじゃないかと思いますが、表記ガイドで完全に逐一列挙してしまうと「そこに入っている単語はどんな場合でも全部削除する/そこに挙げられていない単語は絶対にOKとする」的な解釈をされてしまってもちょっとアレかなと思います。どうしても細かいことでもめたら、このノートでの議論も参照してもらえばいい、ということで、表記ガイドではざっくりした表現にしておくというのはどうでしょう。

①原則として、人名に「○○様」、「○○さん」、「○○先生」、「○○閣下」のような敬称は付けないでください(Wikipedia:スタイルマニュアル#人物・人名によります)。但し、これは付けることが慣習となっているものまで付けてはいけないということではありません。
②肩書、立場、役割、役職、学位、位階、勲位、爵位などは、その人物が記事中何度も登場するような場合、その都度人名と合わせて表記すると文章が冗長になるので、適宜いずれかを省略してください。但し、その人物の固有名詞として扱われているような場合など、文脈的に誰なのか分からなくなるようなものは省略しないでください。
③故人において、人名の前に故を付けたり、人名の後に(故人)や(物故者)を付けたりしないでください。

「例文」に関しては、私はこの件に限らずいつでも「実例」が多いのが好みなのです。しかし、同じ話の繰り返しになってしまいますが、このノートでの議論が「例文」みたいなものでしょうし、例文がいらないということであれば私もそれで構いません。上の案のように「○○様」と4種示せば、まあだいたいわかるんじゃないかなあと思う次第です。
ひとまず、私からはこれが最終案かなあという感じです。ただ、本件に関連するコメント依頼が行われていまして、そこで間接的に本件に関するブレークスルー的な意見があるかもしれないので、他の方がよければ、決定して反映させるのは(忘れて放置しない程度に)少し様子見してもいいかなと思っています。--柒月例祭会話2014年11月8日 (土) 14:01 (UTC)[返信]
柒月例祭氏の最終案に賛成します。1週間異論が無ければ、反映させていいと思います。--uaa会話2014年11月10日 (月) 08:00 (UTC)[返信]
確認ですが、現在の用例にあるサー・ウィンストン・チャーチルの例は削除ということでしょうか?
「○○閣下」はあまり見ないので、最初の3例でいいような気がします。あるいは同列の「○○殿下」のほうが用例として有効な気がします。--T6n8会話2014年11月13日 (木) 23:38 (UTC)[返信]
逆に考えると、「あまり見ない」からこそ×の例として好ましいと思います。要は、どのような敬称の使用が好ましくないかが伝わればいいのですから。「○○殿下」は、特定の人物へ慣習的に使用されることが多々見られますし(アルバート殿下アルバート皇太子の呼び分けとか)、「サー・~」は英語版では普通に使われているので、翻訳の際に削られると、原文と文脈が変わってしまう可能性もあるでしょう。このように、場合によっては付ける必要があるものを用例とするのは好ましくないと考えます。--uaa会話2014年11月14日 (金) 08:08 (UTC)[返信]
コメント 「殿下」は難しい問題をはらんでいると思います。今でもTV・新聞報道では、外国の王族には普通に「殿下」を使っていますし、それを出典としたWP記事も多々あると思います。私が過去に接したのはラオス・カンボジアの王族関連でした。アジアのあの辺は、王族であることが特別の意味を持ち、政治的に重要な役割を果たしていました。ですので、例えば「王子」「親王」「元国王」等とケースバイケースで言い換え作業がなされれば良かったのですが、あの時は機械的に「殿下」を除去されてしまい、前後の説明が付かなくなってしまいました。で、相手の方にお願いし、元に戻していただいた経緯があります。--Ashtray (talk) 2014年11月14日 (金) 10:23 (UTC)[返信]
コメント 「殿下」「閣下」の系統には難しい問題がある、というのは私も同感です。「猊下」は大司教とかに使いますが、日本ではそんなに馴染みがないのでさほど問題は引き起こさないし、「閣下」も対象が広い。しかし「殿下」「陛下」になってくると、外国の王族に対して使っているうちはまだしも、そこから紐がつながっていて、天皇制に関連した思想的な論争(ゴールが見えない)を呼び起こしてしまう。なので、そこらへんはそっとしておきたい、という感はあります。--柒月例祭会話2014年11月15日 (土) 05:31 (UTC)[返信]

T6n8氏からの反論は無く、他に異論がないようなのですので、そろそろ上記内容を反映させてもいいと思います。--uaa会話2014年11月19日 (水) 16:12 (UTC)[返信]

サーの例は除くということで確認いただきましてありがとうございます。
○○宮殿下の殿下はだいたい余計だろうと思ったら、広く考えると難しいようですね。よって、殿下は特別例に示すことはしないというのもよろしいかと思います。
閣下ははずすべき状態の用例がさくっと思い浮かばなかったんです。デーモン閣下の閣下は外さないほうでしょうし。
「「あまり見ない」からこそ×の例として好ましい」という考え方には同意しがたく、日常的な文ではよく使われるが、百科事典向きではない表現をこそ例示するのが望ましいと考えます。その点で先の3例は適切だろうとおもいます。どんな風に使われる可能性のある「閣下」を除くことを意図しているのかをより明確に示されたほうが良いかと思います。--T6n8会話2014年11月20日 (木) 14:38 (UTC)[返信]
敬称#「下」の付く敬称に詳しい説明があります。現代日本で日常的に「閣下」を見かけるかというと、私の経験上はほとんど見かけない気がします。ハリウッド映画では今でも時々「大統領閣下」とか字幕で見かけますし、昔の戦争映画なんかでは将官クラスの人への呼びかけなんかで「閣下」という字幕はよく出るように思います。(デーモン閣下は「閣下」まで含めて固有名詞ですから、この一般ルールとは別次元でしょう。)。
敬称#「下」の付く敬称の代表として「閣下」を選んだのは、「猊下」、「聖下」、「座下」(正教会の用語)、「台下」(仏教など)、「貴下」あたりでは使用例が稀すぎて「代表」にならないこと、「陛下」「殿下」あたりは上で述べたように、天皇制や王制周辺の思想的ないろいろなアレに近すぎてなんかイヤだなあと思い、真ん中らへんの「閣下」を選びました。「大統領閣下」や「大臣閣下」を「大統領」「大臣」としても、日本ではどっち側からもそれほど波風が立たないだろう、と考えました。「閣下」ひとつで、「陛下」や「殿下」についても察してくださいね、という感じです。--柒月例祭会話2014年11月20日 (木) 15:25 (UTC)[返信]
「閣下」は、「様」や「さん」と同様に、百科事典で使わなければならないケースが想定されないので、あってもいいかと考えましたが、とりあえずは外してもいいと思います。あまりに変な使い方がされるようなら、そのようなケースを追加すればいいと思います。--uaa会話2014年11月20日 (木) 17:58 (UTC)[返信]
「閣下」に代表される敬称#「下」の付く敬称を解禁/容認するというわけではなく、単に文案から省くだけだ、という主旨を確認したうえで、文案から外すことでみなさんがOKならばそれでよいと思います。--柒月例祭会話2014年11月25日 (火) 06:15 (UTC)[返信]

一週間以上異論が出てないので、上記柒月例祭氏の最終案から「閣下」を除くということで合意成立とさせていただきます。僭越ながら、私が内容を反映させました。--uaa会話2014年11月30日 (日) 15:30 (UTC)[返信]

全角スラッシュ(/)について

俳優のテンプレにその俳優の主な作品を記載する時に、今までは半角スラッシュ( / )を使用し並べていましたが、現在は全角スラッシュを使う例が多く見受けられます。しかし、全角スラッシュは使用可能な文字には含まれていません。私個人の意見は半角スラッシュを使わずに全角スラッシュを使う方が見やすいと思う次第でありますが、皆様はどのようにお考えでしょうか。何卒意見をお寄せ下さい。 ==欣之介くん会話2014年9月13日 (土) 23:58 (UTC)[返信]

コメントブラウザによって文字化けしたり見にくくなるから半角スラッシュが推奨されてるんじゃないの?自分だけの環境で判断しては拙いよ。それと俳優のtmp内もブラウザによって表示が異なるからこだわっても意味ないよ。ここのテーマには関係ないけどね。--118.109.8.93 2014年9月14日 (日) 02:34 (UTC)[返信]
コメント現在は全角スラッシュを使う例が多く見受けられます」のはどのページですか? 手作業またはbot作業依頼にて<br />タグまたは半角スラッシュに置換を行います。「Template:ActorActressで代表作を全角スラッシュでセパレートしているものが多く見受けられます」というような数の理論ではないのです。--LearningBox会話2014年9月14日 (日) 02:43 (UTC)[返信]
コメント 表記ガイドに持ち込まれましたが、そもそも、渡哲也におけるあなたの編集「テンプレを無駄に長くする必要はない」から出ている話です。
これはTemplate:ActorActressの使い方の話ですが、「主な作品」の引数にはコメントアウトの説明文で<!-- 皆が認める代表作品を入力 -->と書いてあり、その人物の代表作品を書くようになっています。ベテラン俳優のように出演作や主演も多い場合は、多数が納得する形で作品を厳選するか、もしくは全て掲載を行わず『[[#出演]]を参照』とする方法があります。
「あれも載せたいこれも載せたい」「だが、テンプレートが長くなるのは嫌だ」「縦長にしないため<br />タグで一作品1行にするのではなく / で区切って縦幅を詰めたい」「『主な作品』を区切るのに私は / ではなく / を使ってきました」「みなさん『主な作品』の / での区切りを認めてください」この流れですよ? 賛同を得るのは困難と言わざるをえません。--LearningBox会話2014年9月14日 (日) 03:49 (UTC)[返信]
コメント 提案者の意見には賛同できませんが、全角スラッシュを用いてもよい例外が出てくる余地(具体的には思いつきませんが)はあるかもしれません。たとえば、約物全般に言えますが、mw:Typography Refreshの導入でフォント指定が和欧混植となる(現状、デフォルトでゴシック体のCSS適用のガジェットが有効になっていますが)ため、見出しに関しては和文と半角約物の上下位置がずれる場合がある、といった状況もあります。IPの方から文字化けの可能性のご指摘がありましたが、全角スラッシュJIS X 0208に含まれていますのでその心配はないかと。全角チルダなどとは状況は異なります。表記ガイドを根拠にbotで置換するというのは、少々乱暴なご発言かと思いました。--Wolf359borg会話2014年9月14日 (日) 04:16 (UTC)[返信]

01月のような表記のリダイレクトが作成されている件について

Wikipedia:井戸端#01月、平成02年、明治06年、大正09年といった表記のリダイレクトの賛否にて、01月平成02年明治06年大正09年03月07日のような先頭に0を含む表記のリダイレクトがあることについてそれらのリダイレクトを削除しても良いのか問題提起いたしましたのでご報告させていただきます。これは元々Wikipedia:利用案内#複数のリダイレクトの削除依頼を一括で行う方法にてリダイレクト削除の方法を質問したことが発端となっており、利用案内のほうでリダイレクトの有用性や表記ガイドの修正を含めて井戸端などで議論すべきとの意見が出ましたので井戸端に議論場所を移したものです。--Meniv会話2014年10月16日 (木) 15:10 (UTC)[返信]

表記ガイドの修正について

(本節を井戸端からこちらに移動しました。--ディー・エム会話2014年10月18日 (土) 08:18 (UTC)[返信]

利用案内のほうでアルビレオさんや柒月例祭さんよりWikipedia:表記ガイド#年月日・時間への言及がありましたのでこちらで別に発議します。 01月のような表記ができてしまうリダイレクトを削除して0x月0x日のような記述は「できない」ではなく「しない」と明記すべきか、非推奨な一方でできないこともないとしてリダイレクトを存続し、表記ガイドを修正すべきかの皆さんの考えをお聞きしたいです。余談ですが私を含めて井戸端のほうでは0x月系のリダイレクトは必要ないとする考えが多いですが、利用案内のほうでは0x月系のリダイレクトを使用することを積極的に禁止する理由はないとの意見もありました。--Meniv会話2014年10月16日 (木) 15:24 (UTC)[返信]

コメント 個別のリダイレクトの存廃に関しては表記ガイドは直接関係ないので、リダイレクト削除の対応と表記ガイドの改定は別途切り離して進めるのが良いと思います。以下、書式上のルールに限ってのコメントと提案です。
現行の表記ガイドの説明をそのまま読むと、たしかに表現がわかりにくい面はあると思います。基本的には、これは単純に「03月05日」のような表記は使わないという意味で解釈するのが最も自然であり現実的でしょう。「リンクが正しく表示されない」というのはその理由の一例を述べたものかと思いますが、そもそも記事中に置く日付のリンクは人物の生没年など重要なもののみということになっていますし、リンクを置くにしてもパイプリンクを使えば数字の表記方法とは無関係にすべて正常にリンク可能ですので、説明としてこの部分は無い方が良いのではないかと思います。
提案 そこで具体的な対応策として、「Wikipedia:表記ガイド#年月日・時間」内の一文を下記のように改定するという対処法ではいかがでしょうか。
  • (現行)「03月05日」のような0を入れた書き方は、リンクが正しくされないので使わないでください。
  • (改定)「03月05日」のような0を入れた日時の書き方は記事の中では使用しません。表の桁揃えが必要な場合には、スタイル指定で文字を右揃え("text-align:right")にするか、テンプレート {{0}} を使用してください。
--ディー・エム会話2014年10月18日 (土) 08:18 (UTC)[返信]
  • 条件付賛成 原則的にはそのような書き方をしない方向で良いでしょう。ただし「固有名詞で用いられる場合に限り、この限りではない」(単に日時表記を行うために用いることは不可)という断りを付せば良いと思います。--Don-hide会話) 2014年10月18日 (土) 08:26 (UTC) 票変更。--Don-hide会話2014年10月27日 (月) 12:58 (UTC)[返信]
  • (条件付賛成) 原則として「しない」としてよいと思います。ただし、Don-hideさんが指摘されている固有名詞だけでなく、(実際の例の有無はともかく)引用のような「そのまま引き写すことが必要な場合」を除くと条件を付ける必要はあるでしょう。--Claw of Slime (talk) 2014年10月20日 (月) 11:58 (UTC)--2014年10月22日 (水) 18:04 (UTC)条件付き賛成を取消[返信]

コメント ご意見ありがとうございます。たしかに、固有名詞や引用の場合は除くと明記しておいたほうが良さそうです。下記のとおり改定案を修正したいと思います。

  • (改定案2)「03月05日」のような0を入れた日時の書き方は、原典の引用や固有名詞の表記に用いる場合を除き、記事中では原則として使用しません。表の桁揃えが必要な場合には、スタイル指定で文字を右揃え("text-align:right")にするか、テンプレート {{0}} を使用してください。

--ディー・エム会話2014年10月21日 (火) 10:38 (UTC)[返信]

コメント 表記ガイドとしては原則的な書き方を規定するものなので、0を入れた書き方はしないとして良いと考えます。その上で細かい点ですが、Wikipedia:表記ガイド#年月日・時間の節の先頭に『以下は記事の中で年月日・時間について記述する場合に適用します。著作物の名前に年月日・時間が含まれる場合など「固有名詞」には適用しません。また、引用する場合にも適用しません。』という文が既にあり、冗長になるで、提案箇所については当初のディー・エムさんの案のままの方が良いと思います。--アルビレオ会話2014年10月22日 (水) 04:41 (UTC)[返信]

コメント ご意見ありがとうございます。確かに節の冒頭に書かれていました。あと1週間程度待った上で、アルビレオさんご指摘の内容(節冒頭に断り書きがあるので修正部分の文面は原案の方を採用)で特に異論が出ないようでしたら原案の文面で文書の改訂を行いたいと思います。--ディー・エム会話2014年10月26日 (日) 13:09 (UTC)[返信]

  • 余計なことをいいます。みなさんの指摘する問題は概ね仰るとおりと思います。ただ、フッと目に入ったので気になってしまったのですが、署名をするときの時刻表記には「08:15」みたいに、桁そろえのための0が入りますよね・・・(設定によって違うのかな?)。「日時」のうち「時」に関してはシステムがこうなっているのに、「日時で0はダメよ」というのは塩梅がわるい気が・・・。--柒月例祭会話2014年10月27日 (月) 20:11 (UTC)[返信]
まずは事実。私の設定では、表示を標準のベクターではなくモダンにしています。その環境では、例えばウォッチリストの時刻表示は08:15のように時の前ゼロが表示されますが、ノートページ内の署名は8:15のように、時の前ゼロはサプレスされます。ただし、13:09のように分については前ゼロは表示されます。日付についてはウォッチリストでも10月2日のように、月の後の日でも前ゼロは表示されません。
以下私の推測。特に時刻でhh:mmやhh;mm;ssの形式で表記する場合、hhの前ゼロは表示することと抑止することの両方があるが、mmやssについては前ゼロを表示することが一般だと思います。一方日付については前ゼロはサプレスする方が多いのではないでしょうか。年月日でも、2005-06-02(本ノートページの先頭付近にあります)のような形式では月も日も前ゼロをサプレスしないことも普通です。
もし書くのであれば、2014-09-02や12:02のようにハイフンやコロンを使う形式では、ハイフンやコロンの後ろのゼロも表示して構いません、くらいでしょうか。ここまでガイドに書くかどうかという話もありますが。--アルビレオ会話2014年10月28日 (火) 00:28 (UTC)[返信]
「2000-01-01」のようなハイフン区切りでの日付表記や「01:01」のようなコロン区切りでの時刻表記において前ゼロを入れてそれぞれ2桁表示とするのは、ISO 8601によって規定されているものであり、広く用いられているものですので、このような表記まで禁止する必要はないでしょう。特に時刻表記においては、「01:23」を「1:23」と表記することはあっても「12:03」を「12:3」と表記することはまずないですし。一方で、日本語において年月日や時分を区切りとした「2000年1月1日」や「1時1分」を「2000年01月01日」や「01時01分」とすることは一般的ではないよね、というのが今回の提案と理解しています。「2000-01-01」「01:01」について表記ガイドで触れる必要があるのかは微妙なところだと思います。--Claw of Slime (talk) 2014年10月28日 (火) 06:45 (UTC)[返信]
コメント とりあえずはこのノートで明確な解釈を確認できていますので、大丈夫ではないでしょうか。もし今後、誤解されたり拡大解釈されてままならないことがあれば改めて説明の追記を検討ということで問題無いと思います。--ディー・エム会話2014年10月29日 (水) 13:13 (UTC)[返信]

報告 最終の合意以降、特に異論がありませんでしたので、当初案の内容でガイドラインの文言を修正しました。ありがとうございました。--ディー・エム会話2014年11月2日 (日) 15:12 (UTC)[返信]

「具体例による説明」について質問

Wikipedia:表記ガイド#具体例による説明」では記号は半角を使用することになっていますが、例外として全角を使用する場合も記述されています。その中で、「下記参照」とされていながら、イコール(=)については記述が見当たらないのですが、イコールを全角で使用する時とはどのような時なのでしょうか。--V5+c6-S3+w8=DDss会話2014年11月4日 (火) 08:39 (UTC)[返信]

コメント ありがとうございます。気づきませんでした。--V5+c6-S3+w8=DDss会話2014年11月4日 (火) 12:15 (UTC)[返信]

「プロジェクト:放送番組/表記ガイド」のガイドライン化について

プロジェクト‐ノート:放送番組/表記ガイド」にて、同プロジェクト文書のガイドライン化について再確認の発議を行っています。追加の検討事項や議論延長のご要望があればあちらのノートまでコメントをお寄せください。--ディー・エム会話2014年12月28日 (日) 16:26 (UTC)[返信]

報告 当面の文書改定作業がひとまず完了しましたので、当該の内容であと1週間待って異論がなければ文書名を「Wikipedia:表記ガイド/放送関連」に改名の上、正式にガイドライン化したいと思います。プロジェクト関連文書から「表記ガイド」への改名を伴う改定となりますので、こちらのノートにも再度お知らせいたします。--ディー・エム会話2015年1月17日 (土) 14:11 (UTC)[返信]

Webサイトを出典として示す際も表記ガイドに合わせるべきか?

Webサイトを出典として示す際、そのタイトルに全角英数字や全角スペースなどが含まれていた場合、これも表記ガイドに合わせ修正すべきなのでしょうか。私はこれまでは、Webページ上での表記に極力合わせたほうがよいのかな、と考え、修正はしていませんでした。

Wikipedia‐ノート:表記ガイド/過去ログ8#外部リンク先で使用されている文字で一度議論にはなっていた(その際は結論は出なかった)のですが、ガイドラインとして決めたほうがよいのかも?と思いまして。--Sinryow会話2015年2月7日 (土) 02:29 (UTC)[返信]

情報 その後の議論「Wikipedia‐ノート:出典を明記する/過去ログ8#ウェブサイトを出典とする場合の改正提案」では、「表記ガイドに合わない表記も、そのままコピーアンドペーストする」というガイドラインが提案されましたが、否決されています。方向としては逆ですが、当時の反対意見を読む限りは同根の問題だと思います。--Kanohara会話2015年2月7日 (土) 05:46 (UTC)[返信]
コメント ちょっと補足を。上記の議論では「出典を明記することを億劫がらせるような、障壁となるようなルールは作らない方がよい」という趣旨の意見がKs aka 98さんやGyulfoxさんから出されていました。私は、記事の編集に携わるときには「表記ガイドに合わせる」方向で編集していますが、以前の議論を踏まえると、無理にルールで統一せず編集者個人の裁量に任せるという形で良いのではないかと思っています。--Kanohara会話2015年2月11日 (水) 09:58 (UTC)[返信]
コメント 表記ガイドに合わせることが望ましいでしょう。タイトルに丸付き数字、JIS X 0208に含まれない文字やいわゆる半角カナが含まれている場合は、そのままだと環境によっては正しく表示されないことがあります。このような場合は明らかに出典元の文字をそのまま使うのではなく、表記ガイドに合わせるべきです。全角英数字や全角スペースについても、全角であることが意味を持つ場合(ちょっと考えにくいですが)以外は表記ガイドに従って修正するべきだと思います。もし元が全角であることなどを明記したいのであれば「(1)abc(引用元では丸付き数字の1および全角のabcを使っている)」のようにすれば良いと思います。--アルビレオ会話2015年2月7日 (土) 06:59 (UTC)[返信]
コメント 私も、表記ガイドに合わせればいいと思います。全角文字と半角文字の区別は今や純粋に表示上の問題ないし技術的な問題(文字コードの互換性の事情)であり、意味論的・実質的には同じ文字です。同じ文字である以上、出典を特定する役割は全角/半角を変えて失われるものではありません。朝彦会話2015年2月8日 (日) 18:11 (UTC)[返信]
コメント 出典を示す場合に限らず、電子テキストを引用する場合に共通する問題だと理解しています。
全角と半角は(できれば)表記ガイドに従って適宜修正することが望ましい、という点はおそらく意見が一致すると思います。
ただ、上で挙げられている丸付き数字やJIS X 0208外の文字のほか(現時点でフィーチャーフォンをどこまで考慮する必要があるのか、利用者の比率が分からないと判断しにくいですが)、約物(和文でのピリオド・コンマ、3点リーダーのさまざまな表記、山括弧としての不等号、引用符の開き・閉じの不整合など)、単位等の和文合字、ローマ数字などをどこまで表記ガイドに合わせるか、明文化するのはかなり大変だと思います。編集者個人の裁量に任せる、というのが現時点では望ましいと考えます。 --KAWASAKI Hiroyuki会話2015年2月16日 (月) 17:58 (UTC)[返信]
コメント話題が「外部サイトのタイトル」に限定しているという場面では、原則的にはURLが指し示すリンク先(対象)を特定します。「タイトル」はURLの説明である、ということで、この場合には表記ガイドに基づく修正は妥当と思います。
かなり間接的な意見になってしまいますが、一般論として、信頼性が高い情報源ほど、そもそもタイトルに規格外の文字を使用することは回避されているだろうと思います。そのサイトのタイトルに「丸付き数字や規格外の文字」が使われているという事自体が、そのサイトの信頼性がそれほど高くないことを示唆しているようにも思います。
「外部サイトのタイトル」と限定せずに、より広い用法として考える場合には、事情は少し変わります。この場合には、私は、朝彦さんのおっしゃる「実質的に同じ文字」という考え方には100%は賛同しません。もっぱらポップカルチャーなどでの限定的な用例でしょうけども、各種記号類、半角文字、特殊文字のほか、旧字体・異字体などを絵的に用いたり(顔文字やAAなんかが典型)、固有名詞に用いる手法などがあたります。
机上の理想論のような話になってしまいますが、こうした固有名詞的な用法に関しては、例外・条件付として、あえて本則を外れた表記(文字)を使うことについての根拠・理由や意図をきちんとノートで説明したうえで使うことは可能としてもいいのではないかと思います。条件付きの例外を認めるということは、本則を機械的に適用して機械的に書き換えるような行為を認めないということになるのですが、しかしまあ、現実には機械的に書き換えようとする人や、ノートできちんと説明をしないまま編集をする人、これらの人同士のトラブルや論争は起きるでしょう。
特別な事情がある場合は特別な扱いを認める、というのは論争を回避するための手段の一つですが、それが結局論争のたねになってしまうのであれば、「正確性」を多少犠牲にしてでも、そもそも一切の例外を認めない、という方向で論争を予防するというのは、しかたがないかもしれません。つまり、理想としては例外を認めて欲しいのですが、現実的には、多少乱暴でも原則しか認めないということでしょうがないかも、ということです。--柒月例祭会話2015年2月17日 (火) 02:42 (UTC)[返信]
提案 丸付き数字は行政関係では多用されます。約物も、地方自治体や企業のサイトではおかしな使い方をしているケースがあるようなので、ポップカルチャーに限った話でもありません。
範囲を広げすぎかもしれませんが、たとえば、
  • ウェブサイトなどの電子テキストを出典として示す場合のタイトル等、および引用文では、表記ガイドに従い、原文の意味を改変しない範囲で表記を修正してもかまいません。
    • 漢字の用字仮名遣い句点、……の扱いについてはそれぞれの項も参照してください。
    • 印刷物をスキャンし、OCRによる電子テキストが加えられている資料(PDFなど)を引用する場合、OCRの誤認識が明らかな場合は、原文に従って適宜修正してください。
といった内容ではどうでしょうか。 --KAWASAKI Hiroyuki会話2015年2月17日 (火) 04:12 (UTC)、加筆:2015年2月17日 (火) 04:27 (UTC)[返信]
(インデント戻します)提示者です。皆様ありがとうございます。
私としては、基本的にはKAWASAKI Hiroyukiさんの方式が適切なように思いました。ただスタンスを少々変えて、「そのままでもよいが、ガイドラインに沿った表記に変えることが望ましい」というほうがよいのかもしれません。
また記号の問題については、出典や引用に限った話でないので(現にWikipedia:表記ガイド#繰返し符号Wikipedia:表記ガイド#ローマ数字では「固有名詞などでは利用してよい」という例がある)、別途検討でもよいかもしれません。
--Sinryow会話2015年2月23日 (月) 09:41 (UTC)[返信]

人名表記統一の提案

※本件はノート:ビハインド・ザ・マスク (マイケル・ジャクソンの曲)での160.129.139.184さんの提案を基にしております。

提案 Wikipedia日本語版では現在、一度フルネームが記述された場合以降、苗字で呼ぶか下の名前で呼ぶのか示されておりません。
Wikipedia:スタイルマニュアル#人物・人名Wikipedia:表記ガイド#人名を参照)

日本人名に関しては考えるまでもなく苗字で記述されていますが、外国人名には表記揺れが起きています。
(ファーストネームで書かれているダニエル・ラドクリフ、ラストネームで書かれているジェームス・ブラウン)

因みにWikipedia英語版では一度フルネームが記述された場合以降ラストネームで呼ぶものと、統一されています。
en:Wikipedia:Manual of Style/Biographies#Subsequent useを参照)

ので、これらを統一する為、

  • 原則、一度フルネームが示された場合、以降は苗字(ラストネーム)のみで表記して下さい。ただし、同姓の苗字が混在する場合はフルネーム、もしくはファーストネームで表記して下さい。

と加筆したいと思います。二週間待ちます。御意見下さい。
--Gowithitjam会話) 2015年2月22日 (日) 20:40 (UTC)ラストネームをファーストネームに訂正。--Gowithitjam会話2015年2月23日 (月) 02:54 (UTC)[返信]


  • 反対 記事それぞれの事情を鑑み、執筆者の裁量に任せるべきものと思量します。まず、「日本人名に関しては考えるまでもなく苗字で記述されています」などということはありません。例をあげれば、松尾芭蕉を文中全て「松尾は~」と記せと言っているも同然です。また徳川家康では徳川姓が頻出するため、全て「徳川家康は~」と記すことになります。これに違和感を抱かない、というなら何も言うことはありません。
更に前議論として示されたノート:ビハインド・ザ・マスク (マイケル・ジャクソンの曲)を拝見しますと、記事単体での議論で済むところを無理矢理一般化して議論を拡散させているだけに見えます。私論ですが「指示の肥大化を避ける」もご覧ください。--LudwigSKTalk/History2015年2月23日 (月) 00:31 (UTC)[返信]
 提案  貴重なご意見有難う御座います。英語版では当たり前に適用されているマニュアルですから指示を過剰に肥大化させることではないと思います。拡散も目的ではありません。160.129.139.184さんの御意見ではダニエル・ラドクリフなど多くの記事にも修正を加える必要があると考えますし、であればマニュアルで示しておくべきだと思います。ですが、松尾芭蕉は「芭蕉」と表記するのが適切に思いますね。因みに160.129.139.184さんのご意見は如何でしょうか?同氏がジャクソンとすべきと仰られた理由は一貫性に欠けるという理由でしたから松尾芭蕉をどう表記すべきとお考えなのか、教えて頂ければ参考になります。松尾芭蕉の事例を踏まえて改めて提案ですが、
  • 一度氏名(フルネーム)が示された場合、以降は一般的に用いられる表記を用いますが、苗字(ラストネーム)での表記と下の名前(ファーストネーム)での表記の何方が一般的か甲乙つけ難い場合には苗字(ラストネーム)で表記してください。

というのは如何でしょうか?マイケル・ジャクソンジェームス・ブラウンダニエル・ラドクリフでバラツキがあるのは、ラストネーム、ファーストネーム、何方の表記も一般化してないからだと思いますし、その場合の対応は示しておいた方がスムーズではないでしょうか?指示も最小限でありながら、利用者の混乱を防げるものと思います。
--Gowithitjam会話2015年2月23日 (月) 02:54 (UTC)[返信]

反対 どちらかと言えば反対です。一度目と二度目が離れている場合、例えば長大な記事において概要部分と記事末尾の方に二度名前が登場する人物などは、適宜フルネームで表記した方がよいのではないかと考えます。あと、芸能人の芸名やフィクションの登場人物などで、人名として奇抜な名前などは、(それが人名であることを明示するために)適宜フルネームを用いた方が読みやすくなる場合もあると感じています。そういった状況を一律ルールで縛ることには疑問も感じます。--Kanohara会話2015年2月23日 (月) 03:43 (UTC)[返信]

Kanoharaさん、御意見有難う御座います。
表現がやや不適切だったようです。端的に言えば、「マイケル・ジャクソン」を「マイケル・ジャクソン」と表記する必要がない状況において、「ジャクソン」と表記すべきか、「マイケル」と表記すべきかという話です。他に一般的な呼称があるのならそれ(人名として奇抜な名前など)を用いればよいでしょうが、一般的な呼称がそれ程ハッキリしてない場合、執筆者間でブレが生じ、ジェームス・ブラウンはラストネームで表記され、ダニエル・ラドクリフはファーストネームで表記されるという現象が起きてしまっています。両者其々それ程変わらない条件ですからブレが生じた際の指針を示しておくべきではないでしょうか?
--Gowithitjam会話2015年2月23日 (月) 04:12 (UTC)[返信]

  • 反対 「統一する」こと自体に反対です。ほかの方がもおっしゃっている通り、「統一しないことが望ましい」と考えます。

「一貫性」が求められるのは、1つの記事の中での表記であって、複数の・事情が異なる記事を機械的に貫いて形式的な統一性を求めよというものではないでしょう。(英語版の貴族の称号に関する記述には「安易に統一するな(受爵した年号に気をつけろ)」という注意書きさえあります。)

ルールというのは、「なぜ/なんのためにそういうルールがあるのか」を考えるべきです。「統一」することでなにを目指そうとするのか、どういうメリットがあるのか、を最初に考える必要があります。

人物の「名前」というのは世界各地で固有の複雑な文化があります。その複雑さを個別に理解しないまま、安直に「統一」することのメリットがどれだけあり、統一によるデメリットがどれぐらい生じるでしょう。

紙製の出版物の場合には物理的な紙面の制約があり、文字数を削りたいというニーズがあります。これはやむなくそうするものであり、ウィキペディアではそういうものは無いでしょう。

もちろん、単に統一したいという様式美の追求も重要ではないでしょう。共同作業ですから、「美」の基準もまちまちであり、ある人にとって美しく統一されていると思っても、別な人にはそうは見えないものです。

もっとも重要な観点の一つは、「読者にとってわかりやすいか」でしょう。すでにいくつか事例が挙げられていますが、どちらに統一しても「わかりにくい」場面は生じます。「ジョン・スミス」と「マイケル・ジョン」が登場する記事で「ジョン」と書くことは明らかに不適当です。記事の登場人物しだいで、フルネームで書くべき場合はあるでしょう。要するに、わかりやすい表記を求めて、ケースバイケースで、記事毎に判断していくということです。

Gowithitjamさんのご提案は、読者のためというよりも、ノート:ビハインド・ザ・マスク (マイケル・ジャクソンの曲)のように執筆者の間で意見がわかれた際に、議論を行わずに、機械的にラクして正否を判定したい、という目的にみえます。基本的に、意見がわかれる場合というのは、そこに複雑な事情が存在しており、それを議論を通じて紐解いていくことには、価値があります。合意できなければそれはそれでしかたがない(勝ちはないかもしれないが価値はある。)。

上で書いたように、人物の名前というものは世界はきわめて複雑であり、議論を回避するために乱暴で機械的なルールを作っちゃうことは、世界の複雑性を適切に理解していくことの妨げにさえなるでしょう。(つまり、その文化を深く理解している人物が妥当な呼び名を使っても、何もわかっていない人が「ルールだから」といって妥当ではない名前に機械的に書き換えていく、というような事態を招く。)何らかの事情でイージーでシンプルな合意が得られないとしても、記事にそれらの事情を詳述することは、たいていの場合、読者に有用な情報を提供するはずです。必要な議論は安易な解決を求めず、きちんと議論しましょうよ。

なお、「英語版では統一されている」というのは、ほとんど誤りであるようにも思います。英語版では確かに“the person should generally be referred to by surname only (中略) or by a pronoun. ”(人物は一般的に代名詞(pronoun)か姓(surname)だけで言及するのが望ましい)とあります。ですが、その趣旨は“given name gives the impression that the writer knows the subject personally”(名(given name)で記述すると、執筆者がその人物と個人的に親しいという印象を招く)ことを回避するためと説明があります。
さらに例外規定が続き、国・文化毎のスタイルは別節(Country-specific usage)を参照、また、王族、貴族、芸名、学位や博士号の場合の例外規定があります。国・文化毎のスタイルはさらに別の部分(Sort by surname)を参照するようになっていて、そこでは国・文化別に(箇条書きの数で数えても12)の例外規定があり、たとえば日本の場合には、1885年以前に生まれた人物とそれ以降の人物にわかれ、更に力士・芸者・歌舞伎役者の例外規定があり・・・といった具合です。判断基準はものすごく複雑に枝分かれしており、簡単に「姓で統一」などというものではありません。これでは、上で言ったように「記事毎に事情を詳細にケースバイケースで判断する」と言うのと結局一緒でしょう。
英語版がこんなことになってしまっているのは、「記事名でソートするときの基準」を求めたもののようです。今回は記事の中での表現に関する議論ですから、こうした観点は考慮する必要がありません。

ただ、個別の議論にあたって難しい面はあります。そもそもの議論が“英語圏ではファーストネームで呼ぶのが一般的か”で始まっていますけども、「英語圏ではファーストネームかも知れないが、ここは日本語版だ」「日本語版は日本版ではない」「日本語話者と日本は不可分だ」という見解もあるでしょうし、「英語圏ではファーストネームかも知れないが、ロシア語圏では父称優先だ」とか、「ドイツ人だけどアイスランドからの移民二世だ」とか、「この人は英語圏出身の人物だが、日本では日本語でよく知られている」とか、いろいろな事情・考え方があります。

たとえば「マイケル・ジャクソン」に関しては、日本でもよく知られた人物です。私の個人的なセンスでは、日本では「ジャクソン」というより「マイケル」とか「マイケル・ジャクソン」だろう、と思いますが、それは彼の場合には「ジャクソンファミリー」から出てきたので「ジャクソン」では他の人と区別がつかないから、という事情があるからかもしれません。しかしビハインド・ザ・マスク (マイケル・ジャクソンの曲)という記事のなか限定であれば、ジャネット・ジャクソンと混同することもないだろうから単に「ジャクソン」としてもいいかもしれません。しかしやっぱり日本語文献ではフルネーム表記が一般的だから・・・などなどと、個別に議論を重ねて個別に判断するべきでしょう。いきなり一般論まで話を広げて徳川家康やソルターン・モハンマド・シャー・ホセイニー・アーガー・ハーン3世などを一緒くたにぶった切る必要性は感じません。

Gowithitjamさんには言うまでもないことですが、英語版が「アメリカ版」や「イギリス版」ではないように、ウィキペディア日本語版は「ウィキペディア日本版」ではない。「ウィキペディア日本語版」でアメリカ人の名前を書く場合に、アメリカ風に書くべきなのか、日本風に書くべきなのか、日本の文献でどう扱われているかに基づくのか、日本の文献では登場しないような人物の場合はどうなのか、ということに簡単に答えを出すのは難しいように思います。

結局のところ、その記事毎に、日本語の信頼できる情報源ではどう表記されているか、日本語文献が見込めないならどうするか、を個別に話し合っていくべきだし、その過程で色々な有用な情報が得られるでしょう。そうした情報を出し合って議論の結果として「この記事では姓で書く」となれば、それはまさに妥当な表記です。しかし、なんにも考えずに「ルールだから」と言って書いちゃうと、不適切な・一般的でない=誤った・わかりにくい表現になってしまうかもしれません。英語版が「アイスランドではこう、マレーシアではこう、1888年以前の日本ではこう・・・」という風に細かく場合分けしているのは、まさにそういう事情があるからです。--柒月例祭会話2015年2月23日 (月) 06:25 (UTC)[返信]

日本時間と現地時間の表記についての改訂案

現在、日本時間と現地時間の表記についてガイドでは明記がありません。日米外交関係の記事などで、閲覧上混乱を招くので現地時間と日本時間の併記についてのガイドを「年月日・時間」において明記すべきではないでしょうか。Wikipedia:井戸端会議ログ2#時差による日付の表記方法に過去ログあり。

日本が関係する海外での事件や交渉等は現地時間と日本時間を併記する

という文案を提示します。--さんぽーる会話2015年3月24日 (火) 14:19 (UTC)[返信]

適用範囲を絞りすぎです。日本に限った話ではありません。例えば、キューバ危機で両陣営が交わした電報やテレビ演説などの時間は、米国東部標準時とモスクワ標準時のどちらで記載するのか、イラク戦争前夜のブッシュ大統領による「48時間以内」とは、米国東部標準時とイラク時間で何日何時から何日何時までだったのか、など、(現時点で記事はそのような記述になっていないにせよ)様々なケースで時間を併記しても不思議ではない記述が考えられます。--朝彦会話2015年3月24日 (火) 15:01 (UTC)[返信]
みごとなまでにWikipedia:日本中心にならないようにに陥った提案と見受けられます。朝彦さんご指摘のように、範囲を絞りすぎという問題を措くとしても、複数の時間帯の併記の必要性が(可能性として)考えられる事例は多数あるでしょうが、それでは湾岸戦争イラク戦争はどうするのでしょうか。多国籍軍なり有志連合に参加した各国の時間帯を軒並み列挙するのでしょうか。必要性に応じて個々の記事と個々の執筆者とで判断すればよいことで、一律に枠をはめることのメリットが明らかではないようです。--ikedat76会話2015年3月24日 (火) 16:04 (UTC)[返信]
取り下げ お二人のご指摘の通り、個々の記事で判定すればよく、一律にガイドラインにする必要性はないようです。併記なので日本中心という点は違うとは思いますが、提案を取り下げます。--さんぽーる会話2015年3月29日 (日) 12:41 (UTC)[返信]
別に取り下げなんだからどうでもいいっちゃいいけど。「日本が関係する」、これWikipedia:日本中心にならないようにじゃなきゃ何なんでしたけっけ…っていう。--ikedat76会話2015年3月29日 (日) 12:59 (UTC)[返信]
取下げられているけれど コメント。基本はUTC(協定世界時)で記述し,例外として現地時間を併記すべきと考える。なおUTCのみ,併記,現地時間のみのいずれの場合でもタイムゾーンの記述は必須であろう。--eien20会話2015年3月31日 (火) 02:53 (UTC)[返信]
ある国・地域の特定の日付におけるタイムゾーンがなんであったかを調べるのは、困難な場合があります。夏時間、冬時間が、政令で不規則に代わる国もあります。そのため、タイムゾーンが3文字コードで参考文献に明記されるか、まぎれもなく特定できる場合以外は、現地時間のタイムゾーンを推測したり、UTCに換算したりするのは避けるべきです。 --Yhiroyuki会話2015年3月31日 (火) 03:39 (UTC)[返信]
Yhiroyukiさんの仰ることと同意見です。(取り下げになった議論ですし、「必須」とも思いませんが)「協定世界時」を利用するのは構わないんですが、「協定世界時」ができる以前の事柄を「協定世界時」で表記するというのも、絶対にやるなとは言いませんが、慎重にね、と思います。--柒月例祭会話2015年3月31日 (火) 07:36 (UTC)[返信]
すべての記事の時刻を例外なくUTCで書き換えよ,タイムゾーンを絶対に記述せよとは言っていません。わかるならUTC(1972年以前はGMTでしょうか。)で書くのがベストではないかと提案したつもりです。もちろん,憶測で書き換えてはならないと考えています。なお,tz databaseを使用すると過去の標準時が何であったかを調べることができます。 --eien20会話2015年3月31日 (火) 16:32 (UTC)[返信]

「ある国・地域の特定の日付におけるタイムゾーンがなんであったかを調べるのは、困難な場合があります。夏時間、冬時間が、政令で不規則に代わる国もあります。」というYhiroyukiさんの指摘をお読みになってからどうぞ。そういうのいちいち調べて回って時刻を換算するんですか?時刻の換算をしにきてるのか記事を書きにきてるのか、何をしてるんだか分からないですね。憶測で書き換えるなんぞ話にもなりませんが、だったら文献に書いてある書けばいいだけで、ウィキペディアンがわざわざ換算なんてことをする必要は皆無。本筋とズレにズレきったところで労力を使わせられるだけで、ベストどころかワーストもいいところです。終了。--ikedat76会話2015年3月31日 (火) 21:49 (UTC)[返信]

1970年以降の公的標準であれば、Eien20さんのしめされたtz databaseでわかります。ただし、ゾーン境界の移動や文献のローカルルールには注意する必要があります。--Yhiroyuki会話2015年4月1日 (水) 03:59 (UTC)[返信]
返信 UTCを書かないのを悪としているわけでなく,タイムゾーンもUTCも書かないのが悪だとしています。ただ10時と書かれたら日本時間(UTC+9)なのかUTCなのかはたまた別のタイムゾーンかが区別できません。換算が手間ならTemplateを作ればいいだけの話ではないでしょうか。元号を西暦に変えるTemplateはありましたよね。 --eien20会話2015年4月1日 (水) 06:06 (UTC)[返信]
  • Ikedat76さんがおっしゃってることと、たぶんおんなじなんですが、ウィキペディアの基本的な考え方としては、「それが書くべき事柄かどうかは、出典で判断する」というのが本筋ですよね。記事を書くときに使用した出典が、協定世界時なり、現地時間とそうでない時間の両方について言及しているなら、それは出典に基づいて書くに値する情報(「と推定される」)。出典で書いてないものを、計算できるからといって書き足すというのは、ウィキペディアの本則からは外れるでしょう。
出典が言及しているからといって、最初に問題視されたように、「○○中心」との兼ね合いを気にする必要があります。報道なんかでは、「アメリカの午前10時(日本時間今日未明)」みたいに両方の時間を併記することはありますので、そういう出典には注意は必要でしょう。たとえばエジプトとフランスのことを報じるイギリスの新聞が「イギリス時間」を併記したからといってイギリスの時間を書くのは、それは「イギリス中心」になるかもしれません。イギリスの新聞がエジプト時間とフランス時間に言及していたら、重要な事かもしれません。個別的に判断が必要です。
「個別的な判断」ということはつまり、UTCを絶対書くなということでもありません。もしそれが本当に重要なことで、役に立つ情報だったら、データベースで計算して注釈なりで言及する、ということは、私はアリだとは思います。朝彦さんが例示されたような、キューバ危機での各国の時々刻々の情勢とかを書くときには、ひょっとすると各地域の現地時間を計算してでも補足してくれたほうが、理解の役に立つということはあり得ると思います。もちろん、あとになって「この記述は本当なの?」と検証したくなった時のために、計算の根拠なり出典なりをいちいち示しておく必要はあるでしょう。ただしそれでも独自研究との兼ね合いを注意する必要はあります。出典がそう書いてもいないのに「連絡が遅くなったのは、現地時間が深夜だったのが原因だ」というような誤解や誤読を招くことには注意を払わなければなりません。
たいていの場合、記事の主題や記述によって、地球上のたかが24時間程度の時差が重要になるのであれば、それは出典がそのことを示唆するでしょう。出典が言及してなければ、たぶんそんなことはどうでもいいことです。計算できるからといって「ストックホルムでの国際会議が23:46(UTC)に始まりました」とか書かれても・・・。
記事毎・記述ごとに妥当性や読者の利便性を個別的に検討して慎重に行うならいざしらず、全部ひとまとめで併記することにする、というのはどうかなあ。地名の緯度や経度を計算できるからといっていちいち全部書いたらひどいことになるし、人物の年齢を計算できるからといっていちいち書いていってもひどいことになります。「何も考えずにそればっかり機械的にやっていく」タイプの編集はえてして歓迎されません。--柒月例祭会話2015年4月1日 (水) 04:51 (UTC)[返信]
返信 "出典に書いているもののみを書く",そのとおりです。出典に現地時間13時と書いてあれば,jawpにも13時(現地時間)と書くべきでしょう。わかるのであれば13時(UTC+n)表記がいいでしょう。例外なく何にでもUTCを併記するというのは容認できません。最終的には個別に判断すべきでしょうが,最低限タイムゾーンぐらいは書いておくとよいのではないでしょうか。 --eien20会話2015年4月1日 (水) 06:06 (UTC)[返信]

外国語発音記号の統一化の提案

外国語発音記号を示す場合、記法が統一化されておらず、出典から引いた場合の発音記号もどの出典かに依存し流儀が異なるのが目につきます。これを、なるべく統一化するよう提案いたします。どう統一化すべきかは別議論とは思いますが、たたき案を下記に書きました。--Kkddkkdd会話2015年4月11日 (土) 09:46 (UTC)[返信]

個々の出典にどう書かれているかにかかわらず統一せよというのであれば、出典を無視せよ、ということになります。発音記号に詳しいわけではありませんが、いくつも流儀があることが前提の提案なのでしょうから、仮に統一するとしても、どの発音記号を採るのかという時点でWP:NPOVに係る問題がないのか、疑問を感じます。また、出典にどう書いてあるかにかかわらず、統一せよというのであれば、統一記法での記載の仕方の正当性をいったいどう担保するのでしょうか(WP:NOR)。一読しただけでも次々と疑問が涌いてきます。いずれにせよ、出典を無視せよ、という命題を結果としてであれ導く余地のある提案が容れられる余地はありえません。--ikedat76会話2015年4月11日 (土) 10:02 (UTC)[返信]

コメント外国語でなくとも日本語でも、同じ単語の発音やイントネーションには多様性があります。その多様性を、出典に基づいて、多様なものとして説明することのほうが、百科事典としてはあるべき姿と考えます。実際に現実世界で統一されていないものを、統一したい、単純化したいという欲求が存在すること自体は理解しますが、Ikedat76さんがおっしゃっているように、ウィキペディアのルールにはなじまないのではないでしょうか。--柒月例祭会話2015年4月11日 (土) 14:19 (UTC)[返信]

コメント 発音の表記には国際音声記号 (IPA) を使用するのが暗黙のルール、という点で異論はないと理解しています。「化学式は元素記号で記述するものとする」などといったことはあえて明文化していない、ということかもしれませんが、英語版だとWikipedia:Manual of Style/Pronunciationがあります(ちゃんと読んでいませんが)。この点は各国語版で個別に議論するより、共通の表記ガイドがあって、そのうえで各国語版の事情に即したローカルルールを設けることが望ましいのでは、とも思います(実現性は別として)。

英語に関して言えば、現状、日本国内で流通している英和辞典の発音表記はかならずしもIPAに準拠していないはずで、日本語版記事における発音の表記も同様だと思います。例示されているen:Help:IPA for Englishは英語の発音の多様性を吸収する(en:International Phonetic Alphabet chart for English dialectsで示されるような多様性を含意する)音素表記であり、使用することに妥当性はあります。ただ、書き替えるにはそれなりの知識が必要で、現実問題としては難しいのかな、と思います。 --KAWASAKI Hiroyuki会話2015年4月11日 (土) 16:49 (UTC)[返信]

コメント2つのことを切り分けて考えるべきと見受けられます。

「化学式は元素記号で記述するものとする」というのは、ウィキペディア外部にある専門分野での合意事項(明文の合意があるのかどうかは存じませんが、従わなければ専門分野内で相手にされない、という意味で)であり、それをウィキペディアが勝手に左右することは許されません。対するに今回の提案は、ウィキペディア内のルールに係る提案であるに過ぎないと理解します。前回も書きましたが、特段語学の専門家ではありませんので、発音記号が専門家たちの間でどう取り扱われているのか承知しておりませんが、「(ウィキペディア外部にある専門分野で)いくつも流儀があることが前提」が正しいのであれば、まず専門分野に倣うのが根本的な原則です。

しかしながら、仮にIPAを使用するのが今日の原則だとしても、ウィキペディア内部で記事を書くという前提に従う限り、IPAに従わずに著された著作を出典としている場合に、その著作の記述をウィキペディアンが勝手に枉げる余地を認めることにつながる提案は許されません。かかる提案はWP:NOR、WP:Vに反する、悪くすれば偽出典とも考えうる事態をもたらすものと考えられます。--ikedat76会話2015年4月11日 (土) 20:16 (UTC)[返信]

返信 ikedat76さんの懸念は理解いたします。
ただ、現在の表記ガイドでも、原則として日付にはキリスト紀元(西暦)を用い、単位には国際単位系を用い、学術用語は『学術用語集』掲載の用語を用いることを規定しています。引用文の場合は別ですが、文献を出典とする記述においては、原則として表記ガイドに従って適宜修正することが求められます。
このうち、年号からキリスト紀元への修正は旧暦の元日の違いを意識していれば比較的単純だと思いますが、尺貫法を国際単位系に換算するには(ikedat76さんは歴史分野で活動していらっしゃるようなのでよくご存知かと思いますが)時期や地域を特定する必要があります。用語の統一についても、分野や流儀による意味範囲や用法の違いが問題になるので、記事の執筆にも、内容の検証にも、本来は充分な専門的知識が必要です(専門的知識が必要なのは適切な出典の選択や検証も同じです)
IPAも、今のところ表記ガイドで明文化されていないものの、これらと同様のものと考えます。
なぜ英和辞典でさまざまな表記が見られるのか、という点については私は英文学・英語学の専門的な教育を受けておらず、発音学についての知識もないので、本当のところはよく分かりませんが、
  • 多くの英和辞典は英米の英英事典や発音辞典を典拠としており、かつ改訂の際に発音表記を更新するとは限らないため、古い表記が残っていることが多い。
  • アメリカでは専門家でも発音の表記にIPAとは一部が異なる記号を用いることが多い(ジェフリー・K・プラム、ウィリアム・A・ラデュサー 『世界音声記号辞典』 ISBN 4-385-10756-4 にはこのあたりの事情の説明がありました)。
といったところかと思います。
現状、IPAを徹底するのは無理だろう、というのは前述のとおりです(なので末尾に追記するのではなく、ikedat76さんへのお返事とすることを優先しました)。とりあえず、IPA for English に従ってきちんと間違いなく書き換えるのは私には難しいです。 --KAWASAKI Hiroyuki会話2015年4月19日 (日) 17:46 (UTC)、一部修正:2015年4月19日 (日) 18:52 (UTC)[返信]

IPA記号を用いること自体は異論はないと思いますが、IPA記号の使い方(記法)は、出典により多種な流儀があります。(さらに方言の差異を表そうとするとさらに複数を記す必要が出てきます。) 英語wikipediaには、en:Help:IPA_for_English(およびen:International_Phonetic_Alphabet_chart_for_English_dialects)やen:Help:IPA_for_German が整備され、ある種の指針のようです。しかし日本語wikipediaにはこのような指針が無いので、現状は、出典Aも出典Bも流儀は許され、混在・同居しています。例えば出典Aから貼付けて書いたとして「英語: box英語発音: [bɑks]」とすると、それは英語発音: [ɒ]英語発音: [ɑ]とを書き分けない(後者で書く)流儀に基づいていると判断できますが(ただし可能性は低いですが Irish 方言を忠実に表そうとしているのかもしれませんが)、これはen:Help:IPA_for_EnglishのDiaphonemeの流儀に基づいて書けば「英語発音: [bɒks]」です。しかし高度な事柄なので、普通の人は、意識せず、出典Aから貼付けたり、出典Bから貼付けたりすることになってしまうのはやむを得ないのかもしれませんね。--Kkddkkdd会話2015年4月16日 (木) 17:57 (UTC)[返信]

コメント en:Help:IPA for English はいわゆる音素表記なので、[bɒks]ではなく、/bɒks/とすべきものです。
英語版では上で示したとおり、Wikipedia:Manual of Style/Pronunciation で規定されており、表記ガイドとしての扱いです。きちんと読んだわけではありませんが、英語は音素表記としているようで、en:Help:IPA for English のようなルールを導入することが必要になります。英語以外は音声表記であり、en:Help:IPA for German はIPAでの一般的な表記を示しているに過ぎないと思われます。 --KAWASAKI Hiroyuki会話2015年4月17日 (金) 01:03 (UTC)[返信]
コメント 私の意見としては、表記ガイドにIPAについての言及ぐらいはあったほうがいいと思います。
ただ、記事名や本文中での外来語において、既存の外国語辞典等でのカナ表記や発音表記を出典として示し、適切な表記が行われることのほうが重要であって、細かなルールを増やすことはむしろ望ましくないと考えます。 --KAWASAKI Hiroyuki会話2015年4月19日 (日) 18:20 (UTC)[返信]

rubyタグを使用した読み仮名表記についての改定案

rubyタグの使用について、下記のとおり「読み仮名の要否」節の改正を提案したいと思います。内容としてはrubyタグ使用制限の一部緩和です。

【現行】

【修正案】

  • 文中の読み仮名には丸括弧()を用います。表組や情報テンプレート、囲みの引用文などに限り、HTML上の <ruby>……</ruby> タグを使用して構いません。音声読み上げの対応が必要な場合はテンプレート{{読み仮名}}と{{読み}}を使用してください。

理由は、

  • 当サイトは2012年よりruby要素を正式採用したHTML5に移行済みであること
  • span要素へのclass指定とスタイルシートのカズタマイズによるルビ表示を補助するためのテンプレート{{ルビ}}と{{音声ルビ}}廃止の作業が完了し、ruby要素を使用して音声UAでの読み仮名の読み上げに対応(文字媒体での出力は表記ガイドどおり括弧書きで出力)するテンプレート{{読み仮名}}と{{読み}}が新規に導入されたこと
  • 旧テンプレート廃止作業の過程で、脚注などで原典の引用文にルビ表示用のテンプレートを使用していたケース(おもに難読な古文の補記など)が相当数みられたこと
  • 表組みや基礎情報テンプレートなどでは地名・人名・著作物名などの固有名詞を記載する機会が多く、なおかつレイアウト上の手段としてルビ表示のニーズはあるように思われること
  • とはいえ、記事本文を含めた読み仮名すべてにrubyタグを使用するのは編集実務上の負担が大きすぎるため、読み仮名の表記統一を重視するなら、記事の本文については、より編集上の負担が少なく可読性についても無難な括弧書きの表記方法を引き続き採用するのが現実的に最善と考えられること
  • 表組みや囲みの引用文などに関しては地の文と明瞭に区別されて書かれるため、読み仮名の表記方法が記事本文と異なっていても表記上の不都合が生じる懸念があまりないこと

です。--ディー・エム会話2015年4月29日 (水) 14:57 (UTC)[返信]

報告 特に反対がありませんでしたので、提案どおり改定しました。--ディー・エム会話2015年5月7日 (木) 12:25 (UTC)[返信]

国際単位系(SI)におけるコンマのあり方。

表記ガイド#数字に例として"384,400キロメートル"というのが上げられていますが,それは"38万4400キロメートル"と等価ではなく,"384.4 km"という意味です。JISX 8000において3ケタに区切る際にはただ唯一スペースによると規定されています。他方で小数点はピリオドもしくはコンマでなければならないと規定されています。SI文書においても同様の規定があります。以上の理由から変更を提案します。自分で"abc,def"(ラテン文字は任意の1桁の数字。以下同じ。)と入れるのはまだしも(変更できますから),templateの中に"abcdef"と書いたさいに勝手に"abc,def"とされるのは悪質だと言わざるをえません(他のパラメタと同期している場合があり,abc defといれると不都合がある)。なおこの提案は国際単位系のみに言及しており,他の事項(いわゆるヤード・ポンド法や人口 ほか)には関係がありません。よろしくおねがいします。--eien20会話2015年8月20日 (木) 10:10 (UTC)[返信]

コメント >例として"384,400キロメートル"というのが上げられていますが,それは"38万4400キロメートル"と等価ではなく,"384.4 km"という意味です。
これは
"384,400メートル"(表記ガイドにはこの単位での表記はない)は"38万4400メートル"と等価ではなく,"384.4 km"という意味です。
というのと勘違いしていないでしょうか?--Don-hide会話2015年8月20日 (木) 10:16 (UTC)[返信]
返信 (User:Don-hideさん宛)

ありがとうございます。いいえ,一番最初に書いたので間違えありません。"384,400 km"は384.4*103 mであるし,"384.400 km"も384.4*103 kmです。先ほど挙げた文書にはそう書いてあります。日本語がどうだのはなしではありません。よろしくお願いします。 --eien20会話2015年8月20日 (木) 10:34 (UTC)[返信]

Don-hideさん、英米日では桁区切りにコンマ、小数点にピリオドを使うけれど、大陸ヨーロッパ諸国では逆なので、科学技術分野ではコンマもピリオドも小数点と扱って、桁区切りはスペースにしましょう、という流儀があるという話です。そして、現行のWikipedia:表記ガイド#数字でも、桁区切りの方法は3種類あって、3番目にこの方法が挙げられており、現状でも使うことは可能です。なお、この規定はWikipedia‐ノート:表記ガイド/過去ログ10#多桁の数字の区切りで提案があって追加されたものです。
JISで規定されている、と言いますが、ウィキペディアは必ずしもJISに従っているわけではありません。日本語圏の社会において一般的な流儀等を考慮して決めているので、JISでこうだから、と言ってもそれに統一することが自動的に決まるわけではないです。科学技術分野での表記法も認められていますから、その分野においてはそれを使うように提案してやってもらう他ないと思います。全体を、単なる一分野に過ぎない科学技術分野に合わせることはできません。たとえば、人口などは違う、と言いますけど、自治体のテンプレートなどでは面積も含まれているわけで、平方キロメートルもSIの単位のはずです。SIだからと言って、桁区切りをすべてスペースにすることが現実的であるとは思いません。日本社会がそれに対応したなら別ですが。--Tam0031会話2015年8月20日 (木) 15:46 (UTC)[返信]
コメント JIS Z 8000 (量および単位-第1部:一般)という規格があって、その中では確かに「桁区切りはスペースのみを用いる。小数点はカンマまたはピリオドを使用する」と定められています。そのためJISの影響が及ぶ科学技術分野において"384,400キロメートル"のような3桁区切りカンマでの表記をすべきでない。というのはそのとおりの話です。ところが「数字は3桁区切りカンマで表記すべきである」という慣習のある分野もあります。例えば官公庁では公用文作成の要領に基づいて、数字は3桁ごとにカンマで区切ることになっています。つまりこの要領に従っている分野では、"384,400キロメートル"というのは適切な表記ということになります。
百科事典であるウィキペディアでは様々な分野の慣習が入り混じることになります。これを一つに統一してしまうのは現実的でないので、分野ごとの慣習に基づいて記述することになります。Eien20さんご指摘の"384,400キロメートル"は科学技術分野ではなく、財務分野、製図分野などでの慣習という扱いです。先に示したとおり、この表記が適切となっている分野があるため、これはそのまま残しておくべきです。科学技術分野における慣習も表記法の1つとしてガイドに記載されているので、必要に応じて使い分けることになるでしょう。
なお、主に科学技術分野で用いられるテンプレートにおいて、数字が強制的に3桁区切りカンマで表示されてしまう。というのは確かに好ましくないことです。もしそのようなテンプレートがあれば、修正を提案するのは適切であると考えます。--153.200.156.92 2015年8月21日 (金) 01:06 (UTC)[返信]

仮名書きと漢字を使い分けるものについて

提案 「動詞で使う場合は漢字で、接続詞としては仮名で」の例として「従って」のみになっています。しかし、それ以外にも接続詞の「および」・「ならびに」も「従う」と同様に「及ぶ」・「並ぶ」という動詞の活用形として使用する場合は、漢字を使うので、「従って」だけでなく「動詞の活用形で使う場合は漢字書きしてもよいが、接続詞としては仮名で使い分ける。」として例示して追加すべきであると考えます。

なお、この提案が採用されない場合でも「従って」の「例: 父に従ってアメリカへ行くことした。したがって私はアメリカについて学び始めた。」は、日本語として不自然な文章であるので、「父に従ってアメリカへ行くことした。したがって私はアメリカについて学ぶ必要がある。」等に変更すべきであると考えます。 --TOSHIFUMI NAGAO会話2015年9月21日 (月) 10:48 (UTC)[返信]

コメント 反対寄り。そもそも、いちいち漢字表記/仮名表記が望ましいだの規定することが望ましいとは思いません。自分で良し悪しを判断できない輩が、機械的に訳も分からず暴れまわるだけです。「及び」「並びに」については、むしろ漢字表記も可としても良いくらいでしょう。読売・朝日・毎日・講談社の手引きでは「漢字表記可」、公用文の手引きでは「原則漢字表記」とする語句です。念のためお聞きしますが、過去の議論くらいは目を通しましたか。規定の内容を変更するものではない例文の変更については勝手にどうぞ。--Hisagi会話2015年9月21日 (月) 11:28 (UTC)[返信]
コメントHisagiさん、コメントありがとうございました。「過去の議論」の「仮名」節の変更について2(過去ログ7)など目を通しています。接続詞の「および」・「ならびに」についての仮名書きの現在の表記ガイドについては、公用文の手引きや新聞社などの手引きにかかわらず、現状維持が望ましいという立場です。「動詞の活用形で使う場合は漢字書きしてもよいが、接続詞としては仮名で使い分ける。」とまで、わざわざ書く必要もないことは、理解できました。提案撤回といたします。例文については、特に反対意見がなければ、変更させていただきます。--TOSHIFUMI NAGAO会話2015年9月21日 (月) 13:27 (UTC)[返信]
コメント「そもそも」から「暴れまわるだけ」まで、Hisagiさんと同意見です。例文の変更はまあ、そこを直さないと気が済まないならいいのでは、と思います。が、そもそも論としては、韻を踏みたいのでもない限り、「父に従って・・・したがって私は」と漢字&ひらがなに書き直して大満足するぐらいなら「父と一緒に・・・そんなわけで私は」と表現自体を改めることを考えたほうがいいんじゃない?的なアドバイスのほうが捗るんじゃないかなと感じました。もっとそもそも言うと、そこも含めてそれぐらい自分で考えようよ、ということで。--柒月例祭会話2015年9月21日 (月) 13:58 (UTC)[返信]
コメント 仮名書きの節に、かな書きとすべき接続詞が提示されており、その中に「および」も「ならび」も含まれています。--Assemblykinematics会話2015年9月21日 (月) 21:24 (UTC)[返信]
コメント Hisagiさんが言うべきことはいっていると思いますが、反対の意思表明のために。日本語に「拘る」(「ちょっとしたことを必要以上に気にする。気持ちがとらわれる。」「難癖をつける。けちをつける。」〈デジタル大辞泉〉)のは個人的趣味でやる範囲では結構ですが、そういうもので他人を縛ろうとしゃしゃり出てくるのはやめてください。迷惑であるだけでなく、愚昧な輩に遊び道具を与えるだけにしかなりません。--ikedat76会話2015年9月21日 (月) 22:57 (UTC)[返信]
コメント 「迷惑であるだけでなく、愚昧な輩に遊び道具を与えるだけにしかなりません。」ということは、十分わかりました。「しゃしゃり出てくる」なというご批判もわかりました。--TOSHIFUMI NAGAO会話2015年9月22日 (火) 00:50 (UTC)[返信]
コメント 念のためですが、私は「何でもかんでも(漢字・かな双方ともごく一般的な語句まで)規定するのは良くない」と言っているだけで、たとえば「然し」だの「或は」だのの漢字表記には断固として反対ですし、過去の議論でもそのようにしています。--Hisagi会話2015年9月22日 (火) 00:59 (UTC)[返信]

表記ガイドの人名について(容疑者は敬称として扱うか?)

Wikipedia:表記ガイド#人名において、以下のように記されています。

原則として、人名に「○○様」、「○○さん」、「○○先生」のような敬称は付けないでください(Wikipedia:スタイルマニュアル#人物・人名によります)。
ただし、これは付けることが慣習となっているものまで付けてはいけないということではありません。

容疑者は敬称の項目で、「敬称に準ずる物、蔑称」とされています。しかし、「ニュースなどで既に慣習となっているもの」、もしくは容疑者の項目のように「犯罪の嫌疑を受ける者を指す法律用語(に準ずるもの)」であるとも考えられるのですが、これは付けない方が良いのでしょうか?皆さんのご意見をよろしくお願いします。--Tekeonin会話2015年11月16日 (月) 12:43 (UTC)[返信]

記事を書いている時点で何らかの容疑をかけられており、それを書くことが将来にわたり名誉棄損などにならないという場合ならば、操作や裁判の経緯のなかで容疑をかけられていることをわかりやすく読者に示すことは書かれて良いと思いますし(法律用語としての容疑者)、そのなかで「名前+容疑者」という表現を用いたほうがよければ、それはそれでよいと思います。しかし、本文で繰り返し「名前+容疑者」と書く必要はないでしょう。「何々の容疑で逮捕された。警察発表によれば、誰々はああしたこうした」と書けばよく、「何々の容疑で逮捕された。警察発表によれば、誰々容疑者はああしたこうした」とは書かない。これはニュースなどでそのような慣習があるとしても、ニュースと百科事典の役割や文章の違いがあるため、百科事典としては違う表現を用いる、ということになると思います。「付けることが慣習となっているもの」というのは、孔子聖徳太子聖アグネスのようなものと考えています。--Ks aka 98会話2015年11月16日 (月) 14:09 (UTC)[返信]
要するに、敬称での扱いではなく、「立場」を説明するための「法律用語」として考えるなら利用可能という事ですね。そして「肩書、立場などは、その都度人名と合わせて表記すると文章が冗長になるので、適宜いずれかを省略してください。」と。なるほど聖徳太子、孔子の子は敬称でしたね。失念してました。ありがとうございます。--Tekeonin会話2015年11月16日 (月) 14:33 (UTC)[返信]
  • 記事と文脈しだいですが、ニュースとの兼ね合いに関して。ふつうはどこかの時点で「容疑者」から「犯人」(かそうでないか)になっていきます。NOTNEWSの観点では、「容疑者」である時点ではそもそも書くべき時期ではない、ある程度いろいろなことがいろいろなところに落ち着いてから書き始めれば良い、と思います。もちろん文脈によって200年前の事件でも「容疑者」という表現が出ることはあるでしょうから、それはそれとして。---柒月例祭会話2015年12月17日 (木) 09:53 (UTC)[返信]

「数字」の項目における注記の削除

表記ガイド全体のなかで、数字の項のみに、以下の記述があります。

  •  (注意:ノートで議論中。まだ正式なものではありません)

この注記は2007年11月25日に挿入されたものです。これ以降に、過去のノートで数字の書き方について何回も繰り返し議論され、修正されてきています。そして2013年12月以降は、書き方そのものの変更はなされていません。

もし、数字の表記方法についての議論が更になされてガイドを修正すべきであれば、(他の項における修正と同様に)合意に基づいてその時に修正すればよいのであり、上記の注記を現時点で残しておく意味はないと思います。このため上記の注記を削除することを提案します。

併せて、表記ガイド全体のなかで、この数字の項のみに、「です・ます体」ではなく、「だ・である体」が混じっていますので、「です・ます体」に統一することを提案します。 --Awaniko会話2015年12月5日 (土) 04:56 (UTC)[返信]


他に意見がありませんので、上記に基づき、修正しました。--Awaniko会話2016年1月27日 (水) 12:15 (UTC)[返信]

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

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

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

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

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

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

さらに、どちらの文字も環境によっては文字化けする問題があるためでもあります。
  • 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環境(確認くん[17]の情報を信じるなら、恐らく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)[返信]
コメント 追記 なお、(文字コードの問題はさんざん繰り返されているはずなので車輪の再発明的な部分もあるかとは思いますが)具体的に問題になるのは以下の場合だと思います。
  1. スクリーンリーダー点字ディスプレイなど、バリアフリー環境がJIS第2水準外に対応していない場合
    • ダブルハイフンの全角等号での代用、ハイフンマイナスとハイフンと負号とダッシュの混用はテキストの正しい解読を難しくする部分もある
  2. 日本語入力システムやテキストエディターなど、入力時に使用するソフトウェアがJIS第2水準外に対応していない場合
  3. 閲覧者が記事等を再利用するソフトウェアがJIS第2水準外に対応していない場合
  4. 記事等の表示・印刷時に使用するフォントに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つに分類して示されています。そして3つの書き方の例として、それぞれ3例が示されています。 「3.整数部分、小数部分ともに、3桁ごとにスペースを入れます(例:科学技術分野など)。」の場合も、3例を示しました。2例で良いとの意見がありましたが、リバートしました。

理由1:1.2.の両方とも次のように、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

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

コメント 編集の要約欄では意図を伝えきれず混乱を生み、失礼いたしました。こちらで改めて説明させていただきます。
今回私が疑問に思ったのは、リュードベリ定数の例が{{Val}}を使った記述である点です。記事中でこのテンプレートを使うのであればともかくですが、少なくとも本稿においては以下の理由から表記ガイドの他の部分の記述との整合が良くない部分があるため、ここでの例に用いるには向かないと思ったのです。これは同時に使われている{{sup-}}についても同様ですが。
これらのテンプレートは文字参照&minus;の手間を省き、簡単にマイナス記号(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)[返信]


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


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

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

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

コメント 分かりにくい文章だったようで、申し訳ありません。分かりやすくなったかどうか自信はありませんが、また長文失礼します。
順番が前後しますが、結論から言いますと、3)について表現の統一を求めているわけではありません。その他の理解については全面的には否定しませんが、その前提となる根本的な部分で誤解があるようですので、それらについて述べます。
2)について、もちろん方針で禁止されていない限りは、記事中では様々な表現が許されています。ただ、現場で使われている表現だからと言って、それらすべてが推奨できる表現だとは限りません。
「表記ガイド」はWikipediaのガイドラインという位置付けであり、通常の記事とは扱いが大きく異なります。多くの利用者に手本を指南することになる文書ですから、それなりの合意を根拠とした、優先的に記述できる内容が求められます。表記ガイドの冒頭では大きな変更には提案が必要とありますが、だからといって小さな編集が自由とは限りません。例の追加程度であっても、議論の余地があるものは議論が必要です。ましてや本件には明確な異論が出ているのですから、結論が出るまでは独断で本文に反映しないでください。
表現の統一が目的というわけではないにせよ、同じ表記ガイド内に「-」(←これは「半角ハイフンマイナス」と言い、ハイフンとマイナスのどちらにも使われます。)と「−」(←これは単なるマイナス記号で、ハイフンとしては使えない文字です。)の2種類の表記揺れがあれば、当然、読者は疑問を覚えるでしょう。そうなるとそれについて表記ガイドに新たな補足説明を招くことに繋がります。そうなれば「大きな編集」に該当しますので、議論なしに追加する例としては不適当ではないかと言っているのです。なおプランク定数のtexによる表記例については画像で表示されますから、両者の区別が問題になることは無いと考えましたので、ここではtex表記は問題視しませんでした。
1)について、おっしゃるように{{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さんへ:

1)議論が混乱していると感じています。

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


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

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

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

6)なお、長文の記述をされる場合は、お互いの文章の引用が可能なように、番号を付していただけると助かります。 --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

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

提案の背景として、まずこれまでの経緯を大雑把にまとめてみます。前述の通り英語版ではマイナス目的でマイナス記号「−」 (&minus;, 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) 負数減算の表記にはハイフンマイナス - ではなくマイナス − (&minus;) の使用が推奨されています。ただし、ハイフンマイナスをマイナスに変更するだけの編集は避けてください。

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

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

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

コメント 私自身は数学分野で特に貢献しているわけではないので利点について実感は無いのですが、それだけに貢献している方々の足を引っ張るのはあまり本意ではありません。文字化け対策としては、独立した式は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.編集ボックス下の特殊文字リンク
私は数学の分野の記事にはあまり触っておりませんが、物理の分野の記事にはよく触らせて戴いております。やはり物理の分野の記事にも数学の数式は頻出しますので、数学記号は本文中でも多用しております。ですので、私もよく使わせて戴いているのですが、正直に申し上げまして、何度編集を重ねていても、未だに「–」「—」「−」の差異が分かっておりません。恐らく「ハイフンマイナス」「ハイフン」「マイナス」なのでしょうけど(順不同)、私には区別が付きません(因みにこれは右の図1.より打ちました)。これより以下に私個人の意見を述べさせて戴きますが、私は数式の編集そのものは頻繁にしながらも記号の表記揺れについてはほとんど無知で無理解な人間なのだと言う前提において述べますので、皆様方もそのことを念頭に置きつつお読みになって戴けると幸いに存じます。
まず、この3種の似た文字種を編集時に打ち出す時に関して私の個人的な所見を述べるとすれば、私がWindows7で使用しているGoogle 日本語入力Baidu IME|Microsoft Office IMEと言った3つのエンジン(残念ながらATOKは使用しておりません)に関しては、3種の半角文字を全て出すのは不可能なようです。またスマートフォンで入力する際も、これらに文字入力画面で明確な差異は見当たりません。となると、合理的に全ての文字種を恣意的な選択で出すのであれば、図1.のような編集ボックス下の特殊文字リンクから打つのが妥当な方法となると思います。しかしながら、現状この編集ボックス下の特殊文字リンクと言うのは、スマートフォンでは表示されない環境になっている上に、表示される環境にあるPCでも、各記号が何を指し示しているのかについての説明文のようなものがなく、使う側からすると多少は不便なようにも感じます。この特殊文字リンクがどの様な方法で作成され、どの様に編集画面に読み込まれているのかは存じ上げませんが、この特殊文字リンクを改良すれば、「ハイフンマイナス」「ハイフン」「マイナス」の使い分けを編集者がより簡単に出来るようになるのではないでしょうか。因みに、このパラグラフの問題は丸々「全角チルダ」と「波ダッシュ」との問題にも当てはまるかと存じます。
ただ、この場所はあくまで「表記に関するガイドライン」を策定する為の場所ですので、「編集に関わる行為」について議論する場所ではない事は重々承知しております。ですので、あくまでも「ページの編集」や「特殊文字」と言ったヘルプページや数式表記に関連する数学物理学と言ったプロジェクトページなどで、それぞれのノートページにて議論を重ねて結果が出た後で、こちらでも再度合意形成を得てガイドの本文を改定すると言った流れの方が良いのではないのでしょうか。--知識熊会話2016年3月18日 (金) 21:44 (UTC)[返信]
返信 その3つの記号は,それぞれエヌダッシュ,エムダッシュ,マイナスであり,欧文(英文の文章作法)に馴染みのない方だとご存じでない場合もあるようですが,ハイフンとは全く異なる記号です.それぞれ,文字実体参照で &ndash;, &mdash;, &minus; としても入力可能です.編集ボックスについては,ダッシュ類はともかく,マイナスは記号の並びから明らかではないでしょうか.ハイフンマイナスはキーボードだと右上から普通に入力できるやつです.なお,エヌダッシュは日本語版ウィキペディアにおいても特に出典等でしばしば用いる記号です.新規作成 (利用者名) 会話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じゃ全角しか出てきませんし、半角のマイナス記号を一発で出力しようとするとやり方をちょっと考えてしまいますよね。文字コードで変換とか文字実体参照とか辞書登録とかしないと普通に出てこないとなると、正直なところそれらの記号の使い分けを一般ユーザーに求めるのは無茶な話に思えてしまいます。ちょっと調べると、ハイフンマイナスはハイフンおよびマイナスを包摂する記号として広く使われているということみたいですし、基本ラインはマイナスもハイフンも意識せずとも簡単に入力できるハイフンマイナスで代用するということで何の問題もないと思います。数学記事であったり、ハイフンとマイナスを読み違えると文意が変わってしまうような、分野やケースを限定してハイフンとマイナスを厳密に区別する必要がある場面に限った話であれば特に反対はありませんが。ですが、そうでない場面でまで厳密な区別を求める必要はないのではないかと思います。そういう意味ではむしろ、そういう細かいところを気にする人が「ハイフンマイナスをマイナスに変更するだけの編集」でも構わないのでやってくださればいいのではないでしょうか。--重陽会話

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

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

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

2

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

念のため確認しますが,−(&minus;) の推奨に反対されている方はもちろん ·(&middot;) や ⋅(&sdot;) のような記号の推奨にも反対ということでいいのですよね?(どうして以前の表記ガイドにはあった &minus; はハイフンマイナスに代わったのに &middot; は使われているのか謎です.)新規作成 (利用者名) 会話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−1やm−1に変えるということでしょうか?そのぐらいであれば、推奨と言う名の強要にはなりにくいでしょうし構わないと思います。
あと、その他節の紛らわしい文字に気をつけるという部分で「ダッシュ・全角ハイフン・全角マイナス・長音記号・罫線」の例示がありますが、その横の記号の文字コードを見ると3つ目の全角マイナスに対応しているのが半角ハイフンマイナスになってしまっているみたいで、この辺りは整理したほうがいいかもしれませんね。文字化けを理由に反対されている方との合意が取れるのであれば、ここにマイナス(&minus;)を入れておくのもひとつかもしれません。
以下は本件の合意形成部分とはちょっとずれますが、疑問点として。その「きちんと使いましょう」という考え方にはどの程度のレベルのコンセンサスがあるものなのですかね?国際的な標準化団体で勧告されているレベルなのか、世間一般の常識なのか、単なる個人的主張なのか。ハイフンマイナスの記号の歴史的経緯は分かりますが、それは別として今現在どのように扱うべきなのかという部分ですね。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)[返信]
例えば化学工学論文集では、[18]では最終行の単位の部分のマイナスがU+FF0D(全角ハイフンマイナス)になっています。[19][20]でも、マイナスの部分が同じくU+FF0Dです。逆に有機合成協会誌の[21]では、旋光度の向きを示すプラスマイナスのマイナス部分は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の半角ハイフンマイナスを使っている例であれば、日本材料学会誌の[22][23][24]、素材物性学会誌の[25][26][27]、エアロゾル研究誌の[28][29][30]などがありました。見回った範囲での使用状況は、全角ハイフンマイナスは半角ハイフンマイナスよりもさらに多く、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のパソコンだとマイナス記号を簡単に出せたような記憶があります(今すぐには確認できませんが).数式入力時は普通半角なのだから全角ハイフンマイナスの方が入力の手間がかかります.上にも書いたようにマイナス記号は(デスクトップ表示だと)編集画面下部にある記号をクリックしても入力可能です.実体参照がハードルが高いというのは<sup></sup>による上付き添え字がハードルが高いというのと同じくらい馬鹿げています.もっと言えばウィキ独特のマークアップの方がハードルはかなり高いです.というかこんな数回使えば覚える程度のことでハードルとか言い出すのは編集者を馬鹿にしているとしか思えません.「数学や物理のような特定分野にしか浸透して」いないのではなく重陽さんに探していただいたような特定分野に浸透していないのでしょう.新規作成 (利用者名) 会話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) での発言が必要以上に強い口調になってしまったことをお詫びします.また,急いで返信したため言葉足らずな部分もありますから,それを補っていきます.
「マイナスにハイフンマイナスを使わないのが当たり前」と私が言っていないというのは,私とあなたで「当たり前」を異なる意味で使っているということです.たとえて言うならば(適切なたとえではないかもしれませんが他にいい例が思い浮かばないもので),私は赤信号では停まる/横断しないのが当たり前だと言っているのに対し,あなたは信号無視してる人はたくさんいるよと言っているのです.(蛇足ですがプログラミング言語は救急車といったところですかね.)私の主張は「&minus; が正しいマイナス記号でありそちらを使うべき」であって,それが「世間一般に広く受け入れられている」かどうかはメインではなかったのです.そういうわけで,実際の使用例を出したところで,(重陽さんの調査自体は有用ではあるけれど)私の主張に対する反論にはならないのですよね.ハイフンマイナスを使っているのが意図的にそちらを選んだ結果なのかそうでないのか分からないからです.「そうじゃないという指摘」をしなかったのは,単にそのときは特に問題ないと思ったからです.
例からマイナス記号を除くには,光速度については単位を 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 のウェブページとかであっても同じことで(というよりはパソコン等で入力・表示するこのような場合についてこそ言うべきことですが),何度も言っているように &minus; が正しいマイナス記号なのであって,ハイフンマイナスはそれが使えないときの代用でしかないのです.機種依存文字を回避したいなら極論全部 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 = &minus; のことを指すこともあるようですから,はっきりさせておいた方がいいでしょう.新規作成 (利用者名) 会話2016年3月30日 (水) 05:16 (UTC)[返信]
符号位置を見る限りJIS X 0213ではハイフンマイナスに全角と半角の区別はないようですので、もしかしたらJIS X 0213ベースのブラウザかエディタで編集した際に、全角ハイフンマイナスが勝手に半角ハイフンマイナスとして扱われた可能性も考えられそうです。もしそのようなことがあるなら念のため、表記ガイドの説明文では全角ハイフンマイナスのソースを文字参照(&#xFF0D;&#65293;)にしておいたほうが無難かもしれません。--Gwano会話2016年3月30日 (水) 10:02 (UTC)[返信]
ところで &minus; が空白になってしまう環境で全角ハイフンマイナスはどのように表示されるでしょうか?新規作成 (利用者名) 会話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)[返信]
ですから「入力の手間」は執筆者のわがままですから(平方メートルを m<sup>2</sup> と書くのがめんどうだからといって m2 あるいは m^2 と書いていいことにはならないのと同じです),デメリットにはなりえません.(それに,表記ガイドは通常の編集に大して影響があるわけでもないですし.(例えば半角括弧(括弧内に半角のみでも全角が使われる)とか半角括弧の前後や単位の前のスペース(がない)とか見れば明らか.))
「ある程度の長さがある」だけでは「マイナス目的でも充分通用する」とは思えません.マイナス記号と(ほとんど)全く同じ長さの場合があるならそれは別として,ハイフンマイナスはいくつもの意味で用いられるのですから読者に余計な負担をかけることになりますし,ハイフンマイナスがハイフンと認識されるような環境を完全に無視することになります.(もちろん正しいマイナス記号を使うと一部環境で表示されないのでどちらをより考慮するかという問題になるわけですが.)新規作成 (利用者名) 会話2016年5月20日 (金) 04:47 (UTC)[返信]

3

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

案1a
例:光速度 c = c0 = 299 792 458 m/s
例:プランク定数
例:リュードベリ定数

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

コメント 例の中でマイナス記号を使わない分には個人的には構わないのですが、結局のところ「1. 表記ガイド内ではマイナス記号 (U+2212) はとりあえず使わない」、「2. 表記ガイドではマイナス記号 (U+2212) の具体的な扱いについては言及しない(禁止も推奨もしない)」という形になるのでしょうか?
一応、事の発端としては記事中でマイナス記号とハイフンマイナスが混在されていることに対して疑問を持った利用者に何らかの回答を用意する意図もあったので、禁止も推奨もしないのであれば、
  • 減算や負号としては一般的な半角ハイフンマイナス - (U+002D) が使えますが、英語環境や数学・物理の専門分野などではマイナス記号 − (&minus;, U+2212) が使われる場合もあります。
……くらいの、それなりに当たりさわりの無い説明があっても良い気はしますが、どうでしょう。できればオプションとして、
  • ただし、機器組み込みブラウザのようなごく一部の環境ではマイナス記号 − (U+2212) が表示されないケースが確認されており、正負を誤認する可能性が指摘されています。
……にも、個人的には言及したいところです。最近の表記ガイドではマイナー環境の文字化けに関してはあまり言及しない傾向があるようですが、本件は単なる文字化けでは済まない部分がありますので、例外的に。それとも、あまり細かいことはプロジェクト側で考えるべきでしょうか? --Gwano会話2016年4月8日 (金) 12:50 (UTC)[返信]
1については案1aでそう提案してみた,2については議論が停滞中,というところでしょうか?なんらかの言及をしてもいいかもしれませんが……うーん.
  • マイナスを表す記号には、マイナス記号「−」(&minus;, 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)[返信]

数式の節

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

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

以上コメントアウトを除いて引用.まだ改善の余地はありますので何かありましたら編集するなり意見を述べるなりしてください.新規作成 (利用者名) 会話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さんが提案してくださった改訂案([31])が良いと考えていますので、そこに少し例目を補足した以下のような改訂を提起いたします。何かご意見があれば承ります。

  • 作品及び作品群(書名・雑誌名・交響曲などの曲名・組曲などの名称・CDなどのアルバム名・映画名・戯曲名・小説名・テレビの番組名・イベント名・大会名など)の名称は、和文では『 』で囲み、欧文では(入力を''……''として)イタリック体にします。
    • 例:『海辺のカフカ』・『坊ちゃん』・『動物の謝肉祭』・Yesterday ... and Today・『ローマの休日』・『報道ステーション』
  • 作品中の小題(書中の章名や見出し名・小説の章名や話名・戯曲の幕名や場名・交響曲などの楽章名・テレビ番組の企画名や話名など)は、和文では「 」、欧文では、英文における “...” または各言語においてそれに相当する括弧で囲みます。
    • 単独の作品でも、作品群中の一作品として表わす場合(雑誌中の収録論文名・作品集や全集中の収録作品名・詩集中の詩名・組曲中の曲名・シングルやアルバム中の曲名など)は同様とします。
    • 例: Nature “Molecular Structure of Nucleic Acids”・『展覧会の絵』「プロムナード」・Yesterday ... and Today “Yesterday”・『古畑任三郎』「ラストダンス」

--みしまるもも会話2016年5月15日 (日) 02:09 (UTC)[返信]

  • コメント 短編や長編で扱いを分けないのは当然の処置なので、『』への統一そのものには賛成です。しかし、これはこれで別の問題が発生しています。実は、そもそも括弧を使用する必要がないケースも数多くあります。例えば、スポーツの大会や、国際博覧会に「必ず」逐一括弧を付けるものではありません(オリンピックが近いので、感覚的にはそちらの報道を見ると判りやすいかと)。これは、主題や文面から自然に判明するためです。ですが、この文面ではそういった無意味な括弧付与に走る事態が確実に発生します。それは、非常に申し上げにくいのですが、「荒らしの武器」になってしまいます。かつて問題になった『』「」の使い分けのようなスタイル強要という問題ユーザーの行動パターンが存在することを忘れないで下さい。この問題は、「作品名に対して括弧を『使用する』場合」に限定すれば、解消できます。
ついで、イタリックは環境面から問題があります。小さい画面ですと表示が潰れますし、フォントがイタリックを保有しているとは限りません。スタイル的に2バイト・1バイトで表記を変えるべきかどうかも問題です。さらに、日本の作品でたまたまラテン文字だけで構成されている、本質的には「和文」であるものまでイタリックにしなければならないのは不自然です。これは、括弧で対処することを可能とすることで対処できます。以下に修正案を示します。

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

  • 固有名詞でないものは括弧など特別な修飾を付けないでください。
例: 交響曲 第9番 作品95 『新世界より』
  • 作品および作品群(書名・雑誌名・曲名や組曲などの名称・CDなどのアルバム名・映画名・戯曲名・小説名・テレビの番組名など)の名称を括弧で囲む場合には、『 』で囲みます。欧文では(入力を''……''として)斜体とすることもできます。ただし、環境により斜体は反映されない場合もあります。
例:『海辺のカフカ』・『坊ちゃん』・『動物の謝肉祭』・Yesterday ... and Today・『ローマの休日』・『報道ステーション』・『ONE PIECE』
  • 作品中の小題(書中の章名や見出し名・小説の章名や話名・戯曲の幕名や場名・交響曲などの楽章名・テレビ番組の企画名や話名など)は、「 」で囲みます。日本語以外の言語に対しては、英文における “...” など各言語において「」に相当する括弧で囲むこともできます。
単独の作品でも、作品群中の一作品として表わす場合(雑誌中の収録論文名・作品集や全集中の収録作品名・詩集中の詩名・組曲中の曲名・シングルやアルバム中の曲名など)は同様とします。
例: Nature “Molecular Structure of Nucleic Acids”・『展覧会の絵』「プロムナード」・Yesterday ... and Today “Yesterday”・『古畑任三郎』「ラストダンス」
  • リンクに『』や''などの記号を含めないよう注意します。
みしまるももさんの提案からの主な変更点
  • 括弧を使用する場合の使い分けなので、冒頭で宣言。
  • エヴァンズの秘書さんの指摘通り、「および」に変更。
  • イベントや大会は著作物の節にあるべきではありませんからこれらを外します。
  • 作品および作品群では交響曲に限定する必要はありませんし、中黒が不自然な位置にあるので修正。
  • 現在**ではなく::を使用していますので、そちらに合わせました。またこの場合に、<br/>は不要です。
  • 和文・欧文の記法統一を可能として、現行の分離式との選択にします。
    • これに対応して例を追加。漫画がなかったので、漫画から『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アルバムの一曲として成立したわけではないので、一筆補足してみたわけです。以下の文ならあいまい性はなくなると思うのですが、どうでしょうか。でも、この補足事例は特記する必要もないかもしれないので、反対ならば無くてもかまいません。
コメント みしまるもも様、修正いただきありがとうございます。修正内容に異存はありませんが、例示されている『蛍の光』はスコットランド民謡『オールド・ラング・サイン』に稲垣千穎が日本語歌詞を付けたもので、「口承で伝わった民謡」の例としては適切ではないと思います。かといって『オールド・ラング・サイン』はそのタイトルが一般的とは言い難いです。『グリーンスリーブス』(イングランド民謡)・『一週間』(ロシア民謡)・『ロンドンデリーの歌』(アイルランド民謡)・『もみの木』(ドイツ民謡)などに変えられてはいかがでしょうか。この中では『グリーンスリーブス』が最もポピュラーではないかと思います。よろしくお願いいたします。--エヴァンズの秘書会話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|藤}}一郞]]のような感じで。編集の例として[32][33]など)。繁体字用である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)[返信]
コメント基本的には、どのような書き方をするにも強制力のある根拠はないと考えます。背景を知る上で[34]というのを見つけました。
まず、ウィキペディア日本語版では、「強制」は現在もされておらず、「統一」が図られている、と理解しています。少なくとも書き手がピリオドやカンマを使うのは自由だけど、統一したい人が、表記ガイドに従って統一している。統一のためのコストを下げるために句読点にしてくれる方が助かるし、揃えてくれないかとお願いするのはいいけれども、書き手の側に「強制」するのはやりすぎだと思ってます。
ウィキペディアの表記ガイドの類では、「、。」を用いるとされ、その後幾度か議論にはなったけれども覆すには至らない程度に同意があった、あるいはカンマやピリオドへの移行や併記への移行を認めるだけの合意は得られなかった、というのが「根拠」でしょう。「、。」以外を用いるとか、複数の表記法を共存させるという選択肢もあるけれども、それではなく、コミュニティは「、。」による統一を支持している。なので、根拠がどうとか、強制が妥当か、とかいう問いの立て方をされるとしたら、合意が根拠であり、強制はされておらず、統一は妥当だと思います。
手続き論的なところとか、「、。」側の妥当性を問うとかではなくて、あらためて(表記ガイドの過去ログを引き継ぐ形で)合意を取り直そう、合意を探るとしたらどのようなものが好ましいか考える、ということなら、検討の余地はあると思います。難点としては、その項目にきちんと貢献している人同士で使いたいスタイルが食い違った時に解決が難しくなることが挙げられるでしょうか。執筆者意欲に関しては、書くところは書く側の問題として自由、しかしその後の統一については、個人の「執筆」から離れた話、ウィキペディア全体の話として、区別しないと、と思います。
個人的には、百科事典の記述は数式を用いた論証ではなく、歴史や概念を言語により説明するものとして、「カンマ・ピリオド」よりも「カンマ+句点」または「句読点」による統一が好ましく、縦書きへの変換の容易さから句読点を支持しますが、他の書き方でも強く反対はしません。--Ks aka 98会話2016年6月10日 (金) 07:48 (UTC)[返信]
コメント みなさま,コメントありがとうございます.私のはじめのコメントの「強制」は「統一」と書いた方がよかったかもしれませんがまあそれはいいとして,思ったほど否定的な意見が出ていなくて驚きました.私ももちろん無意味な表記の書き換えだけの編集はよく思っていなくて,表記ガイドの役割の一つはそれを防止することだと思っていますが,確かに「その項目にきちんと貢献している人同士で使いたいスタイルが食い違った時」は難しいですね.
ただ一点気になったのは,Ks aka 98さんの最後の一文で,数式は論証のためだけに用いるものでは全くなく,「歴史や概念を言語により説明する」ときに必然的に使われます.新規作成 (利用者名) 会話) 2016年6月16日 (木) 07:53 (UTC) 微修正.新規作成 (利用者名) 会話2016年6月16日 (木) 07:57 (UTC)[返信]

組立単位に用いる中黒について

組立単位などにおける乗算記号の中黒について、多くの記事ではUnicodeで定義されている&sdot;(⋅)でなく&middot;(·)が用いられていますが、これはなぜでしょうか。妥当な理由がなく、また反対意見がなければ、Wikipedia:表記ガイド#単位に「⋅」を用いるように書き加えたいと思います。コメントよろしくお願いします。--Waiesu会話2016年6月29日 (水) 14:14 (UTC)[返信]

昔は &sdot; が表示されない環境があったのでそれが理由の1つである可能性は考えられますが,おそらく実際のところは多くの編集者は &sdot; と &middot; の違いなんて気にしていないでしょう.これまでの経緯を踏まえるといちいち表記ガイドに書くことではなく気付いた人が直していけばいいのではないでしょうか.(別に反対というわけではないです.)新規作成 (利用者名) 会話2016年7月3日 (日) 07:55 (UTC)[返信]
コメントありがとうございます。とりあえず &sdot; と &middot; のどちらに統一するかなど決まっているわけではないのですね。現在の環境では &sdot; が表示されないことはほとんどないようですので、個人的にはそれを使っていきたいと思っています。あと3日ほど待って他の方から意見がなければ現状維持で議論を閉じたいと思います。--Waiesu会話2016年7月3日 (日) 08:35 (UTC)[返信]

著作物名の約物についての補足

今年の5月に改訂が済んだWikipedia‐ノート:表記ガイド#著作物名についてからの補足になりますが、あえて約物を付す必要性のないケース(リストの羅列やテンプレートInfobox内の表題)にわざわざ鉤括弧を付けていらっしゃる方がいるようなので、無用なトラブルを避けるために、そのことに関して一筆補足を加えておきたいと思います。

例えば、Template:Infobox FilmTemplate:基礎情報 書籍内で映画や小説のタイトル名を入れる場合、他の語句との区分の必要性は発生していないわけで、こういったケースには通常は約物類は付けないのが、表記の使用法、ひいては書誌表記の通例となっています。これは世に溢れている映画パンフや本の見出しや目次、[35][36]をご覧になればお判りになると思いますが、作品名に余計な記号(鉤括弧)を付けないことが妥当な記載法となっております。本来、約物とは必要にかられて始めて使用する類の記号ですから、いらない所では付けないのが日本語表記の常識的な使い方であり、多くの現場で実際に行われている慣習です。

これは理由なくそうなっているわけではなく、「純粋な作品名」を記載しなければ、誤解や間違いの元になるためです。こういった、文章内ではなく単語同士の区別の記号のいらない場所において『』を付してしまうと、その『』込みの作品名だと混同されるため(稀ですが、そういうものもあります)、「純粋な作品名」以外の記号は付けないことになっているわけです。

このような一般的な常識中の常識のことまで、表記ガイドにいちいち書き加えて反映しなければならないWikipediaの現状には本当に疲れてしまうことですが、このサイトの事典上では様々な方が誰でも参加していらっしゃいますので、一応基本の約物というものの使用の妥当性を明記しておき、約物が強制荒らしの道具に使われないよう、このガイドラインの冒頭あるいは最後に以下のような一筆を加えたいと思います。

*作品リストや、Template:Infobox FilmTemplate:基礎情報 書籍などのテンプレート内のタイトル名のように、他の語句との区別が生じていないケースでは、特に括弧類を付す必要はありません。

これでも、どうしても付けたい方はいるとは思いますが、一応は約物の基本ですので、ここでも多くの方が実際に採用している慣習をガイドラインに反映させておきたいと思います。何かご意見があれば承ります。

なお、楽曲名に関しても、Template:Infobox SingleTemplate:Infobox Albumは別個のテンプレートに明確に分けられて「○○のシングル」「○○のアルバム」という説明も直下にあるので、余計な記号をタイトル名に付す必要はないと思いますが、ローカルルールでそう決まっているようですので、今回この楽曲のケースにはタッチするつもりはありません。