Localization Testing Services

The problem

A “translated” build can still show English on the error path, truncate German, format dates as US in a UK locale, or charge with the wrong separator. Translation vendors do not catch that. Functional testers working only in en-US do not catch that.

Localization testing services check the product in the locales you claim to support. We are not a translation agency. We do not write your copy in French. We test whether the build behaves as a localized product.

What’s at risk without it

• Untranslated strings on errors, emails, or legal text
• Layout overflow, truncation, or overlap in longer languages
• Dates, numbers, currency, and address formats that ignore the locale
• Language switch that does not persist, or that mixes two locales
• RTL issues if you claim Arabic or similar support and never opened that build

What we test

• Language and locale switching on in-scope journeys
• String coverage: UI, emails, and named templates you provide
• Formats: date, time, number, currency, phone, address — against the locale rules you specify
• Layout on a sample of screens in each in-scope language
• Locale-specific validation (postcodes, tax IDs) when those rules are documented

We need builds or language packs and a list of locales. If you have no native speaker for a language, say so: we can still check resource coverage, formats, and layout, and we will mark linguistic quality as out of scope.

Our approach

1. Freeze the locale list and the journeys
2. Compare against a string inventory or the previous locale build if you have one
3. Execute journeys per locale; log the locale with every defect
4. Separate “wrong translation” (you need a linguist) from “string missing / format wrong / layout broken” (engineering)

Related: web and mobile for the surface; functional testing for behaviour that is not locale-specific.

Deliverables

• Findings per locale
• Missing-string and format defects
• What was not linguistically reviewed

Suitable for

Products entering a second market, or already claiming multi-locale support that nobody has clicked through.

FAQs

Will you translate the product?

No. We test localization. You (or a translation vendor) provide the strings.

Do you need native speakers?

For linguistic quality, yes. For missing strings, formats, and layout, a careful tester plus the spec is often enough — and we will label that limit.

Is this the same as internationalization (i18n) engineering?

No. i18n is how the code supports locales. We test the result.