fix(web): fixes subkey lookup for fat-finger processing

[jahorton]

Fixes one part of #4953 - from the third screenshot onward.

Turns out that subkeys couldn't be "looked up" during fat-finger alternate computation, so their entries were never available as prediction roots. This is easily fixed by 'namespacing' popup key IDs in order to forward the lookup operation appropriately.

[mcdurdin]

LGTM.

Please cherry-pick to stable-14.0 😸

[keyman-server]

Changes in this pull request will be available for download in Keyman version 15.0.33-alpha

[MayuraVerma]

Is this done based on the key position or can we specify the alternate keys/characters in the keyboard definition

It would be very useful to define the alternate keys/characters in keyboard.

[mcdurdin]

Is this done based on the key position or can we specify the alternate keys/characters in the keyboard definition

This is a fix for the algorithm that tests key distance only. There is no way to specify alternates in Keyman 14.

[jahorton]

It would be very useful to define the alternate keys/characters in keyboard.

Could you give some specific examples where you feel this would perform better than the current approach?

---

Note that lexical model developers can include functionality to assist this:

keyman/common/models/types/index.d.ts

Lines 122 to 141 in 662e221

	/**
	* Indicates a mapping function used by the model to simplify lookup operations
	* within the lexicon. This is expected to result in a many-to-one mapping, transforming
	* the input text into a common, simplified 'index'/'key' form shared by all
	* text forms that a person might reasonably interpret as "the same".
	*
	* Example usages:
	* - converting any upper-case characters into lowercase.
	* - For English, 'CAT' and 'Cat' might be keyed as 'cat', since users expect all
	* three to be treated as the same word.
	* - removing accent marks that may be difficult to type on standard keyboard layouts
	* - For French, users may wish to type "jeune" instead of "jeûne" when lazy or
	* if accent marks cannot be easily input.
	*
	* Providing a function targetted for your language can greatly improve a user's experience
	* using your dictionary.
	* @param text The original input text.
	* @returns The 'keyed' form of that text.
	*/
	toKey?(text: USVString): USVString;

For the current WordList model, this is specified via this property:

keyman/common/models/templates/src/trie-model.ts

Lines 50 to 53 in 662e221

	/**
	* This should simplify a search term into a key.
	*/
	searchTermToKey?: (searchTerm: string) => string;

Our current approach asserts that the lexical model is a more reasonable location for these decisions to be made, as there are a number of published keyboards that support multiple languages. Some languages may be more "picky" about their alternates.

[MayuraVerma]

Hello @jahorton

Here is the discussion
https://community.software.sil.org/t/improve-suggestions-corrections-based-on-context/3167

we want to be able give list of alternate characters in dictionary for a particular language, which will help correction/suggestion code to look for words in the dictionary.
this alternate characters can be adjacent keys in the keyboard layout
or
usual suspect/expected typos in script

[jahorton]

If I understand you correctly... it sounds like the simplest solution would be to offer a similar function to the one I mentioned above, but where this one would denote a 'correction' instead of a 'completion'.

While not yet offered, this proposal could be used to 'mix in' known correction patterns that don't otherwise arise from neighboring keys.

[jahorton]

On the other hand, I can't help but notice that in your link, the replacements are specified in pairs. Is this similar to the case mentioned here?

keyman/common/models/types/index.d.ts

Lines 133 to 134 in 662e221

	* - For French, users may wish to type "jeune" instead of "jeûne" when lazy or
	* if accent marks cannot be easily input.

There's no normal û key on a lot of keyboards, so a later keystroke is used to transform a u into a û.

If you expect a keyboard for your language to do something similar, and the keys really are that related, searchTermToKey is the answer you're looking for. You'll want to write one customized for use with your language. Heck, I could take a bit of time to write up an example one based on your spec. I'm technically on another project this week though, so it'll have to wait until I'm back on this one.

[mcdurdin]

If we want to pursue the second half of this conversation, we'll need to turn it into a separate issue, otherwise we won't be able to track it!