Weblate Commit Batching: Reducing CI Noise from Automated Translation Commits

The problem: every save can start a build

Weblate can push translation changes back to Git as soon as a translator saves a string. If your component is set to commit on every change, a single editing session can produce dozens of commits. Each commit can trigger your CI/CD pipeline, run test suites, and consume build minutes. Worse, the repository history becomes hard to review because translation noise is mixed with code changes.

The useful takeaway is to stop treating Weblate as a real-time commit source. Instead, batch its output, attribute it to a dedicated bot account, and route it through a merge request before it reaches your main branch.

How Weblate decides when to commit

A Weblate component maps files in a Git repository to translation units. When a translator saves in the UI, Weblate serializes the change through a pluggable translator for the file format—gettext PO files, Fluent, Java properties, and others—and stages a commit. You control this behavior per component with commit frequency, commit message, and author settings.

Commit frequency options generally include committing immediately, per user, or after a period of inactivity. The inactivity delay is the engineering lever that protects CI: Weblate waits until translators stop saving for a configured window, then issues one commit for the pending changes.

Worked example: batching gettext commits

Suppose your repository stores gettext catalogs under locale/ and you want Weblate to commit no more than once every ten minutes of inactivity. In the Weblate component settings, configure:

Repository URL: https://git.example.com/org/app.git
Branch: main
Filemask: locale/*/LC_MESSAGES/*.po
Source language: en
Translation languages: cs, de, fr
Commit message: [weblate] Translated using Weblate
Commit author name: Weblate Bot
Commit author email: [contact removed]
Commit on inactivity: 600 seconds
Push on commit: enabled

Where to run verification: on a local machine or CI runner with read access to the repository and network access to Weblate.

git clone https://git.example.com/org/app.git
cd app
git log --oneline --author="Weblate Bot" -n 10

Required permissions: Weblate needs write access to the repository, typically through a deploy key or personal access token. You need read access to inspect history locally.

Expected check: after saving several strings in the Weblate UI, wait longer than the inactivity window, then inspect the repository. You should see a single commit from the bot author with the configured message prefix, not one commit per string. If you see immediate commits, the batching delay is not applied or the component is set to commit on every change.

Risk: batching means a translation saved in Weblate does not appear in Git immediately. Downstream processes that consume translation files directly from the main branch will see stale content until the batch commit lands.

Protect the main branch with a translation branch

Pushing directly to main means every batch commit can still trigger CI. A safer pattern is to configure Weblate to push to a dedicated branch, such as weblate/translations, and require a merge request to main. Developers review the diff, confirm no source strings were accidentally altered, and merge only when the change is intentional.

This adds a review step but keeps CI off the main branch until a human approves the translation batch. It also makes rollback straightforward: revert the merge commit if a bad batch slips through.

Trade-offs and limitations

• Batching delays visibility of translations in Git, which can affect tools that generate localized builds directly from the repository.
• Merge conflicts can still occur if developers edit the same .po files in Git while Weblate is committing to the translation branch.
• Repositories with thousands of small translation files may slow down Weblate's synchronization scan, regardless of commit batching.

Practical way to check the result

Enable Weblate's synchronization logs for the component and confirm that push events complete without errors. Then, from a clone of the repository, run:

git log --oneline --grep="weblate" -n 20

Verify the commits carry the bot author, the expected message prefix, and appear at the batch interval you configured rather than on every save. If the log shows gaps longer than your inactivity window, Weblate may be failing to push; check the component's error logs and repository write permissions.

Close the loop by assigning an owner to review translation merge requests. That person becomes the gate between Weblate's automated output and your protected branch, turning continuous localization from a CI liability into a controlled contribution.