Can I leave off plugin textdomain for terms used in core?

2 Views

I’ve got a plugin that puts post statuses into post type admin menus. I’m in the middle of internationalizing it, and I’m wondering how to handle this situation.

The plugin uses some unique strings that will get a textdomain like this:

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

But then there are also cases where I’m using a core-related word for their core-related meaning like this: __( 'Pages' ). In this situation, it seems to make perfect sense for me to exclude the textdomain and take advantage of terms that are already localized in core. However, the codex seems very explicit:

If you’re trying to translate a plugin, the same advice as above applies, except that

  • you must use a domain, which is loaded in a hook of your plugin

  • every translation call must become __(‘text’, ‘domain-name’)

So is this WP-kosher?

Post Views: 2

Related posts

Leave a Reply

3 comments

  1. Never rely on core strings for translation, they may change or get a context parameter any time. Once that happens your users get a partially translated interface, and your translators have no way to fix that.

    Also keep in mind the same string is not necessary translated everywhere with the same word. Even without a context parameter it might be useful to use a different translation for your plugin in some languages. But this wouldn’t be possible if you don’t include the string in your plugin.

    See this chat discussion we had some days ago about this topic.

  2. Yes, but please don’t. This is like coding standard, better follow it even when you can get a small advantage by bypassing it.

    Better reasons:

    1. In version 3.5 WordPress don’t have a monolith translation files, it was broken into 3 part for performance reasons. If this trend continues, can you be sure that the default domain will be loaded at all when you try to use it in __('Pages')?

    2. You don’t save work to the localizer – Translation tools like poedit don’t know how to deal with two translation domains in one file, and in your example they will generate a .po file which contains the word ‘Pages’ even if you use the default domain for it. The localizer do not check the actual usage of the strings he translates unless he needs to understand the context so he will not notice the different domain and will translate the word.
      In addition, if the localizer knows his tools he will have a translation DB based on the WordPress core translation files in a way that enables poedit to translate automatically words like ‘Pages’.

  3. You can try it

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

    Or

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

    Reference：
    https://v123.tw/use-wordpress-core-translation/

    Good luck!!