Description
(Filing as a separate issue as per #53 (comment) )
As with HTML's lang/xml:lang properties, it would be useful to indicate the content language of a particular field in a standard manner. This might be used for proper font display (as in CJK languages) or for selectively showing content to users based on their locale.
I think a name "contentLang" for the property would avoid confusion at (falsely) thinking that this was necessarily indicating the language of the "title" or "description" itself.
Although it is probably not a feature that would be used for validation (since looking at code points might not be reliable or valid such such detection), contentLang does describe the data, placing constraints on how it is to be understood which brings it more into the world of schemas (unlike i18n of the schema itself).
Note that JSON-LD would not solve this unless one uses JSON-LD in the instance documents (which would prevent the benefit of having such a pseudo-constraint at the schema level).
Activity
handrews commentedon Oct 28, 2016
Would this make more sense as part of a JSON UI Schema? (see #67 )
brettz9 commentedon Oct 28, 2016
It may have a bearing on view so I can see that argument, but it is essentially related to describing the content.
In my view, it would make more sense if it were added to the validation spec, though mentioning that no specific validation requirements are added thereby, and with the UI schema mentioning that
contentLangought to be leveraged for such as<html lang>(so as to support the proper font display) and optionally utilized by user agents in choosing whichcontentLangcontent (if any), ought to be displayed by default for the user (e.g., allowing the default hiding of content for languages not in the current locale(s) with the option given to the user to selectively re-enable any number of othercontentLangcontent).Relequestual commentedon Nov 2, 2016
Mmm. Initially I didn't feel like this should be in JSON Schema, but annotation is part of the remit. I don't see a problem with this.
handrews commentedon Nov 17, 2016
See this thread which collects a bunch of proposals relevant to this:
https://groups.google.com/forum/#!topic/json-schema/cG4HAyerqQk
handrews commentedon Dec 27, 2016
This may make sense in the proposed annotation/meta-data spec #136 which would quite likely be where the current meta-data section in the validation spec would end up.
philsturgeon commentedon Jan 15, 2020
Let's combine this suggestion with the conversations about a i18n vocab: json-schema-org/json-schema-vocabularies#10