「あなたにも起きるかもしれないLocalizationのホラーストーリー」

gettextは英語圏指向でできている。順序が変ったり変化の違う言語には対応しにくい。これはテンプレートによる国際化の限界ともいえる。これを克服するための新しいperlの国際化モジュールがLocale::Maketextだ。メッセージにテンプレートでなく関数を対応させることによりテキスト生成の自由度を高めるのだ。各言語の共有のロジックを再利用するための継承システムもある。

この斬新な国際化モジュールのニーズを正当化・解説するこの記事が面白い。
HNにはこのタイトルであがってきた： "A Localization Horror Story: It Could Happen To You"
http://search.cpan.org/dist/Locale-Maketext/lib/Locale/Maketext/TPJ13.pod#A_Localization_Horror_Story:_It_Could_Happen_To_You

記事の著者は言語学者兼プログラマだ。英語、ロシア語、中国語、アラビア語、ウクライナ語など多様な言語の相違点や共通点を挙げ、それがgettext的アプローチを打ち破っていくさまを面白く描いている。Perlを使わなくても、言語や国際化に興味のある方にはお勧め。

一番最後にこのような国際化モジュールの実装言語の話がある。Perlだと他言語で実装されたプログラムにこれが使い難いことも指摘している。そこでプログラミング言語にアグノスティックな国際化フレームワークについて考えてみた。

どんなプログラムにも組込める関数ベース国際化ライブラリ

どんな国際化機構でもランタイムとデータベース=lexiconから構成されることになると思う。Locale::Maketextのlexiconをフレーズの雛形でなく関数にすべきだという考えは正解だと思う。一方、広く使われるためには、gettextのようにどんな環境からでも呼び出せるnativeなランタイムが理想的だ。PerlオンリーのLocale::Maketextでは稼動環境が限定されてしまう。nativeなランタイムで処理できるフレーズ生成言語(DSL)が理想的だ。

関数ベースのlexiconではデータが特定の(自然)言語でメッセージを生成するコードがデータになる。コードがデータって言うと…Lispが頭に浮ぶ。chibi schemeなら64kbという軽量フットプリントでどんなプログラムにも組込める。しかもマクロのあるランタイムだ。国際化する翻訳者にschemeを書かせるのは問題なので、マクロによりフレーズ生成用のDSLをschemeで組めばいい。

稼動時に毎回Lexiconを読み込むオーバーヘッドを嫌うなら、ChickenかGambitのようなscheme-->Cコンパイラでオブジェクト化してしまえばいい。そうすればgettextと同じ起動・ランタイムオーバーヘッドですむはずだ。

組み込みSchemeでメッセージ生成DSLを実装すれば、どんなプログラムと(自然)言語にも対応できる国際化フレームワークができそう。