使用您最喜欢的AI助手总结文档,并引用此页面和AI提供商
此页面的内容已使用 AI 翻译。
查看英文原文的最新版本如果您有改善此文档的想法,请随时通过在GitHub上提交拉取请求来贡献。
文档的 GitHub 链接复制文档 Markdown 到剪贴板
使用 Intlayer 翻译你的 Next.js 15 next-i18next 网站 | 国际化 (i18n)
本指南适用对象
- 初级:按照步骤操作并复制代码块,你将获得一个可用的多语言应用。
- 中级:使用检查清单和最佳实践提示,避免常见陷阱。
- 高级:浏览高层结构、SEO 和自动化部分;你会发现合理的默认设置和扩展点。
你将构建的内容
- 带有本地化路由的 App Router 项目(例如
/、/fr/...) - 包含 locales、默认语言、RTL 支持的 i18n 配置
- 服务器端 i18n 初始化和客户端提供者
- 按需加载的命名空间翻译
- 支持
hreflang、本地化sitemap和robots的 SEO - 用于语言路由的中间件
- 集成 Intlayer 以自动化翻译工作流(测试、AI 填充、JSON 同步)
注意:next-i18next 是构建在 i18next 之上的。本指南使用与 next-i18next 在 App Router 中兼容的 i18next 原语,同时保持架构简单且适合生产环境。 如需更全面的比较,请参见 next-i18next vs next-intl vs Intlayer。
1) 项目结构
安装 next-i18next 依赖:
从清晰的结构开始。保持消息按语言环境和命名空间分开。
检查清单(中高级):
- 每个语言环境每个命名空间保持一个 JSON 文件
- 不要过度集中消息;使用小型的页面/功能范围命名空间
- 避免一次导入所有语言环境;只加载你需要的
2) 安装依赖
如果您计划使用 next-i18next 的 API 或配置互操作,还需执行:
3) 核心 i18n 配置
定义 locales、默认 locale、RTL 以及本地化路径/URL 的辅助函数。
高级提示:如果你使用 next-i18next.config.js,请确保它与 i18n.config.ts 保持一致,以避免偏差。
4) 服务器端 i18n 初始化
在服务器端初始化 i18next,使用动态后端仅导入所需的 locale/namespace JSON。
中间提示:保持每页的命名空间列表简短以限制负载。避免使用全局的“捕获所有”包。
5) React 组件的客户端提供者
使用一个提供者包裹客户端组件,该提供者与服务器配置相对应,并且只加载请求的命名空间。
初级提示:您不需要将所有消息传递给客户端。只需从页面的命名空间开始。
6) 本地化布局和路由
设置语言和方向,并为每个语言预生成路由,以支持静态渲染。
7) 服务器端 + 客户端使用示例页面
翻译(每个命名空间一个 JSON,位于 src/locales/... 下):
客户端组件(仅加载所需的命名空间):
确保页面/提供者只包含你需要的命名空间(例如,
about)。 如果你使用的是 React 版本低于 19,建议对像Intl.NumberFormat这样开销较大的格式化器进行缓存。
嵌套在客户端边界下的同步服务器组件:
8) SEO:元数据,Hreflang,站点地图,Robots
翻译内容是提升覆盖范围的一种手段。请彻底配置多语言SEO。
最佳实践:
- 在根节点设置
lang和dir - 为每个语言添加
alternates.languages(加上x-default) - 在
sitemap.xml中列出翻译后的URL并使用hreflang - 在
robots.txt中排除本地化的私有区域(例如/fr/admin)
9) 用于本地化路由的中间件
检测语言环境,如果缺失则重定向到本地化路由。
10) 性能和开发体验最佳实践
- 设置 html 的
lang和dir属性:已在src/app/[locale]/layout.tsx中完成。 - 按命名空间拆分消息:保持包体积小(如
common.json、about.json等)。 - 最小化客户端负载:在页面中只向 provider 传递所需的命名空间。
- 优先使用静态页面:针对每个 locale 使用
export const dynamic = 'force-static'和generateStaticParams。 - 同步服务器组件:传递预计算的字符串/格式,而不是在渲染时进行异步调用。
- 对重操作进行记忆化:尤其是在旧版本 React 的客户端代码中。
- 缓存和头部设置:尽可能优先使用静态或
revalidate,而非动态渲染。
11) 测试和持续集成(CI)
- 为使用
t的组件添加单元测试,确保键存在。 - 验证每个命名空间在所有语言环境中具有相同的键。
- 在 CI 过程中部署前显示缺失的键。
Intlayer 将自动化完成大部分这些工作(见下一节)。
12) 在顶部添加 Intlayer(自动化)
Intlayer 帮助你保持 JSON 翻译同步,测试缺失的键,并在需要时使用 AI 填充。
安装 intlayer 依赖:
添加 package 脚本:
常见流程:
- 在 CI 中运行
pnpm i18n:test,以在缺少键时使构建失败 - 在本地运行
pnpm i18n:fill,为新添加的键提供 AI 翻译建议
你可以提供 CLI 参数;请参阅Intlayer CLI 文档。
13) 故障排除
- 找不到键:确保页面/提供者列出了正确的命名空间,并且 JSON 文件存在于
src/locales/<locale>/<namespace>.json目录下。 - 语言错误/闪现英文:仔细检查
middleware.ts中的语言环境检测以及提供者的lng设置。 - RTL 布局问题:确认
dir是由isRtl(locale)得出,并且你的 CSS 支持[dir="rtl"]。 - SEO 替代语言缺失:确认
alternates.languages包含所有语言环境和x-default。 - 包体积过大:进一步拆分命名空间,避免在客户端导入整个
locales目录树。
14) 接下来做什么
- 随着功能的增长,添加更多的语言环境和命名空间
- 本地化错误页面、电子邮件和基于 API 的内容
- 扩展 Intlayer 工作流,实现自动打开翻译更新的 PR
如果您需要一个入门模板,可以尝试:https://github.com/aymericzip/intlayer-next-i18next-template。