AI Translation Got Cheap. Why Didn't Localization Costs Follow?
LLMs have driven the price of first-pass translation close to zero. Work that once cost 10 to 15 cents per word now takes a handful of API calls. Yet ask any team actually running a multilingual product and they will tell you their total localization spend has barely moved. The reason is straightforward: translation is only one slice of the localization pipeline.
Break the cost structure down and first-pass translation accounts for roughly 30 to 40 percent. The rest is review, applying corrections, verifying builds, redeploying, and undoing damage after a mistranslation ships. Cutting translation cost by 90 percent moves the total by only about 30 percent. Worse, if the downstream steps are still manual, a higher volume of machine output can make the review bottleneck tighter than it was before.
Teams also tend to overlook that different content types demand different quality bars. Product UI strings are short and context-free, so mistranslation risk is high but the cost of fixing one is low. Help documentation is voluminous, and errors there translate directly into support tickets. Contracts and terms of service carry legal liability in a single sentence. Marketing copy needs transcreation for local sensibility more than it needs literal accuracy. Applying one standard and one process to all four guarantees that you are over-investing somewhere and under-investing somewhere else.
Above all, product content is never translated once and finished. A SaaS product shipping weekly changes 20 to 50 UI strings every release. Re-translating everything blows up cost and lead time; identifying the diffs by hand guarantees omissions.
What Breaks When There Is No Pipeline
Localization has to be designed as a continuously operating pipeline, not a project with an end date.
Extraction: isolating exactly what needs translating
Hardcoded strings in code, CMS content, and Markdown documents live in different places in different formats. The first step is structurally extracting only the translatable text from each source. In a Next.js project, a message catalog such as `messages/ko.json` already serves as an extraction artifact, so the sensible design is to merge CMS and document sources into that same schema.
Incremental processing and translation memory
Attach a content hash to each source string and only changed entries enter the translation queue. Layer translation memory (TM) on top and previously approved identical or near-identical sentences get reused. In repetition-heavy content like product documentation, TM match rates of 40 to 60 percent are common, and every match removes both an LLM call and a review item.
Manage glossaries and style guides as data, not prompts
Writing terminology rules directly into a prompt string is convenient at first and hits a wall quickly. Past 200 terms the prompt becomes bloated, and there is no way to trace who changed what and when. Keep the glossary in its own table and inject only the terms that actually appear in the sentence being translated — this wins on both accuracy and token cost.
Locking do-not-translate items
Brand names, product names, legal notices, and API parameter names must never be translated. The safe approach is substituting placeholders before translation and restoring them afterward. Instructing the model to "leave this untranslated" in the prompt will always leak on a handful of items out of several hundred.
Making Quality Measurable
From reviewing everything to risk-based sampling
Human review of every sentence collapses the moment volume grows. Tier by risk instead. Contracts, payments, and security notices get full review. Product UI gets full review on new strings plus sampling on edits. Blog posts and help content that pass automated checks get a 10 to 20 percent sample.
What automation can catch on its own
More defects than you would expect can be caught mechanically, before a human ever looks:
Automating just these four filters out a large share of the defects that surface in practice.
Where LLM-as-judge is actually reliable
LLM-as-judge is useful for judgments like "does this read naturally" and "was source meaning dropped," but its limits are clear. Absolute scores drift with prompt phrasing and model version, so it is safer to use it as a ranking tool that orders the review queue than as a pass/fail gate. Mistranslations requiring domain knowledge, and legal nuance, still need a human.
Where to place reviewers
Staffing every language equally is waste. A realistic setup assigns dedicated reviewers to the top two or three languages by revenue contribution and user count, and runs the rest on automated checks plus a quarterly audit.
Engineering Concerns When Wiring This Into a System
Pass the context along with the string
Hand a model the key `button.save` and the word "Save" and it cannot tell whether this is a button or a menu item. Passing metadata — the key path, screen name, maximum string length, a screenshot caption — visibly reduces mistranslation. Designing i18n keys with visible hierarchy from the start, like `settings.account.deleteButton`, pays off substantially later.
Problems translation alone cannot solve
Plural rules vary by language. English needs two forms, Russian needs four, so string concatenation cannot cover it and you need a standard like ICU MessageFormat. Dates, currency, and digit separators belong to formatters, not translators. And in languages where word order differs, any code that assembles sentences from fragments will break.
Connecting to the deployment pipeline
Empty translation keys should fail the CI build, or at minimum raise a warning. Automating a coverage check before release structurally prevents the "screen that renders in English only" from reaching production.
Where to Begin
Set priorities from data, not intuition. Start with the languages that carry the most traffic and revenue, and the content types where a mistranslation costs the most. In most cases that means product UI and the payment and onboarding flows.
A sample first-quarter roadmap
Judge results on three metrics. Edit rate (the share of sentences a human had to touch) reflects pipeline quality. Lead time (from source change to translated deployment) reflects operational speed. Per-language bounce and conversion rates show whether localization actually moved the business.
---
POLYGLOTSOFT designs and operates multilingual web services and applications on next-intl, and applies that hands-on experience to building localization pipelines that run from content extraction through LLM translation, automated validation, and CI integration. We can work through it in stages — diagnosing your existing i18n structure, designing the glossary, and automating quality gates. If you are preparing to expand into multiple languages, [get in touch](https://polyglotsoft.dev/en/support/contact) and we will walk through the approach that fits your current architecture.