← 返回列表
未验证
让阿拉伯语等从右到左内容正确排版显示
尚未跑自动兼容性验证,可查看页面内的依赖与入口分析。 · 最近上游提交 2026/8/28 · 已提供中文文档
DeepSeek Harness Web 客户端的从右到左文本方向
综合分
28.8
GitHub 分
28.8
用户评分
—
★ Stars
1
周下载量
—
安装插件(需先安装 dsh CLI 引擎:npm install -g @deepseek-ai/dsh)
dsh plugin --profile web add haythamat/dsh-client-ui-rtl该插件未发布到 npm,走 GitHub 源安装(pnpm 若拦截 prepare 脚本,按其提示在 pnpm-workspace.yaml 的 allowBuilds 中放行后重跑)
数据截至 2026/9/16(元数据每日更新 · 实装验证按队列轮转,单条结论的验证时间见上方)
用户评分
还没有人投票,来当第一个
订阅周报,不错过优质插件更新
每周一封 · 高评分插件 + 新用户活动
README
dsh-client-ui-rtl DeepSeek Harness Web 客户端的从右到左文本方向支持。 该客户端默认从左到右渲染。因此,阿拉伯语、希伯来语、波斯语、乌尔都语以及 其他从右到左的内容作为文本传入时是正确的,但在屏幕上显示却是错误的: 项目符号位于左侧,表格列方向相反,任何混合了拉丁字母和 RTL 单词的句子 都会违背其含义而被重新排序。 此包在渲染时标记从右到左的内容,其他内容则保持不变。 前后对比 一个混合了英文技术术语的阿拉伯语回答: | 之前 | 之后 | |---|---| | 阿拉伯语回答从左到右渲染,项目符号和表格错位 | 同一个回答从右到左渲染 | 一个以拉丁产品名开头的简短提示——这正是 dir="auto" 会出错的情况: | 之前 | 之后 | |---|---| | 阿拉伯语提示因以英文单词开头而被重新排序 | 同一个提示从右到左渲染 | 安装 dsh plugin --profile web add github:haythamat/dsh-client-ui-rtl 之后重启 dsh web。此包自带补丁层,因此无需编辑任何配置文件。 为什么不用 dir="auto" dir="auto" 根据元素中第一个强字符来确定方向。这对大多数希伯来语和 阿拉伯语文本有效,但对于这两种语言的技术写作中非常常见的一种模式却会失败: 以英文产品名开头的句子。第一个强字符是拉丁字母,整个段落便解析为从左到右, 其后的每个单词都被错误排序。 估算器约定 方向通过文字系统的主导性来估算。这是一个产品启发式规则,而非通用的方向 检测——在此明确说明,以便它可以被测试、版本化,并被提出异议。 - 单元——一个以空白分隔的标记。标点不会拆分标记,因此标识符、路径和 包名只计一次,而不是按段各计一次。 - 分类——包含任何从右到左字符的标记是 RTL 单词;否则,包含任何拉丁字母 的标记是 LTR 单词。混合标记解析为 RTL,因为 RTL 行文中嵌入拉丁术语的 情况远比反过来常见。 - 中性——没有强字母的标记(数字、标点、符号)两者都不计入。 - 平局——数量相等时解析为 RTL。 - 回退——完全不含 RTL 单词的块保持不变,因此从左到右的内容永远不会被 标记。 - 覆盖——带有非本包所设置的 dir 属性的元素保持作者所写的样子。这就是 退出机制。 按单词而非字符计数很重要,因为 RTL 单词较短,而拉丁技术术语较长: اشرح لي ال Agentic AI 是八个阿拉伯字符对九个拉丁字符,但却是三个阿拉伯 单词对两个拉丁单词。 元素根据其直接包含的文本进行判断,而不是根据其 后代,因此包含许多子元素的包装器不会因其内容而被翻转,而段落内的内联 code 片段不会贡献拉丁词。表格和列表是例外:它们根据整个子树来判定,因为列顺序和列表标记只有在容器本身翻转时才会重新排序。 已知失败情况 词主导性存在不可约简的失败模式。此处记录而非隐藏: - 短 RTL 子句,长拉丁命令。 شغّل npx @deepseek-ai/dsh web 是一个阿拉伯词对三个拉丁词元,解析为从左到右,这是错误的。没有任何词数规则能解决这个问题;它需要作者指定的方向或对命令进行内联隔离。 - 独立的括号内容。 一个主要由括号中的拉丁术语组成的块,即使在 RTL 文本中也会解析为从左到右。 - 均衡的块 根据平局规则解析为 RTL,这是一种选择,而非推导。 - 文本分散在子元素中。 方向是按元素根据其直接持有的文本决定的,因此一个文本完全存在于子元素中的包装器永远不会被评估——没有任何元素能看到整个句子。一个渲染为 كيف أستخدمdsh-client-ui-brand-official 的气泡,会让标识符子元素在孤立情况下正确地保持 LTR,而它所属的句子却从未被判定。这是放置问题,不是估算器问题;在根处继承方向并配合容器级覆盖,可以从构造上避免它。 对估算器判断错误的任何块显式设置 dir;该包会保持原样。 保持原样的内容 code、pre、kbd、samp、var、表单控件和嵌入媒体永远不会被标记——它们的方向按作者所写是有意义的。不会向内容中插入任何双向控制字符;该包只设置 DOM 属性。 流式处理 一个 MutationObserver 监视新增节点和文本变化,按每个动画帧批处理为一次遍历,因此助手消息在流式传输时就会被纠正,而不仅仅是在加载时。元素是被协调的,而不是只标记一次:一个在流式传输时平衡发生变化的块,其方向会被撤销或应用以匹配。 属性变更被有意不观察,因为该包会写入属性,观察它们会把自己的写入反馈回来。 模型体验 无,因为该包仅贡献浏览器呈现;此处没有任何内容会到达模型请求。 KV 缓存影响 无;该包既不组装也不发送提供商请求。 已知限制与推迟的工作 - 仅呈现,不涉及布局 —— 外壳本身保持从左到右。侧边栏保持在左侧,控件保持其位置。镜像应用外壳应属于一个占据布局槽位的单独包。 - 编辑器未被触及 —— 输入文本区域被有意排除,以避免干扰 IME 和选择状态。 - 浏览器标题是独立的 — DSH_CLIENT_TITLE 在构建时选择标题文本,而不是通过 UI 插槽。 - 仅用阿拉伯语验证过。 希伯来语、波斯语、叙利亚语和乌尔都语属于该字符范围,但尚未经过这些语言的流利读者审阅。DOM 属性无法证明可读性。 许可证 MIT
扫码进群