Talk:Product Safety and Integrity/Anti-abuse signals/User Info
Add topicCandidate wiki
[edit]I would like to nominate azwiki as a candidate wiki for this feature. Our wiki has a high edit rate with active community. Nemoralis (talk) 15:21, 20 June 2025 (UTC)
- Thanks @Nemoralis, I have noted the request on T386439: UserInfoCard: Rollout and metrics monitoring KHarlan (WMF) (talk) 11:20, 24 June 2025 (UTC)
- @Nemoralis we think this feature will be useful for all logged-in editors. We would like to enable this for all logged-in editors on deployment. Would that be okay for azwiki? Does this require a community discussion first? -- NKohli (WMF) (talk) 08:49, 4 July 2025 (UTC)
- Yes, of course. I don't think we need a discussion for that. Nemoralis (talk) 10:50, 4 July 2025 (UTC)
- @NKohli (WMF) I also nominate viwiki for this. It's very useful for our patrollers. Hide on Rosé (talk) 04:02, 7 September 2025 (UTC)
- Noted. Thanks @Hide on Rosé! -- NKohli (WMF) (talk) 10:29, 8 September 2025 (UTC)
Incorrect global contributions count
[edit]Hello,
Special:CentralAuth/Bosco Sin says: "Total edit count: 18,763".
But in this page history, User Info says: "Global edits: 31092".
Regards, NicoScribe (talk) 06:47, 26 June 2025 (UTC)
- I agree. The global edit count in the user info cards is wrong. I have 61,354 global edits, but the card says 118291. --Paloi Sciurala (talk｜contribs) 21:33, 27 June 2025 (UTC)
- @NicoScribe @Paloi Sciurala Thank you both for reporting this. I captured it on phabricator. -- NKohli (WMF) (talk) 09:30, 4 July 2025 (UTC)
Clarify that the edits count ignores imported edits
[edit]Hello,
testwiki:Special:Contributions/JavaHurricane shows 4 edits (the oldest edit has been imported, and the three other edits are manual edits).
But in this page history, User Info says: "Local edits: 3".
Regards, NicoScribe (talk) 06:56, 26 June 2025 (UTC)
- That's not a UserInfo issue, 3 local edits is correct. Imported edits can appear in Special:Contributions but don't affect the edit count. testwiki:Special:Contributions/JavaHurricane says "A user with 3 edits. Account created on 2020-02-17." and Special:CentralAuth/JavaHurricane also shows 3 edits on test wiki. Johannnes89 (talk) 19:46, 27 June 2025 (UTC)
- @Johannnes89: I know testwiki:Special:Contributions/JavaHurricane and Special:CentralAuth/JavaHurricane say 3 edits, and I think WMF should clarify that Special:Contributions and Special:CentralAuth ignore imported edits, too.
- But here, I am focused on User Info.
- I am not saying it is a serious issue, or a small error, or an intentional design: it's irrelevant. I am just saying WMF should clarify that the edits count ignores imported edits. I am not asking for a big developpement effort: displaying "Local edits: 3 (without imported edits)" would be OK. --NicoScribe (talk) 17:58, 30 June 2025 (UTC)
- that would likely lead to even more confusion given how much of an edge case this is. "local edits" is consistent with all the other edit counters. Johannnes89 (talk) 18:02, 30 June 2025 (UTC)
- @Johannnes89: look testwiki:Special:Contributions/JavaHurricane: the text "A user with 3 edits" is small; and the 4 contributions are big. It is hard to see consistency here. --NicoScribe (talk) 18:13, 30 June 2025 (UTC)
- That's for the rare edge case where someone imported an edit and used the "Assign edits to local users where the named user exists locally" option. It has always been the case that such an imported edit doesn't appear in the edit counter of Special:Contributions and Special:CentralAuth – that's why it's consistent that User Info uses the same edit counter. "Local edits: 3" is correct, because the imported edit is not a local edit. 99,99% of all users you are checking won't have imported edits (and if they do their edit count is usually very high, so you won't even notice if the number – including imported edits – should be higher or not). Johannnes89 (talk) 18:31, 30 June 2025 (UTC)
- @Johannnes89: you said "imported edit is not a local edit", so, there is one other solution that ensures consistency: Special:Contributions should not show imported edits (a new page Special:ImportedContributions could show imported edits). When someone from WMF will answer this section, I hope they will understand my need. --NicoScribe (talk) 07:41, 1 July 2025 (UTC)
- @NicoScribe: For what little it's worth I would oppose such a change in the absolute strongest terms. When I'm importing edits from the Nostalgia Wikipedia or another old database dump to the English Wikipedia, half the reason I do so is so that they're available in a user's contributions page just like other edits; in a perfect world, all of Wikipedia's early edits would have been saved. Wikipedia's edit count database field has never precisely aligned with the contributions page and never will. Also, this problenm is not unique to the new User Info tool; for example, due to database issues with old accounts that are completely irrelevant to this page, opening en:Special:Contributions/Neeklamy causes it to say "A user with 0 edits. Account created on 27 September 2008.", when that is absolutely not true. Graham87 (talk) 08:14, 5 August 2025 (UTC)
- @Johannnes89: you said "imported edit is not a local edit", so, there is one other solution that ensures consistency: Special:Contributions should not show imported edits (a new page Special:ImportedContributions could show imported edits). When someone from WMF will answer this section, I hope they will understand my need. --NicoScribe (talk) 07:41, 1 July 2025 (UTC)
- That's for the rare edge case where someone imported an edit and used the "Assign edits to local users where the named user exists locally" option. It has always been the case that such an imported edit doesn't appear in the edit counter of Special:Contributions and Special:CentralAuth – that's why it's consistent that User Info uses the same edit counter. "Local edits: 3" is correct, because the imported edit is not a local edit. 99,99% of all users you are checking won't have imported edits (and if they do their edit count is usually very high, so you won't even notice if the number – including imported edits – should be higher or not). Johannnes89 (talk) 18:31, 30 June 2025 (UTC)
- @Johannnes89: look testwiki:Special:Contributions/JavaHurricane: the text "A user with 3 edits" is small; and the 4 contributions are big. It is hard to see consistency here. --NicoScribe (talk) 18:13, 30 June 2025 (UTC)
- that would likely lead to even more confusion given how much of an edge case this is. "local edits" is consistent with all the other edit counters. Johannnes89 (talk) 18:02, 30 June 2025 (UTC)
New articles link
[edit]Hello,
I know that Phabricator:T394767 is ongoing, but:
- if you show new pages limited to main namespace pages, the link should lead to creations in the main namespace
- if you show new pages in all namespaces, the link should lead to creations in all namespaces.
In this page history, User Info for DvorapaBot says: "New articles: 1" (because there is one creation in the main namespace). But a click on "1" leads to 5 creations in all namespaces.
Regards, NicoScribe (talk) 08:07, 26 June 2025 (UTC)
- I agree. The link is not correct. Paucabot (talk) 08:42, 19 August 2025 (UTC)
Reverted edits link
[edit]Hello,
In this page history, User Info for my account says: "Local edits: 1 (reverted: 0)". But a click on "1" or a click on "0" both lead to all my contributions. A click on "0" should lead to my reverted contributions.
Regards, NicoScribe (talk) 08:29, 26 June 2025 (UTC)
- Thanks for reporting this. Tracking it here: T398629. -- NKohli (WMF) (talk) 13:34, 3 July 2025 (UTC)
Difference between use cases here and in Phabricator
[edit]Hello,
To know whether a user has the temporary account IP access right, nobody should use this user's membership to the relevant user groups (cf. details here). The only privacy-secured solution is to use User Info (Phabricator:T395661).
In Trust and Safety Product/Anti-abuse signals/User Info, the second use case is "Users without extended rights, including newcomers, can assess how they may interact with a given user or whom to reach out to for help". So a recently registered user (without access to temporary account IP addresses) should use User Info to check which users have access to temporary account IP addresses, for instance in these 3 scenarios:
- the user thinks an LTA (with known IP addresses shown in public long-term abuse pages documenting their activities) is now using a temp account, and the user wants to ask experienced users to check that,
- the user has seen vandalisms from two temp accounts, and wants to ask experienced users to check whether one unique human vandal has used these temp accounts,
- the user has seen vandalisms from a temp account, and wants to ask experienced users to check whether the human vandal has made other vandalisms (with other temp accounts on the same IP).
But in Phabricator:T395661 it seems that only the fourth use case ("Users with access to temporary account IP addresses can check which other users have this access for the purposes of sharing privileged information") is considered.
Regards, NicoScribe (talk) 11:05, 26 June 2025 (UTC)
- Generally speaking your preferences are non-public private information (phab:T395661#10905818). That's why the info whether or not you've checked the preference should only exist for the fourth use cases. The three scenarios you mentioned don't need this use case: The user can just ask anyone in the temp account IP viewer user group (or admins etc.) to check. Given that most patrollers will check the preference, that's likely sufficient (and if not there' not much harm in asking the user to turn to someone else – or just report the issue to the wikis vandalism noticeboard). Johannnes89 (talk) 19:52, 27 June 2025 (UTC)
- @Johannnes89: well, with temporary accounts, new rights and groups have been created...
- But we can't rely on user's membership to the relevant user groups... this is a sad situation!
- When User Info was created, it sounded great, it could fix this sad situation... but most people won't be able to see the fix = another sad situation!!
- You said "The user can just ask anyone in the temp account IP viewer user group (or admins etc.) to check" and "if not there' not much harm in asking the user to turn to someone else": well, it will reveal the non-public private information that you've not checked the preference = another sad situation!!!
- Well, a few weeks ago, I thought that requests to temporary account IP viewers should be forbidden (here). Now, it seems that the best solution is to channel requests into a "temporary account IP viewers noticeboard" so only users with IP access will answer requests (and users without IP access will be unsolicited)... --NicoScribe (talk) 18:07, 30 June 2025 (UTC)
- There might be many reasons why a user with temp account viewer permissions chooses not to carry out your request, I don't think that's an issue. Anyway: If I see vandalism from a temporary account, the usual process is reporting it to the project's vandalism noticeboard to request a block. The blocking admin can check the IP without me having to submit a request to anyone if I don't have access to the IP myself. Johannnes89 (talk) 18:18, 30 June 2025 (UTC)
- @Johannnes89: and there might be many reasons why reporting the problem to the project's temporary account IP viewers noticeboard is better than reporting it to the project's vandalism noticeboard (to request a block): old-but-less-than-90-days vandalism, beginning of investigation, project's usual process, etc. For instance, in fr.wikipedia, if I see vandalism from a user, the usual process is to warn him several times, then, only if the vandalism is continuing, to report it to the project's vandalism noticeboard (to request a block). --NicoScribe (talk) 21:53, 5 July 2025 (UTC)
- There might be many reasons why a user with temp account viewer permissions chooses not to carry out your request, I don't think that's an issue. Anyway: If I see vandalism from a temporary account, the usual process is reporting it to the project's vandalism noticeboard to request a block. The blocking admin can check the IP without me having to submit a request to anyone if I don't have access to the IP myself. Johannnes89 (talk) 18:18, 30 June 2025 (UTC)
- @Johannnes89: well, with temporary accounts, new rights and groups have been created...
One use case is missing
[edit]Hello,
To know whether a user has the temporary account IP access right, nobody should use this user's membership to the relevant user groups (cf. details here). The only privacy-secured solution is to use User Info (Phabricator:T395661).
One use case is missing in Trust and Safety Product/Anti-abuse signals/User Info: a logged-out editor has seen vandalisms (see three scenarios in #Difference between use cases here and in Phabricator), so he needs to use User Info, to check the access right of a registered user AAA, before reaching out for help. This logged-out editor is not a newcomer (who would ask for help in a village pump), this logged-out editor is an experienced editor who has already interacted with AAA in the past.
Regards, NicoScribe (talk) 10:57, 26 June 2025 (UTC)
- See above, the logged-out user could just submit a report to the wiki's vandalism noticeboard or rely on the user group which should be sufficient when asking for help (different to the disclosure of IPs where you can't just rely on the user group). Johannnes89 (talk) 19:53, 27 June 2025 (UTC)
Another use case is missing
[edit]Hello,
To know whether a user has the temporary account IP access right, nobody should use this user's membership to the relevant user groups (cf. details here). The only privacy-secured solution is to use User Info (Phabricator:T395661).
One use case is missing in Trust and Safety Product/Anti-abuse signals/User Info: a registered user has seen cross-wiki vandalisms from one temp account, so he needs to use User Info, to check which users have global access to temporary account IP addresses, before reaching out for help (to find more global vandalisms/temporary accounts using this IP, globally, and to find more IP used by these temporary accounts, globally).
This use case is important because in the temporary-accounts-era, there are only approximately 600 users with global access to temporary account IP addresses who can fight cross-wiki vandalism efficiently (Stewards, Global sysops, Global rollbackers, Abuse filter maintainers/helpers and, if they opt-in, CheckUsers and Oversighters), whereas in the visible-IP-era, the whole community was able to fight cross-wiki vandalism efficiently.
So User Info should display, for instance, for an Oversighter who opt-in for global access:
- Can view temporary account IPs locally
- Opted in to view temporary account IPs globally.
Regards, NicoScribe (talk) 15:02, 26 June 2025 (UTC)
- If a user agreed to the temp. account policy, you can communicate with them about temp. account IPs, doesn't matter if the opt-in occurred locally or globally. I don't see the need to display both. Johannnes89 (talk) 20:00, 27 June 2025 (UTC)
- @Johannnes89: Local administrators, in many wikis, are the ones dealing with most problems; but, in the temporary-accounts-era, they don't have the global temporary account IP access right, so they can't fight cross-wiki vandalism efficiently. In my use case, I want to check whether someone is one of the 600 users able to help me.
- User Info displays local groups, but it's not enough, so User Info also indicates whether a user has local access.
- User Info displays global groups, but it's not enough, so User Info should also indicate whether a user has global access. I think this need is clear.
- I can predict your answer (in most cases of vandalism checking global contributions of the temporary account should be sufficient / report to a vandalism noticeboard / rely on the user group is sufficient when asking for help) and I can predict my answer (when someone from WMF will answer this section, I hope they will understand my need). --NicoScribe (talk) 23:18, 30 June 2025 (UTC)
- Noting that User Info shows user with global access as "opted in" on every wiki which should solve your issue. Johannnes89 (talk) 11:11, 5 July 2025 (UTC)
- @Johannnes89: it doesn't solve the issue if User Info shows "Opted in to view temporary account IPs" without clarifying "local / global". The clarification "local / global" is needed to solve the issue. This section is only about global access. --NicoScribe (talk) 13:26, 5 July 2025 (UTC)
- I think it solve the issue. Example: Open the User Info Card for my account on your homewiki. It shows that I'm not part of any local user groups which would grant me access to temporary account IPs, but it shows me as opted in (which is only possible for users with access) -> therefore I'm globally opted-in. Johannnes89 (talk) 13:38, 5 July 2025 (UTC)
- @Johannnes89: User Info is not deployed on my homewiki, but I understand your rationale. Your rationale works for your case (a steward without relevant local user groups) but it does not work for other cases (for instance: local checkusers, local oversighters, local administrators who are also global abuse filter helpers, local rollbackers who are also local temporary account IP viewers + global rollbackers, etc.). --NicoScribe (talk) 14:05, 5 July 2025 (UTC)
- You can try the feature using Special:APISandbox: Select "options" for action, navigate to the "action=options" tab, enter "checkuser-userinfocard-enable" at "optionname" and "enable" at "optionvalue", select "create" at "global", click "auto-fill the token", then click the blue "make request" button above, that's how I'm using it.
- Set aside that I think it's extremely unlikely that someone would only use their local IP access and not their global access (and in this rare case you can just ask someone else), you could always navigate to any WMF wiki where they don't hold local permissions and check their user info card on that project. I don't think the user info card should be overloaded for all potential edge cases, there's already lot's of information.. Johannnes89 (talk) 14:31, 5 July 2025 (UTC)
- @Johannnes89: thank you for your explanations about Special:APISandbox!
- Well, many editors only focus on their homewiki. I could list several local administrators of en.wikipedia without edits outside of it. They would not opt-in for global IP access.
- No, I won't "navigate to any WMF wiki where they don't hold local permissions and check their user info card on that project", because I won't see User Info's line about IP access there (because I am not a local temporary account IP viewer there), and because such investigations should not be necessary. On my homewiki (where I am a local temporary account IP viewer), User Info should tell me about local IP access and global IP access. It is a very basic need, a very simple need!
- Moreover, to avoid overloading User Info, my example of text ("Can view temporary account IPs locally. Opted in to view temporary account IPs globally.") can be simplified: "View temp. account IP: yes globally" (when there's global access) and "View temp. account IP: yes locally, no globally" (when there's only local access) and "View temp. account IP: no" (when there's no access).
- Moreover, to avoid overloading User Info, the groups "(local) temporary account IP viewers" and "global temporary account IP viewers" could not be displayed: they are misleading and redundant with the line about IP access. --NicoScribe (talk) 21:54, 5 July 2025 (UTC)
- Well, this is a basic need, and the associated texts should be consistent with other texts from other needs, so I have created Phabricator:T398768. --NicoScribe (talk) 15:27, 6 July 2025 (UTC)
- @Johannnes89: User Info is not deployed on my homewiki, but I understand your rationale. Your rationale works for your case (a steward without relevant local user groups) but it does not work for other cases (for instance: local checkusers, local oversighters, local administrators who are also global abuse filter helpers, local rollbackers who are also local temporary account IP viewers + global rollbackers, etc.). --NicoScribe (talk) 14:05, 5 July 2025 (UTC)
- I think it solve the issue. Example: Open the User Info Card for my account on your homewiki. It shows that I'm not part of any local user groups which would grant me access to temporary account IPs, but it shows me as opted in (which is only possible for users with access) -> therefore I'm globally opted-in. Johannnes89 (talk) 13:38, 5 July 2025 (UTC)
- @Johannnes89: it doesn't solve the issue if User Info shows "Opted in to view temporary account IPs" without clarifying "local / global". The clarification "local / global" is needed to solve the issue. This section is only about global access. --NicoScribe (talk) 13:26, 5 July 2025 (UTC)
- Noting that User Info shows user with global access as "opted in" on every wiki which should solve your issue. Johannnes89 (talk) 11:11, 5 July 2025 (UTC)
Latest edit
[edit]While that "Editing activity over last 60 days" is useful, I reckon that it's not enough. A "Latest edit" is still needed. Something like this:
- Latest edit: 16:38, 25 June 2025 (2 days ago)
--Paloi Sciurala (talk｜contribs) 21:01, 27 June 2025 (UTC)
- @Paloi Sciurala thanks for this feedback. We have recently made the editing graph interactive and hovering on it will now show when and how many edits were made. You can test this on testwiki. With this improvement, do you still feel we need to add a latest edit timestamp? -- NKohli (WMF) (talk) 07:58, 2 July 2025 (UTC)
- The interactive version of the editing graph seems to largely cover this. --Paloi Sciurala (talk｜contribs) 14:47, 2 July 2025 (UTC)
- However, when dealing with an emergency and one needs to immediately contact a user with advanced rights, it's useful to know how many minutes/hours/days ago a user has last edited. The editing graph displays only the number of edits in the last 60 days. --Paloi Sciurala (talk｜contribs) 15:31, 2 July 2025 (UTC)
- The interactive version of the editing graph seems to largely cover this. --Paloi Sciurala (talk｜contribs) 14:47, 2 July 2025 (UTC)
Languages and timezone
[edit]Adding the languages the user knows and their timezone would be useful, though currently, the only way to configure the languages you know is through Babel, and the timezone is at most a private preference. --Paloi Sciurala (talk｜contribs) 21:29, 27 June 2025 (UTC)
- @Paloi Sciurala thanks for this feedback. For languages - it is hard to determine what languages someone knows since Babel is on the content end and not in the database. Not every user has babel boxes either. We have "Active wikis" data in the UserInfo for users who are active on multiple wikis. Does that suffice? For timezone -- I am curious to hear how would this be useful. Can you please elaborate? Thanks. -- NKohli (WMF) (talk) 08:02, 2 July 2025 (UTC)
- Active wikis do not necessarily reflect the languages a user knows. Many users have significant contributions on only one single wiki, despite knowing several languages at an advanced level. Likewise, some users regularly and successfully contribute to wikis in languages they do not know well. While it's true that some users do not have Babel userboxes on their user pages, it would still be useful to show the languages for those users who do have them. Displaying the languages is useful in multilingual wikis (like Wikidata, Commons, Meta...), when a user needs to contact another user on a wiki in a language the former user does not know (the former user is likely to search for a user that speaks a language spoken by both), or when searching for users that could check a source in language X. Also, users that regularly contribute to wikis in languages they do not speak at a native or advanced level could benefit from signaling their languages.
- Moreover, the wikis listed as active wikis are not very representative for neither the languages a user knows, nor for the wikis where a user is mostly active – for example, gawiki is listed as one of my active wikis, despite having only one edit there. This is especially problematic for users who engage in global anti-vandalism work. Listing a wiki for reverting merely one vandalism is redundant. This seems to be "recently edited wikis", rather than "active wikis". If it's so, I find the actual wording confusing. By "active wikis", I understand the wikis where the user gets involved most of the time.
- Timezone is not as necessary, but it could be useful to have a rough approximation for when a given user is likely to be online, for example, when that user is likely to reply. --Paloi Sciurala (talk｜contribs) 15:26, 2 July 2025 (UTC)
Role colors and other feedback
[edit]I would suggest formatting the user info card a little bit like Discord, and also enabling it when a user left clicks on a user link or user talk page link, and right clicking should show a context menu. Aasim 14:20, 28 June 2025 (UTC)
- @Awesome Aasim would you be able to share a bit more about what you like about the Discord user card? -- NKohli (WMF) (talk) 17:03, 10 July 2025 (UTC)
Consider using the existing icon on mobile diffs
[edit]-
MobileDiffs without User Info (example) -
Mobile Diffs with User Info – two icons -
MobileDiffs with User Info Card – two icons even in the info card
MobileDiffs (e.g. en:Special:MobileDiff/1294264611) show a user icon on small screens. Consider using the existing icon instead of adding a new one. Johannnes89 (talk) 18:41, 30 June 2025 (UTC)
- Thank you for catching this. Filed as https://phabricator.wikimedia.org/T398392 -- NKohli (WMF) (talk) 05:31, 2 July 2025 (UTC)
Incorrect new articles count
[edit]Hello,
In this history, User Info for AlvaroMolina says: "New articles: 0". But this user has created 6 pages in the main namespace.
In this history, User Info for PiRSquared17 says: "New articles: 0". But this user has created 25 pages in the main namespace (20 content pages and 5 redirects by moving pages).
In this history, User Info for MZMcBride says: "New articles: 1". But this user has created many pages in the main namespace.
In this history, User Info for Zilant17 says: "New articles: 1". But this user has created 4 pages in the main namespace (3 content pages and 1 redirect by moving pages).
In this history, User Info for Etonkovidova (WMF) says: "New articles: 4". But this user has created 8 pages in the main namespace (6 content pages and 2 redirects by moving pages).
In this history, User Info for Gryllida says: "New articles: 8". But this user has created 15 pages in the main namespace (12 content pages and 3 redirects by moving pages).
In this history, User Info for Aishik Rehman says: "New articles: 16". But this user has created 18 pages in the main namespace (2 content pages and 16 redirects by moving pages).
Regards, NicoScribe (talk) 15:28, 6 July 2025 (UTC)
- Thank you for reporting this @NicoScribe. Also, generally a very big thank you for your help in improving this feature. Very much appreciated. <3 -- NKohli (WMF) (talk) 17:07, 10 July 2025 (UTC)
Links to user groups
[edit]The user info cards display the user groups a user belongs to, but those user group text strings do not link to any pages describing the meaning of those user groups. They should be links, similar to those in Special:Stats. Newcomers are unlikely to know the meaning of, for example, autopatrolled. The same applies to global user groups. --Paloi Sciurala (talk｜contribs) 17:50, 15 July 2025 (UTC)
- Thanks for the suggestion. cc @KColeman-WMF @Niharika KHarlan (WMF) (talk) 11:28, 9 August 2025 (UTC)
Twinkle issues
[edit]Twinkle is not fully compatible with the user info cards. When user info cards are turned on, clicking a Twinkle revert link will not open the user talk page of the user whose edit has been reverted. --Paloi Sciurala (talk｜contribs) 14:22, 19 July 2025 (UTC)
- This bug practically rends the User Info Card feature unusable for me. I am not willing to give up on using Twinkle, so I had to disable the feature for now. --Paloi Sciurala (talk｜contribs) 14:47, 8 August 2025 (UTC)
- Thanks for this report. I'm not familiar with a Twinkle revert link (I have the gadget enabled on enwiki) -- can you tell me how I can reproduce this issue? Do you see any errors in your browser console? KHarlan (WMF) (talk) 20:03, 8 August 2025 (UTC)
- I guess they are referring to the "Open user talk page after these types of reversions" option in en:Wikipedia:Twinkle/Preferences#rollback which also exists in the rowiki version of TW [1] and in the global version [2]. Johannnes89 (talk) 13:42, 9 August 2025 (UTC)
- @KHarlan (WMF): It's simple to reproduce – go to a diff and click a Twinkle revert link. What happens? The diff's edit summary gets broken (example) and the user talk page does not open properly (example). As far as errors in my browser console are concerned, I don't see any new errors in diff pages after enabling the user info cards. However, a warning, [CdxPopover]: The "anchor" prop must be provided to position the CdxPopover., is displayed only when I have the user info cards enabled. --Paloi Sciurala (talk｜contribs) 14:24, 9 August 2025 (UTC)
- I guess they are referring to the "Open user talk page after these types of reversions" option in en:Wikipedia:Twinkle/Preferences#rollback which also exists in the rowiki version of TW [1] and in the global version [2]. Johannnes89 (talk) 13:42, 9 August 2025 (UTC)
- Thanks for this report. I'm not familiar with a Twinkle revert link (I have the gadget enabled on enwiki) -- can you tell me how I can reproduce this issue? Do you see any errors in your browser console? KHarlan (WMF) (talk) 20:03, 8 August 2025 (UTC)
Небольшой баг
[edit]На странице истории в Викиучебнике на русском языке все никнеймы превращаются в символ о. См. скриншот. Mitte27 (talk) 00:35, 3 August 2025 (UTC)
Data is wrong for reverted edits, edits in last 60 days, and probably more
[edit]Bug reports for my User info on en.WP:
Data is wrong for reverted edits: My contributions say that I have just 14 reverted edits, but when I click on the link, I see my 1,000 most recent reverts, with a link to more.
Link is wrong for "New articles": When I click on the number of articles created, the link includes "namespace=all". It should instead be "namespace=0", I think. Changing that limits the results to article space, but I also see redirects. I think the link needs to have "tagfilter=mw-new-redirect&tagInvert=1" or something similar. Like this, which still has some redirects, but not all of them. That link also contains redirects that were created due to page moves, which should not count as new articles. I don't know how to get a link to actual articles created. Maybe just link to the xtools page instead?
Number is wrong for "New articles": It says I have created 23 articles, but I have created 39 articles, by my count. That's also what xtools says.
Editing activity over last 60 days (962 edits): This is clearly wrong, missing all data from longer than a few days ago.
I'm guessing that some of this will be fixed with database updates or something like that. Jonesey95 (talk) 04:06, 5 August 2025 (UTC)
- @Jonesey95: I came here to say the same thing. I'm guessing from experimenting that it only takes in to account a user's last thousand edits; if that's the case, the tool should say so explicitly, not just in a tooltip, because that's inaccessible to screen reader users, among others. Graham87 (talk) 07:21, 5 August 2025 (UTC)
- I came here with the same thoughts, as it says I have only 17 and there appears to be a 1k cap on the amount of thanks you've received. The data is fine as long as it's correctly labelled. ActivelyDisinterested (talk) 08:58, 5 August 2025 (UTC)
- I think your guess about a 1,000-item cap is correct. My "Edits in the last 60 days" now says "1,000", which is lower than the actual value. My "thanks" says 1,000 thanks as well, and I have 6,205 thanks. So it looks like the tool limited to 1,000 entries for some items, but not others (my local edits correctly says 406,397; I need to get a life). If there is not a tooltip, or if this limit is something that is under development, then the tool should in the short term add a "+" after entries that are known to have reached a limit, so that the numbers are not misleading. Jonesey95 (talk) 14:29, 5 August 2025 (UTC)
- This also applies to the edit activity graph. If a user made 1000 edits in the last 20 days, the other 40 days will display as days without any edits even if the user made another 1000 edits in this period. hgzh 07:03, 6 August 2025 (UTC)
- see phab:T400409 activity graph issue with more than 1.000 edits. Johannnes89 (talk) 12:29, 6 August 2025 (UTC)
- This also applies to the edit activity graph. If a user made 1000 edits in the last 20 days, the other 40 days will display as days without any edits even if the user made another 1000 edits in this period. hgzh 07:03, 6 August 2025 (UTC)
- I think your guess about a 1,000-item cap is correct. My "Edits in the last 60 days" now says "1,000", which is lower than the actual value. My "thanks" says 1,000 thanks as well, and I have 6,205 thanks. So it looks like the tool limited to 1,000 entries for some items, but not others (my local edits correctly says 406,397; I need to get a life). If there is not a tooltip, or if this limit is something that is under development, then the tool should in the short term add a "+" after entries that are known to have reached a limit, so that the numbers are not misleading. Jonesey95 (talk) 14:29, 5 August 2025 (UTC)
- I came here with the same thoughts, as it says I have only 17 and there appears to be a 1k cap on the amount of thanks you've received. The data is fine as long as it's correctly labelled. ActivelyDisinterested (talk) 08:58, 5 August 2025 (UTC)
What's happening with respect to this errors? These info cards still provide significant amounts of misleading information. Please at least add a disclaimer. Jonesey95 (talk) 22:12, 11 September 2025 (UTC)
- @Jonesey95 could you please clarify which issues you are referring to, and on which user accounts you’re seeing those issues? KHarlan (WMF) (talk) 05:19, 12 September 2025 (UTC)
- Most of the issues reported in the original post above are still present, which is easy to verify by clicking on my torso icon at en.WP. For my popup card on en.WP, the count for "reverted" is still wrong, the count for "New articles" is still wrong, and the graph is still wrong (it shows a long, flat section where there should be editing activity). The "New articles" link also still contains redirects that were created due to page moves, which should not count as new articles (maybe filter out the "New redirect" tag with
&tagfilter=mw-new-redirect&tagInvert=1, which seems to exist for post-2017 edits, or use data from xtools as suggested above). Jonesey95 (talk) 12:23, 12 September 2025 (UTC)- Thanks. We are unfortunately limited by our infrastructure here, which makes fixing these things in the UIC feature difficult (see also T341649: Provide an easy way for MediaWiki to fetch aggregate data from the data lake). As a stopgap, one idea would be to remove the "New articles" and "(reverted: $1)" count for users with a high edit count, as well as the editing activity graph. (See also T398500: [timebox: 3 days] Impact module: Support larger wgGEUserImpactMaxEdits which would solve these problems for users with <10k accounts.) Another idea would be to add tooltips informing the user as to why these numbers may be off for users with high edit counts. cc @Niharika KHarlan (WMF) (talk) 12:50, 12 September 2025 (UTC)
- I support doing something to prevent the tool from providing false information to viewers. Suggestions have been made above. Jonesey95 (talk) 20:54, 29 September 2025 (UTC)
- Thanks. We haven’t forgotten about this issue, and it’s been raised by several others. We will either remove these data points for users with a relatively high number of data points or add a disclaimer. KHarlan (WMF) (talk) 20:59, 29 September 2025 (UTC)
- I support doing something to prevent the tool from providing false information to viewers. Suggestions have been made above. Jonesey95 (talk) 20:54, 29 September 2025 (UTC)
- Thanks. We are unfortunately limited by our infrastructure here, which makes fixing these things in the UIC feature difficult (see also T341649: Provide an easy way for MediaWiki to fetch aggregate data from the data lake). As a stopgap, one idea would be to remove the "New articles" and "(reverted: $1)" count for users with a high edit count, as well as the editing activity graph. (See also T398500: [timebox: 3 days] Impact module: Support larger wgGEUserImpactMaxEdits which would solve these problems for users with <10k accounts.) Another idea would be to add tooltips informing the user as to why these numbers may be off for users with high edit counts. cc @Niharika KHarlan (WMF) (talk) 12:50, 12 September 2025 (UTC)
- Most of the issues reported in the original post above are still present, which is easy to verify by clicking on my torso icon at en.WP. For my popup card on en.WP, the count for "reverted" is still wrong, the count for "New articles" is still wrong, and the graph is still wrong (it shows a long, flat section where there should be editing activity). The "New articles" link also still contains redirects that were created due to page moves, which should not count as new articles (maybe filter out the "New redirect" tag with
UserInfoPopup
[edit]This is exciting! I use a slightly similar script, w:User:Guycn2/UserInfoPopup. However, the two features I most often use that script for aren't here: user gender identification and date/age of most recent edit. It would be great if this thing also had those features. Aaron Liu (talk) 04:29, 5 August 2025 (UTC)
- Gender pronouns would be VERY useful. I never remember where to find it. Jonesey95 (talk) 14:31, 5 August 2025 (UTC)
- We decided to remove the gender preference display (in T393343#10858405: UserInfoCard: Add data points for name, gender, local and global registration) because it seems like what we'd want instead are pronouns, which would depend on T389709: A new preference field for customizing pronouns on different languages being done first. KHarlan (WMF) (talk) 11:00, 9 August 2025 (UTC)
- We could have a ternary (he/him, she/her, or they/them) pronoun display as a stopgap. I don't think we need to wait for custom pronouns to display the three sets of pronouns that we currently have. Aaron Liu (talk) 21:35, 9 August 2025 (UTC)
- As I understand it, we currently store “male”, “female”, and “unknown”. It would not be possible to map those to pronouns in a way that addresses all users’ needs, and we would also need to set up translations, at which point we would be taking on the work of T389709. KHarlan (WMF) (talk) 13:32, 10 August 2025 (UTC)
- No worries. Just display what you have stored: Gender: male/female/unknown. If the pronoun task ever gets updated, the gender display in the popup can be enhanced. Until then, just give us what the user has selected. Easy-peasy. Jonesey95 (talk) 22:07, 11 September 2025 (UTC)
- @KHarlan (WMF) Not sure how I didn't see this, but I pretty much agree with Jonesey: Just do something like "Him" if the user selected "masculine" and "Her" if the user selected "feminine". This seems like something that would already be translated, and users who selected these options would probably be more content with such a deficient display instead of none at all, as practically, selecting these options causes other editors to call them He/Him or She/Her already in current practice. Aaron Liu (talk) 01:07, 12 September 2025 (UTC)
- As far as I can tell, "him" and "her" aren't already translated (https://codesearch.wmcloud.org/search/?q=%22him%22&files=&excludeFiles=&repos=, https://codesearch.wmcloud.org/search/?q=%22her%22&files=&excludeFiles=&repos=), and in any case, we need a solution that is not based on the existing binary classification for gender that's in MediaWiki. I would propose that we continue the discussion at T389709: A new preference field for customizing pronouns on different languages. KHarlan (WMF) (talk) 06:43, 12 September 2025 (UTC)
- At minimum, we could copy Citizen's existing translations, or Wkimedia's CapacityExchange's, under different names, or just transclude MediaWiki:Gender-male etc.
That we need an extensive pronouns system eventually doesn't mean we shouldn't implement a stopgap that would work similarly in the months or even years it takes to implement the pronoun system. Aaron Liu (talk) 11:57, 12 September 2025 (UTC)
- At minimum, we could copy Citizen's existing translations, or Wkimedia's CapacityExchange's, under different names, or just transclude MediaWiki:Gender-male etc.
- As far as I can tell, "him" and "her" aren't already translated (https://codesearch.wmcloud.org/search/?q=%22him%22&files=&excludeFiles=&repos=, https://codesearch.wmcloud.org/search/?q=%22her%22&files=&excludeFiles=&repos=), and in any case, we need a solution that is not based on the existing binary classification for gender that's in MediaWiki. I would propose that we continue the discussion at T389709: A new preference field for customizing pronouns on different languages. KHarlan (WMF) (talk) 06:43, 12 September 2025 (UTC)
- As I understand it, we currently store “male”, “female”, and “unknown”. It would not be possible to map those to pronouns in a way that addresses all users’ needs, and we would also need to set up translations, at which point we would be taking on the work of T389709. KHarlan (WMF) (talk) 13:32, 10 August 2025 (UTC)
- We could have a ternary (he/him, she/her, or they/them) pronoun display as a stopgap. I don't think we need to wait for custom pronouns to display the three sets of pronouns that we currently have. Aaron Liu (talk) 21:35, 9 August 2025 (UTC)
- We decided to remove the gender preference display (in T393343#10858405: UserInfoCard: Add data points for name, gender, local and global registration) because it seems like what we'd want instead are pronouns, which would depend on T389709: A new preference field for customizing pronouns on different languages being done first. KHarlan (WMF) (talk) 11:00, 9 August 2025 (UTC)
- Please, see this link below about "Most recent edit": Talk:Product Safety and Integrity/Anti-abuse signals/User Info#Maybe add "Most recent edit" -- Ooligan (talk) 03:26, 12 September 2025 (UTC)
Block reporting doesn't appear to work
[edit]The User Info documentation page says it shows: "Active local blocks (across all wikis, sitewide, or partial)". However, unless I'm missing something (and I could be because I use a screen reader), that feature doesn't appear to work at all. To pick a random example from the recent block log, when I open the User Info card for Philatron WIre and Cable on the English Wikipedia from this page history, it doesn't show any blocks, despite the user being indefinitely blocked. Furthermore, there are some established users who might prefer that their blocks on other wikis not be so easy to find as they could be with this tool, but as far as I'm concerned, that's their problem. Graham87 (talk) 08:33, 5 August 2025 (UTC)
- This is what the user info card shows when I click on the user you mentioned (Philatron WIre and Cable)::
- Joined: 2025-08-04 (1 day ago)
- Active blocks from all wikis: 1
- Past blocks: 0
- Global edits: 2
- Local edits: 1 (reverted: 0)
- New articles: 0
- Thanks received: 0 (given: 0)
- Checks: 0
- Active wikis: commonswiki
- Seems correct, there is just the one active block? Johannnes89 (talk) 13:08, 5 August 2025 (UTC)
- (Checks is only available to users with CU permissions) Johannnes89 (talk) 13:09, 5 August 2025 (UTC)
- @Johannnes89: Yeah the blocks don't display for me at all. Could the difference be that you have the technical ability to block users (being a steward) and I don't? I think this info should be available to everyone, as there are many non-admin vandal-fighters. FWIW the link to get to this user's details now is this log entry. Graham87 (talk) 16:03, 5 August 2025 (UTC)
- Yes, currently blocks are only shown to users who have permission to create blocks, but we should change that so that blocks are visible to anyone using the user info card. KHarlan (WMF) (talk) 15:00, 7 August 2025 (UTC)
- @KHarlan (WMF), Have you submitted a phabricator task to add blocks to display? -- Ooligan (talk) 16:03, 20 August 2025 (UTC)
- Yes, please see https://phabricator.wikimedia.org/T401984 - a patch has been merged for it. KHarlan (WMF) (talk) 16:44, 20 August 2025 (UTC)
- Thank you, @KHarlan (WMF). Please, reply here when this change is close to being "active." -- Ooligan (talk) 23:43, 20 August 2025 (UTC)
- The change should be on all wikis next Thursday, August 28. KHarlan (WMF) (talk) 04:24, 21 August 2025 (UTC)
- @KHarlan (WMF), today I have seen the the number of "active blocks from all wikis" as well as "past blocks" here for example: https://commons.wikimedia.org/wiki/File:Red_Panda_(29069275678).jpg, which is tagged as a"sockpuppet."
- However, this new change does not show the block duration of the each active block, such as "indefinite" for the sockpuppet above or the numbers of hours, days, weeks, months for other Users.
- Can this info card include block duration(s) for each "active blocks from all wikis"? It would be helpful to just seen this on the "info card," instead of clicking through pages to the get that information.
- Can this info card include block duration on the "past block(s)" as well, since blocks are often progressively increased in terms of their duration?
- Another suggestion would be to show a link to any "active discussion about the User on the Administrators' noticeboard"?
- Can this info card show all alternative account name(s), if they exist?
- Can this info card show all account names related to that User? Thanks, --
- Ooligan (talk) 19:46, 27 August 2025 (UTC)
- The change should be on all wikis next Thursday, August 28. KHarlan (WMF) (talk) 04:24, 21 August 2025 (UTC)
- Thank you, @KHarlan (WMF). Please, reply here when this change is close to being "active." -- Ooligan (talk) 23:43, 20 August 2025 (UTC)
- Yes, please see https://phabricator.wikimedia.org/T401984 - a patch has been merged for it. KHarlan (WMF) (talk) 16:44, 20 August 2025 (UTC)
- @KHarlan (WMF), Have you submitted a phabricator task to add blocks to display? -- Ooligan (talk) 16:03, 20 August 2025 (UTC)
- Yes, currently blocks are only shown to users who have permission to create blocks, but we should change that so that blocks are visible to anyone using the user info card. KHarlan (WMF) (talk) 15:00, 7 August 2025 (UTC)
.jpg){kind=link}
The user info should also be a special page
[edit]I think this would be a good idea for linking purposes, and also because this feature shows (or tries to show) unique data about a user that none of the other special pages do. Something like Special:Userinfo/Graham87. Graham87 (talk) 08:44, 5 August 2025 (UTC)
- something similar to en:Special:Impact (which is used on the newcomer homepage). Johannnes89 (talk) 12:30, 6 August 2025 (UTC)
- That's a good idea. I've added a task for it: https://phabricator.wikimedia.org/T402538 Thanks! -- NKohli (WMF) (talk) 15:05, 21 August 2025 (UTC)
Maybe add "Most recent edit"
[edit]Can a task be added to include the date of the "Most recent edit" by the User?
Also, you may already be aware, but the "Thanks received" and "given" are displying "0" today. I checked several Users details and they did both received and gave "Thanks."
P.S. - Good and simple feature. Best regards to the "Trust and Safety Product" Team. -- Ooligan (talk) 04:14, 7 August 2025 (UTC)
- @Ooligan can you please point to an example user where thanks received/given are displaying 0? Is it possibly on a non-Wikipedia wiki?
- We did discuss including "Most recent edit". It's included in the sparkline graph, so potentially duplicates information. But if we could find space for it, I think it would be nice to have. cc @Niharika @KColeman-WMF KHarlan (WMF) (talk) 11:26, 9 August 2025 (UTC)
- Perhaps allow users to select a preference of "date of most recent edit" instead of the "sparkline graph," if space is an issue. Thanks for the reply. -- Ooligan (talk) 03:19, 12 September 2025 (UTC)
- @Ooligan I made a task for showing the most recent edit here: https://phabricator.wikimedia.org/T402537 If you have any thoughts on the design mock, please comment on the task. Thanks! -- NKohli (WMF) (talk) 15:06, 21 August 2025 (UTC)
blocks are not showing
[edit]Here: [3]
Minutes ago this user info card shows:
- Joined: 29 July 2018 (7 years ago)
- Global edits: 1,204,854
- Local edits: 1,204,850 (reverted: 0)
- New articles: 0
- Thanks received: 0 (given: 0)
-- Ooligan (talk) 06:13, 7 August 2025 (UTC)
- Thanks for noting this -- see also "Block reporting doesn't appear to work" above. KHarlan (WMF) (talk) 11:27, 9 August 2025 (UTC)
Please, add "date of last edit" to display.
[edit]This would be helpful. Thanks, -- Ooligan (talk) 16:05, 20 August 2025 (UTC)
Please, add "deceased" to display for Users that have died.
[edit]This former volunteer, for example. https://commons.wikimedia.org/wiki/User:Patrick_Rogel This would be informative. Thanks, -- Ooligan (talk) 20:55, 6 September 2025 (UTC)
- @Ooligan hello! Thanks for this request. I don't know how this data is tracked and whether we will be able to fulfill this request. I will file a task and ask our team to look at it. -- NKohli (WMF) (talk) 11:38, 8 September 2025 (UTC)
- Thanks, @NKohli (WMF). Fyi,
- "Deceased Wikimedian" template is used on Commons
- Category: https://commons.wikimedia.org/wiki/Category:Deceased_Commons_users
- Wikipedia:Deceased Wikipedians/Members: https://en.wikipedia.org/wiki/Wikipedia:Deceased_Wikipedians/Members
- Meta deceased editors here: https://meta.wikimedia.org/wiki/Deceased_editors
- Listed here are current volunteers that work honor these and future deceased volunteers:https://commons.wikimedia.org/wiki/Commons:Deceased_contributors
- The "info card" for Patrick Rogel (deceased volunteer) today shows "globally locked since ....". The link on that line goes to the global lock page, which does not inform the reader that Patrick is deceased. You must click another link here: https://meta.wikimedia.org/wiki/Special:CentralAuth/Patrick_Rogel to see text stating the reason for this "global lock" is because of Patrick's death.
- Can the "globally locked" line on the info card be converted into the word "Deceased" or the phrase "Deceased Wikimedian/ Wikpedian/ Volunteer", (where the lock is because of a volunteer's confirmed death)? Thank you, --
- Ooligan (talk) 17:26, 10 September 2025 (UTC)
- Thanks, @NKohli (WMF). Fyi,
Please, add "renamed" to display the all User names of the User being displayed.
[edit]There are "renamed Users" with past blocks under their previous name(s). This would be helpful and informative. Thanks, -- Ooligan (talk) 21:12, 6 September 2025 (UTC)
- @Ooligan Thanks! We will look into this. -- NKohli (WMF) (talk) 11:44, 8 September 2025 (UTC)
Wrong join date
[edit]Hi all, perhaps a bit out of scope, but I looked to my own data. On English Wikipedia my "join date" is correctly listed, 24 January 2003 (23 years ago). On my home wiki, nl.wikipedia.org it lists the date of 28 May 2008 (17 years ago), while my first edit was on 14 December 2002 (23 years ago). The cause is probably the Global contributions. The date of 28 May 2008 is shown in that overview. I have known for many years this is wrong, but because this information will be so easily shown due to the introduction of User Info, it should be correct imho. The same I saw in the join dates of other "oldies". Can this be corrected? Regards, Ellywa (talk) 20:00, 9 September 2025 (UTC)
- @Ellywa this may be because of how the software recorded this early on and there may not be an easy way to fix it. I have added your comment to this task https://phabricator.wikimedia.org/T397340. -- NKohli (WMF) (talk) 10:32, 10 September 2025 (UTC)
- Thanks, it was a known issue, apparently. Ellywa (talk) 10:46, 10 September 2025 (UTC)
Blocks on other wikis count includes blocks on current wikis
[edit]See w:fr:Spécial:Contributions/~2025-54494-8. UserInfoCard reports this user to be blocked on one other wiki, but user is only blocked on current wiki (frwiki). Escargot bleu (talk) 11:14, 14 September 2025 (UTC)
- It makes sense to include current wiki in the count, a rewording would solve the issue. Escargot bleu (talk) 11:16, 14 September 2025 (UTC)
- I think it's a translation issue, because the English wording is "Active blocks from all wikis" but the French wording translates to "Active blocks from other wikis" KHarlan (WMF) (talk) 12:56, 24 September 2025 (UTC)
- I.e. This can be fixed at translatewiki. (or help review all translations for that extension) Quiddity (WMF) (talk) 21:49, 24 September 2025 (UTC)
XTools link
[edit]Is it possible to add a link to the xtools page of the user as an item in the three dots menu? If not possible by default, is there a way for me to customize and add my own links like the portal links using javascript? ~/Bunnypranav:<ping> 11:00, 20 September 2025 (UTC)
- Not currently. We've talked about enabling users to customize what goes into the overflow menu, but haven't filed a task for it yet. KHarlan (WMF) (talk) 12:53, 24 September 2025 (UTC)
- Could you add xtools then, should be pretty uncontroversial since every wiki uses it right? ~/Bunnypranav:<ping> 13:12, 24 September 2025 (UTC)
- I agreed, this would be a valuable addition @Bunnypranav. @KHarlan (WMF)- can your team add xtools to the "overflow menu?" Thanks, -- Ooligan (talk) 15:29, 26 September 2025 (UTC)
- I filed T406012: UserInfoCard: Add link to view XTools to track this. KHarlan (WMF) (talk) 09:48, 30 September 2025 (UTC)
Falsche Angaben im neuen Mensch-ärgere-Dich-nicht-Männchen
[edit]Hallo,
wenn ich in Wirklichkeit 716 Artikel geschrieben habe, dann möchte ich nicht, dass da 162 neue Artikel angegeben werden. Das ist umso ärgerlicher, als ihr es für das Beste haltet Sperren des Nutzers prominent voranzustellen, auch wenn diese ewig zurückliegen. Diese Funktion ist in der von Euch initiierten Absicht regelrecht frech!!! Ändert das gefälligst. --~~~~ Stephan Klage (talk) 20:44, 1 October 2025 (UTC)
- This should be fixed now (at least partially, via T399096: UserInfoCard: Number of "New articles" incorrect) KHarlan (WMF) (talk) 19:49, 2 October 2025 (UTC)
- It's not fixed yet. See User:zieglhar: 176 vs. 471. That's a not acceptable misinformastion. Zieglhar (talk) 06:47, 4 October 2025 (UTC)
- Sorry, I spoke too soon. The patch that addresses the bug in T399096: UserInfoCard: Number of "New articles" incorrect ( UserInfoCard: Hide new articles count when likely to be inaccurate (mediawiki/extensions/CheckUser~1192554)) is not yet in production. I can deploy it on Monday. (There's also a related issue with the reverted edit count being wrong in some situations, and again, that hasn't yet arrived in production UserInfoCard: Hide reverted edit count if user has more than 1,000 edits (mediawiki/extensions/CheckUser~1192516))
- More background: though it might sound strange, we unfortunately don't have an easy mechanism to count new pages/articles created by users who have been editing for a long time, or who have many log entries. There is work underway to improve our ability to query data like this, but for now, the compromise solution is to just hide "New articles" when the number is likely to be wrong. KHarlan (WMF) (talk) 07:30, 4 October 2025 (UTC)
- This change has now been deployed. KHarlan (WMF) (talk) 07:37, 6 October 2025 (UTC)
- It's not fixed yet. See User:zieglhar: 176 vs. 471. That's a not acceptable misinformastion. Zieglhar (talk) 06:47, 4 October 2025 (UTC)
Stop this
[edit]As a normal user i don't see any reason for this surveillance. This puts a general suspicion on every user most of which didn't do anything wrong. I know that this is public information, but it seeds stalking and distrust among normal users and destroys the climate of collaboration. Please stop the tool or at least ask the communities before activating this for everyone. The tool should be limited to users who actually need it (admins etc.). --Ailura (talk) 09:32, 2 October 2025 (UTC)
- +1. Please switch off immediately. Mautpreller (talk) 09:56, 2 October 2025 (UTC)
- As a sysop specialized in handling incidents in the whole range from vandalism to serious user conflicts on de:wp, I am more than irritated by this. Even if it worked properly, it would be a burden on the community, as it makes the vandal hunter's very specific perspective the lens through which every user now views their colleagues by default. Frankly, I am disgusted. Please stop this immediately. --Gardini (talk) 09:39, 3 October 2025 (UTC)
- @Ailura @Mautpreller @Gardini thank you for your comments. I just wanted to leave a short note to let you know that my team has seen your feedback, we understand the concerns you are raising, and we will post some responses within the next few days. KHarlan (WMF) (talk) 10:43, 3 October 2025 (UTC)
- @KHarlan (WMF) guten Morgen. Den Bedenken der Kolleginnen und Kollegen schließe ich mich ebenfalls als langjährige Mitarbeiterin im Bereich RC und Konflikte, egal ob Schülerunfug oder Personen, die sich inhaltlich nicht einig sind, an. Diese Überwachung der Konten mit ausgewählten, zumeist noch falschen Infos ist nicht hilfreich und befördert eher noch weitere Kontlikte. Menschen sollten nicht nach oberflächlichen Kriterien einsortiert werden. Viele Grüße Itti (talk) 08:47, 6 October 2025 (UTC)
- @Ailura @Mautpreller @Gardini thank you for your comments. I just wanted to leave a short note to let you know that my team has seen your feedback, we understand the concerns you are raising, and we will post some responses within the next few days. KHarlan (WMF) (talk) 10:43, 3 October 2025 (UTC)
Preference section
[edit]Why is this tool in the "Appearance" section of the preferences? This section has settings on skin or date format. I would not expect such a tool in that section. I think it should be at the same section as "Temporary account IP reveal" and "IP Information". As this would make the main setting page very long it might be better to create a new tab. The name could be "Moderation tools". GPSLeo (talk) 11:41, 2 October 2025 (UTC)
- Thanks for the suggestion. "Appearance" was somewhat arbitrary of a choice; I'm open to placing it somewhere else. KHarlan (WMF) (talk) 19:50, 2 October 2025 (UTC)
Displaying past blocks (and a warning symbol) misrepresents users
[edit]If an account is blocked on another Wiki or the user has a previous block on the local Wiki, a colorized warning symbol is shown. This stigmatizes users for what may have been self-requested, purely technical, or simply improper blocks (even when later overturned). For instance, self-requested blocks to enforce a Wikibreak are common on Wikimedia projects (see, eg, en:WP:SELFBLOCK). On dewiki, two out of four bureaucrats have previous blocks; on enwiki, 15 out of 37 current ArbCom members and community checkusers have previous local blocks, including self-performed blocks due to account compromise, tests, self-requested blocks, inadvertent blocks as a result of an administrator clicking on the wrong user, and inadvertent self-performed blocks where the user blocked their own account by mistake instead of someone else. Prominently displaying a block count and a warning label for users with prior blocks stigmatizes those users in perpetuity as individuals unfamiliar with local blocking practices will invariably and reasonably assume that fellow users with a warning symbol in their user info card are less trustworthy. In addition, (highly) active users are disproportionately affected as they have a higher likelihood of accruing blocks over their editing histories. The feature therefore strikes me as very much ill-advised when enabled by default for all registered users (as is currently the case on several Wikis). Pajz (talk) 12:43, 2 October 2025 (UTC)
- Thanks for raising this. I also think that it's less useful to see a count of past blocks after a certain period of time, and personally would be in favor of not displaying this number when the block was beyond a certain time in the past. @Pajz do you have a suggestion on how long of a time period would be reasonable? (cc @Niharika) KHarlan (WMF) (talk) 19:48, 2 October 2025 (UTC)
- I think this numbers should always be there. For me this simply shows that I not need to have a look at the log when the number is zero. If the number is not zero this means nothing about the behaviour of this user until I had a look at the log with the block comments. GPSLeo (talk) 06:25, 3 October 2025 (UTC)
- I think both things can be true -- this data point is useful for some users to be able to see, and for others, it's unnecessarily stigmatizing other users. Maybe it would make sense to have the default behavior be to not show past blocks when those blocks expired more than 90 days ago; and users who always want to see this data point could toggle this in a set of preferences for the user info card feature. In general, I think it would make sense to make it possible to place moderator-focused features behind preferences that are not on by default for general purpose users of the tool. KHarlan (WMF) (talk) 08:26, 3 October 2025 (UTC)
- It should not be shown in any case. The default user of Wikipedia is not a vandal fighter or admin. The whole section on block log statistics, ongoing or past, should be removed entirely from the default info, and as soon as possible. This is actively hurting communities. Gardini (talk) 10:20, 3 October 2025 (UTC)
- @Gardini thank you for your feedback. I understand your perspective on this and have been reading through the concerns on the dewiki thread for this feature. Do you think something like this would work?
- don’t show the “active blocks” and “past blocks” rows at all when the count is 0. This avoids putting users into the mindset of thinking about blocks when there is no reason to.
- for users who don’t have privileges to block other users, don’t show the “past blocks” row when the block is more than N days in the past
- "Active blocks" seems useful to display in the default view, because of users who engage in cross wiki abuse, so I think if the count is more than 0, it makes sense to show it.
- Are there other data points that you are concerned about, or it is just the active/past blocks count? KHarlan (WMF) (talk) 10:40, 3 October 2025 (UTC)
- (FWIW, the active/past blocks used to be available only to users with blocking rights, but we changed that in T401984: UserInfoCard: Allow anyone to view active and past blocks) KHarlan (WMF) (talk) 10:46, 3 October 2025 (UTC)
- @Gardini thank you for your feedback. I understand your perspective on this and have been reading through the concerns on the dewiki thread for this feature. Do you think something like this would work?
- It should not be shown in any case. The default user of Wikipedia is not a vandal fighter or admin. The whole section on block log statistics, ongoing or past, should be removed entirely from the default info, and as soon as possible. This is actively hurting communities. Gardini (talk) 10:20, 3 October 2025 (UTC)
- I think both things can be true -- this data point is useful for some users to be able to see, and for others, it's unnecessarily stigmatizing other users. Maybe it would make sense to have the default behavior be to not show past blocks when those blocks expired more than 90 days ago; and users who always want to see this data point could toggle this in a set of preferences for the user info card feature. In general, I think it would make sense to make it possible to place moderator-focused features behind preferences that are not on by default for general purpose users of the tool. KHarlan (WMF) (talk) 08:26, 3 October 2025 (UTC)
- Hi, @KHarlan (WMF), thanks for the response. I appreciate that limiting the display to recent blocks would effectively be a modest improvement, as it would increase the number of users shown with zero blocks. However, it doesn't really address the issue on a more fundamental level—recent blocks can be just as innocuous as blocks farther in the past, so the potential for stigma would remain, even if reduced. Limiting the display of block-related information to users with blocking rights (i.e., reverting the change made in T401984) would, on the other hand, amount to a more meaningful improvement, consistent with the concerns that your own team appears to have had originally. If there's perceived value in that information for non-admin 'RC patrollers', then allowing non-admins to enable it might be a viable compromise. But, for the time being, I would still urge the Foundation to not show the block count and the block count-related warning symbols to the general public unfamiliar with the significance of an entry in the block log (or lack thereof). Doing so would also better align with the core movement values. See Wikimedia Foundation Universal Code of Conduct, § 2.1 (stating that "All Wikimedians should assume unless evidence otherwise exists that others are here to collaboratively improve the projects [...]"). We should avoid dividing communities into "good" and "bad" users based on past blocks, and be careful not to introduce bias into new users' first impressions of experienced contributors. Best, Pajz (talk) 20:34, 7 October 2025 (UTC)
- Thanks for your note @Pajz. The change we implemented last week was T406480: Limit who can view past blocks and remove redundant data points, where we've made it so that only users who have blocking rights can view past blocks, and the past blocks/active blocks rows do not display at all if the count is zero. Active blocks are shown to anyone, though. Does this sound OK with you? KHarlan (WMF) (talk) 20:38, 7 October 2025 (UTC)
- @KHarlan (WMF) Thank you! I had not seen that. Very much appreciate your action on this matter. Pajz (talk) 21:11, 7 October 2025 (UTC)
- Thanks for your note @Pajz. The change we implemented last week was T406480: Limit who can view past blocks and remove redundant data points, where we've made it so that only users who have blocking rights can view past blocks, and the past blocks/active blocks rows do not display at all if the count is zero. Active blocks are shown to anyone, though. Does this sound OK with you? KHarlan (WMF) (talk) 20:38, 7 October 2025 (UTC)
- I think this numbers should always be there. For me this simply shows that I not need to have a look at the log when the number is zero. If the number is not zero this means nothing about the behaviour of this user until I had a look at the log with the block comments. GPSLeo (talk) 06:25, 3 October 2025 (UTC)
Feature Request: First edit date
[edit]Currently the User Info card shows how many edits a user has made globally and on a specific wiki. It also displays the user’s registration date, but not their first edit date. For some older accounts, the registration date is not available, so including the first edit date would be especially helpful.- ❙❚❚❙❙ GnOeee ❚❙❚❙❙ ✉ 17:18, 30 October 2025 (UTC)
- I support this. First edit date is also relevant for accounts that start editing long after having created their accounts. --Paloi Sciurala (talk｜contribs) 14:57, 31 October 2025 (UTC)