前言
在一个比较大的项目里面（有国际化需求的），国际化的支持是一个必不可少的； 那如何落地就得具体问题具体分析了，这里说说我遇到过并落地的一个改造方案；
说说项目背景，是一个迭代多年的产研类项目(整个系统是围绕react生态去研发的)，历史包袱挺多； 多种第三方库并存，也有iframe的场景以及自研的插件机制系统（现代沙盒隔离那一套）；
方案仅供参考，哈！
方案
基础信息（技术栈）
- 构建工具流：Gulp 4 Webpack 4
- 第三方库（lib）
- moment
- dayjs
- gantt
- ckeditor
- ...
- react 标准全家桶聚焦点 整合所有i18n资源，集中打包，前置加载(页面头部-C端渲染）; 而且我们这边不考虑IE，聚焦现代化的浏览器～
从以下个方面入手语言包覆盖
- 业务层面全部用i18next作为字段文案维护；
- 所有非第三方库自身，都可以算作是业务层面
- 组件库提供语言包端字段映射对象
- 第三方微微魔改
- 没有多语支持或者版本太老旧不好升级的
- 初始化时机篡改原型链
- 对于支持 切换的，比如moment，dayjs，ck
- 把对应的需要的语言对象构建好，丢给他们自己初始化即可！
- 没有多语支持或者版本太老旧不好升级的
语言资源必须集中化维护！（所以我们之前花了些时间做了整个系统的统一）
语言切换时机
- 页面加载过程中阻塞加载语言包，再继续后面的初始化逻辑
- 语言切换采用重载（reload）方案
为什么采用重载？因为会比较彻底和正确响应； 上面说到了，这是一个新老技术融合的项目，不纯粹！
重载有两个非常大的好处
- 从接口层发出语言标识，在进入用户界面时候数据就能拉到正确的响应数据（不同语言的response)
- 其次语言资源可以按需加载（也能非常正确的初始化）
流程图
gulp
为什么用gulp？gulp 在一些场景很好用（比如一些静态资源的转换，迁移等等）； 一股脑的丢webpack这类其实会带来很多构建开销；
所以语言文件用gulp watch实时去监听，产物打到特定的位置就好了；
这边的语言资源是作为一个npm模块来维护的，如图
locale下面就是不同语种，watch整个目录即可！ 比如这个task就是构建语言产物的，这个导出再并入gulp stream即可！(仅供参考)
代码语言：javascript复制import { resolve } from 'path';
import { src, dest, parallel, watch } from 'gulp';
import { accessSync, constants, statSync, readdirSync } from 'fs';
import gulpEsbuild from 'gulp-esbuild';
import { getDevModeAndParams } from '../../utils';
function checkDirExist(checkPath) {
try {
accessSync(checkPath, constants.R_OK | constants.W_OK);
console.log(`${checkPath} 路径gulp能读写`);
} catch (err) {
console.error(`${checkPath} 无法尝试访问,请先检测是否存在`, err);
process.exit(1);
}
}
function getLocaleDirName(path) {
if (!path) throw new Error('path no exist');
try {
const localeDirName = [];
const localeGulpTaskName = [];
const readList = readdirSync(path);
for (const item of readList) {
const fullPath = resolve(path, item);
const stats = statSync(fullPath);
if (stats.isDirectory()) {
localeDirName.push(item);
localeGulpTaskName.push(`${item}_build_locale_task`);
}
}
return {
localeDirName,
localeGulpTaskName,
};
} catch (error) {
console.log(
'%c
