Localization testing

A product that works in English can still break in German, Arabic or Japanese. This page covers what localization testing checks, the bugs that show up with real translations, and a task your AI beta tester can run in each language.

Who it’s for

  • Teams launching a product in new languages or countries
  • Products with community or machine translations
  • Developers adding internationalization to an existing app
  • Stores selling in several currencies

Updated 2026-10-19.

Localization vs translation

Translation turns text into another language. Localization makes the whole product work for a market: translated text that fits the layout, local date, number and currency formats, right-to-left support, and content that makes sense locally. Localization testing checks all of it in the running product, not in a spreadsheet of strings.

It belongs in every beta test for a product launching in more than one language. A beta tester in another country will notice a button cut in half or a price in the wrong format long before they notice your new feature.

How to run a localization test, step by step

  1. List your locales and rank them by importance (traffic, revenue, launch plans).
  2. Pick the key flows: homepage, signup, onboarding, the core task, checkout and the main emails.
  3. Switch the product to each locale the way a user would: language switcher, browser language, or a localized URL.
  4. Walk each flow and screenshot every screen, so you can compare locales side by side.
  5. Trigger the hidden text: validation errors, empty states, confirmation dialogs and notifications.
  6. Test formats with real inputs: local dates, decimal commas, foreign addresses and phone numbers.
  7. Check right-to-left locales separately, since layout mirroring causes its own class of bugs.
  8. Test at phone width, where longer translations break first.
  9. Report each issue with the locale, page, exact text, a screenshot and a severity.

Localization testing checklist

Text and layout

  • Missing translations: strings still in the source language, mixed-language pages.
  • Raw keys: text like checkout.button.pay or {count} items shown to users.
  • Text expansion: translations are often longer than English. Buttons, menus, tabs and table headers overflow or get cut off.
  • Truncation: important words hidden behind an ellipsis.
  • Hard-coded text: strings inside images, emails, PDFs or error messages that never got translated.
  • Plurals and gender: "1 items" or wrong grammatical forms.
  • Fonts: missing characters showing as boxes, especially for non-Latin scripts and accented letters.

Formats

  1. Dates: 03/04 means 3 April in many countries and 4 March in the US. Use the local format or an unambiguous one.
  2. Numbers: decimal commas vs points, thousands separators.
  3. Currency: the right symbol, position and decimals; prices that are actually converted, not just relabeled.
  4. Addresses and phone numbers: forms that accept local formats and do not require a US state or ZIP code everywhere.
  5. Time zones: times shown in the user's zone, or clearly labeled.
  6. Sorting and search: lists sorted correctly for local alphabets, and search that finds words with accents.

Right-to-left languages

For Arabic, Hebrew, Persian and Urdu, the whole layout should mirror: navigation, icons with direction (arrows, back buttons), progress bars and text alignment. Numbers and embedded Latin words stay left-to-right inside the RTL text. Watch for mixed-direction strings where punctuation lands on the wrong side.

Language switching

  • The language switcher is easy to find and labeled in each language's own name.
  • Switching keeps the user on the same page.
  • The choice is remembered.
  • Each language version has its own URL and the right lang attribute, which also matters for SEO.
  • Emails and notifications arrive in the user's chosen language.

Example localization bug report

Title: German checkout button text cut off; price uses US decimal point
Locale: de-DE        Environment: Safari, iPhone width (390px)
Page: /de/checkout
Steps to reproduce:
  1. Open the site and switch language to Deutsch
  2. Add the "Pro" plan to the cart and go to checkout
  3. Look at the order summary and the primary button
Expected: Button reads "Jetzt kostenpflichtig bestellen" in full;
  price shows a decimal comma, e.g. 1.234,50 EUR
Actual: Button shows "Jetzt kostenpflichtig be..."; price shows 1,234.50
Severity: High (unclear action and wrong number format on a payment step)
Evidence: annotated screenshot of button and summary, en-US for comparison

How to prioritize findings

  1. Blocked flows: forms that reject local addresses or phone numbers, broken checkout in a locale.
  2. Wrong numbers and dates: prices, totals, deadlines and times that a user could misread.
  3. Raw keys, placeholders and missing translations on key pages.
  4. Truncated or overlapping text on buttons and navigation.
  5. Style and nuance: unnatural phrasing and tone, best handled by native speakers.

Fix in your most important locale first, then check whether the same bug appears in the others; most localization bugs come from one shared component.

Common mistakes

  • Testing only in English and assuming translations will fit.
  • Translating the interface but forgetting emails, PDFs, error messages and images.
  • Concatenating strings in code, so word order breaks in other languages.
  • Converting a currency symbol without converting the price.
  • Hiding the language switcher, or resetting the user to the homepage when they switch.
  • Treating right-to-left support as a text-alignment setting instead of a full layout mirror.

Quality of the translation

A tester fluent in the language can flag wrong terms, unnatural phrasing and tone. For important markets, have native speakers review key pages too: a careful outside pass catches the layout and format bugs, while native speakers judge nuance.

Manual testing vs an AI beta tester

Native speakers and local users remain essential. They judge whether wording sounds natural, whether content fits local expectations, and whether the product makes sense in their market at all, which no automated pass can confirm.

An AI beta tester like betatest.ing covers the systematic part. It switches the product to each locale in a real browser or on phones, walks the same flows, and reports missing translations, raw keys, cut-off text, broken right-to-left layouts and format errors with screenshots and steps to reproduce. Because it repeats the same checks on every release or on a schedule, new strings that ship untranslated get caught quickly. It never makes real payments, so it stops before paying in localized checkouts.

The test task

What you send your AI beta tester. It works out the steps and tests like a real user.

Test the localization of [SITE URL] in these languages: [LANGUAGES]. In each language visit the main pages and the key flow (switch with the language switcher, and check it keeps you on the same page and remembers the choice). Look for untranslated or mixed-language text, raw translation keys or {variables}, text that overflows or is cut off in buttons, menus, tabs and tables, plural and grammar errors, missing characters, and text inside images, emails or error messages that is not translated. Check date, number, currency, address and phone formats, and time zones. For right-to-left languages check that the layout, icons and alignment mirror correctly. Check the lang attribute and URL of each version. Note translations that read unnaturally. Log each issue with the language, page, exact text, a suggested fix and an annotated screenshot, and end with a report per language with a score and the most important fixes.

Fill in your details

Here, or later in the chat with your tester.

  • [SITE URL] Your site or app, e.g. https://example.com
  • [LANGUAGES] e.g. "German, French and Arabic"

What the AI beta tester checks

  • Untranslated, mixed-language text and raw keys
  • Text overflow and truncation in buttons, menus and tables
  • Plurals, grammar and missing characters
  • Dates, numbers, currencies, addresses and time zones
  • Right-to-left layout mirroring
  • Language switcher behavior and memory
  • Lang attributes and URLs for each language
  • Untranslated images, emails and error messages

What you get

  • Issues per language with exact text and a suggested fix
  • Annotated screenshots of layout breaks
  • A report per language with a score
  • The most important fixes, ranked

How to run it with betatest.ing

  1. Add your site as a project
  2. Paste the task and list the languages to check
  3. Send it; the tester switches languages and checks each page
  4. Fix layout and format bugs, and send translation notes to your translators

Tips

  • Start with the language that has the longest words (often German) to find overflow
  • Check error messages in each language: they are often forgotten
  • Never build sentences by joining fragments: word order differs between languages
  • Re-run after every new batch of translations

Localization testing: FAQ

Can the AI judge translation quality?

It can flag missing, inconsistent and unnatural translations in many languages. For key markets, also have native speakers review the most important pages.

Does it test right-to-left languages?

Yes. It checks that layout, icons and alignment mirror correctly and that numbers and Latin text inside RTL text display properly.

What is text expansion?

Translations are often longer than the source text, so labels that fit in English overflow or get cut off in other languages.

Does localization affect SEO?

Yes. Each language should have its own URL, a correct lang attribute and hreflang links so search engines show the right version.

When should I start localization testing?

As soon as the first translated strings are in the product, not just before launch. Early tests catch layout and format problems in shared components while they are still cheap to fix. Then repeat the checks on every release, since new strings often ship untranslated.

How much does localization testing cost?

It depends on how many locales and flows you test, and on whether you need native-speaker review. Layout, format and missing-translation checks can be automated and repeated cheaply, while nuance and tone reviews by native speakers take more time. Start with your most important locale and key flows.

What should I fix first in localization testing?

Fix anything that blocks a flow first, such as forms that reject local addresses or a broken checkout. Next fix wrong prices, dates and times, then raw keys and missing translations, and leave phrasing polish for native reviewers.

Related beta testing guides

  • Website copy review — A typo on a pricing page or a confusing button label costs more trust than it should. This page covers what a thorough copy review checks beyond spelling, and a task your AI beta tester can run on every page and flow.
  • Responsive design testing — Most layouts are designed on a wide screen and break quietly on a phone. This page explains which widths to test, the layout bugs that come up again and again, and a task your AI beta tester can run at phone and tablet sizes.
  • Website beta testing — A website beta test is a run-through of your site by someone who has never seen it, before real visitors do. This guide covers what breaks most often on marketing and content sites, how to set up the test, and a ready-to-run task your AI beta tester can start on right now.
  • E-commerce checkout testing — The checkout is where an online store makes its money and where small bugs cost the most. This guide covers how to test a checkout end to end without real payments, which edge cases matter, and a task your AI beta tester can run on any e-commerce platform.
  • Free tool: Free website test — Enter a URL, get an instant report: SEO basics, mobile, security headers, broken links and a score.

More in by test type