Localization QA · Checklist

The i18n design QA checklist: 12 checks before dev handoff

Every localization bug has two prices. In code it costs a ticket, a translator round-trip and a rebuild. In Figma it costs a drag of a resize handle. This checklist is how you pay the cheap price — 12 concrete checks to run on any design that ships in more than one language.

Updated July 2026 · 8 min read

Why QA localization at the design stage?

Classic localization QA happens after translation: real strings come back, testers click through each locale, bugs get filed. That stage is necessary — but it is the most expensive possible moment to discover that a button was never wide enough for German. The design is coded, the copy is translated, and the fix touches all three. Teams that treat i18n as a design-review item instead catch the whole “does it fit?” class of bugs while the fix is still free. Here is what to actually check.

Text & expansion (checks 1–4)

1. Simulate worst-case text expansion

English is one of the shortest languages you will ship. German, Finnish and French routinely run 20–35% longer, and short labels can double or triple — “Save” is four characters, “Speichern” is nine. Take the longest language on your roadmap and stretch every string by its real-world ratio (our text-expansion cheat sheet has the numbers per language, with sources). If you don’t know your longest language yet, +35% with extra headroom for sub-20-character labels is a defensible default.

2. Pseudo-localize the key flows

Expansion ratios catch length; pseudo-localization catches everything else — clipped diacritics, missed strings, truncation you can’t see. Transform your copy into accented, padded, bracketed strings (“Continue” → “[Çóñţîñúé·····]”) and walk the flow. A “[” with no closing “]” on screen is a truncation bug you just found for free.

3. Audit fixed-width containers

Buttons, tabs, chips, badges, table cells and sidebar items are where translations die. For each one, ask: what happens when this string grows 50%? If the honest answer is “it overflows” or “I don’t know”, it goes on the fix list. This is mechanical work — exactly the kind a plugin should do for you (all four ways to do it are in how to find text overflow in Figma).

4. Make wrap / truncate / widen an explicit decision

“It fits in English” is not a policy. For every component that holds text, the component spec should say what happens on overflow: wrap to a second line, truncate with a tooltip, or grow. Deciding this once per component beats re-deciding it per bug ticket in five languages.

Layout & structure (checks 5–7)

5. Auto layout audit: hug vs fixed vs fill

In Figma, a text layer set to hug grows with translation — which avoids overflow but can push siblings around or blow up a card grid. Fixed and fill containers clip instead. Neither is wrong; unintentional is wrong. Check that each sizing mode is a choice, and give hugging frames a “grown by 35%” visual pass: does the layout still hold when every label is longer?

6. Line height that clears diacritics

Tight line heights that look crisp in English clip the ascenders and diacritics of Polish, Czech, Vietnamese and accented French — and CJK characters visually fill the line box. If your type ramp uses line heights under ~1.3 for UI text, test them with accented strings before they harden into tokens.

7. RTL mirroring pass

Shipping Arabic or Hebrew? Layout direction flips: navigation, icons with direction (back arrows, progress), text alignment and number ordering. You don’t need a full RTL design for every screen at QA time — you need to have looked at the key flows mirrored once, and flagged the components that can’t simply flip (maps, media controls, phone numbers).

Content & strings (checks 8–10)

8. Locale-proof dates, numbers and currencies

“07/27/2026”, “1,000.50” and “$99” are all English-locale assumptions. Germans write “1.000,50 €”, and many locales put the currency after the amount. Design with the widest realistic format (long month names, thousands separators, postfix currency) so fields and columns are sized for reality.

9. No copy baked into images

Text flattened into illustrations, screenshots or exported icons never reaches translators — it ships in English to every market. Pseudo-localization exposes these instantly: they are the only strings on screen that still look normal.

10. No concatenation-shaped designs

A design that renders “You have ” + count + “ new messages” forces developers into string concatenation — which breaks in languages with different word order and plural rules. Design the string as one sentence with a placeholder (You have {count} new messages), and show the zero / one / many variants in the design file.

Type & handoff (checks 11–12)

11. Font coverage for every script

Your brand font probably covers Latin and little else. Check what actually renders Japanese, Korean, Cyrillic or Arabic in your product — a system-font fallback with different metrics can change line wrapping and vertical rhythm. If the fallback is what users will see, design the key screens with it once.

12. Handoff notes translators and devs can use

The cheapest i18n bug is the one prevented downstream: annotate max lengths on constrained strings, state the truncation rule per component, and give translators context (“Save — button, imperative”). Ten minutes of notes saves a round of “can you shorten this?” emails per language.

FAQ