国際化の技術的課題に対し、どの方法で解決し、どこまで対応するか
ではアプリケーションをi18nで作成する際、考慮すべき点は何か。最初にやるのは、gettextで文字列のリテラルを多言語で書けるようにすることになる。そこでMessageFormatなどにより、メッセージカタログを作ればいい。ただ「さすがに、そのように簡単な話ではない」（藤本氏）。
まずあるのはWord Order、語順などの問題だ。文法が異なる言語の単語を単純に置き換えると、意味不明になったり、まったく逆の意味になってしまうことがある。これは解決法があり、例えばメッセージカタログで順番を指定する。ICUでは普通に基数に番号を付ける。MessageFormatで語順だけでなく、日付、時間などの型を書く。
この国、地域による違いは、奥が深い。まず数字のフォーマットだが、カナダでは小数点の区切りがカンマだ。日付ではフォーマットに加え、そもそも暦が違う場合もある。
次にレイアウトの問題がある。言語により表示幅がかなり異なるため、特にメニューなどでは、シビアに考えなければならない。またFacebookの「いいねボタン」のように画像に文字が入っている場合、全言語分を用意して切り替えなくてはならない。それはできれば避けたい。
またWebアプリケーションを想定すると、そこでは結構JavaScriptが悩ましい。スクリプト内に文字のリテラルがあると、それも多言語化しなければならない。特にモバイルの場合、できるだけコンテンツを減らしたい。そこでサーバーサイドでJSを生成する手法を取ると、今度はキャッシュの問題が生じる。ユーザーが言語を切り替えた場合、キャッシュされたJSを読んで「言語が違う」ということが起こったりするため、何らかの工夫が必要になる。
面倒なことの代表格が、Bi-Di。アラビア語は右から左に書くのだが、数字や英語が混じるとそこだけ左から右になる。さらにレイアウトも逆になる。しかしアラビア語は世界で4億人が使っており、ビジネス面では無視できない。
通貨はどうか。これはアプリケーション的にはそれほど悩むことはなく、難しいのは地域によって通貨価値が違う中で、どうアプリケーションを提供するか。為替リスクもある。そのため、単一アプリケーションを全世界に提供するのではなく、分けた方がいい場合もある。その場合、モバイル利用者の地域判別が難しいという課題がクローズアップされることになる。
地域別の諸問題の中でも対応に悩むのがタイムゾーンだ。時差があることに加え、国によって年齢が上がるタイミングが違っていたりする。アプリケーションのイベントを開始する時間を、どこの標準時間で決めるのか。MySQL Date型に保存する場合もタイムゾーンが問題になる。そこはポリシーを決めて、自分たちでスタンダードを設定するしかない。
センシティブなところではカルチャーの違いもある。宗教関係で、動物のモチーフに留意する必要がある。ファンタジー系を許さない宗教もある。そこはロケーションに応じたFeature Flagで対応することが多いようだ。
また当然、国によって法律が違う。成人の扱い、個人情報の扱いはどうか。どういうコンテンツまで許されるのか。ユーザー情報をどこまで見ていいのか、逆にチェックしなければならないのか。
もちろん、必ずしもすべての問題をクリアしなければならないわけではない。最低限やらなくてはならないこととしてまず、メッセージのリソースは多言語化しておく必要がある。文字コードはUTF-8。ただMySQLの場合、エンコーディングをutf8と書くと3バイトまでしか対応していないので、utf8mb4を使った方がいい。日付の表示などは、基本的にUTCでタイムスタンプを返し、JSでブラウザのタイムゾーンを取り、そこでレンダリングするのが一般的だ（図2）。
以上のようにi18n、ソフトウェア国際化をめぐる環境の整備は、着実に進んできた。ただ新規作成ではない、既存単言語アプリはどうするのか。2004年スタートのGREEには、数多くの貴重なレガシーが存在している。
例えばソースコードがEUC-JPの場合、UTF-8、UTF-16に係わらず、日本語が入っているだけである種負けている。それらを削除し、メッセージカタログなどに置き換えていかなければならないが、ここは一個一個やっていくしかない。
サーバーサイドWebアプリケーションであれば、テンプレートがある。「最近のエンコーディング変換エンジンはしっかりしているので、普通にローカルのエンコーディングからUTF-8によって、あるいはラウンドトリップして、フィルターをかけて変換すれば、それほど問題なかったりする」（藤本氏）。
一番悩ましいのは、DBに大量に入っているローカルエンコーディングの文字列だ。これはUTF-8などに置き換えることができればいいが、サーバーの数が非常に多い。サービスを止めるわけにはいかないので、インクリメンタルに少しずつ変えていかなければならない。藤本氏は、DBアクセスの集中地点にフィルタをかける、あえてUTF-7を介すなど、効率的な変換の手法を求めて試行錯誤しているが、まだ決め手は見いだしていないとのことだ。
最後に藤本氏は「80％をめざす最初の一歩はそれほど大変ではない。2か国対応にするだけで世界の半分をカバーできる可能性がある。ぜひ日本を盛り上げつつ、世界中のアプリケーションが乱れ飛ぶ状況になると面白い」と語り、セッションを閉じた。
GREE Engineers' Blog
グリー株式会社
東京都港区六本木6-10-1 六本木ヒルズ森タワー
