Emulate browser locale (including Accept-Language header, Intl APIs, and Navigator.language)

[whimboo]

It would be useful if BiDi clients could fully emulate the browser’s locale, including key functionalities such as:

1. Accept-Language HTTP Headers:

   • Allow the browser to send the appropriate Accept-Language header according to the emulated locale settings.

2. JavaScript APIs (Date, Intl):

   • Ensure that JavaScript Date and Internationalization APIs (Intl) reflect the correct locale-based formats (e.g., date, currency, numbers).

3. Navigator.language:

   • Properly simulate the navigator.language value in the emulated environment.

Expected Behavior:

The emulation should consistently apply the locale across:

• HTTP Headers: Emulating Accept-Language based on the locale.
• JS APIs: Reflecting the locale in Date formatting and Intl APIs for things like number and currency formatting.
• Navigator Properties: Ensuring that navigator.language matches the emulated locale.

Use Case:

Many modern web applications use locale information for rendering content, formatting dates/numbers, and providing localized experiences to users. Having full locale emulation is critical for testing applications in different regions and languages to ensure proper functionality.

Potential Implementation:

1. Accept-Language Header:

   • Similar to the ability to set custom HTTP headers via page.setExtraHTTPHeaders(), but tied to the locale setting of the browser.

2. Intl and Date APIs:

   • Ensure that JavaScript's Date and Intl APIs automatically reflect the locale and language settings passed during browser initialization (e.g., page.setLocale()).

3. Navigator.language:

   • Override the navigator.language property so that it correctly reflects the locale setting (e.g., en-US, fr-FR).

Impact:

Implementing this feature would significantly improve localization and internationalization (i18n) testing for web applications, as it would allow a more realistic and complete emulation of how the browser behaves with respect to different locales.

[whimboo]

This feature probably dependents on: Support for specifying extra HTTP headers.

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Emulation - Browser locale.

The full IRC log of that discussion

<AutomatedTester> topic: Emulation - Browser locale
<AutomatedTester> github: https://github.com//issues/774
<AutomatedTester> scribe+
<AutomatedTester> jgraham: I think there are 3 separate items here. one thing is set locale and is in CDP. This is isomorphic to the timezones discussion earlier
<AutomatedTester> ... accept-language header... as it says in the we should have this like locale
<AutomatedTester> ... and we have navigator.language but not sure where that comes from
<AutomatedTester> ... I am broadly in favour but not under 1 API
<gsnedders> q+
<AutomatedTester> ... navigator.language is implementation defined... so do we want this to be set similarly when setting locale?
<AutomatedTester> ack gsnedders
<AutomatedTester> gsnedders: at least for native apps on apple platforms language prefs and locale settings are done separately
<AutomatedTester> ... e..g en-GB for language and en-US as locale for currency
<AutomatedTester> or fr-FR and have locale to that of Japan
<AutomatedTester> q?
<gsnedders> I'm pretty sure there's a similar split in WebKit for the Apple ports between language (e.g., `Accept-Language`) and region (e.g., `new Intl.DateTimeFormat(undefined).format(date)`)?
<AutomatedTester> jgraham: we want a command to overload the intl API do. We want a command to set command for accept language and look at what navigator.language does and how its implemented everywhere

[gsnedders]

I'm pretty sure there's a similar split in WebKit for the Apple ports between language (e.g., Accept-Language) and region (e.g., new Intl.DateTimeFormat(undefined).format(date))?

Looking at this more closely, I think currently we always derive the default locale for Intl from the default language, so in our case I think we wouldn't support setting them separately?

[sadym-chromium]

I believe the issue is addressed. Feel free to re-open or open a new one if something is not covered.

[whimboo]

@sadym-chromium checking the tests as landed on https://github.com/web-platform-tests/wpt/tree/master/webdriver/tests/bidi/emulation/set_locale_override I assume we still need some more tests to check the accept language header, navigator.language? I only see the usage of Intl.DateTimeFormat().resolvedOptions().locale so far for the verification that the correct locale is set.

[sadym-chromium]

@sadym-chromium checking the tests as landed on https://github.com/web-platform-tests/wpt/tree/master/webdriver/tests/bidi/emulation/set_locale_override I assume we still need some more tests to check the accept language header, navigator.language? I only see the usage of Intl.DateTimeFormat().resolvedOptions().locale so far for the verification that the correct locale is set.

Regarding the navigator.language, I read the HTML spec as "implementation-defined". Implementation-wise, in Chrome it is not influenced by the Emulation.setLocaleOverride command.