如何将i18n多语言文件夹从项目主仓库独立拆分到其他仓库？

1. 初始化独立翻译仓库 #

• 新建空白专属仓库，将主仓库public/locales下的所有语言代码子目录、各目录内的translation.js文件完整迁移到新仓库，完全保留原有目录层级和文件命名规则，避免后续加载逻辑不兼容
• 仓库内新增前置校验逻辑：提交PR前自动校验各语言翻译文件的JSON格式合法性、key是否与基准语言（通常为英文）对齐，拦截无效修改

2. 主仓库引入翻译资源（两种方案二选一即可） #

方案A：NPM包形式引入（稳定性更高） #

• 给独立翻译仓库新增package.json配置，将整个locales目录作为发布产物，按照语义化规则打版本号，文案修改合并后自动发布新包
• 主仓库安装该翻译包作为依赖，修改构建配置，构建时自动将翻译包内的locales目录拷贝到主仓库的public目录下。以Vite为例，可搭配vite-plugin-static-copy插件配置：

// vite.config.js 新增配置
import { viteStaticCopy } from 'vite-plugin-static-copy'
export default {
  plugins: [
    viteStaticCopy({
      targets: [
        { src: 'node_modules/@你的组织名/i18n-locales/locales/*', dest: 'public/locales' }
      ]
    })
  ]
}

方案B：CI构建时动态拉取（实时性更高） #

• 不需要修改主仓库依赖，仅在主仓库的CI构建流程中新增一步：构建开始前拉取独立翻译仓库指定分支的locales目录到主仓库的public路径下，适合需要文案修改后立即生效、不想手动更新依赖版本的场景

3. i18n逻辑适配 #

只要你保持了原有的locales目录结构，原有i18n-backend的加载路径配置不需要做任何修改，直接兼容原有逻辑，无业务侵入性改动

4. 协作规则调整 #

• 给独立翻译仓库单独配置PR评审权限，仅负责文案的团队成员有权限审核，不需要UI开发团队参与，大幅降低评审成本
• 可配置独立的自动化流程：比如PR合并后自动校验、自动打版本发布，不需要人工介入操作

效果验证 #

改单语言单条文案时，仅需要修改独立翻译仓库内对应语言的1个translation.js文件，PR仅涉及1个文件变更，完全不会触及主仓库的UI业务代码，实现完全解耦

内容的提问来源于stack exchange，提问作者nick