Skip to content

Keep the script when negotiate_locale falls back - #1434

Open
b84330808 wants to merge 1 commit into
python-babel:masterfrom
b84330808:fix-negotiate-locale-script-fallback
Open

b84330808 wants to merge 1 commit into
python-babel:masterfrom
b84330808:fix-negotiate-locale-script-fallback

Conversation

@b84330808

Copy link
Copy Markdown

When a preferred locale isn't available, negotiate_locale only tries its first subtag, so a three-part identifier can't match on language + script:

>>> negotiate_locale(['zh_Hant_TW'], ['zh', 'zh_Hant'])
'zh'        # Simplified, though zh_Hant is available
>>> negotiate_locale(['sr_Latn_RS'], ['sr', 'sr_Latn'])
'sr'        # Cyrillic
>>> negotiate_locale(['zh_Hant_TW'], ['zh_Hant'])
None

This drops subtags from the end one at a time instead (the RFC 4647 lookup order). Two-part identifiers behave as before.

When a preferred locale wasn't available, negotiate_locale only tried its
first subtag, so a three-part identifier could never match on language and
script. With ['zh', 'zh_Hant'] available, zh_Hant_TW resolved to zh
(Simplified), sr_Latn_RS with ['sr', 'sr_Latn'] resolved to sr (Cyrillic),
and zh_Hant_TW with only ['zh_Hant'] didn't match at all.

Drop subtags from the end one at a time instead, which is the RFC 4647
lookup order.
@akx

akx commented Nov 6, 2026

Copy link
Copy Markdown
Member

Is this an actual issue you ran into?

@b84330808

Copy link
Copy Markdown
Author

No, not in a real app. It came up while trying identifiers with a script subtag: zh_Hant_TW picking zh over an available zh_Hant looked wrong. Browsers mostly send zh-TW, which this doesn't touch, so I can't say how often it bites in practice. Happy to close it if it isn't worth the change.

This branch has not been deployed

No deployments
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.

2 participants