Every language, and even different compilers for a given language, has a different set of error messages it will display when given poor input.
Other than general debugging techniques, what are techniques you use when learning a new language to decipher the compiler error messages?
I'm not sure this is a reasonable question, in that I don't think that "techniques" is really the right paradigm to describe understanding unfamiliar error messages. More like you have to get acclimated to understanding what kinds of messages you get and what they mean, like the process you go through in learning any complicated language or idiom. Every time you get the error and figure out what you got wrong you're building your understanding.
Inotherwords, time and repetition.
This may be too obvious, but start with the first message that the compiler reports. The rest may cascade from the first.
A fundamental knowledge of the language's constructs is helpful. An example I recall was when I was helping friends through an intro to comp sci course in college. One of them got a message from the C++ compiler reading "local function definitions are illegal". I knew instantly that the questioner had forgotten to close the braces of a function.
The person who asked me had no clue what "local function definition" even meant, which is perfectly understandable. Jumping to the line containing the error message helps, and reading the message suggested the function definition was in the "wrong place". Knowing how functions work, one might presume this meant they had accidentally tried to declare a function within another function. Of course, knowing about function definitions, that is illegal. How would that happen? Most likely culprit was those braces.
Essentially, I'd recommend taking your time to analyze what the message is really trying to tell you. What does it think you were trying to do, and why did it think that? Reading the documentation per ennuikiller's response doesn't hurt either. Some level of experience is necessary, but logical thinking and deduction will get you far.
Really, you have to learn the dialect of each and every compiler. After you get the same error message from the compiler for the third time, you start to notice the pattern for what kicks it off. Eventually you'll get to the point where you know just by looking at a message what kind of thing you must have done.
In the meantime, if the cause of a message is obscure, you can try googling the most unique-looking part of the message text. I've had good luck with that on new compilers.
Some compilers have better error messages than others, but all that really serves to do is shorten your learning curve a bit.
Two techniques:
Never pay attention to any message but the first. In too many compilers, later error messages are spurious.
When in doubt, make mistakes on purpose to see how the compiler diagnoses them.
After that, it's Google and Stackoverflow for me!