2021 年初，一位德国电商客户来到 Seahawk，提出的需求基本上是这样的："我们需要把 WooCommerce 店铺翻译成英语、法语和波兰语。到三月底。"当时是十一月。而人工翻译的预算，说得委婉点，方向错了。我们之前在几个项目中用过 Google Translate 的 API，说实话，除了按钮标签之外，输出质量令人尴尬。所以我开始寻找替代方案。
那时候我才真正深入研究 DeepL。我之前在一些开发论坛里见过它的名字，但没有当回事。这是我那五年里犯的最大错误。我把相同的产品描述同时通过两个 API 运行，然后把输出并排展示给客户看，结果一目了然。我们在圣诞节前用三种语言上线了这家德国店铺，六个月后客户轻松添加了荷兰语，到现在那个项目仍然是我在别人问什么叫好的 API 集成时会指向的案例。DeepL. I'd seen it mentioned in a few developer threads but hadn't taken it seriously. Biggest mistake I made in that half-decade. Once I ran the same product descriptions through both APIs and showed the client side-by-side output, there was no contest. We shipped the German store in three languages before Christmas, the client added Dutch six months later without breaking a sweat, and that project is still one I point to when people ask what good API integration looks like.
这篇文章讲的是将 DeepL 集成到网站的实际情况。不是营销文案。是真实的实现决策、成本模型、陷阱，以及我在开始前会对过去的自己说什么。
为什么 DeepL 真的击败了其他选择
我直言不讳：对于欧洲语言，DeepL 属于另一个档次。这个模型在欧洲议会语料库和其他高质量平行文本上进行了大量训练，你在德语、法语、西班牙语、意大利语、荷兰语、波兰语和葡萄牙语的输出中能立即感受到这一点。句子结构看起来是经过推敲的，而不是简单的词汇替换。
Google Translate 的 API（v2 和 v3）更便宜，支持的语言也更多。截至 2024 年中期，Google 支持 133 种语言，而 DeepL 仅支持 29 种。如果你需要斯瓦希里语或孟加拉语，DeepL 根本无法胜任。但如果你的客户在扩展到欧盟或日本市场（DeepL 的日语翻译水平确实很高），那么仅仅出于习惯而默认使用 Google 就是在帮倒忙。
另一个没人充分讨论的问题是：DeepL 的正式程度参数。你可以设置 formality=more 或 formality=less，API 会相应地调整输出的语气。这对德语尤其重要，因为 du/Sie 的选择不是小事。DTC 时尚品牌需要的语气与 B2B SaaS 公司完全不同。我有些客户在翻译文本中注意到了这种区别，甚至不用我指出来。formality parameter. You can set formality=more or formality=less and the API will adjust the register of the output accordingly. That matters enormously for German, where du/Sie isn't a minor stylistic choice. A DTC fashion brand wants a different register than a B2B SaaS company. I've had clients notice this distinction in their translated copy without me even pointing it out.
在做决定之前先理解成本模型
DeepL 按翻译字符数收费。免费 API 计划（DeepL API Free）每月提供 500,000 个字符的额度。当你翻译一个包含 800 个产品的 WooCommerce 目录且描述很长时，这听起来就没那么多了。
Pro 计划起价约为每月 $6.99（500,000 个字符），之后按使用量阶梯计费。对于我运营的大多数代理项目，成本通常在每月 $15 到 $60 之间，具体取决于目录规模和更新频率。相比之下，专业人工翻译的费率（英国市场通常为每词 £0.10 到 £0.18）来说，API 成本在翻译 200 词以内就能收回。
早期让我吃过亏的一件事：HTML 处理。DeepL 可以接收原始 HTML 并尝试保留标签而不翻译它们。你在请求中传入 tag_handling=html。但如果你的 HTML 格式不规范，或者产品描述包含内联脚本（我说的就是某些 WooCommerce 插件），输出可能会被破坏。我后来学会了在内容送到 API 之前进行清理，而不是之后。HTML handling. DeepL can receive raw HTML and will attempt to preserve tags rather than translate them. You pass tag_handling=html in your request. But if your HTML is malformed or your product descriptions contain inline scripts (looking at you, some WooCommerce plugins), the output can get mangled. I learned to sanitise content before it hits the API, not after.
两条集成路径：WordPress 和自定义构建
WordPress 网站
对于 WordPress，我用过的最直接的方式是 WPML 集成。WPML 在其翻译管理模块中内置了原生 DeepL 连接器。你在 WPML 设置中授权你的 DeepL API 密钥，选择要自动翻译的内容类型，它就会处理队列。这不是魔法，人工审查步骤仍然值得纳入工作流中，但对于一个 300 页的网站，它可以节省数周的时间。WPML integration. WPML has a native DeepL connector built into their Translation Management module. You authorise your DeepL API key inside WPML's settings, select which content types to auto-translate, and it handles the queue. It's not magic, a human review step is still worth building into the workflow, but for a 300-page site it saves weeks.
另一个选择是 Polylang Pro 配合 DeepL 插件。许可费用稍便宜一些，在翻译管理方面的打磨程度稍逊。去年我在一个法国餐厅集团网站上用过 Polylang。在那种规模下效果不错。但对于任何有自定义文章类型和 ACF 字段的项目，根据我的经验，WPML 对边界情况的处理能力更强。
如果你在构建 headless WordPress（Gatsby 或 Next.js 前端通过 GraphQL 从 WP 拉取数据），你会希望直接从构建管道或无服务器函数调用 DeepL API。不要试图在那种架构下通过插件来实现。它扩展不了。
自定义 / 非 WordPress 构建
这就是有趣的地方。DeepL 为 Python、Node.js、PHP、Ruby、.NET 和 Java 发布了官方客户端库。Node.js 库很不错。我在一个 Next.js 项目中用过它，我们把翻译缓存在 Redis 中以避免重复字符串上的冗余 API 调用。official client libraries for Python, Node.js, PHP, Ruby.NET, and Java. The Node.js library is solid. I've used it on a Next.js project where we cached translations in Redis to avoid redundant API calls on repeated strings.
一个基本的 Node.js 调用看起来像这样：
`` const deepl = require('deepl-node'); const translator = new deepl.Translator('YOUR_AUTH_KEY'); const result = await translator.translateText('Hello, world', null, 'fr'); console.log(result.text); // 'Bonjour le monde' `` const deepl = require('deepl-node'); const translator = new deepl.Translator('YOUR_AUTH_KEY'); const result = await translator.translateText('Hello, world', null, 'fr'); console.log(result.text); // 'Bonjour le monde' ``
很简单。真正的架构问题是缓存。你不想在每次页面加载时都命中 API。把翻译存储在你的数据库或缓存层中（Redis 效果很好，甚至简单的 JSON 文件对小型网站也可以）。当源内容变化时使缓存失效。就这样。大部分复杂性来自缓存失效逻辑，而不是 API 调用本身。
处理占位符和动态内容
这在 Seahawk 的一个 SaaS 项目中难住了我的一个开发者，UI 字符串包含像 {{user_name}} 和 {{count}} 这样的变量。直接把它们原样喂给 DeepL，它有时会翻译变量名。当 {{nombre_de_usuario}} 最后出现在你的西班牙语 UI 中时就不理想了。{{user_name}} and {{count}}. Feed those raw to DeepL and it'll sometimes translate the variable names. Not ideal when {{nombre_de_usuario}} ends up in your Spanish UI.
修复方法：使用 DeepL 的 XML 处理，在发送前用忽略标签包装你的占位符。XML handling and wrap your placeholders in ignore tags before sending.
`` <deepl:ignore>{{user_name}}</deepl:ignore> has {{count}} new messages. `` <deepl:ignore>{{user_name}}</deepl:ignore> has {{count}} new messages. ``
在你的请求参数中设置 tag_handling=xml 和 ignore_tags=deepl:ignore。API 会保留这些标签内的所有内容。这在 DeepL 的 API 参考文档中有说明,但初次阅读时容易遗漏。我在那个 SaaS 项目上因此花了大约三个小时调试。希望你不用花这个时间。tag_handling=xml and ignore_tags=deepl:ignore in your request parameters. The API preserves anything inside those tags. This is documented in DeepL's API reference but it's easy to miss on a first read. Cost me about three hours of debugging on that SaaS project. Hopefully it costs you none.
建立合理的审核工作流程
机器翻译不是发布按钮。我从不建议直接将 DeepL 输出发送到上线网站,至少应该经过一个母语使用者的审核,特别是面向客户的内容。但工作流程不一定要很麻烦。
以下是我为大多数客户项目设置的方式:
- 通过 DeepL API 运行初始翻译。
- 将输出推送到暂存翻译表(在 WPML 中这是自动的;在自定义构建中,我写入一个带有 status 列的 translations 数据库表,默认状态为 pending)。
translationsDB table with astatuscolumn defaulting topending). - 将链接发送给客户所在地区的审核人员(通常是客户自己的本地团队或来自 ProZ 的自由翻译工作者)。ProZ).
- 审核人员直接在 CMS 或我构建的简单审核界面中编辑。
- 状态改为 approved,内容上线。
approved, content goes live. - 锁定该字符串,防止下次 API 同步时被覆盖。
最后这一步很重要。我见过一些情况，源语言的内容更新会触发完整的重新翻译，并删除所有人工修正。在构建其他东西之前，先构建锁定机制。
多语言网站的 SEO 考虑因素
仅靠翻译内容是不会获得排名的。你需要在 HTML <head> 中为每个语言版本添加 hreflang 标签，而且必须正确。设置不匹配的 hreflang 实际上会在搜索结果中抑制你的国际页面。我见过一个客户，他的法文翻译网站设计得很漂亮，却因为有人搞错了语言代码（fr-FR 对比 fr）而在搜索中隐没了四个月。hreflang tags in your HTML <head> for every language variant, and they need to be correct. A mismatched hreflang setup can actually suppress your international pages in search results. I've seen this happen to a client who had a beautiful translated French site sitting in obscurity for four months because someone got the language codes wrong ( fr-FR vs fr).
除了 hreflang：还要翻译 URL。理想情况下，URL slug 也要翻译，不是 /fr/how-to-cook-pasta，而是 /fr/comment-cuire-les-pates。DeepL 可以翻译 slug，但之后你需要通过 slug 格式化工具处理一遍（小写、连字符、去除特殊字符）。WPML 会自动处理。对于自定义构建，需要手动处理。/fr/how-to-cook-pasta but /fr/comment-cuire-les-pates. DeepL can translate slugs but you'll want to run them through a slug formatter afterwards (lowercase, hyphens, remove special characters). WPML does this automatically. In custom builds, handle it manually.
还有元数据。页面标题、元描述、图片 alt 文本，全部都需要翻译。我会在流程中单独通过 DeepL 处理元数据，而不是作为正文内容批处理的一部分。这样更容易控制字符限制。
DeepL 的不足之处
老实说：品牌特定术语。DeepL 不知道你的客户如何称呼他们的产品功能。如果一个金融科技客户使用"Smart Vault"作为产品名称，DeepL 会翻译它。每一次都会翻译。
解决办法是使用 DeepL 的术语表功能。你通过 API 定义术语对（源术语、目标术语、语言对）并在翻译请求中附加术语表 ID。这样"Smart Vault"在每种语言中都会保持为"Smart Vault"，因为你已经告诉系统这样处理。你可以通过编程或 DeepL 仪表板管理术语表。我现在在每个项目启动时都会设置术语表。只需要 20 分钟，但能避免一类错误，否则这些错误在审查阶段需要花费数小时才能发现。glossary feature. You define term pairs via the API (source term, target term, language pair) and attach the glossary ID to your translation requests. That Smart Vault becomes "Smart Vault" in every language because you've told it to. You can manage glossaries programmatically or via DeepL's dashboard. I set up glossaries as part of every project kickoff now. It takes 20 minutes and prevents a category of errors that would otherwise cost hours to catch in review.
另一个诚实的限制：DeepL 的语言覆盖范围。如果你的客户有超越欧洲和东亚的野心，29 种语言确实很受限。如果你需要阿拉伯语，就得采用混合方案：欧洲语言用 DeepL，其他语言用 Google Cloud Translation 或 Microsoft Azure Translator，在一个统一的内部 API 层后面，按语言对路由。构建一次很烦人。维护起来非常方便。
FAQ
DeepL API 是免费使用的吗？
有一个免费套餐，每月包含 500,000 个字符，对于测试和小项目来说很慷慨。免费计划需要在账户上存档信用卡，但除非你超过限额或升级，否则不会向你收费。对于有实际流量或内容量的生产网站，你几乎肯定会想要付费计划。Pro 套餐起价约为 $6.99/月，按字符使用量计费。
我可以在 WordPress 中使用 DeepL 而不需要插件吗？
技术上可以。你可以使用 wp_remote_post() 从 WordPress 自定义插件或 functions.php 直接调用 REST API。但除非你喜欢重复造轮子，否则 WPML 或 Polylang 集成会为你处理翻译队列、字符串同步和内容锁定。我只会在 WordPress 中直接调用自定义 API，如果你有非常特殊的架构原因。wp_remote_post(). But unless you enjoy reinventing wheels, the WPML or Polylang integrations handle the translation queue, string syncing, and content locking for you. I'd only go custom-API-direct in WordPress if you have a very specific architecture reason.
DeepL 与人工翻译相比准确性如何？
对于欧洲语言，DeepL 在 BLEU 分数基准测试中的表现通常与人工翻译相差几个百分点。实际上：对产品描述和 UI 字符串来说足够好，但对法律文件、创意文案或任何语气和文化细微差别很重要的内容来说还不够好。始终为客户项目建立一个人工审核步骤。
DeepL 翻译是否会影响 SEO？
未经审核的机器翻译内容可能会被搜索引擎标记为低质量，特别是如果读起来很不自然。Google 曾表示他们不会因为自动翻译内容本身而惩罚，但质量差或混乱的内容会表现不佳。我的原则是：在索引之前审核，而不是之后。
当源内容变更时，处理翻译更新的最佳方法是什么？
在数据库中跟踪内容哈希（源字符串的 MD5 就可以），与每个翻译一起存储。当源内容更新时，哈希会改变，这将翻译标记为过期。你的流程随后只重新翻译已更改的字符串，而不是整个页面。这可以降低 API 成本并防止对已经过人工审核的字符串进行不必要的变更。
---
DeepL API 是那些真正改变了我如何规划多语言项目范围的工具之一。这不是因为它消除了对人类判断的需求，而是因为它将工作从繁琐的初稿翻译转变为有意义的编辑审查。这是对每个人时间的更好利用，包括你客户的预算。仔细连接，积极缓存，从第一天起就把审查步骤建立进去，它会为你服务得很好。