multi-translate.el 用多个翻译服务翻译当前单词和选区

原本也打算用 widget,但是它似乎有问题。同一个 buffer 擦除之后再利用,就会出现错乱。

应该是我使用方式不对,同样没搞清楚 widget 用法的还有有内置的 eudc.el,它也有同样的问题,重现步骤:

  1. M-x eudic-query-form
  2. 在 minibuffer 随便输入点什么。
  3. 在弹出的窗口中点 [Reset]
  4. 重复步骤 1,然后整个 buffer 变成了一个大号的 editable-field

现在想是不是可以用 overlay 标记一块区域(例如 my-editable-field),然后拦截 self-insert-command 来,当光标处在 my-editable-filed 内,就暂时把 read-only 去掉。

再不行就把内容提取到 minibuffer 来编辑。


目前观察到的有两个问题:

  1. 添加了 widget 之后必须调用 widget-setup 才能生效。如果后续追加了 widget,再调用 widget-setup,就会使得之前的 widget 丢失部分属性。
  2. 有 widget 的 buffer 擦出不干净,最终会剩下一个空白 editable-field,接着就导致上面所述的问题。

看来widget还是不太行,widget作者写完之后跑路了,现在也没人维护。我之前想研究下,发现完全没用EIEIO,而是用symbol propery,结构挺碎片的,也就没改进的兴趣了。


不知道你用没用过deft?deft的输入栏就只允许两个操作:输入和删除,光标默认在最后面不能移动。跟isearch的minibuffer一样。或许可以整个overlay,上面用keymap限制只能在末尾输入和删除。这样还有个好处:输入栏可以做成固定长度,超出长度的话可以把最前面的截掉不显示,变短了再显示回来。不知道我描述地清楚不清楚。


当然更简单的是像你说的用minibufer,在输入框上回车就弹出minibuffer编辑,讲道理效果也不差。

为什么有道翻译那一行 是一段代码?

图片

异步请求结果的占位符。

大概也可以用marker做占位符?不知道和uuid比起来有什么缺点

可以把那个占位符颜色设置为背景颜色,不就不那么突兀了么?

可不可以把查过的词和意思自动保存到org文档中。

这种最好还是自己写一个函数,因为和主要功能关系不大

最近看到一篇博文说可以在Emacs里看Webster’s 1913 dictionary:

http://mbork.pl/2017-01-14_I’m_now_using_the_right_dictionary

正好这个用的是scdv格式。我在苹果的Dictionary.app上用这个词典,还是很不错的。具体优点可以在 You’re probably using the wrong dictionary « the jsomers.net blog 看到,文章写得挺好的(除了有点罗嗦)。

2 个赞

那个词典的链接不太好找,在这里:https://s3.amazonaws.com/jsomers/dictionary.zip 解压出来再解压就是stardict能用的格式了。

我就是从那个链接下载的,已经用上了。这个字典是破解的吗?

1 个赞

1913年写的,没有版权啥的了吧。应该是public domain。

最终决定采用 minibuffer 方案,增加快捷键以修改/交换语言参数,我感觉使用起来比在 widget 上跳来跳去更流畅:

Screenshot_2020-07-29_at_8.25.23_PM--multi-translate-amend-query

新增函数:

  • multi-translate
  • multi-translate-amend-query
3 个赞

支持保留多次查询结果(默认关闭),并提供了相应的函数和 Imenu 以便在各段落之间跳转和折叠段落。

@stardiviner 另,google-translate 的异步改造有在继续码?如果比较麻烦的话,我想我可以考虑写一个基于 web 返回结果的简单实现。毕竟这个包主要还是用来对比长句翻译的(单词有一个词典能翻译就够了),而且的确 web 翻译的结果更好

上次看过觉得麻烦之后就一直没有动手取实现,主要是我太懒的缘故 :wink: 。还是你写一个web返回结果好了。

刚刚再确认了一下前面提到的这句的翻译。发现 API 返回的结果跟 WEB 终于一致了:

(google-translate--request "zh-CN" "en" "修复部分翻译结果未能显示的问题")
;; =>
;; "[[[\"Fix the problem that some translation results could not be displayed\",\"修复部分翻译结果未能显示的问题\",null,null,3,null,null,[[]
;; ]
;; ,[[[\"51171d70a5b6c2485a24361038890141\",\"zh_en_2020q2.md\"]
;; ]
;; ]
;; ]
;; ,[null,null,null,\"Xiūfù bùfèn fānyì jiéguǒ wèi néng xiǎnshì de wèntí\"]
;; ]
;; ,null,\"zh-CN\",null,null,[[\"修复部分翻译结果未能显示的问题\",null,[[\"Fix the problem that some translation results could not be displayed\",0,true,false]
;; ,[\"Repair some problems failed to show the translation results\",0,true,false]
;; ]
;; ,[[0,15]
;; ]
;; ,\"修复部分翻译结果未能显示的问题\",0,0]
;; ]
;; ,1.0,[]
;; ,[[\"zh-CN\"]
;; ,null,[1.0]
;; ,[\"zh-CN\"]
;; ]
;; ]
;; "

从返回数据看,更合理的翻译放在了第一位,原先不太顺畅的翻译放在了后面。

难道 API 比 WEB 滞后一段时间?

最近想把 sdcv 加到后端中,发现一个问题:

manateelazycat 的 sdcv 将 melpa 中的 sdcv-search-with-dictionary-args 改为了 sdcv-search-with-dictionary

mepla 都不是我上传和维护的,我的插件都不在 mepla , 请不要给我报 melpa 上引起的 issue, 谢谢!

我知道 melpa 上面的 sdcv 不是你维护的,没有报相关的 issue ,只是在 multi-translate 这边提醒一下,如果使用你的版本而不是 melpa 的版本会报错。

1 个赞

DeepL 的翻译后端可以参考 deno-bridge - #45,来自 manateelazycat 不需要弄 API Key 就可以一直用。

1 个赞