問題の発端は、テスト中のローマ字変換テーブルで Globish1500語 をカナにしたリストを製作中に、dispute [ dɪsˈpjuːt ]という単語の読みを ディスピュート と入力しようとした時の事である。
s → す … OK
sp → すぷ … OK
spy → すぴぃ … OK
spyu → ぴしゅ … あれっ、「すぴゅ」 のはずなのに何で?
pyu → ぴゅ なのに。
変換テーブルを問題箇所に絞って小さくして説明する。
問題の変換テーブルは、促音の定義を使い回しする仕掛けになっていた。つまり、パ行の ぴゃ、ぴゅ、ぴょ は 本体の 「ぴ」 は変化せず、小書きの文字のみが入力 a、u、o に応じて ゃ、ゅ、ょ に変化しているという性質を利用している。
尚、変換テーブルの左の行は入力、真ん中の行は確定した出力、右の行は表示こそされるが、未だ確定せずに次の入力に回される要素になる。
| ぃu | ゅ | |
| s | す | |
| すy | すぃ | |
| すぃu | しゅ | |
| p | ぷ | |
| ぷy | ぴ | ぃ |
変換テーブルの最初の行では入力 u に対する小書きの ゅ を定義、変換テーブルの最後の行では入力 y により、その後の母音字の入力で促音の小書きとなるようにしている。
しかし、サ行は促音の定義をそれとは別に行っていた。もし定義の使い回しなら、入力が sy まで終わった段階では 「しぃ」 となってしまうが、この時に 「すぃ」 となる必要があったから。
後日談: sy の変換は「すぃ」から「せぃ」に変更した。こちらの方が[si]の音に近いと思われる。それに、「すぃ」だと[swi]の音と解釈される可能性も否定できない。
それで、spy と入力した段階では、表示こそ 「すぴぃ」 となっているが、真ん中の「ぴ」だけが出力されていて、「す」 と 「ぃ」 はまだ入力に残っているのだから、次に u が入力された時に 4行目の定義が適用されて、「しゅ」 が出力され、結果として 「ぴしゅ」 になったらしいのだ。
しかし、私は、s の後に py を入力した段階で 「ぴ」 が確定するから、その時に未確定だった 「す」 も同時に確定するものだと思っていた。そうで無いとすると、何で今迄うまく動いていたのだろう。
とにかく、「ぴ」 が確定した段階でも、「す」 は確定していないのは結果から明らか。そうすると、u を入力した時に、1行目と4行目の定義のどちらも対象になるが、4行目の定義の方になったという事実から考えると、Google日本語入力は「複数の定義が該当する場合には、一番長い定義を選ぶ」という仮説が成り立つ。
しかし、私は、s の後に py を入力した段階で 「ぴ」 が確定するから、その時に未確定だった 「す」 も同時に確定するものだと思っていた。そうで無いとすると、何で今迄うまく動いていたのだろう。
とにかく、「ぴ」 が確定した段階でも、「す」 は確定していないのは結果から明らか。そうすると、u を入力した時に、1行目と4行目の定義のどちらも対象になるが、4行目の定義の方になったという事実から考えると、Google日本語入力は「複数の定義が該当する場合には、一番長い定義を選ぶ」という仮説が成り立つ。
因みに、サ行の促音も使い回す形に定義してみると、spyu は 「すぴゅ」 に変換された。
| ぃu | ゅ | |
| s | す | |
| すy | し | ぃ |
| p | ぷ | |
| ぷy | ぴ | ぃ |
しかし、これでは sy は 「しぃ」 になってしまう。それで、促音の定義の使い回しを止めて見ると…。
| s | す | |
| すy | すぃ | |
| すぃu | しゅ | |
| p | ぷ | |
| ぷy | ぴぃ | |
| ぴぃu | ぴゅ |
こんな感じに定義すれば望み通りの動作をした。この調子で他の音の定義もやり直すと変換テーブルの行数が大幅に増えてしまうけど、ローマ字変換するのはコンピュータだから文句は言わないだろう。