[virt-manager PATCH v2 0/5] Improve translations
Pino Toscano
ptoscano at redhat.com
Wed Jul 8 06:21:00 UTC 2020
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20200708/148b59e3/attachment.sig>
More information about the virt-tools-list
mailing list