-
-
Notifications
You must be signed in to change notification settings - Fork 19
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
Question: Multi-Language Custom Errors #81
Comments
ajv-i18n should be ok to use with v7 - all it does is iterating errors and generating the messages. But it would only work with the standard errors for draft-07, neither draft-2019-09 keywords nor user-defined keywords would be supported. I’ll need to review again the linked proposal - I am not yet certain what’s the best design here, but it seems like it should be some cross-cutting concern that should be applied to all keywords - so possibly different from the current plugin approach... I see it as a wider design question than just for internalisation - e.g. support for parsing seems to be in the same category - the extension mechanism that should be applied to all keywords. That’s why I didn’t want to rush it. Also see ajv-validator/ajv#1161 (comment) At the moment there are two options:
Assuming I settle on the latter approach (I don’t see any alternative tbh) v8 would include some type/function to support such extensions and ajv-i18n will be reimplemented using it. We can collaborate on it if you need it sooner than end of March. Maybe you have some better ideas? |
As always, thanks for the detailed and educational reply. Generating two schema pragmatically and use In our use case we currently allow contributors to upload large dataset to our service, before sending we have a web worker validate the file against our data schema. We do this client side to reduce the amount of data needed to be uploaded when there are errors that need to be resolved. A large number of our contributors are in remote locations in northern Canada where bandwidth is a valuable commodity. We're planning to rebuild our upload system to support multiple languages like french and maybe even some indigenous ones. Our roadmap has this in Q2, so lots of time. I'm happy to collaborate on this if you think I can help. What you described in your linked comment and here sounds like the right approach from a high level. I should be free in a week or so after middy.js v2-alpha goes out for community feedback. Ping me an gitter, maybe we can put together a small working group for this? cc @ucarion |
Hey, I was finally able to get back to this. Did some additional reading of past proposals and comments on the json-schema-spec. Seems there is a kind of agreement that translations should be external (too complicated within the schema) and that an identifier should be used. I put together a proof of concept, https://github.com/willfarrell/ajv-ftl-i18n, based off One caveat is that the option |
I'm just thinking ahead on what will be on the roadmap, and this popped to mind.
What is the best approach to providing custom errors in multiple languages? Is it even possible right now? Something planned for when ajv-i18n become a proper plugin?
ajv-validator/ajv-i18n#153
The text was updated successfully, but these errors were encountered: