Code Monkey home page Code Monkey logo

Comments (3)

KonnorRogers avatar KonnorRogers commented on May 27, 2024

🤔 this is tough. I almost feel like there's a missing API here.

In my ideal world, the lang attribute set on html should come from the user's Accept-Languageheader to determine the Intl API to use. But I could see where this may not always be preferred (perhaps you serve every page as lang="en" in which case you can only work with what you have right? I know I don't set lang on all my projects.

https://twitter.com/JoshWComeau/status/1759616073773543485

Perhaps we keep the existing behavior, document it will use the lang on the page, but add an attribute like:

<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.

from shoelace.

LachlanArthur avatar LachlanArthur commented on May 27, 2024

In my ideal world, the lang attribute set on html should come from the user's Accept-Languageheader to determine the Intl API to use.

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:

Accept-Language: fr-CA, fr;q=0.9, en-CA;q=0.8, en;q=0.7

and your site responded with a generic English page (en), I don't think it would be appropriate for the HTML lang to become fr-FR, since the page isn't in French. And it would also be inconvenient for the Canadian user to be given US-style dates.

I guess it's a matter of how to view these utility elements.

I see the <sl-format-date> as a sort of 'output' analogue to <input type="date"> (which already formats dates using the browser's locale, despite the language of the page it's used on).

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 weekday="long" month="long" will show the translated names of weekdays and months, which may look strange in some contexts.

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.

from shoelace.

claviska avatar claviska commented on May 27, 2024

However, this commit from 3 years ago switched out Intl for a custom localiser that looks at the closest lang attribute, so the dates and numbers are now always formatted based on the page locale instead of the browser's locale.
f87cb8d

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 <html> or from the host element (when present) to determine localization info. Alas, we don't have access to header info at runtime, but we could probably default to the OS/browser's locale using something like this, which seems to be the best way (out of many) to obtain it:

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. <html lang="en-GB">.

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.

from shoelace.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.