contentLang property
#114
Comments
|
Would this make more sense as part of a JSON UI Schema? (see #67 ) |
|
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 |
|
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. |
|
See this thread which collects a bunch of proposals relevant to this: |
|
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. |
|
Let's combine this suggestion with the conversations about a i18n vocab: json-schema-org/json-schema-vocabularies#10 |
(Filing as a separate issue as per #53 (comment) )
As with HTML's
lang/xml:langproperties, 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),
contentLangdoes 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).
The text was updated successfully, but these errors were encountered: