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
12:00 – 20:00 12:00 – 20:00 12:00 – 20:00 12:00 – 20:00 12:00 – 20:00 - -
- - - - - - -

Supporter timezone: Asia/Karachi (GMT+05:00)

Tagged: 

This topic contains 3 replies, has 0 voices.

Last updated by Noman 1 month, 3 weeks ago.

Assisted by: Noman.

Author Posts
February 13, 2026 at 12:46 pm

adrienR-5

Hello,

We are currently experiencing an issue with taxonomy translation on our website:

We have a custom post type called Franchise with a custom taxonomy franchise_category.

**Description of the Issue**

We noticed inconsistent behaviour when working with taxonomy translations:

**1️⃣ Translation Creation Behaviour**

When we create the taxonomy directly as a translation (from the translation interface), it works correctly.

However, when we:

Create the taxonomy separately in EN-US,

Then try to map or assign it to the FR translation,

👉 It does not work properly.

It seems that the taxonomy must be created strictly through the WPML translation workflow, otherwise it fails.

2️⃣** Slug Conflict Problem (Important)
**
The issue appears specifically when the slug of franchise_category is identical across languages.

When the slug is the same:
The taxonomy seems broken.
The category does not update properly.
Saving behaves inconsistently.
However, this should NOT happen because:
Translation is explicitly activated for this custom taxonomy in WPML settings.
The taxonomy is set as translatable.

Please clearly note:

It is when the slug is the same that the issue appears.
It seems broken only in that situation.

This behaviour suggests a conflict in how WPML handles identical slugs for translated custom taxonomies.

**3️⃣ Saving Fails After Unassigning**

Another critical issue:

If we unassign the taxonomy from a post,

We are unable to save the post properly afterward.

The taxonomy cannot be saved again.

Category changes are not updating.

This creates a blocking workflow issue.

**4️⃣ Existing Categories Not Updating**

We also tested:

Using existing categories not currently assigned

Editing and reassigning them

But:

They do not update properly.

Changes are not reflected after saving.

**5️⃣ Conflict Testing**

To rule out conflicts:

We deactivated all unnecessary plugins.

The issue still persists.

We activated a default theme (Twenty Twenty-Four / Twenty Twenty-Five) for testing.

The problem remains even outside the Bricks child theme.

Video Demonstration (Very Important)

Please watch this video carefully to understand the issue clearly:
hidden link

In the video, you will clearly see:

1. The different behaviours between creating as translation vs separate creation
2. The saving issue after unassigning
3. This video demonstrates the issue much more clearly than text explanation.

Our Questions

1. Why must the taxonomy be created only as a translation to function correctly?

2. Why does saving fail after unassigning the taxonomy?

3. Why are category updates not reflected?

4. Why does the issue specifically occur when the slug is identical across languages?

5. Should identical slugs be supported when translation is enabled for that custom taxonomy?

This issue is blocking our workflow, and we would appreciate your guidance.
Looking forward to your assistance.

Thank you.

February 15, 2026 at 5:54 pm #17823744

Noman

Sorry for the delay, I was off during the weekend. This issue has already escalated to our 2nd tier team. It appears to be a very specific edge case (having unconnected terms with the same slug in different languages, and then editing the term in the secondary language).

For now, please try the following workaround:

❌ Please make a full website backup before proceeding ❌

In your child theme functions.php file add:

add_filter( 'terms_pre_query', 'wsmod_terms_pre_query_custom', 10, 2 );
function wsmod_terms_pre_query_custom( $terms, $term_query ){

    if (
        isset( $_REQUEST['taxonomy'] ) && $_REQUEST['taxonomy'] === 'your_taxonomy_slug'
        && isset( $_REQUEST['action'] ) && $_REQUEST['action'] === 'editedtag'
        && isset( $_REQUEST['tag_ID'] )
    ) {
        $term = get_term( (int) $_REQUEST['tag_ID'], 'your_taxonomy_slug' );

        if ( $term && ! is_wp_error( $term ) ) {
            $terms = array( (int) $term->term_id );
        }
    }

    return $terms;
}

Please replace “your_taxonomy_slug” with your custom taxonomy term slug in above code.

Then edit the English slug and connect it to the French one as a translation. After this category term should be updated without any issues.

Also, could you please clarify your use case? Specifically, why there are unconnected category terms with the same slug in different languages and then the secondary language terms are being edited.

I tested the workaround at the fresh WP site here: and it works correctly.
hidden link

Thank you

February 18, 2026 at 12:49 pm #17832392

adrienR-5

Hello Noma,

Thank you for your response.

To give you more context on our workflow: our client has a multilingual team where each person manages content in their own language. Sometimes, a team member creates a new custom taxonomy term directly in their assigned (secondary) language — without first checking if an equivalent already exists in the default language (FR).

Later, the SEO manager reviews the taxonomy structure and notices that this secondary-language term has the same slug as an existing term in FR. At that point, they want to map the secondary-language term to the existing FR term (i.e., set it as its translation).

However, WPML throws an error and prevents saving when they try to edit that secondary-language taxonomy term — precisely because the slug conflict already exists.

Steps to reproduce:
- A taxonomy term exists in FR (default language) with slug example-slug
- A team member independently creates a term in EN (secondary language) that also ends up with slug example-slug
- When trying to edit the EN term (to map it to the FR term or make any change), WPML blocks the save with an error

What we're looking for: an internal WPML fix that allows editing and saving a secondary-language taxonomy term even when its slug matches a term in the default language. The duplicate slug itself is not the problem — WPML should handle this gracefully since these are terms in different languages. The issue is that WPML blocks any edit on that term entirely.

We understand that creating terms via the WordPress sidebar works even with duplicate slugs, but once created, the term becomes uneditable through WPML.

Thank you for looking into this.

February 18, 2026 at 8:29 pm #17833926

Noman

Thank you for the detailed explanation, that helps a lot.

I’ve forwarded your workflow and use case to our 2nd tier team for further review so they can evaluate a proper internal fix.

In the meantime, please continue using the workaround shared earlier to connect the terms and resolve the slug conflict.

I’ll update you as soon as I receive feedback from the team.

Thank you for your patience.