I'm surprised no one gave the obvious answer and, I suspect, the one most often used in practice: just don't read the error messages.
The vast majority of the value of most error messages is simply that something is wrong on such and such line. Most of the time I just look at the line number and go to that line. My "reading" of the error message at that point is usually just whatever my eye catches in passing, not even a skim. If it is not immediately clear what is wrong on or near the line, then I'll actually read the message. This workflow is even better with an IDE or tooling that highlights errors on the spot, and automatically accomplishes Karl Bielefeldt's suggestion to only consider small changes.
Of course, the error messages don't always point at the appropriate line, but then they often don't point at the appropriate root cause either, so even a full understanding of the error message would be of limited help. It doesn't take long to get an idea of what error messages are more reliable about locating the proper line.
On the one hand, most errors a novice is likely to make are likely to be painfully obvious to an experienced programmer with no help from the compiler being necessary. On the other hand, they are much less likely to be so obvious to the novice (though many will be obvious, most mistakes are stupid mistakes). At this point I agree completely with Robert Harvey, the novice simply needs to become more familiar with the language. There is no avoiding this. Compiler errors that reference unfamiliar concepts or seem surprising should be seen as prompts to deepen ones knowledge of the language. Similarly for cases where the compiler is complaining but you can't see why the code is wrong.
Again, I agree with Robert Harvey that a better strategy for utilizing compiler errors is needed. I've outlined some aspects above and Robert Harvey's answer gives other aspects. It's not even clear what your friend hopes to do with such a "glossary", and it's very unlikely such a "glossary" would actually be of much use to your friend. Compiler messages are certainly not the place for an introduction to the concepts of the language1 and a "glossary" is not that much of a better place for it. Even with a lucid description of what the error message means, it's not going to tell you how to fix the problem.
1 A few languages, like Elm and Dhall (and probably Racket), as well as a few "beginner-oriented" implementations of languages do attempt to do this though. In this vein, MSalters' advice to use a different implementation is directly relevant. I personally find such things uncompelling and not quite aimed at the right problem. This is not to say that there aren't ways of making better error messages, but, to me, they tend to revolve around making the compiler's beliefs and the basis of those beliefs clearer.