Как сделать WordPress-плагин готовым к переводу?

13 янв. 2013 г., 01:03:01
Просмотры: 16.8K
Голосов: 24

Какой лучший способ создать плагин, готовый к переводу?

Не обязательно, чтобы он был переведен изначально, но он должен быть легко переводимым, чтобы разработчики из разных стран могли участвовать в процессе локализации плагина.

0
Все ответы на вопрос 2
2
45

1. Пишите с учетом локализации

Не используйте echo или print() для вывода текста, вместо этого применяйте функции WordPress __() и _e():

/** Не дружелюбно к локализации */
echo "Добро пожаловать в мой плагин";    
// ИЛИ
print("Добро пожаловать в мой плагин");

/** Дружелюбно к локализации */
_e('Добро пожаловать в мой плагин', 'my-plugin');
// ИЛИ
$my_text = __('Добро пожаловать в мой плагин', 'my-plugin');
echo $my_text;

_e() и __() предоставят перевод — на текущем языке — текста, переданного в первом параметре. _e() выведет текст, тогда как __() вернет его.

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

Как вывести динамический текст, например: "Привет, <имя пользователя>"?

С помощью __() и sprintf():

/** Получаем имя пользователя */
$username = 'Magictrick';

/** Не дружелюбно к локализации */
echo "Привет, $username";     

/** Дружелюбно к локализации */
printf(__('Привет, %s', 'my-plugin'), $username);
// ИЛИ 
$my_text = sprintf(__('Привет, %s', 'my-plugin'), $username);
echo $my_text;

2. Подготовка файлов .pot/.po/.mo

Определения

  • Файл .pot: предоставляется разработчиком плагина и используется как основа для создания новых переводов. WordPress его не использует.
  • Файл .po: файл перевода, который вы или кто-то другой начали и, возможно, завершили. WordPress его не использует.
  • Файл .mo: автоматически создается Poedit при сохранении .po файла. Вы можете только загружать или перезагружать эти файлы при создании или обновлении .po файла. WordPress берет переводы из .mo файлов.

Откройте Poedit и создайте новый каталог (Файл › Новый каталог...) с такими настройками:

  • Информация о проекте: используйте ваши (или вашей команды) данные, язык и страна должны соответствовать языку плагина по умолчанию
  • Пути:
    • Базовый путь: .
    • Пути : удалите все и добавьте .., (мы будем хранить языковые файлы в поддиректории плагина languages)
  • Ключевые слова : удалите все и добавьте __ и _e

Сохраните каталог как /my_wordpress_blog/wp-content/plugins/my-plugin/languages/<strong>my-plugin.pot</strong> и просканируйте файлы плагина на предмет переводимого текста, нажав кнопку обновления. Когда обновление завершится, закройте каталог — он вам больше не понадобится, пока вы не добавите новые строки для перевода (т.е. заключенные в __() или _e()) в ваш плагин.

Теперь создадим первый перевод (я использую fr_FR):

В Poedit создайте каталог из POT файла (Файл › Новый каталог из POT файла...):

  • Информация о проекте: используйте ваши (или вашей команды) данные, измените язык и страну, я буду использовать французский и Францию
  • Пути: не меняйте
  • Ключевые слова : не меняйте

Сохраните каталог как /my_wordpress_blog/wp-content/plugins/my-plugin/languages/<strong>my-plugin-fr_FR.po</strong>. Переведите некоторые или все строки, сохраните .po файл снова, загрузите оба файла .po и .mo.

Обратите внимание, что при сохранении .po файла автоматически генерируется .mo файл с тем же именем. Имя .po файла критично важно, оно состоит из текстового домена плагина (my-plugin) и локали языка (fr_FR). Всегда называйте .po файлы для плагинов так: [текстовый домен]-[локаль].po, вот несколько примеров:

  • Итальянский/Италия: wpcf7-it_IT.po
  • Португальский/Бразилия: wpcf7-pt_BR.po
  • Арабский: wpcf7-ar.po... Да!

Когда плагин обновляется новым текстом, обновите .po файл, переведите новые строки и перезагрузите .po и .mo файлы

3. Настройте загрузку переводов для текущего языка

Где-то в вашем плагине вы должны указать WordPress использовать ваш .mo файл, это можно сделать с помощью такого кода в начале файла плагина:

function my_plugin_init() {
  load_plugin_textdomain( 'my-plugin', false, 'my-plugin/languages' );
}
add_action('init', 'my_plugin_init');

Замените my-plugin на имя вашего плагина в 1-м и 3-м параметрах функции load_plugin_textdomain.

4. Тестирование и устранение проблем

Некоторые причины, по которым это может не работать:

  • Строки не импортированы в .pot или .po файл
    • → Неправильные настройки каталога (путь или ключевые слова или оба)
  • Текст не переводится на сайте WordPress
    • → .mo файл для этого языка отсутствует или имеет неправильное имя
    • → Текстовый домен не используется (замените _e('мой текст') на _e('мой текст', 'my-plugin'))
    • → Текстовый домен не загружен (используйте пример выше с правильными параметрами, WP не предупредит об ошибках)
13 янв. 2013 г. 01:03:01
Комментарии

+1 Отличная статья :) Посмотрите эту статью: Правильная загрузка языковых файлов в WordPress, "Практические рекомендации по упрощению загрузки языковых файлов в WordPress". :::::: Также стоит упомянуть Glotpress и группу Polyglots.

brasofilo brasofilo
13 янв. 2013 г. 02:27:48

Спасибо за эту полезную инструкцию! Стоит отметить, что load_plugin_textdomain() нужно вызывать в каждом методе, где вы используете _e() и __()

Andreas Andreas
8 мая 2013 г. 08:40:52
3

Ответ Набиля довольно полный, но есть более простая вариация:

  1. Ваш плагин находится в репозитории плагинов WordPress.org

  2. Вы готовы требовать, чтобы ваш плагин работал только с WordPress 4.6 или выше.

Шаги следующие:

  1. В файле readme.txt вашего плагина добавьте Requires at least: 4.6. См. https://developer.wordpress.org/plugins/wordpress-org/how-your-readme-txt-works/

  2. Если его еще нет, загрузите ваш плагин в репозиторий плагинов WordPress. См. https://wordpress.org/plugins/developers/add/.

  3. Найдите slug/текстовый домен вашего плагина. Для этого перейдите на страницу вашего плагина в репозитории WordPress. URL будет выглядеть как https://wordpress.org/plugins/your-plugin-slug/. Последняя часть URL, «your-plugin-slug», это slug вашего плагина. Это то, что вы используете в качестве текстового домена для функций перевода.

  4. Используйте функции перевода WordPress в вашем плагине (например, __e(‘hello’, ‘my-plugin-domain’);). Просто убедитесь, что используете правильный текстовый домен плагина, полученный на предыдущем шаге. Подробнее см. https://developer.wordpress.org/plugins/internationalization/how-to-internationalize-your-plugin/.

Если вы выполните вышеуказанные шаги, WordPress позаботится о:

  • Анализе вашего плагина на наличие всех переводимых строк (нет необходимости устанавливать и запускать Poedit или что-то подобное)
  • Обеспечении простоты для всех желающих внести свой вклад в перевод вашего плагина на translate.wordpress.org (нет необходимости иметь собственный сайт для перевода вашего плагина или создавать пользовательский процесс для отправки переводов вам)
  • Когда кто-то использует ваш плагин, WordPress автоматически проверит, есть ли перевод на их язык, и если да, отобразит его на их языке (нет необходимости загружать файлы перевода на их сайт)

(Ответ из моего поста в блоге: https://cmljnelson.blog/2019/01/01/the-really-lazy-way-to-translate-a-wordpress-plugin/)

6 янв. 2019 г. 04:26:03
Комментарии

Не уверен, почему это получило минусы. Именно так я сделал плагин https://wordpress.org/plugins/print-my-blog/ готовым к переводу (и плагин был успешно переведён).

thespacecamel thespacecamel
25 мар. 2019 г. 03:21:16

Значит ли это, что если плагин/тема не находится в репозитории WordPress, но использует текстовый домен плагина оттуда, WordPress загрузит неправильные файлы перевода?

bodo bodo
14 апр. 2019 г. 12:40:01

Хороший вопрос, @bodo. Если плагин указывает использовать текстовый домен другого плагина из репозитория wp.org, я думаю, WordPress без проблем использует файлы перевода этого плагина с wp.org. Но, к сожалению, я не уверен.

thespacecamel thespacecamel
24 апр. 2019 г. 01:51:15