New i18n interface for KDE 4, second try

[Chusslove Illich]

> [: Nicolas Goutte :]
> Does Gettext knows how to handle %L in its Qt mode?
>
> If Gettext does, it would at least avoid that the translators forget
> the L.

I didn't check, but again the question is why force programmers use %L if 
they don't have to? Actually, upon further investigation, it seems 
KLocale::formatNumber() is used for this purpose in KDE, and...

> But, anyway, on the developer side, it can indeed be forgotten.

It *can* be forgotten? You are an optimist :) Of course something mundane 
like that will be forgotten all over the place. For example, in Konqueror, 
formatNumber() is used for display of file sizes, but not for number of 
files in the status line. On closer inspection, it turns out that it is 
plural handling i18n call (put_n_in function) which doesn't use number 
formatting.

Templates i18n's and argf's would make this formatting automatic, and the 
way we want it in KDE, not under strict Qt's control.

By the way, I figured out a certain heuristic for compiler itself to barf 
on misnamed template calls. It follows from two observations.

First, by far the dominant misnaming would be leaving plain i18n instead of 
i18nc or i18np. Like when adding a context or pluralizing the message at 
later point.

Second, in base KDE packages, the number of i18n calls which have a naked 
string literal as its first .arg() is just about 160. And usualy these are 
not necessary (naked literal as an argument is kind of strange anyway), 
they can be refactored in a cleaner way (eg. 60 of them are in KStars, and 
a cleaner solution there is obvious).

This tells me that when a basic i18n template with two starting arguments 
being string literals is encountered, it is most probably an error of 
misnamed call. So, to each basic i18n template there could be a 
corresponding "trap" template which produces compiler error upon 
instantiation.

Eg., for normal i18n template:

template <typename A1, typename A2>
QString i18n (const char *text, const A1 &a1, const A2 &a2)
{
  ...
}

a matching trap template would be:

template <typename A2>
QString i18n (const char *text, const char *trap, const A2 &a2)
{
  return
    String_literal_as_second_argument_Perhaps_you_meant_i18nc_or_i18np
    (text, trap, a2);
}

So, when compiler encounters misnamed context call:

i18n("%1 is application name", "Configure %1", app);

it would refer to trap template, as it is a more specialized match. So an 
error pops up saying that String_literal_... is not defined, ie. you get a 
funnily disguised info :) I've checked, it works.

And if you really, really need the first argument to be string literal, you 
just wrap it up with argf() or something.

> (Perhaps it is a wish for Gettext too, to have a msgstrzero and
> msgstrone .)

Don't think I haven't given it a thought :) But I am still not believing 
that my cry for context went through; we were approaching another 
do-nothing resolution, when Bruno suddenly decided to actually implement 
the msgctxt, contrary to opinions against it. I'll wait some time before I 
push my luck again :)

-- 
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/20051101/b7a678dc/attachment.sig>