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 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).

Parchear después es la vía cara. 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).

Los modos de fallo se repiten con tanta regularidad que los catalogamos: mira por qué el software fracasa fuera de su mercado para los siete errores que encontramos más a menudo.

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

Una arquitectura multilingüe desde el origen 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, cada API, cada exportación de fichero y cada plantilla de correo de nuestros proyectos va en UTF-8 de punta a punta. Basta un componente heredado con otra codificación para corromper nombres y direcciones: el texto basura llamado "mojibake" que desmenuzamos en Unicode en aplicaciones empresariales.
2. Cadenas externalizadas. Ningún texto visible para el usuario vive en el código. Cada etiqueta, cada error y cada correo están en ficheros de recursos con claves estables, listos para los traductores. Las frases nunca se concatenan 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; en polaco las reglas cambian con el propio número. ICU se encarga de eso; unas plantillas de texto, no.
4. Datos de locale de CLDR. CLDR (Common Locale Data Repository, mantenido por el Consorcio Unicode) aporta los datos de cada locale (un locale es 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: usamos los datos de CLDR 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 le dice a los buscadores qué versión lingüística de una página servir a cada usuario. La generamos por programa 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 ([!!! Àççôûñt Šéttîñgš !!!]) para sacar a la luz textos incrustados en el código y maquetaciones que se rompen antes de traducir una sola palabra.

Ninguna de estas piezas es cara cuando se elige al principio. Todas son caras de meter después. Esa asimetría es todo el argumento a favor de construir en multilingüe desde el origen. El resto de nuestras prácticas están reunidas en buenas prácticas para aplicaciones globales (en inglés).

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

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

• Divisa. El precio multidivisa significa precios por mercado con un redondeo controlado, no cuentas con el 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 el soporte multidivisa en el software.
• Fechas y horas. 04/07/2026 es abril en Nueva York y julio en Bruselas. Pintamos las fechas por locale con los patrones de CLDR y guardamos las marcas de tiempo en UTC con zona horaria explícita, una costumbre que además mantiene honesto el reporting transfronterizo.
• Números. 1.500 es uno y medio en Estados Unidos y mil quinientos en Alemania. Los separadores decimales y de millares tienen que seguir al locale tanto al mostrar como al leer lo que se introduce; una importación que los interpreta mal corrompe datos financieros en silencio.
• Nombres y direcciones. El orden del nombre, los tratamientos, los formatos postales y las convenciones telefónicas cambian con cada mercado. Los formularios que imponen una estructura estadounidense rechazan a clientes válidos.

Cada detalle es pequeño. Juntos deciden si un comprador belga, un expedidor saudí o un técnico de planta japonés siente el software como suyo.

Cómo construimos multilingüe desde el origen: la herencia como prueba

Globaprom nació de BeTranslated, un negocio de traducción global que fundamos y seguimos operando (la historia detrás de Globaprom cuenta el recorrido completo). Esa herencia se nota 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, con varios locales, en producción durante años antes de vender un solo desarrollo.
• Los locales se acotan, no se dan por sentados. Cada proyecto arranca con una matriz de locales: qué idiomas, sistemas de escritura, divisas y formatos, ahora y previsiblemente más adelante. Los criterios de aceptación de i18n entran en el alcance cerrado.
• Velocidad asistida por IA, calidad revisada por humanos. Construimos con desarrollo asistido por IA, y justo por eso la lista i18n de arriba se hace cumplir con revisión y con pruebas de seudolocalización en CI: el código generado asume el inglés por defecto salvo que el pipeline se lo prohíba. Nuestro proceso está documentado en cómo acotamos, construimos y revisamos.
• Organizar la traducción no es problema tuyo. A través de nuestra red de lingüistas profesionales, conectamos tu TMS, organizamos la traducción humana o la MTPE y te entregamos un pipeline en marcha, no una carpeta de cadenas y buenos deseos.

Ninguna otra agencia de software a medida de este mercado puede hacer ese conjunto de afirmaciones. Por eso las ponemos por delante.

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 muestra el enfoque en producción: contenido adaptado al 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).