I always have reordering on, so this extension is unusable for me until it works with it.
1 Like
Ok, I don’t plan on working on wk api integration for a bit, because it’s a large chunk of work, and I would like to have the basic srs features done before that, so version control for decks and stuff.
1 Like
I made it so decks can be updated. This happens if you import a deck, and it has an id/name either baked in or given by you that matches an already existing deck. There’s also a prompt asking if you want to update, create a clone or stop the import process.
Bit of a technical topic from here on out.
This is another thing off my list. The next thing I want to work on is a revamp of the related system. Right now, if a kanji is made up of certain radicals, it will be stored as a bunch of ids, that are the ids of those radicals. This is exactly how I want it, this should stay. だけど, I can’t just straight up use these ids elsewhere, since if user A exports their deck, user B might already have these ids used up, so it would be a total clusterf***. So I opted to instead identify the exported items by their character. This choice has literally nothing, but disadvantages. It’s slow, because to map the ids back, you need to look a lot of stuff up from the database. Of course this is slow as hell. Also, if the character is changed, there’s absolutely no way to know about it, so you’re going to lose your srs progress on it when updating. And probably the worst of them all. If I want to connect a kanji to its radicals when importing, the only way I can do it is by first running through the data to generate ids for everything, then running through the data again to match up the related items.
So what’s my plan? I want to split the responsibilities of the id up into a wk id and a deck id. Wk id is the original one, it’s unique among all of the items (and wk for that matter), this should be simple. The deck id however would be deck local. This would be what gets exported and checked against. With no way to change it, updates would be possible and there would only need to be one run though done when connecting related items.
I also have been planning the rule, that a deck needs to contain everything that any of its items point to. Need a kanji for a vocab item? It better be in the deck, otherwise it’s not happening. This would be aided by a link system that basically links an item from a different deck into another one to avoid duplicates. This actually makes a lot of sense, since when exporting a deck, everything needs to be exported that’s being used in that deck.
2 Likes
Just updated the extension and it’s looking great! Having the hover explanations for all the fields is really useful, and it’s overall looking much more polished.
A quick question though - do you have any plans to add the ability to export as either a CSV, TXT, or JSON rather than just a DECK file? Because it looks like the deck files are encoded somehow, making their use cases quite limited.
But apart from that it’s looking amazing, thanks for your work on this!
Just need kana-only items now, and then WICS will have pretty much all the essentials 
Also some kind of sync options I guess but that’s less important, at least imo
1 Like
Thanks for telling me that 1.9 is out. That was a lot further from the heat death of the universe than I originally estimated.
I use the age old trick of taking a stupid file format and just pushing it through a zip compressor. If you unzip it, it’s a json inside. Eventually there probably will be something to export in different formats, but it’s definitely not a priority right now.
Heh, you think, I still need a few things to call it v1.0. The current roadmap is the id rewrite thingy mentioned above, then I want to make item dependencies work, after that wkapi integration, then kana only items and that will be v1 most likely.
Sync will come after v1, mainly because if I were to attempt to use the chrome sync option, 1. it wouldn’t work with chromium, 2. I estimate I could save maybe about 50 or so items in it. So it might be, that once I set up a website for deck sharing, its actual first raison d’être will be sync storage.
2 Likes
Ah - I should have thought of that. In that case like you say it’s very much not a priority right now - especially if maybe at some point you were to add a hover tip or something with the export mentioning that it’s a zipped json for those who don’t realize 
Makes sense! Thanks for sharing your roadmap, it’s nice to get a general idea of when (in relation to each other) you might be adding features!
I don’t think it’s much more useful that way. It’s still in pretty much a custom json format, I didn’t take any existing standards into account.
1 Like
The id rewrite is mostly done, I just have to figure out a way to deal with old data, where this field isn’t present and the related items have global ids assigned to them. Probably doable by tonight, not sure how much time I’ll have.
This whole id thing also includes a few new features. First and foremost, now it’s mandatory to have all related items in that deck. To make this less of a pain, if the item exists somewhere in your decks, it will prompt you if you want to make an inactive copy in that deck. Inactive copies don’t come up as lessons or reviews and don’t count towards your progress, they are there so they can be referenced. Activeness is also a trait that doesn’t get exported, so if you share your deck full of inactive items, it will still be active for the recipients.
Now if you create a new item, and specify another one as a related item, it will autopopulate the corresponding field of that other item. So if you are adding a new kanji, and you put in one of your radicals as its component, it will then go ahead and mark the kanji as a related item on that radical. It also removes this, if you delete an item others were related to. This behaviour doesn’t apply to editing already existing items because I’m lazy because I wanted to make one-way relationships possible. so an item might have a radical listed as a component, but for some ungodly reason, the reverse isn’t true somehow.
3 Likes
The import .csv feature is great - thank you so much for adding it!
However I’m having some trouble as after a long load time, no new lessons or reviews based on the deck contents actually appear on the site. Trouble is likely to exist between chair and keyboard (笑）, so please let me know if I am missing something obvious to start actually using the deck.
（Incidentally, somehow my level dropped from level 60 on the forums to 59. Bizarre!)
Is there an error in the console? (You can open it up with Ctrl + Shift + I, when you’re in the lessons/reviews page)
I’ve been lurking this thread for a while and I have to say I’m impressed with your pace!
I’m holding off from installing for now, but after kana-only gets added, or most likely after v1.0 milestone (as you mention it) I surely will. Looks like addon I’ll definitely use since I’d love to do more consolidated learning in one place and WK basic structure is admittedly neat.
Script devs are doing so much great work 
2 Likes
Thank you for checking into this. I’m not the savviest with the console, so please let me know if you are looking for info I neglected to provide.
1 Like
The too many request one will be it most likely on the second image. I seem to be overloading the wanikani API. I’ll need to check why this is happening there. Thank you. I assume we’re dealing with the n1 deck from earlier, right?
Yeah, that’s what I expect for most people. I only recommend the current version to those that are willing to have a few bugs. I have an ETA of about a week on the 1.0 version. Depends a lot on how much testing I want to do before I declare the extension good enough and go on to version 1
3 Likes
Brave Browser on Windows 11 + WICS compiled from Github.
Then, the Errors button.
Since there is a visible error, hopefully it can be fixed?
1 Like
Yes, I imported the N1 deck from earlier. Thank you again!
1 Like
Ah, is this master? It might be that I didn’t have everything saved when I pushed to github, I wasn’t sure, but seems like it. I’ll push a new commit with the dependency chain in it soon. You can also try to delete your deck if it doesn’t have much data within, or if it was an import
Yeah, master and not forked. git clean -xdf && git pull && npm i && npm run build. My deck is an Anki import, and no review has been done. Former git clones’ can’t do review either.
Is it possible to use WICS to integrate KaniWani into WaniKani?
Right now it’s not, maybe in the future. Currently only wanikani-like items are allowed, so japanese->english.
1 Like
Finally got around to adding a dependency system. This is how it works:
Each item has a set of items that make it up, so for kanji this is the radicals it has and for vocab the kanji it has. Each item is also assigned a level from 1 to however much the deck’s author want to put in. The simplest decks only have one level with all the items dumped into that, while theoretically a 1000+ items could be sorted across 100 levels, both are valid options.
Each deck stores the level you’re currently on in it. This could be anywhere from 1 to however much the highest level item has.
From then on the equation is pretty much like the wanikani version. If you want to unlock an item, you need to complete all the related items it has. If you want to complete a level, that means passing 90% of the kanji on that level (around the same as on wanikani). Only items from the same or previous levels will be unlocked.
For now this is the only lesson lock, I want to extend this in the future with an option for those that prefer an anki style of taking x items a day instead and want to mostly ignore the levels and dependencies.
Locked items aren’t yet shown in the progress chart. I need to work that out too, but I might need to cache this dependency state on the items themselves, otherwise opening up the deck view would need to load in all wanikani items, which is around half a second or so, but we’ll see.
Also, right now if an item has an original wk dependency, it will consider that as well, when checking if there are unresolved dependencies. I want to make this an option as well, so people don’t need to wait for level 60 before they can practice 漣音.
@polv I pushed a new version to master, I tested it and it should be working with reviews. I’d be thankful if you could test it and see if it works once you have some time
3 Likes