¿Puedo dejar de lado el dominio textdomain para los términos utilizados en el núcleo?

10

Tengo un complemento que coloca los estados de las publicaciones en los menús de administración de tipo de publicación. Estoy en medio de la internacionalización y me pregunto cómo manejar esta situación.

El complemento utiliza algunas cadenas únicas que obtendrán un dominio de texto como este:

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

Pero también hay casos en los que estoy usando una palabra relacionada con el núcleo para su significado relacionado con el núcleo como este: __( 'Pages' ) . En esta situación, me parece que tiene mucho sentido excluir el dominio del texto y aprovechar los términos que ya están localizados en el núcleo. Sin embargo, el códice parece muy explícito:

  

Si está intentando traducir un complemento, se aplican los mismos consejos anteriores, excepto que

     
  • debe usar un dominio, que se carga en un enlace de su complemento

  •   
  • cada llamada de traducción debe convertirse en __ ('texto', 'nombre de dominio')

  •   

Entonces, ¿esto es WP-kosher?

    
pregunta mrwweb 26.12.2012 - 23:57

3 respuestas

14

Nunca confíe en las cadenas centrales para la traducción, pueden cambiar u obtener un parámetro context en cualquier momento. Una vez que eso sucede, sus usuarios obtienen una interfaz parcialmente traducida, y sus traductores no tienen forma de solucionarlo.

También ten en cuenta que no es necesario traducir la misma cadena en todas partes con la misma palabra. Incluso sin un parámetro de contexto, puede ser útil utilizar una traducción diferente para su complemento en algunos idiomas. Pero esto no sería posible si no incluyes la cadena en tu complemento.

Consulte esta conversación de chat que tuvimos Hace días sobre este tema.

    
respondido por el fuxia 27.12.2012 - 00:18
4

Sí, pero por favor no lo hagas. Esto es como el estándar de codificación, es mejor seguirlo incluso cuando puede obtener una pequeña ventaja al evitarlo.

Mejores razones:

  1. En la versión 3.5, WordPress no tiene archivos de traducción monolíticos, se dividió en 3 partes por razones de rendimiento. Si esta tendencia continúa, ¿puede estar seguro de que el dominio predeterminado se cargará cuando intente usarlo en __('Pages') ?

  2. No guardas trabajo en el localizador: las herramientas de traducción como poedit no saben cómo manejar dos dominios de traducción en un archivo, y en tu ejemplo generarán un archivo .po que contiene la palabra 'Páginas' incluso si usas el dominio predeterminado para ello. El localizador no verifica el uso real de las cadenas que traduce, a menos que necesite entender el contexto para que no note los diferentes dominios y traduzca la palabra. Además, si el localizador conoce sus herramientas, tendrá una base de datos de traducción basada en los archivos de traducción principales de WordPress de manera que poedit traduzca automáticamente palabras como 'Páginas'.

respondido por el Mark Kaplun 27.12.2012 - 00:39
0

Puedes probarlo

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

O

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

Referencia : enlace

¡Buena suerte!

    
respondido por el Ann 07.09.2017 - 22:28

Lea otras preguntas en las etiquetas