I was wondering why X overrides the translation file of woocommerce. I my language (Dutch) woocommerce comes with a very good translation but it seems that parts are translated by X and other part by woo.

So what to do?

Best regards Clint
Cdeco.nl

Thanks for writing in! This is because we modify the WooCommerce templates within X. You’ll need to fully translate X for the strings to be translated in WooCommerce. This is why the default translation isn’t applying. We include po and mo files in the language folder of the theme.

Right now we don’t have translation files available, but this is something we’re working on offering to everyone.

Please refer to the following (https://theme.co/x/member/forums/topic/woocommerce-problems/#post-108235).

Thanks!

Thank you.

Best regards.

I just wasted a most frustrating afternoon trying to figure out why certain words and phrases in Woocommerce weren’t translating properly. It turns that out some (but not all, ironically) of the Woocommerce standard words and phrases have been hijacked in X theme template to point to the __x__ domain instead of woocommerce.

I see a response above confirming this, saying ‘This is because we modify the WooCommerce templates within X. You’ll need to fully translate X for the strings to be translated in WooCommerce.’

My question (in response to the answer) is why? Why not just leave the standard ‘woocommerce’ translation domain alone in the template files? I’ve been perfectly happy with the standard Woocommerce translation in other sites I’ve built with other templates. Why would X re-use exactly the same words and phrases in the X template as the standard Woocommerce ones, and yet effectively prevent woocommerce from translating automatically by pointing the domain to __x__, requiring customers to edit the X language files to get them working again? What a pain.

The fact that languages uses textdomain like namespaces, translation will only work on current textdomain which is __x__. Every theme or plugin, have their own text domain.

With woocommerce plugin, the translation uses woocommerce textdomain, eg. __('My String', 'woocommerce') as plugin, but for X’s woocomerce templates, it uses theme textdomain ( __x__ ). This is a standard practice to use theme textdomain on all of its template files.

What you could do is setup a child theme, and copy woocommerce templates (eg. /x/woocommerce/ ) then replace all occurrences of __x__ by woocommerce. And see if it works because the loaded woocommerce’s textdomain is for the plugin.

Thanks!

Flatsome does, of course, follow the standard practice you mention and use its own textdomain ‘flatsome’ in their other, *non-woocommerce* related template files, to ensure that their flatsome-specific words and phrases translate, but they leave the woocommerce texdomain unchanged in the woocommerce templates and everything works fine.

Out of interest I just tested this with my installation of X and did a search and replace on ‘__x__’, replacing it with ‘woocommerce’ in the main (not child) folder. I replaced all 88(!) occurences and all of the standard woocommerce translations work fine.

Check out the documentation on the woocommerce site ‘Template Structure + Overriding Templates via a Theme’. There’s no mention at all about having to change the textdomain. It’s possible to override the templates in the woocommerce domain and have them reside inside the X theme folder without making them part of the __x__ domain and giving your customers the headache of having to track down an translate the 88 entries that would otherwise have translated automatically.

So, to summarise, X having chosen to replace all of the occurences of the ‘woocommerce’ textdomain to ‘__x__’ in the woocommerce templates in my view is completely unecessary and actually *stops* automatic translation from working on those 88 occasions in the X theme.

Can I suggest that you don’t take my word for it and give it a try? Try changing all 88 occurences of ‘__x__’ within the x/woocommerce templates folder back to the original ‘woocommerce’ and see how it would make life a lot less complicated for your customers that both use the woocommerce plugin and rely on its automatic translation.

Glad to hear that it works. Though, how do you translate it? Through mo/po files or just through the plugin? Loading textdomain is always required for mo/po files, and woocommerce textdomain is never loaded on the theme (plugin’s textdomain and theme’s textdomain are different).

__x__ should work on X’s woocommerce custom templates, since the strings are now part of X. Thus translation for X theme should work for all strings covered by __x__. I tried that, and it works and should be working at your end too.

Maybe, you’re only focusing on single textdomain? Let say you’re completely translating your site according to woocommerce plugin’s woocommerce. That means, other strings that fall under __x__ are of course will not be translated. There are threads where users complaining why other strings are not translated when it comes to X theme and Woocomemrce, and that’s the reason. They thought translating __x__ will translate woocommerce too, or if they translate woocommerce then it will translate __x__ too, we have to translate them both.

Wordpress or translation plugin does not decide what textdomain to translate, instead user should manually do it, choose one or both. And it will work your way since your translation is only applied for woocommerce.

I’m not really sure what’s the problem, but I can translate them with no problem on my end. Though, I’ll forward your concern and idea. Thanks for sharing.

Let me try to clarify it with a generic example:

1. Build a WordPress site in standard English: en_US language.
2. Install Woocommerce plugin and ‘FLATSOME’ theme.
3. In WordPress settings change site language to, say, Spanish: es_MX
4. WordPress and Woocommerce auto download their respective and existing es_MX mo/po files.
5. Result: WordPress 100% Spanish, Woocommerce 100% Spanish, the Flatsome-specific strings I need to translate the mo/po but that was to be expected.

All 2285 of the Woocommerce strings are translated automatically.

Now let’s try the same thing with X:

1. Build a WordPress site in standard English: en_US language.
2. Install Woocommerce plugin and ‘X’ theme.
3. In WordPress settings change site language to, again, Spanish: es_MX
4. WordPress and Woocommerce auto download their respective and existing es_MX mo/po files.
5. Result: WordPress 100% Spanish, Woocommerce 96% Spanish, the X-specific strings I need to translate the mo/po, again, to be expected.

The difference is that because the X theme developers have changed the textdomain in the Woocommerce template overrides from ‘woocommerce’ to ‘__x__’ unecessarily then 88 of Woocommerces 2285 words and sentences are no longer automatically translated by the woocommerce mo/po files.

Perhaps those 88 Woocommerce strings that are being blocked from being automatically translated could be the reason why you have threads from customers complaining that some strings are not translated? Having them find the 88 strings and translate them in the ‘X’ theme mo/po – duplicating the work already done by the Woocommerce guys – is hardly a solution or a good use of anyone’s time and can surely lead to customer frustration.

a template-specific example: _e( ‘Product’, ‘woocommerce’ ) has been ‘customised’ to: _e( ‘Product’, ‘__x__’ ), so it no longer automatically follows the woocommerce mo/po translation.

Many simple ecommerce terms such as ‘Product’, ‘Price’ and ‘Quantity’, and another 85 strings have all been changed from ‘woocommerce’ to ‘__x__’ in the woocommerce template overrides meaning that they don’t get translated automatically by the woocommerce mo/po any more!

Sure you can translate them all on your end by editing the X mo/po, but the point is that it’s completely unecessary work.

Hope this makes the problem a bit clearer.

Yes, I understand your point 🙂 and I knew that process.

And that only proves that you’re only relying on single textdomain for translation since it’s automatic. You’re solely relying on woocommerce translation and disregarding other textdomain, which in fact, other textdomain should work properly since it’s part of wordpress standard. But it just happen that you requires all translation be done by woocommerce automatically.

If you’re really relying on languages that are auto-downloaded through woocommerce, then expect that __x__ will not really work since it’s not connected to woocommerce. And because it’s your requirement, then it should work your way, and replacing all instances of __x__ is a good thing since it’s your preferred implementation. Though, not because it’s something you need, it doesn’t mean that we will sacrifice other means of translation. There are other users preferred other ways, and one of them is using mo/po files, and it’s wordpress’s standard. If we will going to choose between plugin’s author standard and wordpress standard, we will choose the one from wordpress.

It just happens that FLATSOME theme follows woocommerce standard that’s perfectly fits to your requirement. Though again, I’ll forward your concern to our developer. It’s not something we could decide 🙂 , maybe we will think a better way without sacrificing the other. MO/PO files requires some effort, but we can’t just ignore it.

Thanks for understanding.