よくある誤解
ソフトウェア開発において、たまに「多言語対応」などの表現でバックログアイテムが作成されることがあると思います。
私は英語があまり得意ではないので、この手の「多言語対応」つまり「英語版を作成する」などの対応は非常に嫌な思いになります。
しかし、そもそも作成するソフトウェアの特徴によっては、多言語対応自体が不要と断定できるものもあるでしょう。
社内システムだったり、日本(しかもある地域)でのみ利用されるサービスだったり。
この時「多言語対応は不要」といってあまり深く考えずにソフトウェアを設計・構築すると後々厄介なことになります。
例えば、社内システムでも会社自体が外資系ソフトウェア会社に買収されたり、日本でのみ利用されるサービスでも外国籍のユーザー向けに、、
などの様に「やっぱり多言語対応やってほしい」と言われることは容易に想像できます。
それでも関係ないと思われる方もいらっしゃるかもしれませんが、「多言語対応」というざっくりとしたものではなく、
タイトルの通り「国際化」と「地域化」の違いを知っておくことは、ソフトウェアエンジニアとして損はないと思います。
今回は、そんな多言語対応にまつわる「国際化」と「地域化」について記載しようと思います。
国際化とは
internationalization (i18n) と呼ばれる国際化対応とは、言語や地域(よくあるのはタイムゾーン)に依存しない様に対応することです。
毎度 Java を例にして申し訳ないですが、SpringBoot などのフレームワークには国際化の機能が既に備わっています。
そのため、あとはデータベースやコンフィグレーションなどを国際化しておけば、言語や地域に依存しないソフトウェアが構築できます。
つまり、日本でしか利用されなくても国際化しておけば、万が一、多言語対応が必要になった際にスムーズに対応できるのです。
国際化は言語や地域に依存しないための工夫なので、システム・アーキテクトとしては、どの様なソフトウェアであっても国際化を前提に設計するのがベターかと考えます。
地域化とは
localization (l10n) と呼ばれる地域化対応こそが、冒頭で記載した「多言語対応」と近しい対応です。
表示するメッセージや日時をユーザーの地域ごと変更したりすることです。
地域化については 国際化をした上で 始めて要求が来た際に対応すれば良いと思います。つまり、国際化とは異なる対応なのです。
具体的な国際化(internationalization)の手法
ここまで「地域化は要望に応じて実施するが、国際化は要望関係なく対応しておいた方がベター」と主張しました。
では、具体的な国際化の手法について、いくつか掲載したいと思います。
相変わらず、Java&SpringBoot で RESTful API を提供し、データベースには MySQL などの RDB を利用する前提で記載します。
メッセージファイル
表示するメッセージをメッセージファイルとして外出し管理することはあると思います。よくあるファイル名は messages.properties でしょうが、ここに国際化の対応を施すと
| 日本語の場合 | 英語の場合 |
|---|---|
messages_ja.properties |
messages_en.properties |
の様に ロケール ごとにメッセージファイル名を設定することになります。
ロケールとは国や地域を表す表記のことです。ja は日本語 en は英語という意味になります。
国際化を考慮してメッセージファイルを作成する場合は、日本語のみの場合でも messages.properties とせずに messages_ja.properties とすることで、「英語版が必要」となった場合の対応が楽になると考えます。
メッセージに関するちょっとしたテクニック
ご存知の様に日本語と英語は主語・述語の順番が異なります。
そのため、メッセージ自体を変数値などを利用して動的に組み立てる場合、日本語と英語を両方対応する場合に辛くなります。
(変数1)は(変数2)を実行できませんでした。
のようなメッセージを定義してしまうケースです。この場合翻訳の難易度が上がってしまいます。
ちょっとしたテクニックですが、メッセージに変数値を差し込みたい場合は、最初から下記の様なメッセージ形態にしておくと翻訳の難易度が下がります。
実行できませんでした。[変数1=(変数1)] [変数2=(変数2)]
こうすれば、変数の有無や場所にとらわれずに、純粋に翻訳作業ができる様になります。
タイムゾーンと日時表記
タイムゾーンに関連する日時処理ほど(SEとして)厄介なものはないと思いますが、国際化を意識するのであれば避けては通れないでしょう。
おそらくどんなソフトウェアでも日時を扱うことはほぼ 100% 存在すると思います。
タイムゾーンとは地域ごとの標準時のことを言い、日本は +09:00 が利用されています。
これは UTC(協定世界時) を基準にどれくらい時間をズラしているか、という意味で解釈できます。
また、 +09:00 ではなく「日本の標準時」という意味で Asia/Tokyo と表記するケースもあります。
よく考えずにソフトウェアを設計・構築すると、データベースからインターフェースまで全てAsia/Tokyoで固定してしまうことが多いでしょう。
その方が正直楽ですし、動作確認やテストの際も直感的に日時を扱えるので便利です。
しかし、一方で「アメリカでも利用されることになった」などの要求があった場合、改修規模はとんでもないことになるでしょう。
そもそも SaaS 形式でソフトウェアを提供するのであれば、ユーザーの地域は問わない方が収益的にも良いと思うので、タイムゾーンこそ国際化を意識して扱うのが良いでしょう。
タイムゾーンは基本的に UTC
私のこれまでの経験則ですが、基本的にタイムゾーンは UTC にしておくことをお勧めします。
そうすれば基本的にどのタイムゾーンにも対応できるからです。
データベースもプログラムが動作する環境(コンテナなど)もAPIのインタフェースも UTC にしておけば基本的に間違いは起きにくいです。
日時表記は ISO 8601
日時表記も地域によって様々です。そのため ISO 8601 に則り、タイムゾーンも付与した表記に統一するのが良いでしょう。
例えば、日本では 2023年1月2日 14:41 と表記することが多いですが、ISO 8601 に則ると 2022-01-02T14:41+09:00 と表記します。
バックエンド -> フロントエンドのインタフェースや、他システムとの連携などでは、ISO 8601 を利用することをお勧めします。
そうすれば、受け取った側が「どのタイムゾーンの話なのか」を理解できるのです。
つまり、ISO 8601 で UTC な日時表記とすれば上述の例は 2022-01-02T05:41Z となりますが、
フロントエンド、つまりエンドユーザーの地域が日本であるならば 2023年1月2日 14:41 と変換して表示することができるのです。
まとめ
日本でソフトウェアを開発すると、あまり「英語の場合〜」などを考えないと思いますが、そもそも 国際化 と 地域化 は異なるので、
国際化 は常に意識して設計していけると良いと思います。
また、最近はコンテナオーケストレーションなどの進化により、実行環境がコンテナベースになることが多いですが、
そうすると「ローカル開発のPCは日本標準時」だけど「実行環境のコンテナはUTC」などの現象も起きやすくなっています。
ローカルでは正常に動いてたのに、実行環境では動かない。。という原因の多くがこれらのタイムゾーンにあることは、わたしの経験から何度も目にしてきました。
ぜひ、最初から少なくとも 国際化 だけは意識して設計していきましょう！