Standard gettext PO format
caslav.ilic at gmx.net
Mon Jan 2 14:11:11 GMT 2006
>> [: 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
Size: 189 bytes
Desc: not available
More information about the kde-core-devel