Allow locale to be specified by the developer.

[michelle]

It would be helpful for merchants to be able to specify the locale that the user agent displays the payment sheet in.

Especially as we're discussing custom error messages, which are merchant-supplied, it is really awkward if the message the merchant supplies doesn't match the language (and amount / currency display) in the sheet.

An additional data point we have from Stripe Checkout is that localization only helps conversion if the merchant page and the payment modal are displayed in the same locale.

[michelle]

cc @marcoscaceres @rsolomakhin @aestes @jenanwise

[rsolomakhin]

The locale should pass on to the payment handler as well. @frank-hoffmann

[marcoscaceres]

I spoke with our implementation team about this, and although receptive to the idea, this wouldn't be high priority for Mozilla to implement. We are planning to do a staged rollout of localized payment sheets over the next year(s), so we could eventually support this... but it would take time.

I'm still happy to add it to the spec tho, because I can see how this would be clearly useful for a consistent shopping experience.

Thoughts from other implementers? Defer this to after CR? @michelle, what priority would you give this from Stripe's perspective?

CC @molly26dalton for input

[michelle]

We definitely understand that it would take time!

However, even if not all browsers are able to support all locales right away, allowing the merchant specify the preferred locale would still be a worthy addition to the CR from Stripe's perspective. Having a single language through the payment flow has, in our experience, increased conversion.

I also imagine that this feature would be a good complement to #647 (and a potential alternative solution for #327), as it would be confusing if the error message and display item language do not match the payment sheet language.

[ianbjacobs]

From previous conversations I thought that we decided that language would be determined by preferences from the user agent (e.g., through HTTP headers). Is that not sufficient?

Ian

[marcoscaceres]

It’s insufficient: language is usually set by users explicitly on the site (think of how annoying it is when you go overseas and your favourite search engine suddenly changes language on you... want to avoid that kind of experience).

[marc-roberts-jg]

Needs to take into consideration that users in places like Canada may have set their preferred language in the site, when the language can't be detected automatically because of the country.

[marcoscaceres]

Exactly the above. Further, any expat will tell you the same thing: just because you live in a country doesn’t mean you speak - or, given the choice, prefer - that country’s language.

I’ll try to draft a PR for this soon.

[rsolomakhin]

I'm OK implementing support for this parameter in PaymentRequest API, but our UI architecture currently allows for only one language at a time. It would take us a while to implement full support for this, but there's nothing technical that fundamentally stops us from doing it eventually.

[marcoscaceres]

Yeah, I think we should only pass in one language tag. Then we can use "lookup" to derive a suitable match.

[marcoscaceres]

Cc'ing @r12a for i18n comment/tracking... not sure which label to use ☺️

[mnoorenberghe]

I spoke with our implementation team about this, and although receptive to the idea, this wouldn't be high priority for Mozilla to implement. We are planing to do a staged rollout of localized payment sheets over the next year(s), so we could eventually support this... but it would take time.

To clarify, we have a similar problem to what @rsolomakhin mentions… that we currently only ship one language pack per build by default. Then we'll have to deal with reading from multiple at a time. Currently our fallbacks for untranslated strings are done at build time, not runtime.

Having a single language through the payment flow has, in our experience, increased conversion.

Was this experience with using a native payment UI that's not embedded in the webpage? I think the value of this will come down to whether users think of the Payment Request UI as part of the webpage or as part of the browser. There are some cases where users may want their UA language to be used, not the page language, for example, if I'm not fluent in the supported languages of the merchant site, having the PR UI in my preferred language will be easier for me to use/understand.

[michelle]

Was this experience with using a native payment UI that's not embedded in the webpage?

This experience was from Stripe Checkout, which is more similar to the payment sheet than to the merchant's website: https://stripe.com/checkout

There are some cases where users may want their UA language to be used, not the page language, for example, if I'm not fluent in the supported languages of the merchant site, having the PR UI in my preferred language will be easier for me to use/understand.

That is definitely plausible, though I think if possible, we should gather end user data to test this hypothesis. The merchant is supplying display items, labels, and (eventually) error message in the language(s) they support. Having two different languages shown in the sheet is potentially also confusing.

[marcoscaceres]

Just noting that I sent a PR for this a little while ago, but hasn't been reviewed yet. Could interested folks take a look: #656

[domenic]

Would it suffice to just use the language specified by the merchant for their entire page? E.g. if their page does , then having any calls to paymentRequest.show() show the UI in Belarusian? That seems a bit cleaner than having to add a new API that is specifically designed to let PaymentRequest get out of sync with the rest of the page.

[stpeter]

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). [Sorry, I added this comment at the PR but it belongs here so that the i18n WG can track it more easily.]

[marcoscaceres]

Speaking out loud here: the merchant will have the Accept-Language header by default, which in turn will allow them to set the language of the body element (this is generally applicable i18n guidance for any website). Additionally, setting the language through a user-configurable option i in the site itself is usually a better solution... alternatively, some sites also use Geo IP solutions, which can be annoying, but mostly "good enough".

As @domenic suggests, it feels like the right thing to do here is for us just recommend the payment sheet use the document language. Let's see how we go with that for, say, 1-2 years. If we find that it's insufficient, then let's add the API part... we have the text ready to go when we need it 😇

I'll make the appropriate changes to #656.

[marcoscaceres]

Marking as future candidate feature. After review from the i18n folks, decided to defer this to after we go to REC.