Consider explicitly allowing/recommending language maps for use in internationalisation.

[anthonycamilleri]

In the European context, multilingual credentials are commonplace. The typical use case is to have approx. 30 languages which may be used for a credential-type, with any individual credential being typically expressed in 2-3 languages. For this kind of use case, it makes sense for us to use JSON-LD language indexing, as specified here https://www.w3.org/TR/json-ld11/#example-71-language-map-expressing-a-property-in-three-languages. This approach is the one currently adopted in the European Digital Credentials scheme.

By my reading of the section 10.1, this approach seems to be supported, but the current language makes it a bit unclear if only examples described in the VC standard are supported, or whether any internationalisation approach supported by the JSON-LD standard is supported.

The suggestion would be to explicitly mention language-maps as a supported approach, and possibly include a language map as an example.

[msporny]

By my reading of the section 10.1, this approach seems to be supported, but the current language makes it a bit unclear if only examples described in the VC standard are supported, or whether any internationalisation approach supported by the JSON-LD standard is supported.

Language maps are supported. Any i18n mechanism supported by JSON-LD is supported by VCDM.

That said, there were multiple organizations that objected to using advanced JSON-LD features. So, the best we could do in the specification is to try and find a middle ground. That resulted in this section:

https://w3c.github.io/vc-data-model/#type-specific-credential-processing

as well as the general section on JSON-LD usage:

https://w3c.github.io/vc-data-model/#json-ld

At present, I don't think we'll be able to get consensus to recommend language maps. They are already allowed per the specification, perhaps we can say more about them being allowed since you read the spec and it wasn't clear to you.

Given the above, what sort of language would you like to see in the specification around this topic?

[iherman]

I believe the right pointer is https://w3c.github.io/vc-data-model/#language-and-base-direction and not what @msporny put into his comments

[iherman]

The issue was discussed in a meeting on 2024-05-01

• no resolutions were taken

View the transcript

3.3. Consider explicitly allowing/recommending language maps for use in internationalisation. (issue vc-data-model#1479)

See github issue vc-data-model#1479.

Brent Zundel: This was raised a couple of weeks ago -- consider explicitly allowing / recommending language maps.
… This was read by someone outside the group who wanted more clarity on the i18n text -- they are making a concrete request for more text.
… We did ask for specific language that they'd perhaps find acceptable -- would like to hear from folks on this in the group.

Anil John: The ability to do language translations automatically for the credentials and attestations that we have would be good. I saw the feedback from Manu on the issue. Just a clarification question -- it sounds like basically having JSON-LD compact form, you have the ability to do that. Does anything in the current spec prevent the use of language maps in anyway shape or form?
… For people who want to use that for translation?

Ivan Herman: I think the problem is that there a section -- I don't know from the top of my head -- that shows how a pure JSON processor can handle JSON-LD credentials and that is not describing anything about language maps the way they are done in JSON-LD.

Anil John: Understand Ivan's point -- I'm glad the flexibility exists that allows someone who wants to use a JSON-LD API to get functionality that is unique to JSON-LD and obviously in a context-specific processing love the flexibility to avoid doing that using static contexts and JSON schemas.
… The question I would ask is -- if you wanted to use the features that are unique to JSON-LD, you would need to use a JSON processing capability. Great. If you choose to go down that path, does anything prevent you from doing that -- with the full understanding that you're going to be treating the credentials that way, you won't have access to that functionality?

Brent Zundel: Nothing in the spec prevents you from using JSON-LD to use its full capabilities to my knowledge.

Dmitri Zagidulin: would just more examples (of multi-language VCs) help?

Benjamin Young: This isn't about JSON-LD processing being required. The spec simply says "shape the JSON like JSON-LD does.".

Phil Feairheller: Isn't the issue here simply that there isn't a comparable set of paragraphs that describe using JSON-LD specific language processing? Implication is that it would be good to have both explanations.

Anil John: Thank you. that is very helpful dlongley.

Gabe Cohen: It seems there is a JSON-LD language map solution -- is there another one if they don't want to use it?

Brent Zundel: Thanks Gabe.

Dmitri Zagidulin: Reading this issue from Anthony, he does a lot of advising to the EU commission on the learning data model, etc. lots of skin in the game. The way he phrases the issue is that he would like it to clarify whether only the subset of i18n is supported or if multiple methods are supported.
… JSON-LD has several methods, we support and recommend a subset, so I am reading the issue as "our subset vs. all options".

Brent Zundel: Perhaps this issue could be resolved with a sentence that says "Additional JSON-LD capabilities could be utilized -- but if the recipient doesn't do JSON-LD processing they may not be received".

Dave Longley: It's not a JSON-LD processing issue but a type-specific VC one.

Brent Zundel: We'll get back on timing issues for the controller docs, thanks all!
… Thanks for scribing, Dave.

---