Teach dh_translations how to deal with meson

That's a bit tricky. it looks like there is no easy way to "grep" for the domain under meson project. Some GNOME translators suggested that we might be able to get the value using "meson introspect" in the builddir.

If we don't figure out a reliable way to do that for meson projects then maybe we should add some extra arguments to dh_translations like --domain=<string> that let us provide the domain value from the debian/rules, that way we could keep using dh_translations rather than having to do custom override. We might also need a --refresh-target=<string> which would let us specifiy "make $domain-pot-update", or maybe just detect meson build system and use "$domain-pot-update" for those

the command which was hinted to try on IRC was

$ mesonintrospect --targets | grep -i -o '"filename": "po/[a-zA-Z_-]*pot' | grep -o [a-zA-Z_-]*-pot

with "replace '"filename": "po/[a-zA-Z_-]*pot' with '"filename": "po/[a-zA-Z_-]*-pot"'" as a tweak suggestion

Thanks, Seb. This will have to wait a few days, but I will try to check out that idea.

This just came up again. I found:

laney@nightingale> meson introspect --targets | jq -r -M '.[].name | select(endswith("-pot")) | sub("-pot"; "")'
ubuntu-default-launchers

Here's a patch for this. I don't really want to upload it without someone's review, so if anybody could take a look that'd be grand!

with this, I removed the dh_translations override from ubuntu-settings, and:

   dh_translations
 check_buildsystem: got domain 'ubuntu-default-launchers', using intltool: 0
 /usr/bin/ninja -C /home/laney/temp/ubuntu-settings-18.04.2/obj-x86_64-linux-gnu ubuntu-default-launchers-pot
ninja: Entering directory `/home/laney/temp/ubuntu-settings-18.04.2/obj-x86_64-linux-gnu'
[0/1] Running external command ubuntu-default-launchers-pot.
dh_langpack: processing files to add translation domain 'ubuntu-default-launchers'..
  gnome-initial-setup.desktop
  ubuntu-amazon-default.desktop
  com.canonical.launcher.amazon.desktop

laney@raleigh> cat debian/ubuntu-settings/usr/share/ubuntu/applications/gnome-initial-setup.desktop
[Desktop Entry]
Name=Welcome to Ubuntu
# Translators: Do NOT translate or transliterate this text (this is an icon file name)!
Icon=ubuntu-logo-icon
TryExec=/usr/lib/gnome-initial-setup/gnome-initial-setup
Exec=/usr/lib/gnome-initial-setup/gnome-initial-setup
Terminal=false
Type=Application
StartupNotify=true
NoDisplay=true
X-Ubuntu-Gettext-Domain=ubuntu-default-launchers

laney@raleigh> ls po/ubuntu-default-launchers.pot
po/ubuntu-default-launchers.pot

but I guess the main thing to check is that it's not going to break random other packages.

Smart way to find the builddir, Laney. :)

I tested with g-c-c and stumbled upon an issue: The introspect command seems to result in a newline separated list of domains, and in the case of g-c-c $domain contains the string:

'gnome-control-center-2.0
gnome-control-center-2.0-timezones'

The log file includes:

ninja: error: unknown target 'gnome-control-center-2.0
gnome-control-center-2.0-timezones-pot'

No POT built, and you can imagine what the .desktop and .policy files look like.

In the patched dh_translations I replaced:

 chomp $domain;

with

 ($domain) = split ' ', $domain;

and could then build g-c-c successfully.

Questions:

1. How do we know that we want the first domain in the list?

2. How do we generally handle packages with multiple gettext domains?

3. Is there a need to create gnome-control-center-2.0-timezones.pot? (If there is, it's another bug, I suppose.)

A side note - I noticed that this:

 # filter out translated fields
 next if (/^(Name|GenericName|Comment|X-GNOME-FullName)\[/);

means that the upstream translations of "Icon" and "Keywords" are kept. Shouldn't those be removed as well, or are they kept intentionally?

I successfully tested the modified dh_translations on libgweather, which also has two gettext domains. In that case we'd need to keep building libgweather-locations.pot in debian/rules.

https://salsa.debian.org/gnome-team/libgweather/merge_requests/1/diffs

We sort of assume there's only one domain already, don't we? What happens with current g-c-c? Probably dh_translations isn't doing anything?

I think the safest thing in this case is to do nothing if we find more than one, right?

Maybe a future enhancement could be to allow someone to specify the domain like

  $ dh_translations --domain=foo

for all files

or

  $ dh_translations --domain=foo path/to/some/desktop/or/policy/or/whatever/file --domain=bar /some/other/file

for ambiguous cases?

Ok, with this patch:

   debian/rules override_dh_translations
make[1]: Entering directory '/<<PKGBUILDDIR>>'
ninja -C obj-x86_64-linux-gnu gnome-control-center-2.0-pot
ninja: Entering directory `obj-x86_64-linux-gnu'
[0/1] Running external command gnome-control-center-2.0-pot.
dh_translations
dh_translations: more than one meson translation domain found (gnome-control-center-2.0,gnome-control-center-2.0-timezones), don't know which one to use

I'll test build a few more packages:

baobab
======

   debian/rules override_dh_translations
make[1]: Entering directory '/<<PKGBUILDDIR>>'
ninja -C obj-x86_64-linux-gnu baobab-pot
ninja: Entering directory `obj-x86_64-linux-gnu'
[0/1] Running external command baobab-pot.
dh_translations
dh_translations: more than one meson translation domain found (help-baobab,baobab), don't know which one to use

baobab's desktop file is not stripped because of this, but the package builds fine

language-selector
=================

   dh_translations
dh_langpack: processing files to add translation domain 'language-selector'..
  gnome-language-selector.desktop
  com.ubuntu.languageselector.policy

builds OK

gnome-recipes
=============

   dh_translations -O--buildsystem=meson
dh_translations: more than one meson translation domain found (gnome-recipes,gnome-recipes-data,help-org.gnome.Recipes), don't know which one to use

builds OK, multiple domains but skipped properly

ubuntu-settings
===============

   dh_translations
»·······check_buildsystem: got domain 'ubuntu-default-launchers', using intltool: 0

this worked, and is our main 'positive' testcase (consider adding 'using meson' there too)

Thanks Iain, that looks fine to me, just one small comment: is the "export DH_VERBOSE=1" change in debian/rules a debugging leftover or needed/wanted for some reason?

Note that the multiple templates issue suggest that having a manual --domain option could still be useful

It was so that someone building this could see the verbose output. It's not in the final uploaded version (just done - dear reviewer, please check this over carefully to make sure I didn't do anything mad).

If we want an override thing, that should be a separate bug at this point to design the interface.

This bug was fixed in the package pkgbinarymangler - 136

---------------
pkgbinarymangler (136) bionic; urgency=medium

  * dh_translations: Add support for meson / ninja projects. (LP: #1751820)

 -- Iain Lane <email address hidden> Mon, 09 Apr 2018 17:23:47 +0100

I opened LP: #1762889 for the "more than one meson translation domain found" issue.