[slf4j-user] OT: Translation infrastructure requirements
s-n-ushakov at yandex.ru
Thu Jun 20 05:45:45 CEST 2013
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
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
Thanks and regards,
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
> - translator sees original text and his translations side-by-side
> - translator can write plural forms as needed, in a straightforward
> 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.
More information about the slf4j-user