Modernizing Software Localization is an Engineering Problem, Not Translation

A software firm releases a product. The English version is released on time. Two weeks later, the Japanese version follows. The German version, four weeks later. At the time of Korean and Brazilian Portuguese releases, the engineering team had already begun the next release. During this gap, the company has already spent a couple of million dollars.

If you want to know where the cost goes, then ask the localization team. They will tell you about translation - translators, localization service providers, cost per word, project managers working across 30 languages and 20 products, and a hundred contractors. You heard the correct answer. It is also the wrong answer to the wrong question, because the matter is not what the LSP invoice says. It is what the rest of the localization budget - the part the LSP does not bill for - is paying for.
I believe there is a “framing problem” in the localization industry and an “evidence problem” among the engineering leaders who are paying for localization. Both problems lead to the same solution.

What the industry will not show you on a budget line

The tale of the localization industry's cost structure is written in its own words. If you read any LSP's published guide to localization costs, you will find a familiar list of categories consisting of translation, editing, formatting and design, quality assurance, and project management. Engineering appears occasionally as a sub-bullet, framed as the LSP's work rather than the customer's.

What is actually happening inside the customer is different. A software company localizing a CAD product across twenty languages is, every release, locating and tagging user-visible strings across a decades-old codebase, routing them to translation, producing localized builds for every product-language combination, testing each for UI breakage, text overflow, RTL flips, and regional format errors, and re-running all of it on every code change.

None of it appears on the LSP's invoice. All of it is done by the customer's own engineers, by build engineers retrofitted onto localization tasks, by QA teams running manual passes that should be automated, by product engineers who get pulled in when extraction breaks.

This work is not named in the industry's cost categorization. It's the engineering iceberg below the LSP-invoice waterline, which is large, expensive, and invisible.

The engineering effort around localization is concrete, substantial, and completely within your organization, but lacks a name, tooling, and a line item in the budget.

How AI modernizes software localization engineering

If the work surrounding translation is engineering work, then modernizing localization is mostly an engineering problem. And artificial intelligence (AI) in software localization is now good enough to absorb large parts of that work in ways that were not feasible three years ago. Four levers do most of the work.

Automated string extraction - Engineering codebases, especially CAD codebases, consist of hardcoded strings, strings buried in odd resource formats, and strings that look user-facing but never appear in the UI. AI in localization can scan codebases, surface user-visible strings with context, and flag ambiguous ones for human review.

Domain-adapted NMT - Generic neural machine translation cannot handle engineering vocabulary effectively. Extrusion and constraints have different meanings in CAD and mechanical design. Mesh means three different things across CAD, computational geometry, and networking. NMT fine-tuned on a company's own terminology and translation memory produces outputs that need less post-editing. This thereby reduces translation cost more than any vendor renegotiation ever will.

CI/CD integration - The seam between development and software localization is where the latency lives. Every code push that changes user-facing strings should trigger automated string extraction, an MT pass on changed segments, routing to human translators, reintegration, and localized-build generation. This is plumbing. Once it exists, the gap between the English ship and the Japanese ship compresses from weeks to days.

ML-driven UI regression and terminology drift detection - Visual regression, including screenshotting localized builds, comparing baselines, flagging text overflow and RTL breaks, has been technically possible for years. However, it is rarely done at scale because the setup costs too much. AI-driven visual diff changes the economics. The same applies to terminology drift: detecting that the same concept has been translated three different ways across releases is pattern recognition at scale — what humans cannot do reliably, and AI can.

Each of these is an engineering investment. None is a translation improvement. Each reduces the surrounding cost of localization far more than any improvement to the translation step itself.

What this changes for the people paying

If the diagnosis is right, three things should change.

Where the budget sits - Localization should be an engineering line item, not a marketing or operations one. The engineering work surrounding translation is larger than the LSP invoice, lives inside the engineering org, and is currently uncosted. Naming it is the first step to investing in it.

Which partners do which work - The next generation of software localization has three parties: the software company, the LSP for language work, and an engineering partner for the pipeline. LSPs have already conceded that the engineering work is outside their scope. Today, that gap is filled by your own engineers, badly, on the side of their actual jobs. That is not sustainable.

What gets automated first - Most software companies are mid-migration on something. Migration windows are when architectures get rebuilt and when "localization is what the LSP does" can be replaced with "localization is what the engineering pipeline does."

What this blog will not argue

It will not argue that LSPs don't add value because linguistic quality, cultural adaptation, and terminology curation are irreplaceable. The argument is about the work they don't do.

It will not argue that AI replaces translators. Domain-adapted MT reduces post-editing volume. It does not eliminate the linguist's role.

It will not argue that this is primarily a cost-reduction problem. The real prize is faster, more consistent localization. It makes the release possible that ships in all twenty languages on the same day.

The window is open now

The industry is already seeing the shift in software localization through modernization. LSPs are talking about continuous AI in localization, CI/CD integration, and engineering complexity. They see the gap. They are not the right people to fill it.

The right people are engineering firms that understand both software pipelines and the localization industry deeply enough to rebuild the scaffolding. That intersection is rare, and it is exactly where the next several years of improvement will be built.

For decades, localization has been organized around language. The next chapter organizes it around engineering, with language as one specialist function inside an engineering-led pipeline. The companies that recognize this first will rebuild their localization stacks for the next decade. The companies that do not will keep paying the engineering iceberg they cannot see and wonder why their localization budget never quite shrinks.

Modernizing Software Localization is an Engineering Problem, Not Translation

Software Localization Modernization: Why Engineering Leads