A few years ago I was reviewing conversion data for a product I work on and noticed something odd. We were getting decent traffic from French-speaking customers, but the purchase rate was lower than for English speakers, even though the two versions of the product were identical. The prices were the same. The only difference was the language experience.
We dug in and found that many of the images, the ones that actually showed how the product worked, the infographics, the size charts, were in English. The title had been translated. The bullet points had been translated. But the images, which often carried the most product-critical information, were entirely invisible to a customer who couldn't understand English. We had translated the words and left the meaning behind.
That experience reshaped how I think about multilingual product strategy, and it's what I want to talk about here. As Product Managers, we treat localisation as a feature: ship a language toggle, run a translation pipeline, call it done. But language in a product is not a feature. It's infrastructure. And most of the time, we've only built about 20% of it before calling it done.
Translation is not localisation
Translation converts words from one language to another; localisation converts meaning. Those are different problems, and conflating them is the source of most multilingual product failures I've seen. LLMs are genuinely good at translation. But translation alone misses several layers of the problem: text embedded in images like sizing guides and product labels, cultural context that makes copy land with one audience and fall flat with another, and post-purchase touchpoints like documentation and packaging that shape whether a customer trusts the product they just bought. Each of these has its own technical constraints. They're also not edge cases, but the parts of localisation that actually determine whether a non-English-speaking customer converts and keeps coming back.
The image problem nobody talks about
Product images with superimposed text are one of the most underappreciated problems in multilingual e-commerce. Think about how many products you've bought where it was the image that actually convinced you because it showed the dimensions, explained the installation, and compared the size options.
Now imagine that image is entirely in a language you can't read. This is the reality for the vast majority of non-English-speaking customers on most major platforms. The page title and description might be translated. But the image, which often communicates detailed technical information about the product, stays in English.
Solving this is a genuinely hard AI problem because you're not just translating text. You're also detecting where text sits within an image, extracting it without losing context, translating it while preserving product-specific terminology, in-painting the original text out cleanly, and re-rendering the translated version so it maintains the original design. That requires a pipeline of multiple models in sequence, each with quality thresholds and an automated QA layer for when the pipeline goes wrong.
Off-the-shelf solutions fail in meaningful ways by losing document formatting, mishandling brand logos or degrading image quality. But it's solvable. And once you've built the infrastructure, you can deploy it across your entire catalog, including the long tail of existing products that have sat with untranslated images for years.
Localisation goes beyond images
Images are the most visible localisation gap, but they're not the only ones. Videos, marketing copy, and post-purchase content all carry the same translated-words-not-meaning problem, each for a different reason. Videos are hard because the text lives in several places at once, captions, on-screen graphics, sometimes the audio itself, and captioning alone doesn't fix instructional text that's baked into the frame; each layer needs its own treatment. Post-purchase content, documentation and packaging inserts, is hard because it's dense and follow customized formatting to meet industry mandates; off-the-shelf LLMs hallucinate on regulatory language they haven't been trained on, so the pipeline needs domain-specific grounding and a quality check independent of the translation model itself.
The clearest example, and the one that changed how I think about this space, was marketing copy. The assumption going in was that once translation quality was high enough, the language gap would close on its own. We tested that assumption directly: manually crafted push notifications written with genuine cultural nuance for US Hispanic audiences outperformed standard translated copy by over 200 basis points in click-through rate. The translated version wasn't wrong. The Spanish was accurate, the grammar was clean. It just didn't sound like it was written for the reader by appealing to what factor (price, speed, nostalgia, etc.) matters most to them when making a purchase. That gap came entirely from intent, not vocabulary, and no amount of translation quality improvement would have closed it. The content needed to be generated with cultural context from the start, not retrofitted from an English original.
What good multilingual AI infrastructure actually looks like
The diagram above shows what a mature localisation pipeline looks like in practice: AI handles the first pass at scale, automated quality checks flag issues before human review, and a feedback loop tightens the system over time. Getting to that state takes real investment.
A few things I've learned building towards it.
- First, plan for the quality gap between languages. AI translation quality is not uniform. High-resource languages like Spanish, French, and German have large training corpora and generally produce reliable output. Lower-resource languages are a different story. You need a quality evaluation framework that's language-specific, not just aggregate. A single accuracy number across all your supported languages will hide problems that matter enormously in specific markets.
- Second, build your evaluation criteria before you pick your models. Teams often choose a translation model, run spot checks, and ship. The model that does well on general text may do poorly on product-specific terminology or culturally sensitive copy. You need test sets that reflect the actual distribution of content you're translating, built with native speakers who also understand the domain, not just the language.
- Third, treat each localisation problem as its own pipeline. Images, video, and marketing copy each have different failure modes and QA requirements. A modular architecture where each pipeline improves independently, while sharing common infrastructure, is far more maintainable than trying to solve everything with one system.
- Lastly, localisation has a long tail. You will launch, feel good about your coverage numbers, and then discover six months later that a new product category has different terminology problems, or that a meaningful percentage of your catalog still has gaps. Multilingual infrastructure requires ongoing investment. The teams that treat it as a product, with a roadmap and dedicated ownership, do significantly better than the teams that treat it as a project.
Why this matters more now than it did two years ago
The agentic AI shift makes all of this more urgent. As AI agents begin to mediate more of the discovery and evaluation journey, the information those agents work from has to be accurate and complete in every language your users speak. An agent helping a Spanish-speaking customer evaluate a product will read the product page in Spanish. If that page is incomplete, the agent will either make a poorer recommendation or skip it entirely.
Language is becoming a discoverability signal, not just a UX signal. Products and services that aren't properly localised won't just lose users directly. They'll also lose the AI intermediaries increasingly deciding what gets surfaced at all.
The good news is that AI has finally made genuinely comprehensive multilingual coverage technically tractable. The bad news is that most teams are still treating localisation as a translation feature rather than as the foundation it needs to be. The gap between those two approaches is where the next generation of global product advantages will be built.
