# How to Internationalize your Eclipse Plug-In

• Print
From the author of

## Internationalization of the Eclipse Platform (V 1.0)

The focus of this section is not a "how to" for Eclipse internationalization, but rather a review of the version 1.0 implementation and its translation-related build processes. Some of these topics are quite specific to the platform itself and describes processes that are not relevant to developers simply wishing to NL-enable their plug-ins to the platform. This section is aimed at those who wish to understand how the platform was NL-enabled and want to navigate the considerable number of files, subdirectories, and JARs that encompass the translated product.

The Eclipse Platform comes internationalization-ready including the ability to enter double-byte characters and support bi-directional data. It is available in the following languages:

• Brazilian Portuguese
• French
• German
• Italian
• Japanese
• Korean
• Simplified Chinese
• Spanish

These are collectively referred to within IBM as the group-1 languages.

What and where are the various elements that were translated?

The Eclipse Platform relies on the internationalization framework provided in the Java SDK. Therefore, the bulk of the translatable text is located in *.properties files. But there are other file formats that include translatable information, such as HTML, XML, and bitmaps (summarized in Table 2. Eclipse-specific (non-Java) translatable resources).

Translation is an art, a balance between time, effort, and costs. It takes into consideration how quickly a product evolved and how quickly it needs to reach the market. There are always analyses and give-and-take decisions about what must be translated and what would be nice to translate.

In a nutshell, Eclipse concentrates its translation in three major areas:

• Plug-ins
• Welcome view

The files involved are:

• *.properties files
• *.html files and their associated "wiring" files
• welcome.xml file

### Eclipse plug-ins: .properties files

In Eclipse, each product plug-in contains properties files. Translating the plug-in means translating its properties files. There are two main steps in handling the properties files:

#### Font related .properties files

Each operating system uses a different set of fonts, and some languages have their own set of fonts (most notably the DBCS languages). The operating system suggests a default font, but the page designer's optimal layout is tied to a specific font, so using it may result in poorly formatted pages. To ensure translated text is displayed correctly, the Eclipse Workbench uses a particular set of fonts consistent with each language/operating system combination.

NOTE

Only those Eclipse Platform developers that are adding support for a new operating system or language will need to create new jfacefonts* property files. Never modify the contents of another plug-in's subdirectory, including the fonts specified in the JFace properties file that come with the Eclipse Platform.

The various Eclipse fonts are defined in the JFace plug-in. You can find the default Eclipse fonts.properties files in:

Location of the default Eclipse fonts.properties files


eclipse\plugins\org.eclipse.ui\workbench.jar
org\eclipse\jface\text\JFaceTextMessages.properties
org\eclipse\jface\resources\jfacefonts.properties (OS default)
org\eclipse\jface\resources\jfacefonts_linux.properties
org\eclipse\jface\resources\jfacefonts_windows2000.properties
org\eclipse\jface\resources\jfacefonts_windowsnt.properties

There are four org.eclipse.ui jfacefonts properties files for each language, all stored in the same NL fragment JAR, <eclipse_root>\fragments\org.eclipse.ui.nl1\nl1.jar.

For example, Italy has jfactfonts_it.properties, jfactfonts_linux_it.properties, jfactfonts_windowsnt_it.properties, and jfactfonts_windows2000_it.properties. Spain has jfactfonts_es.properties, jfactfonts_linux_es.properties, jfactfonts_windowsnt_es.properties, and jfactfonts_windows2000_es.properties, etc.

Add support for a new language by copying the base jfacefonts files above, adding a country suffix (such as jfactfont_linux_xx.properties for country code "xx"), and inserting the new jfacefonts files into the NL fragment JAR.

End-user messages.properties files

To translate the plug-ins' end-user messages:

1. Translate the .properties files.

2. Convert the properties files from the locally-encoded codepage to the encoding expected by PropertyResourceBundle.

3. Follow the Java resource naming convention to rename your files with the correct locale (for example, en = English, de = German, fr = French, it = Italian).

4. Insert the properties file back into the source directory of your NL fragment JAR that you created with the PDE.

The Java resource file naming conventions allow for a language, region, and variant (basename_language_region_variant), however Eclipse only specifies the language in all but three cases (Portuguese, Chinese/China, and Chinese/Taiwan):

<name>_<locale>_<region>.properties

PropertyResourceBundle will automatically find the resource file corresponding to the current locale at runtime. For example, an English plugin.properties would initially be copied to plugin_de.properties for German in preparation for translation.

Eclipse has five online helps. The base language documentation is delivered as plugin-ins in their own subdirectory, and the translated versions are delivered as plug-in fragments. The "documentation" plug-ins are located as follows:

#### Table 1. Location of Eclipse documentation plug-ins

 Online help Location Workbench User Guide eclipse\plugins\org.eclipse.platform.doc.user Java Development User Guide eclipse\plugins\org.eclipse.jdt.doc.user Platform Plug-in Developer Guide eclipse\plugins\org.eclipse.platform.doc.isv JDT Plug-in Developer Guide eclipse\plugins\org.eclipse.jdt.doc.isv PDE Guide eclipse\plugins\org.eclipse.pde.doc.user

The plug-in manifest file, plugin.xml in each of the above directories, defines the help contributions. The necessary help infoset and wiring files are defined in the same directory. To translate the online help:

2. Convert the translated doc.properties from the locally-encoded codepage and rename according to locale-specific resource file naming convention.

3. Insert the properties file back into the source directory of your NL fragment JAR that you created with the PDE.

5. Put the translated .html into the corresponding plug-in fragment directory.

If you translate the online help into more than one language, you must create a language directory structure to hold your country-translated HTML. These files are not locale-sensitive like property files, and thus must keep their original file name and extension. To differentiate, for example, the set of Japanese .html files versus those in German, you must save them under a different directory name, each one representing a country.

For example, the German set of Workbench User Guide *.html files are stored in eclipse\fragments\org.eclipse.platform.doc.user.nl1\nl\de. The Japanese welcome.xml is in eclipse\fragments\org.eclipse.platform.doc.user.nl1\nl\ja.

Eclipse's "Help > Welcome" menu choice: welcome.xml file

The welcome.xml is the introductory view that is displayed when the Workbench first opens or when the user selects Help > Welcome. It is located in eclipse\plugins\org.eclipse.sdk_1.0.0.

Here are the steps to translate the welcome.xml file:

1. Translate the welcome.xml file.

2. Save the translation in UTF-8 format (using Notepad, for example). If you forget to save it in UTF-8, the XML parsing code will display an error if it encounters an accented character (that is, a codepoint that isn't part of the UTF-8 codepage).

3. Just like the .html files, if you translate the welcome.xml into many languages, you will need to save each welcome.xml under a locale-specific directory name. For example, the German welcome.xml is in eclipse\fragments\org.eclipse.sdk_1.0.0\nl\de, and the Japanese welcome.xml is in eclipse\fragments\org.eclipse.sdk_1.0.0\nl\ja..