Define what changes when the language changes
A Hebrew interface may contain an English company name, a request code, a date and a note in either language. Translating the buttons does not settle how those values behave. A useful brief separates three decisions: the language of the interface, the direction in which content is displayed, and the meaning of the saved information.
For a hypothetical service platform, imagine an operator opening request SR-0042 for a customer whose name is stored in Hebrew. The request includes an English product name, a visit date of 4 November 2026 and a note written in Hebrew. A colleague using the English interface must find and continue that same request. Switching language should not translate the customer’s saved name, alter the request code or change the appointment.
Agree what happens to unsaved work during a language switch: preserve it, or clearly ask the operator to save or discard it before leaving. Define this behavior for filters and the current record too. These are product requirements to demonstrate, not features to assume from the presence of a language menu.
Keep mixed-language values intact
A code such as SR-0042 is an identifier, not a quantity. Keep its leading zeroes, hyphen and character order through typing, saving, copying and export. Treat phone numbers, email addresses and reference codes according to their own formats, even when the surrounding form is Hebrew.
W3C’s guidance on inline bidirectional text recommends isolating an opposite-direction phrase from its surroundings. For known-direction content, the implementation can set that direction explicitly; for unknown user-supplied content, HTML provides the bdi element and dir="auto". Automatic direction uses the first strong directional character, so mixed-language names still need representative testing.
Ask the team to try a Hebrew customer name followed by an English product name, a code next to parentheses and a note beginning with a number. Check the punctuation as well as the letters. Correct UTF-8 encoding supports multilingual characters, as W3C’s form guidance explains, but encoding alone does not solve their visual ordering. Never repair a display problem by reversing the stored text or adding spaces inside a code.
Mirror the layout with a purpose
W3C distinguishes the page’s language declaration from its text direction. A Hebrew page needs an appropriate right-to-left base direction; declaring its language alone does not supply that. Logical layout properties such as start and end help spacing and alignment follow the selected direction.
Review each component’s meaning before mirroring it. A navigation control that means “back” needs to make sense in its surrounding interface. A product photograph, an identifier and a symbol with a fixed real-world meaning need their own decisions. Treating every visual element as a reflection can create new errors.
For the request table, choose an order that makes the identifier, customer, visit date, status and next action easy to scan in each language. Keep each heading attached to the correct value when columns move or the mobile layout changes. Test a long name and a narrow screen; a tidy table of short demonstration labels is weak evidence.
Make dates, amounts and statuses unambiguous
The date 04/11/2026 can be interpreted differently by different readers. In the hypothetical request, the intended date is 4 November 2026. Define an unambiguous display or provide an explicit input-format cue, then test what is actually saved. Choosing English should not silently select a different date convention, currency or time zone; agree those settings separately.
A visit day and an event timestamp also represent different things. Ask what should remain fixed if someone views the request from another time zone. For amounts, preserve the currency and sign together with the value. The useful acceptance question is whether both operators understand the same appointment or amount, not whether both screens look equally neat.
Give workflow states the same operational meaning in both languages. “Request received” must not become “Request approved” in translation. Specify who acts next and which action is available in each state. Review error messages and empty results as carefully as headings, because those are the moments when an operator needs help deciding what to do.
Run one complete workflow before approving the release
| Step | What to try | Evidence to keep |
|---|---|---|
| Enter and save | Create SR-0042 with mixed-language names, the agreed visit date and a Hebrew note. | Reopened fields retain the exact code, original text and intended date. |
| Find and filter | Find the request by its code and stored customer name in both interfaces. | Both searches reach the same record; date/status filters keep their agreed meaning. |
| Correct an error | Leave a required field empty, then correct it using the keyboard. | The message identifies the field; focus and the next action remain understandable. |
| Switch language | Change language while viewing the record and while editing a draft. | The same record remains in context; draft handling matches the agreed rule. |
| Hand over | Have an English-interface colleague continue the Hebrew operator’s request. | The colleague can identify its owner, status and next action without re-entering data. |
| Copy and export | Copy the code and export the request in the supported output format. | The identifier and text survive; dates, currency and headings retain their intended meaning. |
Ask for evidence from people doing the work
Run the walkthrough with users who work in each language, using permitted examples that resemble the real records. Search deserves an explicit agreement: exact saved names and codes are one requirement; transliteration, spelling variants and cross-language matching are separate capabilities. Do not assume a translated interface will find an English spelling of a Hebrew name.
Include the supported desktop and mobile sizes, keyboard use, and the assistive technologies relevant to your users. W3C’s focus-order guidance asks for an order that preserves meaning and operation; mirroring the screen does not establish that the focus sequence is usable. A bilingual walkthrough is useful evidence, but it does not establish full accessibility conformance.
Before acceptance, retain the test records, expected outcomes, observed defects and the person responsible for each fix. Resolve wrong-record selection, changed values and blocked actions before release. The result should be one shared workflow that people can operate confidently in their chosen language, with any remaining limitations stated clearly.
Sources and further reading
Make your bilingual workflow clear.
Bring one task, the languages your team uses and examples of mixed-language records. We can help define the product experience and the checks it needs.
Discuss your product workflow
