Vi serve ancora un TMS se è il vostro agente di coding a tradurre l’app?

Una routine di traduzione è un job di un agente di coding che gira a intervalli programmati o in CI: trova le stringhe cambiate, le abbozza in ogni lingua di destinazione, scrive i file di lingua e apre una pull request. Con Claude Code, Codex o un altro agente di coding bastano un file di skill e una riga di cron, e alcuni team ne costruiscono una per sostituire il proprio sistema di gestione delle traduzioni.

La domanda quindi è legittima: vi serve ancora un TMS? Per alcuni team no. Per la maggior parte dei team la risposta non è "il TMS al posto della routine", ma "la routine sopra un TMS". Questo articolo spiega quando la routine basta, cosa deve ricostruire quando non basta più, e tre modi per tenerla.

Com’è fatta la routine

Una routine di solito ha tre parti:

• Un file di skill o di istruzioni con le regole: mantenere i placeholder, aggiungere ogni forma plurale di cui la lingua ha bisogno, rispettare il tono, non toccare mai la lingua di partenza.
• Un trigger: una pianificazione cron, un merge nel branch principale, oppure un’etichetta su una pull request.
• L’esecuzione: l’agente confronta il file della lingua di partenza con i file di destinazione, abbozza i valori mancanti, li scrive e apre una pull request.

I suoi punti di forza sono reali. L’agente che abbozza l’etichetta tedesca di un pulsante sa che è un pulsante, che {{count}} è un numero e non un nome, cosa dicono le stringhe vicine e quanto spazio lascia il layout. Non c’è export, nessun passaggio di consegne e nessuna attesa per un giro di traduzione, e funzionalità che un tempo uscivano solo in inglese ora escono in ogni lingua del progetto.

Quando basta la routine da sola

Tenetela così com’è, senza un TMS, finché valgono tutte queste condizioni:

• il team legge ogni lingua di destinazione, oppure le lingue sono abbastanza poche da controllarle a mano;
• niente dipende dal testo: nessun flusso di checkout, nessun testo legale, nessun contenuto regolamentato;
• un solo team è responsabile del prodotto, e nessuno al di fuori del repository deve cambiare una stringa.

Questo descrive molti progetti. Se descrive il vostro, il resto dell’articolo è l’elenco delle cose a cui fare attenzione.

Cosa deve ricostruire dopo

Ogni esecuzione di una routine è senza stato: sa cosa c’è oggi nel repository e cosa dice il suo prompt. Le lacune non si vedono in una pull request; si vedono da una release all’altra. Il motivo per cui ciascuna deriva nel tempo è in quando gli agenti di codice traducono la vostra app; questa è la lista di ciò che va costruito.

Nessuno di questi pezzi è difficile da solo. Insieme sono un sistema di gestione delle traduzioni, scritto e mantenuto dal team che voleva smettere di gestirne uno.

Tre modi per tenere la routine

L’alternativa al ricostruire è tenere la routine e lasciarla scrivere in un sistema che ha già quei pezzi. In Locize ci sono tre configurazioni, dalla modifica più piccola a quella con più contesto, e tutte e tre girano senza supervisione in CI.

Quale fa al caso vostro:

La routine continua a pagare i propri token del modello; le traduzioni abbozzate da Locize girano sugli AI token di Locize o sulla chiave del vostro provider (prezzi).

Tutte e tre finiscono nello stesso posto: una coda di revisione per lingua, dove ogni bozza aspetta finché qualcuno che legge la lingua non la conferma.

Il filtro needs-review nell’editor di Locize: bozze contrassegnate da revisionare per lingua, e una proposta in attesa con accetta e rifiuta

Cosa intercetta, da un’esecuzione reale con la configurazione 2: un agente ha segnalato 11 chiavi inglesi, e la traduzione automatica di Locize ha restituito 69 valori in sei lingue in circa undici secondi, ognuno con un punteggio di confidenza e una motivazione, e con le forme plurali di cui ogni lingua ha bisogno (tre in francese, una in giapponese) dove l’inglese ne ha due. I punteggi hanno indicato la resa letterale di "Wake up" in tedesco, spagnolo e giapponese. E il tedesco usava due termini per la stessa azione, cosa che un punteggio per stringa non può vedere e un revisore di quella lingua sì. Le bozze che la vostra routine invia direttamente, nelle configurazioni 1 e 3, arrivano senza punteggio; un’esecuzione di revisione IA le valuta.

1. Aggiungere un passo di sync

Tenete la routine così com’è. Dopo che ha scritto i file, inviate i nuovi valori di destinazione a Locize, contrassegnati da revisionare:

locize sync --api-key $LOCIZE_API_KEY --project-id $LOCIZE_PROJECTID \
  --reference-language-only false --needs-review true \
  --skip-delete true --auto-translate false

• --reference-language-only false confronta anche le lingue di destinazione, così le bozze della routine vengono inviate.
• --needs-review true contrassegna ogni valore che la sincronizzazione invia: va online e resta nella coda dei revisori finché qualcuno non lo conferma (locize-cli 12.8.0 o successivo). Con --review true, invece, i valori arrivano come proposte di revisione e vanno online solo una volta accettati.
• --auto-translate false impedisce a Locize di tradurre da solo le nuove chiavi della lingua di partenza, così non entra in competizione con le bozze della routine.
• --skip-delete true evita che venga cancellato un valore che qualcuno ha aggiunto in Locize e che i file non hanno ancora (le chiavi rimosse dalla lingua di partenza restano quindi in Locize finché non le rimuovete lì).

La correzione di un revisore non viene annullata dall’esecuzione successiva: Locize mantiene il valore che ha per una chiave esistente, e la sincronizzazione lo riscrive nei file. Una cosa da impostare prima della prima esecuzione: se il vostro team modifica i testi inglesi nel repository, eseguite locize sync --update-values true prima della routine, altrimenti la sincronizzazione ci riscrive sopra l’inglese di Locize. La sincronizzazione confronta con i file pubblicati, quindi usate una versione con pubblicazione automatica; il resto è nel riferimento di sync di locize-cli.

Provatelo alla prossima esecuzione della routine: avviate una prova gratuita di 14 giorni, create un progetto con le vostre lingue, salvate la sua chiave API come secret della CI, aggiungete il comando dopo la routine, e aprite il filtro needs-review nell’editor quando ha girato. La prima sincronizzazione invia ogni valore di destinazione che la routine ha scritto finora, quindi la coda mostra ciò che le esecuzioni precedenti hanno rilasciato senza un secondo sguardo. Siete già su Locize? Prendete la chiave API del vostro progetto e aggiungete il passo; non cambia nient’altro.

Il limite: i valori arrivano contrassegnati da revisionare, ma nella cronologia e nell’export di provenienza sembrano un qualsiasi altro valore inviato con la chiave API. Basta per la revisione, ma non quando la traccia deve distinguere il testo di un agente da quello di una persona; la configurazione 3 lo fa.

2. Lasciare le bozze a Locize

La routine continua a scrivere la funzionalità e il testo di partenza, e il passo di traduzione passa a Locize. La GitHub Action di Locize estrae le nuove chiavi, le sincronizza, le fa tradurre e scarica il risultato, con la stessa chiave API del progetto:

- uses: locize/translate@v2
  with:
    project-id: ${{ secrets.LOCIZE_PROJECTID }}
    api-key: ${{ secrets.LOCIZE_API_KEY }}

• La traduzione automatica usa come contesto la guida di stile, il glossario e la memoria di traduzione del progetto, e controlla ogni risultato rispetto al suo testo di partenza (sintassi, placeholder, tag, le forme plurali di cui la lingua ha bisogno) prima di salvarlo; i risultati IA sono anche vincolati al glossario.
• Con Quality Estimation ogni traduzione IA riceve un punteggio di confidenza, e le impostazioni di revisione decidono se tutte le traduzioni automatiche vengono contrassegnate da revisionare o solo quelle di cui il punteggio non si fida.
• Su una pull request, command: sync traduce solo le chiavi che la pull request ha cambiato.

L’action si aspetta un file i18next.config (eseguite una volta npx i18next-cli init). Fuori da i18next, locize sync --auto-translate true fa lo stesso con la CLI. Questa configurazione è adatta quando basta una frase di contesto per chiave, e lascia all’agente la parte in cui è più bravo.

3. Far leggere prima il progetto alla routine

Quando una stringa ha bisogno di ciò che solo il codice mostra, lasciate che l’agente continui ad abbozzare, ma tramite il server MCP di Locize invece che nei file. L’esecuzione legge prima di scrivere:

1. find_missing_translations per lingua: cosa manca o è obsoleto.
2. get_glossary, get_styleguide e search_translation_memory: i termini, la voce e le decisioni precedenti; get_screenshot_context per una chiave ambigua.
3. L’agente abbozza, con il codice sotto gli occhi.
4. update_translations con quality: "AI": le bozze sono dichiarate come output IA e contrassegnate da revisionare secondo la regola del progetto.

A intervalli programmati in GitHub Actions, con Claude Code:

name: nightly translations
on:
  schedule:
    - cron: '0 3 * * 1-5'
  workflow_dispatch:

permissions:
  contents: read

jobs:
  translate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: npm install -g @anthropic-ai/claude-code@2.1.317
      - run: |
          claude mcp add --transport http locize https://mcp.locize.app --header "Authorization: Bearer $LOCIZE_PAT"
        env:
          LOCIZE_PAT: ${{ secrets.LOCIZE_PAT }}
      - run: >
          claude -p "Translate the missing keys of the Locize project $LOCIZE_PROJECTID, version latest.
          Call get_project_stats for version latest to see its languages and namespaces (if it answers with totals only, call it again per language),
          then call find_missing_translations per language and namespace.
          Before drafting call get_glossary, get_styleguide and search_translation_memory, and reuse a translation memory match with a high score.
          Read the namespace's existing translations with get_translations to match their tone. Look up where each key is used in the code to see what it labels.
          Push the drafts with update_translations and quality AI. Never send a null value, never publish, delete or rename anything.
          End with a list of what you pushed and what you were unsure about."
          --disallowedTools "Bash,Edit,Write,WebFetch,WebSearch,Read(~/.claude.json),Read(~/.claude/**)"
          --allowedTools "mcp__locize__get_project_stats,mcp__locize__find_missing_translations,mcp__locize__get_translations,mcp__locize__get_glossary,mcp__locize__get_styleguide,mcp__locize__search_translation_memory,mcp__locize__get_screenshot_context,mcp__locize__update_translations,Read,Grep,Glob"
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          LOCIZE_PROJECTID: ${{ vars.LOCIZE_PROJECTID }}

• Il token: create un token di accesso personale con i soli scope read e write, impostate una scadenza e salvatelo come secret del repository. Un token raggiunge ogni progetto che il suo proprietario può raggiungere, quindi fate in modo che appartenga a un utente che è membro solo di questo progetto. Dategli il nome della routine, per esempio "Routine di traduzione notturna": ogni scrittura tramite MCP porta il contrassegno dell’agente con il nome del token, così la cronologia nomina l’agente, e l’export di provenienza elenca le bozze come output macchina con il nome dell’agente, non come la modifica di una persona.
• Cosa può fare: l’elenco degli strumenti esclude quelli strutturali (cancellare o rinominare namespace, pubblicare, branch). update_translations può comunque cancellare una chiave quando riceve un valore null, e solo il prompt dice di non farlo; se il proprietario del token ha il permesso di sola traduzione, è il server stesso a rifiutare le cancellazioni di chiavi e le modifiche strutturali.
• Cosa legge: l’agente legge testo scritto da altre persone (traduzioni, il glossario, i contesti delle chiavi). Il workflow gli nega esplicitamente la shell, la modifica dei file e il web, perché --allowedTools si limita ad aggiungere a ciò che le impostazioni di Claude già permettono, compreso un .claude/settings.json nel repository di cui è stato fatto il checkout. Gli nega anche la lettura della propria configurazione (dove claude mcp add salva il token), e le sue bozze vanno in revisione.
• Intorno: le chiavi di partenza arrivano comunque a Locize come prima (saveMissing, locize sync o report_missing_keys), e l’app riceve le traduzioni revisionate dalla CDN o con un locize download nella build. Se la traduzione automatica è attiva per il progetto, Locize abbozza per primo le nuove chiavi e la routine trova poco di mancante; disattivatela quando deve essere la routine ad abbozzare.
• Altri agenti: un agente di coding che parla MCP su HTTP accetta lo stesso URL e lo stesso header nelle sue impostazioni MCP. I file di convenzioni in locize-agents portano la regola «leggere prima di abbozzare» anche nelle sessioni interattive.

Com’è un’esecuzione: su un progetto di test con tre nuove chiavi e tedesco, francese e russo come lingue di destinazione, la routine ha letto le statistiche, le chiavi mancanti, il glossario, la guida di stile e la memoria di traduzione, ha cercato ogni chiave nel codice, e ha inviato nove bozze come output IA, per meno di un dollaro di token del modello. Ha concluso con ciò su cui era incerta: aveva reso "Wake up" come "riattivare" o "riprendere", non alla lettera, il che fa perdere la metafora dello snooze. Tutte e nove le bozze erano nella coda needs-review, e la cronologia indicava il token come agente accanto a ciascuna.

Per un’esecuzione interattiva completa con l’output reale (i punteggi di confidenza, cosa non hanno visto, la revisione e l’export), vedete un agente di coding localizza una funzionalità, passo dopo passo.

Se siete voi ad approvare

La routine è uno strumento da sviluppatori; la domanda "chi ha approvato questo testo?" di solito arriva a qualcun altro: il responsabile della localizzazione, il product owner, o chi risponde all’ufficio legale o al procurement di un cliente. In tutte e tre le configurazioni, ecco cosa ottiene:

• Revisori per lingua. Un revisore può essere limitato alle proprie lingue, e il permesso di sola traduzione modifica i valori senza cancellare chiavi né cambiare la struttura del progetto (ruoli e permessi).
• Una sola coda, qualunque cosa abbia scritto la bozza. I valori della routine, della traduzione automatica e delle persone finiscono nella stessa coda needs-review per lingua (workflow di revisione); con un piano che include le notifiche, può partirne una quando la coda di una lingua supera una soglia.
• Una traccia per stringa. La cronologia conserva chi o cosa ha scritto ogni valore, chi lo ha confermato e quando.
• Prove su richiesta. L’export di provenienza (CSV e JSON per versione, lingua o namespace, dal piano Growth come le proposte di revisione) impacchetta lo stato di revisione per un auditor. La guida al workflow per l’articolo 50 mostra la configurazione, e la nostra spiegazione chiarisce quando si applica l’articolo 50.
• Un secondo sguardo, quando serve. Un’esecuzione di revisione IA su una versione valuta le traduzioni che un progetto ha già, chiunque le abbia scritte, e contrassegna da revisionare quelle di cui dubita oppure le trasforma in proposte di revisione con una motivazione e una correzione suggerita. Un agente può avviarne una con start_ai_review e un tetto di budget, con un token che ha lo scope manage e un ruolo di admin o manager.

Il vostro passo: configurate la revisione per lingua come descrive la guida al workflow per l’articolo 50, lasciate girare la routine una volta, poi scaricate l’export di provenienza di quella versione e confrontatelo con ciò che chiede il vostro auditor o il vostro cliente. La prova di 14 giorni di un progetto include la revisione e l’export; dopo, entrambi sono disponibili dal piano Growth in su.

Segnali che la routine ha bisogno di un sistema sotto

• la prima lingua che nessuno nel team legge;
• il primo reclamo sulla terminologia da parte di un cliente, delle vendite o del supporto;
• il primo "chi ha cambiato questa stringa, e perché?";
• la prima correzione che deve raggiungere gli utenti prima della prossima release;
• la prima domanda dall’ufficio legale o dal procurement di un cliente sul testo generato dall’IA.

L’agente continua ad abbozzare; quella parte non è mai stata il problema. Ciò di cui ha bisogno sotto è una memoria, un revisore e una traccia. Se la vostra routine gira già, avviate una prova gratuita di 14 giorni, date alla routine una chiave API del progetto, aggiungete il comando di sync e guardate la coda di revisione dopo la prima esecuzione. Siete già su Locize? La chiave API del vostro progetto è tutto ciò di cui la routine ha bisogno.