Blocks can’t be translated

Thanks for reporting, but my understanding from looking at the WordPress code is that “messages” is a fallback. The domain is tried first.

The inline code that gets printed into your page from WP_Scripts::print_translations produces the following line:

var localeData = translations.locale_data[ domain ] || translations.locale_data.messages;

I don’t know if this will ever change, but for backward compatibility I suspect it won’t. It is still present in WP 5.8. Do you see this line for WooCommerce?

So if you’re saying that this doesn’t work in WooCommerce, possibly something else is going wrong. Can you please give more detail so I can reproduce your problem.

Hi Tim.

Many thanks for your quick response. You are completely right, but actually it is not possible to translate woocommerce.po related json files.

To be able to reproduce this issue you have to enable WooCommerce and WooCommerce Blocks plugin, then try to translate any JS string e.g. try to edit some string translation on new checkout block: (ex: Your cart (%d item))

You will see that your custom translation does not work. WC actually load translations only id “message” key presents.

WC actually load translations only id “message” key presents.

Are you saying that WooCommerce overrides WordPress and prints different JavaScript to load the translations?

I don’t have a WooCommerce site available to see this for myself. Can you please demonstrate?

Here you are:

https://prnt.sc/1dg0oep – Textdomain configuration “woocommerce”
https://prnt.sc/1dg080w – Translation interface in admin panel
https://prnt.sc/1dg01yx – There is no translation in front
https://prnt.sc/1dg0yu4 – JSON file looks like this

But

https://prnt.sc/1dg1fzl – Textdomain configuration “messages”
https://prnt.sc/1dg1rta – Translation interface in admin panel
https://prnt.sc/1dg1yjx – Correctly translated in front
https://prnt.sc/1dg2734 – JSON file looks like this

As you can see from provided screenshots, the only difference is “woocommerce” / “messages” key in “locale_data”

Thanks

What I need to see is the JavaScript that gets printed to your HTML. The code like I posted above.

Here you are:

https://prnt.sc/1dun0yy

This screenshot explains a lot, since it tries to load data from textdomain “woo-gutenberg-products-block” but actually the translation json files do include “woocommerce” textdomain. And that is exactly why using “messages” as textdomain saves that confusing situation.

What do you think can be a suggestion to solve it?

• This reply was modified 3 years, 7 months ago by Rufus87.

it tries to load data from textdomain “woo-gutenberg-products-block” but actually the translation json files do include “woocommerce” textdomain

Loco Translate detects the text domain for WooCommerce Blocks as “woo-gutenberg-products-block” which is correct and produces correct JSON files containing locale_data.woo-gutenberg-products-block. I can’t explain how your JSON file could contain “woocommerce” as the text domain. Possibly you configured this.

What do you think can be a suggestion to solve it?

Configure the correct text domain for the plugin. Only WooCommerce should use the text domain “woocommerce”. Doing otherwise may cause you other problems.

I may in future patch the plugin to use “messages” as the locale_data key, but it seems in this case that using the domain has caught a mistake.

“I can’t explain how your JSON file could contain “woocommerce” as the text domain. Possibly you configured this.” – nothing is done specially. The problem is that for example “Your cart (%d item)” string can be only found under “woocommerce.pot”. But this string is written in the code with “woo-gutenberg-products-block” textdomain as shown in the following screenshot: https://prnt.sc/1dvoxtd

Do to fact that textdomains are different, Loco creates translation using “woocommerce” textdomain then places it in .json files. As a result, there is no translation in front. That’s why in my first message I mentioned that it works when we use “messages” as a textdomain for “Woocommerce” translation.

Presumably, this isn’t your plugin related issue, but as a fact it’s actual.

Thanks

Do to fact that textdomains are different, Loco creates translation using “woocommerce” textdomain then places it in .json files.

Loco Translate does not use “woocommerce” as the text domain for “woo-gutenberg-products-block” unless it is specifically asked to do so. It couldn’t possibly know to do this. When editing one plugin it has no awareness of other plugins, including those that define duplicate strings.

The string “Your cart (%d item)” is defined in woo-gutenberg-products-block, but possibly you’re confused because the plugin does not ship with a POT file. See FAQ about missing templates.

Actually there is a possibility to regenerate .pot file for any plugin using wp-cli command, and it is designed to do what we need and can solve mentioned problem, but unfortunately it also has an issue and cannot handle generated (minified) js files.

So, right now the only way to solve this problem is to use “messages” as “textdomain” in bundle settings.

Thank you so much for your great support.

• This reply was modified 3 years, 7 months ago by Rufus87.

So, right now the only way to solve this problem is to use “messages” as “textdomain” in bundle settings.

This is not a good solution and there is another way…

Download the PO file I linked to above. Then copy this to create your custom string overrides. This method is described the FAQ I posted.

Be aware that WordPress-installed language packs will have strings purged from PO files if they are only used in JavaScript. You can get around this problem by manually downloading the PO from GlotPress, or by using the loco fetch wp-cli command, or by using the new sync option labelled Merge strings from related JSON files.

Thank you so much for amazing support.