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
