Quando gli agenti di codice traducono la vostra app: cosa si rompe, cosa tenere

La traduzione assistita da agente (agent-assisted translation) è la pratica di lasciare che un agente di codice basato su IA, l'assistente che già legge e modifica la vostra codebase, aggiunga chiavi di traduzione e abbozzi le stringhe tradotte come parte di una modifica al codice, invece di passare le stringhe a un passaggio di traduzione separato in un secondo momento. È veloce, economico e, per una singola pull request, spesso buono. I problemi non stanno in quella pull request. Stanno nella dodicesima.

Questo articolo è un pezzo di categoria, non un confronto. Parla di ciò che gli agenti fanno davvero bene, di ciò che non si conserva da una release all'altra, e dello schema che mantiene la velocità senza perdere la traccia.

Cosa sanno fare davvero bene gli agenti

La versione onesta comincia dai punti di forza, perché sono reali. Un agente di codice a cui viene chiesto di aggiungere una schermata di impostazioni in sei lingue ha, nel momento in cui scrive l'etichetta tedesca, più contesto di un traduttore che riceve un foglio di calcolo: sa che il componente è un pulsante, che {{count}} è un numero e non un nome, cosa dicono le stringhe vicine, come lo sviluppatore precedente ha chiamato chiavi simili, e se il valore viene interpolato in una frase. Scrive la chiave, il valore predefinito e le traduzioni in un solo passaggio, senza consegne, senza export, senza attese.

È bravo anche nell'impianto che un tempo bloccava del tutto la localizzazione. Gli agenti collegano una libreria i18n, avvolgono le stringhe hardcoded, estraggono le chiavi e lanciano il comando di sincronizzazione, e lo fanno per la funzionalità secondaria per cui nessun team avrebbe mai messo a budget un giro di traduzione. Funzionalità che un tempo uscivano solo in inglese ora escono in ogni lingua del progetto. Non è poco, e nessuna critica alla traduzione tramite agenti dovrebbe fingere che lo sia.

Cosa si rompe nel tempo

Tutto ciò che segue è invisibile in una singola pull request. Emerge tra una pull request e l'altra, ed è per questo che i team lo scoprono tardi.

La coerenza tra le release

Ogni esecuzione di un agente parte da un contesto vuoto. Niente nella sessione ricorda che il nome del prodotto resta non tradotto, che "subscription" è diventato "Abo" e non "Abonnement" in tedesco tre release fa, o che lo spagnolo usa "tú" e non "usted". L'agente sceglie una resa difendibile in isolamento, e il mese dopo un'altra resa difendibile. Il registro è il caso più fastidioso: nelle lingue in cui la distinzione è grammaticale, una schermata che dà del lei accanto a una che dà del tu si legge come un errore, non come una scelta di stile.

La revisione e la provenienza

Quando un cliente, un avvocato o un auditor chiede perché l'app ha detto quello che ha detto in italiano, una pipeline di file modificati da un agente ha una sola risposta: un commit fatto da un bot, approvato da un revisore che non sapeva leggere l'italiano e ha controllato il diff per la sintassi. Non c'è un revisore responsabile, nessuna traccia della decisione per singola stringa, e nessun modo di distinguere l'ipotesi di un agente dalla scelta di un traduttore una volta che entrambe stanno nello stesso file. Dal 2 agosto 2026 è anche una questione normativa: l'articolo 50 del regolamento europeo sull'IA si applica, e secondo le linee guida finali della Commissione una traduzione IA fedele è esente dalla marcatura leggibile dalla macchina, mentre i testi che informano il pubblico su questioni di interesse pubblico richiedono una divulgazione visibile, a meno che non siano passati per una revisione umana documentata con una persona che detiene la responsabilità editoriale. I dettagli giuridici sono nella spiegazione dell'articolo 50; la conseguenza pratica è che "revisionato" deve essere qualcosa che potete mostrare, segmento per segmento, e un workflow di revisione è ciò che produce quella prova. Niente di tutto questo è un parere legale.

La governance della terminologia

Il glossario esiste, di solito come documento. L'agente può leggerlo o no, leggerlo in una sessione e non in quella dopo, e non può sapere che un termine è stato aggiunto dopo la sua ultima esecuzione. I termini vietati tornano. I nomi dei prodotti vengono tradotti. La soluzione che viene proposta, "mettere il glossario nelle istruzioni dell'agente", funziona finché il glossario non ha quattrocento voci e le istruzioni non devono coprire anche tutto il resto. La terminologia è un problema di dati, e i dati che un processo senza stato deve ricordare non sono governati, sono sperati. Il glossario sta in un sistema che l'agente può interrogare, non in un prompt.

La QA sul corpus, non sul diff

Un agente controlla le stringhe che ha toccato. I difetti che arrivano davvero in produzione sono trasversali alle chiavi: lo stesso valore di partenza tradotto in tre modi tra i namespace, un placeholder presente in undici lingue e perso nella dodicesima, un numero cambiato per strada. Si trovano confrontando ogni valore di una lingua con il suo testo di partenza e con il resto di quella lingua, a ogni salvataggio, cosa che nessuna revisione di pull request fa. La tassonomia e il modo in cui i controlli automatici la intercettano sono in cosa si rompe davvero nelle traduzioni.

Plurali, placeholder e le stringhe che portano rischio

Le lingue con più di due forme plurali (polacco, arabo, russo) hanno bisogno di forme che il testo inglese di partenza non ha. Gli agenti le producono correttamente in isolamento e in modo incoerente in massa, e una chiave _few sbagliata è un bug a runtime, non un problema di stile. Poi ci sono le stringhe per cui "il modello di solito ha ragione" non è un livello accettabile: note legali, condizioni di prezzo, formulazioni mediche e di sicurezza, etichette di accessibilità. Un agente le tratta come qualsiasi altra stringa, perché nel diff sembrano qualsiasi altra stringa.

Come i team gestiscono oggi la traduzione tramite agenti di codice

Quattro configurazioni coprono la maggior parte di ciò che vediamo, e la nota onesta è che la prima è quella giusta per alcuni team.

• L'agente modifica i file di lingua nella pull request. Il più veloce, il più economico, e va bene finché le persone del team sanno leggere ogni lingua e niente dipende dal testo. La deriva descritta sopra comincia dal primo giorno e diventa visibile intorno alla decima release.
• L'agente più un passaggio LLM in CI. L'agente aggiunge le chiavi, un workflow al push traduce automaticamente i valori mancanti. Elimina del tutto la parte manuale, e riproduce le stesse modalità di guasto alla velocità della pipeline: output non revisionato, nessuna memoria tra le esecuzioni, nessuna applicazione della terminologia. La strada per uscire da questa configurazione è in quando le traduzioni IA si rompono.
• L'agente abbozza, una persona revisiona il diff. Migliore nello spirito, debole nella pratica: un revisore di pull request vede dodici file di lingua e può giudicarne uno o due. La revisione è reale per le lingue che il revisore legge e teatro per il resto.
• L'agente abbozza attraverso un sistema di gestione delle traduzioni. L'agente continua ad abbozzare, ma la terminologia, la memoria delle decisioni passate, la coda di revisione e la cronologia vivono nel sistema, e l'agente vi legge e vi scrive. È lo schema che il resto di questo articolo descrive.

Lo schema agent-in-the-loop: cosa tenere

Qualunque sia lo strumento, lo schema ha cinque regole.

1. Terminologia e voce vengono dal sistema, non dal prompt. Prima che l'agente abbozzi una stringa, recupera il glossario del progetto (termini preferiti, ammessi e vietati per lingua) e la guida di stile (tono, registro, pubblico). Le istruzioni dicono "consulta questo", non "ecco quattrocento termini".
2. Riutilizzare prima di inventare. Una ricerca nella memoria di traduzione su stringhe di partenza simili viene per prima. Una corrispondenza con punteggio alto viene riutilizzata, ed è così che la dodicesima release resta coerente con la prima.
3. La provenienza è dichiarata, non dedotta. L'output dell'agente viene inviato come output IA, il che lo mette nella coda di revisione invece che in produzione. La modifica di una persona viene inviata come modifica di una persona. Una volta che entrambe stanno nello stesso file senza alcun marcatore, la distinzione è persa per sempre.
4. La revisione è per segmento, fatta da chi legge la lingua, e registrata. Non un'approvazione di pull request, non un controllo a campione su due lingue: un revisore conferma o modifica ogni valore in un editor che mostra il testo di partenza, il contesto e il glossario, e la decisione viene scritta nella cronologia con il suo nome e l'ora.
5. I controlli girano sul corpus dopo il merge, non solo sul diff prima. Coerenza, placeholder, numeri, tag: i controlli che confrontano con l'intera lingua devono girare dove si trova l'intera lingua.

Cosa questo non risolve

• Qualcuno deve ancora leggere il polacco. Lo schema rende la revisione economica e mirata; non la fa sparire. La quality estimation può lasciar passare le bozze sicure e trattenere quelle dubbie, ma la decisione su una stringa dubbia è lavoro umano.
• Anche il testo di partenza è scritto dall'agente. Gli agenti scrivono l'inglese tanto quanto il tedesco, e le stringhe inglesi derivano nella terminologia esattamente come le traduzioni. Un lint sui termini vietati nelle nuove stringhe di partenza ne cattura una parte; un autore cattura il resto.
• Le stringhe a rischio restano una questione di policy. Quali stringhe richiedono una persona a prescindere dalla confidenza, quali contenuti rientrano nella divulgazione di interesse pubblico e chi detiene la responsabilità editoriale di una pubblicazione sono decisioni che uno strumento registra ma non prende.
• I progetti piccoli possono saltare tutto questo. Due lingue che il team legge, nessun fatturato né conformità che dipenda dal testo: lasciate che l'agente modifichi i file. Il segnale per cambiare è la prima lingua che nessuno nel team legge.

Come funziona in Locize

Locize espone agli agenti il lato sistema dello schema attraverso il suo server MCP, raggiungibile su https://mcp.locize.app da Claude, Cursor, GitHub Copilot e altri client MCP, con 26 strumenti in totale. I cicli di traduzione guidati da agenti (trovare le chiavi mancanti, recuperare il testo di partenza, inviare bozze, leggere la coda di revisione) sono una quota visibile e in crescita costante del traffico su quel server.

• Contesto prima della bozza. get_glossary restituisce i termini preferiti, ammessi e vietati per lingua; get_styleguide restituisce tono, registro, pubblico e regole d'uso; search_translation_memory trova traduzioni precedenti di stringhe di partenza simili, esatte e fuzzy; get_screenshot_context mostra dove compare una chiave ambigua. Tutti e quattro sono in sola lettura, e l'articolo sugli strumenti di contesto li passa in rassegna.
• Le bozze finiscono in revisione, non in produzione. report_missing_keys crea nuove chiavi senza sovrascrivere quelle esistenti (e attiva la traduzione automatica dove è abilitata). update_translations accetta una quality pari a AI per i testi generati dall'agente o HT per il testo di una persona; i valori IA vengono contrassegnati da revisionare secondo la regola del progetto (sempre, oppure solo quando il punteggio di quality estimation è sotto la soglia), e find_missing_translations e get_translations con needsReviewOnly permettono all'agente di leggere la coda che ha appena riempito.
• Decide una persona, e la cronologia dice chi. I revisori confermano, modificano o rifiutano nell'editor; il workflow di revisione registra ogni decisione, e l'export di provenienza descritto nella guida al workflow per l'articolo 50 lo impacchetta come CSV e JSON.

La coda "needs review" nell'editor di Locize: valori contrassegnati e proposte in attesa, confermate valore per valore da un revisore

• Impostazioni predefinite, così nessuno deve ricordarsi le regole. Il repository pubblico locize-agents contiene file di convenzioni (CLAUDE.md, AGENTS.md, .cursorrules) che fanno sì che un agente recuperi glossario, guida di stile e memoria prima di tradurre e controlli le pull request alla ricerca di termini vietati. Per i progetti non ancora collegati, npx i18next-cli init --agent-note (i18next-cli 1.73 o successivo) aggiunge una breve nota sull'internazionalizzazione ad AGENTS.md, così la sessione successiva dell'agente sa dove stanno i file di lingua, quali comandi eseguire, e che deve chiedere prima di collegare un servizio di traduzione.

L'agente mantiene la sua velocità. Ciò che cambia è che le sue bozze arrivano in un posto che ha una memoria, un revisore e una traccia. Se il vostro agente sta già traducendo, create un progetto, collegate il server MCP e lasciate che la prossima pull request abbozzi attraverso di esso; la coda di revisione vi mostrerà cosa avrebbero rilasciato le precedenti.

Domande frequenti

Gli agenti di codice basati su IA possono tradurre un'app? Sì, e per una singola modifica spesso bene: con la codebase nel contesto un agente vede il componente, i tipi dei placeholder, il testo adiacente e la cronologia git. Ciò che non porta con sé nel tempo sono la coerenza tra le release, una traccia di chi ha approvato cosa, la terminologia decisa fuori dalla sessione corrente e i controlli di qualità sull'intero corpus. L'agente è un buon autore di bozze; le bozze hanno bisogno di un sistema alle spalle.

Cosa si rompe quando un agente di codice modifica direttamente i file di traduzione? Niente di visibile nella pull request. Tra una pull request e l'altra, lo stesso concetto viene reso in modo diverso, il registro si ribalta tra le schermate, le forme plurali delle lingue con più di due forme vengono indovinate in modo incoerente, e l'unica traccia di una decisione è un commit fatto da un bot. I controlli che confrontano una traduzione con il testo di partenza e con il resto della lingua non girano su un diff, quindi i difetti si accumulano inosservati.

Che cos'è lo schema agent-in-the-loop per la traduzione? L'agente resta l'autore delle bozze ma le scrive attraverso il sistema di gestione delle traduzioni: recupera glossario, guida di stile e voci corrispondenti della memoria di traduzione prima di scrivere, segnala le nuove chiavi e invia le sue traduzioni dichiarate come output IA, il che le mette nella coda di revisione; una persona che legge la lingua conferma o modifica ogni valore, e la decisione viene registrata.

Il regolamento europeo sull'IA si applica alle traduzioni abbozzate da un agente di codice? L'articolo 50 si applica dal 2 agosto 2026. Secondo le linee guida finali della Commissione del 20 luglio 2026, una traduzione IA fedele è esente dalla marcatura leggibile dalla macchina; l'obbligo di divulgazione visibile riguarda solo i testi pubblicati per informare il pubblico su questioni di interesse pubblico e decade con una revisione umana documentata sotto una persona che detiene la responsabilità editoriale. Un passaggio di revisione registrato è la via dell'esenzione. Questo non è un parere legale.

Come faccio in modo che il mio agente di codice usi il glossario e la guida di stile? Dategli strumenti invece di documenti: tramite il server MCP di Locize chiama get_glossary, get_styleguide e search_translation_memory prima di abbozzare, e get_screenshot_context per le stringhe ambigue; i file di convenzioni nel repository locize-agents ne fanno il comportamento predefinito. Per i progetti non ancora collegati, i18next-cli init --agent-note lascia una nota in AGENTS.md perché la sessione successiva dell'agente conosca la configurazione e chieda prima di collegare qualsiasi cosa.