Page MenuHomePhabricator

Provide information about users' rights and editing on user pages
Open, LowPublicFeature

Description

Please make https://en.wikipedia.org/wiki/User:PleaseStand/User_info work everywhere. This lists user rights, the age of the account, the number of edits, the user's gender (if specified), and how long it has been since the user last saved an edit.


Version: 1.23.0
Severity: enhancement

Details

Reference
bz58405

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 2:17 AM
bzimport set Reference to bz58405.
bzimport added a subscriber: Unknown Object (MLST).

I assume it has been checked that there are no issues with http://wikimediafoundation.org/wiki/Privacy_policy ? :)

All the information is already public:

  • User rights are available at Special:ListUsers.
  • The age of the account (or at least the date of first edit), the number of edits, and the time of the most recent edit are all available at Special:Contributions.
  • Gender is 'invisible' in the English language (and others), but gender is automatically displayed by the software when it differentiates between Benutzer/Benutzerin in German (and many other languages).

+1 this would be really helpful on wikis where Google does not translate and even the site navigation is not available in English with ULS. Finding user contribs or recent changes can be challenging and time consuming. Having a handful of data (rights, status, age, edits, and most recent edit) in one predictable place would be assistive. Thanks.

  • This bug has been marked as a duplicate of bug 22516 ***

I'm re-opening this per discussion at Bug 22516:

Bug 22516 is about creating a new, completely separate Special:UserInfo page.

This request is about displaying the list of user rights in a corner of the already-existing User:Example and User_talk:Example pages.

I don't want a new page. I don't want something else to click on. I don't want another page that I can't find in the sidebar. I want this information displayed directly on the page that I'm already looking at.

I want what you see at https://en.wikipedia.org/wiki/User:PleaseStand/User_info (except working everywhere, automatically, which is not the case with that script). I do not want what you see at https://commons.wikimedia.org/wiki/File:MediaWiki-SpecialUserinfo-anon-ip.png (which is what bug 22516 requests).

The request here seems to be fairly straightforward: augment the rendered HTML of user and user talk pages with a bit more markup about the user (disclosed gender, estimated edit count, current user groups, block status). You wouldn't do this in JavaScript, you'd do it in PHP, probably in MediaWiki core, but it's likely a fairly simple coding exercise.

The tricky part of this request comes from the implementation details. I think the open questions are:

  • What do you say to users who don't want to see this information on user pages (their own or others')? Is this a valid concern?
  • What do you say to site admins who don't want this feature? Is this a valid concern?

An RFC on mediawiki.org to answer these questions might make sense here.

I've got nothing against prefs settings, but I understand the rationale against making endless prefs settings. So on the assumption that creating another unpopular prefs setting is undesirable (because it would be unpopular), it seems like this should be easily solvable in CSS:

Individual users should be able to suppress this by tweaking their CSS files (if, for example, User:Bob felt that seeing User:Alice's edit count or the fact that Alice is a sysop would cause Bob to be biased against Alice). Bob would not, however, be able to prevent Alice from seeing Bob's information—which is appropriate, given that the information is already public and we value transparency.

I'm not sure why site admins would object. The information is all available anyway, and I don't think that it would cause performance problems. If the concern was that they (rather paternalistically) thought that their users would all be biased, then presumably it could be suppressed via sitewide CSS.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:13 AM