Using gettext for JDBC translations

I've been looking into the possibility of using gettext to manage the
translations for the JDBC driver instead of the more traditional Java
method of using property files. Let me preface the following remarks with
the fact that I don't speak any language other than English and I've never
done a translation. Feedback from actual translators would be most
appreciated.

The property files method is very difficult on the translator. There is
no real means of keeping a translation up to date. There are really only
two ways to attempt to do this. One way is to monitor the cvs log on the
master properties file and carefully add the changes to your translation.
This is a pain and impossible to do if you do not know the last time the
translation was synchronized or if there have been a significant number of
changes. The other option is to start a new translation file and go
through the master line by line copying the old translation or providing a
new one.

Another problem is that for the developer the error messages are really
unclear. Reading through the source code and finding an error like
"postgresql.con.fathom" doesn't help. This is even more of a problem when
you are passing in data to be displayed in the format strings of the error
message. Composing an error message (just like translating) will have to
involve two open windows and a lot of back and forth between them.

Using gettext solves both of these problems. The error messages in the
source code are the plain english messages complete with format strings.
These strings are extracted from the source files by running xgettext
which creates a simple text file message database. The translator edits
this file to create the translation with a line of english and his
translation right next to each other without some pseudo constant string
mapping to another file. This text file is then processed by msgfmt to
become a .class file which extends ResourceBundle and loading is handled
in the same manner as the .properties files with the locale determining
which messages to load.

The real beauty of gettext is its ability to monitor a translation's
progress. Say a developer adds a new error message, it automatically
shows up in the translators file marked as untranslated so they know they
need to work on it. Then a developer rewords an English error message.
This also shows up in the translators file marked as fuzzy. The
translator can then go in and check the translation, correct it if
necessary, and remove the fuzzy mark.

That said there are some problems with using gettext in a Java
environment. Using gettext does not require any external libraries and
there is no runtime impact or requirements, but there are some compile
time issues. Right now there are no prerequistes to perform a translation
or to compile a driver with translations. Using gettext will certainly
require the translator to have the gettext tools installed on his machine.
The question is whether someone who compiles the driver should need the
tools or not to get translations. Given the translators message file the
msgfmt tool is required to turn it into a useable .class file. That said
there are a number of ways around that.

1) People without msgfmt don't get translations. I think this is a real
step backwards.

2) We check the .class files into cvs when checking in a translation
change. This isn't the cleanest thing to do, but it should work provided
we don't run into any different JVM version incompatibilities.

3) We require msgfmt for building from cvs, but produce source tarballs
with the compiled translation files. This is something akin to how the
server's cvs works with requiring flex and bison to build from cvs, but
these are packaged with the source tarballs. I personally like this
solution best.

The final problem is that the gettext tools are command line utilities
that aren't all that conducive to being run inside of ant. It will
probably be necessary to wrap these commands inside a shell script/batch
file or possibly write a custom ant task to carry these out. I think this
is the real sticking point here. Trying to resolve the differences
between windows and unix machines while running command line programs from
inside ant isn't something I'm really itching to do.

I've created a sample java gettext project (attached). Your thoughts on
are appreciated on:

a) Should we use gettext?

b) What should the requirements be for developers, translators, and
average users who want to compile the driver be?

c) How can we call the gettext commands from ant?

Kris Jurka