@Sinyaven same question, different background: any chance you could add a method to get the current queue? I’m asking because I have a script which displays information about the queue, but doesn’t actually need to alter it. Of course I could just read the script tag myself, but would be nice to do it through wkQueue (especially if I could get it with wkof data already) 
1 Like
I have added wkQueue.currentReviewQueue({openFramework: true, subject: true}) and wkQueue.currentLessonQueue({openFramework: true, subject: true}) – they return promises which resolve to the current queue (or to null when calling currentLessonQueue() while still on the WaniKani default lesson order).
@require https://greasyfork.org/scripts/462049-wanikani-queue-manipulator/code/WaniKani%20Queue%20Manipulator.user.js?version=1166906
@seanblue In case you are using Queue Manipulator in your script, please also update the @required version number.
1 Like
I’m noting some visual glitches.
- A black outline now appears around the input box when it’s in focus (and looks pretty ugly.)
- For some reason the green in the “level up” popup is a slightly different green than the one in the main input (which also looks pretty rough - the colors are just similar enough to make it just look like a mistake, even if intentional)
Unselected (normal)
Selected (weird additional border)
Green of the “new level” popup:
Green of the input after correct answer:
7 Likes
I can’t begin to express how much that black border bugs me. And yes, the new green color is not a great match with the rest of the color palette, but I can live it that. That black border though…It’s like nails on a chalkboard.
13 Likes
Hello fellow humans.
I did not realize this thread existed before now, which is probably a mistake on my part.
Regardless, I maintain a wk plugin [Userscript] Wanikani Katakana For Onyomi - #35 by Harald1 which does not work so well any more.
This script essentially does two things:
1: For every kanji reading on wanikani, try to figure out if it is an on’yomi, and if so replace the hiragana with katakana in the reading.
2: If the current quiz item is a kanji reading, and the reading wk will accept is on’yomi, make the user input caps and therefore katakana by default and make wk accept katakana in the answer.
Previously I have used jstorage to figure out if the reading wk wants in on’yomi, and I don’t know what to replace it with.
I have also used MutationObserver combined with page urls on load to figure out if content is being dynamically altered, but this has never worked well and seems really hard to do for single page stuff.
I’m not much of a js/web developer, so if anyone has any tips or suggestions for how to best implement this script going forward, I’d greatly appreciate it.
6 Likes
I think you could listen to the events that fire when the subject changes and interrogate the subject data. For a Kanji you can look at the primary_reading_type key to deduce whether the expected reading is a Onyomi.
The events are listed up in post 28.
4 Likes
@Sinyaven Would it make sense to add some time of bundle update function to your script? In Lesson Filter I need to filter the queue and change the batch size. Having that update the queue / UI twice instead of once isn’t a great user experience. Please correct me if that’s not how it would work, as I haven’t tested it yet.
@tofugu-scott Any response to this? Really hoping I’m just overlooking a better API endpoint…
I just had a quick look at what your user script actually does and I am not sure what you want to do is possible without significant effort on your behalf (or even at all). If you loosen your requirement so you don’t have to match the Wanikani lesson order then I think @Sinyaven steered you in a better direction with the suggestion to use the summary endpoint.
Sorry I know it is probably not the answer you want. My suggestion is to let your users know of this limitation and to have them request the feature be made native. Then it can be evaluated along with all the other changes we have planned for the future.
1 Like
Thanks for confirming. As you said, I guess I’ll have to loosen my requirements for now, but I see that as a pretty big loss of functionality. Honoring the user setting for the lesson order was a core component of the script.
Also, it seems like the lack of a lessons API endpoint is a pretty big oversight. If I want to request a new lessons endpoint that simply returns (at a minimum) the IDs and types of available lessons sorted based on the user setting, should I send an email for that?
2 Likes
Yes you can do, but keep in mind you maybe the only person to request this. From my point of view, this adds a code maintenance path which must be keep up to date whenever we want to make changes to lesson ordering, so I would not be in favour of it. I would much rather see that this is supported natively over an API if this was a feature that we agreed internally was beneficial to a significant portion of the user base.
1 Like
Yes, but the userscript has like 6k installs. He’d be the only one requesting it, but a lot of people benefit from it.
10 Likes
Perhaps you could poll it here? I know that anecdotally, the lesson filter script is probably the only reason I made it this far with WaniKani (I use it the same way seanblue did, which was to distribute kanji lessons throughout the level instead of doing them in huge clumps), and I have suggested the same strategy to other users probably dozens of times on this forum, and most people who try it seem to end up much happier using WK that way.
I think a substantial number of people would appreciate that script’s functionality being natively supported. If you’re worried about users neglecting their vocab lessons, you could always add in safeguards that prevent users from using the feature to only do the kanji lessons and level up with a backlog of old vocab from multiple levels back.
11 Likes
I think a cool way to do this would be to replace the ‘batch size’ option with a ‘number of kanji per batch’ option. Seeing as there’s roughly 3 times as much vocab on here as kanji, picking say 3 kanji per batch should give you 3 kanji and 9 vocab. Of course there’s also radicals which complicates things but I’m sure there’s a solution
Why would you do this? Please bring it back immediately.
1 Like
I’ve said for a while that they should add a second condition for leveling up. Currently you need to Guru 90% of kanji on level X to reach level X + 1. I suggest needing to Guru 90% of kanji on level X and 90% of vocab on level X - 1 to reach level X + 1. That way a user can never be more than one level behind on vocab no matter how much reordering they do.
8 Likes
Why was this rolled out without any warning to regular users, let alone A/B testing, a beta period, etc? And why was it rolled out without addressing any of the feedback about the summary screen that you got even from just the few people who happened to see this thread in advance? Now you have 100x as many angry customers telling you the same thing. This seems like a terrible development practice.
1 Like
Sorry I wasn’t trying to deminish how useful people find @seanblue’s script. I just wanted to give an alternative perspective. The decision to implement a new endpoint is by no means free from future technical debt and we have to keep this in check.
That is not how we currently want to gather feedback. Sending considered feedback to hello@wanikani.com will ensure things get logged and responded to consistently and correctly.
Thanks for your feedback. This post is more about trying to help script authors so I am trying to keep the discussion on topic. I hope you understand.
I realize, I might have accidentally sounded a bit harsh, didn’t mean to, I’m actually pleased with the work you put in.
2 Likes
Yes, that or something similar seems like a necessary addition if they ever do allow reordering in the official UI.
Personally, I never bothered with lesson reordering, but I’m understanding better why people like it. I slowed down or stopped lessons early on every level when it was all kanji, then sped up again after making it through.