GREEの国際化, その4 – 言語コード

GREEの国際化, その4 – 言語コード

こんにちは、エンジニアの岡崎(@watermint)です。今回も国際化における標準を実際にどのように選び、使っていくかを紹介していきます。今回は言語コードのお話です。

アラビア語

言語コードのお話に入る前にひとつご紹介です。先日、GREEプラットホーム新規11言語のサポートというエントリでもお知らせした通り11月に入って、GREEプラットホームに新しくアラビア語のサポートを追加しました。

これでGREEプラットホームがサポートしている言語は12言語になりました。アラビア語圏のお友達がいらっしゃる方がいらっしゃればぜひご紹介ください。

言語コード

言語コードも前回紹介した国コードと同様の基準で選ぶことになります。GREEのようなインターネットサービスを提供する場合には、必然的にインターネット上でよく使われるプロトコルが重要な選択基準になります。

インターネット上の言語コードは、BCP 47がデファクトスタンダードですのでこれを利用することになります。

GREEプラットホームにおける言語コード

BCP 47で定義されるLanguage-TagをGREEプラットホームでは現在のところ、次のように限定して使っています。ABNFで書くと次のようになります。

この定義に従うと、日本語は ja-Jpan-JP、英語は en-Latn-US、フランス語は fr-Latn-FRのようになります。
いっぽう、BCP 47では次のように定義されています。

BCP 47で定義されるLanguage Tagはかなり広い範囲のユースケース、あるいは将来の拡張のために定義されているものです。GREEプラットホームでこの標準をそのまま利用していないのは、次のような理由があります。

  • 標準仕様の定める全パターンを、すべてのコンポーネントに実装して検証するのは実質的に不可能
  • 現在対応している言語をそれぞれ適切に扱えるような意識的な指定

不要部分をスコープから外す

BCP 47で定義される言語タグでは、言語コードとしてアルファベット2文字で構成されるISO 639 alpha 2(日本語ならja)と、3文字で構成されるISO 639 alpha 3(日本語ならjpn)があります。将来の予約として4文字以上も定義されています。

言語の取り扱いはGREEプラットホームを構成するほぼすべてのコンポーネントで必要になるため、全体の品質安定と工数をおさえるためには直近利用しない部分を対応スコープとして外すことが合理的です。
BCP 47でも将来の拡張目的とされている部分は対応スコープから外します。また、ISO 639 alpha 3のような3文字コードについてもスコープから外しました。
ISO 639 alpha 3を対応スコープから外した理由は、多くのライブラリやAPIがISO 639 alpha 3に対するサポートが無かったり、不十分であったのが主な理由です。
その他にも様々なユースケースに対応するために拡張フィールドなどが定義されていますが、直近は利用しないためスコープから外しました。

意図的に省略をさせない

通常、BCP 47で日本語、英語、フランス語、中国語を表現するにはそれぞれ ja、en、fr、zhのようなISO 639コードを使います。 GREEプラットホームでは中国語について簡体字・繁体字の両方をサポートするために言語コードだけではなく、script (字体)についてのコード指定(ISO 15924)も必須になります。また、中国語は標準中国語のほかに、香港やマカオなどでよく話される広東語、上海などで話される呉語などそれぞれ翻訳に違いがあります。

ISO 639 alpha 3コードを使えば、広東語(yue)、呉語(wuu)なども区別できるのですが前述とおりライブラリ等によるサポートの理由でISO 639 alpha 3の利用が難しいため、言語タグには地域も合わせて指定が必須としています。

数多くのコンポーネントで構成されるGREEプラットホームの全体で間違いなく処理されるよう、BCP 47で許されている省略をあえて許さずに必ず ja-Jpan-JP のように 言語コード字体国コード を明示的に表現するようにしました。

中国語の簡体字なら zh-Hans-CN、簡体字なら zh-Hant-TW のようにしています。

OSのサポートする言語コード

基本的にはGREEプラットホームで定義している言語タグを利用するのですが、AndroidやiOSなどOSが持っている多言語化を利用する場合などOSやライブラリが扱いやすい形に変換した方が効率が良いことがあります。

そのような場合には無理をしてGREEプラットホームの形式を使うのではなく、OSサポートする表現を使うようにしています。

翻訳リソースを作成する場合には、iOSの場合は、日本語を ja.lproj、中国語を 簡体の場合 zh_Hans.lproj、繁体の場合 zh_Hant.lprojのように作成してアプリケーションをビルドします。

Androidの言語コード

Androidの言語コードはやや奇妙な扱いになっています。日本語などのばあいにはリソースファイルを -ja、フランス語のリソースファイルを -fr のようなサフィックスのついたディレクトリに保存して指定することになるのですが、script指定のサポートが無いようです。このため、言語コードと地域を組み合わせて指定することになります。

地域との組み合わせをする場合には zh-rTW のように、国コードの前に r をつけます。よくわからないルールですが、そのように指定します。

またひとつ困ったことにAndroidの実装はJavaの実装の悪いところを引き継いでいるようでヘブライ語、インドネシア語、イディッシュ語のコードにISOでは廃止されたコードを利用しています。

Note that Java uses several deprecated two-letter codes. The Hebrew (“he”) language code is rewritten as “iw”, Indonesian (“id”) as “in”, and Yiddish (“yi”) as “ji”. This rewriting happens even if you construct your own Locale object, not just for instances returned by the various lookup methods.
http://developer.android.com/reference/java/util/Locale.html より

このためGREEプラットホームでサポートしているインドネシア語の言語コードはAndroid向けには「in」を使っています。

いかがでしょうか。このように言語対応については、ライブラリのサポート等いろいろな制約の隙間をぬいながらの選択と集中をしつつ対応が必要になります。一度決めてしまえば楽ですが、そのあとはひたすら問題をひとつずつ解決していく必要があります。

それでは次回もお楽しみに。

お知らせ

GREEでは国際化を担当する、i18n(国際化)エンジニアも随時募集しています。ご興味のある方は応募要項をご確認のうえエントリーフォームよりご応募ください。