I’ve raised this before, but I’m going to raise it again as I’ve looked at similar requests and the responses from the @mods don’t really make sense.
When a radical and a kanji are the same, please could you display the Kanji in the “Found in kanji” section on the radical’s page. This would save time checking up on forgotten items. The Kanji alone does not currently show - it makes logical sense for it to be there as the radical is used in the kanji. See example below:
But I don’t think Jenny’s comments are correct, as I haven’t learnt the kanji for “Get a position” yet, but it still appears under the “capital” radical.
It’s only a small thing, but really bugs me everytime I have forgotten the mnemonic for a radical and have to manually search for the kanji.
It seems like a different situation for “Get a position” - you learn the Kanji after the radical, not before. It’s the opposite to learning the “Capital” kanji before the radical. I agree that it would be ideal if they were linked still, though, regardless of whether it’s feasible for them to implement (which I have no idea about).
I think your interpretation of what she said is reasonable, but unfortunately, it’s a bit of a misunderstanding.
I’m about to explain why it’s correct, but I’ll just mention that I’m not defending keeping it the way it is, since I also expressed my desire to have a way to view the components for radicals in a related topic.
To explain, let’s consider the data available via the API, which I’ll assume is virtually the same as what they’re using to link the items.
The data property of the subject contains a property called amalgamation_subject_ids, which is an array of ids for the subjects in which this subject is used[1].
For “kanji” and “vocabulary” types, they also have a property called component_subject_ids, which is an array of ids for the subjects which this subject is comprised of, however, that property is not included for radicals.
Therefore, the referential nature of radicals → kanji is unidirectional and does not go in reverse. That is to say, the data simply isn’t there for the reverse. That’s why a radical can list the kanji that it’s used in but it can’t (as it currently stands) link the radical(s)/kanji that formed it.
Though, if someone wanted to attempt to programmatically add that data, it might look something like this…
for (let i=0; i < subjects.length; i++) {
const item = subjects[i];
if (item.object !== 'radical') continue;
const sharedKanji = subjects.find(d => d.object === 'kanji' && d.data.characters === item.data.characters);
if (!sharedKanji) continue;
item.shared_kanji = sharedKanji.id;
// avoid a circular reference when the radical is the component for the kanji
if (sharedKanji.data.component_subject_ids.includes(item.id)) continue;
item.data.component_subject_ids = [...sharedKanji.data.amalgamation_subject_ids];
}
Assuming that doesn’t create problems elsewhere, maybe I’ll suggest it as an addition to WKOF or something haha.
(That said, it’s more of a brute force approach and likely doesn’t take into account various factors, nor does it solve the situation for the rest of the radicals that aren’t directly formed from a single kanji)
To be clear, for this example, you can replace the words “subject” with “radical” and replace “subjects” for “kanji”, but note that it works the same for kanji to vocab, for example. ↩︎
The request here isn’t for a list of all the subcomponents that make up the radical, though – it’s specifically that when a radical is exactly identical to a kanji that the kanji is listed. You could achieve that by listing that kanji in the amalgamation_subject_ids for the radical, right? It’s just a content choice to say “涼 contains 京 but 京 does not contain 京”.
That could be possible in theory (as another way of implementing the changes, perhaps), but it’s simply not the case because the kanji is not included in that amalgamation_subject_ids list for the radical, nor is the radical in the amalgamation_subject_ids list for the kanji.
I ran into this problem (or at least a related problem) a lot during the later levels. A lot of the kanji there rely on the mnemonics of kanji thought dozens of levels ago, but do not link to these mnemonics in any way. I guess this is a direct consequence of the seemingly arbitrary choice to not allow using kanji as components of other kanji. Which is doubly weird because as @Inserio noted all the connections are id based, so you could just mix and match ids in the same data structure if you put a bit of effort into updating the code using these values.
A less nice, lower effort solution would be to just include a hyperlink in the note section of these kanji radicals, because any information or link is better than the current “you should already know this because you reviewed this a couple times two years ago”
Hey! I made a request for this to pass on to engineering. I know that’s probably not the answer you want.
As other people mentioned (and probably articulate better me) it is a matter of the data modeling and order. For 京, The kanji is made up of lid + mouth + small. The radical is made up of the kanji.
So in the system, 京 radical is not found in the kanji. Lid, mouth, and small are.
All that said, that doesn’t mean it can’t be in that list. It is more convenient for reference purposes to have it there. It’s a valid suggestion, and if implemented I’d make use of it myself!
You wouldn’t really have to store any of this in the database, you could pre-bake this and store it straight into the code or calculate it on startup, it’s just a dictionary with a few thousand entries. If you really want to make it dynamic, just add a new table somewhere and store it there, but frankly I wouldn’t do that myself. It’s completely static data that’s updated maybe every other month when the team decides to make content changes, so just restart the program when it happens.
For reference I have a very dirty python script that takes the WaniKani kanji data, cross-references it with kanjidic, a custom “synonym” list containing ~2000 entries and keisei data (to find phonetic siblings recursively), loads my own additional kanji and vocab, adds furigana and then dumps all that into an sqlite Anki deck. It runs in 1.2s on my rather outdated computer.
WK’s dataset is really not significant. The missing (and removed) features are missing because the team doesn’t want to implement them, not because it’s a huge technical undertaking.
