Коли XLIFF стає потрібним¶
Уяви: реліз має вийти кількома мовами, а перекладач отримує рядки без пояснення, де саме вони з’являються. Переклад повертається, але частина тексту не підставляється, змінні опиняються не там, де треба, і команда не може відновити початковий ресурс. XLIFF допомагає відокремити структуру продукту від тексту для перекладу, але сам файл не захистить від помилок у всьому процесі.
XLIFF - формат на основі XML для зберігання локалізованих даних і передавання їх між етапами роботи та інструментами. Специфікація OASIS описує його як формат для зберігання локалізованих даних і передавання їх від одного етапу локалізації до іншого, щоб інструменти могли взаємодіяти. Специфікація XLIFF 2.2 називає його словником XML.
«XLIFF is an XML vocabulary that is intended to store localizable data and carry it from one step of the localization process to the other, while allowing interoperability between and among tools.»
Так призначення формату формулює технічний комітет OASIS XLIFF.
Якщо простіше, XLIFF - це проміжний контейнер. У ньому є текст для локалізації, його відповідник цільовою мовою та дані, потрібні інструментам. Інженер експортує ресурс з одного середовища, передає його до CAT-інструмента (системи автоматизованого перекладу), а потім повертає результат у застосунок.
XLIFF - не мова програмування, не інтерфейс користувача й не система керування перекладацькими проєктами. Формат не вирішує, хто розподіляє роботу, хто затверджує переклад і коли виходить реліз. Він задає структуру обміну; решту визначають інструменти й процеси команди.
Одна з ключових цілей XLIFF - обмінюватися даними з мінімальними втратами. Специфікація передусім розроблялася як формат обміну, але не забороняє і не заохочує використовувати її для оброблення вмісту. Різниця практична: XLIFF може бути зручним для передавання, навіть якщо ваша команда використовує його ще й як робочий формат.
Microsoft описує XLIFF як формат XML, що зіставляє джерельні й цільові сегменти та часто слугує для обміну між CAT-інструментами. У прикладі структури XLIFF 2.0 від Microsoft є кореневий елемент xliff, атрибути мов і елементи file, unit, segment, source та target. Не плутайте приклад із новішою специфікацією: Microsoft позначає його саме як XLIFF 2.0.
Що містить файл XLIFF¶
Файл XLIFF - це XML-документ зі структурою, визначеною форматом. Залежно від версії в ньому можуть бути мови, файли, одиниці перекладу, сегменти, джерельний і цільовий тексти, нотатки та статус роботи.
Одиниця перекладу об’єднує текст, який обробляється як одне повідомлення. Сегмент може містити джерельний текст і відповідник цільовою мовою. Таке зіставлення показує локалізатору, до якого оригіналу належить переклад. Зразок Microsoft для XLIFF 2.0 показує цю структуру через елементи unit, segment, source і target.
Ідентифікатор на кшталт button_1 не завжди пояснює, для чого потрібен рядок. Якщо в інтерфейсі кілька кнопок із написом «Далі», перекладачеві треба знати: це перехід до наступного кроку, сторінки чи товару? Mozilla радить використовувати унікальні ідентифікатори, пов’язані з повідомленням і його роллю в інтерфейсі, а не повторно використовувати один рядок у різних контекстах. Настанови Mozilla для розробників пояснюють, навіщо ідентифікатор має описувати повідомлення, а не бути просто технічним номером.
Контекст можна додати в нотатку до рядка. Наприклад, напишіть, що змінна {count} містить кількість завантажених файлів, а повідомлення з’являється після завершення передавання. Без пояснення локалізатор бачить слово й плейсхолдер, але не знає, яке значення змінна матиме під час роботи програми.
Інлайн-коди позначають елементи, які мають залишитися в перекладі, наприклад форматування чи плейсхолдери. Змінюйте їхній порядок лише тоді, коли це дозволяють структура повідомлення й програма. Якщо код загубиться або стане звичайним текстом, збирання може завершитися помилкою або дати неправильний інтерфейс.
Обирайте розмір сегмента з огляду на контекст. Надто короткий сегмент може розірвати фразу, і перекладач не зрозуміє, навіщо вона в інтерфейсі. Довший сегмент дає більше контексту, але зменшує шанс повного збігу з пам’яттю перекладів. Microsoft розбирає цей компроміс у матеріалі про формати локалізаційних файлів.
Як працює цикл вилучення, перекладу та збирання¶
XLIFF сам не читає всі типи файлів і не визначає, які частини програми треба перекласти. Для вилучення потрібен парсер або фільтр, який розуміє початковий формат: наприклад, HTML, RESX, RTF, документи Office чи звичайний текст. Microsoft окремо наголошує: інструмент має аналізувати вихідний формат, щоб відділити локалізований текст від решти вмісту.
«XLIFF is a file format that can be used when translating source files regardless of what proprietary format they might use.»
Microsoft Learn описує XLIFF як формат обміну під час перекладу файлів із різними власними форматами.
Але сумісність не означає, що XLIFF сам перетворить будь-який файл. Парсер має правильно розібрати джерело, а система збирання - знати, куди повернути кожен фрагмент. Якщо вихідний формат має власні правила, метадані або складну верстку, фільтр повинен зберегти їх чи передати достатньо інформації для відновлення.
Типовий цикл має три етапи:
- Вилучення. Парсер читає вихідний файл і визначає, що перекладати, а що залишити без змін. Інструмент створює XLIFF із джерельними сегментами, ідентифікаторами та контекстом.
- Переклад. CAT-інструмент імпортує XLIFF і показує сегменти, до яких можна додати цільові відповідники. Перекладач працює з текстом, нотатками та інлайн-кодами.
- Збирання. Інструмент зберігає перекладений XLIFF, а механізм збирання повертає цільовий текст у формат, який може використати програма.
У деяких процесах разом із файлом передають каркас (skeleton) - початкову структуру з даними, які не треба перекладати. Після перекладу цільові сегменти з’єднуються з каркасом, і так відновлюється вихідний формат. Microsoft описує цю схему в матеріалі про обмін локалізованими ресурсами.
Не зупиняйтеся на перевірці «CAT-інструмент відкрив файл». Успішний імпорт не доводить, що програма прочитає експорт, а правильний XML не означає, що зібраний ресурс працюватиме. Перевірте весь шлях: вилучення, імпорт, редагування, експорт, збирання й тестування в інтерфейсі.
Який контекст передавати локалізатору¶
Нотатка має пояснити те, чого не можна зрозуміти лише з тексту. Напишіть, для чого потрібне повідомлення, де воно показується, що означають змінні, за яких умов з’являється рядок і які частини не перекладати. Microsoft радить через нотатки пояснювати, зокрема, значення плейсхолдерів під час роботи програми та використання рядка в інтерфейсі.
«The comment can explain the conditions under which the string is displayed.»
Саме такий приклад наводить Microsoft Learn: коментар може пояснити, за яких умов показується рядок. Для перекладача ця деталь часто важливіша за буквальне значення короткого тексту.
Нотатка про змінну має пояснювати її значення, а не просто називати її. Коментар «містить змінну» нічого не прояснює. А фраза «{name} - ім’я користувача, яке показується у привітанні» допомагає правильно побудувати речення цільовою мовою. Якщо повідомлення містить технічний ідентифікатор або код, позначте його як незмінний текст.
Контекст потрібен і для рядків, значення яких залежить від стану застосунку. «Закрити» може закривати вікно, відхиляти попередження або завершувати сеанс. Без пояснення той самий напис може вимагати різних перекладацьких рішень.
Якщо команда локалізує багатомовний інтерфейс, узгодьте формат нотаток заздалегідь. Наприклад, визначте поля для призначення, змінних, незмінних фрагментів та обмежень довжини. Сам XLIFF не зробить контекст послідовним, але домовленість допоможе передавати його однаково між файлами й релізами.
Версії XLIFF і сумісність інструментів¶
Версія визначає структуру файлу, доступні можливості та спосіб перевірки. Напис «підтримує XLIFF» у переліку форматів не відповідає на важливіше запитання: чи працює інструмент із потрібною версією, модулями й розширеннями?
| Версія | Що варто знати | Практичний наслідок |
|---|---|---|
| XLIFF 1.2 | Стандарт OASIS від 1 лютого 2008 року; має варіанти схем Transitional і Strict. | Для перевірки потрібно вибрати відповідну схему. |
| XLIFF 2.1 | Стандарт OASIS від 13 лютого 2018 року; визначає правила відповідності та офіційну схему Core. | Перевірки XML і схеми недостатньо, якщо порушено обмеження специфікації. |
| XLIFF 2.2 | Специфікацію датовано 13 березня 2025 року; версія містить модуль множини, роду та вибору. | Перед використанням нового модуля перевірте його підтримку в усьому ланцюжку інструментів. |
Дати й властивості в таблиці наведено за документами XLIFF 1.2, XLIFF 2.1 і XLIFF 2.2.
Специфікація 2.2 складається з кількох частин. Частина 1 визначає основні елементи й атрибути, потрібні для коректного XLIFF-файлу. Частина 2 містить ядро та додаткові модулі для окремих процесів. Коли шукаєте потрібну можливість у документації, перевірте, до якої частини й модуля вона належить.
Модуль множини, роду та вибору в XLIFF 2.2 призначений для повідомлень із варіантами. Він потрібен, коли текст змінюється залежно від кількості, граматичного роду чи іншого заданого значення. Підтримка основного формату ще не означає, що CAT-інструмент або механізм збирання вміє працювати з цим модулем.
Специфікація XLIFF 2.2 повідомляє, що зміни у версії розробили зі збереженням сумісності з 2.0 і 2.1. Але це не підтверджує сумісність кожного інструмента, розширення чи робочого процесу. Не сприймайте сумісність на рівні стандарту як гарантію, що конкретний продукт пройде цикл без помилок.
«The ID chosen for your string, regardless of the file format, should always be descriptive of the message and its role in the interface (button label, title, etc.).»
Mozilla Localization радить обирати ідентифікатори, які описують повідомлення та його роль. Під час переходу між версіями важливо зберегти не лише XML-структуру, а й сенс цього контексту.
Розширення XLIFF можуть додавати власні елементи й атрибути. Специфікація 2.1 не вимагає, щоб кожен обробник розумів елементи, які не належать до XLIFF. Відповідні застосунки мають зберігати розширення, коли це можливо й відповідає зазначеним умовам. На практиці інструмент може не розуміти розширення й видалити його - випадково або навмисно.
Перед переходом на іншу версію підготуйте тестовий набір. Додайте звичайний рядок, плейсхолдер, інлайн-код, нотатку, елемент розширення та варіант із модулем, якщо він вам потрібен. Перевірте, чи файл відкривається, чи зберігає дані після редагування та чи відновлює потрібний ресурс.
Перевірка файлу та типові збої¶
У перевірки XLIFF кілька рівнів, і кожен відповідає на окреме запитання. Синтаксис XML покаже структурні помилки. Перевірка схеми звірить файл зі структурою конкретної версії. Перевірка специфікації виявить обмеження, яких схема не охоплює. А тест збирання покаже, чи можна повернути переклад у потрібний формат.
Для XLIFF 2.1 документ має бути правильно сформованим XML, відповідати офіційній схемі Core XML Schema та виконувати застосовні вимоги специфікації, яких схема не виражає. Специфікація XLIFF 2.1 розділяє ці вимоги. Для XLIFF 1.2 оберіть потрібну схему - Transitional або Strict, як указано в специфікації 1.2.
Перевірте файл за цим списком:
- Визначте версію та простір імен. Не перевіряйте файл схемою від іншої версії. Для XLIFF 1.2 специфікація задає простір імен
urn:oasis:names:tc:xliff:document:1.2. - Перевірте синтаксис XML. Знайдіть незакриті елементи, неправильне вкладення та інші помилки формування документа.
- Звірте файл зі схемою версії. Для XLIFF 1.2 виберіть Transitional або Strict відповідно до документа. Для XLIFF 2.1 використовуйте схему Core відповідної версії.
- Перевірте вимоги поза схемою. Схема не охоплює всіх правил специфікації, тож перевірте відповідні вимоги окремо.
- Перевірте вміст сегментів. Звірте ідентифікатори й джерельний текст із ресурсом, а також переконайтеся, що плейсхолдери та коди не загубилися.
- Перевірте розширення. З’ясуйте, чи кожен інструмент зберігає власні простори імен, елементи й атрибути.
- Зберіть ресурс і перегляньте результат. Переконайтеся, що зібраний файл працює, а локалізований продукт виглядає як треба.
Перевірка схеми не замінює тестування інтерфейсу. Правильний XML усе ще може містити хибний переклад, неправильне значення змінної або рядок, який не вміщується в потрібний елемент. Microsoft радить переглядати локалізований результат у реальному макеті й перевіряти довжину тексту, шрифти, напрямок письма, пагінацію та перенесення рядків. Ці вимоги описано в матеріалі про обмін локалізованими ресурсами.
Збої часто виникають не в XML, а на межі між компонентами. Фільтр може не вилучити рядок із певного поля; CAT-інструмент - зберегти текст, але відкинути власний атрибут; механізм збирання - отримати правильні сегменти, але не той каркас. Зберігайте оригінал, XLIFF до перекладу, файл після експорту й зібраний ресурс. Порівняйте їх - так побачите, на якому етапі зникли дані.
Ще одна пастка - використовувати один ідентифікатор для повторюваного тексту з різними значеннями. Однаковий напис може мати різну функцію, а отже, потребувати різного перекладу. Mozilla застерігає від повторного використання рядків у різних контекстах у настановах для розробників.
Перш ніж обрати новий CAT-інструмент, запитайте про підтримувані версії, обмеження розміру файлів, збіги з пам’яті перекладів, двійкові одиниці, власні простори імен і атрибути та складні мови. Уточніть актуальні можливості в постачальника: загальна заява про підтримку XLIFF нічого не каже про конкретну версію чи розширення. Повний перелік питань є в FAQ OASIS XLIFF.
Після технічної перевірки подивіться на процес очима перекладача. Чи видно нотатки? Чи можна розрізнити однакові рядки? Чи збереглися плейсхолдери? Чи зрозуміло, що можна змінювати, а що має залишитися незмінним? Формат задає спосіб передавання даних, а якість контексту залежить від того, що команда записала у файл.
Коли XLIFF підходить, а коли потрібен інший підхід¶
XLIFF стане в пригоді, коли треба передавати локалізований текст між системами або зберігати його у структурованому форматі обміну. Це зручний варіант, якщо один інструмент обробляє початковий ресурс, інший - переклад, а готовий текст треба повернути в продукт.
OASIS називає XLIFF «lossless interchange specification» - специфікацією обміну без втрати даних. Таке формулювання подано в FAQ OASIS XLIFF.
Для інженера це підказка про призначення формату, а не гарантія, що будь-які інструменти збережуть усі дані. Результат залежить від парсерів, підтримки розширень і перевіреного циклу збирання.
XLIFF не замінить початковий ресурс, парсер, систему керування перекладацькими проєктами чи людське тестування. Якщо ви перекладаєте один короткий текст і не передаєте дані між інструментами, повний обмінний файл може лише ускладнити роботу. А якщо команда використовує спеціальний формат без перевіреного фільтра, спершу розв’яжіть проблему вилучення й збирання. Саме підтримка джерела визначає, чи потраплять потрібні рядки до XLIFF і чи повернуться вони на місце.
Для багатомовного продукту важливі стабільні ключі, зрозумілі нотатки й обережна робота з інлайн-кодами. Додайте до цього версію специфікації та вимоги до розширень. Якщо бодай одну складову не визначити, обмін може пройти технічно успішно, але результат усе одно не буде готовий до релізу.
Орієнтуйтеся не на розширення файлу, а на можливості всього ланцюжка інструментів. Перевірте експорт, імпорт, збереження контексту, потрібні модулі й збирання. Потім перегляньте локалізований ресурс у справжньому інтерфейсі. Так ви відрізните файл, який лише проходить перевірку XML, від процесу, що справді доставляє переклад у продукт.
FAQ¶
Що таке файл XLIFF і як він працює в локалізації?¶
XLIFF - формат XML для обміну локалізованими даними між інструментами й етапами роботи. Файл зіставляє джерельний текст із цільовим, а після перекладу механізм збирання повертає його до потрібного формату.
Чим відрізняються XLIFF 1.2, 2.1 і 2.2?¶
Версії мають різні структури й схеми, тому перевіряйте файл засобами саме його версії. Стандарт XLIFF 1.2 датовано 1 лютого 2008 року, XLIFF 2.1 затверджено як стандарт OASIS 13 лютого 2018 року, а специфікацію XLIFF 2.2 датовано 13 березня 2025 року. Відомості про версії наведено в документах OASIS.
Як перевірити файл XLIFF?¶
Переконайтеся, що XML правильно сформований і відповідає схемі своєї версії. Окремо перевірте вимоги специфікації поза схемою, розширення, плейсхолдери та результат збирання локалізованого ресурсу.
Як працюють вилучення та збирання XLIFF?¶
Парсер читає початковий формат і експортує локалізований текст у XLIFF. Після перекладу інструмент збирання повертає цільові сегменти у вихідний формат, використовуючи каркас або інші збережені дані про структуру.
Що розробникам додавати в нотатки XLIFF?¶
Поясніть, де з’являється рядок, що означають змінні, які фрагменти не можна перекладати та за яких умов показується повідомлення. Нотатка має передавати контекст, якого локалізатор не бачить у самому рядку.
Як дізнатися, чи підтримує CAT-інструмент мою версію XLIFF?¶
Запитайте постачальника про потрібну версію, модулі, власні простори імен та атрибути, обмеження розміру файлів і складні мови. Перевірте не лише імпорт, а й експорт, збереження розширень та збирання тестового файлу.