Consultoría de internacionalización: corregir lo que falla, planificar lo que viene
Ya sabes que la i18n es difícil. He visto los síntomas: diseños RTL que se desmoronan, texto en alemán que desborda los botones, respuestas de la API en el idioma equivocado y traducciones que se desincronizan a las pocas semanas del lanzamiento. No vendo soluciones mágicas. Te ayudo a desenredar el lío concreto en el que se encuentra tu equipo y a crear sistemas que no se rompan de la misma forma dos veces.
«Deberíamos haber planificado esto antes»
El peaje de la arquitectura que estás pagando ahora mismo
Lanzaste tu producto en inglés. Funcionó. Luego añadiste francés «solo para la página de inicio». Ahora estás aquí porque:
Tu base de código tiene comprobaciones de lang= dispersas en 47 archivos
Los gestores de producto preguntan «¿podemos hacer pruebas A/B del texto?» y los de ingeniería responden «no sin reescribirlo todo».
Tienes tres flujos de trabajo de traducción distintos y ninguno funciona de forma fiable.
Lo que he visto fallar:
- Equipos que pasan más de 6 meses adaptando i18n a una aplicación Next.js porque las cadenas estaban escritas a fuego en los componentes.
- Los archivos de traducción se desincronizan porque los desarrolladores no saben qué archivo tienen que actualizar
- Períodos de «congelación de la localización» antes de los lanzamientos porque nadie confía en el proceso de traducción
- Resistencia a modificar cualquier contenido traducido porque el flujo de trabajo es muy tedioso
En qué ayudo:
- Estrategias de refactorización que permiten adoptar i18n de forma incremental (no exijo «parar todo y reescribir desde cero»)
- Diseño de procesos para mantener las traducciones sincronizadas sin bloquear el desarrollo
- Revisiones de arquitectura para identificar dónde fallará tu enfoque actual con más de 10 idiomas
La i18n es arquitectura, no una funcionalidad. Intentar añadirla después es como decidir que tu casa necesita un sótano después de haberla construido.
Te ayudo a cavar ese sótano… o a decidir si realmente lo necesitas.
RTL lo rompe todo
Tu interfaz no se diseñó para árabe, hebreo ni urdu
Cambiaste a dir="rtl" y viste cómo tu diseño saltaba por los aires:
Lo que he visto:
- Sistemas de diseño con más de 200 componentes en los que solo 12 gestionan correctamente RTL
- Equipos que usan float: left en lugar de propiedades lógicas, lo que genera errores RTL en cada nueva funcionalidad
- Popovers y modales que requieren ajustes RTL específicos para cada componente
- Frameworks que dicen ser compatibles con RTL, pero que solo invierten la dirección del diseño y rompen la lógica de posicionamiento
En qué ayudo:
- Migración a propiedades lógicas de CSS (margin-inline-start en lugar de margin-left)
- Auditorías de sistemas de diseño para detectar minas RTL antes del lanzamiento
- Orientación específica por framework (Tailwind, shadcn, MUI) para estilos RTL-first
Corregir a mano los errores RTL en cada componente es insostenible. Hago que el soporte RTL sea sistemático, en vez de estar apagando fuegos constantemente.
«El texto en alemán nos reventó el botón»
Una interfaz que no se diseñó pensando en la traducción
El inglés encaja. El alemán no. Tu diseño asumía:
Luego lo tradujiste al alemán, finés o tailandés y descubriste:
Botones que se cortan a mitad de palabra
Tablas con desplazamiento horizontal en cada fila
Texto que acaba formando bloques ilegibles
El texto no latino se trunca porque los contenedores tienen anchos fijos
En qué ayudo:
- Patrones de interfaz elásticos que se adaptan a la longitud del contenido
- Planificación del presupuesto de caracteres (el alemán se expande un 30 %, el tailandés no usa espacios)
- Sistemas tipográficos que admiten CJK, árabe y devanagari sin romperse
Te ayudo a crear una interfaz que sobreviva a la traducción, antes de que hayas pagado por 10.000 palabras que no encajan.
No necesitas una charla sobre por qué es importante la internacionalización. Necesitas a alguien que haya depurado popovers RTL a las 2 de la mañana, que haya discutido con producto sobre límites de caracteres y que haya diseñado pipelines de traducción que funcionen de verdad.
Las trampas de las que nadie te avisó
Batallitas de equipos que ya han pasado por ello
Esto no es teoría. Son cosas que fallaron en producción:
El infierno de la pluralización
Inglés: «1 elemento» frente a «2 elementos»
Polaco: «1 przedmiot» / «2 przedmioty» / «5 przedmiotów» (3 formas de plural)
Árabe: 6 formas de plural
Tu lógica count === 1 ? 'item' : 'items' ya no funciona.
El caos de fechas y horas
Formateaste las fechas con toLocaleDateString(). Y los usuarios de Japón vieron «2025年2月9日» en sus exportaciones CSV y Excel petó.
Desajuste de idioma en la API
Tu frontend solicita francés. Tu API devuelve inglés porque el token de autenticación no incluye el locale. Resultado: una interfaz con idiomas mezclados y usuarios que creen que es un fallo.
Pruebas de pseudolocalización
No probaste con [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30 %] antes de pasar a producción. Ahora tu sitio en polaco es inutilizable.
La suposición invisible
Diste por hecho que las cadenas son lo único que necesita traducción. Luego te topaste con fechas, números, divisas, ordenación, búsqueda… todo tiene un comportamiento específico según la configuración regional.
En qué ayudo:
- Implementación de ICU MessageFormat (gestiona plurales, género y contexto)
- Patrones de i18n en la API (negociación de idioma, estrategias de fallback)
- Procesos de control de calidad que detectan estos problemas antes de que lo hagan las agencias de traducción
El flujo de trabajo es lo más difícil
¿Cómo mantienes 8 idiomas sincronizados cuando despliegas a diario?
La tecnología ya la tienes resuelta. Ahora estás atascado con el proceso:
Los desarrolladores fusionan código con nuevas cadenas en inglés. Las traducciones se retrasan 2 semanas. Los usuarios ven una interfaz traducida a medias.
No sabes qué cadenas se pueden eliminar sin riesgo (¿se usan? ¿están traducidas? ¿están en proceso con una agencia?)
Producto quiere actualizar el texto. Nadie sabe si cambiar «Submit» por «Send» romperá 12 idiomas.
Los archivos de traducción pasan semanas sin sincronizarse con producción
Preguntas que me hacen los equipos:
Lo que he visto fallar:
- Archivos de traducción subidos a git que divergen de las cadenas en producción
- Avisos de «No tocar el archivo en español» porque nadie sabe qué se puede cambiar sin riesgo.
- Funcionalidades lanzadas en inglés y traducidas 6 meses después (si es que se traducen)
En qué ayudo:
- Diseño del pipeline de traducción (cuándo usar bibliotecas i18n, cuándo usar un TMS y cuándo usar IA)
- Flujos de trabajo en Git para mantener sincronizadas las cadenas fuente y las traducciones
- Automatización que bloquea los PR si las cadenas nuevas no están marcadas para traducción
La tecnología tiene solución. El flujo de trabajo es el obstáculo. Diseño flujos de trabajo que no requieren esfuerzos heroicos para mantenerlos.
Equipos con los que he trabajado
Productos globales, experiencia regional
LINE (Japan, Taiwan, Thailand)
Plataforma de mensajería que opera en 3 mercados principales del este de Asia. He trabajado en retos específicos de gestión de caracteres CJK, integración en el ecosistema de la plataforma y las distintas expectativas de experiencia de usuario en Japón, Taiwán y Tailandia.
KakaoTalk (South Korea)
La plataforma de mensajería líder en Corea. Abordé requisitos de producto específicos del mercado coreano, como las expectativas de formalidad lingüística en la interfaz y las necesidades de integración con la plataforma.
Change.org (196 countries, 20+ priority languages)
Plataforma global de peticiones, donde la velocidad y la calidad del contenido importan por igual. Ayudé a definir el flujo de trabajo de traducción para contenido político y social generado por usuarios en diversos mercados.
Airbnb (220+ countries, 60+ languages)
Mercado global con requisitos complejos de internacionalización. Asesoré sobre los retos relacionados con la confianza y la seguridad en múltiples idiomas, así como la adaptación cultural de los conceptos de la plataforma en distintos mercados.
Intercom (30+ languages, global B2B SaaS)
Plataforma de comunicación con clientes que presta servicio a empresas globales. He trabajado en la internacionalización de productos para herramientas de soporte en tiempo real y en la localización de bases de conocimiento.
Lilith Games (China, Japan, Korea, US, EU)
Editora de juegos para móvil con títulos distribuidos a nivel mundial. Afronté retos específicos de cada mercado en localización de contenido y requisitos regionales de las plataformas.
Mercados en los que he lanzado:
Asia Oriental (Japón, Corea, China):
Tipografía CJK, integración en el ecosistema de la plataforma y compatibilidad con texto vertical
Sudeste Asiático (Tailandia, Vietnam, Indonesia):
Compatibilidad con múltiples escrituras, expectativas de usuario centradas en el móvil
MENA (regiones de habla árabe):
Requisitos de diseño RTL, expectativas de registro formal frente a coloquial, adaptación cultural del contenido
Europa:
24 idiomas oficiales, lanzamientos de producto en varios países
Américas:
Variaciones regionales del idioma (español de Latinoamérica frente al de España, portugués de Brasil), mercados bilingües
He visto de primera mano lo que funciona y lo que falla en estos mercados; no desde la teoría, sino tras haber lanzado productos de los que dependen usuarios reales.
Vamos a corregir lo que está fallando
No necesitas una charla sobre por qué es importante la internacionalización. Necesitas a alguien que haya depurado popovers RTL a las 2 de la mañana, que haya discutido con producto sobre límites de caracteres y que haya diseñado pipelines de traducción que funcionen de verdad.
Revisión de arquitectura y estrategia (1-2 semanas):
Te digo qué fallará cuando añadas tus próximos 3 idiomas y cuánto costará corregirlo
Acompañamiento en el lanzamiento al mercado (4-8 semanas):
Vas a lanzarte en Japón/MENA/UE y necesitas expertos que ya lo hayan hecho
Colaboración continua:
Consultoría integrada a medida que pasas de 2 a 20 idiomas
Nada de teoría. Yo hago triaje, hojas de ruta y lanzamientos.