Closed Bug 981602 Opened 7 years ago Closed 3 years ago

Autocorrect bugs

Categories

(Firefox OS Graveyard :: Gaia::Keyboard, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: janjongboom, Assigned: janjongboom)

References

Details

In general the autocorrect feature is in my way a lot more than the Android one. Here is a list of autocorrect mistakes I found so I can fix them.

Input            Suggested          Should be
--------------------------------------------------------------------
kn               km*                in* (because in has freq 210, km has 155)
dis              disc*              did* (160 vs 128, plus word length mismatch)
Ohja (dutch)     opjagen*           - (big word length mismatch)
norgweian        -                  Norwegian*
asjan            Ashanti*           Asian (126 vs 77, plus word length mismatch)
nauhhtt          naught*            naughty* (Is in dirty words filter, but shouldnt)
flr              DLR*               for* (196 vs 83)
hllland          hollandaise*       Holland (110 vs 40, plus word length mismatch)
Odnt        Isn't*         Don't*
See Also: → 1048792
dis, hllland and ob/on have been solved in bug 971688. The others are because we value keys that are close horizontal more than keys that are close vertical.
(In reply to Jan Jongboom [:janjongboom] (Telenor) from comment #2)
> dis, hllland and ob/on have been solved in bug 971688. The others are
> because we value keys that are close horizontal more than keys that are
> close vertical.

Thank you for these specific examples and this particular horizontal/vertical analysis.

As you've probably seen, the weights are based on the actual pixel distance between the keys. Keys are closer together horizontally than they are vertically. Also the examples you give are typos between the top two rows where the keys are offset horizontally from each other, so the distance is diagonal and even longer.

We assume that the error rate is strongly correlated with key distance. But this is without testing and it could well be that the way we hold our fingers when we type actually makes it harder to see the keys above and below the one we are aiming at.

In any case this suggests to me that we've got a weighting problem here. For the "kn->km" instead of "kn->in" case the difference in the distance weights of n->m and k->i should not be greater than the difference in word frequencies.
The kn->km correction may also be due to the fact that we don't allow substitutions for the first letter.  I think there is commented code somewhere in the prediction engine that says we're assuming that the user typed the first letter correctly.  If that is not valid, we should revist the assumption. But I think it is there to prevent the size of the search space from blowing up.  If we allow the first letter to change, then any time the user starts a word with Y, we also have to consider the (very common) words that begin with T.

So my point is just that getting kn to correct to in instaed of km may be harder than the others where the first letter does not change.
I have a patch for the vertical stuff in bug 1048869.

After some consideration and testing against that branch yesterday I think that 'km' is correct, but that 'in' should be second and 'on' third suggestion.
Blocks: 1055976
See Also: → 1055976
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.