规模化翻译

翻译营销网站是个下午的工作。翻译九万一千页则是管道工程问题。Deluxe Astrology 跨越三十种语言运营。本网站在英文基础上支持八个地区语言。约束条件不是孤立的翻译质量，而是单位成本和时间内的质量，同时保证 hreflang 完整性，还要有人工审核关卡但不能变成全职工作。

DeepL 在欧洲和主要亚洲语言对上大批量处理时表现最好。API 很可预测：发送 JSON 片段，接收翻译片段，按字符数计费。延迟足够低，可以跨数百页并行处理，每小时处理量很大。对于产品列表、目录模板和结构化 UI 字符串，DeepL 是我的默认首轮工具。

DeepL 的短板：营销习语、SEO 标题压缩，以及它不擅长的语言对。它会把"best WordPress hosting"逐字翻译，而该地区用户期望的头部术语结构不同。这在后处理中可以修复，但需要额外工作。

Claude Haiku 是人性化处理的成本高效模型。在经过 DeepL（或直接从英文版本，针对内容较少的页面）之后，Haiku 会以风格指南重写五十到一百个分段：保持含义、本地化习语、保留命名实体、不凭空捏造事实、遵守标题和元数据的字符限制。Haiku 速度足够快、成本足够低，可以在发布前对每一行运行。

与同一任务上的 GPT-4o-mini 相比，当提示包含实际案例时，Haiku 往往能更可靠地遵守结构约束（如这个标题不超过 60 个字符）。对于高风险页面、支柱指南和服务页面，我仍然会由母语使用者进行抽查，或提交给 Sonnet 进行二次审阅。

从 Supabase（或 CMS 导出）提取可翻译的分段，使用稳定的密钥。通过 DeepL API 进行机器翻译，词汇表术语固定（品牌名称、产品名称、法律短语）。运行 Haiku 人性化处理，采用存储在代码库中的地区特定指南，而不是内联在一个超大提示中。Lint 检查：禁用短语、em-dash 密度、元数据长度、hreflang 对完整性。写入翻译缓存表。从缓存构建静态页面，这样运行时永远不会调用翻译 API。

如果某个地区页面缺少相互的 hreflang 或元描述超过 155 个字符，构建时 SEO lint 会导致部署失败。翻译质量门控应该在 CI 中，而不是在三周后的电子表格审查中。

在大约五百个网址以下且没有自定义堆栈的情况下，Weglot 或 Lokalise 通常比工程化流程便宜。交叉点出现在你已经运行 Astro 或 Next.js，具有 Supabase 或 Postgres 内容层，且需要按地区对翻译内容进行程序化控制的地方。这就是 DeepL + Haiku + 缓存表在成本和 SEO 控制上胜出的地方。

相关内容：[多语言 SEO 服务](/multilingual-seo/)、[Weglot vs GTranslate vs 自定义引擎](/blog/weglot-vs-gtranslate-vs-custom-engine/)，以及 [SEO 指南中心](/guides/topic/seo/)。