There are quite a few issues you’ve noted here, so I hope you don’t mind me addressing this one piece at a time.
- The lexical model contains about 160 000 words and it loads in 10-12 seconds.
First off, that load time is clearly not ideal and is quite significant. While I don’t recall any similar load-time reports, that is a rather large wordlist model you’re working with. Unfortunately, that’s presently a limitation of our engine’s architecture; such a large dictionary will require a bit of time to parse. We can look into mitigations for this in the future, but note that our current planned roadmap puts this no sooner than version 18.0 - it’ll be a while. This would be quite complex to tackle and would require significant amounts of dedicated time.
- When I type a word starting with a quotation mark (e.g. «, “, „ ), it does not suggest words correctly.
- In Armenian there are words with hyphen (e.g. ինչ-որ), and when I type the prefix ինչ- incorrect words are suggested.
- When there is no room for suggested long words it would be convenient to see those words with a smaller font size.
Points 2, 3, and 6 are all issues we’ve known about for a little while. While I don’t believe we have a formal issue written up yet for point 3, you can find threads for the other two here:
For the “smaller font size” idea, we actually considered that at one point in the past, but we ran into a different problem when words can get too long. To take a different example from the one seen at that link - here, from the classic film “Mary Poppins”:
supercalifragilisticexpialidocious. On any phone-form device, this would become unreadably small… so we’d need to consider how to handle cases like this well at the same time.
One proposal we’ve received in this direction: feat(common/models): Continuous suggestions #2220. If we combine the two ideas, we could simply give the space for two shorter suggestions to a single very-long suggestion if/when needed.
In the meantime, while not immediately obvious, you can ‘drag’ the suggestion and scroll it left and right to see the end of words that aren’t fully shown. Less ideal, to be sure, but it at least handles all cases ‘decently’ (though not ideally) for now.
- When I type a word starting with a capital letter, the suggested words should also start with a capital letter.
- When I type a word with all letters capital, the suggested words should have all letters capitalized.
For points 4 and 5, we rely on the keyboard to tell us whether or not a language supports capitalization. If there is no ‘caps’-layer functionality in the keyboard, we will not model capitalization in this way - there are languages that don’t want capital forms of letters that other languages for the same script support! While I see that your keyboard does have caps-based rules, the ‘caps’ layer defined within it doesn’t quite match the form we introduced in 15.0 as documented here:
Fixing that up within the keyboard should fully address those two points.
For the others… to revisit a point made earlier, much of this is stuff we hope to address directly in the 18.0 release cycle.