Один файл на входе, пять форматов на выходе: как обеспечить перспективность ваших WordPress-переводов

Вы потратили три недели на перевод своей WordPress-темы на испанский язык. Файл .po идеален — каждая строка проверена, каждая переменная не повреждена, каждая форма множественного числа верна. Затем ваш клиент решает перейти с классической PHP-темы на headless-архитектуру с React на внешнем интерфейсе.

Внезапно ваш файл .po становится бесполезным. Приложению React нужен формат .json. Устаревшим PHP-виджетам по-прежнему нужен .mo. Фрилансер, занимающийся мобильным приложением, хочет .xliff. И ни у кого нет времени переводить 4000 строк в три разных формата.

Это не исключительный случай. Это реальность современной разработки WordPress, где темы поставляются как с PHP, так и с JavaScript-компонентами, плагины используют смесь Gettext и i18next, а клиенты меняют свое мнение об архитектуре чаще, чем свои пароли.

Почему форматы файлов перевода важны как никогда

Пять лет назад перевод WordPress был прост. У вас был файл .po (человекочитаемый источник) и файл .mo (скомпилированный бинарный файл). Это все. Каждая тема, каждый плагин, каждый инструмент перевода говорили на одном языке.

Сегодня в экосистеме WordPress используется как минимум пять форматов файлов перевода в production:

Пять форматов, которые вам нужно знать

.po (Portable Object) — человекочитаемый исходный формат, используемый GNU Gettext. Содержит исходные строки (msgid) и их переводы (msgstr). Это то, что редактируют переводчики.

msgid "Add to Cart"
msgstr "Anadir al carrito"

msgid "Your order has been shipped to %s"
msgstr "Su pedido ha sido enviado a %s"

.mo (Machine Object) — скомпилированная бинарная версия файла .po. WordPress читает файлы .mo во время выполнения, используя load_textdomain(). Быстрее, чем разбор .po во время выполнения, но не редактируется человеком.

.json (JavaScript Object Notation) — используется wp_set_script_translations() для переводов на основе JavaScript в блоках Gutenberg, компонентах React и современных темах. WordPress ожидает определенную структуру JSON с ключами locale_data.

{
  "locale_data": {
    "flavor-starter": {
      "Add to Cart": ["Anadir al carrito"],
      "Your order has been shipped to %s": ["Su pedido ha sido enviado a %s"]
    }
  }
}

.php (PHP Array) — все более популярный формат для тем и плагинов, которые используют загрузку переводов в стиле Laravel. Некоторые современные темы WordPress полностью обходят Gettext и загружают переводы из массивов PHP для повышения производительности.

<?php
return [
    'Add to Cart' => 'Anadir al carrito',
    'Your order has been shipped to %s' => 'Su pedido ha sido enviado a %s',
];

.xliff (XML Localization Interchange File Format) — отраслевой стандарт для обмена переводами между различными инструментами и платформами. Используется CAT (Computer-Assisted Translation) инструментами, такими как memoQ, Trados и Memsource. Необходим при работе с профессиональными переводчиками.

<trans-unit id="1">
  <source>Add to Cart</source>
  <target>Anadir al carrito</target>
</trans-unit>

Проблема: привязка к формату

Большинство инструментов перевода создают один выходной формат. Poedit дает вам .po и .mo. WPML хранит переводы в базе данных (вообще не в файлах). Weglot хранит переводы на своих серверах в проприетарном формате. Даже TMS-платформы, такие как Crowdin и Lokalise, требуют ручной настройки форматов экспорта для каждого проекта.

Это создает привязку к формату — ваши переводы оказываются в ловушке того формата, который создает ваш текущий инструмент. Когда ваши требования меняются, вы сталкиваетесь с двумя вариантами:

1. Перевести все заново в новом формате (дорого, отнимает много времени, и вы теряете любые ручные исправления).
2. Написать собственные скрипты преобразования (чревато ошибками, особенно для сложных форм множественного числа и переменных).

Ни один из вариантов не является хорошим. Оба тратят время и деньги. Оба создают риск.

Реальные сценарии, когда привязка к формату вредит

Сценарий 1: Модернизация темы. Тема вашего клиента перестраивается с помощью блоков Gutenberg. Старые PHP-шаблоны использовали файлы .mo. Новым блокам нужен .json для wp_set_script_translations(). Ваши 3000 переведенных строк должны существовать в обоих форматах во время перехода.

Сценарий 2: Рабочий процесс агентства. Вы управляете 20 сайтами клиентов. Некоторые используют классические темы (.mo). Некоторые используют headless-архитектуру (.json). Один использует пользовательский фреймворк, который читает массивы PHP. Вам нужны одни и те же переводы в разных форматах для разных клиентов.

Сценарий 3: Профессиональная проверка. Ваши AI-переводы точны на 95%, но вы хотите, чтобы носитель языка проверил оставшиеся 5%. Профессиональные переводчики используют CAT-инструменты, которые импортируют .xliff. Вам нужно экспортировать свои переводы в .xliff, отправить их на проверку и объединить исправления обратно.

Сценарий 4: Перенос платформы. Ваш клиент переходит с WordPress на пользовательское приложение Node.js. Новое приложение использует i18next и нуждается в файлах .json. Ваши 5000 переведенных строк в формате .po необходимо преобразовать — не потеряв ни одной переменной или формы множественного числа.

Решение: переведите один раз, получите каждый формат

SimplePoTranslate использует другой подход. Когда вы загружаете файл .po, .pot, .json или .xliff и запускаете перевод, вы получаете обратно ZIP-архив, содержащий все пять форматов:

translations-es_ES.zip
├── flavor-starter-es_ES.po
├── flavor-starter-es_ES.mo
├── flavor-starter-es_ES.json
├── flavor-starter-es_ES.php
└── flavor-starter-es_ES.xliff

Это не «премиум-функция», заблокированная за корпоративным уровнем. Каждый платный тарифный план — Pro (19 долларов в месяц) и Lifetime (399 долларов единовременно) — включает в себя все пять выходных форматов в каждом задании перевода.

Почему это важно для обеспечения перспективности

Когда у вас есть все пять форматов с самого начала, вам никогда не придется переводить заново. Ваши переводы — это актив, который адаптируется к любым техническим требованиям:

• Клиент переходит с классической версии на Gutenberg? Разверните файл .json.
• Новый разработчик предпочитает массивы PHP? Передайте им файл .php.
• Профессиональный переводчик хочет проверить? Отправьте файл .xliff.
• Переход на другую CMS? Файлы .json и .xliff не зависят от платформы.

Вы переводите один раз. Форматы готовы, когда они вам понадобятся.

Как каждый формат работает в WordPress

Знание того, какой файл куда идет, необходимо для чистого развертывания.

Развертывание файлов .mo (классические PHP-темы и плагины)

wp-content/languages/plugins/woocommerce-es_ES.mo
wp-content/languages/themes/flavor-starter-es_ES.mo

WordPress загружает их автоматически, когда язык сайта совпадает. Плагин не требуется. Нулевая нагрузка на базу данных. Это подход, который обеспечивает лучшую производительность.

Развертывание файлов .json (блоки Gutenberg и JS-компоненты)

wp-content/languages/plugins/woocommerce-es_ES-{handle}-{md5}.json

Имя файла включает дескриптор скрипта и хеш MD5. WordPress сопоставляет их, когда вы вызываете wp_set_script_translations() в своем плагине или теме. Если вы создаете блоки Gutenberg, это файл, который обеспечивает правильное отображение переведенных меток и описаний блоков.

Использование файлов .xliff (рабочий процесс профессиональной проверки)

Файлы .xliff не развертываются в WordPress. Они используются в качестве формата обмена, когда вам нужно отправить переводы профессиональному рецензенту или импортировать их в CAT-инструмент. Рабочий процесс выглядит следующим образом:

1. Загрузите .po в SimplePoTranslate и получите .xliff в ZIP-архиве.
2. Отправьте .xliff своему переводчику или рецензенту.
3. Получите исправленный .xliff обратно.
4. Загрузите исправленный .xliff в SimplePoTranslate и получите обновленные .mo и .json.

Этот сквозной рабочий процесс сохраняет каждую переменную и форму множественного числа, поскольку блокировка синтаксиса SimplePoTranslate защищает их на каждом этапе.

Тест на привязку к поставщику

Вот простой тест, чтобы определить, есть ли у вашего текущего рабочего процесса перевода проблема привязки:

1. Можете ли вы экспортировать свои переводы как стандартные файлы .po прямо сейчас?
2. Если вы отмените подписку на свой инструмент перевода сегодня, сохраните ли вы каждую переведенную строку?
3. Можете ли вы импортировать свои переводы в совершенно другой инструмент или платформу без повторного перевода?

Если ответ на любой из этих вопросов — «нет», вы заблокированы. Сервисы, такие как Weglot и GTranslate, проваливают все три вопроса — отмените подписку, и ваши переводы исчезнут. WPML хранит переводы в базе данных, что делает экспорт возможным, но болезненным. Даже настольные инструменты, такие как Poedit, проходят тест на бумаге, но ограничивают вас только .po и .mo.

С SimplePoTranslate ответ на все три вопроса — «да». Вы загружаете стандартные файлы в пяти форматах. Они твои. Удалите свою учетную запись завтра, и каждый перевод, который вы когда-либо делали, все равно будет работать.

Создание не зависящей от формата библиотеки переводов

Для агентств и разработчиков, управляющих несколькими проектами, самый разумный подход — создать библиотеку переводов — репозиторий Git или общую папку, в которой хранятся переведенные файлы для каждого проекта клиента.

translations/
├── client-acme/
│   ├── es_ES/
│   │   ├── flavor-starter-es_ES.po
│   │   ├── flavor-starter-es_ES.mo
│   │   ├── flavor-starter-es_ES.json
│   │   ├── flavor-starter-es_ES.php
│   │   └── flavor-starter-es_ES.xliff
│   └── de_DE/
│       └── ...
├── client-globex/
│   └── ...

Когда клиенту нужен новый формат, он у вас уже есть. Когда клиент меняет платформы, ваши переводы переносятся без каких-либо усилий. Когда новый разработчик присоединяется к команде, он может точно видеть, что было переведено и в каких форматах.

Это то, что на самом деле означает «перспективный» — не предсказывать, какую технологию ваши клиенты будут использовать в следующем году, а убедиться, что ваши переводы работают с тем, что они выберут.

Готовы перестать беспокоиться о форматах файлов? Попробуйте SimplePoTranslate бесплатно — загрузите один файл, получите пять форматов обратно. Никаких скриптов преобразования, никакого повторного перевода, никакой блокировки.