ソフトウェア国際化の環境の整備が進むが留意点も多い
グリーで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だと繁体字で書かれている中国語だと分かる。表し方がぶれることはなくなり、やりやすくなっている。
