IME2Furigana stops working today. (v1.8, Brave Browser on Windows.) Maybe Discourse update something?
3 Likes
Also not working on Google Chrome either.
Thanks for reporting. This seems bad, I don’t know if the script can be adapted to circumvent the new writing protection. I will take a closer look over the weekend.
3 Likes
I made a quickfix of this for now. Well, no fancy syntax like <kanji>[kana], so no real conversion back-and-forth. Only the auto-Furigana part.
It seems like cook-injector isn’t possible anymore. Detail Keep Open is also broken. Emoter is probably broken by the same reason.
1 Like
Thank you for the quickfix! Since I use several different computers though, I think I’ll wait for a change to the original script if possible. If that doesn’t happen though, I’ll happily install your fix on the computers I use.
Sorry, I’ve tried to use your quickfix but it doesn’t seem to be working
It converts on changing modes. Though, I believe a better fix is possible, as Kumirei could fix their script.
2 Likes
I’ve tried changing the mode several times and it didn’t do anything though
I updated the quickfix just now, reusing at emoter’s code.
2 Likes
Thank you for posting the quickfix, that was really helpful! I have merged your changes. Also thank you to @Kumirei for finding the new way to inject custom code into the Discourse cook method.
Version 1.9:
- Updated to work with the Discourse changes
5 Likes
@Sinyaven Any chance the issues we were seeing were caused by this script? Basically we got some really messed up HTML.
1 Like
The intended use of this script was to either only enable it when you actually need furigana in your post, or to at least keep an eye on the indicator that tells you when IME2Furigana has found furigana markup and tampers with the post, so that you get alerted about potentially unwanted conversions.
I did not even know that IME2Furigana still works partially – I thought that the recent Discourse update has broken it completely.
Ah, oh well then. Hopefully people will be more careful going forward.
1 Like
Version 1.10:
Updated to work again after recent Discourse changes
I did not find a way to inject IME2Furigana’s cook function into Discourse’s own call to its cook function anymore. As a workaround, I replaced the textarea’s value property with a custom getter and setter. This approach is probably not yet compatible if used in multiple scripts (e.g. @Kumirei’s Emoter script), but I wanted to push out the update to get feedback before thinking about compatibility.
EDIT: I just realized that this workaround breaks Discourse’s formatting features (e.g. selecting a word and pressing Ctrl+B will fail if there is furigana markup anywhere before that). I hope I will find a way to fix this tomorrow. Ideally, there would be a way to determine whether the textarea.value getter was called from Discourse’s cook function or from somewhere else 
3 Likes
At this point I think I’ll leave the Emoter broken. It was a nice script while it lasted
1 Like
Aw, I’m sad to hear that! I used it semi-regularly… Thank you for making it, though!
1 Like
The trick that now doesn’t work was what made me create the script in the first place. Without it it’s a lot trickier to make preview and save correctly.
Although I could simplify it and make it replace the text directly in the editor. That would be easy to maintain, too
2 Likes
Decided to give it a go after all, and it does work quite nicely except for the formatting thing. Emoter shall rise again.
If you already have a setter/getter defined I will just wrap them. However, that requires that you set your property to be configurable: true in defineProperty. You think you could add that? If you want IME2Furigana to play nicely with the fixed Emoter you might also want to consider wrapping any existing setter/getter in the case that emoter runs first.
3 Likes
I have added your suggestions to the script. After a quick test, it seems that both scripts work now, no matter what the execution order is.
Sadly, I still have not found a way to avoid breaking Discourse’s formatting features.
2 Likes
HTML tags <>, followed by a markdown link [](), will be broken on editing a post (e.g. a wiki), and then saving.
How about auto-add a zero width space between > and [, and between > and {, to prevent the conversion? I don’t think anything will change visually. (Though the script users should double-check to be sure, so give a warning in the OP?)
2 Likes