Comment 2 for bug 586916

Hm. Just exactly how gettext-commons is supposed to make the transition to gettext easier? You still will need to replace every ResourceBundle reference to i18n.tr() or whatever. Which isn't _that_ bad, after all - it's just a couple of rainy evenings..., and you just do it once :)

What's worse is that you need additional tools in your build. xgettext and msgfmt aren't part of the gettext-commons - you need to get them from GNU. And all of this is written in C and thus platform-dependent. And you need them in your Ant path for your Ant build to work. And you need those in your Eclipse builder path for your Eclipse build to work (good luck setting up that). Long story short: all this stuff has been designed around 1980 and has a huge impedance mismatch to Java and Java IDEs. At least, big enough that nobody got around yet to reimplement a compatible version in pure Java. Unlike the first conversion, you have to maintain all this half-compatible tooling _all the time_.

I would think twice before I decided let gettext into my Java app if it was my call.

Aside from that, keep in mind that the claim "gettext[-commons] supports plurals properly" is just outright false. Gettext supports plurals properly _for English and German_, more or less. There are languages that have rules of mind-boggling complexity for the grammatic number (Slavic languages, for example, see http://interglacial.com/tpj/13/).

JOSM uses a somewhat different approach, as they don't host primarily on Launchpad, but use Launchpad Translations and convert them into their own .lang file format (see http://josm.openstreetmap.de/browser/trunk/src/org/openstreetmap/josm/tools/I18n.java). I don't really know how they actually do the conversion, however. They also handle plurals properly (manually on top of the translated messages, see the pluralEval() method at the end of the linked file). Anyway, even this is a more sane approach in my eyes than introducing a direct dependency on gettext.