omuronの備忘録

個人的な備忘録

i18nとL10nについて言語化してみる

なかざんさんのこのツイートを見て、i18nL10nについて自分の理解を言語化してみようと思いました。

自分の経験と軽く調べたことをもとに記載するので、間違いなどもあると思いますが、あくまで自分の理解をまとめたいと思います。

i18n

ソフトウェアの世界においては、複数の「地域」や「言語」を扱えるような仕組みを実装すること理解している。

国際化と地域化 - Wikipedia

「国際化」internationalizationはたびたびi18nと略される。

Wikipedia によると、i18n は国際化のこと。
「国際化」対応の仕組みを、自ら実装することもあれば、予め準備されたプラグインなどを利用する場合もある。

地域について

「地域」≒「国」と読み替えて実装することが多い。
台湾など政治的にも扱いが難しい場合もあるのでこのあたりは配慮が必要。

Web アプリケーションの場合、この判定には GEO ロケーションを利用する。
Amazon CloudFront を利用すれば判別が可能。

docs.aws.amazon.com

CloudFront は、サードパーティーの GeoIP データベースを使用して、ユーザーがいる場所を判別します。IP アドレスと国とのマッピングの正確さは、リージョンによって異なります。最近のテストによれば、全体的な正確性は 99.8% です。

ロケーション情報をもとに適切な国に割り振っていく。
「国」は、ISO 3166-1 alpha-2 を利用して2文字で表現することが多く、ドメインやパスで切り替える。

言語について

ソフトウェアの世界においては、複数の「文字」や「音声」を扱えるような仕組みを実装すること理解している。
いわゆる翻訳をしている状況。

「文字」は、ISO 639 を利用して2文字で表現することが多く、パスやクエリパラメータで切り替える。
言語の判定は、リクエストヘッダー内の accept-language を参照する。
accept-language は、複数列挙可能で優先順位付けられているため、ソフトウェアで実装している表示可能な言語を優先的にだす。

地域と言語の切替例
Apple

Apple のサイトでは、ここ で明示的に「国/地域」を変更することができる。

Sony

https://www.sony.com/ に日本からアクセスした場合、以下のように最適なサイトに促される。

f:id:omron:20201025092434p:plain

i18n まとめ

i18n は、基本的には言語の切り替えができる仕組みを作ることと考えます。
「日本」では「日本語」を主に使い、公用語が一つしか無いので普段意識し辛い状況です。
しかし、ソフトウェアを作る場合には公用語が複数ある国のことも考えておく必要もあります。

リツイート元の上記のケースは、「US」という国で日本語を優先的に使いたい人、ようするに在米日本人に向けて表示する場合であれば最適化されている状況と思います。
一方、「日本」に住んでいる「日本語」話者に向けて表示する必要があるかどうかは微妙です。

L10n

L10n は、localization の略。
i18n を行うことで翻訳の実装はできるようになる。
L10n を行うということは、言語以外にももう一歩踏み込んで、法律や通貨などその地域に住んでいる人の風習に合わせて自然に使えることを行うと理解している。

日本語で表示はできているがドル決済しかできない場合などは、完璧にローカライズができていないともいえる。
完璧にローカライズを目指す場合は、現地に法人が無いと難しいかもしれない。

まとめ

i18n で仕組みを構築し、ターゲットとする地域の L10n を行ないます。
Web アプリケーションの場合は、GEO ロケーションと accept-language から判断して、ユーザーに向けた最適化を目指します。
(ネイティブアプリケーションの場合は、OS から取れる情報をもとに実装すると思います。)

アクセス場所と言語を意識して実装する必要があると考えます。