New i18n interface for KDE 4, second try

[Nicolas Goutte]

On Saturday 29 October 2005 15:37, Chusslove Illich wrote:
> >> [: Chusslove Illich :]
> >> Throughout base KDE packages, I've encountered 130 i18n calls with
> >> .arg() methods with more than one argument [...]
> >
> > [: Nicolas Goutte :]
> > As Qt had not that QString::arg with multiple argument, there is code
> > *not* using it. (Often you can recognise such code at string like "%3
> > %1 %2" where the numbers are not in sequence but the user-given string
> > is the last argument.)
>
> Well, ok, but that is not strictly connected with the interface question we
> are trying to solve here (in any case, arg() methods would be available).

Yes, it is more a "by the way" of what you wrote in the first email.

>

(...)

>
> >> [: Chusslove Illich :]
> >> For example, when giving context, if they forget to specify correct
> >> call name:
> >>
> >> i18n("This is entry in menu Session", "New");
> >
> > [: Nicolas Goutte :]
> > I really think that long names are the way to go:
> >
> > i18n
> > i18n_context
> > i18n_plural
>
> Hm, I've got nothing against long names, but I think typos would be much
> smaller problem than plain forgetting to use appropriate call (or not?),
> and long names wouldn't fix that (or would they?)

Yes, it is the problem of keeping i18n (but here we cannot rename it to 
l10n. :-) )

But I think that long names are better for the developer to learn. (Also Qt 
and KDE have more descriptive identifier names than cryptic ones, especially 
that Qt4 seems to have made a great effor to rename all fuzzy meanings of 
identifiers.)

>
> > By the way, it would be nice, if you could find a way to have a
> > I18N_NOOP_PLURAL.
>
> I thought this one is not already there because there is no need for it, is
> there a situation where it could be used?

If I remember well, there was one once and the change was reverted, as the 
definition had only 2 parameters. But the patched xgettext needs 3 parameters 
for a plural,

I do not really remember why a new version with 3 parameters was never 
committed, probably as it looks funny to have a dummy parameter.

>
> Anyway, what would be the problem having just:
>

> #define I18N_NOOP_PLURAL(singular, plural)  singular, plural

That is probably part of the problem too. How do we define it? The result is 
not something that you can use easily in a variable, as one already needs a 
structure for it (or a more complex class like a QStringList).

>
> and then eg:
>
> struct myEarlyPlurals {
>   const char *singular, *plural;
> }
>
> const myEarlyPlurals mep[] = {
>   {I18N_NOOP_PLURAL("Mary had a little lamb","Mary had %n little lambs")},
>   ...
> }
>
> later on in the code:
>
> i18np(mep[i].singular, mep[i].plural, nlambs);
>

> (Extraction of in this way defined I18N_NOOP_PLURAL by xgettext is also no
> longer a problem.)

Yes, I have supposed so. That is why I have thought that we could again 
discuss about it.

Have a nice day!