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 9 replies, has 2 voices.

Last updated by Yvette 1 month, 2 weeks ago.

Assigned support staff: Yvette.

Author Posts
November 25, 2019 at 9:58 am

olafM-4

I am trying to: translate pages from EN to CN and EN to DE

Link to a page where the issue can be seen: hidden link The page is online. You can see that part of the page is in Chinese and part in English. Very obvious since the characters are very different. There are some complete paragraphs failing and some small subtitles.

I expected to see: It should show all the translated content in the right place

Instead, I got: a language mix

The story. I made a clone of the page, a copy using the plugin "Duplicate Post" and translated the page again. After that all texts show up correctly in the right language. The copz has fixed the issue. We need a solution to ensure that the original works. These problems happen too often.

November 25, 2019 at 10:22 am
November 25, 2019 at 11:19 am #5011411

Yvette
Supporter

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

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

Hello

You wrote: "The copz has fixed the issue. We need a solution to ensure that the original works. These problems happen too often."

This situation tends to happen when you make changes to the original post without having first completed an open/existing translation job. The page strings become unsychronised with the Translation Editor view of your post.

To avoid this, you need to complete all open translation jobs FIRST before making changes to a source language page.

How can you tell if a translation job is "open" on a post? Very simply - if there is a gear icon showing in the Languages sidebar of the editor view of the page/post, then there is a job "open".

Making a copy of the page/post solves this issue because you have a new set of strings from the current view of the post.

You can also correct this error on the page by triggering a rescan of the strings on the page. To do this, I opened the source page and entered a few blanks at the end of one of the untranslated blocks. Then saved the post. This triggers an "update required" on the ATE. When I then open the ATE and save the translations, the strings are now synchronised and the page shows the translations as you can verify on the frontend.

So, in short, the problem you are encountering has to do with a workflow that you are implementing.

I wait your comments on this answer.

November 25, 2019 at 1:06 pm #5012269

olafM-4

Holla,
The ticket started out as a chat but blitzed into an email. Chat is much more efficient though. Sorry I missed your email. The sun came out after 6 weeks of continuous rain and I needed to go out.
I think your analysis is correct. It will solve 90% of our new problems. Your statement about "triggering a rescan of the strings on the page" is the key. If this helps, then we are all good. As a user, I would argue that the algorithm has to adjust to the user and not forcing us into an impractical workflow. Content changes all the time and if translation takes a week, then with WPML we will crash the page. The translation editor should scan the page when the translator starts work and not when the job is put on his to-do list. This would be easy to implement when the translator uses ATE online. What do you think?
For now, I will keep your trigger method in mind for the next problematic translation. So far we focused on finding the culprit in the last paragraph that translated correctly. If I can cause a rescan of the whole page by adding a space to the unsynched paragraph, then that is a very feasible remedy.
Thank you. Let's keep the ticket open for a few days please. Then we know.
Kind regards
Wolfgang

November 25, 2019 at 3:36 pm #5015219

olafM-4

I followed your advice to cause a rescan of the page in another example but in vain. The issue remains. Please kindly look at hidden link and see that the DE version has blocks of the EN original. Again. I added some spaces to the blockquote, retranslate, failure. Any suggestion?
The translation to Chinese has been requested from our colleague in Shanghai, but she has not done it yet. It might fail as well. Certainly, after I added the spaces to the blockquote.
It would be nice if you could find the issue.

November 26, 2019 at 10:35 am #5020213

Yvette
Supporter

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

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

Hmmm - I see. Let me talk to the ATE team about this and I will get back to you soon.

November 26, 2019 at 2:09 pm #5022137

Yvette
Supporter

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

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

I think this may be a different issue.

Could you please send me a copy of your site. I may have to escalate this to our 2nd tier support.
https://wpml.org/faq/provide-supporters-copy-site/

Some other clarification questions.
- are the chinese translations being sent to a 3rd party translation service?

What about other pages, is the workflow workaround working for those?

November 28, 2019 at 10:26 am #5034835

olafM-4

We have provided access to our server. There is a clone in the /wpml folder that is up and running for you to test. You can make all the changes you want there. I am not familiar with the Duplicator Package. The site is huge. It is not a good idea to send a copy to another place.
The translations to Chinese are done using the ATE with the WPML system. No external translation agency.
Your workaround does work always, but often it does. When you said it forces a rescan of the page, then I was hopeful that this should be the solution. Sometimes we have to delete the page and recreate it from ATE. But this gives me a new page number, which is bad for other scripts that rely on the page number to be unchanged. It is also very time consuming to have to fix issues after every translation (80%).
Please research the issue a bit more. Second-tier support is not doing anything on such diffuse issues.

November 29, 2019 at 7:34 am #5040585

Yvette
Supporter

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

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

There seems to have been reported many issues regarding the matter you describe (strings translated but not appearing in the frontend).

We have released an update to CMS and String Translations to address most of the cases where this is occurring.

Could you please download the latest release to your site so we can be sure to be working with fixed code?

Thank you for notifying me when this is done.

November 29, 2019 at 8:37 pm #5045771

olafM-4

That sounds promising. We will test it then for a few days and give you feedback. For the sake of documentation, these are the versions we have today,
WPML Multilingual CMS Version 4.3.4
WPML String Translation Version 3.0.4
WPML Translation Management Version 2.9.2
Thank you Yvette.

December 2, 2019 at 10:03 am #5052019

Yvette
Supporter

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

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

Good idea to document the "pre" state. I sincerely hope that your testing shows that the issue is resolved with the latest releases.

The topic ‘[Closed] ENFOLD theme page translation fails, but is repaired by copy the pages’ is closed to new replies.