gh-151316: Prefer UTF-8 for glibc UTF-8-only locale aliases

[sankalpsthakur]

Summary

• Bare locale aliases that are UTF-8-only in glibc SUPPORTED were still mapped to obsolete X11 codesets because makelocalealias applies X11 locale.alias after glibc.
• On modern systems those locales have no legacy encoding, so getlocale() invented the X11 codeset and setlocale(getlocale()) failed (reported for en_IN).
• Sweep all such bare aliases to prefer UTF-8, restore glibc UTF-8 defaults in Tools/i18n/makelocalealias.py after the X11 merge (plus a de_li carve-out, which has no bare SUPPORTED line), and cover the replacements with TestHardcodedLocaleReplacements.

Validation

• Checked in-tree locale_alias entries and normalize/_parse_localename expectations for the 19 restored bare aliases.
• Explicit legacy encodings (for example hi_IN.ISCII-DEV, az_AZ.ISO8859-9E) still normalize unchanged.
• Full ./configure && make + ./python.exe -m test test_locale was not run here (sparse/partial clone); relying on CI for the built interpreter suite.

Fixes #151316

AI/LLM disclosure

• AI coding tools (including Grok and/or Codex agent-assisted editing) were used to help draft or modify code and this PR description.
• I reviewed the complete change, understand the reasoning, and ran the reported local tests before submitting.
• This submission is original work of authorship under the project CLA / contributor terms; AI output was not pasted unreviewed.

• Issue: locale.getlocale() returns wrong encoding if the locale name doesn't have one #151316

[python-cla-bot]

The following commit authors need to sign the Contributor License Agreement:

• sankalphimself@gmail.com

[StanFromIreland]

You'll have to sign the CLA before we can review.

[picnixz]

Is it the only locale that could have this issue? I would prefer we sweep them all to check if this is the case first instead of having commits for each locale. Also, I think we should instead have a test class that checks for hardcoded replacements thatwe introduce instead of just the case of en_IN.

[bedevere-app]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[sankalpsthakur]

Swept the glibc UTF-8-only locale aliases (not just en_IN), added a test class for the hardcoded replacements, and dropped the irrelevant comment. Still need to finish CLA signing for sankalphimself@gmail.com before this can leave draft.

[sankalpsthakur]

Thanks for the review.

I swept glibc SUPPORTED against X11 locale.alias for bare locales that are UTF-8-only in glibc but still mapped to obsolete X11 codesets. The alias table and makelocalealias now restore those UTF-8 defaults in one pass (19 bare aliases, including en_IN), instead of fixing locales one by one.

TestEnINLocale is replaced by TestHardcodedLocaleReplacements, which asserts the hardcoded/restored alias entries, normalize, and _parse_localename for that full set. Also removed the irrelevant comment on the old round-trip test.

I have made the requested changes; please review again.

[bedevere-app]

Thanks for making the requested changes!

@picnixz: please review the changes made to this pull request.

[sankalpsthakur]

Addressed the three new notes: shorter docstring with the issue link, @support.subTests for the replacements, and apply_x11_locales_patch() with a short comment on why X11 gets overridden. CLA for sankalphimself@gmail.com is still outstanding on my side.

[picnixz]

A fully-agentic PR is not accepted per our policy. AI tools can be used, but you're not meant to let them run in automode. If this happens again, we will restrict your access to our repositories.