Internationalization, or i18n, prepares a product for different languages and regional conventions. Localization, or l10n, adapts it for a particular audience through translation, formats, content, and cultural details. Translated buttons do not guarantee that users can enter addresses, understand amounts, or obtain documents in the right language.
QA should check the whole user journey. Interface language, region, time zone, and currency are related but distinct. Someone might read Russian, live in Kazakhstan, and order in euros. The product should implement its agreed settings model.
Where locale comes from
Clarify precedence among URL, profile setting, interface selection, system language, and browser header. Test first visits, repeat login, another tab, and external links. Unexpected language changes after authentication often result from conflicts between these sources.
Define separate rules for guests and profile users. Language switching should retain page meaning and entered data as required. Missing translations need a defined fallback rather than an arbitrary language mixture.
Translation and content completeness
Check the main UI, validation, empty states, server messages, emails, notifications, and exports. Rarely encountered strings are more likely to remain untranslated. Automated missing-key detection is useful but cannot assess translation meaning.
Check variables, plurals, gender, and grammatical forms. Concatenating translated fragments around a count can break grammar. Use 0, 1, 2, 5, 11, and 21 objects, comparing the expected wording with approved translations.
Layout and writing direction
Long translations must not conceal actions or overlap prices. Pseudolocalization exposes fixed dimensions and untranslatable strings before translations are ready. It does not validate natural language or regional content.
For right-to-left text, check direction, navigation order, mixed text, numbers, and icons. Not every icon should be mirrored; design and product rules determine its meaning. Also verify understandable selection, copying, and editing of mixed-direction strings.
Numbers, money, and units
Thousands and decimal separators vary. A field may display “1 234,50” while sending a normalized number to the API. Verify display, parsing, and final calculation so formatting does not change the amount.
Currency is a separate business value, beyond a symbol beside a number. Do not change it automatically with language unless required. Check precision, rounding, negative and zero amounts, and consistency across UI, email, and documents.
Dates and time zones
Distinguish calendar dates, local times, and instants. A birthday should not shift with time zone. A meeting may display in the user's local time while retaining one instant on the server.
Include examples near midnight and month boundaries. Where daylight saving time applies, test ambiguous and nonexistent local times. A “per day” filter should use the agreed time zone rather than the tester's computer default.
Names, addresses, and search
Use names beyond Latin letters: spaces, hyphens, apostrophes, diacritics, and long values within requirements. Countries do not all share the team's familiar postal-code format, region field, or address order.
Search and sorting need explicit rules for case, diacritics, and alternate spellings. Test text copied from external sources. Visually identical Unicode strings can have different internal representations; agree on normalization expectations with developers.
Practical example: international delivery
Prepare two test-store profiles with different languages, one order in a fixed currency, and an address containing non-Latin characters. Record the amount, creation time, and order ID before switching settings.
- 1.Open the order through a direct link and change language. Expect the order, currency, quantities, and entered address to persist.
- 2.Enter a fractional quantity using the chosen locale's accepted format. Expect unambiguous normalization or a clear error before an incorrect amount is submitted.
- 3.Compare the time in two time zones. Expect the same instant and the correct local date according to product rules.
- 4.Obtain a test email and document. Expect the agreed language, amount, and address without lost characters.
Check error language separately: a server rejection for an invalid postal code must not expose an internal translation key.
Accessibility and technical metadata
Web documents need the correct language declaration, and other-language fragments need appropriate metadata where required. This affects screen reader pronunciation and text processing. Translating a visible label does not guarantee a translated accessible name.
For alternate language URLs, check navigation, parameter preservation, and agreed metadata. These complement editorial review. Confirm natural phrasing and cultural suitability with someone proficient in the audience's language.
Common mistakes and completion criteria
Major mistakes include equating language with country, testing only the homepage, copying expected strings from the application itself, and treating machine translation as a final reference. Shrinking text to fix clipping can also make an interface hard to read.
Readiness requires successful key journeys, complete translations, correct regional data, and no blocking input issues. Distinguish technical defects, translation questions, and missing product rules in reports, since different specialists resolve them.