Environment
- WPML: 4.9.4
- WordPress: 6.9.4
- Source language: Dutch (nl)
- Automatic translation engine: DeepL (only; Google and Microsoft are disabled)
- Target languages on the site: DE, EN, FR, NB, ES, IT, PT, SV, DA
What I'm trying to do
I have a glossary entry to prevent the literal translation of "Nederlandse gids" (Dutch guide). For most target languages I want it shortened — e.g. FR:
"guide", IT: "guida", DE: "Guide" — instead of "guide néerlandais" / "guida olandese" etc. The entry is defined with Dutch as the source language and a
target term filled in for each of the 9 target languages.
What works
The glossary is correctly applied when translating from Dutch to: DE, EN, FR, NB.
Example (NL→FR): "Ga met een Nederlandse gids langs de bezienswaardigheden" → "Découvre les sites touristiques en compagnie d'un guide" ✅
What does NOT work
For these target languages the glossary is ignored and DeepL returns a literal translation: ES, IT, PT, SV, DA.
Example (NL→IT): same source sentence → "Visita alle attrazioni con una guida olandese" ❌ (expected: "…con una guida")
Steps already taken to rule out common causes
1. The glossary source language is Dutch (verified).
2. Target terms are filled in for every target language (verified).
3. Phrase matching is not the issue — the same source string works for DE/FR/EN/NB. The Italian translation contains "una guida olandese", so "Nederlandse
gids" is clearly being matched and translated literally rather than substituted.
4. Not a cache issue — the glossary has existed for a long time and DE/FR/EN/NB have been applying it consistently.
5. I fully retranslated the French page in the Advanced Translation Editor (hidden link) and the glossary was applied. I then did the exact same
thing for Italian — cleared the specific segment (Page Subheader) and let DeepL retranslate — and the glossary was still ignored. So this is not a
"translation not refreshed" issue.
6. "Vertalingen bijwerken" / Update translations does not change anything (expected, since it doesn't re-run MT).
7. DeepL is the only active engine, so the request is definitely going through DeepL, not falling back to Google/Microsoft.
My suspicion
The pattern (works for NL→DE/EN/FR/NB, fails for NL→ES/IT/PT/SV/DA) looks like the underlying DeepL glossary resource is only provisioned/supported for some
NL→X pairs on my account, and silently ignored for the rest. Can you check on the DeepL side whether glossaries for source=nl, target=es/it/pt/sv/da are
actually created and active for my account? If they are not supported, is there a recommended way to achieve this without manually editing every page?
Reproduction
- Glossary entry: source NL "Nederlandse gids" → IT "guida" (and analogous entries for ES/PT/SV/DA).
- Source segment: "Ga met een Nederlandse gids langs de bezienswaardigheden"
- Translate to IT via DeepL in ATE → output contains "guida olandese" instead of just "guida".
Thank you for the detailed explanation and the thorough testing.
From what you've described, it doesn't immediately seem like a limitation with the supported language pairs. Instead, I'd first like to rule out whether the translations were originally created before the glossary entry was added.
In that case, the original machine translation may already be stored in memory, so simply updating the translation would not cause the segment to be translated again with the new glossary applied.
Could you please try using the "Update existing translations" option from the Glossary page? This should reprocess the existing translations using the current glossary entries.
Once you've done that, please let me know whether the glossary is then applied correctly for the affected languages (ES, IT, PT, SV, and DA). If not, we'll continue investigating this further.
I think translations were created after the glossary creation.
I tried using the "Update existing translations" option after the automatic translation last week, and it did not work. Now the button is disabled and says "you did not make any changes for translation update".
By the way, do you know why the interface of this page is a mix of English and Dutch? (Dutch is the original language of the content on the website)
New threads created by Dražen and linked to this one are listed below:
1) Could you please send me a few examples of glossary terms that are not applied and a few page URLs in the default language so I can try and check what is wrong.
I'll also need administrator access so I can check the translations directly and try to reproduce the issue with the glossary on your site.
2) Regarding the mixed English and Dutch interface, it should normally appear entirely in your selected user/admin language, which from your screenshot looks to be English. It's possible this is caused by cached files or a temporary UI issue as I have tested and works fine for NL/EN on my test site.
Could you try refreshing the page (Ctrl + F5) and, if applicable, clearing your browser and site cache? If the issue persists, we can investigate it separately later. I'd prefer to keep that as a separate issue so we can focus on one problem at a time.
Thank you for your patience. I checked the issue and found what appears to be the cause.
When editing a glossary, there is an option called *Preserve related Translation Memory entries." When this option is enabled, existing translation memory entries are preserved, meaning updated glossary terms will not overwrite translations that are already stored in the Translation Memory.
The problem is that, at the moment, this option cannot be disabled—it remains checked even if you try to uncheck it. As a result, updating the glossary and retranslating the content does not update the existing Translation Memory entries.
This appears to be a bug on our side, and it has already been escalated to our development team. I'll add your report to the existing case and get back to you as soon as I have an update. Please note that it may take a few days before I receive more information from the developers.
Regarding the second issue with the mixed-language interface, I'll open a new ticket for that, and we can continue the investigation there.
While the dev fix is pending, could you maybe clear the Translation Memory for source NL → targets ES, IT, PT, SV, DA on my account so glossary-affected segments retranslate fresh?
To avoid clearing all of the related Translation Memory, you can instead retranslate only the affected pages.
Please go to WPML → Translation Dashboard, select the affected page(s), and at the bottom choose Translate automatically with the Overwrite translations option.
This will retranslate the selected page from scratch without reusing the existing Translation Memory for that page, while leaving the rest of your Translation Memory intact.
Could you please give that a try and let me know if it resolves the glossary-related translations on your end?
I just re-translated one of the Dutch pages (hidden link) with "Nederlandse gids" in the content to Italian using DeepL. According to the glossary, the "Nederlandse gids" should be just "guida" in Italian, but I see the "guida olandese" instead (hidden link). It looks like this glossary rule was ignored.
Hi, just following up on this one. You mentioned the issue had been escalated to your development team. It's been a little while, so I wanted to check whether there's any update from the developers or a rough idea of when a fix might land.
No urgency on my side today, but it's blocking us from applying glossary corrections to NL→ES, IT, PT, SV, DA without manually editing pages, so any status you can share would be helpful.
Thanks for your work on this.
Yes, the issue has been escalated to our development team. At the moment, I don't have an ETA for a permanent fix.
I also reached out to our team to see if they can provide a workaround so you're not blocked from applying the glossary corrections. Since I asked on Friday and the weekend followed, I haven't received an update yet.
I'll ping them again today to see if there's any news or a temporary solution I can share with you. As soon as I hear back, I'll update you here.
Following up on your last message — you mentioned the team was treating the glossary / Translation Memory issue as high-priority and hoped to have news within a few days. It's been about a week now, so I wanted to check in for any updates.
Is there any progress from the developers, or a rough idea of when the fix might be released? No pressure — just keeping the thread active so it stays on the radar.
I checked with our team, and it looks like the fix has now been deployed to production.
Could you please try again? When editing the glossary, make sure the "Preserve related Translation Memory entries" checkbox is unchecked, then try retranslating/updating the affected content.
Thanks for the update. I retested after the deployment, but unfortunately, the glossary is still being ignored. Here's exactly what I did:
Test page (source, NL): hidden link
1. "Update translations" (the outcome we actually need)
I made a minor edit to the "Nederlandse gids" glossary entry with "Preserve related Translation Memory entries" unchecked, which enabled the "Update translations" button, then ran the update. Result: no change to the existing translations.
2. Manual retranslation via "Edit translation" (ATE)
German: hidden link
Italian: hidden link
For each, I found the field containing "Nederlandse gids", cleared its translation, and clicked automatic translation.
Interesting detail: the ATE editor showed the correct glossary term as the "suggested translation" — "guide" (DE) and "guida" (IT) — but the value it actually filled in ignored the glossary: "niederländischen Guide" (DE) and "guida olandese" (IT). So the glossary appears to be loaded in the editor UI, but it is not being applied to the actual machine-translation output. See the screenshots.
3. Full automatic re-translation — same result, glossary still ignored.
So both the TM/"Update translations" path and fresh retranslation are still bypassing the glossary after the fix.
Two things I'd like to flag:
The fact that ATE displays the glossary suggestion ("guide"/"guida") but doesn't apply it suggests the term is reaching the editor but not the DeepL request — could you pass this specific observation to the developers? It may point to where the fix is incomplete.
Most importantly, our real requirement is for "Update translations" to apply the glossary to already-translated content in bulk. We have on the order of thousands of pages already translated, so per-page manual retranslation in ATE is not a viable option for us, even if it worked. We need the glossary change to propagate without manually reopening each page.
Happy to provide the screenshots, a debug/system report, or temporary access if that helps the developers reproduce it.
