Oh yeah, I’d forgotten the radical questions are already only one meaning question per item. The blue would ideally be changed to the vocab green, but that’s also not essential if it getting into that CSS would make it much more difficult to implement for whatever reason!
Like you say, for now normal vocab reviews will work, simply that the asking for a reading will be slightly annoying, so it would be amazing if you could maybe take a look at it at some point!
Is there a reason why this needs to be two separate fields?
For a human it would be pretty easy to extract the kanji that make up a word from the characters that make up a word, just throw away all the non-kanji.
Can you not do that based on their unicode values?
Yes, I can, and I will, once I start auto-populating these, but for now I didn’t bother, because it’s not used at all.
I’m keeping them separate fields, because this will be what later on the dependencies will be based on (so what kanji you need to learn in order to unlock this lesson), and there are real scenarios, when you want to change this. For example if there’s a kanji you really don’t want to add for some reason, but it’s in the word, you could remove it as a dependency and it wouldn’t need to be studies anymore. Or a word has several different ways of writing it, and you decide to keep the most common as the actual word, but also mention the other possibilities, in that case it might be beneficial to list the other kanji as prerequirements. It’s all about freedom really, most fields hopefully will be automatically filled out once I get to that step, but it’s always nice if you’re able to modify them
For kana-only words, aren’t there extensions that automatically pass things? Maybe you could use something similar to what they do to skip the reading part?
Is there any workaround, or will we have to wait until the next version?
Sadly I don’t think there’s a good workaround, I’ll try to fix that issue and push the fix as quick as possible
Can you show an example of how these CSV files look like? I’m curious what I can expect
This goes for anyone btw, that wants to import csv files
I tried adding 相 as a vocab item, but then the kanji field disappears after saving.
Yeah, it’s not used for now. Mainly because I need to load in the wanikani items, and that takes an apikey, etc etc.
Just don’t bother with it.
Maybe you (Gorbit) could mark the reading as correct in jstorage if there’s no provided reading?
So awesome! Is there any possibility of adding in the kana pronunciations in the future, in case of any irregular readings?
I’m not sure I fully understand what you asking. Is it future in the sense, that after importing, can you then modify the pronunciations, or can I put in a way of adding something? Tbh, in the latter case I have several more questions, so a generic explanation would be nice.
Something like that, most likely, though I don’t know the code of the progress submissions well enough yet, to know what would need to be done exactly. I’ll figure something out.
Way back when I wanted to have sentence reviews as well, so you have a whole sentence with a word in it you need to input, instead of just the word. Would be useful in my opinion. But definitely not today
I think I got export and import into a state I’m satisfied with for a first draft.
For reference, this is how the import dialog looks like, which I’m proud of:
Also, finally managed to face my fears and make related items work. This means the extension now requires an api key (a free one works as well).
Fetching all items from the api is a long procedure, especially for the first time, when chrome is trying to figure out what the hell you’re trying to do. It takes about 10 seconds, and of course, this isn’t good UX, if the user has to wait 10 seconds between operations, and even the WK team says, that items should be cached aggressively.
So first I tried to put this whole thing into extension local storage. Now, did you know, that storing all items like that is 18 megabytes, out of the 5 you can use? So now I need unlimitedStorage perms as well. That’s fine.
Bigger issue, serializing and deserializing 18 megabytes worth of JSON is also a long operation (not 10 seconds, but more like 5). Waiting 5 seconds between operations is a much better UX, still not very ideal. So I wanted to do something about it.
As a first idea, I wanted to store the items loaded up somewhere. My popup script dies the second the popup closes, my review script lives just as long as the page it is on, my popup scripts were killed alongside my popup. So my choice was a background script (which is funny, because basically every version I think I need a popup script, then it turns out its entirely useless and I delete it). So I created my cache system there, it worked well, the access times went down to 0.5 seconds or so, which is bearable. However, turns out, since Manifest V3, even the background scripts die after a few seconds. This was an issue, the debugging of which I don’t wish on my worst enemies even.
So the background script went the way of the dodo again. And I needed a new method. The main issue is, that parsing 18 megabytes of JSON is hell. So next idea: let’s not do that. Instead I break up the item cache into chunk of 500 items, making them about 1 megabytes in size. Because I can load them individually, and each item should generally take at most 10 or so related items, it’s highly likely I need to load the entire thing, and even then, chrome probably (hopefully) parallelizes. This lowered the cache time to a second usually, which is nice.
Next, when users are adding a bunch of items, though 1 second isn’t much, but it’s annoying, if you need to wait that 1 second a lot of times. So to solve that, I put in another level of cache, actually caching the caches in memory. When a cache instance is loaded and parsed, it gets saved in a volatile cache, so it doesn’t need to be parsed again. This cuts down the lookup times to unnoticable levels.
The current solution is quite nice, decks with 2000 items or so import in a few seconds. The least responsive part of the ui currently is loading deck from storage, but I might address that over time, caching that too, so it doesn’t need to be reparsed over and over again.
For now there’s no way to update a deck you’ve imported from a newer version, but I put in measure to make this possible. If all goes well, you’ll be able to publish a new version of a deck, and whoever has it installed will be able to just pull in the changes without having to reset.
I’ll publish this version (currently 0.1.7.1). There is currently one known limitation, that being, that linking to items not from wanikani inside an exported deck doesn’t work. In the future, I’ll probably disallow intermingling between decks, to make exporting it make actually sense. I’ll probably add item clones in, where you can have a deck contain an item, and another deck contain a clone that doesn’t get placed into lessons, but allows you to link to it.
Seems the chrome team didn’t accept my 0.1.5.1 submission yet, which of course means, that I can’t send in the 0.1.7.2 version yet. Fun.
I’ll send it out to firefox then for now
Edit
Aaaaand it’s literally accepted on firefox already, neat
Sorry, I was not clear. In the original screen shot I didn’t see a column to include the kana reading of the Japanese vocab or kanji word. Looking forward to trying out the importer!
Ah, I see, that is already an imported deck, I don’t show that information on that page, because it would take up even more space and I don’t think it’s necessary. It’s basically required to have a field for kana readings
Awesome! Thank you kindly
