2004/11/12配信号／新居雅行

　コンピュータを使う側の立場でなら、やれ、「日本語化がなっていない」とか、「まったくアメリカ人は他国のユーザがいることを知っとるのか」などと語気を荒げてしまうが、それが自分のこととなってしまったとき、言語がいかに重たいものかを知ることとなる。筆者を中心に開発しているオープンソースのメールソフト「Open Mail Envrionment（OME）」でのローカライズがどのように展開したかを紹介しよう。

　Mac OS 9までは「ローカライズ」だった。OSは固有の言語を持っていて、その言語で動くのが主となる。もちろん、ランゲージキット等でマルチランゲージにはできるが、OS環境そのものに言語要素はタイトに結びついていたのだ。たとえば、英語システムに日本語のランゲージキットを入れたものと、日本語システムはある意味同一ではない。たとえば、システムフォルダの「初期設定」フォルダの名前をとっても、日本語と英語＋日本語ランゲージキットでは違いがある。もちろん、前者が「初期設定」後者が「Preferences」という具合だ。

　結果的に、ソフトウエアは、特定の言語をターゲットにして作らざるをえない。もちろん、例外もあるだろうけど、基本はターゲット言語が存在する。だから、「ローカライズ」なのだ。昔だったら、アメリカで発売されて数年後にアプリケーションが日本でも出るというのはよくある話だった。もちろん、日本で出た頃にはアメリカでは次のバージョンが出ているというのは日常茶飯事、その意味ではいらついたものだが、ローカライズする方も大変だったようだ。

　各社ともそれなりの配慮はしていた模様である。しかしながら、日本市場をどこまで重要視するかによって対応は違っていたようだ。想像だが、マイクロソフトや往年のロータスのような世界制覇を目指す企業はローカライズ版をリリースするという命題は非常に重かったはずだ。一方、小さなソフトハウスはそこまで言ってられない。日本からオファーがあれば、あるバージョンのソースのスナップショットを渡すような作業が関の山だったようだ。もちろん、それをもとに日本語版は出せるとは言え、本家がバージョンアップした差分を反映させるというとても非生産的な開発タスクが待っている。体力が有り余っていても、どう考えても気が遠くなりそうだ。

　ただ、それでも、がんばって日本語化していたひとたちもたくさんいる。大変な作業になることは、いわばビジネスチャンスでもある。また、日本語化の権利は極めて独占的な権利だ。米国でシェアのあるソフトだと、ある意味、成功して当然とも言える。大変なローカライズ作業を経験しないといけないとは言うものの、得るものも大きかっただろう。同じソフトを１から作るより遥かに着実なビジネスモデルなのだ。

　Mac OS Xは、とうとう世界同時リリース、世界統一バイナリになってしまった。一言で言えば、OSは言語に依存しなくなったと言っていいだろう。言語によって違うのはユーザが見える側面で、OSの中、つまりMacの奥深くでは言語依存の極めて少ない世界が実現している。「書類」フォルダも「Documents」フォルダも、OS内部では言語に関わりなくDocumentsフォルダなのだ。また、1つのあプリケーションに多くの言語のリソースを含めることができる。これって、実に驚異的なことだと思うのだが、あまり高く評価されていないような気がしてならない。もっと、評価すべきだろう。

　かくして、Mac OS Xで動くソフトウエアは、ローカライズの必要はなくなったと言っても過言ではない。いや、もちろん、日本語でメニューやダイアログボックスが出てくるようにするといったこともあるのだが、もっと大きな問題が待っていた。それは、インターナショナライズができてしまうという点なのだ。

　英語版を日本語で動かすようにするのも大変なのに、逆に言えば、対応言語が何でも動いてしまうし、また、動くことを要求するのが「インターナショナライズ」であると言えるだろう。

　もちろん、無視してしまうことも可能ではある。日本人のための日本のアプリケーションだ！と言い張るのも一つの道だろうけど、OMEとしてはなんか無視できない気がしていたのだ。遠い昔、アメリカですごいソフトが出ているのに、日本語でアプリケーションが使えない…つまりはデジタルデバイド的なことは海を越えて当たり前にあった時代、日本のユーザとして悔しい思いをした記憶は忘れてはいけないのである。逆の立場になったとき、以前の立場を忘れてはいけない。もっとも、他国の人々がOMEを切望しているかどうかは定かではないが、最初からあきらめたくはないということだ。

　OSという意味での国際化とは微妙に違うとは言え、JavaはMac OS Xが登場した時点ですでに国際化の大方の機能組み込みはできていた。OMEのコア部分は、Mac OS 9時代の途中から、Javaを採用している。理由は簡単で、JavaMailという高機能なフレームワークがあるからだ。しかも、フリーで使える。高性能なメールフレームワークもあるようだが、資金を投入できないので、自ずとそうした選択肢になる。また、木下信さんのJavaMailの書籍があったことも大きい。はまりポイントもありそうだが、自分で世界中の文字セットやエンコードに対応するよりはJavaMailを使うのが得策と考えた。これで、メールそのものに対する文字列処理はある意味、インターナショナライズできたとも言える。

　その後に、インターナショナライズ部分は大きく改定している。結果的に落ち着いたのは、言語ごとの情報をXMLファイルに入れておくという手段だ。OMEでは設定ファイルの構築で当初はいろんなフォーマットを試してみてしまい、それがいまだに尾を引くという結果になっているが、インターナショナルな部分に手を入れたのは最近なので、すんなり今風なやり方にしてみた。クラスといった高機能なものにしなくても、テーブルだけでいいのである。

　実は、PHPのマルチバイトライブラリにあるメール機能も参考にさせてもらった。こういうところがオープンソースのうれしいところだ。ソースの中に日本語だったらISO-2022-JPといったテーブルがさまざまな言語に対応させるために、たくさん入っている。なるほど、こうなるんだなと思った。

　OMEの場合、メールそのものの文字セットやエンコーディングだけではなく、受信したメールファイルの中身、送信するメールのファイルの中身のエンコーディングなどあれこれ指定しないといけない。テーブルの項目が多くなるが、単に対応表だけでいいのはこれまでの運用で明白だった。そして、ヘッダのエンコーディング、文字セット、本文のそれらの設定などなど、細かく対応表をXMLで記述するということに落ち着いた。だから、現状ではそのXMLファイルを書き換えてやれば、受信や送信メールファイルの中身をUTF-8にすることだってできるのである。（おっと、そのやり方をドキュメントにしないと…）

　さらに、OMEの場合、システム全体が特定の言語というわけでもないことが複雑な世界を演出している。当初は「OMEを日本語で使う」という状況を想定していたが、それはまずいことに気づく。韓国語で送られてきたメールは、韓国語モードで処理しないといけない、中国語は中国語…などと送られてくるメールが極めてインターナショナルなのだ。つまり、特定の言語だけの対応というのはメールの受信においては、現実にはあり得ない。一方、送信メールはいつも日本語でもいいわけだが、一方で時々違う言語で送るという場合も考慮して、１通１通に対して言語を指定する機能なんかもつけた。

　ここまではともかくOMEで実装できた範囲だが、まだまだやらないといけないこともある。この続きは別の機会で説明しよう。

　【にい・まさゆき】msyk@msyk.net

　トレーナー、コンサルタント、デベロッパー、そしてライターと、あれこれこなすフリーランス。２週間という長い期間、ずっとセミナーの生徒をやった。しかもほとんどが英語…。セミナーでは講師ばっかりということでもないが、聞くのも大変ということを改めて体験してしまった。さらに英語ばかりのセミナーなので、英語のヒアリングマラソン状態といえるほど。むしろ英語力上がったのが大きいかもしれないと思ったり。