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

Ви витратили три тижні на переклад вашої WordPress-теми іспанською мовою. Файл .po ідеальний — кожен рядок перевірено, кожна змінна ціла, кожна форма множини правильна. Потім ваш клієнт вирішує перейти з класичної PHP-теми на headless setup з React на зовнішньому інтерфейсі.

Раптом ваш .po файл стає марним. React-додатку потрібен .json. Застарілим PHP-віджетам все ще потрібен .mo. Фрілансер, який займається мобільним додатком, хоче .xliff. І ні в кого немає часу перекладати 4000 рядків у трьох різних форматах.

Це не винятковий випадок. Це реальність сучасної WordPress-розробки, де теми постачаються як з PHP, так і з JavaScript-компонентами, плагіни використовують суміш Gettext та i18next, а клієнти змінюють свою думку про архітектуру частіше, ніж змінюють свої паролі.

Чому формати файлів перекладу важливіші, ніж будь-коли

П'ять років тому переклад WordPress був простим. У вас був файл .po (читабельний вихідний код) і файл .mo (скомпільований бінарний файл). Це було все. Кожна тема, кожен плагін, кожен інструмент перекладу говорили однією мовою.

Сьогодні екосистема WordPress використовує щонайменше п'ять форматів файлів перекладу у виробництві:

П'ять форматів, які вам потрібно знати

.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 setup (.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 безкоштовно — завантажте один файл, отримайте п'ять форматів назад. Жодних скриптів перетворення, жодного перекладу заново, жодної прив'язки.