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

> [: Nicolas Goutte :]
> And the solution does not seem to mix well with a normal Gettext
> plural.

I wouldn't really say that it doesn't "mix" well, quite the opposite. By=20
this I mean that in a standard Gettext PO, you could have this new=20
handling alongside Gettext's plural forms without problems. The only=20
question is of policy, I feel such redundacy wouldn't be helpful.

Now I am thinking it over, what exactly are the reasons of wanting to=20
switch to standard Gettext for KDE? I remember only of wish to avoid using=
=20
patched xgettext and this problem with plural forms containing newlines.

If so, this new approach for plurals also gets rid of newline problem and=20
of part of patch to xgettext, while also freeing programmers from special=20
plural syntax. As for other part of the patch to xgettext, handling=20
context info... Well, Gnome people are using standard Gettext, and they=20
didn't come up with anything else other than embedding context into the=20
message by hand, with a delimiter between context and message (like=20
"download status|Unknown").

> [...] KDE's plural count or Gettext's plural formula do not give any
> hint of how many additional pseudo-plurals would be needed. [...]

I think Gettext actually can pull it off, by translator specifying more=20
specific Plural-Forms: header. But then, every plural message would have=20
to have all those forms written out, which doesn't seem desirable.

> The only idea I have is to have:
> msgstr "#0>Zero#1>One#>singular#>plural1#>plural2"
>
> Where #0> would introduce the "0", #1> would introduce "1" and #> the
> normal plural forms.

You are talking about extra functionality to plurals themselves, whereas I=
=20
was only thinking of providing cleaner interface (both on programmer's and=
=20
translator's side) to what is already available, with scripting for=20
extras.

I like this idea, I am only concerned about realization. On translator's=20
side, it looks reasonable, but I would still like if each plural form=20
could begin with same delmiter (with these special cases somehow=20
following). Also, in implementation it would no longer be lightweight to=20
parse (would have to use QString::split() with regex?)

> Also if you create new notations be careful that a \n at start and a \n
> at end must remain there in the translation or "msgfmt --check" will
> complain.

Didn't think about the starting \n :) That one, I think, happened never=20
till now (as opposed to newlines in the middle), so I guess it would be=20
enough to allow *only first* delimiter (#>) to be preceeded by \n. At=20
runtime that would mean only one light check extra.

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

--nextPart1382889.YbSBnDGfLT
Content-Type: application/pgp-signature

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

iD8DBQBDBIWwMSGXgigGr3ERAmEnAJ0WLze8DFFPLvBDKT9buXqFUKnKJgCeKZQE
6GDiVR8uiVtSRsPqUcGfCm0=
=bUJT
-----END PGP SIGNATURE-----

--nextPart1382889.YbSBnDGfLT--