New i18n interface for KDE 4
Chusslove Illich
caslav.ilic at gmx.net
Mon Sep 5 14:41:38 BST 2005
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>
More information about the kde-core-devel
mailing list