You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[l10n] Couple of names are not consistent with ISO-639-1 code names #32288
kzKZ, do not match "kkKZ" since that is logical with ISO-639-1 codes "kk-KZ" (they are bilingual, so "ru-KZ" exist also)
khKH, Cambodia, change to name: "kmKH", ISO code: "km-KH"
A tricker one is:
srSR, Serbian (sr), you could go by srRS (Republic of Serbia, hence "RS"), but they have both the Latin and the Cyrillic alphabet and in the translation, done in the code, is in Latin. Wikipedia says that Latin is more popular in Serbia, but both are likely important. So naming could be something along the line used in e.g. https://tiagodanin.com/Locale-Codes/: "sr-Latn-RS" => srLatnRS. Or perhaps use their LSID code, srRS2074, linux/ubuntu list it as sr_RS@latin.
Then there is srME, serbian Montenegro, which also has Cyrillic and Latin. The little text that exist, likely covers also Montenegro, but that is only a guess, and I hope I don't offend anyone by my ignorance.
In these examples the names don't really match ISO-639-1 codes and for different reasons. ISO-639-1 is still used and works along with the other locale ISO standards.
Context 🔦
Code works with above name. It is more of an inconvenience. An application that uses many locales and switching to e.g. Kazak, the app developer needs to convert the locale name used in their environment (java, C#, etc) and now the only way is to "translate" the code to the name used in mui. Of course, the app developer(s) need to know the locales supported by MUI.
TL;TD
I'm whining... I'm currently working with adaption of mui v4, and mui v5's locales are up-to-date, I figured a translator function to port it back to mui v4 is logical. While I documented these I wanted to handle these locales more automatically, hence found these discrepancies, since these 3 could not be looked up using https://tiagodanin.com/Locale-Codes/, then I looked and tried to find them in the standards.
changed the title [-]locale - couple of names is not consistent with ISO-639-1 code names, then Serbian...[/-][+][l10n] Couple of names are not consistent with ISO-639-1 code names[/+]on Apr 14, 2022
Thanks for reporting this. Would you like to prepare a PR with the fixes you proposed?
As for the Serbian language, I suppose we could go with srRS. It is unlikely we will support the Cyrillic variant, as Serbian is not popular enough (see the note at the bottom of https://mui.com/material-ui/guides/localization/#supported-locales).
This issue has been closed. If you have a similar problem but not exactly the same, please open a new issue.
Now, if you have additional information related to this issue or things that could help future readers, feel free to leave a comment.
@erik-d Thanks again for creating this issue! If you have a moment, we would love to hear your thoughts on how we handled it with this short feedback form.
Activity
[-]locale - couple of names is not consistent with ISO-639-1 code names, then Serbian...[/-][+][l10n] Couple of names are not consistent with ISO-639-1 code names[/+]michaldudak commentedon Jun 1, 2022
Thanks for reporting this. Would you like to prepare a PR with the fixes you proposed?
As for the Serbian language, I suppose we could go with srRS. It is unlikely we will support the Cyrillic variant, as Serbian is not popular enough (see the note at the bottom of https://mui.com/material-ui/guides/localization/#supported-locales).
cc @oliviertassinari
oliviertassinari commentedon Jun 1, 2022
TODO:
ZeeshanTamboli commentedon Oct 28, 2026
This should be fixed in MUI X repo. Material UI already uses mkMK. MUI X pickers still ship
mk.ts.github-actions commentedon Oct 28, 2026
This issue has been closed. If you have a similar problem but not exactly the same, please open a new issue.
Now, if you have additional information related to this issue or things that could help future readers, feel free to leave a comment.
@erik-d Thanks again for creating this issue! If you have a moment, we would love to hear your thoughts on how we handled it with this short feedback form.