A few months ago, if a word was answered incorrectly during a learning session, the session would allow you to fully learn the rest of the other words, but any words answered incorrectly would need to be fully learned in a new session.
In September, a change was made so that regardless if a word was missed, it would be drilled in the learning session so that it would still be fully learned.
Yesterday after finishing a learning session, some of the words were not fully learned. I can’t say if it’s because I answered incorrectly or if my learning session of 10 words was too much to finish all the words fully.
I ask because, in my situation mentioned for example, I didn’t realize those words were not fully learned until the next day, so now those words will be behind in review. So it would be good to know if I should go back to making sure words are learnt in the lesson word list after a session.
Does staff or other users know anything about this? Is it on purpose? Cheers
I am guessing that the way it worked in September and October was caused by a bug, and they have gotten around to fixing the bug. But who knows? It’s not like they actually communicate about that sort of thing.
At the end of a session on the Web, there is a screen that shows whether the item is fully planted or not. That feature is still there.
I had this happen to me at least once, too. My current theory is that because Memrise records learning events by sending network requests in the background, if some of those requests fail, one can end up with words only being partially planted.
Thank you both for the replies. If forced learning to completion was the result of a bug in September, then I must say it was a bug that I found convenient. I’ll just go back to using the planted screen as you suggested. I’m oddly skeptical about that screen, I still go back to the level screen to make sure their really planted haha
@neoncube it could definitely be failed network requests. Using the site in China paired with the fact that the dashboard takes 10 seconds up to a minute to load I suppose points to trouble.
@neoncube woah, that is pretty 聪明. Do you find this working to alleviate bogdown in a lot of sites or do you use a longer list of these in your browsers? Basically it’s working to let the browser realize sooner that the destination is unreachable by substituting to “https://” but isn’t actually giving a alternate font destination, right?
Yep It short circuits things by stopping the request immediately instead of having it wait until it times out. It doesn’t do any substitution, although one could if one could find the font somewhere else (like Font Squirrel, although hotlinking to the font on their site might be against its rules).
I have some other rules, too.
Keep in mind that using this method, the resources will be blocked whether one is using a VPN or not. I don’t use a VPN, so that doesn’t bother me, though.
Anyway, here are some rules to get you started. These should all be redirected to https://
It short circuits things by stopping the request immediately instead of having it wait until it times out. It doesn’t do any substitution, although one could if one could find the font somewhere else (like Font Squirrel, although hotlinking to the font on their site might be against its rules).