翻译 Elementor 和 Divi 模板，同时不破坏布局

你做的一切都是正确的。你购买了一个高级主题，找到了 .po 文件，仔细地进行了翻译，并将 .mo 文件上传到你的语言文件夹。主题头部中的字符串更新正确。页脚显示为西班牙语。你的 WooCommerce 结账页面已本地化。但当你打开首页时，所有用 Elementor 构建的标题、按钮和文本块仍然是英文的。

你检查了 .po 文件。你可以看到代码中的英文字符串。你重新翻译。没有任何变化。你清除缓存。没有任何变化。你说服自己有些东西坏了，直到论坛里有人温和地指出：Elementor（以及 Divi、Beaver Builder 和 Bricks）不将内容存储在 .po 文件中。它们从来就没有这样做过。你一直在与一个用你当前方法无法解决的问题作斗争。

本指南解释了为什么页面构建器内容在架构上与主题和插件内容不同，翻译它的两种途径，以及如何在翻译过程中保持小部件标记的完整性，以便你精心设计的布局不会散架。

为什么 Elementor 和 Divi 不使用 .po 文件

.po 文件存储代码中存在的字符串——例如散布在 PHP 模板中的 __( 'Shop', 'mytheme' ) 调用。构建工具 WP-CLI 可以将这些字符串提取到 .pot 模板中，译者在 .po 文件上工作，并且编译后的 .mo 文件在运行时加载。

页面构建器内容是不同的。当你在 Elementor 标题小部件中输入“欢迎光临我们的商店”时，该文本不在任何 PHP 文件中。它以 JSON（Elementor）或短代码块（Divi）的形式保存在 wp_postmeta 表中，并与你放置它的帖子关联。

页面构建器内容实际存储在哪里

Elementor 将每个页面的小部件树存储在 _elementor_data 键下的 postmeta 中。在数据库中打开任何帖子，你都会找到一个 JSON 数组，描述每个部分、列和小部件，其中包含内联设置和内容：

{
  "id": "a1b2c3",
  "elType": "widget",
  "widgetType": "heading",
  "settings": {
    "title": "Welcome to our store",
    "size": "xl",
    "header_size": "h1"
  }
}

Divi 将其页面内容存储为嵌入在 post_content 中的短代码：

[et_pb_section][et_pb_row][et_pb_column type="4_4"]
  [et_pb_text]Welcome to our store[/et_pb_text]
[/et_pb_column][/et_pb_row][/et_pb_section]

Bricks、Beaver Builder 和 Oxygen 也遵循相同的模式，使用它们自己的格式。所有这些内容都不会被 .po / .mo 文件触及。

.po 文件中实际存储了什么

页面构建器插件本身包含 UI 字符串——编辑器中的按钮标签、错误消息、管理通知。这些字符串位于 .po 文件中，并确实会被 wp-content/languages/plugins/ 中的 .mo 文件翻译。这通常是人们感到困惑的原因：他们翻译了“Elementor”字符串，并看到西班牙语的编辑器 UI，但他们用这些小部件构建的实际内容仍然是英文的。

这种区别也是我们 翻译未显示故障排除指南 中一半工单的根本原因——读者期望 .mo 文件会影响他们在前端看到的内容，但内容在数据库中，而不是在代码中。

.po 文件在页面构建器网站上实际覆盖了什么

让我在这两者之间划清界限，以便你确切知道每种文件类型处理什么。

.po / .mo 文件翻译

• 主题的模板字符串：get_template_part、header.php、footer.php、functions.php 中硬编码的文本。
• 插件 UI 字符串：WooCommerce 结账、Yoast 管理标签、Contact Form 7 字段标签。
• 页面构建器插件 UI：Elementor 编辑器按钮、Divi 保存确认消息。
• 插件回显到前端的动态字符串：WooCommerce 的“添加到购物车”、“缺货”、购物车总计。

.po / .mo 文件不翻译

• 输入到 Elementor 小部件中的标题、段落、按钮文本。
• Divi 模块中的图片说明、悬停效果、手风琴标题。
• 可重用模板、全局部分、已保存区块中的内容。
• 构建器小部件中的自定义 CSS 标签或内联脚本。

这就是为什么主题作者关于翻译的文档在技术上是正确的，但对最终用户来说却常常毫无用处。我们的 如何本地化任何 WordPress 主题 指南全面涵盖了主题方面的内容——本篇文章从那里开始。

页面构建器本地化的两种途径

翻译页面构建器内容恰好有两种方式，并且两者都有实际的权衡。

途径一：按语言复制页面

使用像 WPML、Polylang 或 TranslatePress 这样的多语言插件。它会为每种语言创建一个页面的副本。在 Elementor 中，你复制整个布局，并在每个副本上替换文本。在 Divi 中，你复制短代码块并翻译标签之间的文本。

优点：每种语言都可以有独立设计的布局（当翻译文本较长并破坏原始设计时很有用）。与页面构建器的可视化编辑器完全兼容。

缺点：线性扩展——5 种语言意味着 5 倍的布局工作量。任何设计更改都必须应用 5 次。数据库快速增长。缓存变得更加困难。

途径二：字符串翻译层

一些插件（Polylang Pro、WPML 的 String Translation 模块、TranslatePress）可以暴露页面构建器小部件中的单个字符串进行翻译，然后在渲染时进行替换。你维护一个布局，插件会原地翻译字符串。

优点：布局的单一真实来源。设计更改应用于所有地方。

缺点：当翻译文本长度变化很大时，灵活性较低。某些小部件（包含嵌套内容、动态列表、表单的复杂小部件）不会清晰地暴露字符串。每次渲染的性能开销。

我们的 Polylang vs WPML vs TranslatePress 比较 更详细地涵盖了每个插件的权衡。

在翻译过程中保持小部件标记的安全

无论你选择哪种途径，翻译后的内容都必须保留构建器的结构标记。如果你的译者剥离 Elementor 短代码、替换数据属性或重新排序嵌套标签，小部件将无法正常渲染。

Elementor 危险区

Elementor 小部件在文本设置中嵌入短代码和动态标签。标题小部件的标题字段可能包含：

Welcome to <strong>our</strong> [user_name] store

那个 [user_name] 是一个动态标签——Elementor 在渲染时会将其替换为登录用户的姓名。如果翻译损坏了它，用户将看到字面上的“[user_name]”。

按钮内部的图标使用类属性，这些属性不能被翻译。图片的 alt 文本与图片 URL 是分开存储的。列布局使用断点特定的设置（title_mobile、title_tablet），需要单独处理。

Divi 短代码嵌套

Divi 短代码深度嵌套：[et_pb_section][et_pb_row][et_pb_column][et_pb_text]。如果译者将短代码块视为纯文本，则会编码方括号、翻译属性值或丢失结束标签。这些操作中的任何一个都会破坏模块，并且 Divi 将拒绝渲染它。

安全模式

对于任何一种构建器，翻译都必须：

1. 解析小部件格式（Elementor 为 JSON，Divi 为短代码 AST）。
2. 遍历树结构，仅识别用户可见的文本字段。
3. 锁定短代码、动态标签、HTML 属性和内联 CSS。
4. 仅将文本表面连同上下文一起发送给译者。
5. 将翻译后的文本重新插入到原始结构中。

这与我们的引擎应用于 .po 文件的原则相同。在不破坏代码变量的情况下翻译 .po 文件指南 详细介绍了 %s 和占位符模式——页面构建器的等效是短代码和动态标签。

真正有效的混合工作流程

对于大多数团队来说，实际的答案是结合这两种方法。

步骤 1：通过 .po 文件翻译主题和插件 UI

从你的主题和主要插件（WooCommerce、Yoast、页面构建器 UI）导出 .pot 文件。通过尊重 .po 格式的云翻译工具翻译它们一次。将编译后的 .mo 文件放入 wp-content/languages/。这可以处理你网站 80% 的界面字符串，并且几乎无需持续维护。

步骤 2：为动态内容选择一个多语言插件

安装 Polylang 或 WPML 来处理文章、页面和产品内容。配置 URL 结构（/es/、/fr/）和 hreflang 标签。这为你提供了按语言存储数据库内容的基础设施。

步骤 3：选择性地复制你的页面构建器模板

对于高流量的着陆页、首页和基石营销内容，复制每个语言的页面并手动翻译小部件。在重要的地方，你可以获得完全的设计控制权。

步骤 4：对重复区块使用字符串翻译

对于全局部分、可重用模板以及出现在每个页面上的页脚 CTA，使用你的多语言插件的字符串翻译功能。在一个地方更新，在渲染时替换。

步骤 5：进行质量检查

翻译后的页面构建器内容应在不发生布局偏移的情况下渲染。较长的语言（德语、俄语）会破坏按钮宽度。较短的语言（中文、日语）会留下尴尬的空白。在发布之前，针对每种语言测试每个模板。

常见陷阱及如何避免

在每个页面构建器本地化项目中都会出现的一些陷阱。

图片 Alt 文本不翻译

Elementor 和 Divi 都按小部件实例存储 alt 文本，而不是在媒体库中。翻译原始图片并不会翻译使用该图片的每个小部件中的 alt 文本。在每个复制的页面中更新 alt 文本。

表单和自定义字段

嵌入在页面构建器小部件中的联系表单有其自己的字符串（标签、占位符、验证消息）。有关表单方面的信息，请参阅我们的 关于翻译 Gravity Forms 和 Contact Form 7 的指南。

全局小部件和模板

对全局模板的更改会传播到使用它的每个页面，包括翻译后的副本。根据你想要共享内容还是单独内容，这可能是有用的，也可能是灾难性的。每个模板明确决定。

翻译缓存过期

页面构建器积极地缓存渲染的 HTML。翻译后，清除所有缓存，包括 Elementor CSS 缓存（Elementor > Tools > Regenerate CSS）和 Divi 静态 CSS 缓存。

总结

翻译使用 Elementor 或 Divi 构建的网站并不比翻译静态主题更难——它只需要正确的思维模型。主题和插件字符串存储在 .po 文件中并通过 .mo 文件传输。页面构建器内容存储在数据库中并通过多语言插件或手动复制传输。混淆这两种途径是“为什么我的翻译不起作用”这种挫败感的唯一最常见来源。

成功的工作流程是枯燥的：对于代码中存在的所有内容使用静态 .mo 文件，对于页面内容使用多语言插件，对于高价值着陆页进行手动管理。没有一个工具可以处理所有这三者，任何向你承诺其他方案的人都在向你推销一些东西。

准备好在不破坏小部件标记的情况下翻译你的主题和插件 .po 文件了吗？免费试用 SimplePoTranslate - 无需信用卡。上传 .po 文件，下载安全翻译，放入 wp-content/languages/。