Details
-
Bug
-
Resolution: Fixed
-
P2: Important
-
5.15, 6.0, 6.1, 6.2
-
None
-
-
8
-
1ae24f8b5 (dev), afd7d6824 (dev), 743ceb7cc (dev), e212b3633 (dev), d105c67a7 (dev), a61e3d798 (6.6), 5f974909b (tqtc/lts-6.5)
-
Foundation Sprint 88
Description
At present, qlocale_data_p.h's *_name_list[] arrays for (English, at least nominally) names of languages, scripts and territories use ASCII-compatible names derived from enumdata.py, matching the members of QLocale's Language, Script and Territory enums. The latter, of course, have to have ASCII-compatible names; but the names in the arrays are the ones returned by languageToString() and related QString-returning methods that can cope with more than just ASCII. Since some of the languages, scripts and territories have names, in CLDR's en.xml – so nominally English, although sometimes with accented letters not normally used in English, e.g. "Norwegian Bokmål" for nb_NO or "Côte d’Ivoire" for CI – that don't always coincide with the ASCII-compatible names we use for the enums (in the given examples, NorwegianBokmal and IvoryCoast). In some cases (e.g. Ivory Coast) the name we use for the enum is a recognised variant, listed by CLDR alongside the definitive form, but it would be more consistent with CLDR to use the definitive form.
This arises because we need ASCII names for the enums, but it's only a matter of changing the scripts that generate the data to get the en.xml names into the *_name_list[] arrays instead. Some reworking of the util/locale_database/ scripts shall, of course, be needed.
At present, those scripts do report on major discrepancies between the ASCII-compatible names and the en.xml ones; the fix would be to have it propagate those en.xml names through the QLocale XML data-file from CLDR through to the data-generation step.
Attachments
Issue Links
- is required for
-
QTBUG-72491 Qlocale::system returns wrong language on MacOS
- Closed
- relates to
-
QTBUG-47892 QLocale("es").nativeLanguageName() is "español de España"
- Reported
-
QTBUG-79902 QLocale: make fuller and more faithful use of the CLDR data
- Open