Localisation does not respect browser settings #2002
Replies: 3 comments
-
|
🤔 this is tough. I almost feel like there's a missing API here. In my ideal world, the https://twitter.com/JoshWComeau/status/1759616073773543485 Perhaps we keep the existing behavior, document it will use the <sl-format-date lang="system"></sl-format-date>So we can keep the current behavior, but add the ability to detect language based on OS, does that sound fair? @claviska gonna tag you to see if you have any other ideas here. |
Beta Was this translation helpful? Give feedback.
-
But this would imply that the actual content of the page is in that language. If a multilingual Canadian user that knew French and English requested your page with: and your site responded with a generic English page ( I guess it's a matter of how to view these utility elements. I see the But I can also see it from the view that it's "translated content", so it should match the document's language. For example, using The strongest argument I can make for honouring the browser's locale is that the element is already using the browser's timezone. If the element is using the "server/page locale format", then arguably it should also use the server/page timezone. |
Beta Was this translation helpful? Give feedback.
-
The commit you're referencing still uses Intl, just through the library it was moved to. That said, the library does use the language code from navigator.languages
? navigator.languages[0]
: (navigator.language || navigator.userLanguage)But it's not clear to me what we should do when the headers, the OS/browser's locale, and/or the page locale don't align? Our current approach supports any locale with the caveat that the region code must set, e.g. Offloading this responsibility to the developer seems like a pretty good choice for a client-side library given the limited info and abilities we have from the platform. The more clever we try to be, the more edge cases and bugs we'll run into. I'm open to concrete ideas on how to improve this, but nothing more solid than what we have currently comes to mind. |
Beta Was this translation helpful? Give feedback.
-
Describe the bug
The docs for
<sl-format-date>and<sl-format-number>state that the formatting is handled by the browser based on the user's current locale.However, this commit from 3 years ago switched out
Intlfor a custom localiser that looks at the closestlangattribute, so the dates and numbers are now always formatted based on the page locale instead of the browser's locale.f87cb8d
Either the docs should be updated to properly explain that the browser locale is never used, or the code should be changed back to use the
IntlAPI (this is my preference).To Reproduce
Steps to reproduce the behaviour:
mm/dd/yyyy, because the page has<html lang="en">which resolves to en-USdd/mm/yyyy, but it still shows the US format.Screenshots
en-US Locale
en-AU Locale
Browser / OS
Beta Was this translation helpful? Give feedback.
All reactions