New i18n interface for KDE 4, second try

[Chusslove Illich]

>> [: Chusslove Illich :]
>> QString("%1 %1").arg("foo").arg("bar")
>>
>> results in "foo bar", while
>
> [: Nicolas Goutte :]>
> Ooh, I have not know this trap!

It is undefined behaviour as per Qt 3.3 docs, and no mention in Qt 4.0 
docs. But rest assured, it is being used with precisely this intention; 
check message containing "Welcome to Kontact" in 
kdepim/kontact/src/mainwindow.cpp of branch 3.5. And someone also wanted 
it the other (proper?) way around, so he had to use a workaround, check in 
kmail/kmstartup.cpp message with comment containing "only replaces the 
first occurrence" appended.

This template solution would get rid of such problems. And again, 
programmers wouldn't have to remember to use multiple arg() instead of two 
single arg() methods in situations which require that for safety.

So I wonder, is this enough to outweight the problem of mixing call names 
(taking into account these can be discovered by code-checking scripts)?

> [: Nicolas Goutte :]
> [qarg()] is pretty much useless. If we go so far away from QString, we
> can directly use QString::number, which is static. (That would be
> better than to have QString-like arg functions but that do not work
> like QString::arg functions.)

I did mean that qarg() would behave same as corresponding arg() (ie. one 
qarg() for every formatting arg() method). But, as I said, this is 
completely orthogonal feature, shouldn't have even mentioned it at this 
point :)

-- 
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/630972fa/attachment.sig>