Thread: Using gettext for JDBC translations

Using gettext for JDBC translations

From
Kris Jurka
Date:
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





Attachment

Re: Using gettext for JDBC translations

From
snpe
Date:
Hello,
>
> a) Should we use gettext?
>
Are you see netbeans properties editor - it is very sample for Java translation

> 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?
>

Ant have exec task

regards
Haris Peco

Re: Using gettext for JDBC translations

From
Peter Eisentraut
Date:
Kris Jurka wrote:
> 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.

You beat me by about 30 minutes to this email. :-)  The answer is: Yes!

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

Developers: require gettext tools or use to-be-created build option to
turn off NLS.

Translators: either like developers or download po files from
http://developer.postgresql.org/~petere/nlsstatus/

Average user: Uses precompiled driver.


Re: Using gettext for JDBC translations

From
Barry Lind
Date:

Kris Jurka wrote:
> a) Should we use gettext?

I don't yet have an opinion on this.

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

developers:  shouldn't require extra tools

translators: need to install whatever it takes

average users (who build from source):  shoultn't require extra tools

average users (who use prebuilt binaries): not an issue

One category that I think is important but not in your list is those who
provide various distributions (i.e. the rpms, etc).  I don't have a good
feeling if these are built from source or use the prebuilt binaries (I
suspect some of both).  We shouldn't require them to install a bunch of
extra stuff in order to build from source as that would discourage them
from including the jdbc driver at all.  We already require them to have
ant and a jdk which already may be too much for a non-java aware
distribution maintainer to track down and install.

So I guess I am leaning towards having the .class files in CVS and then
only the translators and those who really need to see the results of
translation changes need to do anything extra.

thanks,
--Barry