[Userscript] Open Framework Kanjidic2 and Traditional Radicals Filters

WaniKani API And Third-Party Apps
1

:warning: This is a third-party script/app and is not created by the WaniKani team. By using this, you understand that it can stop working at any time or be discontinued indefinitely.

Requirements:

[ General Script Installation instructions ] :point_left: You’ll need a script host plugin like TamperMonkey
[ Open Framework Installation ]

Download the script here:

WaniKani Open Framework Kanjidic2 and Traditional Radicals Filters

This is a collection of filters from Item Inspector and Self-Study Quiz with three major common points.

  • They use kanji information from the Kanjidic2 file
  • They introduce traditional radicals as an item type separate from the Wanikani radicals.
  • Some of them implement complex functionality with elaborate configuration dialogs. This makes them suitable for complex search and/or filtering on Wanikani items.

In addition to this data the two stroke count filters use stroke count data for Wanikani radicals.

These filters are fully functional in Item Inspector. In Self Study Quiz they are somewhat limited because Self-Study Quiz cannot quiz you on traditional radicals. The filters will work to the extent they are not selecting traditional radicals. For example filtering all kanji that uses the radical arrow will work because Self Study Quiz can quiz you on kanji. But filtering all traditional radicals found in the kanji 能 will not work because traditional radicals are filtered.

The following filters are provided:

  • Stroke Count >=
  • Stroke count <=
  • Extensive Search: Searches characters, meanings and reading for WK items and traditional radicals. Searches kanji information in both WK and Kanjidic2.
  • Advanced Search: A Swiss army knife of searches. Can find information in characters, meanings, readings, mnemonics, hints, context sentences, allow and block lists, part of speech, reading and meaning notes, user synonyms, semantic-phonetic data. There are more features not mentioned here.
  • Related Search: Searches items based on relation ships, like components found in items, items found using components, various types of visually similar kanji and semantic-phonetic relationships.
  • Explicit List: A filter that explicitly whitelist items.
  • Explicit Block: A filter that explicitly list items to be barred from showing up.

Note to developers

You should use wkof.wait_state('advSearchFilters', 'ready') .to wait for the completion of the filters initialization.

This code is dual licensed under the MIT license and the GPLV3. Portions are written by @rfindley and are available under MIT license only., Other portions are written by @acm2010 and are available under GPLV3 only.

It is available on github

Data License Information

  • The KANJIDIC project files are released under a Creative Commons Attribution-ShareAlike Licence (V3.0) License Information The Licence Deed can be viewed here, and the full Licence Code is here.

Traditional Radicals uses information from the following sources:

The link to the original kradfile-u doesn’t work anymore. You can get this file here

Complete licensing details about Kanjidic2 and kradfile-u are available here

The WK_radicals.json.compressed file is available under the Creative Commons Attribution-Share Alike 4.0 license. Deed - Attribution-ShareAlike 4.0 International - Creative Commons This data was manually copied from the Kanji Stroke Order font for the radicals characters. When no font for a radical existed the stroke count was extracted from the font for a kanji using the character.

Version History

Version 1.4.2 - Minor bug fixes.
Version 1.4.0 - Fixes styling of Explicit List and Block List
Version 1.3.0 - Supports kana only vocabulary - part 2
Version 1.2.0 - Now supports kana only vocabulary
Version 1.1.0 - Adds stroke count data for Wanikani radicals.
Version 1.0.1 - Original Release

2 Likes
2

@Ashikaga

My blacklist filter is ready. It is the Explicit Block filter you get when you install the filter set described in the top post of this thread. The difference with @rfindley filters are:

  • More complex. @rfindley’s filters are simple and to the point.
  • Bigger editing boxes, convenient if you have a lot of data.
  • Editing boxes resizable with the handle located at the bottom right corner.
  • Possibility to download your configuration in a file.
  • Possibility to upload the filtered items from a file.
  • Traditional radicals are supported but this works only in Item Inspector. Currently Self Study Quiz doesn’t quiz you on traditional radicals.

If you want to update your configuration from Self-Study Quiz here is a procedure that gets close to it.

  1. In the filter enter some data.
  2. Save the data in a file with the download button. This will give you a properly formatted file.
  3. This file is editable. Open the file with a simple text editor like notepad (on Windows).
    1. Separate the items with commas (Japanese or Western, it doesn’t matter).
    2. Radicals can be English. Kanji and vocabulary must be Japanese.
    3. Don’t touch the separation lines (radicals, kanji, vocabulary, traditional radicals) The filter relies on this to recognize the format of the data.
  4. You can bring the edited information back to the filter with the file selector and the “set the items” button.
  5. When reviewing your items keep your editor around. When you feel like blacklisting an item, copy and paste it from Self Study Quiz into the editor. When you are done editing you can bring the items into the filter.
1 Like
3

nice one, will check it out later :slight_smile:

1 Like
4

@rfindley

The filters in the top posts raise a number of issues regarding Self Study Quiz. There are four of them:

  1. Button type filters
  2. New item type: traditional radicals
  3. New item source; traditional radicals
  4. Categorization of filters

Let’s go over them one by one.

  1. Button type filters.

This script introduces four button type filters. I think these are the first button types because i believe I know all the filters that were written so far. The issue is these filters need a path to work and Self Study Quiz doesn’t provide one.

The point of a path is to provide a location for the object that is the value stored by the filter.

  • A button filter provide a complex interaction and needs to store more than one parameter.
  • All the parameters must be supplied to the filter through the option parameter of wkof.ItemData.get_items(). This option must be a single value passed as the value property of the filter subobject.
  • The solution to the previous two points is to make the value an object. All the parameters are properties of this object.
  • There must be an agreement between the filter and Self Study Quiz on where to store the object. This requires a path.

Item Inspector provides a path to button type filters. Self Study Quiz does not. I work around this limitation by detecting when the filter is called from SSQ and generate a path accordingly. I can do this because I know the pattern SSQ uses to make paths. This is not a good solution. In an ideal world SSQ should provide a path and the path generation code should be removed from the filters.

  1. New item type: traditional radicals

Are you interested in setting up quizzes for traditional radicals? Currently SSQ can’t do it because code in the shuffle function processes only the native WK item types. The filters produces the traditional radical items and SSQ does nothing with them.

If you don’t want to quiz on these new items you still has a user interface issue. There is a tab showing up in the filters settings for a new data source: Traditional Radicals. If users enable this source no Traditional Radicals will be quizzed on and the filters have an unpredictable behavior.

  1. New item source; traditional radicals

Traditional radicals are not just a new item type. They are a new data source. The code about data source seems to assume that data sources are disjointed and the filters are similarly disjointed. That is

  • A filter applies to exactly one data source.
  • It is registered under this source.
  • It is applied only to items from this source.

The problem is none of my filters work like this. They all apply to both WK native items and traditional radicals.

  • Example 1 The explicit list filter is an expanded item list filter that allows to list items in all four item types.
  • Example 2 The extensive search filter can search items for their characters, meanings and readings of all four item types.
  • Example 3 The related search filter may return every kanji that use a given traditional radical, or conversely all traditional radicals used in a kanji.

All my filters are of this ilk. This raises some thorny issues .

  • Where do we register such filters?
    • Do we register them twice? Once for each source?
  • From a UI perspective does the filter show up under both data sources?
    • Does the user need to configure the filter twice, once for each source?
    • If configured only once, under which source?
    • If configured twice, what if the settings are different or contradictory?

I am afraid my solution to these issues is not ideal. If you have a better idea please chime in.

  • I register them twice, once under each source.

    The filters must be registered twice because each source has its own fetcher and the ItemData code checks that the filter is registered under the corresponding source. If the filtered is registered only once an error is thrown for the source that is missing.

  • In the UI the filters are shown only once.

    Having the filters show up twice is a source of confusion, both from UI and from software perspectives. I have abandoned the idea of having one tab per source. The two sources are consolidated under one tab and the “enable this source” checkbox is replaced by a multi. Categorization is used to tell the user which filters apply only to WK items and which apply to both sources.

filters

filters2

This solution is not implemented in Self Study Quiz. Currently there are two tabs, one for each source. Enabling traditional radicals as a source causes the filters not to work correctly.

  1. Categorization of filters

I have sent you a proposal for categorizing filters in the UI months ago. This proposal is now outdated because I wrote too many filters since. I should update this proposal, but that depends on what you want to do with traditional radicals.

I seek your guidance. Should I propose you something for the evolution of SSQ? I mean should I write some modifications to the code and send it to you?

5

Version 1.1.0 is available - You may download it at the link at the beginning of the top post.

Stroke Count data is now available for Wanikani radicals. This information is used in the two stroke count filters.

6

Version 1.2.0 is available - You may download it at the link at the beginning of the top post.

This version supports the upcoming kana only vocabulary.

7

Version 1.3.0 is available - You may download it at the link at the beginning of the top post.

This version adds supports of kana only vocabulary for two filters that were overlooked in version 1.2.0.

8

Version 1.4.0 is available - Please download it from the link of the top post.

This version fixes the styling of the UI for Explicit List and Block List filters.

9

Version 1.4.2 is available - Please download it at the top post.

This version implements some minor bug fixes