Могу ли я оставить плагин textdomain для терминов, используемых в ядре?

10

У меня есть плагин, который помещает статусы сообщений в меню администратора типов сообщений. Я нахожусь в процессе интернационализации, и мне интересно, как справиться с этой ситуацией.

Плагин использует несколько уникальных строк, которые получат текстовый домен, подобный этому:

__( 'Select the post statuses to <strong>exclude</strong> from post type admin menus', 'csmpmsi' )

Но бывают и случаи , когда я использую слово ядра , связанные с их основным связанным смыслом , как это: __( 'Pages' ). В этой ситуации, мне кажется, имеет смысл исключить текстовый домен и использовать термины, которые уже локализованы в ядре. Тем не менее, кодекс выглядит очень явно:

Если вы пытаетесь перевести плагин, применяется тот же совет, что и выше, за исключением того, что

  • Вы должны использовать домен, который загружен в ловушку вашего плагина

  • каждый переводческий вызов должен стать __ («текст», «доменное имя»)

Так это WP-кошер?

plugins localization mrwweb
источник
1
Спасибо, что задали наводящий на размышления вопрос, ответы (от toscho и Марка Каплуна до сих пор) были интересными и полезными для меня!
webaware

Ответы:

14

Никогда не полагайтесь на основные строки для перевода, они могут измениться или получить contextпараметр в любое время. Как только это произойдет, ваши пользователи получат частично переведенный интерфейс, а ваши переводчики не смогут это исправить.

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

Посмотрите эту дискуссию в чате на эту тему.

Фуксия
источник
Также имейте в виду, что строка все равно будет отображаться в вашем POT-файле, даже если у него нет текстового домена.
scribu
@scribu Зависит от парсера. Плагин локализации кода будет игнорировать его.
fuxia
Кажется, что есть некоторое разногласие между этим ответом и этим ответом на почти идентичный вопрос ...
mrwweb
4

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

Лучшие причины:

  1. В версии 3.5 WordPress нет файлов перевода монолит, он был разбит на 3 части по соображениям производительности. Если эта тенденция сохранится, можете ли вы быть уверены, что домен по умолчанию будет загружен вообще, когда вы попытаетесь использовать его в __('Pages')?

  2. Вы не сохраняете работу в локализаторе - инструменты перевода, такие как poedit, не знают, как обращаться с двумя доменами перевода в одном файле, и в вашем примере они сгенерируют файл .po, содержащий слово «Страницы», даже если вы используйте для этого домен по умолчанию. Локализатор не проверяет фактическое использование строк, которые он переводит, если ему не нужно понимать контекст, поэтому он не заметит другой домен и переведет слово. Кроме того, если локализатор знает свои инструменты, у него будет БД перевода, основанная на файлах перевода ядра WordPress, таким образом, что poedit может автоматически переводить слова типа «Страницы».

Марк Каплун
источник
0

Можешь попробовать

add_action('wp',function(){
    load_default_textdomain();
    _e('Settings');
});

Или

add_action('wp',function(){
    $locale = is_admin() ? get_user_locale() : get_locale();
    load_textdomain( 'default', WP_LANG_DIR . "/$locale.mo" );
    load_textdomain( 'default', WP_LANG_DIR . "/admin-$locale.mo" );

    // WPMU
    //load_textdomain( 'default', WP_LANG_DIR . "/ms-$locale.mo" );
    //load_textdomain( 'default', WP_LANG_DIR . "/admin-network-$locale.mo" );

    _e('Settings');
    _e('First Name');
    _e('Last Name');
});

Ссылка ： https://v123.tw/use-wordpress-core-translation/

Удачи!!

Анна
источник