Cum să traduci fișiere XLIFF (Drupal, Symfony, Angular, iOS)
O dezvoltatoare Drupal a postat săptămâna trecută pe Stack Overflow o poveste care se repetă de mii de ori pe an în echipele de localizare din întreprinderi. Echipa ei a exportat un fișier XLIFF de 40MB de pe site-ul lor Drupal. L-a deschis într-un editor de text, a lipit fragmente în Google Translate, a reasamblat fișierul, l-a importat înapoi în Drupal – și jumătate dintre pagini au refuzat să se randeze, deoarece șirurile traduse conțineau XML deformat, caractere de escape în locuri greșite și etichete <g> stricate, unde formatarea inline fusese distrusă.
XLIFF este standardul de localizare pentru întreprinderi dintr-un motiv. Se bazează pe XML, este independent de instrumente și suportă metadatele bogate de care proiectele serioase de traducere au nevoie: stări de traducere, traduceri alternative, note între traducători și dezvoltatori și marcaj inline structurat. Dar tocmai flexibilitatea sa îl face ușor de corupt, iar instrumentele care gestionează fișierele .po în siguranță adesea cedează în cazul XLIFF.
Acest ghid detaliază ce face XLIFF distinct, de ce abordările generice de traducere îl strică și care este modul corect de a traduce fișiere XLIFF pentru Drupal, Symfony, Angular și iOS – cele patru platforme unde XLIFF este cel mai frecvent utilizat în 2026.
Ce este XLIFF (și de ce îl folosesc echipele de întreprindere)
XLIFF înseamnă XML Localization Interchange File Format. Este un standard OASIS conceput special pentru mutarea conținutului de traducere între instrumente – sisteme de gestionare a conținutului, baze de date de memorii de traducere, instrumente CAT și platforme de localizare. Spre deosebire de fișierele Gettext .po (care stochează perechi cheie-valoare plate) sau fișierele locale JSON (care se imbrică arbitrar), XLIFF este un document XML structurat cu o schemă standardizată.
XLIFF 1.2 vs XLIFF 2.0
Există două versiuni în uz, și nu sunt pe deplin compatibile.
XLIFF 1.2 este versiunea mai veche, mai larg implementată. Utilizează elementele <trans-unit> pentru a încadra conținutul traductibil, cu elemente copil <source> și <target>. Formatarea inline utilizează etichete pereche <g>, <x> și <bpt> / <ept>. Instrumentul de gestionare a traducerilor al Drupal și multe platforme mai vechi încă exportă 1.2.
XLIFF 2.0 este revizuirea din 2014, mai simplă și mai curată. Utilizează <unit> și <segment> cu <source> și <target>. Marcajul inline utilizează <pc> (cod pereche) și <ph> (placeholder). Componenta de traducere a Symfony și exporturile moderne iOS folosesc implicit 2.0.
Un instrument de traducere care gestionează 1.2 nu gestionează automat 2.0. Vocabularul de etichete este diferit, iar regulile de escapare diferă ușor. Verificați întotdeauna ce versiune exportă platforma dvs. înainte de a alege un flux de traducere.
Anatomia unei unități XLIFF
O unitate de traducere XLIFF 1.2 minimală arată astfel:
<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>
Eticheta <g id="1"> încadrează o variabilă placeholder. Atributul state îi spune platformei că acest șir necesită traducere. Eticheta <note> este un indiciu pentru dezvoltator. Un traducător care înțelege XLIFF ar trebui să producă:
<target state="translated">¡Bienvenido, <g id="1">%name%</g>!</target>
Un traducător care tratează fișierul ca text simplu ar putea produce oricare dintre aceste variante stricate:
<target>¡Bienvenido, <g id="1">%nombre%</g>!</target>
<target>¡Bienvenido, <g id="1">%name%</g>!</target>
<target>¡Bienvenido, %name%!</target>
Fiecare dintre acestea strică importul în mod diferit. Primul redenumește variabila. Al doilea scapează XML-ul. Al treilea elimină complet eticheta de formatare.
Soluții greșite (De ce nu poți traduce pur și simplu XML)
Majoritatea echipelor încep cu aceleași trei abordări și pierd câteva zile înainte de a renunța.
Alimentarea XLIFF către o inteligență artificială generică
Copiați fișierul, lipiți-l în Claude sau ChatGPT, cereți traducerea. Modelul face de obicei o treabă rezonabilă cu textul, dar tratează etichetele XLIFF inconsecvent. Uneori păstrează etichetele <g>, alteori traduce atributul id, alteori le elimină complet. Validarea eșuează. Importul dvs. generează erori de parsare XML.
Utilizarea unui instrument CAT fără suport XLIFF
Instrumente precum Poedit sunt construite pentru formatul .po. Pot deschide XLIFF, dar îl tratează ca un container de text generic. Etichetele inline nu sunt blocate. Placeholder-urile nu sunt protejate. Obțineți o traducere care arată bine în editor, dar care eșuează la validarea schemei la import.
Scrierea unui script personalizat
Echipa dvs. scrie un script Node sau Python care parsează XLIFF cu xml2js, extrage șirurile sursă, apelează Google Translate și scrie înapoi țintele. Funcționează pentru 90% dintre șiruri. Celelalte 10% – șiruri cu formatare imbricată, grupuri de plural sau caractere speciale – se strică în moduri care apar doar după ce ați lansat deja.
Același mod de eșec „format flexibil întâlnește traducător naiv” afectează fișierele i18next JSON și Gettext .po. Ghidul nostru despre traducerea fișierelor i18next JSON pentru React și Next.js și postarea noastră despre cum să traduci fișiere .po fără a strica variabilele de cod acoperă problemele paralele pentru aceste formate.
Modul corect: Procesare XLIFF conștientă de sintaxă
Un flux de traducere XLIFF adecvat urmează aceleași principii ca motorul nostru PO, adaptate pentru XML.
Parsează, nu folosi Regex
Tratați XLIFF ca un document structurat. Parsează-l cu un parser XML real, construiește un arbore și parcurge elementele <trans-unit> (sau <unit> pentru 2.0). Încercarea de a potrivi conținutul sursă și țintă cu regex este calea rapidă către fișiere corupte.
Blochează etichetele inline înainte de traducere
Fiecare <g>, <x>, <bpt>, <ept>, <ph>, <pc> din interiorul unui <source> trebuie păstrat după poziție și atributul id. Înlocuiește-le cu placeholder-uri numerice înainte de a trimite textul către LLM, apoi reintroduce etichetele originale cu atributele lor după ce traducerea este returnată.
Respectă mașina de stări
Unitățile XLIFF au atribute de stare: new, needs-translation, translated, reviewed, final, signed-off. Un flux ar trebui să traducă doar unități în starea new sau needs-translation și să seteze starea de ieșire la translated (nu final – un revizor ar trebui să verifice în continuare).
Păstrează structura dincolo de unitățile de traducere
Fișierele XLIFF conțin antete, metadate, atribute la nivel de fișier, note și traduceri alternative (<alt-trans>). Acestea trebuie să rămână neschimbate pe parcursul ciclului de import-export. Eliminarea sau reordonarea lor strică compatibilitatea bidirecțională cu platforma sursă.
Validează înainte de livrare
Înainte de a returna XLIFF-ul tradus, validează-l conform schemei. XLIFF 1.2 are un XSD oficial. XLIFF 2.0 are propriul său. Un instrument care nu se poate auto-valida este un instrument care îți va livra fișiere stricate.
Note specifice platformei
Fiecare platformă majoră care utilizează XLIFF are particularități demne de știut.
Drupal
Instrumentul de gestionare a traducerilor (TMGMT) al Drupal exportă XLIFF 1.2. Tipurile de conținut includ noduri (pagini, articole), termeni de taxonomie și configurație. TMGMT încadrează fiecare câmp traductibil într-o <trans-unit> separată, cu un format de ID specific Drupal (fieldname:delta:format).
Atenție: Drupal stochează informații despre formatul textului (HTML filtrat, HTML complet, text simplu) alături de conținut. Traducerea trebuie să păstreze marcajul HTML atunci când formatul permite acest lucru, și să-l transforme în text simplu atunci când formatul nu permite. Fluxul dvs. are nevoie de conștientizare per-câmp.
Symfony
Componenta de traducere a Symfony utilizează XLIFF 2.0 implicit (începând cu Symfony 4). Șirurile se găsesc în translations/messages.xx.xliff. Symfony suportă formatul de mesaj ICU în interiorul XLIFF, ceea ce înseamnă că o singură unitate poate conține structuri precum {count, plural, one {...} other {...}}.
Atenție: Categoriile de plural ICU din interiorul XLIFF necesită protecție dublă. Etichetele XML rămân intacte, ȘI cuvintele cheie ICU (plural, one, other, =0) nu trebuie traduse. Multe instrumente XLIFF gestionează un strat, dar nu pe ambele.
Angular i18n
Angular exportă XLIFF 1.2 sau 2.0 prin comanda ng extract-i18n. Fișierele conțin șiruri de șabloane de componente, cu etichete <x> reprezentând expresii și interpolări Angular precum {{ count }}.
Atenție: Angular utilizează coliziuni de hash id pentru șiruri sursă identice. O traducere trebuie să mențină ID-urile unităților exact așa cum sunt, altfel Angular nu le poate potrivi la import. Redenumirea atributelor id în timpul procesării este o cauză imediată de eroare.
iOS (Export Xcode)
Xcode exportă XLIFF 1.2 pentru localizarea aplicațiilor prin Product > Export Localizations. Șirurile provin din Localizable.strings, intrări Info.plist, storyboard-uri și XIB-uri. Regulile de plural iOS se găsesc în fișierele .stringsdict exportate ca unități de traducere suplimentare.
Atenție: Șirurile storyboard-urilor iOS fac referire la ID-uri de elemente UI. Acestea nu trebuie modificate. De asemenea, Xcode solicită ca atributul target-language să se potrivească exact cu formatul de limbă așteptat (es, nu es-ES, în anumite contexte), altfel ignoră importul în mod silențios.
Traducerea XLIFF cu SimplePoTranslate
SimplePoTranslate suportă XLIFF pe planurile Pro și Lifetime. Fluxul de lucru este același ca pentru fișierele .po.
1. Exportă-ți fișierul XLIFF
Din platforma sursă, exportați unul sau mai multe fișiere .xliff. Pentru Drupal, utilizați acțiunea de export a TMGMT. Pentru Symfony, găsiți translations/messages.en.xliff. Pentru Angular, rulați ng extract-i18n --format=xlf2. Pentru Xcode, utilizați exportul de localizare.
2. Încarcă în SimplePoTranslate
Trageți fișierul în tabloul de bord. Platforma detectează automat versiunea XLIFF (1.2 sau 2.0), parsează structura și identifică unitățile traductibile. Alegeți limba țintă și tonul.
3. Traducere conștientă de sintaxă
Etichetele inline, parametrii ICU, placeholder-urile și ID-urile unităților sunt blocate înainte de traducere. Motorul AI subiacent vede doar text curat cu context. Textul tradus este reinserat în structura originală exactă, stările sunt actualizate, iar fișierul este validat conform schemei XLIFF înainte de livrare.
4. Descarcă și importă
Descarcă fișierul XLIFF tradus (plus echivalentele .po, .json și .php dacă ai nevoie de compatibilitate cross-platform). Importă-l în platforma sursă. Validează prin randarea câtorva pagini sau vizualizări traduse înainte de a lansa.
# 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. Integrează în CI
Odată ce ai încredere în fluxul de lucru, automatizează-l. Exportă XLIFF la fiecare lansare, trimite prin API, descarcă fișierele traduse, comite în depozitul Git, implementează. Acesta este același model prietenos cu CI pe care multe agenții îl utilizează pentru traducerea fișierelor .po pentru WordPress – vezi postarea noastră despre traducerea în cloud fără site-uri stricate pentru modelul arhitectural.
Pe scurt
XLIFF este instrumentul potrivit pentru munca serioasă de localizare – structurat, independent de instrumente și suficient de bogat pentru a transporta metadatele proiectului între sisteme. Dar structura sa XML este, de asemenea, fragilă. Fiecare etichetă, atribut și valoare de stare are greutate semantică, iar un traducător care nu înțelege XLIFF ca format va corupe fișierul în moduri care s-ar putea să nu iasă la iveală până când importul eșuează sau un utilizator raportează o interfață cu utilizatorul defectă.
Abordarea sigură este cea conștientă de sintaxă: analizează XML-ul, blochează elementele structurale, traduce doar suprafețele de text cu context, validează conform schemei înainte de livrare. Acest lucru este valabil indiferent dacă livrezi un site Drupal, un API Symfony, o aplicație SPA Angular sau o aplicație iOS. Platforma diferă, dar disciplina XLIFF nu.
Ești gata să traduci fișiere XLIFF pentru Drupal, Symfony, Angular sau iOS fără etichete stricate? Încearcă SimplePoTranslate gratuit – nu este necesar un card de credit. Încarcă
.xliff, descarcă traduceri sigure, importă-le în platforma ta.