Locale update

[Kevin Ottens]

Hello,

On Monday 19 March 2012 23:38:41 John Layt wrote:
> 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.

It is, we're not going to release KDE Frameworks 5.0 before Qt 5.1 anyway. 
There other changes we will need which are earmarked for Qt 5.1 as well. It's 
just one more, and we've seen that one coming I'd say, no worries.

> 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.

Agreed.
 
> 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.

That's perfectly fine.

> 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

Indeed there's a fairly large impedence mismatch between the two. I guess apps 
will keep using KLocale from kde4support for a little while as it seems 
difficult to automate the porting there.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120321/9c1594c8/attachment.sig>