10

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:

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

1
  • 2
    Thanks for asking a thought-provoking question, answers (from toscho and Mark Kaplun so far) have been interesting and useful to me!
    – webaware
    Dec 26, 2012 at 23:56

3 Answers 3

14

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.

3
  • Also keep in mind that the string will still show up in your POT file, even if it doesn't have a textdomain.
    – scribu
    Dec 27, 2012 at 5:06
  • @scribu Depends on the parser. The codestyling localization plugin will ignore it.
    – fuxia
    Dec 27, 2012 at 10:17
  • It seems like there's some disagreement between this answer and this answer on a near-identical question...
    – mrwweb
    Jan 14, 2013 at 19:23
4

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'.

0

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.