Investigate local autocorrect / autocompletion algorithms

[dessalines]

A few for java:

• https://developer.android.com/develop/ui/views/touch-and-input/spell-checker-framework
• https://github.com/C-FWES/AutoCorrect
• https://github.com/TeodorDyakov/autocorrect
• https://github.com/GameGenesis/java-autocomplete

Dictionaries:

• https://github.com/dolph/dictionary
• https://www.freedict.com/

[Zireael07]

Speaking of, I find that it autocorrects i to I, which is annoying when I happen NOT to be writing in English...

[dessalines]

Currently that's part of auto-capitalize, but I agree, it should be removed as its correct only for english.

[DeflateAwning]

This would be great!

[racuna]

IIRC MultilingO stores couples of words locally and then a number of occurrences to build a pseudo-smart word prediction: e.g. "I want a beer".

I:want:1
want:a:1
a:beer:1

"I want to walk"

I:want:2
want:to:1
to:walk:1

So, the keyboard could suggest "want" after the user writes "I", then, if the user accepts: "want", the keyboard could suggest "a" or "to" because they both have the same "weight" of 1.

[DeflateAwning]

That seems like a really effective way to store and query this info, and could provide huge value at little complexity.

[racuna]

And can be backed up in plain text

[DeflateAwning]

Ideally, we'd provide an encrypted backup option too. I wouldn't want my typing history stored in plain text, I don't think

[racuna]

yeah, of course. I meant about having it backed up locally and "editable"

[cyxae]

The AOSP keyboard https://android.googlesource.com/platform/packages/inputmethods/LatinIME/ has a nice autocorrection/autosuggestion feature, that may be another option to consider ;)

[uniquePWD]

I wanted to revive this conversation by introsucing a repository. https://github.com/fengjian0106/Minuum-Fleksy-Fuzzy-Matching

Could this be helpfull? I think, maybe so

[Geobert]

That’s the reason I gave up on MessagEase in the first place. With open source alternative, my hope of using this kind of keyboard is back alive :D

[breversa]

Agreed! :-)
Not having autocorrect/autocompletion is the number 1 reason why I haven’t switched full-time to Thumk-Key. :-|

[Hate9]

@pwd-github probably not? I'm pretty sure the main benefits of what minuum does rely pretty heavily on a keyboard where the only input is tapping. could be relevant though, and it's certainly an interesting resource.

[Hate9]

ooo, an "on-the-side" option would be perfect, yeah!

…

On April 26, 2024 4:23:05 AM EDT, cbiere ***@***.***> wrote: Not sure whether this is whithin scop of this issue but I suggest it anyway: Could the unused half of the keyboard area be used to suggest the next characters and words based on previous input and generic dictionary as a starter? Having to type each word individually helps practising the system but it is also a huge slow down. -- Reply to this email directly or view it on GitHub: #44 (comment) You are receiving this because you commented. Message ID: ***@***.***>

[seguri]

hey everyone!

I've just finished adding autocompletion to my fork. It's more of a PoC rather than a full product, but it shows what can be done (and it's fully working) :) I've spent no time tweaking the graphical appearance of the buttons. Right now I'm using a custom dictionary defined with some Italian words. An example:

[dessalines]

Nice!

It'd be a good idea to show the suggestions above the keyboard, like a lot of the other ones do.

I did some searching around, and unfortunately it doesn't look like android gives access to anything but the user dictionary: https://developer.android.com/reference/android/provider/UserDictionary.html

So we might have to think about the best ways to either import or bundle dictionaries into thumb-key.

[Hate9]

I think on-the-side makes a lot of sense for a lot of use-cases, but I think we should probably have it be a settings toggle. For a lot of phones, you won't be using that space anyway so it's a great option, but for (for instance) mine, that space is smaller or otherwise needed (to say nothing of the two-hands layouts).

[Hex5DA]

some ideas i had a while back, maybe a bit overreaching for this discussion. if they're irrelevant lmk.

• the middle button in the 3x3 (or the spacebar?) autocompletes the next predicted word
• the angle which a swipe needs to land in to type a character grows/shrinks if that character is more/less likely to be the next character
• the list of contender words for autocompletion is shown to the side of the keyboard (not above)

[racuna]

So we might have to think about the best ways to either import or bundle dictionaries into thumb-key.

Hi, there's a OSS project with dictionaries: GNU Aspell

https://ftp.gnu.org/gnu/aspell/dict/0index.html

[dessalines]

Once @seguri has their PR ready to look at, we can try to integrate that in some way.

[seguri]

What features should my fork integrate to consider it a sufficiently valid PR?
The purpose of my fork was primarily to tackle something I had never done before: passing data around with idiomatic Android data structures and building a simple autocomplete engine. I consider it complete for developers who can take my fork and write their own dictionary to get autocompletion.
I fear that getting my code PR-ready might require lots of time (80% of the time to complete the last 20% of the work, as per the pareto principle).

[dessalines]

Start the PR and mark it as draft and we can go over what else it needs.

[jm355]

One thing that might be good is a gesture to select the suggestion. If three suggestions get displayed, you could use the top row of gestures in the top left square, where the top left corner selects the leftmost suggestion, top middle selects the middle suggestion, and top right corner selects rightmost suggestion

[Atemu]

Perhaps gestures could be used to select different forms of the same word such as tenses or cases. E.g. typing brea would offer "break" and swiping e.g. right would produce "breaking", up "broke" etc.