Internacionalizacijos konsultacija: taisome tai, kas neveikia, planuojame ateitį.
Jūs jau žinote, kad internacionalizacija yra sudėtinga. Mačiau požymius: RTL išdėstymai, kurie subyra, vokiškas tekstas, netelpantis mygtukuose, API atsakymai netinkama kalba ir vertimai, kurie išsinchronizuoja vos per kelias savaites po paleidimo. Neparduodu stebuklingų sprendimų. Padėsiu Jums išspręsti konkrečias problemas, kuriose atsidūrė Jūsų komanda, – ir kurti sistemas, kurios nesugrius tuo pačiu būdu antrą kartą.
„Reikėjo tai suplanuoti anksčiau"
Architektūros mokestis, kurį mokate dabar
Jūs paleidote anglų kalba. Pavyko. Tada pridėjote prancūzų kalbą „tik nukreipimo puslapiui". Dabar Jūs čia, nes:
Jūsų kodo bazėje `lang=` patikros išsibarsčiusios per 47 failus
Produktų vadovai klausia „ar galime A/B testuoti tekstą?", o inžinieriai atsako „ne be perrašymo"
Turite tris skirtingas vertimo darbo eigas, ir nė viena iš jų neveikia patikimai
Ką teko matyti sugedus:
- Komandos, praleidusios daugiau nei 6 mėnesius integruodamos i18n į „Next.js" programą, nes eilutės buvo užkoduotos komponentuose.
- Vertimo failai išsiderina, nes kūrėjai nežino, kurį failą reikia atnaujinti.
- „Lokalizacijos įšaldymo" laikotarpiai prieš išleidžiant naujas versijas, nes niekas nepasitiki vertimo procesu.
- Pasipriešinimas keisti išverstą turinį, nes darbo eiga yra tokia skausminga.
Kuo galiu padėti:
- Pertvarkymo strategijos, kurios leidžia palaipsniui diegti i18n (nereikalauju „viską sustabdyti ir perrašyti")
- Proceso kūrimas, užtikrinantis vertimų sinchronizaciją neblokuojant kūrimo.
- Architektūros peržiūros, siekiant nustatyti, kur dabartinis metodas neveiks, kai bus naudojama 10 ir daugiau kalbų.
„i18n" yra architektūra, o ne funkcija. Bandyti ją pridėti vėliau yra tas pats, kas nuspręsti, kad namui reikia rūsio, kai jį jau pastatėte.
Padedu Jums iškasti tą rūsį — arba nuspręsti, ar Jums jo iš tikrųjų reikia.
RTL sugriauna viską.
Jūsų sąsaja nebuvo sukurta arabų, hebrajų ar urdu kalboms.
Įjungėte dir=„rtl" ir stebėjote, kaip Jūsų išdėstymas subyrėjo į šipulius:
Ką mačiau:
- Dizaino sistemos su daugiau nei 200 komponentų, iš kurių tik 12 tinkamai veikia su RTL
- Komandos, naudojančios float: left vietoj loginių savybių ir sukuriančios RTL klaidas kiekvienoje naujoje funkcijoje
- Iššokantieji langai ir modaliniai langai, kuriems reikalingi komponentui pritaikyti RTL perrašymai
- Karkasai, kurie deklaruoja „RTL palaikymą", bet tik apverčia išdėstymo kryptį, o išdėstymo logiką sugadina.
Kuo padedu:
- CSS loginių savybių migravimas (margin-inline-start vietoj margin-left)
- Dizaino sistemų auditai, kad surastumėte RTL sprogmenis prieš išleidžiant
- Konkretiems karkasams pritaikytos gairės (Tailwind, shadcn, MUI), kaip stiliuoti RTL-first principu
Rankiniu būdu taisyti RTL klaidas kiekviename komponente – netvaru. RTL palaikymą paverčiu sisteminiu, o ne nuolatiniu gaisrų gesinimu.
„Vokiškas tekstas sugadino mūsų mygtuką"
Vartotojo sąsaja, nepritaikyta vertimui.
Anglų kalba telpa. Vokiečių – ne. Jūsų dizainas numatė:
Tada vertėte į vokiečių, suomių ar tajų kalbas ir atradote:
Mygtukų tekstas nutrūksta žodžio viduryje
Lentelės su horizontaliuoju slinkimu kiekvienoje eilutėje
Tekstas, suskaidomas į neįskaitomus blokus
Ne lotyniškas tekstas apkerpamas, nes konteineriai turi fiksuotą plotį
Kuo padedu:
- Elastingi UI šablonai, prisitaikantys prie turinio ilgio
- Simbolių biudžeto planavimas (žinant, kad vokiečių kalba išsiplečia 30 %, tajų kalba nenaudoja tarpų)
- Tipografijos sistemos, kurios tvarko KJK, arabų ir devanagario rašmenis be problemų.
Padedu jums kurti vartotojo sąsają, kuri atlaiko vertimą, dar prieš sumokant už 10 000 žodžių, kurie netilps.
Jums nereikia aiškinimų, kodėl internacionalizacija yra svarbi. Reikia specialisto, kuris taisė RTL iškylančius langus 2 val. ryto, diskutavo su produkto komanda dėl simbolių ribų ir sukūrė veiksmingas vertimo sistemas.
Spąstai, apie kuriuos niekas jūsų neįspėjo
Tikros istorijos iš komandų, kurios tai išgyveno
Tai ne teorija. Tai realūs gedimai, pasitaikę gamybinėje aplinkoje:
Daugiskaitos pragaras
Anglų: „1 elementas" ir „2 elementai"
Lenkų: „1 przedmiot" / "2 przedmioty" / „5 przedmiotów" (3 daugiskaitos formos)
Arabų: 6 daugiskaitos formos
Jūsų count === 1 ? 'item' : 'items' logika nebeveikia.
Datų ir laiko chaosas.
Jūs formatavote datas naudodami toLocaleDateString(). Todėl vartotojai Japonijoje savo CSV eksporto failuose matė „2025年2月9日", o „Excel" tiesiog užstrigo.
API kalbos neatitikimas
Jūsų sąsaja prašo prancūzų kalbos. Jūsų API grąžina anglų kalbą, nes autentifikavimo raktas neturi lokalės. Dabar turite mišrios kalbos vartotojo sąsają, o vartotojai mano, kad tai klaida.
Pseudo-lokalės testavimas
Netestavote su [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30%] prieš paleidžiant produkciją. Dabar jūsų lenkiška svetainė neveikia.
Nematoma prielaida
Manėte, kad vertimo reikia tik tekstinėms eilutėms. Tačiau susidūrėte su datomis, skaičiais, valiutomis, rūšiavimu, paieška – viskas priklauso nuo lokalės.
Kuo padedu:
- ICU MessageFormat įgyvendinimas (tvarko daugiskaitas, giminę, kontekstą)
- API i18n šablonai (kalbos derybos, atsarginės strategijos)
- Kokybės užtikrinimo procesai, kurie aptinka šias problemas, kol jų nepastebi vertimo agentūros.
Darbo eiga – sunkiausia dalis
Kaip sinchronizuojate 8 kalbas, kai išleidžiate kasdien?
Jūs išsiaiškinote technologiją. Dabar stringate ties procesu:
Kūrėjai sujungia kodą su naujomis angliškomis eilutėmis. Vertimai atsilieka 2 savaitėmis. Vartotojai mato pusiau išverstą vartotojo sąsają.
Jūs nežinote, kurias eilutes saugu ištrinti (ar jos naudojamos? išverstos? perduotos agentūrai?).
Produkto komanda nori atnaujinti tekstą. Niekas nežino, ar pakeitus „Pateikti" į „Siųsti", tai nesukels problemų 12 kalbų vertimams.
Vertimo failai savaitėmis lieka nesinchronizuoti su gamybos versija.
Klausimai, kuriuos man užduoda komandos:
Ką teko matyti sugedus:
- Vertimo failai, įtraukti į „Git", skiriasi nuo gamybinių eilučių.
- „Nelieskite ispanų kalbos failo" įspėjimai, nes niekas nežino, ką saugu keisti
- Funkcijos, išleistos anglų kalba, išverčiamos tik po 6 mėnesių (jei išvis).
Kuo padedu:
- Vertimo proceso kūrimas (kada naudoti internacionalizacijos bibliotekas, kada vertimo valdymo sistemas, kada DI).
- „Git" darbo procesai, užtikrinantys šaltinio eilučių ir vertimų sinchronizaciją.
- Automatizacija, neleidžianti sujungti kodo pakeitimų, jei naujos eilutės nėra pažymėtos vertimui.
Technologiniai iššūkiai išsprendžiami. Tačiau darbo eiga – tai kliūtis. Kuriu darbo eigas, kurioms palaikyti nereikia didvyriškų pastangų.
Komandos, su kuriomis dirbau
Pasauliniai produktai, regioninė kompetencija
LINE (Japonija, Taivanas, Tailandas)
Žinučių platforma, veikianti 3 pagrindinėse Rytų Azijos rinkose. Sprendžiau iššūkius, susijusius su CJK simbolių apdorojimu, platformos ekosistemos integracija ir vartotojų lūkesčiais, kurie skiriasi Japonijoje, Taivane ir Tailande.
KakaoTalk (Pietų Korėja)
Dominuojanti susirašinėjimo platforma Korėjoje. Sprendžiau Korėjos rinkai būdingus produkto reikalavimus, įskaitant kalbos formalumo lūkesčius vartotojo sąsajoje ir platformos integracijos poreikius.
Change.org (196 šalys, daugiau nei 20 prioritetinių kalbų)
Pasaulinė peticijų platforma, kurioje vienodai svarbūs turinio pateikimo greitis ir kokybė. Padėjau valdyti vartotojų sukurto politinio ir socialinio turinio vertimo procesus įvairiose rinkose.
Airbnb (daugiau nei 220 šalių, daugiau nei 60 kalbų)
Pasaulinė prekyvietė su sudėtingais tarptautiškumo reikalavimais. Konsultuota dėl iššūkių, susijusių su pasitikėjimu ir saugumu keliomis kalbomis bei platformos koncepcijų kultūrine adaptacija įvairiose rinkose.
Intercom (daugiau nei 30 kalbų, pasaulinė B2B SaaS platforma)
Klientų komunikacijos platforma, aptarnaujanti globalias įmones. Sprendžiau produkto internacionalizacijos klausimus realiojo laiko palaikymo įrankiams ir žinių bazės lokalizaciją.
Lilith Games (Kinija, Japonija, Korėja, JAV, ES)
Mobiliųjų žaidimų leidėjas, kurio produktai platinami visame pasaulyje. Sprendė konkrečius rinkos iššūkius, susijusius su turinio lokalizacija ir regioninės platformos reikalavimais.
Rinkos, kuriose paleidau produktus:
Rytų Azija (Japonija, Korėja, Kinija):
CJK tipografija, platformos ekosistemos integravimas, vertikaliojo teksto palaikymas
Pietryčių Azija (Tailandas, Vietnamas, Indonezija):
Kelių rašto sistemų palaikymas, mobiliesiems įrenginiams pritaikyti vartotojų lūkesčiai.
MENA (arabiškai kalbantys regionai):
RTL išdėstymo reikalavimai, formalios ir šnekamosios kalbos lūkesčiai, kultūrinio turinio adaptacija
Europa:
24 oficialios kalbos, produktų paleidimas keliose šalyse
Amerika:
Regioniniai kalbos variantai (Lotynų Amerikos ispanų ir Ispanijos ispanų, Brazilijos portugalų), dvikalbės rinkos
Mačiau, kas veikia ir kas neveikia šiose rinkose – ne iš teorijos, o iš realių produktų, kuriais pasikliauja tikri vartotojai.
Pašalinkime tai, kas genda.
Jums nereikia aiškinimų, kodėl internacionalizacija yra svarbi. Reikia specialisto, kuris taisė RTL iškylančius langus 2 val. ryto, diskutavo su produkto komanda dėl simbolių ribų ir sukūrė veiksmingas vertimo sistemas.
Architektūros ir strategijos peržiūra (1–2 savaitės):
Pasakysiu, kas sulūš, kai pridėsite kitas 3 kalbas, ir kiek kainuos tai ištaisyti
Palaikymas įvedant į rinką (4–8 savaitės):
Paleidžiate Japonijoje/MENA/ES, Jums reikia ekspertų, kurie tai jau darė anksčiau.
Nuolatinė partnerystė:
Integruotas konsultavimas, kai plečiatės nuo 2 kalbų iki 20
Nesiūlau teorijų. Užsiimu prioritetų nustatymu, veiksmų planais ir pristatymu.