Arabic or Hebrew Customer Names in an English Portal: Keep Text Direction Local
An English customer portal can receive names, product titles and messages written in right-to-left scripts. You do not need to translate the whole portal to display those values correctly. You do need to keep each inserted phrase's direction from interfering with the surrounding label, punctuation or count.
Specify this as a data-display requirement, not a cosmetic request to align everything on the right. A customer name, a following order count and an adjacent reference are separate pieces of information even when the browser displays them on the same line.
The problem is the boundary around the value
Imagine an English account list containing an Arabic business name followed by a number of open requests. The name may contain a Latin abbreviation as well. Without suitable directional treatment, punctuation and neighbouring numbers can appear in a confusing relationship to the name.
The W3C Internationalization article on inline bidirectional text explains that opposite-direction phrases can cause problems when they begin or end with neutral characters, begin with a number, are followed by a number or sit beside another separate opposite-direction phrase. It also covers nested changes of direction.
This is not evidence that every Arabic word will render incorrectly without extra markup. The same guide says some cases work without intervention. Its recommended wrapping approach avoids having to guess which future edited value will expose a problem.
Ask the developer to treat each inserted value as its own phrase. Do not wrap an entire row as though a name, its English status and its request count all belonged to the same directional passage.
Language and direction are different decisions
A language marker can help software identify the language of a phrase. It does not replace the explicit direction treatment described in the W3C guide. Conversely, identifying a right-to-left phrase does not decide its language, pronunciation or translation.
Keep the portal's interface language separate from the customer-provided content. An English label can remain English while its value uses Arabic or Hebrew script. Do not change a person's name into Latin letters merely to make the row look easier to build.
Alignment is separate again. Moving text to the right edge of a cell does not by itself establish how the characters, punctuation and embedded abbreviations are ordered. Require a correct readable value, not just a tidy-looking column.
Known direction and unknown direction need suitable markup
W3C recommends tightly wrapping a known opposite-direction phrase and setting its direction on that wrapper. “Tightly” means the whole phrase and nothing outside it. Nested phrases may need their own directional treatment.
For text inserted at runtime whose direction is not known in advance, the guide describes using dir="auto" on an existing tight wrapper, or a bdi element where a wrapper is needed. It explains that automatic direction uses the first strong character and isolates the phrase from its surroundings.
These are implementation approaches to discuss with the developer, not instructions for customers to insert HTML into a name field. Customer text should remain text. The application owns its surrounding markup and must continue to handle untrusted input appropriately.
Do not substitute a forced directional override for ordinary isolation. W3C distinguishes bdo from bdi and says the override element is for special cases, mostly educational, rather than normal bidirectional text management.
Preserve the underlying name and reference
My commissioning recommendation is to keep the entered value intact instead of reversing its stored characters until one screen looks right. A visual rearrangement is not a corrected database record. Other screens, searches and exports may reveal the damage.
Also avoid adding invisible directional characters indiscriminately to every stored value. The W3C article prefers markup where it is available because its boundaries are visible and easier to manage. It discusses Unicode controls for contexts where inline markup cannot be used, such as a page title or attribute value. Those contexts need a separate deliberate implementation decision.
Specify what happens when someone copies a displayed name or reference. The pasted value should match the agreed underlying text, not include the adjacent label or request count. Test the actual destination that staff use. A web-page isolation technique is not proof of correct rendering in every email client, PDF or spreadsheet.
Accept mixed rows, not isolated words
Use synthetic data in the acceptance criteria. Include an Arabic name, a Hebrew name, a Latin name and a mixed-script name. Place them in realistic rows with punctuation, a reference and a separate count.
Check the full phrase boundaries, including a value beside another independently directed value. Try an empty value and an ordinary Latin-only row as well. The change must not make the portal's existing labels or counts read backwards.
Ask a reader familiar with the relevant script to confirm the intended reading and inspect the markup separately. Compare the displayed value with what is stored and what the agreed Copy action produces. Test the supported browsers and any separately scoped document output rather than assuming one screenshot proves all surfaces.
Bring a few representative data examples to a customer-portal project discussion. The goal is accurate mixed-script records within the existing interface, not an unrequested language rollout or a promise of universal rendering.
Source scope
The W3C Internationalization guidance, read on 26 October 2026, supports inline isolation, known and automatic direction, nested phrases, markup preference and the distinction from overrides. Storage preservation, copy checks, script-reader review and acceptance examples are commissioning recommendations. This article does not claim a browser test, independent language certification or a completed multilingual portal.