MUI の基本的な概念の説明

• MUI の前提条件
• 言語固有のリソースからのソース コードの分離
  • 初期: コードとリソースが一緒に生きています
  • コードとローカライズ可能なリソースを論理的に分離する
  • コードとリソースを物理的に分離する
• 言語固有のリソースを動的に読み込む
• MUI アプリケーションのビルド

MUI の前提条件

Windows Vista 以降の MUI 準拠アプリケーションを構築するための基本的な前提条件は、Windows グローバリゼーション ガイドラインに従ってアプリケーションを設計することです。

言語固有のリソースからのソース コードの分離

MUI テクノロジの基本的な前提の 1 つは、アプリケーションの多言語シナリオをより効率的に実現するために、アプリケーションのソース コードを言語固有のリソースから分離することです。 コードとリソースの分離は、次のセクションで説明するように、さまざまなメカニズムと時間の経過と同時に異なる度に実現されています。 各方法では、アプリケーションの構築、展開、およびサービスの柔軟性が異なります。

MUI 準拠アプリケーションに推奨されるソリューションは、ここで説明する最後の方法、つまりアプリケーションのソース コードとリソースの物理的な分離です。リソース自体は、ビルド、デプロイ、およびサービスの柔軟性を最大限に高めるために、サポートされている言語ごとにさらに 1 つのファイルに分割されます。

初期: コードとリソースが一緒に生きています

最初は、ローカライズされたアプリケーションは、ソース コードを編集し、コード自体のリソース (通常は文字列) を変更し、アプリケーションを再コンパイルすることによって作成されました。 つまり、ローカライズされたバージョンを生成するには、元のソース コードをコピーし、ソース コード内のテキスト (リソース) 要素を翻訳し、コードを再コンパイルする必要がありました。 次の図は、ローカライズする必要があるテキストを含むアプリケーション コードを示しています。

この方法ではローカライズされたアプリケーションを作成することができますが、次の重要な欠点もあります。

• ソース コードには複数のバージョンが必要です。ソース言語には少なくとも 1 つ、ターゲット言語ごとに 1 つ必要です。 これにより、アプリケーションのさまざまな言語リリースの同期に大きな問題が発生します。 特に、コードで欠陥を修正する必要がある場合は、ソース コードのすべてのコピー (言語ごとに 1 つ) で欠陥を修正する必要があります。
• また、開発者ではないローカライザーがソース コードで変更を加える必要があるため、非常にエラーが発生しやすく、コードの整合性に関してかなりのリスクが生じます。

これらの欠点を組み合わせることで、これは非常に非効率的な提案となり、より良いモデルが必要でした。

コードとローカライズ可能なリソースを論理的に分離する

前のモデルに比べて大幅に改善されたのは、アプリケーションのコードとローカライズ可能なリソースの論理的な分離です。 これにより、コードがリソースから分離され、ローカライズによってリソースが変更されるときにコードが変更されないようにします。 実装の観点から、文字列やその他のユーザー インターフェイス要素はリソース ファイルに格納されます。これは比較的簡単に変換でき、コード セクションから論理的に分離されます。

理想的には、特定の言語のサポートを追加することは、ローカライズ可能なリソースをこの新しい言語に翻訳し、これらの翻訳されたリソースを使用して、コードを変更することなく、新しいローカライズされたバージョンのアプリケーションを作成するのと同じくらい簡単です。 次の図は、コードとローカライズ可能なリソースをアプリケーション内で論理的に分離する方法を示しています。

このモデルを使用すると、アプリケーションのローカライズされたバージョンを簡単に作成でき、以前のモデルよりも大幅に改善されています。 このモデルは、リソース管理ツールを使用して実装され、長年にわたって非常に成功しており、現在でも多くのアプリケーションで一般的に使用されています。 ただし、これには大きな欠点があります。

• 論理的に分離されますが、コードとローカライズされたリソースは、1 つの実行可能ファイルに物理的に結合されます。 特に、同じコードの欠陥 (すべての言語バージョンで同じ) に言語ごとにパッチが必要であるため、保守性は依然として問題です。 したがって、アプリケーションが 20 言語で配布されている場合は、コードが 1 回だけ修正される場合でも、サービスパッチを 20 回 (言語ごとに 1 つずつ) 発行する必要があります。
• 多言語アプリケーションの配布と使用は、このモデルでは適切にサポートされていません。 これは、OEM とエンタープライズのシナリオで大きな問題になる可能性があります。 たとえば、異なる言語を使用して 2 人のユーザー間でコンピューターを共有する場合、このモデルでアプリケーションを 2 回インストールする必要があります。その後、2 つのインストールを切り替えるために、いくつかのメカニズムを有効にする必要があります。 これは、このシナリオが実装されるのを妨げる追加の依存関係がないことを前提としています。 次の図は、2 つのパッチを必要とする 1 つのコード欠陥の例を示しています。

このモデルは一部のシナリオでうまく機能しますが、多言語アプリケーションとそのデプロイに関する制限は非常に問題になる可能性があります。

多言語アプリケーションの問題の一部を軽減するこのモデルのバリエーションは、ローカライズ可能なリソースに一連の異なる言語リソースが含まれているモデルです。 このモデルには、共通のコード ベースと、同じアプリケーション内の異なる言語用のいくつかのリソースがあります。 たとえば、アプリケーションでは、英語、ドイツ語、フランス語、スペイン語、オランダ語、イタリア語を同じパッケージに含めることができます。 次の図は、複数の言語リソースを含むアプリケーションを示しています。

このモデルを使用すると、コードの欠陥を修正する必要がある場合 (これは改善点です)、アプリケーションのサービスを簡単に行うことができますが、追加の言語のサポートに関しては、以前のモデルよりも改善されません。 この場合も、アプリケーションの新しいバージョンをリリースする必要があります (また、すべての言語リソースが同じディストリビューション内で確実に同期されるようにする必要性によって、そのリリースは複雑になる可能性があります)。

コードとリソースを物理的に分離する

次の進化の手順は、コードとリソースを物理的に分離することです。 このモデルでは、リソースはコードから抽象化され、さまざまな実装ファイルで物理的に分離されます。 特に、これはコードが本当に言語に依存しなくなる可能性があることを意味します。同じ物理コードは、実際には、アプリケーションのすべてのローカライズされたバージョンに対して出荷されます。 次の図は、コードとローカライズ可能なリソースを物理的に分離する必要があることを示しています。

このアプローチには、前のアプローチに比べていくつかの利点があります。

• 多言語ソリューションの展開が大幅に簡略化されています。 特定の言語のサポートを追加するには、この特定の言語の新しい言語リソースセットの配布とインストールのみが必要です。 これは、言語リソースがすべて同時に使用できるわけではない場合に特に重要です。 このモデルを使用すると、一連のコア言語でアプリケーションをデプロイし、実際のコードを変更または再デプロイすることなく、時間の経過と共にサポートされる言語の数を増やすことができます。 この利点は、特定の言語でアプリケーションとシステム コンポーネントの部分的なローカライズを可能にするフォールバック メカニズムによってさらに拡張されます。この優先言語で見つからないリソースが、ユーザーも理解している別の言語に "フォールバック" されるようにします。 全体として、このモデルは、単一イメージのデプロイをより効果的な方法で実現できるため、グローバル企業が複数の言語でアプリケーションをデプロイする際に直面するかなりの負担を軽減するのに役立ちます。
• サービスの容易性が向上しました。 コードは完全にローカライズに依存しないため、コードの欠陥を修正してデプロイする必要があるのは 1 回だけです。 このモデルでは、変更が UI に関連しない場合にコード欠陥の修正を発行する方が、以前のモデルよりもはるかにシンプルでコスト効率が高くなります。

言語固有のリソースを動的に読み込む

ソース コードを言語固有のリソースから物理的に分離し、アプリケーションの言語に依存しないコア バイナリを構築するという MUI の基本的な概念は、基本的に、ユーザーとシステムの言語設定に基づいて言語固有のリソースを動的に読み込むのに役立つアーキテクチャを設定します。

言語に依存しないコア バイナリにバンドルされたアプリケーション ソース コードは、Windows プラットフォームの MUI API を利用して、特定のコンテキストに対する適切な表示ユーザー インターフェイス言語の選択を抽象化できます。 MUI では、次の方法でこれをサポートしています。

• システム、ユーザー、アプリケーション レベル、ユーザー レベル、およびシステム レベルの設定に基づいて、表示ユーザー インターフェイス言語の優先順位付けされた一覧を作成します。
• ローカライズされたリソースの可用性に基づいて、この優先順位付けされた言語の一覧から適切な候補を選択するフォールバック メカニズムを実装します。

優先順位付けされたフォールバックを使用してユーザー インターフェイス リソースを動的に読み込む利点は次のとおりです。

• この優先言語で見つからないリソースは優先順位付けされた一覧の次の言語に自動的にフォールバックするため、特定の言語でアプリケーションとシステム コンポーネントを部分的にローカライズできます。
• これにより、ある言語から別の言語に動的に切り替えるなどのシナリオが可能になります。
• これにより、OEM と企業の一連の言語をカバーするリージョンまたはワールドワイドの単一デプロイ イメージを作成できます。

MUI アプリケーションのビルド

前のセクションでは、ソース コードを言語固有のリソースから分離するためのオプションと、コア Windows プラットフォーム API を利用してローカライズされたリソースを動的に読み込める利点について説明しました。 これらはガイドラインですが、Windows プラットフォーム用の MUI アプリケーションを開発するための具体的な規範的な方法がないことも指摘する必要があります。

アプリケーション開発者は、さまざまなユーザー インターフェイス言語設定、リソース作成オプション、およびリソース読み込み方法を処理する方法を完全に選択できます。 開発者は、このドキュメントに記載されているガイドラインを評価し、要件と開発環境に合った組み合わせを選択できます。

次の表は、Windows プラットフォーム用の MUI アプリケーションを作成しようとしているアプリケーション開発者が使用できるさまざまな設計オプションをまとめたものです。