Rahvusvahelistamise konsultatsioon: Parandage see, mis katkeb, planeerige see, mis tuleb järgmisena
Te juba teate, et i18n on raske. Olen näinud sümptomeid: RTLi paigutused, mis vajuvad kokku, saksa tekst, mis voolab nuppudest üle, API vastused vales keeles ja tõlked, mis lähevad käivitamise järel nädalate jooksul sünkroonist välja. Ma ei müü imeravimeid. Aitan teil lahti harutada selle konkreetse sasipuntra, milles teie meeskond on — ja ehitada süsteeme, mis ei katke samal viisil kaks korda.
„Me oleksime pidanud seda varem planeerima"
Arhitektuurimaks, mida Te praegu maksate
Te käivitasite inglise keeles. See töötas. Siis lisasite prantsuse keele „ainult maandumislehe jaoks". Nüüd olete siin, sest:
Teie koodibaasis on lang= kontrollid laiali 47 failis
Tootejuhid küsivad „kas me saame A/B-testida teksti?" ja arendus ütleb „mitte ilma ümberkirjutuseta"
Teil on kolm erinevat tõlketöövoogu ja ükski neist ei tööta usaldusväärselt
Mida ma olen näinud katkemas:
- Tiimid, kes kulutavad 6+ kuud i18n-i järelepaigaldamisele Next.js-i rakendusse, sest string'id olid komponentidesse kõvakodeeritud
- Tõlkefailid lähevad sünkroonist välja, sest arendajad ei tea, millist faili uuendada
- „Lokaliseerimise külmutamise" perioodid enne väljalaskeid, sest keegi ei usalda tõlketöövoogu
- Vastuseis mis tahes tõlgitud sisu muutmisele, sest töövoog on nii valus
Millega ma aitan:
- Refaktoreerimisstrateegiad, mis lasevad teil i18n-i kasutuselevõttu järk-järgult teha (ma ei nõua „peatage kõik ja kirjutage ümber")
- Protsessidisain, et hoida tõlked sünkroonis ilma arendust blokeerimata
- Arhitektuuri ülevaated, et tuvastada, kus teie praegune lähenemine katkestama hakkab 10+ keele juures
i18n on arhitektuur, mitte funktsioon. Selle hiljem lisamine on nagu otsustamine, et teie majal on vaja keldrit pärast seda, kui olete selle juba ehitanud.
Ma aitan teil selle keldri kaevata—või otsustada, kas te seda üldse vajate.
RTL katkestab kõik
Teie kasutajaliides ei olnud disainitud araabia, heebrea ega urdu keele jaoks
Te vahetasite dir=„rtl" ja vaatasite, kuidas teie paigutus plahvatas:
Mida ma olen näinud:
- Disainisüsteemid 200+ komponendiga, kus ainult 12 käsitlevad RTL korralikult
- Meeskonnad, kes kasutavad loogiliste omaduste asemel float: left, luues igas uues funktsioonis RTL vead
- Hüpikaknad ja modaalaknad, mis nõuavad komponendipõhiseid RTL ülekirjutusi
- Raamistikud, mis väidavad, et neil on „RTL tugi", kuid mis ainult pööravad paigutuse suunda ümber ja katkestavad paigutusloogika
Millega ma aitan:
- CSS-i loogiliste omaduste migratsioon (margin-inline-start margin-left'i asemel)
- Disainisüsteemi auditid, et leida RTL miinid enne, kui need välja saadetakse
- Raamistikupõhised juhised (Tailwind, shadcn, MUI) RTL-eelistusega stiilimise jaoks
RTL vigade käsitsi parandamine igas komponendis ei ole jätkusuutlik. Muudan RTL toe süsteemseks, mitte pidevaks tulekustutamiseks.
„Saksa tekst rikkus meie nupu"
Kasutajaliides, mida ei ehitatud tõlkimiseks
Inglise keel mahub ära. Saksa keel mitte. Teie disain eeldas:
Siis tõlkisite saksa, soome või tai keelde ja avastasite:
Nupud lõigatakse sõna keskelt pooleks
Tabelid, kus igal real tekib horisontaalne kerimine
Tekst, mis murrab loetamatuteks plokkideks
Mitteladina tekst kärbitakse, sest konteineritel on fikseeritud laius
Millega ma aitan:
- Elastsed UI-mustrid, mis painduvad sisu pikkuse järgi
- Märgieelarve planeerimine (teadmine, et saksa keel laieneb 30 %, tai keeles ei kasutata tühikuid)
- Tüpograafiasüsteemid, mis käsitlevad CJK-d, araabia ja devanagari kirja ilma katkemata
Aitan teil ehitada kasutajaliidest, mis peab tõlkimisele vastu — enne, kui olete maksnud 10,000 sõna eest, mis ei mahu.
Te ei vaja loengut sellest, miks i18n on oluline. Te vajate kedagi, kes on silunud RTL hüpikaknaid kell 2 hommikul, vaielnud tootetiimiga märgipiirangute üle ja kujundanud tõlketöövood, mis päriselt töötavad
Varjatud ohud, mille eest keegi ei hoiatanud
Kogemused meeskondadelt, kes on selle läbi teinud
Need pole teoreetilised. Need on asjad, mis tootmises katki läksid:
Mitmusepõrg
Inglise keeles: „1 üksus" ja „2 üksust"
Poola: „1 przedmiot" / "2 przedmioty" / „5 przedmiotów" (3 mitmusevormi)
Araabia: 6 mitmusevormi
Teie count === 1 ? 'üksus' : 'üksused' loogika ei tööta enam
Kuupäeva/aja kaos
Te vormistasite kuupäevad toLocaleDateString(). Siis nägid Jaapani kasutajad teie CSV-eksportides „2025年2月9日" ja Excel läks umbe.
API keele mittevastavus
Teie frontend küsib prantsuse keelt. Teie API tagastab inglise keele, sest autentimistõend ei kanna lokaati. Nüüd on teil segakeelne kasutajaliides ja kasutajad mõtlevad, et see on viga.
Pseudolokaadi testimine
Te ei testinud enne tootmisse minekut tekstiga [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30 %]. Nüüd on teie Poola sait kasutuskõlbmatu.
Nähtamatu eeldus
Te eeldasite, et stringid on ainus asi, mis vajab tõlkimist. Siis jõudsite kuupäevade, numbrite, valuutade, sortimise, otsingu juurde — kõige juurde, millel on lokaadipõhine käitumine.
Millega ma aitan:
- ICU MessageFormati teostus (käsitleb mitmuseid, sugu, konteksti)
- API i18n mustrid (keeleläbirääkimine, varustrateegiad)
- QA-protsessid, mis tabavad need probleemid enne, kui tõlkeagentuurid seda teevad
Töövoog on raske osa
Kuidas hoiate 8 keelt sünkroonis, kui saadate iga päev välja?
Te olete tehnoloogia selgeks saanud. Nüüd olete protsessis kinni:
Arendajad ühendavad koodi uute ingliskeelsete stringidega. Tõlked jäävad 2 nädala võrra maha. Kasutajad näevad pooleldi tõlgitud kasutajaliidest.
Te ei tea, milliseid string'e on ohutu kustutada (kas neid kasutatakse? tõlgitakse? on agentuuriga pooleli?)
Toode tahab teksti uuendada. Keegi ei tea, kas „Submit" muutmine „Send"-iks katkestama paneb 12 keelt.
Tõlkefailid on tootmisega nädalaid korraga sünkroonist väljas
Küsimused, mida tiimid minult küsivad:
Mida ma olen näinud katkemas:
- Git'i commit'itud tõlkefailid, mis lahknevad tootmises olevatest stringidest.
- „Ärge puudutage hispaaniakeelset faili" hoiatused, sest keegi ei tea, mida on ohutu muuta
- Funktsioonid käivitati inglise keeles, seejärel tõlgiti 6 kuud hiljem (kui üldse)
Millega ma aitan:
- Tõlkeahela disain (millal kasutada i18n teeke, millal kasutada TMS-i, millal kasutada AI-d)
- Git'i töövood lähte-string'ide ja tõlgete sünkroonis hoidmiseks
- Automatiseerimine, mis takistab PR-e, kui uued stringid pole tõlkimiseks märgitud.
Tehnoloogia on lahendatav. Töövoog on takistus. Ma disainin töövooge, mis ei nõua hooldamiseks kangelastegusid.
Meeskonnad, kellega olen koostööd teinud
Globaalsed tooted, piirkondlik asjatundlikkus
LINE (Jaapan, Taiwan, Tai)
Sõnumiplatvorm, mis tegutseb 3 peamisel Ida-Aasia turul. Töötasin CJK märkide käsitlemisele omaste väljakutsete, platvormi ökosüsteemi integreerimise ja kasutajakogemuse ootustega, mis erinevad Jaapanis, Taiwanis ja Tais.
KakaoTalk (Lõuna-Korea)
Korea domineeriv sõnumsideplatvorm. Lahendas Korea turu spetsiifilised tootenõuded, sealhulgas keele formaalsusootused kasutajaliideses ja platvormi integreerimisvajadused.
Change.org (196 riiki, 20+ prioriteetset keelt)
Globaalne petitsiooniplatvorm, kus nii sisu kiirus kui ka kvaliteet loevad. Aitas orienteeruda tõlketöövoos kasutajate loodud poliitilise/sotsiaalse sisu jaoks eri turgudel.
Airbnb (220+ riiki, 60+ keelt)
Globaalne turg keerukate i18n-nõuetega. Konsulteerisin mitmes keeles usalduse/ohutusega seotud väljakutsete ning platvormikontseptsioonide kultuurilise kohandamise osas eri turgudel.
Intercom (30+ keelt, globaalne B2B SaaS)
Kliendisuhtlusplatvorm, mis teenindab ülemaailmseid ettevõtte kliente. Töötasin toote rahvusvahelistamise kallal pärisajatoe tööriistade ja teadmistebaasi lokaliseerimise jaoks.
Lilith Games (Hiina, Jaapan, Korea, USA, EL)
Mobiilimängude kirjastaja, kelle mängud on levitatud üle maailma. Lahendas turuspetsiifilised väljakutsed seoses sisu lokaliseerimise ja piirkondlike platvorminõuetega.
Turud, kus olen tooteid turule toonud:
Ida-Aasia (Jaapan, Korea, Hiina):
CJK tüpograafia, platvormi ökosüsteemi integratsioon, vertikaalse teksti tugi
Kagu-Aasia (Tai, Vietnam, Indoneesia):
Mitme kirjasüsteemi tugi, mobiiliesmase kasutaja ootused
MENA (araabiakeelsed piirkonnad):
RTL paigutusnõuded, formaalse vs. kõnekeelse keele ootused, sisu kultuuriline kohandamine
Euroopa:
24 ametlikku keelt, mitme riigi tootekäivitamised
Ameerikad:
Piirkondlikud keelevariatsioonid (Ladina-Ameerika hispaania vs Hispaania, Brasiilia portugali), kakskeelsed turud
Olen näinud, mis töötab ja mis nendel turgudel läbi kukub—mitte teooriast, vaid toodete turule toomisest, millest päris kasutajad sõltuvad.
Parandame selle, mis katkeb
Te ei vaja loengut sellest, miks i18n on oluline. Te vajate kedagi, kes on silunud RTL hüpikaknaid kell 2 hommikul, vaielnud tootetiimiga märgipiirangute üle ja kujundanud tõlketöövood, mis päriselt töötavad
Arhitektuuri ja strateegia ülevaade (1–2 nädalat):
Ma ütlen teile, mis katki läheb, kui lisate oma järgmised 3 keelt, ja kui palju selle parandamine maksma läheb
Turu käivitamise tugi (4–8 nädalat):
Te käivitate Jaapanis/MENA/EU ja vajate eksperte, kes on seda varem teinud
Jätkuv partnerlus:
Manustatud nõustamine, kui skaleerite 2 keelest 20 keeleni
Ma ei tegele teooriaga. Ma tegelen triaažiga, teekaartidega ja väljalasetega.