- From: Marcos Cáceres via GitHub <sysbot+gh@w3.org>
- Date: Thu, 29 Apr 2021 04:23:01 +0000
- To: public-geolocation@w3.org
> I think this is a chicken-and-egg problem: browser vendors have no incentive to change something that is spec-compliant, the spec has no incentive to support something browsers are not currently doing. I don't know if it is a chicken/egg problem, tbh. Mandating requirements in the spec is not a motivator either, as without real world incentives to make a change (e.g., a large web site really needs this or it's causing issues at scale), there will be limited incentive to invest in doing the localization of DOMException messages. From experience, across the entire platform, there seems to be little motivation to localize DOMException messages overall... not a good thing, but reflects current reality - but that's something we need to maybe take on at the source (i.e., WebIDL, HTML, DOM spec). From experience, browsers tend to focus their energy localizing end-user facing strings instead, as they impact vastly more people. > each of the browsers has a localization framework and could localize the messages if they cared to. (Localizing them to match the document language is probably the more difficult problem). This is true. And you are spot on about the "cared to", but it's a matter of priority... as in they care to prioritize localizing other strings. > I'm not overjoyed with the text of the note either. While it does describe the current state of affairs, it makes the claim that the message is "not localized" (that might not always be true: a browser vendor could localize it, even if they didn't support document language). As Geolocation transitions to a "Living Standard", it's true per the implementation links above. If that were to change in any engine, we would update the spec to reflect the new reality. Re the updated note - it reads much better, so I'll take add your modifications. However, I'd be hesitant to add: "Implementers should provide for localization of the message attribute using the caller's language." As that's clearly a conformance requirement. I'm also a little hesitant to add: > Future versions of this specification may add support for language and direction metadata as required by [[STRING-META]] and [[BP-I18N-SPECDEV]]. Without first discussing those with implementers. As you know, I'm really supportive of the things being mandated in STRING-META (and hope Localizable will become core infrastructure in WebIDL itself), but I've yet to review BP-I18N-SPECDEV. -- GitHub Notification of comment by marcoscaceres Please view or discuss this issue at https://github.com/w3c/geolocation-api/issues/50#issuecomment-828930032 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 29 April 2021 04:23:03 UTC