bug(android): Casing questions on the suggestion banner

[darcywong00]

Running 16.0.138 stable in the Keyman for Android app, I encountered some scenarios that look curious:
(Not sure if any is related to #7165

Scenario 1 - "Hello" suggestion is capitalized

Typing "hell" results in the suggestions: hell, Hello, hella. I'm confused why "hello" is always capitalized. This isn't at a start of a sentence.

Scenario 2 - "Hello" moves from middle to left position

From scenario 1, leave the device inactive until the screen lock kicks in. After unlocking the screen, the suggestions refresh to: Hello, hella, helluva

I haven't tested on other platforms to see if this is only on Android
I built stable-16.0 and tried mobile viewport of web/testing/prediction-mtnt and it shows "Hello" in the middle too

[darcywong00]

OK examining the mtnt.tsv word list, it uses "Hello". (Also "Yep")

https://github.com/keymanapp/lexical-models/blob/master/release/nrc/nrc.en.mtnt/source/mtnt.tsv#L2609

https://github.com/keymanapp/lexical-models/blob/master/release/nrc/nrc.en.mtnt/source/mtnt.tsv#L1618

I thought predictive text lower-cases all the words though?

[mcdurdin]

I thought predictive text lower-cases all the words though?

Upper case suggestions remain upper case (for proper nouns in many langs). Otherwise case matches context.

[darcywong00]

Upper case suggestions remain upper case (for proper nouns in many langs). Otherwise case matches context.

OK, I've updated keymanapp/lexical-models#178 to cleanup the capitalizations there.

Then this issue will remain for tracking down why the Android app resumes and moves suggestions over. (Scenario 2)

[darcywong00]

I can repro scenario 2 on Keyman for iPhone and iPad 16.0.138.

Is predictive text doing something different when resuming?

Is this an issue with the Android and iOS apps, or KeymanWeb?

[darcywong00]

To triage again in A17S7

[darcywong00]

Then this issue will remain for tracking down why the Android app resumes and moves suggestions over. (Scenario 2)

I added logging and on resuming the Android app, I see languageProcessor.invalidateContext() is getting called.

[darcywong00]

Bumping back to 17.0 for @jahorton to look at when modularization refactor is completed.

[jahorton]

Is predictive text doing something different when resuming?

Sorry, didn't notice this issue until now. The very likely answer is yes, it is doing something different. You should get very similar results if you change the caret's location and then place it back at the end of the context.

The big distinction I'm noticing here: hell - the actual typed text - is being removed as an option when resuming. It's what's already there, and there's no need to modify anything. On resuming, it's not like you just typed it; simply "doing nothing" is sufficient to leave it in place.

When actively typing, we present a 'keep' option if it does indeed match a word in the lexicon when including the keystroke just typed. ("Hell" is a valid English word.) On context-changes, though... it seems like the "keep" option isn't being generated or returned, for whatever reason. (Note: "resuming" is acting like a context-change.) Thus, that option disappears and the other options slide over.

[darcywong00]

Sounds like the suggestions are presented as designed.

Resuming = context-change = not typing anything for the "keep" option.
Can close