I did notice that sometimes (and it's not so rare...), image translated are broken in the media translation, or in the front end or in the media library.
Taking a closer look a it, it's because in the paths of the translated images, sometimes the filename is right, but the path is the original one instead of the translted file's one. Or the other way around.
For example, if I upload an original language image on 2025-05, with image-english.png as filename its path is:
/2025-05/image-english.png.,
And its french translation as image-francais.png on the 2026-01, then the path is:
/2026-01-image-francais.png
Both the original and french files are reachable with these paths, and that's the path displayed in the media translation.
BUT then, in the media translation, once the page is updated, the french image is broken because it's pasth is: 2025-05/image-francais.png, or 2026-01/image-english.png.
In both case, of course, the media won't be reachable because the folder **or** the fileamame is the original's one.
Since the image is broken only in WPML Media translation, and not the library, I assume that's a WPML bug.
Finally, these broken images are also broken for the same reason in the content translation.
Best part is: in such case, there's no way to reupload the file - It'll remain broken, whatever I re-upload. The only solution that seems to work is reuploading the original images in the original language. The the metas, then reupload ALL the translated medias, and ALL their meta. It takes ages.
Enclose, it's just a sample, but I have many images in that case.
From your description it is difficult to determine the exact cause. At the moment we do not have similar open bug reports related to this behavior, so it is possible that the issue is caused by some third-party plugin (for example an image optimization plugin, CDN integration, or similar tool that modifies image paths).
Could you please clarify if there are specific steps that consistently trigger the issue? For example:
- when translating images via WPML → Media Translation
- after editing/updating a page
or after syncing media
Clear reproduction steps would help us investigate this further.
If possible, it would also be helpful to test in a minimal environment (for example on a staging site with only WPML and required plugins active) to see if the issue still occurs.
This can help confirm whether the behavior is caused by WPML or by interaction with another plugin or custom code.
Hi,
We're using Offload Media. But no other media related plugins.
We used to work with ShortPixel but it's not involved anymore, and for sure wasn't involved on the upload of some of the images I encounter issues with.
When the URLs are wrong, the Offload Media "timestamp" subfolder of the path is always right when the filename is translated. In other terms: the timestamps always corresponds to the actual folder of the translated file on the bucket. The only thing wrong it the year/month path, which is the original file's path.
When Offload media is disabled, the error still occurs.
Plus the issue also occurs on other dev environments where Offload Media is disabled.
So it's probably not the culprit.
Now... back to were I was. I was able to complete the stuck media update process after enabling "Automatically detect best options for translating image text" (suggestion by your AI, though I doubt it has anything related with that issue), by deactivating Elementor and Elementor Pro (I already encountered this issue in the pas so was able to fix it). But it didn't solve the issue.
Then , I deactivated all plugins except WPML Multilingual CMS and WPML Media Translation, and switched to storefront standart theme.
It didn't solve anything either: the same image are still broking with the same wrong path.
I can't say what exact process leads to the issue. One thing that I think of is that maybe, it occurs on some translations only when the original file is uploaded through the media library, when called from a content page, instead of loading it straight from the admin menu > Media Library.
Thank you for the additional testing. This is very helpful.
Since the issue still happens even with only WPML Multilingual CMS and WPML Media Translation active and with a default theme, it seems less likely that this is caused by Offload Media or another third-party plugin.
At this point, I would like to investigate this further on a staging site.
Could you please share access to a staging site where the issue can be reproduced.
If the staging site is protected, please also provide the login details using the private reply fields.
This will help me test further and determine exactly where the wrong media path is being generated.
Since I’ve been encountering this issue for a while, I decided to dig into it myself and used Cursor AI to review the code against a few scenarios I suspected might trigger the problem.
I believe the findings might worth take a look.
The error seems to occur when :
1. I first duplicate a media item in the media translation (and optionally translate its metadata),
2. Later on, on a different month, I upload another image for translation. This results in a new path for this specific media translation, which might replace the original one, or the other way around.
This is explained in detail in a (rather extensive, sorry) .md file describing:
- the scenarios I asked the AI to analyze,
- where the issue seems to originate,
- possible fixes
- a way to repair already broken paths in existing content
- Ideas to correct the existing code responsible for this issue.
I didn’t go any further, since it wouldn’t really make sense for me to modify your plugin directly.
The document also explains how this explanation remains compatible with the fact that images uploaded via Media Translation, which appear broken in the media translation view and within content translated using the WPML Translation Editor, still work correctly when accessed from the Media Library, then when added within individually translated content.
Finally, it notes that other plugins might worsen the situation if they also mishandle attachment data later on, though it emphasizes that the root cause seems to originate in WPML.
Thank you for taking the time to investigate this and for sharing the document. I really appreciate the effort you put into analyzing the possible scenarios and documenting your findings this is very helpful.
However, in order for us to properly review this and escalate it to our 2nd tier or development team, we still need a reproducible case where we can actually observe and debug the issue. Without being able to reproduce the problem, it is very difficult for us to confirm the root cause or safely implement a fix.
At the moment, I tried reproducing the scenario on a clean test installation, but the issue did not occur by default, which means we first need to confirm the exact conditions under which it happens.
Could you please provide one of the following so we can investigate further?
• access to a staging site where the issue can be reproduced
• a copy of the site (for example a Duplicator package)
• or we can provide you with a test site and try to reproduce the issue there together, but I already tried and issue is not there by default
This will allow us to verify your findings, debug the behavior directly, and confirm whether the issue is related to WPML itself or possibly influenced by the specific environment, configuration, or other plugins.
Once we have a reproducible example, we will be able to confirm, escalate it properly and work toward a fix.
Hi Dražen,
I've been testing further, and there's definitely scenarios where things go wrong. Where paths won't propagate properly.
But even if I show you some constitent errors, I know you'll ask me to reproduce in a vanilla environment.
So instead of showing you what's wrong on our website, how about you provide me with a clean WordPress / WPML setup where I try to make the issue happen?
Hi,
On the sandbox:
- I just enabled WPML + String Translation + Medias +
- updated WordPress from 6.9.1 to 6.9.4
- went through the WPML wizard to add languages
Now I'm asked for a site key...
As already explained, the issues seems related with the path update.
So here is what I did:
1. Upload an image en English:
2. Install Enable media replace to be able to change the original date (since the issues seems related to datedfolders)
nb: this plugin is installed on our website, but I never use it when images are already translated. Here, I just take advantage of it to be able to "simulate" the upload of translations on a different month
3. From Media Translation, I duplicated this image in French (no specific image), and added a specific image in Spanish
At this step, everything is fine.
4. I replaced the image with an other one, with another filename: test-content-image1us-new-file.jpg
Media Library > Edit image > Upload a new file > Set a Custom date (3 Feb 26 + Ticked "place the newly uploaded file in this folder" > 2026/02
5. Moved back to the Media Library: result attached ((screenshot case 1)
The Original image is fine: it has the new path and file name.
/wp-content/uploads/2026/02/test-content-image1us-new-file-300x300.jpg
The Spanish image is still fine... orignal path + filename: /wp-content/uploads/2026/03/test-content-image-1-es-150x150.jpg
The french one, however, is broken.
And this is because its path is: /wp-content/uploads/2026/02/test-content-image1us-150x150.jpg
The path was updated along the new original file, but not the filename.
Just in case I cleared the WPML cache + Clean/Optimize String Tables + Browser cache of course >> Same results.
===
So this is a case where the duplicated images get broken because the path is updated, but the filename isn't. But therer or other variants of this kind of issues.
The case I encounter the most being when:
1. I upload an image in the orginal language
2. Duplicate it to use it from another language
3. Months later, I upload an alternative image for a translated language, in this translated language, which will be broken because the path is the new one, but the filename is the orignal image's filename... (screenshot case 2)
The timestamp is due to offload media, but I checked multiple time, this one is always the one associated with the path, so doesn't seem involde in these issues
I couldn't replicate that case on your sandbox for now.
