CI/CD für Lokalisierung: Übersetzungen in Ihrer Deployment Pipeline automatisieren

CI/CD für Lokalisierung: Übersetzungen in Ihrer Deployment Pipeline automatisieren

Wichtigste Erkenntnisse

• CI/CD-Integration eliminiert die manuelle Verwaltung von Übersetzungsdateien und stellt sicher, dass Übersetzungen mit jedem Deployment ausgeliefert werden
• Automatisierte String-Extraktion und Validierung erkennen fehlende Übersetzungen, bevor sie die Produktion erreichen
• Webhook-ausgelöste Builds ermöglichen kontinuierliche Lokalisierung — Übersetzungen gehen live, sobald sie genehmigt werden
• Pre-Merge-Prüfungen können PRs mit nicht übersetzten Strings blockieren und verhindern, dass unvollständige Lokalisierungen ausgeliefert werden

Warum Lokalisierung in CI/CD automatisieren?

Manuelle Lokalisierungs-Workflows erzeugen Engpässe:

• Entwickler vergessen, neue Strings ins TMS hochzuladen
• Übersetzte Dateien liegen im TMS und warten darauf, dass jemand sie herunterlädt
• Merge-Konflikte entstehen durch manuelles Ablegen von Dateien
• Fehlende Übersetzungen gelangen in die Produktion

CI/CD-Automatisierung löst diese Probleme, indem sie die Übersetzungssynchronisation zu einem Standardbestandteil jedes Builds und Deployments macht.

Pipeline-Architektur

Code Push → CI Triggered → Extract Strings → Push to TMS
                                                  ↓
Production ← Deploy ← Build ← Pull Translations ← Translations Complete (webhook)

Implementierung mit GitHub Actions

Bei Pull Request: Übersetzungen validieren

name: Translation Check
on: pull_request

jobs:
  check-translations:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Scan for new strings
        run: npx better-i18n scan --check
        # Schlägt fehl, wenn nicht übersetzte Strings gefunden werden

      - name: Validate translation files
        run: npx better-i18n validate
        # Prüft JSON-Syntax, fehlende Schlüssel, Platzhalter-Konsistenz

Bei Merge in Main: Synchronisieren und Deployen

name: Deploy with Translations
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Push new strings to TMS
        run: npx better-i18n push
        env:
          BETTER_I18N_TOKEN: ${{ secrets.BETTER_I18N_TOKEN }}

      - name: Pull latest translations
        run: npx better-i18n pull --all

      - name: Build
        run: npm run build

      - name: Deploy
        run: npm run deploy

Bei abgeschlossener Übersetzung: Webhook-ausgelöster Build

name: Translation Update
on:
  repository_dispatch:
    types: [translations-updated]

jobs:
  rebuild:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npx better-i18n pull --all
      - run: npm run build
      - run: npm run deploy

Automatisierte Validierungsprüfungen

Integrieren Sie diese Prüfungen in Ihre CI Pipeline:

Umgang mit unvollständigen Übersetzungen

Nicht alle Übersetzungen werden zum Deployment-Zeitpunkt vollständig sein. Strategien:

1. Fallback auf Quellsprache — Englisch anzeigen, wenn Übersetzung fehlt (häufigste Methode)
2. Deployment blockieren — Nur deployen, wenn alle Ziel-Locales zu 100 % übersetzt sind (strengste Methode)
3. Prozentsatz-Schwellenwert — Deployen, wenn Locale zu >90 % übersetzt ist, blockieren wenn darunter
4. Schlüssel-Priorität — Kritische UI-Strings müssen übersetzt werden, nicht-kritische können zurückfallen

FAQ

Sollte ich Übersetzungsdateien in git committen? Ja. Das Committen von Übersetzungsdateien stellt sicher, dass Builds auch funktionieren, wenn die TMS-API nicht verfügbar ist. Die CI Pipeline zieht frische Übersetzungen und committet Änderungen automatisch.

Wie verhindere ich Merge-Konflikte in Übersetzungsdateien? Verwenden Sie das TMS als Single Source of Truth. CI zieht Übersetzungen bei jedem Build frisch und überschreibt lokale Dateien. Entwickler bearbeiten Übersetzungsdateien niemals manuell.

Was tun, wenn Übersetzungen nicht bereit sind, wenn ich deployen muss? Verwenden Sie Fallback-Strategien (Quellsprache für nicht übersetzte Strings anzeigen). Verfolgen Sie den Übersetzungsfortschritt und setzen Sie Warnungen, wenn er unter den Schwellenwert fällt.

Wie gehe ich mit Branch-basierter Entwicklung um? Pushen Sie Strings aus Feature-Branches in separate TMS-Namespaces oder -Branches. Übersetzungen zusammenführen, wenn der Feature-Branch in main gemergt wird.

Kann ich Lokalisierungs-CI/CD auch für mobile Apps betreiben? Ja. Dieselben Prinzipien gelten — Strings ins TMS pushen, Übersetzungen während des Builds ziehen, vor dem Release validieren. Mobilspezifisch: ASO-Metadaten in die Pipeline einbeziehen und .strings/.xml-Dateiformate validieren.