Estou surpreso que ninguém deu a resposta óbvia e, suspeito, a mais usada na prática: apenas não leia as mensagens de erro.
A grande maioria do valor da maioria das mensagens de erro é simplesmente que algo está errado em tal e tal linha. Na maior parte do tempo, apenas olho para o número da linha e vou para essa linha. Minha "leitura" da mensagem de erro nesse ponto geralmente é apenas o que meus olhos captam de passagem, nem mesmo um desdém. Se não estiver imediatamente claro o que está errado na linha ou perto dela, então eu realmente leio a mensagem. Esse fluxo de trabalho é ainda melhor com um IDE ou ferramenta que destaca os erros no momento e automaticamente realiza a sugestão de Karl Bielefeldt de considerar apenas pequenas alterações.
É claro que as mensagens de erro nem sempre apontam para a linha apropriada, mas muitas vezes também não apontam para a causa raiz apropriada, portanto, mesmo um entendimento completo da mensagem de erro seria de ajuda limitada. Não demorou muito para ter uma ideia de quais mensagens de erro são mais confiáveis sobre a localização da linha correta.
Por um lado, a maioria dos erros que um iniciante provavelmente fará provavelmente serão dolorosamente óbvios para um programador experiente, sem a necessidade de ajuda do compilador. Por outro lado, eles são muito menos propensos a serem tão óbvios para o novato (embora muitos sejam óbvios, a maioria dos erros são erros estúpidos). Neste ponto, eu concordo completamente com Robert Harvey, o novato simplesmente precisa se familiarizar mais com a linguagem. Não há como evitar isso. Erros de compiladores que referenciam conceitos desconhecidos ou parecem surpreendentes devem ser vistos como sugestões para aprofundar o conhecimento da linguagem. Da mesma forma, para casos em que o compilador está reclamando, mas você não consegue ver por que o código está errado.
Novamente, eu concordo com Robert Harvey que uma estratégia melhor para utilizar erros do compilador é necessária. Eu descrevi alguns aspectos acima e a resposta de Robert Harvey dá outros aspectos. Não é nem mesmo claro o que seu amigo espera fazer com esse "glossário", e é muito improvável que esse "glossário" seja realmente útil para seu amigo. As mensagens do compilador certamente não são o lugar para uma introdução aos conceitos da linguagem 1 e um "glossário" não é um lugar muito melhor para isso. Mesmo com uma descrição lúcida do que a mensagem de erro significa, ela não lhe dirá como consertar o problema.
1 Alguns idiomas, como o Elm e o Dhall (e provavelmente o Racket), bem como algumas implementações de linguagens "orientadas ao iniciante" tentam fazer isso. Nesse sentido, o conselho de MSalter para usar uma implementação diferente é diretamente relevante. Pessoalmente, acho que essas coisas não são convincentes e não visam o problema certo. Isso não quer dizer que não há maneiras de se fazer melhores mensagens de erro, mas, para mim, elas tendem a girar em torno de tornar as crenças do compilador e a base dessas crenças mais claras.