TranslatePress 文字转语音：实际效果解析

TranslatePress 在请求时翻译页面的渲染 HTML，并将所有译文存储在本地数据库表中。每篇文章只有一个文章 ID，语言切换通过 trp_translate() 实现，而非通过复制文章来完成。这一核心机制，直接决定了文字转语音在 TranslatePress 站点上的实现方式。

这是我们多语言 TTS 系列的第五篇，也是最后一篇。此前我们已经介绍了 WPML、Polylang、Weglot 和 GTranslate。TranslatePress 在技术层面介于它们之间，音频配置方式也体现了这一特点。

TranslatePress 与 WPML、Polylang、Weglot 的区别

WPML 和 Polylang 为每种语言创建独立的文章，每个译文都有自己的文章 ID、post_content 和固定链接。由于每种语言都是独立的 WordPress 对象，音频生成过程相对简单。

Weglot 则采用完全相反的方式。译文存储在 Weglot 的服务器上，通过代理或子域名注入页面。WordPress 数据库完全看不到翻译后的文本，这也是为什么在 Weglot 上做服务端 TTS 需要借助 JavaScript 钩子才能实现。

TranslatePress 处于两者之间。每篇文章只有一个对应条目，post_content 只包含默认语言的内容。但所有译文都存储在你的 WordPress 数据库中，位于 wp_trp_ 表里。你可以读取它们、查询它们，也可以将它们传给 TTS 引擎。这使得音频生成方式与其他四个插件都有所不同。

译文的存储位置

TranslatePress 将译文存储在以 wp_trp_ 为前缀的专用表中。每个语言对都有自己的词典表，命名格式为 wp_trp_dictionary_<source>_<target>。此外还有 wp_trp_original_strings 用于存储源字符串，以及主题和插件翻译的 gettext 表。

存储是有方向性的。英文站点的德语译文存储在英德词典中，读取时也需要指定相同的方向。你需要用到的公共函数是 trp_translate()，它接受一段内容和一个语言代码，并返回对应的译文。

if ( function_exists( 'trp_translate' ) ) {
    $translated = trp_translate( $post->post_content, 'de_DE' );
    // 将 $translated 传给 TTS 引擎，而非 $post->post_content。
}

对于 TTS 集成来说，这个函数是获取文本的唯一可靠来源。直接读取 post_content 只会得到默认语言的内容，无论访客访问的是哪个语言的 URL。TTSWP 在我们这边的处理方式，请参阅 TranslatePress 集成文档。

语言代码的常见陷阱

TranslatePress 使用完整的语言区域代码，而非语言缩写。德语是 de_DE，不是 de；法语是 fr_FR；巴西葡萄牙语是 pt_BR。任何假设使用 Polylang 风格两字母缩写的集成，在 TranslatePress 上都会静默失败。

TranslatePress 开发者文档对此有明确说明。传给 trp_translate() 的语言代码是设置页（Settings → TranslatePress → General）中的语言区域代码，不一定与 URL 中的语言缩写一致。像 de 这样的简短缩写无法匹配任何词典，函数会静默回退到原始字符串，不会给出任何警告。如果你编写了自定义代码，请在调用 trp_translate() 之前规范化语言代码，并以相同的语言区域格式存储音频文件，以便后续匹配。

URL 结构与缓存

TranslatePress 默认为每种语言使用子目录结构。英文页面位于 site.com/blog/post，德文版本位于 site.com/de/blog/post。也可以为默认语言启用子目录，使所有语言的 URL 结构保持对称。

这种结构对缓存非常友好。不同的 URL 意味着每种语言对应不同的缓存键。WP Rocket、LiteSpeed 以及 CDN 边缘缓存都将 /de/blog/post 视为独立于 /blog/post 的资源，因此德文音频文件会随德文页面一起提供，英文音频文件随英文页面提供。如有需要，我们的缓存集成文档涵盖了相关的排除规则。

需要注意的是付费版的「自动用户语言检测」插件。它会根据浏览器语言重定向访客，可能与页面缓存冲突，导致将错误的重定向响应发送给错误的用户。我们在 Polylang 那篇文章中介绍过相同的情况。TranslatePress 站点使用检测功能的较少，因为这是付费插件，但如果你启用了它，请将重定向逻辑排除在缓存之外。

播放器界面的翻译问题

这个问题是 TranslatePress 特有的。该插件能够检测并翻译由 JavaScript 插入的字符串，这一点比较特殊——大多数翻译工具都会忽略 JS 渲染的内容。TranslatePress 会在渲染后从 DOM 中捕获这些字符串，并提供翻译选项。

由此带来的副作用是：音频播放器的标签（如「播放」、「暂停」、「收听本文」）会在 TranslatePress 编辑器中显示为可翻译字符串。如果这些字符串未经审核直接被机器翻译，播放器按钮可能出现措辞别扭甚至错误的情况，更严重的是，无障碍标签被误译后会让屏幕阅读器无法正确识别。

TranslatePress 提供了两种解决方法：为不需要翻译的元素添加 data-no-translation 属性，或在「高级设置」中使用排除选择器，通过 CSS 选择器跳过整个容器。两种方法在 TranslatePress 的设置文档中都有说明。对于 TTSWP 播放器，建议通过类名排除播放器容器，让播放器标签由插件自身的语言文件来控制。

建议排除的内容

• 音频播放器容器元素
• 播放、暂停和进度控件上的 ARIA 标签
• 时间显示和时长计数器
• TTSWP 渲染的语音名称或语言名称标签

如果你想在排除播放器后重新设置其样式，我们的自定义 CSS 文档提供了相关选择器说明。

内容编辑导致的音频与译文不同步

TranslatePress 将每条译文与精确的源字符串绑定。一旦修改原文，TranslatePress 就会创建一条新的源字符串，并将现有译文与之解除关联。翻译记忆功能会建议使用旧译文，但在人工确认之前，目标语言会回退到显示源语言内容。

对于文字转语音来说，这意味着每次编辑后，音频可能与译文不同步。在英文原文中加一个逗号，就会导致该字符串所有语言的译文被解除关联。德文音频还在播放旧的句子，但页面上显示的德文文本已经是新的内容了。

编辑内容后的实用检查清单：

1. 在 TranslatePress 编辑器中，逐一确认每种启用语言的新源字符串译文。
2. 先在默认语言文章上重新生成音频。
3. 为每种语言重新生成音频，然后在各语言 URL 上播放音频，确认新文件与页面显示的文字一致。
4. 清除每个语言 URL 的页面缓存，而不仅仅是默认语言的缓存。

在 TranslatePress 站点上配置 TTSWP

以下是当前的操作流程。集成文档始终保持最新状态，请以文档为准。

1. 安装 TTSWP，从 WordPress.org 插件目录安装。安装指南提供了详细步骤。
2. 将插件连接到 TTSWP 后端。免费套餐包含欢迎积分，让你在付费前可以完整体验整个流程。详见连接你的站点。
3. 确认 TranslatePress 已激活，并且至少配置了一种使用完整语言区域代码的目标语言。
4. 为每种语言映射语音，使用语言与语音映射功能。将德语语音分配给 de_DE，将法语语音分配给 fr_FR，以此类推。语音目录请参阅语音选择。
5. 发布或更新文章。系统会先为默认语言生成音频。
6. 在每个语言 URL 上播放音频。音频按需生成。当访客第一次在次要语言页面上播放音频时，TranslatePress 会告知 TTSWP 当前激活的语言，TTSWP 随即生成并缓存该语言的音频文件。之后的播放都会直接使用缓存文件。
7. 在 TranslatePress 中排除播放器，通过 data-no-translation 属性或高级设置中的选择器，确保播放器标签由 TTSWP 自身的翻译文件控制。

TTSWP 为每篇文章的每种语言各存储一个音频文件，播放器会根据访客所在的语言 URL 加载对应的文件。访客访问 /de/blog/post 时加载德文音频，访问默认 URL 时加载默认语言音频。启用自动翻译后，TTSWP 会直接从 TranslatePress 读取译文，再发送给 ElevenLabs 处理，确保音频与访客看到的页面内容一致。

免费版与付费版 TranslatePress 对 TTS 的影响

免费版 TranslatePress 支持一种额外语言，通过 TranslatePress AI 提供 2,000 个 AI 翻译词汇量，并允许使用你自己的 API 密钥接入 Google 翻译。这足以运行一个两种语言的双语博客，并为两种语言配备匹配的音频。

付费版 TranslatePress 新增了无限额外语言、用于翻译固定链接/meta 标签和 hreflang 控制的 SEO Pack、DeepL 支持、翻译员账户、自动用户语言检测插件以及每种语言独立域名等功能。如果你的站点需要支持两种以上的语言、为搜索引擎添加 hreflang 标签，或者希望在 TTS 生成前使用 DeepL 级别的译文质量，付费版是更实际的选择。音频质量本身与使用哪个版本无关。

每语言音频的 SEO 与 AEO 优化

SEO Pack 允许你为每种语言配置 hreflang 标签，支持特定国家语言区域、与地区无关的语言，或两者兼用。对于搜索引擎和 AI 问答引擎而言，这正是识别哪段音频对应哪个地区的关键信号。

为每个语言 URL 添加 AudioObject schema 条目，并在 inLanguage 字段中填写与 hreflang 一致的值。Google 和 Bing 会识别这种语言配对关系。根据我们的实测，当 schema 结构清晰且音频 URL 可正常访问时，Perplexity 和 ChatGPT Search 等 AI 引擎更频繁地引用含音频的文章。我们在 AEO 与音频那篇文章中有更详细的介绍。

常见问题与解决方法

无障碍访问说明

当播放器支持键盘操作且标签设置正确时，音频朗读功能有助于满足多项 WCAG 成功标准。如果你在 TranslatePress 中排除了播放器，请确保 TTSWP 自身翻译文件中的 ARIA 标签保持完整。我们的 WCAG 音频指南详细介绍了相关标准，主要配置教程也是一个很好的起点。

常见问题解答

TranslatePress 支持文字转语音吗？

支持。TranslatePress 将译文本地存储在 wp_trp_ 数据库表中，trp_translate() 函数可在服务端返回翻译后的内容。TTS 集成可以读取这些译文并生成各语言的音频，前提是以文章 ID 加语言区域代码作为音频的键值，并使用完整的语言区域代码（如 de_DE），而非简短缩写。

生成音频需要 TranslatePress 付费版吗？

不需要。免费版 TranslatePress 支持一种额外语言，可通过 TranslatePress AI、带自己密钥的 Google 翻译或手动编辑来完成翻译。这对于双语站点配套生成音频来说已经足够。付费版增加了无限语言、SEO Pack、DeepL 和语言检测插件，如果你需要支持两种以上的语言或控制 hreflang，付费版更合适。

为什么播放器按钮被翻译错了？

TranslatePress 会检测 JS 插入的字符串，因此音频播放器的标签会出现在其编辑器中，并可能被机器翻译。解决方法是为播放器容器添加 data-no-translation 属性，或在高级设置中通过 CSS 选择器排除播放器容器。这样播放器标签就会改由 TTSWP 自身的语言文件来提供。

为什么音频和译文不同步了？

在 TranslatePress 中编辑原始字符串会创建一条新的源字符串，并将现有译文解除关联。翻译记忆功能会建议使用旧译文，但在你手动确认之前，目标语言会回退到源语言内容。每次编辑内容后，请在默认文章和每种语言上重新生成音频，并清除所有语言 URL 的缓存。

TranslatePress 和 Weglot 在 TTS 方面有什么区别？

Weglot 将译文存储在自己的服务器上并注入页面，WordPress 在服务端完全无法看到翻译后的文本。TranslatePress 将所有译文存储在本地数据库中，并通过 trp_translate() 提供服务端访问接口。因此，在 TranslatePress 上生成各语言音频比在 Weglot 上更直接。

下一步操作

从 WordPress.org 插件目录安装文字转语音 - TTSWP，将其连接到你的账户，并为 TranslatePress 中已配置的每种语言分配一个语音。发布一篇文章，在每个语言 URL 上播放音频，确认音频与页面显示的文字一致。如果出现不同步的情况，TranslatePress 集成文档是首先要查看的地方。