Eclipse Babel Project Messages Editor

From an email posted to babel-dev by Pascal Essiembre:

Like discussed in last Babel meeting, here is a list of features for the ResourceBundle editor plugin, comparing the Babel rewrite to its SourceForge equivalent. Vision for the plugin can be found further down.

Please note that until all features have been ported over, I would not consider the plugin “stable”. I will keep you posted on the porting progress through the mailing list.

Implemented

(Features found in both SourceForge version AND Babel version):

• Can edit values of all locales at once for a given key.
• Keys are always sorted for ease of reference.
• Can report missing and duplicate values (still in progress).
• Non-ASCII character conversion to/from Unicode. Not yet configurable.
• Multiple properties file formatting options (key grouping, line wrapping, etc). Not yet configurable.
• Can toggle between flat and hierarchical view of keys.

Not yet ported over

(found in SourceForge version only for now):

• Supports Eclipse "nl" structure for I18N of plugins.
• All refactoring options (renaming, deleting, copying, keys or group of keys).
• Wizard for creating new resource bundles.
• Preferences pages (formatting options, performance tuning, etc)
• Reporting of similar values.

New features

(found in Babel version only):

• Use of the problems view to report validation warnings (needs polishing)
• Folding of locale fields when translating, to clean up the editor when dealing with many locales.

Vision

My vision for this plugin has always been to be a front-end desktop utility/application of choice for all translation purposes when developing applications. To accomplish this, I envision this for the plugin:

• Integrate message key refactoring with several referencing file types. For example, renaming a key in the Babel Editor would not only update it for all related properties files, but also renamed its references found in other files such as Java, JSP, etc.
• Provide the optional ability to configure the editor to hookup with online translation services to facilitate translation. For example, when editing text for any locale, you could have a button next to the text field that says “Translate from…” where the corresponding value in the selected locale (for the same key) is sent for translation, and the text field is populated with the result.
• Support several other repository formats. The editor already abstracts the actual storage mechanism for messages. As long a key/value concept is used for internationalization, any storage mechanism can be supported. Some coming to mind: XML files, relational databases, web services.
• Being able to run the plugin as stand-alone RCP application for translators. This is a frequent request I get that translators could benefit from using the same interface as developers for translating, without having to install a full-blown IDE.
• The formatting options (preferences) should also be made easily exportable so that developers and translators can share and use the same company standards (I have received complaints about different formatting options causing CVS synchronization issues).