Ignore certain domain (e.g. via an options.dontUpdateDomains)

[kraftner]

It would be great to be able to set certain text domains to be left alone, something along

options: {
            dontUpdateDomains: [ 'thirpartydomain' ]
}

My use case is that my theme does some slight modifications of markup via a plugin hook, but although the order of things shifts the actual string to translate remains the same as in the plugin. So it doesn't really make sense to move/duplicate that string in my plugin.
Now I could just ignore that file in target but that is an issue as the file does have other translatable strings with my own textdomain in it.

I know this probably is an edge case, but maybe I am not the only one having this issue. 😄

[bradyvercher]

That does sound like an interesting use case, but I imagine it's probably not worth configuring in most cases unless there are multiple duplicated strings throughout the project. I'll leave this open in case anyone else wants to upvote it, though.

[kraftner]

That is what I expected, let's see if it is just me or common enough to mandate a change.

Thanks for the quick response though!

[robneu]

I ran into something similar to this where I needed to pull in some core text strings without actually modifying them. It's been a little annoying to deal with, but eh.

[michakrapp]

+1 for this.

Use case:
Develop a theme / plugin for the woocommerce plugin. If you duplicate the woocommerce templates to your theme or using filters / actions to change the layout you may want to use the already translated strings from woocommerce itself.

Currently these strings get into your .pot file, but they are already translated, so no need to use them.

I would suggest (maybe additional to @kraftner idea) to be able to explicit set a domain which to process. So that only the strings from my theme / plugin gets added.

options: {
            textDomain: 'mydomain'
}

[GaryJones]

you may want to use the already translated strings from woocommerce itself

It's generally not advised to rely on someone else's strings staying constant. They only need to add a full stop or make another trivial change, and the string in your template would no longer be translatable. To have a non-English site suddenly showing English strings on their checkout, say, because they updated WooCommerce seems like a bad idea. Tracking it down to it being mis-matched (missing) strings in the theme .pot is just asking for wasted time.

Better practice would be to change the textdomain of the strings in your template, and allow them to get added to your .pot file.

I'm strongly in favour of wontfix here.

[michakrapp]

Better practice would be to change the textdomain of the strings in your template...

For woocommerce the template files are meant to be overridden. So if you only change the layout you want to use the already translated strings. And if they change - yes you have to change them too

...and allow them to get added to your .pot file....

Currently they get added even if they have a different text-domain. So a translator would see them but if they translate it, it won't be shown.

It is an option - so you don't have to use it, but you could :)

[GaryJones]

So if you only change the layout you want to use the already translated strings.

No, you don't, for the reasons I've mentioned. With a different layout, a different locale may want the strings to say something different compared to any existing translation - perhaps a lack of space (e.g. long German words that need abbreviating), or something moved such that the previous context of the string is not so obvious (one section moved above another, or outside of a section heading etc.).

If your theme is taking ownership of the layout, then it's also taking ownership of those strings, as such, should be internationalised with the theme's text domain, even if the strings happen to be the same as the current default. Your theme may want to be used by someone in a locale for which WooCommerce has no existing language files, so the strings need to be available, and have the translation applied, from your theme's language files.

[robneu]

IMO that creates an unnecessarily large burden on theme authors. Translations are tough to deal with by default and not allowing a theme to reuse existing translations from a plugin seems a little ridiculous. With something like WooCommerce, the amount of translated languages someone expects from the plugin is very high.

Forcing a theme author to provide parity because they override a couple of templates seems unrealistic to me. What will most likely happen in that situation is a whole bunch of strings will either be untranslated or only translated into the few languages that the theme author has been able to pull together.

As @michakrapp pointed out, if someone did want to provide all of those, that's fantastic and they should still be able to do so. If this were implemented, it would give them the option rather than forcing one way or the other.

[GaryJones]

That option would be to support a non-best practice.

IMO that creates an unnecessarily large burden on theme authors.

No, it provides very little burden - change a few extra textdomains and that's it.

Any extra burden is on theme translators, and that's just a few extra strings. And, if the strings are the same as the default WooCommerce templates, they can copy the translated strings from those language files. It's literally just a few minutes extra work.

With something like WooCommerce, the amount of translated languages someone expects from the plugin is very high.

Sure - it could be in 100 locales, but that bears no relevance on the number of locales the theme is available in, so I don't see what your point is here.

Forcing a theme author to provide parity because they override a couple of templates seems unrealistic to me.

How is it unrealistic? Practically, the only extra work is to change the textdomain on the strings in the template.

What will most likely happen in that situation is a whole bunch of strings will either be untranslated or only translated into the few languages that the theme author has been able to pull together.

Theme translators would still need to translate the other strings in the theme anyway, so there's no point having the strings from WooCommerce magically translated if the rest of the theme strings are still in English.

I ran into something similar to this where I needed to pull in some core text strings without actually modifying them.

You've only got to look at Twenty Seventeen, Twenty Sixteen et al, to see that they also use WP Core strings, but with their own textdomain.

Same goes for Akismet using core strings but with its own textdomain as well.

For TGM Plugin Activation, the generator asks for the theme's / plugin's textdomain, so that the TGMPA file has strings that use that textdomain when used in a WordPress.org environment.

I get that we'd all prefer to keep everything DRY, but that's not the best approach in this circumstance, and adapting this grunt-wp-i18n tool to facilitate folks making this mistake, would be a mistake in itself IMO.

[LC43]

Hi!

Wanted to add that the assumption of 'and that's just a few extra strings.' or just a few minutes doesn't reflect some use cases.

In our particular case, we rely on woocommerce for the default translations. If there's a update and some strings change, we need to just update templates, not the translations. Specially, since we work with 6 other languages, this task of manually translating can be a burden x6, since we would have to hunt down the wc translation and use in ours.

Other use case of ours, is that we include a library. Right now, if we use this task for it, we would have hundreds of strings that are never seen. nevermind this one, we had it solved by using "exclude".

thanks :)

[GaryJones]

Thanks for sharing @LC43 👍

By relying on WooCommerce strings though, you're assuming that the translators of those 6 languages for WooCommerce are going to be prompt and have the strings available before you release your plugin or theme. You're also relying on them to be accurate with their translations. If not, then it's your Support team that will get the hit.

If your team "owned" the translations, then you're not relying on some other volunteers (external dependencies), for something that could affect your business.

[wayheming]

+1 for this. Need this feature.