I18N : 一プログラマのLight and Shade: アプリケーションの国際化

一プログラマのLight and Shade: アプリケーションの国際化

また、1.にしても、画面のラベルから外部リソース化するしかないのは分かるんですけど、パッと見でどんな画面かが分からなくなるので、メンテしにくくなるのは経験済み（しかも、結局4.の問題に対応するために別画面にしてしまうんですよ。パッケージ提供・サービス提供じゃなければ、結局やってくれと言われたらやるんです。

ほかの環境はわかりませんが、少なくとも、Visual Studioと.NET Fx使う場合には、開発時にラベル文字がみられないなどと言うことはありません。基本的に開発時に選択した言語に対して言語リソースを追加していくことになります。まぁもちろん追加リソースの確認にはそれなりに環境を用意する必要はありますが。

Developing International Software
	Dr. International Dr. International (Group) Microsoft Corporation Amazonで詳しく見る by G-Tools

国際化アプリケーション開発に関する日本語の本はほんとうに無いですね。

1.画面に表示される文字、メッセージを日中英切り替えられる
例：「住所を40文字以内で入力してください」「Please enter the address …」「…」
2.データが日中英で登録・表示される
例1：「千葉県船橋市」「… Funabashi-shi,Chiba pref.」「」
例2：「円」「yen」「」
3.データ表示範囲が切り替えられる
例1：日本で使う場合は日本の顧客、中国で使う場合は中国の顧客が検索される
例2：日本では「g、kg…」、アメリカでは「pound、…」
4.項目表示の有無が切り替わる
例：アメリカでのみ社会保険番号を表示する

上の本もそうなのですが、多くの多言語開発環境がたいていの場合1．だけ、WindowsのNLSのように2．のある部分までにしか対応していないのは、プラットフォームレベルで汎用化できるのがそこまでで、それ以外については、原則的にそれがアプリケーション要件だからでしょう。たとえば3.の例としてあげられている単位系の変換は実際には闇雲に変換していいわけではなく、それなりのビジネスルールが必要でしょうし、2．に関しては多言語化範囲をあらかじめ決めておかないと何か人工知能でもこさえないとといった具合にアプリケーション対象ごとの要件定義、スコープの設定が必要で、プラットフォームとしての汎用化は無理です。(まぁ優秀な人工知能でもできれば。。)

そう言う点では、

で、問題は2.以降の問題についてどういう方針をとるかのような気がしています。
そこを考えると、そもそも、一つのシステムを各国で使うのか、各国向けのシステムを提供するのかが違ってくると思うわけです。

これが最初の仕様決定上トレードオフになるという点には同感です。

で、Windowsなら、NLSの仕組みをうまく使うと国際化対応の部品化が楽です。

4.はNLSから現在のロケールをとって、条件分岐させましょう。