Bug: 6435484
Change-Id: Iffe459c117ad438e96ec6f5c7e64fb80b32d227e

This is a follow up of Id962e670.

Change-Id: I9e8542bff9e8faf57f934051fe612463c99ad61f

Change-Id: Ibc2d28f9f95966f77d4d7bdf9ae4688baaed5989

...if there aren't any for the exact case version.

Bug: 6752830
Change-Id: I2737148b01ba04a64febe009ceb2ef53c265d224

Change-Id: Ie6af46acba18a2d1cf3ddd1578d60ded4c90f89a

Change-Id: I722b9e981389f660db928b7fd5ced1b82371fbf3

Change-Id: Ie8792f4f5d3593c25c992fc72cf219daeaa70beb

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

Change-Id: Iec791d061f237f60992dd6048c4a37b46f4cb9aa

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

Change-Id: Ib0b6f36999518096819ada2f19365767cb5f9931

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

Change-Id: I3c45b5a6571f986acc7adb3a8fe17b210303f7ea

Change-Id: I2b2ab99e801fa8b4b30eab16a8aefb8cfe104ba9

Change-Id: I4833ca7e057b8c1f1f22390673cbca0d2433b1bd

Bug: 6705473
Change-Id: Ib6260034b09739b60071e90a018b2dc6be3815d7

Change-Id: Ib4a8f41dc5941bce46402e1a41a6c21dccb0601f

Change-Id: I9b5a0e34529724984aad1e2bf99b3e00f8ed0dd7

Change-Id: I95300bf0a847fb86d026e846ff4ad723bb45284f

Change-Id: Id962e670ee1a5164e6c69deb84625139bf5e7974

The goal here is to disambiguate TypedWordValid and
HasAutoCorrectionCandidate. Ultimately, HasAutoCorrectionCandidate
will disappear.

Bug: 6705473
Change-Id: I1acbd0a5efc7f4bf7b0bdb12839fe3d84e9d1dda

Change-Id: I35c2ba4caf6be4ba0449e11c0597ae8e468c0e6e

Change-Id: I9e4d030974ccec1a6256de6ca87610870e404149

Change-Id: I41b413986a3c5bb6697bb7bbced17ed1e361913c

Change-Id: I1d7790289635729645995fb8c38868259ab1b3be

Change-Id: I52625e707abf61da9b95e542f0814c66b532f483

Change-Id: I1058123d233540fb72a94028987a43740224f635

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

Change-Id: Ia356130b8a95ec9cf676bc6be05d801c13f14b64

Change-Id: I6f569322e645d36bc82fddf4ec2fd621972e3b47

Change-Id: I1df4cef5ae2736a22273843dce67f0012181bfd3

Change-Id: I901e6b0e2b994128da19d68233b9f68bb308cb95

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

Change-Id: Ifc37462f5243563693c8cd7cbeb401ff054daa52

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

Change-Id: I0b8c06d1fd0bfb3caf363c048acc7048abed1752

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

This will allow us to remove unnecessary processing

Change-Id: I251dfdaffb077906186686ebe65fd82e1e360bd2