I had already noticed this when testing the fallback method, but I wanted to see if I can get away with it (and I also first wanted to check if the fallback method even works for you)
If you notice any other problems let me know.
I had already noticed this when testing the fallback method, but I wanted to see if I can get away with it (and I also first wanted to check if the fallback method even works for you)
If you notice any other problems let me know.
I noticed this happened earlier today:
But I was a bit focused on the message I was writing to figure out why. And now it is back to one F. I’ll look into it if I see it again.
I saw it again (a few days ago and forgot to post it here) and opened up the console to check what was there. Not sure it actually helps you, but I’ll post it anyway.
Version 1.8:
The community forum has a strict content security policy (CSP) which prevents some script managers from injecting the script into the page context. While they might fall back to injecting the script into the content context so that the script still runs, a script running in the content context cannot access the global variables in the page context (especially with the strict CSP in place).
The new version of IME2Furigana adds a fallback method that does not access any global variables. Instead of injecting the furigana markup to ruby conversion into Discourse functionality, the fallback method just applies the conversion to the input box content, lets Discourse generate the preview, and then reverts the input box content back. This method might be slower and more error-prone, but it seems to work well enough to be usable.
The furigana preview gets temporarily disabled during IME input because the IME input would get cancelled on each input box content change.
Known affected setups: Violentmonkey in Firefox, Userscripts in Safari (Tampermonkey in Safari seems to be unable to inject any scripts into the community forum at all).
If the script has to fall back to this slightly inferior method it prints a warning into the console.
Sometimes when editing long posts without any furigana (for example when I am posting an entire userscript) I feel like I should temporarily disable IME2Furigana to make sure that it does not convert any false positives without me noticing. The new version adds a blue underline to the F button if IME2Furigana finds something that looks like furigana markup so that you get warned of the script modifying your input.
Ctrl+Shift+F while the textbox is focused now allows you to quickly change the script mode.
Additionally, I have changed the regular expressions to use Unicode property escapes based on @polv’s suggestion. /^\p{scx=Hiragana}+$/u
is much easier to understand (and probably more complete) than /^[\u3041-\u3096\u3000-\u303f\uff01-\uff5eー]+$/
.
If you forgot to disable IME2Furigana before entering some Japanese text for which you don’t want furigana added, you can now undo the furigana markup with Ctrl+Z (does not yet work with the fallback method).
For this, I changed the code to use the deprecated document.execCommand("insertText", false, markup)
. It seems that it is still supported in all browsers and is also used by Discourse itself to make its own text manipulations undoable (e.g. clicking the italics button).
Please let me know if something doesn’t work.
Link to previous script version for downgrading in case version 1.8 doesn’t work for you
@MissDagger I don’t know why you sometimes get two F buttons. The console output makes me think that the userscript manager injected IME2Furigana twice for some reason. The new version now checks if the button is already there before adding it to hopefully avoid this problem.
Yeah, I was thinking it was something like that. Nice to be able to have the standard version now.
Even if I couldn’t figure out how to get the script to install automatically to Userscrips, so I guess I’ll probably have to manually update it. But that is a problem for me to solve, but I don’t care enough to figure out how to fix it because I only use Userscripts for this script. ^^
Click “Raw” button, to add to TamperMonkey
Modification of the original, but less extra features than version 1.7.
\u2060
), or Zero-width space (\u200b
).
<
for <結婚>[けっこん]
to HTML conversion, and after <ruby>
tag for from HTML conversion. [2]
it doesn’t really work…
the F doesn’t appear.
Tried all the steps…
since you are also using Tampermonkey on Safari, I am afraid this is the same problem that @MissDagger had last year. We spent a long time debugging, but in the end it turned out that the Safari-Version of Tampermonkey does not manage to inject the script appropriately on the forum:
I think the Userscripts extension works (at least it did last year).
aw what a shame
I’ll try your user scripts extension
It’s not mine – it’s just an alternative to Tampermonkey
Do you know why I can’t get this triangle to go away
You need to allow the extension for each page (or all pages if you don’t mind it), and even after allowing it, it sometimes didn’t want to acknowledge that I’d allowed it until I restarted Safari. Userscripts is a tiny bit more finicky to get it to work on a page, but once it accepts your allowance of it working, I had no more trouble with it.
After tinkering around with userscripts, I got it it in the end, but it’s actually an F with a grey box?
When it’s activated, the button has a gray background. You can click the button to cycle through the three available modes.
thank you so much for helping me!
If you ever update this script in the future, please consider adding an option to position the furigana below the kanji.
Today I discovered this is WAY easier than I expected: one line of CSS with astonishingly good cross-browser support!
In this case you would just need to add an inline style to the ruby conversion:
<ruby style="ruby-position: under;">
<rb>日本語</rb>
<rp>(</rp><rt>にほんご</rt><rp>)</rp>
</ruby>
It doesn’t work in Discourse, because style attributes get sanitized. (Similar to how you can’t put in colored text other than using LaTeX )
Injecting CSS via Userscript or Userstyles is possible, however.
Darn. Good catch.
A user style sheet makes it a reader’s preference rather than the author’s preference, which is better. Unfortunately it also requires every user that wants it to install stylus or whatever.