将易翻译的技术文档翻译，关键是先明确读者与目标（谁用、怎么用），建立术语与格式规范，利用机器辅助翻译（CAT/TM）提高一致性，做严格的人工校对与上下文验证，最后通过示例测试与本地化适配确认可用性，并记录变更与审阅历史以便追溯。
先把问题拆开：技术文档翻译要解决什么？
用费曼法想一想：技术文档的目的是什么？它不是文学，也不是随笔，而是要让读者“做对一件事”——安装、调用、调试、部署。翻译的核心任务，就是把原文的“可执行信息”准确地、可重复地传达给不同语言的读者。简单说，就是准确、可用、一致、可追溯。
四个基本要素
- 准确性：术语、参数、接口、错误码不能错。
- 可读性：句子清晰，步骤能按顺序执行。
- 一致性：术语和表达在整个文档中统一。
- 可追溯性：变更与决策记录在案，便于回溯。
准备阶段：先做功课
别急着翻字面意思，先收集信息：
- 确定读者画像（开发者、运维、普通用户还是管理者）。
- 明确目标语言的本地化深度（仅翻译内容，还是要改示例、时间格式、单位等）。
- 获取原文的上下文：源码片段、截图、关联Issue、API样例。
- 准备术语表（Terminology）和风格指南（Style Guide）。
术语表和句式规范怎么做？
把常见名词、函数名、错误码、单位、缩写列成表格。示例：
| 原文 | 建议译文 | 备注 |
| API endpoint | API 端点 | 保留 API 缩写，端点比“接口”更贴切网络请求场景 |
| Retry | 重试 | 动作类词汇统一使用动词形式 |
翻译流程：工具与分工
实际操作上，把流程分成“机器预翻+人工润色+审校验证+本地化测试”。
推荐的步骤
- 预处理：提取段落、表格、代码块、占位符（{{userId}}）为独立单元。
- 机器辅助翻译（CAT/TM）：利用翻译记忆（TM）保证术语一致，术语表挂钩。
- 首轮人工润色：关注准确性与上下文，处理代码注释与示例。
- 技术审校（Subject Matter Review）：由开发或产品确认参数、示例是否可复现。
- 本地化测试：把翻译文档放到实际环境或模拟环境里跑一遍（界面截屏、API 调用）。
- 发布前QA：拼写、格式、版本号、变更日志检查。
细节处理：代码、占位符、表格、截图
这些东西不能随便改：代码块必须与原文一致（仅翻译注释和输出），占位符要严格保留，表格列对齐，截图要决定是替换还是保留原图并加注说明。
占位符与变量
例子：原文 “Call GET /users/{{userId}} to fetch the profile.” 翻译时应保留 {{userId}}，并在术语表注释变量类型与范围，比如 “userId: 整数，范围 1-2^31-1”。
代码示例
- 不要翻译代码内的标识符（函数名、类名），除非文档要求。
- 可以翻译注释和输出，且要保留缩进与格式。
质量保障：验收标准与测试
设定可观测的质量指标，不要只靠“看起来没问题”。常用的量化方法包括：
- 术语一致率：新译文中术语被一致使用的比率（目标 ≥ 98%）。
- 错误密度：每千字的语义或技术错误数量（目标接近 0）。
- 可复现率：按照文档步骤能完成任务的成功率（一般目标 ≥ 95%）。
审校清单（可打印的操作项）
| 项 | 检查点 |
| 术语 | 是否与术语表一致？ |
| 占位符 | 所有 {{}}、%s、{0} 是否被保留？ |
| 代码 | 示例能否直接复制执行？ |
| 截图 | 是否需要替换或局部标注？ |
例子演示：把复杂的段落拆成可翻单位
原句（假设）：“Upon failure, the client retries up to 3 times with exponential backoff and logs Error 502 with timestamp.” 我会这样拆：
- 动作：重试（Retry）——行为说明
- 参数：最多 3 次（尝试次数）
- 策略：指数退避（exponential backoff）——可以在脚注解释算法
- 记录：记录 Error 502 与时间戳——说明日志字段名与格式
翻译示例（思路）：“当请求失败时，客户端按指数退避策略最多重试 3 次；若仍失败，记录错误码 502 及时间戳（格式：YYYY-MM-DDThh:mm:ssZ）。”。你看，先拆，再译，最后合并，这样更易校验。
团队与职责：谁做什么？
- 译者：负责初次翻译与术语应用。
- 技术审核：工程师或产品，验证可复现性和准确性。
- 本地化工程师：处理格式、左到右/右到左、字符集、打包发布流程。
- QA：做最终验收（功能测试、界面测试、拼写和样式检查）。
常见问题与坑（太多人踩过）
- 直译接口说明导致歧义——要用“动作+参数+前提+输出”的结构。
- 把代码里的标识符翻译了——结果无法运行。
- 没有上下文就翻单句——术语不一致、歧义多。
- 未记录翻译决策——后面有人来质疑不知道为什么这么翻。
工具一览（简单推荐）
工具不是万能，但能降低重复劳动：
- CAT 工具（如 Trados、memoQ、OmegaT）：管理 TM 与术语表。
- 版本控制（Git）：管理原文与译文的变更历史。
- CI 集成测试：把文档作为用例自动跑一遍（示例脚本）。
- 本地化测试工具：检测硬编码文本、截断、UI 溢出等问题。
小技巧和心法（偶尔有用的经验）
- 用伪翻译（pseudolocalization）提前发现长度与编码问题。
- 把复杂句子改成步骤化的短句：便于读者也便于校对。
- 优先建立并维护一个活的术语库，不要每次从头开始。
- 遇到不确定的术语，先在文档里注释，并发给技术负责人确认，再统一修改。
我通常会怎么做（有点像工作日志）
想象我在做：先拿到原文，翻一次大意，列出 30% 的疑问点；然后跑一遍机器翻译，导入 TM，清理占位符；接下来人肉润色，把每个 API 示例跑通一遍（是的，真跑）；最后和技术同学一起 review，改完再做伪翻译测试，确认 UI 不溢出。发布时，把变更记录、审阅人和版本号写进文档里，方便下次回头。就是这么啰嗦，但挺实用。
如果你现在就要开始，建议先用表格把“术语、变量、示例、疑问”列出来，分配人，定个里程碑：术语表完成、首译完成、技术审校完成、本地化测试完成、发布。别忘了，文档翻译不是一次性活，它伴随产品迭代而活着。
