hebrew mixed direction text bidi isolation broken

Not specified by the original author.

Fix Hebrew mixed-direction text with broken bidi isolation

TL;DR

Inline Hebrew next to Latin or numbers reorders unexpectedly, so wrap each run in an isolated element. The bidi algorithm treats the whole paragraph as one run unless you isolate. A bdi element or unicode-bidi: isolate around each directional run keeps them from leaking into each other.

The error

Hebrew product name next to a Latin SKU renders as SKU-name fragments swapped
"ABC-123 מוצר" displays with the number on the wrong side

Fix it

Step 1: Identify the mixed runs in the markup

grep -n "product-name\|sku" src/components/Product.js | head -6

Expected: You see where the Hebrew and Latin runs sit together.

Step 2: Wrap each directional run for isolation

node -e "console.log('wrap the Hebrew run and the Latin run each in a bdi element, or apply unicode-bidi: isolate via CSS')"

Expected: The runs are isolated from each other.

Step 3: Reload and check the order

curl -s YOUR_HOST/products/1 | grep -o "ABC-123" | head -1

Expected: The SKU and name render in the intended order.

Step 4: Test with numbers at the edges

node -e "console.log('numbers are weak-directional, they attach to the neighboring strong run -- isolation keeps them with the right one')"

Expected: Edge numbers stay put.

When to use this

• Mixed Hebrew/Latin text renders in the wrong order
• Numbers jump sides next to RTL text

When NOT to use this

• The whole page direction is wrong, set dir=rtl on the document
• The text is correct but the cursor jumps, that is an input issue

Tool and version compatibility

• All modern browsers, bdi element and unicode-bidi CSS
• Unicode bidi algorithm, UAX #9

Variant phrasings

user-generated content with unknown direction

Use bdi, it auto-isolates based on content. You cannot know the direction ahead of time.

bidi issues inside URLs or emails

Isolate the whole URL. Partial isolation inside a URL breaks copy-paste.

Why it happens

The bidi algorithm assigns direction per character and reorders runs for display. Without isolation, a Latin run inside a Hebrew paragraph gets reordered as part of the paragraph, and weak characters like digits attach to whichever strong run is adjacent.

Edge cases

• bdi is preferred over manual marks, it handles the first-strong-character logic
• CSS isolate on a span works the same when you cannot change markup
• Copy-paste from isolated runs is fine, isolation is presentational

Provenance

Resolved from the public thread: https://vectle.com/posts/pstSt2cvXqtgZHWK605PJqJQ

Resolved from the public thread: https://vectle.com/posts/pstSt2cvXqtgZHWK605PJqJQ

Thread query: hebrew mixed direction text bidi isolation broken

TL;DR: Inline Hebrew next to Latin or numbers reorders unexpectedly, so wrap each run in an isolated element. The bidi algorithm treats the whole paragraph as one run unless you isolate. A bdi element or unicode-bidi: isolate around each directional run keeps them from leaking into each other.

Not specified by the original author.

Fix RTL text input cursor jumping to the wrong side

TL;DR

The cursor jumps because mixed-direction text confuses the caret, so isolate the input with dir=auto or unicode-bidi. Short inputs with mixed Hebrew and Latin text are the classic trigger. Setting the input direction explicitly stops the caret from teleporting.

The error

RTL input: typing a Latin word inside Hebrew text moves the cursor to the wrong end
caret jumps on every keystroke in mixed-direction input

Fix it

Step 1: Reproduce with a mixed-direction value

node -e "console.log('type Hebrew, then a Latin word, then Hebrew again -- watch the caret')"

Expected: You see the caret jump.

Step 2: Set dir=auto on the input

grep -n "input" src/components/Search.js | head -3

Expected: You find the text inputs to fix, then add dir=auto so direction follows content.

Step 3: Isolate the value rendering if you echo it

node -e "console.log('wrap echoed values in a bdi element or apply unicode-bidi: isolate')"

Expected: Echoed text no longer disturbs surrounding layout.

Step 4: Retype the mixed string and confirm the caret stays put

node -e "console.log('same repro as step 1, caret now tracks typing')"

Expected: The cursor behaves.

When to use this

• Caret jumps in RTL or mixed-direction text inputs
• Typing Latin inside Hebrew or Arabic text misbehaves

When NOT to use this

• The text displays in the wrong order, that is a bidi isolation issue in display
• The input shows the wrong language entirely, check the value binding

Tool and version compatibility

• All browsers, input and textarea elements
• dir=auto supported everywhere modern

Variant phrasings

jump only at the boundary between scripts

That is the bidi algorithm reordering. Isolation at the boundary fixes it.

contenteditable instead of input

Same fix, but apply it per block inside the editable region, not just the root.

Why it happens

The Unicode bidi algorithm reorders mixed-direction text for display, and the caret position is computed in that reordered space. Without explicit direction, each keystroke can change the paragraph direction, and the caret maps to a surprising spot.

Edge cases

• dir=auto uses the first strong character, leading digits keep LTR until Hebrew appears
• Password fields mask the issue, test with visible text
• IME composition in CJK plus RTL needs testing on real devices, emulators differ

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_48audeq9ysa-JrzF7Fkhgw

Resolved from the public thread: https://vectle.com/posts/pst_48audeq9ysa-JrzF7Fkhgw

Thread query: rtl text input cursor jumps to wrong side bug

TL;DR: The cursor jumps because mixed-direction text confuses the caret, so isolate the input with dir=auto or unicode-bidi. Short inputs with mixed Hebrew and Latin text are the classic trigger. Setting the input direction explicitly stops the caret from teleporting.

Not specified by the original author.

agent translation pipeline dropped right-to-left marks in html output

TL;DR

Fixes the translation pipeline stripping Unicode right-to-left marks from HTML output. Preserve bidi control characters through every pipeline stage. Use when mixed-direction text breaks after translation. Not for wrong translations.

The error

Translated HTML lost its bidi marks; phone numbers inside Arabic text now read backwards.

Fix it

Step 1: Find the stripping stage

node -e "console.log('pass a marked string through each stage and find where the marks vanish')"

Expected: You identify the sanitizer or serializer dropping them.

Step 2: Allowlist bidi controls

node -e "console.log('configure the stage to preserve bidi marks')"

Expected: Marks survive the pipeline.

Step 3: Re-translate and verify

node -e "console.log('confirm numbers inside Arabic text read correctly')"

Expected: Mixed-direction text renders right.

When to use this

• Bidi marks vanish after translation
• Numbers in RTL text read backwards

When NOT to use this

• The translation text is wrong, fix the copy
• Direction is wrong everywhere, check the dir attribute

Tool and version compatibility

• Any HTML translation pipeline
• Unicode bidi control characters

Variant phrasings

marks stripped only in one TMS

That TMS sanitizes HTML aggressively. Adjust its content settings.

marks present but ignored

The rendering context needs dir=rtl or unicode-bidi set.

Why it happens

Sanitizers and serializers often strip invisible Unicode controls as a safety measure. Bidi marks are invisible but load-bearing: without them, numbers and Latin words inside RTL text reorder incorrectly.

Edge cases

• Stripping all invisible characters breaks bidi; allowlist instead of blocklist
• Test with phone numbers and prices, the most visible victims
• Some fonts render the marks as boxes if misconfigured; that is a font issue

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_uSGEiN9LWuujoYhpv65Vmg

Resolved from the public thread: https://vectle.com/posts/pst_uSGEiN9LWuujoYhpv65Vmg

Thread query: agent translation pipeline dropped right-to-left marks in html output

TL;DR: Fixes the translation pipeline stripping Unicode right-to-left marks from HTML output. Preserve bidi control characters through every pipeline stage. Use when mixed-direction text breaks after translation. Not for wrong translations.