Most localization defects don't originate from bad translation. They originate from missing context, skipped validation steps, and an absence of systematic checks between source change and final deployment. A misplaced placeholder crashes an app. An untested RTL layout garbles navigation. A truncated German string hides a critical call-to-action. These failures are preventable, but only when teams move beyond ad-hoc review toward a structured Linguistic Quality Assurance (LQA) framework. This article lays out the full LQA discipline for text localization: error typologies, automated checks, pseudolocalization techniques, in-context review, vendor scorecards, and gate criteria. Whether you're running human translation, LLM-assisted post-editing, or a hybrid pipeline, these practices will help you ship localized text with confidence.
What Is Linguistic Quality Assurance (LQA) in Localization?
Linguistic Quality Assurance is the systematic evaluation of localized content against defined quality standards before it reaches end users. Unlike translation review, which focuses on whether the target text faithfully conveys the source meaning, LQA encompasses a broader scope: accuracy, fluency, terminology consistency, formatting integrity, functional correctness, and adherence to locale-specific conventions.
LQA sits at the intersection of linguistic evaluation and engineering validation. A robust LQA process catches errors that neither translators nor developers would catch independently, issues like date formats that don't match the target locale, HTML tags stripped during translation, or plural forms that violate ICU MessageFormat rules.
The goal isn't perfection on every string. It's a repeatable, measurable process that drives quality upward over time while reducing the manual effort required per release cycle.
Establishing an Error Typology: MQM and DQF Frameworks
How MQM and DQF Classify Translation Errors
The Multidimensional Quality Metrics (MQM) framework, developed by the QT21 project, provides a hierarchical taxonomy of translation error types. At its top level, MQM distinguishes between accuracy errors (where meaning is wrong, omitted, or added) and fluency errors (where the target text is grammatically incorrect, unnatural, or stylistically inappropriate). Beneath these sit dozens of subcategories, mistranslation, untranslated text, terminology inconsistency, register mismatch, punctuation errors, and more.
The Dynamic Quality Framework (DQF), maintained by TAUS, offers a complementary model designed for flexibility across content types. DQF allows organizations to select and weight error categories based on their specific quality requirements, marketing content might weight fluency and style heavily, while legal documents prioritize accuracy and terminology.
In practice, most mature localization programs use a hybrid: MQM's taxonomy for classification depth, combined with DQF's adaptability for different content streams.
Assigning Severity Levels and Weighting Scores
Not all errors carry equal weight. A standard severity scale includes:
| Severity | Definition | Typical Impact |
|---|---|---|
| Critical | Error causes functional failure, legal risk, or cultural offense | Blocks release |
| Major | Error significantly impairs comprehension or user experience | Requires fix before ship |
| Minor | Error is noticeable but does not impair usability | Fix in next cycle |
| Preferential | Stylistic choice; not objectively wrong | Track but don't penalize |
Each error instance is scored by multiplying its severity weight by the error category weight. A common weighting scheme assigns critical errors a multiplier of 10, major errors 5, minor errors 1, and preferential issues 0. The total penalty score is then normalized against the word count of the reviewed sample to produce a per-thousand-word quality score.
This quantitative approach transforms subjective quality impressions into comparable, trackable metrics. It also makes vendor performance conversations data-driven rather than opinion-based.
Automated Checks That Catch Errors Before Human Review
Automated checks are the first line of defense. They're fast, consistent, and catch entire categories of error that human reviewers routinely miss, especially formatting and structural issues.
Placeholder and Variable Validation
Placeholders like {username}, %d, or {{count}} must survive translation intact. A missing or reordered placeholder will produce runtime errors or nonsensical output. Automated validation should verify that every placeholder present in the source string appears in the target string, in the correct order where order-sensitive formatting is used, and with no extraneous placeholders added.
ICU MessageFormat and Plural Rule Checks
ICU MessageFormat strings handle pluralization, gender selection, and number formatting. These structures are notoriously fragile in translation. A missing plural category for a language (Russian requires one, few, many, and other) will cause fallback behavior or crashes. Automated checks should parse each ICU message, verify all required plural categories per the CLDR plural rules, and flag syntax errors like unmatched braces.
Spelling, Grammar, and Terminology Linting
Spell-checking against locale-specific dictionaries catches obvious errors, but the real value comes from custom terminology lists. When your product calls it a "workspace" and a translator writes "project space," a terminology linter flags the deviation. Grammar checking tools like LanguageTool provide rule-based validation that complements human review, especially for high-volume content where full human review isn't economical.
Target Length and Truncation Alerts
German text is often 30-35% longer than English. Finnish and Hungarian can expand even further. Automated length checks compare target string length against the source and flag strings that exceed a defined threshold, either as a percentage or an absolute character count tied to UI constraints. For strings with hard character limits (button labels, mobile notifications, SMS), these checks are essential.
HTML/XML Tag Integrity and Non-Breaking Spaces
Translation tools sometimes strip, duplicate, or reorder inline markup. An unclosed <b> tag or a missing </a> can break rendering across an entire page. Tag validation ensures that every opening tag has a corresponding closing tag, tag order is preserved, and self-closing tags remain intact. Non-breaking spaces ( or Unicode \u00A0) also require validation, French typography, for instance, requires non-breaking spaces before colons, semicolons, and question marks.
Locale-Specific Format Validation for Dates, Numbers, and Currency
A date rendered as 12/05/2025 means December 5th in the United States and May 12th in most of Europe. Automated checks should verify that date formats, number separators (comma vs. period for thousands), currency symbols, and measurement units conform to the target locale's conventions as defined by CLDR.
Link and URL Validation
Localized content frequently includes links to locale-specific landing pages, help articles, or legal documents. Link validation checks that URLs in translated content are reachable (not returning 404), point to the correct locale version where locale-specific URLs exist, and haven't been corrupted during the translation process.
Running these checks in CI/CD pipelines, triggered on every commit that touches localization files, catches defects before they reach human reviewers, freeing linguists to focus on meaning and style rather than formatting mechanics. Ollang integrates these automated validation layers directly into localization workflows, so teams can book a demo to see how checks run against their actual file formats and tech stack.
Pseudolocalization: Testing UI Resilience Before Translation
Pseudolocalization is an engineering technique that simulates the effects of translation without actually translating. It transforms source strings using predictable rules to expose layout, encoding, and hardcoding issues early, before real translations are produced and before real translators waste time on strings that will break regardless.
What Pseudolocalization Is and Why It Matters
A pseudolocalized string replaces ASCII characters with accented equivalents (e.g., Login becomes [Ĺŏĝĩń______]), pads the string to simulate text expansion, and wraps it in brackets or other delimiters. The result is still readable by English-speaking developers and testers, but it immediately reveals UI problems: truncated labels, overlapping elements, hardcoded strings that weren't externalized, and encoding failures where accented characters render as garbled text.
Pseudolocalization is cheap and fast. It requires no linguistic resources. It can run as part of every build. And the issues it catches, layout breakage, hardcoded strings, are among the most expensive to fix after real translations have been delivered.
Simulating Text Expansion and Detecting Truncation
The standard approach pads each string by 30-50% to simulate the expansion typical of German, Finnish, or Greek translations. Strings that overflow their containers, get clipped by CSS overflow: hidden, or push adjacent elements off-screen are immediately visible in pseudolocalized builds. Teams should test at multiple expansion levels: 30% for average-case languages, 50% or more for worst-case scenarios.
RTL Mirroring and Bidirectional Text Testing
For languages like Arabic, Hebrew, and Farsi, the entire UI layout must mirror: navigation moves to the right, text aligns right, and directional icons flip. Pseudo-RTL testing applies Unicode bidirectional control characters and reverses string direction to verify that the application's layout engine handles mirroring correctly. This catches issues like:
- Left-aligned icons that should flip
- Breadcrumb separators that point the wrong direction
- Progress bars that fill from right to left
- Mixed LTR/RTL content in the same paragraph
Identifying Hard-Coded Strings in Source Code
Any string that appears in its original English form after pseudolocalization has been applied is a hardcoded string, one that was never externalized to a resource file and therefore cannot be translated. Pseudolocalization makes these strings visually obvious against the sea of accented, bracketed text. Teams should treat every hardcoded string found during pseudo testing as a bug to be filed and fixed before the next localization cycle.