on Jul 23rd, 2008Tip: Internationalization and RCP
I had to help someone internationalize their RCP application today and I didn’t really have a straight forward simple example to point them to so I figure I’d share something here for everyone’s benefit. I’ll use the famous RCP mail example to get things started. The first step in internalization is making sure our strings are externalized so translators can actually do something with them. For Eclipse plug-ins, there will be two places you need to externalize strings:
- Java artifacts (ie., .java)
- Plug-in related artifacts (MANIFEST.MF and plugin.xml)
Within Java files, the wonderful JDT tooling provides an Externalize Strings wizard (Source->Externalize Strings…):
Within plug-in artifacts, PDE also provides an Externalize Strings wizard (PDE Tools->Externalize Strings or click the hyperlink on the Overview page):
Once we have all our strings externalized, we need to create a fragment (e.g., org.eclipse.mail.nl1) to store our translations (File->New->Fragment Project):
From the screenshot above, you should see that the translated properties files are co-located in the same respective location of the original file. The translated properties files also have a naming convention of name_locale.properties (e.g., messages_es.properties).
So now that we have some translated properties file, how do we test our translations? PDE provides an easy way to set the locale you’re developing against… similar to the way you define a target platform. In the target platform preference page, head over to the Environment tab and choose the language you’re interested in:
Once you do that, simply launch like you normally would to test out the fancy translations:
That’s it! Also, if you need translations for Eclipse.org plug-ins… check out the Babel project!
Here is the code used in this tip if you need to take a test drive at home. Hope this helps.
Related posts:
- Tip: Generate NLS Fragments in Eclipse
- Tip: Spellchecking in Eclipse
- Tip: Encoding Issues with Plug-ins
- Tip: Project Level Settings
- Tip: Eclipse, OSGi and Execution Environments
Thanks!
Efforts such as this is what will make Eclipse RCP adoption easier and the learning curve much less steeper.
-sid
Hi Chris. Thank you for this post. But what about unicode characters into *.properties files? I think that is inconvenient to use native codes (\udddd notation) to further support such files. But i don’t understand how to create such a file with the Cyrillic characters, it was easy to read after using Externalize Strings. Or i don’t understand how to use it?!
@sergej
The easiest way to do this I think is to use an editor like the one in this bug below:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=239475
The Babel project (www.eclipse.org/babel) should have this editor within a few weeks hopefully so you don’t have to use it from the bug.
Good luck!
thx for the example.
But now let’s say that we have 2 plugins in our RCP application.
Is there a way to have my translations for the 2 plugins in a unique project ?
Nicolas
@Nicolas, you would need two fragments for each of those plug-in projects. Or if you don’t care about separating translations from code, you can actually put the translations in each of those 2 plug-ins you mentioned.
Thx Chris,
I did two fragments as I care a lot about separation between code and translations
.
By the way, I noticed that the PDE puts a warning for “Bundle-Localization: plugin” when my plugin.properties moved to the fragment. Is it a bug in PDE or I missed something ?
@Nicolas, we usually expect there to be a plugin.properties available to your bundle (ie., english) as what happens if you deploy your bundle and the fragment isn’t available?
I am still looking for a decent i18n editor? Maybe some links?
Ann, I believe there’s tooling available in the Babel project at Eclipse.
You can try their email list or forums to ask.