I18N problem with displayName unresolved?

[aphillips]

6.1. PaymentCredentialInstrument Dictionary https://w3c.github.io/secure-payment-confirmation/#sctn-paymentcredentialinstrument-dictionary

NOTE: For discussion about internationalization of the displayName, see issue 93.

In numerous places in the secure payment confirmation spec there are data structures with display name strings. These don't use metadata. There is a locale-preference field that can be used for language negotiation, but no structure for indicating the results of the request etc.

The I18N WG reviewed this in our 2023-01-26 teleconference (sorry that the notes are very sparse) and concluded that going to CR with this unresolved feels like a problem. Rather than referring to the open issue (which is your self-review), it would be better to make a positive statement about the current specification and future direction. Instead of the above note I would suggest instead:

NOTE: internationalization of the displayName via the inclusion of language and direction metadata remains an open issue. Implementations are encouraged to use locale-negotiation to return values in the language requested and to provide display names that do not result in bidirectional text issues. For more information see: (link to follow)

[ianbjacobs]

Hi @aphillips,

I think the current issue is thus duplicate of our issue #205.

Here is the record of the outcome of our TPAC discussion on this topic (where it was concluded we could advance to CR and what for progress with TC39 before leaving PR): https://github.com/w3c/secure-payment-confirmation/issues/205#issuecomment-1255167247

Having said that, the proposed Note above seems good to me.

Thank you and I18N folks for the review!

[aphillips]

Thanks. Let's use #205 then and close this issue. I'll copy the suggestion to that issue.

[ianbjacobs]

As you have copied the suggestion, I will close here.