table_translator的拼写运算对用户词典无效

[xiaoqun2016]

为方便描述问题，将实际方案简化如下：

# xxxa.schema.yaml

schema:
  schema_id: xxxa
  name: "speller_问题"
  version: 1
  author:
  description: 
  dependencies:

switches:

engine:
  processors:
    - ascii_composer
    - recognizer
    - key_binder
    - speller
    - punctuator
    - selector
    - navigator
    - express_editor
  segmentors:
    - ascii_segmentor
    - matcher
    - abc_segmentor
    - punct_segmentor
    - fallback_segmentor
  translators:
    - table_translator

  filters:
    - uniquifier

speller:
  alphabet: "zyxwvutsrqponmlkjihgfedcba"
  algebra:
    - "xform/^(...)..$/$1/"   

translator:
  dictionary: xxxa

# xxxa.dict.yaml

---
name: xxxa
version: 1
sort: by_weight
columns:
  - text
  - code
...

# table begins
频 abcdd
品 abcdd

#复制词典时，请将词与编码间的空格转为tab

经过拼写运算 "xform/^(...)..$/$1/"处理，实际输入abc时，正常：

输入abcdd时，为空码，也正常：

这些都符合方案设计的预期，没有问题。
接下来
将【abc 品】输入上屏之后，用户词典导出如下：

继续输入，这时候原本为空码的abcdd，变成非空的了①：

看上去这应该是rime没有对用户词典执行schema中的拼写运算导致的。
继续检查
输入若干次后，导出的用户词典如下：

可以看出【品】的词频明显更高，但用拼写衍生的编码abc输入时，实际效果却相反：

拼写的衍生码无法从用户词典中获得词频②。
而原本应该被xform剔除的abcdd这两个词条，不但能打出来，还获取了正确的词频：

此时如果直接将schema中的table_translator改成script_translator，词频是正常的：

综上，在使用table_translator时，拼写运算似乎处理得不够彻底，这会导致：
①出现预期之外的编码
②拼写衍生出来的词条无法获取正确的词频

在实际应用时，②的影响更多一些，比如手机版的五笔双键方案、顶功类方案的三简动态输入，都会因为词频混乱而无法得到满意的效果。

[lotem]

拼寫運算作用於固定的音節表，即在詞典中定義的編碼集合。拼寫運算表在詞典的編譯階段生成，script_translator 的用戶詞都要用這個音節表上的組合編碼。如此是爲了實現高效的音節切分。

table_translator 不適用這個機制。因爲：雖然固態詞典的內容也是固定的，但用戶自造詞可以產生新的編碼（對應「音節表」之外新的「音節」種類），因此查詢用戶詞典時不能侷限於拼寫運算所知的音節表，而是按照用戶詞典中存儲的編碼原文（其中包含固態詞典之外的編碼）檢索。
前面說到拼寫運算需要事先算出編碼對應的輸入形式，用來匹配用戶輸入，而不能反過來根據輸入逆推編碼（效率上無法滿足掃描整個詞典依次比對）。用戶詞典又是可編輯的（導入、導出、在輸入法之外編輯內容），沒有可靠的時機對用戶詞典進行拼寫運算。

事實上，（按照 table_translator 的設計以及碼表輸入法的傳統做法）該需求可以將簡碼（有限的且在編譯期全部已知）預先列入碼表，而不需要在運行時動態添加。table_translator 另外還支持自動生成用戶詞（根據規則自動編碼），用來應對無限的且無法預知的內容。

這兩種機制，都是爲解決運行時問題而設置的。他並不是一個碼表生成器。