Is Wanikani broken right now?

No! It’s not. I just figured out what the problem was because I was having the same problem as you.

If the kanji for NINE, for example, and you need to type the reading… you may be tempted to type
きゆう (ki yu u)

but really want you want to type is
きゅう (kyu u)

And that’s why it’s not accepting it!!!

That wasn’t the problem in this case.
You can see in the screenshot that SouthernScout is trying to submit ふ as the reading for 不, which is correct. Then WaniKani is shaking, instead of marking it wrong, like it would with きゅう / きゆう.

If you did that it wouldn’t shake, it’d give you a wrong answer, which I’m sure you know.

It reminds me of the Norwegian helpdesk :smile:

https://www.youtube.com/watch?v=pQHX-SjgQvQ

5 Likes

That’s really cute. Teehee. XD

That definitely wasn’t it, I was writing the correct answers, as shown above where it gave me that shake when I wrote ふ for 不. It’s fixed now and hasn’t happened since tho

That is hilarious but makes me second guess if I should go study computer science there for a semester… ^^
What if they’re still like that?!

This happened to me just yesterday and it was not the first time it happened.

I went to look into the source code and found out that it makes wrong decision on line 8547:
All the line numbers are relative to the chrome browser’s formatted code.

"reading" === $.jStorage.get("questionType") && answerChecker.isAsciiPresent(a.val()) || "meaning" === $.jStorage.get("questionType") && answerChecker.isNonAsciiPresent(a.val()) 

It asks if the “questionType” is “reading” than it must not contain any Ascii character or if “questionType” is “meaning” than it must not contain any NonAscii character.
The value of $.jStorage.get(“questionType”) is not what it is supposed to be. If the card is “meaning” the value is “reading” and vice versa.

My first taught was that the value is not set correctly but debugging the code i found out that is not not case. Value gets set in line 8620;

$.jStorage.set(“questionType”, i),

The wired thing is that is always get set correctly but when it comes to line 8547 it is not correct anymore. Something must have change it or it was incorrectly set in the first place. Perhaps was it in different thread or perhaps jStorage is not working properly.
Code was debugged without any extension or user-scripts on google chrome.

I hope someone has a clue why value in jStorage would change for no apparent reason.
My guesses (probably wrong):

    1. It was set in wrong thread
    1. there are two separate jStorage instances
    1. some obscure setting was set thus disabling saving of this variable
    1. jStorage is not working properly

Furthermore i don’t think this issue is limited to any specific operation system because it also happened on my phone. It only happened once like 4 months ago.

The simplest solution to avoid this problem is to switch browsers to Firefox. Not permanently … only when this issue occurs :slight_smile: .

4 Likes

^^^ I’m tagging @viet for this debug info. Often, it just takes a little clue like this to point to the true cause.

Thanks for the detailed debug info. Going to create add this to our bug board.

2 Likes

Great find!

I’ve made script that temporarily fixes the problem. So if you encounter this problem again just install this userscript and the problem should go away.

1 Like

That’s how it is with computers.

Not a single living person knows how everything in your five-year-old MacBook actually works. Why do we tell you to turn it off and on again? Because we don’t have the slightest clue what’s wrong with it, and it’s really easy to induce coma in computers and have their built-in team of automatic doctors try to figure it out for us. The only reason coders’ computers work better than non-coders’ computers is coders know computers are schizophrenic little children with auto-immune diseases and we don’t beat them when they’re bad.

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.