Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Mail Systems
Eclipse Documentation

How To Guides
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Problem Solutions
Privacy Policy




Eclipse Plug-in Developer Guide
Previous Page Home Next Page

Locale specific files

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.  

  • Platform core mechanism (the platform's runtime locale-specific sub-directory search)
  • Java resource bundles (java.util.ResourceBundle)
  • The mechanism (Translating values from the plugin.xml files)

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.

Platform core mechanism

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 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.

        plugin.xml    (default locale)
        fragment.xml   (a fragment of com.example.acme.acmewebsupport 1.0.0)
    (French locale)
      (French Canadian locale)
       (French France Euros)
    (English locale)
      (English Canadian locale)
     (English US locale)
   (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 as follows:


The method will return a URL corresponding to the first place is found according to the following order:

 ...  		<any other fragments>

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:

  •  (externalized strings for plug-in -specific preference default overrides)
  •  (externalized strings for feature "about" information)
  •  (externalized strings for product-specific preference default overrides)
  • splash.bmp  (product-specific splash screens)

(Note:  The and are conspicuously absent from this list. They are treated in a sightly different way described below.)

Java resource bundles

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 "".  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 mechanism

The mechanism used to translate files uses the Java resource bundles naming convention. However the files must be located in the root of the plug-in or in the root of a fragment of this plug-in. The same rules apply to the translation of MANIFEST.MF.

Defining NL fragments

The shape of NL fragments has evolved slightly since 2.1. Previously all translation files (including the were provided in a jar. This was inconsistent since the file was provided at the root of the plug-in.
To adapt your NL fragment to the new model, remove the 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:

  Published under the terms of the Eclipse Public License Version 1.0 ("EPL") Design by Interspire