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

>>> [: Krzysztof Lichota :]
>>> Programmers could use i18n("%1 files").arg(numFiles) and the rest would
>>> be translators task :)
>>
>> [: Nicolas Goutte :]
>> That would mean that everybody needs scripting. That does not really
>> to be wanted.
>
> [: Krzysztof Lichota :]
> Current plurals handling code is just such scripting. And if you are
> worried [...]

I might have a solution which suits both of your points, and solves one=20
other long standing problem :) Since I just thought of it, there might be=20
some holes, but here it goes.

Programmer writes:

i18n("Found %1 files").arg(numFiles)

and Highinflexish translator, needing 3 forms, does this:

msgid "Found %1 files"
msgstr ""
"#>Found %1 file"
"#>Found %1 files"
"#>Found %1 filess"

What happens here? First, recall that KI18n class can capture arguments. At=
=20
runtime, when this call hits, KI18n grabs the msgstr and finds the magic=20
sequence #> in the beginning. Thus it knows that msgstr is containing=20
plural forms, as much of them as specified by the language (like it is=20
now). Then KI18n waits until the argument arrives, and only then decides=20
upon which form to take.

So, from translator's point of view, this is just a different take on=20
current system, no scripting here. Additionally, translator can decide not=
=20
to use plural forms at all (eg. putting just "Number of found files: %1").=
=20
=46rom programmer's point of view, no special i18n() for plurals is needed=
=20
any longer.

Incidentaly, #> is also much more magical than old \n delimiter, thus=20
solving the problem that we have from time to time, of \n appearing as=20
part of normal text. Performance-wise, since #> is in the beginning of=20
msgstr, no search through string is necessary to determine if message has=20
plurals or not; also, I find this more convenient for editing in KBabel,=20
as I usually copy/paste and edit forms, and sometimes forget to delete the=
=20
\n at the end of last form.

The only caveat is if message contains more than one parameter, like:

i18n("Found %1 files in folder %2").arg(numFiles).arg(folder);

Then, the translator can insert extra, dummy form, containing just the=20
number of decision parameter, upon which the correct form will be taken:

msgid "Found %1 files in folder %2"
msgstr ""
"#>1"
"#>Found %1 file in folder %2"
"#>Found %1 files in folder %2"
"#>Found %1 filess in folder %2"

In light of previous example, we can say that decision parameter needs not=
=20
be specified if there is only one parameter in the message, or better yet,=
=20
if there is only one number argument in the message (making the=20
specification in this example unnecessary). Or we can even default to=20
first number argument if absence of specification; this would make the=20
specification unnecessary for almost all current plural messages.

Again, let me state there is no scripting in the examples above. Scripting=
=20
now comes as an extra; if translator wants special form for 0, then he=20
scripts:

msgid "Found %1 files"
msgstr ""
"#>Found %1 file"
"#>Found %1 files"
"#>Found %1 filess"
"|/|"
"$[for-zero \"No files found\"]"

That is it. I hope I didn't overlook anything that makes this=20
unimplementable (I did get a bit worried when I remembered there might be=20
more than one argument in msgid :)

=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

--nextPart1430079.aNWhkYY2IY
Content-Type: application/pgp-signature

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

iD8DBQBDAqkMMSGXgigGr3ERArsZAJ9CDyz4Uh5XkrRi87Vs7t5dBNn4YACeIHy2
ZZozZrLyVlMGhEGjCMYriQA=
=jyPA
-----END PGP SIGNATURE-----

--nextPart1430079.aNWhkYY2IY--