The current compositions from incomplete symbols (a.k.a. shortcuts) are pre-generated data and capped at 16 words/phrases, e.g.
ㄧㄕ
藝術 也是 以上 有時 意識 醫師 要是 一時 醫生 ...
or
ㄧ
一 有 以 也 因 業 樣 意 由 ...
We should generate these suggestions by searching all possibilities, so users won't complain certain phrases/words are missing with a certain input. Like these confusing examples,
ㄧˉㄕ
一是 一 醫 依 衣 伊 ㄧ 壹 漪 ...
or
ㄧㄕㄥ
一生 一 有 以 也 因 業 樣 意 ...
The first tone (typed by the space key) can be easily forgotten, for the instance above, making the user thinks 「醫生」is missing from the list.
Implementing this feature will shave disk database size by around 1.x MBs because we no longer need to generate the static composition list. But, we would need to make sure we don't pull to much data into JS world during that search though.
The current compositions from incomplete symbols (a.k.a. shortcuts) are pre-generated data and capped at 16 words/phrases, e.g.
or
We should generate these suggestions by searching all possibilities, so users won't complain certain phrases/words are missing with a certain input. Like these confusing examples,
or
The first tone (typed by the space key) can be easily forgotten, for the instance above, making the user thinks 「醫生」is missing from the list.
Implementing this feature will shave disk database size by around 1.x MBs because we no longer need to generate the static composition list. But, we would need to make sure we don't pull to much data into JS world during that search though.