Multilingual Dynamic Forms in Laravel: Stable Data Across Locales
Multilingual Dynamic Forms in Laravel: Stable Data Across Locales
Laravel language files translate system UI. They do not automatically translate titles, field labels, help text, placeholders, options, or success messages stored inside a dynamic form schema.
A multilingual form has three localization layers:
- System chrome: Submit, Next, errors, unavailable states.
- Author content: title, labels, help, placeholders, options, confirmation copy.
- Submission context: the locale and revision the respondent saw, plus notification/export presentation.
Keeping those layers separate prevents a language switch from changing stored meaning or splitting analytics.
Compare the schema models
| Model | Strength | Weakness | Best fit |
|---|---|---|---|
| Clone form per locale | Works immediately | Logic drift and split analytics | Fast workaround |
| Translation maps in schema | One form and stable codes | Custom builder/render logic | Few locales |
| Translation table | Workflow and query flexibility | More joins/admin UI | Many locales and editors |
A translation map might store label.en, label.fr, and label.ar, while the field code remains one language-neutral ULID. The same applies to option values: store enterprise, not the displayed English or Arabic label.
Persist locale and revision
Store locale and form_version_id on every submission and draft. Historical display can then render the exact revision using the locale the respondent saw.
If option labels come from mutable external records, decide whether the historical label comes from the revision or a submission snapshot. Never infer the old language from the administrator currently viewing the record.
The form versioning guide covers the immutable revision relationship.
Resolve locale before Livewire mounts
Set locale through a trusted route/domain preference before rendering the component. Ensure the localization middleware persists across Livewire update requests; otherwise the initial page may be French while validation updates fall back to English.
Livewire documents persistent/custom update middleware in its security guide. Keep the selected locale allowlisted and store it in trusted component/draft context rather than accepting arbitrary language identifiers.
Translate validation for humans
Laravel can translate rule messages, custom attributes, and values. Dynamic fields need a locale-aware mapping from immutable code to label, or errors will expose internal identifiers.
Translate both:
- the template: “The :attribute field is required”;
- the attribute:
contact_email→ “adresse e-mail”; - enum/value names where they appear in messages.
See Laravel localization and validation message translation.
Language and direction are separate
Set a correct <html lang> and switch dir="rtl" for right-to-left locales such as Arabic. Language metadata alone does not establish directionality. Use logical CSS properties, test mixed-direction values such as email addresses, and inspect focus/error ordering.
W3C maintains separate guidance for language declarations and page direction.
Localization also includes date/time formats, decimal separators, names, address expectations, phone inputs, pluralization, and file constraints. A translated label on a US-specific input mask is not a localized form.
Queue notifications with explicit locale
A worker does not inherit the browser request locale. Store the submission locale and apply it when sending confirmations or rendering exports. Laravel supports localized notifications.
Administrative notifications may use the recipient's locale while including the respondent's locale as metadata. Do not silently translate submitted free text.
Keep analytics unified
Aggregate by stable form, revision, field, step, and option codes. Add locale as a dimension rather than cloning event names. Low-volume locale segments can identify individuals, so apply minimum group sizes and the same retention/privacy policy as other analytics.
Cloned-per-locale forms can be a pragmatic first version, but document the cost: validation and conditional logic can drift, and conversion is split across identifiers.
Missing translations need workflow
Define one fallback chain, for example requested locale → form default → application fallback. Show editors which strings are missing before publishing. A fallback should keep the form usable, but an approval flow may block publication when legal consent text lacks translation.
Test an English/French/Arabic fixture
- locale middleware runs before mount and persists on updates;
- form labels and Laravel validation messages match;
<html lang>anddirare correct;- field/option machine values stay identical across languages;
- submission and draft store locale/revision;
- queued confirmation uses the respondent locale;
- old submission wording survives later edits;
- missing text follows the documented fallback;
- analytics remain one form with locale dimension.
Our form accessibility guide explains why language metadata and understandable errors matter beyond translation. A stable multilingual model translates presentation while keeping stored semantics unchanged.