無法由共用詞典的翻譯器實現調頻，原因是未指明所屬語言一致

[omgredfog]

在調頻定義函數「algo/dynamics.h」中，調頻的對象包括用戶碼表中的全體對象。音碼類輸入法中，這或許是個好辦法，然類，對於幾乎所有形碼類輸入方案，這幾乎是個災難。

不同與音碼類輸入法，形碼類的輸入法方案在制定之初，便有基本的「效率」設定。因爲「重碼」是無可避免的，分流重碼的設計存在於所有種類的形碼方案之中，一級簡碼設二重，二級簡碼設二重或三重，常見高頻漢字的重碼固定排序，都是非常常見的重碼分流方案。

依「五筆」爲例，25個參與編碼的鍵上，都有一個「無理碼」，通常叫作「一級簡碼」。它們是「固定」的，五筆用戶爲了效率，習慣上都將需要四次按鍵（4*某鍵）才能打出的「鍵名字」，作爲一級簡碼的「第二重碼」，比如：

• R
• 一級簡碼 「的」
• 第二重碼 「白」

這種設定，通常是作爲輸入法的「基本規則」來記憶的，不論在何種情形之下，五筆用戶都不希望按下一個「R」鍵時，「的」與「白」的次序有更改。

與此類似，「去」、「支」、「云」三個字共享「FCU」的編碼，一般來講，它們三個字的排序是固定的。在五筆中，整個 GB2312 裏重碼單字統共一百多組，而真正高頻的，不過十來組。這樣的固定序列，很容易形成肌肉記憶，對提升輸入效率，大有裨益。

於是，以五筆爲代表的形碼類方案，便有一個基本的需求：頻率調整，只針對詞組，不涉及單字。

通常來講，詞組編碼的定義是需要「四」個編碼完成，而「三」個編碼（一，二，三）已覆蓋掉 GB2312 單字的 95 % 以上，在「四碼鍵入完畢」時，詞組的排序，可以放心地優先單字顯示。

例如：

目前，五筆用戶唯有禁用所有調頻、自造詞、用戶詞典等功能，才能正常使用 RIME ——在所有平臺中皆是如此。

一級簡碼，一簡二重碼；二級簡碼，二簡二重碼；三級簡碼；全碼重碼字

這些涉及「單字排序」的內容，一旦啓用了 「enable_user_dict: true」，不久就會排序亂得差七錯八。而一旦關掉，就等於告別了 RIME 的自造詞功能，非常遺憾。

倘若 Librime 能打個補丁，將調頻策略修正爲僅針對用戶詞組，那麼即使 RIME 形碼類用戶起初只放置一份純單字碼表，也能養出一份「知我心意」的「用戶詞典」了。

以上，請參考。

[omgredfog]

至於「新詞」的位置，大可以最優顯示，也可以次於單字顯示，這都無所謂，總之，將原來用戶碼表中的單字之間的排序打亂——總是個很大的困擾。

[omgredfog]

经实践发现：优先级低的翻译器在过滤重码时会被无视掉，从而导致它形同虚设。

[lotem]

多謝反饋。
現在無法實現預定效果，是因爲這一處代碼沒有完成：
https://github.com/rime/librime/blob/master/src/rime/gear/memory.h#L65
兩個共用詞典的翻譯器應該指向同一種「語言」，從而互通對詞典的更新。
雖然設計中有這一環，但當時還沒有應用場景，權且假定每個翻譯器處理不同「語言」。

[lotem]

實現方法：
在 Language 對象裏記錄語言代碼，據此實現該類的比較運算符 ==。

語言代碼按照原定設計取詞典名中任何 . 字符之前的部分。即與確定「用戶詞典」名稱的規則一致。
例如詞典 luna_pinyin、luna_pinyin.extended 均對應語言代碼 luna_pinyin。

[omgredfog]

非常抱歉，因爲配置遇着困難就發了這麼一條反饋，實際上一樓，二樓，三樓所指所問都不同，因爲翻查到了佛振君給的「同一字典雙層翻譯器」，二樓，三樓所說，皆是針對這個置配方式上的不完美而談。下面，我做個綜述：

我看到三年前的一處討論裏，佛振先生給出的「雙翻譯器」技巧，它大致是這樣實現的：

但是，這裏有個不完美的地方：

濾重器，會過濾掉來自低權重翻譯器的候選詞條供給，使得這個開啓了「用戶詞典」以拾取「上屏記錄」的翻譯器無法收到任何「上屏記錄」，以致「陰陽魚」無從給出正確的建議：

@lotem 佛振先生您說的，「互通對詞典的更新」這裏我不太明白，依上圖爲例，對於禁掉「用戶詞典」的那支翻譯器來講，用戶打字上屏的記錄它是不會收錄的。這個「互通」是從何說起的呢？

雙層翻譯器方案配置

如果不更改濾重器的濾重策略，針對這種共用了同一方案字典的兩個翻譯器，只要能收錄到來自「高權重禁調頻」的那支的上屏信息並收錄到用戶詞典中，問題便徹底解決了，就像下面，不知道您上面回復的是否與我現在講的可是同一回事兒？

還是非常希望能夠實您三年前給的這種「雙層翻譯器」技巧，這樣能保障用戶的碼表詞序在打字時是固定的，同時，又可以利用陰陽魚的建議功能。新加的詞組，在排序上是後置於原碼表詞條的，不會給形碼用戶造成困擾。

[lotem]

基本正确。
过滤器在此处没有影响。首先 uniqifier 并非简单忽略后来者，而是把文字相同的候选词合并成一个选项，包含原选项的引用。但这不是问题的关键。
每个翻译器也都会收到上屏的候选词序列，他们会有选择地记录来自他们所属语言的文本。这些逻辑都符合设计。
唯一的问题是现在他们不知道在用同一种语言。

[omgredfog]

那太好了，请求修缮一下。

[nameoverflow]

公子准备啥时候弄弄这个？

[nameoverflow]

我觉得这里是不是由 Dictionary::name 相等来判断就可以了？如果两个被 unified 的候选是来自同一个 dict 那么就应该组词。没有很明白独立出一个 Language 类型的作用。

[lotem]

Language 是指輸入法的編碼方案，或者對應語言學的「音系」概念。

拼音和五筆，由於漢字編碼方案不同，因此屬於不同語言；
漢語拼音和粵語拼音，也屬於不同（輸入法概念上的）語言，這比較直觀；
朙月拼音和地球拼音，雖然語言學上都對應現代標準漢語，但是聲調有無導致音節表不兼容，也是不同的輸入法語言。
地球拼音和注音，是同一個音系的不同拼寫法（通過不同的棱鏡反射），兩者詞典共享，恰屬同一種語言。
按照這個分類依據，與語言最接近的概念就是詞典名即 Dictionary::name()。

但問題來了，同一種語言還可以由多種詞典實現。類比漢語詞典會有「新華字典」「現代漢語詞典」等不同版本，輸入法用家也有類似需求，創建更大更全或者個性化、專業化的拼音詞典，然而又想與明月拼音及其衍生方案如雙拼互通，因此約定了這樣的詞典名：luna_pinyin.extended.dict.yaml、luna_pinyin.poetry.dict.yaml 等等，他們都基於共同的拼音音節表。
注意這不只是命名約定而已，輸入法確實會取第一個 . 之前的部份，作爲 用戶詞典名 （如果沒有在配置裏另行定義）。即詞典 luna_pinyin.extended、luna_pinyin.poetry 與 luna_pinyin 共享用戶詞典，以免切換詞典後重新學習輸入習慣。無疑這個「輸入習慣」是與輸入法所講的「語言」更相關的東西。本題所討論的調頻正是針對用戶詞典的。

接下來要做的是把以上取用戶詞典名的邏輯明確定義爲 Language。

[omgredfog]

重大的问题之一啊，盼解决……

希望能将这个 issues 的排期靠前些啊

形码用户们实现rime的自造词，全靠它了。

[lotem]

@omgredfog 自造詞不依賴這個功能

[xiaoqun2016]

針對這種共用了同一方案字典的兩個翻譯器，只要能收錄到來自「高權重禁調頻」的那支的上屏信息並收錄到用戶詞典中，問題便徹底解決了

@omgredfog
像这样打补丁，问题就迎刃而解了：

# wubi86.custom.yaml
patch:
  engine/translators:
    - punct_translator
    - reverse_lookup_translator
    - table_translator@fixed
    - table_translator
  engine/filters:
    - uniquifier
  fixed:
    __include: wubi86.schema:/translator
    enable_user_dict: true  # 开启用户词典
    enable_encoder: true  # 开启造词功能
    initial_quality: 1000
    disable_user_dict_for_patterns:
      - '.*'  # 对所有编码禁用用户词典（不调频，不读取用户词，但不影响自造词写入用户词典）

由高权重的fixed翻译器来负责呈现固态词典中的所有条目，以及造词、记录词频。再由低权重的主翻译器负责呈现用户词，以及用户词的调频。

[nameoverflow]

@xiaoqun2016 很厉害的样子

[omgredfog]

@xiaoqun2016

该贴所述的思路，就是你说的这种想法的实现。
该贴所反馈的问题，就是这种想法实现不了。

[omgredfog]

@lotem

但是目前的问题就是：低权重的翻译器无法拾取到上屏记录。

在纯单字的形码码表下，「秋」和「天」连续上屏之后，尝试「秋天」的编码键入时，「秋天」并不在「阴阳鱼」的建议中，而若去掉「滤重参数」，再次连续输入「秋」和「天」时，都选排在第二位（由低权重翻译器给出的上屏选项）的「秋」和「天」后，尝试「秋天」的编码，「秋天」就被阴阳鱼正确地给出了。

所以，「自造词」确实依赖于这个功能的实现，目前这个issues存在，双翻译器模式下的「自造词」——实现不了。

[xiaoqun2016]

@omgredfog 一些细微的调整，出来的效果就大不相同了。为什么不实际试一下那个补丁呢？ 难道非要用低权重的翻译器来造词吗

[nameoverflow]

@xiaoqun2016 不过你的这个方法用户词不能调频吧。

[xiaoqun2016]

用户词可以调频。因为负责呈现用户词的那个低权重翻译器开启了用户词典，想不调频都难。

[xiaoqun2016]

具体效果：实测录屏 （12M）

参考方案：

# Rime schema settings
# encoding: utf-8

schema:
  schema_id: wubi86
  name: "五笔86-测试"
  version: "0.21"
  author:
    - 發明人 王永民先生
  description: |
    五筆字型86版
    碼表源自 ibus-table
    敲 z 鍵進入拼音反查
  dependencies:
    - pinyin_simp

switches:
  - name: ascii_mode
    reset: 0
    states: [ 中文, 西文 ]
  - name: full_shape
    states: [ 半角, 全角 ]
  - name: extended_charset
    states: [ 常用, 增廣 ]
  - name: ascii_punct
    states: [ 。，, ．， ]

engine:
  processors:
    - ascii_composer
    - recognizer
    - key_binder
    - speller
    - punctuator
    - selector
    - navigator
    - express_editor
  segmentors:
    - ascii_segmentor
    - matcher
    - abc_segmentor
    - punct_segmentor
    - fallback_segmentor
  translators:
    - punct_translator
    - reverse_lookup_translator
    - table_translator@fixed
    - table_translator
  filters:
    - uniquifier

speller:
  delimiter: " ;'"
  max_code_length: 4

fixed:
  __include: translator
  initial_quality: 1000
  enable_completion: true #若设为false，则无法造词
  disable_user_dict_for_patterns:
    - '.*'
# 实测发现词典中4码的字词不会参与造词（未解之谜），而1~3码的字可以正常参与造词。

translator:
  dictionary: wubi86
  enable_charset_filter: true
  enable_sentence: false
  enable_user_dict: true
  enable_encoder: true
  encode_commit_history: true
  max_phrase_length: 4
  disable_user_dict_for_patterns:
    - "^z.*$"

reverse_lookup:
  dictionary: pinyin_simp
  prefix: "z"
  suffix: "'"
  tips: 〔拼音〕
  preedit_format:
    - xform/([nl])v/$1ü/
    - xform/([nl])ue/$1üe/
    - xform/([jqxy])v/$1u/

punctuator:
  import_preset: default

key_binder:
  import_preset: default

recognizer:
  import_preset: default
  patterns:
    reverse_lookup: "^z[a-z]*'?$"

不明白enable_completion为何会影响到造词了？disable_user_dict_for_patterns和其它功能组合起来也出现了意料之外的效果，结果并不完美，临时用用倒是可以。主要还得靠Rime更新功能了。 @omgredfog

[nameoverflow]

发现在 #214 的实现下，只有当设定 enable_sentence: true 并一次性输入多个单字的编码时才能造词，分多次连续输入多个单字无法造词。如果设定 enable_sentence: false 并连续输入多个单字，查看用户词典记录发现并没能拾取到上屏记录。

--

好吧，发现这个问题只有部分词语才会出现，比如分别输入「笑」和「死」后无法整合为一个用户词，但是「用」和「户」是可以的。「可」和「以」也可以。

[omgredfog]

@nameoverflow

当「enable_sentence: false」时，阴阳鱼给出的建议，其实依然与「上屏记录」无关，你看到的，以为起了效的正确建议，是因为它们都是排在「第一」的首选单字。

清空已编译的用户缓存文件，尝试使用纯单字码表输入单字，或连续输入指定单字，然后重新部署一下让程序生成文本文件的「用户上屏记录」，在我这里，我发现是收录不到上屏信息的。

wubi98_jian.schema.yaml：

↓ 在本地生成的用户词典名称
user_dict: 98wb
↓ 用户词典格式，tabledb（文本） 或 userdb （二进制）。
db_class: tabledb

验证是用新编译的 fcitx-rime

[nameoverflow]

@omgredfog 你是使用的 #214 之后编译的 librime？
我从自己这里验证的结果是一部分记录可以收录，但是另一部分不可以。

[omgredfog]

@nameoverflow

忘了这一茬儿了，我重新看一下。
是最新了，没错。

[nameoverflow]

单步一下发现 encode commit history 的问题疑似是因为 src/rime/gear/table_translator.cc#L338 处判断 it->type，不能造词时对应 commit history 的 type 是 uniquified 于是跳出了。我使用的方案中所有 2 码和 1 码的候选的 type 都是 table，3 码以上则是 uniquified。不知道是这里的问题还是 uniquifier 的机制问题。

[omgredfog]

@nameoverflow @lotem

这个 ISSUES 虽然被关闭了，但是我反复验证，发现上屏记录，还是没有办法被拾取到。

下面是验证码表，是「单字」码表，可以连续输入任何「单字」，然后在「用户目录」下的「用户词典」（特别设定为了TXT文本格式）中，查看是否有拾取到的上屏记录，我这里反复验证，无法拾取到。

这个 ISSUE 从佛振君提出设想到今天，已经 4 年有余，我在确认「配置方式」正确的前提下，至今没有复现成功，希望被指点一下，问题到底出在什么地方。

验证文件

[nameoverflow]

要 enable_completion 吧。

[omgredfog]

@nameoverflow

双翻译器都加上「 enable_completion: true 」——它是「逐渐提示」的开关

打单字「春」和「云」

重新部署一次，以刷新「用户词典」

打开一看，还是没有拾取到：

[nameoverflow]

不用 tabledb 就可以造词。

[omgredfog]

@nameoverflow 明白了，感谢

[omgredfog]

@nameoverflow
经过反复测试，发现在造词时，如果有第二或第三重码参与，就会无法造词成功。
举例：「寸云」
可以输入「寸」和「云」的编码，以「编码切分符」切分它们，用方向键选字使「寸」和「云」分别上屏。
但是，如果不给「高权重」的「翻译器」开「 enable_user_dict: true 」，「寸云」的建议，永远不会出现在阴阳鱼中。
可是，如果开了「 enable_user_dict: true 」，完全有违初衷。

[nameoverflow]

@omgredfog

[omgredfog]

@omgredfog

求分享配置文件，查了半天没找到原因。

[omgredfog]

@omgredfog

终于弄清楚了，原来只要对「用户字典」的名命与当前方案名不一致，就会出问题。

# ↓ 在本地生成的用户词典名称
user_dict: 98wb

原来公子真的已经修复了这个问题，下面的配置已经可用了

https://github.com/omgredfog/rime-make-phrase

[omgredfog]

@omgredfog

经过调整，发现原来并不需要「强制开启」逐渐提示，也能使用上自造词功能。
我在这份配置文件中，用了3个翻译器，实现了禁止程序根据上屏历史记录推建议词，同时还可以使用编码切分符手动造词，哈哈，太安逸了！
https://github.com/omgredfog/rime-make-phrase

[huaxianyan]

@omgredfog
抱歉打扰您，但是您分享的链接已经失效了，最近我也碰到了使用第二个翻译器用来给高权重固定候选字词，但是无法上屏的问题，想看看您是怎么解决的

[Ace-Who]

最近使用这个方法，出现一个意外状况，即当自造词为首个候选时，一定会被删词键删去，即使光标在其他候选上。如果那个候选也是自造词，也会被删去，即同时删去了两个自造词，而其他位置的自造词（如果有的话）不受影响。

[KyleBing]

还是手动造词并调整词序实在些，写了个有基础功能的词条添加工具，目前感觉还可以：

码表助手：https://github.com/KyleBing/WubiBuddy