.po проти .mo проти .pot: Пояснення файлів перекладу WordPress

Відкриваючи теку languages теми WordPress, ви знаходите три майже ідентичні файли: twentytwentyfour.pot, twentytwentyfour-de_DE.po та twentytwentyfour-de_DE.mo. Одна й та сама тема, одна й та сама мова, три різні розширення. Який з них редагувати? Який насправді завантажує WordPress? І чому редагування неправильного файлу призводить до непомітного зникнення ваших перекладів?

Якщо ви коли-небудь запитували, який файл має значення в дискусії про файли .po проти .mo, ви не самотні. Ці три розширення є основою кожного перекладеного сайту WordPress, проте різниця між ними спантеличує як новачків, так і досвідчених розробників. Відредагуйте неправильний файл, і ваші німецькі відвідувачі все одно бачитимуть англійську. Відредагуйте правильний, але пропустіть крок, і нічого також не зміниться.

Цей посібник пояснює, що саме собою являють файли .pot, .po та .mo, як вони пов'язані в робочому процесі GNU Gettext, де вони знаходяться у WordPress і чому ви ніколи не повинні відкривати файл .mo у текстовому редакторі. Зрештою ви знатимете, який файл чіпати, а який залишити в спокої.

Що таке файли .pot, .po та .mo?

Коротко: файл .pot – це порожній шаблон, файл .po – ваш редагований переклад, а файл .mo – це скомпільований бінарний файл, який WordPress зчитує під час виконання. Вони утворюють ланцюжок, і кожна ланка має рівно одне завдання.

Усі ці три формати походять від GNU Gettext – системи локалізації, на яку покладаються WordPress, Drupal та тисячі PHP- і C-проєктів. Gettext відокремлює вихідні рядки, написані розробником, від перекладів, наданих перекладачем, завдяки чому одна й та сама кодова база може підтримувати десятки мов, не торкаючись жодного рядка PHP.

Уявіть це як картку з рецептом. .pot – це порожня картка з полями для інгредієнтів, але без кількості. .po – це картка, заповнена для однієї конкретної страви. .mo – це заламінована, машинозчитувана копія, яку кухня фактично використовує під час обслуговування. Ви пишете на паперовій картці; ви ніколи не каракулюєте на заламінованій.

Файл .pot: Головний шаблон

Файл .pot (Portable Object Template) містить кожен рядок, що підлягає перекладу, в темі або плагіні, причому переклади залишаються порожніми. Це головний список, який розробники постачають, щоб перекладачі точно знали, що потрібно перекладати. Рядки msgstr порожні, оскільки мова ще не була обрана.

#: includes/checkout.php:42
msgid "Add to Cart"
msgstr ""

#: includes/account.php:108
msgid "Your order has been shipped to %s"
msgstr ""

Зверніть увагу на порожній msgstr "". Файл .pot — це шаблон, а не переклад. Ви копіюєте його один раз для кожної мови та заповнюєте прогалини. Ви рідко редагуєте .pot вручну; він генерується з вихідного коду щоразу, коли змінюються рядки.

Файл .po: Ваш редагований людиною переклад

Файл .po (Portable Object) — це копія файлу .pot із заповненими рядками msgstr для однієї мови. Це файл, який фактично редагують перекладачі та розробники. Він є простим текстовим, читабельним для людини та зручним для систем контролю версій.

#: includes/checkout.php:42
msgid "Add to Cart"
msgstr "In den Warenkorb"

#: includes/account.php:108
msgid "Your order has been shipped to %s"
msgstr "Ihre Bestellung wurde an %s versandt"

msgid — це оригінальний англійський вихідний рядок, який ніколи не повинен змінюватися. msgstr — це ваш переклад. %s — це заповнювач, який повинен залишитися незмінним у перекладі — його видалення або зміна порядку є найпоширенішою причиною порушення макетів, що ми детально розглядаємо в як перекладати файли PO, не порушуючи кодові змінні.

Файл .mo: Скомпільований бінарний файл

Файл .mo (Machine Object) — це скомпільована, бінарна версія вашого .po. WordPress не може ефективно читати файли .po під час виконання, тому замість них завантажує попередньо скомпільований .mo. Відкриття .mo у текстовому редакторі показує нечитабельні байти — він призначений для машин, а не для людей.

Коли WordPress викликає load_textdomain() або load_theme_textdomain(), він шукає файл .mo, аналізує його бінарну хеш-таблицю та замінює кожен msgid відповідним msgstr на льоту. Цей бінарний формат робить пошук швидким навіть на сайтах з тисячами рядків.

Як ці три файли пов'язані в робочому процесі Gettext?

Вони утворюють односпрямований конвеєр: вихідний код стає .pot, .pot стає .po для кожної мови, і кожен .po компілюється в .mo. Переклади завжди рухаються вниз.

Ось повний життєвий цикл по порядку:

1. Розробник загортає рядки, що відображаються користувачам, у функції Gettext, такі як __() та _e(), всередині вихідного коду PHP.
2. Інструмент сканування читає вихідний код і генерує шаблон .pot, що містить кожен загорнутий рядок.
3. Перекладач копіює .pot у .po для певної мови (наприклад, de_DE.po) і заповнює кожен msgstr.
4. Готовий .po компілюється в бінарний .mo.
5. WordPress завантажує .mo під час виконання та відображає перекладений сайт.

Коли розробник пізніше додає нові рядки, .pot регенерується, нові записи об'єднуються з кожним існуючим .po (зберігаючи старі переклади), перекладач заповнює прогалини, а .po перекомпільовується в .mo. Цей цикл повторюється протягом усього терміну життя проєкту.

Ключовий висновок: ви редагуєте .po, а потім компілюєте в .mo. Ви ніколи не редагуєте .mo безпосередньо і ніколи не перекладаєте всередині .pot. Якщо ви хочете отримати глибшу картину всього процесу, вичерпний посібник з локалізації WordPress покаже весь конвеєр з прикладами.

Угоди про іменування та розташування файлів

WordPress суворо ставиться до імен файлів. Якщо ви неправильно назвете файл, ваш ідеально перекладений .mo буде просто проігнорований, оскільки WordPress шукає точну відповідність на основі текстового домену та локалі.

Схема іменування для перекладів тем та плагінів:

# Pattern: textdomain-locale.po / .mo
twentytwentyfour-de_DE.po      # German (Germany) translation
twentytwentyfour-de_DE.mo      # compiled binary WordPress loads
twentytwentyfour-fr_FR.po      # French (France)
twentytwentyfour.pot           # template, no locale suffix

textdomain відповідає рядку, переданому як другий аргумент функціям Gettext, таким як __( 'Add to Cart', 'twentytwentyfour' ). locale — це код локалі WordPress, такий як de_DE, fr_FR або pt_BR. Шаблон .pot не має суфікса локалі, оскільки він мовно-нейтральний.

Розташування має таке ж значення, як і іменування. WordPress шукає в кількох передбачуваних шляхах:

• Переклади тем постачаються у власній папці теми wp-content/themes/your-theme/languages/.
• Переклади плагінів постачаються в wp-content/plugins/your-plugin/languages/.
• Переклади з translate.wordpress.org та користувацькі перевизначення потрапляють до глобальних каталогів wp-content/languages/themes/ та wp-content/languages/plugins/, які мають пріоритет та зберігаються після оновлень.

Помістіть правильно названий de_DE.mo у потрібну папку, і німецькі відвідувачі бачитимуть німецький текст. Помістіть його на одну папку занадто глибоко або неправильно напишіть текстовий домен, і WordPress тихо повернеться до англійської мови без повідомлення про помилку. Якщо ваші переклади не відображаються, звичайним винуватцем є невідповідність імені або шляху, а посібник з усунення несправностей для відсутніх перекладів охоплює кожну поширену причину.

Чому ви ніколи не повинні редагувати файл .mo безпосередньо

Оскільки .mo є скомпільованим бінарним файлом, немає безпечного способу редагувати його вручну — і будь-яка зміна, яку ви внесете, буде перезаписана наступного разу, коли .po буде перекомпільовано. .po є джерелом істини; .mo — це одноразовий артефакт збірки.

Це єдине правило пояснює значну частку звернень до служби підтримки на кшталт «мій переклад змінився, але сайт не оновився». Хтось змінює рядок, зберігає .po і забуває перекомпілювати .mo. WordPress продовжує завантажувати старий бінарний файл, тому нове формулювання ніколи не з'являється. Виправлення завжди полягає в: редагуванні .po, перекомпіляції в .mo, перезавантаженні.

Існує ще одна причина, чому це правило має значення: файли .mo не зручні для порівняння у системі контролю версій. Оскільки вони бінарні, крихітна зміна формулювання створює непрозорий блок у вашій історії Git, який жоден рецензент не може прочитати. Збереження .po як відстежуваного джерела істини та розгляд .mo як згенерованого артефакту робить ваш репозиторій придатним для перегляду, а ваші переклади – для аудиту.

Виконувати це вручну для десятків мов виснажливо та схильне до помилок. Ось тут хмарний робочий процес економить реальний час. Інструменти, такі як SimplePoTranslate, перекладають ваші рядки .po та повертають єдиний ZIP-архів, що містить відповідні .po та .mo разом — вже скомпільовані, правильно названі, готові для розміщення в wp-content/languages/. Не потрібно нічого компілювати вручну, і немає шансів отримати застарілий .mo.

Він також застосовує Syntax Locking, що блокує кожен заповнювач, як %s, %1$s та {name}, а також HTML-теги, перед перекладом. Ваші змінні залишаються неушкодженими, тому ви ніколи не випустите .mo, який порушує макет. А оскільки він працює повністю в хмарі, немає додаткового плагіна, який обтяжує ваш сайт — ви завантажуєте файл і завантажуєте готові, скомпільовані переклади.

Підсумовуючи

Як тільки розрізнення файлів .po проти .mo стає зрозумілим, вся система перекладу WordPress перестає здаватися загадковою. .pot — це шаблон розробника, .po — це редагована робоча копія перекладача, а .mo — це скомпільований бінарний файл, який WordPress фактично надає відвідувачам. Переклади надходять в одному напрямку — від шаблону до .po до .mo — і ви завжди редагуєте лише середній файл вручну.

Пам'ятайте три правила, які запобігають дев'яноста відсоткам проблем з перекладом: ніколи не перекладайте всередині .pot, завжди перекомпілюйте .mo після редагування .po, і точно дотримуйтесь іменування textdomain-locale. Дотримуйтесь цих правил, і ваші перекладені рядки з'являтимуться щоразу.

Готові припинити боротися з ручною компіляцією та іменуванням файлів перекладу? Спробуйте SimplePoTranslate безкоштовно — кредитна картка не потрібна. Завантажте свій .po або .pot і отримайте готовий до використання пакет .po + .mo на безкоштовному тарифі за лічені хвилини.