Skip Navigation

This thread is resolved. Here is a description of the problem and solution.

Problem:
The client reported an issue where opening a translation in the Advanced Translation Editor (ATE) and then either making edits or simply opening and closing it without changes, resulted in some of the text on the frontend becoming untranslated. This issue occurred despite the translations being displayed as complete in the ATE. The client mentioned that the affected pages were not top-level pages, had escaped URLs, and contained a significant amount of text and translations.

Solution:
We recommended updating the WPML Multilingual CMS, String Translation, and Media Translation plugins to their latest versions, as these have been optimized for compatibility with WordPress 6.5. To update the plugins, the client should navigate to the WordPress admin area and press the 'Check for updates' button on the Commercial Plugins page. If the issue persists after updating, we asked the client to provide steps to replicate the problem so we could attempt to reproduce it on a test site.

Please note that this solution might not be relevant if it's outdated or not applicable to your specific case. If you're still experiencing issues, we encourage you to open a new support ticket. We also highly recommend checking the related known issues, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If you need further assistance, please contact us through the WPML support forum.

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

Last updated by olegA-5 7 months, 2 weeks ago.

Assisted by: Itamar.

Author Posts
April 4, 2024 at 5:34 pm

olegA-5

I have several pages on my site, each of which is translated into several dozen languages. These translations were finished a few months ago. This is what's happening now. If I open the translation for editing in ATE, no matter if I make edits to it, some of the text in the frontend becomes untranslated again. Yes, only part of the text on the page. However, the edits made will be displayed correctly. The same will happen if I don't make any edits, but open the ATE editor and then refuse to translate (click the "back" arrow). In the ATE-editor everything is still translated. And if I open it again, everything is still shown as translated. However, in the frontend, some of the text will not be translated (it will be the same as the original). I realise that sometimes it takes time for translations or changes to show up in the frontend, but I've waited long enough to make sure it doesn't happen. No changes have been made to the original text in any of the scenarios described. What should I do about this? How do I get back the translated content missing from the frontend?

I know from previous support calls that the important thing is that the pages I'm working with are not top-level pages (usually around the fourth level), moreover they have escaped URLs (i.e. they are very long in Latin), plus the size of the text on the page matters (and maybe the number of translations). These pages have just under 40 of them each.

April 4, 2024 at 6:47 pm
April 7, 2024 at 5:37 pm #15491873

Itamar
Supporter

Languages: English (English ) Hebrew (עברית )

Timezone: Asia/Jerusalem (GMT+02:00)

Hi,

I'll continue to help you with this issue.

I've read the summary of the problem my colleague added about this case. However, when I check the pages provided as an example, I don't see the problem. Everything is in English. Please see the attached screenshots.

I checked these pages.

hidden link

hidden link

Have you corrected this problem already?

Regards,
Itamar.

2024-04-07_20-32-32.jpg
April 7, 2024 at 5:49 pm #15491889

olegA-5

I was able to solve this problem for myself. Not by fixing what caused the problem, but simply by re-translating the parts that I suspected were causing the problem.
I suspect the problem is caused by the following. I see that WPML is now working differently than it did when these translations were made. Specifically, it's that WPML _didn't_ previously save in translation memory those translations that were made "manually", i.e. via a sarch box. Moreover, in my particular case such translations usually did not survive changes to the original (I have a separate ticket about this, which remains open, and everything is described there). Now WPML saves such "manual" translations in the translation memory. I noticed that untranslated content appeared in those "blocks" that had exactly such "manual" translations. It's not just the translations themselves, but also the parts that were next to them (in my case, usually inside a single spoiler). That's why I suspected that the problems were related to these "manual" translations. Accordingly, I firstly updated the original (I'm not sure if it was necessary, but I was going to do it anyway), and secondly, I re-translated the parts that were previously translated via the sarch box. After that everything started to display correctly, i.e. all translated parts were displayed in the frontend as translated. However, firstly, it required additional work (rework), and secondly, I did it only for myself. I don't exclude that someone else may have this problem. And I suspect that the problem is the incompatibility of the new WPML algorithm and those translations made through the sarch box, which were created before the introduction of this new algorithm. I should add that these old "manual" translations of mine still don't "survive" the changes to the original without re-translating them. But once they are re-translated (and thus stored in translation memory), they do "survive" the change in the original. Before the re-translation they are also considered to be in translation memory (because the whole text is considered to be stored in translation memory), but as we can see, this is not quite true in practice. They are really only stored in memory after the re-translation.

April 8, 2024 at 7:47 am #15492829

Itamar
Supporter

Languages: English (English ) Hebrew (עברית )

Timezone: Asia/Jerusalem (GMT+02:00)

Thank you for the detailed explanation of this case.

We have released newer versions of WPML Multilingual CMS (our core plugin) - 4.6.10, Strings Translation - 3.2.10, and Media Translation - 2.7.4. These new versions work better with the version of WordPress - 6.5. If not done, please update the plugins to their latest versions and see if it solves the issue. If you don't see the option to update our plugins, press the 'Check for updates' button on this link: your-doain.com/wp-admin/plugin-install.php?tab=commercial.

Otherwise, if you need further help with this issue, please let me know the steps to take to replicate this problem, and I will try to replicate it on a test site.

Thanks,
Itamar.

April 11, 2024 at 2:20 pm #15509788

olegA-5

Itamar,
I could only upgrade to new versions by switching to the beta channel. Anyway, I can no longer check if these plugin versions work better, as I have re-translated all the problematic (according to my suspicions) parts of the texts again, so I no longer have this problem. To reproduce this problem would require creating the texts with the translations made with the sarch box in older versions of the plugins (and possibly an older version of the whole system on your side), which of course I can't do. Accordingly, my particular problem is solved, but not through fixing the reasons why it occurred. However, if the newer versions of the plugins do work differently, I won't exclude that they may have fixed the problem I was experiencing. In any case, thanks for the support!