ソフトウェア国際化の環境の整備が進むが留意点も多い
グリーでCTOを務めている藤本真樹氏のセッションテーマは、ソフトウェアの国際化。タイトルに「いまどきの」と入れた理由は、5年前、10年前と比較して、最初の一歩を踏み出す際の敷居が非常に下がっていることを伝えたかったからだ。
では、なぜi18n、ソフトウェアを国際化しなければならないのか。これまで日本のエンジニアは日本語だけで作成することが多かったが、世界の言語比を見ると日本語を話す人は3％。一方英語は53％になる。単一言語で作成したアプリケーションを2言語にするのは大変だが、仕組みを整えておけば、それを3言語に増やすのはそれほど難しくない。
藤本氏はこの2～ 3年、多言語対応の意識が高まってきていると見ている。その背景にあるのがスマートフォンの普及だ。プラットフォームとしてのコントロールが効いているので、アプリケーションを世界に向けて出しやすい。グリーではこの動きを先取りし、GREEプラットフォームのグローバル版を開発中で、今春に提供される予定だ。
ではi18nとは何か。ある米国の経験豊富なエンジニアは藤本氏に「i18nと聞いて、アーキテクチャだと考えられるようになったら一人前」と語ったという。氏自身の解釈ではフレームワークに近く、特定の何かをする枠組みをソフトウェアの中に持つというものになる。ソフトウェアから言語、文化に固有な特性やエンコーディングに依存する部分を切り離し、1つのバイナリ、アプリケーションインスタンスで複数言語の切り替えができるようにする。同時にl10n、ローカリゼーション可能にする仕組みをアプリケーションの中に持たせることも必要だ（図1）。
文字コードについては、最近ではUTF-8で書くことが多い。これですべて解決すると思いきや、例えばNFC（結合正規化）、NFD （分離正規化）というものがある。日本語の濁点でいえば、濁点だけでコードポイントがあり、「が」を1つのコード（NFC）、「か」+濁点の2つのコード（NFD）、どちらも認められている。それに気づかず文字数を数えると間違える。藤本氏は「文字コードだけでも、話すべきネタが1セッション分ある」と話す。絵文字もユニコードに入ったが、それですべてをカバーできるわけではない。
またプログラミング言語環境では、charとwchar_t、文字エンコーディング変換、リテラルの扱いなどの問題がある。OSでもロケールの設定やタイムゾーンの扱いを決めなければならない。
とはいえ藤本氏がセッション冒頭で述べた通り、この10年でi18nを取り巻く環境が大きく進化しており、アプリケーション作成という視点では、行うことはかなりシンプルになってきている。ライブラリではICUを使えば、エンコーディングの変換やメッセージのフォーマッティングで、それほど悩むことはなくなっている。また地域固有のデータをXMLで公開しているCLDRというものがあり、例えば日本の元号などを一々自分で調べなくてすむようになっている。
標準も大分、定まってきた。2009年に決まった言語タグBCP 47（RFC 564）のlanguage（言語）、Script（表記）、region（地域）で大体行ける。例えばsh-Hans-CNだと繁体字で書かれている中国語だと分かる。表し方がぶれることはなくなり、やりやすくなっている。
国際化の技術的課題に対し、どの方法で解決し、どこまで対応するか
ではアプリケーションを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 六本木ヒルズ森タワー
