Fortgeschrittene Muster

Fortgeschrittene Muster für CI/CD-Lokalisierung – Workflow-Auswahl, Vollständigkeitsprüfungen für Übersetzungen und das Beheben von Merge-Konflikten.

Den passenden Workflow wählen#

Vier Workflow-Muster decken die meisten Team-Setups ab. Jedes bringt eigene Abwägungen bei Automatisierung, Prüfungsaufwand und Branch-Hygiene mit sich.

Workflow	Am besten geeignet für	Trade-off
Direkt in main committen	Kleine Teams, reibungslose Updates	Kein Prüfungsschritt für Übersetzungen
PR aus main	Teams, die Übersetzungen prüfen möchten	Erfordert manuelle PR-Freigabe
Direkt in den Feature-Branch committen	Langlebige Feature-Branches	Übersetzungs-Commits im Branch-Verlauf
PR aus dem Feature-Branch	Maximale Kontrolle pro Feature	Mehrere PRs pro Feature müssen verwaltet werden

Wenn du unsicher bist, starte mit „Direkt in main committen“. Das ist der einfachste Workflow und verhindert Merge-Konflikte komplett, weil es keine auseinanderlaufenden Branches gibt.

Vollständigkeit von Übersetzungen prüfen#

Das Flag --frozen prüft, ob alle Inhalte übersetzt sind, ohne neue Übersetzungen zu erzeugen. Fehlen Inhalte, endet es mit einem Statuscode ungleich null:

bash

npx lingo.dev@latest run --frozen

Nutze das als Deployment-Gate, damit keine unübersetzten Inhalte live gehen.

yaml

name: Check translations
on: [push, pull_request]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npx lingo.dev@latest run --frozen

Merge-Konflikte beheben#

Merge-Konflikte entstehen, wenn die Datei i18n.lock zwischen Branches auseinanderläuft – typischerweise dann, wenn Übersetzungen in verschiedenen Branches unabhängig voneinander aktualisiert werden.

Vorbeugung#

Wenn du Übersetzungen direkt in main committest (statt dafür Feature-Branches zu verwenden), vermeidest du Konflikte in der Lockfile vollständig.

Behebung per Merge#

Merge starten

bash

git merge <branch-name>

Die konfliktbehaftete Lockfile löschen

bash

rm i18n.lock

Merge abschließen

bash

git add .
git merge --continue

Lockfile neu generieren

bash

npx lingo.dev@latest lockfile --force

Dadurch wird die Lockfile anhand des aktuellen Stands deiner Quelldateien neu erstellt, ohne neue Übersetzungen auszulösen.

Behebung per Rebase#

Der gleiche Ansatz funktioniert auch mit Rebase: Lösche i18n.lock bei jedem Konfliktschritt, setze das Rebase fort und generiere die Lockfile am Ende neu:

bash

git rebase <branch-name>
# On each conflict: rm i18n.lock && git add . && git rebase --continue
npx lingo.dev@latest lockfile --force

Nächste Schritte#

GitHub Actions

Die offizielle GitHub Action einrichten

i18n.lock

Wie die Lockfile den Übersetzungsstatus nachhält

So funktioniert's

Die CI/CD-Lokalisierungs-Pipeline

Einrichtung

CI/CD für dein Projekt konfigurieren

Fortgeschrittene Muster für CI/CD-Lokalisierung – Workflow-Auswahl, Vollständigkeitsprüfungen für Übersetzungen und das Beheben von Merge-Konflikten.

Den passenden Workflow wählen#

Vier Workflow-Muster decken die meisten Team-Setups ab. Jedes bringt eigene Abwägungen bei Automatisierung, Prüfungsaufwand und Branch-Hygiene mit sich.

Workflow	Am besten geeignet für	Trade-off
Direkt in main committen	Kleine Teams, reibungslose Updates	Kein Prüfungsschritt für Übersetzungen
PR aus main	Teams, die Übersetzungen prüfen möchten	Erfordert manuelle PR-Freigabe
Direkt in den Feature-Branch committen	Langlebige Feature-Branches	Übersetzungs-Commits im Branch-Verlauf
PR aus dem Feature-Branch	Maximale Kontrolle pro Feature	Mehrere PRs pro Feature müssen verwaltet werden

Wenn du unsicher bist, starte mit „Direkt in main committen“. Das ist der einfachste Workflow und verhindert Merge-Konflikte komplett, weil es keine auseinanderlaufenden Branches gibt.

Vollständigkeit von Übersetzungen prüfen#

Das Flag --frozen prüft, ob alle Inhalte übersetzt sind, ohne neue Übersetzungen zu erzeugen. Fehlen Inhalte, endet es mit einem Statuscode ungleich null:

bash

npx lingo.dev@latest run --frozen

Nutze das als Deployment-Gate, damit keine unübersetzten Inhalte live gehen.

yaml

name: Check translations
on: [push, pull_request]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npx lingo.dev@latest run --frozen

Merge-Konflikte beheben#

Vorbeugung#

Wenn du Übersetzungen direkt in main committest (statt dafür Feature-Branches zu verwenden), vermeidest du Konflikte in der Lockfile vollständig.

Behebung per Merge#

Merge starten

bash

git merge <branch-name>

Die konfliktbehaftete Lockfile löschen

bash

rm i18n.lock

Merge abschließen

bash

git add .
git merge --continue

Lockfile neu generieren

bash

npx lingo.dev@latest lockfile --force

Dadurch wird die Lockfile anhand des aktuellen Stands deiner Quelldateien neu erstellt, ohne neue Übersetzungen auszulösen.

Behebung per Rebase#

Der gleiche Ansatz funktioniert auch mit Rebase: Lösche i18n.lock bei jedem Konfliktschritt, setze das Rebase fort und generiere die Lockfile am Ende neu:

bash

git rebase <branch-name>
# On each conflict: rm i18n.lock && git add . && git rebase --continue
npx lingo.dev@latest lockfile --force

Nächste Schritte#

GitHub Actions

Die offizielle GitHub Action einrichten

i18n.lock

Wie die Lockfile den Übersetzungsstatus nachhält

So funktioniert's

Die CI/CD-Lokalisierungs-Pipeline

Einrichtung

CI/CD für dein Projekt konfigurieren