[13:12:26] tgr|away: The agent isn't part of the requested resource, it's metadata about the client. Although mainly my thinking was probably "User-Agent is a header, so Api-User-Agent is too". [13:18:07] anomie: it makes sense in general, but in case of a cross-origin authenticated GET, an URL parameter would be better [13:18:31] for non-authenticated too, but that can be worked around by using JSONP [13:28:09] anomie: hey, do you have a minute to listen to me ramble about TitleBlacklist's api output? [13:28:20] MatmaRex: Just a minute [13:28:28] (or you can type it and I'll read it in a minute) [13:28:43] anomie: the problem i'm having is that when an action fails because of TitleBlacklist, it's actually impossible to tell. here's example output from aciton=upload: https://phabricator.wikimedia.org/T114940#1713702 [13:28:59] the 'senselessimagename' code is defined on-wiki, on the MediaWiki:Titleblacklist page [13:29:13] i can only check for info "TitleBlacklist prevents this title from being created", which is really stupid [13:29:45] my real question is, is there a way to preserve additional data (message parameters) from getUserPermissionsErrors() in the api output? [13:30:38] if yes, we should change this to always use the same error code, and pass the second code separately. [13:30:58] (see TitleBlacklistHooks::userCan) [13:45:44] MatmaRex: Ugh, ApiBase::$messageMap sucks in general. Ideally the hook would give back a Message, which could be an ApiMessage with the additional data for the API to format it nicely as an error. But I don't know what would be needed to make that actually happen to whatever is returning the key string or the key-and-parameters array now. [13:47:54] anomie: hmm. i found ApiMessage, but it did not look like it was intended to do what you just described. i haven't tested it, but it looks like we should be able to return an ApiMessage instance instead of an array there, and it would work… [13:48:32] i'll look into doing that. thanks [13:48:59] MatmaRex: The idea of ApiMessage is that it's a Message that has some extra data for the API to use when interpreting it as an error (or in the future as a warning). Whether the code path involved here supports getting a Message at all, I have no idea. [13:49:53] i'll find out, i guess [13:51:08] BTW, if the documentation in ApiMessage could be improved, please do! [18:08:53] tgr|away: are you working today? If you are I need to move our 1:1. If not I'll see you at the team meeting tomorrow [18:29:30] bd808: technically not [19:59:39] Hmm. If I setup a wiki as a documentation source for my dads work... How do I do it? :P git? tarball? [20:04:37] Reedy: I'd go with stable tarballs or release branches [20:04:56] Yeah, I wasn't going to do maser [20:04:58] *master [20:05:45] I'd probably use the git release branch [20:06:53] I suspect I'm not going to be needing more than MW, PF, SyntaxHighlight and a few other common stuff [20:07:09] Probably no uploads or anything either