20200731
先下结论: 国际化（i18n）和可访问性(a11y) 都是大坑。
首先说一下背景，仍然是一个SAAS应用，它支持多国语言，因此也就需要支持国际化。
前两天也刚好看到一篇文章，讲这个。https://product.hubspot.com/blog/software-internationalization-101-how-to-go-global-without-slowing-down 。 这是公司里的一位资深大佬发过来的文章，看了之后，也的确觉得我们自己做的还有很多得不足。
当前的流程
当前的流程是这样的，首先开发者会根据设计图画前端UI，这个时候会将那些反映在设计图中的文案拿下来，放到我们的一个JSON文件中，例如我们有一个叫做‘copy’的文案，我们就会在这个JSON文件中添加一个key，就叫做'global.copy',而对应的值就是‘copy’。这里的这个值，是在美国英语环境下的值。
之后，我们将以美国英语作为一个基准，将这个JSON文中中，还没有被翻译的key交到翻译人员手中，翻译人员的职责就是根据这些美国英语下的值，给出对应语言下各个key的值。开发人员将翻译人员给到的最终结果，导入到我们的代码库中，就完成了整个流程。
但是到此为止了吗？其实并没有。由于开发和翻译并不是同时进行的，所以，就会出现开发和测试已经完成，但是翻译的结果却还没有给出来这样的情况。这个时候，我们的做法是优先保证能够上线。这个时候，如果你去看生产环境的话，无论你切换到任何的一种语言，没有被翻译的部分，展示的内容都是你的基准语言，在这里就是美国英语。直到翻译的结果从翻译人员那里给到我们，我们对生产环境再做一次部署，翻译的结果才能够走到线上去。
流程标准化
那么这个流程能否再进一步优化呢？
这篇文章给到了一个很好的思路。可以依靠一个第三方平台去推动翻译工作，翻译不应该是阻塞的。
这篇文章提到可以先由人工智能去做翻译，这样的话，就不会遇到我上面提到的没有翻译的部分用基准语言代替这样的问题了。当然，当翻译结束之后，再将人类翻译的结果发送到生产环境，这也是非常顺滑的。
