When watching a YouTube livestream, when you tap to type something into the live chat, the keyboard appears for a split second before collapsing. Only happens in YouTube. Switching to the normal phones keyboard works.

Oneplus Nord N200 5G DE2118

Android 11 Build 11.0.1.6.DE18CB

SwiftKey Beta 7.8.9.2

YouTube 16.39.36

Hola.
me gusta mucho este teclado y lo use por mucho tiempo, pero después de formatear mi teléfono una vez dejo de corregir los errores con una línea roja como lo hace Word en un Pc y no encuentro una opción para activarlo de vuelta, agradecería mucho que me pudieran ayudar.

It seems like in the last few days my voice-to-text feature has gotten significantly worse. I don't know if this is a Swiftkey thing or a Google thing, but it started happening a few days ago after my phone installed an update and updated a bunch of apps at the same time. The interface looks a bit different, and there are a few significant changes:

- The timeout when I stop talking has drastically decreased, to the point where if I hesitate even a tiny bit between words it stops listening.

- The guesses it makes are often way off, where before they were very reliable

- There was previously a feature where I could tap on a predicted word, and it would bring up a list of other guesses for the word, which was extremely useful when it got something wrong, but it doesn't appear to do that anymore.

- Previously I could hit backspace to delete the last word and it would stay in listening mode, now hitting backspace makes it stop listening.

I use the voice-to-text a ton, so if it's really this broken now it's sort of a dealbreaker for me with Swiftkey, which would be a bummer since I've really liked it up until now. Has anyone else experienced this change recently and found a way to fix it? For reference, I have a Samsung Galaxy s10 with fully updated OS and app. Thanks!

I cannot change my search engine in SwiftKey, it only gives me the option to use Bing.
I found this answered question: https://support.swiftkey.com/hc/en-us/community/posts/360077148331-Can-t-change-default-search-engine

I have an iPhone 12 with the latest (2.9.0) version of swiftkey and somehow the option to disable the quick emoji key is not working: it is set to off, but the key is still there. It is annoying not only because I press it by mistake but also because iOS has its own emoji shortcut right below it, so its just taking up space.

Anything special i need to do to disable it?

In IOS version of the app when you long press letters polish diacritical marks (ą, ć, ę, ł, ń, ó, ś, ź, ż) are on the very end of avalible symbols behind marks not used in polish language. Could you move then so they appear first (plus maybe remove non polish ones)?

Add Bitmoji to the SwiftKey keyboard.

Gboard and Samsung keyboard offers it.

We are many users who have asked for it for a long time.

Every time I use voice to text on any iOS app, SwiftKey's app opens itself and stays open. It is quite annoying.

For some stupid reason if you try to change the things you're typing via hitting a prediction, like I type thrfe but meant three and hit three in the prediction bar to replace thrfe, it will leave the word thrfe's letters (any letters to the right of the cursor) leftover. So "three" becomes "three rfe". Um what sense does it make to leave letters of a word I want to REPLACE, as in get rid of these word, why would I want any of its letters to remain when I'm trying to get rid of it? Clearly I want to replace the entire word! Why would I ever in 9 million years need to leave ANY letters of a word I'm REPLACING? The chances are 0.00001%! Thrfe becomes three e. I will never need that e, ever. I use swipe typing so that e will get in the way. Swipe typing means I don't type 1 letter at a time, the entire word I swipe gets inputted all at once so that e will never be able to be used. I hate how stupid a rule you guys made to not let us put the cursor in the middle or beginning of the word, it can only go at the very end. Otherwise you'll have a bunch of unnecessary letters stamped in the middle of your sentences. What the heck sense does that make?

Please let us pit the cursor anywhere on the word to be able to use the prediction bar and change the word. Do you have any idea how hard it is to move a cursor to an exact spot (end of word) on a tiny phone? It's so hard that I have to use a keyboard with arrows to move cursors bc touchscreen cursor movement slows you down running it back and firth until it finely lands right where you need it, like using a mouse on super high suited is impossible to land it somewhere precise. I don't care what your reason is, maybe you did this cursor-at-end-of-word system for another feature to work, but that other feature is not nearly as important as this. Your other feature is causing huge probs leaving mismatched letters randomly in sentences. Everyone knows you don't implement a system if it's going to cause malfunctioning somewhere else. This is a malfunction, you can't ask people to place it at the end & suddenly the malfunction stops, no. The cursor goes anywhere in the word to replace that word and that is how all prediction typing works, especially since it's hard to move cursors precisely on phones.Please fix this asap, thanks.

First, I will clarify some things for those who may not know and for those who might assume that I am confusing spell-checker with keyboard input prediction.

Then I will:

Bring back a problem that has been called for attention many times and explain why it happens;

Explain why I think it matters and why previous suggested workarounds are sub-optimal;

Discuss Google’s (Gboard) chosen workaround;

Give my suggestion to fix the problem.

Definitions

Input prediction (IP) (Auto-complete and auto-correction) is a feature whose main purpose in software keyboards is to allow the user to type faster. The keyboard suggests words before you type them entirely and correct words where there are typos. By auto-correcting, the keyboard allows the user to type without painstaking care and precision, which allows for faster typing.

Spell-checking (SC) is (usually) a feature of word processors or system-wide input fields (MS Word, Android, and Google Chrome for desktop, each has its own spell-checker independent from software keyboards or any input method). Its main purpose is to alert and correct the user about the orthography of a given language.

The problem

People who use simultaneous multi-language input prediction – a feature present on SwiftKey (and Gboard also) – start seeing a red underling in all words of one of the languages.

The reason is that, while SwiftKey’s input prediction does have support for multiple languages simultaneously, the android’s system-wide spell-checker active in the user’s phone (usually AOSP’s or Google’s spell-checker) does not have.

Previous suggestions

Here it has been suggested that the user should disable the spell checker:

https://support.swiftkey.com/hc/en-us/community/posts/115002878149-Red-underline-Not-a-SK-problem-

Notably, this is also the approach used by Gboard (more on that latter), but I think this is far from the ideal because it forces the user to resort to input prediction (IP) as a form of spell-checking (SC). This is a problem because, as I said in the beginning, input-prediction is a feature focused on fast typing (as it should be) and not on orthography. To illustrate, imagine how a user uses IP as SC:

The user types the word and hopes that the keyboard will correct it automatically if it’s wrong. Except that, even when typing correctly, sometimes the first prediction (the middle one in SwiftKey) is not the desired one. And other times the prediction dictionary doesn’t have the desired word. For those reasons, the exact typed word is always shown as an option, typos and all (as it should be), and the keyboard memorizes anything the user decides to input (as it should be) either by typing space and accepting the middle prediction, or by selecting the desired word in the list.

The result is that the IP learns a lot of slangs, acronyms and jargon (as is should be), but also learns misspelled words. And the user has no way of knowing if the thing he/her has typed didn’t appear as the first (middle) prediction because it was wrong or because the neural network crystal ball simply got it wrong or because the word doesn’t exist in the IP dictionary. Also, sometimes the misspelling is so different from the intended word that the latter doesn’t appear in the prediction list, and sometimes the misspelling is even presented as the first (middle) prediction.

The clear solution to that in my opinion is to have a separate mechanism for checking orthography, the spell-checker, which has to support simultaneously multi-language input as well (chrome desktop browser has that). This is a second independent layer that runs after input prediction, and is not affected by the IP dictionary. And when the user decides to tap a word and include it in the SC dictionary it is a conscious deliberate decision.

How does Gboard deal with that

https://support.swiftkey.com/hc/en-us/community/posts/115002630445-Changing-the-language-doesn-t-change-the-system-spell-checker

Here it has been said that SwiftKey cannot control the spellchecker, and that Gboard doesn’t break in the same way because it has “advanced system privileges that SwiftKey cannot access”. I’m not an android programmer, but from the tests I have done, it seems to me that Gboard has the exact same level of system access that SwiftKey has with respect to spell-checking:

If my selected system-wide spell-checker is the AOSP one, it behaves in the exact same way with Gboard as it does with SwiftKey. The thing that Gboard does different is that, along with the keyboard, the app installs a spell-checking service as well. I’m using LineageOS, which doesn’t come with Gboard or Google’s spell-checker, only the AOSP ones. And when I install Gboard, Google’s SC appears as an option.

Now, Google’s solution is far from the best in my opinion. For what I tested, the ‘Google spell-checker’ (installed by Gboard) simply disables itself if it detects that Gboard is being used and uses only the system’s language when it detects other 3rd party keyboards (exactly like the AOSP one). And I already explained my problems with both solutions.

My suggestion

Simply put together a simple spell-checker with simultaneous multi-language support and ship it within the SwiftKey app. I think this would be simple to do, just copy the default dictionaries of the SwiftKey IP as a starting point, but it would not have to deal with predictions and other complex features that a software keyboard has to deal with. Again, copy the dictionaries, any word learned by the IP should not be automatically learned by the SC.

The simplest implementation would be to have one hash table for each language. If the user decides to use two languages simultaneously, a new empty language-agnostic hash table is created. That way, when the user includes a new word to de dictionary, it is included in the language-agnostic one to avoid guessing the language of the word. Then, spell-checking a word is simply to query the word on 3 hash tables.

Why am I suggesting this to you?

https://support.swiftkey.com/hc/en-us/community/posts/360038666231-How-to-Active-Spell-Checker-in-SwiftKey

Here it has been said that SC “was never a feature of SwiftKey itself”, and that it’s an Android problem.

Indeed, if only AOSP’s SC did support multiple languages simultaneously, this problem would be solved. But I use and prefer SwiftKey; AOSP’s keyboard still doesn’t have support for simultaneous multi-language input, suggesting that this support is also not in the horizon for AOSP spell-checker; and it’s more probable that Google’s engineers will fix this only in Google’s SC, in a way that works exclusively with Gboard (as it’s the case with the ‘auto-disable SC’ workaround).

And ultimately this is a problem that (to me at least) seems extremely simple to solve and is hurting your product.

Here are some treads complaining of SC-related problems that, while not necessarily being all related to multi-language support, could benefit from a simple Spell Checker shipped inside the SwiftKey app.

https://support.swiftkey.com/hc/en-us/community/posts/115002905745-Multilingual-keyboard-underlines-all-English-as-incorrect-Spell-Checker-

https://support.swiftkey.com/hc/en-us/community/posts/360057381832-Red-underline

https://support.swiftkey.com/hc/en-us/community/posts/360041911952-Swiftkey-red-underline-is-gone-

https://support.swiftkey.com/hc/en-us/community/posts/360054924171-Red-line-under-text

https://support.swiftkey.com/hc/en-us/community/posts/115004508429--Duplicate-Android-Showing-red-underlines-for-all-words-in-second-language

https://support.swiftkey.com/hc/en-us/community/posts/360071921211-Swiftkey-underline-not-showing

https://support.swiftkey.com/hc/en-us/community/posts/115000617369-Reduced-English-suggestions-for-incorrect-spellings

https://support.swiftkey.com/hc/en-us/community/posts/360043539472-Red-line-under-spelling-errors-with-SwiftKey-

https://support.swiftkey.com/hc/en-us/community/posts/115000528649-Spell-Check-with-SwiftKey-has-Red-underlined-text

P.S.:

I’m conscious that I might be wrong about a number of things: There could be another workaround that solves the problem in a satisfactory way; There could be a barrier to install system-wide spell-checkers on android; Maybe spell-checking is harder than I think, even without grammar-checking or prediction; etc.

In that case it would be nice if someone could explain the situation in a more in-depth way.