做过技术文档本地化的人都遇到过这个场景：翻译结果读起来没问题，导回系统却报错——标签数量对不上、嵌套结构乱了、变量占位符不见了。内容是对的，格式坏了，整个句段作废。这类问题占技术文档翻译返工量的相当一部分，而它几乎完全可以通过正确配置避免。
先区分两类标签，它们的处理方式完全不同
第一类是结构标签，比如 div、section、table、ul。它们包裹的是完整的内容块，翻译时通常整块处理，标签本身不参与语序调整。这类相对好处理。
第二类是内联标签，比如 strong、em、a、span、code。它们嵌在句子中间，标记的是句子内部的某个片段。麻烦就出在这里：源语言里被加粗的词，在目标语言里位置会变、长度会变，甚至可能被拆成两个词或合并成一个。标签必须跟着语义走，而不是跟着位置走。
为什么简单的正则替换一定会失败
很多团队的第一版方案是：先用正则把标签抽出来存成占位符，翻译纯文本，再把标签塞回去。这个思路在语序不变的语言对之间勉强能用，跨语系就崩了。
英译中时语序大幅调整，占位符按原位置回填会完全错位。更糟的是嵌套标签——外层是链接、内层是加粗，抽取时的嵌套关系在回填时无法恢复。还有一类情况是标签跨越了句子边界，抽取后连原本属于哪一句都判断不了。
正确的做法是让翻译引擎本身理解标签，在解码时同步决定标签位置，而不是事后拼接。调用 文本翻译 API 时开启标签处理模式即可，引擎会把标签当作不可翻译的结构保留并重新定位。
变量占位符要用可识别的格式
软件本地化里到处是变量：欢迎回来，占位符、您还有几天试用期。这些占位符的格式五花八门——花括号、百分号、美元符号加花括号、双花括号，各个框架都不一样。
问题在于有些格式会被模型误认为可翻译内容。比较稳妥的做法是统一成一种明确的、不像自然语言的格式，并把这些模式加进不可翻译列表。另外要注意变量周围的空格和标点——中文不需要空格，英文需要，回填时如果不处理会出现多余空格或标点粘连。
CDATA、注释和属性值的边界
XML 文档里还有几个容易遗漏的位置。CDATA 段落里的内容通常是需要翻译的正文，但很多解析器默认跳过。注释里有时藏着给译者的说明，不该被翻译但需要保留。属性值里 alt、title、placeholder、aria-label 这几个是需要翻译的，而 class、id、href、data-* 绝对不能动。
建议维护一份明确的属性白名单，而不是黑名单——白名单漏掉一个属性只是少翻了一处，黑名单漏掉一个属性可能直接翻坏样式或链接。
用自动校验代替人工核对
标签问题的好处是它可以完全自动检测。在译文写回系统之前加一道校验：比对原文和译文的标签数量是否一致、标签类型是否一一对应、嵌套是否合法、变量占位符集合是否完全相同。任何一项不通过就拦截并标记。
这道检查的实现成本很低，但能把标签类返工从常态变成个例。对接 CAT 工具的团队，这一步可以放在导回之前，避免污染翻译记忆——一旦坏掉的句段进了 TM，后面会被反复复用。CAT 工具集成指南里有流程位置的更多说明。
先测最难的样本，再上量
配置完成后，不要用普通段落验证，要用最复杂的样本：嵌套三层以上的内联标签、一句话里有五个变量、标签跨句子边界、表格单元格里嵌链接。这些边界情况过了，日常内容才不会出问题。
把这批样本固定下来做成回归集，每次引擎升级或配置调整后重跑一遍。技术文档的量通常很大，一个配置问题会被放大成几千处错误，提前拦住比事后修便宜太多。更多接入细节可以看 API 快速开始和 SDK 列表。