Choosing a Text Localization Stack: TMS, MT, LQA Compared

Most localization teams don't fail because they picked the wrong vendor. They fail because they assembled a stack without knowing what the stack actually needs to do. The result is a translation management system that can't parse your ICU MessageFormat strings, a machine translation engine that ignores your glossary, and a quality assurance process that amounts to a single bilingual reviewer eyeballing screenshots. This guide breaks down the three pillars of a modern text localization stack, TMS, MT, and LQA, and provides a structured framework for evaluating, scoring, and procuring each component. By the end, you'll have a scoring matrix, an RFP checklist with concrete test cases, and stack patterns matched to your company stage and content mix.

Defining the Modern Text Localization Stack

A localization stack is more than a list of tools. It's an interconnected system where each layer depends on well-defined inputs and outputs. Before comparing vendors, you need to establish what "done right" looks like at the foundation level.

Source-of-Truth for Strings

Every localization workflow begins with a canonical source of strings. For software products, this is typically a set of resource files (JSON, XLIFF, ARB, .strings, .properties) stored in a version-controlled repository. The source-of-truth must be unambiguous: one file or database record per string key, per locale. If your developers are editing strings in code while translators are editing them in a TMS, you have two sources of truth, and therefore zero.

A well-designed source-of-truth enforces:

- Unique string keys with consistent naming conventions (e.g., screen.settings.label.save)

- Separation of translatable content from code logic, so linguists never encounter raw variables or conditional blocks

- Immutable snapshots at release boundaries, enabling version diffs between localization cycles

String Formats: JSON, XLIFF, and ICU MessageFormat

Your stack must handle the file formats your engineering team actually uses. JSON is the most common for web and mobile apps, but its lack of metadata (context, character limits, translator notes) makes it fragile for localization at scale. XLIFF 2.0 solves this by wrapping each translation unit in rich metadata, and most professional TMS platforms support it natively.

ICU MessageFormat is the standard for handling pluralization, gender selection, and number formatting within strings. A string like {count, plural, one {# item} other {# items}} must be parsed correctly by every layer of the stack, TMS, MT engine, and QA tooling. If your TMS flattens ICU syntax into plain text before sending it to translators, you'll get broken plurals in production. Test for this explicitly during evaluation.

Glossary, Termbase, and Style Guides

A glossary (or termbase) is a controlled vocabulary of terms that must be translated consistently. "Dashboard" might always remain "Dashboard" in German for your product, or it might always become "Übersicht." Without a termbase, every translator makes this decision independently, and consistency erodes across languages and releases.

Style guides complement termbases by defining tone, formality level, date/time formatting preferences, and brand voice rules per locale. Together, these assets form the linguistic governance layer of your stack. Any TMS or MT engine you evaluate should support:

- Termbase import/export in TBX format

- Glossary enforcement during translation (warnings or hard blocks)

- Style guide attachment at the project or language level

Linguist Workflows and Roles

Translation is not a single step. A mature workflow includes translation, editing (or review), and often a separate in-context review phase. Your stack should support configurable workflow stages with role-based access: translators see only their assigned strings, reviewers can approve or reject with comments, and project managers have visibility across all languages.

Look for support for translation memory (TM) leverage, where previously translated segments are suggested automatically, and for the ability to lock approved translations against accidental edits in future cycles.

TMS Capabilities: What Separates Good from Great

The translation management system is the operational hub. It orchestrates file exchange, translator assignment, progress tracking, and delivery. But not all TMS platforms are built equal, and the differences show up in the details that matter most to engineering and localization teams working at velocity.

Connectors and Integrations

A TMS that can't connect to your code repository, design tool, or CMS creates manual handoff points, and manual handoff points create delays and errors. Evaluate connectors for:

- Git-based repos (GitHub, GitLab, Bitbucket): Does the connector support branch-aware syncing, or does it only pull from main?

- Design tools (Figma, Sketch): Can translators see and edit strings in visual context?

- CMS platforms (WordPress, Contentful, Strapi): Does the connector handle structured content models, or does it flatten everything into a single blob?

- Marketing automation and support tools: Zendesk, HubSpot, and similar platforms often have their own string structures.

The best connectors are bidirectional, support filtering (so you only send changed strings), and preserve file structure on round-trip. Consider an orchestration layer (for example, Ollang) that centralizes connectors and reduces custom integration work.

In-Context Previews

Translators produce better output when they can see where a string appears in the product. In-context preview means rendering the translated string inside a live or simulated version of the UI. This is especially critical for short strings (button labels, menu items) where character limits and layout constraints determine whether a translation works.

Some TMS platforms offer browser-based preview via a JavaScript snippet injected into your staging environment. Others generate static screenshots. The former is more accurate but requires a working staging URL; the latter is easier to set up but quickly becomes stale.

Branching and Version Diffs

If your development team uses feature branches, your localization workflow should mirror that structure. A TMS with branching support lets you localize strings on a feature branch without polluting the main translation memory or overwriting work in progress on other branches.

Version diffs, the ability to see exactly which strings changed between two points in time, are essential for incremental localization. Without diffs, you're either re-translating everything (expensive) or manually tracking changes in spreadsheets (error-prone).

MT Engines: Domain Adaptation, Glossary Injection, and Cost

Machine translation has moved from "useful for gisting" to "production-viable for many content types." But the gap between a generic MT output and a domain-adapted, glossary-injected MT output is enormous. Choosing the right MT engine, and configuring it correctly, is one of the highest-leverage decisions in your stack.

Generic vs. Domain-Adapted MT

Generic engines like Google Translate and DeepL perform well on general-purpose content but struggle with domain-specific terminology, product names, and brand voice. Domain adaptation (also called custom training or fine-tuning) uses your existing translation memory and glossary to train a model that reflects your specific vocabulary and style.

According to Intento's 2023 State of Machine Translation report, domain-adapted models can reduce post-editing effort compared to generic baselines, though the exact improvement varies by language pair and content type. The tradeoff is setup time, ongoing maintenance, and cost: custom models require curated training data and periodic retraining as your product evolves.

Glossary Injection and Terminology Control

Even without full domain adaptation, most MT APIs and orchestration platforms like Ollang support glossary injection, forcing the engine to use specific translations for designated terms. Google Cloud Translation, DeepL, and Amazon Translate all offer this feature, though implementation quality varies. Test with your actual glossary: does the engine respect multi-word terms? Does it handle inflected forms correctly in morphologically rich languages like Finnish or Turkish?

Glossary injection is not a substitute for domain adaptation, but it's a cost-effective way to enforce critical terminology without custom training.

Cost Models

MT pricing typically follows one of three models:

Factor in not just the translation cost but the post-editing cost. Cheap MT that requires heavy post-editing can end up more expensive than a pricier engine with better raw output.

LQA and Quality Estimation: COMET, Sampling, and Automation

Translation quality assurance is the layer most often skipped, and most often regretted. A single mistranslated legal disclaimer or a broken placeholder in a payment flow can cost more than the entire localization budget.

Automated QA Checks

Every TMS should include basic automated checks: missing placeholders, inconsistent terminology, double spaces, untranslated segments, and length violations. These are table-stakes features. The more sophisticated question is whether the platform supports custom QA rules, for example, flagging any translation that exceeds 130% of the source string length, or detecting HTML tags that were altered during translation.

Quality Estimation with COMET and MQM

Quality estimation (QE) models like COMET predict translation quality without requiring a human reference translation. COMET scores correlate well with human judgments and can be used to triage MT output: high-scoring segments go straight to production, while low-scoring segments are routed to human reviewers. This dramatically reduces review costs without sacrificing quality on the segments that matter.

For more structured quality measurement, the Multidimensional Quality Metrics (MQM) framework provides a taxonomy of error types (accuracy, fluency, terminology, style) with severity levels. MQM-based LQA produces actionable data: you can identify whether a specific translator consistently makes accuracy errors, or whether a particular MT engine struggles with fluency in Japanese.

Sampling Strategies

Full human review of every translated string is prohibitively expensive at scale. Sampling strategies let you review a statistically meaningful subset:

- Random sampling: Review a fixed percentage of segments per language per release

- Risk-based sampling: Prioritize review of user-facing, legal, or safety-critical strings

- Model-guided sampling: Use QE scores to select the segments most likely to contain errors

Combining model-guided sampling with MQM-based scoring gives you the best ratio of quality signal to review cost.

API Evaluation: Auth, Webhooks, and Rate Limits

Your localization stack doesn't exist in isolation, it must integrate with your engineering infrastructure. API quality determines whether that integration is seamless or fragile.

Authentication and Security

Look for OAuth 2.0 or API key authentication with scoped permissions. A well-designed API lets you create keys with granular access: one key for your CI pipeline that can only push and pull strings, another for your analytics dashboard that can only read project metadata.

Webhooks and Event-Driven Workflows

Webhooks enable event-driven automation: when a translation is completed, the TMS notifies your system, which triggers a pull request or a deployment. Without webhooks, you're left polling the API on a timer, wasteful and slow. Evaluate webhook reliability: does the vendor guarantee delivery? Is there a retry mechanism for failed deliveries? Can you filter events by project, language, or workflow stage?

Rate Limits and Throughput

Rate limits matter when you're syncing thousands of strings across dozens of languages in a CI/CD pipeline. Ask vendors for documented rate limits and whether burst capacity is available. A TMS that throttles your API calls to 60 requests per minute will bottleneck a deployment pipeline that needs to sync 40 locale files in parallel.

CI/CD Fit: Localization in the Development Pipeline

Localization that happens outside the development pipeline is localization that ships late. The goal is to make string extraction, translation, and delivery as automated as building and testing code.

Pipeline Integration Patterns

The most common pattern is a CLI tool or GitHub Action that runs on every push to a feature branch:

1. Extract new or changed strings from source files

2. Push them to the TMS via API

3. When translations are complete (via webhook or polling), pull translated files back into the repo

4. Run automated QA checks as part of the CI test suite

5. Merge translated files with the feature branch

This pattern keeps localization in lockstep with development. Evaluate whether the TMS provides an official CLI, and whether it supports pseudo-localization, generating fake translations that test for string concatenation issues, character encoding problems, and UI overflow, as part of the CI pipeline.

Handling Continuous Delivery

If you deploy multiple times per day, you need a stack that can handle continuous string changes without creating translation debt. Look for incremental sync (only changed strings are sent for translation), the ability to set translation deadlines per string or batch, and dashboards that show localization completion as a release gate.

Security: PII Handling, SOC 2, and Encryption

Localization workflows routinely handle sensitive data: user-generated content, legal documents, medical records, financial disclosures. Your stack must meet the same security standards as the rest of your infrastructure.

Data Residency and Encryption

Verify where translation data is stored and processed. For EU-based companies or products serving EU users, GDPR compliance requires clear data processing agreements with every vendor in the chain, including MT providers. Data should be encrypted at rest (AES-256) and in transit (TLS 1.2+).

PII Detection and Redaction

If your localization workflow includes user-generated content (support tickets, reviews, chat messages), you need PII detection and redaction before strings reach translators or MT engines. Some TMS platforms offer built-in PII detection; others require you to handle this upstream.

Compliance Certifications

SOC 2 Type II certification is the baseline for enterprise vendors. ISO 27001 is common in European markets. Ask for the most recent audit report, not just a badge on the website. For regulated industries (healthcare, finance), additional certifications like HIPAA BAA or PCI DSS may be required.

For teams evaluating vendors across all three layers, TMS, MT, and LQA, with enterprise security requirements, consider booking a demo with Ollang to see how an integrated platform handles PII, encryption, and compliance across the full localization pipeline.

Analytics and Reporting

You can't optimize what you don't measure. A mature localization stack produces data at every stage, and that data should drive decisions about vendor selection, translator performance, and process efficiency.

Key metrics to track:

- Translation velocity: Average time from string creation to approved translation, per language

- MT utility rate: Percentage of MT output accepted without post-editing

- QA error density: Number of errors per thousand words, segmented by error type and severity

- Cost per word: Total cost (MT + human + QA) divided by word count, per language and content type

- Localization coverage: Percentage of strings translated and approved at any given release milestone

Your TMS should expose this data via dashboards and API endpoints. If it doesn't, you'll end up building reporting infrastructure yourself, which is a sign the platform isn't designed for the operational maturity you need. Platforms like Ollang surface these metrics via built-in dashboards and APIs so you don't have to build reporting plumbing.

Pricing Models Compared

Localization pricing is notoriously opaque. Understanding the common models helps you compare apples to apples during procurement.

Ask every vendor for a total-cost-of-ownership estimate based on your actual volume, language count, and workflow complexity. A low per-word rate means nothing if the platform fee, connector costs, and API overage charges double the bill.

Scoring Matrix for Stack Evaluation

Use a weighted scoring matrix to compare vendors systematically. Assign weights based on your team's priorities, a startup shipping its first three languages will weight differently than an enterprise managing sixty.

Score each vendor on a 1-5 scale per criterion, multiply by weight, and sum. This doesn't make the decision for you, but it forces structured comparison and surfaces gaps that demos alone won't reveal.

RFP Checklist with Test Cases

An RFP without test cases is a wishlist. Include concrete, verifiable test scenarios that expose how each vendor handles the edge cases that break localization in production.

Pluralization

Provide a string using ICU MessageFormat with plural rules: {count, plural, =0 {No items} one {# item} few {# items} many {# items} other {# items}}. Ask the vendor to demonstrate correct handling for English (one/other), Russian (one/few/many/other), and Arabic (zero/one/two/few/many/other). Verify that the TMS displays the plural forms correctly to translators and that MT output preserves the ICU syntax.

Placeholders

Submit strings with named placeholders (Hello, {userName}!), positional placeholders (%1$s of %2$d), and HTML-in-strings (<b>Important:</b> {message}). Verify that placeholders are locked from editing, that QA flags missing or reordered placeholders, and that MT output preserves them intact.

Right-to-Left (RTL) Languages

Request a demo with Arabic or Hebrew content. Check that the TMS editor supports RTL text entry, that in-context previews render RTL layout correctly, and that bidirectional text (mixed LTR/RTL within a single string) doesn't break.

HTML-in-Strings

Strings containing inline HTML (Click <a href="{url}">here</a> to continue) are common in web applications. Verify that the TMS protects HTML tags from accidental modification, that translators can reorder content around tags, and that QA checks validate tag integrity.

Additional Test Cases

• String with character limit: Set a 25-character limit and verify enforcement
• Concatenated strings: Submit two strings that are joined at runtime and check whether the TMS flags the concatenation risk
• Context metadata: Attach a screenshot and developer note to a string and verify that translators see both during translation

Stack Patterns by Company Stage and Content Mix

There's no universal "best" stack. The right combination depends on your scale, content types, and organizational maturity.

Early-Stage Startup (1-5 Languages, Product UI Only)

At this stage, simplicity wins. Use a lightweight TMS with a GitHub connector and built-in MT (DeepL or Google). Skip custom domain adaptation, your content volume doesn't justify it yet. Use the TMS's built-in QA checks and have one bilingual team member review critical flows. Budget for per-string pricing to keep costs predictable.

Growth-Stage Company (5-20 Languages, Product + Help Center + Marketing)

You now need a TMS with robust workflow support (translation → review → in-context review), connectors for your CMS and help center platform, and a dedicated MT engine with glossary injection. Implement MQM-based sampling for LQA. Invest in CI/CD integration so localization doesn't gate releases. This is the stage where analytics start paying dividends, track cost per word and MT utility rate to optimize spend.

Enterprise (20+ Languages, Regulated Content, Multiple Product Lines)

At enterprise scale, you need a TMS that supports multi-tenant projects, granular permissions, and SSO. Domain-adapted MT becomes cost-effective. LQA should include both automated QE scoring and structured human review with MQM. Security requirements (SOC 2, data residency, PII handling) become non-negotiable. Consider a managed localization service that integrates TMS, MT, and LQA into a single platform, this reduces vendor management overhead and simplifies accountability.

Ollang operates at this intersection, providing an AI-powered execution layer that unifies text localization across TMS orchestration, MT with terminology control, and automated quality review, built for enterprise teams managing complex, multi-format content.

Frequently Asked Questions

Should I use one vendor for TMS, MT, and LQA, or best-of-breed for each?

An integrated platform reduces handoff friction, simplifies data flow (glossaries, TM, and QA rules live in one place), and gives you a single point of accountability. Best-of-breed gives you more flexibility and avoids vendor lock-in, but requires you to build and maintain integrations. For most teams, starting integrated and selectively swapping components as needs evolve is the pragmatic path. Ollang is an example of an integrated option that centralizes glossaries, TMs, and QA rules while still allowing you to plug in best-of-breed engines where needed.

How do I evaluate MT quality before committing to a vendor?

Run a blind evaluation. Select 500-1,000 representative source segments across your content types and language pairs. Send them through each MT engine with your glossary applied. Have two independent reviewers score the output using MQM error typology. Compare error density, terminology adherence, and fluency. This takes effort but produces data you can trust, far more than a vendor demo with cherry-picked examples.

What's the minimum viable LQA process for a small team?

At minimum, run automated QA checks (placeholder integrity, terminology consistency, length violations) on every translation. Add random sampling of 5-10% of segments for human review in your highest-revenue languages. Use QE scores if available to prioritize which segments get human eyes. This won't catch everything, but it catches the errors that break functionality or damage trust.

How do I handle localization for content that contains PII?

Implement PII detection and redaction before content enters the localization pipeline. Replace personally identifiable information with anonymized placeholders, translate the anonymized content, then reinsert the original PII in the target-language output. Ensure your TMS and MT vendors have data processing agreements that comply with GDPR, CCPA, or whatever regulations apply to your user base. Never send raw PII to a third-party MT API without contractual and technical safeguards in place.

Next Steps

You now have a framework for evaluating every component of a text localization stack: what to look for in a TMS, how to select and configure MT engines, and how to build an LQA process that balances cost and quality. Use the scoring matrix to structure your evaluation, and include the test cases in your RFP to surface real capability differences between vendors.

If you're ready to see how an integrated localization platform handles these requirements end-to-end, from ICU MessageFormat parsing to automated quality estimation to CI/CD pipeline integration, book a tailored walkthrough: schedule a demo with Ollang and bring your toughest test cases.