Get the next one in your inbox.
One email when we publish something worth reading. No spam — appropriately enough, we'd know.
Translating your form's visible text is the easy 20%. Here's the checklist for the parts teams actually miss — field names, routing by language, and autoresponders that reply in the right one.
Get an instant summary, key takeaways, action items, and answers to your questions about this article.
Translating labels and placeholders is the visible part. The parts that actually break multi-language forms are backend-facing: keep field names in a stable, English internal format regardless of display language, detect and route submissions by locale, and send autoresponders in the language the form was actually filled out in.
Translating a contact form usually starts and ends with the visible text — labels, placeholders, the submit button. That part is genuinely easy. The parts that quietly break in production are the ones nobody localizes because they're invisible: field names, routing, and what the automatic reply actually says.
It's tempting to name a field after its translated label — nombre for a Spanish "Name" field, naam for Dutch. Don't. Keep the underlying field name attribute in one stable, internal format (e.g. fb-sender-name) regardless of what's displayed, and translate only the visible label and placeholder text. Otherwise every language variant of your form becomes a different data shape on the backend, and routing rules or exports have to handle N different field names for the same piece of information.
A form served at /de/contact is a reasonable signal, but a submission can still arrive from someone using a browser set to a different language, or from a shared link. Where it matters, capture the page locale as a hidden field alongside the visible fields, so routing and autoresponders can act on the language the form was actually presented in — not just the one your URL structure implies.
If support is split across regions or languages, conditional routing can send a German submission to a German-speaking team and an English one elsewhere, using that same locale field — the identical mechanism already covered in conditional routing recipes, just keyed on language instead of inquiry type.
An autoresponder that arrives in English after someone filled out a German form undoes a lot of the trust a translated form just built. Autoresponder templates can be set per language using the same locale field — see how the inbox surfaces this per submission so a human reviewing it also sees which language to reply in.
If any supported language reads right-to-left (Arabic, Hebrew), test the form's layout specifically in that direction — form validation messages, required-field markers, and error placement are common spots where a form that's otherwise fully translated still visually breaks.
name attributes stay in one internal format across every language variant.None of this requires different infrastructure per language — it's the same endpoint and the same setup for every variant, just with one extra hidden field carrying the locale through.
No — keep the underlying field name attributes in one stable format regardless of display language, and translate only the visible label and placeholder text. Otherwise each language becomes a different data shape on the backend.
Capture it explicitly with a hidden field set to the page's locale, rather than inferring it from the form's URL alone — a shared link or a browser language setting can mean the visible page and the visitor's actual language differ.
No — one endpoint handles every language variant. A hidden locale field carries the language through so routing and autoresponders can act on it without separate infrastructure per language.
One email when we publish something worth reading. No spam — appropriately enough, we'd know.