---
title: How localization works
description: English-pivot transcreation — one canonical content pipeline, a separate localize pipeline with its own deterministic QA gate, and one shared research corpus across all languages.
locale: en
version: 0.2.0
canonical: https://enterium-developer-docs.pages.dev/developers/how-it-works/localization/
---

> Documentation index: https://enterium-developer-docs.pages.dev/developers/llms.txt — every page of this portal has a Markdown twin at <route>.md; the frozen API contract is at https://enterium-developer-docs.pages.dev/developers/api/openapi.json.

**The problem:** running the full Collect → Generate → verify machinery
per language multiplies cost and splits the research corpus into
per-language silos that each mature slowly. The naive alternative —
"just translate" — ships literal translations that fail native reading
and lets translation errors bypass every quality gate built for English.

## Layer 1 — English is the pivot

The main pipeline stays **English-only**: collection, generation,
grounding and all quality gates operate on one canonical English article.
Localization is a **separate, downstream pipeline** with four steps:
select → transcreate → QA gate → publish. Nothing about the main
machinery changes per language.

```mermaid
flowchart LR
    CORPUS[(One research corpus<br/>per contract)] --> GEN[Generate EN<br/>all gates apply]
    GEN --> MASTER[Canonical EN article]
    MASTER --> LOC[Localize pipeline<br/>select → transcreate → QA → publish]
    LOC --> L1[es]
    LOC --> L2[de]
    LOC --> L3[zh …]
```

The key economic consequence: **the research corpus stays unified.** Every
language version grounds in the same facts, so the
[RAG flywheel](../rag-flywheel/) spins at full speed regardless of how
many languages ship — a per-language corpus would divide its momentum.

## Layer 2 — transcreation guarded by a deterministic gate

The localize QA gate mirrors the platform's
[quality doctrine](../quality-gates/): deterministic checks first, LLM
opinion last and only if everything else passed (an LLM verdict costs
money — spending it on a draft that already failed a mechanical check is
waste). The mechanical battery:

- **Structure parity** against the English master — sections, lists and
  FAQ must survive transcreation;
- **Per-script length bands** — expected length ratios differ by writing
  system (CJK compresses; the gate knows);
- **Language-leak checks** — English fragments left in the body, or worse,
  a third language substituted wholesale;
- **Foreign-script detector** — a run of characters from an unexpected
  script is an automatic flag.

## Layer 3 — publishing without breaking identity

Language versions publish as **filename-paired variants** of the master
page on the same site, giving the site generator what it needs for
language switchers and `hreflang` — while the canonical published-URL
registry keeps tracking the master article (locale pages record their own
live URLs alongside, without competing for the master's identity key).

## Trade-offs

Transcreation through an LLM is a quality risk by definition — that is
why the gate is deterministic-first and why a failed draft is held, not
auto-retried. And operationally: the localize pipeline is currently
registered for the **dev** contour only — the code has ridden to the
production branch, but no production catalog variant exists yet, so no
production dispatch can reach it. It is documented here as architecture
that exists, not as a switched-on production feature.

## See it in two minutes

The pipeline catalog lists `localize` with its variants — the honest
switched-on/not surface — and a localized article's variants are visible
right on the destination site's language switcher once a contract uses it.