Как скомпилировать файлы .po в .mo (4 метода)
Вы провели вторую половину дня, доводя до совершенства перевод на немецкий. Каждая строка в вашем файле de_DE.po выглядит безупречно, заполнители целы, формы множественного числа верны. Вы загружаете его на свой сайт, переключаете язык на немецкий, и... ничего. Страница по-прежнему на английском. Вы перепроверяете имя файла, папку, текстовый домен. Всё выглядит правильно. Так почему же WordPress не показывает ваш перевод?
В девяти случаях из десяти ответ один и тот же: вы отредактировали .po, но так и не скомпилировали его в .mo. WordPress не читает файлы .po во время выполнения — он загружает скомпилированный бинарный файл .mo. Если вы хотите, чтобы ваши переводы действительно отображались, вам нужно компилировать po в mo каждый раз, когда вы меняете текст. .po — это ваш редактируемый источник; .mo — это то, что отображает сайт.
Это руководство объясняет, зачем нужен этот шаг компиляции, а затем описывает четыре надёжных способа сделать это: WP-CLI, классическая команда msgfmt, Poedit и облачный инструмент, который автоматически создает .mo для вас. Мы также рассмотрим самую распространённую ловушку — забывание перекомпиляции — и новый формат .l10n.php, который WordPress теперь предпочитает для скорости.
Почему WordPress загружает .mo, а не .po?
WordPress загружает файлы .mo, потому что это скомпилированные бинарные файлы, оптимизированные для быстрого поиска, тогда как файлы .po — это обычный текст, предназначенный для чтения и редактирования людьми. Разбор текста при каждой загрузке страницы был бы медленным; чтение предварительно созданной бинарной хэш-таблицы почти мгновенно.
Файл .po построен построчно и удобен для человека. Каждая запись сопоставляет исходный msgid с переведенным msgstr, плюс комментарии, указывающие, откуда взялась строка. Это отлично подходит для редактирования, но ужасно для производительности — серверу пришлось бы повторно анализировать весь текстовый файл при каждом запросе.
#: includes/cart.php:88
msgid "Your cart is empty"
msgstr "Ihr Warenkorb ist leer"
Файл .mo упаковывает те же пары строк в бинарный формат с внутренней таблицей поиска, поэтому WordPress может перейти непосредственно к переводу, не сканируя текст. Обратная сторона заключается в том, что .mo нечитабелен для человека и должен быть перегенерирован всякий раз, когда изменяется .po. Если различие между .po и .mo всё ещё неясно, наше объяснение в статье .po vs .mo vs .pot files разбивает каждый формат и объясняет, как они соотносятся.
Четыре способа скомпилировать po в mo
Не существует единственного «правильного» инструмента — лучший выбор зависит от того, как вы уже работаете. Ниже представлены четыре надёжных метода, от однострочной команды до полностью автоматизированного облачного рабочего процесса. Все четыре метода создают идентичный бинарный файл .mo, который WordPress загружает во время выполнения.
Метод 1: WP-CLI
Самый чистый современный подход — это WP-CLI, который может скомпилировать целую папку файлов .po одной командой. Если вы уже управляете WordPress из командной строки, это естественным образом вписывается в ваш рабочий процесс.
# Compile every .po file in the languages folder to .mo
wp i18n make-mo languages/
# Compile into a specific destination directory
wp i18n make-mo languages/ build/languages/
Команда make-mo сканирует целевую директорию, компилирует каждый найденный .po и записывает соответствующий .mo рядом с ним (или в указанное вами место назначения). Она изящно обрабатывает пакеты, что делает её идеальной, когда вы поддерживаете много языков одновременно. Это рекомендуемый инструмент для любого проекта, уже использующего WP-CLI.
Метод 2: msgfmt
Оригинальная утилита Gettext для этой задачи — msgfmt, часть пакета GNU gettext. Она компилирует один .po в один .mo и доступна практически на каждой системе Linux и macOS.
# Compile one file
msgfmt my-plugin-de_DE.po -o my-plugin-de_DE.mo
# Add statistics about translated, fuzzy, and untranslated strings
msgfmt --statistics my-plugin-de_DE.po -o my-plugin-de_DE.mo
# Install it first if missing
# macOS: brew install gettext
# Debian: sudo apt-get install gettext
Флаг -o задаёт имя выходного файла. Флаг --statistics действительно полезен — он сообщает вам, сколько строк переведено, являются нечёткими (fuzzy) или всё ещё пустыми, так что вы можете обнаружить неполный перевод до его выпуска. Для сценариев с одним файлом за раз msgfmt — это надёжный, простой выбор.
Поскольку msgfmt — это простая утилита командной строки, она легко встраивается в автоматизацию. Вы можете обернуть её в цикле оболочки для компиляции целой папки или подключить к конвейеру CI, чтобы каждый коммит, затрагивающий .po, автоматически создавал свежий .mo. Распространённый шаблон: for f in languages/*.po; do msgfmt "$f" -o "${f%.po}.mo"; done, который компилирует каждый язык за один проход. Флаг --check добавляет проверку, выявляя несоответствия в строках формата между msgid и msgstr до того, как они попадут в продакшн — дешёвая защита от ошибок с поломанными заполнителями, которые незаметно портят переведённые макеты.
Метод 3: Poedit (компиляция при сохранении)
Если вы редактируете переводы в графическом редакторе, Poedit компилирует их для вас автоматически. Каждый раз, когда вы сохраняете файл .po, Poedit записывает соответствующий .mo рядом с ним — без отдельной команды, без дополнительного шага.
Это одна из причин, почему Poedit остаётся популярным среди переводчиков, которым неудобно работать с командной строкой. Вы открываете .po, вводите свои переводы, нажимаете «сохранить», и оба файла обновляются одновременно. Вы можете подтвердить это поведение в настройках Poedit, где автоматическая компиляция .mo при сохранении включена по умолчанию. Poedit и аналогичные настольные инструменты рассмотрены в статье top 5 free tools to edit and translate PO files on Mac and Windows.
Недостаток настольного редактора заключается в том, что компиляция происходит только тогда, когда человек открывает файл и сохраняет его. Это подходит для проекта одного человека, но не масштабируется до десятка языков или команды, передающей файлы туда и обратно. Если кто-то редактирует .po в другом инструменте и копирует его в репозиторий, не открывая Poedit, .mo никогда не обновляется. Для более крупных или совместных проектов автоматизированный метод — командная строка или облако — устраняет эту зависимость от необходимости нажимать кнопку «сохранить».
Метод 4: Облачный инструмент, который генерирует .mo для вас
Четвёртый вариант полностью исключает шаг компиляции: используйте облачный сервис, который возвращает скомпилированный .mo вместе с переведённым .po. Вы никогда не запускаете команду и не сохраняете файл дважды — вы загружаете, а в ответ получаете готовые, правильно названные файлы.
SimplePoTranslate работает именно так. Вы загружаете .po или .pot, он переводит строки с помощью Context-Aware AI, и возвращает один ZIP-архив, содержащий .po и .mo, сгенерированные рядом — уже скомпилированные, уже названные в соответствии с вашим текстовым доменом и локалью. Нет отдельного этапа компиляции и нет возможности его забыть.
Он также обрабатывает детали, которые нарушают ручные рабочие процессы. Syntax Locking замораживает заполнители, такие как %s, %1$s и {name}, а также HTML-теги перед переводом, так что ваши переменные остаются нетронутыми в .mo. Полная поддержка Gettext plural означает, что сложные формы множественного числа также компилируются правильно — тема, которую стоит глубоко понять, и которую мы рассматриваем в understanding Gettext plurals. И поскольку он работает в облаке, нет плагина для установки и нет инструментов сборки для обслуживания.
Самая распространённая ошибка: вы забыли перекомпилировать
Самая большая причина, по которой переводы не появляются, — это редактирование .po, но забывание перекомпиляции .mo. WordPress продолжает загружать старый бинарный файл, поэтому ваша новая формулировка никогда не отображается — и нет сообщения об ошибке, которое объяснило бы, почему.
Запомните ментальную модель: .po — это ваш черновик, .mo — это то, что публикуется. Любое изменение в .po невидимо для WordPress, пока вы не перегенерируете .mo. Сделайте перекомпиляцию рефлексом после каждого редактирования или используйте инструмент, который компилирует автоматически, чтобы этот шаг никогда не пропускался.
Эта ловушка особенно коварна при передаче от стейджинга к продакшену. Разработчик редактирует и перекомпилирует локально, видит, что перевод работает, затем развёртывает только .po и забывает .mo — в результате на продакшене молча остаётся старый текст. Всякий раз, когда вы перемещаете файлы перевода между средами, перемещайте .po и свежескомпилированный .mo вместе, или компилируйте их как часть шага развёртывания, чтобы бинарный файл всегда пересоздавался из текущего источника.
Если ваши переводы всё ещё отказываются появляться после перекомпиляции, проблема обычно заключается в несоответствии названий, неправильной папке или слое кеширования, хранящем старый файл. Полный контрольный список находится в статье why your translations are not showing up in WordPress.
Примечание о новом формате .l10n.php
Недавние версии WordPress представили третий формат выполнения: .l10n.php. Вместо бинарного .mo переводы хранятся как простой PHP-массив, который PHP-кеш опкодов может удерживать в памяти, что делает поиск ещё быстрее, чем .mo на загруженных сайтах.
<?php
return [
'domain' => 'my-plugin',
'messages' => [ 'Your cart is empty' => 'Ihr Warenkorb ist leer' ],
];
WordPress автоматически генерирует файлы .l10n.php, когда у него есть соответствующий .mo, поэтому вам не нужно создавать их вручную. На данный момент компиляция правильного .mo остаётся основой — формат производительности выводится из него.
Подведение итогов
Чтобы надёжно скомпилировать po в mo, выберите метод, который соответствует вашему стилю работы: WP-CLI для пакетной обработки в командной строке, msgfmt для отдельных файлов со статистикой, Poedit для автоматической компиляции при сохранении или облачный инструмент, который создаёт .mo для вас, чтобы этот шаг никогда не пропускался. Все четыре метода создают тот же бинарный файл, который WordPress нуждается во время выполнения.
Какой бы путь вы ни выбрали, помните золотое правило: редактируйте .po, затем компилируйте в .mo — каждый раз. Эта привычка предотвращает самую досадную ошибку перевода в WordPress, ту, при которой всё выглядит правильно, но сайт упорно остаётся на английском.
Готовы навсегда пропустить шаг ручной компиляции? Попробуйте SimplePoTranslate бесплатно — кредитная карта не требуется. Загрузите свой
.poи скачайте готовый к развёртыванию пакет.po+.moна бесплатном тарифе за считанные минуты.