--nextPart1613154.goEIJdXFhR
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>> [: 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] =3D=3D '\000')
>        trans_full[i] =3D '\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=
=20
introduced, translated forms (as well as msgid and msgid_plural) are=20
stored in the catalog delimited by nulls. Catalog lookup will give the=20
pointer to first plural form and total length of the entry (over all=20
forms). So, if the strlen and returned total length differ, we know those=20
are actually plural forms.

Then, we need to replace nulls with some sane delimiter, basically the same=
=20
story as presently with newlines, but something much more robust. For this=
=20
same purporse, in Gettext \004 was chosen as context separator (msgctxt=20
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=
=20
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=20
let it handle language resolution. And it gets awful lot of other code=20
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!)

=46ound it. And checked that non-ascii msgid is found in catalog after=20
change.

=2D-=20
Chusslove Illich (=D0=A7=D0=B0=D1=81=D0=BB=D0=B0=D0=B2 =D0=98=D0=BB=D0=B8=
=D1=9B)

--nextPart1613154.goEIJdXFhR
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBDtW4KMSGXgigGr3ERAgo3AJ99jr/6X6mVVm+RzJJ5B0Dyj7atdgCdE1JV
r8VOUpqBjAsMBiJCGb8z4hQ=
=FT6q
-----END PGP SIGNATURE-----

--nextPart1613154.goEIJdXFhR--