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

[Max Rydahl Andersen]

Hi Sean,

Anything that prevents users from just checking out our plugins and import  
them into eclipse without any extra weird steps
will be frowned upon :)

/max

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



-- 
-max