[clmgatsoParticipant]

Hi,

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

[DarshanaModerator]

Hi there,

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!

[clmgatsoParticipant]

Ok, I’ll take a look.

Thank you.

Best regards.

[ChristopherModerator]

You’re welcome.

[gbhukParticipant]

Rather than start a new thread I thought I’d just tag onto the end of this one.

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.

[ZeshanMember]

Hi there,

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!

[gbhukParticipant]

Thanks for the reply. I don’t quite agree with your first sentence. For example another WordPress/Woocommerce theme I use is flatsome. They too have customised many of the standard woocommerce templates. However they didn’t change the occurences of the textdomain ‘woocommerce’ in the woocommerce templates to ‘flatsome’ and all of the translations work perfectly well.

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.

[RadModerator]

Hi there,

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.

[gbhukParticipant]

Hi,

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.

[RadModerator]

Hi there,

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.

[gbhukParticipant]

“If we will going to choose between plugin’s author standard and wordpress standard, we will choose the one from wordpress.”

Wordpress uses mo/po files.
Woocommerce uses mo/po files.
X uses mo/po files.

As you know, that way WordPress handles its translations, Woocommerce handles its translations and X handles its translations.

All follow the WordPress standard.

What breaks that standard is that there is no need for X to change the ‘woocommerce’ domain to ‘__x__’ in the woocommerce template overrides. By choosing to do so only 96% of the woocommerce translations in their mo/po files are able to be used, and the other 4% are taken over by X – those 88 entries almost exclusively referring to the exact same words or phrases, but the existing translations in the woocommerce mo/po files are now ignored.

However, as you say, it’s clear that this is not something that can be decided here in the support forum. It would be interesting to hear from the development team why they feel it’s necessary to change the textdomain in the template overrides when neither Woothemes nor other template authors do and 100% of the translations work perfectly well.

Until then I’ll simply replace the references to __x__ in the templates back to their native ‘woocommerce’ and move on.

[RadModerator]

Hi there,

X’s woocommerce templates are custom one, to make it work and fit to the theme. They are not stock templates installed along with woocommerce plugin, they are templates comes from X theme which you can customize anytime you like, like what you’re currently doing. You can replace our custom woocommerce templates, with the stock templates you have at your woocommerce templates if you wish.

There is no rule or standard that “woocommerce” shouldn’t be replace by another textdomain. And there is no rule or standard that it should be replace either. It’s just happen that we wan’t to apply all possible means of translation (not just the woocommerce way), in one theme’s textdomain.

Translations are not ignored, it just happens that you’re just relying on automatic translation of woocommerce textdomain.

Everyone has their own preference so you can do anything you like. Customize and replace all textdomains 🙂

Again, I’ll just forward your concern 😉 , Maybe we should apply option for custom textdomain, but I’m not the one that will decide. Stay tuned.

Thanks for understanding.

[gbhukParticipant]

Hi again! Just to be sure I wasn’t going mad I asked the question to Woothemes support. “As a theme developer should I change the textdomain in the woocommerce templates when overriding them.”

The reply:

Thank you for contacting WooThemes! I’m happy to help you with this. The textdomain belonging to woocomemrce should remain so if you want to use the translations that already exist for WooCommerce.

You can learn more about setting that up here: https://codex.wordpress.org/I18n_for_WordPress_Developers#Text_Domains

As you can see the textdomain needs to stay assigned to the plugin so it will “play well with others”

Hopefully, if your developers agree and change the textdomain back to ‘woocommerce’ in the template files then you’ll receive fewer support questions from customers asking why their woocommerce translations are only partially completed when they use x theme.

Hope this helps!

[RadModerator]

Hi there,

No problem :). As they said, if you want to use the translations that already exist for woocommerce then you should use woocommerce textdomain.

And their textdomain needs to stay assigned to the plugin. In which, there are different ways of loading textdomain on theme and plugin.

https://codex.wordpress.org/Function_Reference/load_plugin_textdomain (used by plugins)
http://codex.wordpress.org/Function_Reference/load_theme_textdomain (used by themes, and naturally, we use this)

Though again, we’re not restricting it. It should work as you intended. It just that we include all translation on one single textdomain, which is __x__. You may replace them as you preferred.

And in fact there are few cases before, the same as yours. Asking why some of those strings are never translated, and same answer. They should translate them using __x__ text domain, or replace textdomain to something they prefer. I don’t see much issues similar to this, they can translate them with no problem as they are not relying one single way of translation.

There are plenty of ways, we shouldn’t restrict it to one, though I agree, your way is faster for constant strings and existing strings. You should follow your preference. I’m not against at your suggestion, I’m not mad either 🙂 , your suggestion is one of all possible solutions we could apply. Again, maybe our developer could look into this and switch over to woocommerce textdomain.

In the end, replace it or not, you still have to translate both __x__ and woocommerce. You don’t want to see your site’s cart translated while home page, about us, and contact us are not. You can’t just restrict your whole site’s translation to woocommerce. X’s woocommerce textdomain is not really an issue, no matter what textdomain you apply, it will still be translatable. And the question is how.

Thanks my friend!

[Author]

Posts