End-to-End Text Localization Workflow: Extraction to QA and Launch

Your problem: localization failures rarely stem from bad translations; they stem from broken processes, strings extracted without context, glossaries that don't exist, review cycles that start too late, and release trains that leave without waiting for localized builds. The result: truncated UI labels, placeholder errors in production, and launch dates that slip because no one defined a string freeze. This article maps a complete, repeatable workflow for localizing all written content, UI strings, product documentation, marketing copy, and support articles. It walks through every stage from source readiness to post-launch validation, with concrete artifacts you can adopt immediately: RACI matrices, SLAs, entry and exit criteria, and a pre-launch checklist. Whether you run localization in-house or with a partner like Ollang, this framework gives your team a blueprint for shipping confidently in every target language.

Source Readiness and String Inventory

Before a single string enters a translation pipeline, the source material must be stable, complete, and auditable. Source readiness is the most underinvested stage in localization, and the one that causes the most downstream rework.

Defining "Source-Ready" Content

Content is source-ready when it meets three conditions: it is final (or frozen for a defined period), it is externalized from code, and it carries enough metadata for translators to understand its purpose. For UI strings, this means resource files (.json, .xml, .xliff, .properties) separated from application logic. For documentation and marketing, it means approved copy in a content management system with clear ownership.

Source readiness also requires internationalization (i18n) compliance at the code level. Strings must be externalized, not hardcoded. Date, time, number, and currency formats must use locale-aware libraries. Concatenated strings, which break grammatical structure in most non-English languages, must be refactored into full translatable units. Use a message framework such as ICU MessageFormat (e.g., "{count, plural, one {# file} other {# files}}") for pluralization, gender, and variable insertion instead of runtime concatenation.

Building a String Inventory

A string inventory is a canonical list of every translatable asset, organized by product area, content type, and priority. It answers a simple question: what exactly needs to be translated, and how much of it?

Maintaining this inventory in a translation management system (TMS) or a version-controlled repository ensures that nothing is lost between releases and that translation memory (TM) leverage is maximized.

Extraction and Context Metadata

Automating String Extraction

Manual extraction, copying strings into spreadsheets, is error-prone and unscalable. Modern workflows use automated extraction pipelines that pull translatable strings directly from source repositories into a TMS. Common approaches include:

• CLI-based extraction from resource files (e.g., i18next-parser, formatjs/react-intl extraction scripts)
• API-driven sync between a code repository (GitHub, GitLab, Bitbucket) and a TMS
• CMS connectors that push content from platforms like Contentful, WordPress, or Adobe Experience Manager into translation workflows

The goal is a single source of truth: strings flow from code or CMS into the TMS automatically, and translated strings flow back without manual file handling. Platforms like Ollang provide API-driven sync and CMS connectors to minimize manual file handling and preserve context metadata across the pipeline.

Why Context Metadata Matters

A string like "Save" could be a verb (save this document), a noun (a sale or discount), or a label on a button with a 40-pixel width constraint. Without context, translators guess, and guessing produces errors.

Effective context metadata includes:

• Screenshots or UI mockups showing where the string appears
• Developer notes explaining variables, placeholders, and intended meaning
• Character limits tied to UI layout constraints
• Placeholder descriptions (e.g., {user_name} = the logged-in user's display name)
• Gender and plurality information for languages with grammatical gender or complex plural rules

Investing in context metadata at extraction time reduces translation queries, shortens turnaround, and directly improves quality. According to CSA Research, context-related issues account for a significant share of localization defects, making this one of the highest-ROI interventions in the entire workflow.

Glossary and Style Guide Preparation

Creating a Localization Glossary

A glossary is a controlled vocabulary of terms that must be translated consistently across all content. It typically includes product names (which may remain untranslated), technical terms, branded phrases, and terms with domain-specific meanings.

Each glossary entry should contain:

Glossaries should be loaded into the TMS so that term consistency is enforced automatically during translation. Most modern TMS platforms flag glossary violations in real time, allowing translators to correct deviations before submission.

Developing Locale-Specific Style Guides

A style guide governs tone, formality, punctuation conventions, date and number formatting, and UI writing patterns for each target locale. It answers questions like:

• Should the product address the user formally (vous) or informally (tu) in French?
• Are Oxford commas used in the target language?
• How should error messages be structured, imperative, passive, or conversational?
• What is the preferred transliteration standard for non-Latin scripts?

Style guides prevent subjective disagreements during review and ensure that localized content feels native rather than translated. They should be co-authored with in-market linguists and reviewed annually.

Translation Paths: Human, MT+PE, and Hybrid

Not all content requires the same translation approach. The right path depends on content visibility, risk, volume, and turnaround requirements.

Human Translation

Human translation is the gold standard for high-visibility, high-risk content: marketing headlines, legal text, onboarding flows, and any copy that shapes brand perception. Professional linguists with domain expertise produce translations that are contextually accurate, culturally appropriate, and stylistically polished.

The tradeoff is speed and cost. Human translation throughput typically ranges from 2,000 to 3,000 words per linguist per day, and rates vary significantly by language pair and specialization.

Machine Translation with Post-Editing (MT+PE)

For high-volume, lower-risk content, support articles, internal documentation, user-generated content, machine translation with human post-editing offers a strong balance of speed and quality. Modern neural MT engines (DeepL, Google Cloud Translation, Amazon Translate) produce output that, for many language pairs, requires only light editing to reach publishable quality.

Post-editing is categorized into two levels:

• Light post-editing (LPE): Corrects only critical errors, meaning, omissions, egregious fluency issues. Suitable for content where gist accuracy is sufficient.
• Full post-editing (FPE): Brings MT output to human-quality standards, correcting fluency, style, terminology, and formatting. Suitable for customer-facing content.

Choosing the Right Path

Ollang supports all of these translation paths within a unified platform, integrating with major MT engines and centralizing routing and post-editing rules. If you're evaluating how to structure translation workflows across content tiers, book a demo with Ollang to see how routing automation works in practice: https://ollang.com/book-a-demo

Review Layers and Linguistic Quality Assurance

Translation alone is not enough. Every localized string must pass through structured review layers before it reaches production.

In-Context Review with Screenshots

Linguistic review performed in a spreadsheet, disconnected from the product UI, misses layout-dependent errors. In-context review, where reviewers see translated strings rendered in actual or simulated UI, catches truncation, overlapping elements, and contextual mismatches that are invisible in a flat file.

The most effective approach is to provide reviewers with annotated screenshots or, better yet, access to a staging environment with localized builds. Some TMS platforms support in-context editing overlays that render translations directly in a browser-based preview of the product.

Pseudolocalization as an Early Warning System

Pseudolocalization is a testing technique that replaces source strings with modified versions, adding accented characters, padding string length, and inserting markers for untranslated or hardcoded text. For example, the string "Save" might become "[Šåvé_____]".

This technique, applied before real translation begins, reveals:

• Hardcoded strings that were never externalized
• Truncation risks where UI elements can't accommodate longer translations (German and Finnish translations are often 30-40% longer than English)
• Concatenation bugs where string fragments are assembled programmatically
• Character encoding issues with non-ASCII characters
• Layout breaks in RTL (right-to-left) languages

Pseudolocalization should be run as part of the CI/CD pipeline, not as a one-time exercise.

Linguistic Quality Assurance (LQA)

LQA is a structured evaluation of translation quality using a standardized error typology. The most widely adopted framework is the Multidimensional Quality Metrics (MQM) model, which categorizes errors by type (accuracy, fluency, terminology, style, locale convention) and severity (critical, major, minor). See: http://www.qt21.eu/mqm-definition/

A typical LQA process involves:

1. Sampling a statistically significant set of translated strings per locale
2. Having an independent reviewer (not the original translator) evaluate each string against the MQM rubric
3. Calculating a quality score per locale and content type
4. Comparing scores against predefined pass/fail thresholds

LQA results feed back into translator performance management, glossary refinements, and style guide updates, creating a continuous improvement loop.

Functional Quality Checks

Beyond linguistic accuracy, localized strings must function correctly in the product. Functional checks include:

• Placeholder integrity: Do all variables ({count}, %s, {{name}}) survive translation intact?
• Truncation testing: Do translated strings fit within UI containers on all target devices and screen sizes?
• RTL rendering: For Arabic, Hebrew, Urdu, and other RTL languages, is text direction correct? Are UI elements mirrored appropriately?
• Plural rule compliance: Does the application handle plural forms correctly using CLDR rules and ICU MessageFormat where applicable?
• Encoding validation: Are all characters rendered correctly across browsers and platforms?

These checks should be automated wherever possible, integrated into the build pipeline, and gated as release criteria.

String Freeze, Versioning, and Rollback

Implementing a String Freeze

A string freeze is a defined point in the release cycle after which no new translatable strings are added or modified in the source. It gives the localization team a stable target to translate against and prevents the costly churn of re-translating strings that changed after translation was completed.

Best practices for string freeze:

• Announce the freeze date at sprint planning, not the day before release
• Enforce the freeze through branch protection rules or TMS configuration
• Allow only critical bug-fix string changes after the freeze, with an explicit approval process
• Communicate the freeze window clearly in the RACI (see below) so that product managers, engineers, and content authors all understand the constraint

A typical freeze window is 5-10 business days before release, depending on the number of target languages and translation path.

Versioning and Rollback Strategies

Localized resource files should be version-controlled alongside application code. This enables:

• Diffing: Identifying exactly which strings changed between releases
• Rollback: Reverting to a previous set of translations if a quality issue is discovered post-launch
• Branching: Supporting parallel localization for feature branches and hotfixes

Fallback Locales

Not every locale will be fully translated at launch. A fallback locale strategy defines what happens when a translation is missing. Common patterns include:

• Fallback to regional parent: es-MX falls back to es-ES if a string is untranslated
• Fallback to source language: Display the English string rather than an empty field or broken key
• Graceful degradation: Show a localized placeholder message ("Translation coming soon") for non-critical content

Fallback logic should be implemented in the application's i18n framework and tested explicitly during QA.

Governance Artifacts: RACI, SLAs, and Entry/Exit Criteria

A workflow without governance is just a suggestion. The following artifacts turn your localization process into a repeatable, accountable system.

RACI Matrix for Text Localization

R = Responsible, A = Accountable, C = Consulted, I = Informed

SLAs by Content Type

Entry and Exit Criteria by Stage

Extraction → Translation:

- Entry: Source strings are frozen, externalized, and loaded in TMS. Context metadata (screenshots, developer notes, character limits) is attached. Glossary and style guide are published.

- Exit: All strings have assigned translators/MT routing. No unresolved source queries.

Translation → Review:

- Entry: All strings translated. Automated QA checks (placeholder integrity, glossary compliance) pass.

- Exit: Reviewer approves translations. LQA score meets or exceeds threshold.

Review → Functional QA:

- Entry: Reviewed translations merged into localized build. Pseudolocalization issues resolved.

- Exit: No critical or major functional defects. RTL rendering verified. Truncation within tolerance.

Functional QA → Launch:

- Entry: All exit criteria from prior stages met. Fallback locales configured and tested.

- Exit: Pre-launch checklist complete. Stakeholder sign-off obtained.

Pre-Launch Checklist

Use this checklist as a final gate before shipping localized content to production.

• [ ] All P0 and P1 strings translated and reviewed for every target locale
• [ ] LQA scores meet defined thresholds (no locale below minimum pass score)
• [ ] Placeholder integrity verified across all locales (automated check)
• [ ] Truncation testing complete on target devices and screen sizes
• [ ] RTL layout verified for all applicable locales
• [ ] Plural forms tested for languages with complex plural rules
• [ ] Fallback locale behavior tested (missing strings display correctly)
• [ ] Glossary compliance verified (no unapproved term deviations)
• [ ] Localized builds deployed to staging and smoke-tested
• [ ] String freeze maintained, no unapproved changes after freeze date
• [ ] Version-controlled resource files tagged with release version
• [ ] Rollback plan documented and tested
• [ ] Stakeholder sign-off recorded (Product, Engineering, Localization, QA)

Frequently Asked Questions

How long should a string freeze last before release?

The freeze window depends on the number of target languages, the volume of new or changed strings, and your translation path. For teams localizing into 5-10 languages with a mix of human translation and MT+PE, a freeze of 7-10 business days before release is a practical starting point. Teams with highly automated pipelines and fewer languages may operate with a 3-5 day window. The key is that the freeze is announced early, enforced consistently, and respected by product and engineering teams.

What is the difference between LQA and in-context review?

LQA (Linguistic Quality Assurance) is a structured, metric-driven evaluation of translation quality using a standardized error typology like MQM. It produces a quantitative quality score. In-context review, by contrast, is a visual inspection of translations rendered in the actual product UI. It catches layout issues, contextual mismatches, and UX problems that LQA alone cannot detect. Both are necessary, LQA validates linguistic accuracy, while in-context review validates the user experience.

How do you handle translations for content that changes frequently?

For rapidly changing content (e.g., release notes, changelog entries, dynamic support articles), use a continuous localization model rather than a batch model. Strings are pushed to the TMS as soon as they are authored, translated via MT+PE for speed, and reviewed asynchronously. Delta workflows, where only new or modified strings are sent for translation, minimize redundant work. Translation memory ensures that repeated or similar content is leveraged automatically, reducing both cost and turnaround time.

When should pseudolocalization be introduced?

Pseudolocalization should be introduced as early as possible, ideally during the development phase, before any real translation work begins. Running it as part of the CI/CD pipeline ensures that internationalization defects (hardcoded strings, truncation risks, encoding issues) are caught before they become expensive to fix. It is not a substitute for real translation testing, but it is the fastest way to validate that your application is structurally ready for localization.

Build Your Localization Pipeline with Confidence

A reliable text localization workflow is not built from heroic last-minute efforts. It is built from clear stages, defined ownership, enforced quality gates, and the right tooling to connect them. The framework in this article, from source readiness through extraction, translation, review, QA, and launch, gives your team a repeatable system that scales with your product and your market ambitions.

Ollang provides the execution layer for this entire pipeline: text localization across UI strings, documentation, marketing, legal, and support content, with built-in translation quality review and API integration into your existing development workflow. If you're ready to move from ad hoc localization to a governed, high-confidence pipeline, book a demo with Ollang to see how it works end to end: https://ollang.com/book-a-demo