Support optionally hosting release notes + translations on a remote location rather than within AppData.xml file

[Pointedstick]

KDE is looking to move our software changelogs into AppData; see https://phabricator.kde.org/T10972. In discussions, it turns out that there is only one blocker. Allow me to explain:

Because the changelog and translations are stored in the AppData.xml file, and the AppData.xml file is inside the source tarball, this means that all translations need to be committed by the day the tarball is created. Our team of translators is small, and we don't have the resources to ensure that 100% of English strings are translated into all languages on the day the source tarball is created. It's not feasible to re-spin new tarballs after release because it would confuse and annoy packagers and users.

We would like to request the ability to point the AppData.xml to an external URL that would host the text of the changelogs. That way we could continue to add translations over time without needing to re-spin tarballs or work our small team of translators to death by dumping a huge amount of work on them.

In principle, the above applies to all translatable strings in the file, but we need this feature most for the per-release changelogs.

KDE is highly motivated to move to using AppStream for this information, but the described issue is currently a blocker for us. I can provide more information and details if needed, so please don't hesitate to reach out if anything's unclear!

[ximion]

For release information I am actually pretty fond of making it possible to pull them from a web location, because a lot of projects have the issue of translating a changelog after the release and it makes sense in general to update information for new releases independently of the main project information. I talked with @hughsie about that as well, a long time ago, but haven't yet looked into implementing the necessary changes, or even drafted a proposal on how that would look like (it most likely would be an "url" property on a releases tag no release XML at a remote location).

As for pulling in all translations after a release, I don't think that will happen. The effort required to implement that is just too high for little benefit, as most information in the metainfo files is not really that volatile. I think time is better spent in improving translation workflows for metainfo files instead of making the AppStream specification significantly more complex (it already is quite involved).
[[Translation workflow improvements that would make sense to me for KDE would for example be to do away with hacking l10n data into metainfo files directly via a cron job, and instead merging it in from a Gettext .po file at build-time, like almost all other projects do. That can be combined with an instance of Weblate to embed localization into the normal Git workflow and make it easy for translators to either get .po files from a central location or do web-based translation, which should ideally yield faster translations and reduce clutter when changing strings in the untranslated file.]]

[Pointedstick]

Thanks @ximion! Adding @tsdgeos for further comment.

[tsdgeos]

Yep, having the possibility of pulling the release changelog (including its translations) from an url would be a great improvement for us :)

Happy to help with the testing if needed

[fedelibre]

The same issue was discussed in the GNOME community:

• https://mail.gnome.org/archives/gnome-i18n/2019-June/msg00015.html
• https://gitlab.gnome.org/Infrastructure/damned-lies/issues/149

Most people thought that translating release notes was not worth the effort, as it would mean translating also old strings and some applications have a lot of old strings.
So release notes in GNOME Software are in english only.

[ximion]

Closing in favour of proposal #354