Was ist Continuous Localization? Definition, Workflow und was es nicht bedeutet

Continuous Localization (kontinuierliche Lokalisierung) ist ein Übersetzungsworkflow, in dem neue und geänderte Strings automatisch und kontinuierlich aus der Codebasis zu den Menschen oder Systemen fliessen, die sie übersetzen, parallel zur Entwicklung, und in dem freigegebene Übersetzungen ohne Release an die laufende Anwendung ausgeliefert werden. Es ist das Lokalisierungs-Gegenstück zu Continuous Integration und Continuous Delivery: Statt einer Übersetzungsübergabe vor jedem Release ist Übersetzung ein Prozess, der immer läuft, und eine Übersetzungskorrektur wartet nie auf einen Deploy.

Dieser Beitrag ist die Definition: was der Begriff bedeutet, was er nicht bedeutet, die vier Stufen, die jede Umsetzung hat, wie er sich vom Batch-Workflow unterscheidet, den er ersetzt, und was er nicht löst. Die Produktseite, wie Locize das umsetzt, und die Teams, die so arbeiten, finden Sie auf der Seite zu Continuous Localization.

Was Continuous Localization bedeutet, und was nicht

Das Wort "continuous" ist mit Absicht von Continuous Integration und Continuous Delivery entlehnt. In diesen Praktiken wird Code in kleinen Schritten integriert und ausgeliefert, ständig, statt in grossen Batches mit einem Freeze vor jedem. Continuous Localization überträgt dieselbe Idee auf die Übersetzung: Die Arbeitseinheit ist der String, nicht das Release, und die Pipeline bewegt Strings vom Code zu Übersetzern zu Nutzern, ohne auf einen Schnitt zu warten.

Drei Lesarten des Begriffs sind häufig genug falsch, um sie auszusprechen:

• Es bedeutet nicht "alles mit KI übersetzen und ausliefern". Maschinelle und KI-Übersetzung sind der Grund, warum der erste Entwurf nicht mehr wartet; was veröffentlicht wird, entscheiden weiterhin Checks und Review. Eine Pipeline, die ungeprüften Modell-Output in die Produktion schiebt, ist kontinuierlich und ungesteuert, und diese Kombination steckt hinter Terminologie-Drift und der gelegentlichen beleidigenden Fehlermeldung.
• Es erfordert nicht, Übersetzungsdateien abzuschaffen. Manche kontinuierlichen Setups haben gar keine Sprachdateien im Repository, weil die Anwendung Übersetzungen zur Laufzeit lädt; andere erzeugen die Dateien in der CI und committen sie. Beide sind kontinuierlich, wenn nichts auf eine manuelle Übergabe wartet.
• Es macht Glossar, Review-Workflow und Qualitätsprüfungen nicht überflüssig. Es macht sie wichtiger, weil mehr Strings schneller unterwegs sind.

Continuous Localization gegen Batch-Lokalisierung

Ein Batch-Workflow hat eine wiedererkennbare Form. Die Entwicklung erreicht einen Schnitt. Jemand exportiert die geänderten Strings, oder alle, in Dateien oder eine Tabelle. Die Dateien gehen an Übersetzer, intern oder in einer Agentur. Tage oder Wochen später kommen sie zurück, jemand importiert sie, löst auf, was in der Zwischenzeit kaputtgegangen ist, und die Übersetzungen gehen mit dem nächsten Deploy raus. Jeder Schritt ist eine Wartezeit, und das Feature, das am Tag des Schnitts fertig wurde, erscheint nur in der Standardsprache.

Ein kontinuierlicher Workflow entfernt den Schnitt. Strings werden erkannt, während Entwickler sie schreiben. Übersetzt wird, während das Feature noch gebaut wird. Ein Review-Gate entscheidet, was bereit ist. Die Auslieferung hängt nicht von einem Deploy ab. Die sichtbaren Effekte für ein Entwicklungsteam: Übersetzung ist keine Release-blockierende Abhängigkeit mehr, und ein falsches Label auf Polnisch wird in Minuten korrigiert statt im nächsten Release. Der sichtbare Effekt für ein Lokalisierungsteam: Die Arbeit kommt als Strom statt als Stapel.

Die vier Stufen eines Continuous-Localization-Workflows

Jede Umsetzung, unabhängig vom Werkzeug, hat dieselben vier Stufen.

1. Erkennen: Strings verlassen den Code automatisch

Eine Entwicklerin schreibt einen Übersetzungsaufruf mit einem neuen Key und einem Standardwert. Entweder liest ein statischer Extraktionsschritt in der CI die Aufrufe und meldet die Keys, oder die laufende Anwendung meldet einen Key, wenn sie ihn zum ersten Mal rendert (bei i18next ist das die Option saveMissing). Niemand exportiert etwas; der Key existiert mit seinem Standardtext im Übersetzungssystem, bevor der Pull Request gemergt ist.

2. Übersetzen: Menschen, Maschinen und KI arbeiten, während die Entwicklung weitergeht

Neue Keys bekommen einen ersten Entwurf aus maschineller oder KI-Übersetzung, mit dem Glossar und dem Styleguide des Projekts als Kontext, damit keine Sprache leer ist, während das Feature in Arbeit ist. Übersetzer und Reviewer arbeiten an denselben Keys in einem Editor, der Quelle, Kontext und Terminologie zeigt. Die Entwicklung wartet nicht auf diese Stufe, und diese Stufe wartet nicht auf ein Release.

3. Veröffentlichen: ein Gate, kein Freeze

Was live geht, wird pro String entschieden, nicht pro Release: automatische Checks für Platzhalter, Zahlen, Tags und Konsistenz, ein Quality-Estimation-Score für maschinell erzeugte Entwürfe, menschliches Review für die Strings, die es brauchen. Versionen oder Branches erlauben es, Übersetzungen für ein noch nicht öffentliches Feature vorzubereiten. Das Gate ersetzt den Freeze: Der Release-Zug fährt weiter, und eine Übersetzung steigt zu, wenn sie bereit ist.

4. Ausliefern: die laufende Anwendung holt sich die Übersetzungen

Freigegebene Übersetzungen erreichen die Nutzer ohne Build: Die Anwendung lädt sie zur Laufzeit von einem Content Delivery Network, mit einer Cache-Dauer, die Aktualität und Latenz ausbalanciert. Teams, die Dateien für Server-Side-Rendering oder Offline-Bundles brauchen, laden sie in der CI als generierte Artefakte herunter. So oder so ist eine im Editor veröffentlichte Korrektur ohne Commit live.

Wie Teams Continuous Localization heute umsetzen

• CI-Sync mit generierten Dateien. Die Extraktion läuft in der Pipeline, ein Sync-Schritt schickt neue Keys ans Übersetzungssystem und holt übersetzte Dateien zurück, die Dateien werden committet oder beim Build heruntergeladen. Kontinuierlich, mit Dateien für Builds, die sie brauchen. Diff-basierter Sync ist hier wichtig, damit ein Pull Request nur die Keys übersetzt, die er hinzugefügt hat.
• Laufzeit-Meldung und CDN-Auslieferung. Die Anwendung meldet neue Keys, während sie läuft (auf die Entwicklung beschränkt), und lädt Übersetzungen zur Laufzeit; das Repository enthält keine Sprachdateien. Die direkteste Form des Musters, verbreitet bei Single-Page- und Mobile-Anwendungen.
• Ein Translation-Management-System in der Mitte. Beide obigen Varianten brauchen einen Ort, an dem Übersetzer, maschinelle Übersetzung und KI auf die Keys treffen, mit Review, Historie und Veröffentlichung. Das TMS ist die Hälfte des Workflows für Stufe 2 und 3; die CI- oder Laufzeit-Integration die Hälfte für Stufe 1 und 4.
• Nur KI in der CI. Ein Workflow, der beim Push Keys extrahiert und maschinell übersetzt, ohne Editor und ohne Review. Nach obiger Definition kontinuierlich, und genau das Setup, um das es im Abschnitt "was es nicht bedeutet" geht: nichts zwischen Modell und Produktion. Was darin kaputtgeht und wie man die fehlende Ebene ergänzt, steht in Wenn KI-Übersetzungen kaputtgehen.

Was Sie brauchen, bevor es funktioniert

• Keys entstehen im Code. Wenn noch jemand Keys in eine Datei oder eine Tabelle tippt, ist Stufe 1 manuell, und alles danach wartet darauf.
• Eine einzige Quelle der Wahrheit. Übersetzungen leben in einem System; Dateien, falls es welche gibt, werden daraus erzeugt. Zwei Quellen der Wahrheit führen den Merge-Schritt wieder ein, mit dem Batch-Workflows ihre Zeit verbringen.
• Eine schriftliche Qualitätsrichtlinie. Welche Inhaltstypen mit KI-Entwurf plus automatischen Checks ausgeliefert werden dürfen, welche eine Person brauchen, welche als Review-Vorschläge zurückgehalten werden, bis sie freigegeben sind. Kontinuierlicher Fluss ohne diese Richtlinie ist ein schnellerer Weg, Fehler auszuliefern.
• Ein Staging-Mechanismus. Versionen oder Branches, damit Übersetzungen für unveröffentlichte Features nicht zu früh live gehen und eine Produktionsversion bewusst befördert werden kann.
• Checks über den gesamten Korpus. Platzhalter, Zahlen, Tags und Key-übergreifende Konsistenz müssen dort geprüft werden, wo alle Strings sind, bei jedem Speichern, nicht nur auf einem Diff. Die Taxonomie steht in Was in Übersetzungen wirklich kaputtgeht.
• Eine Messgrösse. Die eine Zahl, die Ihnen sagt, ob der Workflow kontinuierlich ist: die Zeit vom Schreiben eines Strings bis er in jeder Sprache live ist. Wird sie in Release-Zyklen gemessen, ist der Workflow Batch mit besserem Werkzeug.

Was Continuous Localization nicht löst

• Übersetzungsqualität. Fluss ist nicht Qualität. Terminologie-Governance, menschliches Review und Qualitätsprüfungen sind eigene Ebenen, und kontinuierlicher Fluss erhöht die Kosten, sie zu überspringen.
• Kontext. Ein String, der ohne Screenshot oder Notiz aus dem Code kommt, ist weiterhin mehrdeutig. Kontinuierliches Erkennen macht das Erfassen von Kontext wichtiger, nicht unwichtiger.
• Regulierte Inhalte. Texte, die die Öffentlichkeit über Angelegenheiten von öffentlichem Interesse informieren, können unter die sichtbare Offenlegungspflicht von Artikel 50 der EU-KI-Verordnung fallen (in Kraft seit dem 2. August 2026), es sei denn, sie haben eine dokumentierte menschliche Überprüfung mit redaktioneller Verantwortung durchlaufen. Der Workflow kann dieses Review festhalten; er kann nicht entscheiden, welche Inhalte es brauchen. Das Erklärstück zu Artikel 50 hat die Details, und nichts davon ist Rechtsberatung.
• Kleine, langsame Projekte. Zwei Sprachen, die das Team liest, wenige Releases pro Jahr: Ein Batch-Prozess ist in Ordnung. Die Auslieferung zur Laufzeit lohnt sich trotzdem meistens, denn eine Tippfehler-Korrektur ohne Deploy ist in jeder Grösse nützlich.

Wie das in Locize funktioniert

Locize wurde vom i18next-Team genau um diesen Workflow herum gebaut, und die vier Stufen entsprechen vier Bausteinen:

• Erkennen: saveMissing mit i18next-locize-backend meldet Keys aus der laufenden Anwendung; die CLI und die GitHub Actions tun es aus der Pipeline, einschliesslich diff-basiertem Sync für Pull Requests.
• Übersetzen: Die automatische Übersetzung entwirft neue Keys mit Glossar und Styleguide als Kontext; Übersetzer und Reviewer arbeiten im Editor.

Neue Keys, die aus dem Code eintreffen und von der automatischen Übersetzung in jede Zielsprache entworfen werden, zur Prüfung markiert

• Veröffentlichen: Review-Vorschläge und Needs-Review-Markierungen steuern, was live geht, Versionen und Branches bereiten es vor, und automatische Checks laufen bei jedem Speichern.
• Ausliefern: Freigegebene Übersetzungen werden standardmässig auf das CDN veröffentlicht, mit Caching pro Version; die Anwendung lädt sie zur Laufzeit.

Wie das in der Praxis aussieht, mit dem Vergleich zu einem Batch-Workflow und den Teams, die so ausliefern, steht auf der Seite zu Continuous Localization. Die Engineering-Sicht auf denselben Übergang, wie eine Batch-Übergabe Continuous Deployment bricht und wie die verdrahtete Pipeline aussieht, steht in Wie Batch-Übersetzungsworkflows Continuous Deployment brechen.

Wenn Sie Ihre eigene Zeit von String bis live messen möchten: Erstellen Sie ein Projekt, verbinden Sie einen Namespace und stoppen Sie beim nächsten Key die Zeit vom Commit bis zu jeder Sprache.

Häufig gestellte Fragen

Was ist Continuous Localization? Ein Übersetzungsworkflow, in dem neue und geänderte Strings automatisch und kontinuierlich aus der Codebasis zu den Menschen oder Systemen fliessen, die sie übersetzen, parallel zur Entwicklung, und in dem freigegebene Übersetzungen ohne Release an die laufende Anwendung ausgeliefert werden. Es ist das Lokalisierungs-Gegenstück zu Continuous Integration und Continuous Delivery.

Wie unterscheidet sich Continuous Localization von traditioneller Lokalisierung? In einem Batch-Workflow warten die Strings: Freeze, Export, Übersetzung, Import, Redeploy. Bei Continuous Localization wartet nichts auf einen Schnitt: Strings werden erkannt, während sie geschrieben werden, übersetzt, während die Entwicklung weitergeht, durch Review statt durch einen Freeze freigegeben und zur Laufzeit ausgeliefert. Der Unterschied ist, wo die Strings zwischen dem Schreiben und dem Livegang liegen.

Was braucht man, um Continuous Localization umzusetzen? Keys, die im Code entstehen, einen Ort, an dem Übersetzer, maschinelle Übersetzung und KI mit Kontext daran arbeiten, ein Review- und Publish-Gate und einen Auslieferungspfad, der die laufende Anwendung ohne Redeploy erreicht, meist ein CDN. Versionierung und korpusweite Konsistenz-Checks sind die zwei Ergänzungen, die die meisten Teams als Nächstes brauchen.

Bedeutet Continuous Localization KI-Übersetzung ohne menschliches Review? Nein. Continuous beschreibt den Fluss, nicht die Qualitätsrichtlinie. KI liefert den ersten Entwurf, damit nichts wartet; was veröffentlicht wird, entscheiden Checks, ein Quality-Estimation-Score und menschliches Review, wo nötig. Ungeprüfter maschineller Output direkt in der Produktion ist kontinuierlich und ungesteuert.

Lohnt sich Continuous Localization für ein kleines Team? Wenn Übersetzung eine Release-Abhängigkeit ist: mehrere Deploys pro Woche, mehr als eine Handvoll Sprachen, Personen ohne Entwicklerhintergrund, die Text ändern, oder Korrekturen, die schneller raus müssen als der Release-Zyklus. Ein kleines Team mit zwei Sprachen, die es selbst liest, kann bei einem Batch-Prozess bleiben; die Auslieferung zur Laufzeit lohnt sich trotzdem meistens.