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.