将 Sitecore 网站翻译成其他 4 种语言的最有效方式（Sitecore CMS 中没有译员）答案

【问题标题】：Most efficient way to translate a Sitecore website to 4 other languages (Not having the translators in you Sitecore CMS)将 Sitecore 网站翻译成其他 4 种语言的最有效方式（Sitecore CMS 中没有译员）
【发布时间】：2011-11-17 07:46:23
【问题描述】：

我正在寻找一种将现有 Sitecore 安装（提供英语）翻译成其他 4 种语言（俄语、中文、葡萄牙语等）的好方法。专门的翻译公司会将我们提供的所有文本翻译成指定的语言，但我很好奇其他公司是如何设置的。我想只使用 Sitecore 中的数据库语言导出功能导出所有必须翻译的 Sitecore 项目，并让翻译公司编辑这些文件。通过替换 XML 中的语言标签，我们应该能够将该文件作为新创建的其他语言导入，但是我担心这种 XML 结构对于翻译公司来说完全没用，而且它们会淹没在里面的代码中这个 XML。我们怎样才能有效地做到这一点？除了让这些翻译人员访问 Sitecore 环境并让他们在这里编辑语言之外，还有其他方法吗？任何共享源模块来实现这一点？我还有很多问题，有没有人有这方面的经验？

【问题讨论】：

您打算翻译多少内容？
一个完整的 Sitecore 网站，假设有大约 300 / 400 个页面项目和不同的字典设置。

标签： localization sitecore

【解决方案1】：

您的主要选择是语言导出/导入功能（正如您所提到的），或者与您的翻译机构的翻译管理系统集成的基于工作流的解决方案（如果他们有 - 希望他们有）。

前者更适合初始翻译。通常，您的代理机构应该能够处理 XML 文件中的内容翻译。一个好的可以。如果您事先创建所有需要的语言版本并将英文内容复制到其中，这将使文件更易于使用，因为它们中已经包含新语言的标签。我已经看到使用 Revolver (http://www.codeflood.net/revolver/) 创建这些层，但也可以使用自定义代码或工作流来完成。

对于翻译内容的持续维护，您可能希望通过工作流程进行集成。 Clay Tablet Technologies (http://www.clay-tablet.com/) 有一个带有 Sitecore 集成的中间件组件，可以使这更容易，具体取决于您的翻译机构。您还可以使用允许您的用户发送内容进行翻译的工作流命令进行自己的基于工作流的集成。然后你需要某种监听器来拉回翻译的内容，并继续工作流程。

希望这会有所帮助！

【讨论】：

同意@techphoria414 - 要么找到某种方式他们可以读取导出的语言文件，要么在翻译步骤中构建并作为工作流程设计的一部分进行访问。我假设您将需要随着时间的推移维护这些页面，所以现在整理这个过程可能是最好的。

【解决方案2】：

您还可以查看 Lionbrdige (http://en-us.lionbridge.com/sitecore-and-lionbridge-announce-partnership-to-help-companies-thrive-across-borders.htm) 作为解决方案。

根据我自己的经验，我们的客户通常使用 Sitecore 导入/导出功能作为第一步，然后使用 Lionbridge 或 Clay Tablet 作为服务。

翻译时要考虑的一件重要事情是正在进行的工作。最初的翻译比较简单，但第二次等可能会比较麻烦。如果用不同的语言进行了不同的更改会怎样。如果在法语版本的内容中进行了本地更改，您不能只发送英文版本（然后是第二个翻译），因为您还必须适应内容的区域变化。

【讨论】：

【解决方案3】：

与全球数十个 Sitecore 客户合作，并帮助从所有最大的和许多较小的翻译公司获取内容，我可以证明尝试在 Sitecore 进行现场翻译的效率低下。我把它比作让电工过来给你的房子重新布线，但是当他们从卡车上拿工具箱时，你告诉他们，“不——你需要手工做”。

管理超过一页或两页翻译内容的最佳方式是无缝导出。以适当的格式（XML 或 XLIFF）将其交付给 LSP，并在可能的情况下将其自动导入到他们的 TMS。翻译完成后，内容应该会无缝地流回 Sitecore。

您可以自己编写代码 - 但仅在 Sitecore 方面，陷阱并非易事。（如果您想要直观的 UI、可扩展性以及满足翻译需求的所有功能）。更不用说连接到系统 LSP 使用的挑战了。（例如，谁知道使用 SLD 的 Nexus 连接器与使用 CTA 连接到 TMS 的相对优点/风险？）

如上所述，有一些商业解决方案可以满足所有这些需求，甚至更多。因此，如果您有少量的内容 - 并且想将其发送给您选择的任何翻译提供商 - 我很乐意讨论我们如何提供帮助。

【讨论】：

【解决方案4】：

翻译的主要问题根本不是技术问题，XML 导出是一种足够简单的格式，所有机构都应该能够毫无问题地处理它。正如其他人所建议的那样，初始翻译后的维护问题稍微大一些，但他们也指出了实现这一目标的工具。

我们在翻译中发现的主要问题实际上是语言方面的：如何实现措辞的一致性，既要与原文相匹配，又要充分适应当地要求。翻译公司通常有软件来帮助这一点 - 他们翻译的短语库等 - 使用导出的 XML 文件不会提供在原地查看内容的上下文。特定项目可能会被正确翻译且网站始终如一，但由于每个页面可能由多个项目构建而成，因此呈现的内容之间很容易发生冲突。

这使得使用 Sitecore 后端（可能使用限制字段安全设置）或在页面编辑器中（可能使用英文值预先填充字段）成为一个可行的想法。

【讨论】：

作为项目经理和软件开发人员曾在语言服务提供商工作过，我可以告诉你，每一位称职的翻译人员都会对在基于 Web 的系统中工作感到畏缩。如果您习惯了，这相当于必须在记事本中编写代码。视觉工作室。这需要更多时间，引入更多错误，最终会让客户付出更多代价。
这可能有点苛刻。关键是，在使用 Sitecore 时，翻译材料在导出时会在很大程度上脱离上下文。我当然不是说使用 Sitecore 界面总是最好的选择，只是说其他选项可能存在 Sitecore 特定的缺点，值得考虑。
如果目标是产生一致的翻译，那么在翻译人员无法使用他们习惯使用的工具（包括翻译记忆库、完善的 QA 工具等）的环境中工作是直接冲突的到那个。是的，上下文很重要，基本上任何软件本地化都可能受此影响。但我向您保证，与强制翻译在 CMS 中就地完成相比，有更好的方法来处理这个问题（例如客户评论和反馈）。
我不认为我曾经提到过强制翻译在 CMS 中完成，只是提到这是一个“可行的想法”，尤其是在大部分翻译已在外部完成并导入后进入系统。它的可行性取决于需要完成的翻译量、网站的复杂性、更新频率、您的翻译人员（专业的外部翻译人员，或对他们正在翻译的内容有详细业务知识的内部网站管理员）和需要如何针对自己的市场进行本地化）以及他们习惯使用的工具。