Home›Support›English Support›[Waiting for user feedback] Translation editor loses translated strings after editing original page – Greenshift Accordion blo...
[Waiting for user feedback] Translation editor loses translated strings after editing original page – Greenshift Accordion blo...
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.
When I edit the original (German) page – even minor changes like updating a single link – and then open the translation editor for the English version, a large portion of the previously translated strings are missing (sometimes 50% or more). This is not reproducible 100% of the time – it happens sporadically. Sometimes edits work fine and translations remain intact. Other times, after opening the translation editor, translated strings are simply gone and must be re-entered manually.
Expected behavior:
WPML should retain existing translations for unchanged strings and only mark changed strings as needing update.
Actual behavior:
WPML re-parses the block structure after an edit and drops previously saved translations for strings that were not changed.
Impact:
This is causing significant data loss in our translation workflow. Re-entering translations repeatedly for a large FAQ page is not a viable process. The behavior makes WPML translation of Gutenberg/Greenshift block pages unreliable.
Steps to reproduce:
Translate a page with Greenshift Accordion blocks via WPML translation editor
Save translations
Edit the original page (e.g. update one link in one Accordion item)
Open translation editor again
Observe that multiple previously translated strings are now empty
If possible, please confirm with me if the pages that experience this issue were previously translated using the Classic Translation Editor or the Automatic Translation with ATE editor?
The classic translation editor is the original side to side editor that does not feature the automatic translation.
When previously using that editor and then switching to the new ATE editor this issue can happen due to the non communication between the two editors.
To answer your question: the FAQ page was translated exclusively in the Advanced Translation Editor. The Classic Editor was never used for this page.
The issue persists. I just edited the FAQ page - only the title and meta description - and immediately after, 2-3 previously translated strings were gone from the Advanced Translation Editor. No block structure changes, no content changes, just meta fields.
This confirms that the issue is not related to switching between editors. It is a bug in the Advanced Translation Editor itself, which drops existing translations after minor edits to the original page.
I would like to request temporary access (wp-admin and FTP) to your site to test the issue.
(preferably to a test site where the problem has been replicated if possible)
**Before we proceed It is necessary to take FULL BACKUP of your database and your website. Providing us with access, you agree that a backup has been taken **
I often use the Duplicator plugin for this purpose: http://wordpress.org/plugins/duplicator/
You will find the needed fields for this below the comment area when you log in to leave your next reply.
The information you enter is private which means only you and I have access to it.
NOTE: If access to the live site is not possible and the staging site does not exist please provide me with a duplicator package created with the duplicator plugin.
Providing access to the live site is not possible – we are launching in 2 days and there is no separate staging environment available at this point.
Regarding reproducibility: the issue does not occur on every single edit, but it happens frequently and unpredictably. For example, changing a link in one block can cause unrelated strings in completely different blocks to lose their translations – with no apparent pattern. This is exactly what makes it so disruptive in a real translation workflow.
The steps to reproduce are documented in my original report. I would expect WPML to be able to replicate this internally on a Greenshift block page with ATE, without requiring access to a customer site.
We are launching in 2 days. I need either a fix or a concrete workaround. Please escalate to your development team.
I have deployed a sandbox where the issue was tested, following the steps below.
Steps to reproduce:
1. Translate a page with Greenshift Accordion blocks via WPML translation editor
2. Save translations
3. Edit the original page (e.g. update one link in one Accordion item)
4. Open translation editor again
5. Observe that multiple previously translated strings are now empty
--------------------------
Using the Accordion blocks all links are registered in the ATE.
Editing for example an accordion content line from "Hello" to "Hello." and saving next time when I open the ATE editor, that line will be "empty" and asking for a retranslation.
This is happening because in the eyes of the editor these are 2 different strings and is expected.
However, what is not expected is
Changing "Hello" to "Hello.", now also removes 5 other unrelated translations.
This behavior -- I was not able to reproduce.
Also, minor changes will not cost you extra credits either due to the translation memory. (Of course if the string changes from Hello to Hello today this will cost credits as it's a new string all together)
Loom Screen recording: hidden link
Also, you can access the sandbox using this link in case I have missed a step to reproduce this behavior: hidden link
NOTE:: I'd recommend going to the ATE editor -> click on the right upper corner the gear icon and turn off "I prefer bigger segments
Edit paragraphs as single items instead of multiple sentences. This will apply to all translators and future jobs only. It will not apply to your current or past jobs."
Thanks for the sandbox. Did you test this on a page with a high number of segments (30+)? My feeling is that the issue is related to page complexity rather than segment size. Smaller pages seem stable.
Breaking content into smaller sections could be a workaround, but it makes the translation workflow significantly harder.
I will test the bigger segments setting and report back.
I will test with more segments and report back as well.
If possible, yes please test that feature and let me know your results as we did have some known issues with this feature which is why I am recommending this as a workaround.
I am still facing the same issue - existing translations are being dropped again, and segments are marked as "Flagged for later" even though they were already translated.
See the attached screenshot: multiple blocks are missing their English translations despite having been completed before. I am now forced to re-run automatic translation just to restore them, with no time to review the output.
This is the same recurring bug I reported earlier. My ticket is still open and this issue has not been resolved.
Please escalate this. The problem is causing significant ongoing damage - I am losing time and translation quality on every editing cycle. This is really exhausting and unsustainable.
Just another example of another page. This is so frustrating.
To give you a clearer picture of the full extent of the problem:
- Approximately 1/3 of all my pages now show the English translation as "outdated"
- Some pages only need to be opened in the Translation Editor and saved again – no actual changes needed
- Other pages are full of yellow markers with 50% of translations missing
- Some previously translated content is suddenly stored in the original language instead of English
This is a catastrophic situation. I cannot maintain a bilingual website under these conditions. I need this escalated to your development team immediately.
One more example - as things become even worse. I just edited an original post. What I did:
- Remove "Youtube" embeded video
- Use "Lightbox video" instead
The english version is outdated. That's okay. But, when you look at the screenshot, more than 50% (!) of the already translated post is lost again.
Luckily I have still enough credits for doing all the translation again. But, this is not reliable.
Following up on our last communication, were you able to turn off "I prefer bigger segments ?
We left off with waiting for you to test this as I was not able to reproduce the issue in a sandbox environment.
Unfortunately as I cannot reproduce this behavior we cannot reliably debug this.
Would it be possible to create a staging environment for us? Note that we also have a staging server on Cloudways, if you wish I can provide you with the credentials needed to add to a migration plugin so we can safely migrate a copy for our team to test as part of escalating this issue.
Thank you, that would greatly helps us in understand what is happening and being able to properly escalate the issue to our second tier for further investigation.
