在 React 应用程序中构建国际化：可扩展本地化综合指南

“纵有疾风来，人生不言弃”，这句话送给正在学习文章的朋友们，也希望在阅读本文《在 React 应用程序中构建国际化：可扩展本地化综合指南》后，能够真的帮助到大家。我也会在后续的文章中，陆续更新文章相关的技术文章，有好的建议欢迎大家在评论留言，非常感谢！

引言

过去三个月，我一直在独立开发一个大型SaaS项目。虽然过程令人兴奋，但也充满挑战。最近两周，我的首要任务是在保证质量的同时交付高优先级的功能。

其中一个关键决策是是否集成国际化（i18n）以支持多种语言。最初，我倾向于先发布纯英文版本，之后再使用机器翻译（MT）进行本地化。然而，作为单人团队，我目前选择专注于一个高利润的市场。

虽然对我的项目来说国际化是可选的，但在专业环境中，由于法律法规的要求，国际化至关重要。这篇博文将探讨如何设计一个可扩展、高效的i18n架构，避免高复杂度或结构混乱等陷阱，这些经验对于独立开发者和团队都大有裨益。

由于我决定在我的项目中不实现i18n，我分享这份指南来帮助其他人（以及未来的我！）。

目标

一个优秀的国际化系统应该：

• 可扩展性: 支持跨团队无缝协作进行翻译和语言更新。
• 模块化: 保持简洁的结构，易于扩展，无需额外开销。
• 可预测性: 遵循一致、可执行的本地化模式。
• 易用性: 适合不同技能水平的开发者使用。

可用工具

对于JavaScript的国际化，以下是一些常用的工具：

• i18next: 一个成熟、功能强大的库，非常适合可扩展的专业级本地化。
• 其他方案: formatjs、polyglot.js、linguijs、globalizejs、Mozilla的Fluent。

每个工具都有其优缺点。为简便起见，本指南重点介绍i18next。

架构设计

国际化文件夹结构

架构的核心是i18n文件夹，包含三个关键组件：

1. translations文件夹: 存储每种语言的JSON文件（例如en.json、ar.json、zh.json）以及新语言的base.json模板。
2. index.js: 配置和初始化i18n库（例如i18next），设置默认语言和其他选项。
3. keys.js: 定义翻译键的集中式结构，确保一致性并避免重复。

文件夹结构示例：

<code>src/
├── i18n/
│   ├── translations/
│   │   ├── en.json       # 英文翻译
│   │   ├── ar.json       # 阿拉伯语翻译
│   │   ├── zh.json       # 中文翻译
│   │   └── base.json     # 新语言模板
│   ├── index.js          # i18n配置
│   └── keys.js           # 一致性键的集中式定义</code>

keys.js 作为中心枢纽

keys.js文件反映项目的结构，按功能或模块对键进行分组。这种结构使密钥管理直观且可扩展。

keys.js示例：

<code>src/
├── components/
│   ├── FeatureA/
│   │   ├── index.jsx
│   │   └── FeatureAStyles.css
│   └── shared/
│       └── LanguageSwitcher.jsx
├── i18n/
│   ├── translations/
│   │   ├── en.json
│   │   ├── ar.json
│   │   └── base.json
│   ├── keys.js
│   └── index.js
├── App.jsx
└── index.js

进阶

1. 利用人工智能进行翻译: 使用机器翻译（例如Google Translate API）快速翻译。例如提示：

   "将以下JSON翻译成中文：{en.json的内容}"

2. 后端驱动的翻译: 将翻译集中在后端，无需部署代码即可实现动态更新。选项包括GitOps或专用后端服务。

结论

国际化是应用程序在全球范围内扩展的关键步骤。遵循本指南，您将拥有一个可扩展、模块化且易于使用的架构，支持个人项目或大型团队的无缝本地化。

祝您编码愉快！

— Ahmed R. Aldhafeeri

今天关于《在 React 应用程序中构建国际化：可扩展本地化综合指南》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！