Expose Internal Dictionary Pipeline (wordlist → dicttool) to Users

[iuri79]

Hi! First of all, thank you for Heliboard — it’s honestly one of the most customizable and well-thought keyboards I’ve used.

I’d like to suggest a feature that could significantly improve language support and power-user customization.

Feature idea: Internal dictionary editor (not just user dictionary)

Currently, we can manage the user dictionary, but I’m thinking about a way to directly manage the internal/base dictionary used by the keyboard — through the app’s settings UI.

The idea would be to allow users to:

• Add words
• Remove words
• Edit existing entries
• Define shortcuts/expansions

But instead of storing them only as user entries, these changes would be applied to the underlying wordlist that feeds the keyboard’s main dictionary.

Technical concept (high-level):

• Words would be stored/modified in a wordlist-like structure internally
• This list could be compiled into .dict format using something like dicttool_aosp.jar
• The keyboard would then reload/update the dictionary in real time (or near real time)

Why this matters:

• Many languages (Portuguese in particular) suffer from poor default dictionaries from Google/AOSP:

  • Missing slang and informal usage
  • Missing brand names and modern vocabulary
  • Over-prioritization of uncommon or outdated words

• Power users could “shape” the dictionary to their real usage instead of fighting predictions

Extra benefit (shortcuts/swipe):

• Custom shortcuts could also help improve swipe accuracy, especially on smaller screens (like foldable front displays), where precision is limited
• This would allow users to “force” expected swipe outputs in constrained layouts

Given how customizable Heliboard already is, this feels like a natural extension of its philosophy — giving users full control over their typing experience.

Would love to hear your thoughts on feasibility or potential pitfalls.

Thanks again for the amazing work!

[Helium314]

Essentially this requires someone to continue & adapt #2090. There is too much to do, so I decided to not spend more time on this.
Though maybe an approach closer to the dicttool (creating .dict files) would be better..