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 la capa visible. Debajo hay cadenas de texto escritas dentro del código, maquetación dimensionada para etiquetas cortas en inglés, 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 otras, 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 de formatos crece de golpe. El producto "en un idioma y ya veremos" se queda corto en el mercado propio antes de llegar a la frontera.

El coste comercial se mide. 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. Alrededor de tres cuartas partes de los internautas hablan una primera lengua distinta del inglés (Statista, 2024). Un producto que solo habla un idioma compite por una minoría de su mercado potencial.

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, buscador) mientras el producto sigue publicándose. 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). Quien presupuesta "traducción" y descubre que ha comprado "reingeniería" suele descubrirlo a mitad de proyecto.

Los modos de fallo se repiten con tanta regularidad que los catalogamos: mira por qué el software fracasa fuera de su mercado (en inglés) para los siete errores que encontramos más a menudo, y lo que cuesta deshacer cada uno.

Arquitectura i18n: qué construir desde el primer día

Una arquitectura multilingüe desde el diseño es un conjunto de decisiones concretas, no una filosofía. Estas son las que tomamos al principio de cada proyecto:

1. Unicode en todas partes. Unicode es el estándar universal de caracteres que asigna un punto de código a cada carácter de cada sistema de escritura; UTF-8 es su codificación dominante. Cada columna de base de datos, API, exportación de archivos y plantilla de correo de nuestros proyectos es UTF-8 de punta a punta. Basta un componente heredado con otra codificación para corromper nombres y direcciones: la basura ilegible ("mojibake") que diseccionamos en Unicode en aplicaciones de empresa (en inglés). Una eñe, una cedilla catalana o un acento gallego rotos en una factura son la primera señal que ve el cliente.
2. Textos externalizados. Ningún texto visible vive en el código. Cada etiqueta, error y correo está en archivos de recursos con claves estables, listos para quien traduce. Las frases no se montan nunca a partir de fragmentos, porque el orden de las palabras cambia según el idioma.
3. Formato de mensajes ICU. ICU (International Components for Unicode) es la biblioteca de código abierto que gestiona plurales, género, listas y valores formateados por idioma. El inglés tiene dos formas de plural; el árabe, seis; en polaco las reglas cambian con el propio número. ICU se ocupa de esto; las plantillas de texto no pueden.
4. Datos de locale de CLDR. CLDR (Common Locale Data Repository, mantenido por el Consorcio Unicode) aporta los datos de cada locale (una locale es una combinación de idioma y región, como es-MX o ca-ES). Patrones de fecha, separadores numéricos, símbolos de moneda, órdenes alfabéticos: usamos datos de CLDR en lugar de tablas de formato mantenidas a mano.
5. Un modelo de datos traducible. Los textos de interfaz son la mitad del problema. Nombres de producto, categorías, plantillas de documento y 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 (en inglés) o de campos de contenido localizados.
6. hreflang y enrutado por locale. hreflang es la anotación HTML que le dice a los buscadores qué versión lingüística de una página servir a cada usuario. La generamos de forma programática a partir de la configuración de locales, nunca a mano.
7. Pseudolocalización en CI. La pseudolocalización sustituye el texto por cadenas ficticias acentuadas y alargadas para destapar textos escritos dentro del código y maquetaciones que se rompen antes de traducir una sola palabra.

Ninguno de estos puntos es caro cuando se elige al principio. Todos son caros de parchear después. Esa asimetría es el argumento entero a favor de construir multilingüe desde el diseño. El resto de nuestras prácticas están recogidas en diseñar aplicaciones para usuarios de todo el mundo (en inglés).

Multidivisa, fechas, números y formatos: los detalles que erosionan la confianza

Los fallos de formato casi nunca generan un informe de error. Generan desconfianza silenciosa: la sensación de que el producto se construyó para otro sitio.

• Divisa. Precios multidivisa significa precios por mercado con redondeo controlado, no cálculo del tipo de cambio en el momento de pintar la pantalla. También significa respetar las unidades menores: el yen japonés no tiene decimales, y algunas divisas usan tres. Las reglas de almacenamiento, redondeo y visualización están en gestión multidivisa en software (en inglés).
• Fechas y horas. 04/07/2026 es el 4 de julio en Valencia y el 7 de abril en Nueva York. Pintamos las fechas por locale a partir de los patrones de CLDR y guardamos las marcas de tiempo en UTC con zona horaria explícita, una costumbre que además mantiene honestos los informes transfronterizos.
• Números. 1.500 son mil quinientos aquí y en Alemania, y uno coma cinco en Estados Unidos. Los separadores decimales y de miles deben seguir a la locale tanto al mostrar como al interpretar lo que se escribe; una importación que los lea mal corrompe datos financieros en silencio.
• Nombres y direcciones. El orden del nombre, los tratamientos, los formatos postales y las convenciones telefónicas cambian según el mercado. Un formulario con un único campo "apellido" obliga a un cliente español a elegir cuál de los dos pone, y otro que exige un "state" y un código postal de cinco dígitos rechaza a clientes perfectamente válidos.

Cada detalle es pequeño. Juntos deciden si una compradora de Barcelona, un expedidor saudí o un técnico de planta japonés viven el software como suyo.

Cómo construimos multilingüe desde el diseño: el origen como prueba

Globaprom nació de BeTranslated, una empresa de traducción internacional que fundamos y seguimos operando (la historia detrás de Globaprom cuenta el recorrido completo). Ese origen aparece en el trabajo de formas concretas y comprobables:

• Fuimos nuestro primer cliente. Nuestros sistemas multilingües de facturación, presupuestos y portal de proveedores se construyeron para nuestra propia operación de traducción: multidivisa, multilocale, en producción durante años antes de que vendiéramos un solo proyecto.
• Las locales se definen, no se suponen. Cada proyecto empieza con una matriz de locales: qué idiomas, escrituras, divisas y formatos, ahora y de forma plausible más adelante. Los criterios de aceptación de i18n entran en el alcance cerrado.
• Velocidad asistida por IA, calidad revisada por personas. Construimos con desarrollo asistido por IA, y precisamente por eso la lista de i18n de arriba se impone mediante revisión y mediante pruebas de pseudolocalización en CI: el código generado tira por defecto a suponer inglés salvo que el proceso se lo prohíba. Nuestro método está documentado en cómo definimos el alcance, construimos y revisamos.
• Organizar la traducción no es tu problema. A través de nuestra red de lingüistas profesionales conectamos tu TMS, gestionamos la traducción humana o la MTPE, y te entregamos un pipeline en marcha, no una carpeta de textos y buenos deseos.

Ninguna otra agencia de software a medida de este mercado puede reunir ese conjunto de afirmaciones. Por eso existe esta página.

Caso de éxito: entrega multilingüe en la práctica

C21 Perdomo, web multilingüe y sistema de seguimiento. Para esta agencia inmobiliaria construimos una web multilingüe nueva, asistida por IA, con un sistema de seguimiento integrado, internacionalizada desde el primer commit en lugar de parcheada después. El proyecto enseña en producción el enfoque que describe esta página: contenido consciente de la locale y una interfaz multilingüe entregados como un único sistema coherente.

Hay más proyectos documentados en nuestros casos de éxito (en inglés).