进行语种切换的时候，会先显示原语种，然后才会显示翻译后的语种
场景
进行网页浏览时，当前网页是中文的，通过切换语种切换成了英文，当点击这个网页中的超链接后打开新页面进行浏览时，发现新页面会先显示原本的中文内容，1秒后才变成了英文内容
解释
新打开的页面先显示原本的中文内容，是因为 translate.js 会有个翻译的过程，并不是实时立即就翻译完毕，它会有个计算过程，所以会有个延迟，也就出现了这个所为的1秒的延迟效果。以后随着后续AI算力芯片的提升，这个延迟效果会进行逐渐缩短。
另外新页面第一次打开，内容以前没有被翻译过的，才会有这个1秒的切换效果，如果你已经打开过一次翻译过了，当你在进行刷新页面时，是没有这个1秒切换效果的，而是打开后立即显示的就是英文，不会再有先显示中文在切换英文的过渡，因为translate.js 它本身有一层浏览器级别的缓存，你浏览器打开翻译过一次后，它就将翻译结果进入了浏览器缓存，你刷新页面后，它会直接从缓存中取出翻译结果赋予页面，这个过程非常快，人眼是感知不出来的，所以感觉上是打开后直接就是英文的。
优化
如何能让访客在第一次访问时（也就是访客的浏览器本身没有翻译缓存时），也能做到极速翻译切换的效果，避免出现中文或者降低中文出现的时间？
方式一：
采用 离线翻译 的能力，离线翻译是不依赖自动化翻译，而是跟传统的i18n的原理类似，提前讲某段文字对应语种的译文提前以代码的方式配置好了，当用户打开页面浏览时，程序会自动从配置里讲译文取出迅速进行翻译，完全规避用户视觉上出现先中文，卡顿一下再出现英文的视觉感知。而是直接打开后直接就是英文的。
但是这个方式是有个缺点的，这个缺点就是传统 i18n 的缺点，需要提前进行配置，只不过 translate.js 会简单非常多，它可以一键导出来。
在一些正常使用的场景中，可以这么考虑，在网页的第一屏出现的文字用离线翻译配置好，那么用户访问时，第一屏是最先看到的，而后面向下滑动才能看到的文字，可以依旧用 translate.js 的自动化翻译来进行，这样对技术的工作量是比较少的。
方式二：
启用企业级稳定翻译 它跟开源的翻译通道相比，它是独立的，用户没有那么多，所以它的响应会更快，比如开源的速度是1秒，它的速度是0.5秒，可以进一步降低这个切换过程的时间。 但它还是会出现先中文、在英文的效果的。
另外它还会有一层服务端的翻译缓存，如果你本身的页面的文字是固定的（是指整个页面翻译的文字是固定的，比如你要翻译的文字中有当前时间的，当前时间肯定每次看都是变化的，那这个就不是固定的，有变动了），翻译后服务端会进行一次结果的缓存，当下一次在进行翻译时，他会直接从缓存中吧结果返回，极大降低这个耗时。 如果已经翻译过一次，访问时命中缓存，它从开始网络请求到翻译完成的时间大概不到200毫秒，会非常迅速。