As I understand there are basically three variants of Chinese, that are represented as IETF language tags (RFC1766) by the country where they are primarily used:

  • zh-CN = Simplified script with Mandarin grammar = Chinese as written in China
  • zh-TW = Traditional script with Mandarin grammar = Chinese as written in Taiwan
  • zh-HK = Traditional script with Cantonese grammar = Chinese as written in Hong Kong

On a website, when we don't have any of the preferred languages of the user's browser (Accept-Language), we usually fall back to the first primary language that we have and then to English.

For example, if the visitor wants pt-PT, but we only have pt-BR, we would use pt-BR. If we don't have any Portuguese, we would use English for the that visitor.

Now, what would be the fallback order for the Chinese languages? Or are they so different that it makes more sense to fall back to English when we don't have the requested variant?

  • 4
    I'm voting to close this question as off-topic because it will be better answered on Chinese.SE. While it's definitely related to UX, the answer requires knowledge of Chinese languages and culture more than it does UX knowledge. Feb 2 '15 at 8:08
  • 2
    @VitalyMijiritsky It might be a better fit on Chinese (debatable), but it doesn't appear to be off-topic on UX according to my interpretation of the help center, and therefore should not be a candidate for migration. Feb 2 '15 at 10:02
  • 1
    @200_success Let's put it this way - there's nothing in my UX skill set that could help me answer this question. I'm not saying that I'm the measure for what is UX or that I should be able to answer any question on the site, but usually when I can't answer a question, it's because I'm lacking professional knowledge. Here I'm just lacking a knowledge of Chinese realities. A Chinese person with no knowledge of UX is better qualified to answer this than a UX person who doesn't know anything about China. Feb 2 '15 at 12:11
  • If the grammar is really the same in CN and TW, it should be possible to transliterate texts server-side between Hans and Hant, and vice versa. So it boils down to Mandarin vs. Cantonese, possibly English or another language.
    – Crissov
    Feb 2 '15 at 16:17
  • @Crissov The character mapping is not one-to-one. For example, traditional characters 隻 and 只 both map to the simplified character 只 (based on the fact that they are homophones in Mandarin). Therefore, transliteration is non-trivial. Feb 2 '15 at 16:43

Serving Simplified Chinese to a user who has requested only Traditional Chinese, or vice versa, is a cultural faux pas. The two character repertoires, though mostly mutually intelligible with some mental effort or explicit learning, aren't similar enough to be freely interchangeable.

A typical Hong Kong user, for example, is more likely to be comfortable with English as a fallback than with Simplified Chinese. English is taught in Hong Kong schools. Mandarin instruction, though common, would not necessarily be done using simplified characters. Hong Kong users who prefer Simplified Chinese as a fallback would likely have configured their browsers with zh-HK, followed by zh-CN, followed by en. That said, serving Traditional Chinese text that was written for a Taiwanese audience would be quite acceptable.

Specifically, if you have Simplified Chinese and English versions of a text available, and a request comes in with Accept-Language: zh-HK, en, the only reasonable action is to serve the English version. If a request comes in with just Accept-Language: zh-HK, then I would consider both versions to be equally foreign; whether serving the Simplified Chinese version or the English version is better is a matter of opinion.

Likewise, for a client whose only configured language preference is zh-TW, I suggest choosing English as a fallback over Simplified Chinese. Again, a user who is comfortable with reading Simplified Chinese would likely have configured zh-CN as a fallback. For you to choose Simplified Chinese even when not requested might be perceived as a political statement. Whether or not it is acceptable to serve zh-HK content to a Taiwanese reader depends on the register in which the text is written. In general, it should be fine. However, if the text is more of a transcription of colloquial Cantonese rather than in the standard written register, then a Taiwanese reader would likely not be able to make any sense of it.

The same guideline should hold for Mainland Chinese audiences as well. General education is done entirely in Simplified Chinese, so I wouldn't expect any familiarity with reading Traditional Chinese.

  • "would likely have configured their browsers" most people don't waste their time configuring their browser settings to exactly match their preferences.
    – Boris
    Feb 14 '20 at 21:03

There are (at least) two feasible alternatives:

  1. Send back a 406 Not Acceptable response with, as suggested, “a payload containing a list of available representation characteristics and corresponding resource identifiers from which the user or user agent can choose the one most appropriate”, like a list of alternatives in the available language forms.

  2. Silently map zh-TW and zh-HK to each other (they are actually forms of Chinese as used in two different territories, both using so-called traditional forms of characters) when needed and otherwise any of zh-... to the available alternative.

Alternative 1 might be favored on the basis of “least surprise” and “least potential offense”. It also lets a user select English when he finds that more suitable than an unfamiliar (to him) written form of his preferred language.

In general, when the user agent requests for zh or zh-... without including any designation for English, you should not assume that the user knows English at all

P.S. RFC 1766 was obsoleted in 2001 by RFC 3066, which was obsoleted in 2006 by RFC 4646 and RFC 4647. RFC 4646 was obsoleted 2009 by RFC 5646, Tags for Identifying Languages. Use http://www.rfc-editor.org to check the status of RFCs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.