Oh neat, I’ll have to check that out eventually then, would be nice to support most major formats.
[Extension] WICS - WaniKani Integrated Custom SRS - Now with deck exports!
I always have reordering on, so this extension is unusable for me until it works with it.
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.
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.
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
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.
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.
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.
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
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.
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
Brave Browser on Windows 11 + WICS compiled from Github.
Then, the Errors button.
Since there is a visible error, hopefully it can be fixed?
Yes, I imported the N1 deck from earlier. Thank you again!
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.