Handling merge requests from Weblate translation

Daniel P. Berrangé berrange at redhat.com
Fri Jun 5 13:28:58 UTC 2020

The libvirt project is now converted to use Weblate for translation.
Weblate has its own fork of libvirt git repos.

With weblate managing translations, NEVER, under any circumstances
should anyone change the .po files in libvirt.git directly. This will
result in merge conflicts with Weblate that need tedious manual
resolution. Any .po file changes must always be done via the Weblate

Changes made in the weblate UI are not committed to its fork immediately.
Weblate will wait upto 24 hours before committing. It will keep changes
by each translator as separate commits, and will add SoB lines to them.
When it has commits ready, it opens a merge request in GitLab. If it has
more commits later and the merge request is still open, it will just push
to the pre-existing merge request instead of opening a new one.

What this means is that if we immediately approve & merge a weblate merge
request, it'll likely open a new one the very next day. I don't think we
want to be opening & closing 30 merge requests a month for translations.

Thus I'm suggesting that we leave weblate merge requests open to accumulate
new commits. Only approve & merge them during the freeze period.

Any time we update the libvirt.pot, weblate will msgmerge all the .po files
and submit them back to libvirt. These are going to be quite large commits.

My intention is to only update the libvirt.pot at the time that we start the
release freeze period. This leaves a week to receive new translations, during
which time libvirt strings shouldn't be changing much anyway, since we're
in bugfix only mode.

|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

More information about the libvir-list mailing list