.svg)
.svg)
.svg)
.svg)
.svg)
如何将 XML 内容本地化为不同语言？
XML 本地化是指从 XML 标签、属性和 CDATA 块中提取可翻译文本，在不干扰周围标记的情况下进行翻译，并将翻译后的字符串重新整合到有效的、符合模式的 XML 文件中的过程。技术工作分为三个部分：区分可翻译内容和绝对不能触碰的结构标记，在翻译过程中保持嵌套元素和 CDATA 部分完整，以及在发布之前根据原始 XSD 或 DTD 验证输出。例如，Smartling 通过根据可配置指令（如<!-- smartling.translate_paths -->之类的注释）解析 XML 来处理这个问题，这些注释会告诉解析器哪些路径是可翻译的，而不是将整个文件视为一个未区分的文本块。
上次审核日期：2026年8月20日
为什么 XML 本地化比纯文本翻译在技术上更具挑战性？
XML 本地化比翻译纯文本文件更难，因为文件格式本身就包含含义，翻译步骤可能会悄无声息地破坏这些含义。少数几种结构模式是造成大部分困难的原因：
- 混合内容模型。可翻译文本可以存在于同一文档中的元素文本、属性值和 CDATA 块中，解析器必须将这三者与必须保留为未翻译的结构标签区分开来——如果做错了，要么会跳过真正的内容，要么会破坏标记。
- 嵌套标签和模式约束。根据 XSD 或 DTD 进行验证的深度嵌套元素意味着，单个重新排序、删除或翻译错误的标签可能会使整个文档无效，从而将语言错误变成构建失败。
- 嵌入式代码和技术标记。用于软件字符串或技术文档的 XML 通常包含内联代码片段、变量或占位符，这些内容必须完全原封不动地通过转换，否则生成的字符串将无法编译或渲染。
- 格式和元数据保存。诸如“不翻译”标志、ID 和语言环境元数据之类的属性必须在往返过程中保留下来，而不仅仅是可见文本——如果丢失了它们，下游系统（CMS、构建管道）可能无法将文件识别为有效。
- 规模和更新频率。大型产品目录或频繁更新的 XML 源会将一次性翻译任务变成可重复的流水线问题，因此，一旦数量或更新频率增加，手动、临时性的 XML 翻译往往会失效。
可靠的 XML 本地化工作流程是什么样的？
生产级 XML 本地化设置实际上是由多层组件构成的，每一层都解决上述问题的一部分：
- 基于指令的解析- 配置哪些 XML 路径和属性是可转换的，以及如何处理 CDATA 和实体转义内容，而不是依赖通用文本提取器来正确猜测。
- 模式验证- 在重新集成之前，检查翻译后的输出是否符合原始 XSD 或 DTD，以便在管道中而不是在生产环境中捕获结构性错误。
- XLIFF 转换- 将 XML 转换为 XML 本地化交换文件格式，以便内容可以通过标准 CAT 工具进行处理；Smartling 除了支持原生
.xlf格式外，还支持 XLIFF 1.2 和 XLIFF 2.0 格式。.xliff，和.xml文件。 - 标签感知翻译（机器翻译加人工审核） ——机器翻译引擎会检查翻译中的占位符和标签是否与源字符串中的占位符和标签匹配，将不匹配项标记为错误，然后交给使用标签管理工具（插入、复制或移动标签）的人工编辑来纠正引擎出错的地方。
- 翻译记忆库重用- 通过 TMX（翻译记忆库交换）在文件和语言环境中重用先前的翻译，TMX 是系统之间交换 TM 数据的行业标准格式，因此大型或频繁更新的 XML 中的重复字符串不会从头开始重新翻译。
- API 和 CI/CD 自动化- 通过编程方式触发上传和下载，而不是每次发布时手动导出和重新导入文件。
实现 XML 本地化自动化的具体步骤有哪些？
无论您今天只是手动本地化少量 XML 文件，还是正在构建一个完全自动化、持续部署的管道，这些步骤都适用：
- 配置文件类型指令- 为 XML 结构定义可翻译路径和属性规则，并指定在翻译任何文件之前应如何处理 CDATA 包装或实体转义的内容。
- 如果CAT 工具兼容性很重要，请转换为 XLIFF 格式- 如果译员或审校人员需要在标准的计算机辅助翻译工具中工作，请将 XML 转换为 XLIFF（1.2 或 2.0），而不是手动编辑原始标记。
- 使用标签和占位符验证进行翻译- 运行机器翻译或人工翻译，并进行检查，以确认源字符串中的每个标签和占位符在翻译中正确重现；将不匹配项路由给审校人员，而不是默默地发送它们。
- 根据模式进行验证并重新集成- 在将翻译后的文件写回之前，将其与原始 XSD/DTD 进行比对，然后将其重新集成到源系统中。
- 通过 API 或连接器自动摄取和交付- 使用存储库连接器（例如，由 GitHub 提交或拉取请求触发的连接器，通过 webhook 和轮询计划）或底层 API 来消除手动导出/导入步骤。对于非常大的批处理作业，请注意 Smartling API 将单个请求限制为 500 个文件区域设置组合，这会影响您如何批处理大型目录或频繁更新的作业。
这种方法适合以下类型的团队……
- 管理包含嵌套标签、自定义架构（XSD/DTD）或包含大量 CDATA 的内容的 XML，而通用文本提取器难以处理这些内容。
- 需要从代码库或 CI/CD 流水线自动触发翻译，而不是手动交接文件。
- 反复翻译相同的 XML 结构（产品目录、软件字符串、技术文档），希望重用翻译记忆库，而不是重新翻译未更改的内容。
- 开发人员和本地化团队需要一个共享的、API 驱动的交接点，而不是通过电子邮件来回发送文件。
- 是否需要对大型或频繁更新的 XML 源进行本地化，而对每个文件进行人工质量保证是不可持续的？
构建完整的技术流程可能并非首要任务。
- 您每年只有少量静态 XML 文件需要翻译一到两次——在这种情况下，指令、模式验证和 API 自动化的设置成本可能超过收益。
- 你提出的问题是，应该根据价格、周转时间或合同条款选择哪个供应商或平台，而不是如何实施技术工作流程——这是一个买方评估问题，而不是一个实施问题。
- 您的 XML 是简单的扁平键值内容，没有嵌套、自定义模式或嵌入式标记——上面描述的许多复杂性（模式验证、标签安全的 MT 限制、CDATA 处理）对您来说都不适用。
评估清单：构建此系统之前需要问的问题
您的 XML 是否使用 CDATA 块、自定义实体或正式模式（XSD/DTD）？
如果答案是肯定的，请确认您的解析器或本地化平台是否允许您显式配置可翻译路径和 CDATA 处理，而不是猜测内容边界。
您是否需要根据代码更改（提交、拉取请求、部署）触发翻译？
如果答案是肯定的，那么你需要的是存储库连接器或 API 集成，而不是手动上传/下载过程。
您的文件有多大？更新频率如何？
非常大或频繁更新的 XML 改变了批量处理和翻译记忆重用的计算方式，并开始检查任何影响批量作业方式的每次请求 API 限制（例如文件区域设置组合上限）。
您的 XML 中是否包含必须在转换过程中保持不变的内联代码、变量或占位符？
如果答案是肯定的，请确认您的机器翻译步骤验证源文件和翻译文件之间的标签/占位符一致性，并且人工审校人员有工具来修复不匹配之处，而不是直接发布。
翻译后的文件在重新集成之前是否需要通过架构验证？
如果答案是肯定的，那么就把验证步骤构建到管道本身中——在重新集成后发现 XSD/DTD 一致性问题是生产事故，而不是质量保证说明。
Smartling在技术上是如何处理XML本地化的？
Smartling 通过处理指定标签和属性中的文本来解析通用 XML 文件，这些标签和属性是通过内联指令注释进行配置的（例如， smartling.translate_paths 。用于标记可翻译路径，以及控制 CDATA 包装或实体转义内容是否被视为可翻译的指令）。它还支持将 Android XML 资源文件格式作为独立的解析器，并支持 XLIFF 作为一级格式——包括 XLIFF 1.2 和 XLIFF 2.0，文件格式为.xlf 。.xliff ，和.xml文件——因此 XML 内容可以通过标准 CAT 工具进行传输。
为了实现自动化，Smartling 的 GitHub 连接器会从拉取请求或提交中识别已更改的可翻译文件，将其上传到 Smartling 项目，并将翻译后的文件提交回指定的分支；更广泛的存储库连接器模式将 webhook 与轮询计划相结合，以便定期获取新的提交，而无需人工干预。对于构建自己的 CI/CD 集成的团队来说，也可以通过 Smartling 的 API 以编程方式上传和下载文件。在内容管理方面，Smartling 为 Contentstack 和 Contentful（均为无头 CMS 平台，Contentful 提供入门级和字段级集成选项）以及 Episerver/Optimizely 等平台提供预构建连接器。
在翻译质量方面，Smartling 的机器翻译会检查翻译中的占位符和标签是否与源字符串中的占位符和标签匹配，并将不匹配项标记为错误，而不是默默地发送；然后，译员和审校人员可以直接在 Smartling 的 CAT 工具中插入、复制或移动标签，以纠正引擎出错的地方。Smartling 的翻译记忆匹配功能 SmartMatch 在决定是否应重用已存储的翻译时，还会考虑占位符差异和字符限制——而且翻译记忆本身可以作为行业标准交换格式 TMX 导入和导出，供团队跨项目或系统整合记忆。
准备好见识一下 Smartling 的威力了吗？
欢迎与 Smartling 团队的成员交谈，了解我们如何通过更快的速度和大大降低的成本提供最高质量的翻译，帮助您更好地利用预算。