Skip to content Skip to sidebar

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.

Sun Mon Tue Wed Thu Fri Sat
- 8:00 – 15:00 8:00 – 15:00 8:00 – 15:00 8:00 – 15:00 8:00 – 15:00 -
- 16:00 – 17:00 16:00 – 17:00 16:00 – 17:00 16:00 – 17:00 16:00 – 17:00 -

Supporter timezone: Europe/Rome (GMT+02:00)

Tagged: 

This topic contains 14 replies, has 0 voices.

Last updated by Alejandro 4 days, 20 hours ago.

Assisted by: Alejandro.

Author Posts
July 7, 2025 at 2:31 pm #17209297

Jasper

Then think we are not talking about the same issue. Let me try again:

- I have a CSV file with updated glossary terms
- When import this CSV file into the glossary I select "overwrite existing glossary terms"

After the import of the glossary terms the updated terms from my CVS are not processed/updated in my glossary.

So this has nothing to do with the front-end

-----

For the other issue. I did select copy. But it resulted in the loop so first it does recognize it is coming from production. But then it also recognizes it also had a link to staging.

From that point on it wants to create a copy from the same site as the staging.

July 7, 2025 at 2:33 pm #17209306

Christopher Amirian
WPML Supporter since 07/2020

Languages: English (English )

Timezone: Asia/Yerevan (GMT+04:00)

Hi,

This ticket is for the message that you get when you want to copy the website from staging to live website.

I do have access to the live website now that does not have the message.

Would you please set the next reply as private and provide me with the staging version login so I can see the message that you get?

Thanks.

July 9, 2025 at 11:05 am #17218739

Jasper

Oké so I am getting a bit lost and frustrated now.

At some point my staging DID get disconnected from my glossary. This enabled me to do some translations.

After this I imported my glossary with 150+ entries

I started correcting/retranslation of pages, because this is my expensive work-around.

After the initial 100+ pages the systems gives the message "Out of Credits for Automatic Translation". But when I click on the "fix now" button the window only appears for a split second, before automatically closing.

So now I only have a partial (UNKNOWN) portion translated. And can't get out of this loop.

MORE importantly I notice that my glossary is now reduced to 50 items. So now I have no idea what has been rightfully translated or not.

By now I am starting to get a very reddish face. I thinks I spend twice the amount of money and hour on this then expected.

July 11, 2025 at 9:16 am #17226879

Alejandro
WPML Supporter since 02/2018

Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Rome (GMT+02:00)

Hello there

1) You mentioned the following

From that point on it wants to create a copy from the same site as the staging.

This will be fixed in WPML 4.8 alongside many other improvements for the migration workflow but in the meantime you can do what's mentioned here: https://wpml.org/documentation/translating-your-contents/advanced-translation-editor/using-advanced-translation-editor-when-you-move-or-use-a-copy-of-your-site/

--------------

2) Can you please go to WPML > Support > Troubleshooting and copy the Automatic Translation ID you see on the site where the "fix problem" button appears? you have indeed many instances on our end and I'm sure the new workflow from WPML 4.8 will actually help you trim things down in this purpose but in the meantime I want to unblock you. Usually that problem you're describing happens when the system managed to go over the 195000 credits and for some reason didn't present you with the popup before. That's a bug that was long fixed but we have to check if there's a regression or something similar.

3) You mention

my glossary is now reduced to 50 items.

Do you mean when you export it, it doesn't export all of them but only 50 or that you Only see 50 in the interface? (this should also be fixed in WPML 4.8, by the way)

This info will allow me to see your actual glossary and then try to understand what else is going on.

July 11, 2025 at 9:43 am #17226971

Jasper

Hi Alejandro,

1: Thanks I will read this.
2: 1e836b67-7b3e-464e-8e2c-c9fcb8ebb809#EjRl5ThUB2ffknZHklkCxQtt
3: No that was not what I meant. But for the sake of clarity let's leave this. I think it is connected with the fact that the ATE could not find a ID attached to the system. I now reconnected the staging to the same account of the production site. So I only need the ATE payment system to work again. But only if the glossary is correct.

The end-goal is that I 'dare' to switch the switch to automatic. I hope we will get there soon.

Thanks for your help!

July 11, 2025 at 7:06 pm #17229230

Alejandro
WPML Supporter since 02/2018

Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Rome (GMT+02:00)

I'm checking your account and I'll also check the glossary thing, don't worry? All I asked is because we have a few recent known issue with glossaries so I want to see if that's your case.

I'm going to investigate further and check your other tickets as well. I'll answer them as soon as I have more info.

July 12, 2025 at 10:11 am #17230011

Jasper

Thank you. I hope that if we can not find an answer soon you could upload a glossary for me? I need to update this before you do this. But in this case I can at least prepare a few languages for the next phase to launch them.

Thanks for your help, appreciated.

July 14, 2025 at 9:40 am #17232822

Alejandro
WPML Supporter since 02/2018

Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Rome (GMT+02:00)

I can, of course, do you have one? I can do that for you, no problem.

July 14, 2025 at 2:48 pm #17234474

Jasper

Hi Alejandro,

Enclosed a spreadsheet that can replace the current glossary. Although it does not contain every translation for every language at this point, it should be sufficient to continue my work while you are looking into the issue.

hidden link

If you would like to use the CVS let me know.

Thanks again for your assistance in this matter.

July 14, 2025 at 5:37 pm #17235173

Alejandro
WPML Supporter since 02/2018

Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Rome (GMT+02:00)

Please watch this: hidden link

1) The problem is happening due to the amount of entries you have, but mainly because a lot of them are not supposed to be glossary entries but translation memory (so you should translate it at most once, save them and that's it).

2) When importing the glossaries, there seems to be some that are not importing. I'm not sure if it's because the system is truncating or skipping the entries for some reason (I'm asking our devs about this.

3) The file you shared in dropbox is wrong, it doesn't contain the column "kind" with the value "name" so that's probably why some of the entries never even got updated or added.

July 14, 2025 at 6:53 pm #17235356

Jasper

1. “Kind” Column

Let’s start with the “kind” column.
I used to include this column in every row with the value name, but I removed it from the last CSV because the sample file available under “Import Glossary” no longer includes it.

So my question is: are you sure it’s still required?

Here’s what the current sample file shows:

original_language_code,target_language_code,original_term,translated_term,description
en,it,Page,Pagina,the page of a browser
en,it,page,pagina,the page of a browser
en,it,OnTheGoSystems,OnTheGoSystems,the name of my company

If that’s incorrect, I’m happy to re-add the column.

2. Glossary vs. Translation Memory

There are a few reasons I ended up with this workaround — I hope my explanation can contribute to development:

a) The main issue is that I often need to translate terms more than once, which shouldn’t be necessary if the system behaved as expected. But I also think this should be possible. Because that’s what the “Update existing translations” button is for, right?

b) My source terms are sometimes unconventional — almost like slang. I don’t need to translate them in every language, but most of them need corrections in at least one or two.

Since the system falls back to the original term when a translation is missing, I’m forced to add entries for every language, even if most should default to English.

Ideally, the system should allow for blank cells that trigger auto-translation.

Weirdly: This seems to work now? But I’m almost certain the issue reappears if I use the “Update existing translations” button. That button already caused me to retranslate multiple pages several times.

c) Because of switching between staging and production environments, deleting glossaries, and inconsistent WPML behavior, I can’t rely on the translation memory.

I honestly don’t know what’s in it, if it’s up to date, or if it contains faulty data.
That’s why I prefer using the glossary — it gives me more control.

Ultimately: If either (or preferably both) the glossary or memory would work consistently, I’d happily use the “Translate everything automatically” feature and drink more coffees.

3. Current Workaround

We’ll first need clarity on the “kind” column, but for now I’m happy to delete the current glossary and replace it with the cleaned-up Google Sheet I sent you. This would also delete the 'hidden general terms' you mentioned.

This version isn’t perfect either, but I removed entries that might cause issues. Some translations are still missing though because we’re waiting on input for certain languages.

My philosophy is that the system will fall back to English for now, and I’ll replace them before we publish the full translation (if the bug is resolved by then).

That said: my understanding is that uploading a clean CSV won’t apply changes at this point — but that this will be fixed in the next release? So when we upload this glossary - I am kind of stuck with it exempt manual edits?

4. Suggested Feature

I’d also like to suggest adding a “Delete Glossary” function for users.
This would give them more control — especially since the glossary isn’t stored locally and currently requires support intervention.

Did I understand your reply correctly, and does the above explanation make sense from your end?

If preferred, I’d be happy to go over this together via Zoom, Teams, or another platform If we do this together — it might help us catch issues quickly and streamline the process.

Best regards,

July 15, 2025 at 7:12 am #17236288

Alejandro
WPML Supporter since 02/2018

Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Rome (GMT+02:00)

1) I'm sure the kind column is required. it's true that the file example removed it. the thing is that the kind column will be removed and it had to be removed already but it wasn't, it was pushed to WPML 4.8. that's why it doesn't appear anymore.

2) About the empty entries, The dev team will not allow this because: A glossary MUST always have a value. having empty values would either make the client think that the glossary will be skipped entirely but the logic to just say "if it's empty, translate it normally) is expensive and will end up confusing users and making the system work slower.

- If you have a segment with just the content you add in the glossary, it will do what you need: save it in the translation memory and will appear translated in the future segments with the content on it. Could it be those "slangs" are part of a segment but not the entire segment? because that's the only way I can think of to solve the problem as you're doing right now.

- About the retranslate feature. If you're using DeepL, it's likely you won't see anything changing because DeepL flat out ignores our request for glossary (it's the main reason why we deprecated the "general" term which was solely for DeepL, and they used it as a "suggestion" instead of a Glossary, so they translated it anyways when they saw fit). That's our current challenge and part of the solution is being tested at the moment. Just to make it clear, this restriction comes from DeepL, not us. so at the moment it's not working as it should.

- Why is the translation memory inconsistent? If you connect staging and production, you'll keep a reliable translation memory that will always be applied everywhere. If you instead have them disconnected, then yes it will be unreliable because you'll have 2 separate sites working separately, but that's far from Ideal in this scenario. is there a specific reason for you to keep those sites separated from this standpoint?

3) Refer to point 1: the Kind Column is needed for now. I'm asking our devs about the import and export of entries because what you're experiencing is NOT normal, In fact If I try it on a sandbox site, it works, so I wanted to see what is it that is preventing the entries from being fully imported.

4) I guess you mean a delete glossary in bulk feature, correct? if so, we're working in it, because you can currently delete them one by one.

If you mean via the CSV, then that won't be possible, it could create too many issues (our devs already looked into that one).

July 15, 2025 at 9:07 am #17236902

Jasper

Thanks again — and sorry for yet another long reply. I write these mini-theses not just for you, but also to structure my own thinking. It helps me anticipate future issues and understand the system better. It’s just how my brain works.

Reaction on point 1.

Understood. I’ll re-add the kind column with the value name.

But then the question comes to mind that you mention the glossary with terms set to 'general' are hidden? Will these terms be overwritten when 'kind' is changed to 'name'?

I assume it doesn’t affect my case directly if we replace the glossary. But if we don't I’m curious how the system handles this.

Reaction on Point 2 – Normal Workflow

A glossary MUST always have a value”
Unfortunate, but I understand the rationale — especially when relying on the translation memory rather than the glossary.

That brings me to a general workflow question:

That brings me to a general workflow question:

Let’s say I add Italian via “Translate Everything Automatically,” and I have a large glossary like mine:
1. The new language is added →
the glossary for that language auto-fills with fallback values (i.e., the original term).
2. Translation happens automatically →
the fallback terms are now used in the translations (sometimes incorrectly).
3. I now have a very limited time to either:
• manually correct these terms, or
• import a corrected glossary
…before confirming and publishing the language.

→ Is this understanding correct?

If so, the real issue seems to be the time pressure to catch these fallback terms before they go live.

Reaction on Point 2 – Current Workflow

This puts my current workaround in a tricky spot. What I’m trying to do now is:
• Upload a glossary with gaps → the system fills the missing translations with the original_term (English).
• Download the glossary again → I can now identify these gaps by simply comparing original and translated terms.
• Correct and re-upload the glossary (assuming the update bug is resolved).

Currently, I can only do this for some languages.
I activated all languages early to avoid the bug that auto-fills partial translations.
To get here, I disconnected the site from ATE and used my custom tool to generate the glossary.

The idea was to pre-fill the glossary with the auto-translated terms before sending it to real translators.
This would help them work faster — they don’t have to start from English, they can validate or adjust a local-language suggestion.

Reaction on Point 2 – Conclusion

This workaround helps with efficiency, but the glossary limitation (i.e. “every field must have a value”) makes the default workflow slower and less precise.

I’m trying to highlight how this affects real-world usage.

So here’s the question:
Am I using the system in the wrong way? Or is this a reasonable approach under the current limitations?

You asked:

“Could it be those ‘slangs’ are part of a segment but not the entire segment?”

Possibly. I’ll try to collect some real examples from Spanish and Italian to illustrate this better. In the meantime, you can already feel the issue if you compare the two languages in my Google Sheet. Spanish is processed and manually corrected → Italian is not.

You’ll find odd entries (especially in “occupation” or “sector” descriptions) when filtering for Italian. So should these terms live in the translation memory instead of the glossary? Maybe.
This could be a discussion point .

I initially added them to the glossary to bypass current bugs. And in my case I am sure we 'switched' translation memory a few times or created a new one by my mistake or to fix a bug. I am trying to get this working for about 14 months now - so before the big release.

That said: from my perspective, this workaround is quite safe — By providing the glossary they can’t “break” anything.

Alternatively, I could create a content post with all these terms, just to train the memory and skip the glossary altogether.

But then we face the same issue: “A glossary must always have a value.” So when I add Italian, the glossary immediately inserts English fallback terms — and my translator ends up correcting WPML’s default output, not their own base translation.

So the real question then would be: Are we fixing poor translations, or are we correcting WPML behavior?

Reaction on Point 3 – Understood

No further comments here.

Reaction on Point 4 – Great to hear

A “Delete Glossary” feature will be very helpful — thanks for confirming it’s being worked on.

Final Questions – in preparation for a call

Is my current thinking in “Point 2 – Current Workflow” correct? If so, I’ll simply prepare a clean CSV with the extra kind column added and continue with this method.

In my explanation above I keep circling around. “A glossary must always have a value.” Maybe my mind just keeps hitting the same wall - derived from my website development. But I really feel there is a point here from a user perspective.

I will be available:

Wednesday: till 13:00 and after 16:00
Thursday: full day
Friday: full day

Best regards,

July 15, 2025 at 3:15 pm #17238687

Alejandro
WPML Supporter since 02/2018

Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Rome (GMT+02:00)

But then the question comes to mind that you mention the glossary with terms set to 'general' are hidden? Will these terms be overwritten when 'kind' is changed to 'name'?

No, there will be a process on our end that will correct this situation (the fact that they are getting hidden is actually a bug, a collateral from the transition process).

there won't be a "kind" eventually, as you see in the CSV sample right now, and Actually the fact that when you upload the CSV without a kind, it doesn't upload the terms, is also another bug, it was not supposed to have happened at all.

We gathered all the issues we found about the glossaries and our devs are hard at work to have them all fixed as soon as possible so you can use your glossary as intended.

-----------------

3. I now have a very limited time to either:
• manually correct these terms, or
• import a corrected glossary
…before confirming and publishing the language.

I think I might be missing something. what you say is true for the "review" process, but in general you can se the retranslate feature to set/update the glossary correctly for up to 2000 of the last translations or 30 days in advance, whichever comes first.

This restriction is temporary, we're going to allow a retranslate of everything soon, we just need to test it for performance first.

--------------------------------

It seems that you're using the glossary the correct way and I'd like to see that process in action in a call, maybe for this friday, this way I can consult with our developers first about a few things you mentioned, to make sure that what I'm seeing and what you're expecting are the same and not bugs or any untested scenario.

Allow me one day to get feedback from our devs and then I'll schedule everything.

July 15, 2025 at 3:28 pm #17238705

Jasper

Oké all clear. Thanks