Czy mogę pominąć domenę tekstową wtyczek dla terminów używanych w jądrze?

10

Mam wtyczkę, która umieszcza statusy postów w menu administratora typu post. Jestem w trakcie internacjonalizacji i zastanawiam się, jak poradzić sobie z tą sytuacją.

Wtyczka korzysta z kilku unikatowych ciągów, które otrzymają domenę tekstową w następujący sposób:

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

Ale są też przypadki, w których używam słowa związane z rdzenia do ich znaczenia związane rdzenia tak: __( 'Pages' ). Wydaje mi się, że w tej sytuacji wykluczenie domeny tekstowej i skorzystanie z terminów już zlokalizowanych w rdzeniu ma sens. Kodeks wydaje się jednak bardzo wyraźny:

Jeśli próbujesz przetłumaczyć wtyczkę, obowiązują te same porady, co powyżej, z wyjątkiem tego

  • musisz użyć domeny, która jest załadowana w haku wtyczki

  • każde wywołanie tłumaczenia musi mieć postać __ („tekst”, „nazwa domeny”)

Czy to koszerność WP?

plugins localization mrwweb
źródło
1
Dzięki, że zadałeś prowokujące pytanie, odpowiedzi (do tej pory od Toscho i Marka Kapluna) były dla mnie interesujące i przydatne!
internetowa

Odpowiedzi:

14

Nigdy nie polegaj na podstawowych ciągach tłumaczenia, mogą one zmienić lub uzyskać contextparametr w dowolnym momencie. Gdy tak się stanie, użytkownicy otrzymają częściowo przetłumaczony interfejs, a tłumacze nie będą w stanie tego naprawić.

Należy również pamiętać, że ten sam ciąg nie jest koniecznie tłumaczony wszędzie z tym samym słowem. Nawet bez parametru kontekstu przydatne może być użycie innego tłumaczenia wtyczki w niektórych językach. Nie byłoby to jednak możliwe, jeśli nie włączysz łańcucha do wtyczki.

Zobacz dyskusję na czacie, którą mieliśmy kilka dni temu na ten temat.

fuxia
źródło
Należy również pamiętać, że ciąg nadal będzie się wyświetlać w pliku POT, nawet jeśli nie zawiera on domeny tekstowej.
scribu
@scribu Zależy od analizatora składni. Wtyczka lokalizacji kodestylingu zignoruje ją.
fuxia
Wydaje się, że istnieje pewna sprzeczność między tą odpowiedzią a odpowiedzią na prawie identyczne pytanie ...
mrwweb
4

Tak, ale proszę nie. To jest jak standard kodowania, lepiej go przestrzegaj, nawet jeśli możesz uzyskać niewielką przewagę, omijając go.

Lepsze powody:

  1. W wersji 3.5 WordPress nie ma plików tłumaczenia monolitu, został podzielony na 3 części ze względu na wydajność. Jeśli ten trend będzie się utrzymywał, czy możesz być pewien, że domena domyślna zostanie w ogóle załadowana, gdy spróbujesz jej użyć __('Pages')?

  2. Nie zapisujesz pracy w lokalizatorze - narzędzia do tłumaczenia, takie jak poedit, nie wiedzą, jak radzić sobie z dwiema domenami tłumaczenia w jednym pliku, aw twoim przykładzie wygenerują plik .po, który zawiera słowo „Strony”, nawet jeśli użyj do tego domyślnej domeny. Lokalizator nie sprawdza faktycznego wykorzystania napisów, które tłumaczy, chyba że musi zrozumieć kontekst, więc nie zauważy innej domeny i przetłumaczy słowo. Ponadto, jeśli lokalizator zna swoje narzędzia, będzie miał bazę tłumaczeń opartą na podstawowych plikach tłumaczeń WordPress w sposób, który umożliwi poeditowi automatyczne tłumaczenie słów takich jak „Strony”.

Mark Kaplun
źródło
0

Możesz tego spróbować

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

Lub

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');
});

Odniesienie ： https://v123.tw/use-wordpress-core-translation/

Powodzenia!!

Ann
źródło