Images on a Multilingual Site: What to Translate and What to Leave Alone
Alt text is content and needs translating. Filenames mostly do not. The image itself sometimes should be a different image entirely. A practical split for sites running two or twenty locales, plus the sitemap rule that trips everyone.
A site gets localised into four languages. The translation workflow exports every visible string, sends it out, receives it back, and rebuilds the pages. Everything reads correctly.
Then someone using a screen reader on the German site hears every image described in English, because alt text lives in an attribute and the export picked up text nodes.
This is the characteristic multilingual image failure: not a wrong decision, but a category of content that fell outside the process. Images sit awkwardly between assets and content, and different parts of them belong on different sides of that line.
The split
The useful question for each property of an image is whether it is content that a reader consumes or plumbing that identifies a file.
| Property | Translate? | Reason |
|---|---|---|
| Alt text | Always | Content, and an accessibility requirement |
| Caption | Always | Content, and more visible than alt text |
| Title attribute, where used | Yes | Content, though rarely worth using at all |
| Surrounding body text | Already in scope | Contributes most of the image's context |
| Filename | Usually not | Plumbing, and duplicating files is expensive |
| Folder path | No | Plumbing |
| Embedded metadata | Optional | Rarely consumed by readers |
| Structured data fields | Where user-facing | Descriptions yes, URLs no |
| The image itself | Sometimes | Depends entirely on content |
The two rows worth arguing about are filenames and the image itself.
Why not to translate filenames
It is tempting. If a descriptive filename helps in English, surely a German filename helps in German.
The problem is that a filename is an identifier. Translating it means five files where there was one identical image, five cache entries, five sitemap lines, and five things to update the next time that image changes. Multiply across a library and you have created a substantial maintenance burden for a marginal benefit.
The benefit is marginal because the filename is a modest signal that operates alongside much stronger ones. When the alt text, headings, body copy and page title are all correctly localised, an English filename is not what holds the page back. What filenames actually contribute relative to other signals is worth being realistic about before building a translation pipeline for them.
The exception is an image that genuinely differs per locale. Then it is a different image and naturally gets a different name, which is correct for reasons that have nothing to do with translation. Consistency there matters more than language, and a naming convention that encodes locale as a token handles this cleanly: storefront-exterior-de.webp rather than a fully translated string.
When the image should actually change
This is the decision that gets least attention and matters most, because a wrong image is worse than an untranslated caption.
Swap the image where it contains something locale-specific:
- Text in the picture. Signage, labels, packaging copy, interface screenshots. Text baked into an image is untranslatable without a new file, which is the strongest argument for avoiding it in the first place.
- Things that differ physically. Vehicles on the wrong side of the road, plug sockets, road signs, currency, paper sizes. These are small details that local visitors notice instantly.
- Things that differ legally or by convention. Safety equipment, uniforms, professional dress, and anything subject to local regulation.
- Interfaces. A screenshot of your own product in English on a Spanish page is only acceptable if the product is English-only. If it is localised, the screenshot should be too, which is a real cost worth planning for — and screenshots are their own category of image with their own requirements before locale even enters the picture.
Keep the image where it is genuinely neutral, which is most of the time. Tools, materials, textures, abstract scenes, close work without text or people. The instinct to localise everything wastes budget on images nobody would identify as foreign.
Where a set does need per-locale variants, producing them is the same batching problem as any other multi-page image set. Running a bulk image batch as a defined workflow applies directly, with locale as one more dimension alongside subject.
Where localised sets go wrong
Two failures recur.
Near-identical variants. A site generates one variant per locale of an image that did not need varying, and now carries five almost-identical files. That is the duplicate and near-duplicate image problem created deliberately, and the fix is upstream: only vary images that have a reason to vary.
Style drift between locales. Variants get produced at different times by different people, and the German site slowly diverges visually from the French one. A fixed style specification applied across all locales prevents this, in the same way a consistent style clause holds a generated library together. The look should be a property of the brand, not of which market's images were commissioned last.
Sitemaps and hreflang
Two mechanical points that trip people regularly.
Hreflang does not apply to images. It annotates pages. There is no image equivalent and attempting to construct one is a misunderstanding of what the annotation does. Localised pages get hreflang; the images those pages display are simply the images those pages display.
Image sitemap entries sit under the page that shows them. If one shared image appears on five localised pages, it should be listed under all five page entries. This feels like duplication and is not, because the image genuinely appears on all five. The common mistake is listing images only under default-language pages, which leaves every other locale's images unlisted. How image sitemaps are actually structured covers the mechanics, and the multilingual case is the one where the page-centric structure is least intuitive.
Geo signals across markets
For a site serving several countries rather than several languages, coordinates embedded in images are sometimes proposed as a localisation signal.
Be careful with the reasoning. Coordinates are a claim about where an image belongs, not about which market a page targets. Tagging every image on the French site with a Paris location because the site is French is a fabricated claim about files that may depict nothing in France.
Where an image genuinely depicts a place you operate, coordinates are accurate and cost nothing to include. What geo-tagged images realistically do for local visibility is an honest look at how much that is worth, which is less than commonly claimed but not nothing. Whether it survives your pipeline is a separate question, since metadata is stripped by many upload and optimisation steps regardless of how carefully it was written, and what EXIF fields contribute generally is worth calibrating before building a per-market tagging strategy on top of them.
Right-to-left layouts
Arabic, Hebrew, Persian and Urdu locales introduce a problem that has nothing to do with alt text and is easy to overlook until someone points at a page.
Images that carry directional meaning read backwards in a mirrored layout. A process diagram flowing left to right implies a sequence that is now reversed against the reading order. A photograph composed with the subject looking or moving toward the right, placed beside text, now points away from the content rather than into it. Arrows, timelines, before-and-after pairs and numbered sequences all have this property.
The handling differs by type:
- Diagrams and process graphics: produce a mirrored variant. This is a genuine locale-specific image, named accordingly, and the effort is real but unavoidable. Text inside them has to be re-laid out, not flipped, which is another argument for SVG over raster.
- Photographs: usually leave them alone. Mirroring a photograph produces subtle wrongness — writing on clothing, asymmetric equipment, the hand someone works with. Composition direction matters less than the artefacts introduced by flipping.
- Icons with direction: use the locale's own set. Most icon libraries ship RTL variants for arrows and chevrons, and hand-mirroring individual glyphs produces inconsistency.
The same caution applies to any image whose composition assumes text sits on a particular side. A hero with the subject weighted right and copy overlaid left becomes a hero with the subject behind the copy once the layout mirrors.
None of this is difficult, but it belongs in the localisation plan rather than being discovered during review, because the fix is new artwork rather than a string change.
A workable process
- Put alt text and captions in the translation scope explicitly. Not implicitly. Check the export actually contains them, because attribute content is the standard omission.
- Classify each image once: neutral or locale-specific. Most are neutral. Record the decision so it is not relitigated per locale.
- Keep one filename for shared images. Add a locale token only for genuine variants.
- Produce variants as a batch with a fixed style spec. Not per market, per quarter, by whoever was available.
- List images under every page that displays them. In every locale's sitemap.
- Audit once after launch. A crawl of each locale checking for untranslated alt attributes takes an afternoon and reliably finds several.
The overall principle is that images carry less language than people assume and more culture than people expect. Most of a library travels between markets untouched; the parts that do not are usually identifiable in advance by asking whether a local visitor would find the picture accurate.
Where new locale-specific imagery is needed, generating it means the same subject can be produced under a consistent style with locale-appropriate details, with filenames and metadata written at creation rather than in a separate pass per market. See how SEOpix handles that, or start with ten free images.
Frequently asked questions
Should alt text be translated for each language version?+
Yes, always. Alt text is page content in the same sense as a caption or a heading, and leaving it in the source language means screen reader users on every other locale hear a foreign sentence. It is one of the most commonly missed items when a site is localised, usually because the translation workflow exports visible text and not attributes.
Do image filenames need to be translated?+
Usually not, and translating them creates more problems than it solves. Separate filenames per language means separate files for identical images, multiplying storage and cache entries and complicating every future replacement. A descriptive English filename is not a ranking disadvantage in another language when the surrounding page is fully localised.
Should the same image be used across all language versions?+
Use the same image where it is neutral and a different one where the content is culturally or legally specific. A photograph of a hand tool travels anywhere. An image containing text, a right-hand-drive vehicle, region-specific signage or a local payment method may be wrong or confusing in another market. The test is whether a local visitor would find it accurate.
How does hreflang relate to images?+
It does not apply to images directly, since hreflang annotates pages rather than assets. What matters is that each localised page references the image version intended for it and that the pages themselves are correctly annotated. Trying to apply hreflang logic to image files is a category error.
Should images appear in the sitemap for every language version?+
Image entries belong with the page entry that displays them, so if a shared image appears on five localised pages it should be listed under each of those page entries. This is not duplication in the sense that causes problems, because the image is genuinely displayed on all five. The mistake is listing images only under the default-language pages.
Does translating alt text help image search in other languages?+
It is a reasonable contributor, since alt text is one of the signals used to understand an image and a query in another language needs matching text in that language somewhere. The surrounding page content matters more. Translating alt text is worth doing primarily for accessibility, with any search benefit as a secondary reason.
What about text baked into an image?+
Avoid it wherever possible, because text inside an image cannot be translated without producing a separate file per language and cannot be read by anything parsing the page. Where a diagram genuinely needs labels, SVG lets the text remain real text, which at least keeps it selectable and editable rather than requiring a re-export per locale.
Should the caption be translated as well as the alt text?+
Yes, and captions are actually more visible than alt text, so an untranslated one is more obviously wrong. Captions are read by far more people than alt text is, which makes them a higher priority in practice even though they get less attention in optimisation advice.
Let SEOpix handle the metadata
Filenames, alt text, EXIF fields and GPS coordinates written automatically as each image is generated. Start with 10 free images a month — no credit card required.
