Brechen Translation-PRs die GitHub-Synchronisation von Lovable?

Nein, ein Translation-PR bricht die GitHub-Synchronisation von Lovable nicht, solange er in den einen Branch gemergt wird, den Lovable synchronisiert. Lovable bearbeitet immer nur einen Branch und übernimmt gemergte Commits ins Projekt – ein Translation-PR ist also einfach ein weiterer Commit, der auf diesem Branch landet. globalize.now ist KI-gestützte Lokalisierungsinfrastruktur und liefert Übersetzungen als Pull Request gegen dein Repository. Beide Systeme treffen sich damit an einem normalen Git-Merge und sonst nirgends. Die Fälle, in denen etwas schiefgeht, sind konkret und dokumentiert – dieser Beitrag geht sie durch.

Wie funktioniert die GitHub-Synchronisation von Lovable eigentlich?

Sie läuft in beide Richtungen und mit genau einem Branch. Laut Lovable-Doku bearbeitet und synchronisiert Lovable immer nur einen Branch – standardmäßig den Default-Branch des Repos, meist main. Änderungen, die du in Lovable machst, werden auf diesen Branch committet. Commits, die auf GitHub auf diesen Branch gepusht werden, übernimmt Lovable zurück.

Zwei Details sind wichtig für alles, was von außen in dein Repo schreibt.

Der Pull hängt an einer Benachrichtigung. Lovable erhält von GitHub eine Push-Benachrichtigung und aktualisiert das Projekt. Laut derselben Doku tauchen die Commits dieses Pushes in Lovable nicht auf, wenn die Benachrichtigung nie ankommt. Der dokumentierte Fix: noch einen Commit pushen, damit eine neue Benachrichtigung ausgelöst wird. Wenn du einen Translation-PR gemergt hast und der Editor trotzdem Englisch zeigt, schau zuerst hier nach.

Du kannst den synchronisierten Branch wechseln. In den GitHub-Einstellungen des Projekts gibt es eine Branch-Auswahl. Ein dort angelegter Branch zweigt vom aktuell aktiven Branch ab, nicht automatisch von main. Sobald du wechselst, bearbeitet und synchronisiert Lovable diesen Branch. Alles, was danach in main gemergt wird, bleibt für den Editor unsichtbar, bis es in den Branch gemergt ist, auf dem Lovable arbeitet.

Wenn du dir aus diesem Abschnitt nur einen Satz merkst: Der Translation-PR muss auf dem Branch landen, den die Auswahl anzeigt.

Was passiert, wenn GitHub einen Lovable-Push ablehnt?

Lovable legt die Änderung auf einem Branch namens lovable-sync ab, statt sie zu verlieren. Laut Lovable-Doku passiert das, wenn GitHub einen Push wegen Konflikten oder Branch-Protection-Regeln ablehnt. Anschließend mergst du lovable-sync über deinen normalen Review-Prozess in deinen geschützten Branch.

Ein verwandtes Sicherheitsnetz: Wird der Branch, den Lovable synchronisiert, auf GitHub gelöscht, stellt Lovable das Projekt auf einen neuen Branch namens lovable-fallback um. Und wer das Repository selbst löscht, kappt die Verbindung und beendet die Synchronisation – eine Umbenennung tut das nicht.

Nichts davon betrifft nur Übersetzungen. So soll sich ein zweiter Schreiber rund um Lovable verhalten – und ein Translation-PR ist ein höflicher zweiter Schreiber: Er kommt als reviewbarer Pull Request und pusht nie direkt auf einen geschützten Branch.

Wo passt ein Translation-PR ins Bild?

Zwischen Lovables Commits und deinem Merge-Button. In einem Lovable-Projekt, in dem der lovable-i18n-Skill bereits installiert ist und die Regeln in Lovables Knowledge dafür sorgen, dass neue Strings gewrappt bleiben, sieht der Ablauf so aus.

1. Lovable schreibt ein Feature und wrappt die neuen Strings in Lingui-Makros. Es committet auf den synchronisierten Branch.
2. Ein GitHub-Workflow extrahiert die gewrappten Strings in die PO-Kataloge unter src/locales/ und committet den Sync zurück. Lovable hat kein Terminal – die Extraktion muss also in GitHub laufen statt im Editor.
3. Die Konvertierung passiert einmalig in der App: Du verbindest das Repository, globalize.now konvertiert die Codebase einmal und liefert den Katalog als Pull Request. Danach übersetzen Push-Jobs neue Katalogeinträge und liefern die übersetzten Kataloge ebenfalls als Pull Requests.
4. Du mergst den Pull Request in den synchronisierten Branch. Lovable übernimmt den Merge-Commit, und die App rendert die neue Sprache.

Beachte, was fehlt: kein Import-Schritt in Lovable, kein Export aus einem Web-Dashboard, kein Widget, das Übersetzungen zur Laufzeit lädt. Die übersetzten Dateien sind ganz normale Dateien in deinem Repo – das ist das Argument hinter dem Ansatz, eine Lovable-App ohne Dashboard zu lokalisieren. Die genauen Schritte zum Verbinden stehen auf der Lovable-Integrationsseite.

Können Lovable und ein Translation-PR kollidieren?

Ja, im ganz normalen Git-Sinn – und selten, wenn du Pull Requests kurzlebig hältst. Ein Konflikt entsteht nur, wenn beide Schreiber zwischen Branch und Merge dieselben Zeilen derselben Datei ändern.

Die einzige realistische Überschneidung ist der PO-Katalog. Wenn Lovable einen String hinzufügt, hängt es an jede src/locales/*/messages.po einen neuen Eintrag mit leerer Übersetzung an – die App fällt dann auf den Quelltext zurück. Der Translation-PR trägt den übersetzten Text für Einträge ein, die schon im Katalog standen, als er geöffnet wurde. Hängt Lovable neue Einträge ans Dateiende an, während der Pull Request Einträge weiter oben in derselben Datei ändert, führt Git beides ohne Beanstandung zusammen. Ändern beide denselben Eintrag, bekommst du eine Konfliktmarkierung.

Drei Gewohnheiten halten dieses Zeitfenster klein.

Merge Translation-PRs am Tag, an dem sie geöffnet werden. Nur wenn ein Pull Request eine Woche liegt, während Lovable zehn Features ausliefert, wird es unübersichtlich.

Bearbeite die Referenzkommentare an Katalogeinträgen nie von Hand. Der Extraktions-Workflow erzeugt die Zeilen #. und #: neu. Wenn du einen Konflikt auflöst, behalte also den Eintrag mit dem übersetzten Text und lass den nächsten Extraktionslauf die Kommentare neu schreiben.

Bring einen veralteten Branch auf den aktuellen Stand, bevor du mergst. Liegt der PR-Branch zurück, aktualisiere ihn zuerst:

git fetch origin
git checkout <translation-branch>
git merge origin/<synced-branch>

Löse alles auf, was Git markiert, pushe und merge. Weil die Kataloge Text sind und jede Message ein eigener Block ist, löst du fast immer nur einen Eintrag auf, nicht die ganze Datei.

Was ändert Branch Protection?

Sie fügt eine Prüfung hinzu, und Prüfung ist ohnehin das Modell. Eine Übersetzung, die als Pull Request geliefert wird, durchläuft alle erforderlichen Prüfungen und Genehmigungen deines Branches. Lovables eigene Pushes, die ein geschützter Branch ablehnt, landen auf lovable-sync, den du über denselben Review-Prozess mergst. Die beiden Wege sind getrennt, und keiner blockiert den anderen.

Wenn du den Default-Branch schützt und Lovable ihn trotzdem bearbeiten lässt, musst du lovable-sync regelmäßig mergen – das ist dokumentiertes Verhalten von Lovable, kein Übersetzungsproblem. Stört dich das, kannst du entweder die Schutzregel für Lovables Autor lockern oder in den Projekteinstellungen auf einen dedizierten Branch umstellen. In beiden Fällen gilt: Der Translation-PR zielt auf den Branch, den Lovable synchronisiert.

Warum gab es diese Frage bei Runtime-Translation-Widgets nicht?

Weil sie nie in dein Repository geschrieben haben. Lovalingo, das am 31. August 2026 eingestellt wurde, hat die gerenderte Seite im Browser übersetzt – es gab also keine Locale-Dateien im Repo und keine Pull Requests zu mergen. Teams, die über den Migrationsleitfaden auf committete Kataloge umgestiegen sind, erleben Lovables GitHub-Sync zum ersten Mal als System mit zwei Schreibern.

Das ist der Tausch, und es ist der richtige: Der übersetzte Text gehört dir, ist versioniert und indexierbar, statt zur Renderzeit gemietet zu sein. Dafür musst du wissen, auf welchem Branch Lovable gerade arbeitet. Zur anderen Hälfte der Aufgabe, eine Lovable-App übersetzt zu halten, wenn die Kataloge dem Code hinterherhinken, siehe warum Übersetzungen bei jedem Release brechen. Und wenn deine App auch Inhalte in einer Datenbank speichert: Diese Ebene liegt außerhalb des Repos – Datenbankinhalte in einer Lovable-App lokalisieren behandelt sie.

Halte beide Schreiber auf einem Branch

Prüfe die Branch-Auswahl in den GitHub-Einstellungen deines Projekts, merge Translation-PRs in diesen Branch und behandle lovable-sync als To-do statt als Fehler. Wenn du in Lovable baust und die Übersetzungsarbeit abgeben statt pflegen willst, gibt dir die Vibe-Coder-Seite den Überblick, und die Preise haben eine eigene Seite.