You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been in trouble with Joi default messages, and after searching a bit about it, I found those two comments made by Joi's developper Marsu :
I've said messages shouldn't be forwarded to end-users as is, mainly for i18n reasons, and I maintain that i18n can't be part of the core joi features, it doesn't mean it can't be i18n-friendly. Issue #546
It would be better to post-process the errors with your own i18n layer, error messages are in plain English and intentionally targeted at developers, not end-users.
You have everything you need in the return of joi to build your own messages (type of error, key that failed, ...) Issue #638
He is strongly suggesting to use errors.details to generate messages ourselves, instead of using errors.message
In the current version of react-joi-validation though, users are forced to only get a label-less version of errors.message meaning that personalization or I18n is not possible as is.
It would be a good idea to remove this fixed part of the pipeline and replace it with a hook. For backward-compatibility, this hook could default to the currently implemented version.
About where to put the callback, I was thinking of setting it in the HOC options.
What do you think about this ?
The text was updated successfully, but these errors were encountered:
Please bare with me while I try and clarify my thoughts on this. I am hoping to have a more thoughtful reply than I can offer right now, some time soon.
Hi,
I've been in trouble with Joi default messages, and after searching a bit about it, I found those two comments made by Joi's developper Marsu :
He is strongly suggesting to use
errors.details
to generate messages ourselves, instead of usingerrors.message
In the current version of react-joi-validation though, users are forced to only get a label-less version of
errors.message
meaning that personalization or I18n is not possible as is.It would be a good idea to remove this fixed part of the pipeline and replace it with a hook. For backward-compatibility, this hook could default to the currently implemented version.
About where to put the callback, I was thinking of setting it in the HOC options.
What do you think about this ?
The text was updated successfully, but these errors were encountered: