利用缓存应该能一定程度上缓解网络波动带来的翻译问题

[hmrg-grmh]

这是用页面翻译的时候想到一个方案：

能否让用户选择开启「缓存机制」（并指定缓存持续生效时常）呢？

就是说，只要提交请求翻译的字符串，跟曾经某次已经提交过的并得到了结果的，完全一致（比如可以用哈希对比）的话，那么，这一次请求翻译，就直接返回一定时间内的上次的成功翻译的结果。

特别是对于 DeepL 引擎，可以这样做。
（因为现在遇到一个页面总是只有先看到的一半能被正常翻译的时候，就发现，之前成功翻译过的部分看起来又被重新提交给引擎了。）

方法就是，每次有了引擎A的对字串S的成功翻译结果R，就把R缓存起来，等到过了用户指定的（或默认的）时间t后，就让它失效，或者用户如果可以手动清理缓存的话它也会失效。

---

其实超时了不必立即删除，而是多个超时缓存里只保留最新的这样子。
这样设计的想法是，有可能超时了，但引擎未来一周都挂了，那么这时候，仍然需要至少一个虽然旧了但总比没有要好的翻译结果，如果还保留至少一份缓存，工具就可以在继续请求新翻译结果的同时先给出一个也不是不能看的结果，然后，等到有了新结果再把新结果加进缓存，用户下次再翻译就会看到新的结果了。

——这样，这个缓存最好也支持用户导出导入。比如我给别人安利这个工具，结果，针对特定的某篇文章，我的可以秒翻译他的却要等，可能他的网络环境还会迟迟等不到，这样，工具的使用体验就会下降了。😜

（这部分算是描述了设想的新功能的工作逻辑。。。）

---

（上述功能逻辑里，并没建议用「一有新结果就实时替换」这样的设计。这是因为，在我个人的感受上，那样会让人总觉得不能确定本次翻译到底有没有彻底完成，就会觉得工具缺乏一致性或者觉得工具不可控并为此感到焦虑。如果想看某时刻的已有最新翻译结果，我觉得我主动手动摁两下快捷键就能看到最新结果了，这样比不知道什么时候结果文本又会被换个遍要好。）

[lmk123]

因为现在遇到一个页面总是只有先看到的一半能被正常翻译的时候，就发现，之前成功翻译过的部分看起来又被重新提交给引擎了。

啊，有吗，如果出现这个问题那就是一个 bug 了。。

[hmrg-grmh]

不算，还是之前网络不好的问题，因为过了会儿我这住处的破网就又 ping 不通 deepl 了。。。
（也因此我会非常珍视某次偶然的成功的翻译。。。至于为啥非要用 deepl ，那是因为谷歌的翻译有点生草。。。不生草也机翻味儿太浓了。。。）

[hmrg-grmh]

刚刚在可以用 deepl 的网络里发现了一个现象，那就是，对于以下这些链接，我这的现象是，快速向下滑动过全文，上面的翻译的确会到某自然段就卡住，但是一点点往下滑，视野内翻译完了再往下，那么所有的请稍后就都能全慢慢地完成翻译。

• https://colah.github.io/posts/2014-07-NLP-RNNs-Representations/
• https://colah.github.io/posts/2014-07-Conv-Nets-Modular/

而对于下面这个俩链接，我这儿总是卡在这里不能继续翻译了：

• https://distill.pub/2016/augmented-rnns/

不知道是不是 BUG 。。

[lmk123]

我重现了，应该是 bug，我开了个 issue #1051

[lmk123]

文本翻译的缓存命中率不高的，重复翻译一摸一样的文本的概率是在太低了。如果是单词类的可能命中率才会高一点。

[hmrg-grmh]

全文翻译的话，如果我手动重新执行翻译（不小心），每个提交的自然段应该是一样的吧。。

[lmk123]

也不一定，因为提交的自然段是根据你的可视区域里的文本组成的。

举个例子，你打开了一个网页，立刻启动全文翻译，跟你把这个网页滚动到下半部分再启动全文翻译，这两次提交的文本是不一样的，因为你的可视区域不一样。

[hmrg-grmh]

但是，我先看到第三个自然段和从后往前看到第三个自然段，它提交的内容应该是一样的吧，只是从上往下可能是第 3 次提交（假设这页面只有一般自然段），从下往上则可能是第 17 次提交（假设整个页面只有20个自然段）。

提交第几次会有区别的话，自然段的内容也会有区别吗？
（还是说其实工具是一口气把多个自然段提交而不是一个个自然段分别并发（或串行）提交？）

[lmk123]

还是说其实工具是一口气把多个自然段提交而不是一个个自然段分别并发（或串行）提交？

答对了！

[lmk123]

如果每个自然段都分别提交的话，次数太多了，翻译源的服务器会封禁 IP 的