Cosa succede quando un agente IA internazionalizza un monorepo reale?

Ha estratto 28 stringhe candidate per la UI, riscritto 41 voci di traduzione su più file, configurato middleware e routing, e generato file di traduzione per 5 lingue di destinazione. Configurazione, conversione e traduzione hanno richiesto circa 90 minuti complessivi. globalize.now è un'infrastruttura di localizzazione basata su IA, e l'abbiamo messa alla prova su un monorepo di produzione per vedere cosa sarebbe realmente successo. Nessuna demo confezionata. Nessuna rete di sicurezza. Solo una codebase reale con una complessità reale.

La codebase apparteneva a un veterano del settore della localizzazione, che ha trascorso oltre un decennio come architetto in una delle principali piattaforme di gestione delle traduzioni.

Cosa conteneva il monorepo?

Non era un progetto tutorial. Il monorepo conteneva un'applicazione web Next.js, un'app Android, server MCP e documentazione renderizzata da un servizio di terze parti. Lo sviluppatore usa Claude Code ogni giorno, costruisce con strumenti IA dall'inizio alla fine, e aveva assemblato l'intero stack in tre mesi.

L'obiettivo era il frontend Next.js. L'app Android, i server MCP, il sito di documentazione costruito su Mintlify: nulla di tutto ciò andava toccato. La domanda era se un agente IA potesse capirlo da solo, senza istruzioni esplicite.

Ce l'ha fatta. L'agente ha scansionato l'intero repo e si è concentrato sull'applicazione Next.js. Nella pratica non è servito alcuno scoping manuale, anche se lo sviluppatore ha notato che avrebbe apprezzato la possibilità di dire «converti solo /apps/web» per stare più tranquillo. È un'osservazione legittima e qualcosa che vale la pena aggiungere. Ma non ha bloccato la conversione.

Come ha funzionato la configurazione?

Lo sviluppatore ha scelto la modalità guidata per capire il processo. La configurazione ha coperto cinque decisioni: package manager (NPM, nonostante esistesse anche un lockfile PNPM legacy), formato del catalogo (PO/GetText, consigliato per il supporto ai commenti), modalità di setup (guidata), lingua di origine (inglese) e lingue di destinazione (spagnolo, italiano, ungherese, ceco, slovacco).

Un'osservazione degna di nota: la domanda sul formato del catalogo ha creato esitazione anche in qualcuno con una profonda competenza in localizzazione. La sua reazione è stata diretta. Non pensava che quella scelta fosse abbastanza importante da doverla chiedere all'utente. Automatizzatela.

La strategia di routing era basata sui path. Nessun routing basato su dominio, dato che lo sviluppatore non possedeva domini aggiuntivi. L'app usa un'autenticazione basata su OAuth, quindi i flussi di login sono rimasti in inglese per scelta progettuale. L'agente ha gestito correttamente questo aspetto.

Cosa fa in concreto il passaggio di conversione?

È questa la parte che conta davvero. L'agente ha identificato 28 stringhe UI candidate in the Next.js app e ha processato 41 voci di traduzione. Ha riorganizzato i file, aggiornato il middleware, modificato gli import dei componenti e generato i file di traduzione PO per tutte e 5 le lingue di destinazione.

Il solo step di conversione ha richiesto circa 30 minuti. Aggiungendo setup e configurazione prima, e il completamento autonomo della connessione di traduzione da parte dello sviluppatore dopo, il flusso end-to-end completo si è avvicinato ai 90 minuti. Non è istantaneo. Per contesto, un'app semplice con poche pagine completa l'intero flusso in meno di 15 minuti. Un'app complessa con decine di superfici traducibili richiede più tempo. Il tempo scala con il numero di stringhe, non con la dimensione del repository.

Lo sviluppatore ha osservato lo step di conversione in azione e ha commentato così: l'estrazione delle stringhe e la riscrittura del codice sono il lavoro pesante. È il lavoro che gli sviluppatori temono di più. Nella sua azienda precedente, un fornitore leader di TMS, i file di traduzione nel repository erano solo la punta dell'iceberg. Il vero dolore era il lavoro di preparazione e internazionalizzazione. E l'agente IA ha gestito esattamente quella parte.

Questo conferma quello che sentiamo da ogni sviluppatore che è passato per l'i18n manuale. Nessuno si lamenta delle traduzioni. Si lamentano di dover toccare 40 file per avvolgere le stringhe in chiamate t(), generare chiavi che abbiano senso, ristrutturare gli import e configurare il middleware. È questo il lavoro che globalize.now automatizza.

Ha funzionato davvero end-to-end?

Sì. Dopo la fine della sessione live, lo sviluppatore ha completato in autonomia i passaggi rimanenti. Ha pubblicato il branch Git di globalize.now, connesso l'app alla piattaforma web, impostato il monitoraggio sul branch globalize.now e confermato che i file erano stati caricati e tradotti correttamente.

La sua valutazione della qualità della traduzione in ceco: quasi perfetta. Parliamo di qualcuno che ha passato la carriera a valutare professionalmente output di localizzazione. Non è un generico pollice in su. È un esperto di dominio che conferma una qualità pronta per la produzione su una coppia linguistica non banale.

Ha segnalato due problemi nella web app dopo aver completato il flusso in autonomia. Primo, una nuova scansione del repository mostrava "nessun file i18n rilevato" anche se il job di traduzione era in realtà in esecuzione in background. Uno stato UI fuorviante, non un fallimento reale. Secondo, il job di traduzione è partito senza consenso esplicito. Qualsiasi azione che consuma crediti dovrebbe richiedere una conferma. Entrambi sono problemi UX validi, già in fase di risoluzione.

Cosa è andato storto?

Qualcosa si è rotto. È stato un test reale, quindi ne parliamo con onestà.

Il comando di installazione (npx skills add globalize-now/globalize-skills) è fallito su Windows PowerShell. Era la prima volta che lo strumento veniva testato su Windows. Le skill hanno dovuto essere inviate come file zip via Swiss Transfer dopo che Google aveva bloccato l'allegato email. Attrito di setup totale: circa 15 minuti prima che il flusso vero e proprio iniziasse.

A metà conversione è emerso un conflitto tra moduli ES e CommonJS. Il progetto usa CommonJS, e l'output dell'agente presupponeva moduli ES in un punto. Non bloccante, ma qualcosa che dovrebbe essere rilevato durante il setup e gestito proattivamente.

Alla fine della sessione, connettere il repository GitHub nella globalize.now web app ha restituito una pagina vuota. Lo sviluppatore stava usando Opera. Nessuna schermata di login, nessun errore, nessun contenuto. La sessione è terminata prima che il problema venisse risolto.

Tre bug. Tutti reali. Tutti risolti o in lavorazione.

Perché l'estrazione delle stringhe è il vero collo di bottiglia?

Gran parte dei contenuti sull'i18n si concentra sulla qualità delle traduzioni, sulla configurazione dei framework o sul confronto tra funzionalità dei TMS. Ma così si perde di vista dove gli sviluppatori perdono davvero tempo.

Aggiungere l'internazionalizzazione a una codebase esistente significa scansionare ogni componente alla ricerca di stringhe hardcoded, decidere quali stringhe sono traducibili, generare chiavi di traduzione sensate, avvolgere ogni stringa nella chiamata t() o <Trans> appropriata, aggiornare gli import in tutto l'albero dei file, creare i file di traduzione iniziali e configurare il middleware di routing. In un monorepo, aggiungi anche la complessità di capire quali parti della codebase hanno effettivamente bisogno di i18n.

È un lavoro tedioso, soggetto a errori, ed è esattamente il tipo di lavoro in cui gli agenti IA eccellono. Lo sviluppatore che ha assistito al processo lo ha detto chiaramente: dal punto di vista dello sviluppatore, questo è il lavoro pesante. Ed è un grande sollievo. I vibe coder che costruiscono con strumenti IA possono ora saltare completamente la parte peggiore dell'espansione internazionale.

Cosa abbiamo imparato sullo scoping dei monorepo?

L'agente ha gestito lo scoping del monorepo in modo implicito. Si è concentrato sulla web app Next.js e ha ignorato il codice Android, i server MCP e la documentazione Mintlify senza che gli venisse detto esplicitamente. È il comportamento corretto nella maggior parte dei casi.

Ma uno scoping implicito non equivale a uno scoping esplicito. Lo sviluppatore voleva la possibilità di dire "converti solo la mia app Next.js" come passaggio di configurazione. In un monorepo con più frontend web — ad esempio un'app rivolta ai clienti e una dashboard admin — vorresti un controllo preciso su quale frontend viene internazionalizzato per primo.

È un gap di prodotto che stiamo colmando. Per ora, l'agente ci azzecca nella pratica. Lo scoping esplicito dovrebbe essere un passaggio di configurazione, soprattutto quando la conversione tocca decine di file.

Come si confronta questo con un setup i18n manuale?

Un setup i18n manuale su una codebase di questa complessità richiede giorni. Non perché un singolo passaggio sia difficile, ma perché sono decine di passaggi e ognuno richiede attenzione. Ti sfugge una stringa e rilasci una pagina tradotta a metà. Sbagli il nome di una chiave e crei voci duplicate che ti perseguitano per mesi. Dimentichi di aggiornare il middleware e il routing dei locale si rompe silenziosamente.

L'agente IA ha completato il lavoro equivalente in circa 90 minuti, end-to-end. Lo sviluppatore, qualcuno che ha visto professionalmente migliaia di implementazioni i18n, l'ha definito elegante.

Per gli sviluppatori che costruiscono con strumenti IA, questo cambia il calcolo su quando aggiungere nuove lingue. Se il setup i18n richiede una settimana, lo rimandi finché non hai validato il product-market fit. Se richiede 90 minuti, puoi rilasciare in versione multilingue fin dal primo giorno.

globalize.now gestisce tutto questo. Connetti il tuo repository e la conversione viene eseguita una volta, nell'app; le skill npx skills add globalize-now/globalize-skills coprono ciò che segue nel tuo editor. Scopri come funziona su globalize.now.