What is the difference between zh-Hans and zh-Hant?

zh-Hans is Simplified Chinese, used in mainland China; zh-Hant is Traditional Chinese, used in Taiwan. They use different character sets (for example 电 vs 電), so one cannot be rendered from the other by changing fonts. Vocabulary also diverges by region — mainland writes 软件 for software while Taiwan writes 軟體. strings.dev treats them, plus zh-HK (Traditional, Hong Kong), as three separate locales.

Do I need Simplified, Traditional, and Hong Kong Chinese all at once?

No. Many apps start with zh-Hans for the mainland market, then add zh-Hant (Taiwan) and zh-HK. Because these are distinct locales with different scripts and some different vocabulary, ship the ones your users actually use rather than collapsing them into one generic Chinese file, which would look foreign to at least one audience.

How many plural forms does Chinese have?

One. Chinese uses only the CLDR 'other' plural category — there is no singular/plural noun inflection, so '1 message' and '9 messages' use identical wording. On Android your element needs a single item with quantity="other"; a String Catalog variation for Chinese likewise only needs the other case. Counted nouns do, however, require a measure word (classifier) between the number and the noun, such as 条 before 消息.

Will my %@ and %lld placeholders survive Chinese translation?

Yes. strings.dev preserves iOS placeholders (%@, %lld, %1$@) and Android placeholders (%s, %d, %1$s) as literal ASCII tokens, even when they sit next to full-width Chinese punctuation like ，！。 It also protects brand phrases, URLs, emails, handles, and proper nouns while translating the surrounding text.

Does strings.dev localize my App Store listing for China, Taiwan, and Hong Kong?

No. strings.dev localizes your in-app native strings only — .xcloc / .xcstrings on iOS and strings.xml on Android. The App Store and Play Store run separate storefronts for mainland China, Taiwan, and Hong Kong with their own metadata, but translating those store listings and screenshots is a separate workflow you handle yourself.

Translate Your App to Chinese: Simplified (zh-Hans) vs Traditional (zh-Hant/HK)

By The strings.dev team · Last updated 2026-07-17

Translating your app to Chinese is really a choice among three locales, not one. Simplified (zh-Hans) for the mainland, Traditional (zh-Hant) for Taiwan, and zh-HK for Hong Kong differ in actual characters and some vocabulary — collapsing them into a single "Chinese" file is the fastest way to look foreign to two of the three audiences.

This page covers what changes between Simplified and Traditional, how Chinese text compresses your UI toward half its English width, and how placeholders and measure words behave — with a real before/after string.

"Chinese" is not one locale — it's three

Pick "Chinese" in a generic BYO-key translation utility and you get one file. That is the single most expensive mistake in a Chinese launch, because a mainland reader and a Taiwan reader do not read the same script, and a Hong Kong reader reads Traditional characters with mainland-leaning vocabulary. strings.dev ships these as three first-class locales:

zh-Hans — Simplified script, mainland China (Android values-b+zh+Hans, legacy values-zh-rCN)
zh-Hant — Traditional script, Taiwan (values-b+zh+Hant, legacy values-zh-rTW)
zh-HK — Traditional script, Hong Kong; Apple language ID zh-HK, BCP-47 zh-Hant-HK

Full code mappings live in the locale codes reference.

It's characters and words, not a font

Simplified and Traditional are different character sets — 电 vs 電, 门 vs 門 — so you cannot render one from the other by swapping a typeface. On top of the script split, everyday tech vocabulary diverges between regions:

English	zh-Hans (mainland)	zh-Hant (Taiwan)	zh-HK (Hong Kong)
software	软件	軟體	軟件
network	网络	網路	網絡
information	信息	資訊	資訊
video	视频	影片	影片

A Taiwan user who sees 软件 (mainland "software") reads it as foreign, the same way a British user clocks "color." That is exactly why collapsing to one "Chinese" file undercuts the localization you paid for — the script is only half of it.

A real string: placeholder intact, half the width

Here is an iOS source string and its actual Simplified translation. The %@ and %lld tokens survive unchanged, surrounded by full-width Chinese punctuation (，！。):

// English source — Base.lproj
"inbox_summary" = "Welcome back, %@! You have %lld new messages.";

// Simplified Chinese — zh-Hans.lproj
"inbox_summary" = "欢迎回来，%@！您有 %lld 条新消息。";

Strip the placeholders and the 44-character English string collapses to just 10 Han characters (欢迎回来 · 您有 · 条 · 新消息). Raw glyph count makes that look like ~75% shorter, but each Han character renders full-width — roughly two Latin characters wide — so the translated line still lands at about 40–50% of the English pixel width. That width compression is typical of CJK text and is the layout fact that bites indie apps. strings.dev keeps %@, %lld, %1$@ (and Android %s, %d, %1$s) as literal ASCII tokens even when they are wedged between full-width characters — a spot where naive machine translation loves to widen %@ into full-width ％＠ and crash your formatter.

Measure words and a single plural

Two Chinese-specific rules change how your count strings translate:

One plural category. Chinese has only the CLDR other form — there is no singular/plural inflection. "1 message" and "9 messages" use the identical noun. On Android your <plurals> needs just one <item quantity="other">; on iOS a String Catalog variation for Chinese only needs the other case. No one/few/many scaffolding to fill in.
Classifiers (量词). A counted noun takes a measure word between the number and the noun. In the string above, %lld 条新消息 uses 条 (tiáo), the classifier for messages; Taiwan would write %lld 則新訊息, with a different classifier and a different word for "message." A translator that drops the classifier produces text that reads as broken to a native speaker — so the count word matters as much as the number itself.

Design for compression before you translate

Because Chinese renders so much narrower, UI sized for English looks under-filled: a button labeled 保存 (Save) floats in a box built for eight Latin characters. Two practical moves before you localize:

Let containers shrink-to-fit or center short CJK labels instead of hard-coding widths.
Raise your minimum font size for Chinese — dense strokes at 11pt turn to mud where the same size reads fine in Latin. Chinese also has no spaces between words and wraps per-character, so line-break logic tuned for spaces behaves differently.

Feed your app description into strings.dev as context and the model disambiguates terms that are wrong out of context — 应用 (app) vs 申请 (application form), 主页 (home screen) vs 首页 (website home page) — instead of coin-flipping.

Storefronts are separate — and advisory

The App Store and Play Store treat mainland China, Taiwan, and Hong Kong as distinct storefronts with their own metadata slots. That is useful context for planning which of the three locales to ship first, but store listings are a separate surface: strings.dev localizes your in-app .xcloc / .xcstrings and strings.xml only. Store titles, descriptions, and screenshots stay your own workflow.

Adding Chinese to your app

The free Indie tier covers 1 project and 1 language with unlimited words. Your first language — say zh-Hans — is free. Because Simplified, Traditional, and Hong Kong are three separate locales, shipping the full Chinese matrix means going past that one free language: Indie Plus unlocks unlimited languages, 2 projects, brand context, and the QA dashboard for $20/mo, or $10/mo billed annually (pricing). Upload your existing export, pick the zh variants you need, and get native files back in the same format.