internationalization

国际化

以对用户、搜索引擎和负责维护内容的团队都有效的方式添加语言和地区。不依赖特定技术栈。

---

适用场景

• 添加首个非英语（或非默认）语言
• 为现有国际化网站添加其他区域设置
• 选择语言的 URL 结构
• 实现 hreflang 标签
• 设计翻译工作流
• 处理货币、日期、时间和数字格式
• 为从右向左书写的语言设计或修复布局
• 审查效果不佳的国际化部署

不适用场景

• 单语言网站（请使用其他技能）
• 与语言无关的域名策略（请使用 domain-strategy）
• 与区域设置无关的内容策略（请使用 content-strategy）
• 营销文案制作（请使用 content-and-copy）

---

所需输入

• 涉及的区域设置（语言 + 地区，例如 en-US、de-DE、fr-CA）
• 每个区域设置的业务理由（优先级、受众规模）
• 现有网站架构
• 翻译资源（内部团队、代理机构、AI 辅助、社区）
• 内容量和更新频率

---

框架：5 个层面

国际化涉及方方面面。分为 5 个层面，每个层面都有各自的决策。

第 1 层：URL 结构

区域设置如何体现于 URL 中。

模式	示例	适用场景
国家和地区顶级域名（ccTLD）	example.de、example.fr	重点面向特定国家，拥有独立法人实体，且愿意维护独立域名
子域名	de.example.com、fr.example.com	需要逻辑隔离，愿意分别托管，常用于大型网站
子文件夹	example.com/de/、example.com/fr/	集中 SEO 权重，管理最简单，适用于大多数网站
URL 参数	example.com?lang=de	应避免；SEO 信号较弱

对于大多数网站，默认选择子文件夹。只有存在具体原因（法律、基础设施或品牌）时，才选择子域名或 ccTLD。

在选定的模式中，还需决定：

• 仅使用语言（/de/），还是同时使用语言和地区（/de-de/、/de-at/、/de-ch/）？
• 默认区域设置放在根域名（example.com），还是放在文件夹中（example.com/en/）？

默认区域设置放在根域名的模式很常见，但会使 hreflang 变得复杂（根域名需要 x-default，默认语言页面也需要规范链接）。

第 2 层：内容结构

如何组织不同区域设置的内容。

模式 A：镜像。 每种区域设置都有所有页面。翻译本身就是页面。适用于内容可控的营销网站。

模式 B：子集。 部分内容在所有区域设置中提供，部分内容仅在选定的区域设置中提供。常见于产品页面（仅展示可用产品）、博客（仅翻译部分文章）或因法规而异的内容。

模式 C：本地化。 每种区域设置都有自己的内容，且与其他区域设置的内容大体独立。常见于媒体或社区网站。

大多数营销网站采用 A。大多数大型网站出于实际需要最终会采用 B。C 适用于地区编辑特色鲜明的网站。

该模式会影响：

• 内容模型的设计方式（每个内容条目是否需要父级/翻译关系？）
• 翻译的管理方式（工作流会假定这种结构）
• 团队的协调方式

第 3 层：hreflang 和规范链接

向搜索引擎说明哪些页面是译文，哪些页面彼此独立。

hreflang 用于指定每个版本的语言和可选地区。

<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/page">
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/page">
<link rel="alternate" hreflang="de-DE" href="https://example.com/de-de/page">
<link rel="alternate" hreflang="x-default" href="https://example.com/en-us/page">

规则：

• 每个页面都列出所有对应的译文页面（包括自身）
• 页面必须相互指向（页面 A 指明页面 B 是其德语版本；页面 B 指明页面 A 是其英语版本）
• x-default 是面向地区未指定用户的回退版本
• 每个页面都有指向自身的规范链接（而不是指向默认语言页面）

hreflang 可以放在 HTML head、HTTP 标头或 XML 站点地图中。大型网站最好使用站点地图；小型网站使用 HTML head 即可。

规范链接：

• 每个页面都指向自身
• 不要让德语页面的规范链接指向英语页面（搜索引擎将不会为德语页面编入索引）

第 4 层：翻译工作流

内容如何翻译、保持最新并进行质量控制。

翻译来源：

• 内部译员（全职员工）
• 翻译机构（按字计费，专业）
• 社区贡献者（志愿者，质量不一，免费）
• AI 辅助加人工审核（成本低、速度快，质量不断提升）
• 仅使用 AI（适用于部分内容，不适用于品牌关键内容）

工作流阶段：

1. 使用源语言撰写源内容
2. 通过 TMS（翻译管理系统）或电子表格发起翻译请求
3. 借助翻译记忆库完成翻译（避免重复翻译复用的短语）
4. 由第二位译员或当地员工审核
5. 在翻译之外进行本地化（货币、单位、示例、文化引用）
6. 在目标区域设置中发布
7. 源内容变更时同步更新

总内容超过约 10K 个单词时，TMS 才能发挥价值。低于这个规模，使用电子表格并做好命名管理即可。

同步更新是最难的部分。 源内容会发生变化，译文也会过时。如果没有流程，最终各区域设置的内容就会与源内容脱节。

第 5 层：适配区域设置的用户体验

除了翻译，还必须调整体验。

货币： 在适用的情况下，以当地货币显示。欧洲区域设置使用 EUR，日语区域设置使用 JPY，依此类推。法语区域设置的页面不要向法国用户显示 USD。

数字： 千位分隔符和小数分隔符各不相同。en-US 使用 1,000.50，de-DE 使用 1.000,50。

日期和时间： 格式和顺序各不相同。en-US 使用 MM/DD/YYYY，en-GB 使用 DD/MM/YYYY，YYYY-MM-DD（ISO）是通用格式，但许多人并不熟悉。

姓名和地址： 字段顺序和必填项各不相同。使用适配国家/地区的地址表单。

电话号码： 通用格式采用 E.164 国际格式；显示格式则按区域设置调整。

单位： 公制与英制。世界上大多数地区使用公制；美国使用英制。有些产品需要同时支持两者。

从右到左（RTL）的语言： 阿拉伯语、希伯来语、波斯语、乌尔都语。布局需要翻转：导航移至右侧，文本右对齐，表示方向的图标也可能需要翻转。CSS 逻辑属性（使用 margin-inline-start 代替 margin-left）可以简化处理。

语言切换器： 要醒目，但不要喧宾夺主。使用语言自身的名称显示区域设置（例如显示 “Deutsch”，而不是 “German”）。保存用户的选择。不要仅根据浏览器语言自动重定向，除非同时提供返回方式。

文化敏感性： 颜色、图像、示例和引用内容可能无法直接转换。避免在产品图片中使用手势。除非进行本地化，否则避免使用特定国家/地区的内容。

---

工作流

第 1 步：确定区域设置

不要只因为可以添加语言就添加。每种区域设置都会带来持续的维护成本。

• 受众研究：访客和潜在客户来自哪里？
• 业务优先级：哪些市场是增长目标？
• 内容准备情况：是否有资源持续维护？
• 法律要求：法规是否要求进行本地化（GDPR、无障碍法律）？

第 2 步：选择 URL 结构

大多数情况下使用子目录。记录选择及其理由。

第 3 步：选择内容结构

采用镜像、子集或本地内容。切实评估哪种方式能够长期维持。

第 4 步：设置 hreflang 和规范链接

在推出第二种区域设置之前就完成设置，即使它只有一个额外页面也不例外。

第 5 步：设置翻译工作流

选择 TMS 或电子表格系统。记录工作流。指定译员和审核人员。

第 6 步：在翻译之外进行本地化

针对每种区域设置：

• 货币、数字、日期、单位
• 如有需要，使用适配区域设置的图片
• 地址表单
• 客户服务时间和联系方式

第 7 步：实现语言切换器

• 在页眉或页脚中醒目显示
• 清楚标示当前区域设置
• 使用语言自身的名称列出所有可用区域设置
• 保存用户的选择（Cookie 或本地存储）
• 不根据浏览器语言自动重定向；改为提供建议

第 8 步：测试

• 每种语言环境都能正确呈现
• hreflang 链接有效（使用检查工具）
• 每个页面的规范链接均指向自身
• 货币和日期正确
• RTL 布局正确（适用于 RTL 语言环境）
• 语言切换器正常工作并能记住选择
• 从搜索引擎的角度看：每种语言环境都可抓取和编入索引

第 9 步：发布并监控

每种语言环境都要监控：

• 索引率
• 来自目标地区的流量
• 该语言环境的互动指标
• 翻译的时效性（源内容更改后，翻译何时更新？）

第 10 步：维护

• 翻译更新频率（源内容更改后，翻译何时跟进）
• 每季度评估语言环境的表现
• 停用不可行的语言环境（这比勉强维护一个无人使用的语言环境要好）

---

常见失败模式

根据浏览器语言自动重定向。 用户在德国，但偏好英语。网站强制显示德语，令人沮丧。应提供建议，而不是重定向。

所有页面都规范指向默认语言。 搜索引擎无法为翻译内容编入索引。每个页面都应将规范链接指向自身。

缺少双向 hreflang。 德语页面将英语列为其翻译版本，英语页面却没有列出德语。搜索引擎会认为这种对应关系未经确认。

需要区分地区时，hreflang 只标注语言。 如果只有一个西班牙语版本，hreflang="es" 就可以。如果同时有 es-ES（西班牙）和 es-MX（墨西哥），则应同时使用这两个地区代码。

把自动翻译内容当作最终版本。 机器翻译可以作为可接受的起点。任何面向用户的内容都必须经过人工审核。

在文案中固定写入货币。 正文中的“$99/month”会给欧洲用户带来问题。应使用可根据地区调整的模板化货币格式。

日期格式硬编码。 在代码中写入“January 5, 2024”，无法适配不同地区。应使用支持语言环境的日期格式化库。

字段标签仍使用源语言。 正文已翻译，但表单标签未翻译，会造成不一致。应将界面字符串一并纳入本地化。

错误消息未翻译。 用户提交表单后，在法语页面上看到英文错误提示，令人沮丧。应翻译界面状态文本。

邮件未翻译。 网站使用法语，但事务性邮件却是英文。应将邮件翻译成相同语言。

在 CMS 中遗漏语言环境。 编辑人员可能忘记更新某种语言环境，导致内容出现偏差。应使用能显示内容偏差的 TMS 或工作流。

无法在流程中途正常工作的语言切换器。 用户在德语结账页面切换到法语，却跳转到了法语首页。应尽量让用户跳转到新语言环境中的同一页面。

RTL 布局并未真正翻转。 为 LTR 硬编码的外边距和内边距会导致问题。应使用 CSS 逻辑属性。

停用语言时没有设置重定向。 停止支持法语后，旧法语 URL 返回 404。应将其重定向到其他受支持语言中最接近的对应页面。

---

输出格式

国际化计划包括：

• 语言环境列表： 标注优先级和受众依据
• URL 结构： 选择的模式及原因
• 内容结构： 镜像、子集或本地化
• hreflang 计划： 实施方式
• 翻译工作流： 来源、阶段和工具
• 本地化检查清单： 翻译以外的内容（货币、日期等）
• 语言切换器设计： 位置、行为和持久性
• 测试计划： 每种语言环境要验证的内容
• 维护计划： 更新频率和偏差检测

---

参考文件

• references/locale-checklist.md：按类别（URL、内容、用户体验、格式、法律）整理的逐语言环境检查清单，涵盖翻译以外所有需要调整的内容。