Use Launchpad Translations to translate RevAger

[Johannes Wettinger]

The RevAger project should be configured to use Launchpad for translations.

[Daniel Kulesz (kuleszdl)]

I had a quick look into this one. As far as I can see, Launchpad seems to rely on GNU gettext for the translations, which is also available for Java, but it would require a major rewrite to replace our standard Java Resource bundles by GNU gettext calls. Fortunately it seems there is an interesting and very small (17k) library available for this:

http://code.google.com/p/gettext-commons/

I suggest, we should give this library a try. Or does one of you know a better library or some huge disadvantage of gettext-commons?

In case this library would enable us to switch to launchpad translations with greatly decreased efforts, I would suggest considering the implementation of this FR for a later release of the 1.3-Series.

[Igor Podolskiy (podolsir)]

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.

[Daniel Kulesz (kuleszdl)]

Wenn ich das richtig sehe, ist ein Teil dieses FR ja bereits umgesetzt. Ich habe dazu aber folgende Frage bzw. folgendes Problem damit: Wie können denn die "Originale" sinnvoll eingepflegt werden? In der jetzigen Fassung hat RevAger ja eher das Problem, dass die englischen Texte stärker als die deutschen überarbeitungsbedürftig sind. Die englischen Texte können aber via Launchpad Translations nicht editiert werden?

[Johannes Wettinger (jojow)]

Yes, the translations are managed using Launchpad now. 75% of the original strings (English) are already available in German. The remaining strings will be translated until release 1.4. :) Unfortunately there isn't a chance to simply integrate the strings from the old Java properties file.