RTL text is currently unusable in the desktop client. Hebrew and Arabic render with punctuation, brackets and numbers on the wrong edge of every line.
Steps to reproduce
- Send a message containing Hebrew or Arabic text ending in a period, parentheses or quotes.
- Observe the trailing punctuation renders at the wrong edge of the line.
- Same in the composer while typing.
Environment: Buzz 0.5.3, macOS (Apple Silicon). Also reproduced in a dev build at 28ae6cd.
Current

The sentence-final period sits at the start of line 1, the opening quote is on the wrong side, and the Arabic closing paren has jumped to the left edge.
With the fix below

The English line is unchanged.
Root cause
There is no bidi handling anywhere in the desktop client:
Every block therefore resolves at bidi paragraph level 0 (LTR), so neutral characters at a run boundary take the paragraph direction instead of the surrounding text's.
Proposed fix
One rule in markdown.css, scoped to .message-markdown:
.message-markdown p,
.message-markdown li,
.message-markdown blockquote,
.message-markdown h1,
.message-markdown h2,
.message-markdown h3,
.message-markdown h4,
.message-markdown h5,
.message-markdown h6,
.message-markdown td,
.message-markdown th {
unicode-bidi: plaintext;
}
unicode-bidi: plaintext resolves direction per block from the first strong character, which is the correct behaviour for a client carrying mixed LTR/RTL content. LTR-only messages are unaffected. Code blocks are deliberately excluded, so pre and code stay LTR.
This fixes reading and typing with the same rule. MESSAGE_MARKDOWN_CLASS is applied both to the rendered message wrapper (markdown.tsx#L1945) and to the TipTap editor root (useRichTextEditor.ts#L492).
Verification
Screenshots above are from the actual desktop app via just desktop-screenshot at 28ae6cd, with and without the rule, same message and same clip region. just desktop-check passes.
Happy to open a PR.
RTL text is currently unusable in the desktop client. Hebrew and Arabic render with punctuation, brackets and numbers on the wrong edge of every line.
Steps to reproduce
Environment: Buzz 0.5.3, macOS (Apple Silicon). Also reproduced in a dev build at
28ae6cd.Current
The sentence-final period sits at the start of line 1, the opening quote is on the wrong side, and the Arabic closing paren has jumped to the left edge.
With the fix below
The English line is unchanged.
Root cause
There is no bidi handling anywhere in the desktop client:
desktop/index.html#L2is<html lang="en">with nodirdir="auto"appears 0 times in the repositorymarkdown.csssets no direction on any elementmarkdown.tsx#L1615renders a bare<p>Every block therefore resolves at bidi paragraph level 0 (LTR), so neutral characters at a run boundary take the paragraph direction instead of the surrounding text's.
Proposed fix
One rule in
markdown.css, scoped to.message-markdown:unicode-bidi: plaintextresolves direction per block from the first strong character, which is the correct behaviour for a client carrying mixed LTR/RTL content. LTR-only messages are unaffected. Code blocks are deliberately excluded, sopreandcodestay LTR.This fixes reading and typing with the same rule.
MESSAGE_MARKDOWN_CLASSis applied both to the rendered message wrapper (markdown.tsx#L1945) and to the TipTap editor root (useRichTextEditor.ts#L492).Verification
Screenshots above are from the actual desktop app via
just desktop-screenshotat28ae6cd, with and without the rule, same message and same clip region.just desktop-checkpasses.Happy to open a PR.