User gender should be exposed in revision information (user gender rvprop)
Open, Needs TriagePublic

Description

A call to https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&format=json&prop=revisions&meta=&titles=Main+Page
shows the user who edited the page last. It however omits their gender.

Gender is important for localisation. Please expose it in the response.

Jdlrobson created this task.Aug 1 2017, 9:52 PM
Jdlrobson renamed this task from User gender should be exposed in revision information to User gender should be exposed in revision information (user gender rvprop).
Anomie added a subscriber: Anomie.EditedAug 2 2017, 10:33 PM

This information is already available via the API, using list=users. I'm wary of including bunches of extra information in otherwise-unrelated responses "for localization".

But if this were to be done, the proper way would be to do it across the API everywhere a user name is returned (i.e. using a helper function), not just ad hoc in prop=revisions because that's the one place you happen to need it at the moment.

At any rate, at the code level this would also want some consideration to be able to avoid potentially making 5000 selects for the gender of one user each (better to make 1 select for the gender of 5000 users).

I'm wary of including bunches of extra information in otherwise-unrelated responses "for localization

I'm confused. Our apps/web want to render diffs and last modified information which respects the gender of our editors. How is that unrelated? In the mean time we are assuming their gender is unknown which is not great.

But if this were to be done, the proper way would be to do it across the API everywhere a user name is returned (i.e. using a helper function), not just ad hoc in prop=revisions because that's the one place you happen to need it at the moment.

That sounds great and a good opportunity to improve MediaWiki's code for everyone working with it.

Our watchlist JS wants to display a localized "This page has been added to your watchlist" message in a little popup when someone clicks the 'watch' button, but we removed the returning of the parsed message from action=watch because action=watch isn't the place for that. This seems like a similar situation, even though it's not amenable to the same solution used for that 'watched' message.

Perhaps the ideal thing to do here would be to implement T16027: Implement user generators into the API, particularly along the lines mentioned in T16027#3524520.