Come Tradurre File XLIFF (Drupal, Symfony, Angular, iOS)
La scorsa settimana, uno sviluppatore Drupal ha pubblicato su Stack Overflow una storia che si ripete migliaia di volte all'anno tra i team di localizzazione aziendali. Il suo team ha esportato un file XLIFF da 40MB dal proprio sito Drupal. L'ha aperto in un editor di testo, ha incollato dei frammenti in Google Translate, ha riassemblato il file, l'ha reimportato in Drupal e metà delle pagine si sono rifiutate di essere renderizzate perché le stringhe tradotte contenevano XML malformato, caratteri di escape nei posti sbagliati e tag <g> rotti dove la formattazione inline era stata distrutta.
XLIFF è lo standard di localizzazione aziendale per una ragione. È basato su XML, agnostico rispetto agli strumenti e supporta i ricchi metadati di cui i progetti di traduzione seri hanno bisogno: stati di traduzione, traduzioni alternative, note tra traduttori e sviluppatori e markup inline strutturato. Ma la sua stessa flessibilità lo rende facile da corrompere, e gli strumenti che gestiscono in modo sicuro i file .po spesso si bloccano con XLIFF.
Questa guida illustra cosa rende XLIFF distinto, perché gli approcci di traduzione generici lo rompono e il modo giusto per tradurre i file XLIFF per Drupal, Symfony, Angular e iOS, le quattro piattaforme dove XLIFF è più comunemente usato nel 2026.
Cos'è XLIFF (e perché i team aziendali lo usano)
XLIFF sta per XML Localization Interchange File Format. È uno standard OASIS progettato specificamente per spostare contenuti di traduzione tra strumenti: sistemi di gestione dei contenuti, database di memorie di traduzione, strumenti CAT e piattaforme di localizzazione. A differenza dei file .po di Gettext (che memorizzano coppie chiave-valore piatte) o dei file di lingua JSON (che si annidano arbitrariamente), XLIFF è un documento XML strutturato con uno schema standardizzato.
XLIFF 1.2 vs XLIFF 2.0
Esistono due versioni, e non sono completamente compatibili.
XLIFF 1.2 è la versione più vecchia e più diffusa. Utilizza elementi <trans-unit> per racchiudere il contenuto traducibile, con figli <source> e <target>. La formattazione inline utilizza i tag accoppiati <g>, <x> e <bpt> / <ept>. Lo Strumento di Gestione della Traduzione di Drupal e molte piattaforme più vecchie esportano ancora la versione 1.2.
XLIFF 2.0 è la revisione del 2014, più semplice e pulita. Utilizza <unit> e <segment> con <source> e <target>. Il markup inline utilizza <pc> (codice accoppiato) e <ph> (segnaposto). Il componente traduttore di Symfony e le esportazioni moderne di iOS sono predefinite alla versione 2.0.
Uno strumento di traduzione che gestisce la versione 1.2 non gestisce automaticamente la 2.0. I vocabolari dei tag sono diversi e le regole di escape differiscono leggermente. Controlla sempre quale versione la tua piattaforma esporta prima di scegliere una pipeline di traduzione.
L'Anatomia di un'Unità XLIFF
Un'unità trans-unit XLIFF 1.2 minima si presenta così:
<trans-unit id="msg_welcome" datatype="plaintext">
<source>Welcome, <g id="1">%name%</g>!</source>
<target state="needs-translation">Welcome, <g id="1">%name%</g>!</target>
<note>Displayed on the homepage after login</note>
</trans-unit>
Il tag <g id="1"> racchiude una variabile segnaposto. L'attributo state indica alla piattaforma che questa stringa necessita di traduzione. Il tag <note> è un suggerimento per lo sviluppatore. Un traduttore che comprende XLIFF dovrebbe produrre:
<target state="translated">¡Bienvenido, <g id="1">%name%</g>!</target>
Un traduttore che tratta il file come testo semplice potrebbe produrre una qualsiasi di queste varianti errate:
<target>¡Bienvenido, <g id="1">%nombre%</g>!</target>
<target>¡Bienvenido, <g id="1">%name%</g>!</target>
<target>¡Bienvenido, %name%!</target>
Ognuno di questi rompe l'importazione in modo diverso. Il primo rinomina la variabile. Il secondo escapa l'XML. Il terzo elimina completamente il tag di formattazione.
Soluzioni Errate (Perché Non Puoi Semplicemente Tradurre XML)
La maggior parte dei team inizia con gli stessi tre approcci e spreca diversi giorni prima di arrendersi.
Dare XLIFF in pasto a un'IA Generica
Copia il file, incollalo in Claude o ChatGPT, chiedi la traduzione. Il modello di solito fa un lavoro ragionevole con il testo, ma tratta i tag XLIFF in modo incoerente. A volte preserva i tag <g>, a volte traduce l'attributo id, a volte li elimina completamente. La validazione fallisce. La tua importazione genera errori di parsing XML.
Utilizzare uno Strumento CAT Senza Supporto XLIFF
Strumenti come Poedit sono costruiti per il formato .po. Possono aprire XLIFF ma lo trattano come un contenitore di testo generico. I tag inline non sono bloccati. I segnaposto non sono protetti. Ottieni una traduzione che sembra corretta nell'editor ma fallisce la validazione dello schema all'importazione.
Scrivere uno Script Personalizzato
Il tuo team scrive uno script Node o Python che analizza XLIFF con xml2js, estrae le stringhe sorgente, chiama Google Translate e riscrive le destinazioni. Funziona per il 90% delle stringhe. L'altro 10% – stringhe con formattazione nidificata, gruppi plurali o caratteri speciali – si rompono in modi che si manifestano solo dopo che hai già rilasciato il prodotto.
La stessa modalità di fallimento "formato flessibile incontra traduttore ingenuo" affligge i file i18next JSON e Gettext .po. La nostra guida su come tradurre file JSON i18next per React e Next.js e il nostro post su come tradurre file .po senza rompere le variabili di codice coprono i problemi paralleli per questi formati.
Il Modo Giusto: Elaborazione XLIFF Sensibile alla Sintassi
Una pipeline di traduzione XLIFF corretta segue gli stessi principi del nostro motore PO, adattati per XML.
Parsa, Non Usare Regex
Tratta XLIFF come un documento strutturato. Parsalo con un vero parser XML, costruisci un albero e attraversa gli elementi <trans-unit> (o <unit> per la versione 2.0). Tentare di abbinare il contenuto sorgente e di destinazione con espressioni regolari è la via più veloce per corrompere i file.
Bloccare i Tag Inline Prima della Traduzione
Ogni tag <g>, <x>, <bpt>, <ept>, <ph>, <pc> all'interno di un <source> deve essere preservato per posizione e attributo id. Sostituiscili con segnaposto numerici prima di inviare il testo all'LLM, quindi reinserisci i tag originali con i loro attributi dopo che la traduzione è stata completata.
Rispettare la Macchina a Stati
Le unità XLIFF hanno attributi di stato: new, needs-translation, translated, reviewed, final, signed-off. Una pipeline dovrebbe tradurre solo le unità nello stato new o needs-translation e impostare lo stato di output su translated (non final - un revisore dovrebbe comunque verificare).
Preservare la Struttura Oltre le Unità di Traduzione
I file XLIFF contengono intestazioni, metadati, attributi a livello di file, note e traduzioni alternative (<alt-trans>). Questi devono rimanere invariati durante il ciclo di round trip. Rimuoverli o riordinarli interrompe la compatibilità di round trip con la piattaforma sorgente.
Convalidare Prima della Consegna
Prima di restituire XLIFF tradotto, convalidarlo rispetto allo schema. XLIFF 1.2 ha un XSD ufficiale. XLIFF 2.0 ha il suo. Uno strumento che non può auto-convalidarsi è uno strumento che ti consegnerà file corrotti.
Note Specifiche della Piattaforma
Ogni piattaforma principale che utilizza XLIFF ha peculiarità che vale la pena conoscere.
Drupal
Lo Strumento di Gestione della Traduzione (TMGMT) di Drupal esporta XLIFF 1.2. I tipi di contenuto includono nodi (pagine, articoli), termini di tassonomia e configurazione. TMGMT racchiude ogni campo traducibile in un <trans-unit> separato con un formato ID specifico di Drupal (fieldname:delta:format).
Attenzione: Drupal memorizza le informazioni sul formato del testo (HTML filtrato, HTML completo, testo semplice) insieme al contenuto. La traduzione deve preservare il markup HTML quando il formato lo consente, e rimuoverlo per renderlo testo semplice quando il formato non lo consente. La tua pipeline necessita di una consapevolezza campo per campo.
Symfony
Il componente di traduzione di Symfony utilizza XLIFF 2.0 per impostazione predefinita (da Symfony 4). Le stringhe si trovano in translations/messages.xx.xliff. Symfony supporta il formato di messaggio ICU all'interno di XLIFF, il che significa che una singola unità può contenere strutture {count, plural, one {...} other {...}}.
Attenzione: le categorie plurali ICU all'interno di XLIFF necessitano di doppia protezione. I tag XML rimangono intatti, E le parole chiave ICU (plural, one, other, =0) non devono essere tradotte. Molti strumenti XLIFF gestiscono un solo livello ma non entrambi.
Angular i18n
Angular esporta XLIFF 1.2 o 2.0 tramite il comando ng extract-i18n. I file contengono stringhe di template di componenti, con tag <x> che rappresentano espressioni e interpolazioni Angular come {{ count }}.
Attenzione: Angular utilizza collisioni di hash id tra stringhe sorgente identiche. Una traduzione deve mantenere gli ID delle unità esattamente o Angular non potrà abbinarli all'importazione. Ridenominare gli attributi id durante l'elaborazione è una rottura immediata.
iOS (Esportazione Xcode)
Xcode esporta XLIFF 1.2 per la localizzazione delle app tramite Product > Export Localizations. Le stringhe provengono da Localizable.strings, voci Info.plist, storyboard e XIB. Le regole plurali di iOS si trovano nei file .stringsdict esportati come unità di traduzione aggiuntive.
Attenzione: le stringhe degli storyboard di iOS fanno riferimento agli ID degli elementi UI. Questi non devono essere alterati. Inoltre, Xcode richiede che l'attributo target-language corrisponda esattamente al formato di locale atteso (es, non es-ES, in alcuni contesti) o ignora silenziosamente l'importazione.
Tradurre XLIFF con SimplePoTranslate
SimplePoTranslate supporta XLIFF sui piani Pro e Lifetime. Il flusso di lavoro è lo stesso che per i file .po.
1. Esporta il tuo XLIFF
Dalla tua piattaforma sorgente, esporta uno o più file .xliff. Per Drupal, usa l'azione di esportazione di TMGMT. Per Symfony, trova translations/messages.en.xliff. Per Angular, esegui ng extract-i18n --format=xlf2. Per Xcode, usa l'esportazione di localizzazione.
2. Carica su SimplePoTranslate
Trascina il file nella dashboard. La piattaforma rileva automaticamente la versione XLIFF (1.2 o 2.0), analizza la struttura e identifica le unità traducibili. Scegli la tua lingua target e il tono.
3. Traduzione Sensibile alla Sintassi
Tag inline, parametri ICU, segnaposto e ID unità vengono bloccati prima della traduzione. Il motore AI sottostante vede solo testo pulito con contesto. Il testo tradotto viene reinserito nella struttura originale esatta, gli stati vengono aggiornati e il file viene convalidato rispetto allo schema XLIFF prima della consegna.
4. Scarica e Importa
Scarica l'XLIFF tradotto (più gli equivalenti .po, .json e .php se hai bisogno di multi-piattaforma). Importa nella tua piattaforma sorgente. Convalida renderizzando alcune pagine o viste tradotte prima del lancio.
# Angular example
ng extract-i18n --format=xlf2 --output-path=src/locale
# upload src/locale/messages.xlf to SimplePoTranslate
# download messages.es.xlf
# reference in angular.json i18n configuration
ng build --localize
5. Integra nella CI
Una volta che ti fidi della pipeline, automatizzala. Esporta XLIFF ad ogni rilascio, invia tramite API, scarica i file tradotti, effettua il commit nel repository, distribuisci. Questo è lo stesso modello CI-friendly che molte agenzie usano per la traduzione WordPress .po - vedi il nostro post su traduzione basata su cloud senza siti rotti per il modello architetturale.
Mettendo Tutto Insieme
XLIFF è lo strumento giusto per un serio lavoro di localizzazione – strutturato, agnostico rispetto agli strumenti e abbastanza ricco da trasportare i metadati di progetto tra i sistemi. Ma la sua struttura XML è anche fragile. Ogni tag, attributo e valore di stato ha un peso semantico, e un traduttore che non comprende XLIFF come formato corromperà il tuo file in modi che potrebbero non emergere finché l'importazione non fallisce o un utente segnala un'interfaccia utente rotta.
L'approccio sicuro è sensibile alla sintassi: analizzare l'XML, bloccare gli elementi strutturali, tradurre solo le superfici testuali con contesto, convalidare rispetto allo schema prima della consegna. Questo è vero sia che tu stia rilasciando un sito Drupal, un'API Symfony, una SPA Angular o un'app iOS. La piattaforma differisce, ma la disciplina XLIFF no.
Pronto a tradurre file XLIFF per Drupal, Symfony, Angular o iOS senza tag rotti? Prova SimplePoTranslate gratuitamente - nessuna carta di credito richiesta. Carica
.xliff, scarica traduzioni sicure, importa nella tua piattaforma.