Adding an `external`/`other` type value to `<translation>`?

[C-512L]

According to the docs, both <translation/> and <languages/> are optional tags, but storefronts like gnome-software try to use them together, as they are somewhat dependent. If a <languages/> tag is present but no <translation/> tag is found, its assumed to be English, ignores <languages> and gnome-software for example shows a banner with "This app will be shown in US English", which could be misleading if your app reports your own language with<lang> as supported:

Right now, AppStream's <translation/> types are rather limited. Although gettext is largely used, there are a lot of other choises depending on which programming language or tooling you use. Altough Appstream could theorically integrate with the more popular formats, there will always be edge/niche cases. i.e: a small project using a self-developed/custom i18n library.

I think giving apps the ability to self-report its translation status on its metadata would be helpful for both apps and store frontends (like gnome-software). This could be implemented adding a new value to </translation>'s type attribute or could be clarified as part of the spec that both tags are not dependent on each other.

[ximion]

All of what you write is already possible: The translation tag is used by (lib)appstream-compose and appstream-generator to extract translation status automatically. That tag is then stripped from the data as it is only valid for Metainfo files, and not for Catalog data, and the generated catalog data contains a languages tag that contains the extracted statistics.
See https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-translation for how that is done.

Meanwhile, if the component specifies a languages element, that one will be used if it is the only element present (otherwise it will be augmented with auto-detected data from a translation tag, if present).

So, what you are asking for is already implemented, from the very start - this is not a recent feature (but we do want to have this automated as much as possible, which is why translation is what you will commonly find recommended).

As for supporting more translation systems: If it's not niche and is used commonly enough, patches are welcome for as-compose to support it as well, alongside GNU Gettext and Qt.

I am curious though, have you tested this and found it not working? Which distribution are you using?