- From: Domenic Denicola <notifications@github.com>
- Date: Tue, 08 Mar 2022 11:45:18 -0800
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/716/1062139086@github.com>
(The links to https://github.com/whatwg/webidl/issues/1025 are broken in the OP.) For the TAG's consideration, I think the discussion here is a bit deeper than the procedural question of where a specific dictionary should live. The Web IDL thread brings up an important question which seem more foundational to me: Is it appropriate for specifications to aspirationally include direction/language metadata in user-facing string APIs, even if no implementer has any plans to use that metadata? See discussion starting https://github.com/whatwg/webidl/issues/1025#issuecomment-934150460 . I don't have strong feelings about the specific shape of localized-string APIs, whether based on ECMAScript, a shared dictionary defined somewhere, or spec-specific dictionaries. But I do have strong feelings that adding aspirational features without any implementation commitment is not good, even if the aspiration is in the direction of a good cause like proper i18n support. --- I've also found it persistently frustrating how the i18n folks have been unable to supply many concrete examples of the APIs they'd like to use this infrastructure. In particular, I think the category is: JavaScript APIs, which accept strings for presentation to the user (not developer), and do not involve HTML markup at all. We intentionally try to avoid such APIs on the web platform, preferring markup for user-presentation, but sometimes it's unavoidable as we need to present strings in "browser chrome" or similar. My reading of the thread has been that we eventually settled on there being one or maybe two such APIs on the web platform (PaymentRequest and WebAuthentication), plus Notifications which already has its own solution. The thread also had lots of confusion about geolocation and developer-facing error message localization. I would love to see the explainer include example code (as the "good explainers" document and the template in the OP suggests), of each of these _specific APIs_, before/after the proposal. -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/716#issuecomment-1062139086 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/716/1062139086@github.com>
Received on Tuesday, 8 March 2022 19:45:30 UTC