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...

6 comments:

tmseidel said...

We had very similar requirements and implemented a web-application which has an interface for editing the content of fragments/bundles. After editing some data the application created a new fragment/bundle and feature with an incremented version id, the site.xml was responded with a servlet with the latest features. So the new content is distributed via the update-manager.

Kevin McGuire said...

Tonny, this'd indeed be valuable but yeah a big job. I could see carrying the NLS key forward as part of some improved model the UI, and in general its valuable for the UI to be more self-descriptive ... but really its the same story again and again for e4, if this is important to you then you should get involved!

Anonymous said...

@tmseidel: So you have the second part of the application :-) Unfortunately, I find the first part of the application - getting the NLS key for the different UI items - the difficult part :-(

Anonymous said...

@Kevin: I already try to get involved in e4 - especially in things like this that has an impart of RCP applications. The other two subjects I find particular interesting in RCP applications are 1) a new workbench model with a new model of parts and 2) automation, especially recording actions, alike to what is seen with VBA. Unfortunately, my company is (still) rather small, so it is rather limited how many resources I can invest in this :-/

Kevin McGuire said...

Tonny, I was curious about this subject so investigated further the technical issues. The problem which I think you pointed to is indeed the fact that the NLS keys are converted to strings very early, in fact when the bundle is loaded. The existing API, IConfigurationElement, has a method getAttributeAsIs(String) but which is deprecated because, according to the comment, it never worked anyway. The root of the problem is the fact that the cache build at the OSGi layer (1) no longer retains the key and (2) doesn't point back to the particular configuration element in the plugin.xml. The solution would need to be on the order of "cache the original NLS strings too" but of course this would be wasteful for a deployed application, so then you need an optional cache for development time. Its ... complicated, but as in all things do-able.
After that its a matter of surfacing the traceability of the key all the way up to the UI element so that you can "drill in" from the SWT widget to get the info. I could see us being able to do something in there in e4 in our UI modelling work we've started dreaming about.
Keep the discussion going!

Anonymous said...

Kevin, you have come to exactly the same conclusions as I did... If only I had seen the problem 2-3 months ago, I had been able to make a patch for 3.4, but as you say, there are some non-trivial issues in regard to the cached strings that has to be dealt with first.

One related problem - as far as I can see - is the ability to change language in the running application. Granted, this will not happen all that often, but in the older swing based application in the bank mentioned above, this is actually used as it enables the developers - that often comes from a different country than the current end-user - to investigate difficult problems in the "wild". The point here is that the same NLS keys are needed in order to change the language as well as to solve my problem...