Re: non-Unix gettext

Subject: Re: non-Unix gettext
From: Paul Rohr (
Date: Thu Mar 15 2001 - 15:52:37 CST

At 07:16 PM 3/13/01 +0100, Joaquin Cuenca Abela wrote:
>ok, I didn't understand your statement. Are you speaking about the
>tools that gettext give to merge old translations with new ones, etc.?
>If you're speaking of these tools, can you point me to the xp tools that
>abiword provides to our translators?

You're quite correct.

Our current solution (strings + header files) has no translator-oriented
tools on any platform, aside from Owen's perl script. Worse, a full update
to the translations requires:

  - a debug binary to get a current en-US.strings file
  - the ability to rebuild header files for TB and menu layouts

These actually penalize non-Unix translators more, because compilers are
less available on those platforms. The more we can do to get strings and
labels out of the header files, the better off we'll all be.

On the plus side, we do currently have running code in the product to
support this on all our platforms. In short, the current process works, but
it ain't pretty. Nobody in their right mind would say that it Just Works.

>you asked about gettext advantages, and about experience of gettext's
>users in non-unix land, and I wrote with what I think are the advantages
>of gettext over our i18n system and with my experiences as user of
>gettext in windows.

Thanks. When you were using gettext on Windows, did you have *any* tool
support, or did you just edit the PO files by hand?

There's no question that PO files are easy for both developers and
translators to use on Unix. Developers link in some libraries, translators
fire up Kbabel, and everyone's happy.

AFAIK, all of that work would have to be replicated on Windows and other
platforms, which is what we've been having trouble getting volunteers for.

>If you consider that the fact that I don't have a
>patch to convert from our i18n system to gettext don't give me right to
>speak up, I will not continue the thread.
>My email was just my honest feelings based in my experiences.

You have every right to speak up. Please don't stop.
You have every right to speak up. Please don't stop.
You have every right to speak up. Please don't stop.
You have every right to speak up. Please don't stop.
You have every right to speak up. Please don't stop.

>You really can not know how hard is to merge in your translation new
>messages until you try it. Sometimes it works well, sometimes there are
>problems. I've done it with our i18n mechanism and with gettext, and I
>found the gettext way far easier (but, yes, I'm a linux user, I know)

This is an excellent reminder of how much that sucks. You should line up
some of the non-linux translators to complain about this, too. :-)

>well, right now windows translators should manage the same merge pain
>than the unix translators[1]. Saint-Denis is a windows translator (at
>least I think so), and he seems to experience these problems.

Argh. Boy I've really been sounding like an idiot, haven't I? Advocating
an equally bad experience for translators on all platforms wasn't ever my
intention, but that's essentially what I was arguing.

Sheesh. Sometimes I wonder why y'all put up with me.

>[1]: Actually, I don't think that our current i18n system hurds our
>users (at least, I will not think it until somebody changes my last
>patch about the TODO icons & labels), and I don't think that it hurds
>our translators, because thanks to Kenneth the translators can use .po
>files to translate the messages, so I think that current problems with
>our i18n system are:
>* it hurds our translators in the translation of menubar & toolbar.
>* it makes harder to i18n a dialog.
>* it can not work (at least I don't see how to do it) with tools like
>current advantages over gettext are:
>* you can do cool things like change the layout of the menu items
>* it works the same way for all the platforms/don't impose dependencies
>in another lib (potentially not present in non-unix systems).

Excellent summary. Thanks.


This archive was generated by hypermail 2b25 : Thu Mar 15 2001 - 15:54:01 CST