Have AnkiMorph's optionally generated fields play well with the Japanese Support Add on

[quietmansoath]

Is your feature request related to a problem? Please describe. I would like to be able to batch generate readings with the Japanese Support add-on but cannot because the names of the fields for displaying sentences in AnkiMorph (am-highlighted) doesn't comply with the Japanese Support add-on's rules. It's uncertain if manually changing the name of the am-highlighted field would break it's functionality, either.

Describe the solution you'd like A clear and concise description of what you want to happen. The Japanese support addon requires a field to have "reading" in the name in order for furigana to be automatically generated and displayed on hover. It is the only addon (that I know of) that allows for batch furigana generation. When it creates furigana in batches, you can use specific ruby tags to ensure the furigana shows up only on hover, but this does not work if the field with the readings does not have "reading" in the name.

If I edit the name of am-highlight field, I'm unsure if it will break it's highlighted functionality. This is also a stop-gap measure, since when the field is generated by the add-on and so would likely need to be changed constantly.

I would like to be able to see highlighted text with am-highlighted's functionality, and to be able batch create furigana and display it without brackets.

Describe alternatives you've considered The JapaneseFurigana add on allows for creating readings without the field name requirement, and allows furigana to be seen on hover only, but doesn't have any batch generation option, and I have over 16,000 cards which all already have readings created; generating readings manually using a different add on is unrealistic.

Additional context Here's the screenshot of what is happening currently with the Japanese support add-on:

Here's an image of what I want to happen (example uses the JapaneseFurigana add-on; my mouse was hovering over 北方 when the screenshot was taken but it's not obvious from the image)

[mortii]

That is a really cool feature, I didn't know it did that.

The Japanese support addon requires a field to have "reading" in the name in order for furigana to be automatically generated and displayed on hover.

That's unfortunate. Damien Elmes, the guy who makes Anki, is actually the author of that add-on. I suspect that he doesn't have time to rework that constraint, so we would have to work around it somehow.

It's uncertain if manually changing the name of the am-highlighted field would break it's functionality, either.

Having the field name be static is a very deliberate design choice to prevent accidental overwriting of other fields, which was a significant problem back in the early alpha releases. This means that the highlighted text only gets placed in the field with the exact name 'am-highlighted'.

Changing the name of the field would break it in the sense that it won't update the field anymore, but all the content on the field would still work, so I guess you would be left with a snapshot of your current highlighting at the time of the name change.

I can't think of a super simple way to fix this in a way that doesn't break backwards compatibility. I'll mull it over and get back you.

[mortii]

@quietmansoath actually, I think you could just change your card template to include the furigana prefix:

{{furigana:am-highlighted}}

[quietmansoath]

I tried that initially and it didn't work, and I'm unsure why. I do have a lot of messy code from a previous style on my card which I tried to read through and couldn't find anything that would be conflicting, but I may have made a mistake.

Sorry to bother, but would you be able to test on your end and see if that works?

[mortii]

@quietmansoath sure, upload the deck that has those two cards and I'll take a look.

[quietmansoath]

Here it is.

I ended up batch editing all my cards to include a version of the sentence without the readings in them in the am-highlighted field. One thing I just noticed is that if I then copy and paste what's in the Sentence_Reading field into the am-highlighted field, I'll get the readings on mouseover now, but without the highlighting.

My deck is kind of a giant mess now and I really need to clean it up probably. Thanks for looking at it!

[mortii]

It seems that the brackets have to be right after the text for the furigana functionality to work.

This works:

<span morph-status="learning">北方[ほっぽう]</span>

this does not:

<span morph-status="learning">北方</span>[ほっぽう]

It might be possible to add an exception in the span builder to include the brackets directly following a morph.

I can try to implement it. Hopefully it doesn't cause a massive performance hit to recalc.

[quietmansoath]

Oh, I see. I had no idea that was happening. Is that an issue that would be specific to my deck, though, or to the functionality of AM or Japanese support?

Regardless, thank you for looking into it. I think you're the most responsive and open to feedback developer I've ever seen on github!

[mortii]

@quietmansoath It's not specific to your deck, it's a problem for anyone using a field that has ruby characters, so it would be nice to make this work.

[mortii]

I didn't realize that the ruby characters could also be placed in the middle of morphs like this:

• 同[おな]じ
• 思[おも]わず

That increases the difficulty by at least one order of magnitude since we have to use a different technique instead of just modifying the current one.

The only thing I can think of would be to extract and remove the ruby characters from the text before creating the spans, and then somehow insert them back into the correct spans afterwards. That will probably require some hacky magic, but I'll try.

[mortii]

Okay, I have managed to produce a rough implementation that works:

In the process of rewriting the highlighting I managed to make it significantly faster as well, so this is a win-win.

There is one unavoidable problem however. When morphs are not recognized in the same way that the ruby characters intended, then we get ugly things like this:

This is because 錬金術師 gets split into -> [錬金術, 師] and the ruby characters are after the second morph, so they only attach to that one. This is completely unavoidable, unfortunately.

I just have to iron out some kinks and clean up the code and then I'll push a new release.

[quietmansoath]

Waah, amazing! Thank you so much!

[mortii]

I'll keep track with a todo list here:

• [x] update tests
  • [x] make separate highlighting test
  • [x] remake recalc test with the new highlighting
• [x] clean code
  • [x] performance
    • [ ] use a doubly linked list
    • [ ] prepend to the doubly linked list
    • [ ] reverse sort the span_elements
    • [x] iterate span_elements by index not sub-loops
    • [x] use while loop for sub_string_index
    • [x] check if ruby_character_dict is empty before looping
  • [x] skip extraction and removal if 'ignore content in square brackets' settings option is not active
  • [x] import square_bracket_regex from text_processing module
  • [x] pass pre-commit
  • [x] move highlighting code to a separate file/module
  • [x] document everything
• [x] add it to the guide
  • [x] add to extra fields section
  • [x] add to known problems
• [x] bump ankimorphs version
• [x] upload new deck version

[mortii]

Released in v1.2.1!

Thanks for the feedback, let me know if you have any more!

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.