PolyLingo 与 DeepL API：哪个更好地保留 JSON 和 Markdown？

DeepL 制作了真正出色的翻译软件。它的神经翻译引擎被广泛认为是目前最好的之一，对于纯文本来说几乎无可匹敌。如果你正在翻译句子、段落或作为连续文本编写的文档，DeepL 是一个强有力的选择。

本文要回答的问题更为狭窄：当你的内容具有结构时，DeepL API 的表现如何？当你需要翻译一个 JSON 本地化文件而不触碰键，或者翻译一个 Markdown 博客文章而不破坏语法，或者翻译一个 HTML 页面而不破坏属性时，它表现如何？在这个特定用例中，它与 PolyLingo 相比如何？

DeepL API 的构建方式

DeepL 文本翻译 API 接受纯文本。这是它的原生输入格式。每个请求最多接受 50 个文本字符串，它们独立翻译，彼此之间没有共享上下文。每个请求只能指定一个目标语言。如果你需要五种语言，就需要发出五个请求。

DeepL 确实支持 PDF、Word、PowerPoint 和 HTML 等格式的文档翻译，但这是通过一个单独的文档端点完成的，流程不同：上传文件，轮询完成状态，下载结果。它设计用于办公文档，而非程序化内容管道。

针对 HTML，存在一个 tag_handling 参数，你可以设置为 html，告诉 DeepL 将输入视为 HTML 并尝试保留标签。对于简单的标记，这效果相当不错，但这是一个可选标志，需要你知道并设置，而且它不适用于 JSON 或 Markdown。

对于 JSON，没有原生支持。DeepL 的文本端点不知道什么是 JSON 键。如果你发送一个序列化的 JSON 对象，它会将内容作为字符串翻译，不能保证键、结构或非字符串值能完整保留。babeldown R 库封装了 DeepL 用于 Markdown 内容的功能，记录了 DeepL 在 Markdown 链接和格式中的标点混淆案例，这是通过纯文本翻译引擎处理结构化文本的已知限制。

这不是对 DeepL 的批评，而是对该 API 设计用途的描述。DeepL 的核心用例是高质量翻译人类可读的散文。这是它优化的方向，并且表现出色。

实际中差距的体现

当你的内容不是纯散文时，差异就显现出来了。

考虑一个标准的 Next.js 本地化文件：

{
  "nav": {
    "home": "Home",
    "about": "About us",
    "contact": "Get in touch"
  },
  "hero": {
    "title": "Welcome to our platform",
    "subtitle": "Everything you need in one place"
  }
}

要用 DeepL API 将其翻译成五种语言，你需要：

单独提取每个字符串值
每种语言发起一个单独的 API 请求（五种语言，五个请求）
用翻译后的值在正确位置重建 JSON 结构
处理任何翻译改变标点或引入破坏 JSON 有效性的字符的情况这是一段不简单的胶水代码，也很脆弱。翻译输出与解析器预期的任何偏差都会导致应用程序静默失败或运行时错误。

使用 PolyLingo，你只需将对象原样发送，设置 format: "json"，即可在一次响应中获得每个目标语言的完整结构翻译版本。键保持不变，嵌套结构保留，非字符串值不变。输出可直接投入项目使用。

curl -sS -X POST "https://api.usepolylingo.com/v1/translate" \
  -H "Authorization: Bearer $POLYLINGO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "{\"nav\":{\"home\":\"Home\",\"about\":\"About us\"}}",
    "format": "json",
    "targets": ["fr", "de", "es", "ja", "nl"]
  }'

一次请求，五种语言，结构完整。

Markdown 内容

同样的模式适用于 Markdown。DeepL 的文本端点没有 Markdown 语法的概念。发送一个博客文章，它会将整个内容作为字符串处理。标题可能保留，代码块几乎肯定不会保留，因为其中内容很可能被当作可翻译文本处理。链接语法可能被破坏，尤其是在链接文本边界的标点处。

PolyLingo 的 markdown 格式标志指示模型将 Markdown 语法视为结构性而非可翻译内容。标题保持标题，围栏代码块保持原样，链接 URL 不被更改，只有散文内容发生变化。

对于文档站点或包含技术内容的博客，这种差异非常重要。教程中的代码块损坏不是小的展示问题，而是教程本身被破坏。

一次请求与每语言一次请求的区别

这值得细细考虑，因为成本影响是真实存在的。

DeepL API 每次请求只接受一个目标语言。要将内容翻译成十种语言，你需要发出十次 API 调用。对于大型网站或频繁发布的 CMS，这意味着请求开销增加十倍，管理延迟增加十倍，失败点也增加十倍。

PolyLingo 接受目标语言代码数组，并在一次响应中返回所有翻译。三十六种语言只需一次请求，而非三十六次。

对于小项目，这个差异是可控的。对于任何规模较大的项目，它会改变你构建翻译管道的架构。

价格模型

DeepL 按字符计费。API 免费计划每月允许最多 500,000 字符，付费计划按字符消耗计费。因为每种语言都要发一次请求，内容的字符数会乘以目标语言数量。

PolyLingo 按 token 计费，计算单次请求中所有语言的输入和输出总和。计费透明且可预测：免费层每月包含 50,000 个 token，付费计划起价为每月 9 美元，包含 600,000 个 token。

两种模型在成本每词上不可直接比较，因为单位不同，但 PolyLingo 的一次请求多语言架构意味着请求次数不会随着目标语言数量线性增加。

各自适用场景

DeepL API 适合：

内容是纯散文，无结构要求
主要关注人类可读文本的翻译质量
翻译语言数量少且请求量低
已经使用 DeepL 生态系统，利用其词汇表或正式度功能
需要支持 PolyLingo 当前 36 种语言之外的语言（DeepL 支持 100 多种语言）

PolyLingo 适合：

内容是 JSON、Markdown 或 HTML，且必须保留结构
需要一次 API 调用翻译多种语言
构建 CMS 集成或 i18n 管道，关注请求效率
希望所有内容格式使用一致接口，无需格式特定的变通方法
希望基于 token 计费，且每月额度可预测

并排总结

	PolyLingo	DeepL API
原生 JSON 支持	是	否
原生 Markdown 支持	是	否
HTML 支持	是	是（tag_handling 标志）
一次请求支持所有语言	是	否，每次请求一个语言
自动检测内容格式	是	否
支持语言数量	36	100+
免费额度	每月 50,000 token	每月 500,000 字符
计费单位	Token	字符
无代码网页翻译器	是	是（网页应用）

DeepL 拥有更大的语言目录和更长的散文翻译质量记录。PolyLingo 专为结构化内容工作流设计，格式完整性不可妥协。

它们解决的是相邻的问题。正确选择取决于你的内容实际是什么样子。

试用 PolyLingo

免费层每月包含 50,000 个 token。无需信用卡。完整 API 文档见 usepolylingo.com/docs。

curl -sS -X POST "https://api.usepolylingo.com/v1/translate" \
  -H "Authorization: Bearer $POLYLINGO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "# Hello\n\nThis is **structured** content.",
    "format": "markdown",
    "targets": ["fr", "de", "es"]
  }'

获取你的 API 密钥