Question: Multi-Language Custom Errors about ajv-errors

[epoberezkin]

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:

1. Use errorMessage and generate schemas programmatically, supplying the messages you need.
2. Use ajv v7 and dynamically update error messages inside keyword definitions for your keywords - the new internationalisation is likely to do the same. It means that you’ll need a separate instance per language and keyword definitions need to be cloned, but it seems ok.

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?

[willfarrell]

As always, thanks for the detailed and educational reply.

Generating two schema pragmatically and use ajv-errors was what I was thinking. Not a big burden to write, but added extra complexity. Sounds like I'm not the first to bring this up. Glad to hear it's something that's planned.

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

[willfarrell]

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 ajv-i18n with the ability to pass in a fluent file and the ability to use errorMessage as an id w/ params. For now it's currently unpublished, but curious if you think it might be worth using this for [email protected]?

One caveat is that the option message needs to be true to be able to have the resulting errorMessage accessible to be used for matching up to the translation file. Would it be possible to return the processed errorMessage as a param in this case or always, shaving off ~2kb of unused english messages?