Chinese Character Sets Are Not a Binary Problem
The simplification of Chinese characters happened in the 1950s and 1960s in mainland China. It was a deliberate policy decision, not an organic linguistic drift. Taiwan, Hong Kong, and Macau kept the traditional forms. That is the simple version. The complicated part is that zh-cn and zh-tw are locale identifiers, not just character sets. They affect sorting order, date formats, input method behavior, and font fallback chains. If you are building software that handles both, treating this as a conversion problem will break things quietly. Here is what the conversion actually looks like under the hood. Take the character . In simplified it is one glyph. In traditional it is , which has a completely different radical structure. A lookup table maps roughly 2,200 simplified characters to their traditional equivalents. But the mapping is not one-to-one. The character can mean "empress" in traditional form, or it can be a simplification of , which means "behind" or "after." Context determines which traditional character to output. Most naive scripts just do a blind character swap and produce text that native readers find jarring or outright wrong. I ran into this exact problem last year when a client asked me to generate Traditional Chinese PDF invoices for a Taiwan distribution partner. The system was doing a straightforward simplified-to-traditional character swap. The invoice came back with the word meanin g "empress" appearing everywhere instead of for "after payment due date." I ended up writing a small context-aware disambiguation layer that checked bigram frequency against a Taiwan language corpus and applied corrections before the swap. It added about four seconds to the generation time but eliminated the error rate entirely.
Font handling is where most people get burned. A zh-cn locale will load fonts like Microsoft YaHei or Source Han Sans CN by default. A zh-tw system expects fonts like MingLiU or Source Han Sans TW. The glyphs look nearly identical for the common characters. They diverge on rare characters, variant forms, and specific stroke details. The real issue is that some glyphs are present in one font subset and missing in another. I had a dashboard application that rendered fine on a mainland Chinese test machine and then showed tofu boxes on a Taiwan deployment because the Traditional Chinese font build simply did not include certain CJK extension B characters. The workaround was bundling Source Han Sans in its complete multi-script form instead of relying on the OS default. Sorting and collation is another area that gets ignored until it breaks production. zh-cn uses the Pinyin-based collation order by default in most operating systems and databases. zh-tw uses the Bopomofo-based order, which is essentially the same as Zhuyin. These orders are different. If you have an application that sorts user names or product listings and you switch locales without updating the collation rules, the sort order changes silently. Database indexes become invalid for the new sort pattern. I spent two days tracking down why a search results page was returning inconsistent ordering after we enabled the Taiwan locale. The fix was explicitly setting the collation sequence at the query level rather than relying on the session default.
Practical Approaches for Handling Both Locales
If you need to support both zh-cn and zh-tw in a single application, here is what actually works in practice. Store your data in Unicode throughout. Do not convert at rest. Convert only at the output layer based on the user locale. This means keeping simplified characters in your database if that is what the input was, and converting on the way out. It also means your content team needs to understand which variant they are creating for. Mixed-content databases are a maintenance nightmare and I would recommend avoiding them unless there is a hard constraint forcing that structure. For conversion, use a proper library rather than a manual lookup table. Libraries like OpenCC handle the context-aware disambiguation that a simple character swap misses. It is open source and widely used. The tradeoff is that it is not perfect. There are edge cases where even OpenCC picks the wrong variant, especially with domain-specific terminology or proper nouns. I always run a post-conversion check against a targeted vocabulary list for the specific domain. That catches the majority of errors before they reach the user. Font strategy depends on your delivery method. For web applications, serve a font that covers both character sets. Source Han Sans, Noto Sans CJK, and PingFang all include both simplified and traditional glyphs in a single font file with the appropriate weight and style. This eliminates the fallback problem entirely. For desktop or mobile applications, bundle the fonts explicitly rather than relying on system defaults. System fonts vary too much across device regions and versions.
Get the Full Details
Date, number, and currency formatting should be handled by locale-aware libraries. The zh-cn locale uses the Gregorian calendar with year-month-day ordering and comma thousands separators. The zh-tw locale also uses the Gregorian calendar but the date display format and punctuation conventions differ. Using a library like ICU or the built-in locale functions in your programming language is the only reliable approach. Rolling your own formatter for Chinese locales is a fast way to introduce bugs.
Limitations and When This Approach Fails
No system handles zh-cn and zh-tw perfectly out of the box. The biggest limitation is rare and variant characters. There are characters in the CJK Extension sections that exist in one variant but not the other, and some traditional characters used in Taiwan have no direct simplified equivalent and vice versa. In these cases, you may need to fall back to a generic fallback character or display a note. This is uncommon in usage but it shows up frequently in legal documents, historical texts, and technical specifications. Another failure point is mixed-script content. If your application ingests content from multiple sources using different character sets, normalization becomes difficult. A document that combines simplified and traditional characters in the same paragraph is not uncommon in cross-strait business contexts. Attempting to convert such content risks losing the author's intent. In these cases, preserving the original forms and letting the user choose their preferred display variant is often the better choice, even if it means your UI has to handle both simultaneously. The final limitation is that locale is not the same as character variant preference. Some users in mainland China prefer traditional characters for certain contexts, and some users in Taiwan are comfortable reading simplified characters. Locale detection alone cannot capture this. If your application serves a broad audience, consider adding an explicit character set preference toggle rather than relying solely on geographic locale detection.
Chinese character set handling is not a puzzle with a clean solution. It is a set of tradeoffs that depend on your content, your users, and your technical constraints. Getting the basics right with proper libraries, explicit collation settings, and full-coverage fonts will solve the majority of problems. The edge cases require attention to detail and a willingness to accept that perfect coverage is not realistic.
