|
Dokumentation
Demo buchenPlattform
PlattformMCPCLIAPIWorkflows
LeitfädenChangelog

Kontinuierliche Lokalisierung

  • So funktioniert's
  • Einrichtung

Plattformen

  • GitHub App
  • GitHub Actions
  • GitLab CI/CD
  • Bitbucket Pipelines
  • Fortgeschrittene Muster

Kontinuierliche Lokalisierung

Lingo.dev hält Übersetzungen mit Ihrem Code synchron. Bei jeder Änderung erkennt es, welche Inhalte angepasst wurden, übersetzt sie mit Ihrer verbundenen Lokalisierungs-Engine – inklusive Glossarregeln, Markenstimme und sprachspezifischer Modellkonfiguration, die konsequent angewendet werden – und committet die Ergebnisse oder eröffnet einen Pull Request. Unvollständige Übersetzungen gelangen nie in die Produktion.

Wählen Sie Ihre Integration#

Für jede Integration gibt es eine eigene Anleitung. Wählen Sie die Variante, die zu Ihrem Setup passt:

IntegrationSo läuft sie
GitHub AppEinmal installieren. Lingo.dev übernimmt die Lokalisierung bei Pushes auf den Standard-Branch und – wenn aktiviert – auch bei Pull Requests für Sie. Kein Runner, kein API-Key-Secret, keine Lockfile.
GitHub ActionsFührt die CLI über die offizielle Action in Ihrer GitHub-Actions-Pipeline aus.
GitLab CI/CDFührt die CLI über das offizielle Docker-Image in GitLab-Pipelines aus.
Bitbucket PipelinesFührt die CLI über die offizielle Pipe in Bitbucket-Pipelines aus.

Abgesehen von der GitHub App nutzt jede Integration die Lingo.dev CLI. Damit kann jede CI/CD-Umgebung mit Node.js die Lokalisierung direkt ausführen – auch ohne native Integration.

So funktioniert die GitHub App#

Installieren Sie die App einmal und fügen Sie dem Repository eine .lingo/config.json hinzu. Danach übernimmt Lingo.dev die Lokalisierung für Sie – ohne Pipeline, ohne API-Key-Secret, ohne Lockfile:

  1. Überwacht Änderungen – reagiert standardmäßig auf Pushes in den Standard-Branch und, sobald Sie onPullRequest aktivieren, auch auf Pull Requests, und prüft geänderte Dateien anhand der von Ihnen konfigurierten Quellmuster
  2. Übersetzt das Delta – leitet geänderte Quellinhalte durch die Engine, die mit engineId angegeben ist
  3. Schreibt Ergebnisse nach GitHub zurück – bei Pushes auf den Standard-Branch eröffnet oder aktualisiert sie einen Übersetzungs-Pull-Request; bei Pull Requests committet sie übersetzte Dateien in den PR-Branch und hinterlässt einen Statuskommentar
  4. Holt Versäumtes nach und bündelt Änderungen – erkennt Änderungen, die in einem früheren Lauf übersehen wurden, und verteilt sehr große Updates auf mehrere Commits

Sie können Läufe durch einen Freigabeschritt absichern oder Übersetzungen per /lingo-Befehl in einem Pull Request manuell auslösen. Die vollständige Konfiguration finden Sie im Leitfaden zur GitHub App.

So funktionieren die Pipeline-Integrationen#

GitHub Action, GitLab CI/CD, Bitbucket Pipelines und die eigenständige CLI führen alle dieselbe Lingo.dev CLI als Schritt in Ihrer bestehenden Pipeline aus. Dafür benötigen sie zwei Dinge: Ihre i18n.json-Konfiguration und einen API-Key.

Bei jedem Lauf macht die Integration Folgendes:

  1. Ermittelt Quelldateien – liest Ihre Bucket-Konfiguration, um übersetzbare Inhalte zu finden
  2. Erkennt Änderungen – vergleicht mit der i18n.lock-Lockfile, um neue oder geänderte Strings zu identifizieren, sodass nur das Delta übersetzt wird
  3. Übersetzt – leitet geänderte Inhalte durch Ihre konfigurierte Lokalisierungs-Engine, wobei alle Regeln angewendet werden – Glossar, Markenstimme, sprachspezifische Modelleinstellungen
  4. Schreibt Ergebnisse – aktualisiert Zielsprache-Dateien direkt
  5. Committet oder eröffnet einen PR – je nachdem, welchen Workflow Sie wählen

Da nur geänderte Strings übersetzt werden, laufen Jobs schnell und kosteneffizient – selbst über Dutzende von Sprachen hinweg.

Workflow-Optionen#

GitHub App#

Das Verhalten der App wird in .lingo/config.json konfiguriert:

OptionBeschreibung
Push in den Standard-Branch (onPushToDefaultBranch)Standardmäßig aktiviert. Eröffnet oder aktualisiert einen Übersetzungs-PR, wenn Änderungen an den Quellinhalten im Standard-Branch landen.
Pull-Request-Übersetzung (onPullRequest)Standardmäßig deaktiviert. Committet Übersetzungen in den PR-Branch, während sich der PR verändert.
Freigabeschritt (requireApproval)Standardmäßig deaktiviert. Erfordert Approve/Deny im Check-Run oder /lingo approve in einem PR, bevor automatische Läufe übersetzen.
Manuelle Befehle (/lingo translate)Ergänzt fehlende Übersetzungen oder erzwingt Übersetzungen für bestimmte Dateien jederzeit per PR-Kommentar.

Die vollständige Konfiguration und Befehlsreferenz finden Sie im Leitfaden zur GitHub App.

GitHub Action, GitLab CI, Bitbucket und CLI#

Vier Workflow-Muster decken die meisten Team-Setups ab:

WorkflowAuslöserErgebnis
Commit in mainPush auf mainÜbersetzungen werden direkt in main committet
PR aus mainPush auf mainPull Request mit Übersetzungen
Commit in den Feature-BranchPush auf den Feature-BranchÜbersetzungen werden in den Branch committet
PR aus dem Feature-BranchPush auf den Feature-BranchPull Request aus dem Branch

Die erste Option – Commit in main – ist die einfachste. Übersetzungen erscheinen automatisch, ganz ohne Eingriff durch Entwickler. Die PR-basierten Optionen ergänzen einen Prüfungsschritt, bevor Übersetzungen übernommen werden.

Mehr dazu, wie Sie zwischen diesen Optionen wählen, finden Sie unter Advanced Patterns.

Nächste Schritte#

GitHub App
Verwaltete kontinuierliche Lokalisierung – einmal installieren, keine Pipeline nötig
Setup
GitHub Action oder CLI konfigurieren
GitHub Actions
Die offizielle GitHub Action einrichten
Advanced Patterns
Workflow-Auswahl, Übersetzungsprüfungen, Merge-Konflikte

War diese Seite hilfreich?

Max PrilutskiyMax Prilutskiy·Aktualisiert vor 29 Tagen·3 Min. Lesezeit