The trial in https://gitlab.com/groups/gitlab-com/localization/-/work_items/174+ proved CI Translation Components can generate translation MRs against real production content. The strategic goal is a **git-native translation capability inside GitLab**: translations versioned next to their source and reviewed through the normal MR flow, and eventually a model GitLab customers could adopt (with _their_ less dependence on external routing). #### Decision (2026-08-18, updated 2026-08-26) 1. **_Continue_** CI Translation Components on about.gitlab.com (Spanish Solutions pages). 2. **_Pause_** the rest until the team can review and merge more Translation MRs at a controlled quality. Comment thread: https://gitlab.com/gitlab-com/localization/localization-team/-/work_items/879#note_3699721613 3. _\[Upd 2026-08-26\]_ Orbit is being paused as well. Its docs move to the Argo-Phrase workflow as an interim step, JA included, approved by `@mjsibanez` on 2026-08-24 in https://gitlab.com/gitlab-com/localization/localization-team/-/work_items/905#note_3725741231. MR: ci-translation-overlays!128+. KO and FR Component output is evaluated separately on the Orbit test fork in https://gitlab.com/gitlab-com/localization/localization-team/-/work_items/906+ (MR ci-translation-overlays!129+). #### Plan to **stabilize first:** * Paused: docs-gitlab-com and Operator ([!123](https://gitlab.com/gitlab-com/localization/ci-translation-overlays/-/merge_requests/123), merged 2026-08-25), charts ([!126](https://gitlab.com/gitlab-com/localization/ci-translation-overlays/-/merge_requests/126), 2026-08-18), Orbit ([!128](https://gitlab.com/gitlab-com/localization/ci-translation-overlays/-/merge_requests/128), open, per [#905+](https://gitlab.com/gitlab-com/localization/localization-team/-/work_items/905)). about.gitlab.com keeps delivering MRs to upstream prod. Clear the accumulated open MRs. * Note, verified 2026-08-26: every pipeline schedule on every fork is inactive, so the schedule-only forks translate nothing until a schedule is activated or run by hand. * Prove a paused fork restarts cleanly and catches up from where it stopped (https://gitlab.com/gitlab-com/localization/localization-team/-/work_items/879) #### A promising area where CI Translation can be adopted is, _sim-ship_ From a discussion with @mjsibanez, this reframes expansion from "onboard more repos" toward "sim-ship the specific content that benefits from it." CI Components is fast and git-native, which suits sim-ship: publishing a translation at the same moment the English change goes live. Orbit is close to this today. Candidates worth experimenting with: - Release posts (for example the GitLab 19.0 set, gitlab-org/gitlab!249905+), where a localized post live with the English announcement has real value. _\[Upd: 2028-08-20: aligned on this with @muchikawa and @emikimura-ext here: https://gitlab.com/gitlab-com/localization/localization-team/-/work_items/879#note_3708856292\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\]_ - The docs navigation file (`data/en-us/navigation.yaml` in docs-gitlab-com), which changes often (note: blocked today by the large-file bug https://gitlab.com/gitlab-com/localization/localization-team/-/work_items/849, so it would need that fixed first). #### Decide expansion Guided by the sim-ship lens above: prefer targets where simultaneous translation-with-English adds value (release posts, navigation), and take repo-level candidates (Runner, Omnibus, CLI docs [#814](https://gitlab.com/gitlab-com/localization/localization-team/-/work_items/814), charts) one at a time and _only once the conditions below hold._ **Secure the conditions before expanding:** - **Human team's MR review capacity.** Sett the cadence (scheduled / continuous), scope what each fork translates, and how the team, with any vendor support potentially, absorbs the MR review volume. - **Quality.** Overwrite protection (https://gitlab.com/gitlab-com/localization/localization-team/-/work_items/815), termbase coverage, AI output validation, and the GDATP specs work overall - **Consistency.** Homogenize the fork configs so every fork meant to deliver upstream is wired the same way (https://gitlab.com/gitlab-com/localization/localization-team/-/work_items/875). - **Demand.** Measure whether the translations we ship are actually read, traffic and engagement on the es Solutions pages and the ja Orbit docs, so we judge success by usage (pages read), the metric we are currently missing. Keep about.gitlab.com running as the live sample. Orbit's Japanese pages stay measurable after the interim move to Argo-Phrase, and KO and FR Component output is measured on the test fork in [#906+](https://gitlab.com/gitlab-com/localization/localization-team/-/work_items/906). cc @mjsibanez **Consistency of the configurations.** The 9 overlay files disagree on the settings that decide whether bad output reaches an MR (`allow_fallback`, `fail_on_corruption`, validators, scope files, draft titles). State documented 2026-08-26 (internal doc by @opysaryuk ) , policy proposal to follow. #### **How we expand, and when this stops being a proof of concept** _\[Added 2026-08-27\]_ The conditions above say what must be true before we expand. This says how we expand, and what finished looks like. **How we expand** 1. **One complete slice at a time.** A slice is one repository and one language, generated, reviewed, merged and measured. We do not onboard the next slice until the current one has completed that loop at least once. 2. **Reviewers before generation.** A named reviewer for every language a fork produces, agreed before the fork is switched on. No named reviewer means no generation. (this bullet is TBCoordinated with @mjsibanez ) 3. **A cap while we stabilize.** No more than two forks generating translations at any time until the review loop has run for a full month without a backlog. 4. **We answer a date with a scope.** Where a target date comes from outside the team, we come back with what we can complete by it (given engineering resources are available) and what would let us go further. **When this stops being a proof of concept** The components repository still describes itself as a proof of concept, while its output reaches repositories that customers read. It becomes version 1 when all of the following are true: * Every fork runs from a shared profile, one for documentation and one for marketing, rather than a hand-written config. * The safety settings are identical everywhere: behaviour on AI failure, behaviour on damaged output. * Output checks run on every fork that generates: the Markdown structure check on documentation, the YAML structure check on marketing, and the untranslated-content check on both. * Every fork states, in one line, what it translates, into which languages, where its merge requests open, and who reviews them. * The components are released with version numbers, and a new version runs on a test fork before production forks take it. * Every fork that is meant to run has an active schedule with a named owner. Target for the above: _\[TBD by_ @opysaryuk _\]_. Configuration state as of 2026-08-26 is documented internally, and none of the six bullets above is true today. #### How this backlog is organized The plan above sets what we do first. Below is the full backlog, grouped by theme with _no fixed sequence._ We pull items from it as items are prioritized against that plan. - Bugs - what's broken today: ci-translation-components#11 (closed), localization-team#805, localization-team#807, localization-team#817, localization-team#849, localization-team#857 - Quality - what makes the translations better: localization-team#741, localization-team#815, localization-team#844, localization-team#845, localization-team#848, localization-team#892 - Operations - what keeps it running day to day: localization-team#761, localization-team#770, localization-team#812, localization-team#819, localization-team#822, localization-team#842, localization-team#875, localization-team#879 - Expansion - what we translate next, one at a time: localization-team#810, localization-team#814, localization-team#885, docs-site-localization#1023 - Discovery - what we're still figuring out: ci-translation-components#13 (closed), localization-team#828, localization-team#829, localization-team#843 #### DRIs | Area | DRI | |------|-----| | Engineering | @rasamhossain | | Product ownership of CI Components and GDATP quality specs | @opysaryuk | | Localization programs and business requirements | @mjsibanez | #### #### Related * Rollout trial: https://gitlab.com/groups/gitlab-com/localization/-/work_items/174+ * Pause decision: https://gitlab.com/gitlab-com/localization/localization-team/-/work_items/879+ (comment thread) https://gitlab.com/gitlab-com/localization/localization-team/-/work_items/879#note_3699721613 * Whole-stack context: https://gitlab.com/gitlab-com/localization/localization-team/-/work_items/824+