LINE / Airbnb / Change.org / KakaoTalk

Konzultace k internacionalizaci: Opravte, co nefunguje, naplánujte další kroky.

Už víte, že i18n je těžké. Viděl jsem příznaky: RTL rozložení, která se zhroutí, německý text přetékající z tlačítek, odpovědi API ve špatném jazyce a překlady, které se během týdnů po spuštění rozsynchronizují. Neprodávám zázračné řešení. Pomohu vám rozplést konkrétní zmatek vašeho týmu – a vybudovat systémy, které se stejně znovu nerozbijí.

„Tohle jsme měli plánovat dřív"

Daň za architekturu, kterou teď platíte

Spustili jste v angličtině. Fungovalo to. Pak jste přidali francouzštinu „jen pro vstupní stránku". Teď jste tady, protože:

Váš kód má kontroly lang= rozházené po 47 souborech

Produktoví manažeři se ptají: „Můžeme A/B testovat texty?" a vývoj říká: „Ne bez přepsání."

Máte tři různé překladové pracovní postupy a ani jeden z nich nefunguje spolehlivě.

Co jsem viděl selhat:

  • Týmy, které strávily více než 6 měsíců dodatečnou implementací i18n do aplikace Next.js, protože řetězce byly napevno zakódovány v komponentách.
  • Překladové soubory nejsou synchronizované, protože vývojáři neví, který soubor aktualizovat.
  • Fáze „zmrazení lokalizace" před vydáním, protože nikdo nevěří procesu překladu.
  • Odpírání změn přeloženého obsahu, protože workflow je tak bolestivý.

S čím pomáhám:

  • Strategie refaktoringu pro postupné zavádění i18n (bez „zastavte vše a přepište").
  • Návrh procesu, který udrží překlady v synchronizaci, aniž by brzdil vývoj.
  • Revize architektury pro nalezení míst, kde váš současný přístup selže při 10+ jazycích.

i18n je architektura, ne funkce. Přidávat ji později je jako chtít do hotového domu vykopat sklep.

Pomohu ti vykopat ten sklep – nebo se rozhodnout, jestli ho vůbec chceš.

RTL všechno rozbíjí.

Tvoje UI není navržené pro arabštinu, hebrejštinu ani urdštinu.

Přepnul jsi dir=„rtl" a sledoval jsi, jak se rozložení zhroutilo:

Rozbalovací menu se otevírají špatným směrem.
Ikony směřují špatně.
Flexbox rozložení se hroutí nebo dělá podivné překryvy.
Tooltipy venku z obrazovky
Plovoucí prvky ignorují směr textu.

Co jsem viděl:

  • Design systémy s více než 200 komponentami, kde jen 12 správně podporuje RTL.
  • Týmy používající float: left místo logických vlastností – a tak vytvářející RTL chyby v každé nové funkci.
  • Popovery a modály vyžadující RTL přepsání pro každou komponentu.
  • Frameworky, co tvrdí, že „podporují RTL", ale jen převrátí směr a rozbijí logiku umístění.

S čím pomáhám:

  • Migrace na logické CSS vlastnosti (margin-inline-start místo margin-left)
  • Audity design systémů pro nalezení RTL nášlapných min před nasazením.
  • Pokyny pro konkrétní frameworky (Tailwind, shadcn, MUI) s důrazem na RTL.

Ruční opravy RTL chyb v každé komponentě nejsou udržitelné. Podporu RTL dělám systematickou, ne nekonečný boj.

„Německý text rozbil naše tlačítko"

Uživatelské rozhraní, které není stavěné na překlad.

Angličtina se vejde. Němčina ne. Tvůj design počítal s tím, že:

Popisky tlačítek mají ~10 znakůUživatelská jména se vejdou do sloupce 200 pxChybové zprávy se vejdou do jednoho řádku.

Pak jsi překládal do němčiny, finštiny nebo thajštiny a zjistil jsi:

Tlačítka ořezávají text uprostřed slova.

Tabulky s horizontálním scroll na každém řádku

Text se lámá do nečitelných bloků.

Nelatinkový text se ořezává kvůli pevné šířce kontejnerů.

S čím pomáhám:

  • Flexibilní UI prvky, které se přizpůsobí délce obsahu.
  • Plánování rozsahu znaků (němčina rozšiřuje o 30 %, thajština nemá mezery).
  • Typografické systémy pro CJK, arabštinu a dévanágarí bez rozbití.

Pomohu ti vytvořit uživatelské rozhraní, které přežije překlad… dřív, než zaplatíš za 10 000 slov, co se nevejdou.

Nepotřebuješ přednášku, proč je i18n důležité. Potřebuješ někoho, kdo ladil RTL popovery ve 2 ráno, přel se s produktovým týmem o limitech znaků a navrhoval překladové procesy, které skutečně fungují.

Záludnosti, na které tě nikdo neupozornil

Válečné historky od týmů, co to zažily.

Tohle není teorie. Tohle se rozbilo v produkci:

Peklo pluralizace

Angličtina: „1 item" vs. „2 items"

Polština: „1 przedmiot" / „2 przedmioty" / „5 przedmiotów" (3 tvary pluralu)

Arabština: 6 tvarů pluralu

Tvá logika count === 1 ? 'item' : 'items' už nefunguje.

Chaos s daty a časem

Formátoval jsi data přes toLocaleDateString(). Uživatelé v Japonsku pak v CSV exportech viděli „2025年2月9日" a Excel zamrzl.

Jazykový nesoulad v API.

Tvůj frontend žádá francouzštinu. API vrací angličtinu, protože autentizační token nemá info o lokalizaci. Výsledek: smíšené jazyky v UI a uživatelé to berou za bug.

Testování pseudo-lokalizací

Před produkcí jsi netestoval s [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30 %]. Teď je tvůj polský web nepoužitelný.

Neviditelný předpoklad

Myslel sis, že stačí přeložit jen textové řetězce. Pak jsi narazil na data, čísla, měny, řazení, vyhledávání… všechno má chování specifické pro lokalitu.

S čím pomáhám:

  • Implementace ICU MessageFormat (podpora pluralů, rodu, kontextu)
  • i18n vzory pro API (vyjednávání jazyka, fallback strategie).
  • Procesy kontroly kvality, které odhalí tyto problémy dřív, než je stihnou překladatelé.

Nejtěžší je workflow.

Jak synchronizovat 8 jazyků při denním releasu?

Technologii zvládáš. Teď tě brzdí proces:

1

Vývojáři integrují kód s novými anglickými řetězci. Překlady zaostávají o dva týdny. Uživatelé vidí napůl přeložené rozhraní.

2

Nevíš, které řetězce lze bezpečně smazat (používají se? jsou přeložené? zpracovává je agentura?).

3

Produkt chce změnit texty. Nikdo neví, jestli „Submit" na „Send" nezničí 12 jazyků.

4

Překladové soubory nejsou týdny synchronizované s produkcí.

Otázky, které se mě týmy ptají:

„Má naše API vracet přeložený obsah, nebo nechat frontend, ať si poradí?"
„Jak verzujeme překlady?"
Co je jediným zdrojem pravdy: Figma, kódová základna nebo překladový nástroj?
„Jak zabránit vývojářům, aby dodávali funkce jen v angličtině?"

Co jsem viděl rozbít:

  • Překladové soubory v gitu, které se liší od produkčních řetězců.
  • Varování „Nesahejte na španělský soubor", protože nikdo neví, co lze měnit.
  • Funkce spuštěné v angličtině, přeložené o 6 měsíců později (pokud vůbec).

S čím pomáhám:

  • Návrh překladového procesu (kdy použít i18n knihovny, kdy TMS a kdy AI).
  • Git workflowy pro synchronizaci zdrojových řetězců a překladů.
  • Automatizace, která zablokuje PR, pokud nové řetězce nejsou označené k překladu.

Technologie je řešitelná. Brzdou je workflow. Navrhuji postupy, které nevyžadují hrdinství při údržbě.

Týmy, se kterými jsem pracoval

Globální produkty, regionální expertiza

LINE (Japonsko, Tchaj-wan, Thajsko) logo

LINE (Japonsko, Tchaj-wan, Thajsko)

Platforma pro zprávy na 3 východoasijských trzích. Řešil jsem CJK znaky, integraci do ekosystému a rozdílná uživatelská očekávání v Japonsku, na Tchaj-wanu a v Thajsku.

KakaoTalk (Jižní Korea) logo

KakaoTalk (Jižní Korea)

Dominantní korejská zprávková platforma. Řešili jsme specifické požadavky korejského trhu včetně formálnosti jazyka v UI a integrace s platformou.

Change.org (196 zemí, více než 20 prioritních jazyků) logo

Change.org (196 zemí, více než 20 prioritních jazyků)

Globální petiční platforma, kde záleží na rychlosti i kvalitě obsahu. Pomohl jsem nastavit překladový proces pro uživatelsky generovaný politický a sociální obsah na různých trzích.

Airbnb (více než 220 zemí, více než 60 jazyků) logo

Airbnb (více než 220 zemí, více než 60 jazyků)

Globální tržiště se složitými i18n požadavky. Konzultace výzev v oblasti důvěry a bezpečnosti ve více jazycích a kulturní adaptace konceptů napříč trhy.

Intercom (více než 30 jazyků, globální B2B SaaS) logo

Intercom (více než 30 jazyků, globální B2B SaaS)

Komunikační platforma pro globální enterprise klienty. Pracoval jsem na internacionalizaci nástrojů pro podporu v reálném čase a lokalizaci znalostní báze.

Lilith Games (Čína, Japonsko, Korea, USA, EU) logo

Lilith Games (Čína, Japonsko, Korea, USA, EU)

Vydavatel mobilních her s globální distribucí. Řešil jsem lokalizaci obsahu a regionální platformové požadavky.

Trhy, na které jsem vstoupil:

Východní Asie (Japonsko, Korea, Čína):

CJK typografie, integrace do platformy, podpora vertikálního textu

Jihovýchodní Asie (Thajsko, Vietnam, Indonésie):

Podpora více písem, mobilní očekávání uživatelů.

MENA (arabské regiony):

Požadavky na RTL rozložení, formální vs. hovorový jazyk, kulturní adaptace obsahu

Evropa:

24 úředních jazyků, spuštění produktu ve více zemích

Amerika:

Regionální varianty jazyků (latinskoamerická vs. evropská španělština, brazilská portugalština), bilingvní trhy

Vím, co na těchto trzích funguje a co ne – ne z teorie, ale z dodaných produktů, na které se spoléhají skuteční uživatelé.

Opravme, co se láme.

Nepotřebuješ přednášku, proč je i18n důležité. Potřebuješ někoho, kdo ladil RTL popovery ve 2 ráno, přel se s produktovým týmem o limitech znaků a navrhoval překladové procesy, které skutečně fungují.

Revize architektury a strategie (1–2 týdny):

Řeknu ti, co se rozbije při přidání dalších 3 jazyků, a kolik to bude stát.

Podpora vstupu na trh (4–8 týdnů):

Spouštíte se v Japonsku/MENA/EU a potřebujete odborníky s praxí.

Průběžné partnerství:

Integrované poradenství při škálování z 2 na 20 jazyků

Nezabývám se teorií. Dělám triáž, plány a dodávky.