为您的 Next.js 应用添加多语言支持。
通过单次 API 调用翻译您的本地化文件、Markdown 内容和 HTML 页面。兼容 App Router、next-intl 及任何 i18n 路由设置。
Next.js 提供路由,但不提供翻译。
Next.js App Router 对基于语言环境的路由有出色的内置支持。像 next-intl 这样的库使管理翻译文件和语言切换变得简单。但它们无法解决翻译本身的问题——必须有人为每种语言生成翻译内容,而这个人通常是您。对于大多数团队,工作流程是将英文 JSON 复制到 DeepL,修复被破坏的格式,再粘贴回去,对每种语言重复此过程。这既慢又容易出错,且难以扩展。
最常见的工作流程是在源代码中用英文编写所有 UI 字符串,然后为每个目标语言翻译 messages.json 文件。理论上这很简单,但实际上,保持 10+ 个本地化文件与源代码变更同步是一个反复出现的痛点。每次英文文案变更,都需要更新所有本地化文件。使用标准翻译 API 时,键名会被破坏,变量占位符被翻译,JSON 结构在各语言间漂移——导致难以追踪的细微运行时错误。
PolyLingo 适配您现有的 Next.js i18n 设置。
如果您使用 next-intl 或其他任何 i18n 库,您的消息已经是 JSON 格式。PolyLingo 接收该 JSON,通过翻译模型处理,并返回每个目标语言的翻译副本——保持键不变,嵌套结构完整,字符串值正确翻译。您可以从构建脚本、Webhook 或 PolyLingo UI 调用它。结果直接写入您的 messages 目录。
工作流程:编写您的英文 messages.json。运行一个脚本,调用 PolyLingo API,传入源文件和所有目标语言代码。接收每种语言的翻译 JSON 文件,结构完全相同。写入 messages/ 目录。提交。完成。
对于内容丰富且使用 CMS(Sanity、Contentful)管理 Markdown 的网站,同样的方法适用于内容:导出为 Markdown 或 HTML,翻译后通过 CMS API 写回。整个流程可作为构建步骤或 Webhook 触发运行。
// This repository: frontend/scripts/translate-messages.mjs
// Chunks large namespaces (e.g. home) so the model stays within output limits.
//
// export POLYLINGO_API_KEY=pl_xxx
// npm run i18n:polylingo
//
// Writes messages/es.json, fr.json, … from messages/en.json via POST /v1/translate
// with format: "json". See MARKETING_I18N.md for options and CI notes.
//
// Minimal one-shot pattern (fine for small message files):
//
// const source = readFileSync('./messages/en.json', 'utf8')
// const { translations } = await fetch(apiUrl + '/translate', {
// method: 'POST',
// headers: { Authorization: `Bearer ${apiKey}`, 'Content-Type': 'application/json' },
// body: JSON.stringify({
// content: source, format: 'json', source: 'en',
// targets: ['es', 'fr', 'de'], model: 'standard',
// }),
// }).then((r) => r.json())
//
// for (const [lang, raw] of Object.entries(translations)) {
// const obj = typeof raw === 'string' ? JSON.parse(raw) : raw
// writeFileSync(`./messages/${lang}.json`, JSON.stringify(obj, null, 2))
// }// i18n.ts (next-intl v4)
import { getRequestConfig } from 'next-intl/server'
export const locales = [
'en', 'ar', 'bn', 'cs', 'da', 'de', 'el', 'es', 'fa', 'fi',
'fr', 'he', 'hi', 'id', 'it', 'ja', 'ko', 'ms', 'nl', 'no',
'pl', 'pt', 'ru', 'sv', 'sw', 'th', 'tr', 'uk', 'vi', 'zh',
] as const
export type Locale = (typeof locales)[number]
export default getRequestConfig(async ({ requestLocale }) => {
const locale = await requestLocale
return {
locale,
messages: (await import(`./messages/${locale}.json`)).default,
}
})// package.json
{
"scripts": {
"dev": "next dev",
"build": "next build",
"i18n:polylingo": "node scripts/translate-messages.mjs",
"translate:build": "npm run i18n:polylingo && next build"
}
}为何 PolyLingo 适合 Next.js i18n 工作流
- ✓直接翻译 messages/*.json 文件——始终保留键名
- ✓翻译博客文章和文档页面的 Markdown 内容
- ✓兼容 next-intl、next-i18next 及自定义设置
- ✓REST API 可集成构建脚本和 CMS Webhook
- ✓一次请求支持全部 36 种语言
- ✓免费额度——每月 50,000 令牌
- ✓此仓库自用该工作流程:npm run i18n:polylingo 从 messages/en.json 重新生成营销本地化文件(详见 MARKETING_I18N.md)。
- ✓兼容 App Router 和 Pages Router
- ✓输出文件可直接提交——无需重新格式化
在您的 Next.js 应用中设置多语言
使用英文消息文件设置 next-intl
安装 next-intl 并配置您的 i18n.ts 和中间件。在 messages/en.json 中编写所有 UI 字符串。文件结构可根据应用需求自由设计——扁平或嵌套。它将成为您的唯一真实来源。
运行翻译脚本
使用 PolyLingo JSON API 通过一个小型 Node 脚本调用(见上方代码)。在此 monorepo 中,从 frontend/ 目录运行 npm run i18n:polylingo 并设置 POLYLINGO_API_KEY——它会分块处理大型命名空间以保证可靠性。完整营销包的典型运行时间远低于一分钟。
提交本地化文件并部署
生成的本地化文件是有效 JSON,结构与源文件完全相同。提交到您的仓库。将翻译脚本加入 CI 流程,确保每次内容变更时本地化文件保持同步。
Next.js 多语言使用场景
SaaS 应用和仪表盘
一次脚本运行即可翻译整个 UI 字符串库。支持所有 next-intl 格式化功能——日期、数字、复数——因为 JSON 结构完全保留。
内容网站和博客
对于使用 Sanity 或 Contentful 的内容丰富的 Next.js 网站,使用 PolyLingo 翻译页面内容和 UI 字符串——同一 API,同样的格式保留保证。
带区域变体的电商
翻译产品名称、描述、分类页面和结账 UI。营销文案使用高级模型以保持品牌声音,功能性 UI 字符串使用标准模型。
常见问题
这适用于 Next.js App Router 吗?
是的。PolyLingo 集成只是一个读取和写入 JSON 文件的脚本——不依赖 Next.js 内部机制。兼容 App Router、Pages Router 或任何框架。示例中 next-intl 配置使用 v4 API 和 requestLocale,兼容 Next.js 13、14 和 15。
如果我的 messages.json 经常变更怎么办?
推荐的做法是将翻译脚本加入 CI/CD 流程,在 messages/en.json 变更时触发。这样可自动保持所有本地化文件同步。对于频繁变更的团队,这能完全避免本地化漂移。
PolyLingo 是否兼容 next-i18next 和 next-intl?
是的。next-i18next 使用相同的本地化 JSON 结构。翻译脚本用法相同——指向您的 public/locales/en/ 目录,输出写入其他语言目录。JSON 格式兼容性一致。
动态内容不在 messages 文件中怎么办?
动态内容——博客文章、产品描述、用户生成内容——应在数据层翻译,或通过构建脚本在内容到达 Next.js 前处理。PolyLingo 同样支持 Markdown、HTML 和纯文本的翻译。
能否只翻译自上次运行以来变更的字符串?
增量翻译(仅翻译变更的键)正在规划中。目前脚本会重新翻译整个文件。对于大多数消息文件(小于 20KB),这足够快,可在每次提交时运行。对于非常大的文件,建议按命名空间拆分。
有办法在翻译上线前进行审核吗?
推荐做法是将翻译后的本地化文件提交到单独分支或 PR,待审核后合并到主分支。这是需要人工审核翻译质量团队的标准流程。PolyLingo 生成的初稿质量良好——大多数 UI 字符串的标准模型输出无需编辑。