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.
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
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 first column attached spreadsheet contains links to 2xlibre.net locale
files (purely for convenience), This data had been recently refreshed from 2.14
--- Comment #2 from Chris Leonard <cjlhomeaddress at gmail dot com> 2011-12-22 17:06:57 UTC ---
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.
--- Comment #3 from Claude Paroz <claude at 2xlibre dot net> 2011-12-23 08:30:43 UTC ---
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...
--- Comment #4 from Ulrich Drepper <drepper.fsp at gmail dot com> 2011-12-23 14:53:49 UTC ---
> 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.
--- Comment #5 from Chris Leonard <cjlhomeaddress at gmail dot com> 2011-12-23 14:59:08 UTC ---
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