Support » Plugin: Loco Translate » Blocks can’t be translated

  • Hi there.

    I tried to translate woocommerce blocks and found an issue.

    Wordpress blocks translations .json files require “messages” key in “locale_data” object.

    The .json files generated from .po file with Loco translate plugin places translation file “Textdomain” field value https://prnt.sc/1d3abcg as a value for “domain” field in .json file as well as uses it instead of “messages” key:

    https://prnt.sc/1d39jq0

    To make it work it generated .json file must like following: https://prnt.sc/1d3bcjj

    Thanks in advance

Viewing 12 replies - 1 through 12 (of 12 total)
  • Plugin Author Tim W

    (@timwhitlock)

    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.

    Thread Starter Rufus87

    (@rufus87)

    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.

    Plugin Author Tim W

    (@timwhitlock)

    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?

    Thread Starter Rufus87

    (@rufus87)

    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

    Plugin Author Tim W

    (@timwhitlock)

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

    Thread Starter Rufus87

    (@rufus87)

    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 11 months, 2 weeks ago by Rufus87.
    Plugin Author Tim W

    (@timwhitlock)

    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.

    Thread Starter Rufus87

    (@rufus87)

    “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

    Plugin Author Tim W

    (@timwhitlock)

    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.

    Thread Starter Rufus87

    (@rufus87)

    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 11 months, 2 weeks ago by Rufus87.
    Plugin Author Tim W

    (@timwhitlock)

    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.

    Thread Starter Rufus87

    (@rufus87)

    Thank you so much for amazing support.

Viewing 12 replies - 1 through 12 (of 12 total)
  • The topic ‘Blocks can’t be translated’ is closed to new replies.