[AppStream] Tagging applications as only useful in a certain locale

[Philip Withnall]

On Mon, 2019-08-19 at 18:59 +0200, Matthias Klumpp wrote:
> Hi!
> 
> Am Mo., 19. Aug. 2019 um 18:45 Uhr schrieb Philip Withnall
> <philip at tecnocode.co.uk>:
> > Hi,
> > 
> > (Please keep me CCed, as I am not subscribed to the list.)
> 
> That's actually a problem since the mailinglist is subscribe-only
> (Freedesktop doesn't have a lot of spam filtering for the lists).
> Next
> time your reply gets bounced, I'll try to set your email address on a
> whitelist, so you can reply to the list weithout being subscribed.

Thanks.

> > At Endless, we’ve got various applications which are only useful in
> > certain locales. For example, an application which contains an
> > es_GT
> > copy of Wikipedia. Currently, we use a special naming scheme and
> > some
> > downstream patches to gnome-software to hide applications which
> > aren’t
> > relevant to the user’s current locale. We’re looking for an
> > upstream
> > solution to this though.
> > 
> > I was wondering about the <languages> element in AppStream, but it
> > seems to be intended to report translation stats for display in the
> > UI,
> > rather than to encode which locales the application is useful in.
> 
> Indeed. But I think this will fit your use case anyway - it seems
> like
> you would want to hide apps that are not translated into the user's
> language anyway, so why not use this element and only permit it for
> one locale, hiding it from all others?

That would work, except that it would make the AppStream XML size
balloon, since a lot of apps have 20–30 translations, which would all
have to be listed. It also makes maintenance of the AppData file for an
app harder, since the developer would have to keep it in sync with the
po/ directory in their app (and possibly even have in-depth knowledge
of every language, in order to be able to judge which languages are
sufficiently well translated to be worth listing).

> A drawback may be that English locales will still see all apps,
> unless
> additional logic is added to e.g. not display the software in case
> there is exactly one language element that doesn't match the current
> locale.

That sounds like it’s introducing a second set of semantics to the
<languages> element, which would make its use more complicated.

> > Is there another AppStream element which could be used for this, or
> > does a new one need to be standardised? Note that the solution
> > needs to
> > operate in terms of locales (language + country/region) rather than
> > just in terms of languages, since content might be specific to a
> > region
> > and not relevant to other regions which use the same language.
> > For those who follow gnome-software development, this is filed as a
> > gnome-software issue too:
> > https://gitlab.gnome.org/GNOME/gnome-software/issues/697
> 
> I am not sure whether I understand the need for that restriction. Why
> would an es_GT copy of Wikipedia be irrelevant for users on e.g. an
> English locale? They may be learning Spanish and find that Wikipedia
> copy useful.

In this case, the content is tailored to that locale. More generally,
if someone is learning Spanish and wants to use a Spanish app for it,
they should probably switch their desktop to Spanish. Or install the
app manually using gnome-software with LANG=es_GT. It’s a pretty niche
corner case.

> I can see that users may want to filter by apps that actually support
> their language (what the "language" tag is for), but completely
> hiding
> apps that people think users of other languages shouldn't see feels
> like the wrong approach.

Indeed, this is why I think adding a second set of semantics (hide apps
which don’t list the current locale in their <languages>) to the
<languages> element is the wrong approach.

Philip