Standard gettext PO format

[Nicolas Goutte]

On Friday 30 December 2005 13:05, Chusslove Illich wrote:
> > [: Chusslove Illich :]
> > It does, I've just checked, my oversight. But it also requires that all
> > languages of the requested catalog are in the same directory, as
> > bindtextdomain takes only catalog name and directory name. KDE is just
> > locating xx/LC_MESSAGES/catalog.mo in resource dirs.
> >
> > Hm, for a known catalog directory and catalog language, perhaps I could
> > call bindtextdomain and setenv("LANGUAGE", xx) prior to gettext call.
>
> I did this, and it seems to work. translate() of KCatalog now looks like
> this:
>
> QString KCatalog::translate(const char * msgid) const
> {
>     setenv("LANGUAGE", d->language, 1);
>     bindtextdomain(d->name, d->localedir);
>     return QString::fromUtf8(dgettext(d->name, msgid));
> }
>
> I have offloaded handling other variants of gettext calls to KCatalog as
> well.
>
> In klocale.cpp, I did a lot of deletions, so that translate methods of
> KLocale are one-liners now. Custom plural handling is completely out.
>
> (Patch attached.)

Sorry, I have not the time to check the patch now. (At first glance, I have 
not noticed anything special.)

>
> There are still three possible problems left using Gettext.
>
> First, if LC_ALL is not set to some existing system locale, or set to
> POSIX, or not set at all, Gettext will not provide translation. No matter
> what is in LANGUAGE, or anywhere else. Bruno Haible, the maintainer of
> Gettext, says this behavior is not a bug, but prescribed by POSIX.

Then perhaps KDE should set a $LC_ALL if there are not any of the language 
variables ($LC_ALL, $LANG...) declared. (Perhaps with an option to be 
POSIX-compatible.)

>
> Second, current KDE code has a feature that when KCatalog is destroyed, the
> catalog file is "unloaded". Gettext has no such explicit provision. What
> is the need of this unloading, is there a situation in KDE where catalogs
> could just accumulate and accumulate?

I do not know about this one. (Also I do not know how the KDEINIT system would 
influence here.)

I would suppose that this is going to be more a problem if you keep the 
KCatalog class. So perhaps you should try to find ways to drop it completely 
(and to leave to Gettext the entire responsability for MO files).

>
> Third, there is no way to tell if Gettext found a translation, or just
> returned a fallback string. If the language priority is not handled by
> Gettext, as I did above, than I must consider translation equal to
> fallback as translation not being found (and then check next language in
> queue). This might be no issue, but it is dirty and I feel uncomfortable.

Yes, indeed a problem, as it means for each string to check that it is the 
same or not.


In general, the situation does not seem to be as good as we thought it was, a 
few months ago.

In the case where using Gettext's runtime would really be too much work, we 
could make our own Gettext, but then probably based on Qt (e.g. based on 
QByteArray, with a QHash holding the data from the MO file), so that a few 
developers could potentially fix it. We would still need to be careful to 
work with Gettext's tools and files, probably including its MO format (which 
is defined in the Gettext info file).

Have a nice day!