Fragments are a convenient way to package national language translations. Let's look more closely at the directory structure used for installing locale-specific translation files. This directory structure is used regardless of whether the translated files are packaged in a fragment or delivered in the original plug-in.
There are three mechanisms for locating locale specific files in a plug-in.
It is important to understand which mechanism is used to access any given file that must be translated so that you'll know what to name the file and where to put it in the file system relative to the plug-in.
The platform core defines a directory structure that uses locale-specific subdirectories for files that differ by locale. Translated files are placed in a directory called nl under the plug-in. For example, the following install tree shows a trivial (no code) plug-in with locale-specific translations of its about.properties file. The various translations are shown as coming from a plug-in fragment rather than the plug-in itself. This is typical for shipping translations separately from the base, but you could also place the nl sub-directory under the plug-in itself.
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)
The files to be translated are not contained in JAR files. Each file should have exactly the same file name, but be located in subdirectories underneath the nl sub-directory in the fragment's (or plug-in's) root.
Only the most specific file is accessed at runtime. The file paths are searched as part of the Platform.find, IPluginDescriptor.find and Plugin.find mechanism. For example, suppose the default locale is en_CA, and a plug-in searches for the about.properties as follows:
The method will return a URL corresponding to the first place about.properties is found according to the following order:
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
This mechanism is used by plug-ins to search for well known file names inside other plug-ins. This includes the following well known file names:
(Note: The plugin.properties and fragment.properties are conspicuously absent from this list. They are treated in a sightly different way described below.)
The standard Java handling of property resource bundles is used for other files. Translated files are contained in a JAR file, with each properties file having a locale-specific name, such as "message_en_CA.properties". The files are in package-specific subdirectories and may appear in the plug-in itself or one of its fragments. Each translated properties file may be partial since lookup of keys accesses a well-defined chain of properties files.
The shape of NL fragments has evolved slightly since 2.1.
Previously all translation files (including the plugin.properties) were provided in a jar.
This was inconsistent since the plugin.properties file was provided at the root of the plug-in.
To adapt your NL fragment to the new model, remove the plugin.properties translation files from the jar and put them at the root of the fragment as siblings of fragment.xml. For example, the new shape of the NL fragment for org.eclipse.ui.workbench is the following:
org.eclipse.ui.workbench.nl/ fragment.xml plugin_fr.properties plugin_pt_BR.properties ... nl1.jar