[Feature]: Input HTML elements such as date picker should be localizable rather than rely on OS region

[tubs-coder]

Describe the feature/enhancement you need

For the history behind this request, please see https://github.com/MicrosoftEdge/WebView2Feedback/issues/4204.

Currently Webview2 content can be localized via many different mechanisms:

• ScriptLocale in ICoreWebView2ControllerOptions2 manages the locale used in Javascript for Intl namespace
• Lang attribute in HTML documents can influence CSS (eg :lang(en_US))
• Language in ICoreWebView2EnvironmentOptions can influence the language used by the browser (eg context menus, dev tools)

None of these mechanisms fully influence how Input HTML elements are rendered and this often falls back to the OS Region.

I would like the capability to be able to specify the locale used for all my web content including date pickers.

The scenario/use case where you would use this feature

The specific scenario/gap is with sub locales.

Configuration

• Important: on an English Australia (en-AU) PC (running Windows 11)

Requirement

I want to launch Webview2 content that is uniformly English United States (en-US). This is for consistency across multiple physical sites.

Expected Outcome

Date/Time Pickers and other HTML components should display in the mm/dd/yyyy US format

Current Outcome

Date/Time Pickers and other HTML component will always display in the dd/mm/yyyy AU format. None of the existing mechanisms influence this.

• please note: setting Language in ICoreWebView2EnvironmentOptions DOES have an affect with locales such as jp-JP. But not en-US. My suspicion is this is due to some kind of sub-locale logic.

Workaround

Unfortunately the only workaround is to avoid using Input HTML tags and to use custom web components (not ideal!)

How important is this request to you?

Impactful. My app's user experience would be significantly compromised without it.

Suggested implementation

While the spec recommends that the locale of these components should be defined by the lang attribute (https://html.spec.whatwg.org/multipage/dom.html#language), this is not how Chromium and (all?) other browsers work.

Other Chromium based browsers (such as Opera) have this as a browser setting. This seems like a good approach to me and the existing Language in ICoreWebView2EnvironmentOptions feels like the right mechanism to control this (until Chromium and other browsers drift towards the spec).

What does your app do? Is there a pending deadline for this request?

What does your app do?

The App helps teams model scheduling scenarios, data/files are shared across teams throughout the world and a consistent/configurable locale for confusing areas such as Date is required.

[tubs-coder]

Happy to create a basic project the exhibits the behavior if it is helpful?

[srwei]

Hi @tubs-coder, thanks for creating this issue. Would you mind creating a basic project with this behavior, and provide screenshot(s) of the affected locales? Thanks.