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的值。开发人员将翻译人员给到的最终结果，导入到我们的代码库中，就完成了整个流程。
但是到此为止了吗？其实并没有。由于开发和翻译并不是同时进行的，所以，就会出现开发和测试已经完成，但是翻译的结果却还没有给出来这样的情况。这个时候，我们的做法是优先保证能够上线。这个时候，如果你去看生产环境的话，无论你切换到任何的一种语言，没有被翻译的部分，展示的内容都是你的基准语言，在这里就是美国英语。直到翻译的结果从翻译人员那里给到我们，我们对生产环境再做一次部署，翻译的结果才能够走到线上去。
流程标准化
那么这个流程能否再进一步优化呢？
这篇文章给到了一个很好的思路。可以依靠一个第三方平台去推动翻译工作，翻译不应该是阻塞的。
这篇文章提到可以先由人工智能去做翻译，这样的话，就不会遇到我上面提到的没有翻译的部分用基准语言代替这样的问题了。当然，当翻译结束之后，再将人类翻译的结果发送到生产环境，这也是非常顺滑的。
其他一些坑
翻译的配置是放在前端还是后端呢？
我们自己在实践当中，就发现，经常有一些系统配置级别的文字，出现了没有翻译的问题，而这些问题的产生，就是因为没有搞清楚翻译的配置是放在前端还是后端。 举个例子，我们有一个设置页面，这个页面要从一个下拉菜单中选择出一个需要的设置，而这个下拉菜单的各个选项，又该由前端给出呢？还是后端给出呢？
占位符的问题
一个典型的问题是，如果我们有一个模板，这个模板表示的某人做了某事.这里的某人和某事都是可能发生改变的.
这个时候我们的模板可能是
{0} eat {1}
其中{0}和{1}表示占位符.
我们需要注意的是,有可能在某些语言当中这个模板会被翻译成被动语态.
那么我们就需要确定,当我们在另外一种语言下,它被翻译成了:
{1} afjief {0}
{1} 是否就是我们刚才提到的something,.
我们之前遇到过一个问题,就是前端在处理国际化的时候,没有对颠倒占位符顺序这种情况做出处理.