Localization — istota, adaptacja treści do języka i regionu

Czym jest Localization (l10n) i czym różni się od i18n?

Localization (w skrócie l10n — 10 liter między „l" a „n") — to proces adaptacji aplikacji do konkretnego języka i regionu. Jeśli i18n to fundament architektoniczny, to l10n to wypełnienie. i18n umożliwia tłumaczenie, l10n je wykonuje. Lokalizacja obejmuje: tłumaczenie wszystkich tekstów interfejsu, adaptację formatów dat i liczb, wymianę obrazów z treściami wrażliwymi kulturowo, korektę tekstów prawnych (polityka prywatności, EULA), konfigurację systemów płatności dla regionu oraz testowanie na docelowych urządzeniach.

Rentowność biznesowa — lokalizacja bezpośrednio wpływa na konwersję. Według danych CSA Research (2023), 76% użytkowników woli kupować w aplikacjach w swoim ojczystym języku, a 40% nigdy nie kupuje w obcym. Lokalizacja na japoński dla aplikacji handlowej zwiększa konwersję średnio o 150% (Google, 2022). Zlokalizowane aplikacje otrzymują 2–3 razy więcej organicznych instalacji w regionalnych App Store i Google Play dzięki regionalnemu ASO (słowa kluczowe w języku docelowym).

i18n vs l10n — dwie strony tego samego procesu. i18n: wyodrębnienie ciągów do zasobów, obsługa RTL, formatowanie liczb. Wykonywane raz przez programistów. l10n: tłumaczenie ciągów, adaptacja treści, testowanie lokalne. Wykonywane wielokrotnie przez tłumaczy i QA dla każdej lokalizacji. W IT Sectr przeznaczamy 20–30% czasu sprintu na lokalizację dla każdego nowego języka — obejmuje to tłumaczenie, recenzję, testowanie na urządzeniach i naprawianie błędów.

Lokalizacja w iOS: Localizable.strings i Base Internationalization

Localizable.strings — główny plik do przechowywania tłumaczeń w iOS. Każda lokalizacja ma swój folder .lproj: en.lproj/Localizable.strings, ru.lproj/Localizable.strings, de.lproj/Localizable.strings. Format: „key" = „value"; (z średnikiem). Apple używa Base Internationalization: Storyboard i XIB są tworzone raz (Base.lproj), a ciągi interfejsu są eksportowane do Localizable.strings dla każdego języka. Eliminuje to potrzebę tworzenia kopii XIB dla każdej lokalizacji.

// en.lproj/Localizable.strings
// "settings.title" = "Settings";
// "profile.greeting" = "Hello, %@!";
// "items.count" = "%d item(s)";

// ru.lproj/Localizable.strings
// "settings.title" = "Ustawienia";
// "profile.greeting" = "Witaj, %@!";
// "items.count" = "%d szt.";

// Pobieranie ciągu według klucza
navigationItem.title = NSLocalizedString(
    "settings.title",
    comment: "Tytuł ekranu ustawień"
)

// Ciąg z parametrem
let name = "Anna"
greetingLabel.text = String.localizedStringWithFormat(
    NSLocalizedString("profile.greeting", comment: ""), name
)

// Import XLIFF (Xcode → Editor → Import Localizations)
// Automatycznie aktualizuje pliki .lproj po pracy tłumacza

Base Internationalization — podejście Apple, w którym interfejs (Storyboard, XIB) jest tworzony raz w Base.lproj. Przy dodawaniu języka Xcode eksportuje ciągi z Base do pliku XLIFF. Tłumacz tłumaczy XLIFF. Po imporcie Xcode tworzy .lproj z przetłumaczonymi ciągami. Zaleta: nie trzeba duplikować XIB dla każdego języka. Ograniczenie: dla języków RTL (arabski, hebrajski) może być potrzebny oddzielny XIB z lustrzanym układem.

InfoPlist.strings i lokalizacja metadanych

InfoPlist.strings — plik do lokalizacji nazwy aplikacji (CFBundleDisplayName), uprawnień kamery/mikrofonu (NSCameraUsageDescription) i innych wartości z Info.plist. Tworzony w .lproj: ru.lproj/InfoPlist.strings. Format: CFBundleDisplayName = „Moja aplikacja"; NSCameraUsageDescription = „Aplikacja potrzebuje dostępu do kamery do robienia zdjęć";. Bez lokalizacji InfoPlist.strings systemowe dialogi będą w języku angielskim.

Lokalizacja w Android: values-ru, zlokalizowane zasoby

Zasoby Android do lokalizacji są organizowane przez kwalifikatory (qualifiers) w nazwach katalogów. Dla języka rosyjskiego — res/values-ru/, dla niemieckiego — res/values-de/, dla brazylijskiego portugalskiego — res/values-pt-rBR/. Android obsługuje ponad 160 lokalizacji. System automatycznie wybiera zasoby na podstawie języka urządzenia (Locale.getDefault()). Jeśli dokładna lokalizacja nie istnieje — podstawiane są zasoby z values/ (podstawowa lokalizacja, zwykle en).

// res/values/strings.xml (podstawowy — angielski)
<string name="settings_title">Settings</string>
<string name="greeting">Hello, %s!</string>

// res/values-ru/strings.xml (rosyjski)
<string name="settings_title">Ustawienia</string>
<string name="greeting">Witaj, %s!</string>

// res/values-de/strings.xml (niemiecki)
<string name="settings_title">Einstellungen</string>
<string name="greeting">Hallo, %s!</string>

// Kotlin — jednolity kod dla wszystkich języków
textView.text = getString(R.string.settings_title)

// Ciąg z parametrem
val greeting = getString(R.string.greeting, userName)

// Zlokalizowane obrazy
// res/drawable-ru/flag.png — flaga dla wersji rosyjskiej
// res/drawable/flag.png — flaga domyślna

// Lokalizacja układów (dla języków RTL)
// res/layout-ar/activity_main.xml — wersja arabska

Lokalizacja nie tylko ciągów — Android pozwala lokalizować obrazy (res/drawable-ru/), kolory (res/values-ru/colors.xml), rozmiary (res/values-ru/dimens.xml), animacje, menu, a nawet całe układy. Dla języków o różnej długości słów (niemiecki jest o 30–40% dłuższy od angielskiego) używaj zlokalizowanych dimens.xml z zwiększoną szerokością przycisków. Dla regionów z inną symboliką kolorów (biały — żałoba w Chinach) — zlokalizowane colors.xml.

Sprawdzanie lokalizacji na urządzeniu

Testowanie — przełącz język urządzenia na docelowy przez Ustawienia → System → Język. Sprawdź: wszystkie ciągi są przetłumaczone, daty formatowane poprawnie, liczby wyświetlane z prawidłowym separatorem, obrazy odpowiadają regionowi, układ nie „łamie się" przy długich ciągach. Do automatyzacji używaj Espresso z LocaleTestRule (Android Testing Library) — pozwala uruchamiać testy z różnymi lokalizacjami bez ręcznego przełączania języka.

Adaptacja kulturowa: co trzeba tłumaczyć oprócz tekstu

Cechy kulturowe — lokalizacja nie ogranicza się do tłumaczenia ciągów. Symbolika kolorów się różni: czerwony — szczęście w Chinach, niebezpieczeństwo w USA, żałoba w RPA. Biały — czystość w Europie, żałoba w Chinach. Ikony z gestami: kciuk w górę — pozytyw w USA, obraza na Bliskim Wschodzie. Obrazy ludzi: w krajach arabskich niedopuszczalne są obrazy kobiet w kostiumach kąpielowych. Symbole religijne: krzyż, półksiężyc, gwiazda Dawida powinny być używane tylko w odpowiednim kontekście.

Wymagania prawne — każdy kraj ma swoje przepisy dotyczące produktów cyfrowych. GDPR (UE) — obowiązkowa zgoda na cookies i przetwarzanie danych. CCPA (Kalifornia) — prawo do usunięcia danych. Ustawa o danych osobowych (Rosja, 152-FZ) — przechowywanie danych na serwerach RF. LGPD (Brazylia) — odpowiednik GDPR. Płatności: w Chinach potrzebne Alipay/WeChat Pay, w Indiach — UPI, w Brazylii — Boleto i PIX. Skonfiguruj bramkę płatności dla regionu przed uruchomieniem lokalizacji.

Przykłady i treść — dostosuj przykłady do regionu. Dla lokalizacji niemieckiej używaj systemu metrycznego (kg, km), dla amerykańskiej — imperialnego (lb, mi). Numery telefonów, kody pocztowe, adresy — formatowane różnie. Przykłady walut: ¥1000 w Japonii, $9.99 w USA, 999 ₽ w Rosji. Obrazy jedzenia, ubrań, wnętrz powinny odpowiadać regionalnym standardom. W IT Sectr zalecamy zatrudnianie lokalnych konsultantów do sprawdzania adaptacji kulturowej.

Proces lokalizacji: narzędzia, tłumacze, CI/CD

Narzędzia lokalizacji — profesjonalne platformy automatyzują proces: Lokalise, Crowdin, POEditor, Smartling, Phrase. Integrują się z repozytorium, automatycznie importują nowe ciągi, śledzą zmiany (Delta updates — tłumaczone są tylko zmienione ciągi), zapewniają Translation Memory (TM — zapis wcześniej przetłumaczonych fraz) i Glossary (glosariusz terminów). Średni koszt profesjonalnego tłumaczenia: $0.08–0.15 za słowo (zależy od języka).

Proces — (1) Programista dodaje klucze i18n do kodu, wypycha do repozytorium. (2) CI/CD (GitHub Actions / GitLab CI) automatycznie wysyła nowe klucze do platformy lokalizacyjnej. (3) Tłumacze otrzymują powiadomienie, tłumaczą, zapisują. (4) Przetłumaczone pliki automatycznie tworzą PR w repozytorium. (5) QA sprawdza lokalizację na urządzeniach. (6) Wydanie. Cykl dla jednej lokalizacji: 2–5 dni roboczych (w zależności od objętości). Dla 10 lokalizacji: 5–15 dni przy równoległej pracy tłumaczy.

Machine Translation + Human Review — nowoczesny standard. Tłumaczenie sieci neuronowej (DeepL, Google Translate, GPT-4) daje jakość 80–90% dla popularnych par językowych. Człowiek-tłumacz sprawdza: terminologię, kontekst (słowa mogą mieć różne znaczenia na różnych ekranach), adaptację kulturową. W IT Sectr używamy podejścia hybrydowego: tłumaczenie ML + recenzja native speakera. Dla krytycznych ciągów (prawne, płatności) — tylko profesjonalny tłumacz. Oszczędność: do 60% kosztów przy zachowaniu jakości.