Locale QA fails in predictable ways. Not because teams are careless, but because the failure modes are distributed across disciplines — some are engineering problems, some are translation problems, some are design problems — and no single person owns all of them. The result is that each team checks what they're responsible for and assumes someone else is checking the rest. The things that fall through the gap tend to be exactly the issues that are most visible to end users: text that overflows, dates that look wrong, RTL layouts that mirror incorrectly, currency symbols in the wrong position.
What follows is a structured checklist organized by failure category. It covers the 18 checks that, across many localization programs, catch the most visible bugs before a locale ships to production. The framing is deliberately engineering-level: these are verifiable conditions, not subjective quality judgments.
String completeness and structural integrity
1. Zero untranslated keys. Every key in the target locale file has a non-empty value that differs from the source language value (or is explicitly marked as a same-language intentional pass-through). A missing key means the app will fall back to English or to a key name, both of which are visible failures. Automated: compare key sets between source and target, flag any missing or empty values.
2. Zero source-language passthroughs. A translation that is byte-for-byte identical to the English source is suspicious unless it's a proper noun, a brand term, or a technical string explicitly marked as no-translate. A comprehensive audit flags all identical-value pairs for human review; reviewers mark each as intentional or a translation miss. This catches the common translator error of submitting the source when uncertain about the target.
3. Variable placeholder preservation. Every interpolation token present in the source string is present in the translated string: {{first_name}}, %s, {count}, %(key)s. Missing placeholders cause runtime crashes or blank output. Added or renamed placeholders (a translator who "helpfully" changed {{name}} to {{Name}}) break binding. Automated: parse source and target strings, assert placeholder set equality per key.
4. ICU plural form completeness. For locales with N plural forms per CLDR spec, every plural-sensitive string provides exactly N forms. Arabic needs 6; Russian needs 3; Polish needs 4; English needs 2. A CLDR completeness check on the exported resource file catches forms dropped by CAT tools that only present two translation slots. Run this as a pre-merge gate in CI before the file is merged to the release branch.
Layout and character limits
5. Annotated character limits respected. Every string key with a character limit annotation — from XLIFF maxwidth, .po max-length comment, or a parallel metadata file — has a translated value within that limit. This is a static check on the exported file, no rendering required. Violations go back to translators with a request for shorter alternatives.
6. Button and nav label overflow — visual check. Primary action buttons (confirm, cancel, submit, continue), navigation items, and tab labels are rendered in the target locale and inspected for overflow, ellipsis, or unexpected wrapping. This requires a rendered environment, not just static analysis. Minimum test for each locale: the five highest-traffic screens. Focus on German, Finnish, Polish, and Dutch for expansion risk; Chinese and Japanese for pixel-width risk at larger glyph sizes.
7. Dialog and modal text container bounds. Dialogs often have fixed-width containers with multi-line text. A translated string that's 40% longer than English may require three lines where the design allows two, or may overflow the container entirely on mobile viewports. Check dialogs containing action descriptions, error messages, and confirmation prompts — these tend to be the longest strings in a product UI.
8. Truncation in truncation-safe vs. truncation-unsafe contexts. Some text contexts (card descriptions, list item subtitles) are designed to truncate with an ellipsis. Others (error messages, legal notices, consent dialogs) must never truncate because the full content is load-bearing. Verify that no truncation-unsafe string is actually truncating in any locale. If the design uses CSS text-overflow: ellipsis in a context where it shouldn't, this is a design-system fix, not a translation fix.
Date, time, number, and currency formatting
9. Date format localization. Dates should display in the locale-conventional format, not the source locale's format. en-US uses M/D/YYYY; de-DE uses D.M.YYYY; ja-JP uses YYYY年MM月DD日. Verify that your date rendering calls pass the correct locale string and that no dates are hardcoded in English format. This is often a runtime check — load the locale, trigger a date display, read the output.
10. Time format (12h vs 24h). US English uses 12-hour time with AM/PM; most of the world uses 24-hour time. A product that hardcodes 12-hour display for all locales produces wrong-feeling output for European, Asian, and Latin American users. Verify that time rendering passes locale context and that the output format matches CLDR time format data for the target locale.
11. Number formatting: decimal and thousands separators. 1,234.56 (US) vs 1.234,56 (German) vs 1 234,56 (French). A product that renders numbers by hardcoding a comma as the thousands separator will display the US convention for all locales. This looks wrong to German and French users and causes genuine confusion in financial contexts where comma and period meanings are reversed. Verify all number formatting goes through a locale-aware formatter: Intl.NumberFormat in JavaScript, or the platform-native equivalent.
12. Currency symbol placement and spacing. USD symbol precedes the number: $12.99. EUR in Germany typically follows: 12,99 €. JPY has no decimal places: ¥1,299. Some locales use an ISO code instead of a symbol in formal contexts. If your product displays prices, verify that currency display is locale-driven, not hardcoded to the en-US convention.
RTL (right-to-left) locale checks
13. HTML dir attribute set correctly. RTL locales — Arabic (ar), Hebrew (he), Persian (fa), Urdu (ur) — require dir="rtl" on the <html> element or on the containing layout element. A missing dir attribute causes the browser to render RTL text in an LTR layout: text starts from the wrong edge, punctuation lands in the wrong position, and bidirectional text renders incorrectly. Automated: load the RTL locale, assert document.documentElement.dir === 'rtl'.
14. Logical CSS properties vs physical properties. CSS with hardcoded physical properties (padding-left, margin-right, border-left, text-align: left) does not mirror correctly in RTL. Logical properties (padding-inline-start, margin-inline-end, border-inline-start, text-align: start) mirror automatically. A visual check of the RTL locale at key screens will reveal any physical-property artifacts: left-aligned text in an RTL context, asymmetric margins relative to reading direction, icons positioned on the wrong side.
15. Icon directionality. Icons that encode directionality — forward/back arrows, progress indicators, breadcrumb separators, pagination controls — should be mirrored in RTL layouts. Icons that are inherently symmetric (checkmarks, warning triangles, close X) should not be mirrored. Check that your icon system applies mirroring by convention rather than ad hoc, so it works correctly when new icons are added.
We're not saying every product needs a full RTL implementation from day one. The check is: if you are shipping Arabic or Hebrew, the RTL implementation must be complete before that locale goes live. A partially-RTL layout is often worse than a consistently LTR layout — it signals to Arabic-speaking users that the product was translated but not actually localized for them.
Encoding, fonts, and rendering
16. Extended characters render without substitution. Strings containing characters outside basic Latin — accented vowels, CJK characters, Arabic script, Devanagari, Thai — should render without substitution characters (□), question marks, or rendering gaps. A gap means the font in use doesn't contain a glyph for that character and the fallback font selection failed. For web apps, verify your CSS font stack includes a system font fallback that covers the character ranges of your target locales.
17. Font size and line height adjusted for script. CJK characters at the same font size as Latin text often appear slightly smaller in optical weight. Products targeting Chinese, Japanese, or Korean users conventionally use a slightly larger base font size — roughly 1px–2px — or adjusted line-height ratios for CJK text blocks. Arabic script benefits from adjusted line height because the script includes connecting marks below the baseline that need vertical room. Verify that your typography rules account for the locale's script conventions.
Functional and interaction checks
18. Form input handling with IME input methods. Forms that accept user text input — search, address, name — should function correctly with IME (Input Method Editor) input, the composing interface used for CJK character entry. An IME compose sequence temporarily places uncommitted characters in the input field; event listeners on keydown or input that fire on each composing keystroke can trigger premature search queries, validation errors, or form submissions before the user has finished composing a character. Test search fields, address inputs, and any form with live validation in Japanese (ja-JP), Chinese Simplified (zh-CN), and Korean (ko-KR) with an IME input method active. IME-related bugs in search and form inputs are among the most common and most under-tested localization failures in web products.
When to run these checks
Checks 1–4 (string completeness, variable preservation, ICU plural forms) should run as automated gates in CI on every merge to the release branch. They catch problems while they're cheap to fix — before a translator review cycle, not after.
Checks 5–8 (layout and character limits) belong in a visual regression suite on a post-translation build, at minimum for the locales with the highest expansion risk. Automated rendering with Playwright or a similar headless browser tool against a set of key screens covers most of these mechanically.
Checks 9–12 (date, number, currency) can be partially automated with runtime assertions and partially covered by manually loading each locale and reviewing formatted output on the screens that display these values. The cost is low; the failure visibility is high.
Checks 13–15 (RTL) require a rendered environment with an RTL locale loaded. Manual visual review at key screens is the reliable approach; automated checks can cover the structural assertions but not the visual correctness of icon mirroring and layout flip.
Checks 16–18 (encoding, fonts, IME) require manual testing with real input methods and real devices for the locale in question. No static analysis or synthetic rendering reliably catches these — they need a QA engineer working in the actual locale environment.
A locale that passes all 18 checks isn't guaranteed to be perfect in every cultural nuance — that requires bilingual review and market knowledge beyond any technical checklist. But it is guaranteed to be functionally correct: the text is present, it's the right text, it fits the containers, the numbers look right, and the interaction behavior works for that locale's input methods. That's the minimum bar for shipping with confidence.