Multilingual UX: adapting interfaces to users
A multilingual interface should let people complete the same task in each language: find an offer, understand a price, submit a form or track an order. Translating paragraphs is insufficient if buttons, errors and confirmations stay in another language, or changing language loses the user's journey.
For a Swiss website in French and English, prepare both journeys and test them on actual screens. This guide provides FR/EN examples and an acceptance checklist. The examples are fictional and report no client outcomes.
Distinguish translation, localisation and technical preparation
Translation adapts text. Localisation also adapts formats and information relevant to the intended audience. Internationalisation prepares the product to accommodate these variations without rebuilding its operation for each language. W3C definitions.
Ask practical questions: who reads the English version, in which countries, with which currencies and contact methods? A language does not identify a country. An English-speaking visitor may live in Geneva and a French-speaking visitor may order from abroad.
Do not infer navigation preferences from national stereotypes. Examine enquiries, observed journeys and tests with the people concerned. Record assumptions that still need checking.
Provide an understandable language choice
Show language names in their own language, such as “Français” and “English”. A flag represents a country and leaves the language ambiguous. Keep the selector accessible on mobile, by keyboard and with assistive technologies.
Where an equivalent version exists, switching language should open that page. Someone reading about a service should not have to find it again from the homepage. If a translation is missing, explain this and offer an explicit route rather than suggesting it exists.
For forms, decide what can be retained when changing language. Avoid losing entered information without warning. Retention requires technical and data-protection decisions; do not promise it before testing it.
Test text within the layout
A translated label may be longer, shorter or need different line breaks. A uniform 30% allowance does not replace testing actual text. W3C explains why variation depends on factors including string length and languages. Translated text size.
Check buttons, menus, tabs, cards, filters, tables and confirmation dialogs. Text should wrap without obscuring an action or changing its meaning. Also test long numbers, compound names and error messages.
Fictional example: an enquiry button
A mock-up displays “Get a quote” in a narrow button. Its French version, “Demander un devis”, overflows. Providing more space, allowing a suitable line break or revising the component is preferable to removing part of the message simply to fit it.
“Envoyer” / “Send” works on a form if the context explains what will be sent. A confirmation such as “Votre demande a été envoyée” / “Your enquiry has been sent” then explains what happened. Include a response-time promise only if the team can meet it.
Translate the whole journey, including errors
Inventory labels, help text, validation messages, empty states, confirmations, emails and linked documents. Review text generated by external tools too: booking, payment, search and CRM systems may have their own language settings.
A field should not require an unspecified format. “Date souhaitée” / “Preferred date” can include an explicit example; test what the component accepts and how it redisplays the date. For international phone numbers, avoid rejecting a valid number solely because it does not use a Swiss format.
Errors should explain the problem and correction in the active language. “Saisissez une adresse e-mail valide” / “Enter a valid email address” is more helpful than an isolated error code. Place information near the field and check accessibility.
Make formats explicit
“03/10/2026” can be interpreted differently depending on habits. In a document, “3 octobre 2026” / “3 October 2026” makes the example clear. For an input interface, select an explicit format and verify its presentation in both languages.
Display the currency with the price, such as CHF, and state conditions affecting the decision: VAT, delivery, billing frequency or renewal, depending on the offer. Do not change these conditions during translation. Monthly and annual prices do not become equivalent because their labels are short.
For bookings, state the time zone where audiences may be elsewhere. Test names and addresses containing accents, apostrophes and characters used by your customers. Use appropriate formatting components and check their actual output.
Declare language for reading tools
The HTML lang attribute identifies the content language and helps reading tools select suitable pronunciation. Declare the page language and relevant language changes within its content. WCAG 3.1.2 includes exceptions, notably proper names, technical terms and some borrowed words that have become part of everyday language. W3C language declarations.
This differs from hreflang, which relates language versions for search engines. It replaces neither translated messages nor screen-reader testing. Our hreflang and canonical guide addresses SEO annotations; our web accessibility guide addresses other journey checks.
Use an FR/EN acceptance checklist
This checklist is an EWM project tool, not a certification. Record the result of each check, a screenshot where helpful and the person who will verify the correction.
Navigation
Criterion to check in both languages — Labels are understandable and links open the correct content.
Language switching
Criterion to check in both languages — The equivalent page opens; missing translations are explained.
Layout
Criterion to check in both languages — Text, buttons and errors remain readable on mobile and with enlargement.
Form
Criterion to check in both languages — Labels, formats, validation and confirmation are consistent and accessible.
Conditions
Criterion to check in both languages — Prices, currencies, timelines and offer scope carry the same meaning.
External tools
Criterion to check in both languages — Payment, booking and related messages follow the intended language.
Assisted reading
Criterion to check in both languages — Declared language and announcements make the task understandable.
Then test a concrete task: find a service, compare a condition and submit an enquiry, for example. Observe hesitation and backtracking. Ask what the person thinks they submitted and what they expect next. These answers can reveal ambiguity that proofreading misses.
Maintain both versions after launch
Assign responsibility for copy and business validation. When a service, price or condition changes, also track related buttons, forms and documents. Publishing one version without updating the other can create differences in the offer visitors understand.
Retain approved terms and message context for translators. Avoid assembling sentences from fragments that force the same word order everywhere. Test variations and plurals using the values actually displayed.
For your UI/UX design project, bring your languages, priority journeys and existing text. We can help design the components and checks visitors need to complete their task in each version.