Meeting minutes
SPC Task Force
Nick: First SPC task force meeting is 19 April
http://
Ian: Everyone is invited!
I18N Issues
ian: review by (for example) the internationalisation group (i18n) is part of the process to get to recommendation
… after review by that group, a number of issues were raised
… @marcos and I categorised those issues - and that's what we are reviewing today
… bucket 1: No implementation impact (https://
… bucket 2: localisation including language and direction - which will have potential implementation impacts
ian: for implementers: is the higher cost (1) parsing data (e.g., structure versus series of values) or (2) doing the localization work?
smcgruer_[EST]: I need to look into this in more detail
ian: bucket 3: localisation based on language of merchant checkout experience - localising the browser UX
smcgruer_[EST]: we could just type as "string" or "object" if it's just javascript APIs
ian: next bucket: data requests
ian: i18n would like name to be divided into given name, family name, phonetic given, phonetic family
<mhofman> Since my connection is terrible, one quick comment here: One way to switch from a string to an object without breaking most users is to have the object implement a toString() for partial backwards compatibility.
ian: as an aside, we are looking at whether we should be still including shipping and billing address (because of privacy issues)
… @AdrianHB is supportive of removing these addresses
ian: any other questions on these topics?
benoit: is this text intended to be displayed to users?
ian: the i18n wg found 6 or 7 instances of text that is supposed to be human-readable
benoit: my solution would be to have no human-readable text in the spec - simply error messages/tags
gustavo: +1 on having the merchant drive this. Each merchant will have a way to communicate this
benoit: why are we collecting name and address from the customer?
… from a payment facilitator perspective, why is this necessary?
adrianHB: exactly
ian: history...
… we chose to implement a checkout API
… this has been a hot topic of discussion since the beginning of the group
ian: browser vendors chose to implement payment + checkout as a single API
AdrianHB: We only need the info if the API continues to function in the way it currently does.
… there is browser UI that renders information (that needs to be localized)
… there are also response objects
… if we did away from those behaviors we could remove the fields
https://
https://
Addison: Might fall back to currency code instead of currency symbol.
… also there are some currency symbols that are more than one Unicode character
Ian: Is that a heads-up?
<addison> zloty
Addison: All your examples suggest one character-per-symbol, so maybe add something like Zloty to suggest N may be greater than 1
Action: Ian to work with folks to determine current behavior around currency symbol display when currency code cannot be matched
Ian: How difficult is the actual localization effort ?
Addison: We've worked a lot recently on format support for lang/dir info
<r12a> https://
Addison: some specs have implemented a dictionary for localizable strings
… I don't know that there's a specific implementation in browsers
… I think marcos suggested that we go back to WebIDL to provide a type that can be consumed
IJ: Can we have single dir/lang per dictionary (e.g., Payment Errors) or per-string
r12a: Direction between phone and name may be different. And also email addresses may be RTL
… so probably "per-string"
<Zakim> smcgruer_[EST], you wanted to ask if i18n folks are aware of any existing web APIs which have been in this position (having site-provided strings that are expected to be displayed in browser UI)
smcgruer_[EST]: Got examples of specs or APIs that do the right thing? I will be able to go speak with them.
r12a: Web Annotations
… JSON-LD
Ian: There is not dedicated browser UX in the case of JSON-LD
r12a: We can send you a list.
[Addison takes the action!]
<addison> https://
https://
IJ: How do we finesse in spec language "what the user's browser does" and "how that matches the merchant's language of checkout page"
Addison: This is a language negotiation issue (for UX)
… what you run into is that that doesn't necessarily match the user's actual UX
… the browser may be localized in a language that the Web server doesn't support.
… customers have some control over their (HTTP) Accept language....generally it's the OS setup and not the browser localization
… you may want to indicate in the protocol "what languages the browser supports"
… but sending that up and down the wire may not be useful
… which one they are using at the moment could be sent over the wire (Navigator language)
Addison: You can leave out "if any" since there will always be a language.
<xfq> https://
Addison: The document will not always have a language (inherited)
… there's a question of whether you want to match if that language were not supported in the browser...what fallback might be.
IJ: Do we need family/given/phonetic for all names?
Addison: Yes.
Addison: As far as ongoing discussion: we can also host you at the I18N WG meeting, which takes place at the same time as this one.