Check for an empty installer locale

[d0ggie]

It is possible that a package manifest does not supply a InstallerLocale. In such case, if --locale is supplied by user, currently required locale list will not ever match, as the list compared against an empty installer locale string.

This moves the existing check so that applies for both locale preference and locale requirement.

Fixes #2305

• [x] I have signed the Contributor License Agreement.
• [x] This pull request is related to an issue.

---

Microsoft Reviewers: Open in CodeFlow

[JohnMcPMS]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 1 pipeline(s).

[yao-msft]

I think the original design is to make Preferences match empty locale and let Requirements not match empty locale. We treated empty locale as unknown locale. So when a locale is "required", unknown locale will not be considered as matched.

[denelon]

We also have the scenario with Windows Server Core where we "need" a locale and we should default to 'en-us' in that case unless otherwise specified.

[yao-msft]

We also have the scenario with Windows Server Core where we "need" a locale and we should default to 'en-us' in that case unless otherwise specified.

This could be a behavior change, did you mean we would treat empty installer locale (just to be clear, this is installer level locale, not the locale manifest) as en-US by default?

[d0ggie]

Perhaps the correct way to solve this issue would be to seed a missing installer locale from some other locale specified in the manifest, such as package locale? That way, an explicit match would be required (within tolerance limits), but a missing installer locale would not be a showstopper.

However, I'm not sure if a missing installer locale implies a multilingual installer. It is possible, that a multilingual installer picks up an "incorrect" locale based on user region, not based on OS / user preference. While the software itself is installed using the preferred locale, the installer might report back the locale incorrectly, which reflects the locale using during the installer (or region).

I've seen this happen at least with TheDocumentFoundation.LibreOffice package. The manifest is missing InstallerLocale, installer is multilingual but does not pick up the locale based on the user preference, but based on user region (which I think is not correct). So, while the software (installer) might be partially to blame, this yields a deadlock anyway, if user region is not any of the PackageLocales.

[Trenly]

An empty installer locale generally means that the manifest author didn’t add it, for any number of reasons - was a bit lazy, couldn’t find the right switches, or the website only served the URL for their locale and they weren’t aware other locales were available.

Because the installer locale is not a required field in the manifest, empty is treated as "Unknown". I believe this explains the current behavior very well. If someone had a preference for a certain locale and there is an installer where the locale is unknown, then the installer can still be selected since the locale choice is just a preference. But, if the user specifies a locale is required, then it would violate the explicit locale requirement if an installer with an unknown locale were used, as it's not certain that the installer would be that locale (just like the behavior you described for Libre Office).

Package Locale only describes the metadata that is shown through WinGet and doesn’t correlate to the installers at all, so that really can’t be used.

We've also tried things like having the manifest creation tools set a default, but that resulted in even more problems where users whose system wasn’t of the locale specified in the manifest couldn’t install many packages, as the current system locale is also treated as a correlation point

[mominshaikhdevs]

stale? or should it be closed?