The localization testing checklist: 45 checks before you launch in a new market

Localization testing is what stands between a good translation file and a product that actually feels local. Strings can be perfect in a spreadsheet and still truncate on a Galaxy A15, show dates in the wrong order, or break a checkout in Brazil. This localization testing checklist gives you 45 concrete checks, grouped by area, so you can launch in a new market without surprises.

What localization testing covers, and why translation is not enough

Localization (often shortened to l10n) adapts your product for a specific language and region. Internationalization (i18n) is the engineering work that makes that adaptation possible. Localization testing checks the result: does the German, Japanese or Arabic version look right, read naturally and work end to end?

Translation is only one layer. For example, a perfect French translation can still overflow a button, use the wrong decimal separator, or reference a holiday nobody in Quebec celebrates. Therefore, you need checks across text, layout, formats, commerce, legal requirements and culture. If you are planning a full market entry, also read our global launch QA playbook.

Before you start: set up for localization testing

A little preparation makes every check faster. In addition, it keeps testers focused on real issues instead of setup problems.

• Freeze the strings. Test a release candidate with final translations, not a moving target.
• Run pseudo-localization first. Replace strings with accented, padded text such as “[Ŝéttîñĝš ÷÷÷÷]” to expose hard-coded text and truncation.
• Share a glossary and style guide. Include brand terms, tone (formal “Sie” or informal “du” in German, for example) and words to avoid.
• Provide context. Give testers screenshots or a string-to-screen map so they can judge meaning.
• Pick the right devices. Match the top devices, OS versions and browsers in each market, set to the target locale and region.

The localization testing checklist: 45 checks by area

The checks below are grouped into seven areas. Run all of them for every new locale, and rerun the relevant groups whenever strings, layouts or checkout flows change. Each group ends with an example bug title of the kind a native tester would file.

Language and text localization testing (checks 1 to 8)

1. All user-facing strings are translated, with no leftover source-language text.
2. No strings are hard-coded in code, images or server responses.
3. Translations are accurate in context, not just word for word.
4. Tone and formality match the style guide, for example formal Japanese keigo in support screens.
5. Terminology is consistent across app, website, emails and push notifications.
6. Plurals and grammatical gender are correct, including languages with several plural forms such as Polish and Arabic.
7. Concatenated strings read naturally, because word order differs by language.
8. Special characters render correctly, such as German ß, Turkish dotless ı and Vietnamese diacritics.

Example bug: “Polish: cart shows 5 produkty instead of 5 produktów.”

Layout and UI checks (9 to 16)

Text length changes a lot by language. German and Finnish strings often run much longer than English, while Chinese and Japanese can be much shorter. As a result, layout bugs are the most common finding in localization testing.

9. No text is truncated or clipped on buttons, tabs, labels and navigation.
10. Long words wrap or hyphenate cleanly rather than overflowing containers.
11. Dynamic Type and Android font scaling at large sizes still fit in each locale.
12. Right-to-left languages such as Arabic and Hebrew mirror the layout correctly.
13. Icons with direction, like back arrows and progress bars, mirror in RTL, while media controls and phone numbers do not.
14. Fonts support the full character set, with no empty boxes (tofu) for CJK, Thai or Devanagari text.
15. Line height and vertical spacing work for scripts with tall glyphs such as Thai and Hindi.
16. Images and screenshots with embedded text are localized or text-free.

Example bug: “German, iPhone SE: checkout button reads Zahlungspfl… and hides the price.”

Formats and locale data (17 to 24)

17. Dates use the local order and format, for example 25.09.2026 in Germany and 2026/09/25 in Japan.
18. Times use the right 12-hour or 24-hour convention.
19. Numbers use the local decimal and thousands separators, such as 1.234,56 in Brazil.
20. Currency symbols, codes and placement are correct, for example 12,50 € in France.
21. Calendars and week start days follow the locale, including Monday-first weeks in most of Europe.
22. Phone number fields accept local formats and country codes.
23. Address forms follow local structure, including postal code formats and optional state fields.
24. Name fields accept local conventions, such as family-name-first order and single names.

Your platform’s locale APIs can help. Apple’s localization resources, for example, explain how to format dates, numbers and currencies with system formatters instead of custom code.

Payments and commerce checks (25 to 31)

Localization testing must include checkout, because commerce is where locale bugs cost money directly. For a deeper dive, see our market-by-market payment testing guide.

25. Local payment methods are available and working, such as UPI in India, Pix in Brazil and iDEAL in the Netherlands.
26. Prices display in local currency with correct rounding.
27. Taxes such as VAT or GST are calculated and displayed as local rules expect.
28. Shipping options, delivery estimates and carriers suit the market.
29. Store listings on the App Store and Google Play show localized screenshots, descriptions and pricing.
30. In-app purchase and subscription prices match the local storefront.
31. Receipts, invoices and order emails use the right language, currency and legal details.

Example bug: “Brazil, Android: order total shows 1,299.00 reais instead of 1.299,00.”

Legal, compliance and trust checks (32 to 37)

32. Privacy policy and terms are localized and reviewed for the market.
33. Cookie and consent banners meet local requirements, for example in the EU.
34. Age ratings and content restrictions match the local store and law.
35. Required business details, such as an imprint page in Germany, are present.
36. Support contacts, hours and channels make sense for the region.
37. Identity and KYC flows accept local documents and ID numbers, such as CPF in Brazil.

Culture and content checks (38 to 41)

Cultural problems rarely show up in automated tests. However, a native tester spots them in minutes.

38. Images, colors, gestures and symbols are appropriate for the market.
39. Examples, names and sample data feel local rather than imported.
40. Holidays, seasons and promotions match the local calendar.
41. Humor, idioms and slogans land as intended, or are adapted.

Technical and environment checks (42 to 45)

42. Locale detection works from device settings, browser language and region, with a manual override.
43. Search, sorting and filtering handle local characters and collation correctly.
44. Push notifications, SMS and OTP messages arrive in the right language on local carriers.
45. The app performs well on popular local devices and networks, such as budget Android phones on 4G.

Which localization testing checks you can automate

Not every check needs a human. In fact, automating the mechanical ones frees native testers for the judgment calls only they can make.

• Missing translations. A build step can fail when any key lacks a value for a shipped locale.
• Placeholder mismatches. Scripts can flag strings where variables such as {name} or %d differ from the source.
• Truncation screenshots. UI tests can capture every screen in every locale, so reviewers scan for clipping quickly.
• Format checks. Unit tests can assert that dates, numbers and currencies come from system formatters.

However, automation cannot tell you whether a slogan sounds awkward, whether an image offends, or whether a Pix payment really completes on a local bank app. That is where native testers earn their place.

Common localization testing mistakes to avoid

Most failed launches trace back to a handful of process gaps. Watch for these before your next release.

• Testing only on emulators set to a foreign locale. Real devices, local carriers and local wallets behave differently.
• Using translators as the only testers. Translators review text in a tool. They rarely complete checkout or test OTP delivery.
• Starting too late. If localization testing begins the week of launch, layout fixes collide with store review deadlines.
• Ignoring server-side text. Error messages, emails and push notifications often come from the backend and stay in English.
• Skipping store listings. A perfect app behind an English-only listing still converts poorly.

How to run localization testing with native testers

Tools and pseudo-localization catch structural issues. Native testers catch everything else. Here is a simple process that scales across markets.

1. Pick your locales and markets. Prioritize by launch date and revenue risk.
2. Select native testers in each market. They should live there, use local carriers and hold local payment accounts.
3. Brief with context. Share the glossary, style guide, scope and a list of known issues.
4. Run the checklist plus exploratory sessions. Checks give coverage. Exploration finds what the checklist did not predict.
5. Triage centrally. Reproduce each report, merge duplicates across devices and assign severity.
6. Route fixes. Send translation issues to your localization team and code issues to developers.
7. Verify. Retest fixes with the same testers on the same devices.

Sample cycle for three locales

On TestGate, native testers in more than 120 countries run this kind of cycle on real devices and networks. Every bug is reproduced, deduplicated and given a severity before it lands in Jira, Linear or GitHub. Learn more about our localization and payments testing or see how the platform delivers results.

Frequently asked questions

What is the difference between localization testing and internationalization testing?

Internationalization testing checks that your code can support any locale, for example Unicode handling and flexible layouts. Localization testing checks that a specific locale, such as German or Japanese, looks, reads and works correctly for real users.

Who should do localization testing?

Native speakers who live in the target market are best, because they catch tone, cultural and format issues that translators and machine checks miss. They also test on local devices, carriers and payment methods.

When should localization testing start?

Start with pseudo-localization during development to catch hard-coded strings and layout problems early. Then run full localization testing with native testers on a release candidate, before store listings and marketing go live.

How long does a localization testing cycle take?

A focused cycle for one to three locales usually takes one to three days once the build and translations are ready. On TestGate, cycles kick off in under 24 hours.

Launch your next market with TestGate

Planning a new locale? Talk to us and run this localization testing checklist with native testers before launch.

#checklist #global launch #internationalization #localization #localization testing