Speak a sentence in Mandarin and ask for it back as text, and a Taiwan or Hong Kong writer often gets something subtly wrong — not misheard, but written in the wrong characters. The meaning is right. The orthography belongs to somewhere else. Most speech models were trained on a corpus where simplified Chinese dominates, so simplified is what they emit by default, and a traditional-Chinese user ends up with output they would never actually type. It reads foreign the way American spelling reads foreign to a British writer, except the gap is wider and it runs deeper than spelling. This is the part of "supports Chinese" that the feature list never mentions, and it's worth understanding why it happens and what fixing it actually takes.
Simplified output is the default nobody chose
The character sets diverged by policy in the twentieth century: mainland China standardized on simplified forms, while Taiwan, Hong Kong, and Macau kept the traditional ones. Decades later, most of the digital Chinese text that speech models learn from is simplified — it's simply the larger pile. A model trained to maximize agreement with its data will therefore lean toward simplified output unless something deliberately pulls it the other way. That's not a decision anyone made on behalf of traditional-Chinese users; it's the statistical center of gravity of the training data leaking into the result.
The effect is quiet, which is why it goes unremarked. The tool didn't crash. It "did Chinese." A reviewer testing in a quiet room, reading a clean sentence, might not even notice which character set came back. But the writer in Taipei notices immediately, because 说 instead of 說 and 电脑 instead of 電腦 are the visual equivalent of receiving your own words in someone else's handwriting.
軟體 vs 软件: it's vocabulary, not just strokes
The easy mental model is that traditional and simplified are the same characters drawn with more or fewer strokes — 說 versus 说, 電 versus 电 — and that a lookup table could map one to the other. For many characters that's true. But the divergence isn't only visual; in places it's lexical. Taiwan and the mainland often reach for genuinely different words for the same modern concept.
"Software" is 軟體 in Taiwan and 软件 on the mainland — and 體 versus 件 is a different second character, not a simplified form of the same one. "Information" is 資訊 in Taiwan and 信息 on the mainland. "Network / online" leans on 網路 in Taiwan and 网络 on the mainland. A printer is 印表機 in Taiwan and 打印机 on the mainland. These aren't stroke variants; they're different vocabulary choices that happen to sit on top of the character-set split. A writer who says the Taiwanese word and gets the mainland word back hasn't received a converted version of what they said — they've received a translation into a neighboring dialect of written Chinese.
Why naive conversion afterward doesn't save you
The tempting shortcut is to let the model transcribe into simplified, then run a converter at the end to swap the characters over. It's cheap, it's a single pass, and for casual reading it looks close enough. It also quietly fails on exactly the cases that matter.
Character-by-character conversion handles the strokes but not the vocabulary. Map 软件 straight across and you get 軟件 — real traditional characters, but not the word a Taiwan writer uses; the natural form is 軟體. The one-to-one mapping also breaks where a single simplified character collapses several traditional ones: 里 covers both 里 (a unit of distance, and inside 這裡's older 裡) and 裏/裡 depending on meaning; 发 stands for both 發 (to send/emit) and 髮 (hair). Convert blindly and you'll turn "頭髮" into "頭发" or the reverse in the wrong context. The information needed to pick correctly — which meaning, which regional word — lived in the sentence, and by the time you're running a find-and-replace over finished text, that context is gone. Conversion after the fact can only guess at what a context-aware model already knew and threw away.
A modeling choice, made per user
Getting this right means deciding the target orthography before the characters are committed, not after — resolving the sounds directly into the character set and the regional vocabulary the writer actually uses. That's a property of who is speaking, so it has to be set per user: this account writes traditional Chinese, Taiwan usage; that one writes simplified. Once the system knows that, it can choose 軟體 over 軟件 over 软件 as one integrated decision, using the same sentence-level context it needs to resolve homophones in the first place. The character set stops being a post-processing step and becomes part of understanding what was said.
Sageio Type treats it that way — traditional and simplified are a per-writer setting that shapes the output the model produces, down to the vocabulary, rather than a conversion bolted on at the end or a font swapped in the display. For a Taiwan or Hong Kong writer, that's the difference between text you can send and text you have to comb through and rewrite. This is the home-turf case: a tool built with Asian languages as the starting point, not the last locale added, defaults to getting your own writing system right.
Why "supports Chinese" isn't enough
A tool can list Chinese, transcribe a clean sentence, and still hand a Taipei writer simplified characters and mainland vocabulary — output that's correct in meaning and wrong in identity. The feature list won't warn you; it says "Chinese" and stops. One real session will tell you what the list won't. Dictate a few sentences the way you'd write them, with the terms you actually use — 軟體, 資訊, 網路 — and read what comes back. Is it your written Chinese, or a converted approximation of it? That question, not the language count, is what separates a tool that supports Chinese from one that supports yours. You can see how we think about it at sageio.net/type.