Consultoría de internacionalización: corrige lo que falla y planifica lo que sigue
Ya sabes que i18n es difícil. He visto los síntomas de cerca: diseños RTL que se desploman, texto en alemán desbordando botones, respuestas de la API en el idioma equivocado y traducciones que se desalinean a pocas semanas del lanzamiento. No vendo soluciones mágicas. Te ayudo a desenredar el desorden específico en el que está tu equipo y a construir sistemas que no se rompan de la misma manera dos veces.
"Esto lo debimos haber planeado antes"
El costo oculto de la arquitectura que estás pagando ahora
Lanzaste en inglés. Funcionó. Luego agregaste francés "solo para la landing page". Ahora estás aquí porque:
Tu base de código tiene verificaciones de lang= dispersas en 47 archivos
Los gerentes de producto preguntan "¿podemos hacer A/B testing del copy?" e ingeniería dice "no sin reescribirlo"
Tienes tres flujos de trabajo de traducción diferentes y ninguno funciona de manera confiable
Lo que he visto fallar:
- Equipos que pasan más de 6 meses adaptando i18n en una app de Next.js porque las cadenas estaban hardcodeadas en los componentes
- Los archivos de traducción se desincronizan porque los desarrolladores no saben qué archivo actualizar
- Períodos de "congelación de localización" antes de los lanzamientos porque nadie confía en el flujo de trabajo de traducción.
- Resistencia a modificar cualquier contenido traducido porque el flujo de trabajo es demasiado engorroso
En qué te ayudo:
- Estrategias de refactorización que te permiten una adopción incremental de i18n (no exijo "detengan todo y reescriban")
- Diseño de procesos para mantener las traducciones sincronizadas sin bloquear el desarrollo.
- Revisiones de arquitectura para identificar en qué punto tu enfoque actual se romperá con más de 10 idiomas.
i18n es arquitectura, no una característica. Intentar agregarla después es como decidir que tu casa necesita un sótano cuando ya la construiste.
Te ayudo a cavar ese sótano o a decidir si de verdad necesitas uno.
RTL rompe todo
Tu interfaz no fue diseñada para árabe, hebreo ni urdu
Cambiaste dir="rtl" y viste cómo tu diseño se desmoronó:
Lo que vi:
- Sistemas de diseño con más de 200 componentes donde solo 12 manejan RTL correctamente
- Equipos que usan float: left en lugar de propiedades lógicas, lo que genera errores de RTL en cada nueva funcionalidad
- Popovers y modales que requieren anulaciones de RTL específicas por componente
- Frameworks que dicen tener "soporte RTL" pero 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 ocultas de RTL antes de que salgan a producción
- Guía específica por framework (Tailwind, shadcn, MUI) para estilos RTL-first
Corregir manualmente los errores de RTL en cada componente es insostenible. Hago que el soporte RTL sea sistemático, no una lucha constante apagando incendios.
"El texto en alemán nos rompió el botón"
Interfaz de usuario que no se diseñó para traducción
El inglés cabe. El alemán no. Tu diseño partió de estas suposiciones:
Luego tradujiste al alemán, finlandés o tailandés y descubriste:
Los botones se cortan a media palabra
Tablas con scroll horizontal en cada fila
Texto que se ajusta en bloques ilegibles
El texto no latino se trunca porque los contenedores tienen anchos fijos
En qué ayudo:
- Patrones de UI elásticos que se adaptan a la longitud del contenido
- Planificación del presupuesto de caracteres (considerando que el alemán se expande 30 % y el tailandés no usa espacios)
- Sistemas tipográficos que manejan CJK, árabe y devanagari sin romperse
Te ayudo a crear interfaces de usuario que sobreviven a la traducción, antes de que pagues por 10,000 palabras que no caben.
No necesitas una conferencia sobre por qué i18n es importante. Necesitas a alguien que haya depurado popovers RTL a las 2 AM, discutido con producto sobre los límites de caracteres y diseñado pipelines de traducción que realmente funcionen.
Las trampas de las que nadie te advirtió
Historias de guerra de equipos que ya pasaron por esto
No son teorías. Son cosas que fallaron en producción:
El infierno de la pluralización
Inglés: "1 item" vs "2 items"
Polaco: "1 przedmiot" / "2 przedmioty" / "5 przedmiotów" (3 formas de plural)
Árabe: 6 formas de plural
Tu lógica de count === 1 ? 'item' : 'items' ya no funciona.
Caos con fechas y horas
Formateaste las fechas con toLocaleDateString(). Luego, los usuarios en Japón vieron "2025年2月9日" en sus exportaciones CSV y Excel se trabó.
Discrepancia de idioma en la API
El frontend solicita francés. La API devuelve inglés porque el token de autenticación no incluye el locale. El resultado: una interfaz con idiomas mezclados y usuarios que creen que es un error.
Pruebas con pseudo-locales
No probaste con [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30%] antes de pasar a producción. Ahora tu sitio en polaco es inutilizable.
La suposición invisible
Asumiste que las cadenas de texto son lo único que necesita traducción. Luego te topaste con fechas, números, monedas, ordenamiento, búsqueda… todo tiene un comportamiento específico de cada locale.
En qué ayudo:
- Implementación de ICU MessageFormat (maneja plurales, género y contexto)
- Patrones de i18n en la API (negociación de idioma, estrategias de respaldo)
- Procesos de control de calidad que detectan estos problemas antes que las agencias de traducción
El flujo de trabajo es lo difícil
¿Cómo mantienes 8 idiomas sincronizados cuando haces despliegues a diario?
Ya dominaste la tecnología. Ahora estás atorado 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 a medio traducir.
No sabes cuáles cadenas se pueden eliminar sin problema (¿se están usando? ¿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 están fuera de sincronía con producción por semanas
Preguntas que me hacen los equipos:
Lo que vi fallar:
- Archivos de traducción registrados en git que divergen de las cadenas en producción
- Advertencias de "no toquen el archivo de español" porque nadie sabe qué es seguro cambiar
- Funcionalidades lanzadas en inglés y traducidas 6 meses después (si es que se traducían)
En qué ayudo:
- Diseño del pipeline de traducción (cuándo usar bibliotecas de i18n, cuándo usar un TMS, cuándo usar IA)
- Flujos de trabajo en Git para mantener sincronizadas las cadenas fuente y las traducciones
- Automatización que bloquea los PRs si las cadenas nuevas no están marcadas para traducir
La tecnología tiene solución. El flujo de trabajo es el verdadero obstáculo. Diseño flujos de trabajo que no requieren heroicidades para mantenerse.
Equipos con los que trabajé
Productos globales, experiencia regional
LINE (Japón, Taiwán, Tailandia)
Plataforma de mensajería que opera en 3 mercados principales del este de Asia. Trabajé en desafíos específicos del manejo de caracteres CJK, la integración con el ecosistema de la plataforma y las diferencias en expectativas de experiencia de usuario entre Japón, Taiwán y Tailandia.
KakaoTalk (Corea del Sur)
La plataforma de mensajería dominante en Corea. Atendí requisitos específicos del producto para el mercado coreano, incluyendo las expectativas de formalidad en la interfaz y las necesidades de integración con la plataforma.
Change.org (196 países, más de 20 idiomas prioritarios)
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 mercados diversos.
Airbnb (más de 220 países, más de 60 idiomas)
Marketplace global con requisitos complejos de i18n. Brindé asesoría sobre los retos de confianza y seguridad en múltiples idiomas, así como la adaptación cultural de conceptos de la plataforma en distintos mercados.
Intercom (más de 30 idiomas, SaaS B2B global)
Plataforma de comunicación con clientes que atiende a empresas globales. Trabajé en la internacionalización del producto para herramientas de soporte en tiempo real y la localización de bases de conocimiento.
Lilith Games (China, Japón, Corea, EE. UU., UE)
Editora de juegos móviles con títulos distribuidos a nivel global. Abordé desafíos específicos de cada mercado en torno a la localización de contenido y los requisitos regionales de plataforma.
Mercados en los que he lanzado:
Asia Oriental (Japón, Corea, China):
Tipografía CJK, integración con el ecosistema de la plataforma, compatibilidad con texto vertical
Sudeste Asiático (Tailandia, Vietnam, Indonesia):
Compatibilidad con múltiples sistemas de escritura, expectativas mobile-first de usuarios
MENA (regiones de habla árabe):
Requisitos de diseño RTL, expectativas de lenguaje formal vs. coloquial, adaptación cultural de contenido
Europa:
24 idiomas oficiales, lanzamientos de producto en múltiples países
Américas:
Variaciones regionales de idioma (español de LATAM vs España, portugués brasileño), mercados bilingües
Vi de primera mano qué funciona y qué falla en estos mercados, no desde la teoría, sino entregando productos de los que dependen usuarios reales.
Corrijamos lo que está fallando
No necesitas una conferencia sobre por qué i18n es importante. Necesitas a alguien que haya depurado popovers RTL a las 2 AM, discutido con producto sobre los límites de caracteres y diseñado pipelines de traducción que realmente funcionen.
Revisión de arquitectura y estrategia (1-2 semanas):
Te digo qué se va a romper cuando agregues tus próximos 3 idiomas, y cuánto va a costar arreglarlo
Soporte para el lanzamiento al mercado (4-8 semanas):
Estás lanzando en Japón/MENA/EU y necesitas expertos que ya lo hayan hecho antes
Colaboración continua:
Consultoría integrada mientras creces de 2 idiomas a 20
No hago teoría. Hago triaje, hojas de ruta y entrego productos.