Background of the issue:
I am trying to manage product images using WPML without Media Translation. We use images per language, with each language having its own media library. Images from this library are attached to product/post translations in the same language, including both main product images and gallery images. This setup usually works until WPML unexpectedly mixes the images. The issue can be seen on this page: hidden link
Symptoms:
The main product image is correct, but the gallery images have a Polish domain while the files are in Slovak, which is the default language.
Questions:
Why does WPML periodically mix up the product images?
How can I ensure that images remain localized and do not get mixed up?
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Hello there!
What you want to achieve, is only doable via WPML Media Translation. it's true that what you are experiencing (images being all mixed up in the gallery) is definitely not normal and we can try to tackle that (even though it's difficult without any access whatsoever, even for a staging site OR a site dump).
Doing everything manually is not possible and even if it were it would affect WooCommerce extensions and have unforseen results which is out of our hands. Also we do not cover scenarios where you mix translation methods (using manual translation for some parts of the translation and the translation editor of your choice).
------------
You repeatedly mentioned we need to fix the problem that is creating your situation and I'm willing to dig into that but in order to bring that to our devs we need either a way to recreate it from scratch or access to your site so we can see what happened and send that info to our dev.
I'm not a developer here, I'm the deputy support manager but I do code, I have over 15 years of WP experience (of all kinds, from development to SEO) so I'm fairly certain I'm experienced enough to handle this situation, plus we can always consult a dev as well who will certainly be able to help too.
Knowing that, do you know the way to recreate this problem? you mentioned this has happened for years so have you asked for this in the past? maybe I can use that information from back then to help you out or get the info I need.
Hi Alejandro,
I can give you access to the live site. That is not a problem if you agree to only look around and not do any changes, especially not without consulting them with me first.
Let me summarize it for you so we are on the same page.
The site runs in domain per language mode and basically looks like 9 separate websites from the outside. We don't use any language or currency switchers, etc. on front-end. We only use language switching in admin to edit content in specific languages.
We do not use Media Translation because that plugin assumes that we want to use one image and only localize it's title, alt, etc (HTML tag content).
The media is not mixed up in a sense that under Czech language we have Slovak pictures in the library. At least not now. It happened in the past though. That is a completely different story.
Back to the chase. As I said. We upload media per language. We use localized filenames like
SK - vianocny.-stromcek.jpg
DE - tanenbaum.jpg
CZ - vanocni-stromek.jpg
because it is good for SEO.
We also use localized watermarks in our images. We have to because our competitors stole our images in the past and we invest heavily into product photography. We have to protect our property.
We technically maintain 8 separate media libraries for our 9 domains.
2 domains .de and .at use German content so we created Austrian products as copies of German products. In this case it is perfectly fine to copy the images, but it cannot happen anywhere else.
There should be a way to achieve this and set it up once and for good.
Localized images does not mean only localizing their HTML tags. It also means localizing their filenames, visual content, etc.
The mix-up that currently happens is that all the translated products have Slovak (default language) images in their product image galleries. The main product images are not affected by this for some strange reason.
Please let me know if you need any more info before we proceed with the site access.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Hello,
Thanks for the summary.
1) You mention:
We do not use Media Translation because that plugin assumes that we want to use one image and only localize it's title, alt, etc (HTML tag content).
Media translation's purpose is not that at all. it's actually so you can "translate" a media, meaning that you'll use different images per languages (imagine an image that has a text "Hello" in it in an orange background, when you "translate it" it could be replaced in another language like "Hola" in blue background). localizing title, alt, etc is something that can be done even without the Media translation Plugin
2) From the description it seems like media translation would actually solve your problems because while I'm not sure about the filename, everything else will actually happen exactly as you mention.
Yet, if you mention that you don't want to use it, is because I suspect you actually used it already and something didn't work.
----------------
I recorded this video done on a sandbox: hidden link
In it you can see that with media translation I'm not handling the text or content but the actual image, changing it on each language which seems to be what you want to achieve.
I forgot to show it in the video but the filename changes as well, so it looks like it's indeed the solution to your problem.
Can you watch it and let me know if I'm wrong and point out where? this way I'd better understand what other option we'll have.
Hi Alejandro,
I watched your video.
The reason we stopped using the media translation was exactly because it did not work the way we wanted it to work.
While it is true that what you showed in the video is basically what we want to achieve, you never checked what URL of the image is used at the front end and what is the filename.
Those two things are important as well.
The URL has to be localized (domain per language) and the filename needs to be localized as well.
I can see that Media Translation went through some changes because it wasn't this good back when we decided to get rid of it.
Maybe the devs listened this time and added something that people actually asked for. Please excuse me for being so sarcastic but WPML devs ignore customers on purpose and I have been through WPML forums many times, reading posts of other people who went through same issues I had, seeing only vague replies or no replies at all. Threads closed without explanation or any solutions.
Anyway. Right now we cannot afford to go through this because it might break some products in the process at least for some period of time and we are at the peak of our season as we are selling Christmas goods. You can imagine how important the site performance is right now.
Please, if you can do it on your staging site. I know you probably cannot set different domains other way than setting up your hosts file to fake them. Not suggesting you should do so, but it is a reliable way to test this if you are running your own local server.
If you cannot do that, I think you can still do that with other settings like language in url.
Check if the images have the filenames unchanged (as you uploaded them to secondary language).
Check if you can access them in admin Media Library when you visit it while switched to secondary language.
Also the question. Can we still translate all the alt, title, caption, etc? Those are important for seo as well and I did not see those in the translation pop up.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Hello,
Yes media translation was revamped in WPML 4.7, it was long overdue :).
About the requirements you mentioned above, I actually answered that because I indeed realized I had missed the filename and url part on the video.
I forgot to show it in the video but the filename changes as well, so it looks like it's indeed the solution to your problem.
Both the url and filename change I also just went ahead and tested it locally with different domains and the result is as you would expect it.
- they have their own localized URL
- the filename changes so the URL also changes
- you can see them in the media library instead of the image from the original language (it takes its place)
- you can definitely translate alt text, description, etc.
Basically: if you leave the same image, then it will act as a duplicate and you can modify it's metadata, if you translate it then it means different images per language and possibility to translate metadata as well.
It seems to be exactly what you are looking for.
Would you like to test it later when you have more time and at most open a new ticket and ask to be sent to me or well for people to check this one? This way you don't start over.
You could also test on a dummy product just to see and get acquainted with and if something happens, then I'm here to help.
In your video you show the Media Translation editor and it only contains the title. Will it contain all the other fields if I turn that switch on in the settings?
Can we reuse the media already uploaded under different languages? Basically pair the media in default language with media in other languages using this plugin? The media already contains everything that is needed.
Regarding your testing question.
I am not willing to install the add-on on our live site for now. I might do it after season but certainly not now. The reason is obvious. I got screwed by WPML many times and because of that I am pretty cautious when I deal with it. This is not the first time WPML messed something massively on our site.
Any tests can only be done on local environment I don't have time to build right now. If I decided to test it I would replicate the environment. Most importantly the domain per language mode and other WPML related settings. It is time consuming and I really cannot afford that right now however good the Media Translation looks now.
I basically lost trust in this plugin over the years because devs never listened to what we said. Even when they did it took them literally years while they were developing trash like that Advanced AI powered editor that takes you out of your site to WPML site and prefills content. Never asked for it. It is the worst thing. Only people who ever benefit from that are scammers who need to build well enough localized websites to scam people. Sorry. I really hate WPML for this approach.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Will it contain all the other fields if I turn that switch on in the settings?
on my end, it didn't have anything because those images didn't have anything (alt text, description, etc). if there are more fields, it will show them, yes (I tested this to make sure of it, but I had a case about this just a day ago so it was great timing, hehe)
-------------
Can we reuse the media already uploaded under different languages? Basically pair the media in default language with media in other languages using this plugin? The media already contains everything that is needed.
This, unfortunately can't be done out of the box. I can try to see how we could help you with this (i've been asking our devs about this, even before you ask) but I believe whatever can be done about this is going to be 100% custom coding, so I'm not sure it can be easily done.
--------------
Any tests can only be done on local environment I don't have time to build right now.
I totally agree with you, anything new, should ideally be tested on a staging site first and yes, right now with black friday, thanksgiving, christmas and basically a few other holidays in the world, it's better to keep going until the rush is gone.
---------------
I totally understand your frustration when it comes to WPML changes and errors.We do listen to our clients but we also have priorities which are based on so many different factors, as well as restrictions beyond our powers.
The AI translation, Automatic translation, Advanced Translation Editor are the result of a lot of research from clients and were needed to grow the company so we could actually move faster ;).
One of the things that kept us really really restricted was that we had to move with WordPress pace because of the classic translation editor and WordPress is not investing too much into "Native multilingual" structures which is why we were deeply restricted. that's not the case now with the Advanced Translation Editor!
We know WPML is not perfect and needs to have many things fixed and we had to tackle major issues before going into these "smaller" ones. things have improved a lot over the years ever since 4.7 was released and we're finally fixing and improving ALL aspects of the plugins so I'm sure we'll work hard to make you change your mind about us.
Hi Alejandro,
I am sure no one in WPML team will work hard to make me change my mind. I have been using this plugin for how long? 7 years? Over that period of time I ran into so many issues with it and not a half of them were addressed by your support or developers. So let me set you straight.
This will take some serious work on your side if you really want to change my mind.
Let's get back to the thing.
First. All the images must have the meta fields available to be filled. Even if the image in default language does not have it, every single image must have those fields visible and ready to be filled. It is a huge SEO factor, not to mention some of the meta data is needed for valid HTML. This is non-negotiable. Tell your devs to fix it. Customer can still leave them empty if they decide to.
Next is the ability to use already uploaded media from the library as translation. Please do not act like this is something hard to do. It is just a matter of adding one link underneath the button that will call the Media Library selection screen instead of upload dialogue. With AI this thing is a piece of cake. The only part that might be slightly harder is mapping the output of the selection dialogue into the dialogue for image translation. Again, AI can help with that and you can implement it before lunch.
Speaking of AI. Have you been using AI to compose your replies? Those phrases like "I totally agree with you" and "I totally understand your frustration" sound exactly like Chat GPT.
And last but not least. Over the years I had many issues with WPML and I am nowhere closer to solve them. Hooks you provide are super clunky, documentation lacks any examples of usage, I usually end up coding some hacky custom code to force WPML to do what I want. Mostly with help of AI and people on coding forums.
This applies to WCML as well - that god forsaken, hell-born piece of code was the real headache for most of those 7 years. You know what your team did when I had my last contact about it with them? They ignored everything I said. It has been few months.
So please. To make me feel good about WPML start here.
- build more extensive documentation that has examples and use cases (from the tickets you accumulated over the years you must have truckloads of those)
- add more hooks where appropriate to solve issues your customers reported over the years and you just plainly ignored (forum used to be full of the unsolved tickets until you deleted them all to hide that ignorance)
- learn more about how pricing works around the world when you are selling software that should be able to turn your e-commerce site into multi-currency one (WCML devs are completely out of their minds and never seen any real e-commerce business, not even from a plane)
Have a nice day Alejandro.
I am looking forward to see the changes in WPML staff attitude towards customers. Not that I hope for it. I learned better over the years 😉
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Thanks for your honest feedback.
I'd love to send this info to our dev because it's always good to have the insights of who really uses the plugin so:
1) You say:
Even if the image in default language does not have it, every single image must have those fields visible and ready to be filled. It is a huge SEO factor
Here's the thing. we are a TRANSLATION plugin. translating means that there must be a source language with X content that needs to be translated into Y language so it has a "target" language, right?
How can you translate something that is empty? If SEO is a huge factor, how can it be a factor for one language and not another? and also what you mean seems more like localization where you want to have different structures according to the language (one language without say, an image's alt text, and another with it). in this case, you'd probably be able to do this manually only, since it's not a "translation" so a "translation" editor wouldn't work here. it's one of those rare cases where you could mix both translation methods, only because the metadata is actually handled in different tables than the standard content AND it doesn't exist in the translation editor so it can't be overwritten.
This is not a bug, so it's not something that needs to be "fixed", at most it's a feature that could be implemented (And with your answer on this I'll have all the means to create the feature request).
----------------
2) "Next is the ability to use already uploaded media from the library as translation". I never intended to mean that it's hard to do. it's just something that is not implemented currently. it's actually a pretty good feature request and this I have sent to our devs already 🙂
3) Can you tell me more about that WCML issue? you mentioned you had contacted a supporter. could it be this: https://wpml.org/forums/topic/wpml-wcml-breaks-the-shipping-class-based-shipping-cost-logic/ ? if so that case was escalated to our devs and I'm waiting on their team to understand what's the status. I'm also going to review the ticket to understand better what happened and how we could improve on the support front as well.
---------------
4)
build more extensive documentation that has examples and use cases (from the tickets you accumulated over the years you must have truckloads of those)
I totally agree with you on this and I believe our documentation team is working on something related to this.
5) When you mention the hooks, do you mean WCML hooks or WPML hooks, in general?
6) Noted about the Multicurrency but any input on this would be greatly received. Multicurrency is a particular feature that turned into a plugin kind of by "mistake". We never thought it would be that popular and the goal was just to "translate" the currency in a simple way (i.e: 500 USD > X Eur). it still doesn't have the attention it could have but we're getting there (we need to stabilize our performance first and fix a few longstanding bugs before digging into this one).
I'm really sorry you feel that way and I can clearly see you lost hope with us. I'm really going to fight internally to at least arrange a few things differently (As a deputy support manager I have some voice that has helped many clients over the years). it's not going to be a fast situation since we're already working in versions that will come 2 years from now, but I'll try to at least make some progress on the changes that would help you as much as I can).
Hi Alejandro,
I am sorry for the late reply, I am really busy and I really don't have time to deal with yet another WPML screw-up right now.
1. Empty or not, the fields should be always visible and active when it comes to image meta data. You are not translating strings there but meta data. NULL or empty is also a value. What you say is just a pathetic excuse for bad logic.
The mixup of two editors is your fault as well. You try to push this idea that WPML is a translation plugin but unfortunately some things need to be managed differently in each language and you are basically forcing something that does not make sense upon users. Let me choose what I want translated, copied, managed separately. You still miss the point of good UX.
2. I am pretty sure this will take time. Your devs are awfully slow when it comes to easily fixable things.
3. I can but it is complex. For starters. WCML only allows a currency to exist once. Which means if I wanted to have more EUR prices for different countries. Becasue, you know, the prices might differ for plethora of reasons, then you have to hack it. Literally. I had to programmatically insert fake currencies (AT, DE, SL, HR) and then in the frontend force Woocommerce to change its code to EUR so the invoicing works.
Another issue is that WCML stores all the prices in default language products. (So much for your translation plugin idea).
There is more. I don't have time to go through it. I already did and your devs just ignored it for months. So say hi to them for me. They suck.
4. You agree and you still do nothing about it. For years.
5. I mean hooks in general. And the whole logic of using them. You never ask customers what they want to use them for. You never cared about the scenarios where all of them fail. Your forum used to be full of people having issues with the idiocy of those hooks. You conveniently deleted most of those unsolved/unanswered questions so it does not look so bad. Again. Say hi to devs.
6. I already gave input on WCML and many other issues. So did the people whose tickets were massively deleted during the last few years. Your devs decided not to bother.
Want to do some change? Focus on customers for once.
Your pretend to care but I will never trust you again until I see some signs of effort.
So far, in 6-7 years I saw none. Devs were jerking around with stuff that we don't need and never asked for.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
1) by WordPress standard, Meta data can only exist if it's attached to a post type. in this case the post type is "media" and if the media doesn't exist in the translation, then its metadata can't exist either. this is something that won't change because it goes against the WP standards and a feature as the one you're mentioning could create very very big issues.
2) Please remember we are a plugin that serves millions of users, we have priorities when it comes to features, bugs, etc. and yes, it's true that the media features are super slow, but that's plainly because people hardly ever ask for them. having said this, I talked to our devs and turns out that the feature to select media from the library has just been scheduled to go to our WPML 4.10 version. I understand the frustration of not having features you'd like to have right away but there are many of them (thousands in feature requests alone) so it's plain impossible to be "fast" and being "easy" or "difficult" is just one factor in the process. but the feature will come for sure 🙂
3) Understood (and no, the devs didn't ignore you, there's a ticket from you about WCML where the devs are working in, it's already scheduled to be released in a future version, but it was stopped only because it required some compatibility measure from WC which will come but still hasn't been released, so we need to wait on them to securely release our part as well). I wish things were as simple as "we code, fix and that's it" but there are many clients using our plugin and we can't just deploy something without making sure we minimize the risk of a regression or a bug from it.
4) Again, it's not as simple as "go and do it", there are many many complications that I just can't go nor should go over here. anyways, on this I totally agree that we should improve this and it's up to the documentation team to improve it further. As I said, I know things are in the works because I was part of one tiny part of the changes that are about to come but I don't currently know any ETAs for it, but it's true that the dev documentation should be improved, for sure.
5) You keep saying we just don't care, we ignore you, etc. We go above and beyond our clients but it's not that simple, unfortunately. hooks have a way of messing things up if not done correctly and in the correct place and in many cases we need to follow the WP standards as much as we can, the same applies to WCML. that restricts us from creating hooks just because clients ask for them, the hooks were born initially for plugin authors, since they were the majority of users for them. if you have a specific request of a hook, you can let me know and I can forward it. it will NOT be a fast process, it requires a LOT of study to even think of implementing it, though.
I won't continue discussing things forward about things being ignored or the likes. that's not true but it's also not true that if someone asks for it, we'll go ahead and do it right away, we realistically can't do that, not for a commercially used plugin.
I have sent all your requests to the correct teams and many of them are actually already in the works so you'll see that as the plugin progresses you'll start seeing your suggestions as well as you could see that Media translation works totally different now from when you last used it 🙂
Hi there,
I believe my point is still being misunderstood.
1. You mentioned that metadata can exist only if it’s attached to a post type, and in this case the post type is “media.” However, when adding a translated media item—i.e., uploading a replacement image—the metadata of the original file is irrelevant. The translated media is its own post entry with its own metadata. Whether the original file has metadata or not should not impact the translation, as there is no WordPress requirement that forces such dependency.
2. This feature should have been part of the plugin from the beginning. It is simple to implement and would significantly improve usability. Unfortunately, many similar small improvements are repeatedly dismissed, even though they would greatly enhance the user experience.
3. Shifting the responsibility to WooCommerce is inaccurate. WooCommerce is well-documented, widely used, and highly extensible. Most issues can be addressed via hooks and filters. By contrast, WCML stores prices in a way that contradicts its own “translation plugin” philosophy, overlooks shipping in certain contexts, and offers hooks that are not practical for everyday use. These design choices create unnecessary complexity for users.
4. The lack of clear ETAs is a recurring problem. Good documentation is created alongside implementation, not postponed indefinitely. Additionally, the current hooks and functions are insufficient. Basic operations such as retrieving active currencies or languages are unnecessarily complicated. When requesting support, users are often redirected to paid “experts,” which is not an acceptable substitute for robust documentation and accessible functionality.
5. Finally, the claim of going “above and beyond” for customers does not reflect the experience many users including myself have had. Remember the hundreds of deleted threads in your forums? Those unsolved, dismissed, ignored ones?
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
1) yes, you're right but a "translation" requires a SOURCE and a TARGET, otherwise it's a "localization" (when target and source are handled separately, independently). we support media translation and to "translate" a media via the editor, you need to have content in the SOURCE media. if you want to only translate the translated media, then you'd have to do it directly from the media library or from the actual post where you want to have the media in only one language (the translated one). Is that not what you want to achieve (media metadata only on one of the languages and not on all of them, starting from the source language)?
2) I agree with you, I'm not 100% sure at this point why it wasn't released earlier but it's in the works now 🙂
3) I'm not shifting the responsibility, I'm merely stating a fact, we need something from them in order to release our part. WCML is a compatibility plugin, kind of like a "bridge" plugin which means that when we can we'll release everything on our end, but in some cases we can't. Anyways, Our compat dev told me that the shipping class situation you had, would be fixed in WCML 5.5.4 or 5.5.5 if any issue is encountered about this in the testing phase.
4) I totally get you here, we try not to give ETA's because things can change at the very last minute. it happens constantly in WordPress as well (we've had a few issues thanks to literally changes implemented even 1h before a release) so we try to avoid it because that will only make people even angrier. it sucks, I totally agree with you.
About the hooks, I sent this feedback to our devs. and yes, if you have to use the hooks in the first place, you're already writing custom coding which means we can't support that (It's not an excuse, though), but I get your point and after checking our current hooks for WCML I do see that we need to improve there.
5) About the deleted forum entries. the deleted entries are SOLELY the ones over 2 years old (Archived, with possibility of being unarchived) or 5 years old (completely deleted).
That was done because of 2 things:
- space, we had over 15 years of information on our database and it became quite expensive for mostly deprecated information to keep.
- deprecated solutions: a lot of people kept copying and pasting code that was already deprecated. then the site broke and they complained with us. we didn't want that either and it was not just a "few" people, there were a lot.
The "unsolved" ones, were either escalated to a ticket or checked if they were deprecated and closed.
-----------
Anyways, I truly understand your points and I understand why you feel this way. We have way more resources than we had before and our workflows have changed a lot aiming to improve, but please understand this is a mature product that has over 10 years of development on its back and there's nothing "easy" and "fast" when you have that type of product that on top of it is also used on millions of sites, some even from governments around the world.
That combo makes things slower sometimes, make some features to take ages to be developed or to be set aside, but the aim is to be easier to use, safer and stable, which is something we've been working hard to achieve. we're not perfect, for sure, but we are working hard to be as perfect as we can be.
