前端国际化文件合并冲突解决方案

前言：项目需求多语言，团队20+人共同修改一个国际化文件，冲突可想而知。甚至解决冲突时间都大于开发时间...

一、国际化文件放在后端

通过接口返回国际化文件，自然解决了冲突问题，后续修改也可以直接改库，前端无需重新打包部署。虽然这个方法可行，但是我们项目组并没有采用这种方案。原因有下：

• 国际化文件在前端已成型，迁址至后端也需要一定的工作量。
• 毕竟接口返回是需要时间的，甚至有服务挂了的情况，这种情况前端页面看到的就是各种 common.username类似的文本，用户体验极差。就算用了 || + 默认值的方式，也要增加不少的工作量去维护默认值。

二、国际化模块化

那么既然只能在前端做，就只能拆分模块化了。按路由菜单区分不同模块，不同组各自维护自己的模块，合并冲突解决！

我们的国家化文件为.yaml 文件，当然你的可能是.json文件，拆分思路是一样的。

1.所有国际化文件存放在locales下

2.在locales下以模块或菜单命名新建文件夹

例如有system和user两个菜单，那么就新建这两个文件夹

3.在每个文件夹下分别新建zh.yaml和en.yaml

4.在i18n.ts加载所有文件

const enModuldes = import.meta.glob("../../locales/**/en.y(a)?ml", {
  eager: true
});
const zhModuldes = import.meta.glob("../../locales/**/zh.y(a)?ml", {
  eager: true
});

5.最关键一步：重排数据结构

引入的这两个文件是不能直接使用的，我们希望他变成 key: {zh: "value1",en: "value2"} 的格式

const siphonI18n = (pathObj, acc = {}) => {
  for (const path in pathObj) {
    if (typeof pathObj[path].default === "object") {
      for (const key in pathObj[path].default) {
        if (acc[key]) {
          acc[key] = { ...acc[key], ...pathObj[path].default[key] };
        } else {
          acc[key] = pathObj[path].default[key];
        }
      }
    }
  }
  return acc;
};

6.加载文件

export const localesConfigs = {
  zh: {
    ...siphonI18n(zhModuldes)
  },
  en: {
    ...siphonI18n(enModuldes)
  }
};

通过以上操作，我们的国际化文件就已经拆好模块啦。妈妈再也不用担心合并冲突了~

感谢观看，如果对你有帮助，希望可以点赞、收藏、关注