Shoeisha Technology Media

CodeZine(コードジン)

記事種別から探す

【デブサミ2012】16-A-6 レポート
グリーに学ぶ、グローバル展開の最新事情

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2012/03/09 14:00

目次

国際化の技術的課題に対し、どの方法で解決し、どこまで対応するか

 ではアプリケーションを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か国対応にするだけで世界の半分をカバーできる可能性がある。ぜひ日本を盛り上げつつ、世界中のアプリケーションが乱れ飛ぶ状況になると面白い」と語り、セッションを閉じた。

図2:アプリケーション国際化の基本
図2:アプリケーション国際化の基本
お問い合わせ

GREE Engineers' Blog

http://labs.gree.jp/blog/

グリー株式会社

東京都港区六本木6-10-1 六本木ヒルズ森タワー

http://www.gree.co.jp/



  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

バックナンバー

連載:【デブサミ2012】セッションレポート

もっと読む

All contents copyright © 2005-2017 Shoeisha Co., Ltd. All rights reserved. ver.1.5