librime项目中script_translator多音节补全功能的优化探讨

功能现状分析

librime作为开源输入法引擎的核心组件，其script_translator模块负责处理输入码到候选词的转换过程。近期该模块在enable_completion选项的功能上进行了重要调整，从原先仅控制单音节词补全，扩展为同时控制单音节和多音节词的补全功能。

在旧版本中，当enable_completion设置为true时：

• 输入"ni'hao'shi'j"会补全为"你好世界"
• 设置为false时则无候选词输出

而在新版本中，同样的设置下：

• 输入"ni'hao'shi'j"不仅会补全为"你好世界"，还会显示"你好世界啊"等扩展候选
• 设置为false时同样无候选词输出

现有问题剖析

当前实现存在两个主要技术痛点：

1. 控制粒度不足：多音节补全功能缺乏独立的开关控制，开发者无法单独禁用多音节补全而保留单音节补全功能。

2. 候选词过载：多音节补全会不加限制地加载所有联想词，导致候选区被大量相关但不精确的候选词占据。例如输入"qian'yu'qian'xun"时，不仅会显示"千与千寻"，还会显示"千与千寻作画"、"千与千寻原画"等所有相关扩展词，严重影响输入效率。

优化方案建议

功能解耦设计

建议将enable_completion选项拆分为两个独立参数：

• enable_monosyllabic_completion：控制单音节补全
• enable_polysyllabic_completion：控制多音节补全

这种解耦设计可以给予开发者更精细的控制能力，满足不同场景下的需求。

候选词数量控制

引入max_completion_candidates参数，限制多音节补全返回的候选词数量。可参考macOS输入法的实现策略，默认只返回1-2个最相关的联想词。

技术实现上可以采用：

1. 基于词频排序的截断策略
2. 基于编辑距离的优先级算法
3. 用户自定义的权重系统

候选词类型标记

当前版本已经为补全类候选词标记了"completion"类型，这为后续的过滤和处理提供了基础。开发者可以利用Lua脚本基于此标记实现更复杂的过滤逻辑。

技术实现考量

对于需要精确输入的场景（如输入特定ID），可以考虑以下技术方案：

1. 完全禁用多音节补全功能
2. 使用拼写算法生成缩写替代补全
3. 实现基于上下文的智能过滤机制

这些优化将显著提升librime在复杂输入场景下的用户体验，同时保持其灵活性和可定制性。