On Thu, Mar 30, 2023 at 11:37:55AM +0200, Jiri Denemark wrote:
On Mon, Mar 27, 2023 at 15:37:34 +0100, Daniel P. Berrangé wrote:
On Mon, Mar 27, 2023 at 01:08:09PM +0200, Jiri Denemark wrote:
On Fri, Mar 10, 2023 at 17:14:32 +0000, Daniel P. Berrangé wrote:
Even if fixed, it might be worth switching the .pot file anyway, but this can't be done without us bulk updating the translations, and bulk re-importing them, which will be challenging. We'll almost certainly want to try this on a throw-away repo in weblate first, not our main repo.
I was able to come up with steps leading to the desired state:
0. lock weblate repository 1. update libvirt.pot from the most recent potfile job 2. push to libvirt.git 2. wait for translations update from Fedora Weblate and merge it 3. pull from libvirt.git 4. apply the first 50 patches from this seires (with required changes to make sure all translation strings are updated) 5. update all po files with the attached script 6. update libvirt.pot by running meson compile libvirt-pot 7. apply patch 51 of this series 8. push to libvirt.git 9. wait for translations update from Fedora Weblate and merge it 10. unlock weblate repository
This looks ok, but I'm wondering if weblate will remember all our obsolete msgids when we do step 8 ? IOW, will our po files get the 10,000 current msgids, plus another 5,000 non-position based msgids marked with '#~ msgid' ? If so that's going to massively bloat our .po files. If that's the case, then in between steps 7 and 8, we might need to rename the current weblate 'libvirt' project to 'libvirt-obsolete' disconnect it from libvirt.git and then create a new 'libvirt' project which we populate from the pristine updated .pot and .po files.
The process takes about an hour if we're lucky as weblate is quite slow when processing such large amount of changes.
The result can be seen at
https://gitlab.com/jirkade/libvirt/-/commits/format-strings
and the corresponding weblate repository at
https://translate.fedoraproject.org/projects/libvirt/test/
I used d05ad0f15e737fa2327dd68870a485821505b58f commit as a base.
Looking at this, I picked a random language (Bengali) and compared stats:
https://translate.fedoraproject.org/projects/libvirt/test/bn_IN/
vs
https://translate.fedoraproject.org/projects/libvirt/libvirt/bn_IN/
Translated strings matches to within 2 words, which is probably accounted for by being based on different HEAD
Strings with failing checks is massively different, and that is the fault of 'failing check: C format' - 1300 more failing checks afterwards.
Oops, my random generator apparently selected wrong language where the number of 'failing check: C format' issues was significantly lower then before :-)
Anyway, I did what you suggested and updated the repositories
https://gitlab.com/jirkade/libvirt/-/commits/format-strings https://translate.fedoraproject.org/projects/libvirt/test/
The content is now based on v9.2.0-rc1-8-geb677e3a10 which is just one commit behind 9.2.0-rc2.
This basically looks good to me. The only minor thing I see is that projects/libvirt/libvirt has gained some extra translations that are not in current git master. For example in cs.po there are about 6 fewer failing c-format checks in weblate that are still in cs.po That will be taken care of when you re-sync the .po files and rerun the conversion. So I think this looks ok to go ahead with after release. With regards, Daniel -- |: 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 :|