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

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

Le plugin utilise des chaînes uniques qui obtiendront un domaine de texte comme celui-ci:

__( '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é noyau pour leur signification liée au noyau comme ceci: __( 'Pages' ). Dans cette situation, il me semble parfaitement logique d'exclure le domaine de texte et de profiter de termes déjà localisés dans le noyau. Cependant, le codex semble très explicite:

Si vous essayez de traduire un plugin, le même conseil que ci-dessus s'applique, sauf que

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

• chaque appel de traduction doit devenir __ («texte», «nom de domaine»)

Est-ce donc WP-kasher?

Ne comptez jamais sur les chaînes principales pour la traduction, elles peuvent changer ou obtenir un contextparamètre à 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 que nous avons eue il y a quelques jours sur ce sujet.

Oui, mais non. C'est comme le codage standard, mieux vaut 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 fichiers de traduction monolithiques, il a été divisé en 3 parties pour des raisons de performances. Si cette tendance se poursuit, pouvez-vous être sûr que le domaine par défaut sera chargé lorsque vous essayez de l'utiliser __('Pages')?

2. Vous n'enregistrez pas de travail dans le localisateur - Les outils de traduction tels que poedit ne savent pas comment traiter deux domaines de traduction dans un seul fichier, et dans votre exemple, ils généreront un fichier .po qui contient le mot «Pages» même si vous utiliser 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 a besoin de comprendre le contexte, de sorte qu'il ne remarquera pas le domaine différent et traduira le mot. En outre, 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 d'une manière qui permet à poedit de traduire automatiquement des mots comme «Pages».

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!!