Replies: 2 comments 8 replies
-
啊,有吗,如果出现这个问题那就是一个 bug 了。。 |
Beta Was this translation helpful? Give feedback.
3 replies
-
文本翻译的缓存命中率不高的,重复翻译一摸一样的文本的概率是在太低了。如果是单词类的可能命中率才会高一点。 |
Beta Was this translation helpful? Give feedback.
5 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
这是用页面翻译的时候想到一个方案:
就是说,只要提交请求翻译的字符串,跟曾经某次已经提交过的并得到了结果的,完全一致(比如可以用哈希对比)的话,那么,这一次请求翻译,就直接返回一定时间内的上次的成功翻译的结果。
特别是对于 DeepL 引擎,可以这样做。
(因为现在遇到一个页面总是只有先看到的一半能被正常翻译的时候,就发现,之前成功翻译过的部分看起来又被重新提交给引擎了。)
方法就是,每次有了引擎
A
的对字串S
的成功翻译结果R
,就把R
缓存起来,等到过了用户指定的(或默认的)时间t
后,就让它失效,或者用户如果可以手动清理缓存的话它也会失效。其实超时了不必立即删除,而是多个超时缓存里只保留最新的这样子。
这样设计的想法是,有可能超时了,但引擎未来一周都挂了,那么这时候,仍然需要至少一个虽然旧了但总比没有要好的翻译结果,如果还保留至少一份缓存,工具就可以在继续请求新翻译结果的同时先给出一个也不是不能看的结果,然后,等到有了新结果再把新结果加进缓存,用户下次再翻译就会看到新的结果了。
——这样,这个缓存最好也支持用户导出导入。比如我给别人安利这个工具,结果,针对特定的某篇文章,我的可以秒翻译他的却要等,可能他的网络环境还会迟迟等不到,这样,工具的使用体验就会下降了。😜
(这部分算是描述了设想的新功能的工作逻辑。。。)
(上述功能逻辑里,并没建议用「一有新结果就实时替换」这样的设计。这是因为,在我个人的感受上,那样会让人总觉得不能确定本次翻译到底有没有彻底完成,就会觉得工具缺乏一致性或者觉得工具不可控并为此感到焦虑。如果想看某时刻的已有最新翻译结果,我觉得我主动手动摁两下快捷键就能看到最新结果了,这样比不知道什么时候结果文本又会被换个遍要好。)
Beta Was this translation helpful? Give feedback.
All reactions