LINE / Airbnb / Change.org / KakaoTalk

Consultanță pentru internaționalizare: Reparați ce nu funcționează, planificați ce urmează.

Știți deja că i18n este complicat. Am văzut simptomele: layout-uri RTL care cedează, texte în germană care depășesc butoanele, răspunsuri API în limba greșită și traduceri care se desincronizează la câteva săptămâni după lansare. Nu ofer soluții miraculoase. Vă ajut să descâlciți haosul specific în care se află echipa voastră și să construiți sisteme care să nu se defecteze în același mod de două ori.

„Ar fi trebuit să planificăm asta mai devreme"

Taxa de arhitectură pe care o plătiți acum

Ați lansat în engleză. A funcționat. Apoi ați adăugat franceza „doar pentru landing page". Acum sunteți aici pentru că:

Baza dumneavoastră de cod are verificări lang= răspândite în 47 de fișiere.

Managerii de produs întreabă „putem testa variante A/B pentru texte?", iar echipa de inginerie răspunde „nu fără o rescriere"

Aveți trei fluxuri de lucru diferite pentru traduceri și niciunul nu funcționează în mod fiabil.

Ce am observat că nu funcționează:

  • Echipe care petrec peste 6 luni implementând i18n într-o aplicație Next.js, deoarece șirurile de text erau codificate direct în componente
  • Fișierele de traducere care se desincronizează pentru că dezvoltatorii nu știu ce fișier să actualizeze.
  • Perioade de „înghețare a localizării" înainte de lansări, deoarece nimeni nu are încredere în procesul de traducere.
  • Rezistență la modificarea conținutului tradus pentru că fluxul de lucru e extrem de anevoios.

Cum vă pot ajuta:

  • Strategii de refactorizare care vă permit să implementați i18n treptat (fără a cere „opriți totul și rescrieți")
  • Proiectarea procesului pentru menținerea traducerilor sincronizate fără a bloca dezvoltarea.
  • Analize de arhitectură pentru a identifica punctele în care abordarea actuală va eșua la peste 10 limbi.

i18n este arhitectură, nu o funcționalitate. Încercarea de a o adăuga ulterior este ca și cum ați decide că casa dumneavoastră are nevoie de un subsol după ce ați construit-o deja.

Vă ajut să săpați acel subsol – sau să decideți dacă aveți cu adevărat nevoie de unul.

RTL strică totul.

Interfața dvs. nu a fost proiectată pentru arabă, ebraică sau urdu

Ați activat dir="rtl" și ați văzut cum layout-ul se prăbușește:

Meniurile derulante se deschid în direcția nepotrivită
Pictogramele indică direcția greșită
Layout-urile Flexbox se prăbușesc sau creează suprapuneri ciudate.
Tooltip-urile apar în afara ecranului.
Elementele flotante ignoră complet direcția textului

Ce am observat:

  • Sisteme de design cu peste 200 de componente, dintre care doar 12 gestionează corect RTL.
  • Echipe care folosesc float: left în loc de proprietăți logice, generând erori RTL la fiecare funcționalitate nouă.
  • Componente popover și modale care necesită suprascrieri RTL specifice fiecărei componente.
  • Framework-uri care pretind „suport RTL", dar doar inversează direcția layout-ului, stricând logica de plasare.

Cum vă pot ajuta:

  • Migrarea proprietăților logice CSS (margin-inline-start în loc de margin-left).
  • Audituri ale sistemelor de design pentru a identifica problemele RTL înainte de lansare.
  • Ghidare specifică pentru framework-uri (Tailwind, shadcn, MUI) pentru stilizare cu prioritate RTL.

Rezolvarea manuală a erorilor RTL pentru fiecare componentă este nesustenabilă. Transform suportul RTL într-un proces sistematic, nu într-o stingere permanentă de incendii.

„Textul în germană ne-a stricat butonul."

Interfață de utilizator care nu a fost concepută pentru traducere

Engleza se potrivește. Germana nu. Ați presupus că:

Etichetele butoanelor au aproximativ 10 caractere.Numele de utilizator încap într-o coloană de 200px.Mesajele de eroare sunt afișate pe o singură linie

Apoi ați tradus în germană, finlandeză sau thailandeză și ați descoperit următoarele:

Butoanele taie cuvintele la mijloc

Tabele cu derulare orizontală pentru fiecare rând.

Text care se rupe în blocuri ilizibile

Textul non-latin este trunchiat pentru că containerele au lățimi fixe.

Cum vă pot ajuta:

  • Șabloane UI elastice care se adaptează la lungimea conținutului.
  • Planificarea bugetului de caractere (ținând cont că germana se extinde cu 30%, iar thailandeza nu folosește spații)
  • Sisteme tipografice care gestionează CJK, araba și devanagari fără a se defecta.

Vă ajut să construiți o interfață utilizator care să reziste traducerii – înainte să plătiți pentru 10.000 de cuvinte care nu se potrivesc.

Nu aveți nevoie de o lecție despre importanța i18n. Aveți nevoie de cineva care a depanat popover-uri RTL la ora 2 noaptea, s-a certat cu echipa de produs despre bugetul de caractere și a proiectat fluxuri de traducere care chiar funcționează.

Capcanele despre care nu v-a avertizat nimeni

Experiențe din prima linie: echipe care au trecut prin asta

Acestea nu sunt doar teorii. Sunt probleme care au apărut în producție:

Iadul pluralizării

Engleză: „1 element" vs „2 elemente"

Poloneză: „1 przedmiot" / „2 przedmioty" / „5 przedmiotów" (3 forme de plural)

Arabă: 6 forme de plural

Logica dumneavoastră count === 1 ? 'element' : 'elemente' nu mai funcționează.

Haosul legat de date și ore

Ați formatat datele cu toLocaleDateString(). Apoi, utilizatorii din Japonia au văzut „2025年2月9日" în exporturile dumneavoastră CSV, iar Excel s-a blocat.

Nepotrivire de limbă în API

Frontend-ul solicită franceză. API-ul returnează engleză deoarece token-ul de autentificare nu transmite informația de localizare. Acum aveți o interfață cu un amestec de limbi, iar utilizatorii cred că e un bug.

Testare pseudo-localizare

Nu ați testat cu [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30%] înainte de a lansa în producție. Acum site-ul dumneavoastră în poloneză este inutilizabil.

Presupunerea invizibilă

Ați presupus că șirurile de text sunt singurul lucru care necesită traducere. Apoi ați descoperit datele, numerele, valutele, sortarea, căutarea – totul are un comportament specific fiecărui locale.

Cum vă pot ajuta:

  • Implementarea ICU MessageFormat (gestionează pluralurile, genul și contextul)
  • Modele i18n pentru API (negocierea limbii, strategii de rezervă).
  • Procese de control al calității care identifică aceste probleme înaintea agențiilor de traducere.

Fluxul de lucru este partea cea mai dificilă

Cum reușiți să mențineți 8 limbi sincronizate când livrați zilnic?

Ați înțeles tehnologia. Acum vă blocați la proces:

1

Dezvoltatorii integrează codul cu noi șiruri în engleză. Traducerile rămân în urmă cu 2 săptămâni. Utilizatorii văd o interfață pe jumătate tradusă.

2

Nu știți care șiruri de text pot fi șterse în siguranță (sunt folosite? traduse? în proces de traducere la o agenție?).

3

Echipa de produs dorește să actualizeze textul. Nimeni nu știe dacă schimbarea „Trimite" în „Expediază" va strica traducerile în 12 limbi.

4

Fișierele de traducere rămân nesincronizate cu producția săptămâni întregi.

Întrebări pe care mi le pun echipele:

„Ar trebui ca API-ul nostru să returneze conținut tradus sau să lăsăm frontend-ul să se ocupe de asta?"
„Cum gestionăm versiunile traducerilor?"
„Care este sursa de referință: Figma, codul sursă sau instrumentul de traducere?"
„Cum împiedicăm dezvoltatorii să lanseze funcționalități doar în engleză?"

Ce am observat că nu funcționează:

  • Fișiere de traducere adăugate în git care diferă de șirurile de caractere din producție
  • Avertismente precum „Nu modificați fișierul spaniol" pentru că nimeni nu știe ce se poate schimba în siguranță
  • Funcționalități lansate în engleză, apoi traduse după 6 luni (dacă se întâmplă vreodată).

Cum vă pot ajuta:

  • Proiectarea pipeline-ului de traducere (când să folosiți biblioteci i18n, când să folosiți un TMS, când să folosiți IA)
  • Fluxuri de lucru în Git pentru a menține șirurile sursă și traducerile sincronizate.
  • Automatizare care blochează PR-urile dacă șirurile noi nu sunt marcate pentru traducere.

Tehnologia poate fi rezolvată. Fluxul de lucru este obstacolul. Eu creez fluxuri de lucru care nu necesită eforturi supraomenești pentru a fi menținute.

Echipele cu care am colaborat

Produse globale, expertiză regională

LINE (Japonia, Taiwan, Thailanda) logo

LINE (Japonia, Taiwan, Thailanda)

Platformă de mesagerie activă pe 3 piețe principale din Asia de Est. Am lucrat la provocări specifice legate de gestionarea caracterelor CJK, integrarea în ecosistemul platformei și așteptările utilizatorilor privind experiența, care diferă între Japonia, Taiwan și Thailanda.

KakaoTalk (Coreea de Sud) logo

KakaoTalk (Coreea de Sud)

Platforma principală de mesagerie din Coreea. Am abordat cerințele specifice pieței coreene pentru produs, inclusiv așteptările privind formalitatea limbajului în interfața utilizatorului și nevoile de integrare a platformei.

Change.org (196 de țări, peste 20 de limbi prioritare). logo

Change.org (196 de țări, peste 20 de limbi prioritare).

Platformă globală de petiții unde viteza și calitatea conținutului sunt esențiale. Am optimizat fluxul de traducere pentru conținut politic și social generat de utilizatori pe diverse piețe.

Airbnb (peste 220 de țări, peste 60 de limbi). logo

Airbnb (peste 220 de țări, peste 60 de limbi).

Piață globală cu cerințe complexe de internaționalizare. Am oferit consultanță privind provocările legate de încredere și siguranță în mai multe limbi și adaptarea culturală a conceptelor platformei pe diverse piețe.

Intercom (peste 30 de limbi, SaaS B2B global). logo

Intercom (peste 30 de limbi, SaaS B2B global).

Platformă de comunicare cu clienții care deservește companii enterprise la nivel global. Am contribuit la internaționalizarea produselor pentru instrumente de suport în timp real și la localizarea bazei de cunoștințe.

Lilith Games (China, Japonia, Coreea, SUA, UE) logo

Lilith Games (China, Japonia, Coreea, SUA, UE)

Editor de jocuri mobile cu titluri distribuite la nivel global. Am abordat provocări specifice pieței legate de localizarea conținutului și cerințele regionale ale platformelor.

Piețe în care am lansat:

Asia de Est (Japonia, Coreea, China):

Tipografie CJK, integrare în ecosistemul platformei, suport pentru text vertical

Asia de Sud-Est (Thailanda, Vietnam, Indonezia):

Suport pentru mai multe sisteme de scriere, așteptări ale utilizatorilor orientate spre mobil

MENA (regiuni vorbitoare de arabă):

Cerințe de dispunere RTL, așteptări privind limbajul formal față de cel familiar, adaptarea culturală a conținutului.

Europa:

24 de limbi oficiale, lansări de produse în mai multe țări.

Americile:

Variații regionale de limbă (spaniola din America Latină vs. Spania, portugheza braziliană), piețe bilingve

Am văzut ce funcționează și ce nu pe aceste piețe – nu din teorie, ci din experiența directă de a lansa produse pe care utilizatorii reali le folosesc.

Haideți să reparăm ce nu funcționează.

Nu aveți nevoie de o lecție despre importanța i18n. Aveți nevoie de cineva care a depanat popover-uri RTL la ora 2 noaptea, s-a certat cu echipa de produs despre bugetul de caractere și a proiectat fluxuri de traducere care chiar funcționează.

Revizuire de arhitectură și strategie (1-2 săptămâni):

Vă spun ce se va strica atunci când veți adăuga următoarele 3 limbi și cât va costa remedierea

Suport pentru lansarea pe piață (4-8 săptămâni):

Vă lansați pe piețele din Japonia, MENA sau UE și aveți nevoie de experți care au trecut deja prin astfel de experiențe.

Parteneriat continuu:

Consultanță integrată pe măsură ce vă extindeți de la 2 limbi la 20

Nu mă ocup de teorie. Mă ocup de triaj, roadmap-uri și livrări.