metainfo.its differs from metainfo.its shipped by gettext

[gunnarhj]

The variant of metainfo.its shipped by appstream may cause issues. See this Ubuntu bug for an example.

Two questions:

1. Was Allow release description translations #186 a good idea? (For cases where devs choose to use {metainfo,appdata}.xml as a replacement for e.g. NEWS, it's really not a good idea to bother the translators with all those strings.)

2. Considering that gettext ships metainfo.{its,loc}, is it motivated that appstream does so as well?

[gunnarhj]

Hi @mike-fabian! I accidentally noticed ibus/ibus-m17n@e182a024, so I thought you may be interested in this issue.

[ximion]

To 1): People who blindly replace NEWS with <release/> are doing the wrong thing. The point of the release description is not to contain an excessive list of all the changes, but rather a nice human-readable and localized overview of what the new release is about. If someone doesn't want the translation to happen, they can disable it by either adding it later (AppStream itself does this) or by setting the translatable="no" attribute on the XML element. The latter option is admittedly neither well known nor well documented.

To 2) Gettext ships a different version from what AppStream ships. For one, it calls the format "appdata", while AppStream calls it "metainfo" - both are used by many projects, with the latter being the canonical/universal name. Changing either would break stuff. But more importantly, we want projects to make use of new translatable elements right away without waiting for Gettext to update, and having a new version in AppStream is therefore pretty nice for projects who want to adopt new features early.
It would admittedly be nice if Gettext would use the exact same version of the files AppStream uses eventually, but I don't know if that is possible without breaking some fringe cases.

[gunnarhj]

Hi @ximion, thanks for your comments!

To 1): People who blindly replace NEWS with <release/> are doing the wrong thing.

Probably. Nevertheless...

The point of the release description is not to contain an excessive list of all the changes, but rather a nice human-readable and localized overview of what the new release is about.

That means that every single release must pass the translators, even if no other translatable strings have been changed. I can imagine that the number of project owners who want <release/> translated is lower than the number of project owners who don't want that. If that's the case, maybe it would make more sense that it's the former who need to take an active step.

With that said, setting the translatable="no" attribute on the XML element sounds as a convenient way to deal with it. Thanks for the tip!

To 2) Gettext ships a different version from what AppStream ships. For one, it calls the format "appdata", while AppStream calls it "metainfo" - both are used by many projects, with the latter being the canonical/universal name. Changing either would break stuff.

While previous gettext shipped "appdata" files, the latest gettext ships a metainfo.{its,loc} file pair. It handles extraction from both metainfo.xml and appdata.xml files. That's defined in metainfo.loc. So it means that my 'solution' in the linked Ubuntu bug, i.e. drop appstream from Build-Depends, works even if gnome-software happens to ship an appdata.xml file.

But more importantly, we want projects to make use of new translatable elements right away without waiting for Gettext to update, and having a new version in AppStream is therefore pretty nice for projects who want to adopt new features early.

Ack.

[gunnarhj]

With that said, setting the translatable="no" attribute on the XML element sounds as a convenient way to deal with it. Thanks for the tip!

Hmm.. Yes, due to a very recent change to metainfo.its you can do <description translatable"no">. But I can think it would be more convenient to allow for <releases translatable="no">:

--- a/data/its/metainfo.its
+++ b/data/its/metainfo.its
@@ -18,7 +18,7 @@
                                /component/developer_name |
                                /component/name_variant_suffix |
                                /component/screenshots/screenshot/caption |
-                               /component/releases/release/description |
+                               /component/releases |
                                /component/agreement/agreement_section/name |
                                /component/agreement/agreement_section/description"
                      translate="yes"/>
@@ -29,6 +29,6 @@
                      translate="no"/>
   <its:translateRule selector="/component/name_variant_suffix[@translatable = 'no']"
                      translate="no"/>
-  <its:translateRule selector="/component/releases/release/description[@translatable = 'no']"
+  <its:translateRule selector="/component/releases[@translatable = 'no']"
                      translate="no"/>
 </its:rules>

Or, even better IMO, why not let the project owners opt in for translation of <releases/> instead of opting out, i.e.:

--- a/data/its/metainfo.its
+++ b/data/its/metainfo.its
@@ -18,7 +18,6 @@
                                /component/developer_name |
                                /component/name_variant_suffix |
                                /component/screenshots/screenshot/caption |
-                               /component/releases/release/description |
                                /component/agreement/agreement_section/name |
                                /component/agreement/agreement_section/description"
                      translate="yes"/>
@@ -29,6 +28,6 @@
                      translate="no"/>
   <its:translateRule selector="/component/name_variant_suffix[@translatable = 'no']"
                      translate="no"/>
-  <its:translateRule selector="/component/releases/release/description[@translatable = 'no']"
-                     translate="no"/>
+  <its:translateRule selector="/component/releases/release/description[@translatable = 'yes']"
+                     translate="yes"/>
 </its:rules>

[ximion]

@gunnarhj

So it means that my 'solution' in the linked Ubuntu bug, i.e. drop appstream from Build-Depends, works even if gnome-software happens to ship an appdata.xml file.

No, that's a bad thing - for example, the way to disable translations was just added to AppStream itself, dropping the files would remove the ability of projects to use it. Quite the perfect example of why these files are needed ;-)

If you want to make a case that most people want release descriptions untranslated, you'd need to provide some data to back that up. But even if that were available and say that most people don't translate release descriptions, it wouldn't mean that that's a good thing. Forcing people to learn English in order to know what changed in a release doesn't seem like the right way to go.
In any case though, the defaults on this will not change as it would break the AppStream specification and assumptions by many projects out there, and also be very inconsistent with the rest of the specification, which permits everything to be translatable unless explicitly opted out.

[gunnarhj]

So it means that my 'solution' in the linked Ubuntu bug, i.e. drop appstream from Build-Depends, works even if gnome-software happens to ship an appdata.xml file.

No, that's a bad thing - for example, the way to disable translations was just added to AppStream itself, dropping the files would remove the ability of projects to use it.

I have a feeling that we talk past each other now. What I meant was to make sure that appstream — with metainfo.{its,loc} — is not present at build time, especially when creating the translation template, in order to make use of gettext's metainfo.{its,loc} files instead so the <releases/> strings are not extracted. That's all. Not sure how that would be a bad thing.

OTOH I don't quite understand the meaning of "the way to disable translations was just added to AppStream itself". Maybe I'm missing something. Mind to explain?

Forcing people to learn English in order to know what changed in a release doesn't seem like the right way to go.

Well, not sure that prompting the translators to act in connection with every release of every application is the right way either. Translators are volunteers, and today I'm wearing my hat as a translation coordinator at Ubuntu. 😉

What triggered me to submit this issue was the appdata.xml file for gnome-software. It includes 700+ (maybe more now) strings in <releases/>, and those strings were accidentally extracted to Ubuntu's translation template. I felt kind of embarrassed when my attention was called to it, since we with that wasted the translators' time. As far as I can see, GNOME Software doesn't show anything from <releases/> (at least not in Ubuntu), and Discover shows the strings from the latest release only.

There are indeed ways to work around the default. You can for instance do as @mike-fabian did for ibus-m17n as showed in a previous comment above. But that's rather cumbersome.

As a 'compromise', any chance you can consider the first patch I showed here?

[gunnarhj]

I submitted this gnome-software MR:

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

So @ximion, assuming that your latest comment is your final decision, I closed this issue.

[gunnarhj]

@ximion: Even if I closed this, I can't help letting you know about this discussion:

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

So I'm not the only one who questions the wisdom of passing release descriptions to the translators. 😉