Wikimedia Bugzilla is closed!

... then we do not need the details link anymore at all. This problem is more complicated than it appears though. Currently, the "default" error messages are pretty useless most of the time because they are quite generic. The detailed messages, however, can be quite technical which is appropriate since they should expose as much detail as possible about an error. Additionally, the detailed messages are not intended to be localized.
I guess the proper solution would be to improve the quality and increase the number of "default" error messages. These, for example, may contain advise about how to solve an issue. The back-end error messages are meant to only report an error including technical information that does not have an actual use for regular users (unless they want to file a bug report).

Agreed. We however seem to have way too many cases where we have common errors with a too technical error message that is in addition also not expanded by default.

So the steps here imho would be:
* get a list of common and bad error messages
* improve error message text for those
* remove details link to always show complete error message

I totally agree to the arguments given by Henning and Lydia. I suggest to close this report (or make it a tracking bug) and create new reports for the most common untranslated error messages that should be improved.

Let's collect that list here. No need for a new one imho.

The API already provides localized errors in some cases. I suggest to show that localized error in full if it exists. The structured returned by the API will look something like this:

  {
    "error": {
        "code": "invalid-snak-value",
        "info": "Malformed URL: asldkjf",
        "messages": {
            "0": {
                "name": "wikibase-validator-bad-url",
                "type": "error",
                "parameters": [
                    "asldkjf"
                ]
            },
            "html": {
                "*": "<p>Malformed URL: asldkjf\n</p>"
            }
        }
    }
  }

So, if result[error][messages][html] is defined, we can just show it, it's intended for the user.

If that is not set, we will only have a "traditional" API error:

 {
    "error": {
        "code": "invalid-guid",
        "info": "Invalid claim guid"
    }
 }

In that case, we should do what we do now: show a localized message based on the code, and show what's in "info" under "details".

Not that the error info is, by convention, not localized. This is the first parameter passed to dieUsage(), and we should double-check that we don't localize it (e.g. it seems we are returning a localized message for invalid edit tokens).

The error info should be treated as a plain value (html escaping must be applied). Linebreaks may be significant and should be preserved (using <pre> or <br/>): in some cases, the error info will contain a stack trace (at least if wgShowExceptionDetails is enabled).