Wikipedia‐ノート:表記ガイド

日本語表記法
- 統合前の議論 - 年月日、Wikipedia名前空間における文体、漢字表記の統一
日本語環境
- 2005年1月30日までの議論 - 人名表記のゆれ、ケとヶ、送り仮名、「：」と「:」の使い分け、範囲を表す文字について、段落行頭の字下げについて、「・」（中黒・中黒点・中点）は、全角か半角か？
- 統合前の議論 - 括弧の使い分け、ハイフンのかわりのイコール（＝）、「2バイト文字」の表現、リーダ、句読点、漢字とひらがなの使い分け、〜について、全角空白、漢字の選択、半角英数は絶対？、カタカナでの中点、過去の議論へのリンク希望
表記ガイド
- この文書が利用者:Michey.M/書き方（初版）、利用者:Miya/書き方（時期不明）、利用者:Koba-chan/Paropedia/書き方（2005-06-02から2006-09-26）にあったころの議論 - 中黒、疑問符・感嘆符、括弧類、俗語・俗称・隠語、未分類、外来語について
- 日本語環境・日本語表記法との統合前の議論 - 「祗」、全角と半角の使い分け、人名漢字、2点リーダー、仮名書きと漢字、不等号を括弧に用いること、物故者、文字コードの記述、人名がスタイルマニュアルと重複、団体の種別と内部リンクを含む団体名、統合の提案について

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

このページの節に {{Section resolved|1=~~~~}} を置くと、7 日後に SpBot がその節を過去ログ化します。

「ruby」以外の仕様と使い方について[編集]

日本の神の一覧においてルビ使用のためののテンプレートTemplate:日本の神の一覧/ruby「{{{1}}}（{{{2}}}）」で、表の中などではなく、通常の文中で使用されていてるのですが、この「span」を使ってのルビの振り方と文中使用はWP:JPE#読み仮名の要否では許容されているのでしょうか。補足しますと、テンプレートの初版は、「<ruby>{{{1}}}<rp>（</rp><rt>{{{2}}}</rt><rp>）</rp></ruby>」の仕様でした。<ruby>の替わりのの仕様はガイドライン的には問題ないのでしょうか。--Sonchou（会話） 2017年5月3日 (水) 10:39 (UTC)

少なくともWikipedia自体が提供するCSSにはruby、rt、rpといったクラスは存在しませんから、ユーザーCSSでこれらのクラスを定義していない限りは単なる括弧書き以上の意味はありませんね。テンプレート作成者さんの意図がわかりません。ルビを振りたいのであれば素直にruby要素を使えばいいだけだと思うのですが。現行版の日本の神の一覧では{{読み仮名}}（これも音声読み上げ環境を考慮したもので、ルビを振るものではないです）を使っているようです。--Claw of Slime (talk) 2017年5月3日 (水) 10:58 (UTC)

追記。そもそも本文中にルビを振っていいかは基本的にはWP:JPE#読み仮名の要否に従い「否」でしょう。--Claw of Slime (talk) 2017年5月3日 (水) 11:06 (UTC)

Claw of Slimeさん、コメントありがとうございます。日本の神の一覧において{{読み仮名}}に変更されているのは先ほど気がつきました。私は「CSS」や「タグの仕様」の中身についてはよくわからないので拙い説明ですみません。とりあえずWP:JPE#読み仮名の要否での説明どおりで問題ないということで理解します。--Sonchou（会話） 2017年5月3日 (水) 12:05 (UTC)

益体ないコメントをします。ルビについては私も「使いたいなあ」という場面はときどきありました。「試す（トライ、try）」と「３つの（トライ、tri）」が綴が別で音が同じであることが利用されている韻文を説明するときとか。が、Claw of Slimeさんご指摘のように、基本的にはウィキペディアでは本文中でのルビの使用はだめということになっています。実際、ルール違反を承知で使っても、行間が乱れたり、改行位置や文字間隔が乱れたりしまして見栄えは悪いです。

一方、2008年の草案時点では廃止の方向だったルビ要素が、2014年秋のHTML5の勧告で復活する形で採用されたそうで、それ以前に比べると世の中全般としてはルビタグの是認に傾いているようではあります。このHTML5におけるルビ要素の位置づけは、いわゆる「読み」を指示するほかに、「語句に対する目に見える注釈」としての用法も想定されています。
いまの「ルビタグ禁止」は2006年頃からある決め事でして、この版を見ればわかる通り、当時は「XHTML1.0で採用されていないからダメ」が理由としてあげられていました。そのXHTML1.0の後裔であるHTML5で「OK」になって、多くの主要なブラウザも対応しているそうなので、当時から10年以上たった今の時点で、ルビを可とする方向で表記ガイドの改訂を諮る、というのはあり得ることだとは思います。
ただし、レイアウトが崩れることについては今も変わらないようにも思いますし、読み仮名の要不要をめぐって衝突も起きそうですし、現実的にはじゅうぶんな賛同を集めるのは難しいかもしれませんね。
代用品としての{{読み仮名}}は、ruby要素を音声読み上げ環境のために利用しています。たとえば「宇宙」と書いて「そら」と読ませるだとかの修辞技法としてのルビの利用が「読み」なのか「語句に対する目に見える注釈」なのかはちょっと私には判断がつきかねるのですが（たぶん両方の性格を併せ持っている）、いずれにせよこれは単なる難読漢字のフリガナとは異なる意図・効果をもっています。（つまり、「蝸牛」を音でだけ「カタツムリ」と耳で聞いても情報量はほとんど損なわれないけども、「宇宙」を「ソラ」という音でだけ聞いた場合には、「空（そら）」ではなく「宇宙」と書くことによって生じる効果はほとんど伝わらない。）
例示された日本の神様の読み方の場合には、これと似た部分があって、単なる「難しい漢字の読み方」というだけでなく、その音自体に神様の性格が顕れている的なところもあるでしょうね。そう思って日本の神の一覧を眺めると、その記述スタイルが「通常の文中」といえるのかどうか、私はむしろ「罫線が引いていないだけで、実質的にほぼ表みたいなもの」じゃないかなあと思います（なので、ルール違反じゃないと強弁できないこともない。苦しいですが。）。だったらいっそ、{{読み仮名}}を使うよりも、表にしちゃえばいいのにと思う次第です。たとえば1列目は漢字表記、2列目はひらがな表記、3列目は備考、みたいにしたほうがベターじゃないかな、と思います。ひどく手間ですし、メンテナンス性は低下しますけどね。--柒月例祭（会話） 2017年5月3日 (水) 13:42 (UTC)
（追記）sortableな表にすると、漢字の字面と、ふりがなの字面で並び替えができてちょっと便利だなとも思います。手間ですけどね。--柒月例祭（会話） 2017年5月3日 (水) 13:45 (UTC)

情報現行の読み仮名表記に関する表記ガイド改訂の提案者です。

ruby要素およびTemplate:読み仮名に関する表記ガイドの趣旨について、概要はClaw of Slimeさんと柒月例祭さんが説明くださった通りです。HTMLの仕様に詳しい方の中には「ruby要素が正式採用されたのだから記事内で自由に使えば良いじゃないか」と思われる方もいらっしゃると思いますが、ruby要素を使うと対応した音声ブラウザでは漢字部分が読み飛ばされることになり（そのための要素タグなので当然ですが）、実はこれが諸刃の剣でもあります。たとえば

<ruby><rb>水島宇宙</rb><rp>（</rp><rt>みずしまそら</rt><rp>）</rp></ruby>は日本の声優である。水島宇宙の代表作は……

というテキストをルビ要素対応の音声リーダーで再生した場合、

「みずしまそら はにほんのせいゆうである。みずしまうちゅう のだいひょうさくは……」

と読まれてしまい、1文目の "水島宇宙" と2文目の "水島宇宙が" 別人物のように出力されてしまうという問題があります。これを回避するためには主に2つの方法が考えられます。1つは文章中に出てくるその単語すべてにルビを振る方法です。つまり

<ruby><rb>水島宇宙</rb><rp>（</rp><rt>みずしまそら</rt><rp>）</rp></ruby>は日本の声優である。 <ruby><rb>水島宇宙</rb><rp>（</rp><rt>みずしまそら</rt><rp>）</rp></ruby>の代表作は……

と書けばこの問題は一応は回避可能です。ただしそれだと

水島宇宙（みずしまそら）は日本の声優である。水島宇宙（みずしまそら）の代表作は……

のように同じ単語のルビが繰り返し頻出してしまい、文章によっては実用的ではありません。そこで、視覚的な見た目ではルビのテキストを表示せずに読み仮名（rt要素）の指定だけを行えるテンプレート{{読み}}を併用し、

<ruby><rb>水島宇宙</rb><rp>（</rp><rt>みずしまそら</rt><rp>）</rp></ruby>は日本の声優である。 {{読み|水島宇宙|みずしまそら}}の代表作は……

水島宇宙（みずしまそら）は日本の声優である。水島宇宙（みずしまそら）の代表作は……（通常のテキスト表示では違いが分かりにくいと思いますが、単語にマウスカーソル等を併せていただくと読み仮名の出力内容が一応目視確認できます）

と記述する必要が出てくるわけですが、この方法で一応は視覚的な問題は回避できるとはいえ、一度ルビを振った単語全てに読み仮名を入力する必要があり、これをウィキペディア全体の標準書式とするには編集作業の手間が過大すぎると考えられます。とくにHTMLやウィキマークアップに慣れていない編集初心者はソーステキストを見ただけで尻込みしてしまうと思います。

そこで、もうひとつの解決方法として考えられるのが

水島宇宙（みずしまそら）は日本の声優である。水島宇宙の代表作は……

のように、rubyなどの特別なマークアップを一切使わずに通常のテキストのみで書くという方法です。これを音声ブラウザで再生すれば

「みずしまうちゅう・みずしまそら はにほんのせいゆうである。みずしまうちゅう のだいひょうさくは……」

と、漢字部分の読み間違いは発生するものの、漢字部分が読み飛ばされずに同じ難読単語が同一の読みで再生されるため、音声リーダーをある程度使い慣れた方であれば、１文目と２文目の "水島宇宙" が同一人物でその読みが "みずしまそら" であることを読み取ってもらえることが期待できます。これだと間違った漢字の読みもそのまま出力されるのでベストなソリューションではないかもしれませんが、親切のつもりで漢字を読み飛ばすよう細工したことが逆に致命的な誤読の原因になってしまうのを防ぐことができ、なおかつ編集上の手間や知識も必要ないので、現時点の技術的選択肢の中では、実は最も堅実で合理的な方法と考えられます。

ひとつの考え方として、その両者の方法をうまく使い分けながら併用するという方向性もあると思います。しかしruby要素標準の表示スタイルをそのまま使用しようとすると、単語上にルビ表示されている箇所と従来の括弧書きされている箇所が文章中に混在してしまうので表記スタイルの標準仕様としては現実的ではありません。そこで対応する音声ブラウザに対してはHTMLのruby要素を出力しつつ見た目には従来の括弧書きの読み仮名表記と変わらない出力を行うテンプレート{{読み仮名}}を作成しました。これであればひとつの記事中でruby要素（テンプレート読み仮名）を使用する箇所と通常の括弧書きしているだけの箇所が混在しても視覚表示では見た目がほとんど同じなので書式統一上の不具合が生じません。たとえば

桑島法子（くわしま ほうこ）は日本の声優である。桑島法子は2014年に{{読み仮名|宇迦之御魂神|うかのみたまのかみ}}役を演じ……

と編集ソースを記述すれば

桑島法子（くわしまほうこ）は日本の声優である。桑島法子は2014年に宇迦之御魂神（うかのみたまのかみ）役を演じ……

と出力され、ルビ要素を部分的に使用しても書式上の不整合が生じないので、編集実務的に無理のない範囲で要所だけ部分的にruby要素を使用できる、というのが現状の表記ガイドに書かれた読み仮名に関する書式内容の意図です。

それを踏まえた上で、記事「日本の神の一覧」のリストについて考えると、通常の文章中の頻出単語に読み仮名を振る用途ではないので、ruby要素（テンプレート読み仮名）を使用すること自体には実用上の支障は無いと思います。実際の表示スタイルとしては、直接rubyタグを使って

<ruby><rb>青沼馬沼押比売神</rb><rp>（</rp><rt>あおぬまぬおしひめ</rt><rp>）</rp></ruby>

青沼馬沼押比売神（あおぬまぬおしひめ）

のように単語上に文字通りルビとして表示するか、それとも

{{読み仮名|青沼馬沼押比売神|あおぬまぬおしひめ}}

青沼馬沼押比売神（あおぬまぬおしひめ）

と視覚的な表示は通常の括弧書きで出力するかという2つの選択肢がありますが、このリストの場合はページの横幅が有り余っているので、レイアウト的に後者の方が適していると思います。その両者の違いは表示の見た目だけなので、それらの使い分けはそのようにもっぱら視覚的なレイアウト上の都合だけで選んでいただいて問題ありません。

ただもう1点、地味な注意点がありまして、それはruby要素内のテキスト（漢字、読み仮名両方）にマークアップを使用するのはおそらくは避けた方が良い（より正確に言えば、半角の "<" と ">" を含むテキストもしくはそれらの出力テキストを生成するウィキマークアップの使用は避けた方が良い）、ということです。これは私もうろ覚えできちんと確認できていないのでテンプレートの説明にも書いていない事柄なのですが、音声リーダーの仕様によってはruby要素内にrb, rt, rp以外の要素タグが挿入されるとruby要素が機能しないという機能説明をどこかで目にしたように記憶しています。今もそのソースを見つけられないので具体的な音声リーダーの製品名やバージョンも明示できませんが、たとえば記事間リンクを挿入する場合に

{{読み仮名|[[単語]]|よみがな}}]や <ruby><rb>[[単語]]</rb><rp>（</rp><rt>よみがな</rt><rp>）</rp></ruby>

としてしまうと、音声リーダーの仕様によってはruby要素が無効化されてしまい漢字の「単語」部分が読み飛ばされない可能性があるということです。

つまりこれを確実に避けるためには、少し面倒ですがあえてパイプ構文を使って

[[単語|{{読み仮名|単語|よみがな}}]] や [[単語|<ruby><rb>単語</rb><rp>（</rp><rt>よみがな</rt><rp>）</rp></ruby>]]

として頂いたほうが無難ということです。もともとruby要素を使ったからといってすべての音声出力環境が対応しているわけではありませんし、それが無効になったとしても普通に括弧書きで記述しているのと同じ出力になるだけなので大怪我をするような事柄ではありませんが、ついでに豆知識程度の話として。

そのあたりは、表記ガイド本文と当該改訂の提案説明では要点のみしか述べていないのでわかりづらい点もあったかもしれません。以上、長くなりましたが、ご参考までに改めて詳述するとそんな感じです。--ディー・エム（会話） 2017年5月4日 (木) 04:13 (UTC) （誤字修正しました--ディー・エム（会話） 2017年5月5日 (金) 01:42 (UTC)）

「マジックリンク」の使用を非推奨とする提案[編集]

ウィキペディア日本語版では「マジックリンク」という機能がありますが、マジックリンクの使用を非推奨として対応するテンプレートの使用を推奨することを提案します。

現状以下のものが実装されています。

マジックリンク一覧
対象	書式	対応するテンプレート	マジックリンク追跡カテゴリ
ISBN	ISBN 数値	{{ISBN2}}	Category:ISBNマジックリンクを使用しているページ
IETF RFC	RFC 数値	{{IETF RFC}}	Category:RFCマジックリンクを使用しているページ
PMID	PMID 数値	{{PMID}}	Category:PMIDマジックリンクを使用しているページ

これらについて、マジックリンクではなく対応するテンプレートの使用を推奨するように提案します。提案理由は次の2つです。

テンプレートを使用した場合のレンダリング結果にはISBN、RFC、PMIDが何なのかを指し示すリンクも挿入されるので、それらを知らない読者に有益である。
テンプレートの方が柔軟な対応が可能。例えばISBNにはチェックディジットを用いた検算が可能であるが、テンプレートを使えばその機能も実装できる。
- {{ISBN2}}で実装済みであり、値に間違いがあると判定された場合は「Category:ISBNのエラーがあるページ」に格納される。

発端としては「ウィキメディア財団系ウィキでマジックリンクが使えなくなる見込みがあった」という話がありますが、本提案はそれを受けたものではありません。そもそも使えなくなることは決定していませんし。ただし、それに関する議論については参考になるかもしれないので紹介しておきます。

Wikipedia:井戸端/subj/マジックリンクについて

以上。--iwaim（会話） 2017年7月1日 (土) 08:52 (UTC)

提案自体に反対はないですが、表記（見た目）の話ではないので、この文書にわざわざ新規記載することではないように思いました。Help:マジックリンクの方に記載するということでは不味いのですか？--Yapparina（会話） 2017年7月1日 (土) 09:22 (UTC)
- Help名前空間のものに強制力はありません。そして、この種のものにまったく強制力がない場合は往々にして編集合戦を引き起こします。「Wikipedia:表記ガイド」が見た目に限定されているとは私は判断しておりませんが、方針系文書としてより適切なものがあれば教えてください。そちらにもアナウンスは必要かもしれませんし、議論場所を変更する必要もあるかもしれません。--iwaim（会話） 2017年7月1日 (土) 09:34 (UTC)
  - 内部リンクに関する内容という点では、Wikipedia:記事どうしをつなぐはどうでしょうか？ --Wdpp（会話） 2017年7月1日 (土) 15:40 (UTC)
    - 提案ありがとうございます。しかしながらマジックリンクは、ISBNは内部といっても特別名前空間、あとの2つは外部へのリンクなのでちょっと違うようにも。テンプレートについても主目的はマジックリンクと同じ箇所へのリンクの生成ですし。--iwaim（会話） 2017年7月1日 (土) 15:52 (UTC)
      - たしかにそのとおり内部リンクではありませんでしたね。失礼いたしました。--Wdpp（会話） 2017年7月1日 (土) 16:03 (UTC)
  - （Iwai.masaharuさん宛て）ガイドラインとしてのある程度の強制力があった方がいいということ了解しました。表記（見た目）の話ではない云々というのは杓子定規過ぎる指摘だったかもしれませんね。--Yapparina（会話） 2017年7月5日 (水) 01:02 (UTC)

コメント 提案が採用となった場合、善意で「ISBN 4-**」とか「RFC ****」と書く人もいるでしょうし、自動修正用のBotがあればいいなと思いました。--Jkr 22 55 2017年7月1日 (土) 09:28 (UTC)
コメント 提案は賛成です。ですが、「非推奨とする」だけの提案だったら表記ガイドは関係ないと思います。表記方法としてガイドに実装するという提案であれば受け入れられますが。

Jkr2255さんも仰ったように、自動修正するbotは必要かと思いますが、かなり簡単に作れると思いますので深く考える必要はないかと。--Yuukin0248[会話/履歴] 2017年7月1日 (土) 09:35 (UTC)

- 《表記方法としてガイドに実装する》は『「Wikipedia:表記ガイド」を改訂する』という意味でしょうか？そうだとすれば、当然それを視野に入れた提案です。--iwaim（会話） 2017年7月1日 (土) 09:39 (UTC)
  - なるほど、それでしたら問題ないです。具体的にはどの項目への追加をお考えでしょうか。--Yuukin0248[会話/履歴] 2017年7月1日 (土) 10:01 (UTC)
    - 現時点で議論するような話題でもないでしょう。（もちろん文面案なども）--iwaim（会話） 2017年7月1日 (土) 10:09 (UTC)

コメント マジックリンクを非推奨とする場合は、当然ですが記事以外の方針文書等で使われてるマジックリンクを置換しておく必要があります。ところが、これはそう簡単な話ではなく、Wikipedia名前空間のものでも例えばWikipedia:FAQのものは置換する必要がありますが、Wikipedia:削除依頼/出典不明の妖怪記事のように既に完了していて編集しないでください。と書かれているものはそのまま保存しておくべきでしょう。（こういった文書も一律置換してしまうのであれば簡単な話になるでしょうが）ノートページ中のマジックリンクもどうするのか悩ましいところです。方向性には賛成しますが、結構問題点がありそうです。--アルビレオ（会話） 2017年7月2日 (日) 00:07 (UTC)
- コメント 「マジックリンクは使うことを禁じないが非推奨であり、第三者にテンプレートで置き換えられるかもしれない」「テンプレートが使われている箇所は原則としてマジックリンクに書き換えてはいけない」ぐらいが落としどころだと考えています。機能が無効にならない限り廃止は無理でしょうし、「マジックリンクが非推奨になってもマジックリンクを使い続ける人」がいたところで咎めることは避けたいです。少なくとも短期的には。
  方針系文書は対応しておいた方が望ましいですが、必須作業かといわれればそうでもないと判断しています。漏れていたものは都度対応で大きな問題は発生しないはずです。
  アーカイブやノート系については今回の提案ではそのままで良いとは考えていました。こちらについてもマジックリンクを残しておくことで特に問題は発生しないと考えています。--iwaim（会話） 2017年7月2日 (日) 04:47 (UTC)
- コメント わざわざ非推奨とするメリットとしては（iwaimさんは論点化を避けられたのだろうと思いますが）マジックリンクはMediaWikiにおけるレガシー的な部分があり、将来的には廃止へと向かう可能性があるので、先に対応しておけば廃止されることになった場合にあわてなくて済むし、影響も小さくできる、という点があると思います。その観点からはアーカイブ中のマジックリンクも置換してしまってもかまわないかと思うのですが、いかがでしょうか（あくまでも技術的な変更ですし）。現時点でぜひ変更すべきだ、とは思いませんが。 --KAWASAKI Hiroyuki（会話） 2017年7月2日 (日) 13:48 (UTC)
コメント もしテンプレートの使用を積極的に推奨するのであれば、{{ISBN2}}というテンプレート名は分かりにくく、不親切だと思います。現状、{{ISBN}}は{{ISBNT}}へのリダイレクトになっており、一定数使用されているようですが、このリダイレクトを解消し、{{ISBN2}}を{{ISBN}}へ改名することを検討したほうがいいのではないでしょうか。思いつく弊害としては、[[ISBN]] {{ISBN}}と習慣的に手書きしている場合などに「ISBN」が重複してしまうことですが、かなり考えにくいケースかと思います。なお、英語版で{{ISBN2}}に対応しているのはen:Template:ISBNです。 --KAWASAKI Hiroyuki（会話） 2017年7月2日 (日) 13:48 (UTC)
- コメント 過去の版を閲覧する際に影響がでるのでそこをどう考えるのかという話になりますね。本件とは別の話として考えた方がいいと思ってます。--iwaim（会話） 2017年7月3日 (月) 16:18 (UTC)
議論が止まりましたね。方向性としては、「マジックリンクは非推奨」「現状の全てのマジックリンクを置き換える必要はなく、ノートやアーカイブはその都度対応」でしょうか。このほかに、「マジックリンクを使い続ける人がいてもとくに問題視しない」「{{ISBN2}}は分かりづらい」という意見もあります。
今後はどこまで変更するかを中心に具体的な点を決めていきましょう。--Yuukin0248[会話/履歴] 2017年8月2日 (水) 09:08 (UTC)

大きな反対はなさそうなので、改定案を出し、検討をすすめる予定です。--iwaim（会話） 2017年9月9日 (土) 18:21 (UTC)

文面案を出しました。時間がかなりあいたことも鑑みて、「Wikipedia:お知らせ」版番68147436にてアナウンスしました。--iwaim（会話） 2018年4月10日 (火) 09:36 (UTC)

文面検討[編集]

以下のような文面を「その他」セクションの直前に「マジックリンク」セクションを設けて記載することを提案します。

マジックリンクの使用は非推奨です。対応するテンプレートを使用してください。

マジックリンクとテンプレートの対応表
対象	マジックリンクの書式	対応するテンプレート
ISBN	ISBN 数値	{{ISBN2}}
IETF RFC	RFC 数値	{{IETF RFC}}
PMID	PMID 数値	{{PMID}}

マジックリンクの使用は非推奨ですが、使用を禁じてはいません。
マジックリンクはテンプレートに置き換えられる可能性があります。
テンプレートからマジックリンクへの置き換えは原則として禁止しています。

また、改定後は「Help:マジックリンク」と「Help:ISBNのリンク」の冒頭に非推奨となった旨を記載します。--iwaim（会話） 2018年4月10日 (火) 09:29 (UTC)

Help:マジックリンクをながめて、なんとなく事情はおぼろげながらわかりました。使っている私の個人的な感覚としては「今までより面倒くさくなって、メリットが享受できず不便になるだけ」と感じますが、しかたない。でもまあ、「再度検討をする」といっている時点で「非推奨」まで言うのは勇み足じゃないですか？「廃止になるかもしれない・こちらを推奨する」ぐらいまでにしておく時期なんじゃないかなと。あと私としては、ただ「非推奨だ」と言い放つだけでなくて、趣旨や経緯を盛り込んだほうが受け容れやすいように感じるんですよね、「なるほど、それなら不便に思うけどしかたがないか」って。--柒月例祭（会話） 2018年4月10日 (火) 13:49 (UTC)

テンプレートを使用した場合のレンダリング結果にはISBN、RFC、PMIDが何なのかを指し示すリンクも挿入されるので、それらを知らない読者に有益である。テンプレートの方が柔軟な対応が可能。例えばISBNにはチェックディジットを用いた検算が可能であるが、テンプレートを使えばその機能も実装できる。

返信 (㭍月例祭さん宛) 《でもまあ、「再度検討をする」といっている時点で「非推奨」まで言うのは勇み足じゃないですか？》については、（少なくとも私は）廃止が検討されていたことは考慮にいれていません。むしろ廃止になるかも知れないというだけであればウィキペディア日本語版では特に対応しなくても良いと考えています。（廃止になる可能性が高そうであれば廃止になったときにどのように対応するのかを議論しておいた方がよいでしょうが、廃止が決定されるまではWikipedia名前空間などの変更は不要であるという意味です）
また、非推奨にするのはウィキペディア日本語版での話であって、上流（MediaWiki本体やウィキメディア財団）とは無関係な話であると判断しています。メリットについては版番64630674にも書きましたが「ISBN」や「IETF RFC」、「PMID」という文字列自体に内部リンクが設定できるという点があります。一例ですが、私は「PMID」が何であるのかは知りませんでした。
《「廃止になるかもしれない・こちらを推奨する」ぐらいまでにしておく時期なんじゃないかなと》ということですが、例えば文面案をどのように変更すればよいでしょうか？
《趣旨や経緯を盛り込》むのは「表記ガイド」の性質にあまりそぐわないような気はしています。--iwaim（会話） 2018年4月10日 (火) 14:17 (UTC)

ふーむ。ガイドライン文書のありかたについては、私とは考え方が違うということはわかりました。Aという目的を実現するための手段としてBやCやDがある、というときに、BはAを実現するための手段なんだぜ、って説明をしないまま「Bしろ」と命じたときに、意味も分からずBしまくって結果的にCやDやAを阻害する、みたいなのがイヤなので（そういう事例を数多くみているので）、きちんと目的や経緯も説明したほうがいいと思っています。そうすることで、基本はBだけど今はCのほうがいいね、なんて判断ができるようになる。そうでないとWP:BURO。WP:CREEPも参照。

私はテンプレート化によって得られる効果を「メリット」とは感じません。単なる「機能」です。「ISBNが何なのかわからない人のためにリンクを」とのことですが、じゃあ「著者」がわからない人のためにリンクをはるのかって話です。そもそもISBNを何のため書くかというと、ふつうは検証可能性のためのルートを増やしたり容易にしたりするためであって、ISBNがそもそも何なのかわからない人のためにISBNを解説するためじゃない。ISBNを知らない人にISBNの数字を示してもあまり意味がないし、わからなければ調べればいいでしょう？マウスなら2クリックぐらいで「選択して、Googleで検索」できちゃいます。私はテンプレートにデメリットを感じまして、マジックリンクならば、ISBNを書き込むときに目線は本の裏表紙を見ながら右手だけで数字を打ち込めちゃいますが（2秒ぐらいかな）、テンプレ必須になるとそれができなくなっていくらか面倒。だから、この際ISBN書くのやめちゃおうかなー、となると、結局、検証可能性のためのルートが減ることになります。別にISBN必須というわけでもないし、それがなければ文献を特定できないわけでもないし、独自の書式で書いたって便利なリンクが使えないだけでISBN情報としては無効なわけじゃないし。

まあ便利と思うかメリットと思うかなんて各利用者の主観なので、テンプレートのほうが便利と思う方の選択肢を増やすことはいいと思いますよ。テンプレートを「推奨」するのもいいでしょう。でも、有効に機能していて、10年以上使われてきて、廃止されるわけでもない、問題もないものを「非推奨」にする理由がないですよね。--柒月例祭（会話） 2018年4月11日 (水) 00:17 (UTC)

一案、ですけども、文書の趣旨や性格からして表記ガイドよりはWikipedia:出典を明記する（WP:CITEHOWあたり）が適していると思うんですが、そこに

書誌情報の一つとしてISBN（等）を書くとよい。
ISBNの記入の仕方として、マジックリンク方式と、テンプレート方式がある。
それぞれの方式の特徴。
2017年にマジックリンク方式の廃止が検討されていること。テンプレート方式を推奨すること。

このぐらいを書いて、あとは委ねるって程度じゃないかなあ。--柒月例祭（会話） 2018年4月11日 (水) 00:40 (UTC)

返信 (柒月例祭さん宛) IETF RFCは出典で使われる頻度は割と少ない気がしますし、ISBNも出典以外で使われることが多いので「Wikipedia:出典を明記する」にはそぐわないと考えます。

《（略）テンプレ必須になるとそれができなくなっていくらか面倒。（略）》については、まず「テンプレートの使用が必須」ではありません。あの文面案から必須であると受け取られるとすれば改善が必要ですね。《テンプレートを「推奨」するのもいいでしょう。でも、有効に機能していて、10年以上使われてきて、廃止されるわけでもない、問題もないものを「非推奨」にする理由がないですよね》については、『マジックリンクを非推奨』ではなくて『テンプレートを推奨』という文面だと柒月例祭さんとしては許容範囲という理解であってますか？ちなみに、私が「非推奨」側の記載にした理由は、そっちの方が表記ガイドを根拠とした編集合戦がより起こりづらいと判断したからです。（「テンプレートを推奨」という文面にすることは私としては問題ありません）

また、面倒さの話については、本案で改定となった場合は{{Cite book}}内部でテンプレートが用いられるように改変される（と期待できる）ため、手間は変わらないと判断しています。もちろん{{Cite book}}使わずに「出典となった書籍」の情報を記載することは許容されているのは理解していますが、Cite系テンプレートを使わずにISBNを記載する人ってどれぐらいいるものなんですかね。個人的にはCite系を使わずにISBNなどまでちゃんと記載するのは面倒そうな印象があるので、それほどいないんじゃないかなー、と想像していますが。（既存記事を見ての調査とかしていません。すみません）

《（略）説明をしないまま「Bしろ」と命じたときに（略）》は理解できますが、先にも書いたように今の「表記ガイド」はそこまで記載していない（方が多い？）ので……。例えば「Wikipedia:表記ガイド#句読点」で何故「，」「．」が（非推奨でもなく）禁じられているのかは記載されていません。尤も、その事実を踏まえた上で「本件は記載した方がいいよね」と意見が多いのであれば、記載することに反対する気はありません。

《まあ便利と思うかメリットと思うかなんて各利用者の主観なので、テンプレートのほうが便利と思う方の選択肢を増やすことはいいと思いますよ。》については、主観だということは同意します。ただ、こういうのは往々にして争いを起こすのですよね。現状のままの状態で、テンプレートの方が便利と思う人がISBNのマジックリンクを{{ISBN}}に置き換える作業を実施したら、きっと議論や編集合戦が起こる。たとえば、「出典」の表記方法で「この記事内では混在しているからハーバード方式に統一しよう」とやっちゃうと、議論になることもあるはず。実際にそのような編集をする方はいるのです（差分）よね。この時は議論になっていませんが。--iwaim（会話） 2018年4月11日 (水) 11:31 (UTC)

「既存記事を見ての調査とかして」おらず、廃止の件も関係ないならば、もはや変える必要もないでしょう。具体的に問題があって、その解決策としてある方法があり、その手段によって引き起こされる別の問題と、当初の問題を天秤にかけたときに当初の問題の解決のほうが優先される、というならば、変えるのはわかります。が、必要性もない、メリットもない、デメリットの検討もしていないのでは、ちょっと賛成する余地がなくなります。テンプレートを使いたい人がいれば使えばいいし、そうでなければ使う必要はない、ただそれだけのことでは？

私の方からは、出典としての文献情報を明記して検証可能性に貢献するという文脈以外で、いったいどういうときにISBNを書くのだろう？と思います。--柒月例祭（会話） 2018年4月12日 (木) 03:23 (UTC)

返信 (㭍月例祭さん宛) 《「既存記事を見ての調査とかして」おらず、廃止の件も関係ないならば、もはや変える必要もないでしょう。（略）が、必要性もない、メリットもない、デメリットの検討もしていないのでは、ちょっと賛成する余地がなくなります。》について、調査の話がこの流れで「調査」の話がでてくるのは意味がわかりません。「出典としての書誌情報を記載する際に{{Cite book}}を使わないがISBNは記載する人の有無」の話ですよね、調査に関しては。この論点に関してはそもそも㭍月例祭さんが出してきた話であると判断していますが。「出典としての書誌情報を記載する際に{{Cite book}}を使わないがISBNは記載する人」ってどれぐらいいるのですかね？割合を出すのは難しそうとは考えていますが、㭍月例祭さんの肌感覚ではどれぐらいでしょうか？（ちなみに「調査」ってjawpの記事数か利用者数の総数を鑑みた上で十分な記事か利用者を無作為選出して……となるので、jawpを研究対象とした研究者ぐらいしかやらないんじゃないですかね）

《出典としての文献情報を明記して検証可能性に貢献するという文脈以外で、いったいどういうときにISBNを書くのだろう？》については例えば以下のようなものです。

書籍を主とした記事（事例「ノルウェイの森」）
同一の主題の連作の記事（事例「Vシリーズ_(小説)、GANTZ）
作家記事（事例「有栖川有栖」）
漫画家記事（事例「秋吉由美子」）

書籍を主とした記事については書籍の情報の一つなのである意味当たり前ですね。{{基礎情報_書籍}}にも項目があります。他の記事に必要か否かはちょっとわかりませんが、現状として記載されています。なお、（未調査ですが）漫画記事は記載されている比率が高いような気はしています。--iwaim（会話） 2018年4月12日 (木) 07:05 (UTC)

返信なるほどね、たしかに書籍や作家の単独記事なんかではISBNが書かれるわけですね。それは私の発想にはなかったです。知らないことってたくさんありますね。「調査云々」は、どのぐらいの範囲の記事で具体的にどんなことが起きるのかを事前に想定したのか、って話です。いまわかった気がしますが、私はもっぱら出典情報での影響を考えていましたけれど、iwaimさんはもっぱら書籍や作家の記事を想定していたのでしょうかね。それだとWikipedia:出典を明記するに関係ないとおっしゃったのもわかります。--柒月例祭（会話） 2018年4月12日 (木) 07:19 (UTC)

ということで「Wikipedia:出典を明記する」に記載という案は一旦なしでいいですかね。--iwaim（会話） 2018年4月12日 (木) 07:38 (UTC)

下のほうでまとめてお返事しますね。--柒月例祭（会話） 2018年4月12日 (木) 10:32 (UTC)

たとえばですね、FAのばあい、そもそもISBNが書かれてない10本の記事を除くと、72のFAのうちCite系テンプレートを使わずにISBNを記載しているのは16本（22％）あるわけですよ。あなたの提案にしたがうと、FAの2割が「非推奨」の状況になるわけです。そこまでして禁止するほどのなにかがあるのかって話です。

そもそもマジックリンクって、執筆者は特になにもしなくても勝手にリンクが発生してくれるからマジックなわけですが、手間はゼロなんですよ。それに較べると、ISBNテンプレートやCITEテンプレートを使うと二重に手間が増えますよね。掛け算で言ったら0×？＝2ですから。死ぬほど手間が増える、というふうに受け止めてほしいです。

そしてもしも仮にマジックリンクが廃止になったとして、大して困らなくないですか？だって、その場合には、ただテキストとして「ISBN 01234」という文字列が表示されるだけでしょう。その文献を検証したいと考えた利用者にとって、その数字をコピペして検索するだけで、その本に関するサイトがいくらでも出てきます。大した手間じゃないでしょう。それに較べると、Cite系テンプレートを使うと勝手に末尾に「。」とつくので、コピペしにくくなる。「|isbn = 4-06-257658-9」と入力してあると、「ISBN」という文字列もまとめて書籍情報源ページへのリンクがはられるので、結局「ISBNとはなにか」を知りたい人のためにISBNへ誘導するということが実現できていないですよね。

iwaimさんが、こうすると便利になる、と思って、よかれと思って新しいことを提案するのはわかるのですが、他の機能を便利だと思っている人が困るようなことをされるのはちょっと。--柒月例祭（会話） 2018年4月12日 (木) 04:13 (UTC)

返信 (㭍月例祭さん宛) 《FAの2割が「非推奨」の状況になるわけです。そこまでして禁止するほどのなにかがあるのかって話です》は、何故「非推奨」が「禁止」になるのか。で、再度書きますけど、一方を非推奨って記載じゃなくて、他方を推奨だと許容できますか？

《マジックリンクが廃止になったとして、大して困らなくないですか？》については、私は困りません。しかし、困る人がいるかもしれません、としか。

《「|isbn = 4-06-257658-9」と入力してあると、「ISBN」という文字列もまとめて書籍情報源ページへのリンクがはられる》については現在の実装上の話であって、テンプレートを書き換えれば済むだけの話です。

《他の機能を便利だと思っている人が困る》については、マジックリンクを使うことは禁じていないので執筆者は困りませんよね。閲覧者で困るケースはあるでしょうか？--iwaim（会話） 2018年4月12日 (木) 07:12 (UTC)

（追記）iwaimさんが「考慮に入れていない」としても、マジックリンクが廃止されるかもしれない、ということそのものは変わりないですよね。だから、2方式を示し、それぞれの特徴（使い方、利点、欠点）を説明する。そのうえで、どちらを使ってもいいけれどマジックリンク方式は廃止されるかもしれないですよ、ということも書いておく。あとはどうするかは執筆者が選べばいいでしょう。あえて「推奨」とか「非推奨」とかいう必要性はないように思います。

A方式とB方式があって、どちらでもいいのに、A方式をB方式に変えようとして起きる編集合戦、みたいのは確かにあります。悩ましいと思います。でも、「それをなくすため」に「B方式以外認めないことにします」みたいにするのは、それ自体が「合戦」の一部じゃないでしょうかねえ。「どちらでもいいですよ」と明記しておいたり、「A派とB派の争いがありますよ」とアナウンスしておいたり、そのぐらいまでじゃないかなあと思うんですよね。--柒月例祭（会話） 2018年4月12日 (木) 05:54 (UTC)

返信 (㭍月例祭さん宛) 《だから、2方式を示し、それぞれの特徴（使い方、利点、欠点）を説明する》についてはどこに書くというご提案でしょうか？個人的には利点などの話まで踏み込むと、Wikipedia名前空間とHelp名前空間のどこに書いても不要な争いを巻き起こす気はしますが。「こっちの方がメリットがあると書いているし、全部置き換えてやるんだ」というような人がでてきてしまうようなことは、WP:BEANSの観点からやめた方がよいと考えています。

《それ自体が「合戦」の一部》というのは理解できなくもないです。が、それを一旦ここで結論を出すことは有意義です。問題視する行動力がある人はこのノートにくることが期待できますから。「句読点」の話でもそうですよね。直近は「Wikipedia‐ノート:表記ガイド/過去ログ13」でしょうか。結論なく両方式併記（利点などの記載あり）だと各記事で争われる（そしてどっちも許容しているので泥沼化）ということは私は望ましくない状況であると考えています。（現状問題になってないよね。という指摘はあると想像しますが、「Template‐ノート:Cite_book#isbn引数修正の提案」での提案や井戸端、この議論などがあるので起こりうる未来としてはより現実的になっていると考えています）

《マジックリンクが廃止されるかもしれない、ということそのものは変わりないですよね》については現状は知りません。結局どうなるのかについて興味がないので追っていません。Tech Newsを読んでいるので、廃止されるとしたら必要なタイミングで必要な情報が入ってくると考えております。--iwaim（会話） 2018年4月12日 (木) 07:35 (UTC)

iwaimさんが、「出典欄に書誌情報を書く」ことは想定していなくて、書籍や作家の記事で刊行図書一覧などに書くことを想定している、ということがわかり、ちょっと困惑しています。

私の意識では、(1)Wikipediaの大方針である検証可能性　(2)それを実現するための手段として出典明記があり　(3)出典を特定するために書誌情報を書き (4)書誌情報を書くためにいろいろな方式がある、というふうになっていて、最終的には(1)が満たされるならば方式はどれを使ってもいい、というのが考え方。だからこっち推奨、あっち非推奨なんて縛りはいらない。という話でした。

でも、それとはまったく関係なく、書籍の記事や作家の刊行物を列挙するような文脈でISBNをどう書くか、ということになると、私には特に意見はない、というほかありません。

私はその方向にあまり知識がないので（Hisagiさんは詳しいだろうけど）うろ覚えレベルですが、ISBNて版が違うと番号が変わる？んですよ、ね？個人的にはそういうものをいちいち書く意味あるかね？重版したらいちいち全部書くの？とは感じます。でもまあ、200年前の馬の母親の毛色まで書きたい人もいるわけだから、書籍や作家の記事を書く方たちにとって有意義な情報なんでしょうし、そういう方が大勢いるからそうなっているわけで、それはそれでいいと思います。そういうところで書式を統一しようぜというのであれば、私としては、関心がある方・詳しい方の間で納得いくまで議論してくださればいいと思います。

が、その話の結果として出典情報を書く際のことまで規制されるとなると話は別です。なので、「推奨」「非推奨」など、優先順位を定めるような表現はすべからく反対します。もしたとえば、「書籍記事や作家記事で刊行物をリスト化しようという局面では」という限定のもとでならば、推奨でも非推奨でも禁止でも、とくに意見はありません。「出典情報を示す場合にはこの限りではない」みたいなことでもいいです。・・・が、そんな場合分けみたいのするのもどうかと思いますよね？

iwaimさんが想定していないということならば、「Wikipedia:出典を明記する」のほうにISBN記載時の留意点を追記するということは、「Wikipedia:出典を明記する」のほうで別に議論しようと思います。そもそもあちらにはWikipedia:出典を明記する#入手方法を示すにチラッと出てくるだけでISBNの書き方コーナーがありませんから、WP:CITEHOWに追加することは有意義でしょう。が、仮に、そっちには「二方式どっちでもいい」と書き、こっちには「A方式は非推奨／B方式推奨」と書くと相互に矛盾します。だから結局、どの文書に追加するにせよ、「推奨／非推奨」について合意をはかっておくことは必要でしょう。--柒月例祭（会話） 2018年4月12日 (木) 10:32 (UTC)

返信 (柒月例祭さん宛) 《iwaimさんが、「出典欄に書誌情報を書く」ことは想定していなくて、書籍や作家の記事で刊行図書一覧などに書くことを想定している、ということがわかり》とありますが、私はそんなことは一切発言していません。本提案はある分野やある記述、特定の箇所に限定したものではありません。それは私の文面案をみても理解できるかと。また、そういう話なので「出典欄に書誌情報を書く」ことだけを視野にいれている方の意見も必要であると考えております。

《ISBNて版が違うと番号が変わる？んですよ、ね？》これが重版を意味するものでしたら認識が誤っています。初版と第2版では同じISBNが使われます。

《「推奨」「非推奨」など、優先順位を定めるような表現はすべからく反対します》という立場であれば、現状の「表記ガイド」の記載にもいろいろいいたいことがあるんだろうとは思いますが……。そのようなお考えを持つこと自体は否定しませんし尊重しますが、「Wikipedia‐ノート:表記ガイド/過去ログ13#「、」「。」の強制は妥当か？」での㭍月例祭さんの意見を受けたディー・エムさんの『それを言い出したらきりがないというか、表記ガイドが成り立たないと思います。』やKs aka 98さんの『まず、ウィキペディア日本語版では、「強制」は現在もされておらず、「統一」が図られている、と理解しています。少なくとも書き手がピリオドやカンマを使うのは自由だけど、統一したい人が、表記ガイドに従って統一している。統一のためのコストを下げるために句読点にしてくれる方が助かるし、揃えてくれないかとお願いするのはいいけれども、書き手の側に「強制」するのはやりすぎだと思ってます。』という指摘について、今一度考えてみてはいかがでしょうか。（私も両氏と同様の意見を持ちます）--iwaim（会話） 2018年4月12日 (木) 10:54 (UTC)

『初版と第2版では同じISBNが使われます』？そんな認識でこんなデタラメな話をしているのですか？重版と第2版も違いますし、ISBNと版次は実際には関係ありません。出版者が勝手にやってますので、同じものに複数のISBNを付与したり、内容の違うものに同じISBNを付与したり、なんでもアリです。iwaimさんはこの話に手を出さないほうが良いのではないでしょうか？ --Hisagi（会話） 2018年4月12日 (木) 12:12 (UTC)

それは認識していませんでした。とすれば私の間違いですね。ご指摘ありがとうございます。ただし、私のISBNに関する知識がないことと、本提案の内容についてはそれほど相関がないと判断していますが、いかがでしょうか？（当初から今まで「PMID」がどのようなルールで割り振られているのかを存じていませんが、それによって本提案の根底が瓦解するとは考えておりません）--iwaim（会話） 2018年4月12日 (木) 12:20 (UTC)

関係ないですか、そうですか。じゃあ尚更何をやってるんだ…あぁやはりテンプレ遊びがメインなのかな、という感想になりますけども。瓦解以前に、iwaimさんの頭の中にしか根拠がないのですし、「非推奨であって禁止ではない」と言い訳をしていても、実際の文言はテンプレ強制ですし、これで改定してしまったら最後、ガン細胞のようにテンプレで埋め尽くされるのは目に見えているのですから。--Hisagi（会話） 2018年4月12日 (木) 12:59 (UTC)

「、」と「，」のどちらを選ぶかという話と、「、」を表示させるためにどんな技術的手段を使うか、の話を混同してらっしゃいます。この提案は後者に属します。そして提案の当初から、なんのために、どうして変える必要があるのか全く説明されていないですね。第三者には意図も目的もまったくわかりません。だから私は混乱しているのです。そして、どういう範囲にどのような影響が及ぶか、説明もしていないし、知ろうさえしていないようにしか見えません。「廃止」も関係ない、「出典の明記」に影響を及ぼすことも検討しない、実際どれぐらいの記事に影響が出るか調べる気もない、ISBNのことも知らない、それで全範囲に影響が及び、10年以上問題なく使われているものを非推奨化し、手順を複雑化させようというのは、やはり賛成する余地がないです。--柒月例祭（会話） 2018年4月12日 (木) 13:28 (UTC)

《この提案は後者に属します》については「表記ガイド」という文脈でそこを区別する必要があるとは考えておりません。

変更の必要性については明確には述べていないというのはその通りです。（個別の理由があれば説得力を増強するメリットがあるとはいえ）「表記ガイド」では「表記を統一する」という点が目的であるため、それ自体が「必要性」であるとは判断しています。

《実際どれぐらいの記事に影響が出るか調べる気もない》については何故あの極めて限定的な話題の話にこだわるのか全然理解できません。本提案の影響範囲は記事名前空間に限定したとしても「全ての記事」に決まっています。それが「表記ガイド」です。（対象範囲を限定する場合は限定するための文言が提案内容に含まれることでしょう）--iwaim（会話） 2018年4月16日 (月) 09:25 (UTC)

反対既存の、簡単で、普及している、特に問題はない、廃止になる予定もないやり方を「非推奨」とするにはあまりに弱すぎませんか。コード種別の部分にリンクを張れるからといって、それが必要（常にそうするべき）とは思いません。チェックデジットによる検算も、わざわざこんなことをしてまですることではないでしょう。エラーのあるISBNを一律でエラーのカテゴリに放りこむような乱暴なやり方も支持できません。--Hisagi（会話） 2018年4月10日 (火) 17:10 (UTC)
- 返信 (Hisagiさん宛) 《エラーのあるISBNを一律でエラーのカテゴリに放りこむような乱暴なやり方も支持できません》については「Template‐ノート:ISBN2」あたりで問題提起してください。--iwaim（会話） 2018年4月10日 (火) 18:24 (UTC)

iwaimさんは、まだ諦めずにこの話を延々と続けるつもりですか？ --Hisagi（会話） 2018年4月12日 (木) 13:09 (UTC)

他の方の意見も聞いてみたいとは考えています。--iwaim（会話） 2018年4月16日 (月) 09:41 (UTC)

もともと表記ガイドにはマジックリンクのことは触れられていません。それはマジックリンクは「表記ガイド」に属することではないからでしょう。一方で、Help:ISBNのリンクにはWikipedia:出典を明記するへの言及があります。また、項目としてisbnを持っている様々なCite系テンプレートはWikipedia:出典を明記するためのものです。こうしたことからも、マジックリンクを用いてISBNを表示することと、出典を明記することのあいだには少なからぬ関係があることがわかります。「出典の明記」のことを考えずにISBNまわりをいじるというのは不適当でしょう。

ぶっちゃけ、廃止されるかもしれないからいまのうちに手を打っておこう、という話だったらまだ理解はできました。
2方式あることを知らせたり、それぞれの特性を解説したり、なんとなればそのうち1つは廃止されるかもしれないということを告知すること自体は、とてもいいことだと思っています。（メリット、利点という表現に難があるなら「特性」「機能」という表現でいいでしょう。）
ただまあやはり、それをやるべき場所は「表記ガイド」ではないと思いますよ。上でも書いた通り、表記ガイドは「、」か「，」のどちらにするべきかを示すけども、どうやって「、」を表示させるかまでは指示するものではないでしょう。だから、Help:マジックリンクやWikipedia:出典を明記する#書誌情報の書き方やWikipedia:出典テンプレートあたりに、ISBN表示の2方式を併記することはとても素晴らしいと思います。
書籍や作家の記事でのことについては、プロジェクト:出版とか、プロジェクト:作家、プロジェクト:漫画あたりにこそ書くべきことでしょう。PJ漫画ではISBN表記について詳しい指示があり、そこではH:ISBNを参照することになっていて、H:ISBNでは明らかにマジックリンクのことしか念頭にいれていません。
今回の提案は、「上流（MediaWikiとか廃止とか）」のことも、「下流（この変更によって生じる結果、記事のこと、各地の文書のこと）」のことも、どちらもよく説明されず行われたものという感じがします。「感じがする」というのは、実際にはiwaimさんの中では熟慮されたのかもしれないですが、第三者にはわかりません。
iwaimさんが経験なさったようなベルギービールでの出来事などは、私も本当にいやだなと思います。そこは共感します。そういうつまらない編集がなくなればいいというのは全く同感です。そのためのアプローチというか、方法論というか、考え方が違うだけ。iwaimさんはマニュアルをキチッと整備することでそういうのが減ると考えてらっしゃる。そういうこともあるでしょう。でも私はどちらかというとWP:CREEPの考えを支持していまして、細かい規定を増やせば増やすほどトラブルは増えると思っています。トラブルの原因は、規則の不備にあるのではなくて、字面だけおって趣旨や目的を理解しない・協働の場での他者へのリスペクトを軽んじる「人」の側にあると思うからです。--柒月例祭（会話） 2018年4月13日 (金) 06:26 (UTC)
- 返信 (㭍月例祭さん宛) 《もともと表記ガイドにはマジックリンクのことは触れられていません。それはマジックリンクは「表記ガイド」に属することではないからでしょう》には同意できません。
  《書籍や作家の記事でのことについて》は私自身はその分野に特化して提案する内容は特にありません。
  《waimさんが経験なさったようなベルギービールでの出来事》については、私自体は特に嫌悪感などは持っていません。単に「こういうことやっていると編集合戦が発生することもあるだろうな」という気づきを得ただけです。--iwaim（会話） 2018年4月16日 (月) 09:40 (UTC)

「JIS X 0213」をそろそろ解禁してはどうか（「ゔ」表記）[編集]

現在、Wikipedia‐ノート:索引にて、「ヴ」を含む記事の読み仮名表記をどう扱うかが問題となっております。現在の索引では「読み表記はすべてひらがなとする」「ヴァ、ヴィ、ヴ、ヴェ、ヴォの読みはバ、ビ、ブ、ベ、ボとして扱う」というルールになっております。現行の表記に従うと、

ヴァイオリン協奏曲（ばいおりんきょうそうきょく）
ヴェネツィア国際映画祭（べねつぃあこくさいえいがさい）

のような形となります。このように単純に「ヴァ＝バ」「ヴェ＝ベ」に置き換え可能な項目はあまり問題ないのですが、一方で

ヴィーン条約（びーんじょうやく）
ヴァイマル憲法（ばいまるけんぽう）
ヴォルフガング・アマデウス・モーツァルト空港（ぼるふがんぐあまでうすもーつぁるとくうこう）
ヴァルター機関（ばるたーきかん）

という表記をせざるを得ず、単純な置き換えでは読み表記に違和感を生じるケースが増えてきたことから、凡例の改訂を検討しております。その中の一案として

ヴィーン条約（ゔぃーんじょうやく）
ヴァイマル憲法（ゔぁいまるけんぽう）

のように表記する案が出されておりますが、JIS X 0208に含まれない「ゔ」は当ページにて「できるだけ使わない」と規定されていることが凡例改正にあたって障害のひとつとなっております。索引の一部においては代替表記である「う゛」を使用しているケースもありますが、こちらも緊急避難的措置であると同時に決して支持されている表記法ではありません。この際、JPWP全体で「#使用可能な文字」に「ゔ」を含むJIS X 0213に規定された文字を追加いただける方が、索引のみならず全体での表記の自由度が上がり、記述しやすくなるケースが増えるのではないかと考えます。この記載の源流はWikipedia:表記ガイド 2004年3月9日 (火) 06:40‎初版およびWikipedia:日本語環境 2006年6月20日 (火) 15:45の版まで遡れるようです。JIS X 0213は2000年に制定され、規定導入時の2006年時点ではそれ以前の機器との互換性を重視する必要があったのだと思いますが、既に導入から15年以上が経過しており、かなり機器の変化も進んだことから、そろそろ基準そのものの見直しが必要な時期と考えます。過去ログをいくつか読んでみても、JIS X 0208に含まれない文字のためにいくつか議論が起こっているようです（ノート:う゛(2008年4月)、Wikipedia‐ノート:表記ガイド/過去ログ7#JIS X 0208外漢字の表記について(2010年2月)、Wikipedia‐ノート:表記ガイド/過去ログ9##JIS X0208に含まれない印刷標準字体の扱いについて(2011年12月)、Wikipedia‐ノート:表記ガイド/過去ログ10#常用漢字がJIS X 0208に含まれない場合(2012年11月)など）。今後のことも考え、そろそろJIS X 0213に規定された文字を解禁していただきたいと考えております。なお、この提案は本文に限った話とします。Wikipedia:記事名の付け方に関しては別のシステム上の制約もあると思われますので、そちらの適用は求めておりません。--Suz-b（会話） 2017年8月9日 (水) 16:50 (UTC)

コメント 現状維持寄りの意見ですが、積極的な賛否票は控えます。

現状の表記ガイドでJIS X 0208の利用が本格的に規定されているのはWP:JPE#漢字の部分が大きいと思いますが、漢字か否かに関わらず「できるだけ使わない＝やむを得なければ使ってよい」ということかと思いますので、解禁という言い方には少々違和感を感じます。各ノートで合意があれば使用に問題はないと思いますし、そのための合意の障害になっているというのも、合意のためには必要な議論だと思います。

以前の波ダッシュやマイナス記号の議論にも示しましたように、機器内蔵ブラウザの類ではまだ特殊文字の類を表示できない環境は完全にゼロではない可能性がありますので、JIS X 0213の特殊文字の制限が緩和されても、結局は利用者の裁量で多少は意識しながら（表示されなくても影響が小さい形で）運用する形になると思います。現状で「Unicodeで規定されている文字」であれば使用自体は許可されているのですから、積極的に改正する意味は薄いと考えます。

もっとも件の波ダッシュの議論からも既に1年半ほど経っており、将来的に多くの文字が使用できるようになることは利便性の向上として自然の流れだと思いますので、あまり積極的な主張をするつもりはありません。ただ、波ダッシュの件では2007年頃の議論で、Windows Vistaの発売で逆字体の問題が解決されたのでそろそろ「〜」に統一してもいいだろうという、将来を見据えた形で制定が行われたわけですが、実際にはVistaはあまり普及せずかなりの間XPが使われ続け、あまつさえ議論の後に発売された2011年の機器内蔵ブラウザですらまだ「〜」に対応していなかったりと、当時の見切り発車は思ったよりも影響が大きかったと個人的には思います。そうした経緯から、一部の例外という形ではなく全体に影響する形での、将来を見据えた先取り改正というのは、個人的にはあまり気は進みません。--Gwano（会話） 2017年8月10日 (木) 08:35 (UTC)

コメント いつまでもレガシーに固執するのもどうなのかなという感は否めません。Windowsでいえば、現在のよくあるネット閲覧を考えた場合、Windows 7 SP1・8.1 Update・10への移行ができないと、いろいろと不都合が生じてきています（仕様云々がわからないとしても、目につくところでも表示乱れが激しくなる等の問題があります）。サイト開設者サイドでレガシーに固執し続けるよりも、今は先を見据えた対応に切り替えていくべきなのではないかと考えます。いまどき機器内蔵ブラウザでネット閲覧という、非常にマイナーな閲覧方法はあまり考慮に入れなくて良いのではないでしょうか。--Don-hide（会話） 2017年8月10日 (木) 08:56 (UTC)

いくつかご意見をいただきましたので、事情を補足しておきます。Wikipedia‐ノート:索引で現状問題になっているのは「ゔ」だけですが、索引は分量と統一ルールの問題があり、個別に使用を検討することが難しいという事情があります。もし現状の表記ルールを変えずに個別に認めるという形を維持したまま索引の凡例で「ゔ」の使用を認めると、Wikipedia:索引はい、Wikipedia:索引_はいおりん、Wikipedia:索引へね、Wikipedia:索引_ほる、Wikipedia:索引しゆなど、おそらく索引全体で500以上の「ゔ」が使用されることになるでしょう。これらの記事にはカタカナのみの記事名も多いことから全てに読み仮名が必要になるわけではありませんが、少なくともWikipedia:索引はいだけで20は必要なことがわかっています。これだけの分量になると、「できるだけ使わない」とは言えない状態になってしまいます。索引は統一ルールによって編纂されているのが望ましく、一方でページ数が膨大です。現状「ヴァ」の読みに「ば」「ゔぁ」「う゛ぁ」「わ」の4種類の読み表記が使用され混乱が見られる状況を是正したいという意図から始まった議論ですので、今回手を入れるとなればかなり大がかりなものとなり、かつ将来にわたってできるだけ再修正を必要としない形が望ましいと考えます。それから、今回の提案は「先取り」ではありません。むしろ「遅ればせながらJPWPも世間一般の基準に合わせませんか」という提案です。ウィキペディアの性質上、表記方式が一般社会の後追いにならざるを得ないことはやむを得ませんが、さすがに17年は遅れ過ぎでしょう。もし今回の提案がコミュニティの判断として「時期尚早」として見送られるのであれば仕方ありません。JIS_X_0208#将来にあるように、WindowsがJIS X 0213に対応したのはVistaからですので、今でもWinXPを使用している方が少数とはいえ存在するのは事実でしょう。しかしその場合、一体いつになったら新しい基準を受け入れるのでしょうか。20年？30年？50年？100年？実は私は未だに2008年製のガラケー(SH705i)を使用しており、その携帯では「ゔ」は表示できません。しかし古い機種ということを自覚しておりますので、ある意味互換性については諦めている部分があります。古いブラウザを使用している方はそのあたりをある程度覚悟しており、その上でご自身の慣れであったり使いやすさといった面を重視してブラウザを継続使用されているのではないかと思います。個人的には10年～12年を一つの区切りと考えてよいのではないかと思います（常に10年程度の遅れで世間に追従する形）。パソコンの法定耐用年数は4年ですし、その3回分を経ていれば十分待ったと言えるのではないでしょうか。なお、影響範囲を限定的にするため#漢字については現行の基準を変えないことも視野に入れております（が、将来的にはどうか、という問題は残ります）。--Suz-b（会話） 2017年8月10日 (木) 17:02 (UTC)

Help:特殊文字#JIS X 0213にある文字とHelp:MediaWikiに適応するブラウザにも関係しそうな事項ですね。それと、現行の表記ガイドの「Unicodeで規定されている文字に必要なものがあれば、すべて使うことができます」の件は、2005年10月リリースのMediaWikiバージョン1.5以降では全プロジェクトにおいてUnicode (UTF-8) でエンコードされるようになったことと対応するものだと私は考えています。もしそうであれば、（少なくとも編集者側においては）もはやJIS X 0208かJIS X 0213かというより、Unicodeに対応しているか否かの問題になると思われますが、いかがでしょうか。2002年3月のUnicode 3.2で既にUnicodeは（あくまでも規格上は）JIS X 0213に正式に対応しています。一方で閲覧者側にとっては、「文字が表示できるかどうか」が肝心であり、それはHelp:特殊文字#JIS X 0213にある文字にもある通り、フォントがJIS X 0213に収録されている文字・字形に対応しているか否か（実装）だけを気にしていればよいのだろうと推察します。要するに、JIS X 0213対応フォントの普及率こそが重要であるともいえますかね？「（JIS X 0201とJIS X 0208にない文字は）できるだけ使わないように」との但し書きは、それ（＝環境ごとの対応フォントの利用可能性の差）に配慮した形なのかなと思います。Wikipedia:表記ガイド#使用可能な文字の改定にあたっては、フォントの普及率、すなわちブラウザのシェアとその既定（標準）フォントが目安となるでしょうか。以上、もし私の理解に誤りがありましたらご教示ください。--Doraemonplus（会話） 2017年8月11日 (金) 07:50 (UTC)

レガシー環境・マイナー環境についてはもちろん全ての機能に対応する義務はありません。ただ、それらは最低限のテキスト閲覧のみ提供できればよいという方向性だったかと思われるのが難しいところだと思います。「MediaWikiに適応する（MediaWikiのサポート対象となっている）ブラウザ」については「多くの機能に対応すべき環境」の意味合いが強いと思いますので、単純に普及率で判断することもできると思います。しかし「テキスト閲覧のみ対応する環境」については普及率からの判断は難しそうに思います。統計によっては1％未満が集計されない可能性があり、日本のネット人口（約1億人）の場合は仮に0.01％であっても1万人に相当し、配慮が必要に思われますので。

もっとも、マイナス負号の問題のように表示されないことで致命的な誤解を招くケースでもない限り、一部の文字が見えなくなっただけで大意を読み取れなくなるケースがどの程度生じるのかは現時点で何とも言えませんが。--Gwano（会話） 2017年8月11日 (金) 11:45 (UTC)

質問一つお聞きしたいのですが、「テキスト閲覧のみ対応する環境」というのは具体的にどのような環境が想定されますでしょうか？--Doraemonplus（会話） 2017年8月12日 (土) 07:06 (UTC)

テキスト閲覧のみ対応する環境を保証する具体的な経緯について詳しく把握していませんが、少なくともテキストリーダでの読み上げによるバリアフリー問題は絡んでいるのではないかと思います。そういう意味では、機器内蔵ブラウザについても何らかのバリアフリーで活躍している可能性はありそうな気がします。まあ個人的な用途としては単に3Dテレビ内蔵のブラウザをまだ使っている程度ですが。--Gwano（会話） 2017年8月13日 (日) 07:01 (UTC)

ご回答ありがとうございます。Gwanoさんのこれまでのご発言を総合すると、少なくともガラケー、インターネット対応デジタルテレビ・ゲーム機が「テキスト閲覧のみ対応する環境」の対象となるでしょうか。機器内蔵ブラウザについては、ブラウザを内蔵する機器は多様にあるため、全体を把握して対処するのは困難だと思います。それと、テキスト読み上げやスクリーンリーダーについては、文字コードとはまた違った角度からも考えるべきではないか（→Wikipedia:アクセシビリティ）と思います。--Doraemonplus（会話） 2017年8月13日 (日) 09:22 (UTC)

現実問題として、何十年という配慮を心配する必要は無いと思われます。MediaWikiではSSLなどのセキュリティ強化が段階的に行われており、古い環境ではそもそも閲覧自体が不可能になっているからです。さすがにそのような環境まで配慮するのは難しいと思います（検索サイトのキャッシュ等で間接的に閲覧できる可能性は残されてはいますが）。例えば私のケータイは2011年に新調したものですが、2015年頃からウィキペディアにはアクセスできなくなっていますので、2008年のケータイでまだ閲覧できるというのは運が良いほうではないかと思います。なお同時期の例ではPSP内蔵ブラウザでは既にウィキペディアにアクセスすることはできませんが、ニンテンドーDSブラウザーではどうにか閲覧できているというような状況ですので、そのあたりに限界があるようです。Opera系の場合は最新の機能に積極的に対応する傾向があるから古い環境でもまだどうにか閲覧できているものと考えられますが、遅かれ早かれ、いずれはMediaWikiにアクセスできない「配慮する必要の無い環境」になると思われます。恐らく、Presto時代のOperaでMediaWikiにアクセスできなくなるような頃には、かなりのレガシー環境が切り捨てられるようになるのではないかと予想しています。まあ、逆を言えば、今はまだ配慮の余地が残されているかもしれないわけですが…。--Gwano（会話） 2017年8月12日 (土) 04:59 (UTC)

gooが携帯用にウィキペディアの記事の閲覧機能を提供しているので、私のauガラケーからもよく閲覧しています。JIS X 0208の漢字は読めますが、JIS X 0213の文字は空白になります。まだ少なくとも数年はJIS X 0213の文字が読めない環境でウィキペディアの記事を閲覧する人は残るでしょう。アプリに互換性がないことやセキュリティ面で不安があることからスマホを使わず携帯電話を使い続けている人は少なくないと思います。今後10年以上携帯を使い続ける人がいても不思議はありません。--アルビレオ（会話） 2017年8月12日 (土) 07:37 (UTC)

Gwano様 私の2008年のガラケー(SH705i)で「ゔ」が表示できない、というのは外部サイト含めたインターネット全般の話です。SSLが数年前に非対応になったためウィキペディアに接続することはできません。そういう意味では「配慮する必要の無い環境」です。--Suz-b（会話） 2017年8月20日 (日) 16:33 (UTC)

コメント いわゆる「ガラケー」ですが3G回線が使用不能となりますと、通話だけではなくネット閲覧も使用不能になってしまいます。3G回線は10年後には確実になくなっていると思われます。いわゆる「ガラホ」にしても「スマホ」の一種（「ガラケー」のように使用できるよう、通常の「スマホ」からはかなりカスタマイズされたもの）であって、（一部に3G回線を用いるものがあるでしょうが）基本的に4GまたはLTE回線を用いることになりますし、OSにしてもガラケー独自のものではなく、Androidベースになっていますので、文字表示の問題にしても、スマホと同様と考えられないでしょうか。またガラケーを使い3G回線でウェブサイトを閲覧することについては、かなり厳しくなってきているのが正直なところではないでしょうか。また今となっては一般的に非推奨とされる閲覧方法をウェブサイトの側で提供し続けることが、古いOSの乗ったPCや携帯等のセキュリティを脆弱にする（サポートが切れてかなりの長期になっても使い続けられてしまう）要因になっているとも言えないでしょうか。私も「ガラケー」を持ってはいますが、今では通話+簡単なメール・SMSのやりとりでの使用にとどめており、それ以外のネット閲覧には使用していません（通信料が高額になる云々とは別の問題です）。--Don-hide（会話） 2017年8月12日 (土) 08:19 (UTC)

とりあえず一点だけ。『また今となっては一般的に非推奨とされる閲覧方法をウェブサイトの側で提供し続けることが、古いOSの乗ったPCや携帯等のセキュリティを脆弱にする（サポートが切れてかなりの長期になっても使い続けられてしまう）要因になっているとも言えないでしょうか。』ですが、古いPCと携帯では全く事情が異なります。古いPCはセキュリティの脆弱性の一因になりますが、古い携帯がセキュリティ上問題になることはほとんどありえません。なお、スマホは一般的に言ってPCより脆弱です。一般的に言えばセキュリティの脆弱さはスマホ > PC >> 携帯です。--アルビレオ（会話） 2017年8月12日 (土) 08:43 (UTC)

iモードに代表されるような従来型の携帯電話は、通話・メール・携帯サイトの閲覧が主な用途でしたから、後年フルブラウザ搭載機種も登場したとはいえ、元々が非携帯サイトであるWPを（文字エンコードやフォントを含め）障害なく閲覧しようとするのは土台無理な話です。Help:携帯端末でのアクセスでもフィーチャー・フォン（いわゆるガラケー）は相手にされていないようで、ゲーム機内蔵ブラウザでの閲覧も同様です。「JIS X 0213の文字が読めないネット接続環境」がまだ一定の割合あるとしても、「JAWPを閲覧するためにその環境しか使用しない/できない人」というのは結構少ないはずです。普通、制限がある環境はそれと割り切って使うものです。私は「JIS X 0213の文字が読めないネット接続環境」が何年後かに「主流ではなくなる」ことはあっても「完全消滅」するとは到底思えません。可能な限り（人によっては改造してでも）使い続ける人は必ずいるからです。ではそこで、JAWPが公式にガラケー等でのテキスト閲覧を保証する義務や責任はどの程度あるのでしょうか。基本的にWPはパソコン（あるいは最近のスマートフォン・タブレット）での利用を中心に設計されているのであり、もしガラケーやゲーム機で読めたら唯々幸運というしかないでしょう。また、ガラケー向けにはテキスト閲覧のみに特化した非公式のgoo Wikipediaや暇つぶしWikipediaがあります。そちらでは、JIS X 0208にない文字はJIS X 0213対応の機器で閲覧しても文字化けするようです。推測ですが、サーバ側でShift_JISに変換してしまうからでしょうか。少し古いですが、Wikipedia:井戸端/subj/モバイル版の表示不具合なんて議論もありました。まぁ、現実的に考えれば、Don-hide氏が仰るように、3G回線が完全停波してガラケーのネット接続が使用不能になるまで待つのが一つの目安になるかもしれません（それでもケータイWi-Fi対応のガラケーはどうするんだという問題は残されます。3Gの停波と同時にサービスが終了すれば問題ないですが…）。--Doraemonplus（会話） 2017年8月13日 (日) 06:14 (UTC)

ケータイのセキュリティについては詳しく存じませんが、少なくともサポートの切れたオールドパソコン云々については本議論には恐らく関係がありません。私はここまで、本題部分に関しては基本的にオールドPCをほとんど問題にしてこなかったはずです。なぜならWindowsはNTの頃から既にUnicodeに標準対応しており、XPだろうが2000だろうが「ゔ」は表示できるはずですので、最初から議論する意味が無いのです。ここまでの議論で問題になっているのは基本的に特殊文字を搭載していない機器内蔵ブラウザの類であり、Opera云々についても機器内蔵版Operaを意識したものです。もしかしたらVistaやXPの話を出したことで誤解を与えてしまったのかもしれませんが、それは単に10年前の議論を引用した話に過ぎません。

Help:携帯端末でのアクセスについては初版が2015年の翻訳であり、最初からスマホ用に作られたページではないかと思います。

将来ガラケーが使えなくなるという話は解禁の目安としては面白いかもしれませんね。根拠の無い適当な日付を解禁予定日にするよりは、よほど説得力がありそうに思いますので。もっとも、ガラケー以外にもデジタルテレビやゲーム機などのように必ずしも携帯電話の回線を使わない形でのブラウザ環境もありますし、テキストリーダへの影響についても未検証ですので、今はまだ何とも言えませんが。--Gwano（会話） 2017年8月13日 (日) 07:01 (UTC)

取り下げ 最後の意見から1ヶ月以上経過しましたが、現時点で積極的な賛成意見は得られておりません。Gwano様、アルビレオ様は現状維持寄り、Don-hide様は賛成寄り、Doraemonplus様は中立、といったご意見に見受けられますが、いずれもコメントの形でいただいたものであり明確な賛成票ではないことから、将来的な問題はなお残るものの、現時点での合意の形成は困難と判断し今回は見送らせていただきます。議論にご協力いただいた皆様、ありがとうございました。ひとまずこの結果を受け、Wikipedia‐ノート:索引での議論を再開したいと思います。--Suz-b（会話） 2017年10月10日 (火) 15:21 (UTC)

4桁、5桁の数字にコンマまたはスペースを入れるかどうか[編集]

私 awaniko　と新規作成さんとの間で、議論していましたが、広く御議論いただくため、こちらに移します。

多桁の数字の場合に、コンマ（財務分野など）、スペース（科学技術分野）を入れることは既に規定されています。論点は、数字が4桁、5桁である場合に、コンマやスペースを入れるかどうかです。規定における例として4桁、5桁のものがない（最初のところに3,000ドルはある。）ために、議論になっているものです。なお、科学技術分野では、4桁の場合はスペースを入れないのが通例です。

これまでの議論は、利用者‐会話:Awaniko の「3桁区切りのスペース」をご覧下さい。 --Awaniko（会話） 2017年9月15日 (金) 03:53 (UTC)

別にどちらかに統一する必要はなく、ケースバイケースで入れるか入れないかを決めれば良いと思います。なお「入れない」に統一すると{{人口統計}}を使用している多くの自治体記事に影響するという弊害があるので、反対します。--新幹線（会話） 2017年9月15日 (金) 05:04 (UTC)

コメント 先行する議論を拝見したところ、スペースを入れるべきでない理由として「3桁区切りのスペースをむやみやたらにいれると途中で改行される恐れがあります」とりますが、それならば{{Nowrap}}テンプレートを使えばよろしいのではないでしょぅか？科学分野はともかく、財務分野で4桁にスペースを入れないのは違和感があります。--Kanohara（会話） 2017年9月15日 (金) 08:59 (UTC)

ケースバイケースでしょ．なお発端は分 (角度)です．新規作成 (利用者名) （会話） 2017年9月16日 (土) 10:42 (UTC)

新幹線さんがおっしゃるように、人口や山の高さなどの表記では、4桁や5桁でもコンマを入れるのが普通であり、入れないのは不自然です。それから、途中で改行されてしまう現象に対しては、Kanoharaさんがおっしゃるように、テンプレートを使えば何の問題もないはずです。これは新規作成さんも主張されている方式です。　また、ガイドラインなのですから、規定として決めておかないと編集合戦などを招いてしまうでしょう。したがって、コンマ又はスペースを入れるようにガイドラインを修正すべきです。　--Awaniko（会話） 2017年9月28日 (木) 14:47 (UTC)

コメント閲覧者側の設定に任せるような事は、出来ないでしょうか。記号自体に論理的な意味を持つ場合は別ですが、この場合のコンマやスペースは単に見栄えや見易さの問題と考えられます。似たような例として、CSS3 に半角表示か全角表示かを選択できる機能が追加されています。ブラウザの対応状況を考慮すると、この機能は現実的ではありませんが、実現方法はCSSでもテンプレートでもマジックワードでも良いと思います。--影佑樹（会話） 2017年9月28日 (木) 16:29 (UTC)

コメント 個人的には指示の肥大化の懸念があるため、コンマを入れる/入れないという規定をいれることに積極的に賛成できません。また、そもそも表記ガイドでは桁区切りには漢字を使うのが原則で、ケースバイケースでコンマやスペースによる区切りを使ってもよい、となっているに過ぎません。そのため、敢えてコンマやスペースの区切りを推奨するような規定を入れる理由はありません。発端となった分 (角度) も、21 600分の1 とするぐらいなら 2万1600分の1 とする方が自然でしょう。--新幹線（会話） 2017年9月29日 (金) 03:03 (UTC)

ガイドラインの規定は、桁区切りに「漢字を使うのが原則」ではありません。また、「ケースバイケース」としているのでもありません。

1）分野毎の確立した慣習が無い場合：4桁ごとに「万」「億」を入れることを推奨。小数部分には適切な間隔で半角スペース　2）財務分野・製図分野など：整数部分には3桁ごとにカンマ。小数部分には3桁ごとに半角スペース。　3）科学技術分野など：整数部分・小数部分ともに、3桁毎にスペース　　となっています。

分 (角度)の項目は、科学技術分野のものですから（カテゴリが角度の単位、SI併用単位、数学に関する記事　となっている。）、上記の3）の規定を適用し、3桁ごとにスペースを入れるべきです。

それから、私の提案は、指示の肥大化ではなく、むしろ「簡素化」です。なぜなら、私の主張は桁の多少に関わらず、3桁ごとにコンマやスペースを入れるようにすべき、と言う単純なことだからです。新規作成さんの主張が、桁数が4や5の場合にコンマやスペースを入れるべきでないということからこの議論が始まったことに留意して下さい。　--Awaniko（会話） 2017年10月3日 (火) 16:10 (UTC)

主張がめちゃくちゃすぎます．ガイドでは桁区切りをしろとはなっていません．数学は（ガイドの意図する）「科学技術分野」ではないですし桁が多くても何もしないのが一般的です．最後は私の主張ではないです．新規作成 (利用者名) （会話） 2017年10月4日 (水) 02:15 (UTC)

私も新規作成さんと同じく数学を科学技術分野と扱うことに漠然とした違和感を感じていましたが、やはりそうですよね。広義では科学技術分野でしょうけど、一般に言う科学技術分野とは異なると思います。

ガイドラインの規定の件ですが、新規作成さんが仰るように現状そもそも桁区切りの使用は任意です。それをやめて「桁の多少に関わらず、3桁ごとにコンマやスペースを入れるようにすべき」と定めることに何かメリットはあるでしょうか。その規定を追加することが本当に記事の改善につながるでしょうか。メリットもなしに無用な指示を追加するのは指示の肥大化に他なりません。また、桁区切りを使用する場合は、「分野ごとの確立した慣習がなければ」万億兆の区切りを使うのが原則です。確立した慣習があればコンマやスペースを「使ってもよい」です。とにかく、現状のガイドラインは特定の分野で万億兆以外の区切りに統一するようにはなっていないことをご理解ください。--新幹線（会話） 2017年10月4日 (水) 04:32 (UTC)

ちなみに、数学定数の記事では小数部分は5桁ごとにスペースが入っています。これは表記ガイドに違反していますが、数学分野での慣習を考えるとむしろ適切な記法だと思います。--新幹線（会話） 2017年10月4日 (水) 16:01 (UTC)

現状のガイドラインの解釈が私と新幹線さんとでは異なることが分かりました。多桁の場合は、万億兆での区切り以外は、コンマ（財務分野・・・など）、スペース（科学技術分野など）で区切ることになっているというのが私の解釈です。現状の桁区切りの3分類は、2013年12月22日 (日) 06:24に私が提案したものが基になっています（[1]）が、当然に区切ることを前提に提案したものです。それ以前のノートでの議論も「区切ること」を前提にしています（ノート:表記ガイド/過去ログ2#数字の区切り","（コンマ）について　　　過去ログ3#「数字」節の改変提案　　　過去ログ9#多桁の数字の区切りを、半角スペースに）

コンマやスペースを「使ってもよい」との解釈はどこから出てくるのでしょうか？　「区切りを入れる場合には」の「場合」とは、「入れる際には」の意であって、入れない場合を許容する意味ではないです。また、「分野ごとの確立した慣習がなければ1番目の使用を推奨します。」となっていますから、（例えば）財務分野ではコンマを3桁ごとに入れるのが確立した慣習です。数学分野で小数部に5桁毎にスペースを入れるのが確立した慣習というのであればそれに従うことになるのでしょう。なお、「多桁」の解釈についての議論は後日にします。--Awaniko（会話） 2017年10月8日 (日) 16:21 (UTC)

そう書いてるから入れない場合を許容する意味になるんですよ？　新規作成 (利用者名) （会話） 2017年10月9日 (月) 02:23 (UTC)

Awanikoさんがそういう意図でガイドラインを制定したということは分かりました。しかし私が見る限り、過去の議論は必ずしも「区切ること」を前提にしているようには思えませんでした。確かにWikipedia‐ノート:表記ガイド/過去ログ2#数字の区切り","（コンマ）についての議論が開始された当時は、大きな数には3桁ごとにカンマを入れる、とだけ書かれており、当然に区切ることが前提になっています。しかし提案からすぐに、区切らない場合についても言及されています（Hatukanezumiさん 2007年10月31日 (水) 14:28 (UTC)）し、その後のWikipedia‐ノート:表記ガイド/過去ログ2#具体案でも区切らない場合を定める仮案が提示されています（4桁では区切りを入れないとか、数学記事では区切りを入れないとかの案も出ていますね）。そして、2007年11月13日 (火) 21:37 (UTC) にMicheyさんにより、早くも現在のガイドラインの骨格となる以下の文書が提案されています。

大きな数で区切りがあった方がよい場合には、次のいずれかの方法を使用する。どちらがよいかについては利用者にとって読みやすいもの、またはその分野の慣習に合ったものを選択する。

4桁ごとに「万、億、兆」などの単位語を入れる。「千」以下の単位語は入れない。またカンマは原則省略する。
例：38万4400キロメートル、80兆9123億2122万1233円

3桁ごとに区切り文字（カンマまたは半角スペース）を入れる
例：384,400キロメートル、80,912,321,221,233円

— Michey 2007年11月13日 (火) 21:37 (UTC)

これは「数学記事では区切りを入れない」（HOTUMAさん 2007年11月6日 (火) 13:41 (UTC) など）という意見も受けて提案された文書であり、「大きな数で区切りがあった方がよい場合には」が暗に「区切りがない方が良い場合もある」ということを示しているのは明白です。Wikipedia‐ノート:表記ガイド/過去ログ2#具体案3で現在の「桁の多い数に区切りを入れる場合には」に変わっていますが、これも同じ意味で書き換えただけだと思われます。

コンマやスペースを「使ってもよい」との解釈ですが、私は現在のガイドラインについて、「全分野で通用する万億兆の区切り」と「特定の分野で用いるコンマ区切りとスペース区切り」が並立していると解釈しています。そのそもこのように解釈しないと、その後の「本文と表・グラフなど、場合によっては同一記事中で併用してもよい。」という部分が意味をなさなくなります。財務・製図分野や科学技術分野であっても、図表などならともかく地の文では万億兆の区切りの方が親和性が高い場合もあるでしょう。

なお、私が懸念しているのは、{{基礎情報会社}}の売上高などの記述への影響です。かつてはコンマ区切りの記事も多かったように思いますが、今ではほとんどの記事で万億兆に統一されているように思います。表記ガイドの解釈次第では{{基礎情報会社}}を使用している多くの記事に影響します。--新幹線（会話） 2017年10月9日 (月) 03:49 (UTC)

コメントAwanikoさんの見解＜「区切りを入れる場合には」の「場合」とは、「入れる際には」の意であって、入れない場合を許容する意味ではないです＞については、私は無理な解釈だと考えます。「区切りは必ず入れる。入れないことは認めない。入れるにあたっては次の3通りのいずれかによること」とあるならば明瞭です。が、「入れる場合には・・・」という表現は「入れない場合もある」ことを想定していると考えるのが自然です。また、「推奨」は文字通り推奨止まりであって、排他的に強制するというところまでの効力はないでしょう。

新幹線さんがお示しのように、2007年に行われた議論では多数の方が参加して様々な意見が出ています。

2012年の議論（Wikipedia‐ノート:表記ガイド/過去ログ9#多桁の数字の区切りを、半角スペースに）では、排他的な一律ルールを強硬に主張するIPさんに対し、3名の方が多様な選択肢を認めるべきだとの立場で意見を述べています。

これに比べると2013年の多桁の数字の区切りでは参加者が2名、そのうち1名のCalveroさんは「大雑把で、選択の余地のあるようにしたほうがよい」という見解を示しています。この際には具体的な議論は行われていません。Awanikoさんは他者による意見表明や大きな合意形成がないまま、沈黙を合意とみなして改定に踏み切っていますよね。

このIP:220.156.65.71（会話 / 投稿記録）さんと、Awanikoさんは同一の方なのでしょうか？IPさんによる「2012年7月29日 (日) 05:07 (UTC)の提案」に対し、5日後にCalveroさんが不賛成の意を表明なさっています。が、約1年後の2013年10月24日にAwanikoさんがこれを引き継ぎ、他者の意見がないまま12月に改定を行っていますよね。それまで多くの反対意見があったものを採用するにあたって、充分な告知はなされたのでしょうか。

私は、こうした経緯で行われた改定について、強固な根拠としては扱えないと考えます。少なくとも「この改定は、区切りを入れない方法は一切認めないということですよ」という説明もなされていません。この改定の有効性を認めるとしても、Awanikoさんによる解釈は広く認められたものではないでしょう。--柒月例祭（会話） 2017年10月9日 (月) 05:20 (UTC)

コメント　2013年の多桁の数字の区切りをみる限り、『必ずしも区切りを入れる必要はないが、区切りを入れた方が良いと思われるケースにおいては、次のいずれかの区切り方を使用した方が良い』というような意味にしかとれません。

要は、『区切りを入れたいけれど、どう入れるのが適切か分からない、という人へのアドバイス』位のニュアンスですね。あの文面から『例外なく区切れ』と読み取れというのは、無理が有りますよ。

当時、十分な告知を行ったけれど明確な反対意見が無かったと主張されるので有れば、『推奨』であって『必須』ではなかったから、だと思います。そもそも、あのセクションを見る限り、Calveroさんは『修正の必要はない』という意見をお持ちだったように思えます。それに対して『具体的に修正案を』を迫る事自体、異論を認めないと言っていたようなものではないですか？

悪意が有ったとは言いませんし、むしろ、『Wikipediaをより良いものとしよう』と思っての提案、および改定だったのだと思います。ですが、イコール常に正しいとは限りません。汗顔の至りなのですが、僕自身、同様の行動原理で動いた結果、周囲に迷惑を掛けてしまった事が、何度も有ります。最近では、『2列で編集の競合を表示』の件(会話)ですね。正直なところ、貴方は僕と同じ失敗をされているように見えるのです。

そして、これまた汗顔の至りなのですが、この提案のように。あなたに取っては読みやすくする為の提案でも、実際には逆に可読性が損なわれる改悪に過ぎない『可能性』が有ります。人の事をとやかく言える立場じゃないと言われればそれまでかもですが、一度、『４桁や５桁で、区切りを入れなかった場合に起こる、具体的な不都合は存在するかどうか』を、再検討された方が良いのではないかと思います。

それでは、長文駄文、失礼しました。--ただのしかばね（会話） 2017年10月9日 (月) 16:57 (UTC)

1）表記ガイドの最初にこうあります。

記事執筆の際は、できるかぎりこのガイドラインに従うことが推奨されます。ただし、このガイドラインはすべての記事に絶対に適用しなければならないものではありません。

ガイドの最後の「その他」にもこうあります。

原則として同一項目内の表記は統一しますが、ウィキペディア全体での表記の統一には固執しないでください。異なる表記を使い分けることによって文章が伝えようとするニュアンスがより適切に表現できる場合には、ためらわずそのようにしてください。

したがって、そもそも分野によっては、又は文脈上の都合で、その他諸々の理由で、数字の別の書き方（区切りも含めて）が許容されているわけです。

2）場合のこと:

表記ガイドには、「の場合には」とか「の場合については」など、130個の「場合」の語が使われています。しかし、「区切りを入れる場合には」を「区切りを入れない場合もあってそれは許容される」と解釈できるような「場合」の使い方は、このガイドには存在しません（私の見落としがあるかも知れませんが）。もちろん「場合」の語を使う以上、「・・・する場合」と書いたら、「・・・しない場合」も想定していることは当然ですが（それが「場合」の意味です。）、「桁の多い数に区切りを入れる場合には、次のいずれかによります。」を、何らの理由や基準も示さないままに「区切りを入れなくてもいいんだよ」と積極的に解釈できるような表現振りは、このガイドの他の場所には存在しないと言うことです。したがって、＞「入れる場合には・・・」という表現は「入れない場合もある」ことを想定していると考えるのが自然です。＜　は、失当と考えます。

説明を変えると、（ア）「区切りを入れる場合には」→　入れます。　（イ）「区切りを入れない場合には」　→　入れません。　と言っているだけになってしまい、トートロジーになってしまいます。

3）ガイド本文の性格として、その規定は一意的に決めておく必要があります。それが「ガイドライン」の役割です。1）で示したいわばバスケットクローズとしての「許容規定」があるので、そのように一意的に記述できるわけです。

4）改定の経緯の如何（異議が出る・出ない・少ないなど）によって、表記ガイドの過去の記述や修正を認めないというような意見がありますが、そのような意見はガイドの規定を根本から覆すものです。修正の意見が何らの意見・異議なしに通り（その時点では通ったとしか見なせないのです。）、その修正がなされた場合もあるのですから。また「告知」云々の議論もありますが、この表記ガイドの過去の議論で告知をした例は少数でしょう。

5）ガイドの記述を更に修正すべきという議論なら歓迎します。そして、議論を明示的に提案すべきです。そうでないと更に良いガイドに育っていかないでしょう。

--Awaniko（会話） 2017年10月12日 (木) 13:52 (UTC)

1）へ：今回の提案の背景を考えると、Awanikoさんは如何なる場合でも表記ガイドに従うべきとお考えかと思いましたが、そうした考えなら少し安心しました。しかし、それならそもそも今回の提案は不要では？

2）へ：その直下に「WP:JPE#漢数字」という節がありますが、「一万円札」「百円玉」に関しては明らかに「1万円札」「100円玉」という表記も積極的に許容していると解釈するのが妥当でしょう。この時点であなたの前提は崩れます。

3）へ：いくらバスケットクローズとしての「許容規定」があったとしても、基本的に表記ガイドの内容は「推奨」と位置付けられていますから、表記ガイドを改定すると大きな影響を与えます。ですからガイドを改定するなら慎重な議論が必要です。

4）5）には特に意見はありません。--新幹線（会話） 2017年10月12日 (木) 16:28 (UTC)

2) 分かりやすく例えれば，Awaniko さんが言ってるのは，「雨が降ったら遠足は中止」と書いてあったら雨が降ることが前提になっているということです．新規作成 (利用者名) （会話） 2017年10月13日 (金) 03:33 (UTC)

2は「区切りを入れる場合には、次のいずれかによります。」として、区切りに使う表記をいくつか示しているわけですから、「区切りを入れる場合には入れます」というトートロジーではないです。

方針やガイドラインは重要な文書と位置づけられており、改定には大きな合意形成を求めています。しかし物理的には独断で修正できちゃうわけですから、文面がどういう経緯でできあがってきたかを検討することは必要です。いまのようにガイド文書の中身について議論するならなおさらです。
一般論としては、議論を提起して意見が分かれて着地点が見いだせない場合、往々にして膠着したり停滞に陥ることがあります。多くの真摯な利用者は、そういう場合は、合意を得られなかったとして諦めます。しかし時には、「いつまでも納得しない」利用者が、意見が分かれて実現しなかった案件を蒸し返したりして、「うでづくで」押し切ろうとすることもあります。反対意見があった案件を議論の停滞後に持ち出して、1週間やそこらで「誰も意見を言わなかった」といって実行しちゃうのはそういう部類の行動で、あまり感心はしません。そうしたことが行われた結果なのか、大きな合意をもって行われたことなのか、検証することは必要でしょう。ウィキペディアが過去版や過去ログを保持公開しているのはそういうことも必要だからです。あくまで一般論ですが。
そしてお示しの「ウィキペディア全体での表記の統一には固執しないでください」とある通りでしょう。--柒月例祭（会話） 2017年10月14日 (土) 16:13 (UTC)

新幹線さまへ：

＞「WP:JPE#漢数字」という節がありますが、「一万円札」「百円玉」に関しては明らかに「1万円札」「100円玉」という表記も積極的に許容していると解釈するのが妥当でしょう。この時点であなたの前提は崩れます。＜

何故ですか？　「以下の場合には、漢数字を用いることができます。」は、「数字は原則としてアラビア数字を用います。」規定の例外としての規定であって、漢数字の許容を明示しています。　したがって、私の指摘とは関係ありません。「この時点であなたの前提は崩れます。」は成り立ちません。

3）についてのご意見は、当然のことであって、これに反対している者は、この節での議論では、いないと思いますが。　--Awaniko（会話） 2017年10月22日 (日) 15:56 (UTC)

接尾辞について[編集]

仮名の節の接尾辞について書かれている部分では、「新鮮味→新鮮み」という例が挙げられていますが、一方で「漢字1字の接尾語で音読みのものは例外」とも記述されており、味（ミ）が音読みである以上、矛盾しているように感じます。これは単純なミスとして除去しても良いのでしょうか？--おせろん（会話） 2017年12月4日 (月) 14:56 (UTC)

その接尾辞の「み」は、元来は平仮名表記で「味」という字を当てる場合もある、という種類の接尾辞なので、元来は平仮名表記という立場からすれば「漢字1字の接尾語で音読みのものは例外」の範疇外ということになると思います。例えばパブリックドメインになっている1936年発行の平凡社の大辞典では、接尾辞の「み」は（ミ　み）として収録しており[2]、対称的に接尾辞の「め」は（メ　目）として収録しております[3]。だから、「本来の意味がほとんど失われているもの」というよりは、「本来の意味ではないもの」というべき例でしょうね。混乱を招く例なのでとりあえず除去でいいと思います。--Yapparina（会話） 2017年12月4日 (月) 16:10 (UTC)

なるほど、そうでしたか。こちらの勉強不足だったようで、お恥ずかしい限りです。ただ、混乱を招くことに変わりはないですし、Yapparinaさんのご賛同も得られていますので、新鮮味については除去したいと思います。--おせろん（会話） 2017年12月7日 (木) 08:14 (UTC)

断定の助動詞の終止形「だ」について[編集]

本表記ガイドでは、本文項目は『常体（……である、……だ）で統一します。』としていますが、これだけだと（つまり、「だ・である調」を使いなさい、とするだけだと、文末の断定助動詞に「～だ」が許容される事となり（例：「ウィキペディア（英: Wikipedia）は、～～～インターネット百科事典だ。」とする事ができる事になってしまいます。論文とか百科事典とか公式文書などは（政治・演説・プロパガンダ等の分野を除き）その殆どが、（１）「だ」を全く使わず「である」に置き換える（活用形も含む）、あるいは（２）文末に「だ」（終止形）が来る場合には「である」に置き換え、文末以外では「だ」「である」両用とする（活用形も含む）。とするのが不文律であるような気がしてならないのですが、如何でしょうか。--Willpo（会話） 2017年12月17日 (日) 16:00 (UTC)

そうですね。ウィキペディアでも、紙の百科事典（世界大百科事典、日本大百科全書、ブリタニカ国際大百科事典）でも、ダ調は使われませんから、基本はデアル調ということで修正しておきました。--Hisagi（会話） 2018年1月30日 (火) 14:52 (UTC)

交ぜ書きについて[編集]

WP:KANA#交ぜ書きには

JIS X 0208:1997の第一水準・第二水準外の漢字は、交ぜ書きとし、正しい文字がどのような字体か説明します。

とありますが、Unicodeに収録されている漢字は原則として全て交ぜ書きしないことを提案します。理由は

WikipediaはUnicode(UTF-8)で書かれているため、技術的な問題が無い
漢字を記載せずに漢字の字体だけを説明するのは読者にとってわかりにくい
多くの環境で文字化けするような漢字であっても、字体の説明を併記すれば問題ない
実際、このルールは守られておらず、形骸化している(項目名では守られているが、項目名に関しては別規定があるので表記ガイドの対象外)

「IBM拡張文字を含む人名も、交ぜ書きで対応します。」も同様の理由で削除することを提案します。 Unicodeにドラフトとして収録されているが正式に収録されていない漢字はUnicodeに収録されていない漢字としてみなすことも併せて提案します。--210.148.125.94 2018年1月7日 (日) 14:45 (UTC)

箇条書きの句点について[編集]

報告 Wikipedia:表記ガイド#句点の「箇条書きの最後にも句点を打ちます。ただし、名詞だけを列挙する場合を除きます」というガイドラインの意味を明確にしてください。

利用者:Anax（会話 / 投稿記録）さんという方が、このガイドラインを杓子定規に受け取って箇条書きから句点を除去しています。

プロジェクト:テレビドラマ#キャストの表示方法の定義の箇条書きでは、たとえ名詞であっても後ろに文が続くと予想される場合、句点を打つことになっていますし、プロジェクト:芸能人#スタイルテンプレートでもごく短い箇条書きに句点を打つことになっています。Wikipedia:方針とガイドライン#内容によれば、ガイドラインは相互に矛盾してはならないことになっており、どのような意味で「名詞だけを列挙する場合を除きます」と述べているのかを明確にしてください。--221.118.217.31 2018年3月24日 (土) 17:58 (UTC)

名詞だけの場合は句点はなくても良いという意味ですよね。普通に読めば。それで何か不都合がありますか？
《たとえ名詞であっても後ろに文が続くと予想される場合》は当然「名詞だけ」ではないので、ガイドラインにある記述『箇条書きの最後にも句点を打ちます』に従えばよいだけですよね。--iwaim（会話） 2018年3月24日 (土) 18:18 (UTC)

テレビにおける時刻表記について提案[編集]

提案以前福島中央テレビ#主な番組にて「時」「分」「秒」を「:」（以下、半角コロン）に置き換えたところWikipedia:表記ガイド#年月日・時間に従って戻されました。表記ガイドによると表になっていない場合「時刻の表し方には「時」「分」「秒」を用います」とありますが、テレビ局の欄（例・岩手めんこいテレビ#現在放送中の主なテレビ番組）には表ではなくとも主に半角コロンを使うことが多いです。こういう特殊な場合も見やすいように半角コロンを使えるようにすればどうでしょうか?--おわさか（会話） 2018年5月17日 (木) 03:58 (UTC)

コメント 現状の「ただし、表の中に記述する場合に限り、慣例的に「:」（半角コロン）を用いる分野の場合や横幅を減らすために、それを用いることを妨げません。」の前文を削った「慣例的に「:」（半角コロン）を用いる分野の場合や横幅を減らすために、それを用いることを妨げません。」に改正して、表でない場合でも「:」（半角コロン）を用いることができるようになることに賛成します。理由として現状の運用では表である場合と表でない場合で表記を区別しなければならず編集を行う利用者が混乱してしまうこと、そして、放送局の記事を見ていても時刻表記は表でなくても「時」「分」「秒」ではなく「:」（半角コロン）であることが大多数です。「時」「分」「秒」を今でも用いている放送局は日本国内では利用者‐会話:おわさか#放送時間表記についてで注意を行ったKatuii7さんの地元放送局であるNHK福島放送局、福島中央テレビ、福島放送、テレビユー福島、福島テレビ、ラジオ福島と兵庫県のラジオ関西の7局しかありません。注意を行ったKatuii7さんの編集を見ていますとほぼ毎日のように福島県内の放送局の記事で細かい編集を行っているため、Wikipedia:記事の所有権にある単独の編集者による私有化に抵触していると思います。--116.220.82.167 2018年5月17日 (木) 13:43 (UTC)

反対その改正には反対です。「理由として現状の運用では表である場合と表でない場合で表記を区別しなければならず」というのは時刻表示に限らず単位系はすべてそうです（使い分けるのが面倒なら表内でも「○時○分○秒」で統一すれば書式の使い分けは必要ありません、表内で単位記号を使うかどうかは強制でなくあくまで任意です）。SI系も含めて文書中では原則単位記号は使わないことになっていますので、SI系単位より優先してコロンの時刻表示だけ例外化する必然性は乏しいといえます。

百科事典という当コンテンツの性質上、日本語の文章表現としてもフォーマルな書式とは言い難いですし、実用面でもスラッシュを使った日付表記やコロンを使った時間表記は音声リーダーなどではほぼ正しく読み上げられませんので推奨できません。--ディー・エム（会話） 2018年5月17日 (木) 14:27 (UTC)

コメント ただ、相当の記事が半角コロンを使用しており、これを改正するのには相当な時間がかかると思います。--おわさか（会話） 2018年5月22日 (火) 08:24 (UTC)
- 返信 1記事を改善するのにさほど長時間を要するとは思えません。より理想に近い記事が1記事でも増やせる可能性のある選択肢は、それを阻害する選択肢よりもベターです。--ディー・エム（会話） 2018年5月23日 (水) 09:22 (UTC)
  - 返信それだったら放送番組の節で放送時間のあるところはまるごと表に書き換えればいいと思います。大体が表になっているため、そちらの方が良いと思います。--116.220.82.167 2018年6月5日 (火) 05:29 (UTC)
    - コメント 何でもかんでも表形式にすれば良いというものではないでしょう。放送番組の節だけにその表記が収まっているわけでもないですし。--Don-hide（会話） 2018年6月5日 (火) 07:59 (UTC)

人物記事における存命期間の括弧表記について[編集]

秋元春朝の記事における存命期間の括弧を本記事の括弧の入れ子節に従って修正したのですが、Wikipedia:スタイルマニュアル (人物伝)の例節では括弧を入れ子にしていないからか、差し戻しが発生してしまいました。こういう場合は本記事に従うべきかスタイルマニュアルに従うべきか迷う人が私以外にもいるかもしれませんので、後者なら本記事の括弧の入れ子節に「人物記事における存命期間は除く」などと追加していただけると助かります。--220.213.91.171 2018年6月9日 (土) 10:56 (UTC)

なるほど、確かにWP:QUOTATION（Wikipedia:表記ガイド#括弧の入れ子）では次のように指示がありますね。

括弧の入れ子は、次のようにします。
- 丸括弧類については、[ (〈〉) ] の順で入れ子にします。

私もこれは知りませんでした。なので（XXXX年（平成YY年） - XXXX年（平成YY年））というふうにしています。まあ、「ちょっと見目麗しくはないな」とは感じていましたが。）

ウィキペディアの全体的な慣行からすると、表記ガイドの入れ子の指定のほうが実情にそぐわないという感じもしますが、どうでしょうね。要検討でしょうか。--柒月例祭（会話） 2018年6月9日 (土) 11:45 (UTC)

「実情にそぐわない」というよりはWikipedia:スタイルマニュアル (人物伝)のほうで、例として「天文11年12月26日（1543年1月31日）」という表記をしていますね。なので、単純にWikipedia:表記ガイド#括弧の入れ子に追記を行えば解決しそうですね。--柒月例祭（会話） 2018年6月9日 (土) 11:49 (UTC)

記事本文中の疑問符・感嘆符について[編集]

『全角・半角のどちらを使うかは直前の文字に従います。ただし、記事名に使う場合は、常に半角を使用します。』となっています。例えば記事「あなたが泣くまで踏むのをやめない!」は記事名として半角が使われているのは正しいが、記事の冒頭で「『あなたが泣くまで踏むのをやめない!』（あなたがなくまでふむのをやめない!）は著者・御影瑛路、イラスト・nyanyaのライトノベル。」とあるのは「『あなたが泣くまで踏むのをやめない！』（あなたがなくまでふむのをやめない！）は著者・御影瑛路、イラスト・nyanyaのライトノベル。」のように全角に変更すべきなのでしょうか。かなり違和感があるのですが。--アルビレオ（会話） 2018年7月18日 (水) 08:45 (UTC)

私のほうからも気になった個所を1つ報告しておきます。カードキャプターさくら#特典アニメ (クロウカード編 / さくらカード編)の箇条書き部分について、もしも表記ガイドの感嘆符を厳密に適用するなら

（略）知世のカードキャプターさくら活躍ビデオ日記！（←全角）
（略）知世のカードキャプターさくら活躍ビデオ日記スペシャル！（←全角）
（略）知世のカードキャプターさくら活躍ビデオ日記2! （←半角）

となってしまいます（長いので冠タイトルは略）。ここでの感嘆符は同じシリーズのタイトル共通部分なのに、数字が入るか否かで全半角が異なってしまいます。そのほうがよっぽど違和感あるのですが。

ついでに言うと略した冠タイトル部分にも全角感嘆符があるので、同じタイトル内で全半角が混在するということにもなってしまいます。--Gwano（会話） 2018年7月19日 (木) 09:36 (UTC)

挙例されているケースに限って私論を言えば、つまり自分ならどうするかと言えば、

「『あなたが泣くまで踏むのをやめない!』（あなたがなくまでふむのをやめない）は著者・御影瑛路、イラスト・nyanyaのライトノベル。」

となります。記事中の記述の一部であっても「あなたが泣くまで踏むのをやめない!」は「記事名」と考えられるので、半角の方が良いと思うからです。（もちろん、原則に沿って全角にすべきという考えがあっても不思議はないと思いますし、そこで揉めるのは愚かしいと思います。）また、読みに「！」を入れるのは、全角・半角を問わずナンセンスでしょう。

カードキャプターさくらのケースでは、確かに全角の方が自然でしょうね。おそらく現状の記述をした方も「Wikipedia:ルールすべてを無視しなさい」にある「もしも、ウィキペディアの改善や維持をしようとするときに、いまあるルールが邪魔になるのなら...」という状況に当たると思われたのだと思いますし、そのままにしておいて良いのではないでしょうか。--山田晴通（会話） 2018年7月20日 (金) 06:03 (UTC)

コメント 第1文の主題（主語）に関しては、前出のご意見とほぼ同じになりますが、私も、「記事名」は、記事中のどこに書かれていても、「記事名」であることに変わりはないと考えますので、「あなたが泣くまで踏むのをやめない!」が記事名であれば、第1文の主語でも、既刊一覧でも、「あなたが泣くまで踏むのをやめない!」の半角感嘆符で統一するのが、Wikipedia:表記ガイドの「ただし、記事名に使う場合は、常に半角を使用します」に沿った方法になると思います。また、読みの部分では、私も感嘆符は入れる必要はないと思います。

カードキャプターさくらの件に関しては、第2弾、第3弾などを表す数字は、通例では、その言葉の末尾に付けますので、感嘆符が末尾にある場合、「＊＊＊！2」「＊＊＊！3」のようになり、＊が全角であれば、（記事名でない限り）感嘆符は全角で統一され、「全角半角問題」は起きないはずです。

今回の購入特典のタイトルは、「～2!」と、感嘆符の前に「2」が入っています。こういった例はレアなケースと言って良いかと思います。通常の日本語では、「～ビデオ日記！2」となるはずです。では、なぜこのような例外的なことが起きているのかと考えますと、おそらくこの特典の制作スタッフは、「スペシャル」や「2」を強調したかった、あるいは、そのほうがタイトルとして座りが良いと思ったのでしょう。つまり、「2」を強調したいために「～2!」とした、と考えれば違和感は薄くなるかと思うのですが、いかがでしょうか。

ですので、基本的には、「～2!」の部分の感嘆符は半角にすることが、Wikipedia:表記ガイドに従うことになる、というのが、私の意見です。

ただし、Wikipedia:表記ガイドの冒頭に、

「このガイドラインはすべての記事に絶対に適用しなければならないものではありません。ここに掲載されている表記法と異なる表記を分野ごと、記事ごとに使用する場合、関連分野のウィキポータル・ウィキプロジェクトや、個別記事のノートで合意形成をし、合意事項をわかりやすい形でまとめておくとよいでしょう」

とありますし、今回のカードキャプターさくらのケースは、例外的なものでもありますので、もし意見が分かれるような場合は、ノートで議論をして合意形成をすれば、「～2!」の部分の感嘆符は全角でも問題ないでしょう。--Gtorew（会話） 2018年7月21日 (土) 03:09 (UTC)

コメント 例示されている「あなたが泣くまで踏むのをやめない!」については電撃文庫公式サイトで半角の感嘆符が使われているのでこのままでもよいと思います。全角にすることを否定もしませんが。なお、同じ電撃文庫の作品である「とらドラ!」では記事の冒頭にわざわざ全角の感嘆符を使用することの告知がされています。--雛鳥(Hinadori) 2018年7月28日 (土) 04:10 (UTC)

人名の敬称付記慣習についてのコメント依頼[編集]

プロジェクト‐ノート:神道#貴人記事の項目名変更の提案において、人名の敬称付記について議論が行われております。古代人物の「ミコト（命・尊）」号は敬称に相当するので除去が妥当という論旨です。しかし市販の事典類では、例えば大彦命の場合、

『世界大百科事典』（平凡社）：大彦命
『国史大辞典』（吉川弘文館）：大彦命
『日本国語大辞典』（小学館）：大彦命・大毘古命
『日本人名大辞典』（講談社）：大彦命
『ブリタニカ国際大百科事典小項目事典』：大彦命
『大辞林』（三省堂）：大彦命
『日本古代史大辞典』（大和書房）：大彦命
『日本古代氏族人名辞典普及版』（吉川弘文館）：大彦命

とミコト付記で表記されており、Wikipedia:表記ガイド#人名の敬称に関する「付けることが慣習となっているものまで付けてはいけないということではありません」という定めに沿わないという意見が私ほかから出ています。これに対して議論提起者からは「敬称付記の文献が多いという事実から、それが慣習となっているという結論を導き出すのはWikipedia編集者の独断ですることではありません」というコメントが出されました。上記のような文献例の提示だけでは「慣習」であることの証左と出来ないのかどうか、この場で皆様から客観的コメントを頂けますと幸いです。--Saigen Jiro（会話） 2018年7月18日 (水) 23:42 (UTC)

　「Wikipedia:記事名の付け方」には「認知度が高い」ことが基準の一つとしてあげられています。「ヤマトタケル」のように「ミコト」を省略した表記が一般的に使用されているのであれば、記事名に「ミコト」をつけなくてもよいでしょう。しかし、敬称まで含めた表記が一般的である場合、敬称を付けない表記が使用されていない場合は敬称を記事名に含めるべきです。例えば、日本の天皇の記事名は「○○天皇」となっていますし、日本以外の人物記事でも「アーサー王」「光武帝」などで「○○王」「○○帝」という記事名が使用されています。Wikipediaでは原則として加筆や変更を希望する利用者が根拠となる出典を用意する必要があります（WP:BURDEN）。「大彦命」の「ミコト」を除去すべきと主張するのであれば、単に「オオヒコ」「大彦」などと表記している出典を用意すべきです。また、「敬称をつけない」というのは単に「百科事典として「です」「ます」や「～氏」「～陛下」などの表現は不適切」というだけで、「ミコト」などのように名前に付けるのが一般的なものまで無差別に除去すべきではありません。「大彦命」の「ミコト」を除去すべきという主張は「表記ガイド」の一部だけを抜き出したものであり、Wikipediaで「ルールの悪用」、「法律家ごっこ」と呼ばれる行為に該当しているように思われます。--SilverSpeech（会話） 2018年7月19日 (木) 01:05 (UTC)
SilverSpeechさんに同じく、項目名にはWikipedia:記事名の付け方のガイドラインがありますから、使われている出典があるだけでなく認知度が高い呼称、正式名称などが適しています。中立的な観点に従って、多数派の呼称に比重を大きく置き、少数派の呼称があれば分かりやすく例外的なものであることを示す必要もあります。多数の百科事典に確認できるのであれば、記事名のつけ方の、信頼できる情報源に確認できること、認知度が高いなどを満たします。

ガイドラインの上位であるWikipedia:中立的な観点の方針に従えば、一律機械的にしてしまうと、事典などに確認できる多数派の観点を押しのけて少数派の観点の記事名が採用されてしまうので、プロジェクト:神道のルールが方針違反、ガイドライン違反となっているという点で、ルールの修正も考慮してもいいのではと思います。

方針やガイドラインの方が、プロジェクトルールの後に明文化されている場合もありますから、ガイドラインなどが成立した今となっては古くなったプロジェクトのルールを改定するという形です。--タバコはマーダー（会話） 2018年7月19日 (木) 04:09 (UTC)

コメント 「PJ神道のルールが方針違反・ガイドライン違反」というご指摘についてです。PJ神道のルールは、方針違反ではなく、方針に沿ったものであると考えます。ご指摘のように、大方針は「認知度が高い」などのWikipedia:記事名の付け方の定めの通りです。

ところが神道分野では、同一の神が『日本書紀』と『古事記』で異なる漢字表記が行われるというのがほとんどです。（例：伊弉諾（日本書紀）- 伊邪那岐（古事記）- イザナギ）

信頼できる情報源も、どちらをベースにするかによって分かれ、「有意な多数派」が定め難い。そのため日本書紀式か、古事記式か、どちらか一方の表記を「認知度が高い」と決めにくいという事情があります。カタカナ書きを採用すると、こうした漢字表記の表記ゆれから解放されますし、実際にカタカナ書きを採用している信頼できる情報源も多数みられます。こうした事情で、「日本書紀式」「古事記式」「カタカナ式」の3種類のうち、基本則としてはカタカナ書きを採用しましょう、というものです。これは「認知度が高い」に反するものでもないですし、「中立性」にも寄与する（日本書紀と古事記のいずれか一方を重視するのを回避する）ものです。

つまり、これらPJ神道の細則は、信頼できる情報源の表記にしたがうものです。「多数派」が1系統ではなく3系統に収束するため、そのうち1系統（カタカナ）を基本とする（首尾一貫性）というものです。

あくまでも基本則であり、カタカナ書きでない漢字表記が有意に収束するような場合には、漢字表記も行われています。（例：天照大神、大国主）--柒月例祭（会話） 2018年7月19日 (木) 05:11 (UTC)

私個人としては、現在のPJ神道のルール自体には問題ないと考えます。表記ゆれの回避などを目的として「カタカナ表記・神号なし」を優先するのは百科事典として合理的なルールかと思いますし、「天照大神」のように漢字表記が安定しているものはカタカナ表記の利点よりも漢字表記の利便性の方が大きそうです。一方、「一律ミコトを除去した表記で統一する」のは書式統一のメリットよりも利用者の混乱を招くなどのデメリットの方が大きいように思われます。例えば、「倭彦命」と「倭彦王」は「ミコト」表記を禁止するとますます記事名が混同されやすくなってしまいますし、敬称の有無を統一していないのは中立的でないというならば「ミコト表記はNGで王表記はOK」というのも筋が通らないのではないでしょうか。WP:NOTLAWの観点から言えば、百科事典として十分な合理的理由が示されていない統一ルールを定める必要はないかと思います。--SilverSpeech（会話） 2018年7月19日 (木) 07:57 (UTC)

ミコト除去の提案者です。「光武帝」などの「帝」は肩書・敬称の枠を超え、諡号の一部として扱われますのでミコトとは異質のものです。『「～氏」「～陛下」などの表現は不適切」』とおっしゃいましたが、ミコトはこれらとまったく同質です。これを「付けるのが一般的」と安易に判断し、不統一に付記してよいのでしょうか。それに、たとえばヤマトタケルの例をとると、事典類での表記はほとんど「日本武尊」であるにもかかわらず、記事名はミコトを除いています。これはミコトが省略可能とする証拠に他ならず、これが他記事に通用しない理由はありません。

ヤマトヒコについては、Otherusesで対応すれば良い話です。混乱をまねくのならそれは命名者（伝承時代の人）の責任です。ちなみに「王表記はOK」とする根拠は、以前の合意によっています（Wikipedia‐ノート:記事名の付け方/日本の皇族#Wikipedia-日本の皇族の記事名に関する合意事項）。王は身位であり、厳密な敬称とは少し違います。これに対し、ミコトは完全な敬称であり、除去が妥当と考えられます。--Aitok I（会話） 2018年7月19日 (木) 13:08 (UTC)

引き合いに出されているヤマトタケルについては、記事名について個別具体的に議論が行われています。これを参照すると「事典類での表記はほとんど「日本武尊」である」というのは正しくないです。辞書類では様々な表記がみられること、論文ではヤマトタケルが多数派であることなどが示されています。いずれにせよ記事名は個別的に議論が行われて定まったものです。これがこうなんだからあっちもそうなんだろ、のように用いるべき事例ではないです。ノート:ヤマトタケル/過去ログ1参照。

このなかで、利用者:胡亂堂さんという方が、「本記事対象に直近する政府刊行物（公文書）でもある『日本書紀』での「日本武尊」が正式名称だ」などの主張を行い、「日本武尊」への改名を主張しました。が、他の利用者から、実際には各種辞典・論文類での表記はさまざまであること、実際の用例としてヤマトタケルが多数あること、PJ神道のルールに適合しており、カタカナ表記が中立的であることなどの反対意見があり、改名の合意に至りませんでした。（提案者は主張が通らなくて憤ったのでしょう、さいごに相手方に対して一方的に「致命的にどーしようもない説明」「どーでもいー論拠」などと棄て台詞を残しています。）--柒月例祭（会話） 2018年7月20日 (金) 03:19 (UTC)

情報ありがとうございます。事典類の表記が多様であること、承知しました。最近宗教分野を中心に片仮名表記が増えてきているようですね。先の発言は撤回します。

しかし、日本武尊の件でミコトが入っていないことには2つの理由があろうかと思います。

第一は、『日本書紀』『古事記』間の表記の揺れ（尊と命）。

第二は、神道プロジェクトに規定される「神」とみなした場合、ミコトは外す決まりであること。

以上の二点を見ると、『古事記』に記載がある人名は全て片仮名ミコトなしにするべきであるようにも思えます。参考までに認知度を調べてみます。たとえば手研耳命の例をCiNiiで全文検索すると、

タギシミミ：26件（うちノミコト付き3件）
手研耳（紀）：17件（うち命付き15件）
当芸志美美および当芸志美々（記）：28件（うち命付き15件）

と表記は多様で、最多は「タギシミミ」です。

豊城入彦命の例を検索すると、

トヨキイリヒコおよびトヨキイリビコ：2件（うちノミコト付記1件）
豊城入彦（紀）：28件（うち命付記25件）
豊城入日子（記）：0件

最多は「豊城入彦命」です。

以上からわかるように、文献にはミコト付記・不記、片仮名・書紀表記・古事記表記の別に、対象によりかなり違いがあることがわかります。

もしここから記事名を決めるとなれば、Wikipediaの記事名は記事ごとに表記がバラバラで、非常に不統一な感を呈せざるを得ません。これらの文献の表記の差を、それぞれの編集方針の差と受け取り、WikipediaではWikipediaの編集方針（敬称不記）にしたがうべきではないでしょうか。--Aitok I（会話） 2018年7月20日 (金) 06:06 (UTC)

返信なんども繰り返しご案内していることですが、手研耳命にせよ、豊城入彦命にせよ、個別の記事ごとに個別具体的な根拠となる文献を示し、改名を検討するということについては、多くの方が反対していません。むしろ賛同しています。ですが、現実世界の多様性を無視して、Wikipediaで独自のルールを定め、それに合わないとか統一感がないなどの形式的・WP:BURO的判断で、一律的・機械的に物事を処理しようという考え方が否定されているのです。

CiNiiの検索結果は根拠の一つになりえますが、唯一無二のものではないでしょう。しかしそこで多様性が見られるならば、それはまさにWikipediaでも多様さを反映すべきなのです。

※お示しの事例の場合、手研耳命ではカタカナ：紀：記の比率が26:17:28なわけでしょう。これはもうどうみても、「いずれかの表記に有意に収束している」とはいえませんよね。ヒジョーに大雑把にいって3：2：3ぐらいの比率なのですから、分かれているというほかないでしょう。これに較べると豊城入彦命は有意に収束しているといえますね。

※これはもう枝葉の部類になりますが、豊城入彦命の例では、「豊城入日子（記）」でなくて「豊木入日子」で検索すると1件ヒットしますよ。

記事ごとに表記がバラバラなのは、現実世界における文献の表記が多様であるからです。もちろんたしかに、Wikipedia史的には、かつてはそこまで出典が重視されていなかったり、記事作成者がいろいろな立場・知見の人々であったために、いくらか混乱があるということもあるでしょう。ですがそれは個別的に検討して解決していくことです。

たしかにこの一連の記事主題の場合には、「神」とみるか「人」とみるか、実在の歴史上の人物なのか空想上の説話上の人物なのか、完全に線を引く事はむずかしいでしょう。参照する文献や著者によっても違うかもしれません。だからこそ多様性が見られるのでしょう。

「非常に不統一な感」などというAitok Iさんの個人的な美意識を満足させるために、現実の情報源を無視したり、他利用者の見解を退けたり、原則ではない枝葉の規則だけを振りかざして本則を見失うようなことは、Wikipediaの考え方にそぐわないものでしょう。--柒月例祭（会話） 2018年7月20日 (金) 13:09 (UTC)

コメント 上記の㭍月例祭さんの見解を支持いたします。「個人的な美意識を満足させるため」とは本案件を極めて的確に捉えたワードだと認識します。--Saigen Jiro（会話） 2018年7月20日 (金) 13:52 (UTC)

すみません、『古事記』では「城」ではなく「木」でした。私のミスです。誤表記が0件なのは当たり前ですね。

もちろんCiNiiは参考情報です。記事名決定の唯一の根拠にはなりません。

「Wikipediaで多様性を反映」したならば、いったいどのような記事名が適当なのでしょうか。もし「個別的に検討」するならば、厳密な意味で中立なのは片仮名表記のみということになりかねません。しかし、ここで表記の妥当性について議論するつもりはないので、これ以上は述べません。

本題はミコトです。これに関しては、付記・不付記の二択です。折衷案はありません。ミコトが省略可能というのは上に述べた通りですが、省略する例が存在する以上は、中立性を損なう敬称を強いて付記する必要は無いと思います。敬称の付記・不付記は、文献多数決で決めるものではありません。

本案件は、私の個人的美意識によるものではありません。「不統一」という状態は、WP:CRITERIAの首尾一貫しているに明確に違反しております。--Aitok I（会話） 2018年7月20日 (金) 14:22 (UTC)

返信 WP:CRITERIAの箇条書き以外の部分は読まれましたか？　Aitok Iさんは「首尾一貫している」を根拠としていますが、反対意見の中で使用されている「認知度が高い」もWP:CRITERIAの基準です。このようなケースの場合は他の方針やガイドライン、信頼できる情報源、百科事典としての観点などを根拠に議論して決めるべきです。「中立性を損なう敬称」という意見ですが、Wikipediaにはこのような意見の裏付けとなる方針やガイドラインはありません。表記ガイドは「敬称の使用を全て禁止する」ものではありませんし、WP:POVはあくまでも1つの記事の中での話であって「他の記事と平等に扱う」といった意味合いはありません。また、WP:CRITERIAには専門家よりも一般人の関心を重視するように書かれていますが、「ミコト抜き表記で統一」した場合にはこの記述に明確に違反する事例が発生するかと思われます。付け加えますと、私個人としては「神号の中でミコト表記だけ禁止する」というのは「首尾一貫している」とは言えないように感じます。--SilverSpeech（会話） 2018年7月21日 (土) 03:09 (UTC)

返信百科事典は特定の人物に敬称をつけるべきではないと申しているのです。敬称を入れなければ固有名詞として成り立たないという場合でない限り、無敬称で統一すべきでしょう。

ミコトは必ずしも神号ではありません。それに、他の信神号と違い明確な敬称です。他の神号に敬称にあたるものがあるなら、それも除くべきでしょう。

「一般人の関心」とはどのようなものでしょうか。たとえば「ヤマトタケル」より「ヤマトタケルノミコト」のほうが関心が高いとでもおっしゃるのでしょうか。--Aitok I（会話） 2018年7月21日 (土) 12:09 (UTC)（修正）--Aitok I（会話） 2018年7月24日 (火) 17:58 (UTC)

提案コメント依頼から相当期間が超過し、プロジェクト‐ノート:神道#貴人記事の項目名変更の提案と重複する部分もある関係でこちらでの意見は出揃った感がありますが、あくまでもこちらでの議論（ガイドライン上の議論）としては、

「Wikipedia:表記ガイド」・「Wikipedia:記事名の付け方」での敬称不記の文言は本案件（ミコト除去）の絶対的理由にはならない
「Wikipedia:記事名の付け方」の基準である「認知度が高い・見つけやすい・曖昧でない・簡潔・首尾一貫している」は、上記の敬称不記の文言の上位に位置する

という主旨でAitok Iさん以外は合意が取れているとしてよろしいでしょうか。異存がある場合や、他に合意が取れている事項がある場合にはご意見願います。--Saigen Jiro（会話） 2018年7月29日 (日) 11:49 (UTC)

一つ目については賛成です。個別に除去が適当であることを証明する必要があるというのは、PJ神道の議論でもすでに書いております。

二つ目については、完全に納得はしかねます。たとえば「憲法と法律に矛盾がある場合は憲法を優先する」というのは明らかに正しいですが、現在は「記事名の付け方」に両基準が矛盾した場合の対処については記載されておりません。よって、どちらを実際に上位として扱うべきかは容易に判断できません。私としては、具体的規則である敬称不記を優先すべきと思います。--Aitok I（会話） 2018年7月29日 (日) 14:05 (UTC)

1点目に関しては論旨を変えられたのですね。では相当期間待って異論が出なければ、全会一致の合意形成といたします。2点目に関しては、この議論でそういう主張をなさったのはAitok Iさんだけのように思うので今確認しているのですが、その確認次第かと存じます。--Saigen Jiro（会話） 2018年7月29日 (日) 22:13 (UTC)

返信（Saigen Jiroさんへ）1点目、2点目ともOKです。--柒月例祭（会話） 2018年7月30日 (月) 02:44 (UTC)

返信（Saigen Jiroさんへ）二点目はWikipedia:記事名の付け方のノートで議論するべきことですので、ここでの合意をもってガイドラインの解釈と位置づけるのは不可能であると考えられます。--Aitok I（会話） 2018年7月30日 (月) 10:41 (UTC)

合意形成というか至極当然のことを確認しているだけですので、お気遣いなく。Wikipedia‐ノート:記事名の付け方においても当該議論は告知しております。--Saigen Jiro（会話） 2018年7月30日 (月) 10:56 (UTC)

本当に「至極当然」であるならば、確認する必要はないようにも思いますが。

告知内容を見ましたが、規定の優先度関連については書かれていないようですので、告知不十分ということになるかもしれません。--Aitok I（会話） 2018年7月30日 (月) 11:08 (UTC)

誰のせいかと。--Saigen Jiro（会話） 2018年7月30日 (月) 11:17 (UTC)

コメント ひろく一般的な話をしておくと、記事名というのは、そんなに重要ではないんですよ。重要なのは記事の中身です。今回は私にも責任の何割かはあるのですが、記事名に関する議論が記事本文よりも長大である、というのはちょっと非生産的でして、その時間や労力は記事の充実にあてるべきでしょう。記事名の候補としてそこそこの妥当性を有するものがいくつかあるなら、そのどれかにサクッと決めてしまって、あとは記事本文に注力するのがいいのです。そこそこの妥当性があるものとして定まった記事名をひっくり返そうとするなら、それに値する十分すぎるぐらいの根拠を示し、多くによる合意形成がスムーズに実現するならよいのですが、スムーズにいかないならサクッと諦める、というほうがいいと思いますよ。--柒月例祭（会話） 2018年7月30日 (月) 12:03 (UTC)

記事より議論が長いページなら多くの例があります。記事改善のための議論は「非生産的」とはいえないと思います。

Wikipediaには歴史がありますので、過去に「そこそこの妥当性がある」とされた記事名が、現在は最良のものと考えられないものは多くあります。労力をおしまず改名したほうが、百科事典として高品質になる可能性は高いです。

柒月例祭さんのおっしゃる「ひろく一般的な話」は必ずしもWikipedia編集者の共通認識ではないことにご留意いただければ幸いです。--Aitok I（会話） 2018年7月30日 (月) 13:50 (UTC)

情報当該議論に関連してWikipedia:コメント依頼/Aitok Iが提出されております。--Saigen Jiro（会話） 2018年7月31日 (火) 11:25 (UTC)

終了異論が出ませんでしたので、7月29日の提案案件としては1点目・2点目ともAitok Iさん以外は合意が取れていると認識いたしました。また当該議論の中心的編集者であるAitok Iさんが無期限投稿ブロックになられ、当該議論はこれ以上の進行が望めない状況ですので、議論終了といたします。皆様ご意見ありがとうございました。--Saigen Jiro（会話） 2018年8月22日 (水) 16:16 (UTC)

感嘆符と疑問符の全角・半角[編集]

先行議論は利用者‐会話:アテラストーリ#表記ガイドです。[[若おかみは小学生!|若おかみは小学生！]]のような全角表記が適切かどうか、わからなくなってきました。Wikipedia:表記ガイド#疑問符・感嘆符を解釈します。

「文末の句点（。）のかわりに「？」（疑問符・耳だれ）や、「！」（感嘆符・雨だれ）を使わないでください。」：A

「固有名詞や引用文や記事名に使われている場合は使用できます。」：B
「全角・半角のどちらを使うかは直前の文字に従います。ただし、記事名に使う場合は、常に半角を使用します。」：C

Cで記事名は半角と決めている。よってBの「記事名に使われている場合は使用できます。」が全角を指すと矛盾してしまうので、これは全角・半角問わず「?」や「!」自体を指している。同様に「固有名詞」で使用できるのは、全角・半角問わず「?」や「!」となる。

となると、記事名を記述する場合は、「記事名に使う場合は、常に半角を使用します。」「全角・半角のどちらを使うかは直前の文字に従います。」のどちらが優先されるか、という話になります。

「記事名に使う場合は、常に半角を使用します。」が優先されるのであれば、「若おかみは小学生!」となります。記事化されていない場合は、「全角・半角のどちらを使うかは直前の文字に従います。」となり、記事の存在有無によって表記が変わってしまいます。

「全角・半角のどちらを使うかは直前の文字に従います。」が優先されるのであれば、リンクは全てこのようなパイプ付きリンク（[[若おかみは小学生!|若おかみは小学生！]]）になり、作業とバイト数がムダに思えます。また、英数字の扱いと矛盾します（もし「若おかみは小学生A」や「若おかみは小学生2」という作品があれば、この場合の英数字は必ず半角になります）。

どちらと考えるべきなのか、また表記ガイドに修正が必要なのか、御意見を頂ければ幸いです。--JapaneseA（会話） 2018年10月3日 (水) 16:20 (UTC)

議論の原因となったようなのでコメントします。私の判断は「記事名の半角はシステム上のルール」であり、「文中で使用する際は『直前の文字に従う』」だと考えています。記事の存在有無によって表記が変わる必要は普通に考えればないです。

パイプリンクにすることが無駄かどうかは意見が分かれるでしょうが、別に強制されてるわけじゃないし、やりたくないならやらなきゃいいだけなのでは？表記ガイドも基準であって絶対のルールではないはずです。やりたい人がやるでしょう。

また、英数字の扱いと矛盾するとありますが、だから「疑問符・感嘆符」で単独項目なのでは？英数字と別のルールで動いているということなのでは。そもそも「疑問符・感嘆符」は英数字じゃなくて約物の下部に配置されてますし、そういった意味でも別物と考えるべきでは。

以上、私見です。表記ガイドをそのまま読んだ上での解釈なので、それ以外の議論、慣習、ローカルルールなどで規定があるかどうかは申し訳ないですがわかりません。--アテラストーリ（会話） 2018年10月3日 (水) 16:49 (UTC)

　表記ガイド他、ガイドラインは絶対のルールではないにしろ、今回別に意味合いが変わるものでもないケースで意見が分かれる場合はガイドラインに従った方が無難ではないかと思います。発信側が作品タイトルに半角全角としての特別な意味をもたせているというようなケースでなければ、記事名が半角なのですから、タイトルとして本文中でも半角で統一すれば、wikipedia内の検索からいっても他ページのリンクからいっても混乱もないでしょう。--ジャムリン（会話） 2018年10月3日 (水) 17:36 (UTC)

コメント依頼より参りました。ガイドラインは基本的には「意見相違が発生した場合、編集合戦を避ける目的でお互い納得の上で妥協するために利用する合意済の指針（WP:DR）」なので、記事名が半角を使用しているのですから仰る通りパイプリンクを使う必要性は通常生じない「けども、他の記事リンクと並べた場合にそこだけ違和感が生じる」などといった場合は例外に属するのではないかなと思います。そのとき、バイト数に無駄は発生しますが読者の見やすさ、レイアウトを優先するために故意に無駄なバイト数を用いることは十分に有り得る執筆者側の対処（配慮）ですから、ガイドラインを錦の御旗のように振りかざして徹底的な排除を考えずとも放置しておいても結果に大きな影響は齎さず、むしろガイドラインの存在意義を考えず字面通りの状態にするため「だけ」に徹底遵守を推進しようとする側が場に混乱を齎しているのではないかな、と感じました。 / 出典情報源のタイトルの全半角感嘆符の場合は元の表記に従う慣例（？）があったはずですので、当事例も慣例に基づき『文中やリスト上の表記が全半角どちらであっても特に読者に混乱を発生させない』『ただ、考え方としては文章の流れや他リンクの表記と並べて見栄え、読みやすさが優先される』といった読者主体の観点を用いれば放置して良いかと思います（WP:IGNORE）。──例外に属する事例のためにルール本体を改変するというのは本末転倒もいいところで、その主目的は「ガイドラインの絶対的正当性を維持するために例外規定を設ける」という目的かと思いますけどもそれはそのまんまWP:BEANSの実施であり、全く誰にも必要とされていない、とても無駄な手順かと感じます。--Nami-ja [^会話 _履歴] 2018年10月3日 (水) 18:33 (UTC)
若おかみは小学生!のテレビアニメが放送終了するまでは、記載される際は、放送前からずっと左記の通り記事名の直接リンクで統一されていたのに、今頃（劇場版公開後）になって何故この様な事が？というのが正直なところです。作品の発信者（作成者）に特別な意図がない限り、記事名が規則で半角ならば、wikipedia内では、リンクする際も記事中でも（記事中で使用される際はたいていリンクされますが）そのまま記事名を使用した方が、混乱も面倒もないと思います。そういういう意味では、記事名を優先するという事になるのでしょうか。閲覧者にとっても、半角全角の違いで誤解や弊害があるとも考えにくいので、記事名準拠でいいと思います。ちなみに、原作本はフォントのせいか全角には見えません。投稿者にとっては、わざわざパイプ付きリンクを記載する労力とバイト数の浪費となるので、記事名を直接リンクした方が、編集する上でも楽です。感嘆符の全角半角の違いだけでパイプ付きリンクを使用すると、一見するとどこが違ってパイプ付きリンクを使用しているのか戸惑います。前述通り若おかみは小学生!のテレビアニメが放送終了するまでは、記事名の直接リンクで統一されていたのですから、劇場版の記載でも、それを踏襲して続けていれば、無用な混乱は避けられたでしょうし、今後も記事名の直接リンクで統一すべきだと思います。

似たような事で「[[ラブライブ!サンシャイン!!|ラブライブ！サンシャイン!!]]」といった記載が見受けられますが、こちらは記事名を直接リンクしている記載もあり、記事によってまちまちです。個人的には、記事名を直接リンクした方がバイト数の削減にもなりますし、見た目もすっきりして良いと思ってます。

あまり必要性はないかもしれませんが、もし表記ガイドを改訂するならば、「語句の記事がある場合は、記事名の表記に準拠します。」の様な一文を追加するのはどうでしょうか。

余談ですが、アニメ記事の各話リストでサブタイトルの感嘆符を執拗に半角表記する方を散見するので困惑しています。原作でも全角表記ですし、表記ガイドに照らしても全角表記が適切なのでしょうが、記事名の規則を誤用しているのか、意図的なのか不明です。--えのきだたもつ（会話） 2018年10月3日 (水) 19:50 (UTC)

作品の放送中の表記と終わってから急に、ってのは関係なくないですか？正しい方にいつでも直すべきでは。そもそも「記事名」というのはWikipedia記事の名前であって、作品の名前ではありません。声優記事の箇条書きリンク、アニメ記事の本文中での解説、そういった本文中での規定に記事名の規定は関係ないでしょう。--アテラストーリ（会話） 2018年10月4日 (木) 03:03 (UTC)

本文もまたwikipediaのガイドラインや方針の適応の範囲内であると思います。規則にないから、いうのであれば、ルール基準ではないところの利点や合理性に説得力がなければ今回のような編集合戦になってしまうことでしょう。--ジャムリン（会話） 2018年10月4日 (木) 04:05 (UTC)

コメント 半角文字の場合は『ロウきゅーぶ!SS』→『ロウきゅーぶ! SS』のように公式表記にない空白を入れたがる人がいまして、全角文字を使うことはそのような問題を回避する意味もあります。--XRGD（会話） 2018年10月4日 (木) 10:10 (UTC)

そうような問題に関しては、全角にさえすれば絶対にスペースをはさむ人は現れないということでもないでしょうし、個々人の問題であって該当人物に注意していただくことでしかないように思えますし、その場合は「スペースをいれない」といったルール設定を提議すべきでは？--ジャムリン（会話） 2018年10月4日 (木) 12:34 (UTC)

スペースに関しては文末で使用する際は次の文の前にスペースを入れる規定がありますが、単語として使う時には規定がない、つまり公式表記、一般表記に従う形となります。「スペースを入れるのが公式」という場合もありますので一律に入れてはならないとは設定できません（ロウきゅーぶ関してはノートで議論の跡があります）。ジャムリンさんの意見は少し私のコメントを読み違えているように思うのですが、私の意見としましては「全角・半角のどちらを使うかは直前の文字に従います。」（Wikipedia記事全面に適応される規定）、「ただし、記事名に使う場合は、常に半角を使用します。」（記事の命名に関する規定）という風に、別のものだと言うことです。決まってないから従わなくていい、ではなく、「全角にする」と規定がある上で、「記事の命名は例外」である、という流れだとなのでは、という話です。例えば、英雄夢語り (ヒーローズ)、隙間女(幅広)という記事は記事名で半角カッコですが本文中では全角カッコです（これはカッコなので今回とはまた違う話になりますが、参考例として引用しています。WT:NCでの議論より）。日本語文である以上可読性も考えて全角を使うべきです。あと、検索性で言うなら感嘆符・疑問符は全角・半角に関わらず検索結果に反映されないので関係ないと思います（検索結果には含まれないし、ついでに言えば右上の検索窓に入力した場合は自動で半角に変換されます）。--アテラストーリ（会話） 2018年10月5日 (金) 05:55 (UTC)

該当の案内文に関しては、使用できるケースとして「引用文」も含まれており、「記事名」における半角についてはリンクの関係からいっても本文中の「記事名」も含むとも解釈できるように考えられます。--ジャムリン（会話） 2018年10月5日 (金) 07:17 (UTC)

コメント すみません、どちらが良い悪いという端的な意見ではないのですが。
基本的に半角・全角の使い分けは、"0"（ゼロ）と "O"（オー）や黒星 "★" と白星 "☆" のような表記揺れとは異なり単なる字形の問題ですので、出典資料での使用フォントは基本的には判断材料にならないと思います。もしも固有名詞や引用文中の全角文字をすべて原文ママで転載するとなると、約物だけでなく英字や数字も全角・半角文字が混在してしまい表記の不揃いが目立つと思います。
一応、表記ガイドには「全角・半角のどちらを使うかは直前の文字に従います。」とあるので、本来の原則としては全角文字の直後の感嘆符は全角を用いるのが正論ではあると思います。ガイドライン文中で「固有名詞」「引用文」「記事名」を区別して列挙してある以上、統語的な解釈としては次文の「記事名に使う場合」は純粋に記事名の表示用途（前文の「固有名詞」全般には単純に包含されない固有ケース）と解釈せざるを得ないと思います。ただ、現実には
1. マークアップの便宜上、記事間リンクを張る固有名詞には半角感嘆符・疑問符を用いる方が合理的。
2. 表記ガイドに忠実に従った場合、「令丈ヒロ子の著書『若おかみは小学生！』は〜である（詳細は作品記事「若おかみは小学生!」を参照）。」のように表記の混在（前者は書籍名の説明なので全角、後者はウィキペディア記事名の説明なので半角）が起こり得る。
3. 機械的に表記ガイドどおり直前の文字に従うと『トップをねらえ！』（全角）、『トップをねらえ2!』（半角）のような不揃いが生じる。
4. 仮に表記ガイドの「記事名に使う場合は、常に半角を使用します。」の一文を拡大解釈して記事名と同一の固有名詞全てに半角 "!" "?" を使うとなれば、記事名に使われている表題『HUGっと!プリキュア』は半角感嘆符で、記事化されていない関連書籍『HUGっと！プリキュア1 プリキュアコレクション』は全角感嘆符、といった不揃いが生じる。
といった諸々の問題を踏まえて、表記を統一するなら記事名のシステム制約に合わせて半角で揃えるしかありませんが、本来の組版の常識からいえば現行のガイドラインの内容は相応の妥当性がありますし、きれいな解決はなかなか無さそうに思います。
ちなみに半角テキストの "!" や "?" の直後の空白については、表記慣習としては表記ガイドの指示どおり半角1文字分空けていただくのがオーソドックスかと思います（欧文の表記例 "en:Hugtto! PreCure"）。—ディー・エム（会話） 2018年10月5日 (金) 16:55 (UTC)（例示を一文追加--ディー・エム（会話） 2018年10月6日 (土) 02:09 (UTC)）
コメント 個人的には「記事名に使う場合は…」の一文は、「内部リンクを付ける場合は」という意味であると解釈していました。そもそもリンクを付ければ字体が赤か青くなりますし、システム上書式が変わるのは明らかですから、文中で普通に使われる場合にリンクの有無で全半角が変わること自体に、それほど問題は無いのではないかと思います。つまりリンクを付けない場合は全角（直前の全半角に従う）に統一するのが簡単であると思います。それで問題になるのは、2つ前のスレで示したような、箇条書きなどで書式の不統一が特に目立つような場合かと思います。そのような場合に限り、ノートでの宣言を経てローカルルールとして運用すればよいのではないか、というようなことが上のスレで言われていました。--Gwano（会話） 2018年10月6日 (土) 09:02 (UTC)
- 既に以前議論されていたのですね。見落とし失礼いたしました。もし全角を優先として問題ないのであれば、パイプリンクの要不要の判断は残るものの、直前の文字種によるリストの不揃いについては全角に統一していただく運用で問題無いと思います。W3C『日本語組版処理の要件（日本語版）2012年4月3日版』（「3.1.6 区切り約物及びハイフン類の配置方法」節）でも和文の感嘆符・疑問符は全角で統一されていますので、現ガイドラインの「〜直前の文字に従います。」の記述は、「和文の語句では全角、欧文の語句では半角、迷ったときは直前の文字で判断」という程度の解釈で読み替えていただくのが妥当かと思います（異論があるようなら文言修正を検討いただいても）。
- もし他の方々も含めて感嘆符・疑問符が全角使用優先で差し支えないようであれば「Wikipedia:表記ガイド/放送関連および配信関連#記事の導入部」の『ひらけ!ポンキッキ』の記述例を全角感嘆符に修正したく思います。特に事前の議論を経たものではなく当該記事の記事名をそのまま例示しただけでしたので。—ディー・エム（会話） 2018年10月7日 (日) 04:46 (UTC)

皆様、コメントありがとうございます。また、上の議論の見落としすみません。後述のケースを抜かせば、直前の文字種にあわせるで良いと思います。ただし、それを絶対のルールにしてしまうと、わざわざ[[トップをねらえ!|トップをねらえ！]]としなければなりませんし（これをやっておかないと、「トップをねらえ!はXXXX年の作品。（中略）トップをねらえ！では～」のように、同じ節で2回目の表記でリンクしない際に全角と半角が混在してしまう）、また「トップをねらえ2!」「トップをねらえ！」のように統一がとれなくなります。それを考えれば、半角に混在しそうな場合のみは半角優先とした方が良いと思いますが。--JapaneseA（会話） 2018年10月7日 (日) 09:22 (UTC)

返信すみません。「半角に混在しそうな場合のみは半角優先」は書式統一や編集の負担軽減等のメリットを伴わないので、選択肢としては望ましくないと思います。あくまで本来の組版の標準的仕様としてはあくまで全半角使い分けの基本は和文か欧文かであり、本ガイドラインの「直前の文字に従う」もそれに準じるという意図（明らかに和文の語句内でも機械的に直前の1文字のみに合わせるという解釈は単なる文章表現上での誤解）と解釈するのが自然かと思いますので、それに反する妥協の範囲は（上述のメリットを伴わない選択肢であれば）使用を拡大する運用を積極的に行う必要はないと思います。—ディー・エム（会話） 2018年10月8日 (月) 01:00 (UTC)

（追記）直前のコメントは記事名の制約についての話ではなく、単に和文の語句中に半角文字が部分的に混在するケースの方のコメントです。記事間リンクの必要など特段の事情がない固有名詞については、本来の和文表記の慣習では「トップをねらえ2!」や「とらドラ2!」も全角感嘆符とするのがスタンダードですので、当該のガイドラインの説明内容もそのような意図と解釈する（字面上の機械的な遵守よりもルールの真意を汲むことを優先する）のが自然ではないかと思います。ただ、もし作品名の方の件が必ずしも全角優先（そのためのパイプリンク使用も推奨）の方向でまとまらないのであればパイプリンクの煩雑さなどを避けて半角で統一するという判断も当然ありえますので、問題の優先順位としては先に来るべき話ではないかもしれません。—ディー・エム（会話） 2018年10月8日 (月) 01:52 (UTC)

引用文の補足に用いる約物について[編集]

Wikipedia:良質な記事/良質な記事の選考/恋人たちのクリスマス 20181229での議論を見て浮かびました疑問について、皆様にご意見を頂きたく思います。

本ガイドラインでは引用文の補足に用いる約物に関して、亀甲括弧〔〕の使用が推奨されております。一方、同じ目的のためのテンプレート Template:Interp においては、半角角括弧 [] が使用されており、このテンプレートの使用もある程度普及していると思われます（私はかつてこのテンプレートに大きく手を入れましたが、基本的な表記はそれ以前からまったく変化しておりません）。

Template:Interp は元来、英語における引用文補足のスタイルを踏襲したものと思われますが、現状では、本ガイドラインに引用文補足を半角角括弧で行う旨の指示はありません。しかしながら、半角文字のみに対する括弧の使用が半角括弧 () に限定されているように、半角文字のみによる引用文補足を〔a〕のように亀甲括弧で囲むのにも。若干の違和感を覚えます。欧文における引用文の補足については、引き続き半角角括弧も許容される、との理解でよろしいのでしょうか。--Arvin（会話） 2019年1月13日 (日) 10:02 (UTC)

その後ネット上で検索した限りでは、日本印刷技術協会のページ[4]などが述べているように、和文における引用者注を示す約物は、亀甲括弧〔〕とブラケット・角括弧・大括弧 [] の双方が許容されていると思われます。ということで、

和文における引用者注については、括弧内に全角文字を含む場合には亀甲括弧〔〕、全角角括弧［］、半角角括弧 [] のいずれかを使用する
括弧内が半角文字のみである場合の和文における引用者注、および英文における引用者注については、半角角括弧 [] を使用する

ということで、個人的に納得することにします。--Arvin（会話） 2019年1月15日 (火) 12:21 (UTC)

その後さらに考えますに、括弧内の文字が半角文字のみであったとしても、「A」というような表記が許容されているのと同様、〔A〕という表記も不自然ではないのかも知れません。括弧に亀甲括弧を使用するか角括弧を使用するかは、文字のバイト数によってではなく、括弧内の表示が和文であるか欧文であるかを文脈から判断すべきと考えます。よって、

和文における引用者注については亀甲括弧〔〕、全角角括弧［］、半角角括弧 [] のいずれかを使用する
英文における引用者注については、半角角括弧 [] を使用する

というように考えを変えさせて頂きます（これはあくまでも個人的な覚書です）。--Arvin（会話） 2019年1月28日 (月) 03:22 (UTC)

コメント 「日本印刷技術協会」のような外部権威の文書は参考になりますね。似たようなものとして日本翻訳連盟の「日本語標準スタイルガイド（翻訳用） (PDF) 」というのがあったので紹介しておきます。

結論から言うと、この文書内にはいわゆる「訳注」に関連する定めはないので、直接的にはさほど参考にはならないです。

カッコ類については20ページ以降に解説があります。このなかで、「全角大かっこ」（［］）は、コンピューターの画面用語などの特殊な表記に限って使うようになっています。「［ファイル］メニュー」のように。

「半角大かっこ」（[]）は、ウィキペディア内では特殊性があって、リンクを作るときや出典や注釈などのこれ^[注釈]に使うので、そうでない文章内で用いるのはなんかちょっとヤダなという感じはします。

我々が引用を行うにあたり、引用元で既に括弧類が用いられている場合にはそのまま使うしかない、と思います。しかし、我々が翻訳や引用等を行って記事にする場合には、我々による注釈には<ref group="注"></ref>などを用いるのも手と思います。--柒月例祭（会話） 2019年1月28日 (月) 04:42 (UTC)

丸括弧・波括弧・角括弧の節からノートページへの誘導について[編集]

Wikipedia:表記ガイド#丸括弧・波括弧・角括弧の節で

{{未了2}} これについては、当ガイドラインの[[Wikipedia‐ノート:表記ガイド|ノート]]で議論されています。

のように、こちらのノートページへの誘導が行われています。しかしトップページに飛ばされるだけでは、過去の議論を参考にしたくてもどれを読めば良いのかすぐには判断がしにくいですし、探すのも手間がかかってしまいます。2008年1月5日 (土) 02:02(UTC)の版（差分）において【執筆者・編集者への注記】をコメントアウトする形で「Wikipedia‐ノート:表記ガイド/括弧の使い分け (約第4回)#議論5: 「全角」「半角」の表現を使うか？」へのリンクが追加されたようですが、わざわざソースを確認しない限りこのリンクの存在に気がつくことはできません。そこで提案なのですが、#丸括弧・波括弧・角括弧の節にある

これについては、当ガイドラインのノートで議論されています。

の内部リンクを、該当する過去の議論のページに変更してはいかがでしょうか。あるいは、現在はコメントアウトで隠されている【執筆者・編集者への注記】の部分を注釈に置き換えるだけでも分かりやすくなるかもしれません。--Keruby（会話） 2019年3月31日 (日) 06:17 (UTC)

まずはご指摘どおり、適切なリンク先を改めるなり、なにかするほうがよさそうに思います。

これは「いま現在議論中」ではなく「過去の議論」ですから、「議論されています」よりは、「過去の議論」とか「当時の議論」みたいな表現のほうがよいのでは。

また、注釈化するというのもいいアイデアだと思います。--柒月例祭（会話） 2019年3月31日 (日) 09:01 (UTC)

柒月例祭さん、コメントありがとうございます。自分で提案しておきながら2年近くも放置してしまい申し訳ありません。「該当する過去の議論のページ」のリンクをどれに変更すべきか調査する段階で止まったままでした。改めて履歴を調べたところノートへのリンクは2008年1月4日 (金) 15:58 (UTC) の版で追加されたものでした。要約欄によると適切なリンク先はWikipedia‐ノート:表記ガイド/括弧の使い分け (約第4回)ですが、これはコメントアウトされていた【執筆者・編集者への注記】内のリンク先と重複していたためリンクを除去し、注記のコメントアウト解除および注釈化を行いました。以上、大変遅くなりましたが特別:差分/81838876についてご報告いたします。--Keruby（会話） 2021年2月15日 (月) 01:02 (UTC)

「単位」章の追記提案（主に「度」関連）[編集]

「単位」の章に以下の内容を追加したいと考えております。理由は、本来 ° （度）が使われるべき箇所で º （序数標識）が使われているものが100件あまり見つかったことと、修正作業中に「分」「秒」についても誤字が見つかったことから、表記ガイドにて言及があった方が良いかと思い、提案した次第です。皆様のご意見をよろしくお願いいたします。

(1) 「度」「分」「秒」における例外の説明追記

ただし、角度などにおける「度」「分」「秒」に単位記号を用いる場合は、数値と単位記号の間に空白は入れません。
例：角度 30° （空白を入れて「30 °」としない。また原則として 30度と表記する）

例：緯度 51° 28′ 38″ N（空白を入れて「51 ° 28 ′ 38 ″ N」としない。また原則として北緯51度28分38秒と表記する）

注意： ° や ′ や ″ は、時間の「時」「分」「秒」や長さの「フィート」「インチ」を表すためには使用しない。

解説: 今までは「度」についてのみ言及しておりましたが、これを「分」「秒」に拡大することを意図しました。注意につきましては、英語版ウィキペディアのen:WP:UNITSYMBOLSに倣いました。

(2) 温度の記述説明追記

温度は、摂氏度またはケルビンを用います。
例：摂氏30度または 30 ℃（「30°」「30 C」は誤り）

例：303.16ケルビンまたは 303.16 K（「303.16 °K」は誤り）

解説: 誤りの例、ケルビンの例を追加しました。

(3) 単位記号と誤用しやすい文字の説明の追記

単位記号の中には似た文字があります。誤用にご注意ください。
- ° （度）［ º （序数標識） ˚ （リング符号）は誤り］
- ′ （分、プライム）［ ' （アポストロフィー） ‘ （開始引用符） ’ （終了引用符）は誤り］
- ″ （秒、ダブルプライム）［ " （二重引用符） “ （開始二重引用符） ” （終了二重引用符）は誤り］
- ⌀ （直径記号）［ φ （ギリシア文字のファイ） Ø （スラッシュ付きのO）は誤り］

解説: 追記を提案した理由は冒頭に示した通りです。追記箇所は「単位」章の最後を予定しております。また、正しく表記することでスクリーンリーダーの対応もできるものと思われます。なお、当方の環境 (MacOS X 10.11.6, Google Chrome 73.0.3683.103) においてはOSの機能で「°」「′」「″」が「ド」「フン」「ビョウ」と読み上げられることを確認しました。

--茶でもすするか（会話） 2019年4月17日 (水) 11:30 (UTC)

ご提案は合理的でわるくないとおもいます。「ルール」「解説」に分かれているのは良いと思います。

ちょっと横道になってしまうのですが、半角スペースを挿入することについて。基本則として、「単位記号を用いる場合は」半角数値および単位記号の間に半角スペースを1ついれる、ということになっていますよね。これは、私は「みやすいから」なんだろうな、と思っていたのですが、本当はどうなんでしょうね。スクリーンリーダーのことを考えると、半角スペースがないほうがスクリーンリーダーが意図通りに機能する、ということはありそうなことだと思います。「10メートル」の意味で「10 m」と表記したら、スクリーンリーダーはちゃんと「１０めーとる」と読んでくれるものなんでしょうか。（[5]とかで試すと、「10m」は「10メートル」、「10 m」は「じゅう　えむ」になります・・・ただしこのサイトでは「緯度 51° 28′ 38″」の「′″」は読んでくれない）

ついでに、現在のいちばんうえの文「単位は原則として単位記号を用いず、かな・漢字で表記します。」にも、「スクリーンリーダーのことを考えると、かな・漢字表記の場合はちゃんと読んでくれる、単位記号をつかうとちゃんと読んでくれないかも」的な解説を追加してはどうでしょうね。--柒月例祭（会話） 2019年4月18日 (木) 01:17 (UTC)

「日本語であまり使われない文字を巡る誤用が多い」と言いたさそうですね。「単位は原則として単位記号を用いず、かな・漢字で表記します。」に関する「Why」があればより守ってくそうです。--Takagu（会話） 2019年4月18日 (木) 08:57 (UTC)

返信コメントありがとうございます。数値と単位の間に空白を入れるのは、見やすくするとともに国際単位系における表記ルールでもあります（国際単位系 (SI) 日本語版のp.45の5.3.3 量の値の書式に記載がありました）。ちなみに、当方の環境では、数値と単位の間の空白の有無で音声の内容に変化はありませんでしたが、「m」を「メートル」と読む一方で「t」を「トン」と読んでくれませんでした。

単位記号と誤用しやすい文字につきましては、「日本語であまり使われない文字を巡る誤用が多い」というよりは、英語版ウィキペディアにも注意があり、他の言語でも誤用が多いようです。昔の機械式タイプライターの時代には、例えば「°」は紙を半行ずらして小文字の「o」を打ったり、分記号も一重引用符もアポストロフィも「'」で済ますなど、字形の似た文字で代用することが普通に行われていましたが、Unicodeで文字と意味とがより厳密に結びつくようになったがゆえの問題と言うべきでしょうか。

序文に解説を追加するのは良いアイディアだと思います。ただ、かな・漢字で表記することのメリットと言えば、正直なところ「スクリーンリーダーのより的確な動作が期待できる」位しか思いつきませんでした。特に科学技術分野では単位記号を使わないことでいたずらに文字数が増えたり、かえって分かりにくくなったり（理系的感覚ですみません）とデメリットもあるかと思います。「かな・漢字で表記することでスクリーンリーダーのより的確な動作が期待できます。」の追記くらいではどうでしょうか。--茶でもすするか（会話） 2019年4月19日 (金) 11:29 (UTC)

報告提案から1週間ほど経ちまして反対意見がございませんでしたので、提案の内容を反映いたしました。もしコメント等がございましたらお知らせください。--茶でもすするか（会話） 2019年4月25日 (木) 11:49 (UTC)

ハイフンマイナスの使用について[編集]

現時点で当方から正式に議論を提起することは難しい状況ですが、数か月前にWikipedia‐ノート:アクセシビリティ#記事名におけるダッシュの扱いについてで質問したところ、アクセシビリティの対応上ハイフンマイナスではなくenダッシュを入力したほうが正しいという意見が出たことをお知らせいたします。そちらでも書いた通り、対応としては「正しく使用することを推奨（強制はしない）」が落としどころではないかと思います。--ネイ（会話） 2019年11月3日 (日) 12:01 (UTC)

テキストリーダの問題や、表記しやすさの問題も根強いので難しいところですよね。私もあまり積極的な議論はできそうもないのですが、気付いた点だけ挙げておきます。

まず、以前に問題に挙げていました、マイナス記号などの一部のダッシュ記号の表示ができない機器内蔵Operaの件ですが、当方にあるものでは一週間ほど前のMediawikiのセキュリティ強化（？）によってWikipediaを直接閲覧できなくなっていることをご報告しておきます。これが不可逆であるなら、その環境に配慮する理由は多少薄れたかもしれません。具体的にはニンテンドーDSブラウザーと、2011年モデルのブラビアです。後者はまだぎりぎり修理サポート期間の範囲内（TVの場合は生産「終了」後から8年なので、意外に長いです）なので、いちおう現役の機器なんですけどね。もちろん外部サイト経由で間接的な閲覧はできなくもないようでしたが。

また関連する問題として、ハイフンマイナスの使用において、現在の表記ガイドの文面では波ダッシュの代替として（やむを得ない場合を除き）一律にハイフンマイナスを使用するかのように定められているという問題点も挙げておきます。箇条書きの見出しなどで既にハイフンマイナスが使われている個所の近くではかえって見づらくなる場合もあると思います。以前にも触れたかもしれませんが、波ダッシュの代替可能性については「『から（まで）』を適切に使用する」「長音記号として使われている場合は（正式な表記が明らかでない限りは）長音記号（ー）を使う」「範囲を表す場合は三点リーダ（…）なども検討してみる」などといったケースバイケースを示す必要があるのではないかと思っております。--Gwano（会話） 2020年1月24日 (金) 09:21 (UTC)

○丁目の○は、漢数字とアラビア数字のどちらが適切なのか[編集]

中島敦の記事において、死亡地住所の、「東京府東京市世田谷区世田谷（現：東京都世田谷区世田谷1丁目32番18号）」の、世田谷○丁目は漢数字が正式表記だというご指摘が、地理にお詳しい利用者:Otherdeさんからありました。コメントアウト部で、昭38・７・９民事甲1974号において、「横書きの場合は」アラビア数字を用いて良いとある為表記上の問題はない、というOtherdeさんのご説明もあるので、ウィキペディア上の人物記事内（地理を解説する記事ではなく）では、そこまで漢数字にこだわらずにアラビア数字でも構わないのではないかと思うのですが、今現在のガイドラインで「正式表記に漢数字を用いている場合。（正式表記と確認できる場合だけ）」とあり、この「（正式表記と確認できる場合だけ）」に、世田谷○丁目の場合も当てはまるのかどうか今一つよく分らず、どういうものがいつも漢数字でなけらばならないのかよく分らないので、どなたかご教授願います。--みしまるもも（会話） 2020年4月14日 (火) 07:07 (UTC)

住所の丁目については、大抵の場合は漢数字が正式です。上記の世田谷の例だと、「世田谷」という町があってその下を1丁目、2丁目というように区分しているのではなく、「世田谷一丁目」「世田谷二丁目」という町が設定されているためです。「○丁目」まで含めた固有名詞だということですね。なので、これを横書きだからと算用数字に直すのは、斎藤一郎さんという人の名前を、横書きの時に斎藤1郎と書いてしまうようなことになります。しかし現実には、世田谷の下を区分している数字であるかのように多くの人に認識されていて、世田谷1丁目と書くどころか、世田谷1-32-18みたいな住所表記も慣用されていますし、ウィキペディアの記事においてすら、世田谷 (世田谷区)は、世田谷一丁目から四丁目まである、と書いてあって、4つの町を1記事で説明している状態になっています。私は、算用数字で丁目を書いてあっても、あえてそれだけを直そうとは思わないですが、自分が記事を書くときには漢数字にする、というくらいにしています。

なおごく一部の自治体で、本当に町の下を区分する数字として1丁目、2丁目という書き方をしているところがあるのだそうで、そのために丁目であれば必ず漢数字、とは言えない状態になっているのだそうです。「（正式表記と確認できる場合だけ）」というのはまさにそういうことを指しているのだと思いますが、正直そこまで厳密に追及するのは地理の記事でもない限り無理でしょうし、住所についてはとりあえず漢数字にしておいても良いのではないかと思います。--Tam0031（会話） 2020年4月14日 (火) 07:41 (UTC)

大筋ではTam0031さんと同意見（厳密に追求するのは地理の記事で。今回の場合、住所としてはとりあえず漢数字でよいのでは。）です。厳密にやりだすと、「地番」と「住所」と「住居表示」の違いとかを考える必要が出たりしますが、今回はそこまでの話じゃないでしょう。
行政の文脈では、役所の取扱は「世田谷一丁目」でひとまとまりの語です。行政区分上の1地域であり、「世田谷」の下位区分「1丁目」ではない、ということになってます。「六本木」が「6本木」ではないのと一緒ということです。仮に単独記事にするなら世田谷一丁目になるということですね。
しかし歴史的・一般的な文脈や慣習では、「一丁目」から「四丁目」までの総称として「世田谷」と認識したり、「1丁目」「1-5-10」みたいな表記があるというのも、Tam0031さんがご指摘のとおり。たとえば交差点の信号機に設置されている標識は「世田谷一丁目　Setagaya 1」であり「Setagayaittyoume」ではない。ほかにも、私の運転免許証を見ると、公式の行政地名は「○○六丁目」ですが「○○6-y-z」のように略記されてます。当の世田谷病院のHPでも世田谷1丁目とか「世田谷1-32-18」と記載してたりしますね。たいていはどっちでもいいのです。
自然地名に「正式」という概念は適さない、と私は思いますが、今回のケースは住所に関わることなので、もめるなら「役所の正式」に準じるのでもいいのでは。「いいのでは」というのは、絶対にそう統一しなきゃ問題があるとかいう次元ではないけど、漢数字とアラビア数字で意見が分かれるなら役所の正式に合わせとけばー？ぐらいのニュアンスです。
これもTam0031さん指摘の通り、自治体によっては「丁目」部分が行政区分になってないところもあります。北海道では「○○X条y丁目」のような住所が多く、「○○X条」が行政区分だったりしますね。
まあ、そもそも中島敦の記事の場合、死没地の当時の病院の住所をわざわざ「現在の住所」に置き換えて書くほどの意義があるかしら？とは感じますけども。（死んだ場所の座標をことさら細かく書くべき事情があるのかって話）--柒月例祭（会話） 2020年4月14日 (火) 08:40 (UTC)

： コメント 既にTam0031様より説明がある為簡単な説明に留めますが、「世田谷一丁目」で一つの町名となる為漢数字としました。また、山元町 (横浜市)のように主に住居表示施行以前に設定されたアラビア数字が正式な「字丁目」も別に存在する為、正式な記載を行わずにアラビア数字とするメリットは特にないと考えます。--Otherde（会話） 2020年4月14日 (火) 09:55 (UTC)

Tam0031さん、㭍月例祭さん、Otherdeさん、どうもありがとうございました。この場合、漢数字の方がよいとのことが分りました。今後の参考にもさせていただきます。--みしまるもも（会話） 2020年4月15日 (水) 06:10 (UTC)

記事名における波ダッシュ、チルダについて[編集]

作品名などの固有名詞で波ダッシュまたはチルダを含んでいるものの扱いについて質問をさせていただきます。作品の公式サイトなどで、当該記号をチルダで表記しているものに関して、当該作品に関するWikipediaの記事名もチルダを用いるべきなのでしょうか？

先行議論はノート:Hi~です（記事はアルバムの項目です）。2017年に立項された際は末尾の記号が半角チルダとなっており、私がこれを波ダッシュに改名しましたが、2019年に「アルバム名は波ダッシュではなくチルダである」とのことでノートでの改名提案により改名されています。最近になって私がこの改名に気付き、波ダッシュに戻したほうが良いと考え2度目の改名提案を行いましたが、このとき「本来チルダであるものはチルダで問題ないのでは」「別記号での代替はNGではないか」との意見が寄せられました。当該アルバムをリリースしているアーティストの公式サイトでの表記を確認すると、波ダッシュではなくチルダが用いられていました（ただし公式サイト上で直接的に当該記号がチルダであると明言されているわけではありませんでした）。

Wikipediaにおいては、波ダッシュの代用としてチルダを用いることは認められていませんが、作品名の場合、チルダが使用されていてもそれが本当に「チルダ」を意図しているものなのか、単なる波ダッシュの代用としての使用なのか、第三者が厳密な形で証明することはできません。そして本表記ガイドには作品名における「波ダッシュの代用ではないチルダ」に関しての記載はありません。ただし、チルダの本来の用途が特定の外国語におけるダイアクリティカルマークとしての使用や数学記号としての使用など限定されていることを考えると、作品名のチルダは基本的には波ダッシュの代用である、とは思われます。もし公式サイトでの表記を根拠にチルダを用いるべきであれば、その旨こちらの表記ガイドへの記載が必要だと考えられるほか、記事名への影響は「Hi~」だけにとどまらず、公式サイトで（波ダッシュの代用かどうかによらず）タイトルにチルダを使用している作品の記事で、Wikipediaの記事名として波ダッシュを用いているものはすべて改名対象ということになり、Wikipedia上で大量の改名を要することになるものと思われます。この件に関して、皆様のご意見を伺わせていただければと思います。--Dream100（会話） 2020年5月26日 (火) 12:58 (UTC)

基本的にチルダは単独で現れるものではないので字体揺れの少ない波ダッシュにすべきだと私は思います。Hi~もプロデューサーの意図としては長音記号を意識したものとみられ、曲のハングル表記を確かめたところも「おはよう」(Hi~)でした。フォントの見栄え上、選ばれているのであれば、断り書きに「公式サイト上では半角チルダを用いている」と表記しても良いのではないかと思います。なおGoogle検索もBingもDuckDuckGoも、波ダッシュ・全角チルダ・半角チルダは無視して検索するようアルゴリズムが仕込まれているようです。--Licsak（会話） 2020年5月26日 (火) 13:34 (UTC)

「こうするのがよい」という具体的な意見でなくてごめんなさい。
本件はどちらかといえばWikipedia:記事名の付け方#記事名に使用できる文字やWikipedia:記事名の付け方#特殊記号に属する問題でしょう。
昨今、本件のように、意図的に記号や絵文字類などを用いることで表現上の新しい効果を目指すような事物が登場していますよね。文学とか、音楽とか、芸術とか、芸能分野とかで。たとえば「藤岡弘、」なんかもその類です。古典的・従来の辞書観・言語感覚では捉えきれないもので、新しい表現には新しい対応が求められるかもしれません。
このテの新しい表現技法を、古典的な辞書感覚に基づく規則に従属させるというか、「辞書のルールはこうだからこれに合わせろ」的な対応をするのか、それとも新しいルールを作るかです。Wikipediaの場合には、技術的に重要な問題として、記事名＝urlになるというところがあり、紙の印刷物では対応できてもWikipediaでは対応できない、ということもあるでしょう。たとえば「私の芸名は『%E2%80%90%E3』です」とか、「この作品のタイトルは『  』です」みたい場合にどうするの、とかね。
まあ当座のこととしては、「よく用いられる代替表現」みたいなものを記事名としておいて、記事の中で「正しい表記はこれこれだ」みたいに解説するんでしょうね。--柒月例祭（会話） 2020年5月28日 (木) 07:16 (UTC)

以前はチルダ自体を使ってはいけないとも取れる文言だったのですが、Dream100さんの挙げられた「波ダッシュの代用としてチルダを用いることは認められていません」に変わった経緯ついてはWikipedia‐ノート:表記ガイド/過去ログ13#全角チルダは使用しないでください？になると思いますので、ご参考までに。--Gwano（会話） 2020年5月28日 (木) 08:21 (UTC)

皆様コメントいただきありがとうございます。

㭍月例祭さんのご意見に関してですが、波ダッシュ（〜）もチルダ（～/~）もWikipediaの技術的には使用可能な文字です。記事名に使用することによるURL上の問題も、特にないのではないかと考えています。両者とも使用可能な文字であるにもかかわらず、文字コード上の理由でチルダが本来の用途ではない「波ダッシュの代用」として用いられている、という点が問題の根本です。また記事名に関しては本来Wikipedia:記事名の付け方で議論すべきとは思いますが、同ページには記事名における波ダッシュ、チルダの使用方法について詳細な記載はなく、むしろ「全角チルダについてはWikipedia:表記ガイド#波ダッシュを参照」と本表記ガイドの解説に「丸投げ」している状態です（Wikipedia:記事名の付け方#全角と半角）。このため記事名におけるチルダの使用についての議論は本ページで行わざるを得ない状況です。

チルダの本来の使用目的についてはいくつかありますが、パソコン上でのチルダについては非常に大きく分けると以下の2つのいずれかになります。

波ダッシュの代用であるチルダ
波ダッシュの代用ではないチルダ（数学記号など）

Wikipedia‐ノート:表記ガイド/過去ログ13#全角チルダは使用しないでください？は、2.について波ダッシュに置換する必要がないということを確認するための議論であると思われます。しかし議論の結果、結局1.に関する記載しか行われず、2.に関してどうすべきかは明示されていません（波ダッシュに置換する必要はない、ということを暗に意味しているとは思いますが）。

ノート:Hi~で寄せられたコメントは、末尾のチルダが1.ではない（つまり2.である）という前提の上でのものと認識しています。しかし作品名において公式サイトでチルダが用いられていたとしても、1.なのか2.なのか、厳密な意味で証明することができない、という問題点があり、「Hi~」についても本当に2.かどうかはわかりません。そして、証明はできなくても、日本語における2.の使用例が、数学や言語などに関する限られた文脈を除いてほとんどないことから、作品の公式サイトでチルダが用いられている場合にも、基本的に1.なのだろうと推測されます（「Hi~」は韓国のアルバム名ではありますが、おそらくLicsakさんのご指摘の通りではないかと考えます）。このことを踏まえたうえで、公式サイトで作品名にチルダが使用されている場合のWikipediaの対応としては、

公式サイトの表記に忠実に従い、記事名にはチルダを使用する
チルダを波ダッシュの代用であるとみなして、記事名は波ダッシュにする

のいずれかになると思いますが、いかがでしょうか。もし前者をとるのであれば、「Hi~」と同様の形で膨大な数の記事の改名が予想されるほか、公式に準じる複数のサイトで表記が異なる場合も想定され混乱が生じかねないため、私としては後者がよいと考えています。--Dream100（会話） 2020年5月31日 (日) 02:45 (UTC)

私の上記発言以降コメントがないため、合意形成に移りたいと思います。私としては上記の通り、波ダッシュの代用なのか本当にチルダなのか明言のない作品名については波ダッシュに統一する形でよいと考えており、この考えに対しての異論は出ていません（議論のきっかけとなった「Hi~」についても、本ページで波ダッシュにすべきとのコメントをいただいています）。これを受けて、Wikipedia:表記ガイド#チルダを以下の通り改定することを提案します。

現行：（※コメントアウトも含めて表示）

波ダッシュの代わりに全角チルダ「～」(Unicode: U+FF5E)・チルダ「~」(Unicode: U+007E) は使用しないでください。

またWindows環境の通常のキーボード入力では、「」のキーボード入力を決して行わないで下さい（上述の理由により）。

改定案：

全角チルダ「～」(Unicode: U+FF5E) ・チルダ「~」(Unicode: U+007E) は、波ダッシュの代わりとして用いられるケースがありますが、ウィキペディアにおいて、この目的でのチルダの使用はしないでください。数学記号としての使用など、波ダッシュの代用ではないチルダの使用については、この限りではありません。
作品名に用いられている場合などで、チルダが波ダッシュの代わりかどうか不明なことがあります。この場合は、波ダッシュを用いてください。

またWindows環境の通常のキーボード入力では、「」のキーボード入力を決して行わないで下さい（上述の理由により）。

変更点としては、「チルダが波ダッシュの代用とそうでないものの2種類があることと、後者の場合にチルダを波ダッシュに置き換える必要がないことを示す」「作品名などで波ダッシュの代用かどうか不明なチルダは波ダッシュにする」の2点です。コメントアウトについても簡略化してよいと考えています。

1週間以上異論がなければ、表記ガイドに反映させたいと思います。--Dream100（会話） 2020年6月7日 (日) 05:19 (UTC)

コメント 「上述の理由」という部分を含めて考える必要があるため、恐縮ながらチルダ節だけでなく波ダッシュ節の全体に話が及んでしまいましたが、2点ほど。

まず前提となっている波ダッシュをできるだけ使わない理由について気になっていたのですが、Windows XP時代の逆字体だけが理由に挙げられている点に違和感があります。逆字体の問題はほぼ過去の話になりましたが、その後の問題として、モバイル環境など機器内蔵ブラウザにおいては、環境によって波ダッシュと全角チルダのどちらか片方しか表示されないケースが両方確認されたため、どちらかに統一できなかったことが、より深刻な問題だったように思います。

それと細かい表現の部分で恐縮なのですが、「正しい波ダッシュ」という概念について、この節だけが直接参照された場合に、UnicodeというかUTF-8が前提である旨の（直接的な）記述がほとんど見当たらないのが、少々気になります。キーボードから入力される「～」は、従来の古い文字コード体系では「正しい波ダッシュ」である場合も当然ありますよね？いちおう百科事典に付随する文章なのですから、「～」が間違いであること（「波ダッシュ」を入力したつもりでも、「全角チルダ」が入力されてしまう）を言及するのであれば、「（Wikipediaで採用されている）UTF-8においては」くらいの前置きがあったほうがよいのではないかと思いますが、どうでしょう。

なお文章の細かい部分はともかくとして、今回ご提案の2点の変更点の趣旨そのものについては、今のところ特に異論はありません。--Gwano（会話） 2020年6月8日 (月) 09:55 (UTC)

コメントありがとうございます。今回の改定案は作品名のチルダ（波ダッシュの代用かどうか厳密に証明できない）についての言及を加えることを主眼としたものであり、その他の部分の改定については意図しておりませんでしたが、Gwanoさんのご意見に対して特に反対はございません。

ところで、よく考えるとそもそもチルダ節の最後の段落が必要なのかどうか、疑問に思えてきました。「上述の理由」というのはチルダ節の上にある波ダッシュ節の「Windows環境の通常のキーボード入力による「」では異なる文字である（全角）チルダの入力となってしまい混乱を生むから」という記載を指していると考えられ、最終段落の主張内容は「Windows環境において、波ダッシュを入力するつもりでキーボード上のそれらしき記号を打たないでほしい」というものだと解釈されます。すなわち、チルダに関する節で波ダッシュの入力に関する注意点が記載されているということになり、不自然ではないかと思いました。

Gwanoさんのご意見を波ダッシュ節に反映させると、以下のようになるかと思いますが、いかがでしょうか。

改定前（波ダッシュ節）：

波ダッシュ・波ダーシ（「」など）は原則として用いず、半角(JIS X 0201)のハイフンマイナス「-」で代用して下さい。
この理由は、Windows環境の通常のキーボード入力による「」では異なる文字である（全角）チルダの入力となってしまい混乱を生むからです。また正しい波ダッシュ「〜」(Unicode: U+301C) が、コンピュータOSおよびフォントによっては上下逆の波形「」で表示されることがあるからです。

改定後（波ダッシュ節）：

波ダッシュ・波ダーシ（「」など）は原則として用いず、半角 (JIS X 0201) のハイフンマイナス「-」で代用して下さい。
この理由は、Windows環境の通常のキーボード入力による「」では異なる文字である全角チルダの入力となってしまい混乱を生むからです。モバイル環境など機器内蔵ブラウザにおいては、波ダッシュや全角チルダが正しく表示されないケースもあります。また、Unicodeにおいて正しい波ダッシュとされている文字「〜」(Unicode: U+301C) は、コンピュータOSおよびフォントによっては上下逆の波形「」で表示されることがあります。

--Dream100（会話） 2020年6月10日 (水) 14:44 (UTC)

改定案をご提示していただき、ありがとうございます。とりあえず気付いたこととしましては、Unicodeであることの前置きは後半部にあるのですが、前半のキーボードの記述の部分にもあったほうが良いかなと思います。

Windows環境の通常のキーボード入力による「」ではUnicodeで入力された際に異なる文字である全角チルダの入力となってしまい

という感じでしょうか？ Windowsでは既にNT以降でUnicodeが標準ですが、プログラムソースなどアプリケーションによってはUnicodeでない入力が要求されるものもまだあるかと思いますので…。

それと大変申し訳ないことに、肝心な問題を1つ忘れておりました。波ダッシュ節の部分には上記#ハイフンマイナスの使用についてで挙げましたように、波ダッシュは長音記号の代わりに使われるケースも見られますので、機械的にハイフンマイナスに置き換えるように受け取れるのは、明らかに問題があります。場合によっては他の手段も検討の余地があることを触れておくべきでした。

半角 (JIS X 0201) のハイフンマイナス「-」で代用して下さい。

の部分について、

多くの場合では半角 (JIS X 0201) のハイフンマイナス「-」で代用できますが、それが不適切である場合には適切な代替手段も検討してみてください。

という感じでしょうか？個人的には具体例として、

範囲を示す場合は「から（まで）」を適切に使用することも検討してみてください。
台詞の引用などで長音記号として波ダッシュが使われている個所では、基本的に長音記号（ー）を優先してください。ただし、正式な表記が波ダッシュであることが判明している場合はその限りではありません。
単語や台詞の一部を省略する用途では、三点リーダ「…」や伏せ字（「○」や「×」など）も代替手段となります。
作品タイトルにサブタイトルを添える用途で波ダッシュが使われている場合で、波ダッシュ部分に表記ゆれのあるものは波ダッシュでない表記を優先してください。ただし表記ゆれがほとんど見られない場合は波ダッシュを含めた全体が正式な固有名詞であると考えられますので、その限りではありません。

…といった例を挙げることを考えておりますが、もし議論の余地が大きいようでしたら風呂敷を広げすぎる懸念がありますので、具体例についてはいったん本題とは切り離したほうが良いかもしれません。--Gwano（会話） 2020年6月12日 (金) 13:24 (UTC)

（インデント戻します）波ダッシュの代用が必ずしもハイフンとは限らないという件についてはご指摘の通りと思いますが、具体例をどうするか、となるとこの議論の趣旨から外れてしまうためそれは別の節で議論したほうがよいと考えます（そもそもこの節では波ダッシュ節の改定自体意図しておりませんでしたが）。

いただいたご意見を踏まえ、波ダッシュ節の改定案を以下のように変更します。また、チルダ節についても異論はいただいていませんが、自分で提示した改定案に気になった点があったので新たな改定案を提示します。

波ダッシュ節改定案2：

波ダッシュ・波ダーシ（「」など）は原則として用いないでください。多くの場合では半角 (JIS X 0201) のハイフンマイナス「-」で代用できますが、それが不適切である場合には適切な代替手段も検討してみてください。
この理由は、Windows環境の通常のキーボードでは、「」を入力しようとしてもUnicode上は異なる文字である全角チルダが入力されてしまい、混乱を生むからです。モバイル環境など機器内蔵ブラウザにおいては、波ダッシュや全角チルダが正しく表示されないケースもあります。また、Unicodeにおいて正しい波ダッシュとされている文字「〜」(Unicode: U+301C) は、コンピュータOSおよびフォントによっては上下逆の波形「」で表示されることがあります。

チルダ節改定案2：

全角チルダ「～」(Unicode: U+FF5E) ・チルダ「~」(Unicode: U+007E) は、波ダッシュの代わりとして用いられるケースがありますが、ウィキペディアにおいて、この目的での全角チルダあるいはチルダの使用はしないでください。数学記号としての使用など、波ダッシュの代用ではない目的での使用については、この限りではありません。
全角チルダ、チルダが波ダッシュの代わりかどうか不明なことがあります。例として、作品名で「」が用いられていて、それに関するオンラインの情報源で当該記号が全角チルダまたはチルダで表記されているケースが挙げられます。この場合は、波ダッシュを用いてください。

またWindows環境の通常のキーボード入力では、「」のキーボード入力を決して行わないで下さい（上述の理由により）。

※チルダ節改定案の変更点

当初の改定案では「チルダ」という言葉を「半角チルダと全角チルダの総称」として用いている箇所があったため、これを廃して「チルダ」をすべて半角チルダの意味で使用するようにしました。
2段落目の記載をより具体的にしました。

この改定案で異論がなければ、改定を実施します。--Dream100（会話） 2020年6月14日 (日) 00:52 (UTC)

了解です。具体例についてはあまり細かく考えると私論もしくはHelpのページ、あるいはプロジェクトのローカルルールに向いた内容になってしまいそうですので、どうしても必要という部分が無いようであれば、この場ではとりあえず棚上げということで良いかと思います。ひとまず改定案2についてはチルダも含めて今のところ異論はありません。波ダッシュ部分については結果的に便乗するような形になってしまいましたが、気になっていた部分に対応していただき、感謝します。--Gwano（会話） 2020年6月18日 (木) 07:12 (UTC)

報告改定案2の提示から1週間以上たちましたが、異論がなかったため、改定案2を反映させていただきました。ご意見いただいた皆様、ありがとうございました。--Dream100（会話） 2020年6月23日 (火) 12:51 (UTC)

括弧の規定の改訂提案[編集]

改定前（現状）
括弧改定案20200529（私案）

括弧の使用法部分の刷新提案です。

見かけは大きく変わっていますが、内容はそれほど変わりません。
- 括弧については過去に長大な議論が行われています。主要な論点は、全角と半角、「」と『』でした。今回そこは変えません。
- 最も大きく変わるのは括弧の入れ子に関する部分です。
- ほかの部分は解説を加えた程度です。

(1)提案の前提：現在、日本語の文章（横書き和文）における括弧の用法について、文科省とか文化庁のようなレベルでの決め事は無いに等しいです。

文化庁国語施策参考資料
- ここには「国語審議会答申，文部省が作成し」「一般に国語表記の参考」となるものが挙げられています。
- このうち括弧についてはくぎり符号の使ひ方 (PDF) の中に規定があります。
- ですがこの文書は昭和21年に縦書き和文を想定して作られたものです。現在でもこれが示されているというのは、逆に言えば、昨今の横書き和文に関して国レベルの指針はない、というに等しいです。

権威の程度は不詳ですが、オンライン上でまとまったものとしては以下のようなものが見当たります。
- 日本翻訳協会翻訳日本語表記ガイド (PDF) (2013)、p13
- 日本翻訳連盟JTF日本語標準スタイルガイド (PDF) (2019)、p30
- 日本印刷技術協会括弧類の使い方(2016)
  - 上記2件は「翻訳」を対象としたものだという点は留意を要します。
  - 一番上の「ガイド」は、括弧の部分が現在の表記ガイドと全く一緒です。私は過去議論に参加していないので詳細はわからないのですが、過去版2004年の初版には既に原型が認められ、2006年10月の版でおおよそ現在の状態になっていること、ノートでの過去議論2007年頃などをみると、日本翻訳協会がJAWPの表記ガイドを参考にしたのではないかな？と思います。（よくわかりません）
  - 2番めのものは、角括弧を「［メニュー］-［ファイル］などパソコン操作の説明時に使用する」というような決め方をしており、特殊な印象です。
そのほか手持ちの辞書・辞典類を眺めてみましたが、辞典ごとにルールはありますが世の中一般のルールというものはない、という感じです。

(2)最大の変更点は括弧の入れ子です。

現状、括弧を入れ子にする場合は［（〈〉）］の順で入れ子にせよとあります。私はこれをやや不合理と感じました。

私案で示したように、本来、一般的には括弧は用法によって使い分けます。

しかし入れ子ルールだと次のようなことが起きます。（たとえばです）

織田信長は天文3年（1534年）に……
織田信長（天文3年〈1534年〉-天正10年〈1582年〉）は……
天文3年［1534年（この年吉法師〈後の織田信長〉が生まれた）］……

このように同じ用法なのに3通りのスタイルが混在しかねません。一般的には〈〉は強調効果があるとされていますが、この用法だとそんなの関係ないです。私はこれはヘンだと感じます。
※織田信長の冒頭文は、入れ子ルールに則って、「織田信長（おだのぶなが、天文3年5月12日〈1534年6月23日〉 - 天正10年6月2日〈1582年6月21日〉）は、……」となっています。

実際問題として、この規定ができてから13年ほど経つわけですが、JAWP内でこれが定着しているようには思えません。これを「正しい」とする外部的根拠がよくわかりません。「JIS Z 8301（規格票）」の場合に［（）］とするというような決まりはありますが、それはあくまでJISの規格票の表記ルールに過ぎず、和文一般のものではありません。

たとえばGAの飯塚伊賀七では「飯塚伊賀七（いいづかいがしち、宝暦12年3月29日〔グレゴリオ暦 1762年4月23日〕 - 天保7年11月17日〔グレゴリオ暦 1836年12月24日〕）は……」と（〔〕）という構造です。入れ子ルールには反しているようではありますが、〔〕は注釈に用いるという一般的な用法からすると間違ってはいないようにも思います。
同じくGA田島弥平の冒頭文では（（）（））という構造です。

あくまで私の経験の範囲内ですが、実態としてJAWPでは（（））のような同じ括弧を使った入れ子のほうが普及しているようにも感じます。
同じ括弧を使って入れ子にするのは、日本印刷技術協会「括弧類の使い方」でも「文脈から理解できる」場合の使用法として紹介されています。

(3)括弧の用法についての解説を追加

現状では、亀甲括弧だけ用法の解説があり、丸括弧や角括弧にはありません。これはアンバランスと思います。

(4)半角・全角の説明を、それと分かるように節構成を変更。記事名の解説が割り込んでいるので場所を変える。

現状の節構成だと、引用符、鉤括弧、丸括弧・波括弧・角括弧、亀甲括弧とならんでいて、括弧の種類による解説をしている用に見えます。実際には丸括弧のところだけ全角/半角の話になっており、節構成がヘンだと思います。

ということで、用法に着目して解説を追加し、入れ子については、同じ括弧の入れ子もOK、従来の「［（〈〉）］の順」もOK、と改訂しています。改訂しているようですが、実際問題としては現状の追認に過ぎないとも思います。

ご意見を頂きたいです。--柒月例祭（会話） 2020年5月30日 (土) 02:12 (UTC)

コメント 最初の方でお示しになっている資料をすべて確認しきれておりませんこと、ご容赦ください。ざっと見たところ、括弧改定案20200529の感じで良いと思います。事実、（私の印象ですが）［（〈〉）］の順よりも（（））のほうがよく見かける気がしますし、むしろそちらが主流となっているように思えます（お恥ずかしいような話ですが、現行では［（〈〉）］の順が標準というのを今見て「あれ？そうだったっけ」となりました）。

細かいところですが、括弧改定案20200529で、もう少し他ページへリンクをつけたほうが良いと思います（「リンク」「テンプレート」「マジックワード」等々）。

あと今回の件とは直接関係ないのですが、日本翻訳協会翻訳日本語表記ガイド (PDF) を見て、（表記ガイド制定のかなり初期から）このPDF資料と文がそっくり（というか丸写しに近い）に思いました。…これって著作権大丈夫なんですかね？　単なる思い過ごしなら良いのですが。--Atmark-chan <話/稿> 2020年5月30日 (土) 16:33 (UTC)

ウィキペディア側がコピー元・日本翻訳協会がコピー先という認識でよろしいでしょうか（協会で表記ガイドが作られた経緯を存じませんが、{{CURRENTYEAR}}などのマジックワードが用いられているので）。資料内にコピー元やCCについての明記が存在しないため、当該資料はCC-BY-SAに違反していると見受けられます。--火乃狐（会話） 2020年5月31日 (日) 02:15 (UTC)

確かにそうですね。…というか、「表記ガイド制定のかなり初期」の時点であの文章で、しかも日本翻訳協会の (PDF) が2013年ということは、「ウィキペディア側がコピー元・日本翻訳協会がコピー先」なのは少し考えればすぐ分かることでした、すみません。--Atmark-chan <話/稿> 2020年5月31日 (日) 10:41 (UTC)

コメント 括弧改定案20200529を拝見して、よく考えられていると思います。

［（〈〉）］の決まりについては、『朝日新聞の用語の手びき』（1981年、ISBN 4022580860）12ページに「カッコ内にカッコを使うときは、次の順序で使う」の一文に続けて以下のように示されています。

〔（〈〉）〕

この本の最新版に当たる『朝日新聞の用語の手引』改訂新版（2019年、ISBN 9784022289179）163ページにも同じ内容が書かれています。縦組みでは〔〕を、横組みでは［］を同じ用途に使うことが多いことからすると、現行入れ子ルールの出どころは新聞の表記ルール辺りかもしれません。ほかに読売新聞（『読売新聞用字用語の手引』第6版〈2020年、ISBN 9784120052910〉41ページ）・毎日新聞（『毎日新聞用語集』POD版〈2015年〉457ページ）・時事通信社（『最新用字用語ブック』第7版〈2016年、ISBN 9784788714502〉23ページ）の類書でも（）の中で括弧が必要になった場合は〈〉を使うことになっています。3社の手引書では〔〕のことに触れていません。なおこういう場合によく引き合いに出される共同通信社『記者ハンドブック』第13版では括弧の入れ子についての記述が見当たりません。

個人的には（）内の括弧が（）になるのは読みにくく、（〈〉）の入れ子の方が読みやすくて好ましいと思っています。〈〉には特別な意味付け・強調をする用法がありますが、これが入れ子用法と混在することに特に違和感を覚えません。

~~今回のご提案では~~「JIS規格票（「……」の代わりに“……”を使う）など、別の慣習があるものを引用するときは、それに従います」という内容が~~加えられてい~~あります。~~現行版の~~引用符の節にある欧文用「引用符は和文に使わないでください」とされている内容~~がそのままになっていて、~~と齟齬が生じます。引用符節のうち箇条書き四つ目は「これらのうち “...” 以外の引用符は、和文では使わないでください。」としてはいかがでしょうか。現行の表記ガイドの日本文に“...”が頻繁に使われている紺屋の白袴状態もこれで解消できます。

新聞の表記ルールでは、多くの場合、かぎ括弧は「『〝〟』」という入れ子にすることになっています。また〝〟は「「〜とでも呼ぶべきもの」などの意味合い」や「「言うところの」「いわゆる」という意味合いを含めて」（小学館辞典編集部編『句読点、記号・符号活用辞典。』〈2007年、ISBN 9784095041766〉107ページ）使われるほか、「語句を強調したり、特に注意を喚起したりしたいときや、比喩、造語など」（時事通信社前掲書23ページ）に使われます。JIS X 0208にない約物で入力に難点がありますが、記事名のJIS X 0208制限がなくなったこともあり、〝〟を例示することを考慮してもよいのではないかと思います。--Meme-Meme（会話） 2020年6月21日 (日) 17:05 (UTC)

新聞の表記ルールとのことなのですが、〝〟は縦書きの場合を想定したもの、ということはないですか？--柒月例祭（会話） 2020年7月3日 (金) 10:41 (UTC)

確かに〝〟は古くから縦組み専用という認識があります（例えば『標準校正必携』第8版〈2011年、ISBN 9784888883924〉291ページ、『日本語表記ルールブック』第2版〈2012年、ISBN 9784888883979〉56ページ、いずれも日本エディターズスクール刊）。JIS X 0208に〝〟が収録されていないのは、第1次規格の選定過程で “ ” の「縦書き字形」として認識されていたからだといいます（JIS X 0208:1997 394ページ〈解 20〉）。

しかし現にほとんどの場合横組みになっているはずのこの場でも横組み用の形でご覧になっているはずです。JIS X 0213:2000が〝〟に横組みの用例があることを理由に独自の符号位置を与えたことの意味は大きいと考えます（これには結果としてNEC特殊文字の追認という意味もあり、規格制定後も前述の校正必携やルールブックの認識を変えるに至っていない弱点もありますが）。このほか写真植字の文字盤にも縦組み用の〝〟とは別に横組み用の〝〟（と〝〞）が用意されています（マイナビニュース連載「活字・写植・フォントのデザインの歴史 - 書体設計士・橋本和夫に聞く第28回写研での文字制作（3）フィルムをつくる」から「石井中明朝の文字盤(メインプレート) 」拡大画像）。

新聞では一般に〝〟は「どうしても必要な場合に限って使い乱用はしない」（『記者ハンドブック』第13版〈2016年、ISBN 9784764106871〉118ページ）とされている上、新聞紙面は縦組みが主体ですから、一般記事に横組みの〝〟はあまり見られません。『朝日新聞』東京本社版で見ると、2020年6月25日朝刊16面「TVランキング」に「〝お手本〟」、2019年10月31日朝刊15面「論壇委員が選ぶ今月の3点」に「▷古川美穂「なぜ普通の男性に〝痴漢スイッチ〟が入ってしまうのか」（婦人公論10月8日号）」といった用例があります。このほかラテ欄にはほぼ毎日複数の横組みの〝〟が見つかると思います。--Meme-Meme（会話） 2020年7月7日 (火) 14:29 (UTC)

@㭍月例祭さん、Meme-Memeさん: せっかくいろいろと調べて改定案をまとめてくださったので、Meme-Memeさんの「これらのうち “...” 以外の引用符は、和文では使わないでください。」という変更提案について合意を形成した上で、せめて「括弧の入れ子」節以外は刷新しませんか（「括弧の入れ子」節も合意を形成できればいいですが、上記の議論では結論が出ていないように思われます）。上記の議論でも入れ子に関するコメントがほとんどで、それ以外の変更点については反対がなかったと思います。--ネイ（会話） 2020年10月15日 (木) 12:03 (UTC)

ありがとうございます。

引用符の部分は、私の改定案では現状と何も変えていないです。今見ると、「さまざまな括弧の使い分け」や「丸括弧」に較べると、未整理な印象はありますね。たとえばですが下のような感じでまとめた方が明瞭になるかも。

名称	記号	解説
ダブルクォーテーションマーク（二重引用符）	"..."	英文で用いる直立タイプ	ダブルとシングルの使い分けは、イギリスとアメリカでも慣習に違いがあります。引用を表す以外にも、固有名詞、比喩、注釈、強調、反語など様々な目的で使用されます。（括られる対象を、引用符を用いずにイタリックで書くこともあります）
ダブルクォーテーションマーク（二重引用符）	“...”	上記の本来形
シングルクォーテーションマーク（一重引用符）	'...'
シングルクォーテーションマーク（一重引用符）	‘...’
	« ... »	仏文・西文で用いる
	‹ ... ›	仏文・西文で用いる
	‚...‘	独文で用いる
	„...“	独文で用いる
ダブルクオーテーションマーク以外の引用符は、（基本的には）和文では使わないでください。

少し時間があいて読み直して感じたことなんですが、おそらく、どのようなカッコ・引用符を使用するかは、その分野の慣習や情報源の著者の特性に委ねられていることが多いのだろうと思います。きっと、英文学に関する和書とかでは、ダブル・シングルのクォーテーションマークは普通に使われるでしょうし、もしかするとフランス文学に関する和書では« ... »が普通に使われているのかも。

{ }、[ ]、' ' あたりは、技術上の理由で、使用を注意する必要があります。うっかりテンプレートを呼び出してしまったり（Wikipediaならではの問題。）。また、単なる視覚効果のために（目立たせる意図で）【】だとかを使うべきではなく、適切なタグを使用すべき（HTML5の問題。）。

そうした技術的な観点からの制約を別にすると、分野次第・情報源次第、という面はあるのだろうと思います。重要なのは、１記事の中では用法に一貫性があることであって、分野の違う記事のあいだではスタイルがいくらか違うのはしょうがないんじゃないかなー、と思います。

入れ子については難しいですね。個人的には、「こうするべきだという意見と、こうするべきだという意見があって、いまのところ結論は出ていません」みたいにしておくのでもいいかな、と思います。--柒月例祭（会話） 2020年10月16日 (金) 02:46 (UTC)

柒月例祭さん、「括弧の入れ子」について疑問があります。上記ご提案の私案においても（現行ガイドラインでも）採用されている、「[ (〈〉) ] の順」という部分に違和感を覚えます。と言いますのも、一般に一重括弧の場合は「（）」を利用していて、二重括弧が問題となる場面では異なる種類の括弧を利用とすると、角括弧・大括弧「［］」が突如出てくるわけですよね。二重括弧の場合は「［○○○（○○○）］」となって、三重括弧の場合は「［○○○（○○○〈○○○〉）］」となる。四重括弧以上深い場合はどうするんだという疑問（それなら最初から同じ括弧で統一しておいた方がいい。たとえば法令（公職選挙法（第142条の3））みたいな複雑な条文）は置くとして、二重括弧以上の場合に異なる括弧を使うのだとふだん見慣れていない角括弧が一番外枠に使われることになるのがどうにも腑に落ちません。たったいまこちらの記事の編集を、括弧に着目して終えたばかりなのですが、本ガイドラインをよくよく見るまでは「[ (〈〉) ] の順」との表記部分の角括弧は引用符のつもりで書いてあるものとばかり勘違いしていて、「 (〈〉) の順」に使用するものだと解釈してしまい、その通り編集してしまいました。二重括弧の場合には、あえて見慣れていない角括弧を持ち出さずに、丸括弧と山括弧の併用という形式（つまり私案にもない第3の形式）も許容されるべきではないかと思うのですが、いかがでしょうか？--直蔵（会話） 2021年4月4日 (日) 13:04 (UTC)

返信あらためて整理すると

第1段階　　( 　　)

第2段階　　(〈〉)

第3段階　[ (〈〉) ]

こういう感じで内側に追加されたあと、外側に追加されるという順番になっています。一番最初の提案時に表明した通り、私もなんかヘンだなとは思いました。それは当初示したように、同じ用法なのにカッコの形が変わってしまうからです。（直蔵さんは「ふだん見慣れていない」ので違和感があるとおっしゃいましたけど、それはまあ見慣れるかどうかの問題だと思いますが）

ですが、この規定は

今までの規定通り（変更しない）
『朝日新聞の用語の手びき』で採用されている（Meme-Memeさんによる情報）ので外部的根拠がある

外部的根拠があるものを個人の「ヘンだな」という感覚だけで否定するのもちょっとね・・・というところだなとも思います。そのため、私の提案は既存の方式のほかに（（））のように同じカッコの入れ子もオッケーにしましょうというものです。そして様々な意見があるので、「いろいろな意見があります」と明記しておくというものです。（私は、現実世界で多様な方式があるものを、Wikipedia内で強制的に統一したり否定したりするのには不賛成。）

四重の場合はどうなんだとのことですが、おそらく（三重でもそうなんですが）そんなにカッコが入れ子になるような文章を見直せという話だとおもいます。--柒月例祭（会話） 2021年4月4日 (日) 17:38 (UTC)

「使用可能な文字」の制限緩和提案[編集]

Wikipedia:井戸端/subj/WP:NCにおけるJIS X 0208規定の撤廃について、Wikipedia:井戸端/subj/Unicodeの基本多言語面にない文字をタイトルに含むページの作成解禁に向けてにて、一部の例外を除き、JIS X 0212・JIS X 0213・IBM拡張漢字が使用可能となりました。これを受け、Wikipedia:表記ガイド#項目名も既に修正されております。
記事に適用されるWikipedia:表記ガイド#使用可能な文字についても、「項目名」の規定より厳しい状態では矛盾しているので、下記のように修正することを提案します。

現行

Unicodeで規定されている文字に必要なものがあれば、すべて使うことができます。ただし、JIS X 0201のラテン文字類にもJIS X 0208にも規定されていない文字は、できるだけ使わないようにしてください。

ラテン文字（英字）やアラビア数字など、JIS X 0201のラテン文字類（いわゆる半角英数字）で規定されているものはそれを用います。そうでない漢字・平仮名・片仮名などは、JIS X 0208に規定されているもの（いわゆる全角文字）があればそれを用います。JIS X 0201の仮名文字類（いわゆる半角カナ）は使わないでください。
JIS X 0201のラテン文字類の記号のなかには、場合によっては全角形を用いる必要があるものや、全角形を用いてよいか意見が分かれているものもあります。詳細はそれぞれの記号についての説明を参照してください。

空白は欧文間隔（いわゆる半角空白）“ ”(SPACE U+0020) を用います。和字間隔（いわゆる全角空白）“　”(IDEOGRAPHIC SPACE U+3000) はウィキペディアの記事本文・記事名・カテゴリのソートキーでは使用しないでください。これは、ブラウザによっては全角の場合に適切に割り付けが行われないからです。

なお、Windows-31Jに収録されている特殊文字、および、ベンダ選定漢字は、Unicodeの基本多言語面 (BMP) 上にすべて登録されていますが、Unicode用フォントを取り揃えていない環境から閲覧される場合の便などを考え、なるべく使用しないのが望ましいです。特殊文字を使用する場合はHelp:特殊文字をご覧ください。

修正案（太字部）

Unicodeで規定されている文字に必要なものがあれば、すべて使うことができます。ただし、JIS X 0201のラテン文字類、JIS X 0212、JIS X 0213、IBM拡張漢字、CJK統合漢字（﨎﨏﨑﨓﨔﨟﨡﨣﨤﨧﨨﨩の12文字）のいずれにも規定されていない文字は、できるだけ使わないようにしてください。

ラテン文字（英字）やアラビア数字など、JIS X 0201のラテン文字類（いわゆる半角英数字）で規定されているものはそれを用います。そうでない漢字・平仮名・片仮名などは、JIS X 0212・JIS X 0213に規定されているもの（いわゆる全角文字）があればそれを用います。ただし異体字については固有名詞などを除きJIS X 0208に規定されているものを優先してください。JIS X 0201の仮名文字類（いわゆる半角カナ）は引用など特殊な場合を除き使わないでください。
JIS X 0201のラテン文字類の記号のなかには、場合によっては全角形を用いる必要があるものや、全角形を用いてよいか意見が分かれているものもあります。詳細はそれぞれの記号についての説明を参照してください。

空白は欧文間隔（いわゆる半角空白）“ ”(SPACE U+0020) を用います。和字間隔（いわゆる全角空白）“　”(IDEOGRAPHIC SPACE U+3000) はウィキペディアの記事本文・記事名・カテゴリのソートキーでは使用しないでください。これは、ブラウザによっては全角の場合に適切に割り付けが行われないからです。

なお、Windows-31Jに収録されている特殊文字、および、ベンダ選定漢字は、Unicodeの基本多言語面 (BMP) 上にすべて登録されていますが、Unicode用フォントを取り揃えていない環境から閲覧される場合の便などを考え、なるべく使用しないのが望ましいです。特殊文字を使用する場合はHelp:特殊文字をご覧ください。

私用領域の文字（いわゆる外字）、Unicodeの基本多言語面（BMP）外に配置されている文字、Unicodeの合成文字（例：「カ゚」U+30AB・U+309A、JIS X 0213では1-5-87）、CJK統合漢字を除くCJK互換漢字は、閲覧される環境により正常に表示できない場合がありますので、なるべく使用しないか、使用する場合は代替表記を併記することが望ましいです。

ご意見よろしくお願いします。--Suz-b（会話） 2020年6月26日 (金) 16:00 (UTC)

技術的な面で私の知見では追いつかないのと、先行議論を熟読するのがしんどいので（ななめ読み）、気になったことを書き留めるだけにしておきます。先行議論は専ら、昨今の様々な環境で適切に意図通り表示されるのか、に絞って検討されたようにみえます。私は、画面上で文字が表示されるとして、読み上げソフトなどでどの程度意図通りに挙動（読まれる）のかなあ？というのがちょっと気になりました。先行議論をななめ読みした印象では、その点についてはあまり検討されていないような気が。いまさらこんな事を言うのはアレかもしれませんが。単に私の知識不足で、JIS X 0208の文字はたいがい読み上げられるよ、ということかもしれないのですが。読み上げソフトも日々進化するのでしょうけれど。たとえば{{読み仮名}}で適切な読み仮名を補う、などもあわせて紹介／推奨すると親切では。
この観点で、Wikipedia:アクセシビリティ#翻字の内容についても再検討を要するはずです。
いまのところはハシゴ高とか立つサキとか、ポピュラーな異字体で修正が多く行われている印象で、その程度であれば多くの日本語話者は困らないだろう、とは思うのですが、過度に異字体に拘ると「正確なのかも知れないが読めない」「検索できない」的なことも起きそうで、「使用可能ではある」けど「抑制的にね」的なメッセージもあったほうがいいんじゃないかなー、と感じます。--柒月例祭（会話） 2020年6月26日 (金) 16:48 (UTC)
- 私も、一定の配慮については必要だと思います。最近のモバイル環境やテキストリーダの事情はよく分からないのですが、それらの環境は千差万別ですから思わぬところで制限が残っていないとも限りませんので（ただし基本的には該当する環境の人が率先して声をあげるべき問題だとは思います）。百科事典では正確な表現が不可欠ですから重要なところには特殊な文字であっても使わなければなりませんので、記事名については正確な記述の優先度は高いほうなのかなとは思っています。ただ使ってよいからといって配慮しなくてよいかは別問題で、記事本文ではカッコ付きで字体の説明を加えたり、{{特殊文字}}で注意喚起したりと、最低限のフォローはできますし、そもそも文章的な工夫で使用個所を減らしたりもできるわけですから、そのへんの配慮はなるべく忘れないようにはしたいです。--Gwano（会話） 2020年6月29日 (月) 09:10 (UTC)

コメント 自分のことだけを考えれば、私は緩和推進派です。しかし現実を考えるとJIS X 0212はサポートしない環境があり、日本語の文字集合として考えるには疑問が多いので、JIS X 0212を基準に組み入れるのには、あまり賛成しません。日本語の範囲としてはJIS X 0201のラテン文字類、 JIS X 0213、IBM拡張文字を合わせた文字集合辺りを目安にするとよいのではないかと思います。
「Windows-31Jに収録されている特殊文字、および、ベンダ選定漢字」はIBM拡張文字のことですが、Classic Mac OSやフィーチャーフォンのことを考慮する必要がなくなった今、表示という面だけで考えればこれらを避ける必要は、ほぼ不要になったと考えられます。
「CJK統合漢字（﨎﨏﨑﨓﨔﨟﨡﨣﨤﨧﨨﨩の12文字）」の部分は誤解を受けやすい言い方です。この12文字は〈CJK互換漢字ブロックにあるCJK統合漢字〉であり〈JIS X 0213収録字〉または〈IBM拡張漢字〉です。CJK統合漢字は拡張Gまで含めると9万5380字あり、BMP内の統合漢字に限っても2万7583字です。この12文字以外のCJK互換漢字ブロックにある文字をウィキペディアなどに直接書き込もうとすると正規化され異体字になってしまうので（「福」「益」が「福」「益」になる）、どうしてもその形が必要ならば数値文字参照の形（「福」「益」）などで書き込まないといけません。CJK互換漢字は、数値文字参照を知らない人には使えない文字ということになります。記事名とは違って、12文字には触れず、互換漢字がそのままでは使えないことを説明した方がいいと思います。
私用領域の文字は「なるべく使用しない」ではなく、「絶対に使用しない」くらいでよい性格のものです。これらの文字は外字ですから、コードポイントに対する文字が定まっていません。不特定の閲覧者がいる環境では、執筆者の意図が分からなくなる分、環境によって技術的に表示できないかもしれない文字（BMP外や合成文字の類い）よりも重大な問題です。すでに「渤海 (国)」項の「言語と文字」節では、私用領域の文字が使われているため執筆者と同じフォントがない人には読めない箇所が点在する問題が起こっています。
アクセシビリティーは難しい問題ですが、ウィキペディアがJIS X 0208以外の文字を使っていくと、用例がが蓄積され、将来的にこういった面でアクセシビリティーが改善していくという面もあるのではないかと思います。--Meme-Meme（会話） 2020年6月29日 (月) 16:33 (UTC)

報告㭍月例祭様、Gwano様、Meme-Meme様、ご意見ありがとうございます。可読性、検索性への配慮に関しては追加した方がよさそうですね。最後のご意見から2週間経過しましたが新たな意見がなく、JPWP全体に関わることですので、Wikipedia:コメント依頼を提出させていただきました。他にもご意見をいただけてから再修正案を作成したいと考えております。--Suz-b（会話） 2020年7月21日 (火) 17:10 (UTC)

コメント コメント依頼からやって来ました。Suz-bさんがご提示された修正案につきましてはおおむね賛成です。ただし、Meme-Memeさんのご意見と同じく、JIS X 0212は必ずしも組み入れる必要がない（JIS X 0213でカバーできる）というのと、外字についての制限をもっと厳しく謳っても良いのではないか、と思います。また、最後の項目の説明が若干不十分に感じましたので、ちょっとくどいかもしれませんが具体例を追記してみました。

以下に該当する文字は閲覧される環境により正常に表示できない場合がありますので、なるべく使用しないか、使用する場合は代替表記を併記することが望ましいです。
Unicodeの基本多言語面（BMP）外（U+10000 以降）に配置されている文字
例：「𠮷」U+20BB7（「吉」の上半分が「土」）

Unicodeの合成文字
例：「カ゚」U+30AB・U+309A（JIS X 0213では1-5-87）

CJK統合漢字を除くCJK互換漢字
例：「塚」U+FA10（「塚」の旧字体）

私用領域の文字（いわゆる外字）は使用しないでください。私用領域の文字は閲覧者が自由に割り当て可能なため、ご自分の閲覧・編集環境以外では正常に表示できない可能性がきわめて高いです。

もし誤り等がございましたらご指摘ください。また、編集で外字を使った場合は編集フィルターで警告を出しても良いかと思います。--茶でもすするか（会話） 2020年8月2日 (日) 08:46 (UTC)--マークアップ修正 --茶でもすするか（会話） 2020年8月2日 (日) 09:23 (UTC)

もう一つ追加します。Unicodeの基本多言語面外の文字には多数の絵文字が登録されていますので、以下のような案内を追加することを提案いたします。

絵文字をアイコンとして使う場合は、画像による表示を検討してください。
例：「🚻」U+1F6BB（トイレの記号） → [[File:Emoji u1f6bb.svg|16px]]

例：「🇯🇵」U+1F1EF・U+1F1F5（日本の国旗） → {{Flagicon|JPN}}

--茶でもすするか（会話） 2020年8月2日 (日) 09:23 (UTC)

最後の意見から1か月以上が経過しました。これまでいただいたご意見を反映し、修正第二案を作ってみました。

修正第二案

Unicodeで規定されている文字に必要なものがあれば、すべて使うことができます。ただし、JIS X 0201のラテン文字類、JIS X 0213、IBM拡張漢字のいずれにも規定されていない文字は、できるだけ使わないようにしてください。

ラテン文字（英字）やアラビア数字など、JIS X 0201のラテン文字類（いわゆる半角英数字）で規定されているものはそれを用います。そうでない漢字・平仮名・片仮名などは、JIS X 0213に規定されているもの（いわゆる全角文字）があればそれを用います。ただし異体字については固有名詞などを除きJIS X 0208に規定されているものを優先してください。JIS X 0201の仮名文字類（いわゆる半角カナ）は引用など特殊な場合を除き使わないでください。
JIS X 0201のラテン文字類の記号のなかには、場合によっては全角形を用いる必要があるものや、全角形を用いてよいか意見が分かれているものもあります。詳細はそれぞれの記号についての説明を参照してください。

JIS X 0208に規定されていない異体字を使用すると、検索一致しない、読み上げソフトが対応しない等の事象が起こる可能性があります。異体字は必要以上の使用を避け、必要に応じて代替表記で記述もしくは併記する、カッコ付きで字体の説明を加える、{{読み仮名}}や{{特殊文字}}を利用する等の配慮を心がけてください。

空白は欧文間隔（いわゆる半角空白）“ ”(SPACE U+0020) を用います。和字間隔（いわゆる全角空白）“　”(IDEOGRAPHIC SPACE U+3000) はウィキペディアの記事本文・記事名・カテゴリのソートキーでは使用しないでください。これは、ブラウザによっては全角の場合に適切に割り付けが行われないからです。

以下に該当する文字は閲覧される環境により正常に表示できない場合がありますので、なるべく使用しないか、使用する場合は代替表記を併記することが望ましいです。これらの特殊文字に関してはHelp:特殊文字もご覧ください。
Unicodeの基本多言語面（BMP）外（U+10000 以降）に配置されている文字
例：「𠮷」U+20BB7（「吉」の上半分が「土」）

Unicodeの合成文字
例：「カ゚」U+30AB・U+309A（JIS X 0213では1-5-87）

CJK統合漢字を除くCJK互換漢字
例：「塚」U+FA10（「塚」の旧字体）

絵文字をアイコンとして使う場合は、画像による表示を検討してください。
例：「🚻」U+1F6BB（トイレの記号） → [[File:Emoji u1f6bb.svg|16px]]

例：「🇯🇵」U+1F1EF・U+1F1F5（日本の国旗） → {{Flagicon|JPN}}

私用領域の文字（いわゆる外字）は使用しないでください。私用領域の文字は閲覧者が自由に割り当て可能なため、ご自分の閲覧・編集環境以外では正常に表示できない可能性がきわめて高いです。

この案で問題なければ、1か月後を目途に反映させたいと考えます。ご意見よろしくお願いします。--Suz-b（会話） 2020年9月18日 (金) 19:59 (UTC)

完了 1か月ほど経過し、異論ありませんでしたので反映を完了しました。--Suz-b（会話） 2020年10月25日 (日) 15:52 (UTC)

雑談　この場合は半角？全角？[編集]

弁天島 (稚内市)という記事で迷ったのでほかの方のコメントを頂きたく思います。

いまのガイドでは次のようになっています。（Wikipedia:表記ガイド#丸括弧・波括弧・角括弧）

（ア）括弧の中にいわゆる半角の文字だけがある場合は、いわゆる半角の括弧を用います。
（イ）括弧の中にいわゆる全角の文字のうち、漢字・仮名・和文記述記号がある場合は、全角形の括弧を用いるべきだという意見と用いないという意見の2つがあり、目下の合意はありませんが、ページ内での表記は一方に統一するように合意がされています。

記事では

「宝物を入れる箱」（ないしは「首飾りなど入れる箱」）
「ウェントマリ」（悪い泊地）

のように全角カッコが用いられています。これらはいずれもカッコ内に全角文字かつ漢字・仮名などがあるので（イ）に該当しています。

そのあとで次のような箇所があります。

「ソーヤ」 (so-ya) はアイヌ語で「岩嶼」「磯岩の岸」の意味
ソヤ (soya) ^[11]に由来する

この場合、soyaやso-yaは、半角文字だけなので、（ア）にしたがうと半角カッコとなります。ですがそうすると、一記事中に全角と半角が混在することになります。これはちょっと塩梅がよくないと思うのです。

いわゆる数式オンリーの場合や、まるっと英文などの場合に、（ア）に基づき半角カッコで統一するのはよいと思います。

ですが今回のケースでは、soyaが半角としても、文章全体としては「ソヤ (soya)に由来する」のように和文の中に組み込まれており、（ア）を適用するのはなにかヘンだと思うのです。全体としては、記事のほかの箇所との統一性、和文中に用いられている、などの事情で、すべて全角（）で統一するのがいいのではないかな、と私は感じたのですが、それだと（ア）には抵触します。

今回の（）は、原綴ないし発音を示したもので、たとえば「魚（英:fish）」みたいに書くとしたら、「英」などの文字が入るのでカッコは全角になりますよね。これを「ソーヤ」（アイヌ語：so-ya）だとすると全角（）で問題ないでしょう。ただ、アイヌ語は文字を持たないのでまたちょっと話がややこしいですが・・・。

さらにたまたま、カッコの前後に「」やrefの^[11]があり、カッコとカッコが連続するため、半角カッコを採用すると余計にややこしいことにもなっています。

基本的なこととして、半角カッコの場合に、前後に半角スペースを挿入するのは、もっぱら「和文の中では、そうしないと見にくい・読みにくいため」だろうと思っています。もしこの場合半角カッコを用いると「ソヤ_(soya)_に由来する」となり、だったらもう全角で「ソヤ（soya）に由来する」でいいんじゃないのかな？とも思います。

半角／全角をめぐっては過去にいろいろ論争があったことなので、意見が分かれるかもしれないですが、どうしたらいいでしょう？--柒月例祭（会話） 2021年1月7日 (木) 07:14 (UTC)

これは曖昧さ回避と同じで解決済みのものが文書の記述のみ放置されているタイプの案件であろうと考えます。半角括弧は「数式」「欧文（「コード」を含む）」に用いるのが原則で、和文中に「括弧」「半角」「括弧」が存在しているならそれは「和文の一部としての半角」であって、全角を用いるのが原則でしょう。これをあえて半角とするのは「どうせ中が半角だから面倒」という気持ちはわかる、わかるけど結局その前後は全角でしょうと突っ込みたくなるところと、現実から遊離している方針文書の暴走（全部和文だけど文書にあるから括弧だけわざわざ半角）によるものと考えます。そしてその原因は、文ではなく括弧内部に基準があり、完全な和文ですら半角が選択対象に残っていることです。

というわけで、改訂案を考えました。

現行

丸括弧・波括弧・角括弧
:Unicodeでは、丸括弧 (……)・波括弧 {……}・角括弧 [……] にはいわゆる半角のもの（JIS X0201で規定されているもの）のほかに、全角形の（……）・｛……｝・［……］が規定されています。
:括弧の中にいわゆる半角の文字だけがある場合は、いわゆる半角の括弧を用います。
:括弧の中にいわゆる全角の文字のうち、漢字・仮名・和文記述記号がある場合は、全角形の括弧を用いるべきだという意見と用いないという意見の2つがあり、目下の合意はありませんが、ページ内での表記は一方に統一するように合意がされています。

改訂案

丸括弧・波括弧・角括弧
:Unicodeでは、丸括弧 (……)・波括弧 {……}・角括弧 [……] にはいわゆる半角のもの（JIS X0201で規定されているもの）と全角形の（……）・｛……｝・［……］（JIS X0213で規定されているもの）が規定されています。
:固有名詞、略称などの単語自体に用いられている括弧は規定されている物を使用し、規定がない場合には文字種に依存します。
:本文がいわゆる全角の文字で構成されている場合には、半角文字の使用・括弧内の文字種を問わず全角の括弧を用います。
:括弧を含む全文がいわゆる半角の文字だけで構成されている場合は、いわゆる半角の括弧を用います。
:括弧内部の文・記号でさらに括弧が必要となる場合には、括弧の内部を文と見なして判定します。

要点は簡単で、固有名詞等を優先する規定と括弧の中の括弧の基準を追加、これまで括弧の中に依存していた区別を括弧を含む文＝括弧の外側に変更するだけです。この文章を適用した場合のイメージとしては以下のようになります。赤が全角括弧です。

例
想定ケース	構造	現行	改訂案
固有名詞など	単語に含まれる括弧	規定無し	単語に合わせる
和文中の欧文表記補足	全角文括弧半角括弧全角文	全角文 (半角) 全角文	全角文（半角）全角文
和文中の補足や読み仮名	全角文括弧全角括弧全角文	全角文 (全角) 全角文、全角文（全角）全角文	全角文（全角）全角文
数式に用いる括弧	半角文括弧半角括弧半角文	半角文 (半角) 半角文	半角文 (半角) 半角文
引用された英文中の括弧内漢字表記	半角文括弧全角括弧半角文	半角文 (全角) 半角文、半角文（全角）半角文	半角文 (全角) 半角文
和文中に引用された欧文に含まれる括弧	全角文括弧半角文括弧半角括弧半角文括弧全角文	規定無し	全角文（半角文 (半角) 半角文）全角文
引用された欧文に含まれる和文中の括弧	半角文括弧全角文括弧全角括弧全角文括弧半角文	規定無し	半角文 (全角文（全角）全角文) 半角文

事実上現行の運用を追認するものでしかありませんが、いかがでしょうか？--Open-box（会話） 2021年1月17日 (日) 03:53 (UTC)

ちょっと手直しして提案にします。--Open-box（会話） 2021年1月23日 (土) 15:06 (UTC)

丸括弧・波括弧・角括弧運用の変更提案[編集]

上記の経緯を踏まえまして、括弧の判定基準を括弧の中から外に変更することを提案します。

現行

丸括弧・波括弧・角括弧
:Unicodeでは、丸括弧 (……)・波括弧 {……}・角括弧 [……] にはいわゆる半角のもの（JIS X0201で規定されているもの）のほかに、全角形の（……）・｛……｝・［……］が規定されています。
:括弧の中にいわゆる半角の文字だけがある場合は、いわゆる半角の括弧を用います。
:括弧の中にいわゆる全角の文字のうち、漢字・仮名・和文記述記号がある場合は、全角形の括弧を用いるべきだという意見と用いないという意見の2つがあり、目下の合意はありませんが、ページ内での表記は一方に統一するように合意がされています。

改訂案

丸括弧・波括弧・角括弧
:Unicodeでは、丸括弧 (……)・波括弧 {……}・角括弧 [……] にはいわゆる半角のもの（JIS X0201で規定されているもの）と全角形の（……）・｛……｝・［……］（JIS X0213で規定されているもの）が規定されています。
:固有名詞、略称などの単語自体に用いられている括弧は規定されている物を使用し、規定がない場合には文字種に依存します。
:数式、化学式に用いられる括弧は半角を用います。
:本文がいわゆる全角の文字で構成されている場合には、半角文字の使用・括弧内の文字種を問わず全角の括弧を用います。
:括弧を含む全文がいわゆる半角の文字だけで構成されている場合は、いわゆる半角の括弧を用います。
:括弧内部の文・記号でさらに括弧が必要となる場合には、括弧の内部を文と見なして判定します。

上記の案に数式・化学式を確定で半角括弧として加えたものです。--Open-box（会話） 2021年1月23日 (土) 15:06 (UTC)

（1つ上の「入れ子」の改定の話も放置してしまっていて心苦しいのですが）個人的には、現行の「多様な意見・様々な状況があって完全な統一基準の採用に至っていません」という書き方は、私はいい感じと思っています。この件に限らないですが「何も考えずに機械的かつ粗雑に書き換えるタイプ」がいやなので。「いろいろ難しい問題なんですよ」という。お示しの案だと、ガチガチの「絶対基準」みたいな感じになるのが、なんかいやです。。。「ただし」とか「場合によっては」「いろんな場合があるんだよ」みたいな余地は残しておいてほしいなとは思います。（過去にいろいろ揉めたことだ、というのも踏まえて。）
私は文系なので、理系分野のことはちょっと想像がつかない面もあるのですが、数式以外でもコンピュータ・プログラムの文脈とか、楽譜や音楽関係とか、生物の学名とか、なにかしら各分野毎の常識・慣行もあるだろうと思うので、融通のきかない制約はなんかいやだなあとも思います。
基本的な考え方として、各論の前に「なぜそうする必要があるのか」を示すのが理想的だと思うんですよね。今回の件では関係ないかもしれないですが、たとえばカッコを全角にするのと半角にするのとでは、読み上げソフトの挙動やhtml解釈の点で影響があるんだとか。それとも単に見た目だけの問題なのか。少なくとも、半角の[]と{}は、Mediawikiの技術的にリンクを作るのに使うからただの文章のつもりで使うと意図せぬ挙動を起こす可能性があるので注意する必要はある。（Wikipediaでは関係ないが、紙の印刷物なんかでは、和文のなかに半角文字を使用すると文字の行・列のタテヨコがずれちゃったりするので、それを嫌って全角の数字や記号を使うこともある。）
たとえば大方針として「1つの記事の中では、方式が統一されているのが望ましい」とか。ただしここでいう「方式が統一」というのは、「この記事は全て全角にしろ」ということではなくて、「もっぱら日本語で説明する文章部分は全角カッコを使い、数式部分では半角を使う」とか「同じ（）でも、読み方を補うときは全角カッコで、西暦を補うカッコの場合だけは半角に統一」みたいな混在でもいい。うまく簡潔端的にまとめられないのですが、「1記事のなかでの、同じような用法の場合には同じような方式で揃える」みたいな。
たとえば（）にしてもWikipedia:表記ガイド/括弧改定案20200529#丸括弧で例示した「1 番号などを括る」の用法の場合には、記事の文章部分とは別物とみなして、全角半角混在でも別にいいんじゃないのー？は思います。こんな感じで→（1）(ア)
「固有名詞、略称」のところに、「引用部分」もいれておいてはどうでしょう。
「本文」とか「全文」のあたりで、「機械的に書き換えるタイプ」が問題を起こしそうな予感がします。どこまでが「本文」「全文」なんだとかね。どう表現すればいいのかは簡単には思いつかないのですが。。。--柒月例祭（会話） 2021年1月23日 (土) 16:16 (UTC)
とりあえず、「改訂案」を一読した時点で、「分かりにくい」と感じました (わたしの読解力の問題かもしれませんが)。文章にすると条件が複雑入り組んでいるように見えます。このガイドラインは、初心者も含めたすべての編集者が参照すべきものなので、それはちょっとまずいんじゃないかなと思います。

以下はあくまでも個人的な好みについての意見です。発言者はこれが反対の有力な根拠であるとは考えておりません。^追記個人的には、むしろ全部半角に統一するほうがいいんじゃないかと考えています。好みの問題で表示フォントにも左右されますが、同じ方向の括弧が連続する場合 (「ほげほげ（foobar）」) や括弧の直後に句読点が来る場合に (（ほげほげ）。) 隙間が開くのには違和感を覚えます。とくに表中なんかだと、「このスペースさえなければ、スッキリするのに！」と感じることは多々あります。

好みの問題なら閲覧時のCSSで対応すればどうかなと思ったんですが、font-feature-settings: "palt";はたとえば「ほげほげ（foobar）」と仮名漢字との間のスペースも字詰めしてしまうみたいなんで、帯に短し襷に長しといった感じです。JSで対応するのは可能そうですが、そこまでするのもなあという気がします。--Jutha DDA（会話） 2021年1月24日 (日) 15:38 (UTC)

ご意見有り難うございます。書きかけですがひとまず少しだけ。

㭍月例祭さんへ

『「いろんな場合があるんだよ」みたいな余地』を残した結果、「機械的に書き換えるタイプ」に現在の文書で既にそのタイプが問題起こしているばかりか、根拠を与えちゃってるので対等扱いではなく原則ぐらいにはした方が無難かなと。

半角の[]と{}は<nowiki></nowiki>の使い方の説明になるので、もっと上で説明しないとだめじゃないかなと思います。

引用は加えた方がいいですね。

JuthaDDAさんへ

これ現在の運用を文書化しただけのものなんですね。少なくとも文書に従うと間違いだらけになる現行よりは改善されていますが（実際には無視してきてますけど）。わかりやすくするなら一見例外に見える優先事項を後回しにすればいいんですけれど（要は「全角文中括弧は全角で半角文中括弧は半角」って書くだけで終わり）、それやると必ず悪用されるのが･･････。

「全部半角に統一」元々半角括弧を強制してきたことで全角を機械的に半角にする日本語として不自然な表記を強要するトラブルが多発した結果、全角が使えるようになったにもかかわらず、半角の強要に正当性が与えられている文章が残ったままなのが現状です。その提案は、この文書が成立した当時の問題だらけの運用に戻せという要求です。結果発生するのは、無制限の編集合戦と妨害行為の正当化でしかありません。

「好みの問題なら」好みの問題として半角が生き残ってきたのがこの文書がトラブルを起こす主たる原因なのでなかなかそうはいかなかったり。--Open-box（会話） 2021年1月25日 (月) 01:16 (UTC)

返信 Open-boxさん、ご説明いただきありがとうございます。なるほど、経緯としては納得がいきます。あとはまさに「好みの問題」なので、とくに反対するつもりはないことを表明しておきます。

となると、やはり好みの問題については、閲覧時のスクリプトなりで対応するのが適当かなと思います。似たようなスクリプトは作成したことがあるので、同様の好みの方が多いようであれば、カスタムJSないしガジェットの作成も検討したいと思います（考えてみれば、CSS+JSだと鉤括弧などにも対応できるので、中途半端に半角丸括弧などで対応するよりも、見た目の問題としてもこちらの方が適当ですね）。

ボットによる置換やスクリプトによる表示の変更などまで想定するのなら、もっと詳細（たとえばUnicodeのX-Yの文字を含む場合は云々）にしたほうがいいように思います（解釈の余地が少ないほど、編集合戦なども防げるでしょうし）。そのうえで、初心者向けにできるだけ簡潔にした要約も併記するのがわかりやすいんじゃないでしょうか。--Jutha DDA（会話） 2021年1月25日 (月) 03:54 (UTC)

現行の日本語版における運用の追認として、半角・全角の基準を括弧の内側から外側とする提案には賛成いたします。半角文字で構成される欧文や、数式・化学式における半角括弧の規定も問題はないと思いますが、漢字や仮名を使う日本語や中国語と異なり、ハングルを使う朝鮮語/韓国語では分かち書きを行う都合か半角括弧が使用されている印象があります。現在の改訂案を適用するとハングルを全角文字とみなして朝鮮語/韓国語の文章に含まれる半角括弧が全角括弧に置換されるおそれがあり、「括弧を含む外国語の文章を引用する場合、括弧を半角または全角にするかはその言語における記法に従う」のような例外が必要になるかと思われます。

また現在使用されている{{Sfnp}}や{{Cite web}}などの出典テンプレートではdateなどを括る際に半角括弧が使用されていますが、和文において全角括弧を原則とする場合、これらも改定の影響を受けるのでしょうか。--火乃狐（会話） 2021年1月26日 (火) 17:10 (UTC)

返信 1つめのハングル（外国語）については、「引用」で捕捉できます。新たに例外規定を設ける必要はなく、「固有名詞、略称、引用の場合」で事足りるでしょう。

2つめの既存のテンプレートについては、現時点では「影響なし」としておくほうが無難と思います。話を広げすぎると収拾がつかなくなるでしょう。Cite系テンプレートなどは、英語版から持ち込まれているものも多く、全半角の変更はテンプレートそのもの改変を要する場合もあるでしょう。Cite系テンプレートが出力する文字列は、たいていは脚注部など「記事の本文」とは区別された箇所に表示されることになり、そこは別扱いでいいのではないでしょうか。情報源に外国語文献を使っている場合とかも多くあり、いろいろ難題があります。個人的には、出典の題名に全角の記号や数字があるのを、半角に書き換えることにこだわっている利用者とかもいて、私は「非生産的だなあ」と感じたりします。

現実社会でも、カッコに限らず、「好み」「慣習」で全角派と半角派がいます。雑なレッテル貼りをすると、理系分野の方は記号類は半角を常用する傾向があって、たとえば句読点も「、。」ではなく「,.」を好みますよね。文系でも、外国語文献にあたることが多いであろう法学や社会学系・西洋文学系と、国文学や日本史関係者では違うでしょう。論文も国文学や日本史の論文は縦書きが多いし、他分野は横書きが多い。たとえば私の経験では、和歌や俳句などの区切りの全角スペースを半角スペースに書き換えているのを見ると、さすがにそこは全角スペースがベターじゃないの？と思ったりもします。

Open-boxさんのご提案は、基本的な考え方として「カッコ内の文字列基準」から「カッコの外側の文字列を基準」に変更するものです。大原則としてはこの通りで、あとは分野ごとの例外や慣習などを考慮して必要に応じてローカルな合意を個別にとりつければいいでしょう。--柒月例祭（会話） 2021年1月27日 (水) 06:03 (UTC)

（閑話）実は、「,.」は「,。」って亜種（公文書）もあるんですが、これは今年ようやく解消されそうな動向です（文化庁が鈍かったとも）。

ハングルは「,.」だったりしますしね。ただ、これは引用でいけるでしょう。

読み上げソフトのことを考えると、{{lang|en|}}が大量に必要になる問題が潜んでいたりします。

テンプレートは、影響あり／なし以前の問題がありまして･･････そもそも同系統のテンプレートでこの問題以前に表記バラバラってどうなってるのかと（{{Cite}}系がひどいと思う）。そこ扱ってからじゃないと進まないと思いますし、扱うときに自然と決まるかと思いますが、全角半角を限定できない性格のものが多いので、少なくとも「( )」を「_( )_」にして欲しいですね。

出典の全角／半角は例外として触らない方がいいと思います。逆に筆者とか出典名（掲載誌など）はどんどん翻訳した方が良かったりしますので（例えば、ニューヨーク・タイムズに掲載されたものを出典に限ってThe New York Timesと書く必要は無いでしょう）、出典は出典で独立した表記ガイドが必要なのかも。

（閑話っぽいものしかないのはまずいので）原則を先に出して、優先順位の高い例外事項を後の方がわかりやすそうですね。ちょっと並べ替え検討してみます。--Open-box（会話） 2021年1月27日 (水) 16:34 (UTC)

テンプレートについては、language系のパラメーターである程度場合分けできそうですが、{{cite book}}の「和書」はともかくとして他のテンプレートについては入力しない人が多そうですし、難しいところですね。

出典の雑誌名などについては、他言語版からの翻訳の場合はそのままにする人が多いと思われるので、表記揺れを少なくするという点からするとThe New York Timesなどと原語表記にしたほうがいいようにも思います。下手にガイドライン化すると、あまり詳しくない人がNew Yorkをニューヨーク・タイムズとしてしまうようなトラブルとかも発生しそうですし。--Jutha DDA（会話） 2021年1月27日 (水) 16:53 (UTC)

返信 (柒月例祭さん、Open-boxさん宛) ウィキプロジェクトなどで「ハングルでの既定の括弧は半角」のような合意がされていれば大丈夫のようですね。ご教示いただきありがとうございます。

出典テンプレートについては現状維持ということで了解しました。なお筆者や出典名の翻訳については、Jutha DDAさんのおっしゃるように誤訳のおそれがあるほか、（併記されていない場合）元の綴りやタイトルが分からなくなる、和文出典（翻訳書など）と区別がつかなくなる、などのデメリットもあると思います。--火乃狐（会話） 2021年1月28日 (木) 03:15 (UTC)

（閑話）皆様が懸念されているパターンですと実は、「出典タイトルを翻訳」ってのが厄介なんです。日本語で出典タイトルが翻訳されてる→遷移したら外国語ってなりますので。日本語と間違えるってのは韓国触ってると日本語版記事が多いのでよくありますよね。日韓両方使うスタイルだとなおさら。誤訳の懸念については、記事があるものをそのままってのはそれはそれでってのと、誤訳以上に同名の問題があるので、もうこれはケースバイケースですかね。こちらは翻訳時にたまに遭遇するのですが、誤訳よりも意訳（翻訳としては正しいが指すものが違う）が危なかったりします。--Open-box（会話） 2021年2月14日 (日) 17:14 (UTC)

長らくお待たせして申し訳ありません。議論が2週間以上停止したので、皆様のご意見を取り入れた改定案を作成しました。

改訂案

丸括弧・波括弧・角括弧
:Unicodeでは、丸括弧 (……)・波括弧 {……}・角括弧 [……] にはいわゆる半角のもの（JIS X0201で規定されているもの）と全角形の（……）・｛……｝・［……］（JIS X0213で規定されているもの）が規定されています。
:原則として括弧の種類は本文の文字種に合わせます。
:括弧内部の文でさらに括弧が必要となる場合には、括弧の内部を文と見なして判定します。
:引用、固有名詞、記号、略称などの単語自体に用いられている括弧は規定されている物を使用し、規定がない場合には文字種に依存します。
:数式、化学式に用いられる括弧は半角を用います。
:外国語の括弧は、その言語の記法に従います。
:[[:Category:出典テンプレート|出典テンプレート]]には適用されません。

まずJutha DDAさんのご懸念を考慮して原則の並びを変更しました。初期の提案では原則各種が並んでいたものを、原則とその特例という形式にしてあります。これに伴い、表記を簡略化しました。また、括弧内部の記号については特例を優先するために固有名詞の節に移しました。固有名詞の節に、㭍月例祭さんが指摘された引用を加えました。火乃狐さんのケースですが、「引用ではない」可能性を考慮して「外国語」として独立させました。また、出典テンプレートは解決する問題が別途多々あるため、適用除外としました。--Open-box（会話） 2021年2月14日 (日) 17:14 (UTC)

コメント かなり読みやすくなったと思います。一点付け加えるなら、「原則として括弧の種類は本文の文字種に合わせます（たとえば本文が日本語の場合は全角括弧を用います）。」としたほうが、普段日本語文でも半角括弧を使われている方にも一読して分かりやすいのではないかなと感じます（下に別途例示をするなら冗長かもしれませんが）。

あと気になったのは、除外するテンプレートが出典テンプレートだけでいいのかという点ですが、この点はなにか問題が見つかってから考えるのでもいいかもしれません。--Jutha DDA（会話） 2021年2月15日 (月) 05:30 (UTC)

日本語とzh（全角）とko（半角）だけ書いておけば当座はそれで済む気もします。書き換えるならこんなところでしょうか。

:原則として括弧の種類は本文の文字種に合わせます（例：本文が日本語の場合は全角括弧を用います）。
:外国語の括弧は、その言語の記法に従います（例：中国語は全角、ハングルは半角）。

テンプレートは「和文で押しきる」か「確定できない」か「欧文用」かのいずれであるかによりますね。これは出典プレートだけが有している事情で、他のテンプレートは今のところその性格で処理できる扱いなので出典だけなのです。日本語版というよりも現代日本語の「和洋混合だと全て欧文にしてしまう」（これは出典表記に限らず一般向けでもあります）問題は未だ解決されておらず、特にWikipediaの場合、出典部分も一般書よりに運用すべきとする人と論文の延長で欧文のママで放置が当然という人では決して相容れることはないでしょう。さらに日本語版の特徴として、テンプレートから日本語を排除して英語を積極的に使いたがる日本語版の悪癖（これは日本語版特有です）、リンクの予見性、日中韓（特に日本）の表記を強引に欧文化する必要性の乏しさ（出典以外では問答無用で排除されますし）、一見論文調に見えるがその実一般向けという「スタイルとターゲットがずれる」問題がのります。結局出典テンプレートも腕ずくでの解決が横行しており（そもそもWikipediaの基本に腕ずくでの解決で既成事実を作る事があるのですが）、現状では解決不能なので棚上げせざるを得ないです。実は出典テンプレートの問題はこれに加えて「美観」の問題もあります。欧文のみは日本語版としては論外でありこれに戻すなら荒らし扱いでいいので無視するとしても、欧文 (全角) は全角を補充したものだが美観としては最悪（全体に合わせるなら逆でなければならない）、全角（欧文）はそもそも欧文を残す必要性が論文探索だけになるのでリンク貼った時点で意味が無く、全角のみは「日本語版」であるという観点からはこれしかないが論文の延長で見る人には生理的嫌悪感がどうしても残るしリンクがないときには探索の必要性がある。しかも欧文論文だけを神聖化する利用者もいますので（書籍他だと和文放置するので行動に一貫性がないタイプ）、欧文派の中でもさらに別れるという･･････。こんなのはこの文書で扱いきれません。--Open-box（会話） 2021年2月23日 (火) 10:14 (UTC)

約一月待ちましたが新たな意見が得られません。最後の文を『文の構造が確定できない』もの（例：出典テンプレート）として試験運用的に適用してみます。--Open-box（会話） 2021年4月13日 (火) 16:31 (UTC)

生没年を表すマイナスの使用について[編集]

ハイフンの使用例において、

英語では、数字同士の場合半角スペースを入れずにエヌダッシュ「–」（編集画面下部からも入力可能、文字参照では –）を用いることに注意。
例： 1990–1999

との説明がありますが、この文章の意味が明瞭ではないと思われるので質問します。

「英語では」とはどういう意味でしょうか？日本語記事内の文章は基本的にほぼ日本語だと思われますが、人名をラテン文字で記述するなどの部分は英語なりほかのヨーロッパ系言語であって、日本語ではない、というのは理解できます。これを前提として、たとえば日本語記事中に「鈴木太郎 (1930-2000) 」とあったとして、鈴木太郎は日本語ですが、生没年部分は日本語でしょうか英語でしょうか？私は、この部分も日本語であると理解するので、この部分は英語ではなく、したがって、上記ハイフン（直す前の状況によってはエヌダッシュ）の使用例の説明は該当せず、

期間・区間・範囲を表すときには、「半角スペース＋ハイフン＋半角スペース」を用います。
例： 1990年 - 1999年

との原則にもどって、生没年部分は半角スペースをハイフン前後にはさむ必要が出てくるので、「鈴木太郎（1930 - 2000）」と直す（括弧内は日本語なので括弧も半角括弧から全角括弧に直した上で人名との間の半角スペースは除く）べきことになると理解したのですが、この理解で正しいでしょうか？見かけるところ、和洋折衷というのか、エヌダッシュではなくハイフンを用いつつ前後に半角スペースを入れない、「鈴木太郎 (1930-2000) 」形式が多いように感じます。「英語では」という言葉が多義的で、様々に解釈できる（すくなくとも、英語版記事のことなのか、日本語版記事で使用する英語も含むのか、の疑問は生じるし、日本語版記事を含むとしても、ではその中で英語とは何を指すのかの疑問が残る）ので、この部分は曖昧さの残らないように明確に表現してほしいです。--直蔵（会話） 2021年3月26日 (金) 00:48 (UTC)

履歴を見る限り、当該文言は2016年3月7日 (月) 09:16の新規作成さん編集によるもののようです（差分）。ただ当時のノート（Wikipedia‐ノート:表記ガイド/過去ログ13）を見たところ、この編集に関して合意が形成された様子はありませんでした。また新規作成さんは2019年8月17日以降活動してらっしゃらないようですので、ご質問の答えを見つけるのは難しそうです。

私の推測ですが、上記過去ノートに残っていた『（endash と hyphen の誤りなんかはそれこそ英語論文や書籍で頻繁に目にしますが enwiki ではきちんと正しく使うよう書かれていますね．）新規作成 (利用者名) （会話） 2016年5月28日 (土) 07:09 (UTC)』なるコメントがありましたので、おそらく「英語では」の意味は「英語版記事 enwiki では」の意味かと（つまり日本語版から英語版に翻訳するとき、あるはその逆の場合でも、ハイフン・エヌダッシュの扱いに注意してほしいという意味？でしょうか）。

いずれにせよ意味不明瞭なのは確かなので、もし一旦除去されるなら賛成します。--ぽん吉（会話） 2021年3月26日 (金) 03:03 (UTC)

コメントどうもありがとうございます。履歴までさかのぼって調べていただき恐縮です。質問にあたって過去ログ13には目を通したのですが、肝心の本文の記述の出どころまでは関心が及びませんでした。記述された編集者の意向がおそらく把握できないだろうとのこと、私も同意します。仮に除去するという話になった場合、この記述がなければ、「期間・区間・範囲を表すとき」のハイフンは両側に半角スペースを付ける、との原則となります。この原則が日本語記事の表記ガイドにあるからには、日本語記事（記事中の言語を問わず）に適用されるということになりますから、これは一通りの解決法ではないかと思います。ちなみに、英語版ではen:MOS:DOBがあり、エヌダッシュを使用するとしていますし、半角スペースを入れないようにとなっているので、これと照らし合わせると、「英語では」は「英語版では」と解釈すればぴったり符合するのではないかと、いま調べてみて思いました。こうなると、問題の部分は日本語記事における英語版記事での注釈ということになるので、混乱を避けるためには日本語版に置かなくてもいいかなという気がします（英語版を編集する方は英語版のスタイルマニュアルを参照するでしょうから）。よって、次の提案をしたいと思います。--直蔵（会話） 2021年3月26日 (金) 23:25 (UTC)

提案下記説明部分を除去することを提案します（理由は上記）。

英語では、数字同士の場合半角スペースを入れずにエヌダッシュ「–」（編集画面下部からも入力可能、文字参照では –）を用いることに注意。
例： 1990–1999

--直蔵（会話） 2021年3月26日 (金) 23:27 (UTC)

コメント 除去したほうが分かりやすいという点では反対はしませんが、英語版と日本語版で特徴的に異なる部分なのであれば、あくまで英語版の話ということに体裁を整えて参考として残すというのも個人的にはありかなと思います。おそらく日本語のフォントでは全角ダッシュのマッピング問題が尾を引いているという事情があるのかと思いますが、WikipediaはUTF-8ですから、その辺の制限は将来的に緩和されていくことも予想されます。それと少々話は変わりますが、英語版から訳された{{Sfn}}のドキュメントで使用例としてenダッシュが使われていましたので、念のためスペースを挟むマイナスハイフンに直しておきました[6]。英語版から訳されたテンプレート類では表記ガイドに合致しないケースが散見されるのが、少々気になるところです。--Gwano（会話） 2021年3月27日 (土) 09:43 (UTC)

コメント たぶん、英語版からの翻訳をする場合には記号を置き換える必要があるよ、ぐらいには有益な注意書きなんだろうと思います。万人に有用な注意書きではないかもしれませんが、誰にとっても無用というわけではないのでしょうねえ。

Wikipedia:アクセシビリティ#約物や符号に関する注意点を参照していただくとよいと思います。

私はWikipedia:アクセシビリティ#約物や符号に関する注意点あたりの改訂にかかわって、「‐」と「-」を取り違えただけで大きな問題が生じる（読み上げソフトやAIの挙動が狂う）という問題を知りました。この観点では十分に気をつける必要・重要性はあるでしょう。

しかし一方で、ふつーに読む分には「どうでもいい」違いだというのもまた事実だろうと思います。紙に印刷された情報源ではほとんど区別できないでしょうし、現実社会でもそこまで厳密に使い分けはなされていないだろうなとも思います。

Gwanoさんがおっしゃるように、いくらか手直しをして残すのでもいいと思います。「（いわゆる半角の）ハイフンマイナス」「いわゆる全角ハイフン」「または2分ダッシュ」「エヌダッシュ」などの語が出てきますが、これらの用語の解説・定義がないので、何のことなのか、なぜダメなのかがわからない。

私だったらこうするかも

ハイフンハイフン類には見かけの似た次のような記号・符号があります。 enダッシュ（–） - 区間や範囲、単語間の関係性などを示す。別名2分ダッシュ、半角ダッシュ、二分ダーシ emダッシュ（—） - 時間の経過や説明・副題・引用・省略などを示す。別名全角ダッシュマイナス（−） - 負符号、減算記号ハイフン（‐） - 単語を分割したり、複数の単語を繋いで一つの単語にする。ハイフンマイナス（-） - ISO 646 (ASCII) や Latin-1での代用文字これらを取り違えると、読み上げソフトなどが正しく挙動しない場合があります。日本語版では、期間・区間・範囲を表すときには、「半角スペース＋ハイフン＋半角スペース」を用います。英語版では、半角スペースを挿れずに「enダッシュ」を用いています。記事の翻訳時などには注意してください。（例：英語版「1990–1999」は日本語版では「 1990年 - 1999年」となる）このほか、分野による慣習・合意が定められている場合もあります。 Wikipedia:表記ガイド#ハイフン、ダッシュ_(記号)#全角ダッシュのマッピング問題なども参照してください。

表記ガイドなので、いちいち詳しく説明すると肥大化する面もあり、それを嫌がる方もいます。どこまで説明するかですね。--柒月例祭（会話） 2021年3月27日 (土) 10:37 (UTC)

コメント すぐ下の長音記号のところと合わせ、柒月例祭さんの提案のような横棒の一覧と使い分けについての説明があるとよいと思います。世間一般での使い分けとウィキペディア上でのルールとを明確化しなければならないのと、英語版のくだりは用途に統合するのが適しているとは思いますが。--YTRK（会話） 2021年3月28日 (日) 02:20 (UTC)

コメント 提案者です。Gwanoさんご提案の、除去ではなく残す方針で、体裁を整えるという案でも私は構いません。合意はなかったのだから対処としては単に除去するのが提案するにしても楽ではあったので、結果的に柒月例祭さんにご尽力いただいてブラッシュアップした文案が出来上がってきましたので、これをベースに合意形成を図るのはありだと思います。私の問題意識としては、上記経緯からもご理解いただけると思いますが、要は現状の文面では「英語では」が意味するところが不明瞭なため、日本語版記事中における「鈴木太郎 (1930-2000)」に直しが必要なのかどうかが定かではないというものなので、そこさえクリアになるものであるならば除去しないでより丁寧かつ正確な案内に書き換えるのは合理的な選択だということになると思います。上記柒月例祭さんの文案で「英語では」は「英語版では」と英語版の記事についての話であることが、それに続く「記事の翻訳時」という言葉でより明確になっているとは思いますが、それでもこの場が日本語版記事であることを考えると、念には念を入れて「英語版（英語版記事のことを指し、日本語版記事中の英語部分は含みません）」など注を入れて、勘違いを生まないように配慮したほうがいいと、そのような誤解をしそうになった立場からは提案しておきます。ついでに言えば、日本語版記事において「鈴木太郎 (1930-2000)」のようになっているケースも散見されるので、日本語ではそうしないで「鈴木太郎（1930年 - 2000年）」と直すのだという例示はあったほうが良いのではないかと思います。それから、直すのだと「年」は必須なのでしょうか？「鈴木太郎（1930 - 2000）」も可能だと思っていたのですが。年のあり・なしで2通り表記がありうるならば、その旨も注記があったほうが要らぬ編集合戦は避けられるかと思います。分量についてですが、現状5行のところを11行に約倍増するわけですが、全体での部分を考えると気にするような増量ではないと思います。少しでも行数を減らすならば、「これらを取り違えると」以下の文は冒頭の文に続けて1段落にしてしまえば1行分稼げると思います。次項の長音符号においてもハイフン類の話が再び出てくるので、両者をまとめて使い分けを明確にした上で、総体として分量を減らすのも手かなと思います。ですので、YTRKさんの「横棒の一覧と使い分け」のご提案に賛成します。細かいところですが、「このほか、分野による慣習・合意」の文はインデントを上げてトップレベルに持っていく内容かと思います。ごちゃごちゃ書いたので、私の案を加えた文案を以下に示します。

ハイフン・長音符号ハイフン類には見かけの似た次のような記号・符号があります。これらを取り違えると、読み上げソフトなどが正しく挙動しない場合があります。 enダッシュ（–） - 区間や範囲、単語間の関係性などを示す。別名2分ダッシュ、半角ダッシュ、二分ダーシ emダッシュ（—） - 時間の経過や説明・副題・引用・省略などを示す。別名全角ダッシュマイナス（−） - 負符号、減算記号ハイフン（‐） - 単語を分割したり、複数の単語を繋いで一つの単語にする。ハイフンマイナス（-） - ISO 646 (ASCII) や Latin-1での代用文字長音符号（ー） - カタカナで音を長くのばす符号「ー」。「ゲーム」などの長音に用いる。別名音引ほかに紛らわしいものとして、横線「―」があります。日本語版では、期間・区間・範囲を表すときには、「半角スペース＋ハイフン＋半角スペース」を用います。英語版（英語版記事のことを指し、日本語版記事中の英語部分は含みません）では、半角スペースを挿れずに「enダッシュ」を用いています。記事の翻訳時などには注意してください。（例：英語版「1990–1999」は日本語版では「1990年 - 1999年」または「1990 - 1999」となる）このほか、分野による慣習・合意が定められている場合もあります。 Wikipedia:表記ガイド#ハイフン、ダッシュ_(記号)#全角ダッシュのマッピング問題なども参照してください。

余談ですが、WP:ACCESSを参照したところ、{{lang}}テンプレートがあることを恥ずかしながら初めて知りまして、編集時に使用例は目にしたことはあったのかもしれませんが、そういう時に使うものであることを今になって学びました。同時に、日本語版記事中でよくラテン文字のまま人名などが記述されていることがあり、それらに対してこのテンプレートが使用されている例はかなり少ないのではないかなと感じました。このテンプレートの使用法から逆に言うと、日本語版記事において、このテンプレートが使用されていない範囲はすべて日本語と解釈すべき、あるいはそれで不都合が生じるならばこのテンプレートを使用して非日本語であることを明示すべき、という話になりますね。つまり、「鈴木太郎（1930 - 2000）」において数字部分にこのテンプレートを使う意味はないわけだから、ここも日本語だと理解してよいということになるんですね。--直蔵（会話） 2021年3月28日 (日) 15:18 (UTC)

- 使う記号がなんであろうと、「鈴木太郎 (1930−2000)」（マイナス記号）と書けば、大半の読み手は「この4桁の数字は生没年のことだから、鈴木太郎さん、1930年生まれで2000年没」と理解するでしょう。だからあまり問題にならない。
- ところがこれを読み上げソフトやAIに読ませると「1930引く2000（1930マイナス2000）」と解釈してしまう。なので適切な記号–（enマイナス）を使って「1930–2000」と書き、「1930カラ2000」と読ませるほうがよい。ただそれでも、「スズキタロウカッコ1930カラ2000カッコ」と読み上げても、聞いている人は何をいっているのか即座に理解できないかも（おそらく文脈次第）。なので「鈴木太郎（1930年–2000年）」と書くのがベター。これだと、仮に記号を間違っていても、「1930年マイナス2000年」と読み上げられても、聞き手が人間ならば「ああ、生没年のことを書くときにマイナス記号を使っちゃったんだな」と推測は（おそらく）容易。
- だから理想的には、記号がどうこうとか半角スペースがどうこうとかいう話ではなく、「鈴木太郎（1930年生、2000年没）」とか「鈴木太郎（生年:1930年　没年：2000年）」みたいな書き方をするのが理想的、だろうと思います。
- ほかにもたとえば「日露戦争（1904-1905）」とか「ヴィクトリア朝（1837-1901）」など、「生没」とは異なる表現を要する場合もあります。それぞれ文脈に応じた表記をするのが理想的。
- まあふつうの書き手には「煩わしい、1930-1905で意味通じるからいいだろ」みたいな感覚はあるでしょうし、どこまでこうしたアクセシビリティを追求するのかってのもある。なので「理由は説明しないがとにかく絶対こうしろ、それ以外は認めない」みたいな指示の仕方は避けたいなと思います。--柒月例祭（会話） 2021年3月29日 (月) 01:06 (UTC)
  なるほど。リーダーソフトの利用者のことを考えると、明確に「1990年 - 1999年」の方が「1990 - 1999」よりも好ましい表現というわけですね。では、そのような説明を注記した上で、より好ましい表記として「XXXX年 - YYYY年」形式を例示して、それよりかは一部利用者には可読性が劣るけれども許容範囲の形式として「XXXX - YYYY」を例示する。それから、「XXXX-YYYY」は使用しないように注意喚起するといった内容ではいかがでしょうか？--直蔵（会話） 2021年3月29日 (月) 11:44 (UTC)
  - 悩ましいのは、こういう話を書き足していくと肥大化するっていうところですね。この話は「年」（#年月日・時間）だけでなく、たとえば生物分野で「体長1-2m」ではなく「体長は1メートルから2メートル」がベター、というふうにもなります。この場合、「m」ではなく「メートル」（#単位）、「～」「〜」（#波ダッシュ）ではなく「から」、などの話も複合してる。応用問題という感じです。
    
    応用問題なので、多方面に影響がわたります。たとえば
    - Wikipedia:表記ガイド#波ダッシュでは、“原則、波ダッシュを使用せず、かわりにハイフンマイナスを使え”と指示があります。
      
      Wikipedia:表記ガイド#ハイフンでは、“期間・区間・範囲を表すときにはハイフンを使え”となっています。
      
      Wikipedia:スタイルマニュアル_(人物伝)#生年月日・没年月日では、“故人の生没年を示す場合は半角スペース + 半角ダッシュ（enダッシュ）”、“存命人物の場合はダッシュ（emダッシュ）のみ”
      
      このほかプロジェクト:作家#テンプレートの凡例と書き方あたりにも「こう書け」という指示がある。
    というわけで、指示がバラバラなんです。これは各々の部分で個別にいろいろ決めた結果、各所の記述の連携がとれなくなっているんですよね。あちこち同時に直す必要があるし、相互に「○○も参照せよ」と注意書きをしておかないと、そのうちまた連携が失われるかもしれないです。
    
    生没年ひとつとっても、プロジェクト:人物伝、プロジェクト:紀年法、プロジェクト:歴史などにも諮るべきだし、ほんの少し射程を伸ばして「年」にしてもアフガニスタン紛争 (1978年-1989年)の記事名みたいのまで対象に含まれていきます。
    
    Wikipediaって編集長がいないので、こういうことはあちこちで無数に起きていますね。しょうがない。今回はたまたま人物伝の生没年をピックアップしましたけど、他分野での他の表記でも似たようなことはたくさんあるだろうな、と思います。
    
    今回はアクセシビリティの観点から「この記号にすべき」という話をしましたが、大方針として「Wikipediaは完全なアクセシビリティ対応を最優先する」という合意があるわけでもないです。（本気でアクセシビリティを考慮すると、標準設定のリンク色とかテンプレート色から変えないとダメって話にもなってきます。）そこらへんの根本まで遡って議論・合意をしていくべき事柄でしょう。
    
    でも、話がどんどん大きく広くなっていき、収拾がつかなくなるので、「あんまり細かいことまでこだわらなくてもいいよ」ってしちゃうってのも現実的な解決策の一つだろうと思います。「統一したがる人」にとってはおもしろくないでしょうけど。
    
    なので、前にも書きましたが、「必ずこうしろ」「絶対これはダメ」みたいに縛るよりは、「こういう観点ではこういうことに気をつけろって話もあるよ」「こうするとこういう問題もあります」みたいにヒントを与える・推奨するところまでだろうなあ、と思います。（「推奨」すると、「これは推奨されていない」といって一律に書き換えようとする利用者もいるので、ねえ。）--柒月例祭（会話） 2021年3月30日 (火) 03:15 (UTC)
    
    （追記）今回、もともとは「生没年の場合」の話として問題提起をいただいたわけですが、「そもそもなぜ生没年のときにハイフンを使うのか」というと、「ハイフンは期間・区間・範囲を表すから」ということになり、「だったら生没年に限らないよね」という話になっていくわけです。
    
    Wikipedia内で、「生没年」を表す場合に今どうなっているかを各方面で洗い出す必要はあります。生没年に限定しても、人物伝、分野別の人物伝（私の知っているところだと競走馬も人物伝に準じている）、各種テンプレート類。そして、どう考えても、これは生没年に限った話ではない。
    
    そこにアクセシビリティの観点も加わる。ややこしいです。間違った記号を用いても発見しにくく、つまりたいてい「大きな問題ではない」。それをわざわざ大風呂敷ひろげて根本的なとこから労力かける・・・？って感じもします。うーん。--柒月例祭（会話） 2021年3月30日 (火) 03:45 (UTC)

「Wikipedia:表記ガイド#ハイフンでは、“期間・区間・範囲を表すときにはハイフンを使え”となっています。」についてですが、これは前文の「アルファベットのハイフンには、（いわゆる半角の）ハイフンマイナス「-」を用います」を受けてのことですので、マイナスハイフンをハイフンと呼んでいるだけかと思います（コピペしてバイナリを見る限り、実際にマイナスハイフンのようでした）。このあたりを編集された新規作成氏は当時マイナス記号の使用について議論していたこともあってか、マイナス記号と区別する意味でマイナスハイフンをハイフンと呼ぶことが多かったように思います。それと{{Sfn}}の件についてですが、さすがに文献のページ範囲を示す場合はふつう半角スペースは入れないらしく、いったん差し戻されたことをご報告しておきます。その辺も考慮したほうが良さそうですね。--Gwano（会話） 2021年3月30日 (火) 07:45 (UTC)

コメント 提起での生没年への限定は例示由来のものでしたので、中身の改定に踏み切るのであれば生没年だけを特別扱いするのではなく、期間・区間・範囲でまとめるべきだと思います。ただ、節を分けて議論したほうが良いような気もします。

期間・区間・範囲を示すために用いる記号についてですが、世間一般で正しいとされているのはenダッシュ、日本語版ウィキペディア上での現行のルールとしては半角スペース＋ハイフンマイナス＋半角スペース、という認識で合っていますか？--YTRK（会話） 2021年3月30日 (火) 11:19 (UTC)

コメント 記事の本数は膨大な数あるので、個別の記事のスタイル統一なりは追々やっていくしかないとして、関連するガイドラインに基づいて編集作業は行われますので、ガイドラインの方は早目に見直しをして相互に齟齬がなく混乱を生じないように改訂した方が良いのではないでしょうか？中にはガイドラインなどを参照せずにスタイルを気にせず編集する人もいるでしょうが、せっかくガイドラインまで見に来てそれで指針が混乱していて余計に対処に困ってしまうのでは何のためのガイドラインかということになるのではないでしょうか。ハイフンの節、あるいは本記事の改訂だけでは足りず、全体的な見直しが必要とのご指摘には賛同します。ただ、事が大きくなりすぎて、もっと多くの編集者のご参加も頂いた方がいいでしょうから、ここでの問題提起とは一旦切り離してより適切な場所でどなたか行っていただけませんでしょうか？全体を見回しての問題提起を適切にするのはまだ私には荷が重すぎます。そこでの結果を受けて、こちらの問題に対しては演繹的に指針を出せるはずですから、そちらの合意形成が出るまではここでの議論は凍結という形でいいのではないかなと思います。質問にあたって念頭に置いていた編集対象記事があるのですが、その作業はそれまで置いておきます。--直蔵（会話） 2021年3月30日 (火) 14:48 (UTC)

あくまで個人的な案ですが、Wikipedia:表記ガイド/ハイフンみたいなサブページを作り、そっちで詳しいことや多岐に渡るイロイロを詳説し、Wikipedia:表記ガイド#ハイフンでは簡潔な指示にとどめておく、という感じでまとめてはどうでしょう。「詳しくはWikipedia:表記ガイド/ハイフンを参照」という具合で。--柒月例祭（会話） 2021年3月31日 (水) 01:44 (UTC)

Wikipedia:表記ガイド#文体の追加提案[編集]

Wikipedia:表記ガイド#文体に丸括弧を半角か全角に統一したほうが良いと思うので、記載したいです。

どちらに統一するか（統一するか）と、記載について議論お願いします。--KazuShiba（会話） 2021年4月13日 (火) 07:02 (UTC)

すでにWikipedia:表記ガイド#括弧類という節がありまして、丸括弧の全半角についても2つ上の議題で議論中ですので、そちらをご参照ください。--Gwano（会話） 2021年4月13日 (火) 08:05 (UTC)

Wikipedia‐ノート:表記ガイド

目次

「ruby」以外の仕様と使い方について[編集]

「マジックリンク」の使用を非推奨とする提案[編集]

文面検討[編集]

「JIS X 0213」をそろそろ解禁してはどうか（「ゔ」表記）[編集]

4桁、5桁の数字にコンマまたはスペースを入れるかどうか[編集]

接尾辞について[編集]

断定の助動詞の終止形「だ」について[編集]

交ぜ書きについて[編集]

箇条書きの句点について[編集]

テレビにおける時刻表記について提案[編集]

人物記事における存命期間の括弧表記について[編集]

記事本文中の疑問符・感嘆符について[編集]

人名の敬称付記慣習についてのコメント依頼[編集]

感嘆符と疑問符の全角・半角[編集]

引用文の補足に用いる約物について[編集]

丸括弧・波括弧・角括弧の節からノートページへの誘導について[編集]

「単位」章の追記提案（主に「度」関連）[編集]

ハイフンマイナスの使用について[編集]

○丁目の○は、漢数字とアラビア数字のどちらが適切なのか[編集]

記事名における波ダッシュ、チルダについて[編集]

括弧の規定の改訂提案[編集]

「使用可能な文字」の制限緩和提案[編集]

雑談　この場合は半角？全角？[編集]

丸括弧・波括弧・角括弧運用の変更提案[編集]

生没年を表すマイナスの使用について[編集]

Wikipedia:表記ガイド#文体の追加提案[編集]

案内メニュー

検索

Wikipedia‐ノート:表記ガイド

「ruby」以外の仕様と使い方について[編集]

「マジックリンク」の使用を非推奨とする提案[編集]

文面検討[編集]

「JIS X 0213」をそろそろ解禁してはどうか（「ゔ」表記）[編集]

4桁、5桁の数字にコンマまたはスペースを入れるかどうか[編集]

接尾辞について[編集]

断定の助動詞の終止形「だ」について[編集]

交ぜ書きについて[編集]

箇条書きの句点について[編集]

テレビにおける時刻表記について提案[編集]

人物記事における存命期間の括弧表記について[編集]

記事本文中の疑問符・感嘆符について[編集]

人名の敬称付記慣習についてのコメント依頼[編集]

感嘆符と疑問符の全角・半角[編集]

引用文の補足に用いる約物について[編集]

丸括弧・波括弧・角括弧の節からノートページへの誘導について[編集]

「単位」章の追記提案（主に「度」関連）[編集]

ハイフンマイナスの使用について[編集]

○丁目の○は、漢数字とアラビア数字のどちらが適切なのか[編集]

記事名における波ダッシュ、チルダについて[編集]

括弧の規定の改訂提案[編集]

「使用可能な文字」の制限緩和提案[編集]

雑談 この場合は半角？全角？[編集]

丸括弧・波括弧・角括弧運用の変更提案[編集]

生没年を表すマイナスの使用について[編集]

Wikipedia:表記ガイド#文体の追加提案[編集]

案内メニュー

検索

雑談　この場合は半角？全角？[編集]