Standard gettext PO format

[Chusslove Illich]

>> [: Chusslove Illich :]
>> This against letting Gettext handle language fallbacks.
>
> [: Nicolas Goutte :]
> Yes, after  thinking, I thin that  the problem is not really worth the
> gain of switching to the Gettext runtime.

Darn, after making the point for Gettext resolving language precedence by 
itself, and actually implementing it, I remembered that I absolutely 
positively need to know which language the translation came from, which 
Gettext doesn't provide for.

So I've played a bit more with version where Gettext doesn't resolve 
precedence, and it turned out there actually are no problems with 
unloading/caching. Since the language is switched to next in precedence 
list only if translation wasn't found, there is nothing cached, so there 
is no need to manually flush cache and introduce that slowdown. Although 
the slowdown doesn't really matter, as performance is anyway far, far 
above what is needed in GUI.

Of course, not resolving precedence by Gettext means retaining the full 
flexibility of catalogs locations, as much as I've argued it is not 
needed. So no bets on when the bug report arrives :)

What we should decide now is whether to use the original patched code or 
Gettext code. I preffer the Gettext one: no custom .mo loading and 
searching, plural and context resolution is in complete control of Gettext 
and code is cleaned a lot as result.

http://caslav.gmxhome.de/misc/kdecore_p1.patch (patched original)
http://caslav.gmxhome.de/misc/kdecore_p2.patch (using Gettext)

-- 
Chusslove Illich (Часлав Илић)
-------------- 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/20060102/d669ffa7/attachment.sig>