Fix validation error message localization

[bakerkretzmar]

• Added or updated tests
• Added or updated the README.md n/a
• Detailed changes in the CHANGELOG.md unreleased section

Related Issue/Intent

Ensures it is easy to customize/localize validation error messages when using the validation rules as classes or as strings.

This PR reverts #141, which reintroduced the issue in #133 where using the validation rules as strings (e.g. enum_value:UserType) prevented error messages from being displayed properly. #141 didn't really have any explanation of its changes, but what I think it was trying to do was allow users to easily customize the error messages for this package's validation rules. It implemented this the wrong way though, localizing the message strings themselves directly inside the language file. This has a few disadvantages:

• to translate the messages you would have to re-translate the string by adding "The value you have provided is not a valid enum instance.": "Translation..." in a JSON translation file
• it will translate/override that exact string everywhere it appears in the app, not just in validation errors
• it prevents customizing the validation error message for specific attributes or enums (you can't set new messages in any validation.php file)
• it removed localization of error messages for string rules, breaking the default error messages for something like enum_value:UserType

Changes

This PR re-implements localization of validation error messages.

It allows this package's validation error messages to be translated by adding enum, enum_key, and enum_value keys to the en/validation.php file that ships with Laravel, and the corresponding files for any other locales.

It also allows further customizing the messages for specific cases by adding entries to the custom key in that file, e.g.:

    'custom' => [
        'user_type' => [
            'enum_value' => 'The user type you have entered is invalid.',
        ],
    ]

Notes

The reason the trans()->has() check in the rules is necessary is that Laravel handles validation error messages completely separately for custom rule classes and for string rules added with Validator::extend().

For string rules, the third argument to Validator::extend() is treated as a fallback. If a language file entry for the snake-cased rule name exists, that will be used, otherwise the fallback will be used (source). This worked fine before #141 and still does if you manually add all the keys to your lang files, but #141 breaks it out of the box. This PR makes it work by default again, without users needing to add any language lines themselves.

For class rules, the messages() method is the single source of truth—Laravel's validator doesn't check for custom language file entries for the key at all (source). This PR adds a check to see if any custom keys have been defined, so they'll be used instead when possible, and otherwise falls back to the ones provided by the package.

[BenSampo]

Hi @bakerkretzmar, thanks very much for looking into and fixing this. I really appreciate your detailed write up. I'll get this merged and tagged.

Cheers!

[bakerkretzmar]

Thanks so much!