前端国际化之痛点(二)：多包多库场景下联动多语言

前言

VoerkaI18n是一款非常优秀的前端国际化解决方案，其开发的出发点是为了解决现存多语言的一些痛点,接下来几篇文章将分别进行分析。

• 前端国际化之痛点(一)：让人头疼的词条Key
• 前端国际化之痛点(二)：多包多库场景下联动多语言
• 前端国际化之痛点(三)：上线后修改翻译内容

现有方案痛点

对于大型项目，一般会将项目拆分为多个库或monorepo包结构，一个工程可能包含1-N个子项目或库。如何进行国际化？

针对这样的场景，理想的多语言方案应该是这样：

• 当主应用切换语言时，所有引用依赖库也会跟随主程序进行语言切换
• 所有的每个子包或库均独立进行开发，并且引入其独立的多语言配置，不需要类似模块联邦一样进行复杂的配置。

随着monorepo的流行，针对此场景的多语言需求越来越迫切，但是比较遗憾的是，现有的多语言方案均未能提供比较便利的方案。

解决痛点

voerkai18n 支持多个库国际化的联动和协作，即当主程序切换语言时，所有引用依赖库也会跟随主程序进行语言切换，整个切换过程对所有库开发都是透明的。 库开发者不需要特殊配置，只需要像普通应用一样进行开发即可。

其基本原理是这样的：

当我们在开发一个应用或者库并import "./languages"时，在langauges/index.js进行了如下处理：

• 创建一个i18nScope作用域实例

• 检测当前应用环境下是否具有全局单例VoerkaI18n

  • 如果存在VoerkaI18n全局单例，则会将当前i18nScope实例注册到VoerkaI18n.scopes中
  • 如果不存在VoerkaI18n全局单例，则使用当前i18nScope实例的参数来创建一个VoerkaI18n全局单例。

• 在每个应用与库中均可以使用import { t } from ".langauges导入本工程的t翻译函数，该t翻译函数被绑定当前i18nScope作用域实例，因此翻译时就只会使用到本工程的文本。这样就割离了不同工程和库之间的翻译。

• 由于所有引用的i18nScope均注册到了全局单例VoerkaI18n，当切换语言时，VoerkaI18n会刷新切换所有注册的i18nScope，这样就实现了各个i18nScope即独立，又可以联动语言切换。

小结

VoerkaI18n为多包多库场景下的多语言开发提供了比较完美的解决方案。有理由认为，未来所有的多语言方案均应该是这样的，赶紧上马 VoerkaI18n。

[VoerkaI18n多包多库场景下的多语言原理说明和使用介绍](https://zhangfisher.github.io/voerka-i18n/#/zh/guide/advanced/multi-libs）