Implement Japanese keyboard

[keianhzo]

Fixes #974 Added support for Japanese keyboard romanji to kana and kanji conversion through openwnn.

[MortimerGoro]

Adding @takahirox as reviewer :)

I think it would better to add the openwnn dependency in a separate repo: e.g. another submodule. We can create a public third party folder for this kind of dependencies. I wish it could be included using maven.

[daoshengmu]

I'm also thinking that openwnn should be put at another repo, and it asks me upgrade my CMake to 3.10.2 for building it.

[keianhzo]

@MortimerGoro Removed OpenWnn from the project and refactored it to a maven artifact at JCenter as it's the default gradle repository.

[MortimerGoro]

I tried to write nihao (which is hello in Chinese, not sure what would produce in Japanese), but the app freezes when I type the a

[keianhzo]

@MortimerGoro it should be fixed now

[daoshengmu]

First of all, I guess the Gobutton is translated to 移動 in Japanese seems not right. @takahirox might can provide his thought.

Then, Switching to the symbol keyboard, I don't think we need to use candidate and auto-complete mechanism to try to make a word here, just insert it to URL bar like what we did in Traditional Chinese keyboard.

Third, when taking a look at the design document, I saw the orange highlight in the candidate list needs to move to the next item when users press the 次變換 button. Traditional Chinese keyboard also needs to follow this rule, but we haven't started to refine it yet.

[takahirox]

First of all, I guess the Gobutton is translated to 移動 in Japanese seems not right. @takahirox might can provide his thought.

I think it isn't too bad. And in my IME on my iPod touch, it's translated to "開く" (open). It may be also good.

BTW, I found two problems in textarea form which accepts multiple lines. First, "Enter" isn't translated. Maybe it should be translated to "改行" (new line). Second, even I press enter key, a new line isn't injected.

[keianhzo]

@takahirox @daoshengmu I've updated the PR and added support for continuous clause conversion.
Now space iterates over the candidates and enter selected one and commits the clause. Let me know if this sounds better to you.

[daoshengmu]

I just had a quick check. Trying type nihon, it will show 日本 and following items. Then, pressing 次變換 button a couple of times. It will jump to the next page, then we can't return to the keyboard. (I am concerned if we shouldn't implement this feature, it makes other logic errors we need to handle,)

Then, trying to type nihon again, it can't show 日本 anymore. It is because your index has pointed to the next pages.

Besides, it seems like in the symbol keyboard and some special symbols +/？＠, we don't need to do candidate suggestion, but Pinyin did it and Zhuyin didn't, so I have no idea if which one is correct, we need to do more research.

[daoshengmu]

And it will cause a crash in this branch when using Pinyin input, the possible STR:

1. typing a couple of letters with the alphabetical keyboard.
2. Switch to the symbol keyboard, typing a few symbols. Then a crash will happen.

I checked master branch, there is no crash. The report is as this link, https://crash-stats.mozilla.com/report/index/4892a2f3-8abc-4ad6-ac97-cf2f30190618

[keianhzo]

@daoshengmu Not sure if I understand the case you are explaining but I have made a fix for a related thing that avoided the clauses conversion to finish when a new word is typed.

Then, trying to type nihon again, it can't show 日本 anymore. It is because your index has pointed to the next pages.

I agree, we would need a smaller candidate view for iterating over the candidates and a bigger one to show all the available ones. That's how the Google keyboards do it. Sadly we don't currently have a spec for that and we are not doing it for any keyboard so for the moment I'd keep it as is. When the full candidate list is shown you can no longer press space/enter but you can just choose the candidate from the list using the pointer so I think it's not a blocker. I'd open an issue to implement this in all the keyboards as it's the standard behavior.

Besides, it seems like in the symbol keyboard and some special symbols +/？＠, we don't need to do candidate suggestion, but Pinyin did it and Zhuyin didn't, so I have no idea if which one is correct, we need to do more research.

The behavior I've observed in the Google keyboard is that if you switch to another keyboard layout the current conversion ends and the default candidates for the clauses are displayed. On the other hand if you insert the number using the key pop up it's added to the composing text. We will probably need to implement both behaviors but I prefer to do that across all the keybards so the behavior is consistent. I'll open an issue for that too.

Regarding the crash, it should be fixed after the latets commit.

[daoshengmu]

An another crash is still happening, https://crash-stats.mozilla.com/report/index/cc453a4c-374d-4ea1-8824-036060190620

STR:

1. typing niho.
2. clicking 次變換 a couple of times, then crash.

I would like to suggest to remove the function of choosing candidates when clicking the space key 次變換. It causes issues and crashes, we can support it at other PRs once we figure out the consistent behavior among different keyboards.

I would expect we can merge this JPN keyboard as soon as we can.

[keianhzo]

@daoshengmu I've made a fix for that crash. I've also sent an APK to @takahirox I wanna hear his thoughts about the current continuous conversion implementation to see if it's worth merging it in the current state, otherwise we can roll it back and add a task for adding it to this and other keyboards in the future.

[keianhzo]

@daoshengmu I've rolled back the continuous clause conversion until @takahirox is back. If everything looks ok feel free to merge.

[daoshengmu]

LGTM. Let's merge it. Great job!

[MortimerGoro]

Looks good, let's merge it!