WPML 即将推出对页面构建器的翻译支持

两天前，我们进行了一项调查，询问您希望如何翻译使用页面构建器设计的网站。在本文中，我想分享一下调查结果，以及这将如何影响我们即将推出的 WPML 3.6 的开发。

背景信息 – 目前我们推荐如何翻译使用页面构建器的网站

对于除 Toolset Layouts （在新标签页中打开） 之外的所有页面构建器，目前唯一的翻译方法是为每种语言创建单独的设计。

这虽然可用，但不太方便。我们认为，如果只设计一次即可适用于所有语言，并且仅使用 WPML 翻译文本，将会更加简单。顺便说一下，我们正在完善有关如何翻译 Toolset 中所有内容（包括布局）的文档。准备就绪后，我会撰写相关文章。

问：您对目前翻译使用页面构建器创建的内容的方法满意吗？

实际上，有些人更喜欢为每种语言进行单独设计。当需要调整整个设计时，这是有道理的。我想，如果您对网站首页有非常精确的设计，那么针对每种语言进行调整和优化是合理的。

大多数人对我们现有的方法表示认可，但更倾向于采用单一设计并使用 WPML 进行翻译。此外，也有人表示这种方法对他们不适用。我认为这些是使用专业翻译服务商的人。我同意，要求外部译者去修改您的页面构建器设计几乎是不可能的。在将 WPML 与众多专业翻译服务商集成时，我们也遇到了这些问题。

问：您经常使用哪些页面构建器？

在使用页面构建器的网站中，近 60% 使用 Visual Composer。接下来非常受欢迎的构建器是 Divi 和 Avada。其他的也相当受欢迎。

翻译流程将是怎样的？

由于我们已经将其完全集成并与 Layouts 插件配合使用（尽管文档仍在“编写中”），我将以 Layouts 为例。

步骤 1）在页面构建器中进行设计

正如我所解释的，您只需在页面构建器中设计一次。相同的设计将用于所有翻译。

步骤 2）发送至翻译

当页面使用页面构建器时，您需要对其进行“两次”翻译。第一次是页面本身，包括页面标题和您使用的任何自定义字段。第二次是页面构建器设计。我知道这有点麻烦。我们将努力实现自动化，但可能不会在第一轮中实现。

前往 WPML → 翻译管理。在那里，您将看到页面构建器设计的新内容类型。选择您要翻译的设计并发送至翻译。您可以浏览网站的不同元素并将其添加到翻译篮。当您完成挑选需要翻译的内容后，前往 WPML → 翻译管理 → 翻译篮，并将所有内容作为一个批次一起发送。您可以在本地（使用 WPML 的翻译编辑器）进行翻译，或者发送给您喜欢的专业翻译服务商进行离线翻译。

步骤 3）翻译

您将并排看到属于设计的所有文本。您只需翻译文本，而无需翻译结构。翻译并将每个字段标记为“完成”。保存时，翻译将自动应用到页面构建器设计中。

步骤 4）在前端查看结果

当您查看内容时，您的翻译将出现在前端。您不会在页面构建器中看到任何翻译，因为翻译不会改变它。

步骤 5）在设计更新时更新翻译

如果您在页面构建器中编辑设计，请前往翻译仪表板并重新发送至翻译。只有修改过的文本才会显示以供翻译。

WPML 集成页面构建器翻译的路线图

我们首先从 Visual Composer 的集成开始，遗憾的是，它是最不方便集成的。VC 将设计作为简码存储在“内容”中。这些简码没有 ID，因此很难将元素与其文本关联起来。我们将尝试与 VC 作者合作，向单元格添加 ID。无论如何，我们将使用一种根据内容识别字符串的后备方法。这意味着如果文本发生更改，您需要从头开始翻译，因为我们无法知道在您编辑单元格之前该文本是什么。我们将尽最大努力向 VC 单元格添加 ID。希望您能理解，这并不完全在我们的掌控之中。

其他页面构建器的工作方式不同。它们将构建器设计与“内容”分开存储，并且单元格具有唯一标识符。因此，当您编辑单元格时，您将看到之前的翻译并可以直接更新它。

WPML 3.6 肯定会包含对 Visual Composer 的支持。我们也会尝试加入对 Divi 的支持。作为此发布周期的一部分，我们还将编写有关如何在页面构建器中注册字符串以供翻译的详细文档。这非常简单，只需要妥善记录即可。

然后，我们将与所有其他页面构建器的开发者合作，将此类支持集成到他们的产品中。

有反馈意见？

您觉得怎么样？我相信有些人会希望我们先开发其他页面构建器。我们必须确定优先级，因此我们从大多数人使用的构建器开始。我们将确保最终覆盖所有页面构建器，宜早不宜迟。我想听听您对翻译流程和整体计划的反馈。如果您有任何想法、问题或建议，请留下您的评论，我会回复您。