(In reply to Alex Monk from comment #3)
> James suggested I tackle this bug. I messed around with the API for a little
> bit and assuming I didn't miss anything:
> 
> I think that if we tried to fill out the 'blockedtext' message properly on
> the client we'd have to:
> * Query the API for the user's blockinfo to determine whether or not they're
> blocked. If they are:
> ** Query the API for more info about this block which
> meta=userinfo&uiprop=blockinfo doesn't provide but we need to substitute
> into the message (expiry, user, timestamp).
> ** Query the API to parse the blockedtext message because it can't be done
> on the client (even the default message includes stuff mw.msg can't handle)
> ** Substitute the data we have into the message (and we still won't have $3
> - the current IP)
> *** Mess around with dates/times because they won't be in the right format.
> 
> Another way we could do this is return the full warning from
> action=visualeditor&paction=parse (therefore adding no extra API requests)
> which would cause the client to stop loading. I don't like this idea because
> obviously that paction is not intended for checking this kind of thing...
> 
> Or we could ignore the core blockedtext message and use our own "Your
> username or IP address has been blocked", possibly with the info that just
> meta=userinfo&uiprop=blockinfo provides (block ID, performer, reason).
> 
> Or we could add a new API module/paction that can be queried once and
> provides all the relevant info. I don't like this idea either but it seems
> the nicest.
> 
We already put random junk in the paction=parse response, I wouldn't be opposed to adding blocked-ness to that. Another paction would be OK too, but then we'd have to make two API requests.

There are significant speed benefits in combining everything into one API request. I think we should stop kidding ourselves that paction=parse is a clean, only-does-one-thing action, and perhaps rename it if we want, rather than trying to split it into separate actions, because the latter would just make client-side performance worse.