# General Translation Knowledge Base: 多语言应用本地化测试清单
URL: https://generaltranslation.com/zh/kb/multilingual-app-launch-checklist.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: 在生产环境构建中，于每个支持的区域设置下测试九项内容：包括错误状态和邮件在内的完整流程、语言切换、复数形式、货币与时区、文本扩展、从右到左布局、无障碍访问、译文交付，以及可抓取的语言 URL。为每项检查设定明确的通过标准。
Category: 国际化
Last updated: 2026-10-16
Authors: Jackie Chen
Published: 2026-10-16

首页翻译看起来已经大功告成，但结账流程、验证错误提示或密码重置流程可能仍在使用源语言。请从用户必须走通的路径入手，并在生产环境构建中测试这些路径。

发布多语言 Web 应用之前，请在每个支持的区域设置中检查以下九项内容：

1. **完整流程均已翻译**，包括加载、空状态和错误状态，以及邮件和通知。
2. **语言选择保持一致**，无论是首次访问、切换语言后还是再次访问。
3. **变量和复数形式正确**，覆盖所用语言涉及的每一种复数类别。
4. **货币和时区已显式设置**，且独立于 UI 语言。
5. **布局能适应文本扩展**，在窄屏和浏览器缩放下也不会错乱。
6. **从右向左书写的语言**的文本方向、布局以及混合方向文本均正确无误。
7. **辅助技术能获取正确的语言**、标签和无障碍名称。
8. **生产环境构建包含完整的译文**，且新文案在发布前已完成翻译。
9. **公开页面具有可抓取的语言 URL**，并带有已翻译的元数据和 `hreflang`。

请在每个支持的区域设置中测试内容，并在具有代表性的设备和浏览器上测试布局与交互。第 9 项仅适用于你希望被搜索引擎索引的公开页面。

## Video

The video is narrated in English, with English captions.

[What should I check before launching a multilingual app?](https://caxecubb9c64cezv.public.blob.vercel-storage.com/films/kb-multilingual-app-launch-checklist.mp4) (33秒)

Before launching a multilingual app, test nine things in every supported locale: complete user journeys including errors, language detection and switching, variables and plurals, currency and time zones, text expansion, right-to-left layout, accessibility, production translation delivery, and crawlable language URLs. With General Translation, run gt validate, then `npx gt translate` before the build so new copy ships translated.

## 检查内容与语言的表现

### 1. 翻译完整用户流程，包括失败状态

选择一条关键用户流程，例如创建账户或完成购买，并逐一触发其加载、空、成功和错误状态。检查按钮、对话框、表单验证、占位符、无障碍标签，以及该流程发送的所有邮件或通知。在人工检查之前，先通过[硬编码字符串检查](/kb/find-hardcoded-strings)找出残留的源语言字面量。

**通过标准：** 除产品名称等有意保留的例外外，每个用户交互界面都使用经过审校的目标语言内容，且不出现原始键、缺失消息标记或原因不明的源语言后备内容。

使用 General Translation 时，审校人员在[仪表板翻译编辑器](/docs/platform/dashboard/guides/reviewing-translations)中修正措辞。在生成新译文之前，请在应用项目和邮件项目之间共享[词汇表术语和自定义提示词](/docs/platform/dashboard/guides/defining-context-for-translations)。上下文变更仅对新译文生效；对于已有译文，请专门审校其措辞，不要想当然地认为它们也已随之更新。

### 2. 验证首次访问、语言切换和再次访问

请分别测试以下场景：全新浏览器、用户主动选择语言、页面重新加载、深层链接，以及不受支持的浏览器语言。如果应用会将语言偏好保存在账户中，还需测试登录和退出登录。当 URL、已保存的偏好和浏览器设置相互冲突时，记下哪一项优先生效。[语言检测指南](/kb/detect-user-language)介绍了如何匹配语言偏好；[语言切换器指南](/kb/language-switcher)则介绍了如何处理用户主动选择的语言，以及如何实现无障碍导航。

**通过条件：** 应用始终一致地执行该策略，且用户在语言选择有误时能够恢复。对于服务器端渲染的应用，除了检查水合后的页面，还要检查初始响应。

区域设置标识符遵循 BCP 47：`es-MX` 和 `es-AR` 可以分别作为墨西哥西班牙语和阿根廷西班牙语的独立目标。请逐一测试你发布的每个区域目标。基于 cookie 的语言切换器与带区域设置前缀的路由适用于不同需求，请检查应用实际的 URL 行为。

### 3. 测试变量和复数类别

测试 0、1、2 以及更大数值等各种计数，然后针对目标语言的复数类别补充测试用例。还应覆盖含标点符号的名称、较长的账户名称，以及翻译后变量顺序可能改变的句子。不要把分别翻译的片段拼接成句子。

在 GT 的 React 库中，[`<Plural>`](/docs/react/reference/components/plural) 会选择特定于区域设置的复数形式，[`<Branch>`](/docs/react/reference/components/branch) 会将条件性的备选内容保留在同一翻译单元中，[`<Var>`](/docs/react/reference/components/var) 则在本地替换动态值。请测试每一种备选内容，而不仅仅是默认句子；[`<Var>`](/docs/react/reference/components/var) 内的用户值无需发送到翻译 API。

**通过条件：** 值保持完整，句子通顺正确，且每个必需的复数形式都有可用的内容。Unicode 的[复数规则](https://cldr.unicode.org/index/cldr-spec/plural-rules)解释了为什么仅用一组英语单数/复数用例进行测试是不够的。对于基于目录的消息，还应测试 [ICU 消息](/kb/icu-message-format)中的各个分支。 (基于组件的实现模式请参阅[如何在 React 中处理复数形式？](/kb/how-to-handle-plurals-in-react))

## 检查格式化、布局和无障碍访问

### 4. 区分语言、货币和时区

使用多个区域设置测试同一金额和同一时间点。如果产品有相应需求，请显式指定所需的货币和时区。仅凭语言偏好，既无法判断客户用哪种货币付款，也无法确定预约使用哪个时区。

例如，以下代码按照德语惯例格式化一个已有的 USD 金额：

```js
new Intl.NumberFormat('de-DE', {
  style: 'currency',
  currency: 'USD',
}).format(1234.5);
```

它只会格式化传入的金额，不会进行货币换算。格式化可能会对显示的数字进行舍入，因此请确认你的产品所需的精度。同理，若要显示某一时刻在指定地点的时间，请明确指定时区：

```js
new Intl.DateTimeFormat('en-GB', {
  dateStyle: 'medium',
  timeStyle: 'short',
  timeZone: 'Europe/Paris',
}).format(new Date('2026-01-15T12:00:00Z'));
```

**通过条件：** 分隔符、货币类型、日历日期和显示的时间均与产品的预期含义一致。如果所支持的时区实行夏令时，请将夏令时切换纳入测试。[数字](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat)和[日期](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat) API 会分别提供这些选项。切换 UI 语言不应改变应付金额，也不应改变事件发生的时刻。GT 的 [`<Currency>`](/docs/react/reference/components/currency) 和 [`<DateTime>`](/docs/react/reference/components/datetime) 会进行符合区域设置的格式化，并支持显式指定货币和时区选项；请像测试上文的 `Intl` 调用一样测试这些选项。

### 5. 在不同屏幕尺寸下测试文本扩展

在窄视口下并开启浏览器缩放，打开已翻译的界面。检查导航、按钮、表格、对话框和验证消息。测试时应包含较长的翻译字符串和较长的用户输入值；简短的标题对布局的考验远不及一个完整的地址。

**通过条件：** 关键文本保持可读，控件仍可正常使用。不会有任何操作因文本被裁切或元素重叠而无法触及。应审慎地使用截断，而不是用它来掩盖所有溢出问题。

[伪本地化](/kb/pseudo-localization)可以在译文就绪之前帮助发现布局问题和未标记的字符串。它只是对真实语言测试的补充，并不能证明翻译质量。[Lingui 的指南](https://lingui.dev/guides/pseudolocalization)介绍了一种实现方式。

### 6. 将从右到左内容的测试视为布局要求

如果你支持阿拉伯语、希伯来语或其他从右到左的语言，请测试文档方向、导航顺序、表单，以及电子邮件地址、订单 ID 等混合方向的内容。在布局需要随文本方向变化的地方使用 CSS 逻辑属性，并逐一检查带有方向性的图标。[RTL CSS 指南](/kb/right-to-left-css)介绍了间距、图标和混合方向值的处理方法。

**通过条件：** 布局符合预期的阅读方向，且其中嵌入的从左到右的值仍清晰可读。设置语言代码并不会同时设置文本方向；请参阅 W3C 的 [HTML 文本方向指南](https://www.w3.org/International/questions/qa-html-dir)。

### 7. 检查辅助技术接收到的语言

检查页面的 `lang` 属性、内容中的语言切换 (如适用) 、可见标签、无障碍名称以及替代文本。在主要用户流程中实际试用键盘导航和屏幕阅读器。翻译后的占位符无法取代始终可见的表单标签。

**通过条件：**&#x6587;档声明了正确的语言，控件具有有意义的本地化名称，且翻译后的布局仍可正常操作。W3C 对[语言声明](https://www.w3.org/International/questions/qa-html-language-declarations)有详细说明，其[表单标签指南](https://www.w3.org/WAI/tutorials/forms/labels/)则介绍了如何关联标签。

## 检查用户将获得的发布版本

### 8. 验证生产环境资源和翻译更新

按照发布流程，从干净的检出副本进行构建，然后针对每个支持的区域设置运行该构建。确认翻译资源齐全且能成功加载。在测试分支中修改一条源消息，验证翻译流水线能在下一次发布前检测到该变更。

**通过条件：** 应用能提供预期的译文，且不依赖开发过程中遗留的文件。资源缺失或生成失败时，应明确报错或使用经明确认可的后备内容，而不是悄无声息地发布一个不完整的版本。翻译工具的凭据应保存在构建环境中，切勿放入浏览器应用包。

使用 GT 时，请在构建之前先运行 [`gt validate`](/docs/cli/reference/commands/validate)，再运行 [`gt translate`](/docs/cli/reference/commands/translate)。你可以将构建配置为在翻译失败时终止。[`gt generate`](/docs/cli/reference/commands/generate) 只会写入源模板。如果审校人员修改了本地输出，请使用 [`gt save-local`](/docs/cli/reference/commands/save-local)，以便在后续运行中保留这些修改。

请测试你所配置的更新路径：当你通过已配置的推送、拉取请求或手动方式触发时，[Locadex](/docs/platform/locadex/guides/configuring-automations) 应创建或更新其翻译拉取请求。确认跟踪的是预期的分支。使用[随应用打包的译文](/docs/react/guides/storing-translations)时，已部署的应用无需依赖 GT 服务即可渲染所提供的文件。采用 CDN 投递时，请结合你的版本和缓存设置测试已发布的修改，包括用户收到修改前可能存在的延迟。

### 9. 确认公开语言版本可被搜索引擎发现

对于希望被搜索引擎收录的页面，请检查每个语言版本是否都具备可抓取的 URL、已翻译的标题和描述、预期的规范网址，以及有效的语言替代项。检查 [hreflang 引用](/kb/what-is-hreflang)是否相互对应，包括对当前页面自身的引用。如果替代项在站点地图中声明，请确认站点地图所表达的页面对应关系与之一致。

**通过条件：** 每个公开的语言 URL 都能加载预期内容，在需要时可被索引，并指向真实存在的替代版本。Google 的[本地化页面指南](https://developers.google.com/search/docs/specialty/international/localized-versions)介绍了受支持的注释方法。如需在 Next.js 中实现，请参阅[多语言 SEO 指南](/kb/multilingual-nextjs-seo)。

路径前缀、语言子域名和国家/地区域名都可以为各语言提供独立的 URL；[URL 结构指南](/kb/multilingual-url-structure)对这几种方式进行了比较。`Accept-Language` 请求头或 cookie 可用于选择访问者的语言，但仅凭它们并不会为每个版本生成可抓取的 URL (参见[语言重定向与 SEO](/kb/locale-routing-seo)) 。Google 的[多语言网站指南](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites)建议使用独立的 URL。需要登录才能访问的仪表板可能无需让各语言 URL 被索引；请根据产品的受众选择路由策略。GT 免费的 [Report Card](https://generaltranslation.com/report-card) 可以对公开网站的本地化情况做初步检查，但它无法检查需要登录的用户流程，也无法有意触发你的各种故障状态。

## 保留发布记录

记录构建版本、区域设置、用户旅程、浏览器或设备、预期结果、实际结果以及审核人。为每个失败项指定负责人。结账流程缺失翻译或主要操作按钮无法辨读，与轻微的措辞偏好不能等同处理；凡是认可的后备内容，都应明确记录在案。填写完整的记录示例如下：

| 构建版本             | 区域设置 | 检查项                   | 设备             | 预期结果                   | 实际结果                         | 结论             |
| ---------------- | ---- | --------------------- | -------------- | ---------------------- | ---------------------------- | -------------- |
| 4.12.0 (a1b2c3d) | `de` | 1. 结账时银行卡被拒           | Chrome，桌面端     | 显示德语错误信息及重试操作          | 显示德语错误信息，但按钮标签在 320px 宽度下被截断 | 失败：阻塞发布，已指定负责人 |
| 4.12.0 (a1b2c3d) | `pl` | 3. 购物车中有 2、5 和 22 件商品 | Safari，iPhone  | 正确显示波兰语的 few 和 many 形式 | 5 件商品时显示了 `few` 形式           | 失败：需修复复数键      |
| 4.12.0 (a1b2c3d) | `ar` | 6. 账户设置               | Chrome，Android | 布局镜像，返回箭头指向右侧          | 符合预期                         | 通过             |

## Related questions

- [如何找出未翻译的硬编码字符串？](https://generaltranslation.com/zh/kb/find-hardcoded-strings.mdx): 在 CI 中运行 linter，标记面向用户的字符串字面量，例如 JSX 可使用 eslint-plugin-i18next 的 no-literal-string 规则，Android 可使用 Android Lint 的 HardcodedText 检查，Rails 可使用 erb_lint 的 HardCodedString linter。然后切换到伪区域设置，逐一浏览应用，找出静态检查无法追踪到的文本。
- [语言切换器最佳实践：用户体验、SEO 与无障碍访问](https://generaltranslation.com/zh/kb/language-switcher.mdx): 用每种语言的本语名称来标注它，例如 Deutsch 或 日本語，不要使用国旗，因为国旗代表的是国家。每个选项都应通过可抓取的链接指向该语言版本的同一页面，用 cookie 记住用户的选择，并且切勿对已本地化的 URL 自动重定向。
- [什么是伪本地化？](https://generaltranslation.com/zh/kb/pseudo-localization.mdx): 伪本地化是一种测试方法：将源文本替换为改写后的版本——加上重音符号、长度扩充约 40%，并用方括号包裹——这样在还没有任何翻译之前，硬编码字符串、截断、字体显示异常和句子拼接等问题就会暴露出来。Android 为此内置了 en-XA 和 ar-XB 两个伪区域设置。
- [如何在 CSS 中支持 RTL（从右到左）语言？](https://generaltranslation.com/zh/kb/right-to-left-css.mdx): 在 html 元素上同时设置 dir="rtl" 和 lang，因为仅设置 lang 并不会改变文本方向；然后将 margin-left 等物理 CSS 属性替换为 margin-inline-start 等逻辑属性。Flex 行、Grid 列和默认文本对齐会自动翻转，而 translateX()、left 和 right 不会。
- [如何为多语言 Next.js 应用设置 SEO？](https://generaltranslation.com/zh/kb/multilingual-nextjs-seo.mdx): 为每种语言提供带前缀的独立 URL，例如 /en/about 和 /es/about，然后为每种已发布的语言提供 html lang、自引用的规范网址、包含 x-default 的 hreflang 替代项、翻译后的 title 和 description，以及站点地图条目。将未发布的版本标记为 noindex。General Translation 的 gt-next 会将每种语言路由到各自的 URL，并通过 getGT 翻译标题。

## Previous and next questions

- Previous question: [Transifex 替代方案：General Translation 与 Transifex 对比](https://generaltranslation.com/zh/kb/general-translation-vs-transifex.mdx)
- Next question: [应该自建 i18n，还是使用 General Translation？](https://generaltranslation.com/zh/kb/general-translation-vs-in-house-i18n.mdx)

## Sitemap

See the [Knowledge Base sitemap](https://generaltranslation.com/zh/kb/sitemap.md) for every article.