Re: [virt-manager PATCH v2 0/5] Improve translations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wednesday, 8 July 2020 01:45:47 CEST Cole Robinson wrote:
> On 7/7/20 4:53 PM, Pino Toscano wrote:
> > This patch series improve the handling of translations.
> > 
> > Split the current virt-manager catalog in two:
> > - a virt-manager one, containing only the messages for the GUI; its
> >   translations are still build and installed as usual
> > - a virt-manager-meta one, containing only the messages in .in files
> >   (e.g. the appdata and the desktop files); its translations are used to
> >   create the translated versions of the files, and not installed
> > 
> > To make sure the translations are updated in Weblate, commit the two
> > catalogs in the repository.
> > 
> > This also extracts the virt-manager-meta translations out of
> > virt-manager, to make sure nothing is lost.
> > 
> > Changes from v1:
> > - fix issue in the Python sources extraction; regenerate the catalog
> >   accordingly
> > 
> 
> Thanks for the patches.
> 
> I haven't see this meta-po pattern before. Is it used elsewhere?
> [...]
> The benefit is that less translations are installed?

There are different styles for this:
- in the GNOME community, they extract all the messages (GUI, desktop
  files, AppStream files, etc) to a single catalog
- the KDE community, desktop & AppStream messages are extracted to
  their own catalogs

Both approaches have their pro and cons: a single catalog makes it
easier to extract everything there, and it's only one file to translate;
having the GUI messages only in their catalog means that unused strings
from meta files are not shipped, with some potential saving.

In the end there is not much of a difference; I can revert back to a
single catalog if deemed better. (Disclaimer: I'm from the KDE camp.)

> Does weblate handle this multi .pot/.po workflow?

Yes, you need to create a new component (that's the lingo for a gettext
catalog), specifying the path to the template, and the pattern of the
translations.

> You mention dropping some intltool usage here but a few uses remain.
> I've read that modern gettext can fully replace intltool. Do you have
> any ideas about the dropping the other usage?

Oh right, I almost forgot about that, I will send a v3 removing
intltool (which is definitely doable). Thanks for the reminder.

> One small comment, I haven't done a full review: glob.glob
> recursive=True is python 3.5+ but technically we are 3.4+. I think
> Pathlib recursive glob is 3.4+

Oh OK, I will change this too, thanks for the notice.

-- 
Pino Toscano

Attachment: signature.asc
Description: This is a digitally signed message part.


[Index of Archives]     [Linux Virtualization]     [KVM Development]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]     [Video 4 Linux]

  Powered by Linux