bug(web): unrelated suggestions in banner for languages (non-Roman script case)

[MakaraSok]

Describe the bug

• For NC Khmer Wordlist, the lm does not give relevant suggestions to what's being typed:

Type ស្រ in the emulator with an Android device selected (i.e. Pixel 2, in my case), then the three suggestions given do not begin with the cluster to the left of the caret, i.e.: ខេត្ត ចេញ ខេមរៈ.

When clicking away anywhere but a key, the expected suggestions of words beginning with the cluster are shown.

Edit by @jahorton: in discussion earlier, the notes above were only noted within Developer's test page, and not within either app. This does not hold for the notes after the break.

---

• The same A different issue happens for the same model and for the Brao Wordlist.

Type ទ្រ in the emulator with an Android device selected (i.e. Pixel 2, in my case), then the three suggestions given do not begin with the cluster to the left of the caret, i.e.: កំឡាំង អំហំប៉ាក អំរ៉ិ.

When clicking away anywhere but a key, the expected suggestions of words beginning with the cluster are shown.

To Reproduce

1. Load the lm
2. Test it on Chrome emulator
3. For Khmer type in ស្រ, for Brao ទ្រ
4. See error

Expected behavior

The expected and relevant suggestions should be shown soon after the cluster is typed, not only when a mouse click is triggered.

---

KeymanWeb:

• OS: Windows 10 Pro 20H2 x64
• Browser: Chrome Version 90.0.4430.85 (Official Build) (64-bit)
• KeymanWeb Version: 14.0.271
• URL: n/a

Keyman Developer:

• Keyman Developer version: 14.0.271

---

Keyboard

• Keyboard name: khmer_angkor | sil_brao
• Keyboard version: 1.0.9 | 1.0
• Language name: Khmer | Brao Lave

[jahorton]

Those are two separate bugs; the Brao one follows a very different - and far more easily identifiable - pattern.

[jahorton]

I believe the rest of this is waiting on #5025, at least for full, proper support. Languages without space-based wordbreaking are currently undersupported by our predictive text engine. It's possible to make a custom implementation, though that does require very significant effort.

[jahorton]

We're just coming off of a sprint that addressed a fair few related issues, up to and including the introduction of #7279. We still don't have actual dictionary-based word-breaking support yet, though.

[mcdurdin]

Tracking in #5025, closing this one.