Webサービス多言語対応 技術的なチェックリスト
Webサービスの多言語対応について絶賛勉強中です。
この記事では、Webサービスの多言語化を実現するために、システム面でできることや考慮しなければならないことをチェックリスト形式でをまとめてみようと思います。
文字コードはUTF-8になっていますか？
とにかく文字が表示できなくては多言語化は始まりません。 世界各国の文字を収録しているUNICODEは必須と言えるでしょう。
文字コードはシステムの全ての箇所で統一されている必要があります。 HTMLやアプリ等のフロントエンドだけでなく、サーバー、Webアプリケーション、DBなど、システム全体がUTF-8で統一されていることを確認します。
なお、UTF-8は日本語などの全角文字を3バイトで表現するのに対し、UTF-16は日本語も英語も全ての文字を2バイトで表現する、という性質上、アジア言語をメインにサポートする場合はUTF-16という選択肢も考えられるようです。 （とはいえ広く使われる文字コードはやはりUTF-8ですので、そこまでデータ量にこまかなチューニングが必要になるわけでなければUTF-8を使うのが安全なのではないかと思います）
テキストのハードコーディングはないですか？
システムにおける多言語化対応の大部分はテキストの翻訳作業です。
一般的に多言語化の仕組みとして、プログラム上ではテキストに対して「タグ」を割り当て、そのタグが具体的にどのような文字列を指すのかを言語ごとの翻訳テキストファイルから探し出す、という手法が広く用いられます。 プログラム内でテキストをハードコーディングしていると、そのような言語設定によるテキストの出し分けができなくなってしまいます。
多言語化を視野に入れた段階で、テキストをプログラム内にハードコードするのはやめ、タグと言語ごとの設定ファイルによってテキストを動的に変えられる仕組みを徹底するようにする必要があります。
スタイルはロケールによって切り替え可能ですか？
同じ内容の文章でも、文章の長さや読みやすいスタイルは言語によって様々です。
例えば、漢字という表意文字を使う日本語は、同じ情報量を英語よりもかなり少ない文字量で表現することが可能です。逆に、ドイツ語やフィンランド語は、英語よりも40%ほど文字数が多くなると言われています。
文字の長さだけでなく、右から左に文字が進むアラビア語、縦書きで左から右に文章が進むモンゴル語など、我々に馴染みの無いルールでテキストを表示する言語も存在します。
そのため、国際化対応ではテキストの変換だけでなく、そのテキストできれいにレイアウトを作るためにスタイルそのものを変えることが必要になってきます。そのため、言語設定ごとに適用するCSSやレイアウトファイルが切り替えられる仕組みを検討します。
画像はロケールによって切り替え可能ですか？
国際化において考えなければならないのはテキストだけではありません。画像も、対応する国や地域によっては大きな問題となる場合があります。
例えば、イスラム教では偶像崇拝を禁止しているため神様やそれに類する画像を見せるのは避けるべきです。また、女性の肌、髪の毛の露出なども、地域によっては避けたほうが良い場合があります。Webサービスではありませんが、スターバックスのロゴ問題などが有名です。
スターバックスのロゴ問題 中東編 : きよおと-KiYOTO
また、タイでは曜日ごとに色が振られており、国王や首相が生まれた曜日の色はその人を象徴する色となることがあります。そのため、社会情勢によっては色の使い方で「この人を支持する」という意思表示と解釈されてしまう可能性があったりします。
テキストだけでなく、画像も対象とする国や地域、社会情勢によってすぐに切り替えられるようにしておくと、不測の事態にすぐに対応できるでしょう。
入力フォームは各国の事情に対応できますか？
名前や住所は、国や地域ごとの文化や宗教などに大きく影響を受けます。 日本のように姓・名の入力ボックスだけではミドルネームを始めとする3つ以上の名前の構成要素に対応できないですし、逆に「よみ」はひとつの漢字に対して複数の読み方が存在する日本語固有の項目です。
ロケールによって入力フォームの構成が変えられること、また、テーブル構成がその入力内容を受け付けられることなどが求められます。
サーバーの配置場所は大丈夫ですか？
例えば、ロシアやイランでは、サービス提供者はその国民の個人情報を国外に持ち出すことを禁止しています。
外国企業の半数がサーバ移転中――ロシア人ユーザの個人情報を国内に保管 / SYNODOSが選ぶ「ロシアNOW」 | SYNODOS -シノドス-
また、地理系のサービス提供者が中国でビジネスをする場合、地図データを中国国外に持ち出すことができないなど、様々な制約を課せられます。
http://www.tcci-wbiz.jp/hotnews/2140.html
このように、ターゲットとする国によっては電子データの扱いなどに法律による制限をかけている場合がありますので、それぞれの国の事情に合わせてシステム構成全体を考え直さなければならない場合があることを考慮しておく必要があります。
ネットワークは大丈夫ですか？
法律的な制限がなくとも、地球の裏側の国へサービスを届ける場合、どうしても物理的な距離によってリクエストとレスポンスの速度が数百ミリ秒という単位で遅くなってしまう場合があります。
また、物理的な遅延以外にも、ターゲットとする国や地域のネットワークの整備上記によって、現実的な通信量は変わってきます。
もしサービスが日本の通信網で、日本国内で使うことを前提に設計されているのであれば、データの通信量自体の削減を検討する必要がある場合があります。
URL体系は整っていますか？
例えば、以下のように日本語と英語のページで、URLのロケール部分だけが違うような設計になっている場合、ユーザーはURL自体を修正することで自分の求める言語のコンテンツを表示することができます。
・日本語 https://www.example.com/ja/some/contents/0001 ・英語 https://www.example.com/en/some/contents/0001
ユーザーはどのリンクを踏んで、どの言語のどのページから自社のサービスに流入するか予測できないため、言語部分を修正するだけで同じコンテンツの言語違いのページを表示することができれば、ユーザービリティは大きく向上できるでしょう。
他にも、もしロケールによって準備ができていないページがあったとしても、該当のページが存在しないことをユーザーに提示した上で、一つ上の階層に戻るか、別の言語で表示し直すかを選ばせることができるような構造になっていれば、混乱を最小限に留めることが可能です。
サービスで利用する文言は全て任意のタイミングで表示できるようになっていますか？
翻訳者は、単語や文章だけ渡されてもそれを正確に翻訳することはできません。 想定ユーザーやサービスのコンセプト、どのような場合にどのようにそのテキストを見せるのかなど、情報量が多いほど翻訳はより正確になります。
そうなると、実際に翻訳者にサービスを触ってもらい、実際のユーザーとしての視点から翻訳作業が行えるのが理想です。
好きに触っても本番環境に影響がなく、翻訳をすぐに当てはめて検証することができ、レアなケースで表示されるテキストも任意のタイミングで表示できるような仕組みを作ることができれば、翻訳はより効率的に、正確に進められると思います。
以上、多言語化をするにあたっての技術的な確認観点をまとめてみました。 実際には、これに加えて各々のWebサービス特有の設計や事情から、他にも検討事項が出てくるのではないかと思います。
追加で記載できる内容があれば、この記事も随時更新できればと思います。
