Che cos'è la localizzazione continua? Definizione, workflow e cosa non significa

La localizzazione continua è un workflow di traduzione in cui le stringhe nuove e modificate passano automaticamente e in continuo dalla codebase alle persone o ai sistemi che le traducono, in parallelo allo sviluppo, e in cui le traduzioni approvate vengono distribuite all'applicazione in esecuzione senza una release. È l'equivalente, per la localizzazione, dell'integrazione continua e della consegna continua: invece di una consegna di traduzione prima di ogni release, la traduzione è un processo sempre in corso, e una correzione di traduzione non aspetta mai un deploy.

Questo articolo è la definizione: cosa significa il termine, cosa non significa, le quattro fasi che ogni implementazione ha, in cosa differisce dal workflow a lotti che sostituisce, e cosa non risolve. Il lato prodotto, come Locize lo implementa e i team che lavorano così sono nella pagina sulla localizzazione continua.

Cosa significa localizzazione continua, e cosa no

La parola "continua" è presa in prestito di proposito dall'integrazione continua e dalla consegna continua. In quelle pratiche il codice viene integrato e rilasciato in piccoli incrementi, di continuo, invece che in grandi lotti con un congelamento prima di ciascuno. La localizzazione continua applica la stessa idea alla traduzione: l'unità di lavoro è la stringa, non la release, e la pipeline porta le stringhe dal codice ai traduttori agli utenti senza aspettare un taglio.

Tre letture del termine sono sbagliate abbastanza spesso da meritare di essere esplicitate:

• Non significa "tradurre tutto con l'IA e rilasciare". Traduzione automatica e IA sono il motivo per cui la prima bozza non aspetta più; cosa viene pubblicato lo decidono comunque controlli e revisione. Una pipeline che spinge in produzione output di modello non revisionato è continua e non governata, la combinazione dietro la deriva terminologica e l'occasionale messaggio di errore offensivo.
• Non richiede di abolire i file di traduzione. Alcune configurazioni continue non hanno alcun file di lingua nel repository perché l'applicazione carica le traduzioni a runtime; altre generano i file in CI e li committano. Entrambe sono continue se niente aspetta una consegna manuale.
• Non elimina il bisogno di un glossario, di un workflow di revisione o di controlli di qualità. Li rende più importanti, perché più stringhe si muovono più in fretta.

Localizzazione continua contro localizzazione a lotti

Un workflow a lotti ha una forma riconoscibile. Lo sviluppo arriva a un taglio. Qualcuno esporta le stringhe cambiate, o tutte, in file o in un foglio di calcolo. I file vanno ai traduttori, interni o in agenzia. Giorni o settimane dopo tornano, qualcuno li importa, risolve ciò che nel frattempo si è rotto, e le traduzioni escono con il deploy successivo. Ogni passaggio è un'attesa, e la funzionalità finita il giorno del taglio esce solo nella lingua predefinita.

Un workflow continuo elimina il taglio. Le stringhe vengono rilevate mentre gli sviluppatori le scrivono. La traduzione avviene mentre la funzionalità è ancora in costruzione. Un cancello di revisione decide cosa è pronto. La distribuzione non dipende da un deploy. Gli effetti visibili per un team di ingegneria: la traduzione smette di essere una dipendenza che blocca le release, e un'etichetta sbagliata in polacco viene corretta in minuti invece che nella release successiva. L'effetto visibile per un team di localizzazione: il lavoro arriva come flusso invece che come mucchio.

Le quattro fasi di un workflow di localizzazione continua

Ogni implementazione, qualunque sia lo strumento, ha le stesse quattro fasi.

1. Rilevare: le stringhe lasciano il codice automaticamente

Uno sviluppatore scrive una chiamata di traduzione con una nuova chiave e un valore predefinito. O un passaggio di estrazione statica in CI legge le chiamate e segnala le chiavi, oppure l'applicazione in esecuzione segnala una chiave la prima volta che la mostra (in i18next è l'opzione saveMissing). Nessuno esporta niente; la chiave esiste nel sistema di traduzione con il suo testo predefinito prima che la pull request venga unita.

2. Tradurre: persone, macchine e IA lavorano mentre lo sviluppo prosegue

Le nuove chiavi ricevono una prima bozza dalla traduzione automatica o IA, con il glossario e la guida di stile del progetto come contesto, così nessuna lingua resta vuota mentre la funzionalità è in corso. Traduttori e revisori lavorano sulle stesse chiavi in un editor che mostra testo di partenza, contesto e terminologia. Lo sviluppo non aspetta questa fase, e questa fase non aspetta una release.

3. Pubblicare: un cancello, non un congelamento

Cosa va online si decide per stringa, non per release: controlli automatici su placeholder, numeri, tag e coerenza; un punteggio di quality estimation per le bozze generate automaticamente; revisione umana per le stringhe che ne hanno bisogno. Versioni o branch permettono a un team di preparare le traduzioni di una funzionalità non ancora pubblica. Il cancello sostituisce il congelamento: il treno dei rilasci continua a correre, e una traduzione ci sale quando è pronta.

4. Distribuire: l'applicazione in esecuzione recupera le traduzioni

Le traduzioni approvate raggiungono gli utenti senza build: l'applicazione le carica a runtime da una rete di distribuzione dei contenuti, con una durata di cache che bilancia freschezza e latenza. I team che hanno bisogno di file per il rendering lato server o per bundle offline li scaricano in CI come artefatti generati. In entrambi i casi, una correzione pubblicata nell'editor è online senza commit.

Come i team implementano la localizzazione continua oggi

• Sincronizzazione in CI con file generati. L'estrazione gira nella pipeline, un passaggio di sincronizzazione invia le nuove chiavi al sistema di traduzione e recupera i file tradotti, i file vengono committati o scaricati al momento del build. Continuo, con i file conservati per i build che ne hanno bisogno. La sincronizzazione basata sulle differenze conta qui, così una pull request traduce solo le chiavi che ha aggiunto.
• Segnalazione a runtime e distribuzione via CDN. L'applicazione segnala le nuove chiavi mentre gira (limitato allo sviluppo) e carica le traduzioni a runtime; il repository non contiene file di lingua. La forma più diretta dello schema, comune nelle applicazioni a pagina singola e mobili.
• Un sistema di gestione delle traduzioni nel mezzo. Entrambe le opzioni sopra hanno bisogno di un posto in cui traduttori, traduzione automatica e IA incontrano le chiavi, con revisione, cronologia e pubblicazione. Il TMS è la metà del workflow per le fasi 2 e 3; l'integrazione in CI o a runtime è la metà per le fasi 1 e 4.
• Solo IA in CI. Un workflow che estrae le chiavi e le traduce automaticamente al push, senza editor e senza revisione. Continuo secondo la definizione qui sopra, ed esattamente la configurazione di cui parla la sezione "cosa non significa": niente tra il modello e la produzione. Cosa si rompe lì dentro, e come aggiungere il livello mancante, è in quando le traduzioni IA si rompono.

Cosa serve prima che funzioni

• Le chiavi nascono nel codice. Se qualcuno digita ancora chiavi in un file o in un foglio di calcolo, la fase 1 è manuale e tutto ciò che segue la aspetta.
• Un'unica fonte di verità. Le traduzioni vivono in un sistema; i file, se ci sono, vengono generati da lì. Due fonti di verità reintroducono il passaggio di merge su cui i workflow a lotti spendono il loro tempo.
• Una politica di qualità scritta. Quali tipi di contenuto possono uscire con una bozza IA più controlli automatici, quali hanno bisogno di una persona, quali vengono trattenuti come proposte di revisione finché non sono approvati. Un flusso continuo senza questa politica è un modo più veloce di rilasciare errori.
• Un meccanismo di staging. Versioni o branch, così le traduzioni per funzionalità non rilasciate non vanno online troppo presto e una versione di produzione può essere promossa deliberatamente.
• Controlli che girano sull'intero corpus. Placeholder, numeri, tag e coerenza tra chiavi devono essere controllati dove stanno tutte le stringhe, a ogni salvataggio, non solo su un diff. La tassonomia è in cosa si rompe davvero nelle traduzioni.
• Una misura. L'unico numero che dice se il workflow è continuo: il tempo tra la scrittura di una stringa e la sua pubblicazione in ogni lingua. Se si misura in cicli di rilascio, il workflow è a lotti con strumenti migliori.

Cosa la localizzazione continua non risolve

• La qualità della traduzione. Il flusso non è qualità. Governance della terminologia, revisione umana e controlli di qualità sono livelli separati, e il flusso continuo alza il costo di saltarli.
• Il contesto. Una stringa che arriva dal codice senza screenshot o nota resta ambigua. Il rilevamento continuo rende più importante, non meno, la raccolta del contesto.
• I contenuti regolamentati. Un testo che informa il pubblico su questioni di interesse pubblico può rientrare nell'obbligo di divulgazione visibile dell'articolo 50 del regolamento europeo sull'IA (in vigore dal 2 agosto 2026), a meno che non sia passato per una revisione umana documentata con responsabilità editoriale. Il workflow può registrare quella revisione; non può decidere quali contenuti ne hanno bisogno. La spiegazione dell'articolo 50 ha i dettagli, e niente di tutto questo è un parere legale.
• I progetti piccoli e lenti. Due lingue che il team legge, poche release all'anno: un processo a lotti va bene. La distribuzione a runtime di solito vale comunque la pena, perché correggere un refuso senza deploy è utile a qualsiasi dimensione.

Come funziona in Locize

Locize è stato costruito dal team di i18next esattamente attorno a questo workflow, e le quattro fasi corrispondono a quattro elementi:

• Rilevare: saveMissing con i18next-locize-backend segnala le chiavi dall'applicazione in esecuzione; la CLI e le GitHub Actions lo fanno dalla pipeline, inclusa la sincronizzazione basata sulle differenze per le pull request.
• Tradurre: la traduzione automatica abbozza le nuove chiavi con glossario e guida di stile come contesto; traduttori e revisori lavorano nell'editor.

Nuove chiavi in arrivo dal codice e abbozzate in ogni lingua di destinazione dalla traduzione automatica, contrassegnate da revisionare

• Pubblicare: le proposte di revisione e i contrassegni da revisionare filtrano cosa va online, le versioni e i branch lo preparano, e i controlli automatici girano a ogni salvataggio.
• Distribuire: le traduzioni approvate vengono pubblicate sul CDN per impostazione predefinita, con caching per versione; l'applicazione le carica a runtime.

Come appare in pratica, con il confronto con un workflow a lotti e i team che rilasciano così, è nella pagina sulla localizzazione continua. La visione ingegneristica della stessa transizione, come una consegna a lotti rompe la consegna continua e come appare la pipeline cablata, è in come i workflow di traduzione a lotti rompono la consegna continua.

Se volete misurare il vostro tempo da stringa a online: create un progetto, collegate un namespace e cronometrate la prossima chiave dal commit a ogni lingua.

Domande frequenti

Che cos'è la localizzazione continua? Un workflow di traduzione in cui le stringhe nuove e modificate passano automaticamente e in continuo dalla codebase alle persone o ai sistemi che le traducono, in parallelo allo sviluppo, e in cui le traduzioni approvate vengono distribuite all'applicazione in esecuzione senza una release. È l'equivalente, per la localizzazione, dell'integrazione continua e della consegna continua.

In cosa la localizzazione continua differisce dalla localizzazione tradizionale? In un workflow a lotti le stringhe aspettano: congelamento, esportazione, traduzione, importazione, redeploy. Nella localizzazione continua niente aspetta un taglio: le stringhe vengono rilevate mentre vengono scritte, tradotte mentre lo sviluppo prosegue, filtrate dalla revisione anziché da un congelamento, e distribuite a runtime. La differenza è dove le stringhe stanno ferme tra il momento in cui vengono scritte e quello in cui sono online.

Cosa serve per implementare la localizzazione continua? Chiavi che nascono nel codice, un posto in cui traduttori, traduzione automatica e IA ci lavorano con contesto, un cancello di revisione e pubblicazione, e un percorso di distribuzione che raggiunge l'applicazione in esecuzione senza redeploy, di solito un CDN. Versioning e controlli di coerenza sull'intero corpus sono le due aggiunte di cui la maggior parte dei team ha bisogno subito dopo.

Localizzazione continua significa traduzione IA senza revisione umana? No. Continua descrive il flusso, non la politica di qualità. L'IA fornisce la prima bozza così che niente aspetti; cosa viene pubblicato lo decidono controlli, un punteggio di quality estimation e la revisione umana dove serve. Output automatico non revisionato spinto direttamente in produzione è continuo e non governato.

La localizzazione continua vale la pena per un team piccolo? Quando la traduzione è una dipendenza delle release: diversi deploy a settimana, più di una manciata di lingue, non sviluppatori che cambiano testo, o correzioni che devono uscire più in fretta del ciclo di rilascio. Un team piccolo con due lingue che legge da sé può tenere un processo a lotti; la distribuzione a runtime di solito vale comunque la pena.