Add persistent output locale override setting

[Kaleb Luedtke (Trenly)]

📖 Description

Add a persistent output.locale user setting that allows overriding winget interface string resolution by BCP47 tag.

Current implementation details:

• Reads .output.locale at CLI startup and applies the override only when the setting is non-empty.
• Applies the override through Resource::SetLanguageOverride, which sets the MRT Language qualifier for winget resource loading.
• Treats override failures as non-fatal (logs warning and continues without the override).
• Uses wil::srwlock in the shared resource loader for synchronized read/write access when resolving strings and updating locale override.
• Does not apply this setting in server initialization.

This PR also updates settings schema/documentation and local package resource fallback handling for localized winget.resw files.

🔗 References

Resolves #422

🤖 Copilot Assistance

This PR includes changes authored with GitHub Copilot assistance.

🔍 Validation

• Added/updated unit tests for OutputLocale setting parsing/normalization behavior.
• Added E2E coverage verifying help output changes when output.locale changes.

✅ Checklist

• Signed the Contributor License Agreement
• Linked to an issue
• Updated Release Notes (if applicable)
• Updated documentation (if applicable)
• Updated Copilot instructions (if build, architecture, or conventions changed)

📋 Issue Type

• Bug fix
• Feature
• Task

Microsoft Reviewers: Open in CodeFlow

[Flor Chacón (florelis)]

LGTM, but I'd want to hold off on merging until we have a plan for what to do with App Installer.

[Flor Chacón (florelis)]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Adds a new persisted output.locale user setting that lets WinGet override the UI/output language (via a supported BCP47 tag), and wires the setting into startup initialization so localized resources resolve accordingly. It also updates schema/docs/release notes and adjusts packaging to pick up localized winget.resw files during local builds.

Changes:

• Introduces Setting::OutputLocale (settings mapping + validation/normalization against supported locale tags).
• Applies the locale override at CLI startup via ApplicationLanguages::PrimaryLanguageOverride.
• Updates the settings schema + documentation + release notes, and adds packaging fallback to include localized winget.resw from Localization\Resources\<locale> when Shared\Strings\<locale> is absent.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/AppInstallerCommonCore/UserSettings.cpp	Adds supported-locale normalization and validation for the new output.locale setting.
src/AppInstallerCommonCore/Public/winget/UserSettings.h	Adds the OutputLocale setting enum value and JSON mapping to .output.locale.
src/AppInstallerCLITests/UserSettings.cpp	Adds unit tests covering default/valid/case-insensitive/invalid locale values.
src/AppInstallerCLIPackage/AppInstallerCLIPackage.wapproj	Adds build-time fallback PRIResource includes from Localization\\Resources\\<locale> for local builds.
src/AppInstallerCLICore/Core.cpp	Applies the persisted output locale override during startup initialization.
schemas/JSON/settings/settings.schema.0.2.json	Adds output.locale to the public settings schema with supported enum values.
doc/windows/package-manager/winget/settings.md	Documents the new output.locale setting for end users.
doc/Settings.md	Documents the new output.locale setting in the repo’s settings documentation.
doc/ReleaseNotes.md	Adds a release note entry for the new output locale override feature.

[Flor Chacón (florelis)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Flor Chacón (florelis)]

Looks like we will need to reset the override in App Installer. Internal PR number for that: 16173490
I won't merge this until that other change is in place.

[Flor Chacón (florelis)]

Question from internal discussion:
Instead of overriding the primary language like this, would it be possible to just add the locale qualifier when creating the resource loader? That would avoid setting the locale package-wide, and we wouldn't need to make any changes to App Installer.

[Flor Chacón (florelis)]

Nit: Assuming this is done before any localized strings are fetched, this is going to create a loader with default options, and then immediately overwrite it with a new one that uses the locale. We could make it so that we only needed to create it once, but that's probably too small a gain to care.

[Flor Chacón (florelis)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Kaleb Luedtke (Trenly)]

Grrr, pesky build failures

[Kaleb Luedtke (Trenly)]

@florelis - I've merged the latest changes from master to see if that resolves the ADO build issue despite it building locally without them. I've verified it builds locally after the merge:

[Flor Chacón (florelis)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Kaleb Luedtke (Trenly)]

Root Cause Analysis

Note

This comment was authored by GitHub Copilot.

Root cause: ApplyOutputLocaleOverride() unconditionally accessed Loader::Instance() at startup for every command. The WinGetGenerateDSCv3Manifests build step runs winget.exe dscv3 --manifest as an unpackaged process (before MSIX packaging), and the refactored Loader() constructor now calls CreateLoader({}) which calls ResourceContext::ResetGlobalQualifierValues() before the ResourceLoader() probe.

The original code relied on ResourceLoader() throwing a catchable hresult_error when resource.pri is not found (unpackaged context) — this prevented execution from ever reaching ResourceLoader::GetForViewIndependentUse, which fast-fails with an uncatchable crash (0xC0000409) when no debugger is attached. Calling ResetGlobalQualifierValues first changed the WinRT resource state and broke this safety guard.

Fix

Two changes applied in commit 25c246a:

1. Resources.cpp: Restored the original constructor initialization path — no ResetGlobalQualifierValues call, preserving the ResourceLoader() probe guard
2. Core.cpp: Guard ApplyOutputLocaleOverride() to return early when the locale setting is empty, avoiding Loader::Instance() initialization at startup for commands that don't need UI output (like dscv3 --manifest)

[JohnMcPMS]

This can throw; do we think it important enough to respect the target locale that we should terminate the winget.exe process if we cannot?

[Kaleb Luedtke (Trenly)]

Right now the throw should be caught internally to the function and result in the false return, walking through the warning path here. My thought was that this should be best-effort and not breaking. This would most closely match the behavior today where if the Locale coming from the OS doesn't map to an avaliable resource file it falls back to whatever the resource loader deems is the best fit.

I'm not opposed to making it a hard failure, but without knowing how often it would or could throw, just makes me a bit uneasy. Is this a decision that needs to be made now? Could we do something in the future like adding a telemetry event sampling language overrides as a what-if to better understand the potential impact of making it a terminating failure?