[jbosstools-dev] How to keep track of ResourceBundle keys?

[Snjezana Peco]

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.
>