DeepL、Google 翻译与 AI：哪个最适合 .po 文件？

从您的 WordPress 插件导出 .pot 文件，将数百个字符串粘贴到 DeepL 或 Google 翻译中，得到整齐的德语译文，将其放入您的 .po 文件，编译并发布。然后用户报告说，购物车页面本应显示产品名称的地方却显示了原始的 %1$s，更糟糕的是，由于复数形式崩溃，所有语言的价格行都显示“You have 1 items”。翻译的质量可能没问题。但翻译的结构被破坏了。

当源文件是 gettext .po 文件而不是一段散文时，这就是 DeepL 与 Google 翻译之争的核心矛盾。两者在翻译自然句子方面都是世界一流的。但它们都不是为了尊重 printf 占位符、Gettext 复数数组或 msgctxt 消歧而设计的。它们将 %1$s 视为需要清理的打字错误，并将双重复数形式扁平化为单个句子。对于营销文案，这可能不易察觉。但对于软件本地化，它会导致网站出错。

本文将经典机器翻译（DeepL 和 Google 翻译）与专为 gettext 构建的上下文感知 AI 流程进行比较。我们将探讨对 .po 文件真正重要的方面：占位符处理、复数形式、上下文、批量文件支持和成本。如果您想深入了解 LLM 与 LLM 之间的质量讨论，我们已在AI translation quality: Gemini vs GPT-4 vs DeepSeek中进行过探讨。在这里，问题更具体、更实际：哪个最适合 .po 文件？

DeepL 与 Google 翻译：它们为何而生

两者都是通用机器翻译引擎，旨在提供流畅、自然的语言输出。它们都不会解析文件格式。

DeepL - 流畅，但对格式视而不见

DeepL 因其最自然的输出而广受赞誉，尤其是在欧洲语言之间。但它处理的是文本，而非结构。如果给它一个包含 %1$s ordered %2$s 的 .po msgid，它会在占位符周围翻译单词，同时经常重新排序、添加空格或删除这些标记——因为对 DeepL 来说，它们只是句子中奇怪的字符。

Google 翻译 - 广泛覆盖，同样的盲点

Google 翻译支持更多语言，并且是 GTranslate 等插件背后的经济实惠的默认选择。其占位符处理能力也同样糟糕。这两种引擎都存在相同的根本性局限：它们优化句子的流畅度，但不理解 gettext 规则。

真正的问题不在于质量，而在于结构

对于 .po 文件而言，纯粹的语言质量只是基本要求。导致生产中断的是结构完整性：变量是否能保留下来、复数形式是否能保持多重形式、上下文是否能得到尊重。这正是上下文感知的 gettext AI 流程超越 DeepL 和 Google 翻译的地方。

为什么占位符和复数形式会破坏机器翻译

.po 文件不是散文。它是接近代码的文本，具有严格的规则，其中有三条规则经常让经典机器翻译束手无策。

占位符和变量的损坏

WordPress 字符串中充满了 printf 风格的占位符：%s、%d，以及像 %1$s 和 %2$s 这样的位置形式。位置占位符很重要，因为有些语言会重新排列句子，数字会告诉 sprintf 哪个参数放在哪里。看看经典机器翻译会怎么处理这个：

// Source string in your .po file
$msg = sprintf( __( '%1$s left a comment on %2$s', 'mytheme' ), $user, $post );

// What DeepL / Google Translate often return (German):
// "%2$s hat einen Kommentar zu %1$s hinterlassen"  <- reordered, OK
// "% 1$ s hat einen Kommentar..."                   <- spaces injected, BROKEN
// "hat einen Kommentar hinterlassen"                <- placeholders dropped, BROKEN

一个注入的空格（% 1$ s）或一个丢失的标记会引发 PHP 警告，或者向您的用户显示原始代码。我们已在how to translate PO files without breaking code variables中深入探讨了这种故障模式。

复数形式崩溃

Gettext 复数不是一个字符串——它们是按语言复数规则索引的数组。英语有两种形式；波兰语有三种；阿拉伯语有六种。经典机器翻译将 msgid_plural 视为两个独立的句子并独立翻译它们，不清楚它们必须保持一个连贯的多形式集合。结果通常是单一形式被复制，因此 1 item 和 5 items 渲染结果相同。

msgid "%d item in your cart"
msgid_plural "%d items in your cart"
msgstr[0] ""
msgstr[1] ""
# A gettext-aware pipeline fills BOTH forms correctly with %d preserved.
# DeepL/Google translate each line in isolation and lose the plural relationship.

上下文 (msgctxt) 被忽略

Gettext 使用 msgctxt 来区分相同的字符串——例如名词“Post”与动词“Post”，或 WooCommerce 中名词“Order”与动词“Order”。经典机器翻译从不识别该上下文字段，因此它会进行猜测，并且无论字符串出现在何处，每次都会以相同的方式猜测。

这种损害在商业领域会倍增。WooCommerce 产品目录中充满了短而模糊的字符串——“Order”、“Ship”、“Free”、“View”——错误的理解会导致按钮显示错误的文本，与顾客的语言不符。由于 DeepL 和 Google 翻译孤立地翻译每个字符串，它们无法使用 gettext 特意编码的周围上下文。能够读取 msgctxt 的格式感知型流程可以精确解决这些歧义，这也是为什么它在翻译错误可能导致实际销售损失的商店页面上尤为重要。

.po 文件的上下文感知 AI 方法

一个专门构建的 gettext 流程不仅翻译单词——它理解文件格式并保护其结构。这是类别级别的差异，这也是为什么正确的比较根本不是 DeepL 与 Google 翻译，而是经典机器翻译与格式感知型 AI 工作流的对比。

语法锁定保护每个标记

决定性技术是 Syntax Locking。在任何文本到达 AI 之前，每个变量（%s、%1$s、{name}）、HTML 标签和代码标记都被锁定并暂时移开。模型只看到并重写人类可读的词语。翻译完成后，锁定的标记会恢复到其正确位置。这种 % 1$ s 损坏根本不会发生，因为 AI 从未接触过占位符。这是经典机器翻译在结构上所缺乏的安全网——我们在manual vs AI translation: is AI safe for WordPress localization中详细阐述了这一点。

全面的复数和上下文支持

上下文感知的 gettext 流程将 msgid_plural 作为一个集合来读取，并根据目标语言的复数规则生成所有必需的形式，同时保持所有形式中的占位符完好无损。它还会读取 msgctxt 并将其用作上下文，因此名词“Order”和动词“Order”会进行区分并正确翻译。

批量文件处理，而非复制粘贴

DeepL 和 Google 翻译是即贴即用工具（或基于字符的 API）。云端 .po 工作流会摄取整个文件——通过 Smart Batching，10MB 以上的 WooCommerce 字符串包会被分块、并行翻译并合并，而复制粘贴方法在此之前就已崩溃。您只需上传一个文件，即可下载 .po + .mo + 更多文件，而不是手动拼接列。

DeepL、Google 翻译与 Gettext 感知 AI：结论

对于纯文本散文，DeepL 和 Google 翻译非常出色。对于 .po 文件而言，决定生产安全的关键因素是占位符、复数形式、上下文和批量处理——而这正是格式感知型流程更胜一筹的地方。

对比表格

如何选择

如果您正在翻译博客文章或营销页面，可以选择 DeepL 来捕捉语气。如果您正在翻译用于运行中的 WordPress 网站的 .po 或 .pot 文件，流畅度不是决定因素——结构完整性才是。一个上下文感知的 gettext AI 流程为您提供两者兼顾：强大的语言质量以及在编译 .mo 文件后仍能保持完好的占位符、复数形式和上下文。

表格还低估了工作流程成本。通过 DeepL 或 Google 翻译处理整个插件意味着将字符串列复制到框中，再将结果粘贴回来，并手动重新检查每个占位符——这是一个繁琐、容易出错的过程，每增加一种语言就会变得更糟。基于文件的流程将其简化为一次上传和下载，不仅返回 .po 文件，还会返回编译好的 .mo 文件及其他格式，打包在一个 ZIP 文件中，因此您发布的文件就是 AI 生成的文件——无需手动重新组装，从而避免引入新的错误。

总结

对于 .po 文件，DeepL 与 Google 翻译问题的坦诚答案是，您问错了对象。两者都是出色的散文翻译工具，但对 gettext 的结构视而不见——它们会损坏 %1$s、扁平化复数形式并忽略 msgctxt，因为它们从未被设计用于读取翻译文件。对于软件本地化，这就是干净发布与购物车页面崩溃之间的区别。

一个带有 Syntax Locking 的上下文感知 AI 流程彻底改变了这种比较。它在保持您期望的 DeepL 或 Google 翻译流畅度的同时，确保每个变量、复数形式和上下文注释都完好无损地保留——这样您的翻译网站才能正常运行，而不仅仅是读起来通顺。

准备好翻译 .po 文件，避免占位符损坏或复数形式崩溃了吗？免费试用 SimplePoTranslate——无需信用卡。上传您的 .po、.pot、.json 或 .xliff 文件，即可在免费套餐中获得 gettext 安全的 AI 翻译。