[Waiting for user confirmation] Wpml transaltion with WooCommerce categories gone wrong

Thanks Osama for your assistance my issue has been resolved, just i am waiting to update some logic from frontend if every thing goes smooth so this issue will be mark as resolved

Hi,

We are once again experiencing the issue where the category hierarchy is lost after translation. Previously, when we uploaded the categories, they were automatically translated while preserving the correct parent–child structure. However, after uploading the categories again this time, the hierarchy is still breaking.

Please review this issue once more. We want to avoid running into the same problem repeatedly.

Thanks.

But tell me one thing — when I upload products, the categories are translated automatically one by one as each product gets translated. First, I want to know how I can translate only the categories automatically. Once I understand that, I can follow the rest of your instructions.

still same issue as per your instruction i follow the same

Yes Osama, it’s fixed now, but I’m still not sure how it was resolved. I need you to explain the proper solution so I know what to do next time, and I can document it clearly for the client.

Hi Osama,

We successfully translated all WooCommerce products, and everything looked good at first. But when I started integrating the translations with my custom plugin (Vamos Funnel), multiple critical issues appeared. The translated product data is not loading correctly on the custom frontend, especially for non-English languages. This is causing major problems for our business.

Below is a detailed breakdown of the issues:

WPML Accommodation Issue – Technical Documentation
Problem Summary

Accommodation loading works only in English. Out of 40 languages, most fail to load the correct translated product/category data when fetched via AJAX.

Root Cause

WPML translates category slugs along with category names:

English slug: online

Hindi slug: ऑनलाइन → URL-encoded as %e0%a4%91%e0%a4%a8%e0%a4%b2%e0%a4%be%e0%a4%87%e0%a4%a8

When this value is passed into sanitize_text_field(), WordPress corrupts the Unicode/URL-encoded slug.
This results in an empty string → triggering “Destination is required” errors.

Three Main Issue Types Identified
Type 1: “Destination is required”

Affected Languages: Chinese, Hebrew, Hindi, Persian, Arabic, Korean, Punjabi, Ukrainian, Thai, Japanese
Cause: Non-Latin category slugs get corrupted by PHP sanitization.

Type 2: “No accommodations found”

Affected Languages: Catalan, Italian, Finnish, Hungarian
Cause: English slug like buenos-aires is received, but translated category lookup fails in those languages.

Type 3: Wrong prices or currency

Affected Languages: Several (e.g., Malaga)
Issues:

Prices show in USD instead of EUR

Some translated products show $0.00

Additional Issues After SKU-Based Logic Implementation
4. Loading Time Increased Significantly

After switching to SKU-based WooCommerce product fetching in the AJAX logic, the loading time for several languages increased dramatically.

AJAX responses take too long

Slow DB queries for translated SKUs

Performance drops when WPML applies language filters

This is affecting user experience on frontend heavily.

5. Incorrect Translation Strings Showing

Some translated text strings are appearing in the wrong language.

Examples:

If I select French, a few labels show in Spanish

Choosing Korean loads some Arabic static strings

Certain WPML string translations are mismatched or overlapping

This makes the frontend look broken and unprofessional.

Urgent Request

These problems are now critical for our business. If we cannot properly integrate WPML-translated products through AJAX, WPML becomes unusable for our use case—even after investing heavily in it.

We urgently need:

A clear guide for integrating translated WooCommerce categories/products with custom AJAX

Correct handling of multilingual slugs and SKUs

Fixes or recommendations for performance issues

Help from the WPML technical team if possible

Please help us resolve this before it impacts our business further.