ロケール特定ファイル

フラグメントは、各国語翻訳をパッケージするために便利な方法です。  ロケール特定翻訳ファイルをインストールするために使用されるディレクトリー構造について詳しく見てみましょう。  翻訳済みファイルがフラグメントにパッケージされるか、またはオリジナル・プラグインで配布されるかにかかわらず、このディレクトリー構造が使用されます。

プラグイン内のロケール特定ファイルの位置決めには 3 つのメカニズムがあります。   

翻訳の必要な指定されたファイルにアクセスするためにどちらのメカニズムを使用するかを理解することが重要です。 これにより、ファイルに付ける名前と、プラグインを基準にしてファイル・システムのどこにそのファイルを置くかを認識できます。

プラットフォーム・コア・メカニズム

プラットフォーム・コアは、ロケールによって異なるファイルにロケール特定サブディレクトリーを使用するディレクトリー構造を定義します。 翻訳済みファイルは、プラグインの下のディレクトリー nl に置かれます。  たとえば、以下のインストール・ツリーは、その about.properties ファイルのロケール特定の翻訳が入っている 一般的な (コードなし) プラグインを示しています。  さまざまな翻訳が、プラグイン自体ではなくプラグイン・フラグメントから発生していることが示されています。  これは、ベースから翻訳を個別に配送する典型的な例ですが、プラグイン自体の下にあるサブディレクトリー nl に置くこともできます。 

acmeweb/
  eclipse/
    plugins/
      com.example.acme.acmewebsupport_1.0.0/
        plugin.xml
        about.properties    (default locale)
      com.example.acme.fragmentofacmewebsupport_1.0.0/
        fragment.xml   (a fragment of com.example.acme.acmewebsupport 1.0.0)
        nl/
          fr/
            about.properties  (French locale)
            CA/
              about.properties  (French Canadian locale)
            FR/
              EURO/
                about.properties (French France Euros)
          en/
            about.properties  (English locale)
            CA/
              about.properties  (English Canadian locale)
            US/
              about.properties (English US locale)
         de/
            about.properties (German locale) 

翻訳されるファイルは、JAR ファイルには含まれていません。 それぞれのファイルは全く同じファイル名を持つ必要がありますが、フラグメント (またはプラグイン) のルートにある nl サブディレクトリーの下のサブディレクトリーに配置されなければなりません。 

ランタイムには最も特定的なファイルのみがアクセスされます。 ファイル・パスは、Platform.findIPluginDescriptor.find、および Plugin.find メカニズムの一部として検索されます。   例えば、デフォルト・ロケールが en_CA で、プラグインが about.properties を以下のように検索するとします。

somePlugin.find("$nl$/about.properties");

メソッドは、以下の順序に基づいて検索した結果、about.properties が検出された最初の場所に対応する URL を返します。

com.example.acme.acmewebsupport_1.0.0/nl/en/CA/about.properties
com.example.acme.fragmentofacmewebsupport_1.0.0/nl/en/CA/about.properties
 ...  		<any other fragments>
com.example.acme.acmewebsupport_1.0.0/nl/en/about.properties
com.example.acme.fragmentofacmewebsupport_1.0.0/nl/en/about.properties
 ...
com.example.acme.acmewebsupport_1.0.0/about.properties
com.example.acme.fragmentofacmewebsupport_1.0.0/about.properties

このメカニズムは、既知のファイル名を他のプラグインの内部で検索する場合にプラグインによって使用されます。  これには、以下の既知のファイル名が含まれます。

(注:  plugin.properties および fragment.properties がこのリストに入っていないのはひときわ目立ちます。 これらは、以下の説明とは若干異なる方法で扱われます。)

Java リソース・バンドル

他のファイルについては、プロパティー・リソース・バンドルに対する標準的な Java 処理が使用されます。  翻訳されたファイルは JAR ファイルに含まれ、各プロパティー・ファイルはロケールに固有の名前 ("message_en_CA.properties" など) になります。  ファイルは、パッケージに固有のサブディレクトリーに入れられ、プラグイン自体またはそのフラグメント内に現れることが可能です。  翻訳された各プロパティー・ファイルは、キーのルックアップが、明確に定義されたプロパティー・ファイルのチェーンにアクセスするため、 部分的であることが可能です。

plugin.properties メカニズム

plugin.properties ファイルを変換するときに使用されるメカニズムでは、Java リソース・バンドル命名規則が使用されます。ただし、ファイルは、プラグインのルートまたはプラグインのフラグメントのルートに配置される必要があります。 この規則は、MANIFEST.MF の変換にも適用されます。

NL フラグメントの定義

NL フラグメントの形状は、2.1 以降、若干進化しています。 以前は、変換ファイル (plugin.properties を含む) は、すべて JAR で提供されていました。 plugin.properties ファイルはプラグインのルートで提供されるため、これは矛盾していました。
NL フラグメントを新規モデルに適合させるには、JAR から plugin.properties 変換ファイルを除去し、このファイルをフラグメントのルートに fragment.xml の兄弟として配置します。 例えば、org.eclipse.ui.workbench の NL フラグメントの新規形状は、以下のとおりになります。

  org.eclipse.ui.workbench.nl/
     fragment.xml
     plugin_fr.properties
     plugin_pt_BR.properties
     ...
     nl1.jar