Update to how we handle User Synonyms

Nice. This will help if I misunderstand a word and give me some clarity. Thanks! :clap:

1 Like

You can get the blocked meanings for each subject from the API. see the Auxiliary Meaning Object Attributes section in the Subject Data Structure API documentation.


Aha, I see, I was looking for “block” or “warn” and totally missed those - thank you!


Hello, I’m not a native English speaker and I tend to use synonyms in my native language.

I’d like to ask if it is possible to make this hidden “allow list” visible and block specific items, since there are some vocabs that I get in trouble with due to phrasal verbs/verb transitivity/prepositions being accepted (e.g.: “to be moved”/“to be moving”/“to move”/“to move something”, as well as any verbs with 欠, 交 or 点).

For now, I have to resort to a translation for these to avoid getting the wrong meaning, since Portuguese can be more explicit (and I lack the vocabulary in English to know better synonyms).

1 Like

Hi @Jrom, in general we try to keep to as few visible meanings as possible, while still covering the main range of use of a word. That’s because there are sometimes a LOT of allowed words, and I think listing all of them would be unhelpful (we don’t want to overwhelm people or encourage people to memorize every possible translation).

Would you mind emailing us (hello@wanikani.com) with as many details as possible of your particular use case? Then we can get to the bottom of the issue and see what we can do to help in future updates. :slight_smile:


Let me get this straight

  1. when I type a word related with 枚 (flat object counter) as “sheets?” (my user synonym) because I’m way too lazy to specify when the word means “how many flat objects”

  2. when I add a synonym in my native language because I feel way more comforable typing “antier” instead of “the day before yesterday”

they won’t be marked wrong as long they’re not in a blocked list, right?

Hi @Ninkastmin, that’s right, all synonyms will be marked as correct unless they are blocked.


That’s good to know. I’ve had this happen in the past and not know why my answer was being marked wrong.

1 Like

2 things:

  1. Fantastic update! Love that there’s a dedicated UI for this now instead of trying to click the smallest buttons ever!
  2. it’s not on the updates page :pensive:

Good catch :man_bowing: It’ll be there soon.


Whoohoo! Finally we have warnings for blocked terms


That’s a nice update! Good job team! :+1:

(May sound like a feature request, but:) Any possibility to highlight incorrect meanings to prevent possible misunderstandings? Since I am also not a native English speaker, I often wonder before I add a user synonym if it really is correct. Sometimes the meaning explanation clarifies it, what I really appreciate, but often some explanations don’t. (for example, 講師 is lecturer, but can it also be a “teacher”?)

While writing this post, I noticed that my idea of just showing the block-list is dumb. Because these lists can be quite large, since they also cover “obvious” mistakes like Architect - Architecture. Better would be to only do a selection of common misunderstandings, but that definitely requires more work. I suppose I might write an e-mail to hello@wanikani.com, but just in case you already have some comment on this I decided to not delete what I already wrote :slightly_smiling_face:

A small feature request – disable browser suggestions for user synonyms.



Yeah, indeed. Nonetheless, I have another idea of, listening to “input” event, and warn before such synonym is added.

Additionally, use something like Levenshtein Distance for adding synonyms’ warning, just like how answer checker works. Don’t know if it is possible for “architecture”, though.

tbh, there are a lot of senseless words in allow list and block list as well. Not so meaningful to show them, other than wasting space.

Maybe I would propose about the warning message – what is the closest word you mean, by “please check your spelling” => “Did you mean xxx?”. Also another warning message, “the xxx answer is correct, but not one of our synonyms”. That is, reveal such word when it matters.


It is now :+1:!

1 Like

I don’t like the fact that the synonyms are now behind a separate management dialog.

  • before this update: click “add synonym” → write the synonym → click “add” → done!
  • after this update: click “manage synonyms” → write the synonym → click “add” → click × to close the dialog → done, but with an extra click

For context, I’m a non-native English speaker and I add synonyms in my native language for pretty much every single entry when studying new entries. It’s not that big of a deal, but due to the frequency with which I use this feature, I quickly noticed that adding the synonyms is now more annoying. :face_with_diagonal_mouth:

Is there a way to make the adding more straightforward again? I don’t really get why there’s a need to have this functionality behind a dialog instead of integrating it into the main page view.


This is a great addition. Makes it much clearer why certain synonyms weren’t allowed.

It was necessary to add a modal dialog as that gave us more room to add extra feedback when a user synonym was blocked.
I did however make it easy to enter a synonym with only one click. If you want to add a synonym quickly you could:

  • click “Add Synonym” → write the synonym → press enter → press escape

The escape key can be used to close the dialog and the enter key can be used to submit the synonym input.

I know it is still an extra step over what was there before, however not needing to use the mouse (if you are on desktop) should hopefully put you in the same ballpark speed-wise as before.


Not a fan of the added clicks. There’s also the problem of context switching. The extra step gives me a chance to forget what I was doing (see the Doorway Effect), and by covering up the existing kanji/vocab info, it makes it harder to remember what I was going to add.

I think this is an overdesigned solution to a fairly simple problem. There’s nothing wrong with adding a text message in red if the user adds an invalid synonym, using a form as a metaphor. I’m guessing there’s some arbitrary rule that they’re following where they don’t want to reflow the layout for any reason, even if it’s helpful for the user.


This has been a great change. Thank you!