Форматы обмена локализационными данными используются как промежуточное звено между системой управления переводами, переводчиками и приложением на JavaScript с i18next. Их задача — обеспечить переносимость строк, сохранение контекста, поддержку метаданных (комментариев, описаний, состояния перевода) и возможность автоматизированной синхронизации переводов.
В экосистеме i18next такие форматы применяются на этапах экспорта и импорта ресурсов, а не в runtime приложения. Основной формат выполнения в приложении — JSON, однако XLIFF, PO и CSV широко используются как транспортные представления данных.
В типичной i18n-пайплайне присутствуют следующие этапы:
Форматы XLIFF, PO и CSV занимают промежуточный слой между JSON-ресурсами i18next и внешними инструментами локализации.
Ключевая задача этих форматов:
XLIFF представляет собой XML-ориентированный стандарт, предназначенный для профессиональных систем локализации. Он используется в крупных проектах, где требуется строгая структура и расширенные метаданные.
Базовая структура версии 1.2:
<xliff version="1.2">
<file source-language="en" target-language="ru" datatype="plaintext">
<body>
<trans-unit id="welcome.message">
<source>Welcome</source>
<target>Добро пожаловать</target>
</trans-unit>
</body>
</file>
</xliff>В XLIFF 2.0 структура становится более модульной:
<xliff version="2.0">
<file id="f1" srcLang="en" trgLang="ru">
<unit id="welcome.message">
<segment>
<source>Welcome</source>
<target>Добро пожаловать</target>
</segment>
</unit>
</file>
</xliff>XLIFF поддерживает:
Пример с метаданными:
<trans-unit id="button.save">
<source>Save</source>
<target state="translated">Сохранить</target>
<note>Кнопка сохранения формы</note>
</trans-unit>В экосистеме JavaScript XLIFF чаще используется через промежуточные инструменты:
Типичный процесс:
Формат PO происходит из системы gettext и широко применяется в UNIX-подобных экосистемах. Он текстовый, компактный и ориентирован на пары ключ-значение.
msgid "Welcome"
msgstr "Добро пожаловать"В контексте ключей i18next:
msgid "button.save"
msgstr "Сохранить"Файл содержит метаданные:
msgid ""
msgstr ""
"Project-Id-Version: app 1.0\n"
"Language: ru\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"PO имеет встроенную поддержку плюрализации:
msgid "item"
msgid_plural "items"
msgstr[0] "элемент"
msgstr[1] "элемента"
msgstr[2] "элементов"Это особенно важно при интеграции с i18next, где plural rules зависят от языка и CLDR-таблиц.
#. Button label in form
msgid "Submit"
msgstr "Отправить"Контекст:
msgctxt "form.button"
msgid "Submit"
msgstr "Отправить"i18next напрямую PO не использует, однако существует ряд мостов:
Типичная схема:
PO → JSON → i18next resources
CSV представляет собой табличный формат, используемый как упрощённый способ обмена переводами. Он применяется в небольших проектах или как промежуточный экспорт для несложных систем.
key,en,ru
welcome.message,Welcome,Добро пожаловать
button.save,Save,СохранитьКаждая строка соответствует ключу локализации.
key,source,translation,context
button.save,Save,Сохранить,Form buttonCSV плохо приспособлен к сложным формам множественного числа. Обычно применяются отдельные колонки:
key,one,few,many
item,элемент,элемента,элементовОднако такая модель не универсальна и требует адаптации под конкретную plural-логику i18next.
CSV используется через вспомогательные инструменты:
Процесс обычно включает:
В связке с i18next обычно используется слой трансформации ресурсов:
Используется для передачи данных в профессиональные TMS:
i18next использует ключевую модель:
{
"button": {
"save": "Save"
}
}В форматах обмена:
button.save → trans-unitmsgid "button.save"В XLIFF:
<trans-unit id="common.button.save">В PO:
msgid "common.button.save"В CSV:
key,common.button.save,...i18next использует ICU-подобные правила или встроенные plural rules:
{
"item": "{{count}} item",
"item_plural": "{{count}} items"
}В форматах обмена это трансформируется:
CSV и частично PO не сохраняют UI-контекст, что приводит к неоднозначности переводов.
При преобразовании JSON → PO возможны дубли msgid при неправильной нормализации namespace.
CSV не имеет стандарта plural rules, что требует ручной адаптации.
При росте проекта выбор формата влияет на:
XLIFF применяется в корпоративных системах, PO — в open-source и UNIX-средах, CSV — в упрощённых или административных интерфейсах.