Prioritizing exact matches later in the supported list

[philtweir]

I am not entirely sure what is the expected behaviour here, but I got really confused when I saw it, so raising the query.

When using i18n_embed::DesktopLanguageRequester, I noticed that even if I set en-GB to be the fallback locale for a piece of software, if a user has en in the desktop but not en-GB then en-US will be the fallback, where it exists. This is not desirable in my case as en-US may be a partial translation, so will be inconsistently jumping between en-GB and en-US for users who do not set either. The only way to make en-GB override en-US is either to have the user explicitly add en-GB as their desktop locale or to remove en-US as an available translation.

This is because the sequence:

requested = ["en-IE", "en", "en-GB"] # first two from desktop, third is fallback
available = ["en-GB", "en-US"]

will get to en and then en-US will match en (as en-Latn-US) just before en matches en-GB. This seems fine, except that en-GB is in the requested list, and en-US is not. This means:

expected_supported = ["en-GB", "en-US"]
actual_supported = ["en-US", "en-GB"]

To better understand what I was expecting, I tried to code a rough patch to demonstrate the difference - in this case, it ranks any exact matches up-front, so that if a requested locale matches multiple available locales as a range/variant, then it prioritizes any that are actually requested exactly. I am not sure if that is better, but keen to understand if this is intended, or if there is a reason that the actual_supported is preferable.