Як перекладати файли XLIFF (Drupal, Symfony, Angular, iOS)
Минулого тижня розробниця Drupal опублікувала пост на Stack Overflow з історією, яка тисячі разів на рік трапляється у великих командах локалізації. Її команда експортувала 40 МБ файл XLIFF зі свого сайту Drupal. Вона відкрила його в текстовому редакторі, вставила фрагменти в Google Translate, зібрала файл заново, імпортувала його назад у Drupal – і половина сторінок відмовилися відображатися, оскільки перекладені рядки містили неправильно сформований XML, екрановані символи не на своїх місцях та зламані теги <g>, де було знищено вбудоване форматування.
XLIFF є корпоративним стандартом локалізації недарма. Він заснований на XML, незалежний від інструментів і підтримує багаті метадані, необхідні для серйозних проєктів перекладу: стани перекладу, альтернативні переклади, нотатки між перекладачами та розробниками, а також структуровану вбудовану розмітку. Але його гнучкість робить його легко вразливим, і інструменти, які безпечно обробляють файли .po, часто не справляються з XLIFF.
Цей посібник розповідає про те, що робить XLIFF унікальним, чому загальні підходи до перекладу його ламають, і як правильно перекладати файли XLIFF для Drupal, Symfony, Angular та iOS – чотирьох платформ, де XLIFF найчастіше використовується у 2026 році.
Що таке XLIFF (і чому його використовують корпоративні команди)
XLIFF розшифровується як XML Localization Interchange File Format (формат файлів обміну локалізаційними даними на основі XML). Це стандарт OASIS, розроблений спеціально для переміщення перекладацького контенту між інструментами – системами управління контентом, базами даних пам'яті перекладів, CAT-інструментами та платформами локалізації. На відміну від файлів Gettext .po (які зберігають прості пари ключ-значення) або файлів локалізації JSON (які довільно вкладаються), XLIFF є структурованим XML-документом зі стандартизованою схемою.
XLIFF 1.2 проти XLIFF 2.0
Існують дві версії, і вони не повністю сумісні.
XLIFF 1.2 є старою, більш поширеною версією. Вона використовує елементи <trans-unit> для обгортання перекладеного вмісту, з дочірніми елементами <source> та <target>. Вбудоване форматування використовує парні теги <g>, <x> та <bpt> / <ept>. Інструмент управління перекладами Drupal та багато старих платформ досі експортують 1.2.
XLIFF 2.0 — це редакція 2014 року, простіша та чистіша. Вона використовує <unit> та <segment> з <source> та <target>. Вбудована розмітка використовує <pc> (парний код) та <ph> (заповнювач). Компонент перекладача Symfony та сучасні експорти iOS за замовчуванням використовують 2.0.
Інструмент перекладу, який обробляє 1.2, не обробляє автоматично 2.0. Словники тегів відрізняються, і правила екранування дещо різняться. Завжди перевіряйте, яку версію експортує ваша платформа, перш ніж вибирати конвеєр перекладу.
Анатомія одиниці XLIFF
Мінімальна одиниця trans-unit XLIFF 1.2 виглядає так:
<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"> обгортає змінну-заповнювач. Атрибут state повідомляє платформі, що цей рядок потребує перекладу. Тег <note> є підказкою розробника. Перекладач, який розуміє XLIFF, повинен створити:
<target state="translated">¡Bienvenido, <g id="1">%name%</g>!</target>
Перекладач, який розглядає файл як простий текст, може створити будь-який із цих пошкоджених варіантів:
<target>¡Bienvenido, <g id="1">%nombre%</g>!</target>
<target>¡Bienvenido, <g id="1">%name%</g>!</target>
<target>¡Bienvenido, %name%!</target>
Кожен з них по-різному порушує імпорт. Перший перейменовує змінну. Другий екранує XML. Третій повністю видаляє тег форматування.
Погані рішення (Чому не можна просто перекласти XML)
Більшість команд починають з одних і тих же трьох підходів і витрачають кілька днів, перш ніж здатися.
Передача XLIFF загальному ШІ
Скопіюйте файл, вставте його в Claude або ChatGPT, попросіть перекласти. Модель зазвичай виконує досить хорошу роботу з текстом, але непослідовно обробляє теги XLIFF. Іноді вона зберігає теги <g>, іноді перекладає атрибут id, іноді повністю їх видаляє. Валідація не вдається. Ваш імпорт видає помилки парсингу XML.
Використання CAT-інструменту без підтримки XLIFF
Інструменти, такі як Poedit, створені для формату .po. Вони можуть відкривати XLIFF, але розглядають його як загальний текстовий контейнер. Вбудовані теги не заблоковані. Заповнювачі не захищені. Ви отримуєте переклад, який виглядає нормально в редакторі, але не проходить перевірку схеми під час імпорту.
Написання власного скрипта
Ваша команда пише скрипт на Node або Python, який парсить XLIFF за допомогою xml2js, витягує вихідні рядки, викликає Google Translate та записує цільові рядки назад. Він працює для 90% рядків. Інші 10% – рядки з вкладеним форматуванням, групами множини або спеціальними символами – ламаються таким чином, що це виявляється лише після того, як ви вже все відправили.
Такий самий режим відмови «гнучкий формат зустрічає наївного перекладача» впливає на файли i18next JSON та Gettext .po. Наш посібник перекладу файлів i18next JSON для React та Next.js та наш допис про те, як перекладати файли .po, не ламаючи кодові змінні охоплюють паралельні проблеми для цих форматів.
Правильний спосіб: синтаксично-усвідомлена обробка XLIFF
Правильний конвеєр перекладу XLIFF дотримується тих самих принципів, що й наш рушій PO, адаптований для XML.
Розбір, а не регулярні вирази
Розглядайте XLIFF як структурований документ. Розбирайте його за допомогою справжнього XML-парсера, будуйте дерево та обходьте елементи <trans-unit> (або <unit> для 2.0). Спроба зіставляти вихідний та цільовий вміст за допомогою регулярних виразів – це швидкий шлях до пошкодження файлів.
Блокування вбудованих тегів перед перекладом
Кожен <g>, <x>, <bpt>, <ept>, <ph>, <pc> всередині <source> повинен бути збережений за позицією та атрибутом id. Замініть їх числовими заповнювачами перед відправкою тексту в LLM, потім повторно вставте оригінальні теги з їхніми атрибутами після повернення перекладу.
Дотримання кінцевого автомата станів
Одиниці XLIFF мають атрибути стану: new, needs-translation, translated, reviewed, final, signed-off. Конвеєр повинен перекладати лише одиниці в стані new або needs-translation та встановлювати вихідний стан на translated (а не final – рецензент все ще повинен перевірити).
Збереження структури за межами одиниць перекладу
Файли XLIFF містять заголовки, метадані, атрибути на рівні файлу, примітки та альтернативні переклади (<alt-trans>). Вони повинні залишатися незмінними протягом всього циклу. Видалення або перевпорядкування їх порушує сумісність з вихідною платформою.
Перевірка перед доставкою
Перед поверненням перекладеного XLIFF, перевірте його на відповідність схемі. XLIFF 1.2 має офіційний XSD. XLIFF 2.0 має власну схему. Інструмент, який не може самостійно перевіряти, – це інструмент, який надсилатиме вам пошкоджені файли.
Примітки щодо конкретних платформ
Кожна основна платформа, що використовує XLIFF, має свої особливості, про які варто знати.
Drupal
Інструмент управління перекладами Drupal (TMGMT) експортує XLIFF 1.2. Типи контенту включають ноди (сторінки, статті), терміни таксономії та конфігурації. TMGMT обгортає кожне перекладене поле в окремий <trans-unit> з ідентифікатором у форматі Drupal (fieldname:delta:format).
Увага: Drupal зберігає інформацію про формат тексту (відфільтрований HTML, повний HTML, простий текст) разом із вмістом. Переклад повинен зберігати розмітку HTML, якщо формат це дозволяє, або перетворювати на простий текст, якщо формат не дозволяє. Ваш конвеєр потребує обізнаності щодо кожного поля.
Symfony
Компонент перекладу Symfony за замовчуванням використовує XLIFF 2.0 (починаючи з Symfony 4). Рядки знаходяться в translations/messages.xx.xliff. Symfony підтримує формат повідомлень ICU всередині XLIFF, що означає, що одна одиниця може містити структури {count, plural, one {...} other {...}}.
Увага: Категорії множини ICU всередині XLIFF потребують подвійного захисту. Теги XML залишаються неушкодженими, І ключові слова ICU (plural, one, other, =0) не повинні перекладатися. Багато інструментів XLIFF обробляють один рівень, але не обидва.
Angular i18n
Angular експортує XLIFF 1.2 або 2.0 за допомогою команди ng extract-i18n. Файли містять рядки шаблонів компонентів, з тегами <x>, що представляють вирази та інтерполяції Angular, такі як {{ count }}.
Увага: Angular використовує колізії хешів id для ідентичних вихідних рядків. Переклад повинен точно зберігати ідентифікатори одиниць, інакше Angular не зможе їх зіставити під час імпорту. Перейменування атрибутів id під час обробки призведе до миттєвої поломки.
iOS (експорт Xcode)
Xcode експортує XLIFF 1.2 для локалізації додатків за допомогою Product > Export Localizations. Рядки надходять з Localizable.strings, записів Info.plist, storyboard та XIB-файлів. Правила множини iOS містяться у файлах .stringsdict, які експортуються як додаткові trans-units.
Увага: Рядки storyboard iOS посилаються на ідентифікатори елементів інтерфейсу. Їх не можна змінювати. Також Xcode вимагає, щоб атрибут target-language точно відповідав очікуваному формату локалі (наприклад, es, а не es-ES у деяких контекстах), інакше він мовчазно ігнорує імпорт.
Переклад XLIFF за допомогою SimplePoTranslate
SimplePoTranslate підтримує XLIFF у планах Pro та Lifetime. Робочий процес такий самий, як і для файлів .po.
1. Експортуйте свій XLIFF
З вашої вихідної платформи експортуйте один або кілька файлів .xliff. Для Drupal використовуйте дію експорту TMGMT. Для Symfony знайдіть translations/messages.en.xliff. Для Angular запустіть ng extract-i18n --format=xlf2. Для Xcode використовуйте експорт локалізації.
2. Завантажте в SimplePoTranslate
Перетягніть файл на панель управління. Платформа автоматично визначає версію XLIFF (1.2 або 2.0), парсить структуру та ідентифікує перекладні одиниці. Виберіть цільову мову та тон.
3. Синтаксично-усвідомлений переклад
Вбудовані теги, параметри ICU, заповнювачі та ідентифікатори одиниць блокуються перед перекладом. Базовий механізм ШІ бачить лише чистий текст з контекстом. Перекладений текст повторно вставляється в точну оригінальну структуру, оновлюються стани, і файл перевіряється на відповідність схемі XLIFF перед доставкою.
4. Завантажте та імпортуйте
Завантажте перекладений XLIFF (плюс еквіваленти .po, .json та .php, якщо вам потрібна крос-платформність). Імпортуйте на свою вихідну платформу. Перевірте, відтворивши кілька перекладених сторінок або представлень, перш ніж запускати в роботу.
# 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. Інтегруйте в CI
Як тільки ви довіряєте конвеєру, автоматизуйте його. Експортуйте XLIFF при кожному релізі, надсилайте через API, завантажуйте перекладені файли, комітьте до репозиторію, розгортайте. Це той самий патерн, зручний для CI, який багато агентств використовують для перекладу .po файлів WordPress – дивіться наш допис про хмарний переклад без пошкоджених сайтів для архітектурного патерну.
Підсумок
XLIFF є правильним інструментом для серйозної локалізаційної роботи – структурований, незалежний від інструментів і достатньо багатий, щоб переносити метадані проєкту між системами. Але його XML-структура також крихка. Кожен тег, атрибут і значення стану мають семантичну вагу, і перекладач, який не розуміє XLIFF як формат, пошкодить ваш файл таким чином, що це може не виявитися до тих пір, поки імпорт не завершиться невдачею або користувач не повідомить про пошкоджений інтерфейс.
Безпечний підхід є синтаксично-усвідомленим: парсинг XML, блокування структурних елементів, переклад лише текстових поверхонь з контекстом, перевірка на відповідність схемі перед доставкою. Це справедливо незалежно від того, чи ви постачаєте сайт Drupal, API Symfony, SPA на Angular або додаток iOS. Платформа відрізняється, але дисципліна XLIFF – ні.
Готові перекладати файли XLIFF для Drupal, Symfony, Angular або iOS без пошкоджених тегів? Спробуйте SimplePoTranslate безкоштовно — кредитна картка не потрібна. Завантажте
.xliff, завантажте безпечні переклади, імпортуйте на свою платформу.