Inhaltsverzeichnis
Übersetzungsautomatisierungs-Tools: Webhooks, APIs und CI/CD-Integration für die Lokalisierung
Wichtigste Erkenntnisse
- Übersetzungsautomatisierung eliminiert manuelle Dateiübertragungen und die Koordination zwischen Entwicklern und Übersetzern
- Die drei wichtigsten Automatisierungsansätze sind: Webhook-gesteuerte Workflows, CLI-basierte CI/CD-Integration und API-getriebene benutzerdefinierte Automatisierung
- Die meisten modernen TMS-Plattformen bieten REST APIs und Webhook-Unterstützung, die Tiefe der CI/CD-Integration variiert jedoch erheblich
- Effektive Automatisierung erfordert die Behandlung von Sonderfällen: partielle Übersetzungen, Merge-Konflikte, gleichzeitige Branches und Rollback-Szenarien
- Das Ziel ist ein Workflow, bei dem Entwickler niemals manuell Übersetzungsdateien verwalten — alles fließt durch die Pipeline
Online-Übersetzungstools vs. Entwickler-Übersetzungstools
Der Begriff „Übersetzer-Tools" bedeutet für verschiedene Zielgruppen verschiedene Dinge. Das Verständnis des Unterschieds zwischen verbraucherorientierten Online-Übersetzungstools und entwicklerorientierten Übersetzungsautomatisierungstools hilft Ihnen, die richtige Lösung für Ihren Anwendungsfall zu finden.
Online-Übersetzungstools für den allgemeinen Gebrauch
Online-Übersetzungstools — Google Translate, DeepL, Microsoft Translator und ähnliche Dienste — sind für Personen konzipiert, die Text in einer anderen Sprache verstehen oder erstellen müssen. Sie fügen Text in eine Weboberfläche ein, wählen eine Zielsprache und erhalten sofort eine Übersetzung. Diese Tools sind auf Benutzerfreundlichkeit und breite Sprachabdeckung optimiert. Sie eignen sich gut zum Lesen eines fremdsprachigen Artikels, zum Verfassen einer E-Mail in einer anderen Sprache oder zum Erfassen des Inhalts eines Dokuments.
Was Online-Übersetzungstools nicht leisten, ist die Verwaltung von Übersetzungen in großem Maßstab. Sie haben kein Konzept für Translation Memory (Wiederverwendung zuvor genehmigter Übersetzungen), keine Glossarerzwingung (Sicherstellung einer konsistenten Übersetzung Ihrer Markenbegriffe), keine Review-Workflows (Weiterleitung von Übersetzungen an menschliche Prüfer vor der Veröffentlichung) und keine Integration mit Ihrer Codebasis oder Ihrem CMS.
Entwickler-Übersetzungstools für Software-Teams
Entwickler-Übersetzungstools sind für einen grundlegend anderen Workflow konzipiert. Anstatt Ad-hoc-Texte zu übersetzen, verwalten sie die Übersetzung strukturierter Inhalte — UI-Strings, CMS-Einträge, Dokumentation — über den gesamten Produktlebenszyklus. Die wichtigsten Fähigkeiten, die Entwicklertools von verbraucherorientierten Online-Übersetzungstools unterscheiden:
- Codebasis-Integration: Entwicklertools verbinden sich mit Ihrem Git-Repository, CMS oder Ihrer CI/CD-Pipeline. Übersetzungen fließen automatisch in Ihre Codebasis ein und heraus — nicht per Kopieren und Einfügen.
- Translation Memory: Jede genehmigte Übersetzung wird gespeichert und wiederverwendet. Wenn derselbe String in einem neuen Kontext erscheint, schlägt das Tool sofort die genehmigte Übersetzung vor, was Kosten spart und Konsistenz sicherstellt.
- Glossar- und Terminologieverwaltung: Markenbegriffe, Produktnamen und technischer Jargon werden einmal definiert und in allen Übersetzungen und allen Sprachen durchgesetzt.
- Review-Workflows: Übersetzungen durchlaufen konfigurierbare Review-Stufen, bevor sie in die Produktion gelangen. Marketingtexte erfordern möglicherweise eine menschliche Überprüfung, während UI-Strings mit hohem Vertrauensscore automatisch genehmigt werden können.
- Dateiformat-Unterstützung: Entwicklertools unterstützen die spezifischen Formate Ihrer Codebasis — JSON, YAML, PO, XLIFF, iOS
.strings, Android XML, Flutter ARB — nicht nur reinen Text. - Automatisierung: Webhooks, CLI-Tools und APIs ermöglichen vollständig automatisierte Übersetzungspipelines, bei denen neue Strings erkannt, übersetzt, geprüft und ohne manuelle Eingriffe zusammengeführt werden.
Die Lücke schließen
Einige Teams beginnen mit Online-Übersetzungstools für schnelle Übersetzungen und stellen später fest, dass sie die Workflow-, Memory- und Integrationsfunktionen von Entwicklertools benötigen. Der Übergang erfolgt in der Regel, wenn einer dieser Schmerzpunkte akut wird: das wiederholte Übersetzen derselben Strings (kein Translation Memory), inkonsistente Terminologie über Seiten oder Features hinweg (kein Glossar) oder das Aufwenden von Entwicklerzeit für das manuelle Verschieben von Übersetzungsdateien zwischen Systemen (keine Automatisierung).
Better i18n verbindet beide Welten. Sein KI-Übersetzungsmotor liefert die sofortige Übersetzungsgeschwindigkeit von Online-Tools, während die Plattformschicht Translation Memory, Marken-Glossar-Erzwingung (automatisch mit DeepL synchronisiert), Review-Workflows, Git-Sync, CLI-Tools und eine REST API mit 200+ Endpunkten hinzufügt. Teams nutzen es sowohl als Übersetzer-Tool für schnelle Ad-hoc-Übersetzungen als auch als vollständige Automatisierungsplattform für kontinuierliche Lokalisierung.
Warum Übersetzungsworkflows automatisieren?
Manuelle Übersetzungsworkflows erzeugen an jedem Schritt Reibung:
- Entwickler extrahiert neue Strings und exportiert eine Datei
- Entwickler lädt die Datei ins TMS hoch oder sendet sie an Übersetzer
- Übersetzer übersetzt und exportiert die fertige Datei
- Entwickler lädt die übersetzte Datei herunter und integriert sie
- Entwickler prüft auf Formatierungsfehler, fehlende Keys und Platzhalter-Fehler
Jede Übergabe führt zu Verzögerungen, Fehlern und Koordinationsaufwand. Laut der Globalization and Localization Association (GALA) berichten Organisationen, die Lokalisierungs-Workflows automatisieren, von schnelleren Release-Zyklen und weniger lokalisierungsbedingten Fehlern.
Automatisierungsansätze
1. Webhook-gesteuerte Workflows
Webhooks ermöglichen ereignisgesteuerte Automatisierung — wenn sich etwas ändert, wird automatisch eine Aktion ausgelöst.
Häufige Webhook-Muster:
Quellinhalt geändert → ins TMS übertragen:
Git push (neue/geänderte Strings) → Webhook löst TMS-Import aus → Übersetzer werden über neuen Inhalt benachrichtigt → Übersetzung beginnt sofort
Übersetzung abgeschlossen → ins Repository ziehen:
Übersetzung im TMS als abgeschlossen markiert → Webhook löst CI-Job aus → CI zieht übersetzte Dateien → Erstellt PR mit aktualisierten Übersetzungen → Automatisierte Prüfungen laufen (Formatierung, Vollständigkeit)
Vorteile:
- Echtzeit — Aktionen werden sofort ausgelöst, wenn Ereignisse eintreten
- Kein Polling-Overhead — das TMS benachrichtigt Ihr System
- Flexibel — Webhooks können beliebige nachgelagerte Aktionen auslösen
Überlegungen:
- Erfordert Webhook-Endpunkt (Serverless-Funktion oder CI-Webhook-Trigger)
- Muss doppelte/Wiederholungs-Ereignisse idempotent behandeln
- Netzwerkzuverlässigkeit beeinflusst die Zustellung
2. CLI-basierte CI/CD-Integration
CLI-Tools integrieren die Übersetzungssynchronisierung direkt in Ihre Build- und Deployment-Pipeline.
Push beim Merge in main:
# GitHub Actions Beispiel
on:
push:
branches: [main]
paths: ['src/locales/en/**']
jobs:
sync-translations:
steps:
- uses: actions/checkout@v4
- name: Quell-Strings übertragen
run: |
npx better-i18n push --source en
Pull vor dem Deployment:
# Aktuelle Übersetzungen während des Builds laden
jobs:
build:
steps:
- uses: actions/checkout@v4
- name: Übersetzungen laden
run: npx better-i18n pull --all-locales
- name: Anwendung bauen
run: npm run build
Geplante Synchronisierung:
# Tägliche Übersetzungssynchronisierung
on:
schedule:
- cron: '0 6 * * *' # Täglich 6:00 Uhr UTC
jobs:
sync:
steps:
- name: Übersetzungen laden und committen
run: |
npx better-i18n pull --all-locales
git add src/locales/
git diff --staged --quiet || git commit -m "chore: sync translations"
git push
Vorteile:
- Läuft in bestehender CI/CD-Infrastruktur
- Versionskontrolliert — alle Änderungen werden in Git verfolgt
- Testbar — Übersetzungsprüfungen laufen neben anderen CI-Prüfungen
- Vorhersehbar — läuft auf definierten Triggern
Überlegungen:
- Erfordert CI/CD-Plattform (GitHub Actions, GitLab CI, etc.)
- CLI-Tool muss in der CI-Umgebung installiert sein
- Authentifizierungs-Tokens benötigen sichere Speicherung
3. API-getriebene benutzerdefinierte Automatisierung
REST APIs ermöglichen benutzerdefinierte Automatisierungs-Workflows, die auf spezifische Bedürfnisse zugeschnitten sind.
Häufige API-Automatisierungsmuster:
- Übersetzungsstatus-Dashboard: API für Echtzeit-Abschlussstatus über Sprachen hinweg abfragen
- Vor-Release-Prüfungen: API-Aufruf zur Überprüfung, ob alle Übersetzungen vor dem Deployment vollständig sind
- Automatisierte Key-Erstellung: Neue Feature-Flags erstellen automatisch Platzhalter-Übersetzungen
- Qualitätsüberwachung: Übersetzungsqualitäts-Metriken periodisch über API prüfen
Beispiel: Übersetzungsprüfung vor dem Deployment:
async function checkTranslationsReady(locale: string): Promise<boolean> {
const response = await fetch(`${TMS_API}/projects/${PROJECT}/languages/${locale}/status`, {
headers: { 'Authorization': `Bearer ${API_TOKEN}` }
});
const status = await response.json();
return status.completionPercentage >= 95;
}
Behandlung von Sonderfällen
Partielle Übersetzungen
Nicht alle Strings werden gleichzeitig übersetzt. Ihre Automatisierung sollte folgendes behandeln:
- Fallback-Strategie: Fehlende Übersetzungen fallen auf die Quellsprache zurück
- Schwellenwert-Deployment: Einen Locale erst deployen, wenn er einen minimalen Abschluss-Prozentsatz erreicht
- Schrittweiser Rollout: Teilweise übersetzte Locales zunächst nur an eine Teilmenge der Benutzer ausliefern
Branch-bewusste Übersetzung
Beim Arbeiten mit Feature-Branches:
- Branch-Isolierung: Übersetzungen für einen Feature-Branch fließen nicht in main ein
- Branch-Merging: Wenn das Feature gemergt wird, werden seine Übersetzungen ebenfalls gemergt
- Konfliktlösung: Fälle behandeln, bei denen derselbe Key in verschiedenen Branches geändert wurde
Rollback-Szenarien
Wenn ein Deployment zurückgerollt werden muss:
- Übersetzungsdateien in Git versioniert: Standard-
git revertfunktioniert - TMS-Status: Überlegen, ob der TMS-Status zurückgesetzt werden muss (in der Regel nicht — Übersetzungen sind additiv)
- Cache-Invalidierung: Bei Verwendung von CDN-gecachten Übersetzungen sicherstellen, dass der Cache beim Rollback invalidiert wird
Vergleich der Plattform-Automatisierungsfähigkeiten
| Fähigkeit | Webhook | CLI/CI | API | Allgemeine Unterstützung |
|---|---|---|---|---|
| Quelldatei-Push | Automatisch bei Git push | CI-Schritt | Benutzerdefiniertes Skript | Die meisten Plattformen |
| Übersetzungs-Pull | Bei Abschlussereignis | Geplant/ausgelöst | Benutzerdefiniertes Skript | Die meisten Plattformen |
| Branch-Bewusstsein | Plattformabhängig | Über Git Branch | Benutzerdefinierte Logik | Begrenzt |
| Vor-Deployment-Prüfungen | Über Webhook-Kette | CI-Gate-Schritt | API-Abfrage | Einige Plattformen |
| Key-Extraktion aus Code | Nicht verfügbar | CLI-Scan-Befehl | Nicht verfügbar | Einige Plattformen |
| Automatische PR-Erstellung | CI-Schritt nach Webhook | CI-Schritt | Benutzerdefiniertes Skript | Über CI/CD |
| Übersetzungsvollständigkeits-Gate | Ereignisbasiert | CI-Prüfung | API-Abfrage | Die meisten Plattformen |
Aufbau einer vollständigen Automatisierungs-Pipeline
Eine vollständig automatisierte Lokalisierungs-Pipeline kombiniert mehrere Ansätze:
Entwickler schreibt Code mit Übersetzungs-Keys ↓ CI extrahiert neue Keys (CLI scan) ↓ CI überträgt Quell-Strings ins TMS (CLI push) ↓ TMS benachrichtigt Übersetzer (automatisch) ↓ Übersetzer arbeiten im TMS-Editor ↓ Übersetzung abgeschlossen → Webhook wird ausgelöst ↓ CI zieht Übersetzungen, führt QA-Prüfungen durch ↓ PR mit aktualisierten Übersetzungsdateien erstellt ↓ PR nach Review gemergt ↓ Deployment enthält aktuelle Übersetzungen ↓ Monitoring bestätigt korrekte Darstellung der Übersetzungen
Einstieg in die Automatisierung
Schritt 1: Engpass identifizieren
Vor der Automatisierung ermitteln, wo Zeit verschwendet wird:
- Manuelle Datei-Uploads/-Downloads? → CLI push/pull
- Warten auf den Abschluss von Übersetzungen? → Webhook-Benachrichtigungen
- Fehlende Übersetzungen in der Produktion? → CI-Vollständigkeitsprüfungen
- Koordinations-E-Mails? → Automatisierte Statusberichte über API
Schritt 2: Klein anfangen
Mit der wirkungsvollsten Automatisierung beginnen:
- CI push bei Merge — stellt sicher, dass Quell-Strings immer aktuell sind
- Geplanter Pull — tägliche Synchronisierung hält Übersetzungen frisch
- Vor-Deployment-Prüfung — verhindert das Ausliefern unvollständiger Übersetzungen
Schritt 3: Schrittweise erweitern
Mehr Automatisierung hinzufügen, wenn der Workflow reift:
- Branch-bewusste Übersetzungs-Workflows
- Automatisierte QA-Prüfungen (Platzhalter-Validierung, Längenbegrenzungen)
- Übersetzungsstatus-Dashboards
- Automatisierte Reviewer-Zuweisung
FAQ
Brauche ich Webhooks, wenn ich eine CI/CD-Integration habe?
Nicht unbedingt. CI/CD-basierter Pull (geplant oder bei Merge ausgelöst) deckt die meisten Anwendungsfälle ab. Webhooks bieten Mehrwert, wenn Sie auf TMS-Ereignisse in Echtzeit reagieren müssen (z. B. sofortiges Deployment, wenn Übersetzungen abgeschlossen sind).
Wie gehe ich mit Übersetzungs-Keys um, die aus dem Code entfernt wurden?
Die meisten CLI-Tools unterstützen einen „purge"- oder „cleanup"-Befehl, der Keys aus dem TMS entfernt, die nicht mehr im Quellcode vorhanden sind. Führen Sie diesen regelmäßig oder als Teil Ihrer CI-Pipeline aus, um Übersetzungen mit dem Code synchron zu halten.
Was passiert, wenn Übersetzungen während eines laufenden Deployments aktualisiert werden?
Verwenden Sie einen „Snapshot"-Ansatz: Übersetzungen zu Beginn des Build-Prozesses laden und diesen Snapshot für das gesamte Deployment verwenden. Neue Übersetzungen werden im nächsten Deployment-Zyklus einbezogen.
Wie teste ich Übersetzungen in Staging-Umgebungen?
Übersetzungen als Teil Ihres Staging-Build-Prozesses laden, genauso wie Sie es für die Produktion tun. Einige Plattformen unterstützen Branch-bewusste Übersetzungen, sodass Sie feature-spezifische Übersetzungen in der Staging-Umgebung testen können, bevor Sie mergen.
Leitfaden basierend auf gängigen Mustern moderner TMS-Plattformen, Stand März 2026.