Cómo tradujimos toda nuestra plataforma con IA (y qué tuvo que ver Agile con ello)

A finales de 2025, la plataforma de Agile Academy existía en dos idiomas: alemán e inglés. Cuatro meses después, estaba disponible en ocho. No contratamos una agencia de traducción. Usamos IA. Y los principios ágiles marcaron la diferencia.

El punto de partida

Una plataforma, dos bases de código, dos idiomas y una audiencia internacional en crecimiento.

Agile Academy no es una aplicación única. Es un ecosistema:

• Base de Conocimiento Kirby CMS: más de 440 artículos en 10 secciones, cada uno con Layout JSON complejo, referencias cruzadas y enrutamiento de URL por idioma
• Plataforma Ruby on Rails: páginas de reserva de formación, cursos de e-learning, flujos de pago, páginas de producto, con archivos de localización y vistas
• Sistemas Backend: plantillas de correo, facturación, correos transaccionales
• Traducciones de UI: menús, pies de página, breadcrumbs, botones y el propio selector de idioma, en ambas plataformas

Todo esto existía solo en alemán e inglés. Mientras tanto, no podíamos ofrecer contenido curado a hablantes que no fueran de inglés o alemán, que representaban una parte creciente de nuestra audiencia.

Traducir esto no era solo una tarea de contenido. Cada idioma requería:

• Nuevas rutas en la configuración PHP de Kirby (vistas generales de artículos, reescrituras de slugs de sección, redirecciones)
• Archivos de contenido a nivel de sección con slugs de URL localizados
• Páginas de vista general, landing pages y páginas estructurales (legal, eventos, páginas de autor)
• Archivos de localización de ROR para menús, pie de página, páginas de formación, correos
• Plantillas de mailing en el backend
• Consistencia entre sistemas: la misma palabra "artículos" en las URL, los mismos enlaces legales, la misma estructura de menú

Una agencia de traducción tradicional podía encargarse del texto de los artículos. Pero nadie iba a escribir nuestras rutas PHP, arreglar nuestros layouts JSON ni actualizar nuestros archivos de localización de Rails. Necesitábamos un enfoque diferente.

Iteración 1: Español

Copiar y pegar, cambios manuales en el código y un mes de trabajo pesado. El enfoque en cascada.

El español fue nuestro primer idioma de expansión. El proceso se veía así:

1. Copiar el texto de un artículo en ChatGPT o Claude
2. Pegar la traducción de vuelta en un archivo nuevo
3. Arreglar manualmente el Layout JSON (esperando no romperlo)
4. Repetir 440 veces solo para Kirby
5. Traducir por separado los archivos de localización de ROR, vistas y plantillas de mailing
6. Agregar manualmente rutas, archivos de sección y páginas de vista general en Kirby
7. Actualizar manualmente archivos de localización y rutas en ROR
8. Crear manualmente plantillas de mailing en el backend

Tomó aproximadamente un mes. Solo las páginas más importantes fueron traducidas en ambos sistemas. La calidad era inconsistente. Algunos artículos usaban tono formal, otros informal. Los términos ágiles a veces se traducían, a veces no. Las referencias cruzadas entre artículos apuntaban a páginas inexistentes.

El trabajo de infraestructura fue aún más doloroso. Cada ruta tuvo que escribirse a mano. Cada archivo de sección tuvo que crearse desde cero. Los slugs de URL eran inconsistentes. Las plataformas ROR y Kirby tenían que mantenerse sincronizadas (mismos enlaces de menú, mismo pie de página, mismas páginas legales), y llevar un registro de qué se había hecho dónde era una pesadilla de hojas de cálculo.

En términos ágiles, esto fue una entrega clásica en cascada: un gran lote, ciclos de retroalimentación limitados, sin automatización, sin estándares compartidos. Lo lanzamos, pero sabíamos que no podíamos escalar este enfoque a seis idiomas más.

Iteración 2: Portugués

Primera automatización, primeros scripts, primer uso de Claude Code. Una semana en lugar de un mes.

Para el portugués, cambiamos el enfoque. En lugar de copiar y pegar artículo por artículo, escribimos scripts que automatizaban la traducción mediante llamadas a la API de Claude. Tomábamos como origen el inglés y obteníamos el archivo Kirby traducido.

Más importante aún, comenzamos a usar Claude Code, no solo para el contenido de los artículos, sino para el trabajo de infraestructura. Claude Code podía leer nuestras rutas existentes en inglés y generar los equivalentes en portugués. Podía crear archivos de sección, páginas de vista general y actualizar archivos de configuración.

En el lado de ROR, Claude Code generó archivos de localización referenciando las traducciones existentes en inglés. Actualizó plantillas de mailing, creó nuevas vistas donde fue necesario y mantuvo la consistencia de las referencias entre sistemas.

El resultado: aproximadamente una semana en lugar de un mes. Pero la tasa de errores seguía siendo alta.

Los scripts no entendían el contexto. Traducían "Sprint" al portugués. Rompían el Layout JSON agregando saltos de línea dentro de cadenas de texto. Los slugs de URL a veces eran incorrectos porque la IA no conocía nuestras convenciones de enrutamiento en ambas plataformas.

Dedicamos un tiempo significativo a revisar y corregir. Pero fundamentalmente, ahora estábamos inspeccionando y adaptando. Cada error que encontrábamos se convertía en una regla para la siguiente iteración. Empezamos un glosario. Refinamos el prompt de traducción. Documentamos las convenciones de URL que ambas plataformas debían seguir.

Iteraciones 3–6: Francés, Italiano, Holandés, Polaco

Agentes especializados, conocimiento institucional y dos días por idioma.

Para cuando llegamos al francés, el sistema había madurado considerablemente. Lo que realmente marcó la diferencia fue dividir el trabajo.

En lugar de un solo contexto grande de IA intentando manejar todo, creamos agentes especializados, cada uno enfocado en una parte del sistema:

• Agentes de traducción de contenido que manejaban lotes de artículos de Kirby, siguiendo el prompt de traducción y el glosario
• Agentes de infraestructura que creaban rutas, archivos de sección y páginas de vista general en Kirby
• Agentes de localización ROR que traducían y creaban archivos de localización para la plataforma Rails
• Agentes de verificación que ejecutaban scripts para detectar JSON roto, slugs de URL incorrectos y campos faltantes

Cada agente tenía una ventana de contexto reducida enfocada en su tarea específica. Esto producía resultados mucho mejores que un solo agente intentando mantener toda la plataforma en memoria.

El conocimiento institucional ahora estaba codificado:

• Un prompt de traducción (TRANSLATION_PROMPT.md) definía el tono, formato, reglas de URL y el requisito de aviso de IA
• Un glosario (glossary.json) mantenía los términos ágiles consistentes en todos los idiomas
• Scripts de verificación detectaban errores antes de que llegaran a producción: Layout JSON roto, referencias hreflang incorrectas, campos requeridos faltantes
• Una checklist en CLAUDE.md documentaba cada paso de infraestructura requerido para un nuevo idioma (rutas, archivos de sección, páginas de vista general, páginas estructurales, sincronización menú/pie de página)
• Verificaciones de consistencia entre sistemas aseguraban que Kirby y ROR se mantuvieran sincronizados

El italiano tomó dos días. El holandés tomó dos días. El polaco tomó dos días. Cada iteración fue más rápida y más confiable. La tasa de errores disminuyó con cada idioma porque el sistema aprendía de cada error anterior.

Antes y después

La misma tarea. Un sistema fundamentalmente diferente.

Los principios ágiles en acción

Esto no fue solo un proyecto de traducción. Fueron seis Sprints de aprendizaje organizacional.

Mejora iterativa

Cada idioma fue un Sprint. El español fue el Sprint 1: lento, manual, lleno de aprendizaje. El polaco fue el Sprint 6: rápido, automatizado, refinado. La mejora fue exponencial. Cada iteración no solo agregaba un idioma. Mejoraba el sistema para todos los idiomas futuros.

Inspeccionar y adaptar

Cada error en un idioma se convertía en una regla de prevención para el siguiente. ¿JSON roto? Agregar un validador de JSON al script de verificación. ¿"Sprint" traducido al portugués? Agregarlo al glosario. ¿Convención de slugs de URL incorrecta? Documentarla en la checklist. El sistema se volvía más inteligente porque construimos ciclos de retroalimentación dentro de él.

Equipos autoorganizados

Los agentes especializados eran, en efecto, miembros de equipo autoorganizados. Cada uno tenía una responsabilidad clara, el contexto adecuado para su tarea e interfaces definidas con los demás. El agente de contenido no necesitaba saber sobre rutas PHP. El agente de infraestructura no necesitaba analizar Layout JSON. Separación de responsabilidades. Funciona para el software y para los equipos.

Software funcionando sobre documentación

El prompt de traducción, el glosario, los scripts de verificación. Nada de esto fue diseñado de antemano. Surgieron de problemas reales que encontramos durante el trabajo real. El prompt fue reescrito cinco veces. El glosario creció con cada idioma. Los scripts nacieron de errores que se filtraron a través de la revisión manual. La documentación viva, moldeada por el uso real, resultó ser mucho más útil que cualquier especificación que pudiéramos haber escrito de antemano.

Responder al cambio

Nuestras decisiones de arquitectura fueron impulsadas por errores, no por planificación anticipada. No predijimos que el Layout JSON sería la mayor fuente de bugs. Lo descubrimos durante el español y construimos validación para ello antes del portugués. No planificamos la especialización de agentes. Llegamos a ella después de ver que un contexto grande producía peores resultados que varios enfocados. Terminamos con una configuración mejor que cualquier cosa que pudiéramos haber diseñado en una pizarra.

Conclusiones clave

La IA no reemplaza el pensamiento ágil. Lo amplifica.

1. La IA amplifica tu proceso, para bien o para mal

Si tu proceso es caótico, la IA producirá caos más rápido. Si tu proceso es disciplinado (prompts claros, estándares definidos, ciclos de verificación), la IA producirá calidad a escala. La misma herramienta que rompió nuestro JSON en la iteración 1 producía resultados impecables en la iteración 6. La IA no cambió. Nuestro proceso sí.

2. El contexto lo es todo

El glosario, el prompt de traducción, la checklist, las reglas de consistencia entre sistemas. Todas son formas de contexto. Una IA sin contexto es solo un traductor rápido. Una IA con el contexto adecuado es un miembro del equipo que entiende tus convenciones, tus casos límite y tus estándares de calidad. Construir ese contexto es donde va el verdadero trabajo, y se acumula con cada nuevo idioma que agregas.

3. El rol humano pasa de ejecutor a arquitecto

En la iteración 1, los humanos hacían la traducción. En la iteración 6, los humanos diseñaban el sistema, definían los estándares, revisaban el resultado y mejoraban el proceso. El trabajo no desapareció. Se trasladó a un pensamiento de nivel superior. Menos copiar y pegar, más pensar en qué hace una buena traducción, qué hace una experiencia de usuario consistente y cómo detectar errores antes que los usuarios.

4. Empieza pequeño, lanza, aprende, repite

Podríamos haber pasado meses diseñando el pipeline de traducción "perfecto" antes de traducir un solo artículo. En cambio, empezamos con copiar y pegar e iteramos. Cada idioma nos enseñó algo. Cada error mejoró el sistema. Para cuando llegamos a los últimos idiomas, teníamos un pipeline que ninguna planificación anticipada podría haber producido, porque fue moldeado por problemas reales, no hipotéticos.