Laravel Dynamic Form Validation: Turning answers.{key} into Real Field Names

In a public ICanUp form, Laravel server-side validation was working correctly, but the error message was wrong for the user.

Instead of a real field name, the response could expose a technical path such as answers.request_type.

That key is useful to application code. It means nothing to a person filling in the form.

I wanted to keep the request structure and Laravel validation rules unchanged while teaching the validator to use the real localized label of the dynamic field.

A form could contain a field with this key:

The public request naturally submitted it as a nested value:

The Laravel rule therefore worked with the full attribute path:

Without extra display-name information, Laravel used the technical attribute path when formatting the error message.

It is easy to assume that the fix belongs entirely in lang/en/validation.php or another locale file.

But the message template and the field display name are separate concerns.

Laravel can translate the whole validation sentence correctly and still produce a poor result if :attribute remains technical.

The answers.{field_key} structure was already the correct application contract.

It creates a stable link between a form field definition and the submitted answer regardless of the language used for the label.

For example, request_type can have different translations:

The technical key should not change with translations. Only the way that key is presented in validation messages needs to change.

Laravel FormRequest already provides a mechanism for custom attribute display names through attributes().

That is the mechanism I use in the public form request.

The idea is simple: map each technical answer path to the localized field label.

That would be enough for a static form.

My forms are reusable, however, so the field list is not known in advance.

The rules and labels already exist in the form definition, so duplicating them in the FormRequest would create another source of truth.

Conceptually, the implementation looks like this:

The same public form can be opened in Ukrainian or English.

The validation message therefore needs to use the same language the visitor is currently using.

I do not want a Ukrainian validation sentence containing an English field label or the opposite.

The label is resolved through the existing form translation architecture for the active request locale.

There is another important edge case: the field exists, but its label for the current locale is missing or malformed.

Even then, I do not want to expose:

A neutral human-readable fallback is safer.

This is one reason I prefer this solution.

attributes() does not change the payload or weaken any validation rule. It only controls the display name inserted into a validation message.

Laravel still validates answers.email. The visitor simply sees Email.

Once Laravel knows the correct display name, it does not need a separate label for every rule.

With reusable Forms, an administrator can create a new field without a PHP deployment.

If I maintained every display name manually:

then every new form field would require an application change.

That would undermine the purpose of the form builder.

I want the label displayed in the form and the label inserted into the validation message to come from the same source.

Renaming a field in the admin interface then automatically changes its validation message too.

No separate synchronization is required.

Even if Vue already shows required errors or validates an email before submission, the server cannot use that as the source of truth.

Client validation can be bypassed and the request can be sent directly.

The Form definition therefore continues to generate authoritative Laravel validation rules, while client validation improves only the user experience.

A human-readable attribute name should not change the form security contract.

If a visitor submits a field that does not exist in the active Form definition, wrapping it inside answers must not make it accepted automatically.

The allowed keys and validation rules still need to come from the current Form definition.

This kind of bug can be fixed for one example while other field types continue exposing technical attribute names.

The regression coverage therefore spans different rules and dynamic field types.

An HTTP 422 Unprocessable Entity response proves that validation failed. It does not prove that the user received a good message.

I also want to verify the expected validation key and ensure that the old technical message is absent.

I did not try to rename the validation key answers.request_type itself.

The frontend benefits from that stable path because it can attach the error to the correct field.

The message is the part that needs to be human-readable.

• Do not rename answers.{key} depending on the locale.
• Do not hardcode every FormField label in the FormRequest.
• Do not create a parallel validation-message system only for Forms.
• Do not replace server validation with client validation.
• Do not expose raw answers.* as a fallback label.
• Do not use a label from the wrong locale when the current translation is missing.
• Do not change validation rules just to improve the error text.
• Do not treat HTTP 422 alone as proof of good validation UX.

• Keep a stable technical field key.
• Build server rules from the Form definition.
• Build attributes() from the same FormFields.
• Use the label for the active locale.
• Provide a human-readable fallback when a translation is missing.
• Never expose raw answers.* in user-facing text.
• Test required, email, min, max, and option fields.
• Test UK and EN separately.
• Keep the validation key stable for client-side code.
• Do not change persistence or Communication integration only to localize validation messages.

In the ICanUp Forms case, server-side validation was not wrong. It simply knew the field as the technical path answers.{key} and did not know what that field was called for a person.

Translating standard Laravel validation messages solves only part of the problem. Dynamic forms also need localized attribute display names.

FormRequest::attributes() let me keep the request structure, validation rules, and validation bag unchanged while resolving the real FormField label for the active locale.

When a translation is missing, the user receives a neutral Field label instead of an internal path such as answers.request_type.

For me, proper validation localization means more than translating the word required. It means that a user should never need to understand the application’s internal data structure.