[Resolved] Split: Glossary Translation has random capitalization
This thread is resolved. Here is a description of the problem and solution.
Problem: The client needed clarification on how the glossary translations work in WPML, specifically whether it can handle variations of a term when the words are separated or reordered. Solution: We explained that the WPML glossary translations strictly require exact term matching. This means that the term must appear in the content exactly as it is entered in the glossary for the translation to apply. For example, if 'cored wire' is added to the glossary and translated, it will only be recognized and translated if 'cored wire' appears exactly in that order in the text. Variations where the words are separated or reordered, like 'metal cored gas shielded wire', will not trigger the glossary translation. To handle different variations, additional specific entries must be added to the glossary.
If this solution does not fully address your issue, or if it seems outdated or irrelevant to your specific case, we highly recommend opening a new support ticket. Additionally, please check the related known issues and ensure you have the latest versions of themes and plugins installed. For further assistance, you can also visit our support forum.
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.
We have additional logical issues we need to flag. It might be possible to tweak this based on the configurations you have avialable. Can you please create a separate ticket for "Logical Glossary Translations"? AND if possible, can we do this over a LIVE call, where we are able to share screen and explain the issues exactly?
We can certainly follow up on your new issue regarding the “Logical Glossary Translations.” Please note that we provide support exclusively through our live chat and ticketing system.
Could you please share a short screen recording explaining the issue, along with the URL of the page where it can be replicated? This will allow us to review and verify the problem more effectively.
The "logical" issue can be found on the below URL:
hidden link vs hidden link
Please see attached screenshot (This was sent from the client using DeepL), it is not something that can be better explained with a screen recording. The logical issue is:
- "cored wire" is added to the glossary and translated to "arame tubular" for Portuguese. So the client expects any variation of "cored wire" to respect the glossary translation of "arame tubular"
1. Example 2: hidden link (Look at HARDFACE NICARBW - "Cored hardfacing wire"), it is being translated as "Fio tubular" hidden link
So essentially, the client is looking for a configuration that matches the glossary closely.
2. Example 2:
Another example is the term "Welding Alloys"
"Welding Alloys" is added to the glossary and translated to "Welding Alloys" for Portuguese. The issue is when the phrase contains a question mark ie. "Welding Alloys?" then it ignores the glossary. * I had to add both "Welding Alloys" and "Welding Alloys?" to the glossary as a workaround for now.
1. Reminder to please advise on the first logical issue.
2. Unfortunately, I have been able to reproduce this issue. The Glossary terms are still being "cached" even after being deleted.
- I have deleted both "Welding Alloys" and my workaround "Welding Alloys?" from the glossary and done a test retranslation, but the Glossary is still being applied. Kindly advise if the glossary "cache"/memory on my site can be cleared? Then I will be able to test this properly and provide you with a screen recording.
Thanks.
New threads created by Kor and linked to this one are listed below:
Thanks for your reply, and sorry for overlooking your first question.
Could you please share updated access credentials to your website so I can verify the "logical issue" on my end?
Regarding your second question (“Glossary terms are still being cached even after being deleted”), I checked with our ATE team, and they confirmed that we do not cache glossary entries. That said, we’ll still need to investigate this further once I have access to your site.
To keep things organized, I’ll split your second question into a separate ticket once I have the access credentials, since it may require deeper troubleshooting.
For this ticket, we’ll focus specifically on the first logical issue you mentioned.
It appears that my colleague and I are currently investigating the same issue. Could you please follow the steps suggested by my colleague and let us know the results?
I have left some feedback in the ticket for the Capitalization issue.
This is completely separate to this Logical issue. Kindly review again and look at the previous screenshot I sent to ensure you understand the issue.
Ignore all other tickets please and focus on the first "logical" issue only as per screesnhot from DeepL. Is this a configuration that is possible within WPML?
Thanks. This is more of a question to find out if WPML is able to use more "Natural Language'
Please see summary again:
- "cored wire" is added to the glossary and translated to "arame tubular" for Portuguese.
So, the client expects any variation of "cored wire" to respect the glossary translation of "arame tubular"
Example as per screenshot: 'metal cored gas shielded wire' > because this sentence/phrase contains 'cored wire' , the question is, is there an option for the glossary to still be applied in context, when the phrase contains 'cored wire' as per 'metal *cored gas shielded *wire' or does the phrase always need to contain exactly 'cored wire'? e.g. 'metal gas shielded *cored wire*' ?
Thanks for your reply and for the detailed explanation. I understand what you’re trying to achieve.
In this case, the glossary only applies when the exact term matches the glossary entry. So if you added “cored wire” and translated it to “arame tubular”, the phrase must contain the exact string “cored wire” in that exact order for the glossary to be applied.
For example:
✅ “metal gas shielded cored wire” → The glossary will apply because it contains the exact term “cored wire”.
❌ “metal cored gas shielded wire” → The glossary will not apply because “cored” and “wire” are separated, so it is no longer an exact match.
At the moment, there is no option to make the glossary apply partially, by pattern, or by contextual matching when the words are separated or reordered. The behavior is strictly based on exact term matching.
If needed, you would have to add additional glossary entries that match the specific variations you want to control.
