While language might be improved, I don't see much value in customizing the key name nor doing your own stringify. Can you explain your intent on these ?

The "stringify" method is nothing but a extraction of the former one-liner, an effort for cleaning code.

Regarding the key customisation: It allowed me to prefix the defaults in a custom localisation. Also i can add some formatting using colors when I use joi in a command line context.

I think you shouldn't enforce the quotes without your stringify, I'd rather go with a key defined as '"{{!key}}" '.
The [] in plain english sentences don't look like a great win (eg. array or index's tests).

On a side note, I'd like people's opinion on the semver side, I don't think it necessitates a major bump, unless people are parsing language, any votes ?

The [] in plain english sentences is looking a little uncomfortable, agreed. But it is fixing an the current problem that hello, world and ["hello","world"] generate the same output. With the braces those two cases are clearly distinguishable thus making debugging easier. Same thing goes for the quotes in the key.

You had to change every single test message to add quotes, that doesn't look like it was enforced before ;)
Don't you think quotes without the array are enough to identify it's not part of the sentence but an actual value ?

I did have the problem to distinguish once. I think thats why I changed it (its all been a while since I started that PR ;) )

Don't want to raise another language related issue but it drives me mad.

verifyPassword: Joi.any().valid(Joi.ref('password')).options({language: {any: {allowOnly: "Passwords don't match"}}}).label('')

Even this mess doesn' work as "smart" check inside Joi prohibits empty labels...
Please, please do something with this language option.
Still don't get why it can't be like this:

verifyPassword: Joi.ref('password').customMessage("Passwords don't match")

without all those wrappers and undocumented keys (what is allowOnly?).

@ivan-kleshnin It seems to me you are hoping this message would end up somewhere on the front-end, Joi is not for that. Open another issue to describe more in depth what you want to achieve.

@Marsup I'm aware of multiple projects which already use Joi for frontend validation. So whatever the initial intent of this library was – it's not perfectly valid anymore. Is this such a big problem to fix?
I understand your desire to minimize the responsibilities of library but the absense of adequate custom messages seems very strange...

I don't consider what you're saying a problem, so I won't "fix" it. Open another issue to explain in details.

@Marsup, as you wish #546 but all these are about the same.

Hey @martinheidegger, sorry for the time it took me.
I've rebased your commits against master and did a lot of modifications to how the language works, can you check if it's aligned with what you intended to do please ?

Looking at it now (After some time passed) I think I had two intentions: a) Make sure that I don't get confused by the error messages b) Make it possible to change the templates more flexible.

The changes are a slight step forward in terms of a) but I am not sure if b) could be done better.

I am thinking now that it might be better to enter the values & keys as "objects" with a good .toString method. This way they can be "stringified" differently if the output ought to be html or should have color formatting.

b) is why I've left as much as I could in the template, I don't want to impose any character (like [ or ]) from the code.
I think toString will be the default option for anything that's not an array or a special value, did you have something else in mind ?

b) I think i mentioned it in the comment but it leaves some indistinguishable cases open by not having [] in the stringification. Also I am not sure (havn't figured out) where in the chain the stringification takes place but I assumed when the error is created?

I've noticed your comment, still thinking about solutions to that.
The stringification takes place at the end of the validation, not when they are created.

What do you think about a boolean switch to wrap or not arrays ?

Or defining separately both enclosing characters ?

@martinheidegger does 69904a3 fix your concerns ?

I think it does. Thank you for going the extra mile.

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.