Skip to content

locale.windows_locale: Incorrect Windows locale for Cambodian #123853

Description

@seanbudd

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

Activity

  1. rruuaanng commented on Sep 9, 2024

    @rruuaanng
  2. seanbudd commented on Sep 9, 2024

    @seanbudd
    Author
  3. rruuaanng commented on Sep 9, 2024

    @rruuaanng
  4. seanbudd commented on Sep 9, 2024

    @seanbudd
    Author
  5. rruuaanng commented on Sep 9, 2024

    @rruuaanng
  6. seanbudd commented on Sep 9, 2024

    @seanbudd
    Author
  7. rruuaanng commented on Sep 9, 2024

    @rruuaanng
  8. seanbudd commented on Sep 9, 2024

    @seanbudd
    Author

    @rruuaanng - how did you fix it? how did you test it?

  9. Eclips4 commented on Sep 9, 2024

    @Eclips4
    Member

    @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.

  10. added a commit that references this issue on Sep 9, 2024
  11. rruuaanng commented on Sep 9, 2024

    @rruuaanng
    Contributor

    @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.

  12. 17 remaining items

  13. Sadrita404 commented on Jul 29, 2025

    @Sadrita404

    @@ -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:

  14. serhiy-storchaka commented on Jul 29, 2025

    @serhiy-storchaka
    Member

    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.
  15. malemburg commented on Jul 29, 2025

    @malemburg
    Member

    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.

  16. added a commit that references this issue on Jan 19, 2026
  17. mokurin000 commented on Feb 12, 2026

    @mokurin000
    Contributor

    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.

    Image

    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.

  18. seanbudd commented on Feb 13, 2026

    @seanbudd
    Author

    @mokurin000 - yep, the dictionary just needs to be removed and people need to use LCIDToLocaleName instead

  19. added a commit that references this issue on Feb 27, 2026
  20. added a commit that references this issue on Feb 28, 2026
  21. added a commit that references this issue on Apr 20, 2026
  22. added 2 commits that reference this issue on Apr 25, 2026
  23. added 2 commits that reference this issue on Jun 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    OS-windowstype-bugAn unexpected behavior, bug, or error

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions