Consultoria d'internacionalització: arreglar el que falla, planificar el que ve
Ja sabeu que l'i18n és difícil. N'he vist els símptomes: disposicions RTL que col·lapsen, text en alemany que desborda els botons, respostes d'API en l'idioma equivocat i traduccions que es desincronitzen poques setmanes després del llançament. No venc remedis miraculosos. Us ajudo a desenredar l'embolic concret en què es troba el vostre equip —i a construir sistemes que no es trenquin de la mateixa manera dues vegades.
«Hauríem d'haver planificat això abans»
El cost d'arquitectura que esteu pagant ara
Vau llançar en anglès. Va funcionar. Després vau afegir francès «només per a la pàgina de destinació». Ara sou aquí perquè:
La vostra base de codi té comprovacions de lang= escampades per 47 fitxers
Els gestors de producte pregunten: podem fer proves A/B amb els textos? i enginyeria respon: no sense reescriure-ho tot.
Té tres fluxos de treball de traducció diferents i cap no funciona de manera fiable
El que he vist petar:
- Equips que passen més de 6 mesos adaptant la i18n a una aplicació Next.js perquè les cadenes estaven incrustades als components
- Els fitxers de traducció es desincronitzen perquè els desenvolupadors no saben quin fitxer han d'actualitzar
- Períodes de «congelació de la localització» abans dels llançaments perquè ningú no confia en el procés de traducció
- Resistència a modificar qualsevol contingut traduït perquè el flux de treball és tan feixuc
En què ajudo:
- Estratègies de refactorització que us permeten adoptar l'i18n de manera incremental (no exigeixo «parar-ho tot i reescriure»)
- Disseny de processos per mantenir les traduccions sincronitzades sense bloquejar el desenvolupament
- Revisions d'arquitectura per identificar on el vostre enfocament actual fallarà amb més de 10 idiomes
La i18n és arquitectura, no una funcionalitat. Intentar afegir-la més tard és com decidir que casa vostra necessita un soterrani quan ja l'heu construïda.
Us ajudo a cavar aquest soterrani… o a decidir si realment en necessiteu un.
L'RTL ho trenca tot
La vostra interfície d'usuari no va ser dissenyada per a l'àrab, l'hebreu o l'urdú
Heu canviat dir=«rtl» i heu vist com la disposició s'esmicolava:
El que he vist:
- Sistemes de disseny amb més de 200 components dels quals només 12 gestionen correctament l'RTL
- Equips que utilitzen float: left en lloc de propietats lògiques, generant errors RTL a cada funcionalitat nova
- Popovers i modals que necessiten sobreescriptures RTL específiques per a cada component
- Frameworks que diuen ser compatibles amb RTL però que només inverteixen la direcció del disseny i trenquen la lògica de posicionament.
En què ajudo:
- Migració a propietats lògiques CSS (margin-inline-start en lloc de margin-left)
- Auditories del sistema de disseny per detectar problemes RTL abans del llançament
- Guia específica per a cada framework (Tailwind, shadcn, MUI) per a estils RTL-first
Corregir manualment errors RTL a cada component no és sostenible. Faig que el suport RTL sigui sistemàtic, no un apagafocs constant.
«El text en alemany ens ha trencat el botó»
una IU que no es va dissenyar per a la traducció
L'anglès encaixa. L'alemany no. El vostre disseny donava per fet:
Aleshores vas traduir a alemany, finès o tailandès i vas descobrir:
Botons retallats a meitat de paraula
Taules amb desplaçament horitzontal a cada fila
Text que s'embolica en blocs il·legibles
El text no llatí es retalla perquè els contenidors tenen amplades fixes
En què ajudo:
- Patrons d'IU elàstics que s'adapten a la longitud del contingut
- Planificació del pressupost de caràcters (sabent que l'alemany s'expandeix un 30 % i que el tailandès no fa servir espais)
- Sistemes tipogràfics que gestionen CJK, àrab i devanagari sense petar
Us ajudo a crear una IU que sobrevisqui a la traducció, abans que hàgiu pagat per 10.000 paraules que no hi caben.
No necessiteu una xerrada sobre per què la i18n és important. Necessiteu algú que hagi depurat finestres emergents RTL a les 2 del matí, hagi discutit amb producte sobre els límits de caràcters i hagi dissenyat fluxos de traducció que funcionin de veritat.
Els paranys de què ningú no us va advertir
Històries de guerra d'equips que ja hi han passat
Això no és teòric. Són coses que han petat en producció:
L'infern de la pluralització
Anglès: «1 item» vs «2 items»
Polonès: «1 przedmiot» / "2 przedmioty" / «5 przedmiotów» (3 formes de plural)
Àrab: 6 formes de plural
La vostra lògica count === 1 ? 'element' : 'elements' ja no funciona.
Caos de la data i l'hora
Vau formatar les dates amb toLocaleDateString(). Llavors, els usuaris al Japó van veure «2025年2月9日» a les seves exportacions CSV i l'Excel va fallar.
Desajust d'idioma de l'API
El vostre frontend sol·licita francès. La vostra API retorna anglès perquè el testimoni d'autenticació no inclou la configuració regional. Resultat: una interfície amb idiomes barrejats i uns usuaris que pensen que és un error.
Proves amb pseudolocalització
No vau fer proves amb [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30 %] abans de passar a producció. Ara el vostre lloc web polonès és inutilitzable.
La suposició invisible
Vau assumir que les cadenes eren l'única cosa que calia traduir. Després us vau trobar amb dates, nombres, monedes, ordenació, cerca… tot té un comportament específic segons la configuració regional.
En què ajudo:
- Implementació d'ICU MessageFormat (gestiona plurals, gènere i context).
- Patrons d'i18n de l'API (negociació d'idioma, estratègies de reserva)
- Processos de control de qualitat que detecten aquests problemes abans que ho facin les agències de traducció
El flux de treball és la part difícil.
Com manteniu 8 idiomes sincronitzats si publiqueu cada dia?
Ja domineu la tecnologia. Ara esteu encallats en el procés:
Els desenvolupadors fusionen codi amb cadenes noves en anglès. Les traduccions s'endarrereixen 2 setmanes. Els usuaris veuen una IU mig traduïda.
No sabeu quines cadenes es poden eliminar amb seguretat (s'utilitzen? estan traduïdes? estan en curs amb una agència?)
El producte vol actualitzar el text. Ningú no sap si canviar «Submit» per «Send» afectarà 12 idiomes.
Els fitxers de traducció estan desincronitzats amb la producció durant setmanes
Preguntes que els equips em fan:
El que he vist petar:
- Fitxers de traducció al Git que divergeixen de les cadenes de producció
- Avisos de «no toqueu el fitxer d'espanyol» perquè ningú sap què es pot canviar sense risc
- Funcionalitats llançades en anglès i traduïdes 6 mesos després (si és que arriben a traduir-se)
En què ajudo:
- Disseny del flux de traducció (quan cal utilitzar biblioteques i18n, quan cal utilitzar TMS, quan cal utilitzar IA)
- Fluxos de treball de Git per mantenir sincronitzades les cadenes d'origen i les traduccions
- Automatització que bloqueja les PR si les cadenes noves no estan marcades per traduir
La tecnologia té solució. El flux de treball és l'obstacle. Dissenyo fluxos de treball que no requereixen esforços heroics per mantenir-se.
Equips amb els quals he treballat
Productes globals, expertesa regional
LINE (Japan, Taiwan, Thailand)
Plataforma de missatgeria que opera en 3 mercats principals de l'Àsia Oriental. Va treballar en reptes específics de la gestió de caràcters CJK, la integració amb l'ecosistema de la plataforma i les expectatives d'experiència d'usuari que varien entre el Japó, Taiwan i Tailàndia.
KakaoTalk (South Korea)
Plataforma de missatgeria dominant a Corea. Es van abordar requisits de producte específics del mercat coreà, com ara les expectatives de formalitat lingüística a la interfície d'usuari i les necessitats d'integració amb la plataforma.
Change.org (196 countries, 20+ priority languages)
Plataforma de peticions global on la velocitat i la qualitat del contingut són importants. Va ajudar a gestionar el flux de treball de traducció per al contingut polític i social generat pels usuaris en diversos mercats.
Airbnb (220+ countries, 60+ languages)
Mercat global amb requisits complexos d'i18n. Es va assessorar sobre els reptes de confiança i seguretat en diversos idiomes i l'adaptació cultural dels conceptes de la plataforma a diferents mercats.
Intercom (30+ languages, global B2B SaaS)
Plataforma de comunicació amb el client que serveix clients empresarials globals. Va treballar en la internacionalització de productes per a eines de suport en temps real i la localització de la base de coneixement.
Lilith Games (China, Japan, Korea, US, EU)
Editorial de jocs mòbils amb títols distribuïts arreu del món. Vam resoldre reptes específics de cada mercat relacionats amb la localització de contingut i els requisits de plataforma regionals.
Mercats on he llançat:
Àsia Oriental (Japó, Corea, Xina):
Tipografia CJK, integració de l'ecosistema de la plataforma, suport de text vertical
Sud-est Asiàtic (Tailàndia, Vietnam, Indonèsia):
Suport multiescript i expectatives dels usuaris amb prioritat mòbil.
MENA (regions de parla àrab):
Requisits de disposició RTL, expectatives d'idioma formal vs. col·loquial, adaptació cultural del contingut
Europa:
24 idiomes oficials, llançaments de producte en diversos països
Amèriques:
Variacions regionals d'idioma (espanyol de Llatinoamèrica vs. Espanya, portuguès brasiler), mercats bilingües
He vist què funciona i què falla en aquests mercats, no des de la teoria, sinó des de l'experiència de llançar productes dels quals depenen usuaris reals.
Arreglem el que està petant
No necessiteu una xerrada sobre per què la i18n és important. Necessiteu algú que hagi depurat finestres emergents RTL a les 2 del matí, hagi discutit amb producte sobre els límits de caràcters i hagi dissenyat fluxos de traducció que funcionin de veritat.
Revisió d'arquitectura i estratègia (1-2 setmanes):
Us dic què es trencarà quan afegiu els vostres pròxims 3 idiomes, i què costarà arreglar-ho
Suport per al llançament al mercat (4-8 setmanes):
Esteu llançant al Japó/MENA/EU i necessiteu experts que ja ho hagin fet abans
Col·laboració continuada:
Consultoria integrada mentre escaleu de 2 idiomes a 20
No faig teoria. Faig triatge, fulls de ruta i lliuraments.