When first browser accept-language is `zh-HK`, the default UI language is incorrect

Discourse currently has Traditional Chinese (zh_TW) and Simplified Chinese (zh_CN) localization. However when I have the browser’s accept-language set to zh-HK first, Discourse errorneously selects zh_CN as the default language.

Most users from Taiwan (zh-TW), Hong Kong (zh-HK) and Macau (zh-MO) prefer Traditional Chinese, so for these accept-language values Discourse should select zh_TW as the default language instead. (Technically you can also make use of Unicode CLDR likely subtags information, but for just Chinese it would be a bit overkill.)

I also want to point out that, having “中文” and “中文 (TW)” in the language selection is extremely weird. It really should list “简体中文” for Simplified Chinese and “正體中文” for Traditional Chinese instead.


This is definitely true. Here’s a PR to change it:

(Twitter uses 繁體 instead of 正體, so I followed them.)

Is that all that needs to change @gerhard?


To address the issue in the title, the “correct” option would be for us to use zh-Hans and zh-Hant, but the browsers are inconsistent with the options they present.





I can’t find any way in Safari to pick a language, so it must always use the system settings? That potentially includes all these options:


Documentation suggests a language code like zh-Hans_HK is possible from macOS. I do wonder if that makes it to the browser.

The Taiwanese FOSS l10n community has a preference for “正體” over “繁體”, but I’m not bothered by either.

As long as you only have two variants, the code is mostly cosmetic. Quite often when the name says “Chinese (Traditional)” the underlying code is still zh_TW. Either way you still need to handle both language-region and language-script-region variants of language tags sent by browsers. AFAIK Firefox on Android does send accept-language with zh-Hant-HK, depending on the Android system locale setting.

1 Like