[Userscript] WaniKani Lock Script

[doncr]

The WaniKani Lock Script

Purpose

The purpose of this user script is to allow users to lock a set number of reviews so that they don’t appear in their review sessions. This is to allow people to reduce the review queue size down to something they can manage at any particular time.

Whether you’ve been whisked away back into real life or you’ve toked too much from the lesson pipe, it’s no fun at all coming back to a review queue that you just can’t manage!

Where to get it

It’s on Greasy Fork: WaniKani Lock Script.

Screens

To use the script, follow the instructions on the reviews summary page once you have installed the script.

Method

As a user, all you specify is how many reviews are to be locked.

The method is actually very simple: The script maintains a list of all the active reviews you have and sorts them in order of when they entered your review queue. The script then locks the earliest reviews in the queue.

Consider a review queue with 1000 items and you’ve been away from WK for quite some time. Oh dear.

If you’ve only got the time and energy for, say, 100 reviews a day then you’ve got a problem. Every time you get a review wrong, there’s only a 10% or so chance that it will appear when it’s next up for review. This amounts to a lot of wasted effort if you try and clear the queue this way because you won’t see an Apprentice item again until way after the ideal SRS interval.

With the lock script, you would lock 900 items and then your reviews will always be for the remaining 100 items plus any new additions to the queue since they will always re-enter the review queue at later point compared to the locked items. This allows you to get comfortable with reviews to the point where you’re scoring well before you choose to expand further into the locked reviews.

Great, but what if real life rears its ugly head again and you’ve got less time again?

You simply lock more items until your review queue is manageable again. Let’s say we increase the lock count to 950 this time. The set of active items is now a subset of the 100 items you were already working on just before and so you don’t have to start any of the items in that subset from cold.

Once real life is less of a problem again, just go back to the previous setting and you’ll pick up from where you left off. If we go back to 900 locked items then your reviews will include the 50 most recent items and also the other 50 you were working on. The original 900 locked items were locked away all this time and so your effort was not wasted on them.

You only need to set the level to how much you can handle at any particular time and it will keep wasted effort to a minimum.

Why not remember the actual list of locked items internally?

Using this sorting method, you only need to maintain a single number (the number of locked items) between devices if you frequently use multiple devices with WK. Also, if you regularly clear your browser data then you only need to supply the locked item count afterwards (and your API key) and everything is back to where it was.

What if I don’t like the script and uninstall it?

Nothing bad will happen. Your full review queue will appear again. The script doesn’t change anything on server.

Testing

I’ve tested this on the following browsers:

• Firefox
• Edge (Chromium-based)

Significant updates

Version	Date	Description
1.0.0	2021-11-11	Updated to use upcoming change to WK review queue data

[foozlesprite]

Is this still planned or was it scrapped due to bugs? No worries either way, just curious since I have a backlog and it’s a bit of an uphill battle right now.

[doncr]

No, it wasn’t scrapped due to bugs. Real life got in the way!

I’ve prepared an early release version here:

https://gist.githubusercontent.com/wkdonc/182aba21f4b8547cc136a1cabb75631e/raw/c36472ea2006b953bc1f654505bfdc2eecc8dbde/lockscript0.0.1.js

WARNING: It’s not very polished in terms of user experience at the moment but it does work.

Instructions

1. Go to WaniKani — Log in
2. Enter your API V2 key
3. Click “Set API key”
4. Set the number of items you want to lock
5. Click “Save options”
6. Start your reviews

You shouldn’t have to click the “Reload cache” button.

When you want to change the number of items to lock, redo the above from step 3.

Note: I wrote and tested this in Firefox. I’ve not tried Chrome and I ran into caching issues with the WK API V2 with Edge.

[foozlesprite]

This is great! I’ve been testing it on Chrome and it appears to work. I don’t see the lock icon+number when I’m actually in the review section (which is where I think it’s showing in your picture above). This is a non-issue since I see it on the screen before I start reviews, but I thought I would bring it up in case it’s a browser-specific thing rather than something you changed on purpose.

Remarkably only one of my installed scripts broke it, and it’s not the one I would have expected. It’s the “Similar Kanji” script that injects a list of similar kanji into the review page to help you disambiguate. I’m more than happy to turn that off to get my queue down though, and it’s not anybody’s obligation to troubleshoot/change scripts to work with each other.

Things it did work with include the Override button, Jitai (randomizes fonts), Reorder Ultimate II, Keisei Phonetic-Semantic Composition, and Community Mnemonics. The Ultimate Timeline still shows the full amount of reviews, but I’d completely expect that given the nature of this script. Real Numbers shows 250 right now, which I’m locked at, but will show more when I get more reviews. All I have to do to see how many reviews I really have is subtract 250.

As an aside, I think you’re the first script I’ve seen that calls for the 2.0 key. Right on the bleeding edge of technology Thank you so much! And I’m wiling to test/check anything you need me to.

[doncr]

Thanks for the report!

I’ll check it with Chrome later this week. I’m in conference mode at the moment (which is exactly the sort of thing which sends me into needing this sort of script… )

[acm2010]

@foozlesprite What happens when you use the similar kanji script? Can you look at the error message in de developer console?

That script and Keisei share many parts, I don’t know what could break something when Keisei still works …

[foozlesprite]

That’s what I was thinking too. Why that script of all things, haha. What it’s doing is showing the full amount of reviews in the corner rather than the reduced amount I actually need to do. The similar kanji will show, but the lock script doesn’t work.

It’s showing me this:

rather than this:

and letting me do more reviews than what it takes to get me to my locked number.

Oddly there are no errors showing:

The two scripts it shows there are Override and Real Numbers, neither of which are error messages.

Another batch is about to hit so I’ll test some more with both scripts on.

[acm2010]

Not sure what is happening, the only reason I can imagine is that I had to modify the “related vocabulary” page because WK uses a ridiculously strong selector (I think three nested ids or something) and I needed to override the style, I wrapped it (div#supplement-kan-related-vocabulary) in something additional. Maybe @doncr can tell what it means, it seems the lock script is stopped by mine without error.

[foozlesprite]

It’s not too much of an issue for me since I can just turn the similar kanji script back on when I’m caught up, but if it ends up being an easy fix it’d be neat to have done. That being said, this script is very early in alpha, so I expect this is low priority compared to standalone bugtesting and UI fixes.

[doncr]

OK - back in action!

I just installed The Similar Kanji script on Chrome and I can reproduce the issue, which is a good start…

[doncr]

@acm2010

Not sure what is happening, the only reason I can imagine is that I had to modify the “related vocabulary” page because WK uses a ridiculously strong selector (I think three nested ids or something) and I needed to override the style, I wrapped it (div#supplement-kan-related-vocabulary) in something additional. Maybe @doncr can tell what it means, it seems the lock script is stopped by mine without error.

So that was an odd one.

I modify the XHR object in my script by monkey-patching the responseText property. I figured it was the easiest way to rewrite the data from WK. (Yes, reel back in horror if you will!)

I can only think that the method I used (now rewritten) had conflicted with GM_getResourceText in some exotic way.

Anyway, I’ve improved it now and it works with your script!

@foozlesprite - I’ve edited the top post with the URL for WK Lock Script 0.0.2. It should work without conflict now.

[foozlesprite]

Confirmed working. I haven’t seen any other issues so far. I’ll let you know if I see any more.

And as an aside this is proving the most helpful script I have to help get me back on track. I have several others that help in smaller ways but this takes the cake. I can do my reviews for the day then step back and say “whew, I’m done, I don’t have to do these other 200 for now.” It makes things much less daunting and lets the SRS process work on the ones that are unlocked, so I memorize them and clear them faster. A++ in concept and execution thus far.

[doncr]

How’s it going?

[foozlesprite]

Everything’s going well, no more problems!

[doncr]

I’ve just uploaded a big update to this script to add a proper user interface to replace the temporary one. In terms of testing, I’ve been using this myself for the last three years and it has been very stable during that time.

I now consider this release worthy and no longer beta.

Anyone that was using it already should be able to upgrade without any issues.

[kimera]

Beautiful! I’ve been using level sorting scripts to work on my reviews in smaller batches but this is much better!

[kimera]

Hey this is kinda weird but after I finish all my unlocked items, the script still thinks there are 9 in queue…

But they don’t exist! When I try to start another session it just goes back to the review summary page.

And turning off the script you can see there are only 150 items:

It must be a mistake in how it stores the total number because I can also tweak it like this (although that doesn’t do anything):

On a Mac, using Chrome and Tampermonkey, with no other userscripts turned on. Lemme know if you need other details or if you’d like me to test anything out. Thanks!

PS, everything seems to work fine, it’s just that extra number floating around.

[doncr]

Weird - I’m seeing expected behaviour on Windows 10 / Google Chrome / Tampermonkey however I did see that behaviour years ago and it turned out that browser <-> WK API caching was at fault.

If you’re familiar with Chrome devtools could you check the response headers to the “assignments” API call?

Basic instructions: Press F12 to open the devtools first so that network traffic is captured. Do one review and then when it returns you to the reviews summary page then click on the orange bits below:

[kimera]

Okay, here’s what I got. (BTW I just realized I’m using a read-only API token that I already had, not a brand new one. Do you think something changed in the meantime?)

{object: "collection",…}
data: [{id: 10775793, object: "assignment", url: "https://api.wanikani.com/v2/assignments/10775793",…}]
0: {id: 10775793, object: "assignment", url: "https://api.wanikani.com/v2/assignments/10775793",…}
data: {created_at: "2013-10-26T23:22:35.698954Z", subject_id: 3027, subject_type: "vocabulary", srs_stage: 2,…}
available_at: "2021-07-17T05:00:00.000000Z"
burned_at: null
created_at: "2013-10-26T23:22:35.698954Z"
hidden: false
passed_at: "2013-10-30T09:00:00.000000Z"
resurrected_at: null
srs_stage: 2
started_at: "2013-10-26T23:22:35.698954Z"
subject_id: 3027
subject_type: "vocabulary"
unlocked_at: "2013-10-26T23:22:35.698954Z"
data_updated_at: "2021-07-16T21:05:06.411994Z"
id: 10775793
object: "assignment"
url: "https://api.wanikani.com/v2/assignments/10775793"
data_updated_at: "2021-07-16T21:05:06.411994Z"
object: "collection"
pages: {per_page: 500, next_url: null, previous_url: null}
next_url: null
per_page: 500
previous_url: null
total_count: 1
url: "https://api.wanikani.com/v2/assignments?updated_after=2021-07-16T06%3A47%3A45.675786Z"

[doncr]

Did this problem persist? I wasn’t able to reproduce it on Firefox / Edge on Windows.

Using a read-only token is fine. It only reads one collection type (assignments) so it should either work with the API or fail completely.