@connor1231 I also agree that I was super muddy on why I would start out down one path or another (Gates vs Policies). Found this essay on the web to be useful. Also, towards the bottom, it has a specific paragraph related to this question.

https://www.twilio.com/en-us/blog/developers/community/what-are-laravel-policies-and-how-to-use-them-to-control-access

Here are some of the key comparisons between Gates and Policies:

• Scope: Gates are designed for simple authorization scenarios, where only a single check is required to determine whether a user has access to a particular resource. On the other hand, Policies are designed for more complex authorization scenarios, where multiple rules may be required to determine whether a user has access to a resource.
• Flexibility: Laravel Policies are generally more flexible than Gates, as they can be used to control access to any resource in a Laravel application, while Gates are typically used to control access to specific actions or routes.
• Syntax: The syntax for defining Gates and Policies is slightly different. Gates are defined using a callback function, while Policies are defined as a separate class with specific methods for each action.
• Granularity: Laravel Policies allow for finer-grained control over resource access, as they can be defined for specific models or model types. Gates are typically defined at the route or controller level, which may not provide the same level of granularity.

@RogerManich You can do it directly to each validation method like this:

$request->validate(
[
            'description' => ['required', 'min:10'],
],
[ 
			'description.required' => 'Write here in another language' ,
			'description.min' => 'Write :min to get the value of the variable, In this case = 10',
]);

Or change it globally. You can check out https://laravel.com/docs/13.x/localization

@jeffry if we want to display the messages in a different language is there a way to achieve that?

Little reminder for route order => Routes with fixed segments (create, edit) must always be declared BEFORE routes with dynamic parameters ({idea}).

@terdoo-mzer I've read that Laravel matches routes top to bottom, so the first one that fits the request wins. In this case "create" is acting as the {idea} parameter. That's how I understand. If I'm wrong please correct me

One important thing when creating routes like that, is the order.

Route::get('/ideas/create', [IdeaController::class, 'index']);

Must be defined before

Route::get('/ideas/{idea}', [IdeaController::class, 'show']);

Or you will scratch your head as to why you get a 404 when trying to navigate to the create Idea route.