Japanische Produktdokumentation

Was

GitLabs Produkt ist lokalisiert. Seine Dokumentation war es nicht — in GitLabs größten nicht-englischen Märkten konnten Kundinnen und Kunden das Produkt also in ihrer Sprache benutzen und stießen genau dann auf eine Wand aus Englisch, wenn sie etwas nachschlagen mussten. Die Forschungslage ist eindeutig: Interessenten kaufen eher, wenn sie es in ihrer Muttersprache tun können. Und der Wettbewerbsmaßstab hatte sich längst verschoben — GitHub begann 2022 mit der Lokalisierung seiner Dokumentation und liefert inzwischen acht Sprachen.

Localization und Technical Writing haben gemeinsam ein Programm aufgesetzt, um die Dokumentationsseite für GitLabs Tier-1-Märkte zu lokalisieren — Japanisch, Deutsch und Französisch — beginnend mit Japanisch, nachdem die Migration der Doku-Site auf Hugo einen mehrsprachigen Build überhaupt erst möglich machte.

Ich habe die Engineering-Seite übernommen: die Site-Infrastruktur, die dafür sorgt, dass sich eine zweite Sprache korrekt verhält, die domänenübergreifende Übergabe von gitlab.com/help und den Launch selbst.

Wie

Die Sprache einzuschalten war eine Zeile. Das Recht dazu zu erarbeiten dauerte vierzehn Monate. Der Merge Request, der Japanisch live schaltete, setzte disabled: false für die Sprache ja-jp in config/_default/hugo.yaml. Alles Interessante lag darin, was vorher wahr sein musste.

Die Sprachauswahl reparieren, bevor sie jemand benutzt. Die Auswahl setzte Leserinnen und Leser ursprünglich an den Anfang der Seite in der Zielsprache. In einer Dokumentation — wo man üblicherweise tief in einem bestimmten Abschnitt einer sehr langen Seite steckt — ist das ein leise zur Weißglut treibender Fehler. Ich habe onLanguageSelect so geändert, dass der aktuelle Seiten-Hash mitgenommen wird: #global-keywords auf der englischen Seite landet nun auf /ja-jp/ci/yaml/#global-keywords. Übersetzte Seiten behalten die englischen Anker-IDs, deshalb funktioniert das heute; wo eine Seite keinen passenden Anker hat, lädt sie einfach von oben statt zu brechen. Ausgeliefert im September, drei Monate vor dem Launch — damit war es nie Teil des Launch-Risikos.

Die Übergabe /help → docs.gitlab.com verfolgen. Das feine Risiko lag nicht bei der Doku-Site — die speichert keine Sprachpräferenz — sondern bei gitlab.com, das es tut. Wer auf gitlab.com eine japanische Präferenz hinterlegt hat und zur Doku durchklickt, überschreitet eine Domaingrenze, an der Browser Überraschendes tun können. Die Untersuchung brachte eine echte Einschränkung zutage: die Doku-Site hat außer Review-Apps keine Staging-Umgebung, und /help wird normalerweise nur in der GDK getestet. Die Verifikation musste also aus Review-Apps und lokalen GDK-Läufen zusammengesetzt werden statt aus einem Staging, das es nicht gab.

Launch nach Uhr — und in der richtigen Zeitzone. Das Deployment war auf 12:00 PST am Mittwoch, 10. Dezember 2025 — 05:00 JST am 11. angesetzt, damit japanische Leserinnen und Leser damit aufwachen und es nicht mitten am Nachmittag erscheinen sehen. Der Launch war in drei nachverfolgte Teile mit getrennter Verantwortung aufgeteilt: Site-Deployment, Monitoring und QA während und nach dem Launch sowie der Ankündigungs-Blogpost. Das GTM-Launch-Epic bündelte die QA-Runden, Bugfixes und die interne wie externe Kommunikation an einem Ort, damit Feedback nach dem Launch einen Platz hatte.

Ergebnisse

• docs.gitlab.com/ja-jp ist live, und Japanisch ist die erste lokalisierte Sprachversion der GitLab-Dokumentation. Der Merge Request wurde planmäßig am 10. Dezember 2025 gemergt.
• Die Sprachauswahl behält die Position auf der Seite, wodurch ein Sprachwechsel zur Navigation wird und nicht zum Neuanfang — eine kleine Korrektur mit überproportionaler Wirkung darauf, ob sich lokalisierte Dokumentation benutzbar anfühlt oder nur vorhanden.
• Ein wiederholbarer Weg für Deutsch und Französisch. Die mehrsprachige Hugo-Konfiguration, das Verhalten der Sprachauswahl, die /help-Übergabe und die QA-Routine sind jetzt sprachunabhängig. Die nächste Sprachversion ist ein Inhalts-, kein Infrastrukturproblem — und genau darum ging es, die erste sorgfältig zu machen.
• Ein dokumentiertes Launch-Muster: Deployment, Monitoring und Ankündigung als drei separat verantwortete Stränge mit fester Umschaltzeit in der Zeitzone der Lesenden.