Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Use core language pack translations where possible #534
There are quite a few terms and phrases used in Stream that come from core. These translatable strings are already part of core language packs so it doesn't make sense for Stream to also have to provide translations for them.
Instead, we should use the
esc_html__( 'Revision', 'default' ); esc_html__( 'Posts', 'default' ); esc_html__( 'Pages', 'default' ); esc_html__( 'Plugins', 'default' ); esc_html__( 'Menus', 'default' );
I know that we could just leave the textdomain param blank, but this could also be confused with a mistake as often times textdomains are forgotten, so it will be best to explicitly indicate that
I am totally against this practice and propose to change it back to the plugin's own textdomain!
Example: if your WordPress install uses an informal German translation (which comes as defalt from .org) but the plugin would use an informal translation pack (as a custom user translation), user has to make sure there are no translation conflicts and in style/wording and this user has to override those strings from the plugin that use the - wrong - 'default' textdomain.
From my experience over the years such things make no sense, still some developers try it again and again. It only makes things more complex, even "worse" and has no benefit at all.
Every plugin and/ or theme/ child theme should use a unified textdomain for 100% of all strings and this should be the plugin's/ theme's slug in the very best case.
Thanks, Dave from Germany :)
Hi Dave from Germany,
Thanks so much for your feedback. While I would normally agree with you on your points about different translation styles, part of the purpose of these strings within Stream is to provide a direct reference to another part of WordPress.
That is to say, unlike most other plugins, Stream definitely does want to match the active WordPress translation, so the user knows that when Stream uses the word Post, it means the exact same thing as WordPress core does. We would never want it to be different, regardless of translation style.
Does that make sense, or am I missing your point?
If it's only those 5 strings as stated in first post above you could make a little statement in your documentation/description why these are used directly from core with the 'default' textdomain. Then it's transparent and every (third-party) dev would know how to handle that.
Thanks for explanation!
Greetinx, Dave :)
Interesting discussion. Looks like there are a few different solutions each with their merits.
The first 2 are perfectly valid solutions using gettext as intended. That being said, I agree with the point made above regarding the use of native text domains, and also believe that language files should be shipped with the code that references the same text domain. For those reasons I'm leaning toward the third solution.
My concern with option 3 is that:
I'm leaning toward moving in the direction of Option 2. It's a bit more work on our end, but (secondo me) it seems like the right way.
@ThemeBoy a few comments to your points:
Never go that route.
Only ever use one textdomain in your plugin, this is the slug of the plugin!