Hogyan fordítsunk XLIFF fájlokat (Drupal, Symfony, Angular, iOS)

Egy Drupal fejlesztő a múlt héten a Stack Overflow-n posztolt egy történetet, ami évente több ezerszer is megismétlődik a vállalati lokalizációs csapatoknál. Csapata egy 40 MB-os XLIFF fájlt exportált a Drupal oldalukról. Megnyitotta egy szövegszerkesztőben, részeket beillesztett a Google Translate-be, újra összeállította a fájlt, majd visszimportálta a Drupalba – és az oldalak fele nem volt hajlandó renderelni, mert a lefordított szövegek rosszul formázott XML-t, rossz helyen lévő escape karaktereket és törött <g> címkéket tartalmaztak, ahol az inline formázás megsemmisült.
Az XLIFF nem véletlenül a vállalati lokalizációs szabvány. XML-alapú, eszköztől független, és támogatja azt a gazdag metaadatot, amire a komoly fordítási projekteknek szüksége van: fordítási állapotok, alternatív fordítások, jegyzetek a fordítók és fejlesztők között, valamint strukturált inline jelölés. De éppen a rugalmassága miatt könnyű megsérteni, és azok az eszközök, amelyek biztonságosan kezelik a .po fájlokat, gyakran elvéreznek az XLIFF-en.
Ez az útmutató bemutatja, mi teszi az XLIFF-et különlegessé, miért hibáztatják az általános fordítási megközelítések, és mi a helyes módja az XLIFF fájlok fordításának Drupal, Symfony, Angular és iOS rendszerekhez – ez a négy platform, ahol az XLIFF-et a leggyakrabban használják 2026-ban.
Mi az XLIFF (és miért használják a vállalati csapatok)
Az XLIFF az XML Localization Interchange File Format rövidítése. Ez egy OASIS szabvány, amelyet kifejezetten fordítási tartalom eszközök közötti mozgatására terveztek – tartalomkezelő rendszerek, fordítási memória adatbázisok, CAT eszközök és lokalizációs platformok között. A Gettext .po fájloktól (amelyek lapos kulcs-érték párokat tárolnak) vagy a JSON lokál fájloktól (amelyek tetszőlegesen egymásba ágyazódnak) eltérően az XLIFF egy strukturált XML dokumentum szabványos sémával.
XLIFF 1.2 vs XLIFF 2.0
Két verzió létezik a gyakorlatban, és nem teljesen kompatibilisek.
Az XLIFF 1.2 a régebbi, szélesebb körben elterjedt verzió. <trans-unit> elemeket használ a fordítható tartalom köré, <source> és <target> gyermekelemekkel. Az inline formázás <g>, <x>, és <bpt> / <ept> párosított címkéket használ. A Drupal Translation Management Tool és sok régebbi platform még mindig 1.2-t exportál.
Az XLIFF 2.0 a 2014-es felülvizsgálat, egyszerűbb és tisztább. <unit> és <segment> elemeket használ <source> és <target> elemekkel. Az inline jelölés <pc> (páros kód) és <ph> (helyőrző) címkéket használ. A Symfony fordító komponense és a modern iOS exportok alapértelmezetten 2.0-ra állnak.
Egy fordítóeszköz, amely kezeli az 1.2-t, nem kezeli automatikusan a 2.0-t. A címkeszótárak eltérőek, és az escape szabályok is kissé különböznek. Mindig ellenőrizze, melyik verziót exportálja a platformja, mielőtt fordítási folyamatot választ.
Egy XLIFF egység anatómiája
Egy minimális XLIFF 1.2 trans-unit így néz ki:
<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>
A <g id="1"> egy helyőrző változót foglal magában. A state attribútum jelzi a platformnak, hogy ez a szöveg fordításra szorul. A <note> egy fejlesztői tipp. Egy XLIFF-et értő fordítónak a következőt kellene előállítania:
<target state="translated">¡Bienvenido, <g id="1">%name%</g>!</target>
Egy fordító, aki a fájlt egyszerű szövegként kezeli, a következő hibás változatok bármelyikét előállíthatja:
<target>¡Bienvenido, <g id="1">%nombre%</g>!</target>
<target>¡Bienvenido, <g id="1">%name%</g>!</target>
<target>¡Bienvenido, %name%!</target>
Ezek mindegyike másképp rontja el az importálást. Az első átnevezi a változót. A második escape-eli az XML-t. A harmadik teljesen elhagyja a formázó címkét.
Rossz megoldások (Miért nem fordíthatja le csak úgy az XML-t)
A legtöbb csapat ugyanazokkal a három megközelítéssel indul, és több napot eléget, mielőtt feladja.
XLIFF betáplálása egy általános mesterséges intelligenciába
Másolja a fájlt, illessze be Claude vagy ChatGPT-be, kérjen fordítást. A modell általában elfogadhatóan fordítja le a szöveget, de az XLIFF címkéket következetlenül kezeli. Néha megőrzi a <g> címkéket, néha lefordítja az id attribútumot, néha teljesen eltávolítja őket. Az ellenőrzés sikertelen lesz. Az importálás XML elemzési hibákat dob.
CAT eszköz használata XLIFF támogatás nélkül
Az olyan eszközök, mint a Poedit, a .po formátumra épülnek. Megnyithatják az XLIFF-et, de általános szövegtárolóként kezelik. Az inline címkék nincsenek zárolva. A helyőrzők nincsenek védve. Olyan fordítást kap, amely jól néz ki a szerkesztőben, de az importálás során nem felel meg a séma-ellenőrzésnek.
Egyedi szkript írása
Csapata egy Node vagy Python szkriptet ír, amely xml2js segítségével elemzi az XLIFF-et, kinyeri a forrásszövegeket, meghívja a Google Translate-et, és visszaírja a célnyelvi szövegeket. Ez az esetek 90%-ában működik. A maradék 10% – a beágyazott formázású, többes számú csoportokat vagy speciális karaktereket tartalmazó szövegek – olyan módon törnek el, ami csak a kiadás után derül ki.
Ugyanez a „rugalmas formátum naiv fordítóval találkozik” hibamód érinti az i18next JSON és a Gettext .po fájlokat. Útmutatónk az i18next JSON fájlok fordításáról React és Next.js rendszerekhez, valamint bejegyzésünk arról, hogyan fordítsunk .po fájlokat a kódváltozók megsértése nélkül lefedi az ezekre a formátumokra vonatkozó párhuzamos problémákat.
A helyes út: Szintaxis-tudatos XLIFF feldolgozás
Egy megfelelő XLIFF fordítási folyamat ugyanazokat az elveket követi, mint a PO motorunk, XML-re adaptálva.
Elemzés, ne reguláris kifejezésekkel
Kezelje az XLIFF-et strukturált dokumentumként. Elemezze egy valódi XML elemzővel, építsen belőle fát, és járja be a <trans-unit> (vagy 2.0 esetén <unit>) elemeket. A forrás- és céltartalom reguláris kifejezésekkel való párosítása a sérült fájlokhoz vezető gyors út.
Inline címkék zárolása fordítás előtt
Minden <g>, <x>, <bpt>, <ept>, <ph>, <pc> elemnek egy <source> elemen belül meg kell őriznie a pozícióját és az id attribútumát. Helyettesítse őket numerikus helyőrzőkkel, mielőtt szöveget küld az LLM-nek, majd helyezze vissza az eredeti címkéket attribútumaikkal a fordítás befejezése után.
Tisztelje az állapotgépet
Az XLIFF egységek állapotattribútumokkal rendelkeznek: new, needs-translation, translated, reviewed, final, signed-off. Egy folyamatnak csak a new vagy needs-translation állapotban lévő egységeket szabad lefordítania, és a kimeneti állapotot translated-re kell állítania (nem final - egy felülvizsgálónak még ellenőriznie kell).
A szerkezet megőrzése a fordítási egységeken túl
Az XLIFF fájlok fejléceket, metaadatokat, fájlszintű attribútumokat, jegyzeteket és alternatív fordításokat (<alt-trans>) tartalmaznak. Ezeknek változatlanul kell túlélniük az oda-vissza utat. Eltávolításuk vagy átrendezésük megsérti az oda-vissza kompatibilitást a forrásplatformmal.
Érvényesítés szállítás előtt
Mielőtt visszaadná a lefordított XLIFF-et, érvényesítse a séma ellen. Az XLIFF 1.2-nek van hivatalos XSD-je. Az XLIFF 2.0-nak sajátja van. Egy eszköz, amely nem tudja önmagát érvényesíteni, olyan eszköz, amely hibás fájlokat fog szállítani Önnek.
Platform-specifikus megjegyzések
Minden nagyobb platform, amely XLIFF-et használ, rendelkezik érdemes tudni illesztési pontokkal.
Drupal
A Drupal Translation Management Tool (TMGMT) XLIFF 1.2-t exportál. A tartalomtípusok közé tartoznak a csomópontok (oldalak, cikkek), taxonómiai kifejezések és konfigurációk. A TMGMT minden fordítható mezőt külön <trans-unit>-be foglal egy Drupal-specifikus ID formátummal (fieldname:delta:format).
Figyelem: A Drupal a szövegformátumra vonatkozó információkat (szűrt HTML, teljes HTML, egyszerű szöveg) tárolja a tartalom mellett. A fordításnak meg kell őriznie a HTML jelölést, ha a formátum engedi, és egyszerű szövegre kell csupaszítania, ha a formátum nem. A folyamatnak mezőnkénti tudatossággal kell rendelkeznie.
Symfony
A Symfony fordítási komponense alapértelmezetten XLIFF 2.0-t használ (a Symfony 4 óta). A szövegek a translations/messages.xx.xliff fájlban találhatók. A Symfony támogatja az ICU üzenetformátumot az XLIFF-en belül, ami azt jelenti, hogy egyetlen egység tartalmazhat {count, plural, one {...} other {...}} struktúrákat.
Figyelem: Az XLIFF-en belüli ICU többes számú kategóriák kettős védelmet igényelnek. Az XML címkék érintetlenek maradnak, ÉS az ICU kulcsszavakat (plural, one, other, =0) nem szabad lefordítani. Sok XLIFF eszköz az egyik réteget kezeli, de mindkettőt nem.
Angular i18n
Az Angular XLIFF 1.2 vagy 2.0 fájlokat exportál az ng extract-i18n paranccsal. A fájlok komponens sablon szövegeket tartalmaznak, <x> címkékkel, amelyek Angular kifejezéseket és interpolációkat képviselnek, mint például {{ count }}.
Figyelem: Az Angular id hash ütközéseket használ az azonos forrásszövegek között. A fordításnak pontosan meg kell őriznie az egység azonosítókat, különben az Angular nem tudja őket párosítani az importáláskor. Az id attribútumok átnevezése a feldolgozás során azonnali hibát okoz.
iOS (Xcode Export)
Az Xcode XLIFF 1.2 fájlokat exportál az alkalmazás lokalizációjához a Product > Export Localizations menüponton keresztül. A szövegek a Localizable.strings, Info.plist bejegyzésekből, storyboardokból és XIB-ekből származnak. Az iOS többes számú szabályai .stringsdict fájlokban találhatók, amelyeket további trans-unit-ként exportálnak.
Figyelem: Az iOS storyboard szövegek UI elem azonosítókra hivatkoznak. Ezeket nem szabad megváltoztatni. Ezenkívül az Xcode megköveteli, hogy a target-language attribútum pontosan egyezzen a várt lokále formátumával (es, nem es-ES, bizonyos kontextusokban), különben némán figyelmen kívül hagyja az importálást.
XLIFF fordítása a SimplePoTranslate-tel
A SimplePoTranslate támogatja az XLIFF-et Pro és Lifetime csomagokon. A munkafolyamat megegyezik a .po fájlokéval.
1. Exportálja az XLIFF fájlját
A forrásplatformról exportáljon egy vagy több .xliff fájlt. Drupal esetén használja a TMGMT export funkcióját. Symfony esetén keresse meg a translations/messages.en.xliff fájlt. Angular esetén futtassa az ng extract-i18n --format=xlf2 parancsot. Xcode esetén használja a Lokalizáció exportálást.
2. Feltöltés a SimplePoTranslate-re
Húzza a fájlt az irányítópultba. A platform automatikusan felismeri az XLIFF verziót (1.2 vagy 2.0), elemzi a struktúrát és azonosítja a fordítható egységeket. Válassza ki a célnyelvet és a hangnemet.
3. Szintaxis-tudatos fordítás
Az inline címkék, ICU paraméterek, helyőrzők és egység azonosítók zárolva vannak a fordítás előtt. Az alapul szolgáló AI motor csak tiszta szöveget lát, kontextussal. A lefordított szöveg az eredeti struktúrába kerül visszaillesztésre, az állapotok frissülnek, és a fájl ellenőrzésre kerül az XLIFF séma ellen szállítás előtt.
4. Letöltés és importálás
Töltse le a lefordított XLIFF-et (valamint a .po, .json és .php megfelelőit, ha platformfüggetlen megoldásra van szüksége). Importálja a forrásplatformjába. Ellenőrizze néhány lefordított oldal vagy nézet renderelésével a bevezetés előtt.
# 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. Integráció a CI-be
Amint megbízik a folyamatban, automatizálja. Exportáljon XLIFF-et minden kiadáskor, küldje be API-n keresztül, töltse le a lefordított fájlokat, commit-elje a repo-ba, telepítse. Ez ugyanaz a CI-barát minta, amelyet sok ügynökség használ a WordPress .po fordításához – lásd a bejegyzésünket a felhőalapú fordításról törött oldalak nélkül az építészeti mintáért.
Összefoglalás
Az XLIFF a megfelelő eszköz a komoly lokalizációs munkához – strukturált, eszköztől független, és elég gazdag ahhoz, hogy projekt metaadatokat hordozzon rendszerek között. Azonban az XML struktúrája is törékeny. Minden címke, attribútum és állapotérték szemantikai súllyal bír, és egy fordító, aki nem érti az XLIFF-et mint formátumot, olyan módon fogja megsérteni a fájlját, ami csak akkor derül ki, ha az importálás sikertelen, vagy egy felhasználó hibás UI-t jelent.
A biztonságos megközelítés szintaxis-tudatos: elemezze az XML-t, zárolja a strukturális elemeket, csak a szövegfelületeket fordítsa kontextussal, érvényesítse a séma ellen szállítás előtt. Ez igaz, függetlenül attól, hogy Drupal oldalt, Symfony API-t, Angular SPA-t vagy iOS alkalmazást szállít. A platform eltér, de az XLIFF fegyelem nem.
Készen áll XLIFF fájlok fordítására Drupal, Symfony, Angular vagy iOS rendszerekhez törött címkék nélkül? Próbálja ki a SimplePoTranslate-et ingyenesen – nincs szükség bankkártyára. Töltsön fel
.xlifffájlt, töltsön le biztonságos fordításokat, importálja a platformjába.