[Userscript] Forum: IME2Furigana

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

1 Like

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

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?

2 Likes

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?

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.

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

1 Like

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 (:sweat_drops:).

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

4 Likes

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 :slight_smile:

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 :sweat_smile:


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 &gt; 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

4 Likes

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

1 Like

一緒に頑張れましょうか

is it finally working?

I can’t get the script to work… :sweat:

I’m on Google Chrome. I’m using a Japanese keyboard on a Japanese computer, does that affect things? The script is reading as installed and active, but it won’t add any furigana. I typed out the complete words and then selected them from the suggestions. Any ideas of what I should try?

You have to click the button to activate it

3 Likes

I did not realize modes would be required for functioning. Is that terminology normal for computer/programming stuff?

1 Like

I wanted to add the possibility to disable this script’s functionality because sometimes one might prefer to type Japanese without furigana. Additionally, the script might sometimes affect texts that were not intended to be furigana markup – maybe somebody likes to type weird smileys, and the script would turn

Lorem ipsum <3 dolor sit amet >[ consectetur adipisici elit =]

into

Lorem ipsum 3 dolor sit amet ( consectetur adipisici elit =)

So I thought it would be useful to add a mode that completely prevents this script from tampering with user input.

I thought that it is enough to mention how to enable the script in the first post, but it would probably have been better to have it activated by default. Sorry for the inconvenience.

2 Likes

Ah, I see now, that’s pretty neat!

I think this is a definite case of user error/my own stupidity for not reading the instructions in their entirety, so please don’t feel like you’ve inconvenienced me or anything negative like that.

Honestly, that’s really cool that it does it for stuff like that. I might leave it on to see who all I can harmlessly confuse in pollfam with it now.

Although maybe to prevent more idiot questions like mine it might be better to rename that header from “Script modes” to “How to activate” ?

1 Like

Honestly I would prefer it being active by default

1 Like

Version 1.6 patch notes:

The script functionality is now initially enabled (mode initialized to "on")

When installing the script, the user likely wants to use the script’s functionality immediately, so it was a bad design choice to initialize the mode to “off”.

Rejecting the back-conversion of ruby to furigana markup is persistent again

If the user chooses not to back-convert, I save their choice by adding a class to the element containing the textarea. However, it seems there was a change to Discourse, and now it deletes my added class immediately. I fixed this by moving the class to the parent element.

Repeatedly clicking the F button now keeps updating the preview box

If the user enables or disables the script functionality, the preview box should be updated immediately to reflect the change. However, the update only happend for the first click. This should be fixed now.

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

4 Likes

4 Likes

When creating the script, I was actually tempted to call the script “Press F to Furigana”.

5 Likes

Love it