I don't know what the 'prevailing practice' would be here, but I use the latter method, a simple, short key name, referring to the function of the (error)message. This makes it much more easy to change the actual error message, even in English, because you have all values in one hash that can be revised, clarified, corrected and spell-checked easily later on when real people (as opposed to programmer-aliens) have to be able to make sense out of the error message. Not to mention that some error messages would make terribly long (and error-prone) identifiers. Imagine you want to be more specific about 'Item Not Found', you could end up with keys like 'Proc DoSomething: Item Not Found: Empty Record: End Of File?'. What are the odds you match that exact string without double-checking and/or copy-n-paste?...

No, my money is on very short, conceptual keys that can make you understand with one or two concatenated words where in your program's code things went wrong, like e.g. eofDatabase, paramFileName, validateFirstName, etc. It doesn't take a genius to find out what those error keys refer to, and (at least to me) they seem very hard to spell wrong.

Hope this makes sense,

   december

PS: Nice to see some (voluntary) use of internationalization.