skip to content

In a design system for an accounting product shipped in Latin, Arabic and Japanese, how should font stacks and their fallback order be designed?

level: middleimportance: should knowfreq 38%

answer

  1. the brand face covers Latin only
  2. first font with the glyph wins
  3. script family before generic fallback
  4. same character, different local shape
  5. tag the language of the content

basics

~20 s

Define a stack per locale or script: the brand family first for Latin, then a family chosen for the script, then the platform's default interface font and a generic fallback. Tag content language so the right glyph forms apply.

solid answer

~50 s

A brand typeface usually covers Latin only, so without a plan Arabic or Japanese text falls through to whatever the device finds, character by character, with mismatched weights and proportions. A design system therefore defines **stacks per script or locale**: the brand family for Latin characters, then a family chosen to sit well beside it for the script, then the platform's default interface font, then a generic fallback. Order matters because each character is drawn by the first font in the stack that contains it; putting a broad multi-script font first would override the brand everywhere. Per-locale stacks matter too: Japanese and Chinese share many character codes but expect different glyph shapes, so content must carry its language (WCAG 3.1.1 and 3.1.2 require the language to be programmatically determinable) and the stack is chosen by locale. In an accounting product, also make one font draw every digit in Arabic amounts.

go deeper

for a junior

Recall that a stack is an ordered list, that each character uses the first font containing it, and that the brand font rarely covers Arabic or Japanese.

for a middle

Explain the ordering roles, why per-locale stacks are needed for shared Chinese and Japanese characters, and how language tagging ties into WCAG 3.1.1 and 3.1.2.

for a senior

Show how you would choose and review script families against the brand's weights, fix inconsistent device fallback, and make digits in ledger columns come from one font.

for a principal

Weigh commissioning or licensing script families against relying on platform fonts per market, and decide which locales earn a custom family.

## Why one font is never enough A brand typeface is usually drawn for Latin script: the letters of English, French or German, plus digits and punctuation. The moment a product ships in Arabic or Japanese, most characters on screen are ones the brand font simply does not contain. Something else will draw them. The only question is whether the design system chose that something, or left it to whichever font each device happens to have. ## How a stack resolves A **font stack** (or fallback list) is an ordered list of families. Both web and native platforms resolve it the same basic way: 1. For each character, try the first family in the list. 2. If that family has no glyph for the character, try the next one, and so on down the list. 3. If no listed family has it, the platform's own fallback chain takes over. 4. If nothing has it, the reader sees a missing-glyph box, often called tofu. Because resolution is **per character**, one line can mix fonts: an Arabic sentence can use the Arabic family for its letters and the brand family for an embedded invoice code. That is desirable when both were chosen to match, and ugly when the second one is an accident. ## Designing the order | Position | Role | Why it sits there | |---|---|---| | 1 | Brand family | Draws Latin letters, digits and punctuation in the brand voice | | 2 | Script family chosen for the locale | Covers Arabic or Japanese with a design that matches the brand's weight range and tone | | 3 | Platform default interface font | Reliable coverage of most scripts on that platform | | 4 | Generic fallback | A last resort so text always renders | Two ordering mistakes are common. Putting a broad multi-script family first overrides the brand for Latin too. Leaving position 2 empty means Arabic and Japanese render in whatever the operating system picks, which differs between devices and rarely matches the brand's weights. Native apps follow the same structure. The app bundles the brand Latin family, bundles or relies on script families, and uses the operating system's own fallback chain as the final step. The decision the design system documents is identical on web and native: which family draws which script, in which order, for which locale. ## Per-locale stacks and shared characters Chinese, Japanese and Korean writing share a large set of characters that Unicode encodes once (a decision known as Han unification), but each language expects some of those characters drawn differently. A font designed for Japanese draws them the Japanese way. So: - The stack is chosen **per locale**, not per script alone: the Japanese interface lists a Japanese family before any Chinese one. - Content carries its **language**, so the platform can pick the right glyph forms and the right stack. WCAG 2.2 requires this independently: **3.1.1 Language of Page** (Level A) for the default language and **3.1.2 Language of Parts** (Level AA) for passages in another language. - The design system stores family choices per locale, so a product team never edits a stack by hand. ## Matching across scripts A script family should look like it belongs next to the brand: - **Weight range**: if the brand uses regular, medium and bold, the Arabic family needs usable equivalents. - **Tone**: a geometric brand face pairs better with a clean Arabic design than with a calligraphic one. - **Digits**: an accounting product shows amounts everywhere. Decide per locale whether amounts use Western digits or the locale's own digits, and make sure one font draws all digits in a column, so figures align. - **Punctuation and symbols**: currency signs and percent signs may come from a different font than the surrounding text; check that they match in weight. ## Common mistakes - Relying on the device's fallback and discovering in production that Arabic invoices look different on every phone. - One global stack for all locales, so Japanese users see Chinese glyph forms. - Forgetting to tag the language of embedded passages, so the wrong glyphs and the wrong screen-reader voice are used. - Choosing script families by name recognition rather than by comparing weights side by side with the brand. - Testing only with Latin placeholder text, so missing-glyph boxes surface first in a customer's translated invoice.

  • Why not simply put one large multi-script family first and skip per-script choices?
    Because each character goes to the first family that contains it, a broad family first would also draw the Latin text and replace the brand face. It may also not match the brand's weights or tone in any script. Listing the brand family first and a matched script family second keeps the brand where it applies and controls the rest.
  • Why does the language of an embedded English phrase in Arabic text need marking?
    The platform uses the language to pick glyph forms, fonts and, for screen readers, pronunciation. WCAG 2.2 3.1.2 Language of Parts (Level AA) requires passages in another language to be programmatically determinable, with exceptions such as proper names and technical terms. The design system should make this easy in its text components.

A font stack works like a front desk staffed in a fixed order: each visitor goes to the first clerk who speaks their language. Put a clerk who speaks everything at the front and the brand's own clerk never gets a visitor.

saying these in an interview costs you the question

  • The brand font will render every language as long as it is listed first.
  • Order in the stack does not matter because the platform picks the best font.
  • Japanese and Chinese can share one stack since they use the same characters.
  • Device fallback fonts are good enough, so script families need no design review.
  • Language tagging is only for screen readers and has no effect on rendering.