Tradotto con l’IA di Lara Translate
La maggior parte dei problemi di traduzione dei file XLIFF non dipende da una cattiva traduzione. Succedono a causa di uno strumento inadeguato. Se un traduttore incolla contenuti XLIFF in Google Translate o uno sviluppatore li fa passare attraverso un modello di IA generico, quasi sempre otterrà in cambio un file in cui i tag XML sono stati danneggiati, spostati o cancellati. Da solo, il testo tradotto potrebbe sembrare a posto, ma non appena provi a importare quel file in Trados, memoQ, Xcode o nel tuo progetto Angular, qualcosa va storto. A volte compare un errore XML criptico, a volte non succede nulla e si genera una build in cui alcune stringhe semplicemente non compaiono.
|
TL;DR
|
Risposta breve
I tag XLIFF si rompono quando uno strumento di traduzione tratta il file come testo normale invece che come XML. La soluzione è usare uno strumento che analizza la struttura del documento, estrae solo il contenuto leggibile dall’uomo dagli elementi <source> e riscrive le traduzioni nei nodi <target>, lasciando completamente intatti tutti i tag, gli ID e gli attributi inline.
Perché è importante: Un tag XLIFF danneggiato non causa solo un errore di traduzione, ma anche un errore di runtime. Se manca un placeholder, la tua app mostra all’utente “Welcome back, !”. Un file XML non valido significa che l’importazione nel CAT tool non è andata a buon fine. In ogni caso, la build localizzata è danneggiata e per risolvere il problema bisogna ricominciare da capo.
Traduci i file XLIFF senza toccare i tag
Il processore XLIFF di Lara blocca tutti gli elementi inline — <x/>, <g>, <bpt>, <ept> — e traduce solo il testo leggibile dall’utente. Il tuo file torna con la stessa struttura, pronto per l’importazione.
Perché i tag XLIFF si rompono durante la traduzione
In un file XLIFF reale, le stringhe di partenza raramente contengono solo testo semplice. Una stringa come «Welcome back, {name}!» non esiste con quei caratteri letterali. Invece, ha questo aspetto:
<trans-unit id="welcome.message">
<source>Welcome back, <x id="1" equiv-text="{name}"/>!</source>
<target/>
</trans-unit>Quel <x id=”1″/> è un placeholder che rappresenta una variabile di runtime: il nome di un utente, un numero, una data. Nella traduzione, devi mantenerlo nella posizione corretta rispetto al testo circostante. Se lo sposti, lo elimini o ne traduci gli attributi, la stringa si rompe in fase di esecuzione.
Altri elementi inline sono altrettanto importanti:
- <g id=”n”>…</g> — racchiude il testo con una formattazione specifica: un link, uno span in grassetto, un’etichetta dell’interfaccia utente
- <bpt>/<ept> — tag di apertura e chiusura accoppiati per la formattazione inline che si estende su più segmenti
- <it> — tag isolati per la formattazione che si aprono o si chiudono al di fuori del segmento corrente
Gli strumenti di traduzione generici considerano l’intero file come un flusso di testo. Non sanno che <x id=”1″/> è strutturale. Potrebbero tradurre «id» come una parola italiana, rimuovere il tag perché «non è testo» o riordinare gli elementi inline in base alla sintassi della lingua di destinazione. L’output sembra valido, ma è strutturalmente danneggiato.
I quattro errori più comuni nei tag XLIFF
1. Placeholder mancanti
Il traduttore omette un elemento <x/> inline. In fase di esecuzione, la variabile non viene visualizzata: la tua app mostra “Welcome back, !” invece di “Welcome back, Anna!”
2. Tag riordinati
In alcune lingue, l’ordine naturale delle parole sposta un placeholder in una posizione diversa. Uno strumento che corregge la posizione dei tag in base alla sintassi tradotta genererà un file in cui la variabile si troverà nella posizione sbagliata, oppure farà scattare un errore di convalida dell’ordine dei tag nel CAT tool.
3. Contenuto dei tag tradotto
Uno strumento poco sofisticato vede <x id=”1″ equiv-text=”{name}”/> e traduce “name” nella lingua di destinazione. Il riferimento alla variabile si rompe del tutto perché l’app cerca {name}, non {nombre}.
4. Malformazione XML
Incollare un file XLIFF in uno strumento che non capisce l’XML provoca problemi di codifica, caratteri non escapati o tag non corrispondenti. Il file risultante non si analizza: l’importazione genera un errore o, in alcuni strumenti, importa silenziosamente zero stringhe.
Come funziona la gestione corretta dei tag in XLIFF
In un file XLIFF tradotto correttamente, la serie di elementi inline è identica sia nel testo di partenza che in quello di arrivo: stessi tag, stessi ID, stesse posizioni relative. Cambia solo il testo leggibile dall’uomo che li circonda:
<trans-unit id="welcome.message">
<source>Welcome back, <x id="1" equiv-text="{name}"/>!</source>
<target>Willkommen zurück, <x id="1" equiv-text="{name}"/>!</target>
</trans-unit>Il tag è intatto. L’ID è rimasto invariato. È cambiato solo il testo.
Come Lara Translate gestisce i tag XLIFF
Il processore XLIFF di Lara gestisce il file come XML, non come testo. Analizza la struttura del documento, identifica gli elementi <trans-unit>, estrae il testo traducibile dai nodi <source>, lo traduce trattando gli elementi inline come opachi e intoccabili e scrive il risultato nei nodi <target>. Non viene modificato nient’altro. ID delle trans-unit, metadati a livello di file, note dello strumento, tag di formattazione inline — tutto viene mantenuto esattamente come nel file di origine. Funziona sia con XLIFF 1.2 che con XLIFF 2.0.
Come tradurre XLIFF senza rovinare i tag: guida passo passo
- Vai su laratranslate.com/translate-xliff
- Carica il tuo file .xliff o .xlf
- Scegli la lingua di partenza e quella di arrivo
- Crea un glossario per i nomi dei brand e i termini non traducibili
- Scegli uno stile di traduzione e clicca su Translate
- Scarica il file ed esegui un controllo dell’integrità dei tag prima di reimportarlo
Come verificare l’integrità dei tag dopo la traduzione
Anche se usi uno strumento che rispetta il formato, esegui una convalida prima di importare il file. In Trados o memoQ, usa il controllo qualità integrato per confrontare il numero di tag inline tra i segmenti di partenza e di arrivo: entrambi gli strumenti segnalano automaticamente i tag mancanti o in eccesso.
Se lavori in un ambiente di sviluppo, prima di importare il file XLIFF, eseguilo con un validatore XML. Per i progetti Angular, se esegui ng build dopo l’importazione, eventuali errori a livello di stringa verranno subito evidenziati.
Controlli principali: il numero di tag nel testo di partenza e in quello di arrivo deve corrispondere, gli ID dei tag non devono cambiare e nel testo di arrivo non devono esserci caratteri speciali XML (&, <, >) non escapati.
Smetti di preoccuparti dei tag XLIFF danneggiati
Carica il tuo file XLIFF su Lara e ricevi una traduzione strutturalmente valida e con tag intatti, pronta da importare in Trados, Xcode o Angular senza bisogno di pulizie.
FAQ
Cosa succede se nella traduzione manca un tag XLIFF?
Nella maggior parte dei casi, se manca un tag placeholder, la variabile viene visualizzata come vuota o come testo letterale in fase di esecuzione. Se manca un tag strutturale, la formattazione potrebbe andare persa. In framework più rigidi come Xcode o Angular, una mancata corrispondenza dei tag può causare un errore di compilazione o un errore di importazione.
Un traduttore umano può rompere per sbaglio i tag XLIFF?
Sì, soprattutto se lavora in un editor di testo semplice o in un ambiente che non mostra i tag inline come elementi bloccati. I CAT tool professionali proteggono da questo problema bloccando gli elementi inline. Lara applica automaticamente la stessa protezione nel suo processore online.
Qual è la differenza tra la gestione dei tag in XLIFF 1.2 e 2.0?
XLIFF 1.2 usa <x>, <g>, <bpt>, <ept> e <it> per il contenuto inline. XLIFF 2.0 usa un modello più semplice con <ph> (segnaposto), <pc> (contenuto accoppiato) e <sc>/<ec> (inizio/fine). Entrambi devono essere preservati con la stessa cura. Lara gestisce entrambe le versioni.
Posso usare Lara se il mio file XLIFF ha estensioni di namespace personalizzate?
Sì. Lara conserva tutto il contenuto XML al di fuori dei nodi source/target di <trans-unit>. Gli attributi di namespace personalizzati e le estensioni specifiche dello strumento nell’intestazione del file o nei metadati delle trans-unit vengono mantenuti invariati.
C’è un modo per verificare l’integrità dei tag XLIFF senza un CAT tool?
Sì. Qualsiasi validatore XML confermerà se il file è ben formato. Per la convalida specifica di XLIFF, strumenti open source come XLIFF Checker di Maxprograms possono verificare la corrispondenza dei tag tra i segmenti di partenza e di arrivo.
In questo articolo parliamo di:
- Spiegare perché i tag inline di XLIFF si rompono quando vengono elaborati da strumenti che non comprendono la struttura XML.
- Identificare i quattro errori più comuni nei tag XLIFF: placeholder mancanti, tag riordinati, contenuto dei tag tradotto e malformazione XML.
- Mostrare come si presenta la corretta gestione dei tag XLIFF sia negli elementi trans-unit di partenza che in quelli di arrivo.
- Spiegare come Lara Translate conserva automaticamente i tag inline e come convalidare l’output prima di reimportarlo.
- Aiutare sviluppatori e responsabili della localizzazione a evitare gli errori silenziosi causati da una struttura XLIFF danneggiata.
Traduci file XLIFF mantenendo l’integrità dei tag
Carica il tuo file .xliff o .xlf su laratranslate.com/translate-xliff e ottieni una traduzione in cui ogni tag, ID ed elemento strutturale è esattamente dove dovrebbe essere.
Anche in questa serie:
