Why names are the hard part
A speech model learns from recorded speech and matching text. Whatever appeared often in that material, it handles well. Whatever did not, it has no representation for at all.
Your colleague's surname was not in there. Neither was the name of your company's internal system, the village you live in, the medication you take, or the acronym your industry uses fifty times a day.
Faced with a sound it has no word for, a recogniser does not stop and admit defeat. It produces the closest thing it does know, and so an unfamiliar name comes out as an ordinary word that rhymes with it. The output looks confident and reads as nonsense.
No amount of speaking clearly fixes this. The correct word was never among the options.
Adding a word puts it into the running
For typing, it stops autocorrect fighting you. A name you have added is no longer treated as a typo, so it stops being replaced by something the dictionary does recognise.
For dictation, the effect is larger. The words you have added are given to the speech model as context. So when a sound could plausibly be your colleague's surname or an ordinary word, the surname is now a candidate that it knows about. Usually that is enough to tip a wrong answer into a right one.
A single list does both of those jobs, which follows from one app owning both halves. The keyboard suggesting your next word and the recogniser writing down your sentence read the same additions, so there is no second list to maintain and no wondering which of them you put a name into.
In LocalType those additions never leave the handset. There is nothing to send them to, so the question of whether they are shared does not arise. Nothing else about the app changes because of them either: recognition runs on the phone from a model file no other app can open, and internet access covers exactly one purpose, retrieving the model you picked, after which it goes unused. Nothing needs registering, advertising is absent, nothing inside the product records what you do with it, and your recordings are not archived. The app's data is held back from Android's cloud backup, and a password field is given no microphone key at all. The three model sizes, 60, 190 and 539 MB, set speed against accuracy, with 4.1 seconds needed for 6.9 seconds of speech at the middle setting on the 4 GB test handset, and eighteen languages come out of one multilingual model.
The list to build, and the list to skip
Work down the first list in order. Then read the second one, because a bloated dictionary is worse than a short one.
People you write to or about. Colleagues, clients, family, the plumber. Surnames especially, since first names are more likely to be common words the model already knows.
Places you mention. Your street, your town, the office location, the school. Local place names are almost never in general training material.
Work vocabulary. Product names, internal systems, acronyms, the jargon of your field. If you would have to explain it to a stranger, the model needs it too.
Recurring specifics. The name of your car model, your bank, the shop you order from, medication, a diagnosis, a piece of equipment.
Anything you have corrected twice. Two corrections are the real signal. If you have fixed a word by hand more than once, stop fixing it and add it.
Now the things to leave out.
Ordinary words spelled correctly. They are already known. Adding them changes nothing.
One-off names. Somebody you will mention once. Correct it by hand and move on.
Whole phrases. A dictionary holds words. Adding a sentence does not teach the system a sentence.
Words you are unsure how to spell. You are teaching it your spelling. If that is wrong, you have taught it to be confidently wrong, and it will now correct the right version to your mistake.
Passwords or codes. Never. Aside from the obvious, dictation is disabled in password fields anyway, so it would achieve nothing.
How to do it without it becoming a project
The mistake is treating it as data entry. Do it in two passes.
A batch at the start. Sit down once and add the twenty or thirty things you write about constantly: the people on your team, the two or three place names that appear daily, your employer, the products you buy or sell, the acronyms you would have to explain to a stranger.
Then opportunistically. Every time you correct a word for the second time, add it there and then. Over a couple of weeks that catches everything the first pass missed, without you ever setting aside time for it.
Do not try to be exhaustive at the start. You will add things you never use and miss the ones you do.
If nothing comes to mind when you sit down to do the first batch, open the last twenty messages you sent and read them for proper nouns. Nearly every name in there will come up again, and nearly none of them are in a general speech model.
Where it stops helping
A dictionary fixes one specific kind of error and leaves the rest exactly where they were.
Homophones stay ambiguous. If your colleague is called Mark and you also write about marks, adding the name does not tell the system which you meant. The surrounding sentence does that work, and it will sometimes get it wrong.
Pronunciation still has to match. A word spelled unusually but pronounced conventionally is fine. A word pronounced in a way the model has no mapping for may still fail, particularly names from languages the model saw little of.
It does not improve general accuracy. A dictionary fixes specific words, not your accent, the noise in the room, or how far away you are holding the phone. Those are separate problems with separate fixes.
It is per device. Because LocalType keeps its data out of Android's cloud backup, your list does not follow you to a new phone. That is the direct consequence of not storing your vocabulary anywhere off the handset, and it cuts both ways: nothing to leak, and nothing to restore.
The bilingual complication
It gets more complicated if you write in more than one language.
Names cross between languages constantly. Your Dutch colleague gets mentioned in an English email, the English product name appears in a Dutch message. The word is the same; the surrounding language is not.
Adding the name once helps in both cases, since it is the word being recognised rather than the sentence. But detection of which language you are speaking works on the recording as a whole, so a sentence that is mostly one language with one foreign name in it is still that language, and that is exactly the situation you want.
Spelling is a decision you make here rather than one the app makes for you. If a surname carries an accent your other language does not use, add it in the form you want to see in writing, because that form is what will arrive from then on. The same applies to a company name capitalised in an unusual way.
The one case a dictionary cannot rescue is a sentence divided evenly between two languages. Adding every word in both of them does not change how the recording gets assigned. Say the two halves as two recordings, and the list you built goes back to work.