Missing language/locale negotiation mechanism

[aphillips]

(throughout the spec, some examples follow)
https://www.w3.org/TR/2020/CR-payment-request-20201203/#payererrors-dictionary
https://www.w3.org/TR/2020/CR-payment-request-20201203/#paymentshippingoption-dictionary
https://www.w3.org/TR/2020/CR-payment-request-20201203/#show-method

Throughout the payment-request spec we note that natural language text values are returned. In our teleconference of 2021-03-25 we decided to group a number of pending issues into three buckets:

• The need for language and direction metadata on natural language items (already tracked in payment-request Add dir/lang member on dictionaries whose content is displayed in browser UI #327)
• The need for localizability of natural language fields (e.g. the ability to have more than one language present)
• The need for a language negotiation mechanism so that the the API caller can receive natural language messages such as errors or labels in their preferred language/locale (if available)

This issue tracks the last of these. It is possible this is a duplicate of #650

For example, at #show-method in the NOTE under item # 18:

Note: Localization of the payment sheet

The API does not provide a way for developers to specify the language in which the payment sheet is presented to end users. As such, user agents will generally present the payment sheet using the user agent's default language. The working group is contemplating adding the ability for developers to specify the language of the payment sheet, and of specific PaymentItems, in a future version of this API.

The user agent's default language and the language of the rendering site or host page might not match. Usually items shown as part of the payment-initiating customer experience should match the language and locale of that experience. Defaulting to the user agent's locale would could thus produce a mixed language experience, which is undesirable.

Why not this version?

[marcoscaceres]

Based on #956, leaving this open to address in a future version of the spec.

@aphillips, for our records, could you please indicate if i18n is satisfied with this course of action? - and if so, remove the "i18n-needs-resolution" label.

Please add any other labels the i18n WG needs to track this going forward.

[aphillips]

I am satisfied by the current resolution.

Please do not remove the "i18n-needs-resolution" label. Closing the issue is sufficient (we then close our matching issue to indicate satisfaction). If you want to keep this open for "future", that's okay too. Basically the label informs PLH's tracking tool which issues were from HR and it lets us keep track of our issues. Any open issues will actually be reviewed and are not a blocker. Alternatively, you have my permission to change the label from "i18n-needs-resolution" to "i18n-tracker".

[ianbjacobs]

Sounds like the simplest is to close the issue here; thank you @aphillips