I don’t know if it is documented anywhere. I just discovered it by chance a few days ago.
By … chance?!
Back in the olden times before cellphones, my grandmother was known to occasionally put the telephone to her ear on the off chance someone was calling. ![]()
I wonder what other useful little Easter eggs remain to be found.
On a silly (or perhaps not so silly) note, i’ve now twice clicked on the first link in the first post, thinking it would be the link to Burn Progress, but it’s actually a different script. Maybe you shouldn’t hide the installation link to your script further down in a collapsible point.
I could also read before I click, but, you know… ![]()
Thanks for pointing this out. Not silly at all!
I’ve now made the first link in the post a link to the greasyfork repository.
I’ve just posted version 1.2.
Changes:
Removes the 12px of padding on the left and right (a mistake I just noticed). It’s subtle, but the bar is now as wide as the rest of the page.
Added an update and Download URL from my github repository. You’ll have to update to version 1.2 manually by browsing to the greasyfork repository for burn progress, but once on v1.2 you should be able to check for updates and update using tampermonkey itself.
Added an MIT license (the least restrictive software license I’m aware of).
Just to let you know: Tampermonkey by default uses the URL from where a script was installed as its downloadURL, so the auto-update already worked. Furthermore, Greasy Fork removes these directives anyway. So everyone who downloads your script from Greasy Fork will continue to get updates from Greasy Fork and not automatically switch to your github.
I don’t know much about licenses and legal stuff, but I recently also decided to add licenses to my userscripts. After some search, I decided to use MIT-0, which is the MIT license without the attribution requirement.
Thanks for the explanation! The Greasy Fork behavior makes sense (and I see now that it did strip those lines).
As long as people can get updates, I’m cool.
I’ll continue to make my edits locally with git for revision control (pushing to github). I do consider the version in github canonical, but since Greasy Fork provides install/update functionality for tampermonkey scripts, I’ll continue to manually update the version there if there are any further changes.
Well, you just demonstrated you know more than me. Admittedly, a very low bar. I’ll use MIT-0 as well for any further scripts I might create. I don’t care about attribution. I just wanted the no-guarantees, don’t-sue-me-if-it-blows-up bits. ![]()
Would it be possible to add a setting so you can choose whether this goes at the top or the bottom?
I think I’m rolling with a personal preference of forward-looking stuff like Ultimate Timeline and your Ganbarometer going at the top and progress breakdown stuff like this, Progress Percentages and Heatmap going down below - it would be great to have that option here. For now I’ve edited my copy to $('.srs-progress').append(burnsBar) (adapted from In Kumirei’s Wanikani: Progress Percentages - Source code) to add it to the progress section, but having it as a setting would be helpful if you have time!
I’ll add settings/customization the next time I work on the script, but it may be a while. Editing the script is the simplest solution for the moment.
Perfect, thanks! Do you know if Tampermonkey automatically updates even if you’ve made edits?
You may want to change the name and version of your modified version to prevent it from getting stomped on if I push an update, but yes tampermonkey always uses the edits you’ve made on the next refresh.
[Maybe I misunderstood your question. Tampermonkey will wipe out your edits if I publish with a newer version number. But it hurts nothing to just create your own version with a slightly different name.]
I’d prefer to receive the update so I keep up with any other changes you make to it, so I’ll leave it for now and see what happens!
Okay. I’ll post to this thread if I push a new version to give you a heads up. Will be a while though! Your edit should be safe until then.
Just pushed an update to this very simple script.
Changes in version 1.3:
-
Adds a small amount of top margin UNLESS it’s the first element on your dashboard.
-
Adds support for a super-sekret upcoming color theming system.
EDIT:
Sorry – I totally forgot about the request for positioning where this gets inserted.
I’ll try to get to that in v1.4 one of these days. In v1.3 it still inserts immediately before the .progress-and-forecast section (meaning it will be at the top of your screen unless you have other user scripts installed).
Lot of competition up there…
![]()
Honestly, where it shows up for me by default is actually fine; I just wish I could move Progress Percentages to the top, haha. But I think positioning customization for these types of scripts is a great idea, so thank you for considering it!
I’ve been doing a LOT of work with CSS lately. My styling chops are slowly getting better.
It’s a bit barbaric, and stupid brittle (dependent on WK and script-writer’s code not changing) but I’ve got some crazy ideas brewing re: positioning/ordering.
I just had my first 晩酌[1] though, so my idea might not be feasible. Will see.
Edit:
Nope. Dry hole (my crazy idea was just crazy enough to be … stupid).
It’s reasonably straightforward to add something to position it before or after any existing section, but writing settings dialogs is kind of a PITA.
-
newly learned vocabulary ↩︎
I just made a modest change to this script (current version: 1.4).
It’s rarely a good idea to make users do math in their head, so it now shows your “working set” size (the number of items under active review) explicitly:
This isn’t new information, it’s simply subtracting the number of burned from the number seen for you.
Hope this change doesn’t bother anyone, but I think it’s worthwhile to know how many items you’re actively reviewing.
Does this script not work anymore? I can’t see it running on WK site
It seems like it broke in the recent scriptpocalypse.
However, since the dashboard was almost unchanged, the fix is easy in this case.
Simply replace the line
// @match https://*.wanikani.com/dashboard
with
// @match https://www.wanikani.com
disclaimer: I have never written any sort of userscript and while this fixes the obvious problem, there may or may not be more problems/a better fix.
Sorry - I did this to my own copy and didn’t realize I never pushed the update to everyone.

