Repository navigation
locale.windows_locale: Incorrect Windows locale for Cambodian #123853
Description
Bug report
Bug description:
According to the Windows spec, the locale identifier for Cambodian (0x0453/1107) should be "km-KH"
Sources:
- https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-lcid/70feba9f-294e-491e-b6eb-56532684c37f
- https://ss64.com/locale.html
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
- gh-123853: Corrected Cambodian language locale identifier #123855
- gh-123853: Update locale.windows_locale #123901
- gh-123853: Cleanup Windows 95 locale fallback support #144738
- [3.14] gh-123853: Update locale.windows_locale (GH-123901) #148876
- [3.13] gh-123853: Update locale.windows_locale (GH-123901) #148877
Activity
rruuaanng commentedon Sep 9, 2024
seanbudd commentedon Sep 9, 2024
rruuaanng commentedon Sep 9, 2024
seanbudd commentedon Sep 9, 2024
rruuaanng commentedon Sep 9, 2024
seanbudd commentedon Sep 9, 2024
rruuaanng commentedon Sep 9, 2024
seanbudd commentedon Sep 9, 2024
@rruuaanng - how did you fix it? how did you test it?
Eclips4 commentedon Sep 9, 2024
@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.pythongh-123853: fixed the locale identifier for Khmer
rruuaanng commentedon Sep 9, 2024
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
Sadrita404 commentedon Jul 29, 2025
@@ -1596,7 +1596,8 @@ windows_locale = {
1088: "tt_RU",
1090: "uz_UZ",
1091: "ky_KG",
Corrected per Microsoft LCID specification:
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 commentedon Jul 29, 2025
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:
windows_localein accordance to fresh official data. Some names must deviate from the official Windows names for compatibility with Python implementation.windows_localeas it is never used in the stdlib. Remove also some dead code inlocale._getdefaultlocale()and_locale._getdefaultlocale(), which are deprecated anyway.locale._getdefaultlocale()and_locale._getdefaultlocale()be deleted.malemburg commentedon 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.
document support for cambodian #19450
mokurin000 commentedon 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.
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 once
windows_localeget removed in standard library.seanbudd commentedon Feb 13, 2026
@mokurin000 - yep, the dictionary just needs to be removed and people need to use LCIDToLocaleName instead
pythongh-123853: Cleanup Windows 95 locale fallback support (python#1…
pythongh-123853: Cleanup Windows 95 locale fallback support (python#1…
gh-123853: Update locale.windows_locale (GH-123901)
pythongh-123853: Cleanup Windows 95 locale fallback support (python#1…
pythongh-123853: Update locale.windows_locale (pythonGH-123901)
[3.14] gh-123853: Update locale.windows_locale (GH-123901) (GH-148876)
[3.13] gh-123853: Update locale.windows_locale (GH-123901) (GH-148877)