2008-03-29

A dream for future NLS support in the RCP framework

One of the bigger jobs we are involved in right now, is for a Nordic bank with branches in all the Nordic countries. As the application we make must be deployed in all of these countries, we will have to translate all the relevant text from labels, buttons, view titles, perspectives, menus, etc, etc.

We haven't experienced serious problems with the translations themselves... But, then again, this is an area, where we could dream of some better support from the RCP framework. Unfortunately, the support we are looking for, does not seem to be possible in the current framework.

Basically, we want the business side of the bank - who set the original requirements for the application - to provide the translations for the different languages, as they should know better than the individual developers... This in itself is not a problem and can be accomplished via some of the tools from the babel project along with fragments...

But we would also like to allow the business side to make changes in the translations in a very easy way in the running application: when they see a text they don't like, we want them to press a key-combination (ALT-CTRL is used in an older Swing based application) and then click on the item they want to change. This will then drop them into a special editor where the translations for all the supported languages are shown and can be changed. When they have made the proper change, the differences are stored back into a database, from which new fragments are generated automatically...

In order to implement anything like this, we first of all need the NLS key for the text of the item in question as well as the resource name with the translations.

But, currently, all the translations in the registry - e.g for commands and views - are resolved when the plugin.xml files are read into the RCP application... After that no trace can be found of the original NLS keys and thus it is impossible to implement anything like the above.

I have spent some time look at the code that handles the translations and I cannot find a very easy solution without making changes to too many things in the framework. Changes are needed
  • in the registry reader
  • in IContributionItem code for commands (for menu and toolbar items)
  • in the current Presentation API implementations (for view names)
plus some new easy to use support for labels, buttons, sections and the like...

So, this is a wish for e4, I guess...
Post a Comment