Posvetovanje o internacionalizaciji: popravite, kar odpoveda, načrtujte, kaj sledi
Že veste, da je i18n zahteven. Videl sem simptome: postavitve z desne proti levi, ki se sesujejo, nemško besedilo, ki prekorači gumbe, odzivi API-ja v napačnem jeziku in prevodi, ki v tednih po zagonu izgubijo sinhronizacijo. Ne prodajam čudežnih rešitev. Pomagam Vam razplesti specifičen kaos, v katerem je Vaša ekipa — in zgraditi sisteme, ki se ne bodo zlomili na enak način dvakrat.
»To bi morali načrtovati prej«
Davek na arhitekturo, ki ga plačujete že zdaj
Zagnali ste v angleščini. Delovalo je. Potem ste dodali francoščino »samo za pristajalno stran«. Zdaj ste tukaj, ker:
Vaša kodna baza ima preverjanja lang= razpršena po 47 datotekah
Produktni vodje vprašajo »ali lahko A/B testiramo besedilo?«, inženiring pa odgovori »ne brez ponovnega pisanja«.
Imate tri različne poteke dela za prevajanje in noben od njih ne deluje zanesljivo
Kaj sem videl odpovedati:
- Ekipe, ki porabijo več kot 6 mesecev za naknadno vgradnjo i18n v aplikacijo Next.js, ker so bili nizi trdo kodirani v komponentah
- Prevodne datoteke se razhajajo, ker razvijalci ne vedo, katero datoteko posodobiti.
- »Zamrznitev lokalizacije« pred izdajami, ker nihče ne zaupa prevodnemu procesu.
- Odpor do spreminjanja katere koli prevedene vsebine, ker je delovni proces tako boleč.
Pri čem pomagam:
- Strategije refaktoriranja, ki Vam omogočajo postopno uvajanje i18n (ne zahtevam, da »ustavite vse in prepišete«)
- Zasnova procesa za ohranjanje usklajenosti prevodov brez blokiranja razvoja.
- Pregledi arhitekture za ugotavljanje, kje bo Vaš trenutni pristop odpovedal pri 10+ jezikih
i18n je arhitektura, ne funkcionalnost. Dodajati jo pozneje je, kot da bi se odločili, da vaša hiša potrebuje klet, ko ste jo že zgradili.
Pomagam Vam izkopati to klet – ali pa se odločiti, ali jo sploh potrebujete.
RTL poruši vse
Vaš uporabniški vmesnik ni bil zasnovan za arabščino, hebrejščino ali urdujščino
Preklopili ste na dir="rtl" in opazovali, kako se Vaša postavitev podre:
Kar sem videl:
- Sistemi oblikovanja z več kot 200 komponentami, od katerih le 12 pravilno podpira RTL
- Ekipe, ki namesto logičnih lastnosti uporabljajo float: left in tako povzročajo napake RTL v vsaki novi funkcionalnosti
- Pojavna in modalna okna, ki zahtevajo preglasitve RTL za posamezne komponente
- Ogrodja, ki trdijo, da imajo »podporo za RTL«, a v resnici samo obrnejo smer postavitve in pri tem porušijo logiko pozicioniranja
Pri čem pomagam:
- Migracija logičnih lastnosti CSS (margin-inline-start namesto margin-left)
- Revizije sistema oblikovanja za odkrivanje skritih napak RTL pred objavo
- Smernice za posamezna ogrodja (Tailwind, shadcn, MUI) za oblikovanje z načelom RTL na prvem mestu
Ročno odpravljanje napak RTL v vsaki komponenti je nevzdržno. Poskrbim, da je podpora za RTL sistematična – ne pa nenehno gašenje požarov.
»Nemško besedilo nam je pokvarilo gumb«
Uporabniški vmesnik, ki ni bil zasnovan za prevajanje.
Angleščina se prilega. Nemščina ne. Vaše oblikovanje je predpostavljalo:
Nato ste prevedli v nemščino, finščino ali tajščino in ugotovili:
Gumbi, odrezani sredi besede
Tabele z vodoravnim drsenjem v vsaki vrstici
Besedilo, ki se prelomi v neberljive bloke
Nelatinsko besedilo se odreže, ker imajo vsebniki fiksne širine
Pri čem pomagam:
- Prilagodljivi vzorci uporabniškega vmesnika, ki se prilagodijo dolžini vsebine
- Načrtovanje proračuna znakov (vedenje, da se nemščina razširi za 30 %, tajščina pa ne uporablja presledkov)
- Tipografski sistemi, ki obvladajo pisave CJK, arabsko in devanagarsko pisavo brez težav
Pomagam Vam zasnovati uporabniški vmesnik, ki prenese prevajanje – preden plačate za 10.000 besed, ki se ne prilegajo.
Ne potrebujete predavanja o tem, zakaj je i18n pomemben. Potrebujete nekoga, ki je ob 2 zjutraj odpravljal napake v pojavnih oknih za RTL, se prepiral z oddelkom za izdelke glede omejitev števila znakov in zasnoval prevajalske cevovode, ki dejansko delujejo.
Pasti, na katere Vas nihče ni opozoril
Zgodbe iz prakse ekip, ki so to že izkusile
To niso teoretični primeri. To so stvari, ki so odpovedale v produkciji:
Pekel množine
Angleščina: „1 element" in „2 elementi"
Poljščina: „1 przedmiot" / „2 przedmioty" / „5 przedmiotów" (3 množinskih oblik)
Arabščina: 6 množinskih oblik
Vaša logika count === 1 ? 'item' : 'items' ne deluje več.
Zmeda z datumi in časi
Datume ste oblikovali z toLocaleDateString(). Potem so uporabniki na Japonskem v Vaših izvozih CSV videli »2025年2月9日«, Excel pa se je sesul.
Neujemanje jezika v API-ju
Vaš vmesnik zahteva francoščino. API vrne angleščino, ker avtentikacijski žeton ne vsebuje podatka o jeziku. Rezultat: vmesnik z mešanimi jeziki, uporabniki pa mislijo, da gre za napako.
Psevdo-lokalizacijsko testiranje
Niste testirali z [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30 %], preden ste šli v produkcijo. Zdaj je Vaša poljska stran neuporabna.
Nevidna predpostavka
Predvidevali ste, da so nizi edina stvar, ki jo je treba prevesti. Potem ste naleteli na datume, številke, valute, razvrščanje, iskanje – vse ima vedenje, značilno za jezikovno okolje.
Pri čem pomagam:
- Implementacija ICU MessageFormat (obravnava množine, spola in konteksta)
- Vzorci i18n za API (dogovarjanje o jeziku, strategije nadomestnega delovanja)
- Procesi zagotavljanja kakovosti, ki te težave odkrijejo, preden jih odkrijejo prevajalske agencije.
Potek dela je najtežji del
Kako ohraniti 8 jezikov usklajenih, če objavljate vsak dan?
Tehnologijo ste že obvladali. Zdaj ste obtičali pri postopku:
Razvijalci združijo kodo z novimi angleškimi nizi. Prevodi zaostajajo 2 tednov. Uporabniki vidijo napol preveden uporabniški vmesnik.
Ne veste, katere nize je varno izbrisati (ali se uporabljajo? so prevedeni? so pri agenciji v obdelavi?).
Oddelek za izdelke želi posodobiti besedilo. Nihče ne ve, ali bo sprememba iz »Oddaj« v »Pošlji« pokvarila 12 jezikov.
Prevodne datoteke so tedne zapored neusklajene s produkcijo
Vprašanja, ki mi jih zastavljajo ekipe:
Kaj sem videl odpovedati:
- Prevodne datoteke v repozitoriju git, ki se razlikujejo od produkcijskih nizov
- Opozorila tipa »ne dotikaj se španske datoteke«, ker nihče ne ve, kaj je varno spremeniti
- Funkcionalnosti, zagnane v angleščini, nato prevedene 6 mesecev kasneje (če sploh).
Pri čem pomagam:
- Zasnova prevodnega cevovoda (kdaj uporabiti knjižnice i18n, kdaj TMS, kdaj umetno inteligenco)
- Poteki dela v Gitu za ohranjanje usklajenosti izvornih nizov in prevodov
- Avtomatizacija, ki blokira zahtevke za združitev, če novi nizi niso označeni za prevod
Tehnologija je rešljiva. Potek dela je ovira. Oblikujem poteke dela, ki ne zahtevajo herojskih podvigov za vzdrževanje.
Ekipe, s katerimi sem sodeloval
Globalni izdelki, regionalno strokovno znanje
LINE (Japonska, Tajvan, Tajska)
Platforma za sporočanje, ki deluje na 3 ključnih vzhodnoazijskih trgih. Ukvarjal sem se z izzivi, značilnimi za obravnavo znakov CJK, integracijo v ekosistem platforme ter pričakovanji glede uporabniške izkušnje, ki se med Japonsko, Tajvanom in Tajsko razlikujejo.
KakaoTalk (Južna Koreja)
Prevladujoča platforma za sporočanje v Koreji. Obravnavane so bile zahteve za izdelke, značilne za korejski trg, vključno s pričakovanji glede jezikovne formalnosti v uporabniškem vmesniku in potrebami po integraciji s platformo.
Change.org (196 držav, več kot 20 prednostnih jezikov)
Globalna peticijska platforma, kjer sta hitrost objave vsebin in kakovost enako pomembni. Pomagali smo pri vzpostavitvi prevodnega poteka dela za uporabniško ustvarjeno politično in družbeno vsebino na raznolikih trgih.
Airbnb (več kot 220 držav, več kot 60 jezikov)
Globalna tržnica s kompleksnimi zahtevami za internacionalizacijo (i18n). Svetovanje pri izzivih na področju zaupanja in varnosti v več jezikih ter kulturna prilagoditev konceptov platforme na različnih trgih.
Intercom (več kot 30 jezikov, globalni B2B SaaS)
Komunikacijska platforma za stranke, namenjena globalnim podjetjem. Ukvarjal sem se z internacionalizacijo izdelkov za orodja za podporo v realnem času in z lokalizacijo baze znanja.
Lilith Games (Kitajska, Japonska, Koreja, ZDA, EU)
Založnik mobilnih iger z naslovi, distribuiranimi po vsem svetu. Reševal sem tržno specifične izzive pri lokalizaciji vsebin in zahtevah regionalnih platform.
Trgi, na katerih sem izvajal zagon:
Vzhodna Azija (Japonska, Koreja, Kitajska):
Tipografija CJK, integracija v ekosistem platforme, podpora za navpično besedilo
Jugovzhodna Azija (Tajska, Vietnam, Indonezija):
Podpora za več pisav, pričakovanja uporabnikov z mobilnostjo na prvem mestu
MENA (arabsko govoreče regije):
Zahteve za postavitev od desne proti levi (RTL), pričakovanja glede formalnega in pogovornega jezika, kulturna prilagoditev vsebine
Evropa:
24 uradnih jezikov, zagon izdelkov v več državah
Amerike:
Regionalne jezikovne različice (latinskoameriška španščina proti evropski, brazilska portugalščina), dvojezični trgi
Videl sem, kaj deluje in kaj ne – ne iz teorije, temveč iz izkušenj z izdelki, na katere se resnični uporabniki zanašajo.
Popravimo, kar odpoveda
Ne potrebujete predavanja o tem, zakaj je i18n pomemben. Potrebujete nekoga, ki je ob 2 zjutraj odpravljal napake v pojavnih oknih za RTL, se prepiral z oddelkom za izdelke glede omejitev števila znakov in zasnoval prevajalske cevovode, ki dejansko delujejo.
Pregled arhitekture in strategije (1–2 tedna):
Povem Vam, kaj se bo pokvarilo, ko dodate naslednjih 3 jezikov, in koliko bo stalo, da to popravite
Podpora pri vstopu na trg (4–8 tednov):
Vstopate na japonski trg/MENA/EU in potrebujete strokovnjake, ki so to že počeli
Dolgoročno partnerstvo:
Vgrajeno svetovanje pri rasti z 2 jezikov na 20
Ne ukvarjam se s teorijo. Ukvarjam se s triažo, načrti in dostavo.