I am experiencing an issue where updates made to an existing Glossary in WPML > Translation Management > Tools are not propagating to content that has already been translated.
Steps taken:
I have a live site with several pages already translated from German to English using DeepL.
I updated the translation of a specific term in the WPML Glossary (e.g., changed "Old Translation" to "New Translation").
I used the "Update existing translations" button within the Glossary tool.
Despite this, the front-end English pages still show the "Old Translation."
I created a dummy test page to verify. Even after updating the glossary and clicking the update button, the ATE still shows the old translation in the memory unless I manually edit the source German text to force a refresh.
Troubleshooting steps already attempted:
Our development team has already performed the following actions in WPML > Support > Troubleshooting, but the glossary terms still do not update in the existing translations:
Clear the cache in WPML: Executed to ensure no stale configuration data is interfering.
Remove ghost entries from the translation tables: Completed to clean up any orphaned database records.
Synchronize local job identifiers with the Advanced Translation Editor (ATE): Performed to force a sync between our local database and the WPML cloud editor.
Despite these steps, the Advanced Translation Editor (ATE) continues to prioritize the previous Translation Memory over the newly updated Glossary entries.
Expected Result:
Existing translations containing glossary terms should be updated (or flagged for update) globally without requiring manual "dummy edits" to the source content of every page.
Request:
Can you provide the correct workflow to force the Advanced Translation Editor to prioritize the updated Glossary terms over the existing Translation Memory without manually re-opening every job or consuming full translation credits for content that is 99% identical?
Before we take a deeper look at this issue, I kindly ask you to update any outdated plugins or themes, especially the WPML plugins in Plugins -> Add new -> Commercial tab and double-check if the issue with the Glossary persists afterwards.
Note: Please don't forget to create a full site backup before updating the plugins.
I have checked the website and can confirm that WordPress, WPML, and all other plugins are already updated to their latest versions. I have also verified that the issue with the Glossary still persists after confirming everything is up to date.
Please let me know what information you need from my side so we can investigate this further.
1.- Please provide a glossary term we can use as a reference and share a URL where the glossary hasn't taken effect.
2.- I kindly ask you to share the access credentials to the site in your next message, which I have set private. This will allow me to reproduce the issue in the URL shared in the previous point and double-check the WPML configuration.
Confirm you have created a full site backup that you can restore if necessary.
Hi,
Thank you very much for sharing the information requested
I was able to reproduce the issue in a sandbox site, and I have decided to escalate this ticket to our 2nd-tier of support, where our specialists will take a deeper look at it and will isolate its cause.
I will keep you updated on the evolution of this ticket.
Thank you very much for your patience and understanding!
The behavior you are seeing is expected because you kept active the "Preserve related Translation Memory entries" option mentioned in this video: hidden link
Thank you for the update and for sharing the video explaining that behavior.
I understand how the "Preserve related Translation Memory entries" option works when manually editing a single term directly in the glossary UI. However, that is not the workflow we are using.
Because we manage a large number of terms, our client provides the updated glossary in a CSV file, which we upload in bulk.
When we perform the CSV import, we explicitly uncheck the "Preserve related Translation Memory entries" option. Despite ensuring this is unchecked during the import, the updated translations from the CSV still do not reflect on the existing translated pages. It appears the Translation Memory is being preserved regardless of the checkbox state when updating via CSV upload.
Could the 2nd-tier team please try reproducing the issue using the CSV import method with the checkbox unchecked, rather than manually editing a term in the UI?
Manually editing is also not working consistently. Please check the first video for the manual editing process. You can see the exact steps I followed.
After completing the translation, I waited around 15–20 minutes and checked again, but the page is still showing the old translation instead of the updated one.
Video URL: hidden link
Could you please review the video and let us know what might be causing this issue?
I am trying to update existing glossary translations. To do this, I first exported the glossary CSV file, modified the translation text, then imported the updated CSV and ran the "Update Translations" action.
After waiting 15–20 minutes, I tested again, but the site is still displaying the old translation instead of the updated glossary translation.
CSV test page: hidden link
Video: hidden link
Could you please review the video and let us know if we are missing any steps or if there is an issue with the glossary update process?
Thank you for following up and testing this on your end.
We continued our testing and made a critical observation regarding when the translations actually apply to the live pages. After uploading the updated CSV, we monitored the front-end test pages and waited for over 9 hours, but the old translations remained.
However, the exact moment we logged into the WordPress backend and visited the WPML > Translation Dashboard (hidden link), the pending translations instantly processed and updated on the front end.
This indicates that the glossary updates from the CSV are not executing automatically in the background. Instead, they appear to be stuck in a queue that specifically requires a manual page load of the Translation Dashboard to trigger.
Could the 2nd-tier team please take this observation into account during their investigation? We need a solution or workflow that allows these bulk CSV updates to process automatically, immediately, and reliably in the background, without requiring our team to manually visit the WPML dashboard to force the queue.
I followed the same steps on a sandbox site, and the glossary was applied correctly.
Please activate the WordPress debug mode as described in this guide: https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/ then reproduce the behavior you described in your previous message and check if there is any fatal error in the debug.log file located within the wp-content folder.
