Table of Contents
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.
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.
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).
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)
.
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
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).