[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: KGeography needs your help
From:       Chusslove Illich <caslav.ilic () gmx ! net>
Date:       2005-08-17 3:03:37
Message-ID: 200508170503.40708.caslav.ilic () gmx ! net
[Download RAW message or body]


>>> [: 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 
other long standing problem :) Since I just thought of it, there might be 
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 
runtime, when this call hits, KI18n grabs the msgstr and finds the magic 
sequence #> in the beginning. Thus it knows that msgstr is containing 
plural forms, as much of them as specified by the language (like it is 
now). Then KI18n waits until the argument arrives, and only then decides 
upon which form to take.

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

Incidentaly, #> is also much more magical than old \n delimiter, thus 
solving the problem that we have from time to time, of \n appearing as 
part of normal text. Performance-wise, since #> is in the beginning of 
msgstr, no search through string is necessary to determine if message has 
plurals or not; also, I find this more convenient for editing in KBabel, 
as I usually copy/paste and edit forms, and sometimes forget to delete the 
\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 
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 
be specified if there is only one parameter in the message, or better yet, 
if there is only one number argument in the message (making the 
specification in this example unnecessary). Or we can even default to 
first number argument if absence of specification; this would make the 
specification unnecessary for almost all current plural messages.

Again, let me state there is no scripting in the examples above. Scripting 
now comes as an extra; if translator wants special form for 0, then he 
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 
unimplementable (I did get a bit worried when I remembered there might be 
more than one argument in msgid :)

-- 
Chusslove Illich (Часлав Илић)
Serbian KDE translation team

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]