aragonsr said...I'm a bit concerned about this script.Side note... It seems WaniKani has removed the "..." from vocabulary, except in search results.
A cursory glance at this script looks like this script doesn't dynamically expand the items on the fly.
So if the list changes the script won't work properly or only work on some of the items.
Like if there's more levels or new items added.
Any insights?
aragonsr said... I'm a bit concerned about this script.Just updated it.
A cursory glance at this script looks like this script doesn't dynamically expand the items on the fly.
So if the list changes the script won't work properly or only work on some of the items.
Like if there's more levels or new items added.
Any insights?
rfindley said...Side note... It seems WaniKani has removed the "..." from vocabulary, except in search results.That's nice.
But they didn't add the hover tooltips to radicals and kanji like this script does.
kobayashi said...If they really want ...'s for small screens, maybe they could use CSS 'text-overflow: ellipsis' to trim locally.That would be nice!
As of a week or so ago, I started seeing ‘…’ again on /level/ pages and /vocabulary pages (such as the L1-10 vocabulary page).
Adding some logging to the dot dot expander script (via tampermonkey, if that matters) suggests that the contents of ‘item’ (such as in dotExpandMulti) aren’t matching anything in the dotItem list (or hash, or whatever you call them in JS).
I tried adding an entry to dotItem (which apparently wasn’t already in the list) where I copied/pasted the kanji from the /vocabulary page, but some logging showed that, despite being an entry that matched the … regex, the dotItem[item] was returning something undefined. (Or, at least, ‘undefined’ is what was being logged.)
Specifically…
I added this line to the top of dotItem:
‘下さい’ : ‘Please Give Me’,
Then added some logging to dotExpandMulti:
if (en.match('[\\.]{3}$')) { //Added it inside this block
...
item = $(elem).find('span').html();
console.log('current item: ' + item); //added line
...
enFull = dotItem[item];
console.log('enFull: ' + enFull); //another added line
So, when I refresh the page and look at the console, I see:
current item:
下さい
enFull: undefined
When I reload the L1-10 vocabulary page, there’s 110 or so entries just like this. enFull is always ‘undefined.’ Now that I think about it, I didn’t actually check to see if the entries that appear to have a ‘…’ on the page are in dotItem or not. (I suppose that changes to WK’s vocabulary may introduce undefined entries as well…although that wouldn’t explain why 下さい’s enFull is undefined, as far as I know.)
You’ll have to forgive me if I’m talking about this incorrectly – I’m no programmer…or so I’m told. (But seriously, I’ve done very little with JS and the like.)
Anyhow, my uninformed conjecture is ‘unicode problem.’ If I’m not mistaken, I started seeing this when the fix to the “one review” bug was rolled out last week.
@stevebrown0804,
Notice 下さい is down on the next line in your console output. It looks like you’re picking up a newline character when calling html(), so item is probably ‘\n下さい’ instead of ‘下さい’, and it’s not finding it in dotItem. You’d need to trim any whitespace and newline characters.
For starters, I’d use text() instead of html(), then filter item:
item = $(elem).find('span').text().replace(/[\n ]+/g,'');
Hello,
Does this script still work? I installed it but nothing changed.
I’m guessing it’s related to @stevebrown0804’s reported problem a few posts up. I don’t think the script’s owner integrated the changes.
If I get some time later, I’ll see if I can patch it and rehost.
Ah ok, thanks. Yeah, on the chrome extension page it says it may be corrupted.
Chrome extension page?
A lot of scripts don’t work without a script host plugin like TamperMonkey. I don’t know if this is one of them. I’ve personally never learned what features are different in order to support installation directly as a browser extensions.
Oh, I know that and out of curiosity I tried to do what BreadstickNinja said in post 9 in this thread but the script doesn’t work either way.
I’ve repaired it, and updated newly added items.
[v2.0.0] - Fixed Takuya Kobayashi’s old script. Added new items for expansion.
Doing the Crabigator’s work, rfindley. Thank you!
Thank you, you’re always amazing!
Strangely, this won’t work for me. I also have tried disabling all other scripts first. Is there some specific thing like settings I’ll have to do first? Other scripts worked fine for me though. I’m using Tampermonkey, if that is of any help. If there’s further information needed, I can provide that as well.
Thank you in advance,
Eagle
Did you install the updated version from a few posts above?
i.e. here:
Oh I didn’t notice (facepalm)
That did it for me 
You might want to update the link in the start post so people won’t encounter the same problem as me 
I would update the top-post, but it’s not my thread, nor originally my script.
Come to think of it, though, I do have the power to change thread titles, so I could mark it as deprecated and start a new thread. I think I’ll do that later tonight. (Time for dinner right now…)
The thread for the new version is here:
@rfindley: Posting here to avoid polluting the new thread.
Thanks for supporting this script, but shouldn’t this have been done by WaniKani?
At first glance, this really seems like it ought to be a minor UI change (i.e., style only). However, to my surprise, it looks like the script manually lists the terms that are cut-off by WaniKani and replaces them with the full English phrase. It’s my opinion that this scripts like this should not need to exist. It’s not a very controversial change to have the full term show up desktop, and WaniKani can just use CSS style “text-overflow: ellipsis;” for smaller screens.
Manually inserting ellipses and then having users maintain a user-script to replace those ellipses with the full text seems very wrong to me. 
Just to keep this link as the last post in the thread…
Here’s the thread for the new version of the script:
@BobaGakusei,
Yeah, I think I’ve mentioned that somewhere above. I think CSS text-overflow: ellipsis wasn’t supported by all browsers until about the time WK was in development, and they simply haven’t done a lot of front-end changes over the years since. Or maybe they just weren’t aware of that CSS capability (I know I wasn’t until relatively recently).
I’m not sure how much the coming updates will cover, but I’d like to see the CSS ellipsis eventually. Maybe post about it in the new thread and tag viet and oldbonsai if you’d like.