# General Translation Knowledge Base: 如何让网站支持多语言？ URL: https://generaltranslation.com/zh/kb/make-website-multilingual.mdx Docs index: https://generaltranslation.com/llms.txt Description: 先确定译文放在哪里：代理、CMS 插件、建站工具，还是你自己的代码；然后按照 Google 的建议，为每种语言分配独立的 URL。完整翻译页面以及标题和元描述，用 hreflang 关联各语言版本，并提供语言切换器，而不是自动重定向访问者。 Category: 国际化 Last updated: 2026-10-20 Authors: Kevin Wu, Jackie Chen Published: 2026-10-20 多语言网站会以多种语言提供每个页面，每个语言版本都有独立的 URL，并向搜索引擎说明各版本之间的关系。各种方案的主要区别在于译文存放在哪里，这决定了你对 SEO、翻译质量和内容更新能有多大的掌控权。因此，动手翻译之前，先选定方案。 ## 应该选择哪种方案？ 最省事的方案完全不需要你动手：访客的浏览器可以自行翻译页面。例如，[Chrome](https://support.google.com/chrome/answer/173424) 会根据读者的语言设置给出提示，并使用 Google Translate 翻译页面。这能帮到单个读者，但并不能让你的网站真正支持多语言。这种方式没有可供索引的语言 URL，你也无法审校翻译结果，唯一能做的就是用 [`translate="no"`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/translate) 属性标记品牌名称等文本。 翻译代理和 JavaScript 覆盖层部署在已建成的网站前端。[Weglot 的反向代理](https://weglot.com/technical-presentation/)会抓取你的页面，通过 Weglot 的 API 翻译其内容，然后在语言子域名或子目录下提供翻译结果，并添加 hreflang。其 JavaScript 集成则是在页面加载后于浏览器中插入译文；Weglot 指出，搜索引擎无法识别这些译文，因此建议仅将该模式用于测试或非公开内容。无论采用哪种方式，译文都保存在供应商的仪表板中。 CMS 插件和建站工具将译文保存在平台内部。在 WordPress 上，[WPML](https://wpml.org/documentation/getting-started-guide/language-setup/language-url-options/) 可以将各语言放在不同目录下、为每种语言使用独立的域名或子域名，或使用 `?lang=` 参数；[Polylang](https://wordpress.org/plugins/polylang/) 则根据 URL 中的语言代码，或每种语言对应的子域名或域名来确定语言。[Webflow Localize](https://webflow.com/localization) 在 `/es/` 等子目录下提供各区域设置的内容，可翻译元标题和描述，并生成带有 hreflang 标签的站点地图。在 7.1 版本的 Squarespace 站点上，多语言设置会[连接 Weglot](https://support.squarespace.com/hc/en-us/articles/205809778-Creating-a-multilingual-site-with-Weglot)；由于 Squarespace 无法直接编辑译文，译文需要在 Weglot 中编辑。 静态站点生成器和国际化库将译文保存在你的代码仓库中。[Docusaurus](https://docusaurus.io/docs/i18n/introduction) 将翻译后的文件存放在 `i18n/[locale]/` 下，并自动为你设置 hreflang 请求头或响应头。[Hugo](https://gohugo.io/content-management/multilingual/) 根据 `about.fr.md` 这类文件名后缀或内容目录确定页面语言，再通过 `/fr/` 等前缀提供该页面。在使用 React、Next.js 或 Vue 构建的应用中，i18next 或 next-intl 等库会基于你维护的文件渲染译文。这些工具都不负责生成译文：你需要自己编写、购买，或接入翻译工具。 | 方案 | 译文存放位置 | SEO 控制 | 质量控制 | 工程投入 | 最适合 | | ------------------------------------ | ----------------------------- | ------------------------------------------- | --------------------------- | ------------------------------- | ------------------------ | | 浏览器翻译 | 在每位访客的浏览器中生成 | 无；没有语言 URL | 仅能使用 `translate="no"` | 无 | 访问未本地化网站的读者 | | 代理或覆盖层 (Weglot) | 供应商仪表板 | 代理模式会添加语言 URL 和 hreflang；JavaScript 模式不会被索引 | 先机器翻译，再在供应商编辑器中编辑或订购人工翻译 | 修改 DNS 或添加 script 标签 | 不想重建的现有网站 | | CMS 插件 (WPML、Polylang) | 你的 WordPress 数据库 | 在插件中设置 URL 格式和语言切换器 | 在 WordPress 内进行人工、机器或翻译机构翻译 | 配置插件，之后逐页处理 | WordPress 网站 | | 建站工具 (Webflow Localize、Squarespace) | 建站工具内；Squarespace 则在 Weglot 中 | 由建站工具管理 | 机器翻译加人工编辑 | 低 | 在该建站工具上构建和托管的网站 | | 静态站点生成器国际化 (Docusaurus、Hugo) | 代码仓库中的文件 | 完全可控；URL 和模板由你掌控 | 取决于生成这些文件的流程 | 中等；翻译需单独完成 | 基于 Markdown 构建的文档和内容网站 | | General Translation | 构建中生成的文件，或 GT 的 CDN | 路由和元数据由你掌控；`gt-next` 提供区域设置路由辅助函数 | 基于代码的上下文、统一术语和内置审校 | 标记源文本或接入现有消息目录，在构建前生成译文，测试各区域设置 | 既需要生成译文又需要渲染译文、由开发者维护的网站 | | 仅使用国际化库 (i18next、next-intl) | 代码仓库中的翻译文件 | 完全可控 | 取决于生成这些文件的流程 | 字符串提取、路由、译文交付和 QA；现有集成可自动完成部分工作 | 已有翻译工作流的应用 | 如果营销团队需要翻译页面，又不想重新构建网站，请使用代理或建站工具自带的功能。WordPress 网站请使用 CMS 插件。如果网站由开发者维护且已有译文，请使用静态站点生成器的 i18n 功能或国际化库。如果你还希望在发布流程中生成并审核更新内容，请选择 General Translation；它的 CLI 可以直接翻译现有文件，无需替换你当前使用的库。所需工作量取决于你现有的路由、内容和审核流程；下表列出的是需要完成的任务，而非实测的初始化设置时间。 ## 每种方案都必须回答的问题 无论选择哪种方案，都需要大致按以下顺序做出这七项决策。 ### 1. 选择语言和区域设置 从你现有流量和客户集中的地方入手。每增加一个区域设置，就要多维护一组需要翻译、审校并持续更新的页面，因此只有当某一受众在措辞或格式上确实有所不同时，才需要添加地区变体：巴西葡萄牙语和欧洲葡萄牙语 (`pt-BR`、`pt-PT`) 在词汇上存在差异，而一个 `fr` 就足以覆盖多个国家的法语读者。[区域设置代码指南](/docs/platform/core/guides/locale-codes)介绍了如何编写和选择这些标签。 ### 2. 选择 URL 结构 Google [建议为每个语言版本使用独立的 URL](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites)，而不是让同一个 URL 根据 cookie 或浏览器设置切换语言。子目录 (`example.com/fr/`) 、子域名和国家/地区域名都可以；[URL 结构指南](/kb/multilingual-url-structure)对这几种方式做了比较。 ### 3. 翻译内容和元数据 Google [根据页面的可见内容判断其语言](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites)，而非依据 `lang` 属性或 URL；Google 也不建议只翻译导航栏而让正文保持原有语言。请翻译整个页面，以及页面的标题、元描述、图片 alt 文本、表单错误信息和页面发送的电子邮件。不过，仍需在每个语言版本上设置 ``：[浏览器和屏幕阅读器会依据它](https://www.w3.org/International/questions/qa-lang-why)选择字体、处理断词并进行语音朗读。 ### 4. 添加 hreflang Hreflang 标注用于告诉搜索引擎哪些 URL 是同一页面的不同语言版本，以便搜索引擎向用户展示对应语言的版本。[什么是 hreflang](/kb/what-is-hreflang) 介绍了相关规则、`x-default` 以及常见错误。 ### 5. 添加语言切换器 为访问者提供一个醒目的控件，让他们能够跳转到同一页面的其他语言版本；不要根据推测出的用户语言[自动重定向](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites)，Google 不建议这样做。具体细节请参阅[语言切换器指南](/kb/language-switcher)；如何选择合适的初始语言，请参阅[检测用户语言](/kb/detect-user-language)。 ### 6. 本地化格式 日期、数字、货币和复数形式在不同区域设置下遵循不同的规则：英语中的 `1,234.5` 在德语中写作 `1.234,5`。JavaScript 的 `Intl` API 和大多数国际化库都能自动完成格式化。如果要支持阿拉伯语或希伯来语，页面布局还需要镜像翻转，请参阅[从右到左 CSS](/kb/right-to-left-css)。 ### 7. 让译文保持最新 只要有人改动了源文案，却没人重新运行翻译，网站的其他语言版本就会开始过时。请确定由谁 (或由什么工具) 来翻译这些改动，以及何时翻译：每次发布时、每次部署时，还是按审校计划定期进行。上线前，请针对每个区域设置逐项完成[多语言上线检查清单](/kb/multilingual-app-launch-checklist)。 ## General Translation 如何让网站支持多语言 对于用代码构建的网站和应用，只需在 Next.js 或 React 项目中运行 `npx gt@latest`：[初始化设置向导](/docs/cli/quickstart)会自动检测框架并写入配置。然后用 [``](/docs/react/reference/components/t) 包裹现有标记 (`gt-vue` 也提供相同的组件) ，文案即可保留在原处，无需为每条消息单独维护源键；接着在构建前运行 [`npx gt translate`](/docs/cli/reference/commands/translate)，生成所有区域设置的译文。[Next.js](/docs/react/nextjs-quickstart)、[React](/docs/react/react-quickstart) 和 [Vue](/docs/vue/quickstart) 快速入门分别详细介绍了各自的初始化设置。 `gt-next` 的 [`createNextMiddleware`](/docs/react/nextjs/reference/functions/create-next-middleware) 会提供带区域设置前缀的路径 (例如 `/es/about`) ，但默认情况下不会为默认语言添加前缀，而是根据访问者的区域设置 cookie 或 `Accept-Language` 请求头对这些 URL 进行重定向。因此，请设置 `prefixDefaultLocale: true`，确保每个内容 URL 只对应一种语言。 (有关其中的权衡，请参阅[区域设置路由与 SEO](/kb/locale-routing-seo)。) 经过标记的 JSX 会向翻译服务提供文本的元素结构以及所有显式的上下文备注。发布前，请在 [仪表板 编辑器](/docs/platform/dashboard/guides/reviewing-translations)中审阅生成的译文措辞。匹配的译文会在后续运行中复用，因此修改源内容后无需重新生成整个网站。 除应用代码外，CLI 还能翻译 [HTML](/docs/cli/reference/formats/html-files) 以及 [Markdown 和 MDX](/docs/cli/reference/formats/mdx-md-files) 文件；[Locadex](/docs/platform/locadex/quickstart) 可翻译 Mintlify、Fern 和 Docusaurus 文档；各类集成则可对接 [Sanity](/docs/integrations/sanity/quickstart)、[Payload CMS](/docs/integrations/payload/quickstart) 和 [Storyblok](/docs/integrations/storyblok/quickstart)。它们共用同一套[上下文组](/docs/platform/dashboard/guides/defining-context-for-translations)，以统一术语和风格。 ## 要点总结 * 先确定译文存放在哪里。浏览器翻译和 JavaScript 覆盖层不会生成可被索引的语言页面；代理、建站工具和插件会将译文保存在供应商或平台那里；基于代码的方案则将译文保存在你自己的代码仓库中。 * 无论采用哪种方案，都要解决同样七个问题：区域设置、URL、已翻译内容及元数据、hreflang、语言切换器、格式化以及更新。 * Google 建议为每种语言使用独立的 URL，会根据页面上的可见内容判断语言，并要求不要自动重定向访问者。 * 对于用代码构建的网站，可使用 [``](/docs/react/reference/components/t) 处理 UI，使用 [`npx gt translate`](/docs/cli/reference/commands/translate) 生成译文，然后配置路由，并在上线前逐一测试每个区域设置。 ## Related questions - [多语言 SEO：子目录、子域名与 ccTLD 对比](https://generaltranslation.com/zh/kb/multilingual-url-structure.mdx): 如果同一产品共用一个站点和发布流程，请使用 example.com/de/ 这样的子目录。只有 ccTLD 能指明目标国家，子域名便于独立托管；Google 不建议使用 ?lang= 参数，并会将 .io、.ai 等个性化域名视为通用域名。 - [什么是 hreflang？如何设置？](https://generaltranslation.com/zh/kb/what-is-hreflang.mdx): Hreflang 用于告诉 Google 哪些 URL 是同一页面的不同语言或区域版本，以便在搜索结果中展示正确的版本。你可以通过 HTML link 标签、HTTP Link 响应头或站点地图来添加它，确保所有链接相互指向，并使用有效的代码，例如 en-GB，而不是 en-UK。 - [语言切换器最佳实践：用户体验、SEO 与无障碍访问](https://generaltranslation.com/zh/kb/language-switcher.mdx): 用每种语言的本语名称来标注它，例如 Deutsch 或 日本語，不要使用国旗，因为国旗代表的是国家。每个选项都应通过可抓取的链接指向该语言版本的同一页面，用 cookie 记住用户的选择，并且切勿对已本地化的 URL 自动重定向。 - [多语言应用本地化测试清单](https://generaltranslation.com/zh/kb/multilingual-app-launch-checklist.mdx): 在生产环境构建中，于每个支持的区域设置下测试九项内容：包括错误状态和邮件在内的完整流程、语言切换、复数形式、货币与时区、文本扩展、从右到左布局、无障碍访问、译文交付，以及可抓取的语言 URL。为每项检查设定明确的通过标准。 - [面向开发者的最佳本地化软件是什么？](https://generaltranslation.com/zh/kb/best-localization-software.mdx): 面向开发者的最佳本地化软件会直接在代码中编写内容的位置进行翻译，结合产品上下文，并让每种语言始终保持最新。General Translation 通过开源库、上下文组以及 Locadex（一个会提交拉取请求的 AI 智能体）做到了这一点。 ## Previous and next questions - Previous question: [如何翻译 i18n JSON 文件？](https://generaltranslation.com/zh/kb/translate-json-files.mdx) - Next question: [应该如何命名 i18n 翻译键？](https://generaltranslation.com/zh/kb/i18n-key-naming.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/zh/kb/sitemap.md) for every article.