Add phonetic name as one of `ContactAddress` properties

[agektmr]

Apple recently decided to add support for phonetic name in its Payment Request API's PaymentAddress object.

In Japan, people use 3 different characters - Kanji, Hiragana and Katakana. Texts are usually written in mixture of those 3 characters. While Kanji is written for content words, Hiragana and Katakana (they are equivalent different shapes) are written for phonetics. Names written in Kanji needs accompanying Hiragana or Katakana in order to be pronounced properly. That's where phonetic name field helps. They exists commonly in checkout forms in Japanese ecommerce services.

Therefore, I would like to propose to add DOMString phoneticName as a member of PaymentAddress object.

[marcoscaceres]

Could definitely add it in 1.1... This is similar to discussion we had here: https://github.com/w3c/contact-picker/issues/69

@agektmr, any idea what the attribute is? If not, @aestes will let us know :)

[marcoscaceres]

Correction: just wanted to confirm phoneticName is what Safari added. If so, then yeah... super easy to add.

[agektmr]

The test code doesn't seem to 100% conform with the standard (Seems ApplePayJS variant to me), but apparently phoneticName is the one. https://trac.webkit.org/browser/webkit/trunk/LayoutTests/http/tests/ssl/applepay/ApplePayRequestShippingContactV3.https.html?rev=241105

[marcoscaceres]

Thanks for confirming. I guess we should get an ok from @danyao and @rsolomakhin about wanting to add this to Chrome, yeah? The spec side is easy, but the UI will obviously be more challenging to support.

[rsolomakhin]

Should be OK to add to Chrome. Thank you for checking with us.

[marcoscaceres]

Spoke to @aestes, and he helped clarify a bit what Apple has been working on. The phonetic name enhancements they've added are on the proprietary Apple Pay JS API, and not on the Payment Request API.

For equivalence, Andy suggest is adding the following to Payment Request API:

1. A way for merchants to require/request a phonetic name in PaymentOptions.
2. Add phonetic name fields to PaymentAddress.
3. Add a way to indicate a phonetic name error.

[eternalharvest]

I appreciate your work on improving PaymentRequest API.

In Japan, almost all names are represented in Kanji Character. And, there is no rule to leaving space between family name and given name though some people do. So, it is difficult to distinguish which is the family name or given name parts in programatically.

So Japanese EC sites has familyName and givenName fiels sepratedly. These complex form reducing conversion ratio. So, I think it makes sence adding those fields in PaymentRequest API especially in Japan.

I wonder if consider about adding family Name, givenName, middleName, phonetic FamilyName, phoneticGivenName, phoneticMiddleName fields separately.

Please tell me if I need to make a another issue for this.

Note: Proprietary ApplePay API implementation has familyName and givenName fields separatedly for paymentAddress and shippingAddres. I'm not sure about any other locale implementation. But it seems there is no middleName, phoneticMiddleName fields. But it is not a problem because almost all Japanese people has no middle name and almost all EC sites in Japan has no fields corresponding to middleName or phoneticMiddleName.

FYI: Screen shot of Google Contacts

[xfq]

@eternalharvest See discussions in https://github.com/w3c/contact-picker/issues/69

I agree that adding family names and given names is helpful to people in some regions, but I hope our design does not cause too much trouble for people in other regions (for example, we shouldn't assume the family name exists, since the majority of Mongolian names and Indonesian names do not have family names).

[agektmr]

Address object should be designed to cover as many countries as possible. I think current design is too western countries centric. That's why I proposed phonetic fields. But to enhance the coverage of other countries, I believe the best way is to follow what more specialized standards are doing. autocomplete field in WhatWG is a good example. Since I found that they lack phonetic field support, I proposed them as https://github.com/whatwg/html/issues/5821.

I've also requested to add this support to Chrome's password manager here: https://bugs.chromium.org/p/chromium/issues/detail?id=1115953

What else can I do to move this forward?

[agektmr]

Let me tell this anecdote from one of our business partners:

People at their customer center needs to make phone calls to their customers. The information provided through the form is everything they know about their customers and if it's missing phonetic field, mixing first name and last name, the support person will pronounce their customer's name wrong, call the customer with their first name by mistake, which are considered very impolite in Japan. It's important that Web Payments support those fields.

[ianbjacobs]

This issue was raised in Payment Request, but closed once we removed addresses from that API. Since the features are now part of Contact Picker, we are transferring the issue here.