Re: commit -- libglade support


Subject: Re: commit -- libglade support
From: Joaquín Cuenca Abela (cuenca@celium.net)
Date: Thu Feb 08 2001 - 03:12:17 CST


Paul Rohr wrote:
>
> Joaquin,
>
> You sure know how to make a guy happy! :-)
>
> At 08:15 PM 2/7/01 +0100, Joaquin Cuenca Abela wrote:
> >run-time. But anyway there are (nearly) no bloat. Just a bit the first
> >time the user opens a gladeified dialog, and it's impossible to see the
> >difference even in a old 486 (in fact, I'm pretty much sure you can see the
> >difference even in a 386, but I have no 386 :)
>
> Nice.
>
> >And yes, the users should install libglade. But happily enough, there are
> >many applis out there that depends in libglade, and pretty much everybody
> >with gtk+ has libglade installed (for instance, gnumeric depends in
> >libglade).
>
> Great. Are we likely to run into versioning issues, or are the libglade
> APIs pretty stable now?

no problems. The latest big changes that I remember to libglade was the
inclusion by Miguel de Icaza of gnome support, and the latest widget
added to glade that I remember was (besides the gnome-db widgets &
bonobo widgets) accelerated label. Those changes were a loooooooong
time ago (before {ximian/helix code} was created, I will say 1 year &
half ago, aprox.).

> >I will explain that point a bit more in a few hours... (I have to return to
> >home right now)
> >(but we can introduce gettext *without* touching the non-unix platforms).
>
> Phew! That's a relief. I'm looking forward to hearing the details.

ok, and now, the details.

First, why we need gettext? (besides all the comments that I've done in
the past about facility for the transtalors & the coders).
Well, because libglade will query gettext with each text that it has to
show for an internationalized version, so if we don't provide a .mo file
gettext will not found any translation, and thus the gladeified dialog
will not be gladeified.

Now, we need at least a .mo file, and in order to have a .mo file you
need a .po file (that the gettext utils will threat to produce a .mo
file (a "compiled" version)) with all the translations. So you will
say: "ok, but in order to build a .po file you need to use _("foobar")
all over the code instead of AP_TATA_TOTO_FOOBAR like right now, and it
will be a big change, and it will impact the non-unix platforms, and...
arggggh"

But, luckily enough, we have a perl script that sucks all the messages
from abi and fits it in a cute .po file (kudos to Kenneth
Christiansen!). This script was mainly to make the translator task
easy, but without touching our i18n scheme. Namely, the translators run
Kenneth's script to update his ll-LL.po file, fill the translation of
the new messages, and rerun another Kenneth script to send back the
changes to the right AbiWord file.

Now, we only need to do the right Makefile magic in order to compile the
.po file, copy it to the right place /usr/share/LC_MESSAGES/..., and
link with the right gettext lib, and so on.

And here comes the trick, I don't know how to do all this magic without
autoconf/automake.
I've been searching with google, but I found *ZERO* references (ok, only
a mail from James Hensdridge explaining how to about autoconf, but
anything about how to about automake).

If somebody (Sam?) knows but are the need steps, I will *really*
apreciate some clues.

Well, and that's all folks.

Cheers,

--
Joaquin Cuenca Abela
cuenca@celium.net



This archive was generated by hypermail 2b25 : Thu Feb 08 2001 - 03:12:23 CST