Consultoría de internacionalización: Soluciona lo que está fallando, planifica lo que sigue.
Ya sabes que i18n es difícil. He visto los síntomas: diseños RTL que colapsan, texto en alemán que desborda los botones, respuestas de API en el idioma equivocado y traducciones que se desincronizan a las pocas semanas del lanzamiento. No vendo soluciones milagrosas. Te ayudo a desenredar el problema específico en el que se encuentra tu equipo y a construir sistemas que no fallarán de la misma manera dos veces.
"Debimos haber planeado esto antes"
El impuesto de arquitectura que estás pagando ahora
Lanzaste en inglés. Funcionó. Luego agregaste francés "solo para la página de inicio". Ahora estás aquí porque:
Tu base de código tiene verificaciones de lang= distribuidas en 47 archivos
Los gerentes de producto preguntan '¿podemos hacer pruebas A/B con los textos?' y el equipo de ingeniería responde 'no sin reescribir todo'
Tienes tres flujos de trabajo de traducción diferentes y ninguno de ellos funciona de manera confiable
Lo que he visto fallar:
- Equipos que pasan más de 6 meses adaptando i18n a una aplicación Next.js porque las cadenas de texto estaban codificadas en los componentes
- Archivos de traducción que pierden la sincronización porque los desarrolladores no saben qué archivo actualizar
- Períodos de 'congelamiento de localización' antes de los lanzamientos porque nadie confía en el proceso de traducción
- Resistencia a cambiar cualquier contenido traducido porque el flujo de trabajo es muy complicado
En qué te puedo ayudar:
- Estrategias de refactorización que te permiten adoptar i18n de manera incremental (no exijo 'detener todo y reescribir')
- Diseño de procesos para mantener las traducciones sincronizadas sin bloquear el desarrollo
- Revisiones de arquitectura para identificar dónde tu enfoque actual fallará con más de 10 idiomas.
i18n es arquitectura, no una funcionalidad. Intentar agregarlo 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 fue diseñada para árabe, hebreo o urdu
Cambiaste dir="rtl" y viste cómo tu diseño explotaba:
Lo que he visto:
- Sistemas de diseño con más de 200 componentes donde solo 12 manejan correctamente RTL
- Equipos que usan float: left en lugar de propiedades lógicas, creando errores de RTL en cada nueva funcionalidad
- Popovers y modales que requieren sobreescrituras de RTL específicas por componente
- Frameworks que afirman tener "soporte RTL" pero solo invierten la dirección del diseño y rompen la lógica de posicionamiento.
En qué te puedo ayudar:
- Migración a propiedades lógicas de CSS (margin-inline-start en lugar de margin-left)
- Auditorías de sistemas de diseño para encontrar problemas ocultos de RTL antes de que se lancen
- Guía específica de frameworks (Tailwind, shadcn, MUI) para un estilo que prioriza RTL
Corregir manualmente los errores de RTL en cada componente es insostenible. Hago que el soporte de RTL sea sistemático, no una lucha constante.
"El texto en alemán rompió nuestro botón."
Interfaz de usuario que no fue construida para la traducción
El inglés cabe. El alemán no. Tu diseño asumió:
Luego tradujiste al alemán, finlandés o tailandés y descubriste:
Botones cortados a mitad de palabra
Tablas con desplazamiento 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é te puedo ayudar:
- Patrones de interfaz de usuario elásticos que se adaptan a la longitud del contenido
- Planificación de presupuesto de caracteres (sabiendo que el alemán se expande un 30% y que el tailandés no usa espacios)
- Sistemas de tipografía que manejan CJK, árabe y devanagari sin fallar.
Te ayudo a construir interfaces de usuario que sobreviven a la traducción, antes de que hayas pagado por 10 000 palabras que no encajan.
No necesitas una charla sobre por qué i18n es importante. Necesitas a alguien que haya depurado popovers de RTL a las 2 AM, que haya peleado con el equipo de producto por los límites de caracteres y que haya diseñado flujos de traducción que realmente funcionen.
Los problemas de los que nadie te advirtió
Historias de guerra de equipos que han pasado por eso
Estas no son teóricas. 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 tus exportaciones CSV y Excel falló.
Incompatibilidad de idioma en la API.
Tu frontend solicita francés. Tu API devuelve inglés porque el token de autenticación no incluye la configuración regional. Ahora tienes una interfaz de usuario con idiomas mezclados y los usuarios piensan que es un error.
Pruebas con pseudo-locale
No probaste con [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30%] antes de pasar a producción. Ahora tu sitio en polaco está inutilizable.
La suposición invisible
Asumiste que solo las cadenas de texto requerían traducción. Luego te encontraste con fechas, números, monedas, clasificación, búsqueda: todo tiene un comportamiento específico según la configuración regional.
En qué te puedo ayudar:
- Implementación de ICU MessageFormat (maneja plurales, género y contexto)
- Patrones de i18n para API (negociación de idioma, estrategias de respaldo).
- 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?
Ya entendiste la tecnología. Ahora estás atascado con el proceso:
Los desarrolladores fusionan código con nuevas cadenas de texto en inglés. Las traducciones se retrasan 2 semanas. Los usuarios ven una interfaz de usuario parcialmente traducida.
No sabes qué cadenas son seguras para eliminar (¿están en uso? ¿están traducidas? ¿están en proceso con una agencia?)
Producto quiere actualizar el texto. Nadie sabe si cambiar "Submit" a "Send" romperá 12 idiomas.
Los archivos de traducción quedan desincronizados con producción durante semanas seguidas.
Preguntas que los equipos me hacen:
Lo que he visto fallar:
- Archivos de traducción en Git que difieren de las cadenas de producción.
- Advertencias de 'No toques el archivo en español' porque nadie sabe qué es seguro cambiar
- Funcionalidades lanzadas en inglés y luego traducidas 6 meses después (si acaso)
En qué te puedo ayudar:
- Diseño del flujo de traducción (cuándo usar bibliotecas de i18n, cuándo usar TMS, cuándo usar IA).
- Flujos de trabajo en Git para mantener sincronizadas las cadenas de origen y las traducciones.
- Automatización que bloquea los PR si las nuevas cadenas no están marcadas para traducción.
La tecnología se puede resolver. El flujo de trabajo es el verdadero obstáculo. Diseño flujos de trabajo que no requieren esfuerzos heroicos para mantenerse.
Equipos con los que he trabajado
Productos globales, experiencia regional
LINE (Japan, Taiwan, Thailand)
Plataforma de mensajería que opera en 3 mercados principales de Asia Oriental. Trabajé en desafíos específicos del manejo de caracteres CJK, la integración del ecosistema de la plataforma y las expectativas de experiencia del usuario que difieren en Japón, Taiwán y Tailandia.
KakaoTalk (South Korea)
Plataforma de mensajería dominante de Corea. Abordé los requisitos de producto específicos del mercado coreano, incluyendo las expectativas de formalidad del idioma en la interfaz de usuario y las necesidades de integración de la plataforma.
Change.org (196 countries, 20+ priority languages)
Plataforma global de peticiones donde la velocidad y la calidad del contenido son clave. Ayudé a gestionar el flujo de traducción para contenido político y social generado por usuarios en diversos mercados.
Airbnb (220+ countries, 60+ languages)
Plataforma de comercio global con requisitos complejos de i18n. Asesoré sobre los desafíos de confianza y seguridad en múltiples idiomas y la adaptación cultural de los conceptos de la plataforma en todos los mercados.
Intercom (30+ languages, global B2B SaaS)
Plataforma de comunicación con el cliente que atiende a clientes empresariales globales. Trabajé en la internacionalización de productos para herramientas de soporte en tiempo real y localización de bases de conocimiento.
Lilith Games (China, Japan, Korea, US, EU)
Editor de juegos móviles con títulos distribuidos a nivel global. Abordé desafíos específicos del mercado relacionados con la localización de contenido y los requisitos regionales de las plataformas.
Mercados en los que he lanzado:
Asia Oriental (Japón, Corea, China):
Tipografía CJK, integración con el ecosistema de la plataforma, soporte para texto vertical
Sudeste Asiático (Tailandia, Vietnam, Indonesia):
Soporte para múltiples escrituras, expectativas de usuarios con prioridad móvil
MENA (regiones de habla árabe):
Requisitos de diseño RTL, expectativas de lenguaje formal vs. coloquial, adaptación cultural del contenido.
Europa:
24 idiomas oficiales, lanzamientos de productos en varios países.
Américas:
Variaciones regionales de idioma (español latinoamericano vs. España, portugués brasileño), mercados bilingües
He visto lo que funciona y lo que falla en estos mercados; no desde la teoría, sino desde el lanzamiento de productos de los que dependen usuarios reales.
Solucionemos lo que está fallando.
No necesitas una charla sobre por qué i18n es importante. Necesitas a alguien que haya depurado popovers de RTL a las 2 AM, que haya peleado con el equipo de producto por los límites de caracteres y que haya diseñado flujos 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 costará arreglarlo
Soporte para lanzamiento al mercado (4-8 semanas):
Están lanzando en Japón/MENA/UE y necesitan expertos que ya lo hayan hecho antes.
Colaboración continua:
Consultoría integrada mientras escalas de 2 idiomas a 20
No me dedico a la teoría. Me dedico al triaje, las hojas de ruta y los lanzamientos.