GeezerVison is showing github.com — `locale.windows_locale`: Incorrect Windows locale for Cambodian · Issue #123853 · python/cpython
locale.windows_locale: Incorrect Windows locale for Cambodian #123853
DescriptionBug 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
Activityrruuaanng commented on Sep 9, 2024 seanbudd commented on Sep 9, 2024 Author show commentMore actions rruuaanng commented on Sep 9, 2024 seanbudd commented on Sep 9, 2024 Author show commentMore actions rruuaanng commented on Sep 9, 2024 seanbudd commented on Sep 9, 2024 Author show commentMore actions rruuaanng commented on Sep 9, 2024 seanbudd commented on Sep 9, 2024 @rruuaanng - how did you fix it? how did you test it? Eclips4 commented on Sep 9, 2024 @rruuaanng If this issue is valid (should be confirmed from locale experts, cc @malemburg), we need to send a PR with a fix, applying changes locally affects only your local git repository. rruuaanng commented 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_locale dictionary isn't used anywhere else, so I think fixing the source of the error should be enough.
Sadrita404 commented on Jul 29, 2025 @@ -1596,7 +1596,8 @@ windows_locale = {
1088: "tt_RU",
1090: "uz_UZ",
1091: "ky_KG",
-
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:
serhiy-storchaka commented on Jul 29, 2025 cc @malemburg, @zooba
What should we do with this issue? There is the locale.windows_locale dict 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_locale in accordance to fresh official data. Some names must deviate from the official Windows names for compatibility with Python implementation.
- Remove
windows_locale as it is never used in the stdlib. Remove also some dead code in locale._getdefaultlocale() and _locale._getdefaultlocale(), which are deprecated anyway.
- We can also just ignore this until the deprecated
locale._getdefaultlocale() and _locale._getdefaultlocale() be deleted.
malemburg commented on Jul 29, 2025 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. mokurin000 commented on Feb 12, 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-CN happens 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_locale dictionary directly, which is proven to be dead code since Windows 98.
This can be however marked as resolved once windows_locale get removed in standard library. seanbudd commented on Feb 13, 2026
MetadataMetadataStatusShow more project fields
DevelopmentNo branches or pull requestsIssue actions
|
