Template‐ノート:〜

合理化の提案

提案当テンプレートのマークアップについて、とりあず条件文のマークアップを整理しましたが（更新内容）、さらに以下の点についても更新したほうが良いように思われます。

フォント指定の除去 … ヒラギノを入れているWindows環境（Osakaが無くヒラギノがあるフォント環境）でBold指定した場合や、CSS上で親要素のフォントにゴシック以外が指定されている場合など、親要素のフォント指定と不整合が起こるケースがありえる反面、肥大気味で表示のクオリティ面でもメリットが乏しそうな現行のフォント指定は省く方が妥当かと思います。
引数1のオプションの除去 … 現行の仕様では、引数1が入力された場合に、"display:none" を指定したspan要素として引数1を出力するマークアップとなっていますが、"display:none" の要素は視覚UA・音声UAともに一切出力されないので何も書かれていないのと同じ状態にあります。なので、単純にこの部分を省いてしまうか、doc解説の意図どおり出力するようにマークアップを変更するか、そのいずれかの対応が必要と考えられます。この点に関して、現状のマークアップ（何も出力されない状態）で今まで特に何の苦情も異論もなく運用できているのであれば、シンプルに前者の選択肢がベターかと思います。今後、非表示の読みを指定する必要が生じた場合には別途{{読み}}を使用すれば足りると思われます。
上記の変更に則してdocの内容修正

以上です。--ディー・エム（会話） 2015年3月21日 (土) 02:47 (UTC)[返信]

フォント指定については、かつてWndowsXP以前のバージョンを意識したものをベースに、JIS2004フォントの代用はいかがと提案され、その折衷で指定していたものです。XPがサポート切れになった今としてはこの意味での対策は不要になりましたが、問題は、日本語以外の言語指定で波ダッシュが使われた際に、日本語以外のフォントで波ダッシュが Unicode 7.0 までの例示字形に沿ったものになる可能性がかなり高いことです。何か対策がないか考えているのですが…。ひとまず、指定は簡略化しようと思います。--ケイ20003（会話） 2015年4月14日 (火) 18:16 (UTC)[返信]
- なるほど、了解です。ご説明ありがとうございます。言語指定による表示揺れ対策ということであれば、手堅くシンプルに "{{lang|ja|〜}}" でどうでしょうか。--ディー・エム（会話） 2015年4月15日 (水) 11:19 (UTC)[返信]
- 最初それを考えたのですが、音声読み上げレンダラーに問題が出る可能性があるため、言語切り替えの方法は保留しています。--ケイ20003（会話） 2015年4月15日 (水) 18:35 (UTC)[返信]
  - 「音声読み上げレンダラーに問題」というのは、日本語音声以外の音声ブラウザ利用者（聴覚メディアを使用している海外の日本語版利用者）ということでしょうか。だとすれば、おそらく該当者は極めて少ないだろうとは思いますが該当する方がいらっしゃる可能性もゼロとは言い切れない以上、それを優先するとすれば、たしかにlang指定のja決め打ちは好ましくないかもしれません。
    それも踏まえ、最善策としてはlang指定も省いて "〜" のみとするのが一番良さそうに思います。日本語サイト全体のデフォルトが元々lang=jaなので、よくよく考えると重複して同じ言語指定を書き込む必要がなかったのと（すみません今さら気付きました）、それに日本語圏以外の利用者環境ではどのみち現在指定されたフォントセットが入ってない可能性も高いと想像されますし、日本語以外の言語を明示的に指定している箇所では指定された言語（フォント）本来の字形を出力するほうがむしろマークアップの意図を再現する意味では正確な処理であること等から、それがベストと考えますがいかがでしょうか？--ディー・エム（会話） 2015年4月16日 (木) 04:18 (UTC)[返信]
  - 意図的に言語を指定している箇所で、指定された言語のフォントが表示されることについて、本来ならば何も言うことはありません。しかし波線の場合、Unicode の例示字形が「誤って」左右逆に登録されたため、英語圏などでは波線の正しい知識なしに例示字形をそのままフォントに組み込んだものが多いように見受けられ、指定された言語のフォントで本来出すべき字形が出せないのです。Unicode 8.0 で修正されるとはいえ、日本語以外のフォントメーカーなどがそこをどれだけ修正するか未知数です。また、昨今ではどのOSも言語圏問わず一通りの言語フォントは収録されていますので、そのあたりの問題はないと思われます。--ケイ20003（会話） 2015年4月16日 (木) 09:09 (UTC)[返信]
    - 通常の欧文フォントにはそもそも全角文字が収録されていないはずですので、この全角チルダの出力に限れば、ここで想定されているような事が起こるのはアジアの漢字圏など、デフォルトのフォントに全角チルダを収録している言語環境を持つ国・地域の固有名詞などに限られると思いますが、中国語（zn）や韓国語（ko）など主だったところのメインのフォントはこのチルダ問題への対応は既に大丈夫ではないのでしょうか？具体的にどの言語のフォントを想定されているのか、いまいちピンときません。
    - また、日本語以外のOS環境でのフォントのバンドル状況については、少なくともMacOSはインストールする言語環境は初期設定時に任意選択（日本語環境をインストールしない人にはヒラギノは入っていないはず）じゃなかったかと（最近久しくOSのクリーンインストールをしていないので最新OSでは仕様が変わっていたらすみません）。iOSも（日本では最初から入れてありますが）ヒラギノはオプションのようです（[1]←iOS7の資料なのでもしかすると8は違う？）。Androidの場合は機種によってバージョンもまちまちですし日本語が使えない海外スマホとか普通にありそうな気はしますが、確かめたわけではないので何ともいえません。
    - というかそれよりも、これに関してまず注目すべきなのは、日本語環境でチルダ記号だけが強制的にメイリオで出力されてちぐはぐな表示になってしまうという問題についてです。
    - 現実的なメリットを考えるなら、Windowsキーボードの変則仕様による出力文字の相違を修正するという本来目的の機能に絞る（単純に "〜" を出力する）のが最善かと思いますが、いかがでしょうか。
    - 私が最初に言及した言語指定で対応するという方法については、音声UAの利用者も想定すると好ましくないというご指摘はおっしゃるとおりであり、選択肢から省かせていただきたいと思います。--ディー・エム（会話） 2015年4月16日 (木) 12:22 (UTC)[返信]
(インデントを戻します)全角チルダではなく波ダッシュを出力するので、波ダッシュで左右が逆になる環境が対象ということになります。少なくともMicrosoft Yahei、STHeiti SC、STHeiti TCがアウトであり、特にApple系で影響がより大きいと思われます。余談ですが、ClassでUnicode指定をした際のフォント候補がほぼアウトです。
OS X 10.9の時点では少なくともシステム側のフォルダにヒラギノProNが組み込まれています[2]ので、日本語が表示できないMac環境というのは現在ではほぼ無いでしょう。iOS 8.2 も組み込まれているようです[3]。
部分的に違うフォントになるのは、Template:JIS2004フォントなども同様ですから、文字の字形を修正する意味では同じことだと思います。あなたの言う通り単に変換機能だけにしようかとも当初思いましたが、上記の理由があるのでどうにもトレードオフといったところです。
日本語が使えない海外スマホというのは、日本語が見られないわけですから、波線以前の問題でこのWikipedia日本語版を読むこと自体、そもそもできないのではないでしょうか。--ケイ20003（会話） 2015年4月16日 (木) 14:40 (UTC)[返信]
- たびたびすみません。詳細説明あり難うございます。
- 失礼しました「波ダッシュ」ですか。要するに最後の説明が一番端的な話で、日本語版ユーザーでない環境（海外スマホだけでなく日本語以外の音声UA環境なども）はそもそも考慮不要ですし、全角文字を使用しない言語指定も関係ないですよね。ローカルの環境設定でわざわざ特定の外字フォントを指定しているユーザーも考慮不要ですよね（逆にそれを強制的に変えたらまずいですよね）。そのことを踏まえて、具体的にどういうシチュエーションを想定されているのかが正直わからないというのがあります。日本語版でこの文字を使用するのは実質的に固有名詞の表記だけであり、しかも半角文字は関係ないので "{{lang|en|xxxx{{〜}}xxx}}" みたいな使い方はありえないですし、もし仮に "{{lang|zn|xxxx{{〜}}xxx}}" のようなマークアップで逆向き波線のフォントを出力するOSがあったとしても、表示に問題があれば気づいた人が "{{lang|zn|xxxx}}{{〜}}{{lang|zn|xxx}}" と修正すれば良いだけのことですし。これを中国語の読み上げUAで読む利用者がいれば "〜" の記号だけが日本語用の表現で出力される可能性があり問題ですが、ケイ20003さんがおっしゃるようにそもそも日本語のコンテンツを読むわけですからそのシチュエーション自体が無いということですよね。
- いちおうMacOS10.9で中国語と韓国語（lang=znとko）のデフォルト表示のフォント字形は先に確認済で問題無しですし（デフォルト表示は別のフォントでしたがSTHeitiもOS10.9に入ったので試したところ波線の向きは合ってます、SC、TCは入ってないのでわかりませんがそもそもデフォルトで表示されないフォントであれば関係ないかと）、Windowsの方も字形の共通規格が直ったのを受けて急ピッチで修正したのではないのでしょうか？
- 他方、日本語環境でこの1文字だけフォントが違ったりboldが効かなかったりという状況は確実に発生するわけで、状態としてはそっちのほうがまずいかと。--ディー・エム（会話） 2015年4月16日 (木) 16:16 (UTC)[返信]
  - 私が考慮不要と言っているのは、「日本語版ユーザーでない環境」ではなく、「日本語が一切利用できない環境」です。そんな環境がいまどれだけあるのかはわかりません。
  - 表の中で大きな枠組みごと他言語表記になっていた場合に、{{lang|zn|xxxx}}{{〜}}{{lang|zn|xxx}}といった方法では修正が効きません(その部分だけ違うソース表記にするというのは現実的ではありません)。というか、このテンプレートから字形の修正を取り除くのであれば、{{lang|zn|xxxx}}〜{{lang|zn|xxx}}で十分です。また、iOS 8.2 のラインナップを見ればわかる通り、STHeitiはデフォルトでは入っていません。SC、TCです。
  - 日本語環境でこの1文字だけフォントが違ったりboldが効かなかったりという状況は、Template:JIS2004フォントでも同様ですが、そちらはよろしいということですか?
  - 日本語のコンテンツを読むといっても、一部分が他の言語で書かれていることはあります。「日本語のコンテンツを読むわけですからそのシチュエーション自体が無い」と言いますが、Wikipedia日本語版は「日本語が主となるコンテンツでありつつ、部分的に他の言語も表示できる」のですから、日本語のコンテンツに限らない以上、それは粗暴な判断だと思います(文中のLang属性の指定全てが必要ないことになってしまいます)。--ケイ20003（会話） 2015年4月16日 (木) 18:05 (UTC)[返信]
    - 1,2番目の項目については全く話が噛み合ってないのだと思います。これはお互いにという意味です。
    - MacOS10.9のSTHeitiについては、現に入ってますよ。今打ってる環境はwindowsですが、昨夜の書き込みに使った環境がOS10.9（iMac, ブラウザsafari）ですから。もしデフォルトで入ってないのだとしたらなおさら考慮不要ということですし。
    - 3番目の項目のご質問「Template:JIS2004フォントも同様ですが」ということですが、当然良くはないだろうと思います。そのデメリットを上回るほどの重要な役割があるのかどうか、そのテンプレートの使用実態を詳しく把握していないので全く無用かどうかまでは即答できません（ここでそこまでの言及は必要ないと思いますし）。
    - 4番目の項目について、「部分的に他の言語も表示できる」ということと、ユーザーの普段の閲覧環境が日本語以外かどうかということとは全く別個の事柄ですよね。日本語の読み上げブラウザを常用している方であれば、使用しているソフトによって波ダッシュを「から」とか「なみせん」とか（おそらく多くの場合に固有名詞の正確な読みとは異なる出力であったとしても）どのような文字列を読み上げているのか認識できますし、実際に日常的にそうやって利用されているわけですから、仮に外国語文献の書名など日本語以外の固有名詞の中の波ダッシュが「から」とか「なみせん」と日本語で読み上げられたとしても、実用上まったく問題無いですよね。固有名詞本来の読みとは異なるという問題は波ダッシュだけに限ったことではないので、言ってもはじまりませんし、この文字だけが特別に不便ということにはなりません。他方、日本語以外の音声ブラウザを常用しているユーザーに対して、波ダッシュが文章の一部分でだけ日本語で「から」とか「なみせん」と出力されてしまうと、何の文字が書かれているのか判別できない可能性があるので、そのように固定的に日本語指定を強制するとまずいというのはご指摘のとおりだと率直に思います（そもそもろくに予算が取れずにどこも開発に苦労されている読み上げブラウザにそのような言語切り替え機能を備えたものは通常無いとは思いますが、だからといって正当化すべきでないという意味で）。ただ、日本語版読者に限れば後者の可能性はほとんどないのだから現実的対応の対象としては考慮不要ですよね、ということですよね。
    - それに対してデフォルトがヒラギノであったりメイリオである環境のユーザーは非常に多いと考えられ、現実に想定されるデメリットの影響範囲が大きいのに対して、その犠牲と引き換えに恩恵を受けられるユーザーは具体的にどういう利用環境のユーザーが想定されるのか、全く見えないので、少なくともそれが具体的に見えてこない限り、素直に費用対効果を考えれば前者優先という結論になるのが自然だろうと思います。--ディー・エム（会話） 2015年4月17日 (金) 05:26 (UTC)[返信]
      - よく読んでください。MacではなくiOSの話です。たびたびそう記述しているのですが、Macと混同していませんか。MacにSTHeitiが含まれているのはこちらでもわかっています。iOS 8 では入っていないのです。
      - ユーザーの普段の閲覧環境が日本語以外であっても、日本語版Wikipediaを閲覧する際は、多くの環境で「ユーザーの普段の閲覧環境が日本語の環境」とおおむね同じ表示になると思われます。まあ音声読み上げに関しては一部の固有名詞以外は大した問題ではないかと思いますが、もっと重要な点は下記です。
      - Wikipedia側が古い環境に対してどういう扱いをしているかを鑑みた時、Help:特殊文字をご覧いただければわかるように、Wikipediaではサポートの切れた環境にも配慮している様子が見えます。それを考えると、私は数日前にXPサポート終了を理由にこのテンプレートから大部分のフォント候補を取り除いたことさえ、正直なところあれでもやりすぎた感があるかなと後悔すらしています(削除したい部分がないわけではありません)。
      - グリフが左右逆になることがいかに問題であるかは、表記ガイドにて「波線をなるべく使わない」よう指摘されている理由の1つとして挙げられているぐらいですから、左右逆のグリフになることを放っておくのは好ましくないでしょう。これらの理由で、フォントの見栄えを優先して、字形の修正をおざなりにする判断には、賛同することはできません。--ケイ20003(会話) 2015年4月17日 (金) 06:36 (UTC)[返信]
        返信返信ありがとうございます。上記の4点について。
        
        「いちおうMacOS10.9で〜（略）〜STHeitiもOS10.9に入ったので試したところ波線の向きは合ってます」という私のコメントに対して「STHeitiはデフォルトでは入っていません。」と返答されたので、それに対して私から再度「MacOS10.9のSTHeitiについては、現に入ってますよ」とご説明しただけですので、それに対して唐突にiOSのSTHeitiのお説明を何故されたのか、逆に私の方では存じません。
        
        2点目について。率直に申し上げて、主張されている内容に一貫性が無く、ご説明のたびに変節しており整合性を伴っていません。
        「XPがサポート切れになった今としてはこの意味での対策は不要になりました」/「特にApple系で影響がより大きいと思われます」
        
        「問題は、日本語以外の言語指定で波ダッシュが使われた際に、日本語以外のフォントで波ダッシュが Unicode 7.0 までの例示字形に沿ったものになる可能性がかなり高いことです。」/「日本語版Wikipediaを閲覧する際は、多くの環境で『ユーザーの普段の閲覧環境が日本語の環境』とおおむね同じ表示になると思われます。」
        
        「最初それを考えたのですが、音声読み上げレンダラーに問題が出る可能性があるため、言語切り替えの方法は保留しています」/「音声読み上げに関しては一部の固有名詞以外は大した問題ではない」
        
        そして「もっと重要な点は下記です。」として述べられた内容は、最初に「この意味での対策は不要になりました」とご説明された事柄そのものです。一貫して確固たる理由をお持ちというよりも、現行の対処内容を正当化するための理由付けをその都度探しておられるようにお見受けします。私がケイ20003さんのご主張に賛同できない一番大きな理由がそれです。
        
        Help:特殊文字で古いOSへの言及があるのは古い時期に書かれた記述が温存されているだけのことであり、そこに書かれているからといって「サポートの切れた環境にも配慮している」というのは誤解でしょう。その論理だと、Tiger以降のMacOSは旧い環境に比べて（説明を書く必要も無いほどに）重要で無いという解釈になりますが、それは明らかに当該文書の本意ではなく、ただ単に更新がままならないだけでしょう。ネット接続環境でのXPの継続使用を支援することがユーザーへの配慮とは思いませんし、少なくともウィキペディア内ではそのような主張に対する合意はありません。
        
        表記ガイドで波ダッシュは原則として用いないと定めている主な理由は、Windows環境のキーボード入力で「全角チルダ」が入力されてしまうことであり、そのため具体的指示としてWindowsのキーボード入力を禁止しています。もうひとつの副次的な理由として、上下逆の波形で表示されることがあるとも述べられていますが、ことさら重大視されてはいません。前者は、文字自体が食い違ってしまうという大きな問題であり、それへの対応を補助することがこのテンプレート本来の役割のはずですよね。後者の問題は2つの原因を含んでおり、ひとつは特定のOS環境でのみ文字自体が別の文字に入れ替わって表示されてしまうという問題、もう一つは一部フォントの字形（波ダッシュ "U+301C" ではなく全角チルダ "U+ FF5E" の字形）が異なるということです。前者は深刻な問題だと思いますがフォントなどを変更したところで解消は不可能であり、ウィキペディア内のテンプレート編集などのレベルでは対処不可能です。後者の字形の差異については、当該の国際規格で認められた個々の裁量範囲内のフォントデザインであり、エラーや不具合の類ではありません（[4]従来までで言えば、ヒラギノなどが逆にそうだったわけですが決して規格違反などではありません）。ですから、たとえ国際規格の例示字形に対して上下逆の字形のフォントが存在していたとしても（従来はむしろ規格と逆の字形のフォント環境のほうが歓迎された）、そのような字形デザインのフォントを主体的に選択するユーザーの自由を邪魔しなければならない理由はありません。仮にユーザーの全く意図しないフォント選択によってイレギュラーな字形が表示されるケースが現実に発生しているのであれば、具体的ケースを報告いただいた上でできればそれを避ける方策を練ることは親切といえますが、具体性の無い架空のユーザーのデメリットと現実のそれとを比べたとき、無視できないのは明らかに後者です。--ディー・エム（会話） 2015年4月17日 (金) 12:58 (UTC)[返信]
(インデント戻し)1点目。iOS 8 の例を出したのは、デフォルトの中国語フォントで波線が逆になるであろう環境がある、と申し上げているのです。単にそれだけです。
2点目。これは私の完全な説明不足・失念です。誠に申し訳ありません。確かに読み直してみると整合性が全く取れておらず、それらの文章についてはそのように解釈されたとしても何もいえません。
1. 「XPがサポート切れになった今としてはこの意味での対策は不要になりました」と一旦は思いましたが、後から調べた所、未だXPのシェアが20%弱あるとのこと(2015/3、Net Applications調べ)。後からそれを知り、思い直していますので、撤回します。また、「XPがサポート切れに-」/「特にApple系で-」の矛盾に化してはご指摘をいただき、初めて矛盾に気づきました。誠に仰るとおり整合性が取れていませんでした。
2. 「日本語版Wikipediaを閲覧する際は、多くの環境で『ユーザーの普段の閲覧環境が日本語の環境』とおおむね同じ表示」でも、ページ内で部分的に「日本語以外の言語指定で波ダッシュが使われた際には表示が崩れる」ことを懸念しているという意味です。
3. 「音声読み上げレンダラーに問題が出る可能性がある」と当初考えましたが、{{lang|zn|xxxx}}{{〜}}{{lang|zn|xxx}}という方法なら音声読み上げに支障があまりない、と考えかけました。表組みのCSS指定には適用できないことを見落としたゆえの軽率な判断だったと反省しております。
4. これは私の誤解でございました。
5. 上下逆の波形で表示されることがあることを、ことさら重大視されていないとは、知りませんでした。それでしたら、私の主張は撤回せざるを得ないことになります。
こちらとしては、その都度正当化しようとする意図はありません。しかし、断片的な理由が浮かぶあまり、整合性の取れない指摘になってしまい、信用の置けない状況になってしまったことは確かです。考えのまとまらないであろう今の私がこの一件に関してこれ以上考えても、よい結果をもたらすとは言えないかもしれませんので、引き下がりたいと思います。混乱をきたしたのであればすみませんでした。--ケイ20003(会話) 2015年4月17日 (金) 15:21 (UTC)[返信]
- ご返答ありがとうございます。ここまでの議論の中で一部話がかみ合わず結果的に対話の内容が拡散してしまったことについては、私の方も逐次的な返答に終始してまとまりを欠いていたと感じています。もう少し丁寧に整理をしながら議論を行うべきだったと反省しております。--ディー・エム（会話） 2015年4月18日 (土) 11:33 (UTC)[返信]
  - そちらの提案で改訂しようと思いますので、とりあえず現在、引数1が含まれていることを考慮して、本テンプレート(リダイレクト含む)を取り除ける場所は取り除きました(特に波ダッシュ版{{〜}}の方は、もはや意味すらなしていませんので)。引数1の方も取り除いて問題ないと思われます(これを設定した神奈川エーフレッツさんのノートページへ議論参加をお願いしたのですが、よく見たら2014年10月中旬以降まったく活動していませんでした)。あとは、現在{{～}}(全角チルダ)が{{〜}}(波ダッシュ)へのリダイレクトになっていますが、全角チルダを波ダッシュに修正する目的に絞る理由で、リダイレクトの方向を逆にすべきだと思います(これは、最終的に波ダッシュ版{{〜}}の廃止を予定するためです)。--ケイ20003(会話) 2015年4月20日 (月) 07:11 (UTC)[返信]
    - テンプレートの修正ありがとうございます。全角チルダ→波ダッシュへの変換と波ダッシュ→波ダッシュそのまま出力のテンプレート両方あったほうが良いように思います。というのは、ユーザー側の文字入力の仕様がチルダなのか波ダッシュなのか気にせず確実に波ダッシュを出力できるという利便性があると思います。チルダ→波ダッシュの方をリダイレクトでなく本体にすべきというご指摘は内容的に確かにそのとおりだと思います。あるいは両方とも、一文字出力するだけのためにリダイレクトするよりは、それぞれ別個に直接文字を出力させる形のほうが効率的には良いかもしれません。メンテナンスも大した負担にはならなさそうですし。--ディー・エム（会話） 2015年4月21日 (火) 14:29 (UTC)[返信]
      - 両方のテンプレート残しという案、そのほうがいいかもしれませんね。考えてみれば、過去のOSならまだしも、現在はどちらの文字を入力したか見た目ではわからない環境も増えていますし、今後なおさら増えるとすれば、区別無く利用できた方がよいでしょう。ただ、当初、同じ内容のテンプレートを作ったところ、別のユーザーによりリダイレクトされた経緯がありますので、リダイレクトなしで個別というのは賛同を得られにくいかもしれません。しかしながら、今回のディー・エムさんの「チルダなのか波ダッシュなのか気にせず確実に波ダッシュを出力できる」という観点が、テンプレートの方向性としては有意義に感じられますので、引数1を取り除いて、その案で説明文を修正したいと思います。自分としては波線そのままのテンプレートを廃止する予定でリダイレクト見直しを考えていたのですが、どちらでも気にせず波線を入力できるテンプレートという意義になると、リダイレクトの方向が現在のままでも問題点はないかもしれません。今回はひとまず上記の修正を行います。--ケイ20003(会話) 2015年4月21日 (火) 14:50 (UTC)[返信]
      - 追記になりますが、念のため、リダイレクトの方向性を逆にする提案については、取り下げたわけではなく、現在は保留にしているだけということです。今回の修正で、チルダを波ダッシュに修正するのみならず確実に波ダッシュを表示する機能を説明している状態なので、リダイレクト修正依頼をする動機がまとまらずにいます。--ケイ20003(会話) 2015年4月21日 (火) 15:24 (UTC)[返信]
        テンプレート修正とdocの更新ありがとうございます。リダイレクトの件は了解です。現状でも機能的には支障ないですし、当面はこのまま様子見ということで。--ディー・エム（会話） 2015年4月22日 (水) 14:10 (UTC)[返信]