@aphillips,

At the 15 April 2021 WPWG meeting you suggested dropping "if any" from this pull request; please see the comment above from @marcoscaceres which indicates that the language attribute may return the empty string. At the meeting, @xfq pointed us to the DOM spec [1] which also suggests in some cases there may not be a document language.

Could you confirm that understanding and let us know if this pull request closes #650 and #952. Thank you,

Ian

[1] https://html.spec.whatwg.org/multipage/dom.html#language

blocked waiting on resolution from i18n.

I'm nervous about saying this addresses #650 and #952 because it is "merely" a recommendation that the language of the native interface match that of the document's node. I think this could be improved by being slightly more explicit.

I18N has recommendations (and definitions) in our document LTLI, particularly around here. Perhaps the text would be sufficiently stronger if worded something like this:

The user interface SHOULD be presented using the language and locale-based formatting that matches the |document|'s [=document element|document element's=] [=Node/language=], if any, or an appropriate fallback locale if that is not available.

Note that I didn't define what "an appropriate fallback locale" would be, leaving that up to the implementation, including allowing the user agent to fall back to its own localization/runtime locale.

I am "okay" with the text as is, but my disquiet is that it can be easily overlooked.

Thoughts?

@aphillips,

Thank you for the concrete suggestion. +1 from me. @marcoscaceres, thoughts?

Ian

+1 from me too. Thanks @aphillips, I'll update the PR.

I've left #650 to be addressed in the future.

Grah, I typed up a reply to this yesterday but never clicked the green 'Comment' button >_<. So apologies for the post-landing drive-by:

From the Chrome perspective; I believe we agree conceptually that page language is the correct one to use, but it is technically difficult for us to do currently (https://crbug.com/1079289#c18 has some context). At the moment I believe we translate the payment-handler selection UX and basic-card UX into the browser-level language. So we are supportive but are unlikely to be able to move beyond matching the browser-level selected language in the intermediate future :(