Further on the road to new i18n API for KDE4

[Nicolas Goutte]

On Tuesday 14 March 2006 00:24, Chusslove Illich wrote:

As I suppose that you know my position from previous discussions (and 
therefore do not need it re-iterated), here just a few comments on details.

(...)
>
> Which brings us to second issue, the number formatting. Few days ago, on
> the kde-i18n-doc someone finally raised the question of localized numbers,
> and we are not talking only dots or commas here, but also different
> digits.
>

> With respect to this, Qt offers new %1L placeholders, for localized
> numbers, but I don't know how far these go. 

As QLocale does not go far enough, %1L cannot go further than what QLocale 
implements. So it is probably not enough...

> And even if it is just what we
> need, it is still a pain to put the L's where they should go. The other
> possibility is to always use KDE's number formatters from KLocale, but
> that is yet even greater pain :) So, count both out for large scale
> introduction -- we need something automatic.
>

> The solution, as of now, is to introduce new specialized class, the
> KLocalizedString. To fascilitate extraction by Gettext, it could only be
> instantaniated through friendly wrapper functions, which for the moment
> I'll call ki18n. It would be used like this:
>
> ki18n("%1, %2...").argf("foo%1").argf(10).toString()
>
> which would yield "foo%1, 10-in-your-own-digits...".
>
> argf() methods would simply store arguments inside the class instance, and
> the substitution of placeholders would go at one pass in toString();
> argf() methods for numbers would call within them KDE's number formatters.
> I use name argf() instead of arg(), as they are going to be operationg
> differently from QString's arg().

What happens when the developer uses arg() and not argf(). I expect that this 
will be done quite a number of times.

>
(...)


> Thoughts, comments? I already have code conversion scripts for
> semi-automatic conversion to new API, and I've tested the system on KDE
> 3.5 branch code (ie. kdelibs and kdebase converted and compiled).

In which time would you be ready to put it in trunk/KDE?

Personally I would have prefered the changes in trunk/l10n to be first, 
somewhen after KOffice 1.5 is out (assuming that there is an agreement with 
the translators and document writers but I do not want to start that 
discussion now, as the translators are probably concentrated on translate KDE 
3.5.2 and KOffice RC1 and then final).

Have a nice day!