Translation System Cost: Quality Tiers, Review and Terminology

Machine translation has become inexpensive enough that per-word pricing is no longer the interesting number. What costs money is review by native speakers, terminology management, and the engineering work that gives translation enough context to be usable. This guide covers those, drawing on FISTA Solutions' AI enablement work across multilingual delivery. It complements how to build a localization agent and ai translation.

Why does review dominate?

Because native reviewers are the expensive and necessary component for anything customer-facing. Machine translation of a document costs very little; having a qualified native speaker confirm it reads naturally, uses correct terminology, and carries the right register costs considerably more.

That inverts the intuitive model, and it means translation budgets built from per-word rates understate substantially for any content that matters.

Component	Cost	Scales with
Machine translation	Low	Word volume
Native review	High	Volume and quality tier
Terminology and glossary work	Moderate	One-off plus upkeep
Context extraction engineering	Moderate	One-off per product
Translation memory setup	Low	One-off
Qualified translation for regulated content	Highest	Volume of such content

How should languages be tiered?

By business importance rather than uniformly. A core revenue market warrants native review of all customer-facing content and a maintained glossary; a market served for coverage or accessibility may reasonably run on reviewed machine output with a lighter process.

Uniform treatment over-invests in low-impact languages and under-serves critical ones. Making the tiering explicit is what lets budget follow the business rather than the word count.

Why does terminology matter more than fluency?

Because inconsistency confuses users permanently while awkwardness merely reads oddly. A feature called three different things across a product's interface, help documentation, and support content cannot be searched for or followed.

A managed glossary with enforced terms per language is therefore the foundation, and building it is editorial work with product input. It is the step most often skipped in favour of translating faster. See how to build a localization agent.

What is context extraction and why does it cost?

Capturing where a string appears, its length constraints, whether it is a label or a sentence, and what surrounds it. Without that, a short English string becomes a grammatically valid phrase that does not fit its container or does not make sense in place.

That capture is engineering work in the product codebase rather than translation work, and it is a one-off investment that reduces correction effort on every subsequent translation.

What does translation memory contribute?

Cost reduction through reuse. Content already translated and approved does not need retranslating, and partial matches reduce effort on similar content. For products with iterative releases, where much content is unchanged between versions, this is a substantial ongoing saving.

It also improves consistency, since previously approved translations are reused rather than regenerated differently each time.

What must stay with qualified translators?

Legal terms, privacy notices, regulatory disclosures, safety instructions, and medical or financial guidance. These carry liability, are jurisdiction-specific, and frequently have prescribed wording.

Those categories should be excluded from automated pipelines by configuration rather than by someone remembering, because the exclusion is the control.

How should quality be measured?

By reviewer edit rate per language and content type. A falling edit rate over time indicates the glossary and context work is paying; a persistently high rate in one language identifies a specific problem worth investigating rather than a general quality concern.

Words translated is a volume metric that says nothing about whether the output was usable.

What about adding a new language?

Cheaper than the first but not free. The glossary must be built, context is already extracted, translation memory starts empty, and reviewers must be found and calibrated. Organisations that treat adding a language as a configuration change underestimate consistently, and organisations that have done the context and glossary work properly find each subsequent language substantially cheaper than the last.

What should you do first?

Measure your reviewer edit rate on a sample in your two most important languages. That number tells you whether the constraint is terminology, context, or the model, and each has a different and differently priced fix.

Who should do the review?

Native speakers with domain knowledge, which is a scarcer combination than native speakers alone. A reviewer who speaks the language fluently but does not know the product or the sector will correct grammar and miss terminology errors that matter more.

For organisations with staff in their markets, those staff are frequently the best reviewers and are rarely asked. A structured review task taking a few minutes, presented to someone who knows the product, produces better results than an external reviewer with no context — and costs less.

How FISTA Solutions helps

FISTA Solutions tiers languages by business importance, builds and enforces glossaries as the foundation of quality, extracts context in the product codebase to reduce correction effort, uses translation memory for reuse, excludes regulated content from automation by configuration, and measures reviewer edit rate per language, through AI enablement, AI agents, and web and mobile engineering. The record behind the approach is 150+ projects for 50+ companies across 12+ countries.

To localise at a cost that reflects what each market is worth, message FISTA on WhatsApp, or read how to build a localization agent.