Thanks, Darwin. Vlad pointed out that this change to increase strictness implies some new or additional breakage for sites. Do we have a sense for how often that will trigger? Do we have any UMA data that would give us a sense for the maximum extent of potential breakage? I.e., what's the risk?
Best, Alex On Tuesday, October 20, 2026 at 7:35:08 AM UTC-7 Darwin Yang wrote: > Hi Alex, > > Both before and after the change, developers can populate an optional > `locale` data field with their preferred languages. Before this change, the > UA could use this language information however it wanted. This resulted in > UAs generally ignoring this field because SPC is a browser feature and to > align with other related browser features (e.g., WebAuthn), it would use > the browser language. After this change, if the field is set, the UA will > try to match the browser language with the developer provided list of > languages. If there's a match, there is no change; however, if there is no > match, the UA will return a locale mismatch error to the developer. The > intent behind this change is that the developer supplies strings for the > SPC dialog, and the language of those strings might not match the rest of > the dialog. This allows the developer to guarantee that the language of the > strings they provide matches the dialog's language. > > Addison Phillip's concerns were not fully addressed but we have developer > support > <https://github.com/w3c/secure-payment-confirmation/issues/343#issuecomment-5415886806> > > for this change. In addition, we opened an issue > <https://github.com/w3c/i18n-request/issues/324> with the i18n community, > and they told us they would review our PR for the spec change by the end > of September > <https://github.com/w3c/i18n-request/issues/324#issuecomment-5526812106>. > It never ended up getting reviewed and after numerous attempts to ask for a > review (as well as inviting them to join our WPWG meeting on Oct 8th) we > received no response, so we decided to go ahead with the spec change so the > developer can begin testing the changes. > > On Mon, Oct 19, 2026 at 7:36 PM Alex Russell <[email protected]> > wrote: > >> The "Explainer" here is pretty thin, and I'm not sure I understand the >> before/after code developers would generally write. Also, it wasn't clear >> to me if Addison Phillip's comments were fully addressed; can you perhaps >> comment on those aspects? >> >> >> https://github.com/w3c/secure-payment-confirmation/issues/343#issuecomment-5457268443 >> >> Best, >> >> Alex >> >> On Thursday, October 15, 2026 at 7:08:36 AM UTC-7 Chromestatus wrote: >> >>> *Contact emails* >>> [email protected] >>> >>> *Explainer* >>> https://github.com/w3c/secure-payment-confirmation/issues/343 >>> >>> *Specification* >>> >>> https://w3c.github.io/secure-payment-confirmation/#dom-securepaymentconfirmationrequest-locale >>> >>> >>> *Design docs* >>> >>> https://github.com/w3c/secure-payment-confirmation/issues/343 >>> https://github.com/w3c/i18n-request/issues/324 >>> https://github.com/w3c/secure-payment-confirmation/pull/345 >>> >>> *Summary* >>> Updates Secure Payment Confirmation's `locale` data field to return a >>> Not Supported DOMException if none of the language tags provided in the >>> field match the language used by the Secure Payment Confirmation's dialog. >>> If the field is not set or empty, this validation is skipped. This helps >>> web developers with matching the language of the data that they are >>> supplying to Secure Payment Confirmation with the dialog. >>> >>> *Blink component* >>> Blink>Payments >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EPayments%22> >>> >>> *Web Feature ID* >>> secure-payment-confirmation >>> <https://webstatus.dev/features/secure-payment-confirmation> >>> >>> *Motivation* >>> This feature amends Secure Payment Confirmation so that web developers >>> can align the language of data elements that they supply to Secure Payment >>> Confirmation with the language used by the Secure Payment Confirmation >>> dialog. Currently web developers can provide a list of language tags for >>> Secure Payment Confirmation to use in their dialog. But Secure Payment >>> Confirmation does not use this list because it is not feasible for the >>> browser to support all languages and the Secure Payment Confirmation is a >>> browser feature so it should use the browser language to be consistent with >>> other browser features. By returning an error when none of the language >>> tags provided match Secure Payment Confirmation's language, web developers >>> are able to retry with different language tags (while updating the language >>> of their supplied data elements) until they get a match. >>> >>> *Initial public proposal* >>> https://github.com/w3c/secure-payment-confirmation/issues/343 >>> >>> *Search tags* >>> spc <http:///features#tags:spc> >>> >>> *TAG review* >>> *No information provided* >>> >>> *TAG review status* >>> Not applicable >>> >>> *Goals for experimentation* >>> None >>> >>> *Risks* >>> >>> >>> *Interoperability and Compatibility* >>> This feature updates the behaviour of an existing field. If the previous >>> behaviour was implemented by other browser but this new behaviour is not, >>> then there is an interoperability risk of the browsers behaving differently >>> with the same request. >>> >>> *Gecko*: N/A (https://github.com/mozilla/standards-positions/issues/570) >>> Firefox >>> haven't implemented SPC yet so the update to the locale field is not >>> relevant. >>> >>> *WebKit*: N/A (https://github.com/WebKit/standards-positions/issues/30) >>> Safari >>> haven't implemented SPC yet so the update to the locale field is not >>> relevant. >>> >>> *Web developers*: Positive ( >>> https://github.com/w3c/secure-payment-confirmation/issues/343#issuecomment-5415886806 >>> ) https://www.w3.org/2026/08/13-wpwg-minutes.html >>> https://www.w3.org/2026/09/10-wpwg-minutes.html >>> https://www.w3.org/2026/10/08-wpwg-minutes.html >>> >>> *Other signals*: >>> >>> *WebView application risks* >>> >>> Does this intent deprecate or change behavior of existing APIs, such >>> that it has potentially high risk for Android WebView-based applications? >>> *No information provided* >>> >>> >>> *Debuggability* >>> Web developers should be able to create Secure Payment Confirmation >>> requests with or without matching locales, thus no changes are needed in >>> devtools. >>> >>> *Will this feature be supported on all six Blink platforms (Windows, >>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>> No >>> The locale validation will only be added to platforms that support >>> Secure Payment Confirmation which are currently only Android, macOS, and >>> Windows. >>> >>> *Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>> No >>> Web platform tests are in development. They are delayed due to the lack >>> of support to change the browser locale language which is needed for this >>> feature. >>> >>> *Flag name on about://flags* >>> enable-spc-locale-validation >>> >>> *Finch feature name* >>> SecurePaymentConfirmationLocaleValidation >>> >>> *Rollout plan* >>> Will ship enabled for all users >>> >>> *Requires code in //chrome?* >>> False >>> >>> *Tracking bug* >>> https://crbug.com/535278878 >>> >>> *Launch bug* >>> https://launch.corp.google.com/launch/4489220 >>> >>> *Measurement* >>> A new SecurePaymentConfirmation.LocaleOutcome will be created and used >>> to track the usage and outcomes (match vs no-match) of the field. >>> >>> *Availability expectation* >>> The locale validation for Secure Payment Confirmation will only be >>> available in Chromium browsers for the foreseeable future. >>> >>> *Estimated milestones* >>> Shipping on desktop 154 >>> Shipping on Android 154 >>> >>> *Anticipated spec changes* >>> >>> Open questions about a feature may be a source of future web compat or >>> interop issues. Please list open issues (e.g. links to known github issues >>> in the project for the feature specification) whose resolution may >>> introduce web compat/interop risk (e.g., changing to naming or structure of >>> the API in a non-backward-compatible way). >>> https://github.com/w3c/i18n-request/issues/324 >>> https://github.com/w3c/secure-payment-confirmation/issues/343 >>> https://github.com/w3c/secure-payment-confirmation/pull/345 >>> >>> *Link to entry on the Chrome Platform Status* >>> https://chromestatus.com/feature/5126146013396992?gate=4803300429004800 >>> >>> *Links to previous Intent discussions* >>> Intent to Prototype: >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a7ccbd5.dc132f77.2e13a8.0cd1.GAE%40google.com >>> >>> >>> This intent message was generated by Chrome Platform Status >>> <https://chromestatus.com>. >>> >> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9c101615-d4aa-4b69-b34e-2676279277ean%40chromium.org.
