Do translation pull requests break Lovable's GitHub sync?

No, a translation pull request does not break Lovable's GitHub sync, provided it merges into the one branch Lovable is syncing. Lovable edits a single branch at a time and pulls merged commits back into the project, so a translation pull request is just another commit arriving on that branch. globalize.now is AI-powered localization infrastructure that delivers translations as a pull request against your repository, which means the two systems meet at a normal Git merge and nowhere else. The cases that go wrong are specific and documented, and this post walks through them.

How does Lovable's GitHub sync actually work?

It is two-way and it is single-branch. Lovable's documentation says it edits and syncs one branch at a time, by default the repository's default branch, usually main. Changes you make in Lovable are committed to that branch. Commits pushed to that branch on GitHub are pulled back into Lovable.

Two details matter for anything that writes to your repo from outside Lovable.

The pull depends on a notification. Lovable receives a push notification from GitHub and updates the project. Per the same documentation, if that notification never arrives, the commits from that push do not show up in Lovable. The documented fix is to push another commit so a fresh notification fires. If you merge a translation pull request and the editor still shows English, this is the first thing to check.

You can change the synced branch. The project's GitHub settings include a branch picker. A branch created there forks from whichever branch is currently active, not automatically from main. Once you switch, Lovable edits and syncs that branch instead. Anything merged to main after that is invisible to the editor until it is merged into the branch Lovable is on.

If you only remember one sentence from this section: the translation pull request has to land on the branch the picker shows.

What happens when GitHub rejects a Lovable push?

Lovable parks the change on a branch called lovable-sync instead of losing it. Per Lovable's docs, this happens when GitHub rejects a push because of conflicts or branch protection rules, and you then merge lovable-sync into your protected branch through your normal review process.

A related safety net: if the branch Lovable is syncing gets deleted on GitHub, Lovable switches the project to a new branch named lovable-fallback. And deleting the repository itself breaks the connection and stops syncing, while renaming it does not.

None of this is specific to translations. It is how a second writer is expected to behave around Lovable, and a translation pull request is a polite second writer: it arrives as a reviewable pull request and never pushes straight to a protected branch.

Where does a translation pull request fit in?

Between Lovable's commits and your merge button. The flow looks like this in a Lovable project that already has the lovable-i18n skill installed, with the instruction rules in Lovable's knowledge keeping new strings wrapped.

1. Lovable writes a feature and wraps the new strings in Lingui macros. It commits to the synced branch.
2. A GitHub workflow extracts the wrapped strings into the PO catalogs under src/locales/ and commits the sync back. Lovable has no terminal, so extraction has to run in GitHub rather than in the editor.
3. Conversion is one-time and happens in the app: you connect the repository and globalize.now converts the codebase once, delivering the catalog as a pull request. After that, push jobs translate new catalog units and deliver the translated catalogs as pull requests as well.
4. You merge the pull request into the synced branch. Lovable pulls the merge commit in, and the app now renders the new language.

Notice what is absent: no import step in Lovable, no export from a web dashboard, and no widget loading translations at runtime. The translated files are plain files in your repo, which is the argument behind localizing a Lovable app without a dashboard, and the exact connection steps are on the Lovable integration page.

Can Lovable and a translation pull request conflict?

Yes, in the ordinary Git sense, and it is rare when you keep pull requests short-lived. A conflict needs both writers to change the same lines of the same file between branching and merging.

The one realistic overlap is the PO catalog. When Lovable adds a string it appends a new message to each src/locales/*/messages.po with an empty translation, so the app falls back to source text. The translation pull request fills in the translated text for messages that were already in the catalog when it was opened. If Lovable appends new messages at the end of a file while the pull request edits entries earlier in the same file, Git merges both without complaint. If both touch the same entry, you get a conflict marker.

Three habits keep that window small.

Merge translation pull requests the day they open. A pull request that sits for a week while Lovable ships ten features is the only way this gets noisy.

Never hand-edit the reference comments on catalog entries. The extraction workflow regenerates the #. and #: lines, so if you resolve a conflict, keep the entry with the translated text and let the next extraction run rewrite the comments.

Catch a stale branch up before merging. If the pull request branch has fallen behind, update it first:

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

Resolve anything Git flags, push, and merge. Because the catalogs are text and each message is a block, the conflict you resolve is almost always one entry, not the file.

What does branch protection change?

It adds review, and review is already the model. A translation delivered as a pull request goes through whatever required checks and approvals your branch has. Lovable's own pushes that a protected branch rejects arrive on lovable-sync, which you merge through the same review. The two paths are separate and neither blocks the other.

If you protect the default branch and also let Lovable edit it, expect to merge lovable-sync periodically; that is Lovable's documented behaviour, not a translation problem. If it bothers you, the options are to relax the protection rule for Lovable's author or to switch the synced branch to a dedicated one in the project's settings. In both cases, point the translation pull request at whichever branch Lovable is syncing.

Why did this question not exist with runtime translation widgets?

Because they never wrote to your repository. Lovalingo, which shut down on 31 August 2026, translated the rendered page in the browser, so there were no locale files in the repo and no pull requests to merge. Teams that moved to committed catalogs through the migration guide are meeting Lovable's GitHub sync as a two-writer system for the first time.

That is the trade, and it is the right one: the translated text is yours, versioned and indexable, instead of rented at render time. It does ask you to know which branch Lovable is on. For the other half of keeping a Lovable app translated, where catalogs lag behind code, see why translations break every time you ship. If your app also stores content in a database, that layer lives outside the repo; localizing database content in a Lovable app covers it.

Keep both writers on one branch

Check the branch picker in your project's GitHub settings, merge translation pull requests into that branch, and treat lovable-sync as a to-do rather than an error. If you are building in Lovable and want the translation work handled instead of maintained, the vibe coders page is the overview and pricing is on its own page.