文字コード範囲による言語自動切り替え
nishimoto nishimoto 本家 next ブランチにマージされた。 ざっとコードを眺めた感じでは、日本語に特化した処理は入っていない。
jpbeta + 本家 t2990 というブランチを作ってみるべきか。。
nishimoto 本家のチケットで「ドイツ語の音声で読ませたいのに強制的に英語になってしまう」といった不満が出ている。 本家 next スナップショットをアドオン版 JTalk で評価してみたが、 「読み上げ辞書」を「どく、み、うえ、げ、じしょ」と読んでしまうなど、 この実装にはいろいろ問題がある。
nishimoto とりあえず本家チケットにコメントを書いて問題提起はした。 http://community.nvda-project.org/ticket/2990#comment:16
どうやら本家はこの実装 2015.4 に入れたいらしい。 本気で改良を提案してあげる必要があるか。。
この手法では中国語、韓国語、日本語で問題が起きるのでは、と思ったけど、 もしかすると本当に困るのは日本語だけなのか。。
nishimoto どうせやるなら日本語については DualVoice アドオンみたいな仕様にして欲しいとコメントした。
nishimoto DualVoice 的な実装は別件でやらせてくれという話になっている。
たしか Vocalizer アドオンで文字コード言語自動切り替えをやっていて、 日本のユーザーは不満なく使えているらしい（私は翻訳はしたけど自分用には買ってなかった）ので、 これがどういう仕様になっているか調べてみるべきか。。
nishimoto Vocalizer Expressive が開発されていたころどんな議論をしていたか忘れていたが、 日本人が要望しそうなことはだいたい実装されていた。
Vocalizer Expressive と NVDA 本家版 2015.3 で確認。
Vocalizer Driver 3.0.12 https://vocalizer-nvda.com/downloads
音声の品質は検討対象ではないので、コンパクトな音声として、 日本語 Otoya と英語 Tom の音声をインストールしておく。
ツール「ボーカライザー・エクスプレッシブ」に「自動言語切り替え設定」ダイアログがある
地域と言語を設定して、話者を設定してください： 地域と言語：コンボボックス 話者：コンボボックス
地域と言語には「英語 - en」「英語（米国）- en_US」「日本語 - ja」「日本語（日本）- ja_JP」の4種類が選択肢にある。 以下の組み合わせをそれぞれ設定しておく。
「英語 - en 」「Tom」 「日本語 - ja」「Otoya」
文字コードで言語を自動判別する（実験的機能）：チェック 言語の自動判別で数字や半角記号を使わない（実験的機能）：チェック
ラテン文字を次の言語とみなす：コンボボックス 英語 - en しか選択できないのでこのまま
音声設定
サポートされている場合自動的に言語を切り替える：チェック 記号と文字の説明に音声の言語を使用：チェック サポートされている場合スペル読み機能を使用：チェック
この設定なら日本人にはだいたい違和感のない仕様と思われる。
好みが分かれそうな動作例：
Excel 2016 : すべて Tom で "excel two thousand sixteen" JR西日本：Tom で "J R" Otoya で「ニシニホン」 NHKニュース：Tom で "N H K" Otoya で「ニュース」 かな漢字変換でローマ字入力「ｍｏｊｉ」： Otoya で「ム（聞き取りにくい声）」「モ」「ジュ（聞き取りにくい声）」「ジ」 （どうやら全角英字は Otoya になるらしい） （記号すべて読み上げの場合） メモ帳で Alt キーを押したときのファイル(F)： Otoya 「ファイル カッコ」 Tom "F right paren" Otoya 「サブメニュー」
妥当と思われる動作例
a （半角アルファベットを変換停止で入力）：Tom で "A" 1 （半角数字を変換停止で入力）：Otoya で「イチ」 ,./（半角記号を変換停止で入力）」Otoya で「コンマ」「ピリオド」「スラッシュ」 \（半角円マークを変換停止で入力）」Otoya で「エン」 （記号読まないの場合） メモ帳で Alt キーを押したときのファイル(F)： Otoya 「ファイル」 Tom "capital F" Otoya 「サブメニュー」
nishimoto Windows のユーザーインタフェース言語を英語に切り替えて再確認してみたところ、 さきほど書き忘れていたことに気づいた。
いま試している環境は音声設定「音声」(Voice)では "Tom - English (United States)" "Otoya - Japanese (Japan)" が選択可能で、さきほどは Otoya が音声設定で選択されていた。
この状態では半角数字は Otoya で読み上げられる。
しかし音声設定で Tom を選んでいる場合は、優先される言語が英語になるので、 半角数字も半角カンマなどの記号も Tom で読み上げられる。
"Vocalizer Expressive" "Automatic Language Switching Settings" ダイアログの "Detect text language based on unicode characters (experimental)" をチェックなしにすると、 「NHKニュース」という文字列は Tom の声で「NHK」と読み上げてその後は読まれなくなる。 （Tom が日本語文字をハンドルできないため）
"Detect text language based on unicode characters (experimental)" はチェック、 "Ignore numbers and common punctuation when detecting text language (experimental)" はチェックなしにすると、 例えば「10時30分」は Tom "ten" Otoyta "トキサンジュップン" のようになる。
やはり "Ignore numbers and common punctuation" は日本語環境では必須と言えそうだ。
nishimoto コンテンツの属性に基づく言語の自動切り替えは無効にして、 文字コードに基づく言語の自動切り替えは有効にする、 という設定をしたいことがあるかどうか、という質問を jteh からされているのだが、 ありそうな気がする。 （現状 Vocalizer アドオンではそういう設定はできない）
Word で半角数字を含む文書を作ると、半角数字は Word によって自動的に「英語（米国）」になってしまう。 なので Word で「10時30分」のように書かれていると、"ten" 「ジ」"thirty" 「ブン」のように読まれる。 これを防ぐには現状では音声設定「言語の自動切り替え」を無効にするしかない。
しかし、コンテンツの言語情報を無視して、 「文字コードで言語を自動判別」「言語の自動判別で数字や半角記号を使わない」 を有効にすることができれば、 「10時30分」はすべて日本語で読ませる、 「File」はすべて英語で読ませる、 ということができる。
こういう使い方をしたいという要望があるかどうか知りたい。
nishimoto nishimoto への返信
コンテンツの属性に基づく言語の自動切り替えは無効にして、 文字コードに基づく言語の自動切り替えは有効にする、 という設定をしたいことがあるかどうか、という質問を jteh からされているのだが、 ありそうな気がする。 （現状 Vocalizer アドオンではそういう設定はできない）
たぶんあると思います。
特にHTMLの場合は、コンテンツ制作者が謝った言語コードを設定している可能性を排除できないため、これを無視するかどうかは容易に切り替えられないと困るだろうという気がしています。
しかし、コンテンツの言語情報を無視して、 「文字コードで言語を自動判別」「言語の自動判別で数字や半角記号を使わない」 を有効にすることができれば、 「10時30分」はすべて日本語で読ませる、 「File」はすべて英語で読ませる、 ということができる。 こういう使い方をしたいという要望があるかどうか知りたい。
個人的な好みとしては、設定した数以上の英単語が続いている場合だけ、英語音声に切り替わるような仕様になっているとありがたいと感じます。
1単語だけのものが英語音声で読まれるのは、スムースな理解を阻害するように感じます。
ただ、扱っている文書によっては、その1単語を日本語音声で読ませた時に、全く理解できない読み下しをされてしまうような単語が頻出することもあり得る気がしていて、この場合は、1単語だけでも英語の音声の正しい発音で読まれる方が良いのかもしれません。
ということで、日本語音声の外国語単語の読み上げ精度がどれくらいかで、意見が変わってくる気がします。
nishimoto ありがとうございます。
HTML のコンテンツで制作者が日本語コンテンツに lang="en" をつけていたケースは過去に報告を受けていて、 特に英語エンジンに（他のラテン文字言語ではなく）日本語の文字列が渡されてしまうと 完全に情報が欠落してしまうのが問題です。 このことは本家にはコメントしてあります。
単語数によるヒューリスティックスはたしかにあり得ますね。。 いずれにせよ、こういう話が本家に受け入れられるかどうかが問題です。。
nishimoto 本件、本家のマイルストーンが 2015.4 ではなくなったという話。
nishimoto 本家2990で再実装のレビューを依頼されているので対応予定。
nishimoto nvda-india のブランチ
nishimoto いちおう PR を出す準備はしたのでコードの検討に取り掛かる。
https://github.com/nvda-india/nvda/compare/in-t2990-review...nishimotz:in-t2990-review?expand=1
nishimoto Unicode 関連のデバッグをしながら実装を評価している。
テスト環境には OneCore の英語と日本語の音声が入っている。
入力：2016 読み上げ：日本語「にせんじゅうろく」 入力：Excel 読み上げ：英語「excel」 入力：Excel 2016 読み上げ：英語「excel two thousands and sixteen」
言語の優先順位を設定できる。 例えば Excel は英語とは限らないので、 スペイン語の音声が入っていて優先する言語にスペイン語を追加しておくと、 Excel をスペイン語で読む、といったことが可能のようだ。
残念ながら数字は優先順位制御の対象外になっていると思われる。
nishimoto より深刻な問題として「1個」を「one こ」のように読んでしまい、実用的でなかった。 数字を優先順位制御の対象にするような修正を提案しておいた。
nishimoto 本家 2990 で議論したり nvda-india のコードを試したりしている。 ヒンディー語の文字に関するテストがすでにあるので、日本語のテストケースを提案したところ。
現状、以下のような仕様である。
（１） 現状の nvda-india による実装は、一つの音声合成ドライバーで複数の言語が扱えることを前提としている。
（２） 言語の自動切り替えを有効にすると、音声設定で選んでいる「音声」によって、デフォルトの言語が決まる。 Windows 10 で日本語がメイン、英語が追加の言語になっているとする。 OneCore 音声ドライバを選ぶ。 音声設定で David だと英語がデフォルト、Ichiro だと日本語がデフォルト。
（３） 例えば音声設定が David の場合（英語をデフォルト言語として使う場合）は、 「10文字」のような文字列は、 最初の「10」を英語で読み上げて、 後ろの「文字」を OneCore の日本語音声で読み上げる。 （数字はどの言語についても常にデフォルト言語で読み上げるように提案した）
（４） 例えば音声 Ichoro の場合（日本語をデフォルト言語として使う場合）は、 「10文字」のような文字列は、 最初の「10文字」を日本語 (Ichiro) で読み上げる。
（５） 全角の数字は日本語音声エンジンで読み上げるように提案した。 （ほかの言語では全角の数字は使われていないと思う） 例えば音声設定が David の場合も、 「１０文字」のような文字列は、 全体を OneCore の日本語音声で読み上げる。
（６） 言語の優先順位を設定する画面が追加されている。 だが 10 などの数字は優先順位設定では制御できない。 数字をどの言語で読ませたいかは「Ichiro」「David」など音声の切り替えで行う。
例えば「Windows 10」のような文字列で、 Windows のようなラテン文字を、 英語で読むかスペイン語で読むか、といった制御はできる。
（７） 文字コードから言語を判定する根拠は基本的に unicodedata のカテゴリ情報である。
記号は Common という（どの言語かを判断できない）文字として扱われ、 基本的には直前の文字の言語と合わせようとして処理される。
数字はすべて Common として扱われていたが、 「Excel 2016」の 2016 が必ず英語で読まれてしまう、 といった問題があったため、修正を提案して上述の仕様になった。 ヒンディー語音声ではこういう要望があるのかないのか、 テストケースを読んでもはっきりわからない。
日本語の記号についてさらに仕様修正が必要かどうか、 まだ検討できていない。
記号読み上げモード、句読点記号辞書、 「記号と文字の説明に音声の言語を使用」 の設定などの要因を考慮する必要がある。
Screen Reader NVDA Japanese
Fork
Automatic language detection based on unicode ranges
http://community.nvda-project.org/ticket/2990
インドチームの作業で in_t2990 ブランチが完成したという話なので、 日本語対応への影響を確認しておきたい。