Chapter 5. Managing internationalisation with Nuxeo RCP

Table of Contents

5.1. Making your plugin "internationalizable"
5.1.1. Simple rules
5.1.2. Java files
5.1.3. Externalize plugin.xml
5.2. Contributing a language pack.

Nuxeo RCP is following the Eclipse project way to internationalize messages. This chapter will explain how to quickly make your plugin "internationalizable" how to make a language pack.

5.1. Making your plugin "internationalizable"

5.1.1. Simple rules

Here are some simple rules we are going to follow. Theses rules are based on the way Eclipse organize externalization of strings:

  • The default language is English. All your messages must be in English before begining the process

  • For java files, we are using a .properties file is shared by Java files from the same package and plugin.

5.1.2. Java files

5.1.2.1. Eclipse mecanism

For java files that contains messages to internationalize, use the eclipse externalization tool (right clic, source > externalize strings).

Once you have the dialog box, you have to check "Use eclipse's string externalization mechanism" to use the eclipse way to manage externalization.

if you have already externalized a java file from the same package, select a Message class/.properties that has been created from the combo box.

Most of the time, you will use the default Message class/.properties, but if you're doing a externalization in a package that also exist in another plugin, it's a good idea to rename both the class and properties file to another name.

Things that has to be has to be externalize are strings that are translatable in another speaking language and they must be used in any piece of code is displaying in the user interface or logs (and nothing else).

5.1.2.2. Including variable in translatable strings

What if the strings has a parameters? For example the strings "You can not delete the file example.txt in this directory" has example.txt to be changed according of the name of the file. Use wille use the method NLS.bind: the strings would become "You can not delete the file {0} in this directory", and you will have to change your code to something like NLS.bind(Messages.yourMessage, thefilename).

5.1.3. Externalize plugin.xml

Plugin.xml part of the code can also be translatable: you need to change the Manifest file and add the line

Bundle-Localization: plugin

(plugin is the name of the .properties file which contains the translatable stuff, so your .properties file in this case is plugin.properties)

In the plugin.xml, you will replace all the translatable strings with %the.key to get it translated according to the keys in the plugin.properties file.

You may add to the build directory the properties file

5.2. Contributing a language pack.

Once you have make your plugin "translatable", you may way to contribute to your plugin with language translation other than English like, French or others.

To do so, everywhere you have created a .properties file, you can copy your the file to a _LanguageID.properties: for example, message.properties would become message_fr.properties.

This method is working fine but it may be interesting to give the ability of a pack of languages. To do so, we have to create a set of fragments (we will name them name_of_the_plugin.nl) that contain all the other .properties file, following the same tree structure of all the parents plugins (that the fragment are extending).