屌丝浅谈前端国际化

近来公司规划项目国际化，what?国际化？那么高大上~嗯，浅说也就是中英两语言适配。那么嗯，挺好的，大概一个构思也就浮现在脑海中，不错不错，应该挺容易的。可是产品突然又说，两者版本功能会有不同，部分删减，丫丫的，产品的你够胆出来，看俺不一脚丫子踹飞你～可惜有贼心没贼胆，你还是一边去，不要让我再见到你了，不见，撒哟啦啦!

于是呢，经过上面一轮挣扎，也就出现了一下这篇文章了。。。。

目前据本人了解市面国际化有三种方式，（1）类似teambition、码云等等采用两套代码形式；（2）就是采用语言包形式；（3）使用google翻译插件（真心佩服采用这种方式的，个人强迫症，毕竟采用工具类，语法错误难免，嗯嗯，给坑过挺多次的，特别是毕业外文翻译上，真是~自动消音），采用的有阿里国际卖场，使用范围个人评估是：内容庞大且不在乎准确性，时效性强，更新频繁，支持世界语言；以上最后一种不想描述，主要是个人原本也没想过此种方式，只是在翻阅资料时候发现了，是使用起来效率挺快的，但是并不符合本人这次项目规划，所以下文着重比较（1）及（2）；

书说上文，本人原本脑补情节就是使用第二种方式，奈何奶奶地，产品大大竟然跟我说要部分删减，呵呵，只有此图能表达我当时的心情

好了，言归正传，这中方式有什么效果呢，主要是能够通过更改一定文件内容，即可达到语言的切换，同时更好的处理了代码的同步问题，不用担心功能上增加时，需要手动更新两套代码，后期维护页更方便，若后期提出多语言化的话，也能够快速同步。目前市面上语言框架繁多，相应的适配国际化插件也纷纷冒出了尖牙，例如：

等等。所以可以灵活使用插件，又或者自己编写相应的插件（或许接下来可以写一篇关于屌丝随笔之--编写国际化插件js，哈哈哈哈）。

第二种方式上文其实页提到过了，就是在项目庞大上面很吃亏，个人觉得维护起来稍困难，但是对于目前的情况稍好就是能够控制内容的删减，这是本人赞同的地方。

废寝忘食的想了一天，最后个人得出的结论是使用第一种方案，个人采用语言是angular，而且考虑到项目的效率性，个人为预先采用插件形式angular-translate来编写，但是由于其语义性较差，不否认后期会更改，采用自编译的插件形式（想想就兴奋）。对于上文一直纠结的删减问题，个人思路是：

（1）预先记录用户语言形式获通过IP啥的记录用户处于环境写入文件，如果这方案不行就采用缓存好了，应该不会有太多人手欠清缓存吧，虽然我属于手欠一族。此外默认english较好，毕竟其为国际化语言，对于中国人于互联网IT行业来说，english难道都不知道什么意思？不过不可否认，国外或许很多人真心不知道---简体中午的意思；

（2）读取文件记录/缓存，置换环境

（3）组件形式根据环境重构

done，若思路不明确，欢迎下面帮忙提提意见，感谢至极！唉，新一轮加班又得开始了~~~~~