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
- 8:00 – 17:00 8:00 – 17:00 8:00 – 17:00 8:00 – 17:00 8:00 – 17:00 -
- - - - - - -

Supporter timezone: Europe/Madrid (GMT+01:00)

This topic contains 16 replies, has 0 voices.

Last updated by Paola Mendiburu 5 hours, 27 minutes ago.

Assisted by: Paola Mendiburu.

Author Posts
February 25, 2026 at 10:38 am #17850717

ondrejd-2

Problem:
On translated WooCommerce products, the _product_image_gallery meta stored in the database is correct per language. However, on the frontend, the gallery IDs returned by WordPress are different from what is stored in wp_postmeta.

---------------------------------------------------------------------------------------------
Specifically:
Direct SQL query via $wpdb returns the correct meta_value from wp_postmeta.
But get_post_meta(), get_metadata_raw(), and $product->get_gallery_image_ids() return a different set of IDs.
The returned IDs include values that are not present in the database for that product ID.
This results in the frontend gallery displaying images that do not match the stored _product_image_gallery for that translation.

---------------------------------------------------------------------------------------------
Environment:
WordPress + WooCommerce
WPML + WooCommerce Multilingual (WCML)
No Media Translation used
Each language uses its own attachments (separate media per language)
_product_image_gallery is correctly stored per translation in wp_postmeta

---------------------------------------------------------------------------------------------
Debugging steps performed:
Confirmed correct product IDs (example):
SK product ID: 8411
HU product ID: 8727

---------------------------------------------------------------------------------------------
Verified database content in phpMyAdmin:
wp_postmeta contains correct _product_image_gallery for both SK and HU products.

---------------------------------------------------------------------------------------------
Verified direct SQL via $wpdb inside template:
global $wpdb;

$post_id = $product->get_id();

$row = $wpdb->get_row(
$wpdb->prepare(
"SELECT meta_value FROM {$wpdb->postmeta} WHERE post_id = %d AND meta_key = %s",
$post_id,
'_product_image_gallery'
)
);

var_dump( $row );

This returns the correct meta_value from the database.

---------------------------------------------------------------------------------------------
Verified get_metadata_raw():
get_metadata_raw( 'post', $product->get_id(), '_product_image_gallery', true );

This returns a different value than the direct SQL query.

---------------------------------------------------------------------------------------------
Inspected filters on get_post_metadata via WP-CLI:

wp eval '
global $wp_filter;

$hook = "get_post_metadata";

foreach ( $wp_filter[ $hook ] as $priority => $callbacks ) {
foreach ( $callbacks as $cb ) {
$fn = $cb[ "function" ];
if ( is_array( $fn ) ) {
$name = ( is_object( $fn[ 0 ] ) ? get_class( $fn[ 0 ] ) : $fn[ 0 ] ) . "::" . $fn[ 1 ];
} else {
$name = $fn;
}
echo $priority . " => " . $name . "n";
}
}
'

This revealed:

WCML_Product_Gallery_Filter::localize_image_ids

hooked into get_post_metadata at priority 10.

---------------------------------------------------------------------------------------------
Root cause:

WCML_Product_Gallery_Filter::localize_image_ids filters get_post_metadata and overrides the _product_image_gallery meta at runtime, even though the database contains correct per-translation values.

Expected behavior:

If each translation has its own _product_image_gallery stored in wp_postmeta, WCML should not override those values during metadata retrieval.

Actual behavior:

WCML modifies _product_image_gallery during get_post_metadata, causing frontend gallery to use a different set of attachment IDs than what is stored in the database.

---------------------------------------------------------------------------------------------
Temporary workaround:

Removing the WCML filter restores correct behavior:

add_action( 'init', function () {

global $wp_filter;

if ( isset( $wp_filter[ 'get_post_metadata' ] ) ) {

foreach ( $wp_filter[ 'get_post_metadata' ]->callbacks[ 10 ] as $callback ) {

if (
is_array( $callback[ 'function' ] ) &&
is_object( $callback[ 'function' ][ 0 ] ) &&
get_class( $callback[ 'function' ][ 0 ] ) === 'WCML_Product_Gallery_Filter'
) {
remove_filter(
'get_post_metadata',
$callback[ 'function' ],
10
);
}
}
}

} );

After removing this filter, the frontend correctly uses the raw _product_image_gallery stored in the database.

Questions:

Is WCML intended to override _product_image_gallery even when translations have their own gallery meta stored?
Is there an official way to disable WCML gallery localization without manually removing the filter?
Should WCML respect per-translation _product_image_gallery values stored in wp_postmeta?

February 25, 2026 at 12:21 pm #17851436

ondrejd-2

How rude turning this into a ticket while you clearly saw me writing a reply. I expect no less from WPML stuff. Unskilled, rude...

As I wrote before you interrupted me Paola.

If you want to force us to use the Media Translation plugin then provide a way for us to select from existing media. We have 7 years of media in our media library which cannot be used because Media Translation only allows uploading the translation and not selecting it from existing media.

I feel like I am talking to a kindergarten class with special needs here. You are a godammit software company. Act like one for ffs.

February 25, 2026 at 12:23 pm #17851439

ondrejd-2

Here is the link to a video I recorded during our chat:
hidden link

You will have to wait for it to process. I am not using any AI super tools. Too oldschool for that.

February 25, 2026 at 12:31 pm #17851491

Paola Mendiburu
WPML Supporter since 11/2020

Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Madrid (GMT+01:00)

Hi there!

I have send all the info to the second tier.

I will let you know when I have some news.

February 25, 2026 at 2:50 pm #17852003

Paola Mendiburu
WPML Supporter since 11/2020

Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Madrid (GMT+01:00)

Hi there!

In order to fix the issue, please go to WooCommerce --> WCML --> Settings and uncheck that option: Display original images on the translated product front page if images not specified

I have done on the test site and it works.

I have recorded a video:
hidden link

February 26, 2026 at 8:34 am #17855369

ondrejd-2

I tried it and for now it seems to be working. Let's hope it stays that way.

I have few more questions and I want good, straightforward answers.

1. Since when "Display original images on the translated product front page if images not specified" means the same as "Use the images specified in the translation"?

2. Why the developers decided to turn this option on by default?

3. Why is WCML even touching the media if you have a completely separate - optional plugin that should handle that (Media translation)?

FACTS WE LEARNED HERE:
- our products have images specified
- WCML for some reason thinks they are not specified
- it is probably a bug
- the wording for the setting label is simply incorrect ("Display original images on the translated product front page if images not specified")

February 26, 2026 at 9:34 am #17855627

Paola Mendiburu
WPML Supporter since 11/2020

Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Madrid (GMT+01:00)

Hi there!

I’m glad to hear it’s working for you.

Normally, products are translated using the WPML Translation Editor (Advanced or Classic Translation Editor).

In that workflow, images are handled through Media Translation, which ensures that the correct attachments are associated with each language version.

February 27, 2026 at 10:24 am #17859281

ondrejd-2

That is not true. Media Translation is an optional plugin. Answer the questions I gave you.

February 27, 2026 at 10:37 am #17859332

Paola Mendiburu
WPML Supporter since 11/2020

Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Madrid (GMT+01:00)

Yes but the only way to translate images when using ATE is via Media translation.
Your case is different as you are doing manual translation and adding manually images to the translation and that is the reaso why you need to switch off that option.

March 2, 2026 at 8:10 am #17863479

ondrejd-2

We have been raising this issue for many years (more than 7) and it remains unresolved, which is extremely frustrating for us as a long-term WPML client.

Our case is specific: we have always needed proper media translation that allows different physical images per language. In earlier versions this did not function as expected. Now the feature technically allows different images per language, which is good — however, there is still a major limitation.

There is no way to reuse existing files from the Media Library when assigning translated images. The interface only allows uploading new files instead of selecting already uploaded ones. For businesses like ours, with a large and well-organized media library, this is a serious workflow limitation.

We need clarification on:

1. Is this limitation intentional?
2. Is there a technical reason why existing Media Library files cannot be selected?
3. Is this on your roadmap to improve and when you intend to finally implement it?
4. If it is not in your roadmap, what is the recommended scalable solution for sites with large multilingual media libraries?

We are paying for updates and support because we rely on WPML in a production environment. However, frequent update conflicts and long-standing unresolved workflow issues significantly impact our operations.

We would appreciate a concrete technical explanation and a clear direction forward rather than generic responses.

March 2, 2026 at 11:27 am #17864252

Paola Mendiburu
WPML Supporter since 11/2020

Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Madrid (GMT+01:00)

Thank you for your detailed explanation. I completely understand how frustrating it must be to deal with a workflow limitation for such a long time, especially in a production environment.

Before escalating this formally to our developers as a feature request, I would like to make sure we are talking about the exact same scenario.

Just to clarify:

- Are you referring specifically to the Media Translation screen (WPML → Media Translation), where when assigning a translated image, the interface only allows uploading a new file and does not allow selecting an existing image from the Media Library?

- Because from the standard product editing screen in WordPress, it is normally possible to select existing images from the Media Library for each language.

March 3, 2026 at 7:03 am #17866782

ondrejd-2

Thank you for the clarification.

Yes, I am referring specifically to WPML → Media Translation.

To clarify our setup further:

We are using WPML in a way where media libraries are effectively separated by language context. For example, Hungarian images are uploaded while the admin language is set to Hungarian and are assigned only to Hungarian products. Those images are not visible in the Media Library when switching to a different language context.

This means that in practice, each language operates with its own media set.

Because of this, the Media Translation screen would need to be aware of language context and allow selecting images from the appropriate language-specific media library.

Currently, in the Media Translation interface:
- There is no way to switch language context
- There is no way to select from existing media
- Only new file uploads are allowed

For our workflow, the correct behavior would be:
- When assigning a translated image, allow selecting from the Media Library filtered by the target language
- Respect the language-based media separation already implemented by WPML

Without this, we are forced to either:
- Re-upload images unnecessarily, or
- Manually switch admin language, open products individually, and assign images per translation

For large multilingual catalogs, this becomes inefficient and error-prone.

So the core issue is not just “selection vs upload” — it is that the Media Translation tool does not integrate with WPML’s own language-separated media handling model.

Additionally, this issue has already been escalated in the past. To the best of our knowledge, no change was implemented and we did not receive any follow-up regarding its status.

Given that this was previously escalated, we would expect:

- Either confirmation that the previous escalation is being reopened,
- Or a reference to the original internal ticket (if it still exists),
- And to be notified if and when any change related to this is implemented.

Since this affects our production workflow and has been an ongoing limitation for several years, we would appreciate proper tracking and visibility rather than treating this as a new, isolated feature request.

Please let us know how this will be handled internally.

March 3, 2026 at 8:42 am #17867121

Paola Mendiburu
WPML Supporter since 11/2020

Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Madrid (GMT+01:00)

Hi there!

I can see that this functionality was already requested in the past and registered as a feature request, I see that you have requested also in the past:
https://wpml.org/forums/topic/how-does-media-translation-work/

However, I’d like to clarify that being listed as a feature request does not guarantee that it will be implemented. These requests are reviewed by management and the development team, and their inclusion in future releases depends on overall prioritization, technical considerations, and product strategy.

At the moment, I’m afraid I can’t confirm whether or when this will be developed.

That said, I’ve insisted on this again internally from my side and made sure your use case has been re-emphasized with the team.

March 3, 2026 at 11:04 am #17867927

ondrejd-2

Thank you for re-emphasizing the request internally.

However, this issue has been raised multiple times over the years — not only in February. Please check whether there are additional tickets or internal references associated with our account regarding this matter.

We understand that feature requests are not guaranteed to be implemented. However, this limitation has been affecting our production workflow for many years, despite us being a long-term paying customer operating a large multilingual e-commerce site.

From a business perspective, it is difficult for us to understand how a core workflow inconsistency — between language-separated media handling and the Media Translation interface — remains unresolved for such a long time, while significant development effort appears to be invested in AI-powered tools and modern editor features that, in our case, introduced instability and required us to disable them entirely.

We also have concerns that SEO impact and large-scale e-commerce workflows do not seem to be sufficiently considered in product decisions. For businesses like ours, these are not edge cases — they are central operational requirements.

To move forward constructively, we would appreciate direct answers to each of the following:

1. Is this limitation considered technically complex to implement?
2. Is it intentionally excluded from the product roadmap?
3. Has it simply not been prioritized?
4. Is there any internal discussion about aligning Media Translation with WPML’s language-separated media model?

Clear and direct responses to each question would help us understand the situation and make informed architectural decisions going forward.

March 3, 2026 at 12:01 pm #17868188

Paola Mendiburu
WPML Supporter since 11/2020

Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Madrid (GMT+01:00)

I want to clarify the situation as transparently as possible to properly manage expectations.

This remains a feature request, meaning it has been documented, but it is not guaranteed to be implemented.

At the moment:

- It is not scheduled for development.
- It is currently considered low priority.
- There is no timeline available.
- There is no commitment that it will be included in a future release.

Even if priorities change in the future, implementation would not happen in the short term.