译者：柳千

转贴镜像：https://mp.weixin.qq.com/s/9ez_yAoi67WfSihiqW0i4A

序言

现代后端 App 多词汇最简单的同时实现能由两套积极响应式报文信息系统来代销多词汇美术设计，转换词汇时透过报文的变动使介面依照美术设计再次图形。但虽然 VS Code 构架的复杂程度，须要有两套能相容 Electron 图形询问处(Chromium)及 Node.js 民主化的多词汇计划。

NO.2 VS Code 同时实现

她们从源码已经开始来一步棋一步棋介绍 VS Code 是怎样如前所述词汇包应用程序同时实现多词汇的。

NLS

VS Code 主民主化的出口处是 src/main.js(https://github.com/microsoft/vscode/blob/master/src/main.js)，她们重点项目高度关注第63行(https://github.com/microsoft/vscode/blob/master/src/main.jsL63)

if(locale) {nlsConfigurationPromise= lp.getNLSConfiguration(product.commit, userDataPath, metaDataFile, locale);
}

这儿采用 lp.getNLSConfiguration 建立了两个 nlsConfigurationPromise 第一类，当 Electron 询问处 onReady 该事件促发时，会将调用完的 nlsConfig 增设到 VSCODE_NLS_CONFIG 配置文档中。

当中 nls 是指 Native Language Support(http://wiki.linuxquestions.org/wiki/NativeLanguageSupport)，依照cp能获知这是两个以获取多词汇实用性的 Promise 第一类，其入特勒克 product.commit、 userDataPath、 metaDataFile 和则表示现阶段采用者增设词汇的 locale。前四个模块十分关键，即使它牵涉到多词汇同时实现的核心理念技术细节，她们两个两个来说明她们的促进作用。

product.commit

product product.json(https://github.com/microsoft/vscode/blob/master/product.json)文档，在 VS Code 校对装箱后会补足许多表头，当中主要包括现阶段版的标识符 commit 号。所以为何多词汇的实用性要倚赖标识符具体版的 commit 号呢？简单来说这是虽然 VS Code 的词汇包为官方维护的两个应用程序 vscode-loc(https://github.com/microsoft/vscode-loc)，在每次 VS Code 新版 release 发布后一同发布到应用程序市场。为了区分不同版的词汇美术设计，所以每个 release 版的 VS Code 版都对应相同版号的词汇包应用程序。实际上问题依然存在，为何词汇包要跟随软件版一起 release ？理论上词汇包只是一堆美术设计，和软件本身分开单独维护，社区能随时贡献翻译不是更好吗？这儿先卖个关子她们后面再说。

userDataPath

userDataPath 很容易理解，这是 VS Code 的采用者数据目录，不同操作系统下的路径不一样

MacOS~/Library/Application Support/CodeLinux~/.configWindows$(USERPROFILE)/AppData/Roaming

metaDataFile

metaDataFile 是两个名为 nls.metadata.json 的文档。

constmetaDataFile = path.join(__dirname,nls.metadata.json);

查看 VS Code 源码会发现这个文档并不存在，实际上只有在完整校对装箱一遍 VS Code 后才会生成这个文档，这个文档的大致内容长这样

{“keys”: {“vs/code/electron-browser/processExplorer/processExplorerMain”: