¿Puedo dejar el dominio de texto del complemento para los términos utilizados en core?

Tengo un complemento que coloca los estados de publicación en los menús de administración de tipo de publicación. Estoy a punto de internacionalizarlo 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 entonces también hay casos en los que estoy usando una palabra relacionada núcleo por su significado central relacionada con este aspecto: __( 'Pages' ). En esta situación, parece tener mucho sentido para mí excluir el dominio de 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 aplica el mismo consejo que el anterior, excepto que

• debes usar un dominio, que se carga en un gancho de tu complemento

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

Entonces, ¿esto es WP-kosher?

Nunca confíe en las cadenas principales para la traducción, pueden cambiar u obtener un contextparámetro 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 tenga en cuenta que la misma cadena no es necesariamente traducida a todas partes con la misma palabra. Incluso sin un parámetro de contexto, podría ser útil utilizar una traducción diferente para su complemento en algunos idiomas. Pero esto no sería posible si no incluye la cadena en su complemento.

Vea esta discusión de chat que tuvimos hace unos días sobre este tema.

Sí, pero por favor no. Esto es como el estándar de codificación, mejor sígalo incluso cuando pueda obtener una pequeña ventaja al pasarlo por alto.

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 __('Pages')?

2. No guarda el 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 su ejemplo generarán un archivo .po que contiene la palabra 'Páginas' incluso si usted usa el dominio predeterminado para ello. El localizador no verifica el uso real de las cadenas que traduce a menos que necesite comprender el contexto para no notar el dominio diferente y traducir 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 una manera que permita que poedit traduzca automáticamente palabras como 'Páginas'.

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: https://v123.tw/use-wordpress-core-translation/

¡¡Buena suerte!!