Por qué el software fracasa fuera de su mercado: siete errores que vemos siempre

Muchos fallos de internacionalización aparecen cuando un producto se diseña inicialmente para un idioma o una región y la adaptación a otros mercados se realiza después, sin cambiar cómo estaba construido. La traducción por sí sola no resuelve estos problemas: entra bien, pero debajo, el código sigue dando por hecho el orden de palabras del castellano, el formato de fecha español, el texto en alfabeto latino y una sola divisa, así que el producto se rompe de maneras que ningún traductor puede arreglar.

Este patrón lo tratamos a vista de pájaro en desarrollo de software multilingüe: casi todos los fallos vienen de una reforma a posteriori, de una ingeniería pensada para un mercado y ajustada a los demás cuando ya era tarde. Aquí vamos al detalle. Abajo están los siete errores que más nos encontramos al auditar código ajeno, qué pinta tiene cada uno en producción y qué los evita de verdad.

1. Textos incrustados en el código

Qué pinta tiene. Un botón pone "Enviar" porque alguien escribió <button>Enviar</button> directamente en la plantilla. Un correo de confirmación lleva "Tu pedido nº " + pedidoId + " ha salido" dentro de una función de Node. No existe una lista de los textos de la aplicación en ninguna parte. Para añadir francés, alguien tiene que abrir todos los archivos, buscar todas las cadenas y confiar en haberlas cazado todas.

Nunca las cazan todas. Las auditorías sacan castellano olvidado dentro de avisos de error, correos de administración, pies de PDF y notificaciones push, los rincones que nadie piensa en mirar porque no están en la pantalla principal. Cada uno sale a producción como un error pequeño y embarazoso dentro de un producto por lo demás traducido.

Qué lo evita. Cada texto visible vive en un archivo de recursos bajo una clave estable (checkout.boton_confirmar, no el propio texto) desde el primer commit. Los desarrolladores usan la clave; los traductores trabajan el archivo. Esa misma estructura es la que permite que es-ES, es-MX y ca-ES convivan sin duplicar la aplicación, algo que un producto español necesita antes de lo que cree. La pseudolocalización en la integración continua (cambiar cada texto por relleno alargado y con acentos, y recorrer la compilación a golpe de clic) caza lo que siga incrustado antes de una entrega, no después de que lo reporte un cliente.

2. Diseños dimensionados para la longitud del castellano

Qué pinta tiene. Un botón que aloja "Guardar" con holgura. La etiqueta alemana es "Speichern", más larga, y se parte en dos líneas o se corta con puntos suspensivos. Un panel de ajustes diseñado alrededor de etiquetas cortas se convierte en un muro de texto truncado en cuanto se traduce cada etiqueta. Algunas lenguas pueden producir etiquetas sensiblemente más largas que el idioma de origen, especialmente en cadenas cortas, como ocurre a menudo con las palabras compuestas del finés. Y no hace falta cruzar Europa para verlo: "Cerrar sesión" ocupa bastante menos que "Tanca la sessió", y ese catalán es el primer idioma extra que muchos productos españoles añaden.

La magnitud del problema no es un redondeo. La longitud del texto puede aumentar de forma importante durante la traducción, especialmente en cadenas cortas (W3C, El tamaño del texto en la traducción). El W3C advierte además de que el texto puede expandirse al traducirse, por lo que las interfaces deben diseñarse con margen y probarse con contenido localizado. Un botón dimensionado al milímetro no tiene margen para eso.

Qué lo evita. Los diseños usan contenedores flexibles en lugar de anchos fijos, y los botones, las etiquetas y los menús se prueban contra texto pseudolocalizado o traducido de verdad antes de salir, en lugar de mirarse en castellano y darse por buenos. La arquitectura que hay detrás la desmenuzamos en la internacionalización explicada sin jerga.

3. Frases montadas a base de trozos

Qué pinta tiene. Un desarrollador escribe tipo + " eliminado" para ahorrarse una cadena de traducción, y en castellano ya obtiene "Factura eliminado". El género rompe la plantilla antes incluso de salir del país. El mismo código produce disparates gramaticales en alemán, donde el orden y el género cambian según lo que sea tipo, y algo directamente ilegible en japonés o en euskera, donde la estructura de la frase y los sufijos no se pegan a una plantilla castellana de ninguna manera.

Este error es invisible en el idioma de origen y obvio en todos los demás. Sobrevive más que otros fallos porque nadie que pruebe en su propio idioma llega a verlo.

Qué lo evita. Al archivo de recursos van frases completas, no trozos, con marcadores para la parte variable: "¿Eliminar {tipo}?" como una única unidad traducible. El traductor ve y traduce la frase entera, en el orden que su idioma usa de verdad. El formato de mensajes ICU extiende esto a los plurales y los géneros, donde las reglas simples de un idioma esconden una complejidad que otros no comparten.

4. Suposiciones de formato en fechas y números

Qué pinta tiene. Una confirmación de envío pone "04/07/2026". Aquí eso es el 4 de julio. Para tu cliente estadounidense, eso es el 7 de abril. Nadie ve un mensaje de error. El cliente simplemente aparece con tres meses de adelanto, o un informe se archiva contra la fecha equivocada, en silencio.

Los números guardan la misma trampa en la otra dirección. "1.500" se lee como mil quinientos en España y como uno coma cinco en Estados Unidos o en el Reino Unido, donde el punto es el separador decimal. Una rutina de importación que lea números extranjeros con reglas españolas no se cae. Corrompe datos financieros y sigue funcionando tan tranquila.

Qué lo evita. Las fechas y los números se pintan a partir de datos de locale (el Common Locale Data Repository, no una tabla de formatos hecha a mano), y las mismas reglas de locale se aplican a interpretar lo que el usuario teclea, no solo a mostrarlo. El W3C recomienda admitir las convenciones locales y advierte de que el formato ISO 8601 (AAAA-MM-DD) es una alternativa inequívoca cuando conviene evitar ambigüedades. Un campo de fecha que acepta escritura libre tiene que rechazar o reformatear "04/07/2026" de forma coherente con cómo lo pintó, en ambos sentidos.

5. Errores de divisa y redondeo

Qué pinta tiene. Un checkout convierte precios al tipo de cambio del día y muestra el resultado con dos decimales, para cualquier divisa y en cualquier sitio. Eso se rompe de dos formas concretas. Primera: los precios bailan con el tipo de cambio en lugar de sostener el precio local fijo que un mercado espera, así que un producto que ayer costaba 49,99 € hoy cuesta 51,23 € sin motivo visible para el cliente. Segunda: la suposición de los dos decimales es falsa de partida. Las monedas no comparten necesariamente el mismo número de decimales: la documentación de Intl.NumberFormat muestra, por ejemplo, que el yen japonés no utiliza una unidad menor, y otras divisas como el dinar bareiní, el dinar kuwaití o el rial omaní suelen manejarse con tres decimales; conviene confirmar cada caso con una fuente ISO 4217 o CLDR específica. Un carrito construido para dos decimales o pierde precisión que necesita o se inventa precisión que no existe.

Qué lo evita. El precio multidivisa se fija por mercado con redondeo controlado, no se calcula en vivo desde un feed de tipos de cambio en el momento de pagar. El formato de divisa y el manejo de la unidad menor salen de los mismos datos de locale que las fechas y los números, así que el JPY se pinta entero y el KWD con tres decimales, porque el código preguntó a los datos en vez de suponer. Unicode CLDR documenta precisamente esa complejidad de formatear fechas, números, monedas y unidades entre regiones, una complejidad que el software no debería resolver con la suposición de "dos decimales para todo".

6. Escrituras de derecha a izquierda que salen desordenadas

Qué pinta tiene. Texto en árabe o hebreo dentro de una interfaz que nunca se pensó para leerse de derecha a izquierda. En lugar de una maquetación espejada, la interfaz sigue alineada a la izquierda mientras la escritura corre hacia el otro lado, así que la navegación, los iconos y los indicadores de progreso apuntan en dirección contraria al sentido de lectura. Peor todavía: una frase que mezcla árabe con un código de producto latino o un teléfono puede pintarse con los segmentos en orden equivocado, un desorden visual que hace el texto genuinamente difícil de leer, no solo extraño.

Un tratamiento incorrecto de RTL puede dificultar la lectura y transmitir una experiencia poco cuidada, y se lee como software roto, no como una traducción a medias; el impacto comercial concreto en cada mercado debe demostrarse con datos de usuarios o de mercado. El W3C recomienda tratar explícitamente el texto de derecha a izquierda y el texto bidireccional, y probar esos casos con un idioma RTL real.

Qué lo evita. Las maquetaciones usan propiedades CSS lógicas (inicio y fin, no izquierda y derecha) para que el espejado sea automático, y el texto bidireccional se prueba con un locale RTL real, no se da por bueno porque nadie lo tocó. Hay que declarar explícitamente la dirección y conservar el texto en orden lógico; el algoritmo bidireccional de Unicode se ocupa del reordenamiento visual en los casos compatibles. El tema da para tanto que Globaprom lo trata aparte dentro de su práctica de desarrollo de software multilingüe.

7. Columnas de base de datos que no saben guardar escrituras no latinas

Qué pinta tiene. Un cliente llamado "José" se guarda, y luego se muestra, como "José". Un apellido tan español como "Muñoz" vuelve convertido en "Muñoz". El nombre de una empresa japonesa guardado en la base de datos regresa como una fila de interrogaciones o de cuadraditos. Esto pasa cuando una columna, una API heredada o una exportación a fichero usan una codificación que solo cubre caracteres latinos básicos, así que todo lo que quede fuera se corrompe en el momento de escribirlo, no al mostrarlo. El daño ocurre en la capa de almacenamiento, lo que significa que es invisible hasta que alguien mira los datos en crudo o hasta que un cliente se queja de que su propio nombre está mal escrito en su propia factura.

Y no hace falta salir a Asia para pisar la mina. La eñe, la ç del catalán, la ela geminada de "col·legi" y los diacríticos del gallego y el euskera viven todos fuera del ASCII, junto con las comillas angulares y el propio símbolo del euro.

Qué lo evita. Unicode, el estándar que asigna un punto de código a cada carácter de cada sistema de escritura, tiene que ser la codificación de todas las capas: columna de base de datos, cuerpo de la API, exportación a fichero, plantilla de correo. UTF-8, la codificación Unicode dominante, tiene que usarse de punta a punta, porque basta un componente heredado con otra codificación para corromper nombres y direcciones en todo el sistema. El W3C recomienda utilizar Unicode para contenidos, bases de datos y formularios, porque una codificación inadecuada puede impedir que los usuarios lean correctamente los caracteres.

El patrón detrás de los siete

Cada uno de estos errores parece pequeño por separado: un botón cortado, una fecha equivocada, un nombre destrozado. Estos fallos pueden pasar desapercibidos cuando las pruebas se realizan únicamente en el idioma y la región de origen, por lo que conviene incluir pruebas de localización desde fases tempranas. Por eso a menudo sobreviven hasta producción y los descubren clientes que pagan, en otros países, en lugar del equipo de control de calidad.

Los equipos que añaden varias variantes lingüísticas o mercados internacionales se enfrentan antes a estas diferencias de formato, terminología y expectativas, y un equipo español puede tropezar con este patrón dos veces. La primera, al añadir catalán, gallego o euskera, que ya son mercados con sus propios formatos, su propio léxico y su propia expectativa de trato. La segunda, al cruzar el Atlántico: un solo locale llamado "español" da por hecho que ordenador y computadora son la misma palabra, que móvil y celular se entienden igual, y que un verbo perfectamente neutro en Madrid no va a resultar malsonante en Buenos Aires. La traducción no falla; falla la idea de que hay un español y no varios, y esa idea se codifica en la arquitectura mucho antes de que llegue el primer traductor.

Lo que está en juego comercialmente es real. En una encuesta de 8.709 consumidores de 29 países, CSA Research observó que el 76 % prefería comprar productos con información en su idioma y que el 40 % nunca compraría en sitios web en otros idiomas. Un producto que tropieza con su propia traducción pierde esa confianza igual de rápido que uno que nunca se tradujo.

Arreglar estos siete errores después del lanzamiento cuesta mucho más que evitarlos al principio. Corregir la internacionalización después del lanzamiento puede aumentar notablemente el esfuerzo y el riesgo del proyecto, porque hay que encontrar y arreglar todas las capas a la vez (textos, maquetación, formatos, almacenamiento) mientras el producto sigue entregando; la magnitud exacta depende de la arquitectura, la cobertura de pruebas y el alcance de los mercados objetivo. Los mismos siete puntos aprietan más fuerte en desarrollo de ecommerce a medida, donde el checkout, los precios y la ficha de producto tocan de golpe todos los errores de esta lista, y en software de logística a medida, donde los documentos de aduana, las aplicaciones multilingües de conductores y los formatos de fecha y divisa transfronterizos no dejan margen para adivinar.

Preguntas frecuentes sobre errores de internacionalización

¿Cuál es el motivo más común de que un software falle fuera de su país?

Que se construyó suponiendo un idioma y una región, y se tradujo después en lugar de nacer preparado para varios. La traducción cubre el texto visible; los textos incrustados, los diseños rígidos y las suposiciones de formato de debajo siguen rotos.

¿Se pueden arreglar estos errores sin rehacer el producto?

Sí, pero no barato. Cada error hay que encontrarlo y corregirlo en la capa donde vive (código, maquetación o base de datos) mientras el producto sigue en marcha; corregirlo después suele implicar cambios coordinados en código, interfaz, datos y procesos, por lo que puede resultar bastante más costoso y arriesgado que prepararlo desde el inicio.

¿Esto solo afecta a idiomas de derecha a izquierda como el árabe?

No. La expansión del texto, el lío de las fechas y el redondeo de divisas golpean en todos los mercados, incluidos los que leen de izquierda a derecha. El catalán, el alemán y el español de México exponen los mismos fallos; las escrituras RTL solo los enseñan más rápido y de forma más aparatosa.

¿Cómo compruebo si mi software tiene estos problemas?

Haz una pasada de pseudolocalización: sustituye cada texto por relleno alargado y con acentos, y luego clica por todo el producto buscando botones cortados, castellano superviviente y maquetaciones rotas. Puede revelar rápidamente varios de estos problemas visibles, aunque no sustituye las pruebas funcionales, de datos, de formatos y de almacenamiento en cada mercado objetivo.

¿Arreglar la internacionalización significa que tengo que traducirlo todo yo?

No. La internacionalización es trabajo de ingeniería que hace posible la traducción; no te obliga a traducir nada por tu cuenta. Con el código arreglado, la traducción fluye por un pipeline aparte, que es de lo que hablamos en qué significa i18n y en la diferencia entre localización y traducción, otra decisión de presupuesto distinta.

Construye software que no tropiece con su propia traducción

Cuéntanos a qué mercados tiene que llegar tu software. Auditamos cuáles de estos siete errores ya tienes y te presupuestamos el arreglo a precio cerrado, junto con un pipeline de traducción que impida a los idiomas nuevos repetirlos.

Pide un presupuesto cerrado →