Hi,
Eclipse contains standard tools for externalization(Source>Externalize Strings,
Source>Find Broken Externalized Strings, PDE Tools>Externalize Strings)
Here is an article about externalization Eclipse plugins
http://www.eclipse.org/articles/Article-Internationalization/how2I18n.html (it is an
older, but still useful article) as well as an article describing how to test externalized
plugins
http://www.eclipse.org/articles/Article-TVT/how2TestI18n.html .
There is also the Babel project that can be used for externalization and translation:
http://eclipse.org/babel .This project is used to translate Eclipse projects (Eclipse,
WTP...). I haven't used it before, but will review it.
I believe that xmodel will make a problem during the
internationalization process because it contains hard-coded constants. I
am not sure if there is any way to internationalize those constants (the
org.jboss.tools.common.model/meta/studio_eclipse_option.meta file
contains the Visual/Source, Source, Preview constants, for instance. I
can't find a way to localize them).
Snjeza
Sean Flanigan wrote:
G'day all,
I gather that a lot of the Tools code already uses externalised
strings (ie using ResourceBundles to fetch strings from .properties
files), and I don't think it uses the English text as the key (the way
GNU gettext does in Linux land), but rather the usual Java convention
of artificial string keys like
"SharedIntroConfigurer_gettingstarted_nav".
I personally prefer the English-as-key approach (smaller code changes,
somewhat more readable code, and no artificial keys to keep track of),
but artificial keys have their advantages too, and of course it's
important to maintain a consistent approach.
Do you have any tools or scripts that you use to manage the artificial
keys, make sure they're unique, remove obsolete keys, things like
that? How do you deal with this sort of thing?
Sean.