feat: 添加翻译词典

[nightt5879]

摘要

• 在翻译任务高级选项中新增“翻译词典”，支持按行配置 正则 -> 期望译文。
• 词典不再注入 AI prompt，而是在翻译结果写回前做确定性的 JavaScript 正则全局替换；支持普通正则和 /pattern/flags 写法。
• 所有翻译服务的译文批次都会使用同一套正则后处理；校对页重翻译也复用该词典。
• 新增词典解析、正则替换、无效正则忽略、字面量替换和批量后处理测试。

验证

• npm run test:translation-dictionary
• npm run test:translate-parser
• git diff --check
• npx tsc --noEmit：仍被仓库既有 docs 依赖、路径别名、jest globals、参数配置类型等问题阻塞。
• npm run test:engines：本地 node_modules/electron 安装损坏，Electron 启动前失败。

Closes #287

[vercel]

@nightt5879 is attempting to deploy a commit to the buxuku's projects Team on Vercel.

A member of the Team first needs to authorize it.

[nightt5879]

@buxuku 我已经把这个 PR 同步到最新 upstream/main，解决了之前的 merge conflict，并保留了主线最新的字幕断句实现；词典功能仍然按原 PR 的思路保留为“翻译结果写回前的确定性正则后处理”。

本地已验证：

• npm run test:translation-dictionary
• npm run test:translate-parser
• npm run check:i18n
• git diff --cached --check（合并提交前执行）

当前 PR 上的 Vercel 仍然失败，看起来是团队授权问题，不是代码检查失败。

想请你帮忙确认一下这个功能方向：

1. 这个翻译词典/术语表功能是否希望由我们继续推进？
2. 如果要做，你更倾向于现在这种“翻译后正则替换”的确定性方案，还是希望改成 prompt 注入、前后处理组合，或者做成全局资源中心里的可复用词典？
3. 如果当前 PR 变更范围太大，我也可以按你希望的方案拆小重做。

麻烦有空时给一下方向反馈，我们再按你的意见继续调整。

[buxuku]

@nightt5879 感谢跟进。这几天我把这个功能的方向想了一遍，也对照了沉浸式翻译、VideoLingo 这类工具的做法，给你一个迟来的答复。

功能是在软件的规划里面，#287 的需求真实存在，欢迎继续推进。但实现思路上要做一个比较大的调整：译后正则替换这条路径我和曾经的规划是有区别的

不建议采用译后替换主要是两个原因。一是时机不对：替换匹配的是译文，但用户没法预判模型会把一个词翻成什么。比如想让 Alice 固定翻成「艾丽丝」，模型如果输出的是「爱丽丝」，Alice -> 艾丽丝 这条规则就落空了，除非把可能的错译全枚举出来，这对用户基本不可行。二是正则门槛太高：C++、Dr. Smith 这种词直接写就是非法或错误的正则，而且无效正则目前会被静默忽略，用户毫无感知；普通词不加 \b 又会误伤子串（cat 会命中 category）。

调整后的方案大致是这样：

1. 词库做成全局资源，单独加一个管理页（和「翻译服务」平级）。支持建多套词库（按剧、按领域分开建），每套一个启用开关；词条就是「原文 + 期望译文（+ 备注）」的纯文本，不引入正则；支持增删改查、搜索和 CSV/TXT 批量导入导出。
2. 翻译任务、校对页的重译和 AI 优化这些流程，统一自动读取所有已启用的词库，任务侧不加词库选择，也就不会再有 formData 和 userConfig 两边取值不一致的问题；换剧时去管理页切一下开关就行。多个启用库撞了同一个原文时，按词库顺序取第一条命中，并在日志里提示。
3. 生效机制按渠道分层。AI/LLM 渠道是主路径：每批翻译前扫描字幕原文，只把命中的词条注入 system prompt（现有的 prompt 模板机制加个变量即可），token 开销只有命中的那几条，沉浸式翻译、VideoLingo 都是这个做法。传统机翻渠道（百度、火山、腾讯、阿里等）厂商自带术语库能力，但基本都要在各家控制台维护，应用内没法统一接管，所以这部分不在应用里实现，只在界面上给指引提示，告诉用户去对应控制台配置。

prompt 注入确实不能保证百分百遵守，所以任务日志里会输出每批命中的词条，方便确认效果；先把主路径做好，真遇到顽固 case 再评估其它手段。

按这个思路，现在这个 PR 和新方案差异比较大，建议按新方向重做，你词典文本解析那部分逻辑在导入解析里应该还能复用一些。

[nightt5879]

@nightt5879 感谢跟进。这几天我把这个功能的方向想了一遍，也对照了沉浸式翻译、VideoLingo 这类工具的做法，给你一个迟来的答复。

功能是在软件的规划里面，#287 的需求真实存在，欢迎继续推进。但实现思路上要做一个比较大的调整：译后正则替换这条路径我和曾经的规划是有区别的

不建议采用译后替换主要是两个原因。一是时机不对：替换匹配的是译文，但用户没法预判模型会把一个词翻成什么。比如想让 Alice 固定翻成「艾丽丝」，模型如果输出的是「爱丽丝」，Alice -> 艾丽丝 这条规则就落空了，除非把可能的错译全枚举出来，这对用户基本不可行。二是正则门槛太高：C++、Dr. Smith 这种词直接写就是非法或错误的正则，而且无效正则目前会被静默忽略，用户毫无感知；普通词不加 \b 又会误伤子串（cat 会命中 category）。

调整后的方案大致是这样：

1. 词库做成全局资源，单独加一个管理页（和「翻译服务」平级）。支持建多套词库（按剧、按领域分开建），每套一个启用开关；词条就是「原文 + 期望译文（+ 备注）」的纯文本，不引入正则；支持增删改查、搜索和 CSV/TXT 批量导入导出。
2. 翻译任务、校对页的重译和 AI 优化这些流程，统一自动读取所有已启用的词库，任务侧不加词库选择，也就不会再有 formData 和 userConfig 两边取值不一致的问题；换剧时去管理页切一下开关就行。多个启用库撞了同一个原文时，按词库顺序取第一条命中，并在日志里提示。
3. 生效机制按渠道分层。AI/LLM 渠道是主路径：每批翻译前扫描字幕原文，只把命中的词条注入 system prompt（现有的 prompt 模板机制加个变量即可），token 开销只有命中的那几条，沉浸式翻译、VideoLingo 都是这个做法。传统机翻渠道（百度、火山、腾讯、阿里等）厂商自带术语库能力，但基本都要在各家控制台维护，应用内没法统一接管，所以这部分不在应用里实现，只在界面上给指引提示，告诉用户去对应控制台配置。

prompt 注入确实不能保证百分百遵守，所以任务日志里会输出每批命中的词条，方便确认效果；先把主路径做好，真遇到顽固 case 再评估其它手段。

按这个思路，现在这个 PR 和新方案差异比较大，建议按新方向重做，你词典文本解析那部分逻辑在导入解析里应该还能复用一些。

没问题 按照你说的做也行，命中词条日志的设计我觉得很好 平衡了担心没办法prompt注入准确的问题