国际化与本地化实践

要解决什么问题

公开 Web 应用、SaaS 和多地区产品一旦面向非单一语言用户，界面里散落的硬编码文案、日期数字格式和 RTL 布局就会成为长期维护成本：翻译缺失无回退、德语等语言撑破布局、阿拉伯语方向错误。本技能把 i18n（可翻译） 与 L10n（实际翻译） 的术语、选型与落地习惯整理成可对照执行的清单，而不是泛泛的「多语言支持」口号。

技能如何组织内容

文档从 Locale（如 en-US、tr-TR）、RTL 等基础概念出发，说明不同项目类型（公开 Web、SaaS、内部工具等）是否值得投入 i18n。实现模式覆盖 React（react-i18next）、Next.js（next-intl）、Python（gettext） 等常见栈，并强调文件结构与命名空间划分。

该做 与 别做 对照列出工程细节：用翻译键而非原始文本、支持复数与 ICU 消息格式、用 Intl.DateTimeFormat / Intl.NumberFormat 处理 locale；避免拼接译文、假定各语言等长、在同一文件混用语言。常见问题表给出缺失翻译回退、硬编码检测、复数处理等对应做法；另含 RTL 支持与发布前检查清单（回退语言、RTL 测试、组件无硬编码等）。资料中还提到 scripts/i18n_checker.py，用于检测硬编码字符串与缺失翻译。

适用边界

个人单语言小项目可不必全量套用；内部工具需自行权衡。技能侧重模式与清单，具体框架版本、CI 集成和完整目录示例需结合你方仓库规范补充，不能替代框架官方文档的深度配置说明。