Localization Testing on Real Devices
Run localization testing on real devices to verify translations, regional pricing, app-store variants, geo-restricted features, RTL rendering, and regional device coverage.
Localization testing on real devices verifies that your app's translations, regional pricing, store listings, and geo-restricted features actually work for users in each target market. A device fleet with regional SIMs, locale settings, and network egress lets you see each market's real experience instead of guessing from a spreadsheet.
- Localization is more than translation: it spans currency and pricing, date/number formats, legal text, app-store variants, and geo-gated features.
- Region is signaled by several layers — device locale, SIM/carrier, IP/network egress, and store account — and features can key off any of them.
- RTL languages (Arabic, Hebrew) and long-word languages (German, Finnish) are the most common source of layout breakage and need real-screen testing.
- App-store listings, availability, and pricing vary by storefront; verify them from the target region.
- Cover the device models that dominate each region, not just your home-market flagships.
What localization research actually covers
Teams often reduce localization to "translate the strings," but the market-specific surface is much larger:
- Content and translation — correct, complete, in-context translations with no untranslated fallbacks or truncation.
- Pricing and currency — correct currency symbol, formatting, tax/VAT display, and locally appropriate price points.
- Formats — dates, times, numbers, addresses, phone numbers, and measurement units in local convention.
- Legal and compliance — region-specific consent flows, disclaimers, and required notices.
- App-store presence — localized listing, screenshots, availability, and price per storefront.
- Geo-restricted features — content, payment methods, or functionality that is available only in certain markets.
How region is determined — and why you need real devices
An app can infer a user's market from several independent signals, and different features rely on different ones:
| Signal | Set by | Typically drives |
|---|---|---|
| Device locale/language | OS settings | UI language, formats, RTL layout |
| SIM / carrier (MCC/MNC) | Physical SIM | Carrier features, some geo-gating, SMS/OTP |
| IP / network egress | Network path | Geo-restricted content, ad targeting, pricing tests |
| Store account/region | App store account | Store listing, availability, in-app purchase pricing |
Because these layers can disagree — a device set to French, on a UK SIM, egressing through a German IP, with a US store account — you cannot fully reproduce a market's experience by changing one setting on one machine. A real device fleet lets you configure a coherent, credible combination: a device with the region's locale, an appropriate SIM or eSIM, network egress in-market, and a matching store account. That coherence is what surfaces the true localized experience and any inconsistencies between layers.
Set the layers deliberately and record them per test. A "wrong language" bug is often not a translation problem at all — it is a device whose locale, SIM region, and IP disagree.
| Home-market test | Regional device | |
|---|---|---|
| Language & layout | Home locale only, LTR assumed | Local locale, RTL and long-string checked |
| Pricing | Home currency and tax rules | Local currency, VAT, store-region pricing |
| Store listing | Home storefront only | Local storefront, screenshots, availability |
| Device mix | Home-market flagships | Region-dominant budget/mid-range models |
Testing localized content, pricing, and store variants
Localized content
Walk the app in each target locale and confirm every screen is fully translated, correctly pluralized, and free of clipped or overflowing text. Pay special attention to dynamically composed strings (concatenation breaks many languages) and images or icons that embed text or carry cultural meaning.
Regional pricing
Verify that prices display in the correct currency and format, that tax/VAT is shown per local convention, and that in-app purchase and subscription prices match the intended regional tiers in the store. Because store pricing is tied to the store account region, this needs a device signed into an account for that market. Verifying campaign pricing and offers overlaps with ad and content verification.
App-store variations
Storefronts differ by country in listing language, screenshots, availability, ratings, and price. Confirm the listing renders correctly and the app is actually available (and not blocked) in each target storefront by checking from the region.
Language and RTL rendering
Text rendering is where localization most visibly breaks, and only a real screen tells the truth.
- RTL (right-to-left) languages such as Arabic and Hebrew require the entire layout to mirror: navigation, icons, progress direction, and text alignment. Common bugs are un-mirrored icons, left-aligned RTL text, and broken bidirectional strings that mix numbers or Latin terms.
- Text expansion — German, Finnish, and Russian strings can be far longer than English, overflowing buttons and labels. Some scripts need more vertical line height (for example Thai, Devanagari) and clip if the layout assumes Latin metrics.
- Fonts and glyphs — confirm the device actually has glyphs for the target script; missing-glyph boxes appear only on real devices lacking the font.
Automated screenshot capture across the locale matrix, reviewed on-device for the tricky scripts, is an efficient workflow.
Regional device-model coverage
Device popularity varies enormously by market. A matrix built from your home market's flagships badly represents regions where budget and mid-range models, older OS versions, smaller screens, or different OEM skins dominate. Localization research therefore includes choosing devices that reflect each target region's installed base — the specific budget models, screen sizes, and OS versions real users there carry. This ensures both your translations and your layouts hold up on the hardware that market actually uses. For selection method, see choosing devices for a fleet.
A practical localization test workflow
- Define the market matrix — target locales, storefronts, currencies, and the region-representative devices for each.
- Configure coherent region layers — set device locale, install/assign the right SIM or eSIM, route network egress in-market, and sign into a matching store account.
- Capture the baseline — screenshot every key screen per locale for review and regression.
- Verify content, formats, and pricing against local convention.
- Stress the layout — RTL mirroring, longest-string languages, and script-specific line height.
- Confirm geo-gated features and store variants actually behave per region.
- Record the layer configuration with each result so failures are reproducible.