Closed pdog18 closed 1 year ago
从这个角度看来,类似的单词还会有很多(按概率来算可能还有上百个)。
如果重码时,明确为 拼音
的状态倒也罢了,这样 reduce_english_filter
让英文单词排列在 非首位
是没有负担的。
但是当我们无法明确判断输入码更适合作为拼音,还是更适合作为单词的情况下,reduce_english_filter
的处境就变得尴尬了(当然这是 Rime 带来的问题)
举例:
输入码: bbq
, 有些用家希望是 BBQ
,而其他一些有趣的用家更希望是芭比Q
,这时候,无论让 BBQ 处于首选还是置于次选都是不合适的,更正确的情况应该是动态调整。这显然就是 librime
的问题了。
补充:我在 rime-discussion 新开了一个主题: https://github.com/rime/home/discussions/1307
简码和英文重叠的问题,除非是特别常用的,比如 rug 如果,剩下的懒得弄了。
这个不太好搞吧,比如全拼除了 i v u 开头的,只要脸滚键盘就是简拼,hello 的简拼为「合理了哦」,world 的简拼为「我忍了都」。
melt_eng/initial_quality: 0
可以不让英文在前面,但这样英文输入的体验又不是很好。
英文输入用lua_translator智能调频,可以解决你说的问题,但是会调用几个先进的lua接口,就不能跨平台了。
chap
真的不太好搞,看看 librime 那边有没有什么方案。
不过 chap 差评 bend 笨蛋 优先级应该不低的(相对于单词)。
lua translator直接设置输入码没达到长度降权就行了
lua translator直接设置输入码没达到长度降权就行了
这肯定不行啊,有些就是需要短单词,例如 menu
lua translator也可以设置全码对应时提权,而且降权也不代表会排在非常后面,给英文适当降权更有利于连贯输入。
我目前的英文副翻译器策略是 2码以上激活 输入码长度大于5时且全码对应时,权重+100%并最多再加载一个候选 中文翻译器非全码状态且英文翻译器全码对应时时权重+10% 补全总是使用正数词频 所有非首位候选权重减半
为了 rime-ice 不受干扰, issue 干净些,先 close 不影响继续更新。
en.dict.yaml 中的单词(
length <= 4
) 的。有
2664
个: 2664 - gist我简单统计了其中的2665 个中的 500多个短单词
其中有一些单词, 可能会有「短单词置顶」的问题: