[Userscript] Forum: IME2Furigana

[Sinyaven]

Is this already a bug report?

[Redglare]

No, I think it’s fine( )

Here, I left a space so it didn’t become like this()

[Sinyaven]

Version 1.1 patch-notes:

Upgraded from Discord to Discourse

Fixed the typo/mistake where I wrote “Discord” instead of “Discourse”.

If I broke something in this patch I’d be very surprised.
Link to previous script version for downgrading in case you want to live the Discord life

[seanblue]

I’ve been meaning to make my own markdown script, but hacking it into the post cooking is a pain. I have a working markdown plugin, which would be more useful across the board. But WaniKani’s Discourse plan doesn’t currently support custom plugins. So I’m trying to convert that plugin into a standalone script for the time being, but running it through the markdown engine without converting markdown unrelated to ruby is a pain.

Does overwriting w.require("pretty-text/engines/discourse-markdown-it").cook actually work? I wouldn’t think it would. I think if I run the whole post through that I’d still end up converting unrelated markdown, so I need to find a way to only convert highlighted text or something like that.

[Sinyaven]

Yes, as soon as someone inputs something like:
< something >[ something ] or
< something >{ something }
that isn’t intended for furigana, it breaks. I don’t know if it would be possible to inject a custom rule into markdown-it through a userscript. I haven’t even attempted it – the “ugly hack”-solution that I implemented was already hard enough for me and well beyond my knowledge of javascript project structure ^^
I also had to inject into the save() function – probably because Discord Discourse doesn’t accept a cooked string if it doesn’t match the raw input? Therefore I convert the furigana markup in the raw input right before save() is called.

[Sinyaven]

Version 1.2 patch-notes:

Ruby to furigana markup feature

As soon as ruby markup is detected in the input box, IME2Furigana now offers to convert it into the more compact furigana markup form.

If I broke something please let me know.
Link to previous script version for downgrading in case version 1.2 doesn’t work

[Kumirei]

Does this really need a prompt?

[Sinyaven]

I’m not sure – there might be cases where my ruby markup parser fails (it definitely fails with nested ruby tags). The resulting markup (after conversion to furigana markup and then back to ruby) is also most likely not the same anymore, so for example the Discourse functionality where it highlights the quoted part of the whole post after expanding the quotation would probably not work (I haven’t verified this). And since I automatically add lang=“ja-JP” to the ruby tag, the visual appearance of quoted parts might also be altered. Therefore I wanted to leave the user the choice before manipulating what they wrote.

Would you prefer a different behavior?

[Kumirei]

That all makes sense. I would like it to just convert it, but I understand that it might not be for everyone. Could you maybe make it a setting at least? Maybe just a variable at the top of the script?

[Sinyaven]

Okay, no problem

By the way, thank you for suggesting my script for the Japanese Only (Beginners) threads! Do you know if Mami-sensei also uses userscripts for her posts? Since she uses <ins> and <del> tags inside ruby, this might lead to problems with my script. For example <振>[ふ]り<仮<del>仮</del>名>[がな] leads to 振(ふ)り<仮仮名>[がな].

I guess finding a fix for this will be the next point on my to-do list.

[Kumirei]

I don’t know, buy my impression is that she doesn’t

[seanblue]

With your script, what is actually saved for the post? The ruby tags or the markdown?

[Sinyaven]

Version 1.3 patch-notes:

Added setting for unprompted ruby to furigana markup conversion

You have to edit the script and set ASK_BEFORE_CONVERTING_RUBY_TO_FURIGANA_MARKUP to false.

Sorry for not providing a more convenient way to access settings. I’m wondering if it would be a good idea to add a settings section for my script in the Discourse preferences menu?

[Sinyaven]

The ruby tags. For some reason the result after posting was always <漢字>[かんじ], instead of 漢字(かんじ). Either I missed some place where I would have had to inject something, or the server does some sanity checks?

[seanblue]

I’m pretty sure the “cook” functionality for the markdown is run on the server. I think the client-side copy only runs for the preview pane.

[Sinyaven]

Yes, so I assume there is no other option than to save as ruby tags.

[Sinyaven]

Version 1.4 patch-notes:

Furigana bugfix

Until now, every text that did not contain kanji was classified as “user input” that should potentially be used as furigana. That could lead to problems if the IME first converts the input into katakana or even emoji and afterwards into kanji. The last “input” not containing kanji was then used as furigana, leading to 狼(オオカミ) or 汗().

Now it uses the last input containing only hiragana or punctuation marks. I hope nobody plans to use their IME in katakana mode and wants their katakana input as furigana.

Tags in furigana markup

It should now be possible to use tags like <ins> or <del> inside of furigana markup. Examples:

Furigana markup	Result
<<del>昇</del>上>[のぼ]る	昇上(のぼ)る
<必<ins>須</ins>条件>[ひ<del>つ</del><ins>っす</ins>じょうけん]	必須条件(ひつっすじょうけん)

That’s probably a feature nobody will ever use.

Please let me know if something doesn’t work.
Link to previous script version for downgrading in case version 1.4 doesn’t work for you

[Sinyaven]

@shikaji

@Joeni

That is amazingly useful, thank you!

should it not work, check out the last post in the thread there, cause i had to downgrade to v.1.3 or else it wouldn’t function. also added this script to the API list - for some strange reason it wasn’t already listed despite its incredible usefulness

Thanks for the bug report – I have confirmed that version 1.4 doesn’t work in Waterfox. Version 1.5 should fix this. Since you went back to version 1.3, it probably won’t auto-update for you and you have to manually install the current version. And thank you for adding the script to the API list

rambling

When I saw some time ago that you had problems with RegExp lookaheads in Wanikani Heatmap, I was wondering if some users would also have problems with my IME2Furigana script, which also uses RegExp lookaheads. As it turns out, the lookaheads were fine – the negative lookbehind was not.

To be fair, regexr.com did warn me that negative lookbehind might not be supported by all browsers. And in my defense, I did put that part in a try...catch block. Too bad that regular expression literals are compiled when the script is loaded, and not during runtime, so the try...catch block didn’t help at all

---

Version 1.5 patch-notes:

Bugfix for browsers not supporting RegExp negative lookbehind

Waterfox doesn’t support negative lookbehind in regular expressions, which caused version 1.4 to not work at all in that browser. With version 1.5 it should work now. However, if your browser doesn’t support negative lookbehind, there is a rare case which will lead to wrong results: if you edit or quote a post that contains > in the ruby base, and then let IME2Furigana convert the ruby markup back to furigana markup, the > won’t get sanitized to > and IME2Furigana won’t be able to parse the resulting furigana markup.

Example: 2 > 1(wrong) will be back-converted to <2 > 1>[wrong] instead of <2 &gt; 1>[wrong]. The latter can be parsed by IME2Furigana, while the former can’t.

I doubt that this will ever be an issue, so I’m currently not planning to fix this.

Please let me know if something doesn’t work.
Link to previous script version for downgrading in case version 1.5 doesn’t work for you

[Kumirei]

Honestly I don’t understand why the lookahead was giving me trouble with the Heatmap. Looking at the specs it should have been supported, but maybe something else was going on too

[CDR-Strawberry]

一緒に頑張れましょうか

is it finally working?