Appstream doesn't use generic language-only locales overridden by $LANGUAGE

[joebonrichie]

Some apps such as GIMP may override the locale on a per-application basic using the LANGUAGE env. However, for generic language-only locales such as "pt" or "de", appstream falls back to using LANG.

e.g.

$ echo $LANG
en_GB.utf8
$ LANGUAGE=pt_BR appstreamcli dump test
Não foi possível encontrar um componente com ID “test”!
WHAT IS THE APPSTREAM LOCALE pt_BR
$ LANGUAGE=pt_PT appstreamcli dump test
Não foi possível encontrar o componente com o identificador (ID) "test"!
WHAT IS THE APPSTREAM LOCALE pt_PT
$ LANGUAGE=pt appstreamcli dump test
Não foi possível encontrar o componente com o identificador (ID) "test"!
WHAT IS THE APPSTREAM LOCALE en_GB.utf8
$ LANGUAGE=de appstreamcli dump test
Komponente mit Kennung »test« wurde nicht gefunden!
WHAT IS THE APPSTREAM LOCALE en_GB.utf8
$ LANGUAGE=de_DE appstreamcli dump test
Komponente mit Kennung »test« wurde nicht gefunden!
WHAT IS THE APPSTREAM LOCALE de_DE

When setting LANGUAGE to "de" or "pt" appstream falls back using LANG. Is this expected behaviour?

Downstream issue: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/2326#note_2471512

[ximion]

This is intended behavior, if AppStream can't find a region code in the currently set locale, as a fallback. See https://github.com/ximion/appstream/blob/main/src/as-utils.c#L693

Looking for why this was introduced, I found this annotation in a previous commit:

Some users expect LANG to take priority, and AppStream uses region codes
as well since.
So if we don't have them in LANGUAGE but do have them in LANG, we have
different localization depending on how the application was launched as well as
multiple caches on systems which generate them.

Does this cause problems for GIMP in the real world? Because normally, you wouldn't have these discrepancies.
I wouldn't be against making changes, but only if there is a "best practice" for this or if it causes issues, and if a fix doesn't cause regressions (obviously).