Enabling RCP applications to work with different locales is an essential requirement for server-side Eclipse setups. Multiple users are accessing the same instance of a running application concurrently, and each one should see the UI in his preferred language. Providing a server-side platform, the RAP project faced this problem too and we needed to find solutions to support multiple locales.

Recently I had the chance to discuss with Jeff McAffer how these changes could be integrated into Equinox. There are a number of subtasks to solve:

1. The NLS class must support different locales. Currently, translated strings are kept in static fields.
2. The extension registry must support reading in different locales. Currently, translatable strings in extensions are resolved once at startup and the results are cached.
3. There must be a mechanism to obtain the default locale for the current user and/or API to request a string in a certain locale.

I opened a new bug for the overall multi-locale topic and added patches to these bugs. Currently, comments show that there is no consensus on the suggested solution yet. These patches solve the requirements related to RAP, however, other projects may have different needs. If you have use cases related to multi-locale, please share your comments on the bug.

At any rate, multi-locale support is needed and it would be great to have it even in Eclipse 3.6.

So please comment on the bugs and help to push on this topic!

Tags: nls, OSGi, rap, rcp

In Eclipse 3.5M4, there’s new functionality in PDE to help you generate NL fragments. If you have already externalized strings (PDE Tools->Externalize Strings) in your plug-ins, you can internationalize them by using the internationalization wizard (PDE Tools->Internationalize).

Choose the languages relevant to you, press finish and go!

Tags: eclipse, nls, tips

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.

Tags: eclipse, nls, pde, rcp, tips