Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recommend Payment UI matches doc's language #944

Merged
merged 2 commits into from
Apr 21, 2021
Merged

Conversation

marcoscaceres
Copy link
Member

@marcoscaceres marcoscaceres commented Mar 23, 2021

Maybe addresses w3c/i18n-activity#1043

Implementation commitment:

  • Safari
  • Chrome
  • Firefox
  • Edge

Although RECOMMENDED, no one implements this at the moment.


Preview | Diff

index.html Outdated Show resolved Hide resolved
@ianbjacobs
Copy link
Collaborator

@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

@marcoscaceres
Copy link
Member Author

blocked waiting on resolution from i18n.

@aphillips
Copy link

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?

@ianbjacobs
Copy link
Collaborator

@aphillips,

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

Ian

@marcoscaceres
Copy link
Member Author

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

@marcoscaceres marcoscaceres merged commit 4bb62e1 into gh-pages Apr 21, 2021
@marcoscaceres
Copy link
Member Author

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

@stephenmcgruer
Copy link
Collaborator

stephenmcgruer commented Apr 21, 2021

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 :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants