¿Qué pasa cuando un agente de IA internacionaliza un monorepo real?

Extrajo 28 cadenas de UI candidatas, reescribió 41 entradas de traducción repartidas en varios archivos, configuró el middleware y el enrutamiento, y generó los archivos de locale para 5 idiomas de destino. La configuración, la conversión y la traducción tardaron en total unos 90 minutos. globalize.now es infraestructura de localización impulsada por IA, y la pusimos a prueba en un monorepo de producción para ver qué pasaba de verdad. Sin demo preparada. Sin red de seguridad. Solo un codebase real con complejidad real.

El codebase pertenecía a un veterano del sector de la localización que pasó más de una década como arquitecto en una de las principales plataformas de gestión de traducciones.

¿Qué había en el monorepo?

Esto no era un proyecto de tutorial. El monorepo contenía una aplicación web en Next.js, una app de Android, servidores MCP y documentación renderizada por un servicio externo. El desarrollador usa Claude Code a diario, construye con herramientas de IA de principio a fin, y había montado todo el stack en tres meses.

El objetivo era el frontend en Next.js. La app de Android, los servidores MCP y el sitio de documentación construido sobre Mintlify no debían tocarse. La pregunta era si un agente de IA podía averiguar eso sin que se le indicara explícitamente.

Pudo. El agente escaneó todo el repo y se centró en la aplicación de Next.js. En la práctica no hizo falta acotar el alcance manualmente, aunque el desarrollador comentó que le habría gustado poder indicar «convertir solo /apps/web» para mayor tranquilidad. Es un comentario razonable y algo que vale la pena añadir. Pero no impidió la conversión.

¿Cómo funcionó la configuración?

El desarrollador eligió el modo guiado para entender el proceso. La configuración cubrió cinco decisiones: gestor de paquetes (NPM, a pesar de que también existía un lockfile heredado de PNPM), formato del catálogo (PO/GetText, recomendado por su soporte de comentarios), modo de configuración (guiado), idioma de origen (inglés) e idiomas de destino (español, italiano, húngaro, checo y eslovaco).

Una observación a destacar: la pregunta sobre el formato del catálogo generó dudas incluso en alguien con amplia experiencia en localización. Su reacción fue directa. No consideraba que la elección fuera lo bastante relevante como para preguntársela al usuario. Automatízalo.

La estrategia de enrutamiento fue basada en rutas. No hubo enrutamiento basado en dominios, ya que el desarrollador no tenía dominios adicionales. La app usa autenticación basada en OAuth, así que los flujos de inicio de sesión se mantuvieron en inglés a propósito. El agente gestionó esto correctamente.

¿Qué hace exactamente el paso de conversión?

Esta es la parte que importa. El agente identificó 28 candidatas a cadena de UI en la app de Next.js y procesó 41 entradas de traducción. Reorganizó archivos, actualizó el middleware, modificó imports de componentes y generó archivos de locale PO para los 5 idiomas de destino.

Solo el paso de conversión tardó unos 30 minutos. Sumando la preparación y configuración previas, y la conexión de la traducción que el desarrollador completó después por su cuenta, el proceso completo de principio a fin rondó los 90 minutos. Eso no es instantáneo. Para dar contexto: una app sencilla con un puñado de páginas completa el flujo completo en menos de 15 minutos. Una app compleja con decenas de superficies traducibles tarda más. El tiempo escala con el número de cadenas, no con el tamaño del repo.

El desarrollador vio correr el paso de conversión y dijo esto: la extracción de cadenas y la reescritura de código es el trabajo pesado. Este es el trabajo que los developers temen. En su anterior empresa, un TMS líder, los archivos de traducción del repo eran solo la punta del iceberg. La preparación y el trabajo de internacionalización eran el verdadero dolor de cabeza. Y el agente de IA se encargó exactamente de esa parte.

Esto coincide con lo que oímos de todos los developers que han pasado por i18n a mano. Nadie se queja de las traducciones. Se quejan de tener que tocar 40 archivos para envolver cadenas en llamadas a t(), generar claves con sentido, reestructurar imports y configurar el middleware. Eso es el trabajo que globalize.now automatiza.

¿Funcionó de verdad de principio a fin?

Sí. Después de terminar la sesión en directo, el desarrollador completó los pasos restantes por su cuenta. Publicó la rama Git de globalize.now, conectó la app a la plataforma web, configuró la monitorización en la rama de globalize.now y confirmó que los archivos se subieron y tradujeron correctamente.

Su valoración de la calidad de la traducción al checo: casi perfecta. Esto lo dice alguien que se ha pasado la carrera evaluando profesionalmente resultados de localización. No es un visto bueno genérico. Es un experto del sector confirmando calidad lista para producción en un par de idiomas nada trivial.

Detectó dos problemas en la web app después de completar el flujo por su cuenta. Primero, un nuevo escaneo del repo mostró «no se detectaron archivos i18n» aunque el trabajo de traducción se estaba ejecutando en segundo plano. Un estado de UI engañoso, no un fallo real. Segundo, el trabajo de traducción se inició sin consentimiento explícito. Cualquier acción que consuma créditos debería requerir confirmación. Ambos son problemas de UX válidos que ya se están corrigiendo.

¿Qué salió mal?

Hubo fallos. Esto fue una prueba real, así que vamos a ser sinceros al respecto.

El comando de instalación (npx skills add globalize-now/globalize-skills) falló en Windows PowerShell. Era la primera vez que la herramienta se probaba en Windows. Los Skills tuvieron que enviarse como archivo zip por Swiss Transfer después de que Google bloqueara el adjunto del correo. Fricción total de configuración: unos 15 minutos antes de que arrancara el flujo real.

A mitad de la conversión surgió un conflicto entre ES modules y CommonJS. El proyecto usa CommonJS, y el resultado del agente asumió ES modules en un punto concreto. No fue un bloqueante, pero es algo que debería detectarse durante la configuración y gestionarse de forma proactiva.

Al final de la sesión, conectar el repositorio de GitHub en la web app de globalize.now devolvió una página en blanco. El desarrollador estaba usando Opera. Sin pantalla de login, sin error, sin contenido. La sesión terminó antes de resolverlo.

Tres bugs. Todos reales. Todos corregidos o en proceso.

¿Por qué la extracción de cadenas es el verdadero cuello de botella?

La mayoría del contenido sobre i18n se centra en la calidad de la traducción, la configuración del framework o comparativas de features de TMS. Eso pasa por alto dónde pierden el tiempo realmente los developers.

Añadir internacionalización a un codebase existente significa escanear cada componente en busca de cadenas codificadas, decidir qué cadenas son traducibles, generar claves de traducción con sentido, envolver cada cadena en la llamada a t() o <Trans> correspondiente, actualizar imports por todo el árbol de archivos, crear los archivos de locale iniciales y configurar el middleware de enrutado. En un monorepo, súmale la complejidad de averiguar qué partes del codebase necesitan i18n siquiera.

Esto es tedioso, propenso a errores, y exactamente el tipo de trabajo en el que los agentes de IA destacan. El desarrollador que lo vio en directo lo dijo claramente: desde la perspectiva del developer, esto es el trabajo pesado. Es un alivio enorme. Los Vibe Coders que desarrollan con herramientas de IA ahora pueden saltarse por completo la peor parte de internacionalizar.

¿Qué aprendimos sobre el scoping en monorepos?

El agente gestionó el scoping del monorepo de forma implícita. Se centró en la web app de Next.js e ignoró el código de Android, los servidores MCP y la documentación de Mintlify sin que se le indicara. Es el comportamiento correcto para la mayoría de los casos.

Pero el scoping implícito no es lo mismo que el scoping explícito. El desarrollador quería poder decir «convierte solo mi app de Next.js» como paso de configuración. En un monorepo con varios frontends web, por ejemplo una app de cara al cliente y un panel de administración, querrías control preciso sobre qué frontend se internacionaliza primero.

Es un hueco de producto que estamos cerrando. Por ahora, el agente acierta en la práctica. El scoping explícito debería ser un paso de configuración, sobre todo cuando la conversión toca decenas de archivos.

¿Cómo se compara esto con una configuración manual de i18n?

Configurar i18n a mano en un codebase de esta complejidad lleva días. No porque ningún paso individual sea difícil, sino porque hay decenas de pasos y cada uno exige atención. Te olvidas de una cadena y despliegas una página traducida a medias. Pones mal el nombre de una clave y creas entradas duplicadas que te perseguirán durante meses. Olvidas actualizar el middleware y el enrutado por idioma se rompe en silencio.

El agente de IA completó el trabajo equivalente en unos 90 minutos, de principio a fin. El desarrollador, alguien que ha visto miles de implementaciones de i18n a nivel profesional, lo calificó de elegante.

Para los developers que construyen con herramientas de IA, esto cambia el cálculo de cuándo añadir idiomas. Si configurar i18n lleva una semana, lo pospones hasta haber validado el product-market fit. Si lleva 90 minutos, puedes lanzar multilingüe desde el primer día.

globalize.now se encarga de esto. Conecta tu repositorio y la conversión se ejecuta una vez, en la app; los Skills de npx skills add globalize-now/globalize-skills cubren lo que sigue en tu editor. Descubre cómo funciona en globalize.now.