Für aktive Softwareentwicklung ist eine agile oder kontinuierliche Lokalisierung meist die richtige Wahl, denn sie fügt sich in Sprints und CI/CD-Pipelines ein und nutzt XLIFF als Austauschformat zwischen Entwicklung und Übersetzung. Stufenweise Modelle bleiben sinnvoll, sobald ein Release stabilisiert ist und keine laufenden Textänderungen mehr anfallen.
Kurz gesagt:
- Kontinuierliche Lokalisierung eignet sich vor allem für häufige Releases, da sie Verzögerungen zwischen Entwicklung und Übersetzung nahezu ausschließt.
- Automatisierte Prozesse bei CI/CD und Repository-Triggern ermöglichen eine nahtlose Integration von Textextraktion, Übersetzung und Rückimport in den Entwicklungszyklus.
- Das standardmäßige Austauschformat XLIFF 2.2 sorgt dafür, dass Strings samt Kontextinformationen zwischen Tools interoperabel bleiben.
- Für den Einstieg ist es ausreichend, mit einem kleinen Lokalisierungs-Kit und eine Test-XLIFF-Pipeline zu starten, um die Automatisierungsprozesse ohne großen Aufwand zu etablieren.
- Die Zusammenarbeit mit spezialisierten Dienstleistern hilft, Qualitätskontrolle, Terminologiepflege und Übersetzungsarbeit effizient zu koordinieren.
Inhaltsverzeichnis
- Stufenweise, agile oder kontinuierliche Lokalisierung: Was passt zu Ihrem Produkt?
- Werkzeuge und Austauschformate: TMS, Translation Memory und XLIFF
- Automatisierung in der Pipeline: CI/CD, Repository-Trigger und MT
- UI-Texte, Terminologie und das Lokalisierungs-Kit richtig aufbauen
- Lokalisierungstests vor dem Rollout: Was geprüft werden muss
- Governance und Datenschutz bei automatisierter Lokalisierung
- Minimaler Implementierungsplan für den Start
- UnaLingua als praktikable Unterstützung für Ihren Lokalisierungsworkflow
- Quellen
- FAQ
Stufenweise, agile oder kontinuierliche Lokalisierung: Was passt zu Ihrem Produkt?
Die drei Modelle unterscheiden sich vor allem im Zeitpunkt der Übersetzung. Beim stufenweisen Modell, oft als Wasserfall bezeichnet, wird die gesamte Software zunächst fertiggestellt, bevor die Lokalisierung als eigener Projektabschnitt beginnt. Das agile Modell übersetzt parallel zur Entwicklung, meist sprintbasiert, mit festen Übergabepunkten am Ende jedes Sprints. Die kontinuierliche Lokalisierung geht noch einen Schritt weiter: Neue oder geänderte Strings werden automatisch erkannt und ohne manuellen Übergabeschritt in die Übersetzungspipeline geschickt.
Für Produktteams mit häufigen Releases lohnt sich die kontinuierliche Variante, weil sie Verzögerungen zwischen Entwicklung und Übersetzung praktisch eliminiert. Teams mit seltenen, großen Releases kommen mit dem stufenweisen Modell oft günstiger weg, weil der Koordinationsaufwand geringer bleibt.
Bei der Entscheidung helfen folgende Kriterien:
- Release-Rhythmus: Wöchentliche oder tägliche Deployments verlangen Automatisierung, quartalsweise Releases erlauben klassische Projektplanung.
- Teamgröße: Kleine Teams profitieren von einfachen, wiederholbaren Prozessen ohne komplexe Toolketten.
- Ressourcen: Kontinuierliche Modelle brauchen eine stabile technische Infrastruktur, stufenweise Modelle kommen mit weniger Werkzeugen aus.
- Sprachanzahl: Viele Zielsprachen erhöhen den Koordinationsaufwand und sprechen eher für Automatisierung.
Ein hybrider Ansatz ist in der Praxis häufig: Kernfunktionen laufen kontinuierlich, größere Feature-Releases folgen einem festen Zeitplan mit definierten Übersetzungsfenstern.
Werkzeuge und Austauschformate: TMS, Translation Memory und XLIFF
Ein Translation-Management-System organisiert den Übersetzungsauftrag, verwaltet Fristen und verbindet Übersetzer mit dem Quelltext. Das Translation Memory speichert bereits übersetzte Segmente und schlägt sie bei ähnlichen oder identischen Texten erneut vor, was Kosten senkt und die Terminologie konsistent hält. Maschinelle Übersetzung ergänzt diese Systeme oft als Vorübersetzung, die anschließend von einem Fachübersetzer geprüft wird.
Im Zentrum der Werkzeugkette steht XLIFF als Industriestandard für den verlustfreien Austausch von Lokalisierungsdaten. Die aktuelle Version 2.2 legt in ihrem Core-Teil die Mindestelemente fest, mit denen Strings und ihr Kontext zwischen unterschiedlichen Tools übertragen werden, wie die OASIS-Spezifikation beschreibt. Ein optionaler Erweiterungsteil ergänzt Module wie Übersetzungsvorschläge, die für fortgeschrittene MT-Integrationen nützlich sind.
XLIFF 2.2 als Standard sorgt dafür, dass extrahierte Strings plus Kontextinformationen zwischen verschiedenen Systemen interoperabel bleiben, was den Wechsel zwischen Tools ohne Datenverlust ermöglicht.
Bei der Auswahl einer Toolkategorie stellt sich meist die Frage cloudbasiert oder On-Premises:
- Cloud-TMS-Lösungen sind schneller einsatzbereit und passen zu verteilten Teams mit häufigen Releases.
- On-Premises-Systeme passen zu Organisationen mit strengen Vorgaben zur Datenhoheit oder zu regulierten Branchen.
Ein vertiefender Überblick zu Übersetzungssoftware für Fachbereiche zeigt, wie sich diese Toolklassen im praktischen Einsatz unterscheiden.
Automatisierung in der Pipeline: CI/CD, Repository-Trigger und MT
Der eigentliche Hebel für kontinuierliche Lokalisierung liegt in der Integration zwischen Code-Repository und Übersetzungssystem. Neue Strings werden bei jedem Commit oder Pull Request automatisch extrahiert, in XLIFF umgewandelt und an das TMS übergeben, ohne dass jemand manuell eine Datei exportieren muss.
Ein typischer automatisierter Ablauf sieht so aus:
- Ein Repository-Trigger erkennt geänderte Quelldateien und identifiziert neue oder veränderte Strings.
- Ein CI-Job wandelt diese Strings in XLIFF um und übergibt sie an die Pretranslation, meist über eine MT-Engine mit anschließender menschlicher Prüfung.
- Ein Linting-Schritt prüft Platzhalter, Längenbegrenzungen und Formatierungstags, bevor die Datei zur Übersetzung freigegeben wird.
- Nach Fertigstellung importiert ein weiterer CI-Job die übersetzten Strings automatisch zurück in den Quellcode-Zweig.
- Ein Sicherheits- und Compliance-Check prüft, ob sensible Daten in den übergebenen Texten enthalten sind, bevor externe MT-Dienste sie verarbeiten.
Webhooks verbinden dabei die einzelnen Systeme, sodass Statusänderungen im TMS wiederum Benachrichtigungen im Entwicklungsteam auslösen. Für die Auswahl geeigneter Kollaborationswerkzeuge in diesem Zusammenspiel bietet ein Ratgeber zu kollaborativen Tools zusätzliche Orientierung.
Profi-Tipp: Richten Sie den Rückimport so ein, dass er in einem eigenen Branch landet und erst nach einer kurzen Sichtprüfung in den Hauptzweig gemergt wird, statt automatisch zu deployen.
Eine praktische Anleitung zur XLIFF-Extraktion aus WordPress zeigt diesen Ablauf konkret an einem verbreiteten System.
UI-Texte, Terminologie und das Lokalisierungs-Kit richtig aufbauen
Übersetzungsfreundliche UI-Texte vermeiden Verschachtelungen wie „Sie haben %d neue Nachrichten“, weil Pluralformen und Wortstellung zwischen Sprachen stark variieren. Ganze Sätze statt zusammengesetzter Fragmente, klar benannte Platzhalter und ausreichend Platz für Textexpansion gehören zu den Grundregeln.
Ein Lokalisierungs-Kit, oft als LocKit bezeichnet, fasst alles zusammen, was ein Übersetzer für konsistente Ergebnisse braucht. Nach den Praxishinweisen der eCoLoTrain-Ressource der Universität Mainz gehören dazu:
- Produktbeschreibung und Zielgruppe, damit Übersetzer den Kontext der Anwendung verstehen.
- Screenshots oder Aufnahmen der Benutzeroberfläche zur visuellen Einordnung einzelner Strings.
- Ein gepflegtes Glossar mit freigegebener Terminologie und Stilrichtlinien für Ton und Anrede.
- Vorbereitetes Translation Memory aus früheren Projekten, aufgebaut durch Alignment bestehender Übersetzungen.
Ein gut gepflegtes Kit reduziert Rückfragen von Übersetzern deutlich und verkürzt dadurch den Prüfaufwand im Team.
Profi-Tipp: Pflegen Sie das Glossar als eigenständiges, versioniertes Dokument, damit Terminologieänderungen nachvollziehbar bleiben und nicht in E-Mail-Verläufen verloren gehen.
Lokalisierungstests vor dem Rollout: Was geprüft werden muss
Vor jedem Rollout gehören mehrere Testarten in den Workflow, automatisiert und manuell kombiniert:
- Automatisierte UI-Tests prüfen Textexpansion und Layoutbrüche, etwa wenn deutsche Begriffe deutlich länger sind als ihr englisches Original.
- Sprachliche Qualitätsprüfung durch einen Fachübersetzer deckt Kontextfehler ab, die eine reine MT-Ausgabe nicht erkennt.
- End-to-End-Checks stellen sicher, dass Platzhalter, Datumsformate und Zahlenformate in der Zielsprache korrekt funktionieren.
Automatisierte Prüfungen liegen meist beim Entwicklungsteam, während die sprachliche Freigabe klar bei der Übersetzung oder einer verantwortlichen Lektoratsperson verbleibt. Häufige Fehlerquellen sind abgeschnittener Text, hartcodierte Strings, die die Extraktion übersehen hat, und falsch verkettete Satzfragmente. Eine ausführliche Übersicht zu Qualitätsmanagement für professionelle Übersetzungen sowie eine praxisnahe Anleitung zum Testen von Lokalisierung liefern dazu passende Checklisten.
Governance und Datenschutz bei automatisierter Lokalisierung
Cloud-TMS-Systeme und maschinelle Übersetzung verarbeiten Texte häufig außerhalb der eigenen Infrastruktur, was Fragen zur Datenhoheit aufwirft. Die EU-Initiative European Language Data Space zielt genau darauf ab: Sie soll EU-konforme, vertrauenswürdige Sprachdaten und Governance-Mechanismen fördern, damit Unternehmen kontrolliert und nachvollziehbar mit MT- und TMS-Anbietern zusammenarbeiten können.
In der Praxis empfehlen sich einfache Gegenmaßnahmen: Zugriffskontrollen für jedes Projekt, Vertragsklauseln, die den Verarbeitungsort und die Löschfrist von Übersetzungsdaten regeln, sowie Pseudonymisierung, wo personenbezogene Daten in Testtexten oder Beispielinhalten auftauchen. Zertifizierungen wie ISO 17100 für Übersetzungsdienstleistungen oder ISO 27001-gesicherte Infrastruktur für Informationssicherheit dienen dabei als brauchbares Vertrauenssignal bei der Auswahl eines Dienstleisters oder Tool-Anbieters.
Minimaler Implementierungsplan für den Start
Ein realistischer Einstieg braucht keine vollständige Automatisierung von Tag eins an:
- Ein Lokalisierungs-Kit mit Glossar, Screenshots und Stilrichtlinien erstellen, bevor die erste Übersetzung beginnt.
- Die XLIFF-Pipeline mit einer kleinen Testdatei durchspielen, bevor sie produktiv geschaltet wird.
- Ein Translation Memory aus vorhandenen Übersetzungen initialisieren, statt bei null zu beginnen.
- Lokalisierungsaufgaben als eigene Backlog-Einträge mit klaren Akzeptanzkriterien führen.
- Den Sprachumfang für den ersten Durchlauf bewusst klein halten und erst danach erweitern.
UnaLingua als praktikable Unterstützung für Ihren Lokalisierungsworkflow
Ein automatisierter Workflow ersetzt keine fachliche Übersetzung und keine sprachliche Qualitätsprüfung, er organisiert nur den Datenfluss darum. Als Dienstleister bietet das Unternehmen Software-Lokalisierung, Terminologie-Management und Qualitätssicherung an und übernimmt damit genau die Teile des Prozesses, die intern am meisten Zeit binden: Übersetzung, Terminologiepflege und sprachliche Prüfung vor dem Rollout.
Für Teams, die ihre Pipeline selbst automatisieren, aber keine eigene Übersetzungsabteilung aufbauen wollen, spart die Zusammenarbeit mit einem spezialisierten Anbieter Koordinationsaufwand und senkt das Risiko unentdeckter Sprachfehler im Release. Details zu Leistungsumfang und Ablauf finden Sie auf der Seite zur Software-Lokalisierung.
Quellen
FAQ
Welche Software eignet sich für die Workflow-Automatisierung?
Geeignet sind Translation-Management-Systeme mit XLIFF-Unterstützung, kombiniert mit CI/CD-Werkzeugen, die Repository-Trigger und Webhooks unterstützen. Wichtig ist, dass die Werkzeuge nahtlos ineinandergreifen, also dass Extraktion, Übersetzung und Rückimport ohne manuelle Zwischenschritte funktionieren.
Was ist der Unterschied zwischen Lokalisierung und Lokalisation?
Beide Begriffe bezeichnen denselben Vorgang: die Anpassung von Software an Sprache, Kultur und technische Konventionen einer Zielregion. „Lokalisierung“ ist im deutschen Sprachraum die gebräuchlichere Form, „Lokalisation“ taucht seltener als Variante auf.
Welche Beispiele gibt es für Workflows?
Ein Beispiel ist die stufenweise Übersetzung nach Abschluss eines Releases, ein anderes die kontinuierliche Lokalisierung, bei der neue Strings automatisch bei jedem Commit erkannt und übersetzt werden. Dazwischen liegt der agile Workflow mit sprintbasierten Übergaben am Ende jedes Entwicklungszyklus.
Wie heißt „Workflow“ auf Deutsch?
Die gebräuchlichste deutsche Entsprechung ist „Arbeitsablauf“, seltener auch „Arbeitsprozess“. Im fachlichen Kontext der Softwarelokalisierung wird trotzdem meist der englische Begriff „Workflow“ verwendet, weil er sich als feste Bezeichnung etabliert hat.