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