大乐视的美国Bigbang终于进行了，从6月份得知我们云的全线产品要开发英文版之后，到现在，将近4个月，将手上的N个系统，全部做了英文版的了，觉得还是需要总结一下的。
我们的国际化，首先是做的英文版，后期还要做台湾版、香港版、俄罗斯版，so，尽量第一次的时候累点，以后轻松点。
国际化，首先就是汉字的翻译了，如下图，国际友人肯定看不懂汉字。
里面的N多汉字，除了读库之外的，都需要进行汉字翻译。
除了库里的文案，网页里面的汉字还分如下几种
- JSP界面渲染的文案
- JS渲染的文案
- 前后端分离，html界面的文案
这些汉字都需要进行翻译，为了保证翻译的一致性，集体聘请了第三方的翻译团队，由各产品线线提供自己产品线的中文词库，统一进行翻译。
注：我们的css没有在:before :after等伪类中写中文，故CSS无需处理。
1、词库抽取
JSP界面以及Java里的文案，由后端Java工程师处理。后端的架构师，封装了一个jar文件，会将jsp、Java等文件中的词库抽取成Excel。
我也是这个思路，写了一个node程序（le-translate），遍历产品线所有的JS、Html文件，抽出成词库列表到Excel。
思路如下：
node控制台运行如下：
导出的Excel结果如下：
词库导出来提交给翻译团队了，然后就等着拿到翻译结果，需要进行具体的替换了。
2、JS文字替换
无数次的经验、教训告诉我，我们的JS代码，只能有一份，来做动态切换，不能单独开一个全英文版，要不然维护成本指数上涨，后面再做其余语言版本的话，就无法整了。
我们的产品线由于前期的野蛮发展，JS都是由jquery的架构开发的，写的也是很野蛮，如下：
2、1 做成大JSON方式
将最早拿到的翻译结果，通过扩展上面提的那个le-translate工程，遍历Excel、保存json文件，修改成JS文件，做成配置文件，准备修改具体的业务JS代码。
第一想法就是，人力挨个把业务JS的中文，换成object键值对请求的形式，例如，将如下代码
替换为：
这样的话理论上最好，只修改一遍，以后只维护词库的配置文件即可。
但是这样的话，需要人力去将汉字手动的修改，对应到应有的JSON文件的key值，面对着当时很紧张的工期、我手上将近10个产品线的JS、还有国际化其余的工作，我一阵头晕。
这种方式适合新开发的产品线，在后来的官网改版中，我们使用了这种方法，但是注意，这样的话，会使想代码变得可读性非常差，因为好多都走了配置文件。所以，建议在代码后面加上中文注释。例如：
2、2 补救式的LCT方式
上面所述，抽取大JSON的方式，不适合我们一下子修改N多旧产品线，so，我想了一个投机的方式，即以中文为KEY值，在le-translate产品线中扩展了功能，遍历JS文件，把中文分词，使用了LCT()包起来，如下图：
如上代码，在中文环境下LCT()方法，直接返回中文，在英文环境下，返回对应的英文值。
这样的话，可以使用正则替换+node io操作，将JS里面90%以上的中文分词处理掉，剩下的极少数不好被正则处理的，手动检查处理，比单个处理快了N倍。
这个方式，优点是十分快速、保持了语义化，缺点有如下两个
- 1、性能小有损耗
使用function调用的方式，比使用键值对调用的方式，耗时要长50%——200%不等，不过我们最低兼容到IE9，而且绝大部分产品线，仅需要兼容到IE11就行，JS引擎都已经非常快，就算是最大的一个业务JS，我们测试对比发现，总执行延迟，不超过10-20毫秒，性能的损耗，可以忽略 - 2、维护不方便
由于配置文件使用了中文为KEY值，所有以后如果需要修改中文文案的话，不仅要修改key-value里面英文的value，同时还需修改中文的key，增加了维护的成本。
不过我们的产品线都已经十分成熟，文案的维护频率很低，还可以接受。
3、html文字替换
除了有JSP架构的系统之外，我们还有前后端分离的html界面，html界面不适合做通过大JSON、LCT方法等异步获取文案的方式，那样的话，会使界面闪烁，十分影响用户体验，可以做的，只能是再保存一份英文的html文件。
于是乎，又扩展了一下le-translate工程，加上了翻译html的功能，根据词库，直接将中文html翻译成英文html，单独部署。
4、借助百度翻译，提前拿到词库
上面提到很多次词库，开发过程中遇到了一个问题，集团聘请的翻译团队，因接到的翻译需求太大，返回翻译结果无法保证。
工期不能等，于是，又又又扩展了le-translate工程，通过npm的request模块，借助了百度翻译的API，批量将分词进行翻译，10秒钟可以翻译1000条。
虽然一些专业术语翻译不尽靠谱，但总体上还算可以继续调试，发现后续问题，深度国际化。