Perché i file di traduzione continuano a perdere l’allineamento?

I file di traduzione perdono l’allineamento perché due sistemi possiedono gli stessi dati e nessuno dei due prevale. Il repository cambia quando uno sviluppatore fa merge. I file di traduzione cambiano quando qualcuno si ricorda di aggiornarli. Sono due orologi diversi e nello spazio tra loro vivono chiavi mancanti, chiavi orfane e stringhe obsolete. globalize.now è un’infrastruttura di localizzazione basata su IA che colma il divario generando chiavi e file di traduzione nel punto in cui viene scritto il codice, così non esiste un secondo orologio che possa restare indietro.

Cosa fa davvero perdere l’allineamento ai file di traduzione?

Un file viene scritto e gli altri vengono mantenuti: non è lo stesso lavoro.

Uno sviluppatore che costruisce una funzionalità modifica en.json perché è il file in cui finirà la stringa. Le altre lingue sono un problema di qualcun altro, con la tabella di marcia di qualcun altro. Uno sviluppatore che ha scritto di questo pattern su DEV ha descritto le due forme del problema: le chiavi vengono aggiunte al file inglese e dimenticate negli altri, così una parte dell’app torna silenziosamente all’inglese; oppure le chiavi vengono eliminate in una lingua ma restano nelle altre, accumulando voci obsolete. In entrambi i casi, il problema viene scoperto da un reclamo di un cliente, settimane dopo.

Nessuno dei due è un problema di traduzione. Non è stato tradotto nulla in modo errato. Le stringhe non sono mai state instradate da nessuna parte.

È il tipo di errore che sopravvive a ogni aggiornamento degli strumenti, perché gli strumenti intervengono a valle del punto in cui la stringa è stata creata. Se la stringa non entra mai nella pipeline, una pipeline migliore non serve. La stessa causa alla radice compare ancora prima nella catena, quando un coding agent scrive stringhe che non sono mai state trasformate in chiavi.

Perché i file di traduzione generano così tanti conflitti di merge?

Perché sono dati generati, modificati a mano, in un formato progettato per essere scritto dalle macchine.

Un file di traduzione è una mappa piatta di chiavi e stringhe. Due branch che aggiungono entrambi una feature aggiungono elementi alla stessa mappa, di solito quasi nello stesso punto, di solito nella stessa zona alfabetica. Git vede due modifiche a righe adiacenti in un file privo di una struttura semantica che possa comprendere e chiede a una persona di risolvere il conflitto.

A risolverlo è uno sviluppatore che non legge la lingua di destinazione. La scelta sicura è mantenere entrambe le versioni: così compaiono chiavi duplicate. La scelta rapida è mantenerne una sola: così le traduzioni vengono eliminate senza che nessuno se ne accorga.

Nessuno risolve a mano i conflitti in un lockfile. Lo rigenera. I file di traduzione meritano lo stesso trattamento non appena smettono di essere documenti scritti da una persona.

Quanto diventa obsoleta una traduzione mentre aspetta la review?

Abbastanza da smettere di descrivere il prodotto. E questo si può misurare pubblicamente.

Un field report pubblicato su DevOps.com ha seguito cinque pull request di localizzazione reali in progetti open source. Quella più istruttiva è la PR #8377 di Kilo Code: i controlli automatici sono passati, la review del maintainer è arrivata dopo e nel frattempo il repository era già cambiato. La PR è stata chiusa con l'invito a ripresentarla sulla base dell'architettura corrente. Lo stesso report documenta un issue di OpenClaw in cui volontari avevano offerto traduzioni in spagnolo, giapponese, portoghese, coreano, cinese e vietnamita, ma i maintainer hanno detto di non avere modo di integrarle.

Leggile come report sulla latenza, non sulla qualità. Le traduzioni erano corrette quando sono state scritte. L'interfaccia è cambiata mentre erano in coda.

È il costo che nessuno considera quando confronta gli strumenti di localizzazione. Tutti misurano la traduzione. Quasi nessuno misura quanto tempo una stringa trascorre in transito o cosa è successo all'interfaccia mentre non c'era.

Quanto costa davvero il round-trip?

Più in coordinamento che in traduzione. Ecco perché la fattura non spiega mai il problema.

Il costo visibile è calcolato per parola, per chiave o per seat e compare in fattura una volta al mese. Il costo invisibile è uno sviluppatore che chiede «quale file devo modificare?», un secondo sviluppatore che risolve un conflitto in una lingua che non sa leggere, un terzo che si accorge che nella build tedesca mancano undici chiavi e l'autore della feature originale a cui viene chiesto conto di una stringa scritta cinque settimane prima.

Niente di tutto questo compare in un confronto dei prezzi. Ma tutto viene pagato in tempo di sviluppo, alle tariffe degli sviluppatori, a ogni sprint. Uno strumento dal prezzo in vetrina basso che costa a due ingegneri una giornata alla settimana non è economico.

È il round-trip a generare questo costo. Spostare i file dal punto in cui vengono create le stringhe a quello in cui vengono tradotte è il passaggio costoso e resta costoso indipendentemente da chi lo vende. È anche per questo che la localizzazione continua a spostarsi a monte, dentro il ciclo di sviluppo.

Cosa cambia quando le chiavi vengono generate dove si scrive il codice?

Il secondo orologio scompare e il drift non ha più da dove arrivare.

La sequenza non è più: lo sviluppatore scrive una stringa hardcoded, qualcuno la trova in seguito, qualcuno crea la chiave, qualcuno invia il file, qualcuno lo traduce e qualcuno lo riporta indietro. Diventa: la stringa viene scritta come chiave con un valore, nello stesso commit della feature, e da lì parte la traduzione.

Con globalize.now si parte da una conversione una tantum. Connetti il repository nell'app e le stringhe hardcoded esistenti vengono estratte in chiavi e file di traduzione in un unico passaggio. Dopodiché le skill dell'agente fanno sì che coding agent come Cursor e Claude Code scrivano stringhe con chiavi fin dall'inizio, invece di hardcodarle, mentre i job avviati dai push traducono le nuove unità del catalogo man mano che compaiono.

La parola importante è «una volta». La conversione è la parte difficile e avviene una sola volta. Quello che segue è ciò che prima era manuale, eseguito sullo stesso ritmo del codice: è questo il motivo per cui va inserito nel workflow dello sviluppatore invece di restargli accanto.

Le librerie di runtime non cambiano. i18next e next-intl continuano a leggere i file di traduzione esattamente come prima. Non cambia nulla nel modo in cui le traduzioni vengono servite. Cambia chi scrive i file.

Come distingui il drift da un vero problema di traduzione?

Chiediti se una persona incaricata della traduzione ha mai visto la stringa.

Se nel file tedesco manca una chiave, non è colpa di chi traduce. La stringa non è mai arrivata a nessuno. È un problema di instradamento e aggiungere passaggi di review lo peggiora, perché aggiunge tempo di coda a un processo il cui problema è già la latenza.

Se nel file tedesco la chiave c'è ma la formulazione è sbagliata per il contesto, allora è un vero problema di traduzione. Merita una persona che parli tedesco e possa vedere dove viene visualizzata la stringa. In questo caso il tempo è ben speso.

La maggior parte dei team ha molti più problemi del primo tipo che del secondo, ma li tratta come se fossero lo stesso problema. Ecco perché la localizzazione sembra non finire mai. Separali e il carico di lavoro diminuisce, perché la parte di instradamento smette del tutto di essere lavoro umano. La distinzione conta ancora di più per i team piccoli, ed è per questo che emerge con particolare chiarezza per chi sviluppa da solo e per i piccoli team che rilasciano rapidamente.

Un test utile: conta quanti degli ultimi dieci bug di localizzazione riguardavano parole sbagliate e quanti parole mancanti. Se la maggior parte riguardava parole mancanti, non hai un problema di traduzione. Hai un problema di infrastruttura idraulica, per così dire, e questo tipo di problema è automatizzabile in un modo in cui il giudizio non lo è. La stessa logica vale quando cerchi di capire quanto dovrebbe costarti davvero la localizzazione.

Il drift dei file di traduzione è un problema di instradamento travestito da problema di traduzione. Connetti il repository una volta e l'instradamento smette di essere un tuo compito.