[Feature & Fix] - Universal RTL Support for Hebrew, Arabic & Right-to-Left Languages (Ready Patch & Installer) ❤️

[AlonDan]

Hi everyone,

I am not a programmer, but I run DeepSeek Harness locally and needed a proper solution for Right-to-Left (RTL) language rendering in the Web GUI. Currently, when typing or reading text in languages like Hebrew, Arabic, Persian, Urdu, and other RTL scripts, the text alignment and word order get broken (especially when mixing RTL text with English code or terminology).

Using the Qwen 3.8 27B model running directly inside DeepSeek Harness, I developed a clean, lightweight, and robust solution that adds dynamic dir="auto" language detection across the entire interface (chat composer, user bubbles, and assistant markdown responses).

To make it super easy for the community to use—and to survive future updates—I have packaged this fix into a ready-to-use Patch file and an automated Windows Batch installer.

---

📸 Visual Preview:

1. Input Box (RTL Auto-Direction):

2. Chat Bubbles & Assistant Response:

---

📦 What is included?

1. rtl-support.patch: A clean git patch containing all the necessary dir="auto" attributes across the client source files (using relative paths).
2. apply-rtl.bat: A smart interactive script for Windows that validates paths, checks for conflicts (dry-run), applies the patch, and automatically rebuilds the web interface.

---

🛠️ How to use (For Users):

1. Download the ZIP file below and extract its contents Apply-RTL.bat into your DeepSeek Harness root folder (where package.json lives).

2. Double-click Apply-RTL_v2.bat and press Enter.

3. Refresh your browser page once the build completes!

---

📥 Download Package:

📁 Apply-RTL_v3.zip

---

🙏 Request for Main Maintainers & Developers:

Please consider officially integrating dir="auto" into the core UI components in the next release. This simple native-level fix makes DeepSeek Harness fully accessible and friendly to millions of RTL language users worldwide, without breaking any LTR (English/European) behavior!

Hope this helps the community!

[haythamat]

Thanks for putting this together, and for shipping something rather than just filing a complaint. The screenshots make the problem concrete in a way a description doesn't.

I've been working on the same problem from the plugin side, and I want to flag one case dir="auto" doesn't cover — because it matters for the request to the maintainers at the end of your post.

dir="auto" resolves direction from the first strong character in the element. That works for most Hebrew and Arabic text, but it fails on a pattern that is very common in technical writing in both languages: a sentence opening with an English product name.

A real example from my testing:

Git هو مثل الآلة الكاتبة مع سجل زمني — تتيح لك تدوين وتتبع كل تغيير في مستندك.

The first strong character is G, so auto resolves the whole paragraph to LTR and every word after it is misordered. Same for a short prompt like
اشرح لي ال Agentic AI.

What worked instead was resolving by script dominance — but counted in words, not characters. That distinction turned out to matter: اشرح لي ال Agentic AI is 8 Arabic characters against 9 Latin ones, so a character-count heuristic marks it LTR, wrongly. By words it is 3 against 2 and resolves correctly. RTL words are short; Latin technical terms are long.

Two other things worth handling:

• code, pre, kbd and form controls need excluding — flipping a code block or an ASCII diagram destroys it.
• Tables and lists need dir on the container, not the cells, or columns and list markers don't reorder.

So I'd suggest refining the ask slightly: rather than dir="auto" in the core components, resolve direction by script dominance. auto is a real improvement over the status quo, but it would leave mixed-direction sentences broken while looking solved — which is harder to revisit later than leaving it visibly broken now.

I've implemented this as a client plugin rather than a source patch, so it installs in one line, survives upgrades, and needs no rebuild:

dsh plugin --profile web add github:haythamat/dsh-client-ui-rtl

https://github.com/haythamat/dsh-client-ui-rtl — MIT, and happy for any of it to be folded into whatever the maintainers prefer. The goal is the fix landing, not whose fix it is.

[AlonDan]

Thanks for sharing🙏
I didn't try making mine as a plugin because it has lots of issues so I went for the core patch, but PLUGIN sure sounds like a much cleaner and user-friendly solution.
I didn't try your solution yet because mine just works nice (latest update in the main post) 👆
But I may look into it if I'll ran into some weird RTL cases, so far I'm happy with my patch.

[Saidoua]

Your thread is a large part of why I wrote this up, so thank you for it — the request was clear and the visual before/after made the problem obvious.

I built the same dir="auto" idea directly into the client components, together with an Arabic language pack (34 dictionaries, about 1060 keys), so there is nothing to re-apply after an update. Write-up: #5804 — code: packages/client/locale-ar and the one alignment rule.

Two differences from the patch that may matter to you as a user:

• Alignment comes from one theme rule keyed off the active language, not an attribute on each element, so components stay direction-agnostic.
• Code blocks, terminal output, diffs, and JSON trees are pinned dir="ltr", so a shell transcript or a diff does not right-align under Hebrew or Arabic — column order there carries meaning.

The application frame deliberately does not mirror: the sidebar, panels, and toolbars keep their positions, and only text inside content zones moves to the reading edge.

Nothing is merged upstream yet — this runs on a fork branch. If the maintainers pick it up, your dir="auto" request lands in the core the way you asked.