[建议 / Feature] Per-message RTL support for chat rendering — implementation brief for #273 (Electron dir="auto")

提交前确认 · Pre-submission checklist

• 我已搜索过现有 issue，确认这不是重复提议 / I searched existing issues and confirmed this isn't a duplicate.
• 我已阅读 CONTRIBUTING.md / I've read CONTRIBUTING.md.

问题类别 · Category

UI / 界面体验 · UI / UX

涉及的 Agent 框架 · Agent framework

ZCode Agent（自研）

使用场景 · Use case

This builds directly on #273 (open, P2, awaiting evaluation since Aug 15) — not a duplicate. #99 reported the same problem as a bug and was closed as its duplicate, so everything bidi-related funnels into that thread.

What's missing there is the implementation detail and daily-usage evidence. This issue adds both, to help move it from 待评估 → 已采纳.

Who's asking: daily ZCode desktop user writing in Arabic, and Z.ai community ambassador. Arabic/Persian users report this issue to me directly and repeatedly.

What breaks

Every message mixing Arabic with English identifiers renders incorrectly.

Real examples, each one a single chat message exactly as typed:

• هذا المتغير userName يخزن اسم المستخدم الحالي
• أصلح الدالة fetchData في ملف NetworkService.kt
• الخطأ يحدث في السطر 42 عند استدعاء setupUi()
• غيّر قيمة timeout من 2000 إلى 5000 في ملف config.json
• استخدم Room بدلاً من SQLite لحفظ favorites

With a fixed LTR base direction, each line breaks differently:

• English tokens drift to the wrong side of the sentence.
• Arabic segments around them can swap order.
• Parentheses can flip or render incorrectly, for example setupUi() may appear visually reordered.
• Numeric ranges such as من 2000 إلى 5000 can display in the wrong order.

Note: GitHub renders these examples in an LTR context too, so some of the problem may already be visible here. The same issue occurs inside the ZCode chat UI.

Root cause

Messages appear to render with a fixed LTR base direction.

The Unicode Bidirectional Algorithm (UAX #9) then resolves mixed RTL/LTR text against the wrong paragraph direction.

This is not a font issue and not a locale-pack issue. The core problem is the paragraph direction used by the chat renderer.

Proposed fix

As noted in #273, ZCode runs on Electron, so Chromium's bidirectional text machinery is already available. The main requirement is to use it correctly:

1. dir="auto" on each message container

   • Let the direction be determined per message using the first-strong-character heuristic.
   • This should allow Arabic, Persian, Hebrew, and Urdu messages to render naturally while keeping English messages LTR.

2. Force dir="ltr" on code blocks and inline code

   • Code snippets should not be reordered inside an RTL paragraph.
   • Identifiers, file paths, function calls, numbers, and punctuation should remain in their intended code order.

3. dir="auto" on the chat input

   • Correct text alignment and caret behavior while typing Arabic/Persian/Hebrew/Urdu.

4. Alternative: unicode-bidi: plaintext

   • If the layout cannot change direction on a per-message basis, unicode-bidi: plaintext may provide an alternative approach for paragraph-level bidi handling.

Full UI mirroring and an Arabic locale can be treated as a later phase.

For now, points 1–3 are the important changes needed to make mixed RTL/LTR chat usable for Arabic, Persian, Hebrew, and Urdu users.

Triage context

Since #273 was opened, v3.10.1 (Aug 28) and v3.10.2 (Aug 31) have shipped, including fine-grained text-rendering fixes down to single-tilde strikethrough, while text-direction handling still appears unresolved.

GLM itself handles Arabic very well, so the model is not the bottleneck here — the chat UI rendering is.

This is a relatively contained Electron/Chromium rendering issue that affects an entire language family rather than a single isolated edge case.

I'm happy to provide additional examples, test a build, or verify the behavior with Arabic/Persian/RTL mixed-content messages.

Moving this from 待评估 to 已采纳 would make a meaningful difference to a whole language family of users

建议方案 · Proposal

The chat renderer should support bidirectional text on a per-message basis instead of using a fixed LTR direction.

Recommended implementation:

1. Apply dir="auto" to each chat message container so the paragraph direction is determined automatically from the first strong character.

2. Force dir="ltr" on code blocks and inline code so function names, variables, file paths, numbers, punctuation, and other code elements always remain in their intended order.

3. Apply dir="auto" to the chat input so Arabic/Persian/Hebrew/Urdu text has correct alignment and caret behavior while typing.

4. If changing the DOM direction per message is not practical, consider CSS unicode-bidi: plaintext as an alternative for paragraph-level bidirectional text handling.

ZCode is Electron-based, so Chromium already provides the underlying Unicode bidirectional text support. This should therefore be primarily a chat-rendering/layout change rather than a model or language-support change.

The goal is not full Arabic UI localization or complete interface mirroring at this stage. The immediate goal is simply to make mixed RTL/LTR messages render correctly and consistently.

预期价值 · Expected value

No response

你认为的优先级 · Your perceived priority

No response

你使用的 ZCode 版本 / 环境 · ZCode version / environment

No response

补充材料 · Additional context

No response

Start by locating the Electron chat renderer, per-message containers, code blocks, inline code, and chat input. Verify mixed Arabic or other RTL/LTR messages against the examples in the issue; done means message direction and input behavior follow the requested per-message handling while code remains in LTR order.