Translation QA: cosa si rompe davvero nelle traduzioni, e come trovarlo automaticamente

La Translation QA (assicurazione qualità delle traduzioni) è la pratica di controllare i contenuti tradotti alla ricerca di difetti prima che raggiungano gli utenti. Ha due livelli: il livello meccanico, tutto ciò che si può confrontare oggettivamente tra un testo di partenza e la sua traduzione (placeholder, tag HTML, numeri, punteggiatura, spazi, coerenza terminologica), e il livello di giudizio, cioè se la traduzione dice davvero la cosa giusta con il tono giusto. Il primo livello si può automatizzare completamente. Il secondo no, e fingere il contrario è il modo in cui release rotte arrivano in produzione.

Questo articolo riguarda il primo livello: cosa si rompe davvero nei dati reali di traduzione, perché la revisione manuale continua a non vederlo, e cosa i controlli linguistici automatici possono farci, e cosa no.

Cosa si rompe davvero nelle traduzioni

Chiedete a qualcuno come appare un errore di traduzione e vi descriverà una traduzione sbagliata: una frase che dice la cosa sbagliata. Guardate nei dati reali di traduzione dei prodotti software e troverete qualcosa di meno affascinante. I difetti che arrivano in produzione sono in larghissima parte strutturali, e si raggruppano in una piccola tassonomia.

Placeholder e markup

La classe più dannosa. Un placeholder di interpolazione come {{count}} che un traduttore (o una macchina) ha rinominato, tradotto o perso non viene visualizzato come testo leggermente sbagliato: appare letteralmente come {{Anzahl}} sullo schermo, o manda in errore il formatter. Lo stesso vale per i tag HTML e dei componenti: i marcatori <0>…</0> di react-i18next, uno <strong> che ha perso il tag di chiusura, un link sparito in una lingua. Un tag rotto viene di solito visualizzato come testo grezzo, esattamente per gli utenti che leggono quella lingua, e per nessuno in ufficio.

Numeri

Un numero presente nel testo di partenza e assente nella traduzione ("30 giorni" tradotto come "giorni") cambia il significato in silenzio. La finezza: i numeri cambiano forma tra le lingue in modo del tutto legittimo. Formati numerici locali, cifre arabo-orientali e a larghezza piena, conversioni dall'orologio a 12 ore a quello a 24 ("9pm" diventa "21 Uhr") sono tutti corretti. Un controllo utile deve trattarli come uguali e segnalare comunque la quantità davvero mancante.

Punteggiatura, maiuscole, parentesi

Un due punti finale perso rompe un'etichetta che l'interfaccia concatena con un valore. Un punto interrogativo sparito trasforma una richiesta di conferma in un'affermazione. Lo spagnolo si aspetta il ¿ rovesciato quando la frase termina con un punto interrogativo. Le parentesi sono una categoria a sé: una traduzione con un numero di () diverso dal testo di partenza, o una parentesi non chiusa che l'originale non ha, è quasi sempre un valore troncato o modificato a metà. E la maiuscola iniziale differisce legittimamente tra le lingue (il tedesco scrive i sostantivi in maiuscolo; i frammenti dei titoli variano per lingua): un confronto ingenuo produce rumore invece di risultati.

Spazi

Invisibili e perciò popolari: spazi doppi dentro un valore, o spazi iniziali e finali che differiscono dal testo di partenza. Gli spazi finali contano nel momento in cui la vostra applicazione concatena frammenti tradotti. La tipografia francese aggiunge la sua sfumatura: uno spazio unificatore prima della punteggiatura è francese corretto e non va contato come doppio.

Ripetizioni

"Il il" capita in ogni lingua, di solito come residuo di una modifica. Il tranello: alcuni raddoppi sono grammaticalmente corretti, come le costruzioni riflessive francesi ("nous nous retrouvons") o certe sequenze di articoli in tedesco. Un controllo che non lo sa inonda i revisori di falsi positivi finché non lo spengono.

Terminologia incoerente

Il difetto più silenzioso, e nei nostri dati il più diffuso: lo stesso valore di partenza tradotto in modo diverso tra le chiavi. Un pulsante "Save" dice "Speichern", un altro "Sparen". Un termine è raramente tradotto male ovunque, ma spesso lo è da qualche parte, ed è in questi disaccordi che si nascondono le traduzioni sbagliate. Non è un controllo per singolo valore; ha bisogno dell'intero corpus di una lingua.

Markup pericoloso

La coda di sicurezza dello stesso problema: i valori di traduzione sono contenuti che la vostra applicazione renderizza. Un valore che contiene <script>, un handler onclick= o un URL javascript: non è un problema di qualità, è un vettore di injection, perché gli account dei traduttori e le chiavi API con permesso di scrittura fanno parte della vostra superficie di attacco, che li consideriate così o no.

Quanto è frequente davvero?

Misurato sui progetti Locize nell'agosto 2026: circa il 2,3% dei segmenti tradotti fa scattare almeno uno dei controlli meccanici qui sopra, con in testa spazi, punteggiatura finale e differenze nei numeri. La coerenza tra chiavi è ancora più ampia: circa il 3,9% dei segmenti ha almeno una chiave sorella che traduce diversamente lo stesso valore di partenza, e l'87% dei progetti campionati contiene almeno un disaccordo di questo tipo.

Un segmento su quaranta sembra poco, finché non lo si moltiplica per un prodotto con ventimila segmenti in otto lingue. E si concentra esattamente nei contenuti cambiati di recente, cioè quelli che la vostra prossima release spedisce.

Come i team fanno Translation QA oggi

La maggior parte dei team che prende sul serio la qualità delle traduzioni combina alcuni di questi approcci:

• Un passaggio di revisione umana per lingua, con un secondo traduttore, un collega nel mercato di destinazione o un giro di LQA dell'agenzia. È lo strumento giusto per significato e tono, e quello sbagliato per i placeholder: gli umani sorvolano sul dettaglio meccanico, e un revisore che controlla il numero di parentesi su 4.000 stringhe smette di essere un linguista e diventa una regex molto costosa.
• Controlli a campione nei fogli di calcolo: esportare, filtrare, dare un'occhiata. Trova ciò che per caso si guarda, il giorno in cui lo si guarda.
• Script fatti in casa nella CI: una raccolta di regex scritte in un pomeriggio, che cattura le interpolazioni mancanti in un formato di file, nelle lingue a cui l'autore ha pensato. Utile, non mantenuto, e cieco a tutto ciò che attraversa le chiavi (la coerenza) e a tutto ciò che è specifico di una lingua (il ¿, lo spazio unificatore, le maiuscole dei sostantivi tedeschi).
• Guide di stile e glossari come documenti: la terminologia corretta vive in un PDF che i revisori dovrebbero ricordare mentre il corpus reale va alla deriva.

Lo schema comune a tutti e quattro: il livello meccanico viene controllato occasionalmente e parzialmente, da persone o script costruiti per altro. I difetti, nel frattempo, entrano in continuo, con ogni nuova chiave, ogni batch tradotto automaticamente e ogni correzione veloce digitata direttamente in un file.

Cosa cambiano i controlli linguistici automatici

Un controllo automatico esegue il confronto in cui un revisore non è mai stato bravo, su ogni valore, in ogni lingua, a ogni modifica. I requisiti che separano un'implementazione utile da un generatore di rumore:

1. Consapevolezza della lingua. Ogni controllo qui sopra ha eccezioni legittime per lingua. Un validatore che segnala le maiuscole dei sostantivi tedeschi come errore, o gli spazi unificatori francesi come doppi, insegna ai revisori a ignorarlo nel giro di una settimana.
2. Portata di corpus. I difetti di coerenza sono invisibili a livello di singolo valore. Il controllo deve confrontare attraverso tutte le chiavi di una lingua.
3. Continuo per impostazione predefinita. Un giro di QA che qualcuno deve ricordarsi di lanciare è un foglio di calcolo con un'interfaccia migliore. I controlli appartengono al percorso di salvataggio e all'editor, con i risultati agganciati alla chiave, non a un report che nessuno riapre.
4. Una via d'uscita per singolo risultato. A volte la differenza è voluta: la stessa parola di partenza ha davvero bisogno di due traduzioni in due contesti. Se ignorare un risultato non è un'azione mirata a un clic, i team disattivano l'intero controllo.
5. Un confine netto con il giudizio umano. I controlli rispondono a "è strutturalmente coerente con il testo di partenza e con il corpus?". Non rispondono a "è una buona traduzione?". Quello resta lavoro di revisione, supportato da glossari e guide di stile, e per le traduzioni generate automaticamente dalla Quality Estimation, che valuta ciò che i controlli non possono confrontare.

Come funziona in Locize

Locize gestisce questo livello in modo integrato, attivo per impostazione predefinita, senza configurazione:

• Dieci controlli linguistici consapevoli della lingua confrontano ogni traduzione con il suo testo di partenza: punteggiatura finale, maiuscola iniziale, numeri, numero di parentesi, parentesi non bilanciate, spazi, parole ripetute, caratteri speciali, numero di URL, e tag HTML o dei componenti, ciascuno con le eccezioni per lingua descritte sopra.
• I controlli di coerenza lavorano su tutto il corpus: trovano lo stesso valore di partenza tradotto diversamente tra le chiavi (le chiavi in disaccordo sono elencate accanto al risultato), i valori di partenza duplicati, le violazioni del glossario e le incoerenze di sintassi i18n.
• Il rilevamento del markup pericoloso segnala contenuti che eseguono script nei valori e per impostazione predefinita ne blocca il salvataggio, nell'editor come via API, così un account traduttore compromesso non può iniettare <script> nella vostra applicazione attraverso una traduzione.
• I risultati compaiono direttamente nell'editor sulla chiave, si aggregano nelle statistiche di traduzione del progetto, e ogni risultato può essere ignorato per chiave dove la differenza è voluta. Potete anche eseguire tutti i controlli sull'intero progetto in un'unica azione:

Eseguire tutti i controlli di un progetto in Locize

Il senso di questa impostazione predefinita è lo stesso di questo articolo: il livello meccanico non è il posto dove deve andare l'attenzione umana. Lasciate che i controlli tengano quella linea, date ai revisori il glossario, la guida di stile e il workflow di revisione, e investite gli umani nella parte che le macchine non possono giudicare.

Se volete vedere cosa trovano i controlli nei vostri contenuti: create un progetto, importate i vostri file di traduzione esistenti e lanciate i controlli. I risultati di solito non sono quelli che vi aspettavate.

Domande frequenti

Che cos'è la Translation QA? La Translation QA (assicurazione qualità delle traduzioni) è la pratica di controllare i contenuti tradotti prima del rilascio. Copre il livello meccanico (placeholder, tag, numeri, punteggiatura, spazi, coerenza) e il livello di giudizio (significato, tono, scorrevolezza). Il primo si automatizza; il secondo richiede persone, supportate da glossari, guide di stile e workflow di revisione.

Quali sono gli errori più comuni nelle traduzioni? Dominano i difetti meccanici: placeholder di interpolazione e tag HTML modificati o persi, numeri divergenti dal testo di partenza, punteggiatura finale mancante, spazi danneggiati attorno a valori concatenati, parole ripetute, e lo stesso termine tradotto in modo incoerente tra le chiavi.

La Translation QA può essere automatizzata? Il livello meccanico si verifica in modo deterministico a ogni salvataggio, in ogni lingua. Il livello di giudizio no: l'output della traduzione automatica può essere valutato dalla Quality Estimation, la revisione umana decide. Gli impianti che funzionano combinano entrambi.

Qual è la differenza tra controlli QA e Quality Estimation (QE)? I controlli QA sono confronti deterministici con il testo di partenza e con il corpus; trovano difetti strutturali e sono sempre riproducibili. La QE è un punteggio di modello che predice la qualità di una traduzione senza riferimento. La QE dà priorità all'attenzione di revisione per le nuove traduzioni automatiche; i controlli QA presidiano l'intero corpus in continuo.

I controlli automatici sostituiscono la revisione umana? No. Eliminano il rumore meccanico perché il tempo di revisione vada a significato, terminologia e tono. Un revisore liberato dal conteggio delle parentesi è un linguista migliore, non un linguista disoccupato.