Один файл интерфейса проходит через репозиторий, CAT-инструмент, переводчика и сборочный процесс, а на выходе кнопка оказывается не на месте или переменная попадает внутрь переведённой фразы. XLIFF помогает разделить текст и детали исходного формата, но сам по себе не гарантирует, что инструменты одинаково обработают файл.
Что такое XLIFF и какую задачу он решает¶
XLIFF - XML-формат обмена, который хранит локализуемые данные и переносит их между этапами локализации и инструментами. Формат задуман как промежуточный слой: из файла приложения извлекают текст, переводят его в подходящей среде, а затем возвращают в локализованный ресурс. Спецификация OASIS описывает XLIFF как словарь XML для хранения данных локализации и взаимодействия инструментов (XLIFF 2.2, часть 1).
По формулировке технического комитета OASIS: “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.”
Проще говоря, XLIFF не заменяет исходный формат приложения и не переводит его автоматически. Файл упаковывает исходные строки, целевые строки, идентификаторы, контекст и другие сведения так, чтобы разные участники процесса могли работать с одним набором данных.
Практическая ценность формата появляется, когда в локализации участвуют несколько инструментов или команд. Разработчик может извлечь строки из ресурса, агентство обработает XLIFF в CAT-среде, а инженер импортирует результат обратно. XLIFF помогает согласовать передачу, но совместимость зависит от версии, схемы, расширений и того, что конкретный инструмент действительно умеет читать и сохранять.
Формат проектировали прежде всего как lossless interchange format, то есть формат обмена, при котором данные должны проходить через процесс без потерь. Спецификация не предписывает и не запрещает использовать XLIFF как формат для внутренней обработки. Разница важна: файл может хорошо подходить для передачи между системами, но неудобно представлять внутреннюю модель проекта в конкретной платформе (спецификация XLIFF 2.2; FAQ OASIS).
XLIFF также не является полноценной заменой CAT-системе или TMS. Сам формат не организует работу команды, не назначает переводчиков и не гарантирует наличие памяти переводов. Он задаёт структуру обмена, а управление процессом и вспомогательные функции остаются за инструментами.
Как устроен файл¶
В структуре XLIFF есть контейнер документа, языковая информация и единицы перевода. Пример XLIFF 2.0 в документации Microsoft показывает элементы xliff, file, unit, segment, source и target: исходный текст хранится в source, а целевой вариант - в target (Microsoft Learn).
Упрощённо цепочка выглядит так:
- Файл XLIFF задаёт общий контейнер и языки.
- Единица перевода связывает сообщение с идентификатором и контекстом.
- Сегмент содержит исходный и целевой текст.
- Структурные данные сохраняют связи, примечания, коды форматирования и другие сведения, нужные для обработки.
- Файл-скелет или связанный исходный ресурс помогает вернуть переведённые строки в формат приложения.
Конкретная разметка различается между версиями. Поэтому пример одной версии нельзя механически использовать как образец для другой, даже если названия элементов кажутся знакомыми. Перед обработкой выясните версию и пространство имён файла, а затем сопоставьте их со схемой и требованиями используемого инструмента.
Документация Microsoft описывает XLIFF так: “XLIFF is a file format that can be used when translating source files regardless of what proprietary format they might use.”
Смысл не в том, что XLIFF умеет прочитать любой исходник самостоятельно. Парсер или фильтр сначала должен понимать исходный формат: например, HTML, RESX, RTF, Office-файл или обычный текст. После извлечения XLIFF становится общим обменным представлением. Если парсер пропустил строку, потерял связь с ресурсом или неверно обработал разметку, формат обмена не восстановит отсутствующую информацию автоматически (Microsoft Learn).
Единица перевода и сегмент - не одно и то же¶
Единица перевода обычно объединяет сообщение и сведения о нём: идентификатор, контекст, состояние и сегментированные данные. Сегмент - конкретная часть текста, которую обрабатывают как единицу исходного и целевого содержимого. Разделение помогает сохранять связь между строкой, переводом и дополнительной информацией, но размер единицы влияет на работу переводчика и памяти переводов.
Короткая единица может быть понятна системе, но не переводчику. Строка Open без контекста подходит для многих значений: открыть файл, открыть меню или перейти в открытый режим. Соседние строки и описание интерфейсной роли помогают выбрать правильный перевод.
Слишком крупная единица даёт больше языкового контекста, но длинные тексты реже совпадают целиком с записями памяти переводов. Microsoft описывает этот компромисс: крупные единицы могут поддерживать более естественный перевод, а чрезмерная длина снижает вероятность полного совпадения с памятью переводов (Microsoft Learn).
Как проходит XLIFF-обмен на практике¶
Типичный процесс состоит из извлечения содержимого, передачи XLIFF на перевод, импорта перевода и проверки результата в исходной среде. Ошибки часто возникают не внутри одного шага, а на стыках: фильтр извлечения неправильно отделил текст от разметки, CAT-инструмент нормализовал файл, а импортёр потерял идентификатор или не сохранил расширение.
1. Извлеките переводимые строки из исходника¶
Первый шаг выполняет парсер, который понимает формат исходного файла. Парсер отделяет текст от кода, атрибутов и данных, которые не нужно переводить, а затем формирует XLIFF. При этом инженер должен проверить не только список строк, но и то, как извлечение сохранило их связи с компонентами приложения.
Уникальный идентификатор помогает связать сообщение с местом использования. Mozilla советует выбирать описательные и уникальные идентификаторы, отражающие само сообщение и его роль в интерфейсе, и не использовать одну строку в разных контекстах (рекомендации Mozilla).
Например, идентификаторы save_button_label и save_dialog_title объясняют назначение лучше, чем string_17 или save. Если одно слово используется как подпись кнопки и как заголовок, общий идентификатор скрывает контекст и усложняет выбор перевода. Повторное использование строки оправдано только тогда, когда совпадают и смысл, и функция в интерфейсе.
2. Добавьте контекст до передачи¶
Примечание полезно, когда строку нельзя однозначно понять по её тексту. В нём стоит указать место появления, роль элемента, условия показа, смысл переменных и части, которые нельзя переводить. Microsoft отдельно рекомендует использовать заметки XLIFF для контекста, включая значения подстановочных параметров во время выполнения (документация Microsoft).
Microsoft Learn поясняет: “The comment can explain the conditions under which the string is displayed.”
Такое примечание полезно, если строка видна только при определённом действии или зависит от состояния интерфейса. Примечание должно объяснять смысл, а не просто повторять исходный текст. Например, запись «показывается после успешного подключения» помогает понять, что сообщение описывает завершённое действие, а не инструкцию.
Переменные требуют отдельного пояснения. Для фразы Hello, {name} переводчику нужно знать, что подставляется вместо {name}: имя человека, название команды или значение другого типа. От этого зависят грамматика, согласование и место переменной в целевой фразе. Если переменная может содержать произвольный пользовательский текст, это тоже нужно сообщить.
Список контекстных заметок можно проверить перед экспортом:
- где пользователь увидит строку;
- что запускает её показ;
- что означают переменные и какие значения они могут принимать;
- какие фрагменты, идентификаторы или коды нельзя переводить;
- есть ли ограничения на длину или форматирование;
- связано ли сообщение с другими строками или состояниями интерфейса.
3. Переведите целевые сегменты, не ломая коды¶
В сегментах могут находиться inline-коды - элементы, которые обозначают форматирование, переменные, ссылки или другие части исходной структуры. Переводчик должен сохранять их смысл и допустимое расположение. Если код пропал, дублировался или оказался внутри слова, исходный ресурс может потерять форматирование или некорректно показать переменную.
Инженер локализации должен понять, какие коды можно перемещать с учётом грамматики целевого языка, а какие должны оставаться на месте. Порядок слов в языках различается, поэтому безусловное закрепление каждой переменной в позиции исходника иногда портит перевод. Но свободное перемещение кода тоже опасно: идентификатор может оказаться за пределами фразы, которую он должен связывать.
Проверка должна учитывать не только наличие тегов, но и корректность пары «исходный фрагмент - целевой фрагмент». Посмотрите, сохранил ли CAT-инструмент все коды, допускает ли спецификация их перемещение и может ли импортёр интерпретировать получившуюся структуру. Для проблемных строк полезен тестовый импорт в приложение, а не только визуальный просмотр XML.
4. Верните перевод в исходный ресурс¶
После заполнения целевых сегментов файл импортируют обратно. Сборщик использует XLIFF вместе с исходными данными или файлом-скелетом, чтобы восстановить формат приложения и подставить локализованные строки. Microsoft описывает общий процесс именно так: извлечь содержимое в XLIFF, перевести целевые строки и использовать файл-скелет для повторной сборки локализованного ресурса (Microsoft Learn).
Файл-скелет - данные или исходный ресурс, которые сохраняют структуру, не предназначенную для перевода. Скелет может связывать строку с исходным компонентом и предоставлять сборщику информацию, которую не нужно отдавать переводчику как обычный текст. Если скелет устарел или относится к другой версии исходника, импорт может завершиться ошибкой или дать некорректный результат.
Поэтому храните вместе сведения о версии исходного ресурса, экспортированном XLIFF и применённом фильтре. Если разработчик успел изменить ключи после экспорта, сопоставление может перестать работать. Проще обнаружить это до перевода: сравните идентификаторы и структуру на тестовом цикле, а затем закрепите правила обмена для проекта.
5. Проверьте результат в контексте¶
Файл, прошедший технический импорт, ещё не доказывает, что локализация готова. Проверьте строки в реальном интерфейсе или в макете. Microsoft указывает на длину текста, шрифты, направление письма, пагинацию и переносы как на факторы, которые стоит тестировать в фактической раскладке (Microsoft Learn).
Проверка должна включать не только отдельные строки, но и состояние экрана. Перевод может быть грамматически точным и при этом обрезаться в кнопке. Переменная может быть оформлена правильно в XML, но подставляться в неподходящем месте. Направление письма может изменить расположение элементов, а выбранный шрифт - отображение символов.
Для рабочего цикла сохраните контрольный набор строк: короткие и длинные подписи, строки с переменными, тексты с inline-кодами, сообщения с числами и элементы для языков с направлением письма справа налево. Набор помогает повторять проверку после смены парсера, CAT-инструмента или схемы, не полагаясь на случайно выбранный файл.
Версии XLIFF: 1.2, 2.1 и 2.2¶
Версия XLIFF определяет структуру документа и правила его обработки. Номер версии нужно установить до импорта: поддержка формата в целом не означает поддержку конкретной версии, модулей или пользовательских расширений.
| Версия | Что важно инженеру |
|---|---|
| XLIFF 1.2 | Стандарт OASIS от 1 февраля 2008 года; использует пространство имён urn:oasis:names:tc:xliff:document:1.2 и имеет схемы Transitional и Strict. |
| XLIFF 2.1 | Стандарт OASIS, утверждённый 13 февраля 2018 года; соответствие требует проверки XML, официальной схемы и ограничений спецификации. |
| XLIFF 2.2 | Спецификация от 13 марта 2025 года; часть 1 задаёт основную структуру, часть 2 описывает дополнительные модули, включая модуль вариантов множественного числа, рода и выбора. |
Даты и особенности версий указаны в соответствующих спецификациях OASIS: XLIFF 1.2, XLIFF 2.1, XLIFF 2.2, часть 1.
Что нужно знать о XLIFF 1.2¶
XLIFF 1.2 - версия с долгой историей использования и отдельным пространством имён. Спецификация от 1 февраля 2008 года включает два варианта схемы: Transitional и Strict. Для валидации нужно выбрать подходящий вариант, а не просто проверить XML любым доступным валидатором (спецификация OASIS XLIFF 1.2).
При работе с файлом 1.2 проверьте точное пространство имён, схему и поведение парсера. Инструмент может заявлять поддержку XLIFF, но при этом ожидать другой вариант схемы или преобразовывать документ при сохранении. Если файл проходит импорт, а после экспорта меняет структуру, не считайте результат автоматически эквивалентным исходнику.
Что изменилось в XLIFF 2.1¶
Спецификация XLIFF 2.1 была утверждена как стандарт OASIS 13 февраля 2018 года. Документ, соответствующий 2.1, должен быть корректным XML, проходить проверку официальной схемой Core и соблюдать ограничения спецификации, которые схема выразить не может (XLIFF 2.1).
Последний пункт часто упускают: схема проверяет структуру, но не заменяет все правила стандарта. Поэтому проверка по XSD - обязательная часть контроля, но не единственная. Команде следует дополнить её проверками, которые соответствуют тому, как приложение и инструменты используют данные: например, проверить ожидаемые языки и наличие нужных сегментов.
XLIFF 2.1 разрешает пользовательские расширения. Однако обработчик не обязан понимать нестандартные элементы и атрибуты. Совместимое приложение должно сохранять расширения при оговорённых спецификацией условиях, но инженер не должен предполагать, что любая программа сделает это автоматически (XLIFF 2.1).
Что добавляет XLIFF 2.2¶
XLIFF 2.2 опубликован как многочастная спецификация: часть 1 задаёт минимальные основные элементы и атрибуты валидного файла, а часть 2 описывает основное ядро и дополнительные модули для отдельных процессов. Спецификация датирована 13 марта 2025 года (XLIFF 2.2, часть 1; часть 2).
Среди дополнений есть модуль Plural, Gender, and Select. Он предназначен для представления и обработки сообщений с вариантами, например зависящими от числа, рода или условия выбора. Такая модель полезна, когда одной исходной строкой нельзя корректно описать все формы сообщения.
Поддержка модуля должна быть согласована между генератором, CAT-инструментом и импортёром. Файл может быть корректным по спецификации, но конкретный инструмент не обязательно покажет варианты редактору или сохранит их при экспорте. Проверьте путь целиком на тестовом документе, а не только факт успешного открытия.
Изменения XLIFF 2.2 разработаны с расчётом на совместимость с версиями 2.0 и 2.1. Эта формулировка спецификации не означает, что каждая отдельная программа, расширение или рабочий процесс автоматически совместимы (XLIFF 2.2). Техническая совместимость стандарта и совместимость конкретного набора инструментов - разные проверки.
Проверка файла, версии и инструментов¶
Валидация XLIFF должна отвечать на несколько отдельных вопросов: корректно ли сформирован XML, соответствует ли документ схеме версии, соблюдены ли ограничения спецификации и сохранит ли нужные данные ваш реальный набор инструментов. Один успешный запуск валидатора отвечает только на часть этих вопросов.
Порядок валидации¶
- Определите версию и пространство имён. Сверьте сведения в документе с ожидаемой версией проекта. Для XLIFF 1.2 пространство имён определено спецификацией; для других версий проверяйте соответствующие официальные документы.
- Проверьте корректность XML. Ошибки синтаксиса, например незакрытый элемент или некорректный атрибут, нужно устранить до проверки содержимого по схеме.
- Запустите схему нужной версии. Используйте официальную схему для выбранного варианта, а для XLIFF 1.2 выберите Transitional или Strict согласно требованиям документа.
- Проверьте ограничения стандарта отдельно. Для XLIFF 2.1 спецификация прямо требует соответствия условиям, которые невозможно выразить схемой.
- Сверьте исходные и целевые сегменты. Убедитесь, что обязательные строки присутствуют, идентификаторы не потеряны, а коды и переменные не изменились неожиданным образом.
- Сделайте круговой обмен. Импортируйте тестовый файл в CAT-инструмент, сохраните его и сравните структуру с исходной.
- Соберите локализованный ресурс. Проверьте реальный результат в приложении, макете или другом целевом формате.
Для XLIFF 2.1 требования к корректности XML, Core XML Schema и дополнительным ограничениям перечислены в спецификации OASIS. Для XLIFF 1.2 требование выбрать правильную схему описано в стандарте XLIFF 1.2.
Как проверить CAT-инструмент¶
Вопрос «поддерживает ли инструмент XLIFF?» слишком общий. До запуска проекта уточните конкретную версию, расширения, ограничения по размеру, работу с бинарными единицами и поведение при обработке пользовательских пространств имён и атрибутов. FAQ OASIS также советует проверять поддержку совпадений с памятью переводов и сложных языков (FAQ OASIS).
Запросите у поставщика инструмента ответы на вопросы:
- Какие версии XLIFF инструмент импортирует и экспортирует?
- Поддерживает ли он нужные модули и расширения?
- Сохраняет ли пользовательские элементы и атрибуты после повторного экспорта?
- Как обрабатывает единицы с нетекстовым или бинарным содержимым?
- Какие ограничения размера файла применяются?
- Как ведут себя память переводов и сегментация на длинных единицах?
- Корректно ли отображаются нужные вам языки и направления письма?
После ответов проведите тест на файле, который похож на рабочий: включите заметки, переменные, коды форматирования, целевые языки и расширения, используемые проектом. Успешное открытие простого примера не подтверждает поддержку более сложной структуры.
Расширения и риск потери данных¶
Расширение добавляет к общему формату данные, специфичные для приложения или процесса. Такая возможность полезна, когда ядра XLIFF недостаточно, но каждый дополнительный элемент увеличивает число ситуаций, которые нужно проверить на всём пути передачи.
Инструмент может распознать основную часть файла и проигнорировать неизвестные расширения. В результате файл останется формально пригодным для работы, но дополнительные сведения исчезнут после сохранения. Спецификация XLIFF 2.1 не требует, чтобы обработчики понимали нестандартные расширения; сохранение таких данных зависит от поведения приложения и применимых условий стандарта (XLIFF 2.1).
Если расширения важны, проверяйте их до передачи большого пакета. Создайте небольшой тестовый файл, пройдите полный круговой обмен и сравните неизвестные элементы и атрибуты до и после. Если инструмент не сохраняет их, договоритесь об альтернативном процессе: например, храните исходные данные отдельно и восстанавливайте их при сборке.
Когда XLIFF нужен, а когда стоит выбрать другой путь¶
XLIFF подходит, когда нужно отделить локализуемый текст от исходного формата и передавать его между инструментами или участниками процесса. Формат особенно полезен, если исходный ресурс нельзя напрямую отдать переводчику или если команды используют разные системы.
FAQ OASIS описывает XLIFF как инструментонезависимую спецификацию обмена без потерь, формализованную через XML и схему и допускающую расширения.
Для инженера это означает, что XLIFF помогает стандартизировать границу между извлечением и переводом. Но он не убирает необходимость в парсере исходника, импортёре и проверке сборки. Если проект работает только в одной системе, а эта система надёжно обрабатывает исходный формат напрямую, промежуточный XLIFF может добавить дополнительный шаг без заметной пользы.
Для простой строки в небольшом проекте экспорт и импорт могут быть лишними, особенно если разработчик может передать переводчику компактный ресурс с ясным контекстом. Для большого набора сообщений без идентификаторов и заметок XLIFF тоже не исправит проблемы модели данных: технически корректный файл способен оставаться неудобным для перевода.
Практический выбор можно свести к трём вопросам:
- Есть ли несколько инструментов или участников? XLIFF полезен, когда нужен общий формат передачи между ними.
- Нужно ли сохранять структуру исходного ресурса? Проверьте, поддерживают ли парсер и файл-скелет обратную сборку.
- Совпадают ли версия, схема и расширения у всех систем? Если ответ неизвестен, сначала протестируйте короткий файл.
Что чаще всего ломается¶
Первая ошибка - считать любую поддержку XLIFF одинаковой. Инструмент может импортировать базовую структуру, но не понимать нужный модуль или пользовательские поля. Проверяйте версию и расширения отдельно, а не только наличие пункта «XLIFF» в списке поддерживаемых форматов.
Вторая ошибка - экспортировать строку без описательного идентификатора и рассчитывать, что контекст появится позже. Идентификатор text_42 не объясняет функцию сообщения. Рекомендации Mozilla советуют использовать уникальные и описательные идентификаторы и не объединять строки с разным контекстом (Mozilla Localization).
Третья ошибка - оставить примечание пустым или заменить его повтором исходного текста. Переводчику нужны причины, условия и ограничения: где строка показывается, что означает переменная и какие фрагменты нельзя менять. Microsoft рекомендует включать полезный контекст, в том числе runtime-значения переменных (Microsoft Learn).
Четвёртая ошибка - считать успешную проверку схемы доказательством корректности всего процесса. Схема не проверяет каждый смысловой риск, а спецификация может содержать ограничения, которые не выражаются в XSD. Для XLIFF 2.1 требования включают оба уровня: схему и применимые ограничения документа (XLIFF 2.1).
Пятая ошибка - не проверять локализованный ресурс после сборки. XLIFF хранит данные для обмена, но визуальная проблема может проявиться только в приложении: текст выходит за границы кнопки, перенос меняет смысл или элемент интерфейса неправильно располагается для языка с другим направлением письма. Проверьте целевую раскладку и поведение, а не только содержимое XML (Microsoft Learn).
Шестая ошибка - передавать CAT-инструменту длинные единицы, полагая, что больше контекста всегда лучше. Более крупный фрагмент может дать переводчику связное сообщение, но чрезмерная длина уменьшает вероятность полного совпадения с памятью переводов (Microsoft Learn). Выбирайте границы по смыслу и контексту, а затем проверяйте результат на реальных строках проекта.
Короткий список перед запуском проекта¶
Перед тем как отдавать пакет переводчику, проверьте его по этому списку:
- версия XLIFF и пространство имён совпадают с ожиданиями всех систем;
- схема выбрана для правильной версии и варианта;
- идентификаторы уникальны и объясняют роль строки;
- двусмысленные фразы сопровождаются понятными примечаниями;
- значения переменных и непереводимые фрагменты описаны;
- inline-коды сохранены и могут корректно перемещаться в целевом языке;
- расширения проходят круговой обмен без потерь;
- парсер умеет извлекать нужный исходный формат;
- файл-скелет соответствует версии исходного ресурса;
- локализованный результат проверяется в приложении или макете.
Список не заменяет автоматические тесты, но закрывает основные места, где обычно возникают проблемы между экспортом, переводом и импортом. Сохраните его рядом с конфигурацией фильтра, чтобы проект не зависел от устных договорённостей.
Частые вопросы¶
Что такое файл XLIFF и как он работает в локализации?¶
XLIFF хранит локализуемые данные в XML и передаёт их между этапами локализации и инструментами. Обычно парсер извлекает исходный текст, CAT-инструмент помогает заполнить целевые сегменты, а сборщик возвращает перевод в исходный ресурс.
Чем отличаются XLIFF 1.2, 2.1 и 2.2?¶
Версии различаются структурой документа и правилами валидации. XLIFF 1.2 имеет схемы Transitional и Strict, XLIFF 2.1 требует проверки XML, официальной схемы и ограничений спецификации, а XLIFF 2.2 включает модуль для вариантов множественного числа, рода и выбора.
Как инженеру локализации проверить XLIFF-файл?¶
Определите версию, проверьте XML и примените официальную схему именно этой версии. Затем проверьте требования спецификации, целевые сегменты, коды и расширения, а после импорта соберите ресурс и проверьте его в интерфейсе.
Как работают извлечение и обратная сборка XLIFF?¶
Парсер, который понимает исходный формат, извлекает локализуемое содержимое и формирует XLIFF. После заполнения целевых сегментов импортёр использует файл-скелет или исходный ресурс, чтобы вернуть переведённые строки в локализованный файл.
Что разработчику включать в примечания XLIFF?¶
Добавляйте роль строки в интерфейсе, условия её показа, значение переменных во время выполнения, непереводимые части и контекст, которого не видно из текста. Такие заметки помогают выбрать перевод, который соответствует ситуации, а не только словарному значению.
Как проверить поддержку версии XLIFF в CAT-инструменте?¶
Уточните поддержку конкретной версии, модулей и расширений, а также работу с пользовательскими пространствами имён, бинарными единицами, сложными языками и ограничениями размера файла. Затем проведите тестовый круговой обмен и сравните документ до и после.