Background of the issue:
We ran our site through the translator using DeepL and had a third-party contractor from your network page work through the review process for us. We're looking to launch the fully translated staging site tomorrow, and our client is hoping to be able to make text changes to the site moving forward. They want us to give them a process document to ensure there's a good translation process moving forward. We'd like to have it so that they can go into the Divi builder and make edits in English, then have the DeepL translator automatically run the edited text and save the new Spanish translation as a draft for review. Then we'd like an automated email to go out to a designated translation reviewer to check the Spanish translation for accuracy. Only once they approve the changes, we'd like them to appear on the Spanish site.
Symptoms:
1) Some pages - like the Homepage - were broken when the initial translation was run. Manual edits in both the English and Spanish copies of the page resulted in the Spanish page not being synced to the English page. So no translations appear to be automated for this page.
Link to a page where the issue can be seen: hidden link
2) Some pages have the translated page appearing as the English page rather than the other way around. The Global Locations page on our site, for instance, says it's a translation of the Spanish copy instead of the Spanish copy being a translation of the English page. So any edits we make to the English version is NOT being translated.
Link to a page where the issue can be seen: hidden link
3) The automatic translation is set to 'Wait for Review' but any time we add a new section of text in one of the English pages that are synced correctly, it IMMEDIATELY is published in Spanish on the Spanish copy without waiting for a review.
Link to a page where the issue can be seen: hidden link
Questions:
How can we ensure that manual edits in both English and Spanish copies remain synced for pages that have had to be fixed during translation?
Why are some pages showing the translated page as the English page?
How can we ensure that automatic translations wait for review before being published?
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Hello there!
1) I checked your site today and I couldn't see any page that is broken or even know what you mean by broken (things were missing? things were looking weird?). Is there a way to recreate the problem?
2) It's indeed weird that you see the changes even if you have set the review option.
3) About the wrong translations, that could mean that the original page was in Spanish and you were trying to translate them INTO spanish.
Would it be possible for you to allow me to the site and give me a reference page that still has the issue or that constantly have the issue so I can check it out and try to get all you asked for?
Thanks for your response. This is Michael from Trefoil. Just to clarify up front: while the account is under Vaune’s name (she handles billing), I’m the one managing the translation initiatives. Before I provide access to the site via SFTP, I want to make sure we’re aligned on the issues I raised in the original ticket. I realize now that some parts may not have been clear enough based on your responses.
A few clarifications upfront:
• We only translated the site from English to Spanish. No translations were ever created in the other direction.
• The issues I described occurred on our staging site, which has not been changed since launch.
• We copied the site from staging to production yesterday, but the original staging environment is still intact.
• If helpful, I’m happy to set up a development token to re-enable WPML on the staging site so you can access it freely and safely. That way, any troubleshooting won’t impact the live site, though we may need to reapply your fixes on production later.
Regarding the specific issues:
"1) I checked your site today and I couldn't see any page that is broken or even know what you mean by broken (things were missing? things were looking weird?). Is there a way to recreate the problem?"
In the original translation, certain Divi elements didn’t translate at all. Others caused layout issues, such as:
• Anchor links being improperly translated/broken
• Elements with "hidden" visibility in Divi triggering critical CSS issues
• Required us to disable critical CSS entirely on the homepage
We also manually edited the Spanish homepage using the visual builder to fix layout and content problems, and removed dynamic post content that we didn't want translated.
Since these manual fixes, the Spanish homepage is no longer syncing with the English version. If we update the English version now, those changes do not get sent for translation. We’re hoping you can help us re-establish that sync, so future English edits can once again trigger translations properly.
"2) It's indeed weird that you see the changes even if you have set the review option."
This is the most urgent issue.
We have automatic translation set to “Wait for Review”, but when we make changes to an English page that is still syncing properly, the Spanish version publishes instantly without review. We need the Spanish draft to be held for review before publishing, and we’d like help figuring out why that setting isn’t working as expected.
"3) About the wrong translations, that could mean that the original page was in Spanish and you were trying to translate them INTO spanish."
Some pages – like Global Locations – list the Spanish version as the original, and the English version as the translation. This is incorrect. We never created Spanish pages first, and we never translated from Spanish to English. This mismatch seems to break the intended workflow. We'd like help fixing those relationships so English is always the original and Spanish the translation.
Let me know if access to the staging site is your preferred route, and I’ll get you credentials. Once these issues are addressed, I’d like to align on best practices for the future process — ideally where an English edit triggers a Spanish draft for review, and an email is sent to a designated reviewer for approval before publishing.
Thanks again, and looking forward to your guidance.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
If you have the staging site and the problems are visible there then:
- I'll gladly work there! I just need a place where the problem exists and I kindly ask you to give me the steps to recreate the problem, to see them (A link, a screenshot something that takes me to the place where the problem is).
- If the critical css came from custom CSS, please let me know where they were added and how, if they were DIVI ones, then also let me know so I can understand how to move from there.
- I'll check that Global Location" page and try to find out what happened.
Yes please, allow me access, for now I think only WP access will be needed. If you can also provide SFTP then that's even better because I'll be more independent and we'll probably require less back and forth.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Let's start. You mentioned
"The Spanish copy of the Homepage required a different layout from the English version" this means that you needed to disable the translation editor for that page, not just switch to the translated version of the page.
However when you treat WPML in that way, you're localizing the content, so you have to use the native WordPress Editor, instead.
When that happens, though, there's no "sync" anywhere, it's as if there were independent from each other.
Apart from that the only error i found was with the hummingbird plugin. when it's activated I can't even access the translated page in the back-end: hidden link
But apart from that I couldn't see any other error on the site so can you please guide me on where to see the problem? From what you mention, though, the problems might be related to hummingbird as well, to its configuration on JS, CSS Loading and when to load them, etc. but so far that's a guess since I haven't been able to actually see any of the problems you mention 🙁
First, thank you for showing me the location on the WordPress page editor where I can toggle between the WPML Translation editor and the WordPress Editor. That is probably one of the reasons I had issues with some of the pages. As I mentioned in my most recent message to you, instead of having two versions of the homepage, I was able to resolve the need to hide elements on the Spanish version by using the page ID in the CSS selector. This means the HTML can remain the same, but only the Spanish page's components are targeted by the global styles, which allows me to hide them.
Second, the critical errors are because of the DiviFlash and DiviGear plugins calling functions before they're initialized, paired with the staging server's lack of processing power. The Divi Addon is beginning to cause a lot of stress on the site and I'm considering avoiding or replacing it as a result. On the live site, it doesn't cause the same issues, since the live site's server has vastly more resources, but all the same I do not like seeing critical errors while editing. Often these critical errors can be resolved by refreshing the editor page. They did not require any investigation on your part. If you decide you want to troubleshoot this further, please read through my guidance again for the precise steps I provided. I will reiterate them here: While "generate critical CSS" is enabled in Hummingbird, you need to click the "disable" option on a section above the fold in the Spanish version of a page and then save changes. The resulting element is removed from view, but its styles persist as critical CSS and apply themselves to the next element on the page, (an element labeled "column-2" that was disabled this way would have all the "column-2" critical css apply to the "column-3" object - since disabling the element makes all the indexed objects move up by one degree. Again, this is not anything we need you to troubleshoot as I mentioned we have a workaround to KEEP the same layouts between pages but we use GLOBAL CSS to target the elements on a specific page to hide it. So you do not have to worry about this.
Your explanation of how the translation cannot be synced once we change layouts to one of the pages clarified why the sync/translation connection no longer was applied. Regarding the elements that did not translate or were broken during the original translation attempt, we saw this with the DiviGear modules and the DiviFlash modules I believe. These plugins add several new objects to the Divi builder that have unique characteristics. By attempting to translate the content in them, I believe something broke. Again, we do not need to revisit this. I believe we've gotten past this issue.
Thirdly, no, I want to inform you that I am not committing bad practice to place manual critical CSS at the top of the page above the fold. The commentary on my development practices was unnecessary and inaccurate. While it is possible to rely on optimization tools to generate critical CSS, these tools often ignore massive cumulative layout shifts, resulting in poor overall performance. Manually copying the requisite CSS to a loading point high in the HTML resolves these and allows the page to load much faster and score considerably higher in performance tests. This needs to be done page-by-page with more important pages getting more attention, such as the homepage. While I appreciate your advice, I will not be changing my methodology and I hope you learn something about development from this exercise.
Now. All of this said, there's really only one issue left to resolve and that is the automatic publishing of Spanish translations without going through review whenever an English version of a page is updated. I gave you precise directions to recreate this issue and you haven't addressed it yet. This is the main problem with the plugin. We need a review process in place very soon and the methods provided aren't working.
To recreate this issue, go to an English page set up correctly with a Spanish version. Create a new text element on the page. Type in a few words. Save changes.
Instead of the text going through a translation review, the translated Spanish appears immediately on the Spanish version of the page as published.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
About the best practices, I thought I had removed that from the video because I did some research during that video recording and it's no longer the case, so yes, you're right about that, it was bad practice and in general to avoid performance issues it's better to add them in the footer, but it's not a problem to add them in this page builder anymore (it used to be the case up until the last major version). It's a very page-builder specific case, so I apologize about that.
------------------
About the review situation, I did test it before but I wanted to give it a go this time by first changing it to another setting, running a job while doing so and then changing it back again: hidden link
So far I haven't seen that situation from happening whether I add content, remove it, change it, etc.
I talked to our devs about this and there are situations when the content won't trigger a review, but it's mainly when there isn't anything to translate and the change is seen as "minor", which is almost impossible to recreate on sites with page builders since there's usually a lot of activity with them.
I apologize if there's still any confusion about the issue we're having, because I don't see you in the video testing the issue based on the behavior I'm describing.
This is what I wrote before:
To recreate this issue, go to an English page set up correctly with a Spanish version. Create a new text element on the page. Type in a few words. Save changes.
Instead of the text going through a translation review, the translated Spanish appears immediately on the Spanish version of the page as published.
Since I'm still seeing the same behavior, I'll clarify the steps with more detail here:
1. Go into a page editor - in this case, let's go with "History" since you've been working in that page.
2. Click "Add new module (the gray "+" symbol)
3. In the new module's content editor, add a test sentence and click the green checkbox to confirm changes to the new text element.
4. Click "update" to save the changes to the page.
5. This is where you didn't appear to test the resulting behavior - Navigate to the Spanish translation of the History page (Historia). On this page, the new text element is published and includes the Spanish translation. This is the new text that we added to the site and needs to be reviewed in Spanish before appearing on the Spanish page. Since it's immediately published on this page, it doesn't get reviewed before going live. This is a problem for us if we're making changes across the site, since translations of these new text elements need to be approved by our designated translators.
Is this expected behavior? Is there a way we can add new text elements onto our English pages without immediately pushing the translations on the Spanish versions live? Or is this supposed to be how it works - in which case, we will need to devise a review process that incorporates this behavior.
Please let me know. Attached are screenshots:
1) the settings which say that no changes will be published in Spanish before a translator reviews the text
2) a text box element being added to the page with sample text. Upon saving this change, the expected behavior should be that the Spanish page will not have the translation of this text element appearing until a reviewer approves it.
3) the live version of the Spanish page with the translated text appearing without any approval or review.
One of the other original issues has resurfaced. The client went in before getting any training on the process to edit pages moving forward and ended up de-syncing one of the Spanish pages from its English counterpart. Now, when you go to the Spanish version of the page, you cannot see an option to "edit translation" at the top WordPress bar. You can toggle between the two editors in the WordPress page editor interface, but there's no sign of the translation job in the "translations queue" page from the original translation from English to Spanish. I do not understand how these pages can become unsynced so easily and so permanently. Is there not a way to restore the translation sync? How exactly does it break? Even if I revert the pages to their state prior to the modification today, I cannot seem to restore the connection to the translation tables for these two pages.
If that's not the case, could you please explain what you mean by "desync'd", like do you still see the language appearing there?
If you want you can allow me access to the site and let me know which page has the problem, because things in WPML do not work like you describe. I'd like to know what was it that is not in sync anymore to understand better what happened, why and how it can be fixed or prevented.
I'm not sure why you would say that's not how WPML works this way. It's apparent that the following synchonization steps happen when you translate a page and create a copy in another language:
1. the hreflang tags are populated and link from one to the other
2. the languages can be toggled to display one language or another both in the published page as well as in the WordPress editor.
3. a table of translated verbiage is produced that can be reviewed on the WPML domain and will house all future translations
4. with automatic translation active, new translations on the original page are translated and published on the translated page
5. on the translated page, you can see a "View Translation" option in the WordPress toolbar to take you to the translation table described in number 3 here.
This is the behavior I've experienced whether you agree or not. I know WPML uses "synchronization" in its terminology to describe the connection between an original page and a translated one - it's right in the settings on the WordPress plugin.
In this case, it appears that SOMETHING my clients have done to a page is triggering the synchronization items 3-5 above to no longer work. In other words, the translation table of English to Spanish for the page disappears completely from the translation queue page (#3), any further edits no longer trigger the autotranslation from one page to another (#4), and the option to review translation is no longer available on the translated page (#5). I've attached screenshots of the items I'm no longer seeing when a page becomes unsynchronized (#3 and #5)
What I need to know is exactly what kind of site edit will trigger these pages from no longer being able to continue translating from one to another. Will any revision on a translated page cause it to no longer accept new translations from the original page? What if we need to modify links or fix display issues that appear? Can we modify styles and links on the translated pages safely?
In the case of the careers page, we enabled (to be specific, we used the Divi toggle to enable/disable the row) an announcement element and modified the text in it, which didn't apply changes to the spanish version for instance. The element was still set to disabled in the translated page and the new text we placed into the element did not trigger a translation.
When something like this happens, how are we supposed to update our translated pages? If we need to manually edit them, are we risking disconnecting them from receiving automatic translations forever? Is there no way to restore the translation connections?
At this point, it may be in both of our interests to put a meeting in the books so I can show you what I'm seeing in more detail and you can provide me with immediate insights. Our last step is to provide our client with a process document for them to be able to make safe edits to the page content without worrying about translations not happening. Until I get clarity on this issue, I don't know how I can guide them.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
I believe we're talking about 2 different things here, that's why you think I'm wrong. What I meant when I mentioned that WPML didn't work that way was referring specifically to this text:
I do not understand how these pages can become unsynced so easily and so permanently. Is there not a way to restore the translation sync?
See, if a page is linked to a translation, then it can't be "unsynced" at all, because we do not "sync" anything in the way I think you mean. Logistically we can simplify the process like this:
- There's a page and you translate it
- You get the translation editor or the native WP editor
- If you use the translation editor, then whatever it's in the translation editor then, is what will be pushed to the translated page (there's no "sync" anywhere here, the original page creates an XLIFF file that is read by the translation editor and then uploaded to the site afterward populating the translated page)
- If you use the native WP editor for the translated page, then you work as if it was an independent page, there will be no sync anywhere here either, you need to make all the changes manually.
So the only sync here would be to show the correct content in the translation editor and that when you make a change the page will change status.
---------------------
Would it be possible for you to allow me access to the site where this problem is happening and tell me which pages did you find affected? I'd like to see what could've happened to understand where the problem is coming from.
Thanks for explaining how you're defining "sync" in WPML. We understand now that from your perspective, WPML doesn’t maintain a live synchronization in the strict technical sense — rather, it generates translation jobs based on the content available at the time, and those jobs are passed through the translation editor. Once the translation is completed or the translation editor is disabled, the translated page becomes independent.
That said, from a practical standpoint, there is a persistent connection between the original and translated versions of a page as long as the translation editor is still enabled and functioning — which is why we refer to it as a “sync” in terms of process behavior. When that connection breaks (i.e., the “Edit Translation” link disappears, no new translation jobs are created, and the translation is no longer listed in the WPML queue), it becomes unclear what exactly triggered it and whether it can be restored without rebuilding the page.
This leads to the question we’re really trying to get clarity on:
There have been times when we’ve had to manually edit translated pages using Divi — not to change the translated text, but to fix layout or visual issues caused by the translation process. Examples include adjusting spacing, fixing broken modules, resizing elements for longer translated text, or replacing imagery with language-appropriate versions. These changes are sometimes necessary when the auto-generated translation introduces styling problems.
- In these cases, does making layout or structural adjustments (without editing the actual translated text) still cause WPML to treat the translation as disconnected?
- Is the translation relationship only broken when we edit translated text content directly in the native WordPress or Divi editor?
- And once this happens — where automatic translation no longer triggers from English changes, and the translation table disappears — is there any supported method to restore that relationship without adding a new page translation to the queue? We've burned through a considerable number of translation credits attempting to restore this relationship in testing and we'd like to stop wasting them if you can provide us with a clear answer.
We’re trying to finalize our process documentation and need to know what specific actions are safe, and which will sever the translation workflow. Any detail you can provide on where that line is drawn would help us avoid future issues.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
In these cases, does making layout or structural adjustments (without editing the actual translated text) still cause WPML to treat the translation as disconnected?
Here's the thing, If the editor translates a page and that page is missing something, whether it's a styling issue or missing content, then the best thing is to contact us and let us know. Divi constantly changes their settings and we then come and update our compatibility with them to make sure it works, However there are times where they don't inform us of changes and we might miss something (it rarely happens but has happened in the past), so it's better you let us know or you'll end up in the same way :(.
Now, if instead they come from add-ons to divi, then that just means the author is not compatible with WPML.
In any way, it's not like it causes to "disconnect" but if you made manual text changes, they will not appear in the translation editor and if you then use the translation editor again, then you might removing all the changes you manually did.
Is the translation relationship only broken when we edit translated text content directly in the native WordPress or Divi editor?
Technically, the relationship (which can be seen as the button to edit or update a translation) is never broken, in fact that issue you mention where you don't see the edit translation link? that should never happen if there is indeed a translation, and if you do have one like that at the moment, please point me in the right direction to understand why that's happening.
It's better you let us know about this or that you create a staging site where the problem can be seen (in case you need to fix the problem really fast in the live site) and let us know so we can understand why it happened or at least what happened and then proceed to help you find a solution for it.
