Standard gettext PO format

[Chusslove Illich]

>> [: Chusslove Illich :]
>> [...] the patch is attached as a reference, but it certainly
>> needs some explanations from my side, as MO format itself has
>> compatibility hacks.
>
> [: Nicolas Goutte :]
> if (trans_full[i] == '\000')
>        trans_full[i] = '\004';
>
> Why do you expect a NUL character in the middle of a UTF-8 string?

Those are the hacks I reffered to. For compatibility when plural forms were 
introduced, translated forms (as well as msgid and msgid_plural) are 
stored in the catalog delimited by nulls. Catalog lookup will give the 
pointer to first plural form and total length of the entry (over all 
forms). So, if the strlen and returned total length differ, we know those 
are actually plural forms.

Then, we need to replace nulls with some sane delimiter, basically the same 
story as presently with newlines, but something much more robust. For this 
same purporse, in Gettext \004 was chosen as context separator (msgctxt 
and msgid in the catalog are delimited by it).

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

Hm, it works as it is. I think the point of using \004 in Gettext was that 
it is benign enough.

> Well, I suppose that you will probabl have less problem by tweaking the
> current code.

I don't seem to have many problems with Gettext either, especially if we 
let it handle language resolution. And it gets awful lot of other code 
deleted :)

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

Found it. And checked that non-ascii msgid is found in catalog after 
change.

-- 
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/20051230/5563d45e/attachment.sig>