前言
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)