Skip to content

Feedback : Word Suggestion : Look at the last two words instead of one for predictions & corrections #334

Description

@mastertrivia

Note :- This is an optional feature request rather than a critical issue. If you consider this outside the scope of Dictate Keyboard or not important enough to implement, please feel free to close this issue without implementing it. I am mentioning it only as a possible enhancement that could make the keyboard more complete and useful.

Hi! I've been using this keyboard as my daily driver for a while now, and I genuinely think the correction quality and the learned-words handling are among the best I've used on Android. This post is just one idea that came out of daily use — feel free to ignore it completely if it doesn't interest you, I won't take it personally.

What the engine does today (as I understand it)

When deciding what to suggest, the engine looks at the word right before the one I'm typing, in two places:

  1. Next-word prediction — after a word is finished, the strip shows words that usually follow it.
  2. Correction re-ranking — when I mistype, candidates that commonly follow the previous word get a small boost over candidates that don't.

The context in both places is a single previous word (bigram statistics).

Where one word of context runs out of information

One word is a strong signal most of the time — but it's almost worthless after extremely common words, and everyday typing is full of those moments:

  • After "in the", "at the", "on the", "to the" — the word "the" follows hundreds of different words, so the model cannot tell "in the" apart from "at the". All of them get basically the same generic strip.
  • Typing "there/their" after "looked at" — "at" alone barely narrows anything down, but the pair (looked, at) is a strong signal for "their".
  • "going to be" vs "want to be" — same last two words, completely different continuations, decided entirely by what came before them.

These are exactly the moments where some modern keyboards (Gboard, for example) feel a step ahead — not because their dictionary is bigger, but because they look one word deeper.

The idea

Condition on the last two words instead of one, using a table of three-word phrase statistics ("w1 w2 w3" → count). Concretely:

  • Plug it into exactly the two places the current single-word bonus already lives. Nothing else changes — not the learning engine, not the slip/typo detection, not the dictionaries, not auto-commit.
  • A missing entry changes nothing: if the two-word phrase isn't in the table, the score is exactly what it is today. The signal is purely additive — it can only re-rank candidates the engine already found, never invent new behavior. Worst case, the keyboard behaves exactly as it does now.
  • Where one-word and two-word evidence disagree, the two-word evidence should win — its presence already proves the phrase is real and common.

What the data looks like (the honest part — this is where the work is)

  • A pruned table of the top ~100–300k three-word phrases is only a few megabytes, and it covers exactly the everyday phrases ("in the …", "one of the …", "going to …") where the win lives. Rare phrases contribute nothing; dropping them is what keeps the file small.
  • The counts can be generated offline from free public sources — Google Books N-grams and Wikipedia dumps are public and free to build from. Nothing needs to come from any app or closed source.
  • The format is language-independent: one generator, one reader, one per-language data file. That means it can ride the same download-on-demand path the glide dictionaries already use, and any language gets it later without code changes.

Pros, as I see them

  • Predictions after common function words stop being generic — for me the biggest day-to-day "feel" upgrade available.
  • Confusions like their/there, then/than get settled by context more often instead of falling back to raw frequency.
  • Universal by design — every language benefits once its data file exists.
  • Zero risk to what already works: it's an add-on tier that degrades to current behavior when it has no evidence.

Costs, honestly

  • The offline data pipeline (generate + prune the tables) is the real work; the engine-side change is small.
  • A few MB per language, downloaded on demand like the glide dicts.
  • One extra table lookup per keystroke — negligible.

If the full version feels too big, a smaller first step would still be valuable on its own: two-word context for correction re-ranking only, or an English-only pack to start. And if I've misunderstood anything about how the context model works internally, I'd genuinely like to be corrected — that's half the reason I posted.

Either way, thanks for reading, and thanks for the keyboard! ❤️

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions