search

jhthorsen / json-validator

:cop: Validate data against a JSON schema
https://metacpan.org/release/JSON-Validator
56 stars 58 forks source link

Add support for translating error messages #130

Closed jhthorsen closed 5 years ago

jhthorsen commented 5 years ago

To be able to merge this PR, I need at least someone to look over the phrases documented in JSON::Validator::Error.

I do however think it's a good idea for the format validators to return an array-ref, instead of a plain string.

Overview of PR:

beyondcreed commented 5 years ago

Phrases look ok to me.

beyondcreed commented 5 years ago

However I think what the original idea was, that client code would translate directly, not the backend. Most of our use cases are SPA's or PWA's that read some data via API, interpret error codes and then select appropriate error on their own by consulting local lookup table so backend stays language neutral. I guess with this approach you are thinking more the translation should happen at backend, then return that to client? What if client wants to display something else though? Should we be stuffing error codes into phrase_params? A little confused.

jhthorsen commented 5 years ago

I was considering adding phrase and phrase_parameters to the TO_JSON() method, so that you would get that through the API directly.

Further, I was thinking about adding a type (which is probably the same as your "code") attribute to the Error object that group the different phrases together.

The nice thing about type (or code) is that it's easier to make sure it doesn't change in the future. The downside is that it's hard to figure out the correct type initially - I think.

The downside with phrase is that I cannot change it in the future if I find a typo or I want it structured differently.

beyondcreed commented 5 years ago

Hm, ok I guess that would show up in return structure. For type, maybe it was misunderstood what I was trying to say about error_code. Its not really a group indicator, its more of a unique/specific code representing that exact error state or value of the constraint that failed. e.g. e_register_duplicate_email. But I guess type could be used for groupings of phrases with some kind of default group? So from what I see, we would stuff error codes into phrase params, then read on client from returned structure?

jhthorsen commented 5 years ago

I think this idea was too ambitious. I will investigate if I can make a smaller change that adds "type" instead.

jhthorsen commented 5 years ago

This is replaced by https://github.com/mojolicious/json-validator/pull/133