• Помогите разобраться с приоритетами переводов плагинов.
    Я был уверен, что в дефолтном wp-content/languages/ они имеют приоритет над теми, что в каталогах плагинов, но оказалось, что это не так. Если в каталоге плагина есть лангпак, то используется он, а не из wp-content/languages/. Эксперименты проведены с 3-мя плагинами. (или это неправильные плагины?)

    WP_LANG_DIR в конфиге, если я правильно понимаю, роли не сыграет, тк wp-content/languages/ — и так дефолтная дира. Так ведь?

    Так как же можно управлять приоритетами лангпака?
    Собсно, задача прозаична — не потерять свой перевод при обновлении плага, если у него в дистре идёт лангпак.

Просмотр 12 ответов — с 1 по 12 (всего 12)
  • Модератор Sergey Biryukov

    (@sergeybiryukov)

    Live and Learn

    Если к каталоге плагина есть лангпак, то используется он, а не из wp-content/languages/. Эксперименты проведены с 3-мя плагинами. (или это неправильные плагины?)

    Пример? 🙂

    Автор SeVlad

    (@sevlad)

    Пример? 🙂

    https://wordpress.org/plugins/subscribe-to-category/ ну этот сразу показался подозрительным в названиях файлов лангпака (но сосбно сейчас он и нужен больше всех. И аналогов ему нет, к сожалению), поэтому пошел проверять другие:
    https://wordpress.org/plugins/addquicktag/
    https://wordpress.org/plugins/siteorigin-panels/

    Во всех этих работает внутренний лангпак и только после его удаления — пользовательский.

    Модератор Sergey Biryukov

    (@sergeybiryukov)

    Live and Learn

    Таки да — если плагин по-прежнему содержит в дистрибутиве свои собственные переводы, то используются они, если нет — то файлы из wp-content/languages (которые скачиваются с translate.wordpress.org).

    Это сделано для того, чтобы авторы плагинов могли спокойно и неспешно направить переводчиков, ранее присылавших им файлы напрямую, на translate.wordpress.org и убедиться, что у них есть права редактора перевода.

    Переопределить путь к файлам можно с помощью фильтра load_textdomain_mofile, примерно так:

    add_filter( 'load_textdomain_mofile', function( $mofile ) {
    	$local_mofile = str_replace( WP_LANG_DIR . '/plugins/', WP_LANG_DIR . '/local-plugins/', $mofile );
    	$local_mofile = str_replace( WP_LANG_DIR . '/themes/', WP_LANG_DIR . '/local-themes/', $mofile );
    	if ( file_exists( $local_mofile ) ) {
    		return $local_mofile;
    	}
    	return $mofile;
    });
    Автор SeVlad

    (@sevlad)

    Таки да — если плагин по-прежнему содержит в дистрибутиве свои собственные переводы, то используются они, если нет — то файлы из wp-content/languages (которые скачиваются с translate.wordpress.org).

    Как-то странно выходит. В темах приоритет имеет вп-ланг-дир, а в плагах наоборот. Нипарадок 🙂

    примерно так:

    Спс, попробуем.

    Только я недопонял — /local-plugins/ — это ж по идее путь к лангпаку плага, так? Но тогда его конкатенация с WP_LANG_DIR вроде не правильна и нужно WP_PLUGIN_DIR. Или как?

    И ещё не ясно. Если выше я правильно думаю, то $local_mofile нужно ж повторить для каждого плага (вернее каждого варианта размещения лангпаков в палгинах). Так ведь?

    Модератор Sergey Biryukov

    (@sergeybiryukov)

    Live and Learn

    /local-plugins/ — это ж по идее путь к лангпаку плага, так?

    В этом примере wp-content/languages/local-plugins — это тот путь, куда можно класть свои переводы плагинов.

    $local_mofile нужно ж повторить для каждого плага

    Зачем? 🙂

    Автор SeVlad

    (@sevlad)

    В этом примере wp-content/languages/local-plugins — это тот путь, куда можно класть свои переводы плагинов.

    Ещё больше перестаю понимать.
    Есть же дефолтный wp-content/languages/plugins/. Зачем заводить ещё один каталог?

    Зачем?

    Эээ.. понимаю, что ничего не понимаю 🙁

    Модератор Sergey Biryukov

    (@sergeybiryukov)

    Live and Learn

    Есть же дефолтный wp-content/languages/plugins/.

    Если свой перевод положить туда, он затрётся при обновлении языкового пакета с translate.wordpress.org.

    Автор SeVlad

    (@sevlad)

    Если свой перевод положить туда, он затрётся при обновлении языкового пакета с translate.wordpress.org.

    Даже так?!! уу как всё, оказывается, не хорошо.

    Модератор Sergey Biryukov

    (@sergeybiryukov)

    Live and Learn

    Всё хорошо, если есть фильтры 🙂

    Автор SeVlad

    (@sevlad)

    Всё хорошо, если есть фильтры 🙂

    До них ещё добраться надо. А большинство пользователей, способных поправить родной (корявый или неустраивающий) перевод нескольких строк (с пом напр того же Loco) не подозревают о такой «радости».
    Я вот, наверное как и многие другие пользователи ВП, был уверен, что переводы и тем и плагинов работают одинаково. И что в wp-content/languages/*/ — пользовательские переводы, не подлежащие автообновлениям (кроме ядра). Ан нет, как оказалось.

    ЗЫ. Для меня эта тема на время потеряла актуальность, но всё равно надо будет разобраться.
    Спасибо.

    Модератор Sergey Biryukov

    (@sergeybiryukov)

    Live and Learn

    Я вот, наверное как и многие другие пользователи ВП, был уверен, что переводы и тем и плагинов работают одинаково.

    Так и есть. Перевод темы, если его положить в wp-content/languages/themes/, тоже затрётся при обновлении языкового пакета. То же самое с переводами ядра.

    У Loco Translate есть ответ в FAQ на эту тему.

    Модератор Sergey Biryukov

    (@sergeybiryukov)

    Live and Learn

    И что в wp-content/languages/*/ — пользовательские переводы, не подлежащие автообновлениям (кроме ядра).

    Эта директория никогда не была предназначена для пользовательских переводов, в официальной документации таких рекомендаций не было. Использование недокументированных решений — на свой страх и риск 🙂

    Как вариант, можно попробовать оставить их там, но после редактирования поставить права с защитой от записи.

Просмотр 12 ответов — с 1 по 12 (всего 12)
  • Тема «Приоритеты переводов плагинов» закрыта для новых ответов.