kfirsch/dsh-hebrew-rtl

dsh-hebrew-rtl

英文 | עברית

为 DeepSeek Harness Web GUI 提供正确的希伯来语 RTL 渲染：按主导文字系统为每个块设置方向、双向安全的输入字段，以及感知 RTL 的 Cmd+←/→ 行导航。

问题

该 GUI 将每个块都按从左到右渲染。对于希伯来语，这会产生三种截然不同的故障：

1. 整段文字反向阅读。 一个希伯来语句子被按 LTR 段落排版，因此其各行从错误的一侧开始，标点也落在错误的一端。
2. 在字段中输入时方向错误。 ask_user_question 自定义答案字段继承了页面方向，因此输入其中的希伯来语会从左到右流动。
3. Cmd+←/→ 感觉是反的。 这些快捷键在所有浏览器中都是逻辑方向：← 会移动到该行的逻辑起点，而在 RTL 行上，该起点位于视觉上的右边缘。按下 ← 会把光标跳到最右侧。

显而易见的 CSS 答案——unicode-bidi: plaintext——只能解决简单的一半。它根据块的第一个强方向性字符来选择块的方向，因此一个以拉丁产品名、列表编号或 emoji 开头的希伯来语句子仍会按 LTR 渲染，仍然读起来是乱码。

此插件的作用

按主导文字系统为每个块设置方向

对于每个块元素（p、ul/ol、h1–h6、blockquote、table），它会从块的文本中剔除类代码 token，然后在剩余内容中统计希伯来语占多数的单词与拉丁语占多数的单词：

| 内容 | 结果 |
| --- | --- |
| 无希伯来语散文 | 不覆盖——仍由 unicode-bidi: plaintext 负责 |
| 希伯来语单词 > 拉丁语单词 | direction: rtl + text-align: right |
| 拉丁语单词 > 希伯来语单词 | direction: ltr + text-align: left |
| 相等（两者都存在） | direction: rtl——一个希伯来语与拉丁语一样多的块，就是引用英文的希伯来语文本 |

被强制设置的块会获得 unicode-bidi: isolate，因此 Unicode 双向算法仍会在所选段落方向内部正确地排布少数文字系统的文本段：

היום בדקנו את הפלאגין החדש עם DSH והכול עבד מצוין.
→ RTL，并且 "DSH" 保持原位，未被反转

This is a test sentence with שלום in the middle.
→ LTR，并且 "שלום" 保持原位，位于句子中间

以主导性为规则，是因为两个更简单的替代方案都会以显而易见的方式失败。仅凭第一个强方向性字符，会错误渲染任何不是以希伯来语开头的希伯来语段落。“任何希伯来语字符都强制 RTL”则在另一个方向上过度纠正：一个带有一个希伯来语单词的英文句子会翻转为 RTL，其英文文本段会反向输出。
为什么按词计数，以及为什么排除代码 token。 按原始字母计数在技术性希伯来语散文中会出错。单个标识符的权重可能超过一整段——git+https://git@github.com:kfirsch/...# 本身就贡献了 44 个拉丁字母，而一个提交 sha 又贡献 40 个——因此一个仅仅引用了 URL 的希伯来语句子会被渲染为 LTR。因此，标识符、URL、路径、sha 以及 15/15 形式的比例在计数前会被剥离；它们仍会正常排版，只是不再对段落方向投票。按整词而非字母计数出于同样的理由：一个三字母的希伯来语单词对句子语言的说明，与 credential 一样多。剥离是刻意保守的——一个单独出现的普通拉丁词绝不会被当作代码，因此真正的英语散文仍会被完整计入。

对于剥离后确实一半一半的块（比如一行短文本，大部分是提交哈希，外加两个希伯来语单词），该启发式并非万无一失。这些情况会回退到 first-strong，而不是猜测。

复合元素整体判定，绝不按组成部分判定。 这一条规则被反复学到了三次：

- 表格。 分别判定每个 td 会让一个六行状态表得出三种不同结论——希伯来语标签单元格变为 RTL，而旁边的 HEAD 和 Commits 单元格仍保持 LTR——于是标签列逐行改变边缘。列的顺序是表格的属性，而不是单元格的属性，因此逐单元格方向也会与列顺序本身冲突。
- 列表。 同样的失败低一层出现。在一个希伯来语编号列表中，像 push 这样的短全拉丁项没有希伯来语可供权衡，因此它完全没有得到判定，回退到页面的 LTR，并从其 RTL 同级项跳到了相反的边距——破坏了编号列。
- 公式。 KaTeX 将公式渲染为数百个嵌套的 ，其水平位置由它自己计算。让每一个都选择自己的方向会把公式撕裂：(idle + rightsizing) 和 $870/month 被重排成了乱码。.katex 及其整个子树被排除——KaTeX 自己处理双向文本。

因此，方向对每个复合元素只根据其整体文本决定一次，每个部分都继承它。unicode-bidi: isolate 仍会在该方向内正确排版每个部分自身的内容。

随着文本流式传入，块会通过 MutationObserver 重新求值，并用 requestAnimationFrame 合并，这样流式传输就不会每字符触发一次扫描。

双向文本安全的输入字段

编辑器与 ask_user_question 自定义答案字段各自都是一个双层堆叠：一个可见或用于测量的镜像层，加上一个共享同一网格单元格的真实 。两层必须携带完全相同的双向文本度量，否则它们计算出的高度和换行会发散，字段会尺寸错误，或光标会偏离字形。
因此，两层都会同时接收 unicode-bidi: plaintext——绝不只是 textarea 单独接收——这样每一行的方向都会跟随实际输入其中的内容。

感知 RTL 的行导航

一个捕获阶段的 keydown 监听器会拦截 Cmd+←/→，仅当光标当前所在行是 RTL 时，并交换它们，使每个箭头都指向光标视觉上移动的方向。非 RTL 的行则完全不受影响。Shift 扩展和选区方向都会保留。

安装

dsh plugin --profile web add github:kfirsch/dsh-hebrew-rtl

然后重启 dsh web 并强制刷新浏览器标签页。

要固定到确切的提交（推荐——这样之后的推送就无法悄悄改变实际运行的内容）：

dsh plugin --profile web add github:kfirsch/dsh-hebrew-rtl#

该包在 lib/ 中提供的是纯手写 JavaScript，没有构建步骤，因此从 GitHub 安装无需 allowBuilds 批准。

卸载

dsh plugin --profile web remove dsh-hebrew-rtl

范围：刻意仅支持希伯来语

该方向规则可以干净地推广到所有 RTL 文字——阿拉伯语及其诸语言、叙利亚语、塔纳语、恩科语、阿德拉姆文——那个版本已经写好，并通过了 16 个用例的文字矩阵测试。但随后它被有意回退：无论是作者还是审阅者都无法校对那些文字，而发布无人能够验证的文本方向处理，比不发布更糟。包名说明了它实际支持的内容。

欢迎由能读懂该文字的人提交添加其他文字的拉取请求，并能通过肉眼确认其渲染效果。

兼容性

- 界面： web 配置文件（dsh web）。无宿主服务、无配置、无网络访问。
- 它从不触碰的内容： contenteditable 区域和代码块——代码无论内容如何都保持 LTR。
- 已针对 dsh 0.1.1-rc.2 测试。

许可证

MIT © Kfir Schneider

致审阅者：为什么没有构建步骤

lib/ 不是构建产物——它是手写源代码，采用 DSH 客户端模块系统加载的确切传输格式。这里刻意没有 src/、没有 scripts.build，也没有 scripts.prepack，因此干净的检出本身就是产物，从 GitHub 安装无需 allowBuilds 批准。

plugin_check 会在假设插件是编译产物的前提下，将这三者都标记为警告；它们在这里并不适用，而非未处理。该包以零错误通过检查。

自行运行检查：

npm test          # smoke-tests the direction rule and the caret swap