Checklists
By Emirhan Karahasan
The Localization QA Checklist: What to Test Before You Ship
A practical pre-release checklist for localized products, covering text expansion, RTL, locale formats, terminology, and the layout bugs spreadsheets miss.
Most localization bugs are not translation mistakes. They are integration mistakes, correct text placed into a product that was not built to hold it.
This checklist covers what to verify before a localized release goes out, grouped by the kind of failure it catches.
1. Text expansion and contraction
Translated text rarely matches source length. German and Finnish commonly run 30% longer than English; Japanese and Chinese often run shorter, which creates its own layout problems.
Buttons and CTAs render fully, no truncation, no ellipsis where none was designed
Navigation labels fit without wrapping into a second line that breaks the header
Form field labels and helper text do not overlap adjacent elements
Table headers and data cells hold their content at the narrowest supported breakpoint
Modal and tooltip text does not overflow its container
Character-limited fields (meta descriptions, SMS, push notifications) are still within limits after translation
2. Layout integrity
No horizontal scroll introduced on any localized page
Fixed-width containers still accommodate the longest supported locale
Icon-plus-text pairings stay aligned when the text length changes
Line height and letter spacing render correctly for scripts with different vertical metrics (Thai, Devanagari, Arabic)
Mobile breakpoints tested per locale, not just for the source language
3. Right-to-left (RTL) support
If you ship Arabic, Hebrew, Farsi, or Urdu:
Layout mirrors correctly, navigation, progress indicators, back/forward controls
Directional icons (arrows, chevrons, undo) are flipped where semantically appropriate and not flipped where they are not (a play button stays a play button)
Mixed-direction content (Latin brand names, numbers, URLs inside RTL text) renders in the correct order
Text alignment and padding mirror, rather than staying hard-coded to the left
4. Locale conventions
Date formats match locale expectations (03/04 is ambiguous across markets)
Number formatting, decimal and thousands separators, is locale-correct
Currency symbol placement and spacing follow local convention, not a global template
Address forms accept the local format (postal code position, required fields, state/province presence)
Name fields do not enforce a first/last structure that does not exist in the target market
Phone number formats and country codes validate correctly
Units of measurement converted where appropriate
Time zones and 12h/24h display follow the locale
5. Terminology and consistency
Product-specific terms match the approved glossary in every occurrence
The same source term is not translated differently across screens
UI element names in help text match the actual labels on the interface
Brand names and trademarks left untranslated where required
Feature names consistent between the product, the docs, and the marketing site
6. Context-dependent accuracy
These are the errors a string-level review cannot catch, because the string is not wrong, its usage is.
Ambiguous source words resolved correctly (does Open label an action or a state?)
Placeholders and variables land grammatically in the target sentence structure
Pluralization rules correct for languages with more than two plural forms (Polish, Russian, Arabic)
Gendered forms correct where the target language requires agreement the source did not encode
Concatenated strings still form grammatical sentences after translation
7. Functional and technical
Character encoding correct, no mojibake, no stripped diacritics
Font supports every character in every shipped locale, including fallbacks
Search and filtering work with non-Latin input
Sorting follows locale collation rules, not ASCII order
Localized URLs, slugs, and canonical tags resolve correctly
hreflang tags present and reciprocal across language versions
Localized content indexes correctly, no locale pages blocked in robots.txt
8. Untranslated and hardcoded content
No source-language strings leaking into the localized build
Error messages, validation text, and edge-case states localized (these are the most commonly missed)
Text baked into images identified and localized
Email templates, receipts, and transactional messages localized
Third-party widget and integration text accounted for
9. Legal and market-specific
Required disclaimers present and legally accurate in the target market
Consent and privacy language meets local regulatory requirements
Age gates, restricted content rules, and market-specific compliance handled
The problem with running this manually
Most of this list cannot be verified from a bilingual file export. Sections 1, 2, 3, and 8 in particular require someone to look at the rendered product, in every locale, at every breakpoint, which is why they are usually spot-checked rather than actually tested.
That is a scaling problem, not a discipline problem. Twelve locales across forty screens at three breakpoints is over 1,400 states. No review cycle covers that by hand, so teams sample, and the errors that ship are the ones outside the sample.
Loqalit scans every locale of your live product and reports the layout, terminology, and context errors this checklist covers. Start free
