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

10

J'ai un plugin qui place les statuts de publication dans des menus d'administration de type 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 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 leur 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 chargé dans un hook de votre plugin

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

  •   

Alors, est-ce WP-Kosher?

    
posée mrwweb 26.12.2012 - 23:57

3 réponses

14

Ne comptez jamais sur les 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.

N'oubliez pas non plus qu'une 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 en ligne , nous en avons eu quelques-uns il y a quelques jours sur ce sujet.

    
réponse donnée fuxia 27.12.2012 - 00:18
4

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

Meilleures raisons:

  1. Dans la version 3.5, WordPress n’avait pas de fichier de traduction monolithique, il était 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èrent un fichier .po contenant le mot. "Pages" même si vous utilisez le domaine par défaut. 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. 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, de manière à permettre à poedit de traduire automatiquement des mots tels que "Pages".

réponse donnée Mark Kaplun 27.12.2012 - 00:39
0

Vous pouvez 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 : enlace

Bonne chance !!

    
réponse donnée Ann 07.09.2017 - 22:28

Lire d'autres questions sur les étiquettes