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

[Sean Flanigan]

Max Rydahl Andersen wrote:
> My worry is that our build today is not exactly a piece of cake to get 
> setup
> BUT it at least run on all the platforms that we have developers on 
> (windows, mac and linux)
> then I would be against something that would restrict that since going 
> forward
> I would like to get the build made much much simpler than it is 
> today....at least
> keep that hope alive.

If I were to change the build, (I think) it would only be to add 
optional tasks, so it shouldn't affect most developers.  But I think I 
would prefer a separate i18n server anyway.

> mkay - if you want to maintain a seperate build for it be my guest;
> but what do you do when the properties files get updated by jboss tools
> dev ... you would just nuke them or ?

I was hoping you wouldn't notice that hand-wave ;-), because I haven't 
worked out what to do in the case of translation conflicts just yet.

Here goes some more thinking by writing...

Ideally, translations would flow in one direction only (thus eliminating 
conflicts), but we would want the translations to be kept somewhere open...

The problem is that developers would prefer to modify translations in 
the .properties files, but translators generally don't.  Some 
translators do their work in TMX, or XLIFF, but the Red Hat localisation 
team generally uses GNU gettext formats (POT/PO).

I want to make developers' lives easy, but it's a balancing act, because 
I don't want to make translators' lives hard either.  That means you 
don't want to force translators learn a new file format just to work on 
a new project.

If we make the PO files the definitive translations, then developers 
need to be able to (a) modify translations - that's fairly easy, PO 
editors are far better than ResourceBundle editors and (b) test their 
code with the latest translation.  Which means they need to convert the 
PO files into ResourceBundles.

And now we're back to needing file conversion as part of the build!

Hmm.  Not great.  It might work better the other way (.properties as 
canonical), if the conversion tools are up to it (ie conflict handling).

This thinking by writing isn't getting me very far.  I'll have to think 
about it over the weekend.

I think the answer will lie in making sure it's developers who handle 
svn conflict resolution, not translators or build/i18n servers.  Along 
with avoiding svn conflicts as much as possible, thanks to smart 
conversion tools.

More to come...

Sean.
-- 
Sean Flanigan

Senior Software Engineer
Engineering - Internationalisation
Red Hat