Japanese comma should now work in reading fields (lmk if it gives you issues still)
Right arrow key will now submit and advance lessons
I’ve never used Yomichan so I’m not sure how it works, but I’ll take a look at some point in the next couple of weeks to see if there’s anything I can do there if I get the chance.
Dependencies will now correctly keep an item locked now - this was actually more difficult than I expected
Dependencies that are other custom items you’ve added to the pack will wait until you’re at Guru for that item.
WK items however are a bit more complicated: Firstly, for now at least only newly added WK dependencies will keep things locked - I might see if I can automate the fixing of this at some point but it’s surprisingly complicated to do this without hitting WK API rate limits if you have lots of dependencies - so for now you’d need to remove and re-add any dependencies you wanted to work for the locking. And, right now WK items will only lock by level and not by SRS level. So e.g. if your item has a dependency of level 50 then it will unlock once you get to level 50.
It looks like it is properly scanning for input, but the yomichan popup is being put behind the custom srs popupwindow. It also looks like scanning works everywhere except input fields, but that is hard to confirm with the popup being invisible. I don’t know if this is fixable, and it is probably not a very high priority regardless. Making the characters a bit bigger would also solve the issue for me. However font preferences seem to be a very touchy subject I learned recently from another thread here, and probably also dependent on you monitor resolution, so that might have to be some sort of setting.
Perfect. I had a few hours today and wanted to work on this script a bit!
From what you say it sounds like there’s very little chance I can fix the popup placement - they’re probably not using “dialog” elements for their popup (because it’s a very new feature) which complicates things a lot. I can however make an input/japanese font size setting for you - it should be fairly easy I think, at least for the inputs. It will likely take until next week though I’m afraid, I’m going to be quite busy for the next few days!
That would help. I appreciate any time you put in this, I can wait.
The comma splitting turned out to not work yet, so I took a look at that myself and it turns out that javascript regexes use /regex/ syntax, and the script is using “/regex/”, so instead of splitting on , or 、 the script is now specifically splitting on /,|、/ which is not ideal. I fixed it locally on my copy but I have not been able to test it yet.
I don’t think this was broken before, and I have no idea what changed.
edit:
I have looked into this a bit further, and the problem seems to be a number of null values in the internal datastructure used by the script. These were present in the debugger, but also in the export pack json. Specifically, when vocab items include a list of used kanji, the list of readings for these kanjis often includes null.
The script is adding all three reading types together in this field, but not every kanji has all three readings, and null values mess with the answer checker.
I think I have fixed it by replacing itemFromID.info.onyomi?.concat(itemFromID.info.kunyomi).concat(itemFromID.info.nanori) with itemFromID.info.onyomi?.concat(itemFromID.info.kunyomi).concat(itemFromID.info.nanori).filter(Boolean), which according to google is a good javascript way to filter null values out of an array, even though it looks fishy to me.
I have done little to no testing at this point though. I only checked if the exporter now worked with one test value, which it did.
I’ve had a quick look and the just-released update should stop the nulls being created (although I haven’t had time to test it yet!). Next weekend I’ll also get it to fix any items that already have the nulls automatically.
I’ll also get the Kanji alignment fixed at the weekend.
Thanks for letting me know about the issue and looking into it a bit for me!
The inspect item info button has stopped working during reviews. There is no exception in the log, so I don’t really know where to start looking this time.
Just pushed an update to fix this and a couple of other basic issues. Unfortunately the latest WK update broke a ton of stuff in ways I didn’t imagine possible so I’ll need to find time at some point to fix this up some more
I spend today trying to get at least some functionality working again. It now somewhat works like the other scripts, requiring a page reload after starting the reviews to work. I also fixed some data structure changes in the wanikani backend. I got stuck on trying to fix the view item information button. It looks like you previously intercepted fetch requests. These now go through the turbo framework. I manged to intercept one after a lot of trying, but the body is unintelligible gibberish to me, instead of a normal data structure. There also is still a problem with null values reappearing in the exported json. No idea if I did that or if that was already there. Maybe some of this can help fixing it further, so I will post it here. It is however a messy amalgamation of “maybe this will work”, so no promises.
changes
Inserted in front.
//It looked like the page was often already loaded by the time this script added the listener, so this small listener sets a flag if the pageload has already happened.
let loadAlreadyDone=false;
document.addEventListener("turbo:load", () => {
if (window.location.pathname.includes("/review")) {
loadAlreadyDone=true
}
});
/* Event listener debug code.
document.addEventListener("turbo:frame-load", () => {
console.log('captured a turbo frame load thingy');
});
document.addEventListener("turbo:before-frame-render", (e) => {
console.log('captured a before render event:',e);
});
document.addEventListener("turbo:click", (e) => {
console.log('captured a click event:',e);
});
*/
/* A coppy of the code I was trying to turn into turbo event listeners.
} else if (resource.includes("/subject_info/") && config && config.method === "GET" && resource.split("/").pop() < 0) {
// Submit original fetch but to different URL to get usable headers
args[0] = "https://www.wanikani.com/subject_info/1";
let response = await originalFetch(...args);
let subjectId = resource.split("/").pop();
let subjectInfo;
if(window.location.search.includes("conjugations")) subjectInfo = Conjugations.getSubjectInfo(subjectId);
else subjectInfo = activePackProfile.getSubjectInfo(subjectId);
return new Response(subjectInfo, {
status: response.status,
headers: response.headers
});*/
// Attempt at modifiying fetch request, intercepting reponse, and modifying that one as well.
// Aproach breaks at modifying reponse, as the response is some complicated stream object that is hard to interpret, and might not even be the correct response.
/*
let lastcapturedSubjectId;
document.addEventListener("turbo:before-fetch-request", (e) => {
e.preventDefault()
if(e.detail.fetchOptions.headers["Turbo-Frame"]=='subject_info' && e.details.method == "GET")
{
lastcapturedSubjectId = e.detail.url.href.split("/").pop();
e.detail.url.href = "https://www.wanikani.com/subject_info/1";
e.detail.pathname = "/subject_info/1";
}
e.detail.resume();
console.log('captured a before fetch event:',e);
});
document.addEventListener("turbo:before-fetch-response", async (e) => {
//e.preventDefault()
//e.detail.resume();
let response = e.detail.fetchResponse.response.clone().text();
await response;
console.log('captured a before fetch response event:',e);
console.log('json response:',response);
});
*/
The rest are changes to existing code.
getSRS(packID) {//TODO: add 1 here to array, because all instances so far have had a 1 here, and I dont know what it means. It is used to index into the SRS name array, which is an array of arrays of SRS names now for some reason.
return [Utils.cantorNumber(packID, this.id), parseInt(this.info.srs_lvl),1];
}
…
let alreadyExecuted=false;
//Doing this without waiting a bit first seems to break doublescheck for some reason.
await new Promise(r => setTimeout(r, 1000));
console.log('setting up custom srs listener');
// Add custom items to the quiz queue and update captured WK review
document.addEventListener("turbo:load", async () => {reviewEventListener();});
if(loadAlreadyDone) {reviewEventListener();}
…
// Add custom items to queue
if(activePackProfile.getNumActiveReviews() !== 0) {
// if url param is set to "custom" then set queue to only custom items
if(urlParams.has("custom")) {
queueElement = activePackProfile.getActiveReviews();
SRSElement = activePackProfile.getActiveReviewsSRS();
changedFirstItem = true;
} else {
switch(CustomSRSSettings.userSettings.itemQueueMode) {
case "weighted-start": {
let reviewsToAddW = activePackProfile.getActiveReviews();
let reviewsSRSToAddW = activePackProfile.getActiveReviewsSRS();
for(let i = 0; i < reviewsToAddW.length; i++) {
let pos = Math.floor(Math.random() * queueElement.length / 4);
if(pos === 0) changedFirstItem = true;
queueElement.splice(pos, 0, reviewsToAddW[i]);
SRSElement.subject_ids_with_srs_info.splice(pos, 0, reviewsSRSToAddW[i]);
}
break;
} case "random": {
let reviewsToAdd = activePackProfile.getActiveReviews();
let reviewsSRSToAdd = activePackProfile.getActiveReviewsSRS();
for(let i = 0; i < reviewsToAdd.length; i++) {
let pos = Math.floor(Math.random() * queueElement.length);
if(pos === 0) changedFirstItem = true;
queueElement.splice(pos, 0, reviewsToAdd[i]);
SRSElement.subject_ids_with_srs_info.splice(pos, 0, reviewsSRSToAdd[i]);
}
break;
} case "start":
changedFirstItem = true;
queueElement = activePackProfile.getActiveReviews().concat(queueElement);
SRSElement.subject_ids_with_srs_info = activePackProfile.getActiveReviewsSRS().concat(SRSElement.subject_ids_with_srs_info);
break;
}
}
}
Thanks for taking a look, I’m overloaded with unexpected work these next few weeks and so have zero time.
I’ll take a quick look now though. It’s so annoying lol, turbo seems to even ignore reloads occasionally… I’ll see what I can do!
Well, I’ve fought with it for a while. To be perfectly honest I have no idea why the fetch requests aren’t being caught properly sometimes. They go through Turbo initially but they still eventually have to do a standard fetch…
I’ve pushed an update (0.7.1) - Audio quiz seems to work without needing to manually reload the page (proper full load is being forced automatically), conjugations & custom items require reloading the page if you want the item info to work (which I don’t really understand as these are also being forced to to an automatic full load lol). When I next find time I’ll fight with the fetch stuff a bit more and try to get it fixed. Thanks for sharing your edits to it - while I didn’t use most of them directly they were super useful while trying to work out what needed fixing!
The reviews, audio quiz, and conjugation quiz are working fine, but I just checked and indeed the lessons seem to have broken again. I’ll see if I can find time this weekend to fix
