Localization Testing: Best Practices and a Step-by-Step Guide

Summarize this post with: 9 min read

ChatGPT Perplexity Grok Google AI

Localization testing checks that a translated website or app works and reads correctly for people in each target market. It covers four things: the language (accurate, natural, consistent), the layout (nothing cut off, overlapping or mirrored wrongly), the functions (forms, search, checkout and emails still work) and the local conventions (dates, numbers, currencies, addresses). The best process starts before translation with pseudo-localization, then combines automated checks with a review by native speakers on the real pages.

This handbook gives you a step-by-step process, a checklist you can copy, and the best practices that catch the most bugs for the least effort.

Key takeaways

• Test in context, on real pages and devices. Reviewing strings in a spreadsheet misses most layout and meaning problems.
• Run pseudo-localization before translating to find hard-coded text and layouts that can’t stretch.
• Budget for text expansion. Short English labels can more than double in length in other languages.
• Use native speakers for the linguistic pass, with a glossary and style guide so feedback is consistent.
• Re-test after every significant content or design change, not just at launch.

What localization testing covers

Localization testing vs. internationalization testing

Internationalization (i18n) testing checks that the product can be localized: text isn’t hard-coded, layouts stretch, the code handles Unicode, dates and currencies come from locale settings. It happens once per feature, ideally before any translation.

Localization (l10n) testing checks each specific language version. It repeats for every language you add.

Most painful localization bugs are really internationalization bugs found late. That’s why the first step below happens before translation.

Step-by-step localization testing process

Step 1: Define scope and priorities

List the languages, the markets (Spanish for Spain and for Mexico are different test targets), the pages and flows in scope, and the devices and browsers your visitors use. Rank flows by business impact: sign-up, checkout and pricing come before the careers page.

Step 2: Prepare the reference material

Give testers the same material translators used:

• A glossary of product and brand terms, with approved translations and terms that must stay in English.
• A style guide per language: formal or informal address, tone, punctuation, how to write numbers and units.
• Screens or URLs for every flow in scope, and test accounts.

Without these, reviewers argue about preferences instead of reporting errors.

Step 3: Run pseudo-localization

Before real translation, replace the source text with a stretched, accented version, for example “Add to cart” → “[Àdd ţö çàŕţ !!!!!]”. This quickly shows:

• Hard-coded strings (they stay in plain English)
• Layouts that break when text gets longer
• Characters that don’t render in your fonts
• Concatenated strings (“You have” + count + “items”) that can’t be translated properly

Fix these in the code or templates now. It’s far cheaper than finding them in 12 languages later.

Step 4: Translate, then check the text in context

Once translations are in, reviewers should read them on the live or staging page, not in a file. Context changes meaning: “Book” can be a noun or a verb, “Free” can mean no cost or available. Check:

• Every visible string is translated, including buttons, error messages, tooltips, alt text and emails.
• Terms follow the glossary.
• Tone and formality match the style guide.
• Nothing is offensive, confusing or culturally off in images, colors, examples and idioms.

Step 5: Visual and layout testing

Test every in-scope page at desktop and mobile sizes. Pay special attention to:

• Text expansion. The W3C’s article on text size in translation cites IBM guidelines: English strings of up to 10 characters can expand by 200 to 300% in other European languages, and strings over 70 characters by about 130%. Menus, buttons, tabs and table headers break first.
• Fonts. Look for empty boxes or a sudden switch of typeface, which mean the font lacks those characters. Our list of multilingual fonts covers fonts by script.
• Right-to-left languages. Arabic, Hebrew and Persian need the whole layout mirrored: navigation, icons with direction, progress bars, form fields. See our guide to RTL design.
• Line breaking. Languages like Japanese, Chinese and Thai don’t use spaces between words, so check that text wraps sensibly.

Step 6: Functional testing per locale

Walk through each key flow in each language:

• Forms accept local names (accents, apostrophes, non-Latin scripts), local postcodes and phone formats, and show error messages in the right language.
• Search and filters find results with and without accents, and sort alphabetically in the local order.
• Checkout shows the right currency, taxes, payment methods and shipping options.
• Emails and notifications triggered by the flow arrive in the visitor’s language.
• Links and redirects keep the visitor in their language; the language switcher lands on the same page, not the homepage.

Step 7: Check locale formats

Dates (03/04/2026 means 3 April in much of Europe and 4 March in the US), times (12- or 24-hour), numbers (1,234.56 vs. 1.234,56 vs. 1 234,56), currencies and their position, units of measure, address order, and first day of the week in calendars.

Step 8: Run the SEO and technical checks

• The <html lang> attribute matches the language shown.
• Titles and meta descriptions are translated.
• Each language has its own URL, with hreflang linking all versions and a self-referencing canonical. Our article on self-referencing hreflang tags shows how to check this in a few minutes.
• The main content is actually translated. Google’s multilingual site guidance says it “uses the visible content of your page to determine its language”, not code-level attributes.

Step 9: Log, fix and re-test

Log each issue with the language, URL, screenshot, the current text, the suggested fix and a severity:

• Critical: blocks a flow or changes meaning (wrong price, broken checkout, offensive text).
• Major: clearly wrong or confusing, but the task can be completed.
• Minor: style, spacing, or small inconsistencies.

Fix, then re-test the affected pages in every language, because one template fix often affects all of them.

Step 10: Keep testing after launch

Localization isn’t finished at launch. New pages, new products and design changes create new strings. Add localization checks to your release checklist, and schedule a review of the top pages per language every few months.

Localization testing checklist

• Glossary and style guide shared with testers
• Pseudo-localization run, hard-coded strings fixed
• All visible text translated (including errors, tooltips, alt text, emails)
• Glossary terms used consistently
• No truncated, overlapping or overflowing text on desktop and mobile
• Fonts render every character
• RTL layouts mirrored correctly
• Forms accept local names, addresses and phone numbers
• Search, sorting and filters work with local characters
• Prices, taxes, payment and shipping correct per market
• Dates, numbers and units in local format
• Language switcher keeps the visitor on the same page
• lang attribute, translated metadata, hreflang and canonicals correct
• Critical and major issues fixed and re-tested

Best practices

Test in context, always. Most serious issues only show up on the real page.

Use native speakers who know the product. A fluent speaker who has never used your product will miss terminology errors.

Automate what’s mechanical. Screenshot comparisons, crawlers that flag untranslated text or missing hreflang, and form tests can run on every release.

Keep one source of truth for terms. Update the glossary when reviewers agree on a change, so the fix spreads to every page.

Fix the root cause. If a button breaks in German, the fix is usually a flexible layout, not a shorter German word.

How ConveyThis supports localization testing

ConveyThis is built around reviewing translations in context. The visual editor shows the translated page as visitors see it, so you can correct wording and spot layout problems at the same time. The glossary keeps terms consistent across the site, team roles let you invite translators and native-speaking reviewers per language, and translation memory reuses approved translations. Translated pages get their own URLs with hreflang, and titles and descriptions are translated too, which covers much of Step 8.

See how the review workflow works on the translation quality page, what’s included in features, and plan limits on the pricing page. For the wider process beyond testing, read about website localization.

FAQ

What is localization testing? Checking that each language version of a website or app is accurate, fits the layout, works functionally and follows local conventions.

What is pseudo-localization? Replacing source text with a stretched, accented placeholder before translation, to find hard-coded strings and layouts that can’t handle longer text.

Who should do localization testing? QA testers for functional and visual checks, native speakers who know the product for the linguistic review, and ideally someone from the target market for cultural fit.

How often should I run localization tests? At launch, on every release that changes text or layouts, and in a periodic review of the most important pages per language.

Want to review every translation on the real page before visitors see it? Create a ConveyThis account and open your site in the visual editor.