You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Chat messages with mixed Arabic and Latin text render in the wrong order
#11248
Environment
DeepSeek Harness desktop 0.2.1-rc.3 (macOS, Apple Silicon), bundled Web UI, model deepseek-flash.
Summary
When a message paragraph starts with a Latin word, the paragraph is laid out left to right, and the Arabic runs inside it are placed in the wrong visual order. Numbers detach from the words they belong to, and the sentence reads backwards. The text is stored correctly; only the display is wrong. Paragraphs that start with an Arabic word are unaffected.
Steps to reproduce
Ask for an Arabic reply that starts a sentence with a Latin product name and mixes numbers in, for example the sentence below.
Read the reply in the chat window.
Sample sentence:
DeepSeek: النموذجان الحاليان deepseek-flash وdeepseek-v4-pro بنافذة 1M رمز، وأقصى إخراج 384K رمز. لا توجد دورة 5 ساعات ولا حصة أسبوعية.
Actual
The line starts at the left edge with "DeepSeek:" and the Arabic continues to the right. Read from right to left, the words come out in reverse order: "بنافذة 1M" loses its space, "384K" moves ahead of "رمز، وأقصى" and breaks apart, and "دورة 5 ساعات" appears as "5 دورة ساعات".
Expected
The same sentence with a right-to-left base direction: the Latin tokens stay in place inside the Arabic sentence, and each number stays with its word.
Why this looks like a base direction problem
The session transcript on disk holds the sentence in correct logical order, so the model output is not the cause.
The shipped frontend bundle sets no dir attribute on message content, and the app stylesheet contains no direction or unicode-bidi rules, only text-align:end.
Rendering the identical sentence in headless Chromium reproduces the same scramble with the default LTR base direction, and renders it correctly with dir="auto" and with dir="rtl".
Suggested fix
Set dir="auto" on the message block, or on the Markdown container, so the base direction follows the first strong character.
Add unicode-bidi: isolate to inline code and path spans so Latin tokens cannot reorder the surrounding Arabic.
Add a regression case: a paragraph that starts with a Latin word and mixes Arabic with digits.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Environment
DeepSeek Harness desktop 0.2.1-rc.3 (macOS, Apple Silicon), bundled Web UI, model deepseek-flash.
Summary
When a message paragraph starts with a Latin word, the paragraph is laid out left to right, and the Arabic runs inside it are placed in the wrong visual order. Numbers detach from the words they belong to, and the sentence reads backwards. The text is stored correctly; only the display is wrong. Paragraphs that start with an Arabic word are unaffected.
Steps to reproduce
Sample sentence:
DeepSeek: النموذجان الحاليان deepseek-flash وdeepseek-v4-pro بنافذة 1M رمز، وأقصى إخراج 384K رمز. لا توجد دورة 5 ساعات ولا حصة أسبوعية.
Actual
The line starts at the left edge with "DeepSeek:" and the Arabic continues to the right. Read from right to left, the words come out in reverse order: "بنافذة 1M" loses its space, "384K" moves ahead of "رمز، وأقصى" and breaks apart, and "دورة 5 ساعات" appears as "5 دورة ساعات".
Expected
The same sentence with a right-to-left base direction: the Latin tokens stay in place inside the Arabic sentence, and each number stays with its word.
Why this looks like a base direction problem
dirattribute on message content, and the app stylesheet contains nodirectionorunicode-bidirules, onlytext-align:end.dir="auto"and withdir="rtl".Suggested fix
dir="auto"on the message block, or on the Markdown container, so the base direction follows the first strong character.unicode-bidi: isolateto inline code and path spans so Latin tokens cannot reorder the surrounding Arabic.All reactions