Starting with 1.97, some words such as 食べながら are highlighted incorrectly when you type them in the editor.
For example:
たべながら [enter] -> 食べながら, 食べな is highlighted.
It's debatable whether to highlight the whole word with the nagara, but it should be either that or 食べ, not 食べな.
h4. The reason:
In 1.97, Wakan now searches for typing suggestions in stRomaji. This is correct as searching in stJapanese only looked upon kanji field, while we really need a phonetic lookup (stRomaji).
But in stRomaji mode, inflen field in the results was not properly filled as it had originally been intended for stJapanese only.
Instead of the deflexion guess length (たべ = 2), simply the length of the vocabulary term in kanji (食べる = 3) was being stored.
This is because it wasn't clear how to interpret this field for romaji requests.
h4. The solution
Storing the length of the vocab term is anyway pointless, so that wasn't a good idea.
After thinking for a while, I think for stRomaji inflen should reflect the length of the inflected guess, in kana (despite that we've searched in romaji):
That's what people usually need anyway
If you need inflected length in romaji, you have to look at the search result kana field to figure how your romaji had translated to mishmash of latin/kana characters anyway.
If you need inflected length in kanji, it's easy: just adjust by the difference between kanji/kana lengths of the dictionary entry (in deflected form). Inflection cannot change that difference.
Another problem had been that the Editor in typing suggestion mode:
First replaces the typed kana with suggested kanji match
Then attaches the already pre-generated search result to that match with SetWordTrans.
The search result had been generated for the stRomaji lookup, and contains inflen in kana characters (5 for かんがえた).
After the editor replaces かんがえた with 考えた it calls SetWordTrans to attach a translation for it. But SetWordTrans doesn't know the backstory, it's attaching a translation to 考えた, so inflen of 5 means it should highlight 考えた and 3 more characters.
Worse, SetWordTrans is also used on auto-translated words, where we look for stJapanese (since the text is already in its final form) and inflen in search results really contains 3 for 考えた.
The correct solution is this: SetWordTrans is correctly unconcerned with these particulars and should continue to remain so.
When accepting typing suggestion, the Editor replaces kana with kanji inplace, and should not pass search results for kana entry to SetWordTrans.
It can either search again for the replaced word and try to re-locate the chosen translation in the new list (more future-proof but more prone to not finding the result again either), or just fix the chosen search result in place, adjusting the inflen.
I went the second way, so after making the replacement, the suggestion accept code adjusts the inflen by the difference between kana/kanji versions of the word.
Original report by me.
Starting with 1.97, some words such as 食べながら are highlighted incorrectly when you type them in the editor.
For example: たべながら [enter] -> 食べながら, 食べな is highlighted.
It's debatable whether to highlight the whole word with the nagara, but it should be either that or 食べ, not 食べな.
h4. The reason:
In 1.97, Wakan now searches for typing suggestions in stRomaji. This is correct as searching in stJapanese only looked upon kanji field, while we really need a phonetic lookup (stRomaji).
But in stRomaji mode,
inflen
field in the results was not properly filled as it had originally been intended for stJapanese only. Instead of the deflexion guess length (たべ = 2), simply the length of the vocabulary term in kanji (食べる = 3) was being stored.This is because it wasn't clear how to interpret this field for romaji requests.
h4. The solution
Storing the length of the vocab term is anyway pointless, so that wasn't a good idea. After thinking for a while, I think for stRomaji
inflen
should reflect the length of the inflected guess, in kana (despite that we've searched in romaji):Another problem had been that the Editor in typing suggestion mode:
SetWordTrans
.The search result had been generated for the stRomaji lookup, and contains
inflen
in kana characters (5 for かんがえた). After the editor replaces かんがえた with 考えた it callsSetWordTrans
to attach a translation for it. ButSetWordTrans
doesn't know the backstory, it's attaching a translation to 考えた, soinflen
of 5 means it should highlight 考えた and 3 more characters.Worse,
SetWordTrans
is also used on auto-translated words, where we look for stJapanese (since the text is already in its final form) andinflen
in search results really contains 3 for 考えた.The correct solution is this: SetWordTrans is correctly unconcerned with these particulars and should continue to remain so. When accepting typing suggestion, the Editor replaces kana with kanji inplace, and should not pass search results for kana entry to SetWordTrans. It can either search again for the replaced word and try to re-locate the chosen translation in the new list (more future-proof but more prone to not finding the result again either), or just fix the chosen search result in place, adjusting the
inflen
.I went the second way, so after making the replacement, the suggestion accept code adjusts the
inflen
by the difference between kana/kanji versions of the word.