[slf4j-user] OT: Translation infrastructure requirements

[Toolforger]

Am 19.06.2013 07:07, schrieb USHAKOV, Sergey:
> Gettext is really a great tool, and should I need to internationalize an
> existing application, it might be one of the first candidates to
> consider. Still its core design has a downside that 'consumer/resource'
> links are ordinary strings, like with standard ResourceBundle approach,
> and so are prone to getting out of sync; tools are available to detect
> these cases, but they require extra build phases. And extra build phases
> are also not an advantage IMHO...

The usual argument for naming constants is that if you change the 
constant, you do not have to change all the places where it is used; 
however, translatable strings aren't typically reused all over the 
place, so that advantage evaporates.
In the end, forcing the programmer to invent a name for every 
translatable string is a misguided approach.

 From my couple of years as a professional translators, I'd say that 
gettext always had the best workflow for translators. The po file format 
has a number of advantages:
- translator can't accidentally damage the code
- translator sees original text and comments that provide context
- translator isn't distracted by irrelevant text (such has other 
translations)
- translator sees original text and his translations side-by-side
- translator can write plural forms as needed, in a straightforward manner

Your approach is better than property files, but property files are the 
most awful approach to translation; clearing that bar is pointless if 
gettext is already available and far better.
Gettext could be improved upon, but doing so would require personal 
dedication; you're far into diminishing returns land there.
The low-hanging fruit in that area are:
- Bruno Haible's GettextResource class which provides .mo files as 
resource bundles.
- It may be worth checking out ICU4J's translation infrastructure.