Have fields for locale-specific information (names, addresses, etc.) been checked?

[aphillips]

A number of examples contain personal names and street addresses, broken into component parts. Has there been some attempt to ensure that these fields will work around the world?

This issue was originally created by @r12a. This is an I18N issue that we forgot to send to you previously. It is editorial and not substantive.

[iherman]

The issue was discussed in a meeting on 2021-10-06

• no resolutions were taken

View the transcript

3.2. Have fields for locale-specific information (names, addresses, etc.) been checked? (issue vc-data-model#734)

See github issue vc-data-model#734.

Brent Zundel: Have fields for locale-specific information been checked? This is a comment from the Internationalization folks that came in after the Candidate Recommendation wide review period.
… The issue speaks for itself.
… Would anyone like to volunteer to review the spec, or to write a PR to address this?

Ted Thibodeau Jr.: There's no standard for this. "name" and "address" - leave it at that

David Chadwick: It doesn't matter if the address is specific to a country if it says what the country is in the address, because it's destined for that country.
… In our examples we could have addresses, India, Thailand, ...
… Address for England has to be an England address, etc.

Ted Thibodeau Jr.: The point of their comment is that there are subfields listed, street, city, province, postal code, etc. UK address breakdown does not work in US address breakdown. The breakdown is the problem. That is where it breaks down ;)
… So just say name, and "address".

Dmitri Zagidulin: +1 to what Ted said. We should change out detail tags with a single address field, like already modelled

Ryan Grant: also +1 to non-schema address examples

Brent Zundel: I agree, solution would be to make examples less specific rather than more specific

Dmitri Zagidulin: I can volunteer to make that change

Charles Lehner: I was going to say I'm familiar with that use of the country as the separator, but I don't know the standard for that

[iherman]

The issue was discussed in a meeting on 2021-12-01

• no resolutions were taken

View the transcript

4.1. Have fields for locale-specific information (names, addresses, etc.) been checked? (issue vc-data-model#734)

See github issue vc-data-model#734.

Brent Zundel: We discussed this two months ago -- assigned to Dmitri - update?.

Dmitri Zagidulin: IIRC, need a PR... this is a reminder to do that PR..

[brentzundel]

@dmitrizagidulin any movement on this?

[msporny]

@aphillips -- this group is not responsible for the vocabularies that can be used in a Verifiable Credential. We don't work on address vocabularies. That said, we will try to make sure the vocabularies we use for expressing addresses in the specification use global standard vocabularies for addresses.

[msporny]

There is one example in the spec that doesn't use a good internationalizable format that we should fix: https://w3c.github.io/vc-data-model/#example-a-credential-issued-to-a-holder-who-is-not-the-only-subject-of-the-credential-who-has-no-relationship-with-the-subject-of-the-credential-but-who-has-a-relationship-with-the-issuer

Everything else is out of our hands... We use schema.org's address expression mechanism, which has been through i18n review IIRC, would that work for you @aphillips?

[iherman]

The issue was discussed in a meeting on 2021-12-08

• no resolutions were taken

View the transcript

4.3. Have fields for locale-specific information (names, addresses, etc.) been checked? (issue vc-data-model#734)

See github issue vc-data-model#734.

Brent Zundel: Have fields for locale-specific information been checked ... assigned to Dmitri. It seems once a month we talk about this. I'm not sure anything's happening to move it forward..
… We'll send another ping to Dmitri..

Ivan Herman: So, I am not even sure I understand what it being asked. I realize addresses are very different from one place to another. If I take a VC with names and addresses ... those vocabs are external vocabs and the VC is just the framework. If I'm well informed. This WG, I don't think this WG can do anything here..

Kevin Dean: I would agree with that. GS1 went through a long and tedious process standardizing address for international shipping purposes. It's not our job to do that sort of thing in this group..

Manu Sporny: Same..

David Chadwick: Is it correct that the examples are non-normative. So then -- that sort of resolves the issue in a way? If we just say these are non-normative examples?.

Ted Thibodeau Jr.: Yeah, I think that they weren't looking to see if this was in scope for us, it's just something that caught their eye and the examples are broken into, I think, US normative formats. If we just use name and address and nothing else it's easy to fix..

Brent Zundel: I believe the fix we settled on was to alter the examples to make them more general..
… Beyond that I don't think we needed to do anything..

Ted Thibodeau Jr.: I don't think that this flag was about us changing vocabs in any way. Internationalization looks at things that are normally i18n concerns and if we make the examples more generic they become non-concerns..

Ivan Herman: I don't disagree with anything said, but I think Addison and Richard deserve an explicit answer and we say it's not the WG's job to do the vocab parts..

Manu Sporny: I'm scanning through the entire spec for where we use addresses. We have one example in C6 where a holder is using a non-i18n address field and we can fix that. We have been using schema.org because we know it has been through a massive i18n effort..
… One example is a good example, another is not. We'll tell them that we'll fix the bad one and clarify that we don't work on address formats in the group..

Ivan Herman: +1 to manu.

Brent Zundel: We are still looking to Dmitri to raise a PR to fix that one example..
… Any other opinions?.

[aphillips]

@msporny Thanks. We know you're not responsible for external standards. Generally, we prefer that examples that don't draw on some specific external standard (i.e. invented values) not exemplify I18N anti-patterns. Personal names are a complex topic, as are postal addresses. Where you're drawing on schema.org's work, I'm sure we're fine.

Also, I did a quick scroll through your examples and don't see any (outside the one you cite) that seem to require changes. @r12a might have keener eyes than I do :-). [Ed. Nit: Parsian postal codes are more like 75001 than 98052 and Exemple d'Université looks incorrect as a translation (I am not a native speaker).]

[msporny]

@pchampin I need some help from a native French speaker! @iherman perhaps you can help as well. :)

Two questions:

1. We have text in our spec that says "Exemple d'Université" today, which is supposed to translate into "Example University", but probably doesn't... how do we say "Example University" in French?
2. Is the postal address in https://www.w3.org/TR/vc-data-model/#example-a-credential-uniquely-identifying-a-subject correct? If not, would there be a good fake but believable address in Paris or Lyon that we could use instead?

We've been trying to fix this example for years... I'm still trying, but am out of my depth. :)

[iherman]

@pchampin I need some help from a native French speaker! @iherman perhaps you can help as well. :)

Two questions:

1. We have text in our spec that says "Exemple d'Université" today, which is supposed to translate into "Example University", but probably doesn't... how do we say "Example University" in French?
2. Is the postal address in https://www.w3.org/TR/vc-data-model/#example-a-credential-uniquely-identifying-a-subject correct? If not, would there be a good fake but believable address in Paris or Lyon that we could use instead?

We've been trying to fix this example for years... I'm still trying, but am out of my depth. :)

1. I would probably use "Université Exemple". What you have is a literal translation, but that is not how universities are usually called, my alternative makes it closer to current practice
2. The format for the address is correct, but the locality (Paris) and the Zip code (98052) are out of sync: afaik, no Zip code begins with '98', which is usually the number identifying a French "département" (and 98 is for none of those). I think putting it to 75123 might be better: all zip codes in Paris begin with "75".

[pchampin]

+1 to @iherman's suggestions

[OR13]

Can someone propose a complete JSON-LD example, and where it would be inserted into the specification?

[msporny]

Fixed in 43cc3a60b19b341237e6829fb16de1b5beab9e10 (purely editorial). We no longer have any Paris zip codes in the spec.

This last set of changes addresses the last remaining items we found related to this issue in the specification. Closing.