pub struct Candidate {
pub word: String,
pub kind: KanaKind,
pub freq: u32,
pub composed: bool,
pub proximity_milli: u16,
}Expand description
One JP candidate with its sub-source category, so the host UI can optionally render a hint (kana vs kanji) on top of the W/P/J source dot at the composite layer.
Fields§
§word: String§kind: KanaKind§freq: u320–100 frequency score. Higher = more common in modern JP. Used
by the composite-layer scoring (japanese_adapter::candidates_with_scores)
to lift high-frequency JP entries above rare Chinese candidates
per the user’s design rule: JP-base < wubi/pinyin bases, but
JP-high-freq must beat 中文难检字 + 生僻词组. For kana entries
(mechanical romaji → kana rendering) freq is 0.
composed: booltrue for compose_sentence products — mechanical (content +
particle/copula) sentence guesses like 私は or, for non-Japanese
romaji, junk like 時へ時. These are LOW confidence: unlike a real
dictionary 熟語 (新宿) they must never be treated as jukugo nor
trigger the full-match promote, and must score below real Chinese
words so they don’t pollute Chinese pinyin input. See
japanese_adapter::candidates_with_scores.
proximity_milli: u16Prefix-prediction proximity in thousandths: 1000 = the buffer is the
full reading (a normal/exact candidate); < 1000 = this is a PREDICTED
candidate whose reading the buffer is only a prefix of (shinjuk → 新宿
at 7/8 = 875). japanese_adapter decays the freq contribution by
(proximity/1000)^K and excludes < 1000 from the full-match promote
(the buffer isn’t the complete word yet). See PLAN-prefix-prediction.md.