Kann ich die Plugin-Textdomäne für Begriffe, die in core verwendet werden, abbrechen?

Ich habe ein Plugin , das Post-Status in Post-Admin-Menüs setzt. Ich bin dabei, es zu internationalisieren, und ich frage mich, wie ich mit dieser Situation umgehen soll.

Das Plugin verwendet einige eindeutige Zeichenfolgen, die eine Textdomäne wie folgt erhalten:

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

Aber dann gibt es auch Fälle, in denen ich ein kernbezogenes Wort für seine corebedeutung verwende: __( 'Pages' ) . In dieser Situation erscheint es mir sinnvoll, die Textdomäne auszuschließen und bereits im core lokalisierte Begriffe zu nutzen. Der Codex scheint jedoch sehr explizit zu sein:

Wenn Sie versuchen, ein Plugin zu übersetzen, gilt derselbe Hinweis wie oben

  • Sie müssen eine Domain verwenden, die in einen Hook Ihres Plugins geladen wird

  • Jeder Übersetzungsaufruf muss __ (‘text’, ‘domain-name’) werden

Also ist das WP-koscher?

Solutions Collecting From Web of "Kann ich die Plugin-Textdomäne für Begriffe, die in core verwendet werden, abbrechen?"

Verlassen Sie sich niemals auf corezeichenfolgen für die Übersetzung, sie können sich jederzeit ändern oder einen context . Sobald dies der Fall ist, erhalten Ihre Benutzer eine teilweise übersetzte Benutzeroberfläche, und Ihre Übersetzer haben keine Möglichkeit, das zu beheben.

Bedenken Sie auch, dass die gleiche Zeichenfolge nicht überall mit dem gleichen Wort übersetzt werden muss. Auch ohne Kontextparameter kann es sinnvoll sein, in einigen Sprachen eine andere Übersetzung für Ihr Plugin zu verwenden. Dies wäre jedoch nicht möglich, wenn Sie die Zeichenfolge nicht in Ihr Plugin aufnehmen.

Sehen Sie sich diese Chat-Diskussion an, die wir vor einigen Tagen über dieses Thema hatten.

Ja, aber bitte nicht. Dies ist wie ein Codierungsstandard, besser, wenn Sie einen kleinen Vorteil haben, indem Sie ihn umgehen.

Bessere Gründe:

  1. In Version 3.5 hat WordPress keine Monolith-Übersetzungsdateien, es wurde aus Performancegründen in 3 Teile aufgeteilt. Wenn dieser Trend anhält, können Sie sicher sein, dass die Standarddomäne überhaupt geladen wird, wenn Sie versuchen, sie in __('Pages') ?

  2. Sie speichern keine Arbeit im Localizer – Übersetzungstools wie poedit wissen nicht, wie Sie mit zwei Übersetzungsdomänen in einer Datei umgehen, und in Ihrem Beispiel werden sie eine .po-Datei erzeugen, die das Wort ‘Pages’ enthält, selbst wenn Sie Verwenden Sie die Standarddomäne dafür. Der Localizer überprüft nicht die tatsächliche Verwendung der Zeichenfolgen, die er übersetzt, es sei denn, er muss den Kontext verstehen, damit er die unterschiedliche Domäne nicht bemerkt und das Wort übersetzt. Wenn der Lokalisierer seine Werkzeuge kennt, wird er außerdem eine Übersetzungsdatenbank haben, die auf den WordPress-coreübersetzungsdateien basiert, so dass poedit automatisch Wörter wie “Seiten” übersetzen kann.

Du kannst es versuchen

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

Oder

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

Referenz: https://v123.tw/use-wordpress-core-translation/

Viel Glück!!