テストは大事だよ..
と日本でエンジニアしていた頃 (そして今でも) 意識する様にしていたのだけれど、それは L10N にも勿論当てはまる。素晴らしすぎる例を見つけてしまったので書いておく。
SETI@home というと、知っている人は結構知っているボランティアプロジェクト (といっても実際にボランティアするのは人間ではなくてコンピューター) なのだけれど、私が職場にいる間は自宅のパソコンを使っていないからという理由で導入してみた。
自動的に日本語が選択される (恐らく OS から情報を取得しているのだろう) のは良いのだけれど..。
- 文字が切れている
特に Windows で動くソフトウェアでは良くあることです (それとも単に数が多いだけなのか?)。状況によっては使われているフォントが変わってしまうので、L10N なんてされていない英語ソフトを動かしているだけでもダイアログの文字が切れたりします。
どういう L10N ツールを使っているのだろうか? 想像するに文字列を単に (GUI を見る事無く) 翻訳したのでは無いだろうか。それにしても、メインの画面でボタン内部の文字列が切れているというのはなぁ..。テストしようよ..。
- メニューが文字化け
Mac OS X のメニューバーに表示される BONIC の項目が文字化けしています。アプリケーション側のメニューは普通に日本語で表示されていた (はず) なので、やっぱりテストしなかったんでしょう。
当たり前だけれど、文字化けしてしまうとユーザーは手も足も出なくなります (メニューを選択する事はできるけれど、例えば表示されるメッセージが全く意味を持たない状況でアプリケーションを使用したいと思う人は少ないでしょう)。
結局 BONIC のクライアントを使い始めて１時間しないうちに英語に切り替えました。L10N により、潜在的なソフトウェアの市場は拡大されるのでしょうが、下手な地域化は逆に害を及ぼすこともあるという良い例でした。そこまで文字列も多く無いからかもしれませんが、翻訳そのものに違和感を感じた記憶はありませんでした (あまり使っていないから分からないけれど)。
L10N という仕事は翻訳とは少し違うということなのでしょう。短い文字列 (= 使われる状況を知らないと文字列の翻訳が正しくできない) の翻訳をする為に開発者と話さなければならない事もありますし、文字列が連結されたり、(日本語ではあまり関係ないけれど) 文字列の最初にある小文字を大文字に変換して、他の文字列と連結するといった処理も往々にしてあります。(当たり前でしょうが) 翻訳者と技術者という両方の側面があるのだと言う事なのでしょう。そこには勿論テストも含まれると私自身は考えています。