JMdict sense numbers are redundant with ordered list numbers in Group Term-reading Pairs

[yangmillstheory]

Hello; apologies if I'm misunderstanding, but for many definitions I see the following ordered list with the list element number being exactly the same as the JMdict Sense number:

This seems duplicative to me when using grouping mode Group Term-Reading Pairs.

• Is there a reason to keep both (is it possible for one single definition to have multiple senses)?
• Could we turn off the numerical sense icons?

When I import definitions into Anki, I have to do some extra work to remove the sense icons to remove the redundancy.

[stephenmk]

is it possible for one single definition to have multiple senses

Yes.

ミス


けいそつ


もと【元】


Is there a reason to keep both

The JMdict sense numbers aren't always going to be the same as the HTML ordered list numbers. If you have multiple dictionaries and the JMdict senses are displayed below them, then the numbers will be offset by those other entries.

The numbers aren't always going to be sequential within a given JMdict entry, either. Notice that sense #9 is missing from the もと【元】 screenshot above. Since the #9 definition only applies to the 本 form of the word, the definition has been omitted.

I designed the dictionary that way because I spend a lot of time editing JMdict, and the information is useful for me. I agree that the presentation isn't great and that the information might not be useful for everyone. I think I have improved upon the design in Jitendex.

Could we turn off the numerical sense icons?

They would need to be removed from the dictionary, or you could maybe modify the Yomitan handlebars to strip them out. I'm willing to accept a commission to make a dictionary file without the numbers for you, but I'm afraid it wouldn't be very cheap. Maybe someone else will volunteer to do the work for free.

[yangmillstheory]

Thanks for the reply Stephen! I'm still new to the various dictionary schemas and tagging semantics, but it sounds like the numbering is working as intended (indeed, I only spot-checked a few entries).

If I'm the first person that's asked for this, then perhaps it's not worth doing the work to implement this feature, and maybe it doesn't make sense in general. In that case, I'm fine closing the issue as not planned.

BTW I tried Jitindex yesterday, but ran into #504 when mining cards.

[stephenmk]

BTW I tried Jitindex yesterday, but ran into https://github.com/themoeway/yomitan/issues/504 when mining cards.

Correct me if I'm wrong, but it looks like you're using the jp-mining-note anki template. The issue with the SVG images that you had is due to that template, not Jitendex or Yomitan.

I agree that the SVG icons aren't a good solution. I recently submitted a patch to Yomitan that will allow Yomitan dictionaries to use more types of CSS styles (border-radius, background-color, etc.). As soon as this new version of Yomitan is available (probably within the next week?), I am going to release a new version of Jitendex which replaces those SVG icons with plain HTML and CSS. I expect that this new version will resolve the image issues with the jp-mining-note template.

[yangmillstheory]

Correct me if I'm wrong, but it looks like you're using the jp-mining-note anki template.

Nah, I'm using my own hacky HTML and CSS code, though I did suspect that the rendering issue could have been fixed on the user side. If you ping this bug or #504 when the new Jitindex releases, I'd be happy to try it out again.

[djahandarie]

As soon as this new version of Yomitan is available (probably within the next week?)

@stephenmk I just promoted the https://github.com/themoeway/yomitan/releases/tag/23.12.29.0 release from dev to stable, so go for it! :pray:

[yangmillstheory]

Continuing the conversation in #504.

[Kuuuube]

Closing as this is a dict issue not a yomitan issue.