Konsultacje z zakresu internacjonalizacji: napraw to, co szwankuje, zaplanuj dalsze kroki.
Wiesz już, że i18n to trudna sprawa. Widziałem te objawy: układy RTL, które się sypią, niemiecki tekst wylewający się z przycisków, odpowiedzi API w niewłaściwym języku i tłumaczenia rozjeżdżające się w ciągu tygodni od wdrożenia. Nie sprzedaję cudownych rozwiązań. Pomagam rozplątać konkretny bałagan, w którym tkwi Twój zespół — i budować systemy, które nie zepsują się w ten sam sposób po raz drugi.
„Powinniśmy byli to zaplanować wcześniej"
Podatek architektoniczny, który Pan/Pani płaci teraz
Pan/Pani uruchomił(a) w języku angielskim. To działało. Następnie Pan/Pani dodał(a) francuski „tylko dla strony docelowej". Teraz Pan/Pani jest tutaj, ponieważ:
W Pana/Pani bazie kodu znajdują się sprawdzenia lang= rozrzucone po 47 plikach
Menedżerowie produktu pytają: „Czy możemy przeprowadzić testy A/B treści?", a inżynieria odpowiada: „Nie bez przepisania kodu".
Macie trzy różne procesy tłumaczeniowe i żaden z nich nie działa jak należy
Co widziałem, że zawodziło:
- Zespoły spędzające ponad 6 miesięcy na wdrażaniu i18n do aplikacji Next.js, ponieważ ciągi znaków były zakodowane na sztywno w komponentach.
- Pliki tłumaczeń rozjeżdżają się, ponieważ programiści nie wiedzą, który z nich zaktualizować.
- Okresy „zamrożenia lokalizacji" przed wydaniami, ponieważ nikt nie ufa procesowi tłumaczeniowemu.
- Opór przed wprowadzaniem zmian w przetłumaczonych treściach, ponieważ proces jest tak uciążliwy.
W czym pomagam:
- Strategie refaktoryzacji, które pozwalają na stopniowe wdrażanie i18n (nie wymagam „zatrzymajcie wszystko i przepiszcie od nowa")
- Projektowanie procesu, który zapewni synchronizację tłumaczeń bez blokowania prac programistycznych.
- Przeglądy architektury, aby zidentyfikować, gdzie obecne podejście zawiedzie przy ponad 10 językach.
i18n to architektura, nie funkcja. Próba dodania tego później jest jak stwierdzenie, że dom potrzebuje piwnicy, gdy już go zbudowałeś.
Pomagam wykopać ten fundament — albo zdecydować, czy w ogóle go Pan potrzebuje.
RTL psuje wszystko.
Twój interfejs nie został zaprojektowany z myślą o arabskim, hebrajskim ani urdu
Włączyłeś dir=„rtl" i obserwowałeś, jak układ się rozjeżdża:
Co widziałem:
- Systemy projektowania z ponad 200 komponentami, z których jedynie 12 prawidłowo obsługuje RTL.
- Zespoły, które zamiast właściwości logicznych używają `float: left`, co generuje błędy RTL w każdej nowej funkcjonalności.
- Popovery i modale wymagające nadpisania ustawień RTL specyficznych dla komponentów.
- Frameworki, które deklarują „obsługę RTL", ale jedynie odwracają kierunek układu, łamiąc logikę rozmieszczania.
W czym pomagam:
- Przejście na logiczne właściwości CSS (margin-inline-start zamiast margin-left)
- Audyty systemów projektowania w celu wykrycia pułapek RTL, zanim zostaną wdrożone.
- Wytyczne specyficzne dla frameworków (Tailwind, shadcn, MUI) w zakresie stylizacji z podejściem RTL-first.
Ręczne poprawianie błędów RTL w każdym komponencie jest nieefektywne. Zapewniam systematyczne wsparcie dla RTL, zamiast ciągłego gaszenia pożarów.
„Niemiecki tekst zepsuł nam guzik"
Interfejs użytkownika, który nie został zaprojektowany z myślą o tłumaczeniu.
Angielski pasuje. Niemiecki nie. Twój projekt zakładał:
A potem przetłumaczono na niemiecki, fiński czy tajski i okazało się:
Przyciski ucięte w połowie słowa
Tabele z poziomym przewijaniem
Tekst, który zawija się w nieczytelne bloki.
Tekst nielaciński jest obcinany, ponieważ kontenery mają stałe szerokości
W czym pomagam:
- Elastyczne wzorce interfejsu użytkownika, które dostosowują się do długości treści
- Planowanie budżetu znaków (wiedząc, że niemiecki rozszerza się o 30 %, tajski nie używa spacji)
- Systemy typograficzne obsługujące języki CJK, arabski i dewanagari bezbłędnie.
Pomagam Panu zbudować interfejs, który będzie przystosowany do tłumaczenia, zanim zapłaci Pan za 10000 słów, które się nie zmieszczą.
Nie potrzebuje Pan wykładu o tym, dlaczego i18n jest ważne. Potrzebuje Pan kogoś, kto debugował popovery RTL o 2 w nocy, kłócił się z produktem o limity znaków i projektował potoki tłumaczeniowe, które naprawdę działają.
Pułapki, o których nikt nie ostrzegał
Historie z okopów od zespołów, które przez to przeszły.
To nie są kwestie teoretyczne. Oto rzeczy, które zawiodły na produkcji:
Piekło pluralizacji
Angielski: „1 item" kontra „2 items"
Polski: „1 przedmiot" / "2 przedmioty" / „5 przedmiotów" (3 formy liczby mnogiej)
Arabski: 6 form liczby mnogiej
Pana/Pani logika 'count === 1 ? „item" : „items"' już nie działa.
Chaos w datach i czasie.
Daty sformatowano za pomocą toLocaleDateString(). W efekcie użytkownicy w Japonii zobaczyli „2025年2月9日" w eksportach CSV, co sprawiło, że Excel miał problemy z ich odczytem.
Niezgodność językowa API.
Frontend wysyła zapytanie po francusku. API zwraca odpowiedź po angielsku, ponieważ token autoryzacyjny nie zawiera informacji o lokalizacji. W rezultacie interfejs użytkownika wyświetla się w mieszanych językach, a użytkownicy uznają to za błąd.
Testowanie z pseudolokalizacją
Nie przetestowano z [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30 %] przed wdrożeniem na produkcję. Teraz polska wersja strony jest bezużyteczna.
Niewidoczne założenie
Założył Pan, że ciągi znaków to jedyne, co wymaga tłumaczenia. Potem jednak pojawiły się daty, liczby, waluty, sortowanie, wyszukiwanie — wszystko z zachowaniami specyficznymi dla lokalizacji.
W czym pomagam:
- Implementacja ICU MessageFormat (obsługuje liczbę mnogą, rodzaj i kontekst).
- Wzorce i18n dla API (negocjacja języka, strategie awaryjne).
- Procesy QA, które wykrywają te problemy, zanim zrobią to agencje tłumaczeniowe.
Przepływ pracy to najtrudniejsza część
Jak zapewnić synchronizację 8 języków, gdy codziennie wdrażacie nowe wersje?
Opanował Pan/Pani technologię. Teraz utknął Pan/Pani na procesie:
Programiści scalają kod z nowymi angielskimi ciągami znaków. Tłumaczenia opóźniają się o 2 tygodnie. Użytkownicy widzą częściowo przetłumaczony interfejs.
Nie wie Pan/Pani, które ciągi znaków można bezpiecznie usunąć (czy są używane? przetłumaczone? w trakcie realizacji przez agencję?)
Dział produktu chce zaktualizować treść. Nikt nie wie, czy zmiana „Submit" na „Send" nie spowoduje problemów w 12 językach.
Pliki tłumaczeń tygodniami nie są zsynchronizowane z wersją produkcyjną.
Pytania, które zadają mi zespoły:
Co widziałem, że zawodziło:
- Pliki tłumaczeń zatwierdzone w Git, które różnią się od ciągów znaków w wersji produkcyjnej.
- Ostrzeżenia „nie ruszaj pliku hiszpańskiego", bo nikt nie wie, co można bezpiecznie zmienić
- Funkcje wprowadzane w języku angielskim, a tłumaczone 6 miesięcy później (jeśli w ogóle).
W czym pomagam:
- Projektowanie potoku tłumaczeń (kiedy stosować biblioteki i18n, kiedy TMS, a kiedy AI).
- Procesy pracy w Git, które zapewniają synchronizację ciągów źródłowych i tłumaczeń.
- Automatyzacja blokująca żądania zmian (PR-y), jeśli nowe ciągi znaków nie zostały oznaczone do tłumaczenia.
Technologia jest do ogarnięcia. Prawdziwym problemem jest przepływ pracy. Projektuję przepływy pracy, których utrzymanie nie wymaga heroicznych wysiłków.
Zespoły, z którymi pracowałem
Globalne produkty, regionalna ekspertyza.
LINE (Japonia, Tajwan, Tajlandia)
Platforma do przesyłania wiadomości działająca na 3 głównych rynkach Azji Wschodniej. Praca obejmowała wyzwania związane z obsługą znaków CJK, integracją z ekosystemem platformy oraz różnicami w oczekiwaniach użytkowników w Japonii, na Tajwanie i w Tajlandii.
KakaoTalk (Korea Południowa)
Dominująca platforma komunikacyjna w Korei. Uwzględniono specyficzne wymagania produktowe dla rynku koreańskiego, w tym oczekiwania dotyczące formalności języka w interfejsie oraz potrzeby związane z integracją platformy.
Change.org (196 krajów, ponad 20 priorytetowych języków)
Globalna platforma petycyjna, gdzie liczy się zarówno szybkość, jak i jakość treści. Pomogliśmy w usprawnieniu procesu tłumaczenia treści politycznych/społecznych generowanych przez użytkowników na wielu rynkach.
Airbnb (ponad 220 krajów, ponad 60 języków)
Globalny marketplace ze złożonymi wymaganiami i18n. Doradztwo w zakresie wyzwań związanych z zaufaniem i bezpieczeństwem w wielu językach oraz kulturowej adaptacji koncepcji platformy na różnych rynkach.
Intercom (ponad 30 języków, globalny B2B SaaS)
Platforma komunikacji z klientami obsługująca globalnych klientów korporacyjnych. Praca obejmowała internacjonalizację produktu dla narzędzi wsparcia w czasie rzeczywistym oraz lokalizację bazy wiedzy.
Lilith Games (Chiny, Japonia, Korea, USA, UE)
Wydawca gier mobilnych z tytułami dystrybuowanymi globalnie. Rozwiązano wyzwania związane z konkretnym rynkiem w zakresie lokalizacji treści i wymagań regionalnych platform.
Rynki, na których uruchamiałem produkty:
Azja Wschodnia (Japonia, Korea, Chiny):
Typografia CJK, integracja z ekosystemem platformy, obsługa tekstu pionowego.
Azja Południowo-Wschodnia (Tajlandia, Wietnam, Indonezja):
Obsługa wielu systemów pisma i oczekiwania użytkowników dotyczące podejścia mobile-first.
MENA (regiony arabskojęzyczne):
Wymagania dotyczące układu RTL, oczekiwania co do języka formalnego i potocznego, kulturowa adaptacja treści
Europa:
24 języków urzędowych, wielokrajowe premiery produktów
Ameryki:
Regionalne warianty językowe (hiszpański LATAM vs Hiszpania, portugalski brazylijski), rynki dwujęzyczne
Widziałem, co działa, a co nie sprawdza się na tych rynkach — nie z teorii, ale z wdrażania produktów, na których polegają prawdziwi użytkownicy.
Naprawmy to, co szwankuje.
Nie potrzebuje Pan wykładu o tym, dlaczego i18n jest ważne. Potrzebuje Pan kogoś, kto debugował popovery RTL o 2 w nocy, kłócił się z produktem o limity znaków i projektował potoki tłumaczeniowe, które naprawdę działają.
Przegląd architektury i strategii (1-2 tygodnie):
Powiem Panu, co przestanie działać, gdy doda Pan kolejne 3 języków, i ile będzie kosztować naprawa.
Wsparcie we wprowadzeniu na rynek (4-8 tygodni):
Uruchamia Pan działalność w Japonii/MENA/EU i potrzebuje Pan ekspertów, którzy już to robili.
Stała współpraca:
Konsulting zintegrowany z procesem skalowania z 2 języków do 20
Nie zajmuję się teorią. Zajmuję się triażem, planami działania i dostarczaniem.