# React19+ts+Tailwindcss4+vite7.x+zustand+reactrouter+monorepo

**Repository Path**: wen-pro/react_monorepo

## Basic Information

- **Project Name**: React19+ts+Tailwindcss4+vite7.x+zustand+reactrouter+monorepo
- **Description**: 打造企业级Monorepo项目架构
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2025-08-15
- **Last Updated**: 2025-09-11

## Categories & Tags

**Categories**: Uncategorized

**Tags**: monorepo, React, TypeScript, Tailwind, zustand

## README

# 多语言与国际化指南（Train Monorepo）

[English](./README.en-US.md)

本仓库采用 pnpm workspaces 的 monorepo 架构，包含：

- packages/shared：复用组件与工具库
- packages/train、packages/work：基于 Vite + React + TypeScript 的前端应用

本文档介绍如何在该架构下实践国际化（i18n），推荐合适的多语言库，并解释 i18n / L10n / G11n 的区别与应用场景。

## 推荐的多语言方案与库

根据当前技术栈（React + Vite + TS + Monorepo），推荐以下方案：

1. i18next 生态（推荐优先）

- 依赖：i18next + react-i18next
- 可选：i18next-browser-languagedetector（语言自动检测）、i18next-http-backend（远程加载词条）
- 优点：生态成熟、文档完备、支持命名空间与懒加载、与 Vite 按需加载兼容、容易把公共/业务词条拆分到 shared 与各应用
- 适用：大多数中大型前端项目

2. LinguiJS（编译时、ICU 支持）

- 优点：CLI 支持提取词条、强 ICU 消息格式（复数/性别）、对 TypeScript 友好、适合在 CI 中集成
- 适用：希望规范化管理文案、需要复杂语法（复数/占位符）的团队

3. FormatJS / react-intl（ICU 强、标准化）

- 优点：成熟的 ICU 支持、良好生态
- 适用：对 ICU 格式依赖重、追求标准化的团队

简要建议：如果你希望“快速落地 + 易维护”，优先选择 i18next + react-i18next；如需严格的消息提取与 ICU 能力，考虑 LinguiJS 或 react-intl。

## 目录结构与组织建议

- 公共词条（shared）：
  packages/shared/locales/
  ├─ en/
  │ └─ common.json
  └─ zh-CN/
  └─ common.json

- 应用词条（按命名空间拆分）：
  packages/train/locales/
  ├─ en/
  │ ├─ page-home.json
  │ └─ menu.json
  └─ zh-CN/
  ├─ page-home.json
  └─ menu.json

- 每个应用可以根据自身页面/模块创建不同 namespace 的 json 文件；shared 放通用词条（例如按钮、通用提示）。

## 实现步骤（以 i18next 为例）

1. 安装依赖（在 monorepo 根目录执行）

- pnpm -w add i18next react-i18next
- 可选：pnpm -w add i18next-browser-languagedetector i18next-http-backend

2. 在 shared 封装初始化（例如 packages/shared/src/i18n/index.ts）

- 创建并导出一个 setupI18n(initOptions) 函数，注册公共命名空间（common 等）
- 支持按需加载：基于 import.meta.glob 动态导入各应用的命名空间资源

3. 在各应用入口挂载 Provider（packages/train/src/main.tsx 或 App.tsx）

- 调用 setupI18n 并使用 I18nextProvider 或 useTranslation
- 在路由切换时可按需加载对应 namespace

4. 组件中使用

- 使用 hooks：const { t } = useTranslation('namespace')
- 使用 key：t('menu.home')、t('page.title')

5. 语言切换与持久化

- 配合语言检测器，或在 UI 中提供语言切换（比如放在头像下拉菜单）
- 将当前语言存储在 localStorage，并在初始化时读取

## 最佳实践

- 命名空间：以页面/模块维度拆分词条，保持文件小而清晰
- Key 命名：语义化，避免硬编码文本；例如 menu.home、form.submit
- 懒加载：使用 import.meta.glob 按需动态加载，减少首屏 bundle
- 回退语言：配置 fallbackLng，例如 'en'
- 统一来源：公共词条放 shared，各应用只维护业务私有词条
- 翻译流程：结合 CI（如 PR 校验词条是否存在、是否遗漏翻译）

## 概念解释与应用场景

- 国际化（Internationalization，I18n）：让产品具备支持多语言/多地区的能力的“工程准备”，如提取文案、日期/货币格式化、布局适配等。应用场景：在启动全球化前，先把工程改造为可配置、可切换语言的形态。
- 本地化（Localization，L10n）：针对某个特定语言/地区进行“落地适配”，包括翻译、时区/度量衡/货币符号、图片/示例等本地内容。应用场景：面向中国区、东南亚、欧洲用户分别提供符合当地习惯的内容与格式。
- 全球化（Globalization，G11n）：企业层面的全球业务布局与运营，涵盖市场、合规、客服、支付、物流等一揽子工作，其中技术上的 i18n 与 L10n 是 G11n 的基础支撑。应用场景：公司决定进入多个海外市场，需要产品、运营、技术协同推进。

---

如需我直接为本仓库落地 i18next 初始化与目录搭建，请告诉我你偏好的语言和默认语言，我会在 shared 和各应用中补齐示例代码与配置。