feat: Predictive Query Bar with Trie-backed Suggestions

[jorge1289]

Adds a predictive query bar with Trie-backed suggestions to the search page. Supports fast kanji/hiragana prefix matching and frequency ranking. Still a work in progress—keyboard support, Japanese-only restriction, debouncing, and tests are planned. And Possible integration to other supported languages.

Looking for feedback on UI/UX, Trie pre-population via IndexedDB indexes, and the current limitation: only works when wanakana is enabled (Japanese input only).

P.S. works best with frequency dictionaries enabled.

[YukiNagat0]

I should have shared my opinion earlier in the original issue (#1866), but I'll provide it here instead.

I'm struggling to understand the purpose of this proposal. What problem is it aiming to solve?
If the goal is autocomplete functionality, why not use the device's native solutions (e.g., phone keyboard autocomplete or IME autocomplete)? In most cases, these should be sufficient.

While Yomitan's dictionary access could theoretically provide unique value, I believe rare vocabulary gaps could be resolved with a simple Google search.

My concern with features like this is that they introduce significant code complexity (and sometimes performance issues if implemented incorrectly) for unclear benefits. I suspect users might try it once, then disable it permanently.

Personally, I also feel this feature diverges from typical language learning usage. The general consensus in the community is that you should use Yomitan as a reading companion - for pop-ups on native content or as a clipboard monitor. This implementation feels more like an output tool, which contradicts core input-focused approach.

[jorge1289]

Thank you for the thoughtful feedback! I really appreciate your perspective and agree with many of your points, especially about keeping Yomitan focused and avoiding unnecessary complexity.

To keep it short, my intent with this PR was two-fold: Firstly, I wanted to give back to the Yomitan community, henceforth I saw an issue (#1866), I thought it was interesting and useful, thus I decided to pursue it. Secondly, it was to provide dictionary-aware suggestions using Yomitan’s installed dictionaries and frequency data.

Ultimately, I agree with all your concerns particularly when it comes to the main usage of yomitan as a reading companion and not a output tool. My hope was to refine the existing search-bar functionality.

But, that being said, if this PR is too niche and adds unnecessary complexity i'm open to keeping it as an experimental branch for further discussion or closing it all together.

[SalwynnJP]

I should have shared my opinion earlier in the original issue (#1866), but I'll provide it here instead.

I'm struggling to understand the purpose of this proposal. What problem is it aiming to solve?
If the goal is autocomplete functionality, why not use the device's native solutions (e.g., phone keyboard autocomplete or IME autocomplete)? In most cases, these should be sufficient.

While Yomitan's dictionary access could theoretically provide unique value, I believe rare vocabulary gaps could be resolved with a simple Google search.

My concern with features like this is that they introduce significant code complexity (and sometimes performance issues if implemented incorrectly) for unclear benefits. I suspect users might try it once, then disable it permanently.

Personally, I also feel this feature diverges from typical language learning usage. The general consensus in the community is that you should use Yomitan as a reading companion - for pop-ups on native content or as a clipboard monitor. This implementation feels more like an output tool, which contradicts core input-focused approach.

Regarding the point you raised :
I completely agree. tbh, this kind of feature is quite niche.

Why did I end up requesting this PR? Simply because I'm primarily a mobile user, and sometimes I read physical novels. Of course, Google Lens usually works perfectly for 99% of the cases when I don't have/i'm unsure about the reading of an entry. But I see this feature being useful mainly when there's no internet connection, and for making lookups faster on smartphones, as some apps like Livio do. ofc, IME keyboard already lists suggestions but it's quite easy to get lost among all the suggestions (sometimes you have to scroll quite a bit to find what you were looking for, e.g, 多寡), and they’re not sorted by any frequency dictionary either. With this PR, having them directly in front of me and sorted this way would make the task significantly easier.

That said, I totally recognize it's a niche use case. In any case, I'm really happy someone contributed.

I know I probably sound extremely nitpicky, but for me, noticing this kind of detail just feels natural. UX matters on all types of devices, and personally, I often find myself choosing from a predictive bar on YouTube or elsewhere and every time I think: "It just makes sense to have this built in." But maybe I’m overthinking it for something that doesn’t really matter that much. I requested the same way for the sticky header or clear button, as it felt like an obvious thing to include. Well if tl;dr, then i send u kisses 🐰