For the translation Eclipse uses OSGi resource bundles. This is based on the property files in the OSGI-INF/l10n/ folder. OSGi expects at least one bundle property file, e.g. bundle.properties, in this folder.

Via the Bundle-Localization attribute in the MANIFEST.MF file, you point to these files.

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: I18n
Bundle-SymbolicName: de.vogella.rcp.i18n; singleton:=true
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: de.vogella.rcp.i18n.Activator
Require-Bundle: org.eclipse.ui,
 org.eclipse.core.runtime
Bundle-ActivationPolicy: lazy
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Bundle-Localization: OSGI-INF/l10n/bundle 

The bundle.properties file contains key/values.

#Properties file
TodoOverviewPart=Overview of Todos
TodoDetailPart=Todo Details 

Alternative languages are defined via additional property files. The filename of these files include a language indicator, e.g. bundle_en.properties.

The key in your property file can be used for contribution to extension points in the plugin.xml file via the %key reference. This is used mainly in the label attribute.

The Eclipse tooling supports extracting existing strings from the plugin.xml file. Select your plugin.xml file, right-click on it and select Plug-in Tools → Externalize Strings.

Via PDE Tools → Internationalize you can also directly create one or several fragments for the result of the internationalization.

The translation of model element is similar to the translation to the plugin.xml file. Use %key for labels in the model.

Currently the application model tooling includes rudimentary support for extracting Strings. Press the right mouse key in the application model editor and select, Externalize Strings.

You can also manually replace the hard-coded strings with a %key placeholder and create the bundle.property file.

To create the bundle.property file and the OSGi reference you can use the PDE wizard.

It is possible to translate the Java source with two different approaches, based on Strings and based on constants. The approach based on constants is more reliable and should be preferred. To enable this support you have to have the org.eclipse.core.runtime plug-in as dependency in your related plug-in.

To translate String in the source code, select the file you want to translate and select Source → Externalize Strings.

Please note that the Use Eclipse's string externalization mechanism option is only visible if you have the org.eclipse.core.runtime plug-in defined as dependency in your plug-in.

In this wizard you can select which strings should be translated, which can be skipped for the translation and which strings should be marked as not translatable.

If you select that a string should not be translated Eclipse will mark these strings with a $NON-NLS comment in the source code.

As the result a Messages class is generated which serves as an access point for the properties file.

package test;

import org.eclipse.osgi.util.NLS;

public class Messages extends NLS {
  private static final String BUNDLE_NAME 
    = "test.messages"; //$NON-NLS-1$
  public static String View_0;
  public static String View_1;
  static {
    // initialize resource bundle
    NLS.initializeMessages(BUNDLE_NAME, Messages.class);
  }

  private Messages() {
  }
} 

Via the BUNDLE_NAME constant it points to a resource message*.properties file in the test package. * is a placeholder for your locale, e.g. _de,_en, etc.

View_0=test.view
View_1=Hello 

In your code you access the translations via the Message class.

label.setText(Messages.View_1); 

You can also use placeholder in the messages and evaluate them with the NLS.bind() method.

MyMessage = {0} says {1} 

// NLS bind will call the toString method on obj
NLS.bind(Message.MyMessage, obj, obj); 

If Strings should be consistently used over several plug-ins, it is best practice to create a separate plug-in or fragment for the Messages. All plug-ins which wants to use the Messages define a dependency to this plug-in.

Additional languages are typically contributed via Eclipse fragment projects to this message plug-in.

The build.properties file in a plug-in defines which of the files are included in the exported product.

You must include your property files in the build.properties file otherwise your translations will be missing in the exported product.

The translation based on property files was hard-coded into Eclipse 3.x. Eclipse 4 replaces this with a flexible approach.

Eclipse 4 introduced a translation service via the TranslationService interface. The default implementation of this class is the BundleTranslationProvider which will work on property files but you can provide your own OSGi service which uses a different source, e.g. a database to get the translations.

This service is stored in the Application Context. You can replace it here, e.g. via a lifecyle hook. By storing it in the Eclipse Context you can have different translation services for different local contexts, e.g. for different Windows you can use different translation services.

Create a new Eclipse RCP application "de.vogella.rcp.i18n" based on the "RCP application with a view" template. Check the contributions to the "org.eclipse.ui.views" extension point in your plugin.xml file and validate that the name of the View is hard coded to "View".

Right-click on the plugin.xml file and select PDE Tools → Externalize Strings. Accept the default and press ok.

This will create the file bundle.properties and replace the hard-coded string in plugin.xml with a "%key" placeholder, e.g. %View.

<extension
       point="org.eclipse.ui.views">
    <view
         name="%View"
         class="de.vogella.rcp.i18n.View"
         id="de.vogella.rcp.i18n.view">
    </view>
</extension> 

Copy bundle.properties to "bundle_fr.properties" and "bundle_en.properties" Change the text in the property views for the view.

Start you application in the different languages and valid that the translation is correctly used.

View = Lars Test
 

Please help me to support this article:

Before posting questions, please see the vogella FAQ. If you have questions or find an error in this article please use the www.vogella.com Google Group. I have created a short list how to create good questions which might also help you.