I notice that, since last update, an image that's translated in the Media Translation, when used in a page, then translated in the CTE won't be translated anymore. The original image is served instead of its translation in the translated page.
It appears that the issue persists in a minimal environment.
However, it took me some time, but I also noitced that the issue only seem to occur with SVG media files. SVG files, translated in the media translation, aren't translated anymore in the translated posts where they are added.
Removing, then reuploading the translation again, or uploading a new SVG file in orignal language then translate it, working on brand new content. Nothing works as long as we play with svg files.
However, it works like a charm with existing PNG medias and new ones.
I appreciate very much the detailed documentation you provided, including the problem and its solution. I'm consulting our second-tier supporters about this case, and will keep you updated here.
We are unsure of the steps to replicate the issue you describe. To investigate this issue, we created a sandbox site and added the Safe SVG plugin. This is because WordPress Media Library doesn't support SVG images. When trying to replicate the problem, we get mixed results. Sometimes it works when replacing an SVG image with the Media translation addon, and sometimes it does not.
Could you please provide the steps to reproduce the issue?
We have a sandbox site to test this issue. It would be awesome if you could help us and replicate this problem on it. Here is the direct access link.
We also use the Safe SVG plugin to upload our SVG media.
First, I think it would make sense to switch the editor from ATE/automatic translation to CTE, since that’s what we actually use. I’ll let you apply that configuration change.
I can now see the issue on the page you created, Itamar: hidden link
The image has a translated version in the Media Translation tool.
However, the original image is displayed on both the original and the translated pages.
On the other hand, I can see that the issue doesn’t occur on the other pages you created.
Unfortunately, I don’t know how you translated those pages and media files:
- Did you duplicate the pages before translating them, or did you translate them directly?
- Did you provide specific metadata for the translations?
- Did you upload the original image from the page itself, or from the media library?
- Did you upload the translated images after publishing the translated page?
From what I’ve observed on our website, an image used in a page wasn’t translated when the page was translated — even though the image was correctly translated in the Media Translation tool.
At first, I thought the issue was happening for all images. Only after many tests did I realize it only occurred with SVG files.
Once I managed to reproduce the issue in a minimal environment — first with one image, then with another, both in a native block and in a custom block using a native block — I assumed there was a bug specifically related to SVGs. I had already spent a significant amount of time investigating this, so I reported it to you and to my developer without digging further.
So I’m not aware of cases where the issue occurs or not under specific conditions. All I know is that some of my images stopped being translated, and without the fix, I can consistently reproduce the failure.
Still, I ran another test on your sandbox using the following steps:
1. I created a new page.
2. I uploaded the original media from the page into the media library and added metadata.
3. I published the original page: <URL>
4. I uploaded a translated image and manually translated its metadata.
5. I translated the page; the metadata appeared translated, and the page was already fully translated even though I hadn’t set its title.
6. I saved everything.
Resutl: The page title and slug are translated (I suppose thanks to automated translation), but the image isn't: hidden link
Did you take a look at the README?
It seems to provide relevant explanations of what’s going on, and suggests that the causes of the image translation failure are multiple.
When I don’t know which specific steps lead to a translated SVG or to the original one, these explanations probably help answer that question.
The difficulty in reproducing the bug through a user scenario (“click by click”) likely comes from the fact that the problem is structural within the code and related to the nature of SVG files.
The issue is not how we create the content, but the fact that your code attempts to handle SVGs as raster images (JPG/PNG) without first checking their format.
Here are the specific technical causes (based on our code analysis):
Missing dimensions: Your code checks for or requires width and height. However, many valid SVGs do not expose these attributes the same way raster images do, or rely solely on a viewBox.
Missing thumbnails: Your logic appears to iterate over image sizes (thumbnails). WordPress does not generate physical size variants for SVGs. As a result, when the code attempts to access size arrays for an SVG, it fails.
Missing safety check: There is no condition such as if (mime_type === 'image/svg+xml') { return; } (or appropriate handling) before executing the standard image resizing/verification logic.
We feel there is no need to reproduce the bug “visually”; what’s important is to secure the code so it doesn’t fail when the width, height, or sizes properties are missing or null.
Overall, the issue we’re seeing seems to come from the fact that SVG handling is still a bit incomplete. There are situations where the code processes SVGs as standard images, which naturally leads to unexpected behavior — especially regarding size management.
In addition to this, our analysis also highlights four further points, related more specifically to block handling, which would benefit from some adjustments to ensure fully robust functionality.
The code fixes provided are a mix of AI assistance and human brain juice, but they should address the issues we’re encountering.
Another specific issue I noticed, is that the CSS class wp-image-ID don't seem to translate properly, wathever the media format.
I did a test on your sandbox:
1. I uploaded 2 images (png and webp)
2. I created a page and added these images + the svg one: hidden link
3. I translated the page
4. I displayed the translated page. No images were translated: of course, neither the png and the webp since I didn't upload a translation yet, and not the svg.
5. I translated the new images by uploading a french version for each of them, from the media translation
6. I check that both were displaying on the french page >> That was the case
7. I opened the page for individual edition, and noticed that both the png and webp images were broken (attempt recovery). I checked the HTML, and it appears that the images had no CSS class at all, while I already had checked that the original ones did. Then I purposely did not save the page.
8. From the media library (I didn't close that thumbnail), I clicked to option at the top of the page to update the page where the uploaded images were added.
9. I checked that nothing had changed on the frontend
10. I reloaded the admin page : both image were still the the Attempt Recovery state, but now had a class="wp-image-0" (yes, zero), when to my understanding, they should get the translated media ID.
11. Try playing with the media size, and it will break the translation.
I feel this test is pretty basic, but obviously, something already goes wrong here.
