Locale update

John Layt jlayt at kde.org
Mon Mar 19 23:38:41 UTC 2012


Hi,

With Qt 5.0 now effectively API and feature frozen, I thought I'd update 
everyone on my progress (or lack there-of) with pushing stuff from KDE into 
QLocale and QDateTime.

The bad news is that none of the new date API made it into 5.0 and has now 
been put off to 5.1.  This is mostly down to Qt deciding to go with 
libicu as a localization backend, meaning all the backend code I had written 
got trashed and I didn't have time to re-wire the api to ICU.

The better news is I did get a number of BIC and behavioural changes in to 
tidy things up and extend the supported date range.  The new API is also 
fairly well nailed down, except for the new QTimeZone which needs work.  Qt 
4.8 has already added a lot of the other api we needed.  Once the new ICU 
based code is in Qt 5.1 we get pretty much the full set of locale features in 
a standard cross-platform way, even if api to control it is lacking at first.

The implication of this is that any switch to fully using QLocale and 
QDateTime will have to depend on Qt 5.1 and we have to decide if this is 
acceptable.  Most things in kdelibs/frameworks could be switched right now 
with minimal visible difference, except for Calendar (and thus all the date 
widgets) and Binary.  The impact on apps using frameworks would be far 
greater.

So, do we accept the risk and start porting, or do we keep using KLocale until 
it feels safe?  I'm pretty confident we will be OK.

I think the Tier 1 libraries should definitely switch now to using QLocale and 
tr() exclusively.  I see no point in delaying their switch as we want 
them independent of KLocale entirely.  Their use of KLocale should be minimal 
anyway.

Any other framework code using straightforward locale methods can probably be 
switched straight away too.  It's only code using Binary and Calendar methods 
that will need to continue using KLocale for now.

I've now created a page at [1] detailing the possible migration path.  It 
sketches out how to replace KGlobal::locale() and starts mapping out the 
KLocale to QLocale api conversion.  I'd appreciate any comments people have.

[1] http://community.kde.org/KDE_Core/KLocale/Frameworks

Cheers!

John.



More information about the Kde-frameworks-devel mailing list