国/地域別情報に応じてユーザーに情報を表示するアプリケーションを、 グローバリゼーション されていると形容します。こうしたアプリケーションは、 異なる場所のユーザーと国/地域別に適切な方法で対話するよう構成できます。 グローバリゼーションされたアプリケーションでは、 ある地域のユーザーが、エラー・メッセージ、出力、およびインターフェース・エレメントを自分の要求した言語で見ることができます。 通貨と同様に日付と時刻のフォーマットも、特定地域のユーザーに適した形で表示されます。 他の地域のユーザーは、その地域の標準的な言語やフォーマットで出力を見ることができます。 グローバリゼーションは 2 つの段階で構成されます。国際化対応 (アプリケーション・コンポーネントが地域の規則を使用できるようにします) とローカリゼーション (特定の地域規則を実装します) です。
従来、グローバル化されたアプリケーションの作成は、複雑なシステムを作成する大企業に限られていました。 しかし、分散コンピューティングの普及、およびワールド・ワイド・ウェブ (WWW) の利用の増加により、 アプリケーション開発者は、はるかに多種多様なアプリケーションをグローバル化するよう迫られています。 この傾向の結果、アプリケーション開発者がグローバリゼーションの技法をさらに簡単に利用できるようにす ることが必要になっています。
アプリケーションの国際化対応は、時間帯とロケールという 2 つの変数により実行されます。 時間帯 は、グリニッジ標準時 (GMT) などの標準時間からの時間差としてローカル時間を計算する方法を表します。 ロケール は、言語、通貨、および日付などの情報を表す規則に関する情報の集まりです。 1 つの時間帯に多数のロケールが含まれることもあれば、 1 つのロケールが複数の時間帯にまたがっている場合もあります。時間帯とロケールの両方を指定することにより、 特定地域にいるユーザーの日付、時間、通貨、および言語が判別されます。
グローバル化されていないアプリケーションでは、 ユーザー・インターフェースは変更できない方法でアプリケーション・コードに書き込まれています。 ユーザー・インターフェースを国際化対応する場合は、アプリケーションの設計に抽象層を追加することになります。追加の抽象層によりアプリケーションによってサポートする必要がある各ロケールのアプリケーションをローカライズすることができます。
ローカライズされたアプリケーションでは、 ロケールによりアプリケーションがメッセージ・ストリングを取得するメッセージ・カタログが決定されます。アプリケーションは、エラー・メッセージを印刷するのではなく、いくつかのニュートラル言語情報とともにエラー・メッセージを表示します。最も単純な場合、各エラー状態は 1 つの鍵に対応します。使用可能なエラー・メッセージを印刷するには、アプリケーションで メッセージ・カタログ 内のキーを検索します。 それぞれのメッセージ・カタログは、関連付けられたストリングを持つキーのリストです。 それぞれのメッセージ・カタログが、異なるサポート言語のストリングを提供します。 アプリケーションは適切なカタログのキーを検索して、 対応するエラー・メッセージを要求された言語で取り出し、ストリングをユーザーに向けて印刷します。
エラー・メッセージを翻訳するよりも、テキストのローカリゼーションの方がはるかに応用が利きます。 たとえば、グラフィカル・ユーザー・インターフェース (GUI) の各エレメントを示すためにキーを使用したり、適切なメッセージ・カタログを提供したりすることにより、 GUI (ボタン、メニューなど) で複数の言語をサポートできるようになります。 追加言語に対するサポートを拡張するには、これらの言語用のメッセージ・カタログを提供する必要があります。 多くの場合において、アプリケーションには修正を加える必要はありません。
ローカライズ可能なテキスト・パッケージは、 Java クラスとインターフェースのセットであり、分散アプリケーションでストリングを容易にローカライズするために使用できます。言語固有のストリング・カタログは集中して保管できるため、効果的に保守できます。
インターネット・ベースのビジネス計算モデルの出現によって、異なる 地理的地域で運用されるクライアントやサーバーで構成されるアプリケーションが増加しています。これらの相違により、 強固なクライアント/サーバー・インフラストラクチャーの設計のために以下のような課題が生じています。
クライアントおよびサーバーは、異なるエンディアン方式を持つコンピューター内に存在できます。 クライアントをリトル・エンディアン方式の CPU に置き、 サーバー・コードをビッグ・エンディアン方式の CPU で実行させることが可能です。 クライアントが、クライアントのものとは異なるコード・セット上で実行されるサーバー上の ビジネス・メソッドを呼び出す場合があります。
クライアント/サーバー・インフラストラクチャーは、正確なエンディアンおよびコード・セットの追跡および型変換の規則を定義する必要があります。 Java プラットフォームでは、すべてのストリング・データを UCS-2 形式でエンコードし、 すべてをビッグ・エンディアン形式で外部化する Java 仮想マシン (JVM) に依存する独特の方法でこれらの問題をほぼ解消してきました。JVM では、ネイティブ・プラットフォームとのインターフェースをとるための、 プラットフォーム固有のプログラムのセットを使用しています。これらのプログラムでは、 UCS-2 とプラットフォームのネイティブのコード・セットの間で必要なコード・セット型変換が実行されます。
クライアントおよびサーバーのプロセスは異なるロケール設定を使用することができます。例えば、スペインのクライアントが、米国英語のサーバー上にあるオブジェクト上のビジネス・メソッドを呼び出すことができます。実際は、いくつかのビジネス・メソッドは ロケールに依存します。例えば、 ストリングのソート済みリストを戻すビジネス・メソッドの場合、 スペインのクライアントは、サーバーの英語照合シーケンスではなく、 スペイン語照合シーケンスに従ってそのリストがソートされることを期待します。データ検索およびソート・プロシージャーはサーバー上で実行されるので、 合理的なソートを実行するためにクライアントのロケールが使用可能である必要があります。
類似した 考慮事項が適用される例がほかにもあります。サーバーが、 日付、時刻、通貨、例外メッセージなどを含むストリングをクライアントの国/地域別の期待に沿うフォーマットで 戻さなくてはならない場合です。
クライアントおよびサーバーのプロセスは異なる時間帯での稼働が可能です。 これまで、 すべての国際化対応の文献およびリソースは、主にコード・セットおよびロケール関連問題に集中していました。 ビジネス・メソッドが ロケールだけでなく時間帯に依存する場合があるにもかかわらず、これらでは 時間帯問題が概して無視されていました。
例えば、ベンダーが「2:00 PM までに受注した注文は、同日の 5:00 PM までに処理する」と要求すると仮定しましょう。 与えられる時刻は 当然、注文を処理しているサーバーの時間帯です。他の時間帯にいるカスタマーに同日処理の正しい時刻を与えるために、 クライアントの時間帯を認識していることが大切です。
他の時間帯依存の操作には、 サーバーにログ記録されるメッセージへのタイム・スタンプ付加、 およびファイルまたはデータベース・リソースへのアクセスが含まれます。夏時間調整の概念によって、 時間帯問題はさらに複雑になります。
Java 2 Platform, Enterprise Edition (J2EE) は、 異なるエンディアン方式およびコード・セットを使用したコンピューター上で実行されているアプリケーション・コンポーネントに対するサポートを提供します。 異なるロケールまたは時間帯を持つコンピューター上で実行されているアプリケーション・コンポーネントに対しては、 専用のサポートは提供していません。
国際化対応サービスでは、 従来の技法の制限を受けることなく、 ロケールおよび時間帯のミスマッチにより発生する問題に対処できます。 このサービスは、クライアント・アプリケーション、エンタープライズ Bean、 サーブレットなどの EJB アプリケーションのさまざまなコンポーネント間で、 国際化対応コンテキストの配布を体系的に管理します。詳しくは、タスク概要: アプリケーション・コンポーネントの国際化対応 (国際化対応サービス) を参照してください。