How to Test App Localization

Test localization in two stages: use platform pseudolocales early to expose hardcoded strings, text expansion, clipping, and right-to-left layout problems; then test the actual translated app in its target language and region on representative devices or emulators. Pseudolocales are useful diagnostics, but they cannot verify translation meaning or prove that every real translation will fit.

Localization testing covers both linguistic correctness and whether the app remains visually and functionally correct for its users. This guide gives a repeatable workflow for iOS and Android, the defects to look for, and a way to capture evidence developers and translators can act on.

1. Define the locales, screens, and behaviors to test

Start with the locales your app supports and the highest-impact paths. Include onboarding, account creation, navigation, forms, validation and error messages, notifications, checkout or subscription flows if applicable, and store-facing text. The right screen list depends on the product.

For each locale, record the language and region separately. Region affects formatted values even when the language is the same. Note which screens contain dates, times, currencies, decimal and grouping separators, addresses, calendars, or measurement units.

Scope	Questions to answer
Locales	Which language-region combinations are supported? What should happen for a partially translated or unsupported locale?
Screens and flows	Which user journeys are release-critical? Are errors, empty states, notifications, and permission prompts included?
Devices	Which screen sizes, densities, OS versions, and input methods are representative?
Locale data	Which dates, times, currencies, numbers, units, and time zones appear?
Evidence	How will an issue record the build, device, locale, steps, expected result, and screenshot?

2. Find strings that are not localized

Before reviewing translation, check whether visible copy comes from localizable resources at all. A hardcoded label cannot be translated by changing the app language. Look for text embedded in code, images, or UI components, including small labels, accessibility names, validation messages, and text generated only after an interaction.

Apple platforms

Xcode localization debugging can display nonlocalized interface strings in uppercase, making missed strings easier to spot. Use this pass on important screens and flows before translation is complete. See Apple’s Preparing your interface for localization.

Android

Run an Android pseudolocale build and look for ordinary hardcoded strings among visibly altered resource strings. Also inspect strings created by joining translated fragments: languages can require different word order, so composing a sentence from separately translated pieces can produce incorrect grammar or meaning. Android describes these risks in Test your app with pseudolocales.

3. Run pseudolocales before translations are ready

Pseudolocales replace normal-looking copy with deliberately altered content so common internationalization defects appear early. They help screen layout and resource handling; they are not a substitute for testing real translations.

iOS and Xcode

Use Xcode’s localization debugging and available pseudo-language configurations to stress longer strings, bounded text, accented content, emoji-like characters, and right-to-left direction. Inspect screens with navigation, text fields, buttons, alerts, and multi-line labels. Apple explains the available approaches in its interface preparation documentation.

Android

Enable pseudolocales in a developer-oriented build and exercise at least these configurations:

• English (XA): stresses accents and expanded text, helping reveal clipping, fixed-width assumptions, and hardcoded strings.
• AR (XB): stresses right-to-left direction and can expose layout mirroring and bidirectional text problems.

Android lists hardcoded text, layout failures, concatenation, BiDi handling, and incomplete RTL mirroring among the issues pseudolocale testing can reveal. Follow the current setup guidance in Android’s pseudolocale documentation.

What to inspect in either platform

• Text is clipped, overlaps another control, or is ellipsized before its meaning is clear.
• Buttons or cells grow in a way that hides neighboring controls or pushes content off-screen.
• A string is missing, remains in the source language, or appears as a resource key.
• Words assembled from fragments appear in the wrong order or with broken spacing.
• RTL screens have incorrect alignment, navigation affordances, or reading order.
• Inline Latin text, numbers, punctuation, or URLs render in the wrong direction inside RTL copy.

Do not set a single pseudo-string growth factor as your final acceptance limit. Real translations can be longer than generated pseudo text, and length alone cannot validate grammar or meaning. Microsoft explicitly cautions that pseudolocalization can miss real translation length cases in How to perform localization testing.

4. Test actual translated builds in the target locale

Once translations are available, change both app language and device or simulator region to the intended language-region combination. Verify that the expected resources load, fallback behaves correctly for incomplete translations, and important paths still work. A preview helps find visual defects quickly, but confirm on an emulator or device with representative screen sizes and densities.

iOS

Run the app in Simulator or on a device configured for the target language and region. Choose a region that changes the formatted values under test, then check the actual rendered dates, numbers, and other locale-sensitive data. Apple’s archived guide still gives the relevant test principle: Testing Your Internationalized App.

Android

Use Android Studio’s localized UI and RTL previews for quick inspection, then verify behavior in an emulator or on a device. Check the default resources and fallback path as well as the target translation. Resolution and density can change how text and controls appear, so inspect more than one representative configuration where the app’s supported devices make that relevant. See Localize your app.

5. Review translation meaning and resource behavior

A string can fit perfectly and still communicate the wrong thing. Have a qualified reviewer check the translated meaning and intent, particularly for ambiguous source text, button labels, warnings, plural forms, placeholders, and content assembled from multiple values.

• Check that placeholder values appear in the intended order and retain their meaning.
• Check singular, plural, and other language-specific quantity forms using values that exercise the available forms.
• Check that a partially translated locale uses the intended fallback instead of an empty label or an unrelated string.
• Check terminology consistency across navigation, help, errors, and purchase flows.
• Check that translation does not change what an action, consent choice, or warning asks the user to do.

Microsoft’s localization guidance treats accuracy as a distinct test dimension and notes the risks of concatenation and order-dependent insertion patterns. Review its localization testing guidance alongside the actual product context.

6. Test locale-sensitive formatting and mixed-direction content

Test formatted data with the target language and region. Do not assume that an English-language device’s formats are suitable everywhere. Include realistic boundary values and verify that the displayed value and the action based on it are both correct.

• Dates and calendars: check date order, month and weekday names, and any calendar behavior the product supports.
• Time and time zones: check displayed time, scheduled events, and conversions around relevant zone changes.
• Numbers and currencies: check decimal and grouping separators, currency display, rounding, and values near product limits.
• Measurement units: check that displayed units and any conversion or labeling are correct for the locale.
• RTL and BiDi: check direction, punctuation, numbers, inline Latin text, addresses, and URLs in actual RTL translations as well as the pseudo-direction pass.

For broader internationalization dimensions, see Microsoft’s internationalization testing guidance. Android’s pseudolocale guidance also describes common BiDi and RTL failure modes.

7. Capture reproducible evidence for defects

Give each issue enough context for an engineer or translator to reproduce it without guessing. A useful record includes:

1. App version or build identifier.
2. OS version, device or emulator model, screen size, and density if known.
3. App language and device region, plus any relevant time zone or formatting settings.
4. Steps to reach the screen and the test data used.
5. Expected behavior and the observed behavior.
6. A screenshot showing the issue, with sensitive data removed.
7. A category: translation meaning, layout, resource/fallback, formatting, RTL/BiDi, or functional behavior.

On Apple platforms, Xcode UI tests can collect localized screenshots; Apple documents how screenshot context and string/frame metadata can help localizers understand where text appears in Creating screenshots of your app for localizers. Keep locale and device configurations named consistently so a later build can be compared against the same conditions.

8. Make the test pass repeatable

1. Keep a locale matrix with supported language-region pairs and representative device configurations.
2. Run pseudolocale checks during development, especially after layout, navigation, or resource changes.
3. Run translated builds for release-critical locales and flows when reviewed translations are available.
4. Include locale formatting and fallback cases in the relevant manual or automated checks.
5. Attach screenshots and environment details to defects and retest them on the same configuration after fixes.

Prioritize coverage by risk: important user journeys, languages with a different reading direction, screens with dynamic text or formatted data, and changes to shared components. The exact device matrix depends on the app’s supported environments; previews and emulators are useful coverage tools, while representative physical devices help catch device-specific display differences.

9. Capture app screens for review and handoff

Localization review often needs consistent screenshots across languages, regions, and builds. For an app you can run in a simulator or device, capture the screen after setting the desired locale and navigating to the same state. Keep one screenshot per configuration and retain the build and locale metadata with it. A website screenshot service captures web pages; it does not change an app’s locale or replace iOS or Android device testing.

For web pages in a localization workflow, ScreenshotNeo is a website screenshot API and MCP server. It can produce PNG, JPEG, WebP, or PDF captures, including a full-page screenshot with lazy images loaded. Its options include viewport and device presets, custom headers and cookies, a wait condition, and cache controls. See the ScreenshotNeo API documentation.

For API screenshots in particular, ScreenshotNeo puts clean shots first: it accepts consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets, with each step configurable. Its response identifies page verdict and billing status; bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing. The MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents using Claude, Cursor, or another MCP client.

Or skip the browser setup

If the review target is a web page, a single request can save a screenshot. Replace the example URL with the page you need to capture and use your API key:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Cookie banners, popups, and chat widgets are removed before the shot. Bot checks, blank pages, timeouts, and failed loads are never billed, and the response says the page verdict and billing status. An MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots. See the API docs, then sign up free for 1,000 screenshots a month, with no card.

Common problems and fixes

Symptom	Likely cause	What to do
A label stays in the source language	Hardcoded text, a missed resource, or a different screen state than expected	Trace the visible string to its source; run the platform localization debugging or pseudolocale pass and add it to the correct resources.
Long text is cut off or overlaps controls	Fixed dimensions, restrictive line limits, or assumptions based on source-language length	Revisit constraints and wrapping behavior, then test the actual longer translation on the affected screen sizes.
RTL layout looks partly mirrored and partly broken	Direction was handled for containers but not for icons, navigation, punctuation, or inline LTR text	Inspect the whole flow in AR (XB) and in an actual RTL translation; apply direction-aware layout and check mixed-direction content.
A sentence sounds ungrammatical	Text was assembled by concatenating separately translated fragments, or placeholders are ordered incorrectly	Localize the complete sentence or use a format designed for reordered arguments; ask a language reviewer to check the result.
Dates or numbers look wrong	The device language or region is not the intended test configuration, or formatting was hardcoded	Set both language and region, use locale-aware formatting, and retest with values that expose separators and ordering.
A translated value is blank or inconsistent	Resource fallback is missing or the selected locale is only partially translated	Check required default resources and the fallback path; test the partially translated locale explicitly.
A preview looks correct but the app does not	Preview coverage differs from runtime device resolution, density, OS, or state	Confirm in an emulator or on a representative device and record its configuration with the defect.

Performance, reliability, and cost considerations

• Start with cheap, broad checks: pseudolocales and previews can reveal many layout and resource problems before each translation is ready. They do not establish linguistic quality.
• Spend review effort where meaning matters: have actual translations reviewed in high-impact flows, especially consent, account, payment, safety, and error content when those are part of the app.
• Keep evidence deterministic: use named locale/device setups, stable test data, and the same navigation path so screenshot differences are easier to interpret.
• Balance device coverage: emulator coverage is repeatable; representative physical devices can expose display behavior that previews do not. Choose based on supported devices and risk.
• Control screenshot capture cost: local simulator and device captures do not require a screenshot API. If using a web screenshot API for web content, compare its billing behavior and capture options against your volume and needs. ScreenshotNeo lists Free at 1,000 shots/month with no card, Starter $5 for 3,000, Growth $15 for 15,000, Pro $39 for 60,000, Scale $99 for 250,000, and Business $249 for 1,000,000; yearly billing gives two months free, and every feature is on every plan.

FAQ

Can pseudolocales prove my app is ready to localize?

No. They expose common engineering and layout defects early. A qualified review of actual translations is still needed for meaning, tone, and real string length.

Do I need to test both language and region?

Yes, when the app displays locale-sensitive data. Language chooses text resources; region can change formatting such as dates, numbers, and currency.

Are screenshots enough to test localization?

No. Screenshots help inspect and hand off visible defects, but flows, resource fallback, formatted values, and interactions also need checking.

Should I test every device and locale combination?

Use a risk-based matrix of supported locales, screen configurations, and critical flows. Add combinations when a locale or device exposes a distinct layout or formatting risk.