在处理内容管理系统 (CMS) 本地化时，需要注意的是，各个公司的策略会有很大差异。 适合某个供应商或业务合作伙伴的方法可能并不适合您自己的需求。
您的计划大部分将取决于与您的CMS兼容的本地工具。 在从事 CMS 本地化项目时，有两个主要因素将决定您的策略——您使用的平台和导入/导出文件类型。
CMS 本地化通过内容和导入/导出文件类型
有四个主要的 CMS 被一致使用： Adobe Experience Manager、WordPress、Drupal 和 Sitecore。 每个选项都需要不同的体系结构方法和用于导入和导出文本的特定文件格式。
Adobe Experience Manager （AEM）
AEM有一个翻译框架，该框架是程序的本机部分。 这意味着整个架构已经可用；你只需要配置它。 完成后，您可以享受近乎自动的本地化过程，在这个过程中，您可以导入和导出将以可预测方式呈现的 XML 文件，从而减轻开发人员的负担。
WordPress
WordPress 没有原生翻译框架。 您可以使用连接器或 WordPress 多语言插件，但您必须自己构建架构。 然而，由于这是一个如此受欢迎的平台，许多翻译机构，包括 Bureau Works，已经开发了自己的连接器和程序来建立多语言网站翻译的架构。
Drupal
Drupal 在翻译功能方面与 WordPress 非常相似，但基于模块而不是插件运行。 用户需要下载的第一个模块之一是国际化模块，它将支持多语言的分类和菜单系统。
Sitecore
Sitecore，与AEM类似，将本地化作为其平台的关键重点，通过内容树系统进行管理。 用户可以为每个区域设置单独的树，或者为所有内容使用共享的树。 他们还可以采用混合方法，同时使用共享树和孤立树。 这允许根据语言更灵活地更改内容和结构。 选择 CMS 时，重要的是要考虑它如何处理您使用的导入/导出格式。 这将决定在翻译 CMS时保留代码的难易程度。 在翻译中，您将看到四种常见格式：
可扩展标记语言 (XML)
这种格式既可供人类阅读，也可供机器读取，使其在翻译项目中非常有用。 在使用适当的标签和分段时，区分代码和内容相对容易。
JavaScript 对象表示法（JSON）
与 XML 一样，JSON 也是人类和机器可读的。 JSON 在信息传输中特别有用，因此它通常是 CMS 中的默认选项。
超文本标记语言（HTML）
HTML 可能是最熟悉的编码格式之一，因为它在网页中是标准使用。 翻译 HTML 文件可能有点挑战，但有一个 translate 属性，允许用户标记要翻译的文本和要避免的文本。
逗号分隔值（CSV）
CSV 不应用于翻译，因为这种格式主要由逗号分隔的文本数据组成。 系统无法区分语法逗号和代码相关的逗号，因此很容易破坏翻译文件。翻译您的内容的整个策略将依赖于这两个因素。 每个 CMS 都需要不同的方法，每种文件格式也是如此。 您还必须考虑您的总体目标、语言以及每个页面所需的灵活性。 总的来说，这是一项需要谨慎方法的巨大工作。
从小处着手以实现本地化成功
无论您选择什么平台或文件类型，有一个适用于任何项目的 CMS 本地化最佳实践——采取缓慢而稳定的方法。 不要尝试一次性翻译一个500页的大型网站；可以从一些登陆页面和其他高优先级内容的小规模开始，并使用这些内容进行测试。 这将允许您提前解决错误并解决问题。
CMS 本地化是一项巨大的任务，但正确的策略和工具将帮助您简化它。 这就是为什么与熟悉大多数（如果不是全部）平台和文件类型的来龙去脉的翻译公司合作很重要的原因。 这样，您可以确保您的内容和代码都能成功过渡到新市场。
Unlock the power of glocalization with our Translation Management System.
Unlock the power of
with our Translation Management System.
