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

[Sean Flanigan]

Max Rydahl Andersen wrote:
 >> 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".
 >
 > Yes, it uses the standard eclipse way (this is not ResourceBundles in
 > the code,
 > but the property files are the same)

Ah, the "new" eclipse way, with static string fields that get magically 
filled in on classload.  I had forgotten about this approach.  I haven't 
really used it, because you can't use this scheme for servers which 
might support multiple languages all at once.

But for single-user Eclipse, and plugins for it, I dare say it works 
quite well.  Really well, I hope.

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

Actually, I hadn't been considering the Eclipse approach, so I have even 
less interest in switching to English-as-key.

 > sure, gnu text seem to be cool but I haven't seen a tooling stack for it
 > that
 > will work on windows where most of our devs (and users) are currently.

I think there are a couple of (old) win32 ports plus a cygwin package 
but it's true that Windows is the poor cousin for gettext.

However, it's only when extracting text that you need the native tools 
(such as xgettext).  At runtime, you can just use ResourceBundle or a 
wrapper around it.  So you only really need the native gettext tools on 
the build server.

BTW, for those who don't know, the reason for text extraction is to 
generate (English) templates for the translators.  Red Hat's 
localisation team generally uses POT files as templates, which are what 
xgettext generates.

Even with the Eclipse approach, you still need to extract strings, 
except that you extract them from .properties files rather than source 
code.  ("Convert" is a better word than "extract" in this case.)

When using artificial keys, I don't think the GNU gettext tools are 
appropriate.  The Translate Toolkit, particularly the tool 
<http://translate.sourceforge.net/wiki/toolkit/prop2po>, should do just 
what we need.

The good news is that Translate Toolkit has an up-to-date win32 binary, 
so even a Windows-based build server shouldn't be a problem.

 >> 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?
 >
 > No, not in particular. But eclipse has a few validation checks for 
some of
 > these things. I haven't used them much so can't even really point to
 > them ;)

If nothing else, it should be possible to search for unreferenced fields 
in Messages classes in the IDE; maybe even use a static analysis tool 
(FindBugs/PMD/?) to look for all unreferenced fields.  The Eclipse 
approach is pretty clever in the way it integrates Java static checking 
with the externalised strings.

-- 
Sean Flanigan

Senior Software Engineer
Engineering - Internationalisation
Red Hat