Errori di formattazione nella traduzione: Guida completa

Tradotto con l’IA di Lara Translate

La maggior parte delle lamentele sulla qualità della traduzione punta il dito contro il motore. Nella maggior parte dei casi, è un’errata valutazione. Il testo restituito è illeggibile, il layout è compromesso, i caratteri vengono visualizzati come punti interrogativi… e il problema era nel file, prima ancora che il motore lo vedesse. Gli errori di formattazione nella traduzione sono la causa più comune di rilavorazioni evitabili in qualsiasi flusso di lavoro di localizzazione e non hanno nulla a che fare con il modello di IA che stai utilizzando. Questa guida illustra i problemi che possono verificarsi in base al tipo di file, i formati che si traducono senza intoppi e una serie di piccole abitudini che prevengono la maggior parte dei problemi prima che si presentino.

La maggior parte dei problemi di traduzione ha origine dal file, non dal motore

I team attribuiscono ai motori di traduzione problemi che non sono stati causati da questi ultimi. Il testo risulta strano da leggere. Le tabelle si spostano. I punti elenco si moltiplicano o svaniscono. Le intestazioni perdono il loro stile. I caratteri speciali vengono visualizzati come punti interrogativi. Interi blocchi di testo scompaiono.
Nella maggior parte di questi casi, il motore ha svolto il suo compito. Il file, invece, no. Si tratta di errori di formattazione della traduzione, non di qualità della traduzione, e possono essere corretti a livello di file.

Gli errori di formattazione nella traduzione sono un insieme di errori evitabili che si verificano quando i file di origine non sono preparati per il modo in cui un motore di traduzione basato sull’intelligenza artificiale li legge. Si presentano come:

• Contenuti persi o duplicati. Il testo in intestazioni, piè di pagina, note a piè di pagina, commenti o note del relatore viene tradotto due volte, oppure saltato del tutto.
• Errori di codifica. Caratteri accentati, simboli di valuta o alfabeti non latini arrivano al motore danneggiati e vengono restituiti corrotti.
• Testo incorporato non tradotto. Le parole all’interno di immagini, grafici e grafiche SVG risultano invisibili al motore e vengono consegnate nella lingua di partenza.
• Danni a tag e codice. I file HTML, XML e JSON perdono la struttura dei tag, compromettendo pagine, componenti o intere build a valle.

Ognuno di questi problemi può essere risolto a livello di file. Nessuno di questi è un problema di modello. Scegliere il formato giusto e preparare il file prima dell’invio risolve da solo la maggior parte dei problemi.

Problemi comuni con i tipi di file nella localizzazione

Formati diversi presentano problemi diversi. Riconoscere gli schemi è il primo passo per evitarli.

PDF

I PDF sono il formato che i team scelgono più spesso e quello che si traduce peggio. Ci sono due casi distinti:

• I PDF nati digitali (esportati da Word, InDesign, ecc.) sono gestibili. Il testo è estraibile. La ricostruzione del layout è imperfetta ma utilizzabile.
• I PDF scansionati sono immagini di testo. Senza OCR, il motore vede pixel, non parole. Anche con l’OCR, il layout e la precisione ne risentono, soprattutto per documenti complessi come contratti o moduli.

Se disponi del file originale in Word, InDesign o del documento di design sorgente, invia quello. Inviare un PDF di un documento che in origine è in un altro formato è uno dei problemi più comuni legati al tipo di file nella localizzazione, e uno dei più facili da evitare.

DOCX e altri file di Office

I file DOCX, PPTX e XLSX si traducono bene quando sono puliti. La traduzione risulta scadente quando i file sono composti da elementi con interruzioni di riga manuali, formattazione nascosta, oggetti incorporati o caselle di testo incollate sopra le immagini.
Ecco alcune delle insidie più comuni:

• Interruzioni di riga manuali (Shift+Invio) all’interno dei paragrafi, che il motore considera come delimitatori di frase.
• Tabelle create con caratteri di tabulazione invece di vere e proprie tabelle.
• Testo inserito in immagini o forme raggruppate, invisibile alla maggior parte degli strumenti di estrazione.
• Revisioni e commenti tradotti insieme al testo originale.

Una rapida revisione prima dell’invio – accettare tutte le modifiche, rimuovere i commenti, sostituire le tabelle fittizie con quelle vere – evita la maggior parte di questi problemi.

HTML, XML e JSON

Questi sono gli input preferiti dal motore, se gestiti correttamente. I tag separano il testo traducibile dal codice, gli attributi indicano ciò che non va modificato e la struttura ritorna perfettamente al sistema che l’ha generata.
I problemi sorgono quando i team cercano di tradurli senza proteggere le parti non traducibili. Ecco alcuni degli errori più comuni:

• Tradurre i valori degli attributi che dovrebbero rimanere nella lingua di origine: URL, ID, nomi di classe, attributi di dati.
• Rompere la sintassi dei segnaposto — {username}, %s, {{count}} — traducendo il nome della variabile o suddividendo il segnaposto tra più segmenti.
• Perdita di spazi o interruzioni di riga da cui dipende il rendering successivo.
• Tradurre il codice incorporato o gli esempi tecnici che dovrebbero rimanere invariati.

La soluzione è utilizzare uno strumento di traduzione o un flusso di lavoro che riconosca il formato e lo analizzi come codice, non come testo semplice, e fare una prova su un piccolo campione prima di elaborare l’intero file.

XLIFF e altri formati nativi per la traduzione

XLIFF è lo standard del settore per lo scambio di contenuti traducibili tra sistemi e strumenti. Separa il testo di origine da quello di destinazione, contrassegna i segmenti e conserva i metadati. Se il tuo stack lo supporta, è quanto di più vicino a un formato predefinito corretto per il lavoro di traduzione, e Lara Translate lo supporta nativamente insieme a oltre 70 altri formati.
Anche InDesign IDML, FrameMaker MIF e formati di pubblicazione simili si traducono in modo impeccabile se gestiti da strumenti in grado di comprenderli. È quando si forzano questi formati in una pipeline di testo generica che le cose iniziano a non funzionare.

Fogli di calcolo

I file XLSX si traducono bene a livello di cella, ma la struttura circostante può causare problemi:

• Le formule che fanno riferimento ad altre celle vengono tradotte e non funzionano più.
• Le celle unite, le righe nascoste e la formattazione condizionale possono confondere l’estrazione.
• Le stringhe lunghe escono dai bordi delle colonne strette nella lingua di destinazione e appaiono danneggiate anche quando sono corrette.

Per le tabelle di stringhe, una struttura piatta – una colonna per la sorgente, una colonna per la destinazione e una per il contesto – garantisce una traduzione più affidabile rispetto a un modello annidato. Per questo motivo, Lara Translate gestisce i file CSV e XLSX in modo nativo.

File di immagini, video e design

Il testo incorporato in immagini, screenshot, infografiche e sottotitoli video si trova al di fuori di qualsiasi livello di testo che il motore possa leggere. Deve essere estratto, tradotto e reinserito, di solito manualmente o tramite un flusso di lavoro separato. Lara Translate supporta la traduzione da immagine a immagine e del testo all’interno di immagini PDF, risolvendo così una parte significativa del problema. Trattare queste risorse come parte integrante della traduzione, e non come un elemento secondario, evita i problemi di layout più evidenti al momento del lancio.

I migliori formati di file per la traduzione con l’IA

La raccomandazione è semplice. I formati di file migliori per la traduzione con l’IA condividono tre proprietà: testo leggibile a macchina, struttura separabile e metadati preservati.
In ordine approssimativo di preferenza per contenuti generali aziendali e tecnici:

1. XLIFF. Creato appositamente per la traduzione. Da usare ogni volta che la toolchain lo supporta.
2. Formati sorgente nativi (DOCX, PPTX, XLSX, IDML, MIF). Traduci l’originale, non un file esportato.
3. HTML, XML, JSON e YAML. Eccellente quando il flusso di lavoro protegge tag, attributi e placeholder.
4. Markdown. Si traduce bene per la documentazione quando i blocchi di codice e i link vengono gestiti correttamente.
5. Testo semplice (TXT, CSV). Accettabile per contenuti semplici senza requisiti strutturali.
6. PDF nativo digitale. Da usare solo quando il formato di origine non è davvero disponibile.
7. PDF scansionati o file di sola immagine. Ultima risorsa. Aspettati di dover rifare il lavoro.

La stessa logica vale per i motori di intelligenza artificiale e per i traduttori umani. I formati di file migliori per la traduzione con l’IA sono gli stessi che richiedono i traduttori umani di qualità. Se un file rallenterebbe un linguista, il modello produrrà un risultato peggiore.

Consigli pratici per evitare errori di formattazione nelle traduzioni

Con poche semplici abitudini, la maggior parte degli errori di formattazione nella traduzione viene eliminata prima ancora che arrivi al motore.

• Invia il file sorgente modificabile, non uno snapshot. Le esportazioni in PDF di documenti Word o gli screenshot di diapositive perdono informazioni necessarie al motore.
• Per prima cosa, pulisci il file. Accetta le revisioni, rimuovi i commenti, correggi le interruzioni di riga manuali, sostituisci le tabelle fittizie e normalizza gli stili. Dieci minuti di pulizia fanno risparmiare ore di post-editing.
• Blocca ciò che non deve essere tradotto. Nomi di marchi, codice, segnaposto, URL, termini regolamentati. Utilizza gli indicatori “non tradurre” del motore o dello strumento CAT. In Lara Translate, i glossari gestiscono questo aspetto su larga scala.
• Standardizza la codifica. UTF-8 è l’impostazione predefinita sicura. I file con codifiche obsolete danneggiano i caratteri speciali e le scritture non latine durante il processo di conversione.
• Esegui un test con un piccolo campione. Esegui il flusso di lavoro su alcune pagine rappresentative prima di impegnarti nell’intero progetto. Individua eventuali problemi di gestione dei tag, codifica e layout con un test di 5 pagine, non con un lancio di 500 pagine.
• Convalida l’output prima della pubblicazione. Soprattutto per i file strutturati (HTML, XML, JSON), verifica che il file tradotto venga analizzato correttamente. Una parentesi non corretta in un file JSON di 200 stringhe può compromettere un intero rilascio.

Questi passaggi trasformano il formato del file da una speranza a un controllo. Lo stesso progetto, eseguito due volte – una con un sorgente pulito e una senza – produrrà un output visibilmente diverso, indipendentemente dal motore utilizzato.

Come Lara Translate gestisce la complessità dei formati di file

La maggior parte degli strumenti di traduzione ti lascia con il problema del formato. Lara Translate è progettato per risolverlo.

• Oltre 70 formati di file supportati. Il motore di traduzione di documenti di Lara Translate supporta oltre 70 formati, tra cui DOCX, PPTX, XLSX, HTML, XML, JSON, IDML e molti altri, coprendo così la vasta gamma di contenuti strutturati in cui solitamente si verificano errori di formattazione nella traduzione. L’elenco completo è disponibile su developers.laratranslate.com/docs/supported-file-formats.
• Mantenimento del layout e della struttura. Lara Translate mantiene la formattazione, il layout e gli elementi strutturali sia nel testo di partenza che in quello di arrivo, riducendo così la necessità di interventi manuali per correggere tabelle danneggiate, stili persi o elementi di pagina spostati.
• Tre stili di traduzione per calibrare il tono. Gli stili Faithful, Fluid e Creative consentono ai team di adattare il motore al tipo di contenuto: un complemento utile quando si gestiscono file di vario tipo, con contenuti tecnici, editoriali e di marketing.
• Il modello Think per controlli linguistici in più fasi. Secondo la documentazione ufficiale, il modello Think di Lara esegue un’analisi linguistica in più fasi che copre grammatica, stile e contesto, progettata per rilevare circa l’80% dei principali problemi linguistici. Ciò è utile per individuare artefatti di codifica e problemi relativi ai tag che sopravvivono alla fase di conversione del formato.

Creare un manuale di formattazione per il tuo team

Gli errori di formattazione nelle traduzioni diminuiscono rapidamente quando la scelta del formato non viene più fatta caso per caso. Un breve playbook trasforma le regole di cui sopra in qualcosa che il team dei contenuti può applicare senza pensarci, e fa sì che gli errori di formattazione nella traduzione non siano più un fastidio ricorrente, ma un problema risolto.

• Formati predefiniti per ogni tipo di contenuto. Documentazione in Markdown o HTML. Marketing in DOCX. Stringhe dell’interfaccia utente in XLIFF o JSON. Fogli di calcolo per glossari strutturati. Imposta i valori predefiniti e gestisci le eccezioni come tali.
• Una checklist pre-lancio. Prima di inviare qualsiasi file in traduzione, esegui sempre lo stesso controllo: formato del testo di partenza, codifica, contenuto pulito, termini bloccati, campione testato.
• Un elenco di riferimento degli input accettabili. Pubblica ciò che il tuo team accetta e ciò che restituisce. “Non traduciamo PDF scansionati senza OCR” è una politica produttiva, non ostile.
• Un canale per ricevere il feedback dei traduttori. Che il tuo team si affidi a liberi professionisti, agenzie o motori di intelligenza artificiale, sono le persone che lavorano più a stretto contatto con il file a notare per prime i problemi di formato. Registra il loro feedback nel playbook, in modo che il prossimo progetto parta da ciò che è stato appreso in quello precedente.
• Una revisione periodica. Nuovi strumenti, nuovi tipi di contenuto e nuovi mercati modificano il mix di formati. Una revisione trimestrale mantiene la compatibilità dei file nella traduzione in linea con il modo in cui il team lavora effettivamente.

Se ben realizzato, questo playbook risolve definitivamente il problema della compatibilità dei file nella traduzione, evitando che diventi un problema ricorrente. In questo modo, il team può concentrarsi sugli aspetti della qualità della traduzione che richiedono davvero un giudizio linguistico.

Conclusione

Il formato del file non è un dettaglio. È la prima decisione in qualsiasi flusso di lavoro di traduzione e determina quanto della qualità del motore si rifletta effettivamente nel risultato finale. La maggior parte degli errori di formattazione nella traduzione avviene prima ancora che il motore entri in gioco.
Invia il file sorgente modificabile. Pulisci il file. Esegui un test su un piccolo campione. Convalida l’output. Non sono passaggi complessi. Sono proprio quelle che spesso vengono saltate nella fretta di rispettare una scadenza, e che poi generano il maggior numero di modifiche successive.
Lara Translate si occupa del formato, così il tuo team può concentrarsi su ciò che richiede davvero un intervento umano. Per farlo bene non serve un nuovo strumento o un nuovo processo: basta considerare il formato come una variabile fondamentale nella localizzazione, non come un elemento secondario.

Domande frequenti

Quali sono gli errori di formattazione più comuni nelle traduzioni?

Inviare PDF scansionati, tradurre file esportati invece dei file originali, lasciare attive le revisioni e i commenti, e danneggiare tag o segnaposto in file strutturati come HTML, XML e JSON.

Quali sono i formati di file migliori per la traduzione con l’IA?

XLIFF, formati nativi di origine (DOCX, PPTX, XLSX, IDML) e formati strutturati (HTML, XML, JSON, YAML) quando tag e placeholder sono protetti. Il testo semplice va bene per contenuti semplici. I PDF scansionati sono l’ultima risorsa.

Perché la scelta dei formati di file per la traduzione automatica è così importante?

Perché la maggior parte dei problemi di qualità attribuiti al motore sono in realtà legati al formato: codifica errata, tag non funzionanti, layout perso, testo incorporato. Il formato giusto fornisce al motore un input corretto ed elimina la necessità di dover apportare modifiche evitabili.

Come posso evitare problemi di conservazione del layout quando traduco documenti?

Invia il file sorgente modificabile, puliscilo prima dell’invio, blocca gli elementi non traducibili, standardizza l’encoding su UTF-8 e testa un piccolo campione prima di elaborare il file completo.

I PDF sono una scelta sbagliata per la traduzione automatica basata sull’intelligenza artificiale?

I PDF nati in formato digitale sono utilizzabili, ma raramente rappresentano la soluzione ideale. I PDF scansionati sono la scelta peggiore, perché il motore riconosce le immagini al posto del testo. Quando possibile, invia il file originale in Word, InDesign o il file sorgente.

Il modello di traduzione influisce sul mantenimento del layout?

No. La conservazione del layout è un problema legato al formato del file. Il motore traduce solo ciò che il file gli rende accessibile. Passare a un modello di qualità superiore non ripristinerà il testo incorporato nelle immagini né correggerà i tag non funzionanti.

Questo articolo parla di

• Perché la maggior parte degli errori di formattazione nella traduzione è dovuta al file e non al motore.
• Problemi comuni relativi al tipo di file nella localizzazione di PDF, file Office, formati strutturati e immagini.
• I migliori formati di file per la traduzione AI, classificati in base alla qualità del risultato finale.
• Passaggi pratici per scegliere i formati di file per la traduzione automatica ed evitare problemi di conservazione del layout.
• Una breve guida per risolvere il problema della compatibilità dei file nella traduzione, per tutti i tipi di contenuto.

Articoli utili

• 84 domande da porsi prima di tradurre un documento o un file con l’IA
• Traduci in Google Sheets con Lara Translate (e smetti di rovinare l’allineamento)