Skip to content

Add localization hint for payment sheet #656

New issue

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

Sign up for

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

Already on ? Sign in to your account

Jump to bottom
Merged
merged 3 commits into from
Feb 15, 2018
Merged

Add localization hint for payment sheet #656

merged 3 commits into from
Feb 15, 2018

Conversation

marcoscaceres
Copy link
Member

@marcoscaceres marcoscaceres commented Nov 24, 2017•
edited by pr-preview bot
Loading

  • Adds "lang" member to PaymentRequestInit dictionary
  • Adds processing model for lang
  • Optionally allows UA to localize the payment sheet

closes #650

Preview | Diff

@w3cw3c deleted a comment Dec 27, 2017
@marcoscaceresmarcoscaceres mentioned this pull request Jan 17, 2018
Open
domenic
domenic approved these changes Jan 19, 2018
View reviewed changes
Copy link
Collaborator

@domenic domenic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with a nit and a suggestion for expansion. Although, just using the language of the body element might suffice for #650 without any new APIs...

index.html Outdated
with the <var>handlers</var>. Optionally, if
<var>request</var>.<a>[[\uiLang]]</a> is not null, localize the
user interface to match, as closely as possible, the language of
<a>[[\uiLang]]</a>. The user agent SHOULD prioritize the
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you should paragraph break before the last sentence as now it's somewhat disconnected from the rest.

index.html Outdated
with the <var>handlers</var>. Optionally, if
<var>request</var>.<a>[[\uiLang]]</a> is not null, localize the
user interface to match, as closely as possible, the language of
<a>[[\uiLang]]</a>. The user agent SHOULD prioritize the
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we state more about what to do if [[uiLang]] is null? For example using the language of the body element?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that might be good to recommend using the document's language.

@marcoscaceres
Copy link
Member Author

Although, just using the language of the body element might suffice for #650 without any new APIs...

Having both the API hint and falling back to body's lang seems like it would cover all cases. I don't have a strong opinion, and could definitely live with just "use the document's lang". @michelle, can you think of cases where it would be challenging to just use the document's language?

Having said that, implementation support for localizing the UI will remain a challenge for implementers, as we don't generally ship support for multiple UI languages. So we will have to see how much demand there is for this.

stpeter
stpeter reviewed Jan 24, 2018
View reviewed changes
index.html Outdated
Optionally, if <var>request</var>.<a>[[\uiLang]]</a> is not null,
localize the user interface to match, as closely as possible, the
language of <a>[[\uiLang]]</a>. Otherwise, if
<var>request</var>.<a>[[\uiLang]]</a> is null, is it RECOMMEDED
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/is it/it is/

stpeter
stpeter reviewed Jan 24, 2018
View reviewed changes
index.html Outdated
<dfn>lang</dfn> member
</dt>
<dd>
A [[!BCP47]] language tag representing the preferred language of
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/preferred/merchant's preferred/ (what the merchant prefers might not be what the buyer prefers)

@stpeter
Copy link

stpeter commented Jan 24, 2018•
edited
Loading

The Accept-Language HTTP header might also be communicated from the user's browser to the merchant website. See https://www.w3.org/International/questions/qa-when-lang-neg regarding use of this header for language negotiation. For example, the hint that the merchant sends could be constrained to one of the languages that is in the Accept-Language set. See also https://www.w3.org/International/wiki/Locale-based_forms for related discussion regarding number and date formats (which could be important for payment totals and ship dates).

@marcoscaceres
Copy link
Member Author

It might be worth looking at what effect, if any, Content-Language has on "the body element" in HTML.

@marcoscaceres
Add localization hint for payment sheet
e5105db
* Adds "lang" member to PaymentRequestInit dictionary
* Adds processing model for `lang`
* Optionally allows UA to localize the payment sheet

closes #650
@marcoscaceresmarcoscaceres removed the request for review from michelle January 29, 2018 06:22
@marcoscaceres
Copy link
Member Author

@domenic, changed as you suggested (no API).

@michelle, can you live with this for now and we see how we go?

@marcoscaceresmarcoscaceres merged commit 0e4539d into gh-pages Feb 15, 2018
@marcoscaceresmarcoscaceres deleted the lang branch February 15, 2018 23:29
Sign up for free to join this conversation on . Already have an account? Sign in to comment
Reviewers

@stpeter stpeter stpeter left review comments

@domenic domenic domenic approved these changes

Assignees
No one assigned
Labels
needs tests proposal - needs discussion
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Allow locale to be specified by the developer.
3 participants
@marcoscaceres @stpeter @domenic