Add documentation on that standalone language codes like "en" are also supported, and not just language-country codes like "en-US".

[DandelionSprout]

Brief description of your issue

Directly based on microsoft/winget-pkgs#407968 (comment).

It's safe to say that @Trenly knows more about the codebase factors for this than I do, so I'll mostly quote him. though a qualified guess of my own on a summary, is that it's a lack of official tests in winget-cli for that kind of scenario (Things that involve 2-letter language codes without countries) that necessitates further test environments for them.

More or less direct quotes, though shortened for focus:

• "(…) - I'm not seeing any code coverage in the CLI repo that ensures the two letter tags resolve correctly"
• "(…) - it's not that I'm worried it won't work. As you correctly pointed out - it does seem to be handled. My concern is that it is NOT tested anywhere in the CLI codebase, which makes the implementation undefined behavior
  Things like -
  • InstallLocaleRequirement: ["en"] - does it pass or silently reject en-US packages?
  • ARP producing "en" as InstalledLocale during an upgrade flow is never exercised
  • Raw GetDistanceOfLanguage("en", "en-US") - the Windows API score is never asserted in any tests"

And keep in mind, it is in fact supported, with the XnSoft.XnShell package in pkgs having become a prominent case of it.

[DandelionSprout]

As for how I came up with the idea of using 2-letter codes like en and fr in manifests in the first place, it's based on pl4nty/winget-extras#235 (comment). While the problems surrounding that PR turned out to be due to a different bug, the overall points in it almost certainly still stand.

Quoting myself:

"1. Let's say the language list in the OS is:
  en-GB
  fr-FR
  en-US
2. And the package has (...).locale.fr-FR.yaml and (...).locale.en-US.yaml,
3. Then the fr-FR locale would be shown."