Чи можу я залишити textdomain плагіна для термінів, які використовуються в core?

10

У мене є плагін, який розміщує статуси публікацій у меню адміністратора типу публікацій. Я в середині інтернаціоналізації, і мені цікаво, як впоратися з цією ситуацією.

Плагін використовує кілька унікальних рядків, які отримають такий текстовий домен:

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

Але бувають і випадки , коли я використовую слово ядра , пов'язані з їх основним пов'язаним змістом , як це: __( 'Pages' ). У цій ситуації, здається, має сенс для мене виключити textdomain і скористатися термінами, які вже локалізовані в ядрі. Однак кодекс здається дуже явним:

Якщо ви намагаєтеся перекласти плагін, застосовуються ті самі поради, що і вище, крім цього

ви повинні використовувати домен, завантажений у гачок вашого плагіна

кожен виклик перекладу повинен стати __ ("текст", "ім'я домену")

Так це WP-кошер?

plugins localization

— mrwweb
джерело

1

Дякую за те, що задали питання, що викликають думки, відповіді (від Тошо та Марка Каплуна) були цікавими та корисними для мене!

— webaware

14

Ніколи не покладайтеся на основні рядки для перекладу, вони можуть contextбудь-коли змінити або отримати параметр. Як тільки це станеться, ваші користувачі отримують частково перекладений інтерфейс, а ваші перекладачі не мають можливості це виправити.

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

Дивіться цю дискусію в чаті, яку ми мали кілька днів тому щодо цієї теми.

— фуксія
джерело

Також пам’ятайте, що рядок все одно відображатиметься у вашому POT-файлі, навіть якщо у ньому немає textdomain.

— scribu

@scribu Залежить від аналізатора. Плагін для локалізації коделінгу буде ігнорувати його.

— фуксія

Здається, що між цією відповіддю та цією відповіддю на майже ідентичне запитання є якась незгода ...

— mrwweb

4

Так, але будь ласка, не варто. Це як стандарт кодування, краще дотримуйтесь його навіть тоді, коли ви можете отримати невелику перевагу, обійшовши його.

Більш обґрунтовані причини:

У версії 3.5 WordPress не має монолітних файлів перекладу, він був розбитий на 3 частини з міркувань продуктивності. Якщо ця тенденція продовжиться, чи можете ви бути впевнені, що домен за замовчуванням взагалі буде завантажений, коли ви намагаєтесь його використовувати __('Pages')?
Ви не заощаджуєте роботу на локалізаторі - засоби перекладу, такі як 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/

Удачі!!

— Енн
джерело