Continuous Localization: Wie du Übersetzungen mit deiner Codebasis synchron hältst

Continuous Localization: Wie du Übersetzungen mit deiner Codebasis synchron hältst

TL;DR / Wichtigste Erkenntnisse

• Continuous Localization behandelt Übersetzung als fortlaufenden Pipeline-Schritt, nicht als einmalige Aufgabe zum Release-Zeitpunkt — genauso wie CI/CD Tests und Deployments behandelt.
• Batch-Übersetzungsworkflows versagen, wenn Release-Zyklen schneller werden: Strings veralten, Merge-Konflikte häufen sich, und Übersetzer verlieren den Kontext.
• Eine funktionierende Continuous-Localization-Pipeline hat sechs Phasen: Code-Änderung, String-Extraktion, Übersetzungs-Trigger, Review, Merge und Deploy. Jede Phase kann in unterschiedlichem Ausmaß automatisiert werden.
• Wichtige Integrationsmuster unterscheiden sich darin, wie sie den Sync auslösen: Webhooks von deinem VCS, CLI-basierte Push/Pull-Befehle in CI-Schritten, File Watcher für die lokale Entwicklung und OTA/CDN-Delivery für deploy-freie Updates.
• Kein einzelnes Tool löst jeden Teil dieses Problems. Das richtige Setup hängt von deinem Release-Rhythmus, der Anzahl der Sprachen, dem Translator-Workflow und davon ab, ob Over-the-Air-Updates für dein Produkt relevant sind.

Was ist Continuous Localization?

Continuous Localization ist die Praxis, Übersetzung als kontinuierlichen, automatisierten Prozess in deinen Software-Entwicklungslebenszyklus zu integrieren — statt als manuellen Schritt, der einmal pro Release-Zyklus stattfindet.

Um zu verstehen, warum das wichtig ist, betrachte den Kontrast zum traditionellen Ansatz — oft Batch-Übersetzung oder Waterfall-Übersetzung genannt. In einem Batch-Workflow schließt ein Entwickler ein Feature ab, ein Product Manager sammelt alle neuen Strings in einer Tabelle oder einem Export, ein Localization Manager reicht sie bei Übersetzern (intern oder extern) ein, Übersetzungen kommen Tage oder Wochen später zurück, ein Entwickler importiert sie, und das Release wartet auf den letzten Locale, der fertig wird. Dieser Zyklus funktionierte einigermaßen gut, als Software quartalsweise ausgeliefert wurde. Er bricht zusammen, wenn Teams wöchentlich oder täglich shippen.

Die Analogie zu CI/CD ist direkt. Bevor Continuous Integration aufkam, arbeiteten Entwickler auf langlebigen Branches, Integration fand spät statt, und die Kosten für Merge-Konflikte skalten mit der Zeit. CI verlagerte Integration früher und häufiger, was diese Kosten drastisch senkte. Continuous Localization tut dasselbe für Übersetzungen: Statt String-Änderungen über einen Sprint anzusammeln und sie zum Release-Zeitpunkt abzugleichen, löst jede Code-Änderung sofort die Übersetzungs-Pipeline aus.

Dieses Konzept wird manchmal als Shift-Left-Localization bezeichnet — dasselbe „Shift Left"-Konzept, das beim Testing angewendet wird, wo das frühere Auffinden von Problemen günstiger ist als das spätere. Ein String, der an dem Tag in die Übersetzungs-Pipeline gelangt, an dem er geschrieben wird, wird mit vollem Kontext, ohne Rückstand und ohne das Risiko übersetzt, den Release zu blockieren. Ein String, der einen Tag vor dem Release in die Pipeline gelangt, wird unter Druck übersetzt — oft ohne Kontext, oft zusammen mit 400 anderen Strings, und oft beim ersten Mal falsch.

Continuous Localization bedeutet nicht, dass jeder String in Stunden übersetzt und ausgeliefert wird. Maschinelle Übersetzung kann diese Lücke für Geschwindigkeit füllen, mit anschließendem menschlichem Review. Was es strukturell bedeutet, ist, dass die Pipeline immer läuft: Neue Strings fließen automatisch ein, Übersetzer-Queues werden inkrementell aktualisiert, und Übersetzungen fließen zurück in die Codebasis oder den Delivery-Layer — ohne dass ein Mensch jeden Übergabepunkt orchestriert.

Warum Batch-Übersetzung versagt

Batch-Übersetzung ist nicht grundsätzlich falsch — für Projekte, die selten ausgeliefert werden oder eine kleine Anzahl von Strings verwalten, ist sie ein vernünftiger Ansatz. Aber für Engineering-Teams auf CI/CD-Pipelines erzeugen Batch-Workflows vier spezifische Failure-Modi.

Release-Verzögerungen. Wenn Übersetzung eine Voraussetzung für das Shippen ist und Übersetzung eine Batch-Aufgabe ist, die nach dem Feature-Freeze ausgelöst wird, ist der Release-Zeitplan durch den Durchsatz der Übersetzer begrenzt. Teams, die kontinuierlich shippen, können keinen Lokalisierungsschritt akzeptieren, der fünf Werktage dauert. Der Release wird entweder ohne übersetzte Strings ausgeliefert (mit Fallback auf die Quellsprache, oft Englisch) oder er wartet — beides ist nicht akzeptabel in großem Maßstab.

Veraltete Übersetzungen. In einem Batch-Modell werden Strings oft aus einer Codebasis exportiert, die sich bereits weiterentwickelt hat. Bis die Übersetzungen ankommen, können sich die Strings selbst geändert haben — eine Button-Beschriftung wurde umformuliert, ein Screen wurde neu gestaltet, ein Feature wurde entfernt. Übersetzer arbeiten mit einem veralteten Snapshot. Das Ergebnis sind Übersetzungen, die nicht zum Live-Produkt passen, oder Übersetzungsarbeit, die verworfen und wiederholt werden muss.

Merge-Konflikte in Übersetzungsdateien. Wenn mehrere Entwickler parallel arbeiten und Übersetzungsdateien im Repository liegen (als JSON, YAML, XLIFF oder ähnlichem), erzeugen gleichzeitige Änderungen an diesen Dateien Merge-Konflikte. Anders als Konflikte in der Anwendungslogik sind Konflikte in Übersetzungsdateien mühsam und fehleranfällig zu lösen: Zwei Branches haben beide neue Keys hinzugefügt, beide einen Key gelöscht, beide einen Key unterschiedlich umbenannt. Je größer der Batch, desto schlimmer die Konflikte.

Reibung zwischen Entwicklern und Übersetzern. In einem Batch-Workflow ist der Übergabepunkt zwischen Entwickler und Übersetzer ein manueller, oft asynchroner Prozess, der auf Konventionen basiert, die unter Zeitdruck zusammenbrechen. Entwickler vergessen den Export. Übersetzern werden Dateien ohne Kontext übergeben. Keys werden zwischen Export und Import umbenannt. Importe überschreiben Änderungen, die Übersetzer direkt vorgenommen haben. Keiner dieser Fehler ist einzeln katastrophal — aber sie summieren sich. Mit der Zeit führt die Reibung dazu, dass Teams die Qualität der Lokalisierung vernachlässigen, und Lokalisierungsschulden häufen sich genauso an wie technische Schulden.

Die Continuous-Localization-Pipeline

Eine Continuous-Localization-Pipeline bewegt String-Änderungen durch sechs Phasen. Die Pipeline wird durch eine Code-Änderung ausgelöst, nicht durch eine menschliche Entscheidung. Jede Phase erzeugt einen deterministischen Output, den die nächste Phase ohne manuelle Intervention verarbeiten kann.

Code-Änderung
    |
    v
String-Extraktion
    |
    v
Übersetzungs-Trigger
    |
    v
Übersetzung (MT + menschliches Review)
    |
    v
Merge zurück ins Repository (oder Push zum CDN)
    |
    v
Deploy (oder OTA-Update, wenn CDN-basiert)

Phase 1: Code-Änderung. Ein Entwickler fügt einen übersetzbaren String in der Codebasis hinzu, ändert oder entfernt ihn. Mit einem guten i18n-Setup bedeutet das, eine Key-Value-Datei (JSON, YAML, XLIFF) zu aktualisieren oder eine Key-Referenz im Code hinzuzufügen, die zur Laufzeit aufgelöst wird.

Phase 2: String-Extraktion. Die Pipeline identifiziert, welche Strings neu, geändert oder gelöscht wurden, indem sie den aktuellen Stand mit dem vorherigen Extraktions-Snapshot vergleicht. Dies wird typischerweise vom CLI des Lokalisierungstools oder einem CI-Skript übernommen. Der Output ist ein Diff der String-Änderungen — nicht ein vollständiger Export aller Strings, nur das Delta. Tools, die bei jeder Ausführung vollständige Exporte statt Diffs berechnen, erzeugen unnötige Übersetzerarbeit und erschweren die Priorisierung neuer Strings.

Phase 3: Übersetzungs-Trigger. Neue und geänderte Strings werden an das Translation Management System (TMS) gesendet. Dies kann über einen Webhook (VCS-Event löst einen API-Call zum TMS aus), einen CI-Schritt (ein CLI-Befehl pusht den String-Diff nach einem erfolgreichen Build) oder einen File Watcher (in der Entwicklung überwacht ein lokaler Agent Dateiänderungen und synchronisiert kontinuierlich) geschehen. Der Trigger sollte automatisch sein — ein menschliches Eingreifen an diesem Schritt führt das Batch-Problem wieder ein.

Phase 4: Übersetzung. Übersetzer (menschlich oder maschinell, oder eine Kombination) arbeiten an den neuen Strings im TMS. Gut gestaltete Systeme stellen Screenshots, Komponentenkontext, Zeichenbeschränkungen und benachbarte Strings bereit, um Übersetzern zu helfen, genaue Übersetzungen ohne Hin-und-Her zu erstellen. Maschinelle Übersetzung kann automatisch Erstentwürfe erstellen; menschliche Reviewer konzentrieren sich auf Genauigkeit, Markenstimme und kontextsensitive Korrekturen.

Phase 5: Merge. Fertige Übersetzungen werden als Pull Request zurück ins Repository gepusht oder direkt in einen Übersetzungs-Branch committed — je nach deinem Governance-Modell. Für OTA-fähige Plattformen pusht dieser Schritt übersetzte Strings zu einem CDN oder API-Endpunkt — das Repository wird für den Delivery-Pfad vollständig umgangen.

Phase 6: Deploy. Bei dateibasierter Delivery werden Übersetzungen im nächsten Build gebündelt und mit der Anwendung deployed. Bei CDN-basierter Delivery sind Übersetzungen bereits live am Edge — die Anwendung holt sie beim nächsten Request ab, ohne einen neuen Deploy.

Das kritische Designprinzip ist, dass die Phasen 2 bis 5 für maschinell übersetzte Inhalte vollständig automatisiert sein sollten, wobei menschliches Review als optionale Ebene die Qualität verbessert, aber die Lieferung nicht blockiert. Menschliches Review sollte asynchron sein: Zuerst die MT-Übersetzung veröffentlichen, sie durch die geprüfte Übersetzung ersetzen, wenn sie fertig ist.

Integrationsmuster

Wie du deine Codebasis mit deiner Übersetzungs-Pipeline verbindest, bestimmt, wie viel des oben Beschriebenen tatsächlich automatisiert werden kann. Es gibt vier primäre Integrationsmuster, jedes mit unterschiedlichen Trade-offs.

VCS-Webhook. Deine Repository-Hosting-Plattform (GitHub, GitLab, Bitbucket) sendet ein HTTP-Event an das TMS, wenn ein Commit oder Pull Request erstellt wird. Das TMS analysiert den Payload, identifiziert geänderte Dateien, extrahiert neue Strings und stellt sie in die Warteschlange für die Übersetzung. Dies erfordert keine Änderungen an deiner CI-Pipeline und funktioniert auch bei Branches, bevor sie in main gemergt werden. Die Einschränkung ist, dass das TMS dein Dateiformat und deine Projektstruktur verstehen muss — die Konfiguration erfolgt auf der TMS-Seite, nicht in deiner Codebasis.

CI-Schritt (CLI). Deine CI-Pipeline enthält einen Schritt, der den TMS CLI ausführt, um neue Strings zu pushen und optional übersetzte Strings zu pullen. Dies ist das flexibelste Muster, weil das Skript in deiner CI-Umgebung mit vollem Zugriff auf den Build-Kontext läuft. Der GitHub Actions Marketplace und GitLab CI enthalten offizielle oder community-gepflegte Actions für die meisten großen TMS-Plattformen. Der Trade-off ist, dass du die CLI-Version, Authentifizierungsdaten als Secrets und die Reihenfolge der Push/Pull-Schritte relativ zu Build-Schritten verwalten musst.

File Watcher. Ein lokaler Daemon überwacht deine Übersetzungsdatei-Verzeichnisse und synchronisiert Änderungen in Echtzeit mit dem TMS, während du Code schreibst. Dies ist primär ein Developer-Experience-Tool: Übersetzer sehen neue Strings innerhalb von Sekunden, nachdem ein Entwickler sie hinzugefügt hat, statt auf einen CI-Run zu warten. Es ist nicht als Produktions-Pipeline-Mechanismus geeignet, da es davon abhängt, dass ein Entwickler den Daemon laufen hat, und ein konsistentes lokales Setup im Team erfordert.

OTA / CDN Delivery. Statt übersetzte Strings ins Repository zu committen und sie in einem Deploy zu bündeln, holt die Anwendung Übersetzungen zur Laufzeit von einem CDN oder einer API. Updates an Übersetzungen sind sofort global verfügbar, ohne einen neuen Build oder Deploy. Dieses Muster erfordert, dass die Anwendung für das Laden von Übersetzungen zur Laufzeit ausgelegt ist — was in den meisten modernen i18n-Bibliotheken Standard ist — und führt eine Laufzeitabhängigkeit vom CDN ein. Es ist das betrieblich agilste Muster für UI-Strings.

Die meisten Produktions-Setups kombinieren Muster: einen CI-Schritt (oder Webhook), um das TMS mit der Codebasis synchron zu halten, plus CDN-Delivery für String-Updates, die keinen neuen Deploy erfordern.

Wichtige Funktionen, auf die man achten sollte

Nicht alle Lokalisierungsplattformen unterstützen echte Continuous Localization. Bei der Evaluierung von Tools sind dies die Funktionen, die bestimmen, ob eine Plattform tatsächlich in eine CI/CD-Pipeline integriert werden kann, statt als manuelles Übersetzungsportal genutzt zu werden.

Automatische Erkennung neuer und geänderter Strings. Die Plattform sollte String-Änderungen automatisch aus einem File-Diff oder VCS-Event identifizieren, ohne einen manuellen Export zu erfordern. Plattformen, die verlangen, dass du bei jeder Änderung eine vollständige Datei exportierst und neu importierst, sind nicht für kontinuierliche Workflows ausgelegt.

Übersetzerkontext. Übersetzer, die an einzelnen Strings isoliert arbeiten, produzieren Übersetzungen von geringerer Qualität als Übersetzer, die sehen können, wo ein String in der UI erscheint. Die besten Plattformen akzeptieren Screenshots, Komponenten-Metadaten oder In-Context-Editing, das den String im tatsächlichen Produkt gerendert zeigt. Ohne Kontext werden kurze Strings wie „Speichern", „Ansehen" oder „Abbrechen" regelmäßig falsch übersetzt, weil ihre Bedeutung ohne Kontext mehrdeutig ist.

Branching-Unterstützung. Wenn dein Team Feature-Branches verwendet, sollte deine Lokalisierungsplattform Übersetzungs-Branches unterstützen, die deine VCS-Branches spiegeln. Strings auf einem Feature-Branch sollten übersetzbar sein, bevor der Branch in main gemergt wird — sonst sind Übersetzungen immer mindestens einen Merge-Zyklus hinter dem Code.

Pseudo-Lokalisierung für Tests. Pseudo-Lokalisierung ersetzt Zeichen in Quell-Strings durch visuell ähnliche erweiterte lateinische Zeichen, um übersetzten Text zu simulieren, ohne tatsächliche Übersetzung. Es erkennt Layout-Bugs — Text-Overflow, abgeschnittene Labels, hartcodierte Breitenannahmen — früh in der Entwicklung, bevor echte Übersetzungen verfügbar sind. Eine Plattform, die automatische Pseudo-Locale-Generierung unterstützt, ermöglicht UI-Tests in jedem Locale zu jedem Zeitpunkt der Entwicklung.

Over-the-Air (OTA) Updates ohne Redeploy. Für Anwendungen, bei denen das Ausliefern eines neuen Builds zur Aktualisierung einer Übersetzung zu langsam oder zu kostspielig ist — mobile Apps, Desktop-Anwendungen oder hochfrequente Web-Apps — ist OTA-Delivery unerlässlich. Die Plattform sollte Übersetzungen von einem global verteilten Edge-Cache mit geringer Latenz und automatischer Cache-Invalidierung bereitstellen, wenn Übersetzungen veröffentlicht werden.

Translation Memory und Konsistenzerzwingung. Translation Memory verwendet früher übersetzte Strings über Projekte und Kontexte hinweg wieder, reduziert den Aufwand für Übersetzer und verbessert die Konsistenz. Konsistenzerzwingung kennzeichnet Strings, die einem früher übersetzten Begriff entsprechen, aber unterschiedlich übersetzt wurden — und erkennt so Terminologiedrift in einem großen Projekt.

Häufige Fallstricke

Continuous-Localization-Pipelines führen spezifische Failure-Modi ein, die sich von manuellen Workflow-Problemen unterscheiden. Dies sind die häufigsten.

Zu viel Automatisierung ohne QA-Ebene. Vollständig automatisierte maschinelle Übersetzungs-Pipelines können Übersetzungen mit hoher Geschwindigkeit ausliefern. Sie können auch falsche Übersetzungen mit hoher Geschwindigkeit ausliefern. Maschinelle Übersetzung ohne jedes menschliche Review ist für interne Tools und wenig kritische UI-Strings geeignet. Für kundenseitige Marketingtexte, rechtliche Hinweise, Fehlermeldungen oder alles, was Markenstimme widerspiegelt, ist ein menschlicher Review-Schritt nicht optional. Gestalte deine Pipeline so, dass MT-Übersetzungen sofort als Fallback veröffentlicht werden, wobei menschlich geprüfte Übersetzungen sie asynchron ersetzen — blockiere die Veröffentlichung nicht durch menschliches Review, behandle MT aber auch nicht als endgültig für alle Inhalte.

Kontext für Übersetzer ignorieren. Die Übergabe von Strings zu automatisieren, ohne den Kontext zu automatisieren, schafft eine schnelle Pipeline, die Übersetzungen von geringer Qualität produziert. Ein String-Key wie checkout.button.primary ohne Screenshot, Beschreibung oder Zeichenbeschränkung sagt einem Übersetzer fast nichts. Baue die Kontextlieferung von Anfang an in deine Pipeline ein — es ist viel schwieriger, das nachträglich einzufügen.

Translation Memory durch Key-Umbenennungen zerstören. Translation Memory ordnet Übersetzungen Quell-Strings oder String-Keys zu, je nach Plattform. Wenn Entwickler Keys umbenennen — zum Beispiel user.save_button in profile.save_changes ändern — behandelt das TMS dies oft als gelöschten Key und einen neuen, unübersetzten Key. Alle bisherigen Übersetzungsarbeiten für diesen String gehen aus dem TM verloren. Lege eine Key-Umbenennungsrichtlinie fest: Behandle Key-Umbenennungen entweder als Deprecated-and-Create-Operation (den alten Key behalten, bis Übersetzungen bestätigt sind), oder verwende ein TMS, das String-Identität durch Key-Änderungen hinweg mit einem Content-Hash statt nur dem Key-Namen verfolgt.

Gelöschte Keys nicht behandeln. Wenn ein String aus der Quelle entfernt wird, lassen die meisten Plattformen seine Übersetzungen im TMS auf unbestimmte Zeit bestehen. Mit der Zeit entstehen verwaiste Übersetzungen, die Speicherplatz verschwenden, Übersetzer verwirren und die Berichterstattung über Übersetzungsvollständigkeit ungenau machen. Implementiere einen regelmäßigen Bereinigungszyklus — entweder über CI-Skript oder eine TMS-Automatisierungsregel — der Übersetzungen für Keys entfernt, die nicht mehr in der Quelle vorhanden sind.

Alle Locales gleich behandeln. Verschiedene Locales haben unterschiedliche Übersetzungsgeschwindigkeiten, abhängig von der Verfügbarkeit von Übersetzern, der Komplexität des Sprachpaares und den Review-Anforderungen. Eine Pipeline, die das Deployment blockiert, bis alle Locales die Übersetzung abgeschlossen haben, wird häufig durch den langsamsten Locale blockiert. Gestalte deine Pipeline so, dass sie mit den übersetzten Locales deployed, die bereit sind, und auf die Quellsprache für Locales zurückfällt, die es nicht sind — mit einer Benachrichtigung, wenn ein Locale unter einen von dir definierten Vollständigkeitsschwellenwert fällt.

Tools, die Continuous Localization unterstützen

Dies sind die Tools, die am häufigsten in engineering-getriebenen Continuous-Localization-Pipelines eingesetzt werden. Jedes hat ehrliche Stärken und echte Einschränkungen.

Crowdin CLI. Crowdins Command-Line-Client integriert sich eng mit GitHub, GitLab und Bitbucket über native Integrationen und Webhook-Unterstützung. Es unterstützt Branching, hat eine breite Dateiformat-Bibliothek (JSON, YAML, XLIFF, Android XML, iOS Strings und viele andere) und bietet ein starkes Translation Memory. Die CI-Integration ist gut dokumentiert. Einschränkungen: Das Branching-Modell kann für komplexe Monorepos verwirrend zu konfigurieren sein, und OTA-Delivery erfordert das Crowdin OTA-Feature, das in höheren Tarifen verfügbar ist.

Transifex. Transifex hat seit langem CI/CD-Integrationsunterstützung über seinen CLI und Webhooks. Es führte „Live Translation" für webbasierte OTA-Delivery ein — ein JavaScript-Snippet, das Text-Nodes abfängt und sie durch übersetzten Inhalt von einem CDN ersetzt. Dieser Ansatz funktioniert ohne Änderungen am Anwendungs-Build-Prozess, was für Teams nützlich ist, die die Build-Pipeline nicht einfach ändern können. Der Live-Ansatz hat Performance-Trade-offs, weil er auf DOM-Ebene operiert.

Lokalise CI. Lokalise hat starke GitHub-Actions- und GitLab-CI-Integration, einen gut gestalteten Contributor-Workflow für Übersetzungsreviews und unterstützt OTA über seine SDKs für iOS, Android und Web. Seine Branching-Unterstützung ist ausgereifter als bei den meisten Wettbewerbern. Der Web-Editor hat gute Screenshot-basierte Kontextunterstützung. Lokalise ist im Allgemeinen auf den Mid-to-Enterprise-Markt ausgerichtet, mit einer Preisgestaltung, die das widerspiegelt.

Phrase CLI (ehemals Phrase Strings). Phrase (ehemals Memsource und PhraseApp, jetzt unter einer einheitlichen Marke) hat einen umfassenden CLI, starke XLIFF-Unterstützung (nützlich für Teams mit professionellen Übersetzungsagenturen, die XLIFF-Workflows bevorzugen) und ausgereifte Translation-Memory- und Qualitätssicherungsfunktionen. Es ist besonders stark in professionellen Übersetzungsagentur-Workflows. Seine CI-Integration ist solide, erfordert aber mehr Konfiguration als Crowdin oder Lokalise für VCS-native Automatisierung.

Better i18n. Better i18n verfolgt einen Developer-First-Ansatz mit einem CLI, React/Next.js/Vue/Svelte SDKs und CDN-basierter Delivery über Cloudflares Edge-Netzwerk. Das OTA-Modell bedeutet, dass Übersetzungs-Updates innerhalb von Sekunden nach der Veröffentlichung global verfügbar sind — ohne einen neuen Build oder Deploy auszulösen. Es unterstützt KI-gestützte Erstentwurfs-Übersetzungen und ist auf Engineering-Teams ausgerichtet, die Übersetzungen nah an der Codebasis verwalten möchten. Seine CI-Integration ist über den CLI unkompliziert. Stand Anfang 2026 ist es früher in der Entwicklung als Crowdin, Lokalise oder Phrase, mit einem schmaleren Feature-Set in Bereichen wie XLIFF-Workflows und Enterprise-SSO.

FAQ

F: Können wir Continuous Localization verwenden, wenn unsere Übersetzer nicht technisch sind?

Ja. Die Pipeline-Automatisierung liegt auf der Engineering-Seite. Übersetzer interagieren nur mit der TMS-Weboberfläche, wo sie Strings in einem Übersetzungseditor sehen — keine YAML-Dateien oder Git-Befehle. Die Automatisierung übernimmt die Extraktion von Strings aus dem Code, das Senden an das TMS und das Mergen von Übersetzungen zurück. Die Erfahrung des Übersetzers wird weitgehend durch die Qualität des TMS-Editors und den von dir bereitgestellten Kontext bestimmt, nicht durch die Pipeline-Mechanik.

F: Wie gehen wir mit Feature-Branches um, die noch nicht gemergt wurden?

Die meisten TMS-Plattformen unterstützen Übersetzungs-Branches, die VCS-Branches spiegeln. Du konfigurierst ein Branch-Mapping — zum Beispiel synchronisieren Feature-Branches, die feat/* entsprechen, mit entsprechenden TMS-Branches. Übersetzer können an Strings in einem Feature-Branch arbeiten, bevor er gemergt wird. Wenn der Branch in deinem VCS gemergt wird, wird auch der TMS-Branch gemergt, und Übersetzungen werden übernommen. Dies erfordert ein TMS, das Branching explizit unterstützt — nicht alle tun das.

F: Sollten Übersetzungen im Repository oder im TMS leben?

Idealerweise beides. Das Repository ist die Source of Truth für Quell-Strings (die Strings, die Entwickler schreiben). Das TMS ist die Source of Truth für übersetzte Strings. Deine Pipeline synchronisiert zwischen beiden: Quell-Strings fließen vom Repo zum TMS, übersetzte Strings fließen vom TMS zurück ins Repo (oder zu einem CDN). Übersetzte Strings nur im Repository ohne TMS zu speichern, macht es für Nicht-Entwickler schwer, Beiträge zu leisten. Sie nur im TMS zu speichern, ohne ins Repo zu synchronisieren, macht es schwer, Builds deterministisch zu reproduzieren.

F: Wie messen wir die Gesundheit unserer Lokalisierungs-Pipeline?

Verfolge diese vier Metriken: Übersetzungsabdeckung (Prozentsatz der Quell-Strings mit einer Übersetzung pro Locale), Übersetzungsverzögerung (Zeit zwischen dem Hinzufügen eines Strings zur Quelle und der Veröffentlichung seiner ersten Übersetzung), Review-Rückstand (Anzahl maschinell übersetzter Strings, die auf menschliches Review warten) und verwaiste Key-Quote (Übersetzungen im TMS für Keys, die nicht mehr in der Quelle existieren). Eine gesunde Pipeline hat hohe Abdeckung, geringe Verzögerung, einen überschaubaren Review-Rückstand und eine nahe-null verwaiste Key-Quote.

F: Was ist das minimale Continuous-Localization-Setup für ein kleines Team?

Für ein Team von zwei bis fünf Engineers, das ein Web-Produkt ausliefert: ein einzelner CI-Schritt, der den TMS CLI ausführt, um neue Quell-Strings bei jedem Merge in main zu pushen, maschinelle Übersetzung für Erstentwürfe aktiviert, und eine wöchentliche Übersetzer-Review-Session für die kundenseitig relevantesten Strings. Dies allein eliminiert release-blockierende Batch-Übersetzung und die meisten Merge-Konflikte. OTA-Delivery und Branching-Unterstützung können später hinzugefügt werden, wenn das Produkt und der Übersetzer-Workflow reifen.

Fazit

Continuous Localization ist die logische Erweiterung des CI/CD-Denkens auf die Übersetzungsebene deines Produkts. Die Kernaussage ist, dass Übersetzung kein Release-Meilenstein ist — es ist eine Pipeline-Phase. Wenn Strings automatisch extrahiert, an Übersetzer übergeben, geprüft und als Teil deines normalen Entwicklungsflusses gemergt werden, werden die Kosten, die Lokalisierung in Batch-Workflows schmerzhaft machen — Release-Verzögerungen, veraltete Übersetzungen, Merge-Konflikte, Reibung zwischen Entwicklern und Übersetzern — auf Engineering-Probleme mit Engineering-Lösungen reduziert.

Die in diesem Artikel beschriebene Pipeline ist nicht hypothetisch. Teams in Unternehmen, die für Dutzende von Locales ausliefern, betreiben Varianten davon in der Produktion. Die Details variieren — welches TMS, welches CI-System, ob OTA-Delivery in Betracht kommt, wie viel menschliches Review erforderlich ist — aber die Struktur ist konsistent: Automatisiere die mechanische Arbeit, liefere Kontext für die menschliche Arbeit, und behandle Übersetzungsvollständigkeit als kontinuierliche Metrik statt als binäres Release-Gate.

Beginne mit der reibungsärmsten Änderung, die für dein Team verfügbar ist: ein CI-Schritt, der neue Strings bei jedem main-Branch-Merge zu deinem TMS pusht. Füge von dort aus Branching-Unterstützung, Kontextlieferung, OTA-Updates und automatisierte Qualitätsprüfungen inkrementell hinzu. Jede Ebene reduziert Reibung und verbessert die Qualität, ohne einen vollständigen Pipeline-Umbau zu erfordern.

Das Ziel ist ein Lokalisierungs-Workflow, der für Entwickler unsichtbar ist — einer, bei dem das Ausliefern in eine neue Locale eine Konfigurationsänderung ist, kein Projekt.

Referenzen

[^1]: Martin Fowler, "Continuous Integration," martinfowler.com, https://martinfowler.com/articles/continuousIntegration.html

[^2]: W3C Internationalization Working Group, "Internationalization Best Practices for Spec Developers," W3C Working Group Note, https://www.w3.org/TR/international-specs/

[^3]: OASIS XLIFF Technical Committee, "XLIFF Version 2.1," OASIS Standard, https://docs.oasis-open.org/xliff/xliff-core/v2.1/os/xliff-core-v2.1-os.html

[^4]: GitHub Actions documentation, "Events that trigger workflows," https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows

[^5]: GitLab CI/CD documentation, "GitLab CI/CD pipeline configuration reference," https://docs.gitlab.com/ee/ci/yaml/

[^6]: Unicode CLDR Project, "Unicode Common Locale Data Repository," https://cldr.unicode.org/

[^7]: IETF BCP 47, "Tags for Identifying Languages," https://www.rfc-editor.org/rfc/rfc5646

[^8]: Crowdin documentation, "CLI tool," https://developer.crowdin.com/cli-tool/

[^9]: Lokalise documentation, "CI/CD integrations," https://lokalise.com/blog/continuous-localization/

[^10]: Phrase documentation, "Phrase Strings CLI," https://support.phrase.com/hc/en-us/articles/5784095916188

Zuletzt aktualisiert: März 2026