Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

给网页全文翻译的“自动开启”加上“仅限当前窗口”的限制 #1112

Closed
lmk123 opened this issue Aug 1, 2021 · 15 comments
Labels
优先级 P1 一般会在下个版本中解决。 功能改进 网页全文翻译
Milestone

Comments

@lmk123
Copy link
Member

lmk123 commented Aug 1, 2021

功能简介

目前的“自动开启”一刀切式的会给所有网页都自动打开网页全文翻译,但使用体验上并不好

为什么你觉得需要(改进)这个功能?

参考来自 #1090 的两个反馈:

@cxhttt233

就个人而言,我觉得这样是会影响到的。可以折衷一下,从全文标签页打开的所有新标签页也自动全文,全文标签页跳转之后也自动保持全文。

这个功能的目的是为了省去多余的点击操作,但是如果无论什么页面都全文的话,反而可能会带来多余的关闭全局的操作。
这样的话我可能会专门开edge用翻译,然后开chrome用于普通的浏览和搜索

因此从我个人的角度来看,还是保留对页面的细粒度控制权对用户更加方便点

@zerojade

影响很大,我想在一些网页自动开,如果能自定义网址规则决定哪些网页自动开/关(就是总开关加个例外名单?v2ray分应用代理那种逻辑)就完美了。比如说有时候我要摸鱼看个视频,这个功能就很碍事,等我回归工作就要重新开上。(因为我喜欢双语对照,不管中英文都会翻译的)
或者有时候我看文献希望它开着,但是找资料的时候用到中文网页就不需要开,如果开着会令我很困惑,假如找资料和看文献的状态切换得频繁点,就要不断开开关关。如果总开关不开,那我每篇文献都要手动开(因为不是每篇文献都看全文,所以短时间内会过目挺多文献的)

@lmk123 lmk123 added 功能改进 讨论中 issue 已确认,但正在讨论要如何解决。 网页全文翻译 labels Aug 1, 2021
@lmk123
Copy link
Member Author

lmk123 commented Aug 2, 2021

有用户提议可以加一个选项:非中文页面自动开启网页全文翻译

@kingofotaku
Copy link

个人认为即使是外文页面,有些人(比如我)也不总是需要翻译的,对于简单的外文网页来说,用机翻翻出来的结果有时是不如自己看的。个人还是比较倾向于再简化右键菜单的入口(比如像谷歌翻译的扩展一样在右键菜单第一层加个“翻译网页为中文”)

@lmk123
Copy link
Member Author

lmk123 commented Aug 5, 2021

可是,如果一个扩展程序有多于一个的右键菜单,浏览器会强制将它们放在二级菜单下,无法做到直接在一级菜单中

@kingofotaku
Copy link

kingofotaku commented Aug 5, 2021

可是,如果一个扩展程序有多于一个的右键菜单,浏览器会强制将它们放在二级菜单下,无法做到直接在一级菜单中

那就没办法了 或者可以考虑将按钮集成到地址栏内最右侧?(我似乎见过其他扩展有这样的操作)

@zerojade
Copy link

zerojade commented Aug 5, 2021

所以说开个自定义例外网址列表就好了,油猴脚本那种。个人觉得 kingofotaku 说的不正是手动网页全文翻译,嫌麻烦可以设置一个网页全文翻译快捷键。

@kingofotaku
Copy link

kingofotaku commented Aug 5, 2021

所以说开个自定义例外网址列表就好了,油猴脚本那种。个人觉得 kingofotaku 说的不正是手动网页全文翻译,嫌麻烦可以设置一个网页全文翻译快捷键。

没错,我是这个意思。只不过个人比起快捷键更喜欢点一下而已。但白名单之类的东西我觉得还是有局限性,因为很多时候查资料解决问题并不只是访问特定的几个网站,而是需要从无数的搜索结果里头访问各种各样的网站,这种情况下白名单好像并没有用 所以我的想法还是希望默认不开启,同时把手动开启做到最方便,无感,仅为个人观点。

@zerojade
Copy link

zerojade commented Aug 5, 2021

其实我说的例外网址列表不止白名单,黑名单也是例外的一种。虽然查资料解决问题并不只是访问特定的几个网站,但是平时娱乐访问的不需要翻译的网站(对我来说)是比较固定的,可以在黑名单里默认不翻译;同时如果能按类别内置一些常见网址简直完美,比如视频类别:ytb,优酷,iqiyi等

@kingofotaku
Copy link

其实我说的例外网址列表不止白名单,黑名单也是例外的一种。虽然查资料解决问题并不只是访问特定的几个网站,但是平时娱乐访问的不需要翻译的网站(对我来说)是比较固定的,可以在黑名单里默认不翻译;同时如果能按类别内置一些常见网址简直完美,比如视频类别:ytb,优酷,iqiyi等

你说的有道理,这种情况也是很常见的。

@cxhttt233
Copy link

我认为,应对这些情况最好的办法就是固定某个标签页为全文,跳转之后也保持全文,并且会在标签页的上面提示,就跟这个扩展程序的逻辑一致。

@GH01
Copy link

GH01 commented Aug 6, 2021

有没可能实现 快捷选项:

□ 当前标签中 始终开启
□ 次生标签中 始终开启
▲这样,用户只需在开始时点击1-2次。

□ 当前窗口中 始终开启
▲这样,此窗的新标签中始终开启,直至关窗。用户可以通过分窗来维持。

@lmk123
Copy link
Member Author

lmk123 commented Aug 6, 2021

我觉得可以给“自动开启”加一个“当前窗口中”的限制。注意,不是给自动开启新增一个选项,而是直接给自动开启增加一个“当前窗口”的限制。

  • 如果再给“自动开启”加一个新的选项,我觉得略显麻烦
  • 加上“当前标签中”我觉得范围不够宽,因为有些网站是在新标签页中打开链接的
  • “次生标签”的话,于我而言,代码的逻辑判断有点复杂,而且使用体验感觉跟“当前窗口”差不多

综合来看,直接给“自动开启”加上“当前窗口”的限制是性价比最高的做法了。

各位怎么看?

@GH01
Copy link

GH01 commented Aug 7, 2021

我个人觉得可以,反正现在浏览器分窗合窗挺方便的。
选项上应该加个注。

好奇合窗后会怎样?

@lmk123
Copy link
Member Author

lmk123 commented Aug 7, 2021

标签页合并到另一个的窗口中之后,会遵照那个窗口的“自动开启”规则

@lmk123 lmk123 added this to the v8.5.1 milestone Aug 7, 2021
@lmk123 lmk123 added the 优先级 P1 一般会在下个版本中解决。 label Aug 10, 2021
@lmk123 lmk123 removed this from the v8.5.1 milestone Aug 10, 2021
@lmk123 lmk123 removed the 讨论中 issue 已确认,但正在讨论要如何解决。 label Aug 15, 2021
@lmk123 lmk123 changed the title 网页全文翻译的“自动开启”功能改进 给网页全文翻译的“自动开启”加上“仅限当前窗口”的限制 Aug 15, 2021
@lmk123
Copy link
Member Author

lmk123 commented Aug 15, 2021

好奇合窗后会怎样?

@GH01 准确点说,标签页从移到另一个窗口之后,如果原来的窗口开启了“自动开启”,那么原来的窗口会关闭“自动开启”而新的窗口会开启“自动开启”

@lmk123
Copy link
Member Author

lmk123 commented Aug 15, 2021

此改进将在下个版本中发布。

@lmk123 lmk123 closed this as completed Aug 15, 2021
@lmk123 lmk123 added this to the v8.5.4 milestone Aug 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
优先级 P1 一般会在下个版本中解决。 功能改进 网页全文翻译
Projects
None yet
Development

No branches or pull requests

5 participants