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

El software falla fuera de casa porque se construyó para un idioma y una región, y después se le pidió servir a otras sin cambiar cómo estaba construido. La traducción entra bien. 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 clicar por encima de la compilación) 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. El finés empeora lo mismo: sus palabras compuestas pasan de 20 caracteres donde el castellano usa dos palabras cortas. 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. El texto de interfaz en alemán corre entre un 30 y un 35 % más largo que en inglés de media, y las cadenas cortas de menos de 10 caracteres pueden expandirse entre un 200 y un 300 % (W3C). 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. 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. El yen japonés tiene cero decimales, mientras que el dinar bareiní, el dinar kuwaití y el rial omaní usan tres. 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.

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.

El usuario lo nota en segundos, y lo lee como software roto, no como una traducción a medias. Es una de las formas más rápidas de perder credibilidad en un mercado entero.

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ó. 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 correr de punta a punta, porque basta un componente heredado con otra codificación para corromper nombres y direcciones en todo el sistema.

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. Ninguno aparece en pruebas hechas enteramente en el idioma de casa, porque ese idioma es justo el único al que ninguno afecta. Por eso exactamente sobreviven hasta producción y los descubren clientes que pagan, en otros países, en lugar del equipo de control de calidad.

Un equipo español topa con este patrón antes que la mayoría, y encima 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 vaya 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 comercial que hay en juego es real. El estudio de CSA Research sobre 8.709 consumidores de 29 países encontró que el 76 % prefiere comprar productos con información en su propio idioma, y que el 40 % no comprará jamás en webs en otros idiomas (CSA Research). 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. Meter la internacionalización con calzador en un producto ya en explotación cuesta entre dos y cinco veces más esfuerzo de ingeniería que integrarla desde el primer día (XTM, 2026), porque hay que encontrar y arreglar todas las capas a la vez (textos, maquetación, formatos, almacenamiento) mientras el producto sigue entregando. 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, y por eso una reforma cuesta entre dos y cinco veces más que construirlo bien desde el principio (XTM, 2026).

¿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. Saca la mayoría de estos siete errores en una tarde.

¿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 una tubería aparte, que es de lo que hablamos en qué significa i18n (en inglés) 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 una tubería de traducción que impida a los idiomas nuevos repetirlos.

Pide un presupuesto cerrado →