Answer.

Background:

In the era of globalization, more and more products are becoming multilingual. Localization testing (translations, date formats, numbers, currencies, etc.) is an important task for a manual tester, especially if the release to new markets leads to changes in UI and logic. Localization testing is necessary to prevent perception errors, incorrect translations, and user experience issues.

Problem:

Automating this type of testing is difficult — visual, semantic, and cultural aspects are important. Errors such as "layout breaks due to long words", "inconsistent measurement units", or "functions crashing due to date format changes" are common. Testers often limit themselves to superficial checks of only texts.

Solution:

The organization of the process includes:

- Checking the correctness of all translations according to the glossary
- Testing long and short strings (critical for German, Finnish languages, etc.)
- Verifying the display of dates, numbers, currencies in the context of the selected locale
- Checking the correctness of the UI: no cut-off labels, proper line breaks, and readability on screen
- Testing all changes with "different" languages (e.g., Arabic, which requires RTL display)

Key features:

Manual checking of visual artifacts and non-standard scenarios
Attention to locale details (dates, currencies, forms of address)
Validation through approved translation glossaries

Tricky questions.

Is it enough to just compare the localized text with the original in English to check the translation quality?

No, semantics, language specifics, formatting nuances, and integration with UI must be taken into account. A translation can be literally "correct" but completely incorrect in meaning for a native speaker.

Can testing of RTL languages be skipped if the product operates in European languages?

No, support for RTL (Arabic, Hebrew) requires special changes in layout, and without manual testing, element redistributions and loss of functionality may occur.

Should localization be tested only in a language comfortable for the tester?

No, it is necessary to involve native speakers or use services of linguists, especially when it comes to markets with a different culture and measurement system.

Common mistakes and anti-patterns

Testing "by eye" without comparing to the glossary
Skipping tests for non-standard string lengths
Ignoring specific features of the locale (currency, plurality, date formats)

Example from life

Negative case

The tester checked only the English and Russian versions of the application without testing the German language. After the release, users complained about cut-off text in buttons and unreadable messages.

Pros:

Quick verification process

Cons:

Layout issues in production
Decreased user loyalty

Positive case

The tester worked on the UI in all supported locales, noted issues with long words for the German language, and retested after fixes. All adjustments were made on time.