New i18n interface for KDE 4, second try

[Chusslove Illich]

>>> [: Nicolas Goutte :]
>>> As Qt had not that QString::arg with multiple argument, there is code
>>> *not* using it. [...]
>>
>> [: Chusslove Illich :]
>> Well, ok, but that is not strictly connected with the interface
>> question we are trying to solve here [...]
>
> [: Nicolas Goutte :]
> Yes, it is more a "by the way" [...]

It was very good that you and Ingo pointed this out, as now I no longer 
think it is a side question :) Hopefully, it might be an important 
argument in favor of the template solution.

As said, template solution already offers less clutter without arg()'s and 
warnings about shady placeholder issues. But still, while misused call 
names can easily be detected by hunter scripts, the loss of some compiler 
help is putting negative light.

Taking this multiple argument problem into account as a new element, we can 
define the templates not as I have originally suggested (eg. for 3 
arguments):

template <typename A1, typename A2, typename A3>
friend i18n (const char *text, const A1 &a1, const A2 &a2, const A3 &a3) {
  KTurtleString(text).arg(a1).arg(a2).arg(a3).toString();
}

but like this instead:

template <typename A1, typename A2, typename A3>
friend i18n (const char *text, const A1 &a1, const A2 &a2, const A3 &a3) {
  KTurtleString(text).args(QString(%1).arg(a1),
                           QString(%1).arg(a2),
                           QString(%1).arg(a3)).toString();
}

In other words, KArmadilloString would have a special args() method, which 
would esentially behave like arg() methods of QString which take multiple 
QStrings, but with some improvements. Eg. we can avoid one inconsistency:

QString("%1 %1").arg("foo").arg("bar")

results in "foo bar", while

QString("%1 %1").arg("foo", "bar")

results in "foo foo".

More importantly, the code which is currently dangerous as Nicolas pointed 
out, and as Ingo et al. had to be carefull of in KMail, like:

i18n("There is a problem with URL %1. Error: %2").arg(url).arg(errmsg);

would become perfectly ok after conversion to template solution:

i18n("There is a problem with URL %1. Error: %2", url, errmsg);

Programmers would no longer have to pay attention to this issue, which is 
currently *not* catchable in an automatic way (unlike the possibility of 
misnamed calls with templates, which are catchable).

To further empower the template solution, we can also dispense with 
formatting .arg() methods of QString:

QString::arg(int a, int fieldWidth = 0, ...)

used like:

i18n("Directory %1: %2 MB").arg(dir).arg(size, 5) // dangerous

by defining few small standalone matching functions:

QString qarg (int a, int fieldWidth = 0, ...) {
  return QString("%1").arg(a, fieldWidth, ...)
}

and using it in template call:

i18n("Directory %1: %2 MB", dir, qarg(size, 5)) // safe

-- 
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/20051030/0988d9c7/attachment.sig>