网络编程 
首页 > 网络编程 > 浏览文章

vue项目实现多语言切换的思路

(编辑:jimmy 日期: 2024/12/24 浏览:3 次 )

Web 项目多语言(i18n,即国际化)是比较常见的需求,常规的做法大概有以下几种:

  1. 每种语言单独开发页面,适用于 CMS 之类的网站
  2. 多语言文本和页面结构分离,运行时动态替换。适用于单页应用(SPA)
  3. 直接用网页翻译插件,机器翻译。这种效果不太理想,同时有一些局限性(后面会讲到)

问题

每一种方案都有各自的优点和局限性,具体项目应该根据实际情况选择。最近在工作中碰到的需求是要在现有的项目基础上快速推出多语言版本。项目是基于 Vue.js 开发的,已经迭代过很多版本了。其实一开始是有规划多语言的,也引进了 vue-i18n 插件。这个插件就是上面第二种方案,用 JSON 文件管理多语言的文本资源,在 Vue 组件模板里通过键名引用文本。但是要管理这些英文键名比较麻烦,命名就很头疼。而且阅读代码的时候也很难从键名快速识别出对应的中文。后面发现 VS Code 有相关的插件,可以显示出对应的中文,但是代码找起来还是有点麻烦。再加上产品的多语言版本一直没有提上日程,时间久了就嫌麻烦,慢慢地就直接在模板里写中文了。

结果,该来的还是来了。老板突然说最近要推出英文版,后续还有其他语言。一开始的想法是直接用 Chrome 浏览器自带的 Google 翻译功能,怎么快怎么来。但经过一番测试,发现了不少问题。首先机翻的效果肯定是要打折扣的,但这还在接受范围内。最关键的是会影响到功能使用。什么问题呢?由于项目是用 Vue.js 开发的单页应用,页面内容完全是用 JS 动态渲染的。有些对话框内的文字 Google 翻译就忽略了。另外,Google 翻译只处理了 DOM 文本节点,input输入框内的文字(包括placeholder)被忽略了。最严重的问题是,经过 Google 翻译处理后的 DOM 元素,竟然失去了 Vue 响应式特性,数据变化后 DOM 内的文字不会更新了!

如果要继续采用浏览器 Google 翻译的方案,就要解决这几个问题。通过调试发现 Google 翻译用的 JS 脚本是嵌入到浏览器 VM 里的,通过 HTTP 调用翻译服务,然后修改 DOM 元素。JS 脚本是压缩混淆过的,格式化后也很难看。想要找到更新 DOM 的代码,然后用自己的逻辑去覆盖?眼睛都看瞎了,还是算了。

vue项目实现多语言切换的思路

鉴于以上原因,浏览器自带的 Google 翻译方案基本不考虑了。

现在只剩下第二种方案了,语言配置文件和页面结构分离。前面提过,vue-i18n用得不彻底,如果把所有组件重新规范化,工作量太大了。有没有办法不修改现有代码,也能实现文本翻译呢?很自然地就想到了 Google 翻译的思路,直接对页面渲染结果进行翻译。自己翻译的优势就是,可以精细地控制 DOM 操作,比如可以把输入框里的文本和placeholder也翻译出来。同时,经过研究发现,Vue 组件通过数据绑定渲染出来的 DOM 元素,包含的文本内容不能直接通过 innerHTML或者innerText修改,这样会导致响应式失效。解决办法是操作它的子元素,也就是文本节点(nodeType为3的节点),修改它的 textContent属性。

多语言配置映射表

跟 Google 翻译不同之处在于,我们采用静态翻译,也就是通过多语言配置文件映射。 vue-i18n 是每种语言准备一个 JSON 文件,属性名用英文,用命名空间(多层级对象)的方式避免命名冲突。我直接简化了,用一个 JS 对象存储所有语言版本,键名就是页面用到的中文。随着日积月累的开发迭代,这些中文散落在几百个文件里……我的做法是用 VS Code 全局正则搜索,把查找结果复制出来,写一个 JS 方法把这些字符串处理成 JS 对象。

vue项目实现多语言切换的思路

匹配中文的正则(不够全面,有些还夹杂了其他符号):

[A-Z]*[\u4e00-\u9fa5][,,!! 0-9a-zA-Z\u4e00-\u9fa5]*

将结果复制到翻译工具翻译,再写一个函数把这些文本合并成对象,并保存到labels.js文件中备用。

var kv = dist.reduce((acc,cur, index) => {
acc[cur]=en[index] || cur;return acc;
},{})

对象的结构大致如下:

// labels.js
export default {
 客户性名: {
  en: 'Customer Name',
 },
 // 动态文本,后面会讲到
 '剩余{0}台矿机未登记': {
  en: '{0} unregistered',
 },
 xxxx: {
  en: 'XXX',
 }
}

操作 DOM

跟 Google 翻译类似,我们也采取事后更新 DOM 的方式来进行翻译。由于是单页应用,随着用户的操作,会不停地更新 DOM。一开始的想法是监听整个 body的变化,在回调里再更新 DOM。监听 DOM 变化有一个原生的 API 可用,就是 MutationObserver。

mounted() {
 this.observeDOM(document.body);
},
methods: {
 observeDOM(el) {
  let mutationTimer;
  const vm = this;
  const observer = new MutationObserver(() => {
   // 类似于 debounce 的效果,多次调用合并为一次
   clearTimeout(mutationTimer);
   mutationTimer = setTimeout(() => {
    if (!vm.mutationFromTrans) {
     translate();
     vm.mutationFromTrans = true;
     setTimeout(() => {
      vm.mutationFromTrans = false;
     }, 300);
    }
   }, 100);
  });
  const options = {
   childList: true, // 监视node直接子节点的变动
   subtree: true, // 监视node所有后代的变动
   attributes: true, // 监视node属性的变动
   characterData: true, // 监视指定目标节点或子节点树中节点所包含的字符数据的变化。
  };
  if (this.language === 'en') {
   observer.observe(el, options);
  }
 },
}

但是试过之后发现这会导致无线循环,因为没有判断 DOM 的变化来自用户操作还是翻译本身。所以代码里后面加了判断,但是结果依然不理想。这种操作代价太大了,页面性能受了很大影响。而且还有个很明显的问题,就是进入到新的界面会闪一下,从中文变成英文。这个体验太糟糕了。后面有改进办法。

翻译

先来来看下翻译的过程。翻译就是从多语言配置对象里查找匹配的属性名,获取对应语言的属性值。这对于静态文本来说比较简单,直接用属性名就好了。但是对于动态的文本怎么处理呢?由于中英文表达方式不一样,这种文本不能简单地拆分成多个部分单独处理,而是要在英文的表达方式里替换动态数据。我的做法是使用带格式的键名,比如{0}这样的占位符。在查找的时候,优先匹配固定文本。因为大部分情况是固定文本,而且这种匹配是O(1)时间复杂度的,优先判断会提高性能。匹配失败的时候才去提前构造好的正则列表里遍历匹配,成功则提取正则匹配的group用于替换动态数据。如果失败,说明没有对应的翻译,直接返回原始字符串就行了。

const keys = Object.keys(words);
// 提前缓存正则,避免重复执行消耗性能
const regExps = keys.reduce((acc, key) => {
 // 模板型键名
 if (key.indexOf('{0}') > -1) {
  const reg = new RegExp(key.replace('{0}', '(.+)'));
  acc.push({
   expression: reg,
   key,
  });
 }
 return acc;
}, []);
export function translate(el = document.body, lang = 'en') {
 const kv = words;
 if (!el.querySelectorAll) {
  return;
 }
 const _trans = label => {
  const text = label"htmlcode">
const __patch__ = Vue.prototype.__patch__;
Vue.prototype.__patch__ = function() {
 const elm = __patch__.apply(this, arguments);
 if (this.$store?.getters?.language) {
  translate(elm, this.$store?.getters?.language);
 }
 return elm;
};

至此,基本完成了多语言翻译。经过权衡对比,这个方案算是比较省时省力又能完成需求的了。当然,这种方案或多或少对页面性能有一定影响,毕竟增加了 DOM 更新的时间。尤其是动态文本较多的情况,涉及到遍历正则匹配,比较耗时。如果大家有更好的方案,欢迎留言!

以上就是vue项目实现多语言切换的思路的详细内容,更多关于vue项目多语言切换的资料请关注其它相关文章!

上一篇:逐行分析鸿蒙系统的 JavaScript 框架(推荐)
下一篇:vue实现放大镜效果
一文看懂荣耀MagicBook Pro 16
荣耀猎人回归!七大亮点看懂不只是轻薄本,更是游戏本的MagicBook Pro 16.
人们对于笔记本电脑有一个固有印象:要么轻薄但性能一般,要么性能强劲但笨重臃肿。然而,今年荣耀新推出的MagicBook Pro 16刷新了人们的认知——发布会上,荣耀宣布猎人游戏本正式回归,称其继承了荣耀 HUNTER 基因,并自信地为其打出“轻薄本,更是游戏本”的口号。
众所周知,寻求轻薄本的用户普遍更看重便携性、外观造型、静谧性和打字办公等用机体验,而寻求游戏本的用户则普遍更看重硬件配置、性能释放等硬核指标。把两个看似难以相干的产品融合到一起,我们不禁对它产生了强烈的好奇:作为代表荣耀猎人游戏本的跨界新物种,它究竟做了哪些平衡以兼顾不同人群的各类需求呢?