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

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

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

日本の神の一覧においてルビ使用のためののテンプレートTemplate:日本の神の一覧/ruby「<span class="ruby">{{{1}}}<span class="rp">（</span><span class="rt">{{{2}}}</span><span class="rp">）</span></span>」で、表の中などではなく、通常の文中で使用されていてるのですが、この「span」を使ってのルビの振り方と文中使用はWP:JPE#読み仮名の要否では許容されているのでしょうか。補足しますと、テンプレートの初版は、「<ruby>{{{1}}}<rp>（</rp><rt>{{{2}}}</rt><rp>）</rp></ruby>」の仕様でした。<ruby>の替わりの<span>の仕様はガイドライン的には問題ないのでしょうか。--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にはチェックディジットを用いた検算が可能であるが、テンプレートを使えばその機能も実装できる。

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

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

  • 提案自体に反対はないですが、表記（見た目）の話ではないので、この文書にわざわざ新規記載することではないように思いました。Help:マジックリンクの方に記載するということでは不味いのですか？--Yapparina（会話） 2017年7月1日 (土) 09:22 (UTC)[返信]
    • Help名前空間のものに強制力はありません。そして、この種のものにまったく強制力がない場合は往々にして編集合戦を引き起こします。「Wikipedia:表記ガイド」が見た目に限定されているとは私は判断しておりませんが、方針系文書としてより適切なものがあれば教えてください。そちらにもアナウンスは必要かもしれませんし、議論場所を変更する必要もあるかもしれません。--iwaim（会話） 2017年7月1日 (土) 09:34 (UTC)[返信]
  • コメント 提案が採用となった場合、善意で「ISBN 4-**」とか「RFC ****」と書く人もいるでしょうし、自動修正用のBotがあればいいなと思いました。--Jkr2255 2017年7月1日 (土) 09:28 (UTC)[返信]
  • コメント 提案は賛成です。ですが、「非推奨とする」だけの提案だったら表記ガイドは関係ないと思います。表記方法としてガイドに実装するという提案であれば受け入れられますが。
Jkr2255さんも仰ったように、自動修正するbotは必要かと思いますが、かなり簡単に作れると思いますので深く考える必要はないかと。--Yuukin0248[会話/履歴] 2017年7月1日 (土) 09:35 (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を書くのだろう？》については例えば以下のようなものです。
書籍を主とした記事については書籍の情報の一つなのである意味当たり前ですね。{{基礎情報_書籍}}にも項目があります。他の記事に必要か否かはちょっとわかりませんが、現状として記載されています。なお、（未調査ですが）漫画記事は記載されている比率が高いような気はしています。--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)[返信]

iwaimさんは、まだ諦めずにこの話を延々と続けるつもりですか？ --Hisagi（会話） 2018年4月12日 (木) 13:09 (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さんにより、早くも現在のガイドラインの骨格となる以下の文書が提案されています。

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

  1. 4桁ごとに「万、億、兆」などの単位語を入れる。「千」以下の単位語は入れない。またカンマは原則省略する。
    例：38万4400キロメートル、80兆9123億2122万1233円
  2. 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に収録されている漢字は原則として全て交ぜ書きしないことを提案します。理由は

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

「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)[返信]

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

秋元春朝の記事における存命期間の括弧を本記事の括弧の入れ子節に従って修正したのですが、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)[返信]
「https://ja.wikipedia.org/w/index.php?title=Wikipedia‐ノート:表記ガイド/過去ログ15&oldid=99688955」から取得