Created attachment 5954 [details]
Summary of glibc country_name field entries.
I have performed a comprehensive analysis of the use of the LC_ADDRESS field for country_name. I am somewhat concerned by the findings of that analysis for a field that should be populated with the name of the country in the language of the locale, two pieces of information inherent in the locale name.
There are 279 locales (excluding the deprecated iw_IL).
Of those 279, only 84 locales have populated country_name fields.
43 empty, (not readily determined)
152 empty, but can be easily determined by look-up in ISO-3166 L10n files.
equals 279 total
Of the 84 populated country_name fields:
37 can be confirmed from ISO-3166 L10n files.
31 cannot be confirmed from ISO-3166 L10n files (not necessarily a problem).
16 have obvious encoding errors or require review and / or correction.
Examples of errors:
km_KH encodes Lao characters spelling Laos, not Khmer characters spelling Cambodia.
bg_BG, ku_TR, mk_MK, mn_MN, tr_TR encode English, not native language/script names
bo_CN and bo_IN coded as FIXME, should be commented out.
dz_BT coded as BHU
ur_IN uses "copy hi_IN", thus encoding Localein Hindi, not Urdu language name of India.
en-US encodes USA (not United States)
es-US encodes USA (not Estados Unidos)
Others include conflicts with ISO-3166 entries that require clarification.
Some consideration should be given to correcting the obvious errors and making the easily confirmed additions so that the LC_ADDRESS country_name field is more usefully populated with the country name of the locale in the language of the locale.
The first column attached spreadsheet contains links to 2xlibre.net locale files (purely for convenience), This data had been recently refreshed from 2.14 release.
All details checked against original sources at:
The key columns are the "Action" (suggested) and the "Corrected country_name" column. The entries in the "Evidence ISO-3166" column link directly to the relevant location within the PO files.
Either you provide a real patch and not something as useless as a spreadsheet or you close the bug.
Ulrich, thank you for commenting, I wasn't sure anyone had looked at this bug.
As it was a global analysis a spreadsheet seemed the best way to communicate about it. Are you saying that the only way to get action would be to provide several hundred individual patches? Just trying to understand.
If I would have to receive the patch, I would like to have one for changes/fixes and one for new field additions, but it's just me...
> As it was a global analysis a spreadsheet seemed the best way to communicate
> about it. Are you saying that the only way to get action would be to provide
> several hundred individual patches? Just trying to understand.
For all files where the change has been created the same way a single patch is sufficient. But yes, a patch is needed.
I will work on several patches as suggested. I was not sure that such a multi-locale patch would be acceptable. i will break them out as logically as possible, additions supported by ISO-3166, simple fixes (commenting out the "FIXME"), etc.
*** This bug has been marked as a duplicate of bug 11484 ***
I'm sorry wrong issue marked as duplicate
Restored to waiting
i'm in the process of updating all locales to the CLDR entries. since it'll be automated from a vetted source, doing multiple patches shouldn't be needed.