Repository navigation
locale.windows_locale: Incorrect Windows locale for Cambodian #123853
Description
Activity
- addedtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
on Sep 9, 2024 @rruuaanng - how did you fix it? how did you test it?
@rruuaanng If this issue is valid (should be confirmed from
localeexperts, cc @malemburg), we need to send a PR with a fix, applying changes locally affects only your local git repository.- added a commit that references this issue
on Sep 9, 2024 @rruuaanng - how did you fix it? how did you test it?
I checked the results of the
windows_locale.get(int(code, 0))statement to see if it gets the corrected value now.windows_localedictionary isn't used anywhere else, so I think fixing the source of the error should be enough.17 remaining items
@@ -1596,7 +1596,8 @@ windows_locale = {
1088: "tt_RU",
1090: "uz_UZ",
1091: "ky_KG",- 1107: "kh_KH",
-
Corrected per Microsoft LCID specification:
- 1107: "km_KH",
1110: "gl_ES",
...
}
bpo-XXXX: Corrected Cambodian locale identifier (1107) to "km_KH" in locale.windows_locale
According to Microsoft's LCID specification, the correct locale code for Cambodian (LCID 1107 / 0x0453) is "km-KH". This patch updates the CPython mapping from the outdated "kh_KH" to "km_KH".
References:
cc @malemburg, @zooba
What should we do with this issue? There is the
locale.windows_localedict that maps Windows codes to locale name. It is incomplete and contains errors. Its purpose is to be used if_locale._getdefaultlocale()returns a hexadecimal code instead of the locale name on Windows, but on modern Windows (after Windows 95?) this never happens, so the dict is not used on practice._locale._getdefaultlocale()is deprecated anyway.So we can:
- Update
windows_localein accordance to fresh official data. Some names must deviate from the official Windows names for compatibility with Python implementation. - Remove
windows_localeas it is never used in the stdlib. Remove also some dead code inlocale._getdefaultlocale()and_locale._getdefaultlocale(), which are deprecated anyway. - We can also just ignore this until the deprecated
locale._getdefaultlocale()and_locale._getdefaultlocale()be deleted.
- Update
The removal is scheduled for 3.15 and the dict would normally get removed as part of this, since it would no longer be needed.
However, people are using it directly and independently from
getdefaultlocale(), so perhaps we need start a separate deprecation process for the dict removal.Until then, it's a good idea to fix entries where needed.
Reacted by Steve Dower- added a commit that references this issue
on Jan 19, 2026 cc @seanbudd
As #123853 (comment) mentioned, the windows_locale dict should be considered dead code since Windows 98. You confirmed the bug on Python 3.11 ~ 3.13, is this bug introduced by incorrect language tag returned by Win32 API?
I am proposing modern Win32 locale API migration, could you test how would that behave for your locale settings?
You can also test API behavior by this standalone program, it will display return value of different API.Note:
GlobalizationPreferences: zh-Hans-CNhappens because windows actually have two different language settings and the real widely used one is in the control panel region settings.
Update: I just found the expression included the
windows_localedictionary directly, which is proven to be dead code since Windows 98.
This can be however marked as resolved oncewindows_localeget removed in standard library.@mokurin000 - yep, the dictionary just needs to be removed and people need to use LCIDToLocaleName instead
Metadata
Metadata
Assignees
Labels
Projects
- StatusShow more project fieldsDone
Bug report
Bug description:
According to the Windows spec, the locale identifier for Cambodian (
0x0453/1107) should be "km-KH"Sources:
Currently
locale.windows_locale[1107] == "kh_KH"incorrectly.https://github.com/python/cpython/blob/3.12/Lib/locale.py#L1596
It is possible this mistake is from an older version of the protocol, but using the MS reference, the current mapping in Windows has been the case since the earliest recorded spec from
8/8/2013.If this issue is accepted I am happy to make a small PR to adjust this value.
CPython versions tested on:
3.11, 3.12, 3.13, CPython main branch
Operating systems tested on:
Windows
Linked PRs