I found a bug where long highlighted text is overflowing.
Here is the example.
Got it, Iâll have a fix for it in the next update.
Here is the rendaku plugin. [Userscript] WaniKani Rendaku Information
Itâs based on the tofugu article about rendaku. It probably covers most cases but of course it isnât foolproof.
Also, is it possible for you to fix how far the background extends on the color highlighting. As you can see on the app, the background hits the character following the highlighted area making it a little hard to read sometimes. This is especially true for the black background text since the following character will be black as well.
Thanks
1 Like
The fix for the overflow will also fix that. Unfortunately, it will also prevent the nice rounded corners from appearing, but those are the limitations of the Android TextViewâŠ
1 Like
This is a deliberate recent change, but it only happens in situations where the bars are narrow and there are several bars close together that have roughly the same height. The purpose is to avoid overlapping labels, especially if you configure the timeline to have more than 24 hours. Priority is given to labels for taller bars.
In your screenshot example, you have one bar with 20 reviews at 18:00, a bar with 10-12 or so at 17:00 just before that, and a bar with 8 at 19:00 just after that. If the 17:00 and 18:00 bars both got a label they would overlap, so the taller bar at 18:00 gets the label, and the 17:00 doesnât. The bar at 19:00 has fewer than 10 reviews, so the label is narrower, and it will fit next to the â20â label without overlap, so both labels are shown.
This example stands out a little because you have one tall bar of 189 reviews that dominates the view, meaning that a bar of 20 reviews is only a tiny bit taller than a bar of 12 reviews. When youâve cut down the 189-tall bar a bit, the other bars will become taller relatively, and the 17:00 label will fit comfortably below the 18:00 label.
Aside: âOverlapâ is a slightly fuzzy term here, admittedly. A â1â is a bit narrower than a â0â, so even if the text boxes overlap, the character glyphs might not. But to avoid making this check insanely complex, Iâm just using the text boxes that Androidâs font rendering system gives me, even though it can say âoverlapâ when there is no actual visual overlap.
4 Likes
Ah, thatâs, why Iâm only noticing it now. Thanks for the comprehensive response 
Would it be possible to include a mini version of the heatmap in Flaming Durtles? I would love to see the number of lessons I did yesterday and todayâŠ
Sorry, no. That would require collecting and storing individual review records, which would mean a larger database, and a more resource hungry app. I donât want to do that for just a cosmetic feature.
You can already do that, just assign âundo and put back into queueâ to one of the special buttons. It wonât âbreakâ the order you have chosen, but within the current slice of the pie (level, type, âŠ) youâre working on, it will be shuffled in randomly.
2 Likes
Thanks for answering and explaining!
Not that itâs a big big, but if there are two readings of a vocab words, and I type in the one without audio, the app plays the one with audio.
I also noticed that sometimes if I click too quickly on the next key after clicking the enter key on the keyboard to submit my answer, the app sometimes seems to act like I clicked the button to expand the explanation of the vocab word I was on.
Also, expanding on the reordering comment above, would it be possible to shuffle the current items after they have been selected. So if I say order by level and then type, with a limit of 20, it would be nice to mix up the cards in the subset of 20 that were choosen based on that criteria.
WK also does this 
Didnât realize the audio thing was the same on WK. If thatâs the case, I guess itâs not a bug then.
tbf it should be considered a bug on WK too. They even play the wrong sometimes if there are multiple answers
1 Like
Yep, thatâs deliberate. The idea is that if autoplay is on, the user wants to hear audio for the vocab, and some audio is better than none, even if itâs a different reading. This should be a rare thing, since (as far as I know) every reading for every vocab has audio, so this should only ever happen with partially downloaded audio.
Presumably thatâs because you actually clicked that button as far as Android cares. It takes a little time for the system to process your touch events, and if the UI updates during that time, Android may misinterpret those events. And by necessity, after every answer the UI updates. Probably the âShow allâ button just happened to appear right where your finger was over the âNextâ button.
Basically, if youâre faster than your device can keep up with, you need to slow down or enable lightning mode so you donât have to click the next button anymore. I have checks in place to make sure you canât mess up your session by (for example) quickly submitting the same answer twice for a single question, but this is out of my control.
Iâll consider it, but Iâll have to figure out how to present this clearly without a big wall of text. Right now the ordering chosen in the settings is exactly adhered to under all circumstances, and the last thing I want to do is deal with a lot of confused users complaining that their ordering doesnât work anymore. (Especially in email I get a lot of questions/complaints from people who change settings and then call the behaviour they explicitly asked for a bug. I donât want to add to that any more than absolutely necessary.)
3 Likes
Well, just because itâs a bug on the web site, that doesnât mean it should be a bug in FD as wellâŠ
I havenât listened to all vocab audio, but after the big audio update a while back I took a sample and checked how consistent the audio was. And at that time, my conclusion was that a) every vocab seems to have audio for every reading listed, b) audio files all seem to be correctly tagged, i.e. the audio actually contains a pronunciation for the reading it says itâs for.
So unless the app only has partially downloaded audio, the audio played should always match the given answer. (Except in Anki mode of course, where the app will just play the primary reading.) If there are vocab where this goes wrong, either the WK database is incorrect, or maybe there is still a bug for this in the app. If you see that, please let me know an example vocab where this goes wrong and Iâll look into it.
2 Likes
I donât know if itâs the same for the API or if they just removed it from the website, but they have pulled audio from some items for various reasons. They could be fixed by now for all I know, but itâs happened.
Since the big audio overhaul I think the site and the API use the same audio data. And I think it wouldnât really make sense to do it otherwise. But yeah, if the WK database has missing or incorrect audio data, then that will affect the app as well. The app will blindly trust whatever the database says, perhaps to a fault
1 Like
There are still a few items that are missing audio. It only came up because I found one today. The word was ă§ă©ăă. WaniKani / Vocabulary / ćșæ
I checked, and that one indeed only has audio for one reading (the primary one) in the API. I think the secondary reading was only added after the audio overhaul, Iâm pretty sure this is one of the vocab I checked back then.
I stand by my opinion that in a situation like this, some audio is better than no audio, but if the consensus is otherwise I can always change that behaviour.
2 Likes