[BUG] RTL: list markers, digits and the Code-mode composer still render LTR — 94% of the CSS bundle uses physical instead of logical properties

Status Open

Maintainer reply None cached

Activity 0 comments · opened Aug 4, 2026

Summary

Recent releases added RTL support across most of the Claude Desktop UI, and that work is genuinely appreciated — mixed-direction chat is far better than it was. Three things are still wrong, and they share one cause: the stylesheet is built almost entirely on physical CSS properties (padding-left, margin-left, text-align: left) instead of logical ones (padding-inline-start, margin-inline-start, text-align: start). Physical properties do not flip under direction: rtl, so any element positioned by them stays pinned to the left even inside a correctly-RTL container.

This is a follow-up to #38005 with measurements from the shipped bundle, not another "please add RTL support" request — most of it is already there.

Environment

| Item | Value |
|---|---|
| OS | Windows 11 Pro 10.0.26200 |
| App | Claude Desktop (MSIX / Microsoft Store) |
| Version | 1.25927.0.0 |
| Language | Hebrew (he) |

---

Evidence from the shipped stylesheet

Counted in the main bundle app\resources\ion-dist\assets\v1\c6a992d55-CpfKNmLE.css (1.6 MB) of version 1.25927.0.0:

| Property | Occurrences |
|---|---|
| padding-left (physical) | 211 |
| padding-inline-start (logical) | 13 |
| margin-left (physical) | 168 |
| margin-inline-start (logical) | 26 |
| text-align: left (physical) | 11 |
| text-align: start (logical) | 3 |

~94% of horizontal padding and ~87% of horizontal margin is direction-blind.

Worth saying: the bidi work that was done is correct, and shows the team already knows the right approach. unicode-bidi: isolate is applied to code, pre, del and ins:

.[&_code]:[unicode-bidi:isolate] code { unicode-bidi: isolate }
.[&_pre]:[unicode-bidi:isolate]  pre  { unicode-bidi: isolate }
.[&_del]:[unicode-bidi:isolate]  del  { unicode-bidi: isolate }
.[&_ins]:[unicode-bidi:isolate]  ins  { unicode-bidi: isolate }

unicode-bidi: plaintext also exists in the bundle as a utility class — but it is not applied to p or li, which is exactly where it's needed. The tool is already in the box; it just isn't wired to the markdown renderer's block elements.

---

Bug 1 — list items (`<li>`) render LTR

In a Hebrew response, both bulleted and numbered lists keep their marker on the left and the text runs LTR, even though the surrounding message block is correctly RTL. Numbered lists are the most visible: the digit and its separator sit on the wrong side, and a Hebrew line beginning with a digit gets that digit pushed to the far end of the line.

Cause: the list marker box is positioned by padding-left / margin-left on ul/ol/li, and li gets no unicode-bidi treatment, so paragraph direction is never resolved per item.

Suggested fix:

.message-content ul,
.message-content ol { padding-inline-start: 1.5em; padding-left: unset; }

.message-content p,
.message-content li,
.message-content blockquote { unicode-bidi: plaintext; }

unicode-bidi: plaintext resolves direction per paragraph from its first strong character. That is the correct behaviour for mixed-language chat content and requires no language detection.

Bug 2 — digits and inline LTR runs inside Hebrew sentences

Numbers, version strings, file paths and English identifiers inside a Hebrew sentence come out in the wrong order — a sentence containing Next.js 15.2 or src/utils/foo.ts shows the segment misplaced relative to the Hebrew around it, and sentence-final punctuation lands on the wrong side.

Cause: no bidi isolation around inline LTR runs. The Unicode Bidirectional Algorithm can't infer intent without either isolation characters or CSS isolation.

Suggested fix: the same unicode-bidi: plaintext on block containers, plus wrapping bare LTR runs in <bdi> (or U+2066 LRI … U+2069 PDI) when the markdown renderer emits them. Inline <code> is already correctly isolated and needs no change.

Bug 3 — the user input box is left-aligned in Code mode

This one reads as a regression. In Code mode (not Home), the composer/input field is aligned to the left even when the user is typing Hebrew. Home mode does the right thing, so the two composers evidently don't share styling.

Suggested fix:

.composer-input { text-align: start; }

plus dir="auto" on the element so the caret and first typed character resolve correctly:

<textarea dir="auto" …>

Note that dir="auto" on an empty input falls back to page direction, so pairing it with text-align: start is what makes an empty composer behave for an RTL user.

---

Why this is worth doing properly

unicode-bidi: plaintext + dir="auto" + logical properties is roughly a one-file change. It fixes Hebrew, Arabic, Persian and Urdu at once (~520M speakers), needs no language detection, doesn't affect LTR rendering, and doesn't regress code blocks — which are already correctly isolated.

---

Prior RTL reports

#38005 — RTL support for Hebrew & Arabic in Claude Desktop / Cowork (open, area:a11y, also labelled duplicate)
#38708 — BiDi rendering: mixed Hebrew + English in wrong order (closed as duplicate)
#30984 — Hebrew (RTL) text displayed as LTR in Claude Code UI (closed as not planned, stale)
#49521 — RTL/Hebrew alignment issues in Claude Desktop (closed as not planned, invalid + stale)
#75240 — Hebrew/Arabic renders reversed in Claude Desktop on macOS
#72580 — RTL support in Claude Code web interface (open, stale)

Several of these were closed as invalid on the grounds that they aren't Claude Code issues. They are Claude Desktop issues. If this repo isn't the right tracker for the desktop app, could you point to where desktop RTL bugs should go? Right now they're being closed with nowhere to be refiled, which is why the same report keeps reappearing under new numbers.

View original on GitHub ↗