How can I translate Laravel's default validation errors in JSON file?

I need to translate Laravel's default validation errors in JSON files. The problem is if I want to overwrite a translation, like the 'required' validation error in resourses/lang/de.json file, it doesn't work.

The reason why I have to do this is the Phrase translator system what I am using.

Any idea? Thanks!

ANSWER

After some research, now I see what is my 'problem'. Laravel using the trans() function for translating the validation errors but if you want to use Laravel's JSON translation then you have to use the __() function. Okey, I know why they are doing in that way, because the validation errors are structured by 'short keys' and the JSON formatted translation if for use strings as keys. But what if I still want to translate the default errors in the JSONish (I know it's a futuristic word) way? Follow my solution here:

First of all you have to create a form request (https://laravel.com/docs/7.x/validation#creating-form-requests):

php artisan make:request UserUpdateRequest

In the newly created form request file you have to overwrite the messages function to be able to translate the validation errors:

namespace App\Http\Requests\v1;use Illuminate\Foundation\Http\FormRequest;use Illuminate\Contracts\Validation\Validator;use App\Exceptions\ApiValidationException;class UserUpdateRequest extends FormRequest{     /**      * Get the validation rules that apply to the request.      *      * @return array      */     public function rules()     {          return [              'name' => ['required', 'string', 'min:3', 'max:255'],          ];     }     /**      * Get custom messages for validator errors.      *      * @return array      */     public function messages()     {          return [              'name.required' => __('The user name is required.'),              'name.string' => __('The user name must be a string.'),              'name.min' => __('The user name must be at least three characters.'),              'name.max' => __('The user name may not be greater than 255 characters.'),          ];     }}

Now we have to create the translations files (https://laravel.com/docs/7.x/localization#using-translation-strings-as-keys) and put the new translation strings into them.

# resourses/lang/de.json{    "The user name is required." : "The user name is required.",    "The user name must be a string." : "The user name must be a string.",    "The user name must be at least three characters." : "The user name must be at least three characters.",    "The user name may not be greater than 255 characters." : "The user name may not be greater than 255 characters."}

And that's all.I hope this description of translation process it will be useful for someone else.

Based on the answer provided I digged some more and discovered the double underscore function is working as intended in the default validation.php file! I tested it with Laravel 5.6.

I have a similar issue that I need to provide a way for users to give translations for everything in the web app and so I started to test the solution. While it works as explained it does not use the placeholder attribute anymore and therefore it is not very scalable in my situation.

I tested using the double underscore function with the following requirements:

1. locale and fallback_locale are set to 'en' in app.php
2. There is an en folder inside resources/lang
3. There is a validation.php file inside the en folder
4. There is a locale json file (like pt-br.json) inside resources/lang folder
5. The application sets the locale dynamically using App::setlocale()

All that is needed to change in validation.php is to use the function in the string, like the following:

# before'unique' => 'The :attribute has already been taken.',#after'unique' => __('The :attribute has already been taken.'),

And the json file needs to have a string key with the same string, like the following:

"The :attribute has already been taken.": ":attribute j\u00e1 existe!"

Thanks for making me thinking more on this problem. I think Laravel should have better support for use cases like this.