Hello,
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).
If you have any questions, please feel free to ask.
Pascal Essiembre