Skip to main content

​
Compliance Translation Parity Tracker

The compliance corpus is the part of these docs a regional customer reads before signing: the regional rule pages (Brazil LGPD, Mexico NOM-184, the EU Digital Services Act and AI Act, KSA CST) and the tenant-control pages that describe the settings their compliance team configures in Orbit. This page is the standing tracker for how much of that corpus exists in each active translated locale, and the process that closes the gap. The English compliance corpus currently holds 185 pages. The active translated locales hold: Arabic 37, Spanish 27, French 26, German 26. The tables and policy below are the plan for closing that gap, ordered by market priority: Arabic, Spanish, French, German.

​
Language-parity policy

Regulatory guides ship in English first; localized peers follow within two releases. English remains the reviewed source of truth, so when a rule page changes between the English publish and its translation landing, the English page governs until the localized peer ships. Two classes of page carry different translation obligations, defined in the next section: regional-rule pages must exist in the language of the market they regulate, and universal-control pages must exist in all four active translated locales. A page that misses its window stays visible: every locale falls back to the complete English page at the locale-prefixed URL, so no reader ever meets a blank or pointer-only page. The fallback is stated behavior, documented in Docs languages and translations; it is not a substitute for the translation, and it does not stop a page from counting as a gap in the tables below.

​
Page classes: regional rules vs universal controls

Every compliance page belongs to exactly one class, and the class sets the translation obligation. Regional-rule pages are country- or region-specific: compliance/mx-nom-184-consent, compliance/lgpd-brazil, compliance/saudi-arabia-cst-sender-rules, compliance/eu-ai-act, compliance/uk-pecr-eprivacy, compliance/au-spam-act, compliance/casl-canada-anti-spam, compliance/dlt-india. A regional-rule page must be translated for the market it regulates: the Mexico page in Spanish, the Brazil page in Portuguese when that locale joins the active set, the KSA page in Arabic, the EU pages in the EU locales. In this tracker they are listed under “priority-30 backlog” only when their market is one of the four active locales; a page whose market has no active locale yet (for example Australia) waits for the locale to open. Universal-control pages describe tenant-owned controls that apply to every tenant regardless of market: the posture overview, consent management, opt-out suppression, quiet hours, the TCPA posture guide, STIR/SHAKEN attestation, data retention, the DPA, recording consent. A universal-control page must be translated for all four active translated locales (ar, es, fr, de), because every regional customer configures the same controls. Orbit documents tenant controls only; the tenant owns regulatory outcomes, so these pages describe the setting, its default, and its fail-open or fail-closed behavior, and never a platform-side mandate.

​
Current coverage

Counts are the .mdx files under each locale’s compliance/ mirror root. The translated sets are subsets of the English corpus; each page in a locale root pairs with a real English sibling, enforced by the parity gate referenced in the runbook below. The per-locale lists of which pages are covered live in the gate’s bounded stub set, not on this page; this page tracks the aggregate gap and the order in which it closes.

​
Priority-30 backlog

The next thirty translations, ordered for the four active locales. The regional rows are the sales-gating markets; the universal rows are the control pages every compliance team reads first. Backlog beyond the priority thirty is scoped per release against the counts above and recorded here in the same change that schedules the translation.

​
Maintainers’ runbook

When drafting a new compliance page:
  1. Classify it. Regional-rule or universal-control, per the definitions above. When in doubt, universal-control: the stricter obligation wins.
  2. Name the locale owners. For a regional page, the owner of the market locale; for a universal page, one owner per active locale (ar, es, fr, de).
  3. Schedule the translations before publish: universal pages inside the two-release parity window, regional pages with the market launch they support. A page may publish English-first, but the translation work items are opened in the same change, not after.
  4. Update this tracker’s counts and backlog in the same change that ships each translation, so the tracker never lags the tree.
Pre-publish checklist, pairing with the source-pin test that ships with this page:
  • Page classified regional or universal.
  • Locale owners named for every locale the class obligates.
  • Translation work items opened (or the page listed on this tracker’s backlog with a due release).
  • docs.json nav points at the English page path only; locale roots are never wired into nav.
  • New localized variants land in the locale mirror root and the parity gate’s bounded stub set in the same change.
  • This page’s counts re-run and updated.

​
Translation pipeline

Translation requests and completed translations follow the existing pipeline: the parity gate (apps/docs/scripts/check-docs-i18n-parity.mjs) holds the bounded set of pages a locale mirror may serve, the localization pin tests under apps/docs/__tests__/ assert each shipped variant carries its topic content, and Docs languages and translations documents the reader-facing behavior. Route any new compliance translation through the same pipeline: widen the gate’s stub set, land the localized .mdx mirror, and register a pin test for the variant in the same change.