I once produced a Traditional Chinese version of a Simplified Chinese corporate site for a client in Taiwan. The first pass dropped the whole site copy into a character-by-character mapping table. The result: "hair" came out with the wrong traditional character for hair, "noodles" got the character for face, and "cadre" happened to land on the right one by luck. The client sent screenshots of three spots and said it read like machine translation. That round cost me three days of rework: the copy held more than 4,300 strings, and over 200 of them needed a human decision about which character to use. Only then did I understand: the hard part of Simplified-Traditional conversion is not how glyphs map, but that one simplified character often stands for several different traditional sources, and only context can pick between them.
1. Why one-to-many mapping is bound to fail
Simplification merged several distinct traditional characters into one simplified character, so reversing it has no unique solution:
| Shared simplified form | Possible traditional characters | Split by context |
|---|---|---|
| fā (one character) | fā (to issue) / fà (hair) | fāzhǎn (development); tóufa (hair) |
| hòu (one character) | hòu (after) / hòu (empress) | hòumiàn (behind); huánghòu (empress, unchanged) |
| gān / gàn (one character) | gàn (to do) / gān (dry) / gān (to interfere) | gànhuó (to work); gānzào (dry); gānyù (to interfere) |
| miàn (one character) | miàn (face) / miàn (noodles) | qiánmiàn (front); miàntiáo (noodles; the variant form is normalized to the standard character, but the tool in Hong Kong mode returns the variant) |
| tái (one character) | tái (platform) / tái (table) / tái (typhoon) | Táiwān (Taiwan, also seen written with the plain form); táifēng (typhoon); bātái (bar counter) |
A character-level mapping can only pick one candidate for these characters, so a batch of errors is guaranteed. What actually keeps the error rate down is a word-level dictionary: a word like tóufa is matched as a whole to the corresponding traditional word, and fāzhǎn behaves the same way, decided by context rather than by the single character. That is why I stopped writing my own replacement table and moved to a solution built on the OpenCC lexicon.
The correspondences are not my own guess: the list of one-to-many cases follows the General List of Simplified Characters (reissued in 1986), and Annex 1 of the Table of General Standard Chinese Characters (2013), the comparison table of standard, traditional and variant forms, gives the correspondences between standard characters, traditional characters and variants. I checked my glossary against both tables; machine output is only a suggestion.
2. Traditional Chinese is not internally uniform
Copy for Taiwan and copy for Hong Kong do not use the same characters or the same words. Taiwan usage prefers ruǎntǐ and wǎnglù where Hong Kong writes ruǎnjiàn and wǎngluò; that is a vocabulary difference, not something you get by swapping one character for another. So I now produce two passes: a generic Traditional version first, then a rerun in Taiwan or Hong Kong mode depending on the destination, and finally I use one as the reference and proof the other against it to unify any mixed usage.
3. My actual workflow
- Export the Simplified source and isolate what must not change: code snippets, variable names, URLs, email addresses, product model numbers. Any of these breaks once it goes through conversion, so I replace them with placeholders first and paste them back afterwards.
- Paste the whole block into Chinese Converter and choose direction and regional mode. Which modes are offered (generic Traditional, Taiwan standard, Hong Kong Traditional) depends on what the tool page actually shows. Long text does not need splitting, but after conversion I always check line count and character count once.
- Put the result and the source side by side in a diff and look only at lines containing the problematic characters, the ones that map to fā or fà, hòu, gàn or gān, miàn, lǐ and tái, confirming each line.
- Keep proper nouns in a separate table: personal names, place names, brands, original titles. None of these are left to the machine. The word for empress must not be touched, for example, and whether tái in a place or institution name should be written as the formal Táiwān depends on the client's character standard; a human has to sign it off and add it to the glossary for reuse.
- Before sending, check terminology consistency against the client's sample: the same document must not contain both yǐngpiàn and shìpín for a film, or both ruǎntǐ and ruǎnjiàn for software.
4. My review checklist and what it costs
After the three days of rework, I broke the review down from "read it through" into several fixed actions with definite counts; otherwise the job never gets done:
| Check item | Volume in that version | How I handled it |
|---|---|---|
| Lines containing the problem characters | 186 lines | Read line by line, judging only whether the character choice was right |
| Personal names, place names, brands, original titles | 41 items | Written into the glossary, no machine involvement |
| Punctuation (quotes, title marks, enumeration commas) | About 200 places | Normalized once to the destination region's conventions |
| UI microcopy (overflow risk) | 55 strings | Screenshotted the interface after conversion and compared |
| Code, variables, URL placeholders | 12 blocks | Verified before and after that each one was unchanged |
Putting that table together the first time took me most of a day. The second time, the same client's incremental copy was only about 200 lines to review, the glossary could be reused directly, and the cost dropped at once.
5. Details that are easy to miss
- Traditional to Simplified is mostly lossless, but not entirely: the many-to-one direction is indeed much safer, yet the pairs behind zhu and zhe, chou, yu, liao and jie, plus characters like wàn that have only one simplified counterpart, still need word-level judgement. OpenCC keeps a dedicated word layer in that direction for exactly these. My approach is a full-text spot check on those characters, not a blanket pass.
- The real cause of layout overflow: Simplified and Traditional are both full-width, one character wide, so the metrics of a single glyph do not change. Overflow comes from word length: jìyìtǐ for memory is one character longer than the two-character mainland form, zīliào is the usual Hong Kong and Taiwan word where the mainland says shùjù, and sìfúqì is the Taiwan word where the mainland says fúwùqì. Fixed-width buttons and tabs are the first to break.
- Spell out the subtitle unit first: I count by cue. A 45-minute episode is roughly 900 cues, which as .srt is 900×3 = 2700 lines (one index line, one time line and one text line per cue). The 1800 index and time lines are pure numbers and conversion leaves them alone, so they can be set aside; the remaining 900 text lines still need a cue-by-cue check for a whole line being replaced or a timecode shifting. Sampling 10 lines is enough to check format, not enough to check characters.
- Mixing variant forms: two spellings in one document and the reader immediately senses something unprofessional. After conversion, unifying the wording takes longer than the conversion itself.
- Classical texts and poetry: these have many obscure correspondences, plus naming taboos and phonetic loan characters, so machine output has to be checked sentence by sentence.
- How to find mixed usage: a half-edited document often contains both spellings at once, and reading it through misses them easily. I align both regional versions against the same Simplified source and look only at the lines that differ, which is much faster than reading character by character.
- Keep sensitive material local: client lists and contract text never go through any backend. That is a precondition when I choose a tool.
6. Common questions
Q: Does conversion make mistakes, and can I publish the output directly?
I have not run statistics, so this is only a qualitative judgement: news and explanatory text of the ordinary kind has few obvious wrong characters, but one-to-many cases and regional vocabulary always leave residual errors. In that 4,300-string job, over 200 spots needed a human decision, concentrated on the handful of problem characters. Anything going public with a client reading it must go through a human review; internal reference material can be used as is.
Q: Does it destroy the original line breaks and paragraphs?
Judge by what the tool page actually outputs; I will not guarantee it on its behalf. My own method is to compare line counts after conversion. The only time those 4,300 strings ran together was when I pasted the wrong source file, not because of the conversion.
Q: Can I produce Taiwan and Hong Kong versions at the same time?
I run it twice, choosing the matching regional mode each time, then diff the two results and turn the differences into a glossary. How many options exist depends on what the page shows; when one document has to serve both regions, that table can be reused next time and gets shorter with use.
Q: Can I also get pinyin or zhuyin?
It handles glyphs and wording only, not pronunciation. For pinyin you need a Chinese-to-pinyin tool.
Q: Will a very long text get truncated?
I have run a whole manual in one pass without a problem, but the safer method is chapter by chapter, with a character-count check at the end so that a missing block cannot go unnoticed.
What those three days of rework taught me: the cost of Simplified-Traditional conversion is not in the conversion but in knowing which spots to review. List the characters that go wrong easily, manage proper nouns separately, and two rounds are enough to converge. Leave the other ninety percent, the mechanical replacement that follows formatting rules, to a program; a human only handles the less than ten percent that depends on context. Once the division of labour is right, this kind of job no longer takes three days.