[Userscript] WaniKani Pitch Info

Could simply retain the Weblio lookup as backup if local definition is not found.

It’s now checking for digraphs, so words like 女王 will display correctly with the accent on お.

However, concerning the 中高 pattern: If the accent falls on a digraph, long vowels, ん, or small っ and the pitch also drops before the particle, are all high pitch notes pushed back? Problem is I don’t know any words to double check on this on OJAD. I imagine there are only a few edge cases like this.

Also this seems like it could be a helpful post too

Looking at the new version, I think having the dot above the small ゃ (for example) is misleading because it misrepresents the number of mora in the word. Regardless of the angle of the line you choose, I think you should have exactly one dot per mora, plus the extra one for the particle.


Also, this may be a small thing, but I think having some padding (around 3-5px) between the type of pitch (like 平板) and the number (like [0]) would make it easier on the eyes.


I got an error when looking up 小学校. Cannot read property '3' of undefined - VM609:404


What do you mean by this? By definition, if the pitch falls anywhere in the word, it falls before the particle as well. I believe someone explained that long vowels, ん, and small っ all count as their own mora, but a digraph only counts as a single mora, meaning that small ゃ, etc. do not count separately. Can you give an example, even if it’s with a fake word to demonstrate?

EDIT: Related to this, looking at your code I don’t think you should be including little っ and ッ in your list of digraphs.

EDIT 2: I temporarily added handling for 7 kana so I could see the diagram for 小学校, and unless I messed something up completely, the diagram didn’t look right. It dropped after the う when it should have dropped after the が. Maybe this answers your question.

2 Likes

That’s because it’s a hard-coded table. The values in the 7th array block would need to be adjusted to display properly.
I believe @nasatitan is generating a lookup table with all the wanikani vocab so that shouldn’t be an issue later. Though in the case of new words added, it might be good to explore a dynamic method for when a lookup fails.

Also, isn’t the う a normal mora in that word? It’s not displayed as the ぅ digraph. Or am I mistaken in thinking the small versions are the digraphs?

I’ve added the spacing for the accent type and link, and upped to 7 mora support.

I’m fairly certain I created the correct array block for 7 mora, but I’ll check against your version later.
You are correct about う and ぅ. I think the diagram for 小学校 got messed up from the ょ in しょ.


Regarding the lookup table, I would hope the table just has the number (or numbers if more than one pitch accent) like [0] that weblio supplies. I think hard-coding it to a specific diagram would be a bad idea since any human error or mistakes in the current algorithm (or changes in implementation) could require redoing all that work later.

1 Like

Hey, I installed the script earlier and did some lessons with it for the first time, and so far I really like it!

I’m not sure if this has been brought up already or not, but after my 4th item or so, the reading sections started to look like this:

Screenshots

Yea that’s the format I’m using, [“前回”,[1,0]],[“十”,[1]],[“石”,[2]],[“言い方”,[0]]… etc in the case it has two correct patterns. We can also add the individual kana, if we need that, but that more than doubles the size the of array and didn’t feel it necessary. I’ve been looking for some form of ID in WaniKani for the vocab, to prevent searching the entire list. I know each item has an html vocabulary class with a unique number when you’re viewing all the vocab in Lattice, but I don’t think this number is used reviews for example.

In the 小学校 isn’t that considered a compound word? I think that will follow different rules than just looking it up in a table. In Dogen’s phonetic video #9 (patreon) he explains that the general rule for compounds is that it will follow 中高 and the downstep will occur on the first mora of the second word, 学校, rather than treating it like a 7 mora word. So the correct one would be the one found in OJAD:

50 PM

Edit: What are the chances of having WaniKani devs add meta data to the page, like Kanji, Reading, ID :wink: It would make extensions a lot easier.

If you use an Object/Dictionary it should make word lookup much easier and much more efficient. For example {"前回": [1,0], "十": [1]}.
I don’t think adding the kana is necessary.

I don’t think 小学校 being a compound word matters. If it’s in Weblio, you should probably just use the value given.

Really wish I had this script since the beginning of my Japanese studies (and paid more attention to pitch accent earlier).
The script looks good! Thank you so much!

1 Like

[Edit for future readers: I don’t know that 小学校 is considered a compound word.]

Yup, we’re actually in agreement! As I understand it, 小学校 is listed as 中高 [3] in Weblio, but it’s also because it’s a compound word that it reads as 中高 [3]. But because it’s a compound, it follows additional rules. I think for any questionable patterns we should be checking against OJAD, since that’s an academic research tool.

Actually here’s a snippet from that video I was referencing for additional compound rules (via tofugu article):

2 Likes

Didn’t realize JS Objects were hashmaps, kind of seems obvious in hindsight… :thinking:

1 Like

I just saw that weird repeating kana issue too. Happened during a lesson for 昇進.

image

Also, I think this bug made the sound louder since there is more that one instance of the audio button. That’s really weird.

1 Like

Yeah I saw that issue last night too, I should be able to get around to fixing it tonight hopefully.

Seems like the MutationObserver callback is getting invoked multiple times (over 60 for me!), and thus parsePage function calls drawPitchDiagram repeatedly, which is not idempotent, so it adds multiple diagrams for each observation. I kludged a local copy to set the class name on the diagram and check for existence of that same class name in the containing element before adding another one. If the pitchNumber is unique for a given vocab, something like that should suffice to fix the issue.

Well, that’s the case for reviews too. The problem is that WaniKani doesn’t create the reading data until you actually reveal is, so we have to watch for changes and do a check if it’s there and if we’ve already drawn it. It’s working for reviews, just need to take a look into what difference is making it not hold itself back on lessons, because I already append a “vocabPitch” attribute to the create element.

I thought I had the latest script, but I guess not? I don’t see the vocabPitch attribute on the elements in the DOM or the script. My kludge was essentially the conditionality you describe. If it matters, given my stale script, I saw this in vocab reviews. Happy to retest whenever there is an update.

Also, it would be great if it worked on Kaniwani too, I have Kaniwani Audio with the autoshow on correct setting enabled, so also seeing pitch would be very handy.

And for whatever reason, I don’t see the audio replay button next to the graph as shown in other’s screenshots.

I’m planning to add it to Kaniwani natively, keeping an eye out here ^^

2 Likes

You had the latest script, it’s just that the check was being avoided because the pitch lines are created outside of the element I create that has a custom class, and the attribute I apply to the wanikani reading class wasn’t be utilized in a way that would work. Also after the internal lookup feature was added, a variable wasn’t being assigned to in that route that needed to be for one of the checks.

The audio only displays on the side only during lesson, during reviews it’s a button on the middle-right of the page.

I’ll take a look into kaniwani support since I do use that too, thanks.

The markup is going to change considerably rather soon. Mangled classnames for scoped css will make it a pain to script with. Plus the html tags are subject to change if I do any spring cleaning, so targeting by ul > li p:first-child etc will be rather brittle.

You’re certainly welcome to add it in the meantime!
Just warning you that any time spent on it will probably be wasted (so to speak) as it will be rendered obsolete shortly.

1 Like