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/.
A ticket has been created in WordPress Trac to overcome this issue: https://core.trac.wordpress.org/ticket/43271 (feel free to add a comment to this ticket to make it move forward).
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