Translation and localization: when every string in your product is on the meter

Modern software products ship in many languages. A typical SaaS application supports somewhere between five and twenty languages in its UI, with growing investment in supporting more as the company expands into new markets. Documentation, marketing pages, in-app messaging, error strings, transactional email templates — all of it has to be translated for every supported locale.

Until a few years ago, this was done with human translators, with software helping but not making the calls. Today, the bulk of the volume is done by AI. The human translators are still in the loop, but their role has shifted from "translate everything" to "review and approve what the model produced." The economics have shifted dramatically.

And so has the cost structure.

What the bill looks like

A reasonable mid-sized SaaS product has somewhere between fifty thousand and two hundred thousand strings in its UI, plus documentation, marketing site, and transactional email templates. Multiply by the number of target languages — say, fifteen — and you are looking at well over a million strings to translate and maintain.

The maintenance is the part people miss. The strings change all the time. New features add strings. Refactors rename strings. Marketing rewrites copy. Product changes terminology. Every change requires re-translation across every supported language.

For a typical company in this category, the volume of monthly translation work is in the range of fifty thousand to two hundred thousand strings per month. Each translation, with surrounding context, is a small cloud-LLM call — about five hundred input tokens and one hundred output tokens. At frontier pricing, about $0.003 per string.

A hundred thousand strings per month at $0.003 each is $300 per month — modest, but it's only one workload at a small-ish company. At an enterprise localization team supporting a major product with thirty languages and frequent releases, the volume can be a million strings per month, and the bill scales accordingly: $30,000 per year just for the translation layer.

The bigger cost story is in localization for high-volume content. A team running marketing AI across thirty languages, translating blog posts, social content, ad copy, and email campaigns — that team is processing tens of millions of words per month. At frontier pricing, the bill is in the low six figures per year.

Why translation is a strong local-SLM workload

Translation has every property that makes a workflow well-suited to specialized local inference.

It is narrow. The model needs to know how to translate between specific language pairs, with specific glossaries, specific style preferences, specific brand voice. A model trained on the company's own translation history will outperform a general-purpose model on the company's own work.

It is repetitive. The same phrases recur. The same terminology choices recur. Specialization compounds across millions of strings.

It is high-volume. The cost scales linearly with the volume of content being translated, which means the local-vs-cloud math gets more favorable as the company expands into more markets.

It is privacy-sensitive in a specific way. Translation often happens on content that hasn't been published yet — marketing copy for an unannounced product, support documentation for an unreleased feature, internal training materials. Sending pre-release content to a third-party cloud LLM is a posture not every company is comfortable with.

It is brand-sensitive. The translation has to match the company's voice in each target language. A general-purpose translator gets the words right but often misses the brand tone. A model trained on the company's own approved translations captures the tone as well as the meaning.

What changes with a local fine-tuned model

A translation workflow on a local SLM has a structure like this.

A model is fine-tuned on the company's translation memory — every previously-translated string, indexed by language pair, with the approved final translation. The fine-tune captures the company's specific terminology choices, style guide, and brand voice in each language.

The model runs on infrastructure the company controls. Strings flow in from the product, the documentation system, the marketing CMS, and the email tooling. The model translates them, with full context (the source string, surrounding strings, any glossary entries, any style annotations). The translations flow back into the systems that need them.

The cost flips from per-string to fixed. The team pays once for the model and once for the hardware. Volume can grow ten-fold as the company expands into more markets without the bill moving.

The brand consistency improves. A general translator might render "dashboard" three different ways across three different strings. A fine-tuned model knows that this company always renders "dashboard" as a specific word in each target language.

The privacy story improves. The pre-release content stays inside the company's systems.

The audit trail improves. Every translation gets a structured log of what the model considered, what it chose, and why. When the human reviewer disagrees, the disagreement gets fed back into the next round of fine-tuning.

Where the cloud LLM is still the right call

A few cases where cloud-LLM-based translation is genuinely better.

For very rare language pairs where the company doesn't have enough translation history to fine-tune a local model. Cloud LLMs trained on broad multi-lingual corpora can handle pairs that a narrow local model cannot.

For brand-new product domains where the terminology is new and not yet reflected in the company's translation memory. Until enough history accumulates, the cloud LLM's breadth helps.

For one-off translation work where the volume doesn't justify the infrastructure investment. The threshold here is lower than people guess — a few thousand strings per month is enough — but it isn't zero.

For everything else — the high-volume, recurring, brand-sensitive translation work that constitutes the bulk of localization at any serious software company — the local-SLM case is strong and getting stronger.

The pattern, applied

Avery NXR is not a translation tool. It scaffolds Next.js applications. The architectural pattern is the same.

Translation is a narrow, repetitive, high-volume, privacy-sensitive, brand-sensitive workload. The economics that favor a specialized local model for code scaffolding are the same economics that favor a specialized local model for translation. The quality-improvement story is unusually strong — the fine-tuned model isn't just cheaper, it produces translations that better match the company's voice.

The companies that build excellent vertical translation tools on local infrastructure — with appropriate fine-tuning, appropriate workflow integration, and sensible business models — are going to find willing buyers in every product team and marketing team running international operations.

The pattern continues. The architectural shift moves through one operational workflow after another. Translation is one of the next ones to flip.