Localization testing usually gets reduced to checking translations. The words matter, but they are the layer everyone already reviews. The bugs that reach production live underneath: layouts that shatter when strings grow, dates in the wrong order, digits that switch script halfway down a screen. I test apps as a native Arabic speaker based in Amman, which means I regularly watch products meet a locale their developers never actually ran. This is the checklist I work through beyond the translation file.
Start localization testing with pseudo-locales
Before real translations exist, run the app in a pseudo-locale. Android emulators ship with en-XA, which pads and accents every string, and ar-XB, which forces right-to-left layout. One session in each catches two entire bug classes early: hardcoded strings that refuse to change, and layouts that silently assume English lengths. If a screen survives pseudo-localization, real locales become far less scary.
String expansion and truncation
German and Finnish translations commonly run around 30 percent longer than their English source strings. Walk every button, tab label, toast, and empty state looking for clipped text, overlapping elements, and ellipses that change meaning — a button reading Delete acc... helps nobody. Check the opposite direction too: Arabic strings are often shorter than English, leaving controls that look strangely wide or labels that lose their visual balance.
Dates, numbers, and currency
Format bugs are quiet and embarrassing. Verify date order (day-month versus month-day), first day of the week (the week starts on Sunday in Jordan), 12 versus 24 hour time, decimal and thousands separators, and currency symbol position. My favorite trick is setting the device locale and the app language to different values; that mismatch exposes code that reads one setting but formats with the other.
Arabic-Indic numerals
Arabic locales may render digits as Western Arabic (0, 1, 2) or Arabic-Indic (٠, ١, ٢) depending on platform, locale variant, and how each string was formatted. I have seen both scripts on a single screen: prices in Arabic-Indic, the phone number field in Western. Neither choice is wrong on its own — mixing them is. Decide what the product wants, then verify it holds everywhere digits appear: prices, one-time codes, counters, and dates.
Pluralization is not two forms
English needs singular and plural. Arabic grammar has six plural categories — zero, one, two, few, many, other — and Russian follows its own rules again. String concatenation like "You have " + count + " items" collapses instantly under that. Confirm the app uses platform plural resources, then test the counts 0, 1, 2, 3, 11, and 100 in each language, because those values land in different grammatical categories across locales.
Images, icons, and direction
Text baked into images does not translate, so flag any screenshot, banner, or illustration containing words. Icons carry direction too: in RTL layouts the back arrow must flip and progress flows should run right to left, but media playback icons and clocks stay exactly as they are. A mirrored play button is the classic RTL over-correction, and I still find it in shipped apps.
Automation tie-in: I keep a short Maestro flow that walks our top screens in an Arabic locale and in en-XA, wired into the same GitHub Actions pipeline as the smoke suite. It cannot judge translation quality, but it catches broken layouts and hardcoded strings before a human ever looks.
Translation review confirms the words. This checklist confirms the product actually works in the locale — and that second part is where users decide whether an app feels local or merely translated. If your team has a native speaker of any target language, put them in front of the build early; they will see in seconds what a spreadsheet of strings never shows.