New i18n interface for KDE 4

[Chusslove Illich]

On kde-i18n-doc there has been some discussion about how to provide more 
power to KDE translators, especially for translating into mid to highly 
inflected languages.

For example, one of the problems is that sometimes an argument in a 
message, like "Open with %1", in some languages requires form (case) 
different than the basic one, so that it is in agreement with sentence 
structure. A very thorough demonstration of this kind of problem (as well 
as a lot of talk regarding how we can solve it with new interface) can be 
found in, what I believe to be quite infamous, thread on kde-i18n-doc: 
http://lists.kde.org/?t=112300742000007&r=1&w=2

The idea is to allow translators to somehow operate on arguments at 
runtime, what I refer to as "translation scripting". The realization of 
this concept can be divided into two decoupled parts: an i18n interface 
capable of "capturing arguments", and choice of scripting engine for the 
translator. Decoupled means that the choice of scripting engine (or 
translator side interface) would not influence the application interface, 
ie. could be tweaked at will without breaking binary compatibility.

From discussion so far, the second part (scripting engine) seems to be more 
problematic, due to concerns of overhead, security and organization. So I 
would postpone talk about this point until new structure and policies for 
kdelibs are established. But it can also turn out there is a show-stopper 
for the first part (new i18n interface), and then there is no point 
talking about the second part :)

So, at this moment we could talk about new i18n interface, and I think this 
is the proper timing because it would introduce one extra class, whose 
position in reorganization of kdelibs would have to be determined.

Presently, translations are made through calls to i18n() functions, which 
return QString containing the translation with placeholders, and then the 
arguments are substituted using QString's arg() methods. The problem here 
is that translation occurs before arguments come into play, so nothing can 
be done to arguments under the hood.

Instead, i18n() functions should return a special class, named say KI18n, 
which would have its own arg() methods, smart enough to store arguments as 
they come, and perform the translation only when all the arguments have 
been supplied (passing the arguments to underlying scripting engine...)

On kde-i18n-doc we came up with three ideas of how this KI18n could be 
implemented, but at this point there should be an intermezzo, like 
reflecting if any of the above makes sense? :) Perhaps you have further 
questions about need of sketched system, expected performance overheads, 
whatever...

(I do have one possible implementation of the whole thing in SVN right now, 
including a particular scripting engine linked in for proof of concept, so 
that I can run KDE with added translation candy and show off with 
screenshots...)

Onwards to the possibilities for implementation of KI18n.

First is that KI18n is inherited from QString, and only has the smart arg() 
methods which override QString's. The positive side is that source 
compatibility with present KDE app code is almost preserved, very few and 
trivial changes are needed (problems are mostly in applications of ternary 
condition op, where illegal conversion is sometimes requested). The 
negative side is that QString isn't really made to be inherited (eg. no 
virtual destructor, so dynamic allocation of KI18n should be forbidden), 
and people also pointed out that there is no clear is-a relation to 
QString.

Second one is to not inherit KI18n from QString, but provide some 
facilities for implicit conversion to QString, and some more overriding 
methods to QString's original ones. This is in order to preserve as much 
as possible of source compatibility and current programming habits. 
Positive here is that there is no dependency on QString, and negative is 
that implicit conversions are double-edged sword, selection of overriding 
methods is dubious, and still it might not be able to achieve same level 
of source compatibility as with inherited version.

Third approach is again with non-inherited KI18n, but also without implicit 
conversions and (possibly) without extra overriding methods. Instead, KDE 
widgets taking QString's would be changed to take KI18n's. This approach 
is both clean and would force programmers not to forget to wrap naked UI 
messages (they would get compile time error), but there are problems with 
choosing what exactly constitutes as UI string arguments in classes, and 
with the fact that pure Qt widgets are used as well.

I favor the first approach, with KI18n inherited from QString. The downside 
of restrictions imposed by QString not being quite inheritable, is IMHO 
offset by the fact that nobody would want to do anything fancy with KI18n 
anyway (just usuall i18n() calls, like till now). And the downside of 
dependency to QString is not a problem restricted to KI18n, as if 
something strange would happen to QString, there would be whole lot more 
breakage.

I have also toyed with second possibility (non-inherited KI18n, implicit 
conversions), trying to just compile as much files in KDE modules to see 
what problems would come up. And it turned out that no matter what 
conversion facilities I used, this or that class or function would 
complain about inappropriate arguments (thus requiring ugly explicit 
conversions throughout).

Third possibility (changing widgets to accept KI18n instead of QString) I 
didn't give much consideration, for the problems I mentioned (presence of 
Qt widgets, deciding which arguments are UI messages) seem to me too tough 
to crack.

The above mentioned implementation is for the approach I preffer, with 
inherited KI18n, so we can discuss it in more detail. Implementation is 
there for both snapshot of kdelibs4 and 3.5 branch (to have a stable 
testing platform).

There is also an interesting "side effect" of the new interface: it would 
allow us to get rid of the plural handling variant of i18n(), and of 
course still have plurals for the translations (and more capable than they 
are now, and without usage of scripting engine). Unfortunately, although 
this seems attractive at first sight, there are some organizational 
concerns involved that yet have to be discussed.

-- 
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/20050905/f748be19/attachment.sig>