Open
Overview of the issue
Translating a term with the same slug as the original term will automatically add a suffix with the language code. This is because WordPress API does not allow to have more than one occurrence of a slug for a specific taxonomy.
Here’s an example of what we expect:
– http://example.org/city/paris/
– http://example.org/fr/city/paris/
Currently, a language suffix is automatically added to the translated term => http://example.org/fr/city/paris-fr/.
Workaround
As a workaround, you can use the following steps (or watch a screencast of the workaround):
- create the term first
- update it with the “quick edit” link
- change the slug value and click Update {Taxonomy name}
Good that it is logged. Here it is described what the erroneous situation is. Good.
Could you please also explicitly declare what the required functionality is, as that is not clear here.
And maybe provide an example with a default language and translation language, where the suffix is automatically added?
Hi minis,
Indeed this wasn’t so clear so I updated the title and the description. Does it makes sense to you now?
You’re wonderful Pierre! Yes, a lot clearer. Thanks.
When adding an identical term to a post on the post edit screen, the term is not added with a language suffix, but the original term (in another language!) is used.
The adding of an identical term only works correctly from the term overview admin page.
Hi @erikD-2,
I think the trouble you are facing is specific to post tags. We reported this recently in https://core.trac.wordpress.org/ticket/45121#ticket. This is because post tags are handled as names (not IDs) in the save process.
If this is a wider issue, could you please open a support ticket so we can investigate?
Thanks,
Pierre
I’ve found a workaround for this.
Add the category with the translation service
After it’s added, go to the language tab in the category overview and use ‘quick edit’, this will allow you to use the same slug.
Whoops I read over the workaround
Sorry can you be more detailed about this workaround, i have some problem to follow all the step.
Thank you!
Hi @Marco,
I added some screenshots in the workaround. Let me know if it helps!
Thanks,
Pierre
I cant send the screenshot here but this workaround doesnt work for me.
My step:
– created a new taxonomy (eng translation) with differente name and NO SLUG
– SLUG automatically ADDED succesfully with the “-ENG” suffix or a number
– click on a QUICK EDIT and modify the SLUG at the same name of the other language
– get an error from WORDPRESS who avoid to rename it because its already used from another taxonomy
You miss one step.
Here its the correct order:
– WPML > TAXONOMY TRANSLATE : and add the language of the new taxnonomy
– when the popup jump out COPY THE SAME SLUG from the language source with the copy button
– moving to the category taxonomy and follow the step showed in the screenshot
But after, in the result page, i get ZERO RESULT and NO TRANSLATION.
Seems the TAXONOMY do not catch the database or the original taxonomy (who are now the same)
Hi Marco,
I invite you to open a support ticket on the forum and a supporter will provide you with the needed assistance.
Please include your debug information, and a temporary access to your site (if you wish).
Thanks,
Pierre
Hi Marco,
I added a screencast of the workaround in the description. If you are still experiencing issues, please open a support ticket.
Thanks,
Pierre
Hi everybody,
This issue is solved ?
Thanks
Didier
Hi, no this is not added to WPML yet. It’s on the list of our features but I do not have an estimation for when can it be added.
Hi everyone,
I am having the same issue as well.
My url goes from “/blog” for the English version, to “/blog-de” for the German version.
If I try to edit it to “/blog” for the German version (wpml–> taxonomy translation –> category translation),
WPML still creates and alternative version of the slug.
Hello there,
In that case, please follow the workaround, it should help.
Hi, I was wondering if there is a fix for this in the make or still no news? Thank you.
Hey there,
Unfortunately, we still don’t have a fix for this. Devs plan to add it in the next big release cycle, however, it totally depends on their developing roadmap.
We will keep this erratum updated.
Regards
I really have to say that it is quite sad how long that issue is actually there and for how long the implementation by the Core team is already done (5 years). Any news/timeline on that matter?
Hey there,
Unfortunately, we still don’t have a fix for this. Devs plan to add it in the next big release cycle, however, it totally depends on their developing roadmap.
We will keep this erratum updated.
Regards
When your “Big Release” is out i believe by then wordpress will already have implemented native multilingual support, so no need for the devs to tire themselves out on the existing issues, let them take a break.
You are right, hope they release wordpress phase 4 soon that will have native multilingual support in the core
If I had seen this problem that hasn’t been solved for 6 years, I definitely wouldn’t give 100 euros. Does anyone in the development team know what 6 years is?
Hello,
No this is not added to WPML yet. It’s on the list of our features request and the dev team is aware of it but we do not have an estimation for when can it be added.
Its funny how many of the issues with WPML you start with the thread 2020 and ends in 2024 and you see the typical following answer “It’s on the list of our features request”
Truly looking forward to Phase 4 of wordpress with native multilingual support in the core so we can skip all the issues with WPML and the extremly slow progress, i wonder what the developers are up to… seem to be to lazy no beeing able to solve several issues that have existed for several years.
We understand your frustration but some fixes may take longer than others, however this is already in our devs roadmap.
We will keep this erratum updated.
Regards
we are 2025, that is 7 years later than when the issue was highlighted, this should be the number 1 priority to fix
We understand your frustration. This issue is still on our development roadmap, and we’ll update this erratum as soon as there’s progress to share.
Thank you for your patience.