Desarrollo de software multilingüe

Por qué la mayoría del software fracasa fuera de su mercado (la trampa del parche)

La mayoría del software fracasa fuera de casa por un solo motivo: se diseñó para un idioma y se tradujo después. Las palabras son solo la capa visible. Debajo hay cadenas de texto escritas dentro del código, maquetaciones pensadas para etiquetas cortas, lógica de fechas que asume una única convención de calendario y una base de datos que guarda texto sin preguntarse qué escritura contiene.

Una empresa española choca con esto antes que muchas, porque su mercado ya es multilingüe. Si vendes en Cataluña, el País Vasco o Galicia, tus clientes esperan su idioma en la interfaz, en el albarán y en el correo automático, no solo en el folleto. En cuanto exportas a la UE o a Latinoamérica, la lista de idiomas y formatos crece de golpe.

Y eso te cuesta ventas. El estudio «Can't Read, Won't Buy» de CSA Research, con 8.709 consumidores en 29 países, estableció que el 76 % prefiere comprar productos con información en su propio idioma, y que el 40 % no comprará nunca en webs en otro idioma. Menos del 20 % de la población mundial habla inglés, pero casi la mitad de las webs están escritas en ese idioma (Statista, 2026).

Parchear después es la vía cara. Añadir idiomas a un código monolingüe obliga a tocar todas las capas a la vez (textos de interfaz, validaciones, correos, PDF, campos de base de datos, búsqueda) mientras el producto sigue en marcha. Los equipos declaran un esfuerzo de ingeniería de dos a cinco veces mayor en un parche que si hubieran integrado el mismo soporte desde el principio (XTM, 2026). Casi todos descubren a mitad de proyecto que presupuestaron traducción y compraron reingeniería.

Vemos los mismos fallos tan a menudo que los catalogamos: por qué el software fracasa fuera de su mercado recoge los siete errores que más encontramos y lo que cuesta deshacer cada uno.

Arquitectura i18n: qué dejar montado desde el primer día

Una arquitectura multilingüe desde el origen se reduce a una lista corta de decisiones concretas. Tomadas al principio, cada una cuesta poco. Metidas después, cada una cuesta mucho. Esto es lo que lleva cada proyecto que entregamos:

1. Unicode en todas partes. Unicode asigna un punto de código a cada carácter de cada sistema de escritura, y UTF-8 es su codificación dominante. Cada columna de base de datos, API, exportación de fichero y plantilla de correo que construimos va en UTF-8 de punta a punta, porque basta un componente heredado con otra codificación para corromper nombres y direcciones. Ese texto basura tiene nombre, «mojibake», y lo desmenuzamos en Unicode en aplicaciones empresariales.
2. Cadenas externalizadas. Ningún texto visible para el usuario vive en el código. Cada etiqueta, mensaje de error y correo está en ficheros de recursos con claves estables, listos para los traductores. Las frases nunca se montan a partir de fragmentos, porque el orden de las palabras cambia de un idioma a otro.
3. Formato de mensajes ICU. ICU (International Components for Unicode) es la biblioteca de código abierto que resuelve plurales, género, listas y valores formateados en cada idioma. El inglés tiene dos formas de plural, el árabe tiene seis y en polaco las reglas cambian con el propio número. Unas plantillas de texto no dan para eso. ICU, sí.
4. Datos de locale de CLDR. CLDR (Common Locale Data Repository, mantenido por el Consorcio Unicode) aporta los datos de cada locale, es decir, de una combinación de idioma y región como fr-BE: patrones de fecha, separadores numéricos, símbolos de moneda, criterios de ordenación. Lo usamos en lugar de tablas de formato mantenidas a mano.
5. Un modelo de datos traducible. Las cadenas de la interfaz son la mitad del problema. Los nombres de producto, las categorías, las plantillas de documento y las notificaciones viven en la base de datos, así que el esquema los guarda por idioma desde el primer día, normalmente detrás de un CMS multilingüe o de campos de contenido localizados.
6. hreflang y enrutado por locale. hreflang es la anotación HTML que indica a los buscadores qué versión lingüística de una página mostrar a cada usuario. La generamos a partir de la configuración de locales, nunca a mano.
7. Seudolocalización en integración continua (CI). La seudolocalización sustituye el texto por cadenas ficticias acentuadas y alargadas, como "[!!! Àççôûñt Šéttîñgš !!!]", para destapar textos incrustados en el código y maquetaciones que se rompen antes de traducir una sola palabra.

El resto de nuestras prácticas está en buenas prácticas para aplicaciones globales. En tu proyecto, los criterios de aceptación i18n que las garantizan quedan escritos en el alcance cerrado.

RTL, CJK y las escrituras que rompen las interfaces ingenuas

Dos familias de escritura destapan una internacionalización débil más rápido que ninguna otra. Si las detectas en las pruebas, tus usuarios nunca verán la rotura.

Las escrituras de derecha a izquierda (RTL), el árabe y el hebreo, invierten el sentido de lectura de toda la interfaz. Un buen soporte RTL significa maquetación en espejo (navegación, iconos, flujos de progreso), propiedades CSS lógicas en lugar de valores izquierda/derecha y un tratamiento correcto del texto bidireccional, cuando una frase en árabe contiene un código de producto latino o un teléfono que se lee en el otro sentido. Una interfaz ingenua convierte el texto RTL en un revoltijo, y el usuario lo nota en segundos.

Las escrituras CJK (chino, japonés, coreano) rompen otras suposiciones. No hay espacios entre palabras, así que el salto de línea tiene que conocer la escritura. Los caracteres son más densos, así que los tamaños de letra e interlineados pensados para el alfabeto latino se vuelven ilegibles. La búsqueda, la ordenación y los métodos de entrada también se comportan de otra manera.

Queda la expansión del texto. Las etiquetas en alemán ocupan alrededor de un 30 % más que en inglés, y hasta palabras corrientes desbordan los botones de ancho fijo. La maquetación hay que probarla con escrituras reales, no traducirla al final, así que cada proyecto multilingüe que entregamos pasa por seudolocalización y por al menos un locale RTL y otro CJK.

Pipelines de traducción: conectar tu aplicación con flujos de traducción profesional

Aquí jugamos en casa. Un pipeline de traducción es la ruta automatizada que recorre tu contenido desde el código hasta los traductores y de vuelta. Es lo que mantiene al día el software multilingüe, versión tras versión, en lugar de traducirlo una vez y dejar que se quede anticuado.

Un pipeline de producción tiene cinco etapas:

1. Extracción. Las cadenas nuevas y modificadas se detectan solas en cada versión. Nadie envía hojas de cálculo por correo.
2. Entrega al TMS. Un sistema de gestión de traducciones (TMS) reparte el contenido entre traductores y sigue el avance. Aplica memorias de traducción (traducciones ya aprobadas, reutilizadas en lugar de pagarlas dos veces) y glosarios terminológicos, para que el vocabulario de tu producto sea coherente entre versiones e idiomas.
3. Traducción. Traductores humanos, traducción automática o posedición de traducción automática (MTPE: la traducción automática revisada y corregida por un profesional), según el tipo de contenido. Los textos legales y las cadenas de interfaz merecen atención humana. Las descripciones masivas de catálogo justifican a menudo la MTPE.
4. Revisión en contexto. Los traductores ven las cadenas donde aparecen, no en una columna de hoja de cálculo. La mayoría de los defectos de traducción son defectos de contexto.
5. Integración y despliegue. Las traducciones aprobadas pasan por los mismos filtros de revisión que el código. Con localización continua, el bucle se ejecuta en cada versión, así que ningún idioma espera nunca a una «fase de traducción».

Llevamos flujos como estos en decenas de combinaciones de idiomas durante más de 20 años, como proveedor de traducción, coordinando a cientos de lingüistas profesionales con plazos cerrados. La elección de herramientas y la arquitectura completa están en nuestra guía de pipelines de traducción.