Skip to content

update locale aliases for glibc 2.24 #422

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 8, 2017
Merged

Conversation

benjaminp
Copy link
Contributor

I also made makelocalealias.py prefer the glibc defaults.

Copy link
Member

@serhiy-storchaka serhiy-storchaka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change needs an entry in Misc/NEWS. Please open an issue on the tracker for discussion and reference.

data.update(parse(args.locale_alias))
data.update(parse_glibc_supported(args.glibc_supported))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this is changed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because some of the X11 locale aliases conflict with the glibc ones. glibc obviously uses the glibc ones. This fixes problems where we would return encodings (like en_IN.ISO8859-1) that don't correspond to the C-level one.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is separate issue (bpo-20087). Let don't mix updating to newer glibc with changing the priority of aliases tables. The latter change needs blessing from the module maintainer.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, this is the only interesting change. I only upgraded the alias list because finding an old version of glibc is slightly annoying and updating it is unlikely to break things.

@serhiy-storchaka
Copy link
Member

I suppose some of changes are related to bpo-20087. This was not discussed yet.

@benjaminp
Copy link
Contributor Author

I think this is the correct fix for bpo-29571.

@benjaminp benjaminp force-pushed the benjamin-locale-aliases branch from 7d6c3b1 to 33a0ce0 Compare March 3, 2017 07:55
@ncoghlan
Copy link
Contributor

ncoghlan commented Mar 3, 2017

Aye, I never did figure out why locale.getpreferredencoding(False) and locale.getlocale(LC_CTYPE) were giving different answers - this would definitely explain it.

+1 for fixing the underlying discrepancy in 3.7+.

@benjaminp benjaminp force-pushed the benjamin-locale-aliases branch from 33a0ce0 to 4f5053a Compare March 4, 2017 07:27
@benjaminp benjaminp requested a review from malemburg March 4, 2017 07:27
@serhiy-storchaka
Copy link
Member

@benjaminp, when you run Tools/i18n/makelocalealias.py on unmodified sources, you get also a list of modified aliases:

#    updated 'az_az' -> 'az_AZ.ISO8859-9E' to 'az_AZ.UTF-8'
#    updated 'ca_ad' -> 'ca_AD.ISO8859-1' to 'ca_AD.ISO8859-15'
#    updated 'ca_fr' -> 'ca_FR.ISO8859-1' to 'ca_FR.ISO8859-15'

It should be added to the long comment before the alias table. Only "updated" lines are needed, not "removed".

Add a comment that glibc aliases now are preferred. This is the main cause of changes.

And please add a test for en_IN.

@benjaminp benjaminp force-pushed the benjamin-locale-aliases branch from 4f5053a to 8ffe417 Compare March 7, 2017 05:42
I also made makelocalealias.py prefer the glibc defaults.
@benjaminp benjaminp force-pushed the benjamin-locale-aliases branch from 8ffe417 to 3738b4a Compare March 7, 2017 05:43
@malemburg
Copy link
Member

Please see the ticket for discussion: http://bugs.python.org/issue20087

@benjaminp benjaminp merged commit 02371e0 into master Mar 8, 2017
@benjaminp benjaminp deleted the benjamin-locale-aliases branch March 8, 2017 06:04
@malemburg
Copy link
Member

This merge should be undone. The PR clearly contains bugs and also is not complete. See the ticket for discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants