Closed Bug 1160045 Opened 10 years ago Closed 7 years ago

[Keyboard User Dictionary] Favor user words with spaces inside when autocorrecting

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: mnjul, Unassigned)

References

Details

From QA's comment at bug 879145: (In reply to Joshua Mitchell [:Joshua_M] from comment #22) > Hi Jon - I did have a bit of feedback on this feature - It does not seem to > handle 2-part words well if they include a space. For example: If I add 'zug > zug' to my dictionary, and then launch sms and begin typing, after I type > the first 'zug' and hit space it corrects it to 'zig'. > If the feature is not meant to handle words with spaces in them - it might > be a good idea to either disable the space-bar input for the add word screen > or provide a warning that it might not work for words containing spaces. > I realize I'm probably mis-using the feature here but I imagine some users > might expect it to accommodate phrases as well and might interpret it as > not-working-correctly. And UX's opinion: (In reply to Omega Feng [:Omega] [:馮於懋] (please ni?) from comment #25) > I prefer to keep space support in the user dictionary. I think it's about > the priority score each candidate gets. Can we make some tweak on the > scoring mechanism to increase priority of user-defined words? I think a way is: when we're going auto-correct when spacebar is pressed, we see if suggestions from user dictionary contain a space, and if affixing this space to user input will *not* count as a correction in the prediction engine (i.e. such suggestion will be kept when user continues typing into the final, complete word). If so, we don't auto-correct to the built-in suggestion. However, this is only the "make a correction from prediction engine" path. The "send user input to prediction engine" path must be modified too: since we only retrieve the current user input word by looking back until the first non-character (e.g. space) (i.e. if a textbox has "user feedb|" and the cursor is at "b", we only retrieve the user input word back beginning at "f" as we assume everything before the space has been correct). So, when user types "zug z|" and we're predicting at cursor position of (the second) z, we must know to retrieve the current user input word back beginning at the first "z" (this knowledge may be gained by setting a flag when we bypass autocorrection when the user types the space) This is my rough idea on the paper -- not sure how it's gonna work in real implementation.
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.