There are various ways that we fail to use CLDR fully and faithfully. At least:
- CLDR's date-time formatting is richer than ours
- CLDR distinguishes number formatting for percentages from that for currencies and ordinary numbers
- Some number formats have separators in a different pattern than the "thousands" pattern currently assumed
- CLDR locales can have variants (e.g. POSIX variant of C and Valencian variant of Catalan)
- Some fields that QLocaleData expects to store in a single QChar need a surrogate pair in at least some locales
- CLDR has more distinctions than just singular/plural when it comes to varying the forms of texts
The first two (at least) shall require incompatible API and behaviour changes.
All shall require significant re-working of QLocale and its associated classes.
Formatting of dates is handled rather clumsily between Q(Date|Time)+, QCalendar and QLocale. Some rationalisation of this following the addition of calendars (and the movement of some locale-specific data into the care of calendars rather than QLocale itself) shall likely be advantageous also.
Adding support for percentages to our existing (currency and) number formatting will complicate the APIs (in QLocale, QString, QByteArray and likely others), making this a good moment to streamline the existing APIs as far as possible.
All of the formatting-related aspects of this (and linked tasks) should be designed with an eye to eventual C++20 <format>-compatibility.
|For Gerrit Dashboard: QTBUG-79902|
|288200,2||Ensure we use UTF-8 for the emitted QLocaleXML data file||dev||qt/qtbase||Status: MERGED||+2||0|
|293934,10||Take number system into account in currency format look-up||5.15||qt/qtbase||Status: MERGED||+2||0|
|294144,7||Change QLocale to use CLDR's accounting formats for currencies||5.15||qt/qtbase||Status: MERGED||+2||0|
|294245,2||Ensure we use UTF-8 for the emitted QLocaleXML data file||5.15||qt/qtbase||Status: MERGED||+2||0|