Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deconjugation of Target Word #18

Open
ccos89 opened this issue Feb 11, 2024 · 3 comments
Open

Deconjugation of Target Word #18

ccos89 opened this issue Feb 11, 2024 · 3 comments

Comments

@ccos89
Copy link

ccos89 commented Feb 11, 2024

Hey there, loving the extension. One thing I’d like to request if possible - right now, for adjectives and verbs, the target word that gets output to Anki is the conjugated word used in the sentence as opposed to the deinflected dictionary form of the word. For example, if my sentence contains 食べたり, the target word will export as 食べたり instead of 食べる.

Can this behavior - at least optionally - be altered to export the headword of the selected dictionary entry, or deinflected form of the word, as the target word instead? This would help avoid inflated known word counts for me.

@nairyosangha
Copy link
Member

That is what extensions/EXT_dict_word_lookup.lua tries to do.
This one also required that you have those patterns in langsupport/ja/dictwrapper.lua working for your dicts.

As I mentioned on your other issue, if the headword in a dict looks like ののしる【罵る】, the extension will try to add 罵る as target word on your note.

If you don't care about that you could change this line

local parsed_word = selected:get_kanji_words()[1] or selected:get_kana_words()[1]

and have it use selected.word directly, instead of trying to extract info out of it

@oldmerkum
Copy link

oldmerkum commented Sep 29, 2024

I'm a little confused by the explanation.
I also have this issue, and the dictionary lookup works properly, it's just that the dictionary headword isn't being added to the note, and instead the instance of the word in the sentence is added.
e.g.
I lookup successfully the word: 温めて
It provides the correct definition and reading: あたためる - to warm
The headword is found in the lookup: 温める (it has to have found this since the lookup succeeded)
The note generated does not use the headword and instead uses: 温めって
This is even added to the note, showing that the headword is available:

<div class="definition">
<ol><li dict="JMdict-ja-en">あたためる・あっためる・ぬくめる【温める・暖める】<br>〘v1・vt〙<br>to warm; to heat.</li></ol>
</div>

@nairyosangha
Copy link
Member

I'm a little confused by the explanation. I also have this issue, and the dictionary lookup works properly, it's just that the dictionary headword isn't being added to the note, and instead the instance of the word in the sentence is added. e.g. I lookup successfully the word: 温めて It provides the correct definition and reading: あたためる - to warm The headword is found in the lookup: 温める (it has to have found this since the lookup succeeded) The note generated does not use the headword and instead uses: 温めって This is even added to the note, showing that the headword is available:

<div class="definition">
<ol><li dict="JMdict-ja-en">あたためる・あっためる・ぬくめる【温める・暖める】<br>〘v1・vt〙<br>to warm; to heat.</li></ol>
</div>

The actual lookup is handled by KOreader itself so that doesn't mean the plugin automatically knows what to do.

I'm seeing in the snippet your dict has the name 'JMdict-ja-en' which is not list here, so it falls back on the default, which might not work here, it's looking for the patterns listed in that file I linked above as well:

kana_word_pattern = "(.*)【.*】",
kanji_word_pattern = "【(.*)】",

and it's matching that against whatever is in the word for your dict, which might not match

You could test it by updating this line:

local parsed_word = selected:get_kanji_words()[1] or selected:get_kana_words()[1]

And append or self.popup_dict.word which will make it fall back to whatever is in the word field, if it can't do the match. I should probably add that myself so turning this extension on at least has some effect even if the matching failed.

Also obviously make sure the extension is turned on, but I'm assuming that's the case already

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants