Skip to content

How localization works

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.

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.

One research corpusper contractGenerate ENall gates applyCanonical EN articleLocalize pipelineselect transcreate QA publishesdezh

The key economic consequence: the research corpus stays unified. Every language version grounds in the same facts, so the 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

Section titled “Layer 2 — transcreation guarded by a deterministic gate”

The localize QA gate mirrors the platform’s quality doctrine: 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

Section titled “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).

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.

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.

Specs: SPEC-109 (English-pivot localization), SPEC-073 (published-URL identity).