This is the technical support forum for WPML - the multilingual WordPress plugin.

Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.

This topic contains 9 replies, has 2 voices.

Last updated by The J 3 months ago.

Assigned support staff: Yvette.

Author Posts
April 11, 2019 at 7:05 pm #3592291

The J

When I sync prod variations, the attribute terms get cloned for each language.
Since the attributes are numbers (lenght, width, etc), this doesnt make sense and is confusing for admin.
These attributes are set to NOT translate (only 1 is)... but they still recreate terms in every lang 🙁
eg. 25, becomes 25-en for english ... not good.

I would like to use "global" terms for all langs, and only use the translated one for the 1 attribute I set as "translatable".

April 12, 2019 at 9:41 am #3597275

Yvette
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/Madrid (GMT+02:00)

Hello

I´ll be helping you with this.

The issue is with the use of the terms in global attributes. For these to be seen in all language spaces, they would need to be translated.

When you sync the product variations - are you using the WCML support tool?

For the record, the language suffix (e.g. "-en") can be removed by editing the term directly from the WordPress panel: Products > Attributes > Edit Terms
It´s just the WPML tool that is appending the language suffix.

Thanks for clarifying.

April 15, 2019 at 11:28 am #3613069

The J

It's not really clear honestly, how to manage a site/woocommerce, that has some attr/taxonomies that should NOT be translated, but used globally for all langs, and other that should instead be translated.

When using the WPML troubleshooter, the terms get duplicated in the other langs (even if set as NOT translatable).

So how to set an ecommerce to have GLOBAL product categories (must not be translated and duplicated in other langs!!!) and some attr that are GLOBAL and others translatable?

I think WPML should check into this scenario a little better, because this is the 3rd or 4th WC site that I have this issue with. Had successful chat support for one, but it shouldnt be this hard or arbitrary (WPML cannot decide for users how to use a site).

April 15, 2019 at 3:34 pm #3614619

Yvette
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/Madrid (GMT+02:00)

Hello

1. You wrote: "..Had successful chat support for one,"
Would you please share the resolution of that chat and why that same resolution woudl not be applicable for your current case?

2. You wrote: "..It's not really clear honestly, how to manage a site/woocommerce, that has some attr/taxonomies that should NOT be translated, but used globally for all langs, and other that should instead be translated..."

The crux of the confusion (i believe) seems to be with the way you are thinking about "translation". In general, all wordpress objects need to exist/be present in the different language spaces. The values of these objects can be text (translatable values) or numeric (not necessary to translate but need to then be copied). For WPML, creating the object in various language spaces is the what we call "translation".

The architecture of WPML will seek to retrieve from the database, the various objects using a single language code at a time. This is why the objects must exist (i.e. be "translated to") in all language spaces.

If you have attributes that need to be viewed from various language spaces, then indeed, they need to be "translated" to other langauges otherwise no object will be found. The attributes will not exist in that language space which will cause issues if, for example, you need these attributes for pricing.

There **is** a multilingual option setting to set an object to "appear as translated". However, this is only available for frontend templates. IF your solution/function is requiring any kind of database query, then you must have the ojbect really existing in the language spaces.

I hope that this might clarify what WPML views as translation. It is, in summary, creating the wordpress object in various language spaces and not just "translating" the label or value of the object.

April 15, 2019 at 4:12 pm #3614969

The J

Support fixed it but I don't know exactly how unfortunately.
They were able to do exactly what I needed at the time: have some attributes not translatable and used globally, others instead, could be translated.
In that scenario, I didnt need taxonomies to be global too though, now I do.

About WPML:

I understand its architecture and that is why I am letting you know, that as a developer of 20 years experience in web development, and at least 5 with WPML, it's too strict and arbitrary.
It might have been ok some years ago, but as needs grow and change, so should WPML, or at least try to adapt and listen carefully to its developers feedback (developers pay for your licenses mostly I imagine?).

There are *many* scenarios, where admin/shop manager might not want to duplicate categories, too many to ignore.

If this was a one-off issue, I would not be so vocal about it, but it keeps happening and it's getting complicated and time-consuming to work *around* WPML, instead of *with* it.

Eg. a car brand should not/cant be translated to another language, a fashion line cannot be translated, certain product categories are international and should not/cant be translated, attributes that are international sizes like s,m,l should not be translated.
Having a DB ful of trash terms (eg. Ferrari-en, Ferrai-de, Gucci-en, Gucci-de... etc.) is *not* an advisable way to manage things, and it shoulnd't be pushed as a normal or acceptable logic .

You are forcing people to create cumbersome structures, hard to maintain and sometimes messy, when it's not always necessary, or it shouldn't be.
The structure you talk about works in many cases, but not most, especially in certain industries.

WPML *should* be built around *developer's* needs, not the other way around.
If you want, an "Advanced" WPML setup should be possible, at least.

*Will you please consider a better structure or an open debate, with your developers, at least?*

----

Back to my original question then.
I have 20 Product Categories. I dont want to translate them, in any way. I want a unique term ID to be able to contain both eg. italian posts and english products, without having to create eg. Ferrari-en, Ferrari-it.
Same with size attributes: S should be applicable to either a eg. italian product or english product, without having to create s-it or s-en.
*Is this, normally, possible?*

April 15, 2019 at 10:16 pm #3616655

Yvette
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/Madrid (GMT+02:00)

1. OK
So I did some testing on my local installation.

Global Attributes
I stand corrected. You *can* set the translation options for the various global attributes to be "translatable" or "not translatable" and they will still be visible in the other language space for pricing. This was my primary concern.

Here is a test site for you to see this.
Login: hidden link

EN: hidden link (default lang)

ES:
hidden link

The variations are created with 2 attributes: size (not translatable) , color (translated)
The pricing is working fine.

What you cannot get around is setting the taxonomy "Product Category" to be non-translatable. In order for the product to work, I had to duplicate the various product categories. As you pointed out, the slugs for these translated categories initially had a language tag appended "-es".

I removed these by entering editing the slug here: Product > Categories > Edit

So, in summary:
- Product Cateogories must be duplicated (you can removed the language tag suffix) otherwise you will have errors in the panel
- Global attributes can be set at will to translatable or not. They can be mixed in variations.

Please do more testing on this site and let me know if there are further questions on how to set it up

2. Design Debate
For you various remarks, my suggestion to you is to fill in this "feature request" form including these same points. You can do this here: https://wpml.org/suggest-a-new-feature-for-wpml/

Amir, the CEO of the company is the only one that reviews/responds to these requests. Going through the support channel (i.e. me) has little chance to get your remarks heard at the right level to effect necessary changes.

April 16, 2019 at 12:53 am #3617079

The J

I kinda figured that attributes could already do that (which, btw, are taxonomies 😉 ), that's why I have been confused about other taxonomies... which clearly cant though.

Question: what is the *real* difference, in WPML overall, by setting a taxonomy as Translatable with fallback and "purely" Translatable (so without fallback)?
Could I use the fallback setting, for what I need? or would the system still duplicate all the product category terms anyway?
And what about queries?

I have sent the feature request!
Thank you for your assistance.

April 16, 2019 at 11:07 am #3621303

Yvette
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/Madrid (GMT+02:00)

1. Question: what is the *real* difference, in WPML overall, by setting a taxonomy as Translatable with fallback and "purely" Translatable (so without fallback)?

I´ve put in a question to our senior support team to see if I can get you any further info/documentation on this question so I don´t confuse concepts.

To my knowledge, the difference is best understood in what it will NOT do. Placing a taxonomy to "appear" as translated will not satisfy any SQL queries. It is only satisfying the need to show information on the frontend. This means, for example, that a taxonomy that has been configured to appear as translated, can appear with default language text on the frontend of a 2nd language page.

To my understanding, the "replacements" are affecting only frontend templates.

2. You asked: "...When I sync prod variations, the attribute terms get cloned for each language....
would the system still duplicate all the product category terms anyway? "

Are you synching the product variations using the WCML troubleshooting?
or are you using WCMl > Attributes > Syncrhonise product variations

I did some testing in the sandbox site.

If you are using the troubleshooting tools, the results are not desireable. The tools recognise something is "off" and attempts to "fix" the issue when it should not. HOwever, the normal attribute sync seemed to work ok.

2.1 WCML > Status > Troubleshooting > Fix translated variations relationships
This created terms with language suffix and placed them in the terms listing (nonsense result)

2.2 WCML > Status > Troubleshooting > Sync products variations
This does not detect/show any issues since the variations are correctly translated even if one attribute is listed as not-translatable.

2.3 WCML > Attributes > Color (the translatable attribute) > Synchronise product variations
In this case, the non-translatable term (e.g. Size) did not have the terms duplicated.

April 16, 2019 at 11:32 am #3621515

Yvette
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/Madrid (GMT+02:00)

I forgot to mention the testing done with Product Categories.

I deleted all duplicated product categories and set the taxonomy to be "Appear as translated".

Result:
The taxononmy archives did not work in the 2nd language:
- English(default) hidden link

- Spanish: hidden link
First, notice the permalink - it includes the ES base but the permalnk is EN.
However, the sidebar still shows a listing of product categories (using the Product Cateogry widget)
Here you can see the "frontend" substitution working. All EN product categories are listed but the "Uncategorized" is showing the translated version.

April 16, 2019 at 11:48 am #3621665

The J

We came to the same conclusion.

I think that the "Translatable with fallback" is confusing at the moment and could cause problems... because it doesnt really use the not translated one as global (if no translation is found), therefore it's kinda useless and misleading.

The way I see it, that solution should be close to what I mentioned in my previous points: if no translation is found, use the default lang one as global, both in backend and frontend queries.

Anyway, thank you for your time and I hope that Amir will think about it! 🙂