KLocale plans (Re: KF5 Unit test results)

[David Faure]

On Tuesday 11 September 2012 13:15:37 Chusslove Illich wrote:
> > [: David Faure :]
> > Is it also part of your plans to remove i18n()'s dependency on KLocale?
> 
> I consider it rather an orthogonal matter. I will anyway remove all Gettext-
> related stuff from KLocale, before doing anything about replacing
> *gettext() calls themselves.
> 
> > This is what's blocking me now, for extracting a ki18n framework (which I
> > then need for the kservice+plugins framework).
> > 
> > I think I'll let you move ahead on this topic and I'll find another area
> > to work on meanwhile, there are plenty :-)
> 
> On the other hand, not to stall unnecessarily, maybe it would be better if I
> "real soon" factored out i18n as it is into staging/ki18n (possibly
> temporarily breaking some internal details, which is no big issue)? And
> only then go into what I mentioned before, proposing updated
> klocalizedstring.h with new doc, etc. This shouldn't lead to any wasted
> work, only slightly changed order of doing it.

The reason I'm asking about KLocale, is that it currently depends on 
KCalendarSystem, KDateTime and KDayPeriod, all of which are not related to 
ki18n. (and that's basically all of kdecore/date except for the timezone 
stuff).

So either i18n is ported away from KLocale, or all that calendar stuff has to 
move into the ki18n framework, at least in the short term.

Apparently the calendar stuff itself has no additional dependencies (apart from 
a few kdefakes.h that Nicolas is currently fixing and a KToolInvocation that 
I'll fix), so the second solution is workable technically.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5