Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
whimboo opened this issue Sep 17, 2024 · 3 comments
Labels
enhancement New feature or request module-emulation Emulation module needs-discussion Issues to be discussed by the working group

Comments

@whimboo
Copy link
Contributor

whimboo commented Sep 17, 2024

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 whimboo added enhancement New feature or request module-emulation Emulation module needs-discussion Issues to be discussed by the working group labels Sep 17, 2024
@whimboo
Copy link
Contributor Author

whimboo commented Sep 18, 2024

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

@css-meeting-bot
Copy link
Member

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
Copy link
Member

gsnedders commented Sep 26, 2024

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request module-emulation Emulation module needs-discussion Issues to be discussed by the working group
Projects
None yet
Development

No branches or pull requests

3 participants