Re: [w3c/payment-request] editorial: mark languageCode at risk (#764)

For the sake of traceability, here are the conclusions of my i18n review (it's possible @aphillips might have more or better suggestions)...

First, the i18n WG guidelines for spec authors [0] don't say about how to handle web forms. There are a few suggestions about character encoding [1] and text direction [2] in the guidelines for content authors and developers, but those are rather minimal, too. Because the Payment Request API is a strange beast (in essence it moves ecommerce checkout forms out of web content and into a browser dialog), it's likely an outlier for advice to spec developers. I've raised the issue of web forms guidance for discussion in the i18n WG.

Second, there are a few topics we might want to broach in the Payment Request API spec, such as:

(a) Recommend that the browser set a language tag for user input in the payment dialog. For instance, it could inherit the language tag from the html `lang` attribute [3] on the merchant site.

(b) Recommend that the browser be able to handle a locale value that is distinct from the language tag. As noted in [4] and relevant for our use cases, "the region code is also sometimes used to indicate the physical location, market, legal, or other governing policies for the user."

(c) Require the browser to treat all input from the payment dialog as UTF-8, consistent with [1].

(d) Mention that the user can set a base direction for textual input, as described at [2].

Third, there are probably easier ways to determine the script of user-inputted text than the algorithm Rouslan provided [5] (which I take it described what libaddressinput [6] uses). For instance, the browser could simply inspect the characters themselves to see if there are in Latin script, Japanese script, etc. (I'll grant you that mixed-script input could be a challenge, though.)

Fourth, a scenario Addison mentioned on an i18n WG call is the need for the same address in multiple forms (e.g., an English-language version for delivery from the U.S. to a import handling location in China and a Chinese-language version for final delivery to the customer). We have not designed for this yet, but might want to open a tracking bug for multiple representations of the same address.

Fifth, a related scenario might be billing address in one script and shipping address in another script. This is simpler than multiple representations of the same address, but still requires support for two different scripts in the same set of input forms.

We might uncover additional issues in the future, but these are the ones we've discussed so far.

[0] https://w3c.github.io/bp-i18n-specdev/#loc_forms
[1] https://www.w3.org/International/questions/qa-forms-utf-8
[2] https://www.w3.org/International/questions/qa-html-dir#userexplicit
[3] https://www.w3.org/International/articles/language-tags/
[4] https://www.w3.org/TR/ltli/
[5] https://github.com/w3c/payment-request/issues/608#issuecomment-414546200
[6] https://github.com/googlei18n/libaddressinput/blob/3cefac503f6321f7f84a790939dc7cb022bce169/cpp/src/language.cc#L58


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/pull/764#issuecomment-418879354