New UI Option for Mobile Users - Force Input

I think it would be nice to have a button on the UI when reviewing/doing lessons on mobile to force hiragana or katakana input regardless of the keyboard capitalisation. If this was done, I wouldn’t have to change my keyboard settings or have to worry about hitting shift two times every time I want to type in a reading. I’ve already gotten quite a few reviews wrong because of this. Hitting shift on a computer is much quicker and easier than clutzing around with thumbs on a touchscreen.

It’s quite time consuming to do this, making an already large pile of reviews take even longer. Just a suggestion, but I think it could make our WaniKani experience a lot smoother when on the go and doing reviews.

In summary, a toggleable button that forces input to either hiragana or katakana depending on the toggle status, regardless of keyboard state or capitalisation. Well, thanks for giving this a read.

1 Like

You can always answer in hiragana so this should not be a problem. Alternatively you can use a userscript (android browsers allow that) or allicrab on iOS to correct genuine mistake. Allicrab also fixes problems with shirt, dunno could also exist as an android app.

1 Like

WK actually uses an input field with the following options: <input autocapitalize="none" autocomplete="off" autocorrect="off" spellcheck="false" id="user-response" name="user-response" placeholder="..." type="text" lang="ja">

You could also blame Chrome for not honoring valid settings (on iOS it does Autocapitalize for mobile - Chrome Developers).

In general the keyboard is a very restricted area for websites because you could fake a keyboard and steal passwords, if it is not supported by the OS there is no chance to change this.

1 Like

It’s a more complex issue than I thought then. What am I supposed to do, just use an IME? I was hoping to avoid that since WK goes to the trouble removing the need for one on a laptop.

WK uses a custom kana conversion, I actually don’t see a need to produce katakana at all. Your idea should work by changing that in-browser conversion, now that I think about it :slight_smile:

1 Like

This is exactly what I was thinking.

Wk uses an old version of WanaKana which converts “Ka” to katakana, but they can upgrade to WanaKana 3.x which only converts if both chars are caps (“KA” but not “Ka”) which sidesteps the initial capitalization issue.

Though there’s currently a bug with ‘n’ + consonant which is more inconvenient than the caps issue that I need to fix. So ideally they should wait for the next version instead.

It would solve this annoyance though.


That’s a very clever way to fix the problem and still preserve the caps lock for katakana. I look forward to the future updates.

Wow! I didn’t even know that was an issue! Is this on all android phones because I haven’t encountered this before.

Just did some reviews on Chrome Android with auto capitalization on and it worked, not sure under which circumstances it happens.

1 Like

Maybe it depends on the keyboard being used too. @Krispy Can’t hurt to try a different keyboard just to see if that helps.

It will, some of them don’t care where they are inserting text.
From memory, one of swiftkey or swype ignored input attributes.

My keyboard is a Swiftkey keyboard and it’s the only one that I’m going to use without having to have multiple keyboards installed. Plus, I don’t see how it makes a difference since all keyboards should autocapitalise. I want my keyboard to autocapitalise. It makes good sense when typing literally anywhere else. The issue is that I don’t want to have to go trawling through my keyboard settings to toggle that setting every time I start and finish a lesson or review (or hit shift two times which is very clumsy on mobile). The native WK experience is so good currently that scripts aren’t necessary, they’re an optional add-on.

The philosophy at WK seems to be that the user shouldn’t need optional extras unless they want them, that’s why there’s a native kana converter. If WK has gone to that much trouble, it only makes sense to go the last 10 yards and to fix the last few kinks and make the system practically perfect. Hence, it makes sense to fix this issue natively rather than find user-end solutions.

I don’t know a huge amount about keyboards or website coding though, so there’s likely a lot of potential roadblocks such as in the way as Subversity mentioned. It would be very unfortunate if a SwiftKey keyboard proved to be particularly difficult to work with because I’ve found it’s much preferable to Google keyboards or any other market alternative, in my personal opinion.

Let me clarify. Keyboards should autocapitalize unless the HTML input tells them not to. The WaniKani input tells the keyboard not to, but your keyboard seems to be ignoring that suggestion. If that’s the case, it’s a problem with the keyboard, not WaniKani. And there’s nothing WaniKani can do to force all keyboards to do the correct thing.

I wasn’t suggesting that you use another keyboard always or even keep it after testing this once. Rather I was suggesting that you try another keyboard just to verify that it’s a problem with your usual keyboard. If you verify that it’s a bug with the keyboard, you could even submit a bug report to the keyboard maker if you wanted, letting them know that they ignore the autocapitalize attribute on inputs.


Thanks for the explanation. I’ll do a test later then and find out definitively whether it’s specifically the SwiftKey keyboard that’s the problem.

However, I still think that this problem can easily be fixed on the WK side for all mobile users irrespective of their keyboard, as Subversity mentioned. It shouldn’t matter what I input into the text field, the website can still choose to change it to hiragana when it should be hiragana regardless of the keyboard capitalisation. Rather than forcing the keyboard to do anything I’m just suggesting that the WK coding recognises that the first character of a word is incorrectly capitalised into katakana and changes it to hiragana. This doesn’t change what the keyboard inputs, only what WK displays and accepts as an answer.

Apparently it depends on the specific keyboard installed.

Some words on WaniKani allow you to use katakana. They take hiragana as well, but the katakana is technically correct. I think it would be unfortunate to not even allow the actually correct answer by always converting to hiragana. (I mean sure, I could still get katakana using an IME, but to your point earlier that kind of defeats the purpose of WaniKani having a built-in converter.)

For example: アメリカ人. アメリカじん is really the correct answer, but they also accept あめりかじん for convenience.

1 Like

I’m wondering if this is the same thing you’re talking about:
When I run:


I get おかあさんん, where I expected おかあさん.

In my Self-Study Quiz, I’m checking if the user answered with ‘reading’ when the ‘meaning’ is requested. Mostly, it works okay, but the ‘nn’ doesn’t translate as I expected. But I figured maybe the toHiragana() function expects a particular romanization format, rather than the specific keys you’d use in the IME.

@seanblue The fix that Subversity mentioned completely sidesteps this issue, while preserving the abilty to input katakana. I guess it’s just a waiting game until future versions allow the problem to be addressed.

I mentioned in another thread that the Android WK App can replace the IME with its own. It doesn’t allow you to type katakana at all, but it doesn’t have this bug :slight_smile:

(All the words that have katakana accept hiragana as well)

1 Like