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. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development