Please make sure to update to WPML 4.3.6 and check our list of Known Issues before reporting

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

Last updated by Pieter 7 months, 2 weeks ago.

Assigned support staff: Bruno Kos.

Author Posts
April 17, 2019 at 12:49 pm #3630893

Pieter

Peter Materna has asked me to open a ticket about this issue that we have spoken about since a few weeks.

My client has several sites: a UK one for the UK market, a French one for the French market and a US one for the US market.

Apart from that there is staging setup with WPML where Irish English is the default language and there are translations for Polish, Spanish and a few other European languages.

Recently they have made the decision that the languages of this staging site are to be added to the US .com site. But they want to do so in a way that is different than usual.

Although US English is the default language on that .com site, the European languages that are going to be added are in fact based on a default language of Irish English (not to be confused with the locale ga). Now for each language that is going to be added the requirement is that we use 4 letter language codes in the URLs.

To illustrate this:
- US English site can be reached on .com/
- Irish English site can be reached on .com/en-ie/
- Polish site can be reached on .com/pl-pl/

So far so good.

Now we have added European Spanish which follows the same pattern:
- Spanish site can be reached on .com/es-es/

That also works fine.

Now the client wants to add Spanish for the US market (as a huge part of the USA is in fact speaking Spanish). Although our initial suggestion was to use one of the Latam Spanish available, the client has insisted on using the url format earlier established, thus: es-us

And here is where the problems have started.

Since we already have existing Spanish I have tried to duplicate the Spanish content to the new ES-US content, but that failed. Also duplicating from the default language US English failed. Sending the content to ICanLocalize for translation is not possible either, because it is not recognized as a language. We can overcome that issue by using XLIFF files or manual translations if necessary though.

But when we started implementing ACF Site Options into that new ES-US language, is when mayhem really broke out. These site options have Elementor IDs assigned to them, so basically per language we fill in the Elementor ID for a specific template or section.
What happened was that whatever I filled in for the ES-US language, was automatically copied over to both ES-ES and US English. Something I have never seen in my entire WPML career!

Basically my question is whether you have heard of this happening ever before, and if so what can be done to prevent it? And my other question is what would be a good solution for adding languages given the requirements above?

Would it perhaps be possible to make the locale es_MX, but then the language code (and hreflang) es-us?

April 17, 2019 at 2:50 pm #3632045

Vincenzo
Supporter

Languages: English (English ) Italian (Italiano )

Timezone: Europe/Rome (GMT+01:00)

Hello, thank you for contacting WPML Support!

The only "issue" that I can see in the debug info is that the required MBString extension is missing.

This may be an issue caused by the specific structure of the languages.
I think the quickest way to deal with this issue is to reproduce it in a Sandbox and to escalate it to our 2nd tier support.

1. Could you please replicate the problem in this specifically created test installation?
You can access it by clicking on this One Click Login link:
hidden link
You will find your username and password in the site's Dashboard or in Dashboard -> WP Sandbox

Please configure WPML exactly how you described in the ticket and install/activate only the plugins and/or the theme required to reproduce the issue.

After that, please repeat the steps to reproduce the issue on this test install too.

It would be very useful if you could send me a detailed list of the steps used to replicate the problem in the Sandbox so I can share it with the 2nd tier support.

2. Regarding the second question, as you know, it is technically possible to change the Default locale value of a language from WPML -> Languages -> Edit languages.

You may try that and then test the site with an hreflang test tool.

The only notice I see when I check the current site with an hreflang test tool is this one:

Missing region-independant link for that language (en)

Thank you

April 17, 2019 at 4:25 pm #3632879

Pieter

Hi Vincenzo,

Thanks for your reply.

Could you please elaborate on "the required MBString extension is missing"?

Furthermore I can set up the languages as they are on the site of the client, but I am not sure how you want me to go ahead making the exact same setup on this sandbox?

Peter Materna mentioned in his email to me that a colleague had mentioned to him that:
I've seen original overwriting several times, but it's difficult to catch why it happens. In some cases, the translation was first a duplicate, then set as translate independently but for some reason still behaved like a duplicate. In some cases deleting the translation and redoing them was enough. The suspect: issue with Elementor or ACF.

I much rather spend time researching this particular issue, than that I am going to replicate a client site on your sandbox (read: that is impossible for me to do).

April 17, 2019 at 4:43 pm #3633069

Vincenzo
Supporter

Languages: English (English ) Italian (Italiano )

Timezone: Europe/Rome (GMT+01:00)

Hi,

1. the mbstring (Multibyte String extension) PHP extension seems missing from the server that is hosting the site.
- https://wpml.org/home/minimum-requirements/

You should see a warning on WPML -> Support in the Info -> PHP section.

2. By reading your description of the problem I thought that both issues happened only when the new language was created (EN-US).

If this issue would be reproducible on a Sandbox by creating the same language there and repeating the same steps, it could be faster to debug and solve by our 2nd tier or developers.
There is no need to reproduce the entire site.

On the other hand, if this issue would not be reproducible on a fresh install (Sandbox), then we would be sure that the cause of the issue is not the language structure and it will require other steps (eg. disabling all plugins and the theme except WPML, testing a copy of the site on a different server, etc.)

This is why I think that the best way to deal with this issue is to start by trying to reproduce it.

April 17, 2019 at 5:18 pm #3633373

Pieter

Hi Vincenzo,

Thanks for your effort, but this has nothing to do with creation of languages.

The site comes with an Options page (ACF Pro) which contains a couple of variable fields where an Elementor ID needs to be filled in. These Elementor IDs are certain sections that receive translations.

The site uses an odd (for lack of a better word) language URL format:
- US English is default on .com
- Polish is .com/pl-pl/
- European Spanish is .com/es-es/
- Irish English is .com/en-ie/

This we have all working without any issues.

Then instead of using Mexican Spanish for the US, the client has opted to use ES-US.
Adding the language then becomes .com/es-us/ with the code es-us, locale es_US and hreflang es-us.

As US Spanish will be an almost verbatim translation of European Spanish, I then duplicate the content as well as the Elementor Section Templates.

And that is when everything falls apart. Immediately after duplication of the templates into the new ES-US language and adding the IDs of these templates to the ES-US option page, all options pages of all other languages get the IDs of this new ES-US language.

These Spanish Elementor Section Templates are themselves duplicated from Polish as that was the first European language that was added to the site (after the default US English). After duplication they have of course been set to independent translations.

Now your colleague told Peter Materna that specifically that might be a conflict between WPML, Elementor and ACF, so I really would like to focus on that.

Rebuilding the site on the 3rd-party sandbox site is not an option I'm afraid, but I am happy to give someone of your 2nd tier support access to a dev box we have prepared for this.

Please let me know.

April 18, 2019 at 10:50 am #3638495

Pieter

The same issue is happening again when adding Dutch (nl-nl) and German (de-de) to the site.

As I am now alert to the issue, it happens immediately upon batch duplication.

This time I was duplicating from Irish English (en-ie), which in itself also was a duplicate when we added it.

So this issue really seems to be related to duplicated content (whether or not Elementor Pro and ACF Pro play a role in this I do not know).

April 18, 2019 at 12:00 pm #3638993

Vincenzo
Supporter

Languages: English (English ) Italian (Italiano )

Timezone: Europe/Rome (GMT+01:00)

Thank you for adding further details.

1. Can you please verify the translation status of those custom fields and of the related Systems fields?
- As you know, you can check the status of those fields in WPML -> Settings -> Custom Fields Translation.
You need to click on the "Show system fields" link to see the Systems fields too.

2. Can you please tell me the name of the related fields so I can check them too in the debug info?

3. Can you please try if this happens when duplicating the original content and not a translation?

Thank you

April 18, 2019 at 1:39 pm #3639665

Pieter

Hi Vicenzo,

ACF Options are not written to the postmeta table, but to options instead and therewith not visible in WPML -> Settings -> Custom Fields Translation.

The names of the related fields are:
- homepage_masthead_section_shortcode (key: field_5b588bce17222)
- try_our_demo_section_shortcode (key: field_5b6ad0822280c)
- call_to_action_section_shortcode (key: field_5b6adca55c0e8)

April 18, 2019 at 3:28 pm #3640411

Vincenzo
Supporter

Languages: English (English ) Italian (Italiano )

Timezone: Europe/Rome (GMT+01:00)

Hi,

1. Are these options registered or registrable as admin_texts in WPML -> String Translation?
- https://wpml.org/documentation/getting-started-guide/translating-theme-options/

2. Just as a test, can you please try if this issue happens when duplicating the original content and not a translation?

3. I can see that there is an open internal ticket about issues with ACF options.

In order to quickly escalate this issue to our ACFML developer, I need either a copy of a site where the issue is reproducible or the issue reproduced on the Sandbox that I shared with you previously.
- Please add a detailed list of the steps used to reproduce the issue.

Thank you

April 18, 2019 at 5:44 pm #3641181

Pieter

Hi Vicenzo,

As I wrote earlier to you and I also informed Peter Materna of this issue before he asked me to open this ticket, it is in no way possible that I rebuild the site here, on your sandbox or with Duplicator. Apart from the immense amount of work and data, I am bound by legalities, so that has been a non-option from the get-go.

It also makes no sense whatsoever to try and replicate the issue anywhere else than the servers where the site is running on, because the entire setup is bespoke.

A few times I have invited you to ask someone from 2nd tier support to have a look on our server; you have ignored this invitation insofar.

I have the feeling that you are focusing on the wrong things here and it seems you have not read the issue.

Again:
Peter Materna (from WPML) has already brought up this issue with another colleague and that person has said the following:

I've seen original overwriting several times, but it's difficult to catch why it happens. In some cases, the translation was first a duplicate, then set as translate independently but for some reason still behaved like a duplicate. In some cases deleting the translation and redoing them was enough. The suspect: issue with Elementor or ACF.

I can confirm that the issues come up after using the option of "BATCH DUPLICATION" in WPML Translation Management.

I can also confirm that when doing this batch duplication, the source was created as a duplicate itself.

After mass duplication I usually do a direct db query to remove the `_icl_lang_duplicate_of`-meta_key from the postmeta table.

DELETE FROM `table-prefix_postmeta` WHERE meta_key='_icl_lang_duplicate_of';

As the colleague has mentioned that it is difficult to catch when it exactly happens we have been trying to figure that out, but in the meantime have blown up our development server.

I really would like to urge you to get in contact with the colleague that Peter Materna is speaking about, so we can get to the bottom of this issue, instead of trying to shoot arrows in all different directions.

Thank you.

April 19, 2019 at 8:47 am #3644161

Vincenzo
Supporter

Languages: English (English ) Italian (Italiano )

Timezone: Europe/Rome (GMT+01:00)

Hello,

I was there when Peter asked about this issue and when my colleague said the phrase that you are quoting. We were thinking that the issue was about normal ACF custom fields.
Of course, I talked about this issue with my colleague and, with her permission, I will quote here what she said on that very occasion, just after the sentence you quoted:
in some cases deleting the translation and redoing them was enough.
In your case, since it seems quite complex, I'd try reproducing from scratch

1. I think there is a misunderstanding about the meaning of reproducing the issue in the Sandbox (from scratch).
You don't need to send us any private data or rebuild the site in the Sandbox.

What is required is just to create the minimal conditions to reproduce the issue in a controlled environment. This usually requires just adding the customized theme and only the needed plugins to reproduce the issue.
After that, you just need to configure WPML in the same way of the affected site, add one post and duplicate it to reproduce the issue.

2. You say: It also makes no sense whatsoever to try and replicate the issue anywhere else than the servers where the site is running on, because the entire setup is bespoke.

Actually, there are many reasons to do that.
- If you could verify that the issue is not reproducible in a different server environment, it would help to exclude many potential causes and to better understand the origin of the issue.
- If the issue is not reproducible in a fresh install, it means that there is some custom setting or code that is causing this, and this also would help to understand the origin of the issue.

3. You say: A few times I have invited you to ask someone from 2nd tier support to have a look on our server; you have ignored this invitation insofar.

I offered to escalate the issue directly to the ACFML developer.
Before escalating an issue to 2nd tier or to our developers, I am required to do some basic checks. to exclude most common issues. and I need to provide the steps to reproduce the issue in a fresh install or, at least, a copy of the affected site.
As it seems there is no way to obtain any of these required things, I will try to escalate the ticket to the 2nd tier anyway, but I can't guarantee their involvement because of the missing requirements.

4. In order to try escalating this issue, I would like to request temporary access (wp-admin and FTP) to your test site where the issue is reproduced and a detailed list of the steps required to reproduce the issue there.

You will find the needed fields for this below the comment area when you log in to leave your next reply. The information you will enter is private which means only you and I can see and have access to it.

If you don't see the form below, please don't add your credentials as they will be publicly exposed:
hidden link

Thank you

April 19, 2019 at 4:11 pm #3647427

Vincenzo
Supporter

Languages: English (English ) Italian (Italiano )

Timezone: Europe/Rome (GMT+01:00)

Hello,

I talked with our ACFML developer and he said that the older way of translating options pages is not possible anymore. The translation of the ACF Options can only be done from String Translation.

However, he is working towards adapting complex ACF options page translation.

You can also see a similar ticket here:
https://wpml.org/forums/topic/options-page-not-showing-the-translation-in-v1-2/

If you can confirm that the issue is similar to the one reproduced on that ticket, I will escalate this ticket to our developers.

Kind regards
Vincenzo

April 19, 2019 at 4:55 pm #3647619

Pieter

I talked with our ACFML developer and he said that the older way of translating options pages is not possible anymore. The translation of the ACF Options can only be done from String Translation.

Nobody thought that this would be a breaking change? And nobody thought it would be a good idea to actually test this in a real world scenario?

I really have no idea what you guys are thinking when you invent new "features" or try to "improve" things that do not need improving!

Similar <a href="https://wpml.org/forums/topic/options-page-not-showing-the-translation-in-v1-2/#post-3622117">as the person of the link you posted</a> we also use our options not only for textual strings. See this screenshot:
monosnap.com/file/3Ec8dgOfiOAexcoJlhtohNi6HDjuI5

So how can we translate this?

Just like the person in the other post, if this does not change, then you force your users to roll back to the previous version of ACFML and fix it at that.

I am really unhappy with this!

April 23, 2019 at 12:20 pm #3663791

Bruno Kos
Supporter

Languages: English (English )

Timezone: Europe/Zagreb (GMT+01:00)

Hi,

Vincenzo is currently on a vacation, so I will take over. I went over the whole thread in detail and based on all of this, can you tell me:

- what is the issue you want to solve here? is it about the ticket title, this "monosnap.com/file/3Ec8dgOfiOAexcoJlhtohNi6HDjuI5" or something else?

Vincenzo explained in his reply https://wpml.org/forums/topic/previously-working-translations-fall-apart-when-new-language-is-added/#post-3644161 about the importance of Sandbox sites and that these usually require a minimum amount of work, as there are not site clones.

In short, if we can't reproduce, we can't trace the error and hence can't fix it.

Let me know how you want to proceed and what do you think we should focus on.

Regards,
Bruno Kos

April 24, 2019 at 8:49 am #3670585

Pieter

Hi Bruno, thanks for your message.
Thing is that whilst we were experiencing the initial issue, the 1.2 release of ACFML messed things up even more. So we have now rolled back and locked the setup on the previous, working version to be able to fully test the initial issue.
At the moment I’m a few days out of town, so I will be able to start testing again next week, upon which I will update this ticket again.