It's simpler to check the safety net directly inside the
function that checks for auto-correction threshold.
This introduces one very slight change in behavior. The value
checked by the safety net is not any more the "typed word" but the
"considered word", the difference being any possibly appended
single quotes.
E.g. the user types "this'''" : the typed word is "this'''" but
the considered word is "this".
This change in behavior can be considered a bugfix.
Change-Id: Ia7ab4bc933183dfbd41bb00328e4c0b5ab76bc63
We internally use the string "zz" to mean no locale, but
the user dictionary service does not understand that and
words added with this locale pitifully end being added to
a "zz" user dictionary, which makes no sense to the user.
This change fixes things so that words added when the
keyboard is in a "no locale" layout, the words are added
to the global, all-locales user dictionary.
Bug: 6645306
Change-Id: Iec3cdd1fe3d5bc43427a43ef9ae9bf89e12be1f2
If allowsAutoCorrected is false, there is no point in making
hasAutoCorrection true, since in the only place where we use
it again, it's &&'ed with allowsAutoCorrected !
Well that was extremely obscure, good thing refactoring allowed
to realize this was useless >.>
Change-Id: I34936d445f1ced17c7bd04a9524bf608f9e8b9c8
The test against hasMainDictionary is a test to know if we should
auto-correct or not. Its result should be recorded in
hasAutoCorrection, not in allowsToBeAutoCorrected.
Actually, this value being inserted in allowsToBeAutoCorrected was
causing a bug that nobody noticed: when typing in a language with
no dictionary, the word in the middle of the suggestion strip would
always be bold, as if it was going to auto-correct to itself !
This change fixes this bug.
Change-Id: Ia1f08efd7089b9c5cbede910c5b0951d83e698d2
The goal here is to disambiguate TypedWordValid and
HasAutoCorrectionCandidate. Ultimately, HasAutoCorrectionCandidate
will disappear.
Bug: 6705473
Change-Id: I1acbd0a5efc7f4bf7b0bdb12839fe3d84e9d1dda
TypedWordValid and AllowsToBeAutoCorrected are almost the
same thing; the difference is whether the word is also a
whitelist entry or not. In this case, TypedWordValid was
the right one to test.
Change-Id: I695fe5b9f6bbe9d3ba314c646da3a25742c9f4ed
isWhitelistedOrNotAWord takes an 'ignoreCase' argument. By looking
at the contents of the wordcomposer here, there is only one case
where its output will be different : when the word is typed with a
capital, but the lower case version exists in the dictionary.
E.g. the user typed "This".
In this case, isWhitelistedOrNotAWord in line 235 will return false
instead of true, so the test will score a true instead of a false,
so hasAutoCorrection may be true instead of false in this specific
case and that's the only case where it's different.
But in this case, allowsToBeAutoCorrected is certain to be false,
which means the result will not have changed if hasAutoCorrection
was true in the first place. So in the end this change is sure not
to change the behavior.
Change-Id: Ic41cf959c20c19165f84d9b8ff006731fa595d84
There is no reason to prevent 1-letter words to auto-correct
to themselves, or to dictionary words. Don't do it.
Change-Id: Iceada847ae632336026ada29afed0353cd9c51b5
If a word is a dictionary word but still has no suggestion,
this method should return true. In the practice, it makes
no difference since a word without suggestion won't be changed
anyway.
Change-Id: Ib1f5ef254b7da7e5cedb2f973529ad431beb93f9
allowsToBeAutoCorrected always returns false if the word is empty.
This is because the whitelist never contains an empty string,
and isValidWord returns false if the word is empty.
Change-Id: I34ecc2a1563aea6db5b2f12796f251f6598576a2
