[slf4j-user] OT: Translation infrastructure requirements

[USHAKOV, Sergey]

Well yes, I agree and take many of your points regarding separated 
programmer/translator procedures. I believe gettext may be convenient in 
certain development environments. Still I am not very comfortable with 
an idea that occasional change of an English word in gettext-based 
program has chances to break i18n for related texts silently...

And I hope that my programmer-friendly library may be useful for someone 
too... :)

As for ICU4J - also yes, I agree it is certainly worth attention, though 
it also depends on ResourceBundle's :)  I like its MessageFormat 
extensions...  They may be a good ground for the next step towards 
pluralization...

Thanks and regards,
Sergey


On 19.06.13 12:09, Toolforger wrote:
> [...]
>
> 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.
> [...]