| 11:56 | <Jessidhia> | Is there a good reason as to why https://tc39.es/ecma402/#sec-defaultlocale ignores the document language? Like, I know the spec language is intentionally underspecified here, but is there a reason to prefer the chrome's language instead of the document's language? From what I can gather this would just result in out-of-place formatting if |
| 11:57 | <Jessidhia> | on Firefox it ignores the document language even if it's present in navigator.languages; only the primary navigator.language is ever used |
| 12:00 | <Jessidhia> | this is kind of a blocker on me using Intl.DateTimeFormat without very careful wrapping 😅 |
| 12:03 | <Jessidhia> | (on the other hand this gets into trouble with SSR because there's no document language during SSR so I guess my problem formulation is incomplete) |
| 12:34 | <annevk> | "host environment's current locale" seems kinda bogus |
| 12:36 | <annevk> | Well, I guess it's good enough, but I haven't seen a PR for HTML that maps "current locale" to navigator.language's underlying primitive. |
| 12:38 | <annevk> | (Using the language of a document wouldn't work in quite a few environments, e.g., all workers, worklets. And it's not necessarily declared on the root element all of the time either, although it kinda ought to be. So if you want to write portable code you probably want that to be a separate input from the end user locale.) |
| 12:41 | <ryzokuken> | Jessidhia: did you come across this by any chance? https://github.com/WICG/proposals/issues/78 |
| 12:41 | <ryzokuken> | basically "fetch the user's preferred locale" is a known problem in Intl |
| 12:43 | <Jessidhia> | I had come across https://github.com/tc39/ecma402/issues/38 which I guess is similar enough to WICG#78 |
| 12:43 | <ryzokuken> | it's a complicated problem to solve while protecting the users' privacy but we're working on it |
| 12:44 | <ryzokuken> | I had come across https://github.com/tc39/ecma402/issues/38 which I guess is similar enough to WICG#78 |
| 12:44 | <ryzokuken> | it was an impetus for us to start looking into the problem, but the solution requires a non-trivial amount of API design and privacy auditing. |
| 12:45 | <Jessidhia> | but it's not quite what I was looking for; more of a way to include the application's preferences (say, user accessing page with document language set to Japanese while using an English language browser, which is my case as a developer of a Japanese web app 😅) |
| 12:46 | <ryzokuken> | ah, essentially the other way around, I guess? |
| 12:46 | <ryzokuken> | enforcing a locale instead of inferring the user's preference, I mean |
| 12:48 | <Jessidhia> | yes, due to the document language; in my example the default result would produce a result with / separators instead of YYYY年MM月DD日, which would look out of place in a japanese language phrase (user preference for the website being lang="ja") |
| 12:50 | <Jessidhia> | luxon somewhat has a facility for this (Settings.defaultLocale) but it doesn't handle dynamic updates well |
| 12:50 | <ryzokuken> | why can't you just call all the formatters with "ja-JP"? |
| 12:50 | <ryzokuken> | by hardcoding the locale argument |
| 12:52 | <Jessidhia> | the locale is actually user preference (out of 4 supported languages) but yes, I can supply a locale (or document.documentElement.lang on the browser side) -- the problem then becomes coworkers using Japanese browsers accidentally getting "correct" output while omitting the argument if they don't test changing the language |
| 12:56 | <ryzokuken> | I see |
| 12:56 | <ryzokuken> | well, this seems to be more of a host problem than a language problem 😅 |
| 12:56 | <ryzokuken> | all ways to override would be host-defined behavior I'm afraid |
| 12:58 | <Jessidhia> | prioritizing document language would be sufficient for this use case |
| 12:58 | <Jessidhia> | the complication is on hosts without a document (like node), that would necessitate a host-defined override |
| 12:59 | <ryzokuken> | yes, but DefaultLocale is completely host-defined too (https://tc39.es/ecma402/#sec-defaultlocale) |
| 12:59 | <ryzokuken> | oh wait, we've looped around to the start |
| 13:00 | <ryzokuken> | but yes, essentially hosts can choose to do whatever they prefer as long as the result is a valid locale |
| 13:40 | <annevk> | ryzokuken: why is there no HTML PR for this feature? |
| 13:55 | <ryzokuken> | annevk: it's still under active development. We're only just starting to narrow down the final semantics after consultation with different browser privacy teams. |
| 13:55 | <ryzokuken> | but yes, hopefully a PR should be out soon. |
| 15:08 | <littledan> | maybe we could start with an HTML issue then? |
| 15:17 | <annevk> | ryzokuken: oh weird, I thought that by the time something is in the main spec it would be stage 4/done? |
| 15:20 | <littledan> | The Intl default locale logic came before ES6 even; as you know very well, annevk , HTML/JS spec coherence wasn't so great back then |
| 15:21 | <annevk> | Hah, I might have known for sure, but my memory isn't always up-to-date :-) |
| 15:22 | <littledan> | My understanding of the history is that actually, Intl was initially going to be proposed as a web spec, but the web standards folks felt the platform wasn't ready for it yet; TC39 OTOH was excited about making this happen, and worked with the internationalization teams of all the same companies, and shipped it :) |
| 15:22 | <annevk> | I recall some effort around an event for the default locale changing, but I'm not sure if that ever landed |
| 15:22 | <littledan> | IIRC that did land but only Firefox actually exposed that event |
| 15:22 | <littledan> | for the language changing |
| 15:23 | <littledan> | there was also an idea about exposing a more detailed locale; this is what ryzokuken is working on now |
| 15:32 | <Jack Works> | The compartment proposal used to contain that part. You were able to virtualize the default locale within a compartment |
| 15:32 | <Jack Works> | But after the proposal is simplified, those abilities are removed. |
| 15:35 | <annevk> | Filed https://github.com/whatwg/html/issues/8493 as a start |
| 15:36 | <annevk> | (And yeah, languagechange did happen, timezonechange not yet.) |
| 15:38 | <nicolo-ribaudo> | Maybe following a similar naming scheme as ECMA-262 (e.g. HostGetDefaultLocale()) makes it easier to see what needs to be defined at the host level |
| 15:57 | <littledan> | Definitely. Historically, I think these algorithms were written without the intention to be hookable in this sort of way. |
| 15:58 | <littledan> | Allen always said, the spec is not an API, and hosts can go in and do whatever, subject to the documented constraints on hosts. The idea to mark all things as Host* is sort of a rejection of this idea. |
| 16:03 | <nicolo-ribaudo> | The Host* hooks are more an "API" that ecma262 expects the host to provide, than an API exposed by ecma262 to the host - they mark AOs that must be provided by the host |
| 16:35 | <littledan> | Yeah, I agree with that idea. We can collectively change our minds on these things. |
| 16:36 | <littledan> | if we're trying to understand why the spec is how it is, it helps to understand that articulating host APIs like this was an anti-goal in the past. |
| 17:12 | <annevk> | I would love for it to be an even more concrete API and scope certain host hooks by tying them to agent clusters and such. |
| 18:46 | <ljharb> | definitely critical to keep the historical context; it seems to me that we've largely discovered the hazards of underspecifying and being too implicit, and are trying to avoid repeating those mistakes :-) |