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.
[...]
_______________________________________________
slf4j-user mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/slf4j-user
