Update the Specification for Locale Validation - #345
darwinlyang wants to merge 5 commits into
Conversation
| [=list/is not empty=] | ||
| [=list/is not empty=]: | ||
|
|
||
| 1. Let |dialogLanguageTag| be the [=language tag=] used by the Secure |
There was a problem hiding this comment.
I'm not 100% sure this is the right definition, but I leave this one to our i18n folks to be sure. (Maybe it should be "the language tag that the user agent will present the Secure Payment Confirmation dialog in"? Maybe we should be allowing for a list of tags?)
| are an [=ASCII case-insensitive=] match, set |matched| to true and | ||
| break. | ||
|
|
||
| 1. If |matched| is false, throw a "{{NotSupportedError}}" {{DOMException}}. |
There was a problem hiding this comment.
Do we handle wildcards? See https://w3c.github.io/i18n-glossary/#dfn-language-range
I guess not since we're only allowing language tags and I think by https://www.rfc-editor.org/info/rfc5646/ anything with a * isn't a language tag?
There was a problem hiding this comment.
The current proposal does not allow for wildcards as en could just be used instead of en-*.
There was a problem hiding this comment.
That makes sense, albeit I suspect there may be good reasons that our i18n community can think of to allow them (e.g., I believe en-*-us is allowed as a wildcard setup)
stephenmcgruer
left a comment
stephenmcgruer
left a comment
There was a problem hiding this comment.
I think this is ok from my viewpoint, although I imagine our i18n friends will ask if we have considered applying the matching algorithms from https://datatracker.ietf.org/doc/html/rfc4647#section-3, and why we haven't chosen them if so. It may be worth expressing that reasoning as a NOTE in the spec.
Sounds good. I added a note on why standard language negotiation isn't used. |
ianbjacobs
added
the
i18n-tracker
|
Hi @aphillips and @xfq we welcome your input on this PR! |
This branch has not been deployed
3 participants
The goal is to update the specification so that the locale field in
SecurePaymentConfirmationRequestwill return an error whenPaymentRequest.canMakePayment()is called if:See #343 for additional discussions for this PR.
Preview | Diff