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 :|
