Build Interfaces That Survive Translation

Believe it or not, Chinese makes interfaces easier.

Every glyph is the same size. Lines can break anywhere, so nothing overflows. A label's width is knowable before it is rendered, and more information fits into less area. A whole class of responsive problems never happens, silently.

You could see it in the Windows XP years, when most software was laid out by whoever wrote it. English builds clipped and overflowed everywhere; the Chinese builds of the same programs simply fit. Nobody designed that. The writing system was doing the design work.

Open a modern Chinese app next to its Western equivalent and you feel something before you can name it: more on screen, smaller gaps. Screen-translate it to English and watch it stop fitting.

Run the translation the other way and the opposite happens. An English-designed product usually lands in Chinese cleaner than it left, the voice a little flattened, because its designers spent years building slack for English's worst cases and Chinese needs none of it. Slack flows downhill. Translation into Chinese inherits it. Translation out of Chinese inherits the debt.

This is not a story about Chinese, though. Every language quietly subsidizes the people who design inside it; they just pay different bills. English hands you three levels of hierarchy through case alone, keystrokes cheap enough to hang power features on, and an alphabet that stays legible at sizes Chinese cannot survive. Chinese hands you fixed-width atoms, break-anywhere lines, and a chrome density English cannot afford. Easy mode is where your blind spots live, because the language absorbs your mistakes there before you can learn they were mistakes.

I sit in an odd seat for watching this. My native language is Chinese; I have designed in English since the day I started designing. Every screen I work on renders twice in my head, once per language, and the two versions disagree in ways neither audience gets to see. Lately, shipping one product across many languages has turned those disagreements from a private curiosity into a bug tracker. We follow the Apple pattern, same screens in every locale, no forked layouts, so every subsidy has to be found and paid off by hand.

Here is the invoice, itemized: eight subsidies, the bill that arrives for each, and the practice that pays it. They compress into a checklist at the end.

Find the floor

Every writing system has a smallest indivisible unit. In English it is the word: variable length, occasionally enormous. In CJK it is one character, fixed and small.

Almost everything else follows from that. The clean way to see it is min-content, the narrowest a box can be before its contents spill. Drag the handle.

English cannot go narrower than "Internationalization", because a word is an atom with nowhere inside it to break. Chinese keeps going until it is one character wide.

English text imposes a minimum width on its container. Chinese text does not. That is the real reason responsive layout is harder in English. The second-order effect is quieter and more expensive: Chinese advance widths are uniform, so a string's width is a linear function of its character count. A Chinese designer can write "no more than six characters" into a spec and know the pixel width at design time. An English designer cannot know a width without measuring it at runtime.

Which is why English design systems are full of min-width, max-width, truncation policy, and container queries. Half your design system is a workaround for a writing system, and it never admits it. That machinery is compensation for an unpredictable atom. It reads as maturity only because everyone who might have noticed grew up inside it.

The blind spot runs both ways. A design system raised in English mistakes its floor machinery for universal best practice. One raised in Chinese contains no floor knowledge at all, and its first German build discovers every floor on the same day.

Never let a hard-coded width be the only thing holding a label. If nobody on the team can name the floor, you have not designed a component. You have described one screenshot of it.

Pay for compression

Chinese is denser per character. But Coupé and colleagues measured seventeen languages in 2019 and found them all landing near the same information rate, around 39 bits per second. Dense syllables get produced slower, sparse ones faster, and languages self-balance.

That guts the naive version of the argument. Chinese is not delivering more meaning per glance. It delivers the same meaning in less area. Density is a spatial discount, not an informational one.

The discount gets charged back somewhere. Latin's distinguishing features are gross outline shapes, resolvable small. Chinese's are interior strokes at high spatial frequency: 未 and 末 differ only in which horizontal is longer. Below is your own screen, in your own system faces. Latin usually survives to the bottom of the ramp. Chinese stops resolving around 11 or 12px, and that sets a floor under every component holding it.

Now spend the discount and see what survives paying the floor.

Two results, pointing opposite ways.

In chrome, Chinese wins outright and keeps winning after the legibility bump. Five labelled tabs is a Chinese luxury. English needs about seventy pixels for "Notifications" in a sixty-pixel slot, so it truncates, abbreviates, or drops to a bare icon.

In body text the win evaporates. Set Chinese at a readable size with the line-height it actually needs and the area advantage collapses toward parity.

So the density advantage is real in chrome and close to nothing in running text. Which is exactly where you feel it: tab bars, toolbars, table headers, buttons, filter chips. Not articles. If a Chinese page feels crowded in its prose, density did not do that.

The generalizable half has nothing to do with Chinese. English is redundant, so it survives damage: truncate it, shrink it, render it badly, misspell it, and it still reads. Chinese is compressed, so it is brittle. Compression and error tolerance are the same dial. Here it is, one action at five compressions:

Every step buys space and sells self-evidence. An icon is a maximally compressed label and therefore maximally ambiguous. A shortcut is denser still and therefore unlearnable without a menu to teach it. A gesture is the densest encoding of all and therefore invisible. Chinese and English are simply the cleanest place to watch the dial move, because you hold the meaning constant and vary only the compression.

Every step of compression you add, you owe back somewhere in redundancy. An icon owes a tooltip. A gesture owes a visible fallback. A shortcut owes a menu row that teaches it. Compress without paying and you moved the cost onto whoever is left guessing.

Count your channels

Latin encodes rank inside the letterforms. Case gives you three levels at no cost, then italic, then weight, then small caps, then letterspacing. Five channels for signalling importance without touching size or color.

Chinese has weight, and weight is the weakest of the five: bolding a dense glyph fills its counters instead of adding contrast against surrounding whitespace. There is no case at all. Synthetic italic actively makes CJK worse.

Hierarchy has to come from somewhere.

The middle pane uses exactly the channels the left pane uses and they collapse into one gray block. The right pane recovers the hierarchy by spending a different budget: size jumps, three colors, a filled chip, a rule.

This is the part of "Chinese interfaces look busy" that is honestly about language. The color and the boxes are what you buy when the typographic channels are not for sale.

And it mirrors. Set a case-and-italic hierarchy in Chinese and it collapses into gray. Carry a color-and-boxes hierarchy into English and it reads as shouting to eyes trained on quieter channels; part of the Douyin-to-TikTok slimming is exactly this rebalance.

Write the available channels down before you design the tiers. Case, italic, weight, size, color, enclosure. Keep only the ones your content language actually grants, then build the hierarchy from that list. Designing four tiers in one language and translating them afterwards is how you end up with four tiers that look identical.

Pass the mirror test

Right-to-left changes the coordinate system, and that sorts a design into two piles: the parts encoding meaning in relationships, and the parts encoding it in positions.

Flip the toggle and watch which widgets move.

Back arrows, progress, sliders, step flows: anything encoding sequence mirrors, and if the layout is written in logical properties it mirrors on its own. Clocks, playback controls, checkmarks: anything depicting a convention or a physical thing holds still. And numbers do not mirror at all: Arabic numerals stay left-to-right inside a right-to-left run, so one line carries two directions at once and cursor movement, selection, and string indexing all quietly stop meaning what you assumed.

A design that survives mirroring is one whose meaning lives in relationships. Chinese and English sit on the same end of this axis, which makes direction the one blind spot both sides share: no one's home language issues the warning.

Set dir="rtl" on the root and look. Whatever comes out wrong was encoding meaning in a position, and would have broken eventually even without Arabic. Ten seconds, no translator, and it belongs in the definition of done.

Distrust the units

CSS has a length unit called ic, defined as the advance width of the character 水.

It exists because em, ex and ch are all defined against Latin letterforms — the em quad, the x-height, the advance of a zero — and none can express "one Chinese character wide." Somebody had to add a unit to the web platform, in this decade, so a Chinese layout could be described at all.

ch is the same idea pointed the other way, and it is the unit behind every "this field fits 24 characters" spec. Below is that spec: one value, one stylesheet, two scripts.

True in exactly one of them. An ideograph is two zeros wide, so the Chinese string needs double the room the spec promised. Flip the spec to ic and the bug inverts politely: Chinese lands flush on the boundary and English swims in a field twice its content. The spec was never about characters. It was about one alphabet's characters.

The spec bug speaks every language. 不超过六个字, no more than six characters, is a perfectly reliable line in a Chinese design file and gibberish the moment the product leaves home. 24ch is the same sentence with a Latin accent.

Keep pulling and it does not stop. CSS inline layout is a formalization of the Latin line: baseline, ascender, descender, leading, none of which exist in a writing system set on a square em body. text-spacing-trim and text-autospace are recent specs for CJK punctuation and the CJK-to-Latin gap. writing-mode: vertical-rl is a retrofit. Full-width and half-width forms in Unicode are a fossil of two typesetting technologies colliding. The CSS changelog is a public record of a Latin machine being slowly taught about another writing system, and it is not finished.

This generalizes past typography, which is the uncomfortable part. Sort order, string length, search tokenization, truncation, capitalization APIs. toUpperCase() is a function that assumes case exists. Every abstraction leaks the language it was designed for, and the leak lands on somebody else.

Treat any value named after a letterform as a locale bug with a delay on it. ch, ex, a magic pixel width you got by counting characters in your own language. Each is measured against an alphabet your user may not be reading.

Price the input

This one has nothing to do with shapes. It is about what a single character costs to produce. Watch the same word get typed in both languages:

Eight English keystrokes are eight letters: press, appear, done. The six Chinese keystrokes buy something else entirely: a menu. There is no key for 设; the IME collects pinyin, proposes candidates, and makes you look away from your sentence to judge and pick one. In Chinese, writing has been an act of selection on every device since the eighties.

That ratio, what a symbol costs to produce against what it costs to recognize, quietly sets an interface's shape. Expensive production pushes toward selection: visible options, chips, toolbars. Cheap production pushes toward commands: type-ahead, shortcuts, palettes. And a mnemonic shortcut cannot even exist when 保存 contains no S, so the toolbar carries the load that ⌘S carries in English, and has for forty years.

That is also a better answer than "China skipped Web 2.0." Chinese desktop software already had mobile's input economics before mobile existed. Selection-first, toolbar-forward: it converged on mobile's interface grammar early, and the phone was continuity rather than rupture.

The same ratio governs everyone. A phone keyboard makes every language's keystrokes expensive, which is why mobile interfaces are selection-heavy everywhere. Voice interfaces are menu-shaped for the same reason. So are accessible ones. Chinese only makes the ratio visible because it is extreme.

The blind spots mirror once more. A system raised on cheap keystrokes hangs its power features on shortcuts and type-ahead, then ships to users for whom every character is a round trip. A system raised inside an IME under-builds exactly those shortcuts, then meets users who expect one keystroke to do everything.

Ask what one symbol costs your user to produce on the device they are actually holding. Where production is expensive, every keystroke you demand is a tax and selection is the correct default.

Decide who yields

Which brings us back to Apple, and to what they actually did. When a string changes length, something has to give. There are four answers:

1. The text truncates. The container wins.
2. The container grows. The text wins.
3. The text shrinks. Split the difference.
4. The layout changes arrangement. A row becomes a stack.

Language tolerance is decided entirely by which one you picked, per component, in advance.

Nothing there is translated at runtime and no layout is language-specific. Arabic mirrors because the card is described with margin-inline-start and text-align: start rather than left and right. Only the fourth card survives every locale, and it is the only one changing its arrangement instead of its text.

Apple survives forty locales because they made that choice explicitly, everywhere, and mostly chose the fourth. Dynamic Type forced it years before localization did: once a user can set body text to 53pt, every layout already has to know how to rearrange itself, and a layout that rearranges for an accessibility size rearranges for German.

The mirroring is the same story with different words. UIKit gives you leading and trailing, not left and right. Auto Layout gives you relationships, not coordinates. Intrinsic content size means a component derives its size from its text instead of asserting a size over it. Their layout vocabulary makes brittleness harder to express than flexibility. CSS handed everyone left, so everyone used left, and margin-inline-start is the platform catching up a decade later.

Most teams never make the choice. A component born in a punishing language truncates by default and calls it a policy. One born in a forgiving language never chose at all, because nothing ever overflowed. Either way, the user reads the result as "this product was not built for me."

So make the choice. Four components, four policies, and one of them genuinely wants truncation.

If you picked truncation for the table header and something else for the other three, you already have the rule: truncation is fine when the string is repeated context, and a bug when it is the only thing carrying the meaning.

Name the yield policy for every component that holds a string. Write it in the component's own file if there is nowhere better. Any component whose policy nobody can name is truncating, because truncation is not a decision. It is what happens when no decision was made.

Blame the right layer

Run the whole list against a genuinely crowded Chinese app and it explains less than you would like.

Atom size and predictable extent buy a slightly tighter row. Density in chrome buys a fifth tab. The missing hierarchy channels explain the color and the boxes. Input economics explain the visible toolbar.

Everything else is business. The four entry points to the same feature, the banner above the banner, the storefront inside the messaging app, the red dot on a tab with nothing new behind it. That is a super-app model, a brutal acquisition-cost market, an ad load, and a growth team with a quarterly number. The proof is that the same companies' English builds are usually just as crowded.

Language shapes interfaces. It does not shape them at the altitude where people keep blaming it. Fix the components with the practices above; the crowding above the components is an argument to have with the growth team, not the translator.

Re-author the vibe

Everything so far assumed the interface has no personality. Most don't. But the products people love are loud: a display face with the tracking pulled in, copy that sounds like a person who has actually used the thing.

That layer behaves in the opposite way to the layout layer.

Layout survives translation because geometry has coordinates in every language. Voice has none. It lives in three things, and all three break at the border.

Register. English product voice occupies a narrow band between formal and casual that most languages have no match for. Chinese has 您 and 你, institution and friend, with very little in between. "Let's get you set up" lands either childish or bureaucratic. There is no neutral middle to aim at.

Idiom. "Oops." "Nice." "You're all set." "Hang tight." Those four strings carry more personality than anything in your design system, and none has an equivalent at the same register.

Rhythm. A three-word headline is punchy partly because it is three words. At eight characters the punch has a different shape, and the line break lands somewhere else.

The visual half goes at the same moment. The display face you licensed has no CJK cut, and commissioning one is a five-figure multi-year project because the character set runs to tens of thousands of glyphs. So the translated build gets the system face at whatever weights it ships with. Voice dies in both channels at once.

Which produces the counterintuitive part: the stronger your voice, the worse it translates. A flat, functional interface round-trips almost perfectly, because it had nothing in the untranslatable layer to lose. Personality is precisely the part that fails to cross.

Here is what makes this hard to see. If you cannot read the language your product ships into, you cannot feel what arrived. You look at the translated build, see glyphs you cannot judge, and assume it is fine.

So run the loop backwards and read the result in a language you can judge. This page is written in English, so the demo below runs English → 中文 → English; the right-hand state is the register that actually arrives in a translated product, rendered so you can hear it.

Flip the copy toggle first. Nothing is wrong. Every string is grammatical, accurate and polite. It also sounds like it was written by someone who has never used the product, and you trust it slightly less than you did ten seconds ago. You cannot point at the error, and that inability is the whole sensation. That is what your product sounds like on the far side of every border it crosses.

Then flip the type toggle alone, then both. Each channel costs you some of it. Together there is nothing left to lose.

The fix is to stop translating this layer at all.

Split your strings in two. Most are functional: labels, field names, error causes, settings rows. Translate those and hold them to the practices above. A much smaller set carries the voice: the headline, the empty states, the success moment, the one error message people screenshot. Brief a native writer on the intent and let them write it fresh. Forty strings written by someone who lives in the language buy back more personality than four thousand translated ones.

Same for type. Either budget a face per script, or build a voice that does not depend on one. Color, motion, layout rhythm and illustration all cross intact.

If a string would embarrass you coming back flat, write it fresh instead of translating it. That is the entire sorting rule for the voice layer.

Takeaway

The eight practices compress into one afternoon, and you need no translator until the last step.

1. List the five components that hold the most text. Nav labels, primary buttons, table headers, empty states, the destructive dialog. Language lands there first.
2. Find the min-content floor of every label, then grep the styles for ch, ex, and any magic width you got by counting characters in your own language. A fixed width below its own floor is a bug that has not fired yet.
3. Name the yield policy for each component. Truncate, grow, shrink, reflow. Anything you cannot name is truncating.
4. Count the hierarchy channels your content language actually gives you. Fewer than you are using means budgeting color and enclosure now, not in review.
5. Run the mirror test. dir="rtl" on the root. Whatever lands on the wrong side was a position, not a relationship.
6. Price the input. What does one symbol cost to produce on the device your user is holding? Selection is the default wherever the answer is "a lot".
7. Round-trip the forty loudest strings and hand whatever comes back flat to a writer instead of a translator.
8. Then set the whole thing in a language you did not design for. German for expansion, Chinese for contraction and the legibility floor, Arabic for direction. Everything that breaks here should already be on the list from steps two through seven; the checklist exists to make this step boring.

One last thing about that final test, because it reads differently on the two layers it touches. Point it at your layout, and whatever survives translation is a real design principle, while whatever dies was your language wearing one. Point it at your voice, and whatever survives is the part that never had a personality to begin with.

Same operation, opposite reading. Knowing which layer you are holding it against is most of the job.

Notes

• Coupé, Oh, Dediu & Pellegrino, Different languages, similar encoding efficiency, Science Advances, 2019. The 39 bits per second result.
• The ic unit, and the rest of CSS's font-relative lengths: MDN
• Apple's Right to Left guidance is the shortest good description of what does and does not mirror.
• The companion piece on the strings themselves: Wording in Interfaces.
• If you want more of this kind of thing, I collect interface details at Detail.