国际化、本地化与时区工程

国际化不只是翻译字符串

国际化（i18n）让产品具备适配不同语言和地区的结构能力，本地化（l10n）则为具体地区准备语言、格式和内容。工程问题还包括路由、资源拆分、复数、日期时区、数字货币、排序、文本方向和发布流程。

语言与地区

语言标签应使用 BCP 47 形式，例如 zh-CN、zh-HK、en-GB。语言、地区和时区不是同一个概念：用户选择英文不代表使用美元，也不能据此推断所在时区。

URL 应能够表达并分享语言状态，例如 /zh/notes/。首次访问可以参考浏览器偏好，但明确的 URL 或用户设置优先，重定向不能让搜索引擎和用户陷入循环。

使用平台格式化能力

使用 Intl.DateTimeFormat、Intl.NumberFormat、Intl.RelativeTimeFormat 和 Intl.PluralRules 处理地区差异，避免手工拼接：

const formatter = new Intl.DateTimeFormat(locale, {
  dateStyle: 'medium',
  timeStyle: 'short',
  timeZone,
})

接口中的时间应明确使用时间点还是不带时区的当地日期。生日、会议时间和服务器时间戳具有不同语义，不能都靠 new Date(string) 猜测。

翻译资源

• Key 表达稳定语义，不直接把长英文原文当作标识
• 带变量的消息使用支持复数和语法变化的消息格式
• 按语言或路由拆分大型资源，但避免切得过细产生请求瀑布
• 缺失翻译在开发和 CI 中可见，生产环境有明确回退
• 翻译更新与功能变更关联，并允许产品和译者预览真实上下文

RTL 与布局

通过 dir、逻辑 CSS 属性和方向感知图标支持 RTL。文本方向改变不仅影响对齐，还会影响返回箭头、步骤流、混合数字文本和键盘导航预期。

实践任务

1. 为应用增加中文和英文 URL，并保持刷新、分享和回退正确。
2. 展示包含复数、货币和用户时区的任务截止时间。
3. 添加一种 RTL 测试语言，检查布局和图标。
4. 在 CI 中检测缺失 Key、未使用 Key 和插值参数不一致。

验收标准

• 语言状态可通过 URL 分享并持久化
• 日期、数字和复数由 Intl 或可靠消息格式处理
• 服务端和客户端使用一致 locale 与 time zone，避免 Hydration 差异
• RTL 下关键流程可用，焦点顺序合理
• 缺失翻译不会静默显示内部 Key

参考资料

• MDN：Intl
• W3C：Internationalization