The MIME database appears to use underscore to join its locale tags,
where QLocale::uiLanguages() uses dashes. This meant that lookups by
anything but the raw language were failing even when there was an
entry in the MIME database for the desired locale. Also, since 6.5,
the uiLanguages() list always does contain the locale's own name, so
don't add it to the list again.
At the same time, the search was putting the "default" key (used by
the MIME database parser for the entry with no locale specified) at
the end of the list but macOS (at least) uses that for the "en_US"
version, omitting "en_US" itself from the locale-specific data, with
the result that those using en_US as locale, but with some other
languages later in the list, got the translation for one of those
languages instead of the en_US one, since they were found before
"default" was reached. So insert "default" after the first block of
en-entries in which en_US appears, if it does, rather than at the end.
As a drive-by, amend a comment about using "pt" as fall-back for
"pt_BR"; as it happens, for pt_BR, uiLanguages() will contain "pt" in
any case, as pt_BR is the default for "pt". (Like en, pt anomalously
defaults to a territory other than the one the language is named
after.) So use de_CH -> de as example, instead (and place the comment
where the decision is taken).
Fixes: QTBUG-105007
Pick-to: 6.6 6.5
Change-Id: I1f4835190748256ce53a51321a94ae450ab7f61e
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
1b5e13c8d9