Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Customize error messages (e.g. for translations) #971

Open
pierrecamilleri opened this issue Jul 9, 2022 · 8 comments
Open

Customize error messages (e.g. for translations) #971

pierrecamilleri opened this issue Jul 9, 2022 · 8 comments
Labels
Enhancement Some new desired functionality Error Reporting Issues related to clearer or more robust validation error reporting

Comments

@pierrecamilleri
Copy link

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

This comment was marked as off-topic.

@pierrecamilleri

This comment was marked as off-topic.

@Julian

This comment was marked as off-topic.

@pierrecamilleri

This comment was marked as off-topic.

@Julian

This comment was marked as off-topic.

@gloaguen-evan
Copy link

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
Copy link

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
Copy link

goschtl commented Mar 4, 2024

Hi,

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

Christian

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement Some new desired functionality Error Reporting Issues related to clearer or more robust validation error reporting
Projects
None yet
Development

No branches or pull requests

4 participants