Odpowiedź.

Historia pytania:

W erze globalizacji coraz więcej produktów staje się wielojęzycznych. Testowanie lokalizacji (tłumaczeń, formatów dat, liczb, walut itp.) — to ważne zadanie dla testera ręcznego, szczególnie gdy wydanie na nowe rynki prowadzi do zmian w UI i logice. Weryfikacja lokalizacji jest niezbędna, aby zapobiec błędom w postrzeganiu, nieprawidłowym tłumaczeniom i problemom z doświadczeniem użytkownika.

Problem:

Automatyzacja tego typu testów jest trudna — kluczowe są aspekty wizualne, semantyczne i kulturowe. Często występują błędy takie jak „łamanie się układu z powodu długich słów”, „niespójne jednostki miary” czy „awarie funkcji z powodu zmiany formatu daty”. Testerzy często ograniczają się do pobieżnej analizy jedynie tekstów.

Rozwiązanie:

Organizacja procesu obejmuje:

- Weryfikację poprawności wszystkich tłumaczeń zgodnie z glosariuszem
- Testowanie długich i krótkich ciągów (krytyczne dla języka niemieckiego, fińskiego itd.)
- Weryfikację wyświetlania dat, cyfr, walut w kontekście wybranej lokalizacji
- Weryfikację poprawności UI: czy nie ma obciętych napisów, czy są zawijania, czy wszystko jest czytelne na ekranie
- Testowanie wszystkich zmian z „różnymi” językami (np. arabskim, który wymaga wyświetlania RTL)

Kluczowe cechy:

Ręczna weryfikacja wizualnych artefaktów i nietypowych scenariuszy
Uwaga na szczegóły lokalizacyjne (daty, waluty, formy zwracania się)
Walidacja przez zatwierdzone glosariusze tłumaczeniowe

Pytania z podtekstem.

Czy wystarczy porównać zlokalizowany tekst z oryginalnym w języku angielskim, aby sprawdzić jakość tłumaczenia?

Nie, należy uwzględnić semantykę, specyfikę języka, niuanse formatowania i integrację z UI. Tłumaczenie może być dosłownie „poprawne”, ale całkowicie nieprawidłowe pod względem sensu dla rodowitego użytkownika języka.

Czy można pominąć testowanie języków RTL, jeśli produkt działa w językach europejskich?

Nie, wsparcie RTL (arabski, hebrajski) wymaga specjalnych zmian w układzie, a bez testu ręcznego mogą wystąpić przemieszczenia elementów, utrata funkcjonalności.

Czy należy testować lokalizację tylko w wygodnym, znajomym języku dla testera?

Nie, należy zaangażować rodzimych użytkowników lub korzystać z usług lingwistów, szczególnie gdy mowa o rynkach o odmiennej kulturze i systemie miar.

Typowe błędy i antywzorce

Testowanie „na oko” bez porównania z glosariuszem
Pomijanie testów nietypowych długości ciągów
Ignorowanie specyficznych cech lokalizacji (waluta, liczba mnoga, formaty dat)

Przykład z życia

Negatywny przypadek

Tester sprawdził tylko angielską i rosyjską wersję aplikacji, nie testując wersji niemieckiej. Po wydaniu użytkownicy skarżyli się na obcięty tekst w przyciskach i nieczytelne komunikaty.

Plusy:

Szybkie przejście testu

Minusy:

Problemy z układem w produkcji
Spadek lojalności użytkowników

Pozytywny przypadek

Tester opracował UI we wszystkich wspieranych lokalizacjach, zidentyfikował problemy z długimi słowami dla języka niemieckiego i ponownie testował po poprawkach. Wszystkie korekty zostały dokonane na czas.