Las apps modernas tienen un problema de localización. Y no es la traducción.
Durante la última década, la industria de la localización se ha centrado en los flujos de traducción: herramientas que ayudan a los equipos a gestionar traductores, revisar cadenas y lanzar contenido multilingüe.
Herramientas como Phrase, Lokalise, Crowdin y Transifex son excelentes gestionando traducciones. Pero todas dan por sentado algo crítico: que tu aplicación ya está internacionalizada. En realidad, la mayoría no lo está. Y con el auge del código generado por IA, esa brecha está a punto de convertirse en un problema enorme.
¿Cuál es la capa oculta de i18n que las herramientas de localización pasan por alto?
Localización e internacionalización se confunden a menudo. No son lo mismo.
Localización (l10n) — Traducir una app a distintos idiomas.
Internacionalización (i18n) — Preparar el codebase para que la traducción sea siquiera posible.
Internacionalizar implica cosas como: extraer cadenas de UI, generar claves de traducción, crear archivos de locale, admitir reglas de plural, dar formato a números y fechas, admitir idiomas de derecha a izquierda y evitar texto de UI codificado. La mayoría de las herramientas de localización empiezan después de este paso. Pero en muchos codebases reales, este paso nunca llegó a suceder.
Cómo es el código correctamente internacionalizado
En una app bien estructurada, el texto de la UI se referencia mediante claves de traducción.
<button>{t("checkout.submit_order")}</button>
El texto vive en archivos de locale:
/locales/en.json
{
"checkout.submit_order": "Submit order"
}
Esta estructura permite que las herramientas y motores de traducción funcionen de forma fiable.
Cómo son la mayoría de las apps en realidad
En la práctica, muchas apps se ven así:
<button>Submit order</button>
<h1>Welcome back</h1>
<p>Your payment was successful</p>
A primera vista parece inofensivo. Pero multiplícalo por cientos de componentes y miles de cadenas de UI. Ahora todo el codebase asume una UI solo en inglés. En el momento en que intentas admitir otro idioma, empiezan a aparecer problemas por todas partes.
- El texto en alemán se expande ~30 % más. Los botones se desbordan.
- El árabe requiere layouts de derecha a izquierda. Interfaces enteras se rompen.
- Las reglas de plural difieren entre idiomas. Los mensajes acaban siendo gramaticalmente incorrectos.
Sin arquitectura de internacionalización, la localización se convierte rápidamente en un proyecto de refactorización enorme.
¿Cómo hizo la generación de código con IA que la localización fuera más difícil?
El desarrollo moderno depende cada vez más de herramientas de IA para programar: Cursor, GitHub Copilot, ChatGPT, Replit, Lovable, Bolt. Estas herramientas optimizan para la velocidad y una UI funcional, no para la arquitectura.
El código generado típico se ve así:
<button>Submit</button>
<h2>Welcome back</h2>
<p>Your order has been confirmed</p>
En un proyecto típico generado por IA puedes encontrar: cientos o miles de cadenas de UI codificadas, texto de interfaz duplicado, sin claves de traducción, sin archivos de locale, sin soporte de pluralización. Dicho de otro modo: demos perfectas, arquitectura de localización pésima.
El patrón es predecible. Los equipos desarrollan rápido, lanzan, ganan tracción — y entonces se dan cuenta: «Toda nuestra UI está en inglés codificado». Llegados a ese punto, añadir localización obliga a tocar una porción enorme del codebase de la UI.
Un patrón real que estamos viendo
Al escanear pequeños proyectos SaaS generados por IA, aparece un patrón enseguida. En un proyecto prototipo de React que analizamos: 1284 cadenas de UI en 312 archivos, sin ninguna estructura de internacionalización. Algunos ejemplos:
<h1>Welcome back</h1>
<button>Start free trial</button>
<p>Your payment failed</p>
Para añadir localización, el equipo tuvo que: extraer cadenas de UI de cientos de componentes, introducir claves de traducción, construir archivos de locale, reescribir la lógica de UI — antes incluso de poder empezar a traducir. Estamos viendo este patrón repetirse una y otra vez en proyectos generados por IA.
¿Por qué las herramientas de localización tradicionales no pueden con el código generado por IA?
La mayoría de las herramientas de localización se diseñaron para equipos de traducción, no para developers. Sus flujos de trabajo asumen que el equipo de desarrollo ya implementó: un framework de i18n, claves de traducción, estructuras de archivos de locale, pipelines de extracción de cadenas. Pero los codebases modernos —sobre todo los generados por IA— a menudo carecen por completo de esta base. Así que los equipos se enfrentan a una realidad inesperada: antes de poder traducir nada, primero tienen que refactorizar toda la capa de UI.
La capa que falta en el stack de localización
El stack de localización actual suele verse así:
Pero falta algo crítico. Lo que realmente tiene que pasar es:
Esa capa que falta necesita: escanear el codebase, extraer cadenas de UI, generar claves de traducción, construir archivos de locale, detectar cadenas duplicadas, crear glosarios de terminología. Solo entonces pueden empezar los flujos de traducción.
Por qué este problema está a punto de estallar
Tres grandes tendencias están chocando entre sí.
- Desarrollo AI-first. Cada vez más apps se construyen con codificación asistida por IA. Algunos codebases de startups son hoy en gran parte generados por IA. La arquitectura suele pasar a segundo plano frente a la velocidad de lanzamiento.
- El auge de los indie hackers. Cada semana se lanzan miles de productos SaaS nuevos. La mayoría se lanza primero en inglés.
- Usuarios globales desde el primer día. Incluso los productos pequeños atraen rápidamente a usuarios de Alemania, Brasil, India, Japón. En cuanto llegan usuarios internacionales, la localización se vuelve urgente. Pero la arquitectura normalmente no está lista.
Un enfoque diferente
¿Y si la internacionalización pudiera automatizarse? Eso es exactamente lo que hace conectar tu repositorio en globalize.now. La primera conversión se ejecuta una vez, en la app, y devuelve un informe con lo que encontró:
✔ Found 128 UI strings
✔ Generated 92 translation keys
✔ Created /locales/en.json
✔ Updated 41 files
Done in 2.7s
La herramienta se encargaría de: escanear el codebase, extraer las cadenas orientadas al usuario, generar claves de traducción estructuradas, crear archivos de locale, reescribir el código de la UI automáticamente. Convirtiendo esto:
<button>Submit order</button>
En esto:
<button>{t("checkout.submit_order")}</button>
De repente, todo el codebase queda listo para traducir.
Una nueva categoría: localización lista para IA
La próxima generación de herramientas de localización no empezará por los traductores. Empezará por la transformación del código. El flujo de trabajo se parecerá más a esto:
El mayor hueco del ecosistema de localización hoy es automatizar ese primer paso: preparar el codebase para usuarios globales.
Descubre cómo globalize.now gestiona esto automáticamente para equipos de developers.
Para el recorrido histórico desde las herramientas CAT hasta los flujos de trabajo nativos de IA, lee las tres etapas de la localización en la era de la IA.
El futuro de la localización
La localización solía ser un problema de traducción. En la era del desarrollo con IA, se está convirtiendo en un problema de arquitectura de código. Los equipos que resuelvan esta capa definirán cómo se construye el software global en la próxima década.
globalize.now convierte el texto codificado de tu app en archivos de traducción listos para localizar y los mantiene actualizados en cada despliegue.
Prueba globalize.now gratis