Standard gettext PO format

[Nicolas Goutte]

On Friday 30 December 2005 14:48, Chusslove Illich wrote:
> >> [: 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).

What I do not understand is:

if (trans_full[i] == '\000')
        trans_full[i] = '\004';

Why do you expect a NUL character in the middle of a UTF-8 string?

(Especially passing \004 to QString is perhaps a bad idea as I do not know if 
QString supports the conversion of control characters.)

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

Well, I suppose that you will probabl have less problem by tweaking the 
current code. If you do so, try to fix the hash problem. (It is just a 
different cast in one line. I do not remember in which mailing list this was 
discussed nor when. Sorry!)

Have a nice day!