Any way to remove 飛び込み自殺?

WaniKani Feedback
#15

Personally, I don’t see any point to remove that from Wanikani. Hiding something doesn’t make it disappear, and it won’t make any difference to the problem of what exists, in Japan and elsewhere. Actually, I think the opposite would be better for everyone, more exposure for the subject and perhaps people learn to talk about problems before a situation escalates to point of suicide.

And as @Epona pointed out, it’s not WK’s job to think what trigger word might trigger someone. If someone feels uncomfortable about subjects they should look for plugins that can block them.

Removing those from every place just makes those subjects more abstract and harder to talk about, and what/who that helps?

15 Likes
#16

It’s good to learn it exists, so you know you can avoid it whenever it comes up.

1 Like
#17

So because a term makes your tummy hurt you want to pretend it doesn’t exist and be unable to read it? Seems backwards and counterproductive to me. Maybe while we’re at it we can remove 太る and 痩せる since people have eating disorders. Or remove お母さん because some people have abusive parents. Or 犬 because some people have cynophobia. Or 飛行機 because many people have a crippling fear of flying. Or 酒 because it could trigger a relapse in an alcoholic.

My point is twofold. First, just about anything can be “triggering” to someone and trimming words based on that possibility we would be left with a barren and useless language. Second, pretending a word doesn’t exist doesn’t do anyone any good. Besides, if you don’t learn it now you’ll probably end up looking it up at some point anyways

27 Likes
#18

Agree. A lot of bad things happen to a lot of people, incurable may trigger thinking about my mothers incurable brain cancer, murder, murderer, dentist, doctor…there are all kind of potential triggers…fugu…etc. We can’t remove them all.
I suppose a system where people could remove them themselves while still letting others learn might be a good compromise.
There seems to be too much emphasis nowadays on avoidance of anything unpleasant at all costs…whatever happened to “you must face your fear, let it wash over you and through you etc…”

8 Likes
#19

I think we can perhaps agree that while yes “every thing can be a trigger for someone” some words are more likely to be to be upsetting for a large amount of people than others.

I don’t think that not teaching is necessarily the answer. But I do think that they might improve the presentation as mentioned above. Include links for helplines, or they could also remind users about how to use user synonyms to swap in something else that might be less upsetting. Just something that is a bit more caring overall and give people some options.

3 Likes
#20

Someone correct me if I’m wrong, but I think part of the reason why no one has made a script that can block out certain WaniKani vocabulary items yet is because it’s probably not that easy to make.

IIRC review sessions only have 10 active items at a time (since you only review half of an item at a time, either the reading or meaning, and if you don’t finish both within 2 hours the progress of the item resets) so I imagine that the script would constantly have to check for the blocked item to make sure it doesn’t appear? I think a script made by someone on these forums would have to do it this way, since only WaniKani themselves could remove an item for you client-side, right?

#21

I know this will make me sound like a jerk because of assumed tone, but I mean this in the most literal and neutral way possible: if you have a problem with suicide you picked the wrong culture’s language to learn. Contemporary Japan has a high suicide rate, is famous for ritual suicide into the modern era, and used suicide warfare within living memory. Suicide in Japanese culture is A Thing.

13 Likes
#22

Ah might be, don’t know how userscripts work (or js/html/css). They could create generic hide functionality but they should not hide anything by default.

But no client-side chagnes don’t need to be done on WK-side at all. That’s how ad-blockers works too, when the website is loaded all data is read and checked against the blacklist before it’s put on webengine to render. So it can be done on the client-side, but I don’t know the codebase of WK so cannot say if it’s hard or easy to implement on their side either.

#23

Yes, I don’t see how else this could be done. Only WK can delete a word from their server.

If a script is done, I assume the script would scan the batch of reviews when you start one and see if the word(s) you have added to the delete list appears there or not. If it does, then it can make it not show up but I wonder, how could someone do this? How could we block a word from appearing? Perhaps we could have the definitions of the words being blocked in a list and automatically submit them when the word is detected so that they go through the normal stages but you just don’t see them in action.

#24

Right. The information that is rendered on the client side can be manipulated but the words themselves cannot be deleted. I can get and manipulate info from their API either with an IDE or using Postman which is easier but there you’re not free to do all you want there. I have not learned now to do this via the web. It is so much fun to see all of these scripts that people make and I also want to make one.

I’m gonna see if I find tutorials on how to get started with scripts for the web. But yeah, I believe it is something that can be done by requesting a batch of reviews from their server (whatever the user is set to do— either reviews or lessons) and then simply submitting the correct answers for those automatically so that the user doesn’t see them.

Edit: if someone that makes scripts can point me in the right direction that would be great :slight_smile:
I am familiar with HTML and CSS and have recently ventured out into fetching data from WK API with success.

#25

There is no need to remove those from the server at all. There only needs to be a possibility to hide elements for specific users.

To do this on the server-side there need to be at least a few changes (but as I said I don’t know exactly codebase so there might be even more things)

  • In the user database there needs to be a list of elements that he has hidden.
  • Change website to support this functionality (checkbox in element)
  • And hide it from review/training sessions.

There is no need at all to remove them.

On the script side what needs to be done.

  • Make changes on few pages, the checkbox for elements what’s hidden
  • Keep a list somewhere on client (ex. Web Storage?)
  • If element appears one of two possibilities:
    • Autocomplete element and continue forward (you can keep screen white during this so user wont get triggered
    • Keep element in training session but block somehow to going there (as I said don’t know how userscripts works or wk api) and update front page training image - ignored elements what should have happened.

Those are two methods what came in mind. To be honest I think script to block would be easier than in WK side.

#26

But as far as I know, we can’t hide or alter anything from the server side. Only WK can do that.

Yes, that’s what I was thinking as far as the client side. The thing is, whoever makes the script would have to have a web storage—mongoDB for example but it may get expensive due to the user base I suppose and the server will always have to be available— but I believe it could work as well with this method.

#27

You don’t need to alter anything on the server side if doing client-side blocking.

No need to use mongodb, Storage - Web APIs | MDN should be sufficient.

Edit: mongodb is nosql serverside database, you don’t use that heavy thing in client-side.

#28

Oh ok. So you were just mentioning what WK would have to do on their side if they wanted to block certain words from users.

#29

Good to know :+1:

#30

Well, they can do it on the server-side too.

But it can also be done on the client-side as I explained earlier.
You don’t really remove them but you just hide their existence.

#31

Even putting aside this pretty unkind way of portraying those with adverse reactions to discussions of suicide, I have to wonder why you’ve gone out of your way to portray TC like this given they’ve explicitly stated that they’re only wanting to remove it out of concern for others in their workplace.

Would also like to add my support for a SFW mode, if possible tied to a user-managed list of vocab items. As someone who works in an office in Japan there’s a couple of items I’d get nervous about appearing in big letters on my screen.

7 Likes
#32

Yep. I’m gonna learn how to do web apps. Perhaps I could make a script for WK in the future

#33

I really thought that this script existed already but I couldn’t easily find it. Rather than work out all the integration stuff yourself it might be easier to add your filter logic to [Userscript] WaniKani Open Framework Additional Filters (Recent Lessons, Leech Training, Related Items, and more) instead.

There are other motivations for this though. Some people don’t want 金玉 coming up in their reviews in front of students / faculty room colleagues during break. Also, others complain about the baseball terminology in WK.

1 Like
#34

Yes, indeed. That’s what this specific word issue is about. It’s very important to navigate this subject specifically in extra careful ways. This isn’t about users potentially being uncomfortable, or disliking a word on WK. It’s about keeping people safe and alive.

5 Likes