Re: glib gettext implementation

[James Henstridge <james daa com au>]

On Wed, 22 Aug 2001, Matthias Clasen wrote:

> Frankly, I don't think that code duplication can be the right answer to
> licensing problems.
>
> Will you keep this uptodate with developments in gnu gettext ?
> What about eg the plural handling that has recently been added by Bruno
> Haible, will
> you g_ wrap that as well ?

First of all, GNU gettext is GPL'd, so can't be unconditionally linked to
gtk+ without requiring all apps that link with it to be GPL compatible
(which includes things like MPL apps as well as proprietary apps).

Secondly, including something like this in glib gives us baseline support
for translations.  This should mean it is less likely for someone on an
obscure architecture to just disable NLS to make a package easier to
compile.  This sounds like a good thing to me.

Third, on a platform using glibc, g_gettext and friends would just be
#define's or thing wrappers around the standard GNU gettext functions.  In
this case, there is nothing to stop you using g_gettext and ngettext side
by side.

If your app is GPL compatible and you need the ngettext() function (or any
other features in GNU gettext not found in Alex's g_gettext), you are free
to include GNU gettext as before to ensure that the features are
available.

I really don't see what we would lose by using this wrapper.  By putting
this in glib, and using it in all the LGPL gtk and gnome libraries, we
would ensure that they handled translations.  I don't think we are
actually using ngettext in any of these libraries anyway.

As a bonus, it would remove the need for the intl/ directory in all the
libraries, which should cut down on package sizes a bit :)

James.

-- 
Email: james daa com au
WWW:   http://www.daa.com.au/~james/