Standard gettext PO format

[Chusslove Illich]

> [: 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.)

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.

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?

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.

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdecore_p2.patch
Type: text/x-diff
Size: 23591 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20051230/4d0dbcb2/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20051230/4d0dbcb2/attachment.sig>