Two systems, one sentence
When you dictate, two separate pieces of software have an opinion about what should end up on screen.
The recogniser decides which words you spoke. It works from sound plus context, and when it is wrong the result is a real word that sounds similar to what you said.
The dictionary behind autocorrect decides whether a word on screen looks like a mistake. It works from spelling and from the language it thinks you are writing in, and when it is wrong the result is a word replaced by a more common one.
Most frustration in this area comes from blaming one for the other's mistakes, and then applying a fix that could never have worked.
Telling them apart
Two questions identify the culprit almost every time.
Did the wrong word appear immediately, or change afterwards? Recogniser errors arrive already wrong. Autocorrect errors appear correct and then change, often as you continue.
Does the same thing happen when you type it? Type the word by hand. If it gets replaced, the dictionary is responsible. If typing it is fine but dictating it is not, the recogniser is.
That second test takes five seconds and settles the question definitively. Run it first, before you change any settings.
Why the language setting causes most of it
The single biggest source of conflict, and the easiest to fix.
Autocorrect uses a dictionary tied to the keyboard's language. Dictation may be working in a different language, either because you set it that way or because the system identified it from your speech.
When those disagree, everything looks broken. You dictate a perfectly good Dutch sentence and an English dictionary immediately corrects half of it into English words that were never said. The recogniser did its job and the dictionary undid it.
The fix is to align them. Choose a specific language instead of leaving everything automatic, and the layout, the dictionary and the dictation language all move together. The conflict disappears entirely. If you write in one language for a stretch, pin it.
If you genuinely switch constantly, expect some friction here. Language detection from a recording is reliable; a dictionary that has to be chosen in advance cannot follow it perfectly. The limitation is real, and no setting you have missed will remove it.
Names are where it hurts most
Proper nouns are the collision point, because they fail in both systems at once.
The recogniser has never met your colleague's surname, so it produces a common word that sounds similar. Then, if you type the name correctly by hand, the dictionary does not recognise it either and offers to change it back.
Adding the word to your personal dictionary fixes both halves. LocalType keeps those additions on the phone and gives them to the speech model as context, so the name becomes a candidate during recognition and not merely something tolerated afterwards.
That is the difference between a dictionary entry that stops autocorrect interfering and one that actually improves dictation. Both matter, and they are not the same thing.
Should you turn autocorrect off?
Usually not.
Autocorrect is doing a lot of invisible work on the typed half of your writing. Turning it off to fix a dictation problem trades a small irritation for a large one, particularly on a phone where typing accuracy is poor to begin with.
The exceptions are narrow. If you write in a language the keyboard does not support well, or your work is full of technical strings that are neither words nor names, the dictionary is fighting you constantly and switching it off is reasonable.
For everyone else, aligning the languages and adding your vocabulary addresses the actual problem, and leaves the correction of genuine typos intact.
The gesture that teaches the dictionary
When a keyboard corrects a word you did want, tapping that word usually brings back the original along with alternatives, and choosing your version teaches the dictionary to stop replacing it. On most keyboards, doing that a few times is enough for it to give up on that word permanently.
People rarely discover this, so they either fight the same correction for years or disable the feature entirely. Neither is necessary.
Predictive suggestions are a third thing
People lump all keyboard interference together.
The strip above the keys offering the next word is prediction, not correction. It never changes anything on its own; it only does something when you tap it.
That distinction matters when you are diagnosing a problem. If words are changing without you touching anything, prediction is not the cause. If you are accidentally accepting suggestions while reaching for the space bar, it very much is, and changing a habit is the fix, not changing a setting.
Prediction also behaves differently after dictation than after typing. Having just been handed a complete sentence, it has plenty of context and its suggestions are usually better. A small bonus.
Why this is worse on a phone than a computer
Desktop writing generally has spellcheck rather than autocorrect: it marks a word and waits for you. Phones correct silently as you go, because typing accuracy on glass is poor enough that waiting for confirmation would be unbearable.
Silent correction is the right default for thumbs and the wrong one for dictation, where the input was already a complete, deliberate sentence. That mismatch is the underlying reason the two keep getting confused, and it is not specific to any one keyboard.
What LocalType does here
The two halves belong to the same app, and one whole category of conflict never gets started.
The dictionary follows the language you set, and setting a specific language moves the layout, the dictionary and the dictation language together. Words you add by hand serve both sides: they stop autocorrect interfering, and they are handed to the speech model as context so recognition improves as well. Those additions stay on the handset.
Everything else about the app is unchanged by any of this. Recognition happens on the device from a model kept in storage only the app can reach, internet access is requested for exactly one purpose, collecting the model you chose, and there is no account. Advertising is absent, no behavioural tracking runs inside the product, no archive of your recordings is kept, and Android's cloud backup is deliberately denied the app's data. In a password field the microphone key does not appear, and the keyboard does not learn from what you type there.
Which system is at fault, in four steps
Check whether the error appears immediately or changes afterwards. Type the word by hand to confirm which system is responsible. Align the keyboard language with the language you are speaking. Add the names and technical terms you use regularly. Only then consider turning anything off.
By the fourth step you usually know which of the two systems you are arguing with, which is the thing to establish before you change any setting.