Bilingual website forms: keep English and Spanish consistent

By Noe Guerrero III

A Spanish service page should lead to a form a Spanish-speaking customer can finish. That includes the field labels, instructions, error messages, confirmation screen, and any follow-up message your system sends.

It's easy to review a translated homepage and assume the job is done. The more useful check is to follow one customer request from the first click to the final confirmation.

For a business serving customers in McAllen and the Rio Grande Valley, that gives language support a practical purpose: helping someone ask for what they need without having to translate the process themselves.

Follow the request, not just the page

Imagine a customer reading a Spanish page about a repair service. They click to request an estimate, but the form asks for “service details,” rejects their entry with “invalid input,” and finishes with an English confirmation email.

That's a hypothetical example, but it's a useful test case. The service description has been translated; the request process still needs work.

My recommendation is to map the screens and messages before translating individual words. Include anything supplied by a booking tool, form plugin, or customer-management system. Those tools may have their own language settings and templates.

Give a reviewer one task: submit a test request in Spanish and explain what they think happens next. Then repeat it in English. Use a test environment or an agreed test procedure so the review doesn't accidentally create real appointments or customer notifications.

Make mistakes understandable in either language

People mistype email addresses and miss required fields. The form should help them recover.

W3C's form-notification guidance recommends clear feedback that identifies the problem and explains how to correct it. Apply that same care to both languages.

For example, “Revisa tu correo electrónico e incluye el símbolo @” gives someone a next step. “Error” alone doesn't. Match the message to the actual validation rule; don't tell someone their address is wrong when the email service is temporarily unavailable.

Keep the field names consistent, too. If the label says “Correo electrónico,” use that wording in the related error message. Have a fluent reviewer check whether the instructions sound natural and describe the action correctly. A translation can be grammatically correct and still leave the customer guessing.

Carry the language choice through the handoff

A success message should say what was received and what happens next. Requesting an appointment and receiving a confirmed appointment are different events; neither language should promise more than the system has actually done.

Here's a compact review list for the full journey:

• Before submission: labels, required-field notices, examples, and button text match the selected language.

• When something fails: the customer gets a useful explanation and can correct the problem.

• After submission: the confirmation accurately describes the saved request and next step.

• During follow-up: automated messages use the chosen language where supported, and staff can see the customer's preference.

• When switching languages: the choice is easy to find, and any loss of already-entered information is identified and addressed.

Don't infer someone's preferred language from their name or address. Let the customer choose. If your team can only follow up in one language, explain that before the form is submitted so expectations are clear.

Give your developer two separate checks

First, check the language declared in the page's HTML. W3C recommends declaring the document language on the HTML element and marking language changes within a page where appropriate. That technical setting should match the content being presented; it doesn't translate the content for you.

Second, review how translated pages can be found in search. Google recommends separate URLs for different language versions, with appropriate language-version annotations. A language toggle alone doesn't establish that every version is independently discoverable. Google also says it uses visible content to determine a page's language, rather than the HTML language attribute.

Those are related implementation checks, but they solve different problems. Neither replaces testing the actual form.

Start with the form customers use most

You don't have to review every page at once. Pick the quote request, booking flow, or contact form that matters most to your business. Walk through both languages on a phone, record where the experience changes unexpectedly, and fix those points first.

If you're also preparing a new app for customers, our business app launch checklist covers permissions, backups, and other checks beyond language. For help planning the website itself, explore our web and software services.