Add an option for extending gts-picker-lang-matcher

[gynamics]

The match function is cool, but sometimes it is annoying when I do not want to translate the language matched near my cursor. 匹配函数挺好，但有时烦人，特别是我想翻译的不是我的光标匹配到的语言的时候。

Currently I did not see any related extensible design, the matcher is called by default, unless I hack it after loading the package, that is not good. 目前我没有看到相关的扩展设计，匹配函数默认是被调用的，除非在加载包后再去进行hack，这不好。

My advice is that expose the variable gts-picker-lang-match-alist as a configurable option to users and set up a toggle. 建议把变量gts-picker-lang-match-alist作为一个可配置选项暴露给用户，并设置一个开关。

[lorniu]

You're right, this should be exposed as a user-configurable option. At present, this method is very simple. Maybe some PR is need to make it more complete.

Mybe you can temporarily close it with:

(setq gts-picker-lang-match-alist nil)

[gynamics]

I see, thank you for your work. Currently I customized my gts-picker-lang-match-alist from source and it works well, but after that, here are some thoughts:

At first I think, maybe you could just leave the regex for users. And a toggle is good for newbies. However, now I found that I was wrong. it's hard to say that when the matcher actually benefits. There are several scenarios:

• The user want to see the translation answer synchronously when browsing a large file
• The user want to see the translation of a language he/she does not know

As for me, the trouble lies in that I just want to use it as a translate engine in emacs, rather than an intelligent translator, and what I want is not being disturbed by such benefits. However, this could be done in another way: add a better source/target language select/switch mechanism. e. g. loop options before do translate with several simple interactive functions.

The matcher should not be abused, if regex are exposed to the user, complicated precedence decision mechanism will be introduced to take care of it, and that is absolutely not a good idea. So just keep a toggle is good enough.