On Sunday 15 Jan 2012 19:04:09 John Layt wrote: > I think I'm favouring the second option as being cleaner and easier to > implement in phases.
After reading more of the ICU number API and trying some things out, I now think sticking closer to the current model will actually match the ICU API better and require less code albeit in one big bang. * QLocalePrivate holds instances of the ICU Locale, NumberFormat, DateFormat etc classes. QLocale methods call these objects directly to obtain format codes and perform format/parse without any call to QSystemLocale. * For Named locales, i.e. app creates QLocale instance for en_GB: QLocalePrivate is created, ICU Locale and format classes initialised. All QLocale calls will thus use only the CLDR default settings for the named locale. * For System locale, i.e. app creates default QLocale instance: QLocalePrivate created as per Named locales, but then calls QSystemLocale to obtain all the settings which are used to set the ICU NumberFormat and DateFormat default values. All QLocale calls will thus pickup the system settings. * A QCldrLocale is not really needed for Qt purposes, it's only needed for anyone who wants to know what individual settings are, like KDE. Note the ICU Format class instances may have delayed initialisation for efficiency, i.e. only when toString() is called for the first time. Cheers! John. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development