web-dev-qa-db-fra.com

Puis-je laisser le plugin textdomain pour les termes utilisés dans core?

J'ai un plugin qui met les statuts dans des menus admin de type post. Je suis en train de l'internationaliser et je me demande comment gérer cette situation.

Le plugin utilise des chaînes uniques qui auront un textdomain comme ceci:

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

Mais il y a aussi des cas où j'utilise un mot lié au noyau pour sa signification liée à celle-ci, comme ceci: __( 'Pages' ). Dans cette situation, il semble parfaitement logique pour moi d'exclure le domaine text et de tirer parti de termes déjà localisés dans le noyau. Cependant, le codex semble très explicite:

Si vous essayez de traduire un plugin, les mêmes conseils que ci-dessus s'appliquent, sauf que

  • vous devez utiliser un domaine qui est chargé dans un hook de votre plugin

  • chaque appel de traduction doit devenir __ ('text', 'nom de domaine')

Alors, est-ce WP-kasher?

pluginslocalization
10
mrwweb

Ne vous fiez jamais aux chaînes principales pour la traduction, elles peuvent changer ou obtenir un paramètre context à tout moment. Une fois que cela se produit, vos utilisateurs obtiennent une interface partiellement traduite et vos traducteurs n'ont aucun moyen de résoudre ce problème.

Gardez également à l'esprit que la même chaîne n'est pas nécessairement traduite partout avec le même mot. Même sans paramètre de contexte, il peut être utile d’utiliser une traduction différente pour votre plugin dans certaines langues. Mais cela ne serait pas possible si vous n'incluez pas la chaîne dans votre plugin.

Voir cette discussion de discussion nous avons eu il y a quelques jours à ce sujet.

14
fuxia

Oui, mais s'il vous plait ne le faites pas. C'est comme la norme de codage, il vaut mieux le suivre même lorsque vous pouvez obtenir un petit avantage en le contournant.

De meilleures raisons:

  1. Dans la version 3.5, WordPress n’a pas de fichier de traduction monolithique, il a été divisé en 3 parties pour des raisons de performances. Si cette tendance se maintient, pouvez-vous être sûr que le domaine par défaut sera chargé lorsque vous essayez de l'utiliser dans __('Pages')?

  2. Vous ne sauvegardez pas le travail dans le localisateur - Les outils de traduction tels que poedit ne savent pas comment gérer deux domaines de traduction dans un seul fichier. Dans votre exemple, ils généreront un fichier .po contenant le mot utilisez le domaine par défaut pour cela. Le localisateur ne vérifie pas l'utilisation réelle des chaînes qu'il traduit sauf s'il doit comprendre le contexte afin de ne pas remarquer le domaine différent et de traduire le mot. De plus, si le localisateur connaît ses outils, il disposera d'une base de données de traduction basée sur les fichiers de traduction principaux de WordPress de manière à permettre à poedit de traduire automatiquement des mots tels que "Pages".

4
Mark Kaplun

Tu peux l'essayer

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

Ou

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

Référence: https://v123.tw/use-wordpress-core-translation/

Bonne chance!!

0
Ann