# WPML Glossary Bug Report: Language Variants Not Handled Correctly
## Summary
**Critical Bug**: The WPML Glossary feature cannot properly handle languages with multiple country-specific variants (e.g., French as `fr` and `ch-fr`). The backend API assigns the same translation ID to different language variants and copies the wrong translation text, causing data loss.
When creating a glossary entry with translations for both `fr` (French - Custom) and `ch-fr` (French - Switzerland), only one translation is displayed correctly. The other shows an "add translation" button, and the translation text is incorrect.
1. Both `fr` and `ch-fr` receive the **same translation ID** (7541183) - they should have unique IDs
2. The `ch-fr` translation shows `"french-fr-entry2"` instead of `"french-ch-entry2"` - **data loss**
3. The original `ch-fr` text is lost and replaced with the `fr` text
## Root Cause
The `create_or_update` endpoint treats language variants (e.g., `fr` and `ch-fr`) as if they share the same translation record, when they should be completely separate records with unique IDs and their own translation text.
## Steps to Reproduce
1. Navigate to WPML → Translation Dashboard → Glossary
2. Create a new glossary entry in English
3. Add translation for French (Custom) - `fr` with text "french-fr-entry"
4. Add translation for French (Switzerland) - `ch-fr` with text "french-ch-entry"
5. Save the glossary entry
6. **Result**: Only one French translation displays correctly. The other shows wrong text or "add translation" button.
## Expected Fix
1. **Backend**: Each language variant should have its own unique translation record with a unique ID
2. **Backend**: Country-specific variants should preserve their own translation text, not copy from base language
3. **Frontend**: Use `language_code` (or composite key) instead of `id` alone when mapping translations to columns
## Affected Entries
- "english-entry" (ID: 1680345) - both `fr` and `ch-fr` have ID 7541012
- "english-en-entry2" (ID: 1680360) - both `fr` and `ch-fr` have ID 7541183
The issue affects all languages with multiple country variants (French, German, Italian).
First of all, I would like to thank you for the exceptionally detailed and accurate description of the issue. It is very helpful.
I will try to reproduce the issue on my side now and evaluate the complexity of the bug fix. I will come back to you with an update as soon as I have more information.
Hi Hans,
We understand your point.
At the moment that's not supported.
In order to assign the correct priority to it I would like to know if it's a nice to have or it's blocking some translations.
The current situation prevents us from using the glossary for words which differ between countries.
For example in Swiss German, it is common to use different words for the same meaning as used in Germany.
This means that we need to fix these words manually in each translated post, which is pretty time consuming.
Thank you very much for your patience and for the detailed information you have provided in this thread. It has been extremely helpful.
I would like to clarify how WPML handles custom language mappings, as this is related to the behaviour you are seeing in the glossary.
In your configuration, ch-fr is mapped to fr. When a language variant is mapped this way, WPML does not treat ch-fr as an independent translation target. Instead, translation jobs that appear to be targeted at ch-fr are internally created and processed as fr because of the mapping. In other words, the target language of the job becomes fr as a direct result of the mapping.
This is why glossary terms for ch-fr are not stored separately from fr: the system cannot distinguish them during translation.
From a technical perspective, this means that the behaviuor you observed (same ID and text for both variants) is expected when ch-fr is mapped to fr.
That said, we may not fully understand your intended workflow, so it would be very helpful if you could clarify exactly what you need to achieve.
For example, do you need:
1. Separate glossary terms for fr and ch-fr that are both respected during translation in the ATE editor, or
2. Separate glossary terms purely for organizational or display purposes in the backend, even if the translation editor treats them as the same language, or
3. Something different entirely?
Understanding the goal will allow us to determine whether this is a configuration issue, a technical limitation of the mapping mechanism, or a feature request for a different workflow.
Thank you again for the detailed report and for working with us on this.
They tell me, that they don't know of any case, where the glossary entry needs to be different for two instances of the same language.
So it would probably suffice to fix the glossary GUI so it can handle the case where there is more than one instance of a language.
I'm not sure how this is best solved.
It would probably make sense to only have one input be editable.
Maybe the other ones just show a disabled input where the content of the first one is shown?
One last question.
If we use the glossary as it is, it will probably already work, just the gui is a bit broken with multiple instances of the same lang?
Thanks a lot for checking with the customer and for the detailed explanation.
We’ve created a ticket on our side to address this as a UX issue in the glossary GUI. We’ll look into improving how this is handled visually to avoid confusion.
To answer your last question: yes, using the glossary as it is should work correctly. The current issue is limited to the GUI and does not affect the underlying functionality or how the glossary is applied.
