Localization was never just a tooling problem

The other day, I received an email with a proposal for a new AI tool. The message was polished and confident. According to the pitch, this software could solve all the localization problems I might have. Speed, quality, scale, consistency, everything, covered.

I didn’t delete it. I didn’t reply either. I just paused for a moment. Because it made me reflect on something I’ve seen many times over the years.

Let me be clear from the start: tools matter. A lot. You need a solid localization tech stack before you can go anywhere. Systems that help manage content, automate workflows, ensure consistency, handle volume, control quality, and scale across languages are essential. Without them, everything becomes slower, more expensive, and harder to control.

We are lucky to live in a time where there are LSPs fully dedicated to building localization tools, and many of them are incredibly talented. The tools we have today are very powerful. Sometimes I think about how different things were when I used my first tool to report bugs back in the 90s (Microsoft RAID 4.1, for the curious geeks reading this), and comparing that with the technology we have today in localization honestly feels incredible.

And yet, despite all those changes, something fundamental about the ingredients that define good localization hasn't changed. Keep reading, I’ll share more about that in the next paragraphs.

 AI is a powerful addition to that stack. It brings speed, reduces manual effort, and makes things possible that were unrealistic not that long ago.

So yes, good tools are a must.

 But once those foundations are in place, once your typical localization needs are covered, something interesting happens.

 When you can already translate at scale, reuse content, manage terminology, automate reviews, and ship faster, the remaining challenges usually don’t look technical anymore.

 They look human.

Looking back, the hardest localization problems I’ve seen were rarely about missing features or insufficient automation.

 They showed up earlier, in decisions about what to localize, how far to adapt, and who the product was really built for.

 I’ve been in many conversations where the focus naturally moved toward a practical question: “How fast can we translate this?” It’s a reasonable starting point, what required more attention was a deeper discussion of whether the product or content had been designed with more than one market in mind, because that would affect delivery timing and, more broadly, how it would be interpreted by users with different expectations, habits, and cultural references.

When something later felt off, localization was often where those issues surfaced, even though their origin was much earlier. How fast we can translate is rarely the main problem to solve

This is also where it helps to be realistic about what tools can and cannot do.

 AI and modern localization platforms are excellent at execution. They handle speed, volume, consistency, and workflow complexity extremely well. They reduce friction and give teams control.

 Honestly, it’s great to have all these tools nowadays. When I compare them with how things worked in my early days, the difference is huge. They allow us, fellow localization professionals, to focus on what we do best.

 What they don’t do on their own is decide what is appropriate for a specific market, sense cultural risk, or recognize when something that is technically correct still feels wrong.

Balancing global consistency with local relevance still requires judgment. I often think about this from the perspective of localization teams themselves. Many teams are under real pressure to keep investing in new tools. Faster delivery, lower costs, more automation, more AI. Those expectations are understandable, and tools do help teams deliver on them.

 At the same time, I’ve seen teams reach a point where tooling is no longer the bottleneck. The basics are covered: translation flows, quality is stable, automation works, and tools are already part of the process.

 And yet, the same questions keep coming back.

 Why does this market underperform?

Why do users struggle to trust the product?

Why does the customer experience still feel foreign?

At that stage, adding another tool rarely answers those questions.

What often helps more is making space for conversations that don’t fit neatly into a platform.

How well do we understand local customers?

Where are we taking cultural risks without realizing it?

And where does ownership of the international customer experience really sit?

 Those conversations don’t replace tools. They come after the tools are already doing their job.

View fullsize

Click HERE to download the infographic

That’s why I don’t really see localization as a tooling problem anymore. Once the tools are in place, the real work shifts to how strong a team is in a few specific areas.

Trust.

Cultural relevance.

Human judgment.

Customer understanding.

 Final thoughts

Over the last thirty years, our industry has adopted many “game-changing” tools. Translation memories, terminology systems, automation, neural machine translation, and now AI. Each one raised the bar for execution, and each one delivered real value.

 But none of them removed the need to understand customers, markets, and context.

AI fits naturally into that same evolution. It strengthens execution. It accelerates decisions. It amplifies direction.

But it doesn’t automatically strengthen trust, cultural relevance, human judgment, or customer understanding. When I think about the future of localization, this is what stays constant for me.

 Build a strong tool stack. Invest in the technology. Use it fully.

 And then focus on the parts that tools have never owned: understanding people, making informed trade-offs, and designing experiences that feel local by default. Maybe that’s what is truly permanent in localization, even in the age of AI.

 What else would you add to that list?