Difference between revisions of "RCP User Enabled Localization Design"

Revision as of 17:24, 16 August 2007

Obtaining and maintaining localized translations in an open source project is often difficult. This is currently a problem for Eclipse. A good way of solving this problem would be to enable the end users to edit the translations. Consider an Eclipse user in Latvia who sees text in English (because no one has done a Latvian translation). She chooses 'Localize Text' from a menu and selects the text. She then types in the text in Latvian. She sees the new text immediately. Her translation is written to a central server and is included in the next build of the Eclipse IDE (or the next build of the RCP application).

This idea has been independently thought of by more than one person. Jeff McAffer calls it the Wiki approach to localization.

This page has been removed by the original author because the issues covered on this page are now covered by the Eclipse Babel project.

The Localization Server

There must, of course, be a central server to which translations can be sent.

The Location of the Localization Server

This is specified in the plug-in. Each plug-in developer would need to setup or find a suitable server willing to host the plug-in's localized text.

Once the plug-in has been released, it would be hard to change the address of the localized text server. This will require a new version of the plug-in to be released which is configured with the new address of the localized text server. If translations are provided by those still using old versions of the plug-in (after the localized text server was copied to the new location), the translations will not show up in the new versions of the plug-in.

Server Implementation

There are a few possibilities as to how the server is implemented.

• Wiki pages could be used. The Wiki pages would have to follow a precise format so that the localized text translations could be automatically extracted. This has the benefit that we get a lot of the Wiki support for free. For example, Wiki implementations have code to look for pages that flip repeatedly back and forth between two conflicting states. They also provide discussion pages.

• The text could be stored in property files with a script to provide, say, a Web Services interface. This does not allow other data to be stored such as history or an explanation of each text message, so this is probably not a good solution.

• The text could be stored in a SQL database with a script to provide a web services interface.

The last option is probably the way to go. Of course, if a Web Services interface is agreed upon then the server implementation does not have to be specified. Plug-in developers would be free to implement their own server back-end behind the Web Services interface.

Updating the Text on the Users' Computers

A utility would be needed to build the language files. This would be run as part of the plug-in build.

Users may, however, not want to wait for the next build to see the latest translations. They may not want to install unstable builds. Yet they may want to get the latest messages because there is nothing more infuriating than spending time contributing translations to an open source project only to find that someone else has already translated to your language. It is therefore important that users can update to the latest text from the localization server.

The user will want to see the latest translations while using the Eclipse IDE or the Eclipse RCP application. This can be done by writing the text to a local file on the user's computer. This is then read when the plug-in is loaded. This does require the Eclipse IDE or the RCP application to be restarted. It would be very difficult to immediately change the text because the text could be displayed in all sorts of different controls, text could be formatted with parameters, etc. Unless someone can come up with a very clever solution, and Eclipse is prepared to accept significant changes to the existing APIs, it will not be possible to update the text in the user's views without re-starting.

Within the localization dialog, the messages will be up to date in real time. This is important because after a new release there are likely to be a lot of users providing translations simultaneously. If a user changes text, that text will update on the screens of all other users that have the translation dialog box open and are viewing that text.

Other issues

Modifications to the Original English Text

The plug-in developer may change the original English text. This will not affect the translations. However, this will cause the messages to be flagged in the localization dialogs. The user will see both the English text as it was when the current translation was made and the English text as it is now. It is thus easy for the translator to see the changes made to the English and decide what changes, if any, need to be made to the translated text.

If the change to the English text is so extensive that all translations of the previous text would not longer be useful then the developer should use a new property key for the message. On the other hand, if prior translations are to be kept then the developer must be careful not to change the property key.

The same issue applies if a change is made to a generic language translation while country specific translations have already been made. For example, an Austrian user changes the text in the 'de' property file, but a Swiss user has already made a Swiss specific translation in the de_CH' property file.

Users can only change the text for the language that they have set. For example, if the user has language set to fr_CA then they can provide translations either specific for French Canadians or for all French speakers in general. The UI would not allow them to provide, say, a German translation. (Though they could easily enough change the language in the OS and re-start Eclipse).

Vandalism

This could potentially happen happen. However I can't imagine Eclipse is likely to be a target of vandalism and the wiki experience has shown that vandalized text is rapidly removed. In the unlikely case that this is a problem, we can incorporate some of the solutions developed by Wikipedia.

Eclipse does have one additional problem. The vandalism may occur just before a release is built. Even if the vandalism is rapidly corrected by the community, it is still built into the source and binary distributions.

Non-English Plug-in Developers

Until now it has been assumed that the developer who originally created a localized text is always able to create the text in English. It would be hard to work with Eclipse without knowledge of English. Eclipse already has a built-in bias towards American English and it is reasonable to require text be supplied by the plug-in developer in American English. However, a native English speaker may want to provide a better English translation for someone else's plug-in.

Action to list messages by view/editor

As mentioned earlier, it may be possible to present messages to the user based on the view or editor in which the message is shown.

An action to bring up a list of all text messages in the selected view. Note that some of these messages may have been contributed by plug-ins other than the plug-in that contributed the view. All messages used by the view must, however, been shown because the user does not know or care where the message came from. He just wants to translate it.

How is the list of messages obtained? This is not all that simple. Localized text may be returned through extension point interfaces. This can only be achieved if a handle, not text, is returned.

For example, consider the 'action' extension point. This contains two methods that return localized text (label and tooltip). These could be changed to return handles to the text:

ILocalizedText getLabel();

IlocalizedText interface would contain a getText() method. However, each view implementation would need to keep track of the IlocalizedText objects that it has used to render the view. This involves effort on behalf of the developer of every view.

Note the flexibility of this approach. For example, suppose the text to be put in the label for the action is built by combining two localized messages. The IlocalizedText implementation can know that and can be implemented so as to add both messages to the view's translation list.

This action should be available even if the 'by view' action is implemented. This would allow users to translate messages for views that have not been coded to keep track of the localized messages used by the view. It would also allow users to translate all messages in a plug-in without the need to see them first.

Not all messages appear in views. For example, menu labels and tooltips, perspective names. These would not appear in the translate actions that are targeted at a view. These will appear in the general action.

Note also that the set of messages in a view may not be static, especially when text is obtained indirectly.

Unfortunately this requires some changes in the views. There is work to do here to decide how and when the list of messages is built.

It has been suggested that the SWT controls in the view be traversed for text messages. However this will not work because the controls have no information on the source of the text. Not all text put into SWT controls is localized; some of the text may be user data, or may be localized formatting text with inserted parameters.