Weblate Component Git Push: Syncing Translations to the Default Branch

Translations committed in Weblate but missing from Git

If your translators work in Weblate and commit changes there, but the project's Git repository never receives those updates, the missing piece is usually the component-level push setting. Enabling it tells Weblate to run a git push after translations are committed, sending the changes to the remote repository defined for that component.

What the push toggle actually does

Weblate keeps a local Git repository for each component (or a shared repository if multiple components point to the same source). When push is enabled, Weblate performs two steps after a commit:

1. It writes the translation files according to the component's file format and file path mask—for example, locales/*/messages.po or src/i18n/*.json.
2. It pushes the resulting commit to the remote repository URL stored in the component settings.

The push targets the remote repository's default branch, typically main or master. Weblate does not create a feature branch or open a pull request through this toggle; it updates the default branch directly.

Worked example: enabling push for a JSON locale component

Consider a component that manages front-end translations stored as JSON files. The component is linked to [contact removed]:acme/webapp.git, and the file mask is public/locales/*.json. After a translator submits a string and it is committed, Weblate updates the matching JSON file and pushes the commit to the main branch of that repository.

To configure this in Weblate:

• Open the component's Configuration page (requires administrator or project-owner permissions).
• Locate the Repository push URL field and confirm it contains the correct remote endpoint.
• Enable the Push checkbox. In some Weblate versions this may appear as Push on commit.
• Save the component settings.

Credentials are not entered in this dialog. Weblate uses the repository access credentials configured for the component—either an SSH key added to the remote or an HTTPS token stored in the component's repository settings. If those credentials expire or lose write access, the push fails silently from the translator's perspective.

Limits and common mistakes

Automatic push is convenient, but it has hard boundaries:

• Default branch only. If your workflow requires pull requests, release branches, or protected main branches, direct pushes will be rejected or will bypass review.
• Credential drift. Expired SSH keys or revoked tokens leave translations locked inside Weblate. The interface may still show the commit as successful locally, but the remote never receives it.
• Shared repository conflicts. If several components share one Git repository and push is enabled on more than one, Weblate may attempt to push local commits that are behind the remote. If upstream commits were not pulled first, the push fails with a non-fast-forward error, or—in misconfigured setups—risks overwriting work.
• Autoaccept amplification. Over-aggressive autoaccept settings can promote unreviewed translations to committed status. With push enabled, those unreviewed strings are immediately published to the repository.

How to verify the result

Do not assume the push worked because the translation disappeared from the Weblate to-do list. Check it explicitly:

1. Open the component's Repository tab and use the Push action to trigger a manual push. Note the timestamp of the last successful push shown in the repository status.
2. Inspect the Weblate Audit log for the component. Look for entries that record push attempts, including failure messages such as authentication errors or rejected non-fast-forward updates.
3. In a local clone of the remote repository, run git fetch origin followed by git log origin/main --oneline -5 to confirm the Weblate commit is present on the default branch.

If the commit is absent, the audit log entry usually explains why: expired credentials, network failure, or remote branch protection rules.

When to leave push disabled

Keep the push toggle off if your team reviews translations through pull requests, if the remote repository enforces branch protection, or if the component shares a repository with other projects that manage their own Git history. In those cases, commit translations in Weblate and let an external CI/CD job handle the synchronization, using Weblate's API or webhook notifications to trigger the pipeline.