Simplified vs traditional Chinese: two localization targets, not one

'Add Chinese' is not a complete instruction. Written Chinese exists in two current forms — simplified and traditional characters — and shipping only one, or treating them as a single language entry with a machine conversion between them, causes problems that surface late and are expensive to unwind. This is not two dialects of one language in the everyday sense of the word; it is two character sets built on the same underlying language, and your localization pipeline needs to treat them as two distinct targets from the start.

Two character sets, not two languages

Simplified characters (jiantizi) reduce the stroke count of many traditional characters and are the standard writing system used in mainland China and Singapore. Traditional characters (fantizi) retain the historical, higher-stroke-count forms and are the standard in Taiwan, Hong Kong, and Macau. The underlying spoken language associated with each varies by region — Mandarin is standard in mainland China and Taiwan, Cantonese is widely used alongside standard written Chinese in Hong Kong — but the simplified/traditional distinction is about the writing system, independent of which spoken variety a reader uses.

Many characters are identical or near-identical between the two sets, which is exactly what makes the difference easy to underestimate. A meaningful proportion of common characters differ, sometimes drastically, and a text that mixes the two within one line reads as visibly wrong to a native reader — the way mixing two alphabets mid-word would in a Latin script.

Why the script subtag matters more than the region code

It is tempting to key your locale files by country — zh-CN for mainland China, zh-TW for Taiwan — and let region imply script. This works most of the time but is the wrong axis: the actual distinguishing property is the script, not the country. The correct approach is to tag content by script subtag (zh-Hans for simplified, zh-Hant for traditional) and treat region as a separate, optional refinement layered on top for regional vocabulary or formatting differences, not as a stand-in for script.

Getting this backwards causes real bugs: a locale system keyed purely on region cannot express 'traditional Chinese for a Hong Kong audience' versus 'traditional Chinese for a Taiwan audience' as variants of the same script, and cannot cleanly represent a simplified-script community outside mainland China without an awkward region choice.

Machine conversion is not a substitute for translation into both

Tools exist that mechanically convert simplified text to traditional and back, character by character. This is useful for quick previews but unreliable as a production pipeline for two reasons. First, some conversions are one-to-many or ambiguous: a single simplified character can correspond to different traditional characters depending on meaning, and a naive converter picks one mapping regardless of context, producing wrong characters in specific words. Second, and more consequential for a game, vocabulary and terminology genuinely differ between the regions that use each script — technical terms, everyday words, and even game-genre terminology are not always shared, so a character-level conversion can produce text that is script-correct but reads as translated-from-the-wrong-region to a native player.

Font requirements are not interchangeable either

A font with full simplified-character coverage does not necessarily include the traditional forms it did not simplify from, and vice versa — font glyph sets are frequently built and licensed separately for each script. Confirm coverage for the specific script you are shipping rather than assuming one CJK font file handles both; missing glyphs render as a fallback box or trigger a silent font substitution with different metrics.

Treat them as separate localization targets

The practical conclusion: simplified and traditional Chinese should be planned, budgeted, translated, and QA'd as two separate localization targets, not one language with an automated variant. A short checklist for a project adding Chinese support:

• Decide up front whether you are shipping simplified, traditional, or both — do not default to 'Chinese' as a single line item
• Tag content by script (Hans/Hant), and treat region as a separate, optional layer on top
• Translate each script from source, or have a native editor pass over any machine-converted text before it ships
• Verify font glyph coverage separately for each script you ship
• QA each script independently — a bug fixed in one does not imply it is fixed in the other