WooCommerce Blocks Language

I’m hitting the exact same issue, but with Italian. I don’t think it’s possible with WPML right now. I’m super disappointed, because this block is exactly what I wanted for my checkout page. Now I’m looking into CheckoutWC, which I’d need to pay a lot for.

same to me. Unfortunately Loco Translate cannot find a file to translate either.

Same here, can’t translate with loco translate or i can’t find the path… don’t know.

https://translate.www.ads-software.com/projects/wp-plugins/woo-gutenberg-products-block/

You can translate for the entire community here.

Manuals, glossaries and style guide (per locale):
https://make.www.ads-software.com/polyglots/handbook/tools/glotpress-translate-wordpress-org/list-of-glossaries-per-locale/

After translating: https://make.www.ads-software.com/polyglots/handbook/translating/after-your-contribution/
see approval procedure. Lets say that Italian is quite ready for review.

Yes, but WPML doesnt support translating these strings as it is, so doing this is kind of pointless.

> Yes, but WPML doesn’t support translating these strings as it is

You are correct, WPML (nor Loco Translate) doesn’t support translating strings that are created using the JavaScript wp.i81n functions. However, the plugin is using a core WordPress API for making JavaScript strings translate-able.

Currently the advice Yui gave is the correct advice for translating strings for the plugin. When the translation percentage for a locale reaches 95% it then becomes available as a language pack for download by any WordPress site configured with that locale as it’s language. So it’s definitely advantageous for folks to contribute to having the strings translated via this way.

What does a language pack do that is different from downloading the existing translations (i.e., Italian, which is at about 65%) as a .po or .mo, and loading them through WPML?

In fact, I tried that, and nothing happened.

What does a language pack do that is different from downloading the existing translations (i.e., Italian, which is at about 65%) as a .po or .mo, and loading them through WPML?

.po and .mo files are not what the JavaScript i18n API loads its strings from. Instead it uses JED formatted JSON files. While this format is available from download, it unfortunately is a single file that is not loaded automatically via the JavaScript i18n API used by WordPress core.

Unfortunately, because of this, there is currently no other way to get translated strings for the client rendered JavaScript unless it is through a language pack because of the way those strings are loaded and provided via the WordPress JavaScript i18n API. The language packs include multiple JSON files that are split out into just the strings related to a specific JavaScript file that is loaded and WordPress knows what JSON files correspond to the JavaScript file because of a MD5 hash of the file path. These individual JSON files are not available via direct download via the GlotPress interface.

• This reply was modified 4 years, 8 months ago by Darren Ethier (nerrad). Reason: fix message to remove already mentioned content and improve explanation

That makes a lot of sense, I really appreciate the explanation!

I’m curious to know, is there a reason this plugin was designed to load strings via i18n instead of other conventional methods that would make translating these blocks easier? Genuinely curious.

I’m curious to know, is there a reason this plugin was designed to load strings via i18n instead of other conventional methods that would make translating these blocks easier?

We are using a conventional method for translating strings in JavaScript. A method that is currently supported by language packs in WordPress.

that would make translating these blocks easier?

“Easier” is a fairly relative term here. For folks used to using tools like Loco Translate and WPML I definitely can see how that would be seen as easy way to have custom translations for one’s own site. However, there’s also a whole group of users that could benefit from language packs being automatically installed on their sites in their Site’s language (if enough people saw the value in contributing translation strings for those languages so everyone can benefit)!

It also would be nice if plugin authors that built these other alternatives for translations would add support for the new conventional method of translating JavaScript in WordPress (which in turn would make it easier for folks like yourself who prefer to use such tools).

We definitely want to support folks in other languages that want to use our plugin so we’ve made sure to use the provided API WordPress exposes for ensuring the strings are translate-able.

Keep in mind, one of the reasons we released the blocks as an early preview is so that translators could start actively translating the strings as we iterate on the blocks to add more features. If we waited until the blocks were fully feature complete and then published them, that wouldn’t give translators much time to add strings.

Thanks for taking the time to comment, and I hope that helps explain things from our point of view?

We haven’t heard back from you in a while, so I’m going to mark this as resolved – if you have any further questions, you can start a new thread.

– Joey