Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide better mapping between PaymentAddress and HTML5 autofill #505

Closed
4 tasks
marcoscaceres opened this issue Apr 7, 2017 · 8 comments
Closed
4 tasks
Assignees

Comments

@marcoscaceres
Copy link
Member

marcoscaceres commented Apr 7, 2017

For instance, be more clear that:

  • region maps to address-level1.
  • city is address-level2.
  • Example of sorting code.
  • Point to ISO country codes.

This helps with the conversion from auto-filled form fields to payment PaymentAddress.

@marcoscaceres
Copy link
Member Author

Does dependentLocality map to address-level1 or 2? or something else?

@marcoscaceres
Copy link
Member Author

sorting code example would also help?

@marcoscaceres
Copy link
Member Author

Also, the country attribute pointing to [CLDR] is not very helpful. It should point directly to the ISO 2-digit country codes.

@marcoscaceres marcoscaceres added this to the CR milestone Apr 7, 2017
@rsolomakhin
Copy link
Collaborator

dependentLocality is address-level3. @evanstade introduced the address-level* naming convention, I believe.

Sorting codes are used in France and related countries. See the Wikipedia entry. Our French working group members should be able to provide some good examples.

CLDR is better than ISO in that it's updated more frequently to reflect the changes in the real world, like the break-up of Yugoslavia.

@lararennie: Please double-check my i18n-foo.

@lararennie
Copy link

The field labelled "sorting code" is not just used for that, but is country specific: in some countries it manifests as a post office indicator.

Comments for this field should be:
// This corresponds to the SortingCode sub-element of the xAL
// PostalServiceElements element. Use is very country-specific. Where it is
// used, the value is either a string like "CEDEX", optionally followed by a
// number (e.g. "CEDEX 7"), or just a number alone, representing the "sector
// code" (Jamaica), "delivery area indicator" (Malawi) or "post office
// indicator" (e.g. Côte d'Ivoire).

Note that address-level1 and 2 does NOT map to the levels used for administrative purposes in a country, but in an address. For instance, for the US, level1 would be state, and level2 would be city/post-town NOT county. In Spain, the top-level admins e.g. Catalonia are not in an address, so level1 is the province, which is.

@lararennie
Copy link

@zkoch
Copy link
Contributor

zkoch commented Apr 12, 2017

@marcoscaceres why is this a blocker for CR?

@marcoscaceres
Copy link
Member Author

Closing in favor of w3c/contact-picker#71

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants