OrchardCore: BUG: 'zh' localization directory not exist

Describe the bug

To Reproduce

Steps to reproduce the behavior:

  1. when my chrome broswer language is ‘中文(简体)’, the CurrentUICulture field value is zh,
  2. then ModularPoFileLocationProvider() can’t find the zh localization dir. because it is not existed.
  3. so the website always display en-US culture.

Expected behavior

show Chinese properly

Screenshots

image image image image image

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 98 (97 by maintainers)

Most upvoted comments

Okay interesting, and I assume you also added in the admin settings zh-Hans-CN in the supported cultures and not marked as the default culture, as you mentioned, right?

Okay but with the exact same configuration, in my case when putting a break point in the alias middleware the current culture is en-US, I can get zh if I add it to the supported cultures in the admin settings, but never zh-CN that I can’t add in the settings, so no mapping is done on my side.

Can you show your admin culture settings? Did you save them, maybe zh-CN is still in the database document. Would be good to put a breakpoint in the module startup to see what is added in the supported cultures, just try to understand how it can select a culture which is not in the supported cultures.

It will be better if someone else can confirm if this feature is working on main branch

Thanks for trusting me 😉 But even if it works for someone else, it will not magically start to work on my machine.

The Translation repository is now updated:

  • Deleted the zh-Hans-CN folder that was obsolete
  • Kept zh-CN and zh-TW just such that users who are upgrading won’t be broken and have some time to update to zh-Hans and zh-Hant. The subsequent release should get rid of these folders. We need to add this information to the release notes. And maybe have some docs explaining which languages are available to use by default, and to add in the Supported Cultures settings.
  • zh-Hans and zh-Hant are now available as NuGet packages (cloudsmith for now)

https://sites.psu.edu/symbolcodes/languages/asia/chinese/

Language Tags allow browsers and other software to process Chinese text more efficiently. Below are the recommended codes for different scripts

Chinese: zh (the most generic tag, but rarely used)
Mandarin Chinese, Simplified Script: zh-Hans is preferred, but zh-CN may be found on older sites.
Mandarin Chinese, Traditional Script: zh-Hant or zh-Hant-TW (Taiwan) is preferred zh-TW
Pinyin (Mandarin): zh-Latn-pinyin for Mandarin. If the text is not Mandarin,use one [the dialect codes below](https://sites.psu.edu/symbolcodes/languages/asia/chinese/#dialects).
Cantonese (Hong Kong): zh-HK

I added the custom languages on crowdin: https://crowdin.com/project/orchard-core/zh-hans-cn https://crowdin.com/project/orchard-core/zh-hant-tw but there is no such thing than “renaming” a culture into another one.

A mitigation is to set this ENV: DOTNET_SYSTEM_GLOBALIZATION_USENLS=1 Then the zh-CN will appear in the list.

What I see is that zh-CN is not available after .NET 5.0 and that might be the source of the problem

I notice that too

zh-Hant,zh-Hans Yes, I think these are enough, because in terms of characters, Chinese is not so much variety, it is more about pronunciation

I totally agree with @hyzx86, that’s what I mentioned earlier here

image

in my submission… All the billions of browsers in China should be zh-CN 🤣

rename the directory can resolve it, but There are same problems in macos and windows 10. so i suguest to add zh dir to OrchardCore.Translations repo, or add some codes to enhance it. (^_^)