Snjezana Peco wrote:
Hi,
Eclipse contains standard tools for externalization(Source>Externalize
Strings, Source>Find Broken Externalized Strings, PDE Tools>Externalize
Strings)
Looks like they've added a couple of useful wizards since I last looked
into it.
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 .
Thanks.
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'm actually in the process of getting Babel's translations packaged for
the next version of Fedora. Look for the package 'eclipse-nls', coming
soon to a mirror near you!
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).
Um. That must be
<
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbosstools/trunk/common/plugin...
I'll have to look at that when I can. Perhaps it will be possible to
generate such a file in multiple versions (one for each locale) by
merging a generic template and the translations during the build
process. (And then finding a way to load the appropriate version at
runtime.) I'm sure someone in my team will have some ideas. There's
definitely some work to be done in that area, in any case.
--
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat