CI Translation Components

Was

Übersetzung findet in den meisten Unternehmen außerhalb der Werkzeuge statt, mit denen Entwicklerinnen und Entwickler tatsächlich arbeiten. Inhalte werden exportiert, an einen Dienstleister geschickt, irgendwo anders übersetzt und Wochen später wieder eingefügt — und bis dahin hat sich die Quelle längst weiterbewegt. Das Ergebnis sind lokalisierte Inhalte, die strukturell und dauerhaft veraltet sind.

CI Translation Components begann als mein Beitrag zu GitLabs AI Enterprise Hackathon 2026: eine Sammlung wiederverwendbarer GitLab-CI/CD-Komponenten, die Übersetzung als Pipeline-Stufe behandeln und nicht als Nebenschauplatz. Eine Quelldatei ändert sich, CI bemerkt es, der Inhalt wird übersetzt, und die Übersetzung erscheint als gewöhnlicher Merge Request im selben Repository — prüfbar, zurücknehmbar und nachvollziehbar wie jede andere Änderung.

Der Trial war bewusst eng gefasst. Ziel von v1 war nicht, jeden Lokalisierungsfall zu lösen, sondern zu belegen, dass eine CI-Komponente eine kleine, klar abgegrenzte Menge echter Produktionsinhalte zuverlässig verarbeiten und die richtigen Merge Requests erzeugen kann, ohne dass jemand daneben steht. Etwas zu bauen, das Kundinnen und Kunden übernehmen können, hieß, es zuerst selbst zu benutzen.

Ich habe die Roadmap geschrieben und das Epic als Gesamt-DRI verantwortet, gemeinsam mit der DRI für Linguistic Quality Assurance, die für die Übersetzungsqualität zuständig war.

Wie

Aufbau der Pipeline. Quelländerung → Erkennung → Übersetzung → Commit → Merge Request → Auto-Merge. Jeder Modellaufruf läuft über das GitLab AI Gateway; der Runner spricht nie direkt mit einer Anbieter-API. Genau das machte das Ganze im Security-Review vertretbar.

Qualität beginnt, bevor das Modell ein Wort sieht. Nichts wird ohne Kontext übersetzt. Jeder Job stützt sich auf drei Grundlagen: eine Reihe von Spezifikationen dazu, was und wie übersetzt wird, eine in GitLab gepflegte Termbase und Übersetzungsanweisungen, die Ton, Stil und lokale Konventionen festlegen. Weil alle drei unter Versionskontrolle stehen, sind Terminologie und Tonalität prüfbar, vergleichbar und klar verantwortet — genau wie die Inhalte, die sie prägen.

Review bleibt daneben, nicht davor. An dieser Entscheidung hing der ganze Trial. Wenn eine Linguistin freigeben muss, bevor ein Übersetzungs-MR gemergt werden darf, sinkt der Durchsatz auf das Tempo menschlicher Prüfung — und man hat den Dienstleister-Engpass innerhalb von CI neu gebaut. Stattdessen findet die erste Prüfung dort statt, wo die Übersetzung ankommt: GitLab Duo prüft den Merge Request, sobald er eintrifft, und macht das schon allein erstaunlich gut. Die linguistische Prüfung setzt anschließend nach dem Merge ein — ein Translation-Review-Flagger-Flow öffnet asynchrone Tracking-Issues in einem separaten Projekt linguistic-review-tracker —, sodass Qualitätsprobleme gefunden und behoben werden, ohne die Pipeline aufzuhalten.

Die Qualitätslatte ist konfigurierbar, nicht fest. Wer eine höhere Latte braucht, hat reichlich Stellschrauben, alle nativ in GitLab: eigene MR-Review-Anweisungen für Duo, zusätzliche CI-Jobs mit eigenen Prüfungen, Vale-Regeln für Stil und Terminologie und die üblichen Approval-Regeln. Die Komponente setzt einen sinnvollen Standard; jedes Projekt entscheidet selbst, wie streng es die Linie hält.

Blinde Flecken vor der Produktion. Bevor irgendetwas Kundenseitiges angefasst wurde, liefen zwei parallele Arbeitsstränge gegen Forks — spanische Solutions-Seiten auf einem about.gitlab.com-Fork und /docs auf einem GitLab-Operator-Testfork. Forks zuerst bedeutete, dass die gefundenen Fehlerbilder nichts kosteten. Die eine harte Voraussetzung war unspektakulär: die Bereitstellung von AI_API_KEY und GITLAB_API_TOKEN auf Gruppenebene, die bis dahin jede Produktions-Pipeline blockierte.

Erste Produktionswelle. Vier Projekte, ausgewählt, weil sie echt, aber begrenzt waren:

Orbit war der Beweis für kontinuierlich: Ich habe die gesamte Dokumentation ins Japanische übersetzt und sie aktuell gehalten, während sich die Quelle änderte — Übersetzungs-MRs landeten typischerweise etwa 20 Minuten nach dem Quell-Commit.

Linguistinnen und Linguisten liefern Releases — von Anfang bis Ende. Der stärkste Beleg war keine Seitenzahl, sondern wer am Steuer saß. Ich habe unser Linguistik-Team in die Lage versetzt, diese Pipelines selbst zu konfigurieren und Übersetzungen eigenständig von der Quelländerung bis zum gemergten MR umzusetzen — ohne Engineering dazwischen. Damit haben sie die Releases 19.2, 19.3 und 19.4 im Simship auf Japanisch veröffentlicht, am selben Tag wie das englische Original statt Wochen später. Genau dafür wurde das Projekt gebaut: Lokalisierung in den Händen derer, die die Sprache verantworten — auf derselben Plattform wie alles andere.

Rollout in drei Phasen. Zuerst blinde Flecken identifizieren, dann Produktion aktivieren, dann volle operative Abdeckung — jeweils mit Datum und benannter Verantwortung statt eines vagen „wenn es fertig ist".

Sicherheit von Anfang an. Least-Privilege-Zugriff für die Komponente und ihre Service-Accounts, maskierte und verborgene Secrets, jeder Lauf nachvollziehbar von der Anfrage über die Pipeline bis zum MR, und ein Rollback-Pfad, den jede DRI sofort ausführen konnte. Dass das vor dem Rollout festgehalten wurde, war der Grund, warum der Trial danach schnell vorankam.

Ergebnisse

Der Trial lief seinen Zeitraum, das Epic wurde im August 2026 geschlossen. Was dabei herauskam:

• CI Translation Components laufen in Produktion auf echten Projekten; Übersetzungen landen als Merge Requests in den Repositories, die den Inhalt besitzen.
• Ein dokumentierter, wiederholbarer Workflow von Anfrage → CI-Ausführung → Übersetzungs-MR → Review → Merge, mit benannten Verantwortlichen, Monitoring und Support-Pfaden — genau das, was fehlte, solange es nur eine Hackathon-Demo war.
• Runbooks für Kundschaft, nicht nur für uns: wie man die Komponente übernimmt, wie man einen fehlgeschlagenen Job debuggt und wie man Änderungen anfragt oder beiträgt. Der Sinn des Dogfooding war immer die Weitergabe.
• Ein klarer Weg nach vorn. Der Trial endete mit einem ausgearbeiteten Epic zum Stabilisieren und Ausweiten statt mit einer Siegesrunde — das ist das ehrliche Ergebnis. Die Produktion lehrte uns etwas über Token-Rotationen, die Forks pausieren, über Nachverarbeitung, die gehärtet werden musste, und über Konfigurationsrichtlinien, die bewusst entschieden und nicht geerbt werden sollten. Jede dieser Lektionen ist als abgegrenzte, dokumentierte Arbeit festgehalten, sodass alle, die die Komponenten als Nächstes übernehmen, mit einem Plan und einer funktionierenden Produktionsbasis starten — nicht bei null.

Die Zielwerte, an denen der Trial gemessen wurde und die vorab festgelegt waren: eine Pipeline-Erfolgsquote von mindestens 50 % der Produktionsläufe ohne manuellen Engineering-Eingriff, erfolgreiche MR-Erstellung bei mindestens 80 % der erfolgreichen Läufe und ein Median von der Quelländerung bis zum offenen MR innerhalb eines Werktags, mit Minuten als Stretch-Ziel. Die japanische Orbit-Doku erreichte das Stretch-Ziel regelmäßig, mit etwa 20 Minuten Durchlaufzeit.