Customize error messages (e.g. for translations)

[pierrecamilleri]

Hi,
I would need to translate the error messages and it happens to be more complicated than I expected (or than it could be, I believe).
I started using information on ValidationErrors to define custom messages, but all relevant information for the message is not always readily available. Found this related issue #564 but with not much follow-up so I thought I could ask again.

For instance, for an "additionalProperties" keyword, looking at the code shows that there is some logic that needs to be reimplemented to make message translations (using internal _utils.find_additional_properties to find the offending properties, two different messages depending on whether properties or patternProperties is used etc.).

In addition to the overhead this introduces, I am afraid that it may drift out of sync with the logic in this package in case of improvements, bug fixes, or new draft support etc. or that internal functions may change without backward compatibility.

I am wondering if it would be possible to not hard-code messages, but use templates instead (e.g. Jinja2), that have access to error-specific contextual data (e.g. offending properties for "additionalProperties" errors), and that could be changed for a translation without touching at the logic. This is for instance the approach taken by xeipuuv/gojsonschema.

I think it would be worth a try, and I would be willing to contribute on this with a little help, if you think it is a good idea.

[Julian]

I'll respond in more detail on the core issue here, but

For instance, for an "additionalProperties" keyword, looking at the code shows that there is some logic that needs to be reimplemented to make message translations (using internal _utils.find_additional_properties to find the offending properties, two different messages depending on whether properties or patternProperties is used etc.).

This is essentially always considered a bug (not being able to reconstruct the error), so a bug report for that specifically is definitely welcome.

[pierrecamilleri]

Thanks for the answer. I don't think that in these cases, it is not possible to reproduce the error message, but it requires some extra effort.

One borderline case I encountered may be for minContains and maxContains: to count the number of matching elements, each element of the array is validated with validator.evolve(schema=contains).is_valid(each) (here). Reproducing this reliably presupposes to remember what jsonschema draft to use, which is often known from the context but cannot be guessed from the ValidationError alone. If you think this deserves a full bug report I would be happy to file one.

[Julian]

Isn't the relevant value in the minContains example just error.validator_value? The code today doesn't calculate the total number of matches, it stops once that's met -- maybe that's what you mean by borderline?

Essentially what I mean is a bug is anytime there's some metadata that was calculated during processing, affects the error message, and isn't present in one of the existing attributes.

Maybe I misunderstand that case but yeah isn't everything needed already present without recalculating?

[pierrecamilleri]

Ah, you are right for maxContains but minContains reports the total number of matches.

"Too few items match the given schema (expected at least "
f"{min_contains} but only {matches} matched)"

[Julian]

Ah indeed, ok yeah that's certainly a bug (regardless of the original topic).

[gloaguen-evan]

Thank you for your response to my issue.

I don't take that as a slight, I fully understand that this is not a priority and that there are other more important bugs/features to deploy.

I will take a look at the gettext module.

[gloaguen-evan]

Hi,

Here is my proposal with the use of the gettext module (branch)

I think it's more regulatory, but I'm afraid that to maintain, it won't be great.
Indeed, each time a line is added or messages are modified, all the .po/.pot files will have to be resumed.

Tell me if you want me to do a PR with this branch.

[goschtl]

Hi,

thanks for this work.
What id the status of this branch. Would it be possible to merge it. Any plans?

Christian