Standard gettext PO format

[Chusslove Illich]

>> [: Chusslove Illich :]
>> 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. [...]
>
> [: Nicolas Goutte :]
> 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.)

This could be one solution, but then we would have to find some arbitrary 
existing locale, and that could be a surprise to the user. I could 
investigate this, but I wonder if it is really worth it. All other Gettext 
software does it this way, and users should anyway have proper UTF-8 
locale set on modern system.

>> [: Chusslove Illich :]
>> Second, current KDE code has a feature that when KCatalog is destroyed,
>> the catalog file is "unloaded". Gettext has no such explicit provision.
>
> [: Nicolas Goutte :]
> 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).

KCatalog is not a problem in itself, with Gettext it is just a light 
wrapper to handle the bindings. I wouldn't consider this unloading 
business really needed, if there weren't that kdeinit stuff that I have no 
knowledge about at all, and the fact that, well, somebody did implement it 
before :)

Hm, perhaps the unloading is there just because manual loading is there as 
well, to avoid memory waste when temporary KCatalog objects are 
created/destroyed? If so, we really do not need unloading, as catalog 
files are in full control of Gettext.

>> [: Chusslove Illich :]
>> Third, there is no way to tell if Gettext found a translation, or just
>> returned a fallback string. [...] I must consider translation equal to
>> fallback as translation not being found.
>
> [: Nicolas Goutte :]
> Yes, indeed a problem, as it means for each string to check that it is
> the same or not.

If you mean performance wise, I am not really taking any conclusive hit, 
when compared to the current code minimally patched to read standard MO 
files (for which the patch is attached as a reference, but it certainly 
needs some explanations from my side, as MO format itself has 
compatibility hacks).

Also, this would dissapear alltogether as a possible problem if we would 
opt to drop that flexibility in catalog locations, as explained in the 
other message.

> In the case where using Gettext's runtime would really be too much work,
> we could make our own Gettext [...]

I think that we should at least start with either patched current code or 
standard Gettext, and see how it goes. PO/MO format and i18n API would be 
fixed anyway, so there would be no BC trouble to switch internals at any 
point (even after kdelibs of KDE 4 is considered in BC freeze).

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdecore_p1.patch
Type: text/x-diff
Size: 9100 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20051230/aaef56e3/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/aaef56e3/attachment.sig>