将《易翻译》技术文档翻译成准确、可用的目标语言，首先把文档按模块拆分、提取术语表与变量占位符，建立风格与术语一致性规范；使用机器初译+人工编辑的混合流程，配合上下文检查、界面字符限制与语音输出校对，最后经过多轮审校和本地化测试交付。同时保留原文链接和版本注释，便于后续维护与更新，并进行术语回溯评估。
先说结论：为什么要按流程来翻译技术文档
技术文档不是一般的文学文本，它承载产品用法、接口约定、参数说明与交互行为。翻译质量直接影响用户使用体验、开发接入成功率与售后成本。所以对《易翻译》这种覆盖文本、语音、拍照取词、双语对话的产品，翻译要兼顾准确性、一致性和可读性——这不是一句“直译”能解决的事，需要步骤化、工具化与多人协作。
理解易翻译产品对文档翻译的特殊要求
- 多模态输出：除了界面文本，还涉及语音播报、OCR提示、实时对话脚本；翻译时要校对语音合成效果与语速。
- 占位符与变量：UI里常有{username}、%s、{0}等占位符，不能轻易替换位置，否则会出错。
- 字符限制：移动端界面常有长度限制，翻译后字符过长会导致截断或布局错位。
- 术语一致性：像“实时翻译”、“拍照取词”这类产品词汇必须在整套文档及界面中统一表达。
- 本地化差异：不同语言的读法、敬语、度量单位、时间格式都需本地化处理，而不是简单翻译。
一步步做：标准翻译流程（费曼式解释）
想像你要把一台机器的说明书翻成另一种语言。第一步是拆开机器看每个零件（模块化），第二步是把每个零件的名字列成表（术语表），第三步是先用机器翻译把零件粘回去（初译），第四步请熟悉机器的工程师检查（人工审校），最后在实际操作中试验是否能组装（本地化测试）。下面我把这个过程拆成可执行的步骤。
准备阶段：收集与拆分
- 收集资料：原文档、原始设计稿、界面截屏、语音文本、翻译记忆库（TM）、术语表、变更记录。
- 按模块拆分：界面词条（UI strings）、用户手册、快速入门、API/SDK文档、FAQ、隐私合规文本等分别处理。
- 标注上下文：每条字符串都尽量附加上下文截图或使用场景说明，避免断章取义。
术语与风格规范建立（先做后说）
先做一个最小可用的术语表（至少包含产品名、核心功能名、术语短语），并定义语气（比如：简洁、友好、技术中性）。把这些写成一页样式指南，供翻译和校对参考。
- 示例术语表：
| 原文 | 建议译文 | 备注 |
| Real-time translation | 实时翻译 | 用于产品功能按钮和介绍 |
| Photo lookup | 拍照取词 | 避免译成“图片查询”之类不贴切的词 |
| Conversation mode | 双语对话模式 | 在UI中作为模式开关名出现 |
机器初译：快而不全靠机器
通过CAT工具或易翻译内部的翻译引擎批量初译，目的是提高效率、填充翻译记忆（TM），而不是直接发布。初译后要做自动QA检查，例如占位符是否被改动、HTML/Markdown标签是否完整、数字和时间格式是否被破坏。
人工编辑与上下文对照
- 按模块分配译者：界面词条给熟悉UI/UX的译者，API与技术说明给有工程背景的译者。
- 重点核查：术语一致性、占位符、示例代码、参数类型、错误信息的可操作性。
- 语音校对：对涉及语音播报的句子做朗读测试，检查语速、断句与发音歧义（尤其是专有名词）。
本地化测试（理想是“用起来”）
把翻译文本放回产品里进行真机或真环境测试，检查界面是否溢出、按钮是否截断、语音播报是否自然、OCR提示是否准确。测试包含多语言回归测试与不同屏幕尺寸测试。
审校与验收：多轮为宜
- 第一轮：语言审核（可读性、语法、术语一致性）。
- 第二轮：技术审核（工程师检查API示例、参数说明）。
- 第三轮：本地化审核（测试人员或目标语母语用户试用反馈）。
细节清单：不踩坑的那些地方
- 占位符不变位：遇到{username}、%1$s等要保持结构，必要时写注释说明位置关系。
- 不要直译错误提示：错误提示要说明可操作路径，比如“网络错误”改为“无法连接服务器，请检查网络设置”。
- 代码块与命令：代码内容通常不翻译，但注释应翻成目标语言并保留原文代码示例。
- UI长度预算：把每个字符串标注最长字符数，翻译时不要超出（尤其是德语、俄语通常更长）。
- 声音与拼写：语音ID、拼写提示需按目标语音规范处理（重音、连读可能影响效果）。
一个小表格：翻译交付检查表
| 步骤 | 检查项 | 是否通过 |
| 术语表 | 核心术语是否统一、是否包含翻回链 | ☐ |
| 占位符 | 占位符完整且位置说明清楚 | ☐ |
| 界面测试 | 按钮/提示无截断、溢出 | ☐ |
| 语音测试 | 合成朗读流畅、专有名词可识别 | ☐ |
| 版本控制 | 翻译文本与原文版本对齐、有变更记录 | ☐ |
工具和团队协作建议
- CAT工具：使用支持TM、术语库和QA检查的工具（如SDL Trados、memoQ或开源的OmegaT）。
- 版本控制：把文档和翻译稿放在有版本管理的仓库（Git）中，标签化每次发布。
- 持续集成：把翻译接入CI流程，形成本地化构建与自动化回归测试。
- 沟通渠道：建立译者、产品经理、开发与测试之间的固定沟通机制（如每周短会、专门的注释文档）。
实际例子：遇到的常见场景与处理方法
场景一：字符串长度超限
问题：德语翻译后长度比中文长30%，按钮显示成“…” 处理：优先重新措辞，保持术语；若无可行缩短方案，考虑使用更短同义词或调整UI布局。应和产品经理沟通是否可改为换行或使用图标辅助。
场景二：占位符被移动导致格式化出错
问题：翻译把“Hello, {name}!”改为“{name}，您好!”但代码中期望先输出名字导致拼接出现两次或缺失。处理：翻译时在注释中标明占位符不能随意变更位置，必要时在代码侧采用命名占位符（如 {user.name}）来减少歧义。
场景三：语音播报出现歧义
问题：产品中“重试”在语音中读得像“冲刺”。处理：修改语音拼写注释或替换为更口语化但更清晰的表达（如“请重试”），并在TTS引擎中测试不同发音配置。
评估质量的量化方法
- 错误率度量：记录线上用户报告的问题数量与种类（术语错、截断、功能理解错误等）。
- 可读性测试：邀请目标语言的真实用户完成核心任务，看任务完成率与平均所需时间。
- 术语一致性：统计术语表覆盖率与术语误用次数。
- 上线回归：每次原文更新后统计翻译延迟与覆盖率。
小技巧：提升效率但不牺牲质量
- 优先处理高频词条与核心流程的翻译，次要说明可以边用边补。
- 把语音文本与UI文本拆开维护，专人负责语音文本的自然化调整。
- 用翻译记忆（TM）减少重复工作，长期会显著提速并保持一致性。
结尾前随想（边想边写的那种）
翻译技术文档其实像做菜：准备好配料（资料与术语），按步骤下锅（初译与审校），尝味道（本地化测试），不停地试和改。对《易翻译》这样的多功能产品，别把翻译当成最后一步才想到的事，把它放进开发与发布的节奏中，会少很多返工。顺便说一句，实际操作中总会碰到例外和小插曲：某个术语突然被产品改名、某条语音需多语言适配，这些都需要灵活的流程与有耐心的合作伙伴。
如果你现在正准备开始翻译，先从建立术语表和标注上下文做起，其他的慢慢补上去，边做边改，会越来越顺手。
