Come abbiamo tradotto l'intera piattaforma con l'IA (e cosa c'entra l'Agile)

Alla fine del 2025, la piattaforma di Agile Academy esisteva in due lingue: tedesco e inglese. Quattro mesi dopo, era disponibile in otto. Non abbiamo assunto un'agenzia di traduzione. Abbiamo usato l'IA. E i principi agile hanno fatto tutta la differenza.

Il punto di partenza

Una piattaforma, due codebase, due lingue e un pubblico internazionale in crescita.

Agile Academy non è un'unica applicazione. È un ecosistema:

• Kirby CMS Knowledge Base: 440+ articoli in 10 sezioni, ciascuno con Layout JSON complessi, riferimenti incrociati e routing URL per lingua
• Piattaforma Ruby on Rails: Pagine di prenotazione corsi, corsi e-learning, flussi di checkout, pagine prodotto, con file di localizzazione e viste
• Sistemi backend: Template per email, fatturazione, email transazionali
• Traduzioni UI: Menu, footer, breadcrumb, pulsanti e lo stesso selettore di lingua, su entrambe le piattaforme

Tutto questo esisteva solo in tedesco e inglese. Nel frattempo, non potevamo fornire contenuti curati a chi non parlava inglese o tedesco, una quota crescente del nostro pubblico.

Tradurre tutto questo non era solo un compito di contenuti. Ogni lingua richiedeva:

• Nuove route nella configurazione PHP di Kirby (panoramiche articoli, riscrittura slug di sezione, redirect)
• File di contenuto a livello di sezione con slug URL localizzati
• Pagine panoramiche, landing page e pagine strutturali (legali, eventi, pagine autore)
• File di localizzazione ROR per menu, footer, pagine formazione, email
• Template email nel backend
• Coerenza cross-sistema: la stessa parola "articoli" negli URL, gli stessi link alle pagine legali, la stessa struttura del menu

Un'agenzia di traduzione tradizionale avrebbe potuto gestire il testo degli articoli. Ma nessuno avrebbe scritto le nostre route PHP, sistemato i nostri layout JSON o aggiornato i file di localizzazione Rails. Serviva un approccio diverso.

Iterazione 1: Spagnolo

Copia-incolla, modifiche manuali al codice e un mese di lavoro faticoso. L'approccio waterfall.

Lo spagnolo è stata la nostra prima lingua di espansione. Il processo era così:

1. Copiare il testo di un articolo in ChatGPT o Claude
2. Incollare la traduzione in un nuovo file
3. Sistemare manualmente il Layout JSON (sperando di non romperlo)
4. Ripetere 440 volte solo per Kirby
5. Tradurre separatamente i file di localizzazione ROR, le viste, i template email
6. Aggiungere manualmente route, file di sezione, pagine panoramiche in Kirby
7. Aggiornare manualmente file di localizzazione e route in ROR
8. Creare manualmente i template email nel backend

Ci è voluto circa un mese. Solo le pagine più importanti sono state tradotte in entrambi i sistemi. La qualità era inconsistente. Alcuni articoli usavano un tono formale, altri informale. I termini agile a volte venivano tradotti, a volte no. I riferimenti incrociati tra articoli puntavano a pagine inesistenti.

Il lavoro infrastrutturale è stato ancora più doloroso. Ogni route doveva essere scritta a mano. Ogni file di sezione doveva essere creato da zero. Gli slug degli URL erano inconsistenti. Le piattaforme ROR e Kirby dovevano restare sincronizzate (stessi link nel menu, stesso footer, stesse pagine legali), e tenere traccia di cosa era stato fatto dove era un incubo da foglio di calcolo.

In termini agile, questo era un classico delivery waterfall: un unico grande lotto, cicli di feedback limitati, nessuna automazione, nessuno standard condiviso. Lo abbiamo rilasciato, ma sapevamo che questo approccio non avrebbe potuto scalare per altre sei lingue.

Iterazione 2: Portoghese

Prima automazione, primi script, primo utilizzo di Claude Code. Una settimana invece di un mese.

Per il portoghese, abbiamo cambiato approccio. Invece di copiare e incollare un articolo alla volta, abbiamo scritto script che automatizzavano la traduzione tramite chiamate API. Inserisci la sorgente inglese, ottieni il file Kirby tradotto.

Ancora più importante, abbiamo iniziato a usare Claude Code, non solo per il contenuto degli articoli, ma per il lavoro infrastrutturale. Claude Code poteva leggere le nostre route spagnole esistenti e generare gli equivalenti portoghesi. Poteva creare file di sezione, pagine panoramiche e aggiornare i file di configurazione.

Lato ROR, Claude Code generava i file di localizzazione facendo riferimento alle traduzioni spagnole esistenti. Aggiornava i template email, creava nuove viste dove necessario e manteneva coerenti i riferimenti cross-sistema.

Il risultato: circa una settimana invece di un mese. Ma il tasso di errore era ancora alto.

Gli script non capivano il contesto. Traducevano "Sprint" in portoghese. Rompevano il Layout JSON aggiungendo interruzioni di riga all'interno delle stringhe. Gli slug degli URL a volte erano sbagliati perché l'IA non conosceva le nostre convenzioni di routing su entrambe le piattaforme.

Abbiamo speso tempo significativo nella revisione e correzione. Ma, cosa fondamentale, stavamo ora facendo ispezione e adattamento. Ogni errore trovato diventava una regola per l'iterazione successiva. Abbiamo iniziato un glossario. Abbiamo raffinato il prompt di traduzione. Abbiamo documentato le convenzioni URL che entrambe le piattaforme dovevano seguire.

Iterazioni 3–6: Francese, Italiano, Olandese, Polacco

Agenti specializzati, conoscenza istituzionale e due giorni per lingua.

Quando siamo arrivati al francese, il sistema era maturato considerevolmente. Ciò che ha fatto la vera differenza è stata la suddivisione del lavoro.

Invece di un unico grande contesto IA che cercava di gestire tutto, abbiamo creato agenti specializzati, ciascuno focalizzato su una parte del sistema:

• Agenti di traduzione contenuti che gestivano lotti di articoli Kirby, seguendo il prompt di traduzione e il glossario
• Agenti infrastrutturali che creavano route, file di sezione, pagine panoramiche in Kirby
• Agenti di localizzazione ROR che traducevano e creavano file di localizzazione per la piattaforma Rails
• Agenti di verifica che eseguivano script per individuare JSON rotto, slug URL errati, campi mancanti

Ogni agente aveva una finestra di contesto ridotta focalizzata sul proprio compito specifico. Questo produceva risultati molto migliori rispetto a un unico agente che cercava di tenere in memoria l'intera piattaforma.

La conoscenza istituzionale era ora codificata:

• Un prompt di traduzione (TRANSLATION_PROMPT.md) definiva tono, formato, regole URL e il requisito dell'avviso IA
• Un glossario (glossary.json) manteneva i termini agile coerenti in tutte le lingue
• Script di verifica individuavano errori prima che raggiungessero la produzione: Layout JSON rotto, riferimenti hreflang errati, campi obbligatori mancanti
• Una checklist in CLAUDE.md documentava ogni passaggio infrastrutturale necessario per una nuova lingua (route, file di sezione, pagine panoramiche, pagine strutturali, sincronizzazione menu/footer)
• Controlli di coerenza cross-sistema assicuravano che Kirby e ROR restassero sincronizzati

L'italiano ha richiesto due giorni. L'olandese ha richiesto due giorni. Il polacco ha richiesto due giorni. Ogni iterazione era più veloce e affidabile. Il tasso di errore diminuiva con ogni lingua perché il sistema imparava da ogni errore precedente.

Prima e dopo

Lo stesso compito. Un sistema fondamentalmente diverso.

I principi Agile in azione

Questo non era solo un progetto di traduzione. Erano sei Sprint di apprendimento organizzativo.

Miglioramento iterativo

Ogni lingua era uno Sprint. Lo spagnolo è stato lo Sprint 1: lento, manuale, pieno di apprendimento. Il polacco è stato lo Sprint 6: veloce, automatizzato, raffinato. Il miglioramento è stato esponenziale. Ogni iterazione non aggiungeva solo una lingua. Migliorava il sistema per tutte le lingue future.

Ispezionare e adattare

Ogni errore in una lingua diventava una regola di prevenzione per la successiva. JSON rotto? Aggiungere un validatore JSON allo script di verifica. "Sprint" tradotto in portoghese? Aggiungerlo al glossario. Convenzione slug URL sbagliata? Documentarla nella checklist. Il sistema diventava più intelligente perché avevamo costruito cicli di feedback al suo interno.

Team auto-organizzati

Gli agenti specializzati erano, in effetti, membri di team auto-organizzati. Ciascuno aveva una responsabilità chiara, il contesto giusto per il proprio compito e interfacce definite con gli altri. L'agente dei contenuti non aveva bisogno di conoscere le route PHP. L'agente infrastrutturale non aveva bisogno di parsare il Layout JSON. Separazione delle responsabilità. Funziona per il software e per i team.

Software funzionante rispetto alla documentazione

Il prompt di traduzione, il glossario, gli script di verifica. Niente di tutto ciò è stato progettato a priori. Sono nati da problemi reali incontrati durante il lavoro reale. Il prompt è stato riscritto cinque volte. Il glossario è cresciuto con ogni lingua. Gli script sono nati da errori sfuggiti alla revisione manuale. La documentazione vivente, plasmata dall'uso reale, si è rivelata molto più utile di qualsiasi specifica avremmo potuto scrivere a priori.

Rispondere al cambiamento

Le nostre decisioni architetturali sono state guidate dagli errori, non dalla pianificazione a priori. Non avevamo previsto che il Layout JSON sarebbe stato la principale fonte di bug. Lo abbiamo scoperto durante lo spagnolo e abbiamo costruito la validazione prima del portoghese. Non avevamo pianificato la specializzazione degli agenti. Ci siamo arrivati dopo aver visto che un unico grande contesto produceva risultati peggiori di diversi contesti focalizzati. Abbiamo ottenuto un setup migliore di qualsiasi cosa avremmo potuto progettare su una lavagna.

Conclusioni chiave

L'IA non sostituisce il pensiero agile. Lo amplifica.

1. L'IA amplifica il tuo processo, nel bene e nel male

Se il tuo processo è caotico, l'IA produrrà caos più velocemente. Se il tuo processo è disciplinato (prompt chiari, standard definiti, cicli di verifica), l'IA produrrà qualità su larga scala. Lo stesso strumento che rompeva i nostri JSON nell'iterazione 1 produceva output impeccabili nell'iterazione 6. L'IA non è cambiata. Il nostro processo sì.

2. Il contesto è tutto

Il glossario, il prompt di traduzione, la checklist, le regole di coerenza cross-sistema. Sono tutte forme di contesto. Un'IA senza contesto è solo un traduttore veloce. Un'IA con il contesto giusto è un membro del team che comprende le tue convenzioni, i tuoi casi limite e i tuoi standard di qualità. Costruire quel contesto è dove va il vero lavoro, e si accumula con ogni nuova lingua aggiunta.

3. Il ruolo umano passa da esecutore ad architetto

Nell'iterazione 1, gli umani facevano la traduzione. Nell'iterazione 6, gli umani progettavano il sistema, definivano gli standard, revisionavano l'output e miglioravano il processo. Il lavoro non è scomparso. Si è spostato verso un pensiero di livello superiore. Meno copia e incolla, più riflessione su cosa rende una buona traduzione, cosa rende un'esperienza utente coerente e come individuare gli errori prima che lo facciano gli utenti.

4. Inizia in piccolo, rilascia, impara, ripeti

Avremmo potuto passare mesi a progettare la pipeline di traduzione "perfetta" prima di tradurre un singolo articolo. Invece, abbiamo iniziato con il copia-incolla e iterato. Ogni lingua ci ha insegnato qualcosa. Ogni errore ha migliorato il sistema. Quando siamo arrivati alle ultime lingue, avevamo una pipeline che nessuna pianificazione a priori avrebbe potuto produrre, perché era stata plasmata da problemi reali, non ipotetici.