Функция load_plugin_textdomain не работает с add_action plugins_loaded.

Вопрос или проблема

Я пытаюсь загрузить локализацию для моего плагина.

В папке моего плагина есть директория languages, содержащая файлы .po и .mo.

У меня есть следующий код в основном файле плагина:

<?php
function myplugin_lang_init() {
    $domain = 'mydomain';
    // Фильтр "plugin_locale" также используется в load_plugin_textdomain()
    $locale = apply_filters('plugin_locale', get_locale(), $domain);
    load_textdomain($domain, WP_LANG_DIR.'/plugins/'.$domain.'-'.$locale.'.mo');
    load_plugin_textdomain($domain, FALSE, dirname(plugin_basename(__FILE__)).'/languages/');
}
// myplugin_lang_init(); // Это работает
add_action('plugins_loaded', 'myplugin_lang_init'); // Я не знаю почему, но это не работает

Это работает только если я вызываю myplugin_lang_init() напрямую, но не работает, если я использую add_action('plugins_loaded', 'myplugin_lang_init').

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

Не могли бы вы взглянуть на это? Возможно, я что-то пропустил?

Заранее спасибо.

Если кто-то увидит это,

Следующее сработало для меня после 4 изменений:

  1. переведенные файлы только в директории lang плагина
  2. использование хука “init” вместо “plugins_loaded” и убедитесь, что строки для перевода загружаются после него
  3. использование get_user_locale() для отображения правильного языка для залогиненных пользователей (если не залогинен, возвращается get_locale())
  4. имена файлов переводов такие: en_US.mo/po, fr_FR.mo/po…
function myplugin_lang_init() {
    $domain = 'mydomain';
    $plugin_dir_lang = plugin_dir_path( __FILE__ ) . 'languages'; // предполагаем, что текущий php файл находится в корневой директории плагина
    // Фильтр "plugin_locale" также используется в load_plugin_textdomain()
    $locale = apply_filters('plugin_locale', get_user_locale(), $domain); // используем get_user_locale() вместо get_locale()
    load_textdomain($domain, $plugin_dir_lang . '/' . $locale . '.mo');
    load_plugin_textdomain($domain, FALSE, $plugin_dir_lang);
}
// myplugin_lang_init(); // Это работает
add_action('init', 'myplugin_lang_init'); // используем init вместо plugins_loaded

С моим плагином я не мог перевести элемент меню Панели управления и соответствующую форму, но информация в записи, созданной моим плагином, показывала переводы. Ни хук ‘init’, ни ‘plugins_loaded’ не помогли. Это было решено назначением хука ‘load_textdomain’:

add_action('load_textdomain', 'myplugin_lang_init');

Ответ или решение

Загрузка локализации плагина в WordPress – это ключевая задача для обеспечения поддержки разных языков и улучшения пользовательского опыта. Ваша проблема с функцией add_action('plugins_loaded', 'myplugin_lang_init'), которая не работает, может быть связана с различными факторами. Рассмотрим теоретические основы, конкретные примеры и то, как их можно применить в вашей практике.

Теория

В WordPress локализация и интернационализация управляются через функции, такие как load_plugin_textdomain(), которые загружают файлы перевода для использования в плагине. Эти файлы обычно находятся в папке languages вашего плагина и имеют расширения .po и .mo.

Действие plugins_loaded часто используется для инициирования таких процессов загрузки, поскольку оно выполняется после того, как все плагины были подключены, но до начала работы темы. Тем не менее, это действие может не всегда быть идеальным для определенных сценариев, таких как ваш.

Примеры и комментарии

1. Использование init вместо plugins_loaded:

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

2. Использование get_user_locale() вместо get_locale():

Ваша правка с использованием функции get_user_locale() весьма полезна, особенно в многоязычных сайтах, где разные пользователи могут работать с различными языковыми настройками. get_user_locale() возвращает язык, установленный пользователем, если он авторизован, и текущий язык сайта в противном случае. Это гарантирует более точное отображение языка для конкретного пользователя.

3. Корректное именование и размещение файлов перевода:

Ваши файлы перевода должны следовать стандартному шаблону именования, который соответствует коду локали (например, en_US.mo). Файлы должны находиться в стабильной директории, как правило, 'languages', чтобы избежать проблем с путями и загружать правильные переводы.

Применение

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

  1. Убедитесь, что все файлы перевода находятся в папке languages, в корневой директории плагина.
  2. Используйте $locale = apply_filters('plugin_locale', get_user_locale(), $domain); для поддержки разных пользовательских настроек языка.
  3. Настройте подключение функции инициализации локализации через add_action('init', 'myplugin_lang_init');.
  4. Дополнительно вы можете рассмотреть использование подключаемого действия load_textdomain, если init и plugins_loaded не обеспечивают необходимой загрузки переводов.
function myplugin_lang_init() {
    $domain = 'mydomain';
    $plugin_dir_lang = plugin_dir_path(__FILE__) . 'languages/';
    $locale = apply_filters('plugin_locale', get_user_locale(), $domain);
    load_textdomain($domain, $plugin_dir_lang . $locale . '.mo');
    load_plugin_textdomain($domain, FALSE, $plugin_dir_lang);
}
add_action('init', 'myplugin_lang_init');

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

Вывод

Ваш практический подход к решению проблемы и оптимизации процесса локализации плагина в WordPress является обоснованным и эффективным. Различные сценарии использования языковых настраиваемых параметров делают ваш плагин более адаптируемым и удобным для пользователей по всему миру. Надеюсь, это детальное объяснение поможет вам и другим разработчикам в дальнейшей работе с локализацией плагинов в WordPress.

Оцените материал
Добавить комментарий

Капча загружается...