Jak tłumaczyć pliki XLIFF (Drupal, Symfony, Angular, iOS)
Deweloperka Drupal opublikowała w zeszłym tygodniu na Stack Overflow historię, która powtarza się tysiące razy rocznie w zespołach lokalizacyjnych dużych firm. Jej zespół wyeksportował plik XLIFF o rozmiarze 40MB ze swojej strony Drupal. Otworzyła go w edytorze tekstu, wkleiła fragmenty do Google Translate, ponownie złożyła plik, zaimportowała go z powrotem do Drupal – i połowa stron odmówiła wyświetlenia, ponieważ przetłumaczone ciągi znaków zawierały źle sformułowany XML, nieprawidłowo zakodowane znaki specjalne i uszkodzone tagi <g>, gdzie formatowanie liniowe zostało zniszczone.
XLIFF jest standardem lokalizacji w przedsiębiorstwach nie bez powodu. Jest oparty na XML, niezależny od narzędzi i wspiera bogate metadane, których potrzebują poważne projekty tłumaczeniowe: stany tłumaczenia, alternatywne tłumaczenia, notatki między tłumaczami a deweloperami oraz ustrukturyzowane znaczniki liniowe. Ale jego elastyczność sprawia, że łatwo go uszkodzić, a narzędzia, które bezpiecznie obsługują pliki .po, często zawodzą w przypadku XLIFF.
Ten przewodnik wyjaśnia, co wyróżnia XLIFF, dlaczego ogólne podejścia do tłumaczenia go niszczą, oraz przedstawia właściwy sposób tłumaczenia plików XLIFF dla Drupal, Symfony, Angular i iOS – czterech platform, na których XLIFF jest najczęściej używany w 2026 roku.
Co to jest XLIFF (i dlaczego używają go zespoły korporacyjne)
XLIFF to skrót od XML Localization Interchange File Format. Jest to standard OASIS zaprojektowany specjalnie do przenoszenia treści tłumaczeniowych między narzędziami – systemami zarządzania treścią, bazami danych pamięci tłumaczeniowych, narzędziami CAT i platformami lokalizacyjnymi. W przeciwieństwie do plików Gettext .po (które przechowują płaskie pary klucz-wartość) lub plików regionalnych JSON (które zagnieżdżają się dowolnie), XLIFF jest ustrukturyzowanym dokumentem XML ze standaryzowanym schematem.
XLIFF 1.2 vs XLIFF 2.0
W obiegu istnieją dwie wersje, które nie są w pełni kompatybilne.
XLIFF 1.2 to starsza, szerzej wdrożona wersja. Używa elementów <trans-unit> do opakowywania treści do przetłumaczenia, z dziećmi <source> i <target>. Formatowanie liniowe wykorzystuje sparowane tagi <g>, <x> oraz <bpt> / <ept>. Narzędzie Translation Management Tool w Drupal i wiele starszych platform nadal eksportuje wersję 1.2.
XLIFF 2.0 to rewizja z 2014 roku, prostsza i czystsza. Używa <unit> i <segment> z <source> i <target>. Znaczniki liniowe używają <pc> (paired code) i <ph> (placeholder). Komponent tłumacza Symfony i nowoczesne eksporty iOS domyślnie używają wersji 2.0.
Narzędzie tłumaczeniowe, które obsługuje wersję 1.2, nie obsługuje automatycznie wersji 2.0. Słowniki tagów są różne, a zasady ucieczki znaków różnią się nieznacznie. Zawsze sprawdzaj, którą wersję eksportuje Twoja platforma, zanim wybierzesz proces tłumaczenia.
Anatomia jednostki XLIFF
Minimalna jednostka tłumaczeniowa XLIFF 1.2 (trans-unit) wygląda tak:
<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>
<g id="1"> otacza zmienną zastępczą. Atrybut state informuje platformę, że ten ciąg znaków wymaga tłumaczenia. <note> to wskazówka dla dewelopera. Tłumacz, który rozumie XLIFF, powinien utworzyć:
<target state="translated">¡Bienvenido, <g id="1">%name%</g>!</target>
Tłumacz, który traktuje plik jako zwykły tekst, może stworzyć jedną z tych uszkodzonych wersji:
<target>¡Bienvenido, <g id="1">%nombre%</g>!</target>
<target>¡Bienvenido, <g id="1">%name%</g>!</target>
<target>¡Bienvenido, %name%!</target>
Każda z nich inaczej psuje import. Pierwsza zmienia nazwę zmiennej. Druga ucieka znaki XML. Trzecia całkowicie usuwa tag formatowania.
Złe rozwiązania (dlaczego nie można po prostu tłumaczyć XML)
Większość zespołów zaczyna od tych samych trzech podejść i marnuje kilka dni, zanim się podda.
Podawanie XLIFF ogólnemu AI
Skopiuj plik, wklej do Claude lub ChatGPT, poproś o tłumaczenie. Model zazwyczaj wykonuje rozsądną pracę z tekstem, ale traktuje tagi XLIFF niespójnie. Czasami zachowuje tagi <g>, czasami tłumaczy atrybut id, czasami całkowicie je usuwa. Walidacja kończy się niepowodzeniem. Twój import wyrzuca błędy parsowania XML.
Używanie narzędzia CAT bez obsługi XLIFF
Narzędzia takie jak Poedit są zbudowane dla formatu .po. Mogą otwierać XLIFF, ale traktują go jako ogólny kontener tekstowy. Tagi liniowe nie są zablokowane. Placeholdery nie są chronione. Otrzymujesz tłumaczenie, które wygląda dobrze w edytorze, ale nie przechodzi walidacji schematu podczas importu.
Pisanie niestandardowego skryptu
Twój zespół pisze skrypt Node lub Python, który parsuje XLIFF za pomocą xml2js, wyodrębnia oryginalne ciągi znaków, wywołuje Google Translate i zapisuje przetłumaczone ciągi z powrotem. Działa dla 90% ciągów. Pozostałe 10% – ciągi z zagnieżdżonym formatowaniem, grupami liczby mnogiej lub znakami specjalnymi – psują się w sposób, który ujawnia się dopiero po wdrożeniu.
Ten sam tryb awarii „elastyczny format spotyka naiwnego tłumacza” dotyczy plików i18next JSON i Gettext .po. Nasz przewodnik na temat tłumaczenia plików i18next JSON dla React i Next.js oraz nasz post na temat jak tłumaczyć pliki .po bez uszkadzania zmiennych kodu omawiają równoległe problemy dla tych formatów.
Właściwy sposób: przetwarzanie XLIFF z uwzględnieniem składni
Prawidłowy proces tłumaczenia XLIFF opiera się na tych samych zasadach co nasz silnik PO, dostosowanych do XML.
Parsuj, nie używaj wyrażeń regularnych (Regex)
Traktuj XLIFF jako ustrukturyzowany dokument. Parsuj go za pomocą prawdziwego parsera XML, buduj drzewo i przechodź elementy <trans-unit> (lub <unit> dla 2.0). Próba dopasowania treści źródłowej i docelowej za pomocą wyrażeń regularnych to szybka droga do uszkodzonych plików.
Zablokuj tagi liniowe przed tłumaczeniem
Każdy <g>, <x>, <bpt>, <ept>, <ph>, <pc> wewnątrz <source> musi być zachowany pod względem pozycji i atrybutu id. Zastąp je numerycznymi placeholderami przed wysłaniem tekstu do LLM, a następnie ponownie wstaw oryginalne tagi z ich atrybutami po powrocie tłumaczenia.
Szanuj maszynę stanów
Jednostki XLIFF mają atrybuty stanu: new, needs-translation, translated, reviewed, final, signed-off. Proces powinien tłumaczyć tylko jednostki w stanie new lub needs-translation i ustawiać stan wyjściowy na translated (nie final – recenzent powinien nadal weryfikować).
Zachowaj strukturę poza jednostkami tłumaczeniowymi
Pliki XLIFF zawierają nagłówki, metadane, atrybuty na poziomie pliku, notatki i alternatywne tłumaczenia (<alt-trans>). Muszą one pozostać niezmienione podczas całej podróży. Usunięcie lub zmiana ich kolejności narusza kompatybilność z platformą źródłową.
Waliduj przed dostarczeniem
Przed zwróceniem przetłumaczonego pliku XLIFF, waliduj go względem schematu. XLIFF 1.2 ma oficjalny XSD. XLIFF 2.0 ma własny. Narzędzie, które nie potrafi samodzielnie walidować, to narzędzie, które dostarczy Ci uszkodzone pliki.
Uwagi specyficzne dla platformy
Każda główna platforma używająca XLIFF ma swoje specyficzne cechy, o których warto wiedzieć.
Drupal
Narzędzie Translation Management Tool (TMGMT) w Drupal eksportuje XLIFF 1.2. Typy treści obejmują węzły (strony, artykuły), terminy taksonomii i konfigurację. TMGMT opakowuje każde pole do tłumaczenia w osobną jednostkę <trans-unit> z formatem ID specyficznym dla Drupal (fieldname:delta:format).
Pułapka: Drupal przechowuje informacje o formacie tekstu (filtered HTML, full HTML, plain text) razem z treścią. Tłumaczenie musi zachować znaczniki HTML, gdy format na to pozwala, lub sprowadzić do zwykłego tekstu, gdy format tego nie umożliwia. Twój proces musi uwzględniać specyfikę każdego pola.
Symfony
Komponent tłumaczeń Symfony domyślnie używa XLIFF 2.0 (od Symfony 4). Ciągi znaków znajdują się w translations/messages.xx.xliff. Symfony obsługuje format wiadomości ICU wewnątrz XLIFF, co oznacza, że pojedyncza jednostka może zawierać struktury {count, plural, one {...} other {...}}.
Pułapka: Kategorie liczby mnogiej ICU wewnątrz XLIFF wymagają podwójnej ochrony. Tagi XML pozostają nienaruszone, ORAZ słowa kluczowe ICU (plural, one, other, =0) nie mogą być tłumaczone. Wiele narzędzi XLIFF radzi sobie z jedną warstwą, ale nie z obiema.
Angular i18n
Angular eksportuje XLIFF 1.2 lub 2.0 za pomocą polecenia ng extract-i18n. Pliki zawierają ciągi znaków z szablonów komponentów, z tagami <x> reprezentującymi wyrażenia Angulara i interpolacje, takie jak {{ count }}.
Pułapka: Angular używa kolizji hashy id dla identycznych ciągów źródłowych. Tłumaczenie musi zachować dokładne ID jednostek, w przeciwnym razie Angular nie będzie w stanie ich dopasować podczas importu. Zmiana nazw atrybutów id podczas przetwarzania natychmiast prowadzi do awarii.
iOS (Eksport Xcode)
Xcode eksportuje XLIFF 1.2 do lokalizacji aplikacji za pośrednictwem Product > Export Localizations. Ciągi znaków pochodzą z Localizable.strings, wpisów Info.plist, storyboardów i XIB-ów. Zasady liczby mnogiej iOS znajdują się w plikach .stringsdict eksportowanych jako dodatkowe jednostki tłumaczeniowe.
Pułapka: Ciągi znaków storyboardów iOS odwołują się do ID elementów interfejsu użytkownika. Nie mogą one być zmieniane. Ponadto Xcode wymaga, aby atrybut target-language dokładnie odpowiadał oczekiwanemu formatowi lokalizacji (np. es, a nie es-ES, w niektórych kontekstach), w przeciwnym razie cicho ignoruje import.
Tłumaczenie XLIFF z SimplePoTranslate
SimplePoTranslate obsługuje XLIFF w planach Pro i Lifetime. Proces jest taki sam jak w przypadku plików .po.
1. Eksportuj swój XLIFF
Ze swojej platformy źródłowej wyeksportuj jeden lub więcej plików .xliff. Dla Drupal użyj akcji eksportu TMGMT. Dla Symfony znajdź translations/messages.en.xliff. Dla Angular uruchom ng extract-i18n --format=xlf2. Dla Xcode użyj eksportu lokalizacji.
2. Prześlij do SimplePoTranslate
Przeciągnij plik do pulpitu nawigacyjnego. Platforma automatycznie wykrywa wersję XLIFF (1.2 lub 2.0), parsuje strukturę i identyfikuje jednostki do przetłumaczenia. Wybierz język docelowy i ton.
3. Tłumaczenie z uwzględnieniem składni
Tagi liniowe, parametry ICU, placeholdery i identyfikatory jednostek są blokowane przed tłumaczeniem. Podstawowy silnik AI widzi tylko czysty tekst z kontekstem. Przetłumaczony tekst jest ponownie wstawiany w dokładnie oryginalną strukturę, stany są aktualizowane, a plik jest walidowany względem schematu XLIFF przed dostarczeniem.
4. Pobierz i zaimportuj
Pobierz przetłumaczony plik XLIFF (plus odpowiedniki .po, .json i .php, jeśli potrzebujesz ich do innych platform). Zaimportuj go do swojej platformy źródłowej. Zweryfikuj, renderując kilka przetłumaczonych stron lub widoków przed wdrożeniem.
# 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. Zintegruj z CI
Gdy zaufasz procesowi, zautomatyzuj go. Eksportuj XLIFF przy każdym wydaniu, przesyłaj przez API, pobieraj przetłumaczone pliki, commituj do repozytorium, wdrażaj. To ten sam wzorzec przyjazny CI, którego wiele agencji używa do tłumaczenia plików .po w WordPress – zobacz nasz post na temat tłumaczenia w chmurze bez uszkodzonych stron dla wzorca architektonicznego.
Podsumowanie
XLIFF to właściwe narzędzie do poważnych prac lokalizacyjnych – ustrukturyzowane, niezależne od narzędzi i wystarczająco bogate, aby przenosić metadane projektu między systemami. Ale jego struktura XML jest również krucha. Każdy tag, atrybut i wartość stanu mają znaczenie semantyczne, a tłumacz, który nie rozumie XLIFF jako formatu, uszkodzi Twój plik w sposób, który może nie ujawnić się, dopóki import nie zakończy się niepowodzeniem lub użytkownik nie zgłosi uszkodzonego interfejsu użytkownika.
Bezpieczne podejście uwzględnia składnię: parsowanie XML, blokowanie elementów strukturalnych, tłumaczenie tylko powierzchni tekstowych z kontekstem, walidacja względem schematu przed dostarczeniem. Dotyczy to zarówno witryny Drupal, API Symfony, aplikacji Angular SPA, czy aplikacji iOS. Platforma się różni, ale dyscyplina XLIFF pozostaje ta sama.
Gotowy do tłumaczenia plików XLIFF dla Drupal, Symfony, Angular lub iOS bez uszkodzonych tagów? Wypróbuj SimplePoTranslate za darmo – nie wymagamy karty kredytowej. Prześlij
.xliff, pobierz bezpieczne tłumaczenia, zaimportuj do swojej platformy.