[Development] QLocale work

[John Layt]

Hi,

Apologies for an extended absence, life got rather busy.  I've now pushed the 
first of my QDate changes for review, but the QLocale stuff now needs more 
focus as the next step.

Discussions back in November around QLocale resulted in a decision to move to 
using ICU as the backend for all localisation functions, but left a lot of 
open questions which I'm now working on.

The general philosophy seems to be:
* The QDate, QTime, QDateTime, QString etc methods for toString/fromString 
should use C locale instead of System locale.  These may use ICU routines or 
their existing routines, but this can be decided later.
* QLocale will be the only class to localise values.  All methods will be a 
thin wrapper around calls to ICU to perform the actual format/parse/whatever.
* In order to respect users default locale settings, QLocale will still need 
to obtain settings from the host system and these settings or the CLDR 
defaults will be passed to ICU, rather than letting ICU decide on the required 
locale or settings.
* The default host system locale settings will continue to be optional, if 
compiled out QLocale will use just the CLDR settings as currently, either by 
querying ICU or just calling ICU with the default locale.

I think there's two different ways to do this within the current class model:

* QCldrLocale - New class, returns the CLDR settings for a given locale.  
Initially could use existing CLDR settings code from QLocalePrivate and then 
later change to calling ICU.
* QLocalePrivate - Could cache current locale settings from system or CLDR on 
creation to save repeated calls to System/ICU.  If is system locale (i.e. not 
specific locale requested by app) then update on signal from host system that 
locale settings have changed.
* QLocale - Reads settings from QLocalePrivate if cached, otherwise does a 
QSystemLocale and QCldrLocale query to obtain settings, and pass them to ICU 
routines.

Alternatively:

* QSystemLocale - Base class returns CLDR settings, derived system classes 
override with their settings where appropriate.  Base class also provides the 
calls to ICU routines which derived class can override where needed.  May or 
may not cache settings.
* QLocale - thin wrapper that just passes all calls to QSystemLocale which 
works out what settings to use and calls to make. QLocalePrivate doesn't do 
much.
* QT_NO_SYSTEMLOCALE - As QSystemLocale base class always needed, changes to 
mean to only use CLDR settings and ICU routines, and not host system settings 
or routines.

I think I'm favouring the second option as being cleaner and easier to 
implement in phases.

This gives a task list of:

High priority, must be in 5.0
* Modify QLocale to use ICU per the decided model
* Modify my existing Calendar code to use ICU instead
* Modify QDate/QString/etc methods for toString/fromString to only use C 
locale instead of system locale with existing code.

Lower priority, prefer done in 5.0 but can probably wait for 5.1:
* Modify QSystemLocale sub-classes to return more platform settings (have 
existing patches)
* Modify QDate/QString/etc methods to use ICU with C locale?

Some other discussion points:

* Date/Time format codes.  The Qt4 format codes differ slightly from CLDR/ICU 
standard codes.  Do we provide fallback support for the old codes, i.e. if 
QT4_COMPAT is set, or make a clean switch to only use the CLDR codes 
everywhere to save confusion?

* Time Zones.  This needs some serious work on what is needed in 5.0.  I doubt 
we can have an agreed model, let alone code, by freeze date.

* UNIX user settings - While I appreciate Thiago's argument that we need a 
single standard way for doing this on UNIX, that will be a way off and will 
not meet KDE's needs for a long time.  With the switch to ICU, the first 
option is now to investigate if KDE can write a CLDR format locale file and 
force ICU to use that so Qt loads it that way.  If that is not possible then a 
private QSystemLocale for KDE could be an interim option until a common 
standard is agreed, perhaps using Lars' binary json parser if it is in QtCore?

Cheers!

John.