Build Interfaces That Survive Translation

Believe it or not, Chinese makes interface design easier.

Every glyph is the same size. Lines break anywhere, 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 even see it in Windows XP. English interfaces clipped and overflowed everywhere while the Chinese ones in the same programs simply fit—even at that time, when China's internet had less software.

Open a modern Chinese app next to its Western counterpart: more on screen, smaller gaps. Screen-translate it to English and watch it stop fitting.

An English-designed product usually works more cleanly when simply translated to Chinese, because designers spent decades optimizing for English's worst cases and Chinese needs none of it. You will only notice that the voice is somehow flattened. But those kind of product still fail sometimes just in different way.

Even Vercel, for example, with many of my favorite designers and engineers, can sometimes be trapped by another language:

My native language is Chinese, but I've designed in English since day 1. Recently, I started refactoring my team's app to turn it from a Chinese-only app into one that meets a global standard. We decided to follow the Apple pattern: same screens in every locale, fewer forked layouts. During the practice, I found that every language quietly subsidizes the people who design in it or even speak it; they just pay different bills. The blind spot is that you cannot know the gotcha unless you know that language and test with it.

Here I'll share what I learned on this journey and, more importantly, how to build language-tolerant interfaces. The lessons run roughly from what CSS can save to what only a writer can.

Atom and Wrap

Every writing system has an atom. In English it is the word: variable length, occasionally enormous. In CJK it is one character, fixed and small. The clean way to see it is min-content, the narrowest a box can be before its contents spill. Try dragging the handle until English refuses to go smaller.

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

That is the real reason responsive layout is harder in English, or latin language. Also, CJK advance widths are (mostly) uniform , so a string's width is a linear function of its character count. 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.

The blind spot runs on both sides: Latin and CJK. As a designer, you don't have to completely master another language. Never let a hard-coded width be the only thing holding a label.

And it naturally comes down to line breaks, which are almost free for Latin languages, because every space is a machine-readable seam and a browser will never cut a word in half. Chinese and Japanese have no spaces. Every tinted block below is one word exactly as your own browser's segmenter reads it, and it turns red the moment a line cuts through it. Rescue 应用: hand the line breaker the dictionary.

English never splits in any mode. Japanese and Chinese face the same problem: words are split. Flip to Visual Balance and notice what it does not do: 应用 still splits. Line breaking has two jobs: to keep the proportions and respect the meaning. English only ever needed the proportion half, because spaces guard the meaning half for free. Chinese needs both, and today's platforms hand it exactly one — the visual polish shipped, and the dictionary is still waiting for its wiring.

iOS refuses to end a paragraph on a stubby last line, pushing characters down until the ending carries real weight. The demo's Visual Balance mode is the web's version of the same policy implemented with text-wrap: pretty. iOS confused me at the start. I thought it was semantics-based wrapping until I realized I could adjust the UI font size to test.

But however you wrap, as long as the container grows downward, nothing is lost. Switch the specimen to Deutsch and watch which of the two changes height.

The truncating row is exactly as tall in German as it was in English, because it is not absorbing the extra length, it is throwing it away. Height is the only thing a row has to spend, and that one is spending nothing.

So from this section, we learned:

1. Wrap, wrap, wrap. In the v0 screenshot at the beginning, the problem is fixed if they allow "Import from Figma" to wrap. Let the label take as many lines as the string needs, and let the row, the list and the pane grow to hold it.
2. Wrapping needs somewhere to wrap, so give every container a minimum width, and state it as a visual width.

Very simple, right? Just make sure you check every corner.

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" — the exact feeling many foreigners have inside Alipay or WeChat.

Pay for compression

Every step of compression you add, you need to pay for it eventually somewhere else. Try swiping the handle all the way down to the gesture.

Language compresses information. 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.

Chinese is denser per character. But Coupé and colleagues measured controlled read speech across seventeen languages in 2019 and found their information rates clustering around 39 bits per second.¹ Languages with more information per syllable were read more slowly, those with less were read faster, and the measured rates converged.

That probably means Chinese is not delivering more meaning per glance. It delivers the same meaning in less area. Density buys space, but it doesn't buy time.

The discount gets charged back somewhere. Latin's distinguishing features are gross outline shapes, resolvable at small sizes. Chinese's are interior strokes at high spatial frequency; for example, 未 and 末 differ only in which horizontal is longer. And this gets worse with Traditional Chinese, which is even denser. So the legibility floor sits higher: dense glyphs need more pixels before they resolve at all.

Now spend the discount and see what survives paying the floor. Watch how the body advantage melts.

In chrome, Chinese wins. Five labelled tabs are a Chinese privilege. English needs about 70px for "Notifications" in a 60px slot, so we either truncate, abbreviate, swap it for "Inbox", move it to another place, or drop to a bare icon.

In body text, English wins. Set Chinese at a readable size with the line height it actually needs and the area advantage collapses.

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.

Don't patch with words

If you ignore the compression we mentioned above, you'll likely patch an ambiguous design with a word. This is one of the biggest traps for high-density language designers because a small character can do the heavy lifting (very well). And this also contributes to why screen-translating a Chinese app to English feels off.

Say we are building an AI art app. AI can suggest a list of paintings. You have 2 choices:

• Create a list for these paintings and publish it
• Just save the items to the collection, no list

Instinct tells us: yeah, a primary + a secondary button. Let's put them together. Clear. To help the user know that the secondary button just saves items, let's add "only"—in Chinese, the word "仅" takes up only a few pixels but can "clarify" well.

We are now compensating for a design problem with language. The buttons shouldn't be put together at all. Serve the user's intent. So drop the "only" and move the Publish List button to the right side.

Worth mentioning: still write full & clear strings for aria-label attributes.

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.

CJK 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. So hierarchy has to come from somewhere.

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

The same channels may not work across languages. Case, italic, weight, size, color. So keep only the ones your content language actually grants, then build the hierarchy from that list.

Pass the mirror test

Classic one: for Right-to-left languages, arrange your elements by relationship than position. I call this "pass the mirror test". Flip the panel into Arabic and count what refuses to 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.

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.

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.

ch is the same idea pointed the other way, and it is the unit behind every "this field fits 24 characters" spec. Flip the spec to ic and watch the bug invert. You will understand that these units work only when the localization can never change.

This problem continues even if you use JS to limit the content length.

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.

This generalizes beyond 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.

Price the input

A single character costs a different amount to produce. Check the race to see eight letters against one menu. IME languages need more characters to produce the target character.

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.

Some common gotchas in real-world software:

• Command palettes assume everything is Latin, making it hard for people using CJK languages to find content named in CJK. I left a comment for Karri from Linear about exactly this. ⌘K is a live example of unpriced input. That's why many search fields in Chinese products support Pinyin-based queries.
• Hard-limit the input length.
• Listen for Enter to send, submit, or save. IME languages use Enter to pick candidates.
• Auto convert space or illegal symbol to symbols like "-".

All of these point to one result: making people hard to type.

Don't translate vibe

Everything so far assumed the interface has no personality. Layout survives translation because geometry has coordinates in every language. But voice has none. It lives in three things:

• 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.
• 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. But there might no longer be 3 words after translation. The rhythm is silently lost.

Besides, not every display face you licensed has CJK cut (mostly actually. Like Inter the goat one.) This website uses Inter, so CJK text falls back to the system font. 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. Which produces the counterintuitive part: the stronger your voice, the worse it translates. A flat, functional interface round-trips way much better because it had fewer thing in the untranslatable layer to lose, though you sometimes need to pay for the compression, per we talked about above.

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. The demo runs English → 中文 → English.

Does something feel off?

So split your strings into two types:

• Functional: labels, field names, error causes, settings rows. Translate those and hold them to the practices above (sometimes translated strings lose information, per the compression we talked about before).⁴
• 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.

Notes

To sum everything up:

• Don't rely on a mono-locale view to judge the visual balance.
• Set a hard-coded minimum width visually instead of by character count. Avoid ch, ex, and any magic width you got by counting characters in your own language, unless the string can never be localized.
• For CJK line breaking, break at Intl.Segmenter seams rather than waiting for word-break: auto-phrase.
• Tag the lang, and let text-wrap: pretty guard the proportions.
• Avoid font sizes below 12px when lang is set to a CJK language.
• Build hierarchy only from the channels your content language actually grants. Where case and italic are missing, prefer color and enclosure instead.
• Test with dir="rtl" on the root. Whatever lands on the wrong side was a position, not a relationship.
• Symbols cost different amounts to produce on the device your user holds. Never assume typing is equally fast for everyone.
• Round-trip the loudest strings and hand whatever comes back flat to a writer instead of a translator.
• Typesetting principles of Chinese, Japanese, and Korean (CJK) text

I'm not saying "language shapes the product". Business does. The super-app model comes from a brutal acquisition-cost market and a growth team with a quarterly number. The proof is that the same companies' English builds are usually just as crowded.

Some English-native apps can still feel crowded.

The real and silent thing languages do is language → culture → business → software. Even if you did l10n perfectly, people from another market may still not come. Apple cannot promise it either: flawless Chinese localization has not made every Chinese user choose iPhone.

Language tolerance will not win you a market. It only removes the moment the interface says "this product was not built for me". That moment is the part in your hands.