Re: [w3c/payment-request] Recipient and payerName are lacking i18n support (#471)

Actually, breaking the customer's name into component fields introduces internationalization issues that are potentially not present with an opaque string representation. With a single "full name" string, the user can input their name however they like it to be displayed. Implementations can't infer family or given name or do operations like sorting, but modeling these is complex. Does your specification really want/need that?

-- 
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/issues/471#issuecomment-317504768

Received on Monday, 24 July 2017 18:00:57 UTC