Add "messages" property

[johnmanko]

A continuation of json-schema/json-schema#183

Add a "messages" property to define custom messages for validation keys.

Example:

{
    title: "Name",
    type: "String",
    minLength: 4,
    maxLength: 6,
    messages: {
        minLength: "Your name must be at least four characters long.",
        maxLengh: "Your name must be no more than six characters long"
    }
}

Custom messages of an implementation could allow for template vars. Also consider:

{
    title: "Password",
    type: "pattern",
    pattern: '^[a-zA-Z0-9@#\\$%]{8,20}$',
    messages: {
        pattern: "%title% must be 8-20 characters and must contain only alpha-numeric character or the following @, #, $, %"
    }
}

Related:
geraintluff/tv4#115
geraintluff/tv4#206
json-schema/json-schema#183

[awwright]

This looks like a string that's supposed to be presented to end users, which should be able to be localized. Putting end-user strings in the JSON Schema might make that job more difficult, and generally it's best to place localized strings together in the application anyways.

A validator should already be able to tell you which keyword(s) failed and let you generate an error message based off it.

Maybe this is less true for labels, if we ever used JSON Schema to generate UI/form fields; but for errors this might create more of a problem instead of less of a problem, because of how substitution into strings works.

Can you describe your particular use case a bit?

[handrews]

@johnmanko you might also be interested in this thread on additional JSON Schema vocabulary proposals including UI and documentation-oriented schemas. The topic of I18N/L10N as a cross-cutting concern for these sorts of things is also mentioned.

[seagreen]

Link to the issue @handrews mentioned: #136

[awwright]

@johnmanko Can you describe your particular use case a bit, including how you're doing localization?

[revolunet]

Hi 👋

Just another use case :)

some json-schema validators, like https://github.com/tdegrunt/jsonschema or https://github.com/bugventure/jsen, who provide default error messages based on data + schema could use the schema messages if present
And form generators like https://github.com/mozilla-services/react-jsonschema-form can then just consume the schema definition and provide the full UI and messages just based on the schema definition

[handrews]

@revolunet thanks! Just so you know, @Anthropic of angular-schema-form (to which I believe react-jsonschema-form is related? Or maybe there's another react-schema-form?) and json-schema-form (framework-neutral) filed #67 about creating a JSON UI Schema vocabulary in case you want to be involved in that. We haven't really gotten started on it yet.

[Anthropic]

@handrews react-jsonschema-form is a Mozilla project and react-schema-form is the one based on ours. Not sure which one to base our react port on yet. I do think an expected pattern for validator responses to follow would be good for everyone. Especially for switching and avoiding lock in, but also for fairly testing between them in benchmarks.

[Relequestual]

As an aside, we should try and get someone from Mozilla on board for the draft-6 review =D I'll see what I can do!

[epoberezkin]

@handrews see https://github.com/epoberezkin/ajv-errors/blob/master/SPEC.md (that's a preliminary spec, not implemented yet...)

[alphanull]

The localization issue is what I also see here. But on the other hand, you also could use just some defined error codes instead of fully translated messages. In general the idea is not bad, especially when used with patterns. I mean, if I say to my users "Invalid Pattern", it is more confusing than useful in any way. So definetly a thing to think about imho.

[johnmanko]

@awwright To be honest, I wasn't considering localization. Bad on my part. The use case was to use the json schema to validate input in business logic - ie, allowing json schema libraries that tightly follow the spec to act as input/form validators. This is less of an issue now with front-end frameworks that use reactive forms. I still think it's a good idea if we can solve the localization issue.

[johnmanko]

@epoberezkin Should change "errorMessage" to "validators".

[epoberezkin]

@johnmanko the term used in the I-D is "keywords".

[philsturgeon]

With #396 being discussed for formalizing error output, I think we could close this issue. As everyone has mentioned, localization here becomes tough. Using the error format we're working on it should be possible to pass in the data and construct a human-readable error message which does indeed support localization. That's something we'll keep in mind the whole time, so let's close this and move our attention over there.