Background of the issue:
I’m following up on a previously reported bug (no reply received yet): hidden link
Summary of the issue:
The issue concerns automatic glossary entries in wrong language overriding my translation workflow across many languages.
My workaround:
To prevent this, I duplicate the site without connecting it to the original production ATE, keeping the glossary empty. Only later do I connect the development site to ATE, allowing me to control glossary behavior.
Current problem:
Now, when creating a new staging site:
1. I deliberately do not connect to the production ATE.
2. I add new payment information.
3. After adding new languages, I try testing ATE translations — but receive errors:
• “Service Unavailable”
• “API error: Missing resource – No site key found for this website”
4. I generate a new site key at WPML.org and assign it to the staging environment.
5. Unexpected behavior: ATE still connects to the production glossary and starts importing terms — thus reproducing the original bug.
My questions:
• Has anything changed in WPML’s system or ATE behavior since my original bug report?
• Is there a way to prevent glossary terms from being auto-imported when using a new site key?
• Can you confirm whether glossary linkage is based solely on the site key or if another ID is used?
Thank you in advance for your clarification
Symptoms:
When creating a new staging site, I deliberately do not connect to the production ATE and add new payment information. After adding new languages, I try testing ATE translations but receive errors: 'Service Unavailable' and 'API error: Missing resource – No site key found for this website'. I generate a new site key at WPML.org and assign it to the staging environment. Unexpectedly, ATE still connects to the production glossary and starts importing terms, reproducing the original bug.
Questions:
Has anything changed in WPML’s system or ATE behavior since my original bug report?
Is there a way to prevent glossary terms from being auto-imported when using a new site key?
Can you confirm whether glossary linkage is based solely on the site key or if another ID is used?
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Hello,
That last "ticket" was actually a chat and was closed so you can't nor will get a reply there at all. Glossaries, like translation memory should be passed over to the duplicated sites, what's not supposed to be active is the Pay-As-You-Go subscription.
However by checking your ticket history, I can see you had a few issues with this feature:
- Some disappear when they shouldn't (We found out why this is happening and are fixing it)
- Some should've been deleted but they reappear (this one is linked to the issue mentioned above).
- Glossary entries are not updating or being overwritten during import.
-----------------
I'd like to have more insights about the "WHY" of these procedures. I see you have many issues with glossaries and I'd like to tackle the core situation here which is why you're avoiding them or what is it that is not working ok.
We are making changes to the glossaries because each translation engine ultimately "decides" whether to keep the glossary or not and we're trying to find a way around this restriction to make things work smoother but I wonder if the main reason why you don't want to have the entries sometimes but then you do when you connect the site is somehow connected to this restriction?
Please let me know because I truly want to have your perspective on this so I can make sure we make things work correctly for you.
Thank you for your reply. I will try to answer your question to the WHY. Bear with me:
One major problem with the glossary aside the issues you describe is that when I create a new language on the site. The glossary will instantly create entries for this language with the 'original language' (not a translated version). Because of this I can't use ATE for my content because the translation will be faulty (have English words in the translation).
Fixes like emptying the glossary by hand after creating the new language proved to be very tricky and sometimes still resulted in the same bug reappearing.
So after the last chat I came up with the work around to first create a duplicate from the website and not connecting WPML to the production website. That way I did not have a glossary at all and I could make an initial translation.
Here is the WHY(s):
1) My glossary is too big, the interface too complex with languages and the tool is to far hidden into WPML for my content managers to use the glossary efficiently.
2) My content managers are only correcting the ATE. Our glossary is large because these words are basically untranslatable. Even in English they do not make sense. It's basically 'slang' for occupational names or official sector names.
3) I need to facility their process making it as easy as possible.
My solution was:
1. Translate the website with ATE (partially) on a copy of the website not connected to the glossary. That way we had some foundation to start on.
2. I created this tool hidden link So I could export the words used in the glossary for the content manager. The would update their glossary entries for their languages.
3. CONNECT the site to the glossary (marking it as a development site of production). And then updating the glossary and fully translate the site for that language including a retranslation of the part from step 1.
My problem now:
I can't disconnect the copy from production anymore. I did not connected and give it my credit card details again. After a while the glossary reappears. Even when I give it a new website key it is still there.
This would be beautiful, a desired outcome and upgrade IF the previous bug was not still active. But now this upgrade killed my solution for the fix.
If I am able to disconnect the glossary for the first translations and reconnected it later my problem is fixed for now.
----
Side note:
In general I found it somewhat irritating that the glossary is the only thing that is not stored on my website. That means I don't have any control over it. At least if it were stored there I could bulk edit the glossary, create backups or influence it.
Now I am solely dependent on support. Making my work slower, costly (multiple translations of the same content + hours) and inefficient. I think this glossary should be stored on the client side. I would give me a better feeling.
Sorry something came to mind that I think needs to be explained too, because it is a WHY...
If the glossary was working as expected I would have had the content managers use the glossary (previous remarks still standing). But I am using this method with the large glossary of "using a tool to get all the desired translations" and then "updating and uploading it again to the glossary" because:
We previously found out that a large glossary with empty cells for some languages would result in the same behavior that these cell will be filled with the original languages (English). Therefore endangering further translations.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
I see,
Could you please watch this video: hidden link
I know i have only a few terms, but I tried recommending you a different course of action because what you're doing is definitely not sustainable at all.
I will still talk to our devs to see how we can use your feedback to improve the workflows and UI but I wonder if what I'm suggesting is totally not doable on your end and why (That would also help me with our devs).
I’m currently applying about 98% of the workflow you described, including CSV filtering. I rely almost entirely on the ATE for translations (around 98%), with only 2% manual corrections. The glossary solves many translation issues — when it works as intended.
That said, I’ve adopted the export/import approach out of necessity, not preference. Here’s where I encounter problems:
⸻
1. Glossary overwrites with source terms
When using a large glossary with empty cells, WPML sometimes fills those cells with the source term (English). This definitely happens when using the “Update existing translations” button, especially with glossaries containing ~150+ entries.
This behavior forces me to pre-fill all cells, even if I’d prefer to let ATE apply its default translation. I would expect WPML to treat empty cells as an instruction to fall back to ATE — just like it does for untranslated content.
⸻
2. Expected behavior of empty cells
You mentioned that a translation is always required, but I respectfully disagree. Ideally, an empty cell in the glossary should allow WPML to apply the default ATE suggestion.
This did seem to work with smaller glossaries in the past, so I’m unsure if this behavior is by design or an unintended consequence of glossary size.
⸻
3. Empty cells do not overwrite existing entries
When importing a CSV, empty cells do not clear previously stored glossary values — even when “overwrite existing translations” is selected.
This means I cannot remove or fix incorrect entries by leaving them blank in the CSV. Instead, I’m required to pre-translate every single term in all languages before using ATE.
With 150 entries and 33 languages, that feels inefficient — isn’t that what WPML and ATE are supposed to simplify?
⸻
4. Adding new languages doesn’t create empty cells
Contrary to what’s shown in the tutorial video, adding a new language does not leave glossary cells empty. WPML adds the new language to the glossary and automatically fills it with the source term (English), not the ATE translation.
⸻
Why I built a workaround
To properly build a glossary, I need to see ATE’s translations first. That’s why I developed a tool that allows me to:
1. Translate content using ATE without a glossary
2. Extract the actual ATE-generated translations
3. Review, correct, and compile these into a reliable glossary
4. Re-upload the glossary manually
⸻
In short, I see two possible paths forward:
Option 1 – Clean clone workflow
Use a clean copy of my site, disconnected from ATE memory and glossary, to build the glossary as described above. But this only works if I can fully isolate the site from the ATE cloud memory.
This is the core of the bug I’m reporting — I need help preventing reconnection to the original site’s ATE key and glossary. I’ve now added all required languages to avoid this in the future.
Option 2 – External translation workflow
Translate the glossary completely outside WPML — even if ATE would have handled 75% of the entries correctly — simply to avoid conflicts caused by WPML’s overwrite behavior between languages.
⸻
Please let me know if any of this aligns with your understanding, or if there’s a workaround I might have missed.
For now maybe the simplest approach might be if you could 'empty' the glossary for me? So I can complete my remaining translations and I can upload a fresh glossary through my tool?
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Gotcha, I understand everything way better now and I deeply thank you for taking the time to explain it to me. I'll take it to our devs to see if something actionable can come from this.
I'm almost certain that an empty language cell will not be possible (if there's a glossary entry, then it will always be detected as such, no matter the language so what you say could be probably a resource hog or proned to errors, technically) but hey, there might be something that can be done to solve these issues!
---------------
I have already asked our devs to empty the glossary so you should be good to go in this regard, soon 🙂
Thank you. I will wait for the empty glossary and create the last languages. Pleas check if it is connected to my primal site hidden link
I hope this will be achieved today.
Please let me know your progress. I am happy to be used as a testing case. Although these work arounds and test problems are starting costing me a lot of money.
Thank you but there is something not right. Under the translation tools on both sites I keep getting this waiting/idle state and the following error in the log (see images).
If I try to translate I get: Connection Error. Please wait a minute and reload this page. If the problem continues, please contact WPML support.
In a previous situation we deleted the glossary before successfully. But this error is new.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Hello,
Those errors are actually coming from your server, did you make any change to your database by any chance? can you check that the user assigned to your site (the database user) has all the privileges?
