[Waiting for user feedback] Wrong Media Translation path

Hi,
Thanks for this feedback.

I understand what you suggest. Unfortunately, Enable Image Replace can't be the origin of the errors I encounter. As already explained, we don't use EIR on our website to replace such images. I used EMR here, only to **simulate** a time gap between the upload of the original image and its translation replacement image.

Still, I gave a try to your method: running Regnerate Thumbnail to fix the broken images that correspond to this scenario, on our website.

Most of them are SVGs, on which this plugin won't do anything since there are no thumbnails for vectorial images. So that's just not a solution for this case.
So I identified another broken image, a webp file, that has only one specific translation broken (I'll explain below the "history" of this file).

Clicking "Regenerate thumbnails" from this broken translated image in the Media Library, first offered to regenate over 500 images it found as having broken thumbnails. I ran it, and it didn't list, nor fixed the one I tracked.
And on the second attempt, it basically says:
"ERROR: The full-size image is not present in your uploads directory: {translated-image-upload-folder}/{translated-image-filename}.webp. Without it, new thumbnail images cannot be generated."

This process was tested on an local env, with all plugins up to date, without the Offload Media plugin enabled.

To sum it up, while I understand what you offered, I can affirm EIR is not the origin of the issue I face, since we basically don't use this plugin (or only on different cases, where images aren't already translated, nor offloaded - off-topic).
And I checked that processing **our** broken images with it won't fix it, not even on non-SVG files. So while this solution might fix some cases, it doens't fix ours.

Anyway, I had a closer thought to the case I identified.

This image was uploaded 2025/09, and translated to some other languages straight away Those worked fine after upload, and still work fine today.
The original image was used in an orignal content, content that was then translate to 3 other langages, both as duplicated, and with proper alternative image files, depending on the language.
When this content was later translated to one further language (Italian, through XLIFF) I didn't already provide an new file for this image in the new language at the time, so the orignal image was copied over and used as the image for this new translation . So that the image:
- appeared as copied in WPML Media Translation,
- was available from the frontend in the translated content

But once I provided, couple of months after, a new translation image file for this language (so new folder date + new filename), its path was saved as {new folder date} + {original filename}.webp.
So that, it's broken in the content, in the media library, in the media translation. For all size (original + thumbnails).
I try to re-save the image from the library: it didn't change anything.

So this case is different from what your solution aims to fix (where only the thumbnails are broken).

The issue I face, could be that, when an image, that's first been automatically duplicated in a new language during a page's translation process, is then replaced by another image provided through the Media Translation tool, then its path is updated, but not the filename.

So I uploaded new test images to your sandbox, in jpg and webp, to test if the issue occurs:
- specifically with the webp format
- when the content is translated on the same date, then the image alternative provided afterwards, on a different month.
The process is explained it the original pages (English).
Thanks for not touching those pages / images for now.

I hope this explanation, and tests, make sense to you.

Best Regards,

Hi Dražen,

I have some good news.

As planed, I tried, on the sandbox, from the Media Translation panel , to upload an alternative image instead of a copied one (pen mode), to check if it ends up broken.
Result: I had no issue here, the image works fine, and is uploaded to the current date path, not the original file path.

Then I did mutliple tests on different environments of ours, and finally found a consistant culprit: Offload Media.

This issue occurs, again, on an image that's been declined earlier (pen symbol in Media Translation, NOT "+", whatever the date), but for which I upload an alternative image on a different month.

After uploading the image > Validate > Reload the Media translation page :
- With Offload Media >> The image is broken in the Media Translation, with a wrong date path / right filename
- Now if I disable Offload Media >> The image is back in the Media Translation

That's consistent with 3 images.
And there's no issue when I upload an alternative image for an image that wasn't already declined in the target language, with or without offload media enabled.

Now if I have a look at the translated file path, from the Media Library, in the translated language:
- The server image is on the new year/month path (2026/04/ - I can see if by disabling Offload Media)
- The Offloaded Media displayed is... the orignal file! The filename displayed in the screen is the translated one (-fr), but the actual thumbnail file (from the list), and the actual file (from the media page, is basically the offloaded original image.
- However, for a media that wasn't declined earlier, it's the right file that's displayed in the library.

Finally, if I upload the alternative image from the Media Translation, while Offload Media is disabled >> The image works straight away... And will appear broken as soon as I re-enable Offload Media. So having Offload Media enabled or disable during the upload doesn't change anything

I also tested it against W3 Total Cache as well, in case it was involved, and doing the process with and without it enabled didn't change the result.

This was teste with previous versions for WPML and Offload Media, since I don't have a CDN capable environment with plugins up to date for now.

Is this consistent enough?

We could test it again on a clean environment, but this would require an offload media setup.

Hi,

I'd be happy to test it, but I won't be able to create a test bucket before a week at least