Migrating from https://github.com/w3c/webpayments/issues/84:
The spec needs to clearly state how it will handle internationalization issues (such as selection order for language via explicit preferences, Accept-Language headers, etc.)
Per the comments from @nickjshearer and @rsolomakhin in w3c/webpayments#84, I don't believe there are any requirements here for an API in an interactive user-agent.
All browser APIs that receive information to display from the web page rely on the web page to know what language they are showing to the user. The page decides what language to provide. Native UI is presented to the user in the language that they have chosen for their browser or OS; we typically don't let pages influence this.
So in PaymentRequest, the only information provided in a natural language is for display only (e.g., labels on displayItems/total). Processing of Accept-Language headers, etc. is outside the scope of the API.
I propose we close #53 until we find any I18N requirements that we need to add to the spec.
paging @r12a to weigh in
I suggest we get the I18N folks to weigh in on this before closing it. For example, we could ask them if they have I18N considerations for APIs, especially ones that pop up a UI for the user to interact with.
I asked the I18N folks to review the spec in April:
https://lists.w3.org/Archives/Public/public-i18n-core/2016AprJun/0035.html
On that thread I wrote: "We are aiming to meet FTF in July. I think having comments before July would be useful. If that’s not possible, then the next good opportunity is TPAC."
I think it's fine to close this issue and when we receive their comments, they might be individual new issues.
Ian
This is a horizontal review issue which @ianbjacobs has in hand.
I would prefer that we maintain a list of issues from which we have concrete actions and expect that if the i18n review raises any they will be logged as such.
Most helpful comment
Per the comments from @nickjshearer and @rsolomakhin in w3c/webpayments#84, I don't believe there are any requirements here for an API in an interactive user-agent.
All browser APIs that receive information to display from the web page rely on the web page to know what language they are showing to the user. The page decides what language to provide. Native UI is presented to the user in the language that they have chosen for their browser or OS; we typically don't let pages influence this.
So in
PaymentRequest, the only information provided in a natural language is for display only (e.g., labels on displayItems/total). Processing of Accept-Language headers, etc. is outside the scope of the API.I propose we close #53 until we find any I18N requirements that we need to add to the spec.