Latest revision as of 19:23, 6 June 2011

Warning

This page contains rough working notes from discussion sessions at Platform 11, the contents of which may not accurately reflect any decisions made. Please do not infer anything from these notes, official summaries of the conclusions reached will be made available for discussion as soon as possible.

Locale

NOTE: This page concerns only the Locale functionality of KLocale, i.e. settings, formatting and parsing. It explicitly excludes Translation which is a different topic.

KLocale

Based on POSIX standard locales with many extensions.
Have own locale settings files

What's wrong with KLocale:

Gtk/Qt apps running under kde-workspace don't use the KDE locale
KDE apps running under other platforms/workspaces do not use host locale
Class merges settings, formatters, parsers and translations in one giant blob
Circular dependencies with KConfig and KCalendarSystem
Unnecessary dependency for Qt-Addon libraries

What's great about KLocale:

Users can customise workspace locale settings
Apps can customise locale settings
Many advanced settings and formats not in QLocale (yet)

QLocale

Based on Unicode CLDR standard locales.
Obtaining a POSIX backend foruse on MeeGo in Qt4.8?
http://www.unicode.org/reports/tr35/tr35-15.html
Encodes CLDR data in .h file for performance

What's wrong with QLocale:

Not all KDE, CLDR or POSIX settings are supported
Users unable to change settings
Apps unable to change individual settings without sub-classing QSystemLocale (to/from string methods partially mitigate need for this)

What's good with QLocale:

Uses host settings on all platforms
Low-level common class so good for Qt Addons
Some settings not yet in KDE
QSystemLocale settings container that can be sub-classed

The Plan

Add all KDE settings that are also in CLDR to QLocale
Use QLocale to replace KLocale's role as settings container
- Gives correct Windows, Mac, Gnome, Meego settings
KDE Workspace to set locale envvar on login if KDE locale different to system locale
- Gives correct locale Gtk/Qt apps
KCM to load settings from QLocale, write out as both POSIX and CLDR format files only if user chooses different settings
- locale envvar then set to absolute path to users POSIX file so all Gtk apps get right settings
- QLocale loads CLDR(?) file so KDE/Qt apps get right settings
Apps use parser/formatter classes/api's to alter settings for one-off calls rather than changing the locale itself, or create a whole new locale object.
Settings not available in QLocale are used by formatter/parser classes
Remove our kde-runtime/l10n locale files
Remove currency files and api to new Qt Addon ISO Codes library

Big Questions

Breaks Source Compatibility in a big way, virtually every method and enum has a different name and parms as well as the different namespace. Keep KDE4support KLocale wrapped around QLocale?
Date/Time formats: Keep POSIX formats (need own formatter/parser that translates Unicode format) or switch to Unicode format (not SC, QDateTime may not support all our features)
How will QLocale load custom CLDR? Probably not via xml? Platform plugin? If not CLDR then fallback to custom POSIX file but lacks some settings.

What's missing in QLocale

ISO codes for language/country, uses enums instead [CLDR, already in data .h]
Digit Sets [CLDR]
Binary Formats [???]
Page Size [???]
Decimal Places [CLDR patterns]
Separate monetary number symbols (decimal, sign, etc) [Not in CLDR, POSIX only]
Monetary formatting options internal only not exposed
Digit grouping [CLDR patterns]
Week number systems [CLDR week vars]
Calendar systems [CLDR]
Duration [???]
Pretty format [???]
Day of Pray [???]
Working week start/end [CLDR]
...

What's extra in QLocale

More locale metadata
Script
Quotes
Lists
More number symbols
Standalone month/day names
Read DateTime
...

@@ Line 1: / Line 1: @@
-== Locale ==
+{{warning|This page contains rough working notes from discussion sessions at Platform 11, the contents of which may not accurately reflect any decisions made.  Please do not infer anything from these notes, official summaries of the conclusions reached will be made available for discussion as soon as possible.}}
+= Locale =
+NOTE: This page concerns only the Locale functionality of KLocale, i.e. settings, formatting and parsing. It explicitly excludes Translation which is a different topic.
 * http://community.kde.org/KDE_Core/KLocale
 * http://community.kde.org/KDE_Core/ISO_Codes
+* http://community.kde.org/KDE_Core/QtMerge/QDateTime
+== KLocale ==
+* Based on POSIX standard locales with many extensions.
+* Have own locale settings files
 What's wrong with KLocale:
@@ Line 8: / Line 18: @@
 * KDE apps running under other platforms/workspaces do not use host locale
 * Class merges settings, formatters, parsers and translations in one giant blob
+* Circular dependencies with KConfig and KCalendarSystem
 * Unnecessary dependency for Qt-Addon libraries
@@ Line 14: / Line 25: @@
 * Apps can customise locale settings
 * Many advanced settings and formats not in QLocale (yet)
+== QLocale ==
+* Based on Unicode CLDR standard locales.
+* Obtaining a POSIX backend foruse on MeeGo in Qt4.8?
+* http://www.unicode.org/reports/tr35/tr35-15.html
+* Encodes CLDR data in .h file for performance
 What's wrong with QLocale:
-* Not all settings are supported
-* Apps and users unable to change settings
+* Not all KDE, CLDR or POSIX settings are supported
+* Users unable to change settings
+* Apps unable to change individual settings without sub-classing QSystemLocale (to/from string methods partially mitigate need for this)
 What's good with QLocale:
 * Uses host settings on all platforms
 * Low-level common class so good for Qt Addons
 * Some settings not yet in KDE
+* QSystemLocale settings container that can be sub-classed
-The Plan:
+== The Plan ==
-* Add all KDE settings that already exist in CLDR to QLocale
+* Add all KDE settings that are also in CLDR to QLocale
 * Use QLocale to replace KLocale's role as settings container
 ** Gives correct Windows, Mac, Gnome, Meego settings
@@ Line 34: / Line 57: @@
 ** QLocale loads CLDR(?) file so KDE/Qt apps get right settings
 * Apps use parser/formatter classes/api's to alter settings for one-off calls rather than changing the locale itself, or create a whole new locale object.
+* Settings not available in QLocale are used by formatter/parser classes
+* Remove our kde-runtime/l10n locale files
+* Remove currency files and api to new Qt Addon ISO Codes library
+== Big Questions ==
-Big Questions:
+* Breaks Source Compatibility in a big way, virtually every method and enum has a different name and parms as well as the different namespace.  Keep KDE4support KLocale wrapped around QLocale?
 * Date/Time formats: Keep POSIX formats (need own formatter/parser that translates Unicode format) or switch to Unicode format (not SC, QDateTime may not support all our features)
-* How will QLocale load custom CLDR?  Fallback to custom POSIX but lacks some settings.
+* How will QLocale load custom CLDR?  Probably not via xml?  Platform plugin?  If not CLDR then fallback to custom POSIX file but lacks some settings.
+== What's missing in QLocale ==
+* ISO codes for language/country, uses enums instead [CLDR, already in data .h]
+* Digit Sets [CLDR]
+* Binary Formats [???]
+* Page Size [???]
+* Decimal Places [CLDR patterns]
+* Separate monetary number symbols (decimal, sign, etc) [Not in CLDR, POSIX only]
+* Monetary formatting options internal only not exposed
+* Digit grouping [CLDR patterns]
+* Week number systems [CLDR week vars]
+* Calendar systems [CLDR]
+* Duration [???]
+* Pretty format [???]
+* Day of Pray [???]
+* Working week start/end [CLDR]
+* ...
+== What's extra in QLocale ==
-What's missing in QLocale:
+* More locale metadata
-* ISO codes for language/country, uses enums instead
+* Script
-* Digit Sets
+* Quotes
-* Binary Formats
+* Lists
+* More number symbols
+* Standalone month/day names
+* Read DateTime
 * ...