Tutorial

For the translation Eclipse uses OSGi resource bundles. This is based on the property files in the "OSGI-INF/l10n/" folder. OSGi expects an bundle property files, 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.property" file contains key/values.

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

These keys can be used in "plugin.xml" (Eclipse 3.x) and in the model for the Eclipse workbench (Eclipse 4.x).

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

The key in your property file can be used for contribution to extensions points in the "plugin.xml" file. This is used mainly in the label attribute.

PDE support to extract existing strings from "plugin.xml". Select your "plugin.xml", right-click on it and select PDE 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 Eclipse does not provide tooling to extract the strings from a model file. You have to replace manually the hard-coded strings with %key placeholder and create the bundle.property file.

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

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

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 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 file "message*.properties " 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 NLS.bind().

			
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" in a plug-in defines which of the files are included in the exported product.

You must include your property files in build.properties" to make them available in the export.

The translation based on property files was hard-coded into Eclipse 3.x. Eclipse 4.x 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.

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.de Google Group. I have created a short list how to create good questions which might also help you.