Irrelevant translatable strings

[Gunnar Hjalmarsson]

When building gnome-software on Ubuntu, dh_translations generates a translation template (.pot file) to be imported to Rosetta. That template includes 700+ log messages from data/appdata/org.gnome.Software.appdata.xml.in. The messages are not shown to users, and it makes no sense to have those strings translated. It's worth mentioning that the strings are excluded in upstream's translation template.

The issue was first reported at the ubuntu-translators mailing list:
https://lists.ubuntu.com/archives/ubuntu-translators/2021-May/007757.html

I stripped the redundant strings from the template and uploaded it to hirsute manually as a temporary measure.

The reason why this happens seems to be that the appstream package is included in Build-Depends. appstream installs the file /usr/share/gettext/its/metainfo.its with rules which make all the log entries be extracted. But the gettext package installs /usr/share/gettext-0.21/its/metainfo.its with more sensible rules which do not make the log entries be extracted. If the former is not present, xgettext falls back to the latter.

So a solution to this issue is to drop appstream from Build-Depends. gnome-software seems to build fine without that package (tested in PPA).

[Gunnar Hjalmarsson (gunnarhj)]

I pushed this commit:

https://salsa.debian.org/gnome-team/gnome-software/-/commit/b1830b58

The issue also affects the translation template for Ubuntu Software. I'm not able to tell if this change makes a difference for Ubuntu Software, so to be sure I added a separate snap-store-desktop bug task.

[Sebastien Bacher (seb128)]

the solution is sort of unreliable though, it means you will get random results depending on what is installed on the builder...

[Gunnar Hjalmarsson (gunnarhj)]

That's true. My thought was that there is typically no reason to include appstream in Build-Depends.

I don't know the reason why appstream and gettext ship different versions of metainfo.its. Possibly there are cases where the appstream version makes more sense. If there aren't, it may be motivated to turn to appstream upstream and suggest that they adapt to the gettext variant also in the appstream package.

[Gunnar Hjalmarsson (gunnarhj)]

I submitted this upstream gnome-software MR:

https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/876

It ought to be a more persistent improvement. Would be good if the POT for snap-store-desktop could be fixed soon.

[Gunnar Hjalmarsson (gunnarhj)]

In the upstream gnome-software issue I learned that Fedora ships metainfo{its,loc} via their libappstream-glib-devel package. So could Debian/Ubuntu move those files from appstream to libappstream-glib-dev? Well, don't think so — see the attached file for the reason.

It makes little sense to pass release descriptions, which upstream decided to not translate, to the downstream translators. The problem has now been reduced via the MR I mentioned (which was merged), but the descriptions for the latest few releases are still there.

So as regards the POT file for snap-store-desktop I currently see no other feasible solution than simply making sure that appstream's metainfo{its,loc} files are not available when generating it. By e.g. renaming them temporarily or something.

[Gunnar Hjalmarsson (gunnarhj)]

I stripped the redundant strings from snap-store.pot, uploaded it, and had it imported by LP as a temporary measure. So right now it's free of release info at org.gnome.Software.appdata.xml.

https://translations.launchpad.net/snap-store-desktop

[Jeremy Bícha (jbicha)]

We have done big transitions before. If we wanted to move the file, I think it could go like this:

Step 1: Have libappstream-glib-dev depend on appstream
Step 2: File bugs against all the rdepends to change their Build-Depends
Step 3: After all the rdepends are fixed, move the file and drop the dependency we added in step 1

[Gunnar Hjalmarsson (gunnarhj)]

@Jeremy: That would be quite some work. And please note that avoiding the metainfo.its file shipped with some appstream{,-glib} binary should be considered a temporary fix, i.e. the file will sooner or later replace the older equivalent in the gettext package.

After I had filed the appstream issue, they made a change so you can opt out from extracting <release/> strings:

https://github.com/ximion/appstream/commit/51ab4f32

So in the GNOME Software issue I proposed that we should opt out all over, but the maintainer let me know that the strings will be shown in Software as from GNOME 41, so he didn't let me 'hide' the latest strings.

At the same time: Here is the attitude from the l10n.gnome.org folks:

https://gitlab.gnome.org/Infrastructure/damned-lies/-/issues/149#note_532339

And here we sit downstream and see that GNOME disagrees with GNOME. :(

[Jeremy Bícha (jbicha)]

The package move suggestion wasn't about this bug. If the file ought to be in the -dev package and we think it's important enough, we can do the move.

We once discussed this idea for policykit's .its file, which is included in policykit-1 instead of the -dev package.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gnome-software - 40.4-1

---------------
gnome-software (40.4-1) unstable; urgency=medium

  [ Gunnar Hjalmarsson ]
  * Drop appstream from Build-Depends
    - This prevents that irrelevant translatable strings are extracted
      when building for Ubuntu (LP: #1927149).

  [ Adrian Bunk ]
  * Add mipsel to the gnome-software-plugin-flatpak architecture list

  [ Laurent Bigonville ]
  * debian/watch: Update the URL to follow the new version scheme
  * New upstream release
    - Adjust the build-dependencies
    - Fix the installation paths of the plugins, they have moved to another
      directory. Also remove deprecated rules and options
    - Install the new libgnomesoftware private library in the main package
  * debian/rules: Enable the apt URL handler in the .desktop file

 -- Laurent Bigonville <email address hidden> Mon, 13 Sep 2021 10:09:53 +0200

[Gunnar Hjalmarsson (gunnarhj)]

Ah, I see.

[Matthias Klumpp (ximion)]

I still think this is a dumb fix, especially since you loose the feature to actually mark strings from being untranslatable by dropping the appstream dependency.
A proper workaround would be to leave that in, possibly backport the ITS patch for appstream to update the file, and then mark the release entries you don't want to have translated with `translate="no"` in the XML.

[Gunnar Hjalmarsson (gunnarhj)]

On 2021-09-20 04:14, Matthias Klumpp wrote:
> I still think this is a dumb fix, especially since you loose the
> feature to actually mark strings from being untranslatable by
> dropping the appstream dependency.

And I still don't understand that part of your reasoning.

If appstreams's version of metainfo.its is not present when the POT file is generated, it falls back to gettext's version which does not extract <release/> strings at all. And that's what we want to achieve in Ubuntu, at least as long as GNOME keeps appstream's metainfo.its away when generating the upstream POT file. Did you see this issue:

https://gitlab.gnome.org/Infrastructure/damned-lies/-/issues/149

> A proper workaround would be to leave that in, possibly backport the
> ITS patch for appstream to update the file, and then mark the release
> entries you don't want to have translated with `translate="no"` in
> the XML.

That's a possible way to deal with it in the future once the GNOME Software maintainer (and all other GNOME project maintainers...) have reached an agreement with the Damned Lies admins on the matter.

Please note that several `translatable="no"` have already been added:

https://gitlab.gnome.org/GNOME/gnome-software/-/commit/7dc44712

(seems to be effective only for GNOME 41) But the <release/> strings for 40+ are still translatable, so even if the problem is reduced compared to when I first filed this bug report, it's still present.

If the Damned Lies admins would change their mind, we still have the problem with the very latest <release/> info. Let's study the release of gnome-software 40.4 as an example. The NEWS file and the appdata.xml file were updated in the same commit (surprise, surprise) on August 13:

https://gitlab.gnome.org/GNOME/gnome-software/-/commit/70c23e4a

The actual release HAPPENED ON THE SAME DAY!! So even if those strings had been passed to the GNOME translators via Damned Lies, the strings for 40.4 would still have been shipped untranslated. You can't just snap your fingers to have strings translated. Translators need time.

As you already know, I think it was an unfortunate mistake to consider the <release/> strings translatable by default. If some project owners wanted them to be translatable, it would have been much better to give those projects a possibility to opt in for translation. The maintainers of projects which opted in could be assumed to be aware of the required translation workflow for this to make sense.