Eclipse RCP Internationalization独立插件

Question

No tutorial presents a concrete example of how an is created an used. I need translations to the 's and source code files. Trying to wrap my head around where the translations go, and where the i18n facade goes.

How does that fragment apply to an multi-plugin enterprise application, and more importantly, how do all those plugins externalize their strings inside appropriate folders in the fragment?

What about external JARs? How does the mechanism provide translation support for external resources?

With the risk of being a long-shot, would it be possible to provide independent translation of a view or perspective ? Not necessarily at runtime, because I know bundles can't be dynamically switched.

Answer 1

There is some help available, this article lists the process. It's based on Eclipse 2.0 (!) but the basic ideas are still correct. An even better article is this tutorial by Vogella

1. For each plugin you need to translate, you will create one plugin fragment. The fragment is associated to one host plugin, so you need several fragments. Each fragment can contain several languages though. The languages are separated by the folder structure as described in Step 5 in the first article

2. I am guessing you are referring to non-eclipse Java jars that you have made yourself, yes? If so, that is a completly different process, best suited for a separate question with the Java tag. Oracle has a guide that may help . But keep in mind that you only need to translate the content that the user is exposed to. So a refactor to keep all user visible strings to the Eclipse plugins might be a good idea.

3. Are you referring to the name of the view/perspective? If so, yes. You can translate the information you give in your plugin.xml aswell. See Vogellas article, chapter 3

Edit:

At nr.3 I was referring to choosing which View to translate (eg via a view menu), then restart the app, then only the said view should translate

Well.. I think of a way that would work in theory, but I'm not sure its the best alternative. So translatation is based on locale. And given the locale a certain translation is chosen. If no appropriate translation exists, a default will be selected.

So if your View menu were to change the locale of the application to, say "us-en-v1", and you only had one view which had a translation for the locale "us-en-v1", that would mean that particular view would be translated, but the rest of the application would use a default (could be that they default back to the closest translation, dont remember exactly).

Then for each view you would create a new translation and use a unique locale for each.

That should work, but it abuses the way translations are supposed to work, so it could lead to issues.

I've done something similar at one time, one app was used in the same language but different customers had different vocabulary. So we used the i18n to make the application use the right terms by defining our own locales.

Answer 2

We are using http://babel.eclipse.org/babel/ to let people translate existing ressources. The build process adds the required language fragments to the artefact. Each plug-in defines its own Messages.properties / Messages.java file. I guess, you can't do much about external jars.

For instance:

public final class MyMessages {
  // a string member as you reference it later in the code 
  public static String login_window_user_label;

  // static initializer which initalizes the fields in this class
  static {
    NLS.initializeMessages("mymessages", MyMessages.class);
  }
}

And (usually in the same package) you have a properties file, in this case,

mymessages.properties

which includes the string:

login_window_user_label = Enter username to login to {0}

And within the code you do:

String userNameLabel = NLS.bind(MyMessages.login_window_user_label, Environment.getName());

Thats how we make our bundles "translatable". The build generates the language fragments and the babel server instance allows the translation.