New i18n interface for KDE 4

[Chusslove Illich]

(Nicolas answered pretty much everything, I'd just like to put more 
emphasis on some points.)

> [: Tom Albers :]
> Can you give some examples of how this will look like? How does it look
> like from a developers point of view, do we need to do something
> different then the i18n() calls we do now, other the making them
> capitals ;-)?

No capitals :) Ideally, there would be no change in syntax for programmers 
(except perhaps that little possibility of *reducing* syntax...)

The only additional thing you should worry about is actually an old thing, 
but made more strict: don't split sentences. Without this scripting 
system, that just means that you should not split the text, but if you 
consider arguments as part of the sentence, which they indeed are, then 
you should not split them either. Practically, to not split arguments, you 
either use KI18n instead of QString as Nicolas has shown, or if you can, 
just put them together:

QString msg = i18n("Error reading file: %1").arg(i18n("No permission"));

Both approaches are fine, you use whichever suits you better.

However, if programmer does make a wrong split, nothing special happens. 
The program will work fine, the translation will be available, but only a 
nonscripted one (next part). Then, the first translator who tries to use 
the script on that message, checks and sees that it doesn't work, and then 
alarms the programmer (like it is being done now for missing i18n()'s, 
etc.)
 
> And how does this work in the po-files?

An example in my language:

msgid "The capital of %1 is..."
msgstr "Prestonica %1 je..."
"|/|"
"Prestonica $[genitive %1] je..."

The magic thingy Nicolas mentioned is that "|/|" (a fence); it signalizes 
that there is a script attached, which is the part of msgstr following the 
fence. Everything before the fence is an ordinary translation. In this 
particular case, as script I use same text like in ordinary translation, 
but request genitive form of country supplied by %1.

Whatever is inside $[...] is considered a scripting engine expression, and 
"genitive" is the function that translator would have to define. Or more 
precisely, what couple of us translators would make available as a 
cookbook solution. (The expression, "genitive %1", is in this case simple 
enough that it could syntactically be either Scheme or Perl :)

The ordinary translation is there for two reasons, one being that if that 
expression fails (or if programmer split the argument out), user still 
gets some translation.
 
> Are we going to ask translators to script there translations with
> if;then;else;fi constructions, or? 

Yes and no.

One very important point is: the script doesn't have to be there (just 
don't put the fence). So, translator who doesn't want to mess with 
scripting (say, doesn't need it), doesn't see scripting at all. Addition 
of scripting makes absolute zero (as in 0 Kelvin) change to the current 
practices for those translators who choose to stay away from it.

On the other hand, it is not like that there are no common scripting needs 
between languages. In case of such commonalities, on kde-i18n-doc we would 
make more general solutions. This already happened in that thread on 
KGeography; we came to one way to "define" that genitive (or any other) 
form mentioned above, that translator would be able to use, e.g.:

msgid "The Netherlands"
msgstr "Holandija"
"|/|"
"$[has-forms genitive Holandije dative Holandiji accusative Holandiju]"

The only "outside PO" thing here is "has-forms", and that we would make 
available as a ready-to-paste (into outside "include" file, I have some 
system for those too) piece of code. Or it even doesn't have to be 
ready-to-paste, but just plain ready, but I didn't think much about that 
yet.

As for the choice of scripting engine, look at previous two scripted 
messages. I said that the expression used in first one could be either 
Perl or Scheme, but not so for the second. In these two messages together, 
"has-forms" is the *only* thing defined outside, the choice of the wording 
"genitive" and "accusative" was completely at translator's will. And that 
is how it should be: different languages, different cases (forms). Also, 
there is absolute minimum of syntax in call to "has-forms"; no commas, no 
quotes, only pure information. This is Scheme.

-- 
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/20050908/3368e57f/attachment.sig>