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サービス特有の設計や事情から、他にも検討事項が出てくるのではないかと思います。
追加で記載できる内容があれば、この記事も随時更新できればと思います。
Webサービスを多言語化するリスクを考えてみた
IKEAがサウジアラビアで製作したパンフレットが物議を醸しているという記事がありました。
IKEA's Women-free Catalogue in Saudi Arabia
内容は記事を読んでいただければと思うのですが、これを読んで、自社のWebサービスを「国際化」するつもりが「多言語化」だけで満足してしまうことのリスクについて考えたので、まとめてみます。
多言語化することのリスク
最初に紹介した記事はいわゆる「多言語化」とは違った取り組みですが、今までの顧客とは違った文化を持つ層にアプローチするという意味では多言語化するのと同じだと考えています。
その上で、多言語化することのリスクについて、以下の２つがあると思いました。
新しいターゲットに意図しないメッセージが届いてしまうリスク
例えば今私たちが日本語で日本人向けのサービスを展開していることを考えた場合、作る側が使う側の立場になって自分のサービスを見ることができるため、作る側が提示しているテキストや画像がどのように受け取られるのかをある程度予想することができます。
しかし、多言語化して自分とは全く異なる文化、言語で生活している人たちにサービスを提供するとなると、先ほどの「作る側が使う側の立場で自分のサービスを見る」ということができなくなるため、そのテキストや画像がどのように受け取られるか、予測することはほぼ不可能になってしまいます。
さらに、多言語化という意識で「言語」だけを見てしまうと、言語は同じだけれど国も文化も宗教も全く違う人たちの存在を見落とします。 例えば、スペイン語はスペインだけでなく、はるか海を渡った中南米でも公用語として使われていますし、中国語（特にMandarinと呼ばれる共通語）は中国本土の各地域や台湾、香港、さらにはシンガポールといった様々な国や地域で、13億人以上が読むことができてしまいます。
私たちが日本語で日本人に発しているテキストを単純に翻訳すれば、新しいユーザーにもそのまま同じように届くとは限らないのです。
想定外の人にメッセージが届いてしまう
今回のIKEAの件は、イスラム教を厳格に守っている人たちに向けてサービスをチューニングした結果、それが全く意図しない「女性の人権を考える人たち」に拾われてしまったことが発端のようです。
つまり、良かれと思って特定の言語に対応した結果、それ自体を快く思わない人たちが出てくるリスクがある、ということになります。
例えば、同じハングルでも韓国と北朝鮮では書き方・読み方に方言のような差異があるそうなのですが、韓国人向けにハングルでサービスを提供した結果それを目にした北朝鮮の人が「ハングルと言ったら北朝鮮だろう、なんで南訛りの表記をしているんだ！」とクレームの声を上げることも考えられないことではありません。
上の例はさすがにそう起こることではないかと思いますが、とはいえ宗教上の対立、紛争地域、歴史的な経緯などが影響して、「こっちのユーザーを想定してこの言語で出したら、それを読めちゃうあっちのユーザーが不快に思う」という事態は十分起こり得るのではないかと思います。
システム的な多言語対応というと、言語設定ごとのテキストの変換や、画像などのリソースファイルの選択をサポートしてくれるものがほとんどで、それを使って満足してしまうこともあるのではと思いますが、それだけでは不十分どころか、サービスの内容や翻訳方法によってはブランドイメージを損なう可能性もあるのではないかとIKEAの記事を読んで考えました。
本当にターゲットの国のユーザーに使ってほしいのであれば、テキストの翻訳だけで満足するのではなく、いわゆるグロースハックのような、継続的な検証と修正が国・地域ごとに必要なのではないかと思います。
技術的には、翻訳文を変換する仕組みの実装だけでなく、国・地域ごとに継続的に細かなチューニングができる柔軟な環境づくり、場合によってはある国向けのサービスだけ全く別のシステムとして構築し直すことになった場合にシステム全体を再設計する力、などが必要になるのではないかと思います。
機能を追加すれば必ず何かを失う。とても声を大にして言いたい。
— ちゅーやん_i18n (@chooyan_i18n) 2017年2月13日
最小限にこだわるサービス開発の試み - クックパッド開発者ブログ https://t.co/BhKiOaSK0U
やればいいというものではない、ということかなと思います。
i18n対応で参考になりそうなサイト
Webサービスの国際化対応について勉強するにあたり、参考になりそうなサイトをまとめます。随時更新です。
コーディングのガイドラインなど
文字コードとは、みたいな基本的なところからまとまっているので入門として使えそう。
Androidアプリを国際化する際に知っておきたい基本的な仕組み。
実際の例
実際に世界中にサービスを展開している企業のウェブサイトは参考になることが多い。
stackoverflowの議論
- localization - i18n and l10n web guidelines - Stack Overflow
- php - How would you transform a pre-existing web app into a multilingual one? - Stack Overflow
- c# - What Should I Know and Consider To Create Multi Language Web Site - Stack Overflow
それぞれ言語は違うけれど、サービスを国際化する際に考えなければならないこと、という意味では特にどの言語で書くかは関係ない。
その他参考になりそうな記事
SwiftでiOSアプリを国際化する際に知っておきたいTips、ノウハウなど。iOS以外でも同様に使える知識が書かれている。
“10 Best Practice Tips On How To Write Global-Ready Content For Localization” というタイトルの記事。国際化対応は大変だけど、これだけ抑えておけばある程度対応が楽になる、という話。
さらにその他
Webサービスが開発できる言語であれば、だいたいサービスの国際化をサポートするライブラリなりツールなりが開発されているので、それらができることをじっくり見ていけば、どんなところに気をつける必要があるのかある程度分かってくる気がします。
