GitHub ↗

01 · 问题分析:中英混排顺序错乱

01 · 问题分析:中英混排顺序错乱

现象

语音说「今天讨论 docker 部署」,屏幕实际出现「今天讨论部署 docker」——英文整体后移到中文之后。SenseVoice 的转写结果本身顺序是正确的(voxtype transcribe 直接验证可复现正确顺序),问题出在输出注入环节。

根因

输出链路

voxtype 当前配置 output.mode = "type":转写完成后用 wtype(首选,Wayland 虚拟键盘)或 ydotool(uinput 内核级)逐字符模拟键击。

合成按键与物理按键走完全相同的处理路径:

wtype 发送 keysym
  → Hyprland 合成器
    → zwp_input_method_v2(fcitx5 正在此挂载)
      → rime 引擎按"用户正在打字"处理
        → 应用收到的是 fcitx5 处理后的结果

关键分流

fcitx5 中文模式(rime 激活)下,两类字符命运不同:

字符类型 rime 的处理 用户看到的
CJK 字符(今天讨论部署) 无法进入拼音编码缓冲区,直接透传 commit ✅ 实时出现在正确位置
Latin 字母(docker) 被当作拼音编码输入抓进缓冲区,等待组词 ❌ 不立即上屏

被缓冲的字母何时提交?下一个无法组词的事件到来时、录音结束后的超时、或用户按下空格/回车。此时光标早已移动到全部中文之后——英文整段落在末尾。

为什么识别是对的

voxtype transcribe test.wav --engine sensevoice 直测输出顺序正确,证明问题不在 ASR 层。SenseVoice 对混语种文本按发音时间序输出,与屏幕表现无关。

触发条件

  1. voxtype output.mode = "type"(打字式注入)
  2. 注入期间 fcitx5 处于中文模式(rime 组词激活)

两个条件缺一不可。切到英文直通模式后字母不被缓冲,问题消失——这也是临时规避手段(单按 Shift 切换),但依赖人的记忆,不可靠。

结论

修复方向不是改识别,而是绕开打字式注入:让应用通过剪贴板粘贴动作自行插入完整文本,IME 全程不接触字符。见 02-方案设计.md。