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?
3 s
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.
