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 Pieter 3 months ago.

Assigned support staff: Bruno Kos.

Author Posts
May 16, 2019 at 7:42 am #3822717

Pieter

Site uses 4 letter language/country codes divided by hyphen.

Default language is US English (en-us).
Secondary languages are Polish (pl-pl), Spanish (es-es), Irish English (en-ie) and now Hispanic (es-us).

Site uses ACF and Elementor extensively, among other plugins.

Polish content was duplicated from US English, then the duplicates were overwritten with translations.

Because European languages largely have the same layout and site structure, which differs from the US English site the next translations (Spanish and Irish English) were done as duplicates of Polish.

Hispanic is now being implemented and it follows the layout and structure of the US English site (as it is Spanish for the US market), so several duplicates were made from US English; but as we already have European Spanish we have done most duplications from Spanish were possible.

Because the site uses fairly unique language codes AND we have basically invented the Hispanic language (most other sites use one of the Latin American Spanish versions to target Spanish speakers in the US), ICanLocalize does not recognise the language and can therefore not provide translation services.

To tackle that we are using an outside translator to manually go over the translations. We have set the translator up to translate European Spanish (es-es) to Hispanic (es-us), using the WPML Translation Editor (classic version I believe you call it now).

Now the problem is that in the WPML Translation Editor English is showing up for several content elements as the source language.

We have checked the entire database and neither in the `wp_posts`-table, nor in the `wp_postmeta`-table is there any English content for this post-ID.

And since all content in the tables of WPML has been base64-encoded, there is nothing to check for us there.

So the question is: have you ever come across this problem?

I suspect it has something to do with duplicating translations for a source that originally also duplicated from another source. Perhaps there is something that WPML does when it does the first duplication?

Unfortunately I cannot give site access nor can I make the site available via any way, so this question is purely aimed at your collective experience as per Amir's suggestion.

May 16, 2019 at 9:05 am #3823457

Bruno Kos
Supporter

Languages: English (English )

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

Hi,

Thank you for contacting WPML support!

We have set the translator up to translate European Spanish (es-es) to Hispanic (es-us), using the WPML Translation Editor (classic version I believe you call it now).

I've performed some tests on my local installation. This is what I've did:

- English is default
- Translated English page into Croatian (but forgot to translate one part into Croatian (see image which one is it)
- Added new language (Albanian)
- Created new translator who can translate Croatian->Albanian language pair
- All the fields were properly picked up from Croatian translation
- I returned to Croatian translation and translated that part
- I returned back to my Croatian->Albanian translator and opened their translation job, but that part which I have now translated wasn't picked up
- I cancelled this translation job and created a new job and the newly translated part is now there

Why is that? Most likely because in order to guarantee that it would be possible to send/receive translations among various systems and CAT tools, WPML would take this data, encode it into base64 and save all of this as translation job. Also, this ensures that the original job content can't be edited during the translation itself, as it may cause many problems, especially to our paid translation services.

So what comes to my mind related to your case are these things:
- the translation job was created before the translation from English into European Spanish has been done
- Translation manager have may accidentally created English->Hispanic translation job (most likely not, as it would be noticed immediately)
- string language was changed for these elements for some reason, but not sure if that's the case either

Regards,
Bruno Kos

May 16, 2019 at 11:19 am #3825463

Pieter

Hi Bruno,

I appreciate your efforts in trying to replicate the issue.

From the process that you describe it is not clear whether you indeed have first done the duplication of the content?

I think that is the most important step of this whole process and as mentioned I suspect that the conflict is related to that.

1. Default English

2. Duplicate English for Polish, then translate manually

3. Duplicate Polish for Spanish, then translate manually

4. Duplicate Spanish for Hispanic, then translate via the Translation Editor

May 16, 2019 at 1:30 pm #3826283

Bruno Kos
Supporter

Languages: English (English )

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

Hi,

I missed the fact that I need to duplicate first, so I did it. I followed the same steps and this is what I see:

4. Duplicate Spanish for Hispanic, then translate via the Translation Editor

In my case, there were two things that happened when I duplicated from Albanian to French:
- it showed Albanian language in the header and English content (wrong)
- after I refreshed the Albanian page in the backend of the site, now the same URL gives me the correct English content and translation into French
- however, this doesn't seem right since we were duplicating Albanian page in fact and not the original English

This does seem like a bug, but I guess that it was never spotted as this is quite a rare scenario I think. However, there is one thing we need to consider. See this link:
https://wpml.org/documentation/translating-your-contents/how-wpml-keeps-track-of-your-translations/

""""
You might edit an existing translation using the WordPress editor or a page builder. These edits will not be “seen” by WPML. If you update these contents using Translation Management, these edits will be overwritten and lost.
""""

So since we edited all the subsequent pages manually, this link got lost due to how WPML works and when we activated Translation Editor, it fallback back to where it all started - English page that is - and returned these values.

We could try emulating the same behavior on our Sandbox site if you are interested and escalate to developers for their opinion and possible fixes.

Regards,
Bruno Kos

May 17, 2019 at 4:00 pm #3835857

Pieter

Hi Bruno,

Great work on being able to replicate this on your side!

So it is a bug then.

I agree that the scenario is not very likely to happen very often, although I must say that I hardly ever use translation editors and almost always implement translations manually, doing the duplication as first step.

Although duplications of duplications are something that does not happen too frequent, they do happen for example on sites where there is a lot of localised content. de_de, de_at, de_ch are good examples that come to mind.

The excerpt you explain from the linked page indeed seems to be where the problem starts and this would mean that duplication can (and perhaps should) only ever be done from the default language and never from one of the secondary languages (if they were generated by doing a duplication in the first place). Not sure if that last part between the brackets has to be true or not, I guess that cannot be very hard to test out 🙂

Although I'm quite busy at the moment (hence my late reply to you), I would definitely be interested to get to the bottom of this.

Thanks and wish you a great weekend!
Pieter

May 20, 2019 at 5:21 am #3843737

Bruno Kos
Supporter

Languages: English (English )

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

Hi,

I've asked our 2nd tier about it on what they think and will get back to you once I get more information.

Regards,
Bruno Kos

May 20, 2019 at 10:36 am #3846019

Bruno Kos
Supporter

Languages: English (English )

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

Hi,

This issue has been confirmed as a bug by our 2nd tier support and escalated further. As for fixing it, I can't give you any dates. This is totally up to developers - severity of the issue and number of reported cases (among other things) decide its queue on the list.

I will keep this thread updated as soon as I get any new information about possible fixes!

Regards,
Bruno Kos

May 20, 2019 at 2:18 pm #3847847

Pieter

Hi Bruno,

Thanks for your message and that your 2nd tier support also has confirmed this indeed is a bug.

Since the timeline for a fix of this bug is unclear, is there a suggested workaround? Is there something we can do to fix this manually directly in the database or something?

The reason I ask is because in the current project as described above, all European language are in fact duplications of the first PL duplication. It would be great to know of a workaround, because the alternative it seems is starting from scratch, which is the absolute worst case scenario at this point.

Thanks,
Pieter

May 21, 2019 at 8:16 am #3853001

Bruno Kos
Supporter

Languages: English (English )

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

Hi,

is there a suggested workaround?

I am not sure exactly how, based on the number of jobs that went through. The only thing that comes to my mind is to use “Copy content from…” option when you create a translation (and not a duplicate), so that the troubled link disappears, but you still fill in the page with duplicated content (custom fields do not copy, though).
https://wpml.org/documentation/translating-your-contents/displaying-untranslated-content-on-pages-in-secondary-languages/using-content-duplication/#differentiate-2-buttons-copy-content-from-and-overwrite-with

You could get this this point by simply switching the page language into the language you want to make translation within.

There is also this option you could try (after creating translation and not a duplicate): "Overwrite with [original language] content: Copy everything, or convert the current translation to a duplicate."

And test then - perhaps it would work.

Regards,
Bruno Kos

May 21, 2019 at 8:36 am #3853247

Pieter

Thanks for your thoughts Bruno!