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 15 replies, has 3 voices.

Last updated by George Botsev 8 months, 3 weeks ago.

Assigned support staff: Yvette.

Author Posts
September 27, 2019 at 4:06 pm #4655741

George L.

It appears that if you try to edit a product in the wrong language, the links from that product are broken.

For example, if you have Product 1 in English and Translation 2 in German, if you try to edit product 1 using /wp-admin/post.php?post=1&action=edit&lang=de the translation link is broken, which causes multiple side effects.

Steps to reproduce
1. Create a new product (id: 1)
2. Translate this product into say German (id: 2)
3. Go to /wp-admin/post.php?post=1&action=edit&lang=de
4. Save

Expected results
The admin interface is in German, but the product configuration and links to its translation remain unaffected

Actual results
The admin interface is in German. when saving, the "Language of this product" is set to "German" and the links to the translated version (id: 2) are lost.
If you save the original product in English again, the links are not reinstated.

Why this is bad
There are cases where you have a list of product IDs that need to updating. It is impossible to know the language of those products, so unless you know of this bug, you just replace the post ID.

How to resolve
WPML should not be using the "lang" Query string value to set the product's language or change the value of the "Language of this product". The query string should be used to decide the interface language, but any important fields should only be set when creating a NEW product, not while editing existing ones.
If this is not possible, WPML should instead have a validation to check the given "lang" value and compare it to the language of the product. If they are different, WPML should redirect to the correct language.

Side effects
Other than the obvious issue that translations are unlinked, when Composite Products are used, if you've set ID 1 as a component for EN and ID 2 as the component for DE, this bug causes the component to disappear from the EN version of the composite product. This is because the composite is set to language EN, but the component is now set to language DE. You generally have few simple products, but loads of composites, so a small bug like this, can cause a large number of products to break.

p.s. I have not tried with other post types, but i see no reason why this bug wouldn't affect any post type.

p.s.2 I cannot provide a duplicator package or a dump of our database. This is not necessary however as the issue can be reproduced on vanilla installtion of WPML.

September 27, 2019 at 10:35 pm #4656807


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

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


I understand the case you explained to be the following:

- user profile setting is enabled
WPML language settings > Editing language > Set admin language as editing language.

- A product is trnalsated to 2 languages
- attempt to edit the primary product using the admin language = 2nd language

I was unable to reproduce this in a fresh installation of WPML/WCML/Woocommerce
Please see the following sandbox site:
hidden link

Here, you can use the following link to edit an original language (EN) in the 2nd language (ES). The translation links are not broken.

hidden link

If you are able to reproduce the error, can you please let me know?

September 28, 2019 at 6:49 am #4657957

George L.

Hi Yvette,

I did not make any changes to the staging you sent me.

I just visited the products you made and noticed the folllowing

On /wp-admin/post.php?post=32&action=edit&lang=en
1. The UI is in Spanish (should be EN)
2. There is no link to the Spanish translation
3. The language of the product is set to English (Correct)

On /wp-admin/post.php?post=98&action=edit&lang=es
1. The UI is in Spanish (correct)
2. There is no link to the English translation
3. The language of the product is set to Spanish (Correct)

Hope this clarifies the issue

October 1, 2019 at 6:23 am #4668869


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

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

Thanks - I´m looking at this now. I appreciate your patience

October 1, 2019 at 9:44 am #4670529

George L.

Right, so there are a few different issues here.

1. The translations get unlinked.
2. The UI changes language unexpectedly.

Issue #2 is happening if you do the following
1. Go to hidden link
2. Then go to hidden link by updating the URL on your browser.

The first time you load product #32, the UI is in Spanish. If you refresh, the UI changes to English.

This works the other way round too, so if you do steps 1 & 2 the other way round, you'll get the UI in English initially, then Spanish after you refresh the page.

I imagine you use the _icl_current_admin_language_ cookie instead of the lang variable on the URL to decide the language of the UI

October 1, 2019 at 12:12 pm #4671929


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

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


THanks for that - I was able to reproduce reliably. I´m prepping the escalation now.

October 1, 2019 at 2:27 pm #4672935


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

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


I´ve gone ahead and escalated this to our 2nd tier group.

I believe this has to do with the difference between "object language" and "session language" and specifically what the "lang" URL parameter is actually referring to.

In any case, the result should not be disconnected objects - let´s see what the 2nd tier group finds out.

October 14, 2019 at 2:57 pm #4751295

George Botsev

Languages: English (English )

Timezone: Europe/Sofia (GMT+03:00)

I am George from 2nd tier support.
I visited your site and I understand the issue.
The parameter should not be changed like you do.
Doing that is the cause that makes the translation to disconnect.

Instead you should delect the option "Assume that the original language of all strings is English" in WPML > Theme and plugin localization

That should make the profile of yours, if it is set to Spanish to display the proper translations when you edit the page and not to switch the language.
So in the end you won't need the change of the lang parameter

October 14, 2019 at 3:04 pm #4751311

George L.

Hi George,

This setting is/was enabled, yet the issue occurred. Can you please try the steps I've given you and confirm if your solution actually works?

To clarify, what I described is an edge case scenario, but unfortunately affected us and the plugin didn't work as it should.

October 15, 2019 at 8:12 am #4755331


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

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


I was reading through George´s notes and I think there is a typo in his response to you. His working notes say the following:

"It seems that the problem was because "Assume that the original language of all strings is English" was set!
Unsetting that option fixes the problem from above. "

So, please read his response with "de-select". If you still experience the issue, I will ask him to take another look.

October 15, 2019 at 8:43 am #4755487

George L.

Thanks, this solution partially fixes the issue.

The UI no longer changes language when i set my default editing language to EN and deselect the "Assume..." option.

The issue with the unlinked translations remains however!

So if you save any product while being on the wrong "lang", the translations become unlinked.

For example, if i visit /wp-admin/post.php?post=123&action=edit&lang=de where the default language is EN and a DE translation exists, when i save, the translations are unlinked.

October 15, 2019 at 9:00 am #4755675

George L.

Also, slightly off topic, but is there an ETA for the versions you currently have in Beta? I've asked in the relevant blog post but my comment hasn't been approved (or answered) yet

October 16, 2019 at 9:19 am #4764015


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

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

OK - let me pass on your comments to George and see what he can respond about your observations.

October 16, 2019 at 9:25 am #4764045


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

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

Hello again.

I was reading through the messages and I do see that George wrote:

"The parameter should not be changed like you do.
Doing that is the cause that makes the translation to disconnect."

Unless I am mistaken, it appears that this behaviour will happen if you use the URL language parameter as you do. It is not intended to have this use. From you last message, it sounds as if you are still attempting to use a URL language parameter.

October 16, 2019 at 9:39 am #4764201

George L.

Correct. I did explain my reasons for that.

To give you another example, imagine you need to make a tiny change across a big list of products (let's say 100), but not all products in your inventory.

Also, assume you use a large site with hundreds of thousands of orders.

WPML is not optimised well enough (hopefully things will improve with your changes currently in beta).

If you try to go to the products list page, search for a product, then open it, it'll take minutes just to get to a single product.

Instead, you can be given a list of product IDs and be asked to make the change. This is quite common and we've done it multiple times in the past for various reasons.

What's the way of accessing those products? Simply replace the product ID on the URL.

As it's still permitted to translate products without WPML's translation editor I see no harm in editing translations that way.

Unless you are given the list of IDs broken down by language (harder to do, and more likely to forget), you're gonna end up unlinking the translations.

If WPML "recommends" its translation editor, then the above steps are perfectly valid and WPML should not act that way.

If WPML "enforces" its translation editor, then you should prevent users from accessing translated products that way (or redirect to the right place).

Even though you have a standard way you work, not everyone conforms to that and there are always exceptions or reasons to do things differently. This is the main advantage of WP anyway.

I, therefore, think this is a problem that needs fixing.