Closed Bug 981602 Opened 7 years ago Closed 3 years ago
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*
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.
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.