工程师小明拿到多语系上线前的最后测试，一启动项目，终端机立刻喷出满版红字：SyntaxError: Unexpected token。追查下去，才发现是外包翻译人员把 JSON 配置档里的 true 翻成了「正确」，还顺便把结尾的逗号给删了。在软件本地化过程中，JSON 与 YAML 这类配置档的翻译看似只是文本替换，实则暗藏让系统直接崩溃的风险。
为什么配置档翻译这么容易「翻车」？
配置档不是给人看的普通文章，它们是机器读取的指令。一旦格式跑掉，程序就无法解析。常见的翻车原因包含：
- 语法极度严格：JSON 少一个括号、多一个逗号就会报错；YAML 则对缩进（空格）极度敏感，Tab 和 Space 混用直接导致解析失败。
- 键值对（Key-Value）误译：翻译人员若不了解结构，很容易把作为识别码的 Key（如
btn_submit）也翻译掉，导致程序抓不到变量。 - 特殊字符与转义：配置档中常见的
\n、\"或 HTML 标签，若被当作普通文本翻译或修改，会破坏原有逻辑。
JSON 与 YAML 翻译的结构保留技巧
要确保翻译后文件可用，必须严格区分「代码」与「待翻译文本」。以下为两种主流配置档的翻译保留原则对比：
| 特性 | JSON 配置档 | YAML 配置档 |
|---|---|---|
| 语法内核 | 大括号 {} 与键值对 : |
缩进层级与键值对 : |
| 常见崩溃原因 | 逗号遗漏、引号未闭合、Key 被翻译 | 缩进错位（如使用 Tab）、Key 被翻译 |
| 翻译保留原则 | 仅翻译 " 内的 Value，保留所有 {}、[]、, |
仅翻译 : 后的 Value，严格维持原有缩进空格 |
| 特殊符号处理 | 保留 \n、\" 等转义字符 |
保留 ` |
配置档翻译的最高原则：机器读得懂语法，人类读得懂语意。任何破坏结构的翻译，都是无效的本地化。
防崩溃实务：从工具到流程的把关
锁定语法与术语一致性
手动用试算表翻译配置档是灾难的开始。现代软件本地化需要依赖专业工具来锁定不可译内容。DocTransAI 在处理这类结构化文档时，能自动识别并锁定 JSON/YAML 的语法符号与 Key，确保翻译引擎只针对 Value 进行处理，从根源杜绝语法崩溃。
此外，配置档中常有 UI 字符串或系统提示，创建统一的 企业翻译为什么必须创建术语库（Glossary）？ 能让不同模块的翻译保持一致，避免同一个 error_404 在不同文件中被翻成不同意思，降低用户的认知负担。
企业级配置档翻译的资安与部署
私有化部署保障机密不外泄
配置档中有时会夹杂测试环境的 API Key、内部数据库路径或未公开的项目代号。将这些文件上传至公有云翻译服务，无形中增加了资安风险。
对于对资安要求极高的科技业或金融软件团队，企业私有化部署：让翻译数据完全不出本地 是更稳妥的选择。通过私有化部署，企业可以在内部网络环境中调用 DocTransAI 的翻译引擎，确保机密配置与代码逻辑完全不外泄，同时满足严格的合规要求。
机器翻译与人工审校的平衡
虽然 AI 模型已经能很好地理解 JSON/YAML 结构，但对于涉及业务逻辑的长句或特定领域的 UI 提示，仍建议采用机器翻译加上人工审校的流程。实务上可依照以下步骤进行：
- 结构解析与提取：使用工具自动提取可翻译字符串，并保留原始格式与上下文。
- 多模型翻译：针对不同语系或领域，选择表现最佳的 AI 模型进行初译。
- 人工审校微调：由工程师或本地化测试人员针对翻译后的 Value 进行语意微调，确保符合软件接口情境。
- 结构还原与验证：将翻译后文本写回原档，并运行语法检查（Lint）确保无误。
通过这套标准流程，开发团队无需再花时间修复被破坏的语法结构，就能大幅提升软件出海的迭代速度与产品品质。