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