[w3c/browser-payment-api] Recipient and payerName are lacking i18n support (#471)

We have two properties right now, recipient (in PaymentAddress) and payerName (in PaymentResponse) which are hold a user's full name and are plain DOMStrings. 

I think this is going to cause a few problems for internationalization. 

Firstly, merchants and websites won't be able to infer the correct ordering, since in many countries the family name comes before the given name (e.g, China). This will cause problems, since for many merchants they may want to address the user by their family name or otherwise format it for communications. Additionally it's not defined whether implementations should or shouldn't return prefixes (Mr, Ms, Dr, etc), making it harder for parsing to occur.

Secondly, and this is less important but still relevant for i18n, sometimes users may wish to provide (and merchants may wish to receive) a phonetic representation for the name in addition to the name itself.

I think we need to consider replacing the plain DOMString with a better data structure that at the very least has distinct fields for given and family name, and ideally with room for expansion to additional fields like a phonetic representation.

-- 
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/browser-payment-api/issues/471