多语言遗留问题修复

[jsonz1993]

在某一天，测试说有一个地方多语言词条有问题，展示的文案是一串id...

看了一下测试的截图，这很明显是多语言工具生成出来的md5串，直接原因肯定就是词条库里面缺少这个id，而又没有做fallback导致直接把id展示给用户看。

庆幸的是在测试发现之前，我就开始隐约觉得有这个坑，因为之前的维护是用excel维护的，很像一个黑盒子，你完全不知道里面发生什么，不管是程序员还是投资，最不喜欢的就是这种不确定性。所以前两天已经给工具加了一个feature，在扫描的过程中会检索已经匹配的词条是否有丢失的情况，还有其他一系列的小更新。

词条丢失原因

历史原因，第一版用的是excel，虽然存在的时间大概是一个星期，但是这一个星期的版本迭代对于excel来说完全黑盒，出了问题你也很难人工去排查到底哪些词条确实，所以这时候就急需一个排查的工具，能帮你检索出当前已经存在项目中的词条有哪些是确实的或者不完整的。

已用词条检索

举html模板为例子，其实这个功能很简单，因为我们已经替换的标签有很强的标识性。 模块名:md5{8}:中文提示 | i18next2 ，一个正则即可匹配出来，再把id提取出来，在当前模块的词条库中查找，如果没有找到对于的id，意味着这条词条是丢失的。我们应该及时处理，手动补到词条库中或者其他操作。

fallback方案

但是如果线上万一有了，总不能直接展示id给用户看，所以这时候需要做一个fallback的功能，至少得预备一些降级方案，这时候我们之前预留的中文提示就派上用场了，可以修改 i18next2 的函数，原本我们是提取模块名做 namespace ，然后基于这个namespace再用 md5作为他的key。修改后我们的namespace和key逻辑保持不变，但是对取出来的文案做一个判断，如果取出来的文案与id相同，意味着 i18next 没有找到对于的词条，这时候取中文提示当文案展示给用户，再把当前词条记录下来，告警开发人员去排查问题。相当于至少用户可以看到中文的文案，至少只是体验差了，比起直接展示id会好很多。不过自从改成json之后，目前没有发现有类似的问题再出现了。

fallback方案与更新问题

既然我们可能会有极小的概率会用到中文提示，那么就会出现另一个问题，如果我们供应商，或者产品需求变更，需要改动到中文，按照目前的逻辑是直接修改到词条库，后面导出一遍到项目的多语言数据文件中就可以。但是这时候就会导致一个问题，数据文件中的文案和词条库的文案是同步更新的，但是中文提示的文案是之前的文案，可能会导致fallback展示了具有误导性的标签，这比不展示更危险！

当然我们也可以改词条库的时候，手动改项目中用到的中文提示，这种方式繁琐不说，万一有开发人员忘记改（因为正常情况下不会用到中文提示，所以测试很难发现），也会留下一个隐患，所以最好还是交给工具来改。

已用词条检索相似，我们在查找到已替换的i18next表达式的时候，可以根据后面的中文提示来生成md5，跟目前存在的md5对比，看是否相同，如果不同则代表文案有更新了，这时候可以把词条库的中文代替当前的中文提示更新到代码中。

词条冗余问题

当我们的产品迭代时，几乎百分百会改动到文案，比如增加一些feature，或者改动一些功能点的时候，对文案的增删改问题是不可避免的，如果我们的项目一直是用增量扫描提取的方式，最后必将导致词条库日渐庞大，可能一些词条早就不存在项目中，但是词条库在导出的时候也会将这些导出到项目的多语言数据中。不仅增加了项目的大小，还会徒增许多干扰项。

所以在扫描已存在的i18next表达式时，我会将该id记录下来，当一整个模块扫描完之后，把未记录id的词条检索出来，这些词条就是没有用到的，目前的做法是给这些词条增加一个key来标识是冗余数据，生成项目多语言数据时，跳过这些冗余数据，就可以避免词条库只增不减的现象，当然也预留了一个口子，加个配置在最后删除这些冗余的词条。

日志

多语言工具是一个终端工具，所以在运行时会有很多关键的信息打印输出，比如正在处理的文件，处理中提取了多少词条等，包括上述的词条丢失问题、词条更新问题以及词条冗余情况都会在控制台打出来，目前跑的模块大概十几个，信息很容易刷一下就过去，所以又加了一些开发者友好的功能点。用 log4js 做日志输出工具，在运行结束前，读取日志，对当前一些比较重要的信息进行输出，比如词条丢失、冗余、更新以及项目运行中 warn 级别以上的信息进行再打印，并且提供了日志以便问题追踪与排查。

这就是最近业余时间对多语言工具维护新增的一些小点，展望下一步就是改朝换代用平台管理词条的方式。