Page MenuHomePhabricator

RC filters: The 'X edits' & 'X days of activity' values in the user-experience-level descriptions should be taken from the wiki's configuration, rather than being hard-coded within the system messages
Open, Needs TriagePublic5 Estimated Story PointsBUG REPORT

Description

Special:RecentChanges can be filtered for edits made by "Newcomers", "Learners", and "Experienced users":

screenshot.png (325×659 px, 22 KB)

The thresholds for what define a "learner" or an "experienced user" can be configured using the $wgLearnerEdits, $wgLearnerMemberSince, $wgExperiencedUserEdits, & $wgExperiencedUserMemberSince config variables (which default to the values seen in the screenshot above).
To quote their docblock:

- newcomer: has not yet reached the 'learner' level

- learner: has at least $wgLearnerEdits and has been
  a member for $wgLearnerMemberSince days
  but has not yet reached the 'experienced' level.

- experienced: has at least $wgExperiencedUserEdits edits and
  has been a member for $wgExperiencedUserMemberSince days.

As these are config variables, their values can be modified on individual wikis. However, the descriptions for the 'Newcomers' and 'Experienced users' filter checkboxes currently hard-code these values to the config-variables' defaults:

  • rcfilters-filter-user-experience-level-newcomer-description: "Registered editors who have fewer than 10 edits or 4 days of activity."
  • rcfilters-filter-user-experience-level-experienced-description: "Registered editors with more than 500 edits and 30 days of activity."

These messages should presumably be changed to take the 'X edits' & 'X days' values from the wiki's configuration itself; as otherwise, these descriptions would be inaccurate for a wiki that uses the config variables to set its own thresholds for what constitutes a 'learner' and/or an 'experienced user'.

Acceptance criteria

  • The 'Newcomers' & 'Experienced users' checkbox descriptions match a wiki's custom-configured values for $wg(Learner|ExperiencedUser)(Edits|MemberSince).
  • {{PLURAL:}} is used in the system messages.
  • (wishlist/in an ideal world) The descriptions look nice when an Edits or MemberSince variable is set to 0 -- e.g., if $wgLearnerMemberSince is set to 0, the 'Newcomers' description might read "Registered editors who have fewer than X edits.", rather than "Registered editors who have fewer than X edits or 0 days of activity.". (To avoid lego messages, this might need an extra two system messages to be added for both the 'newcomers' & 'experienced editors' descriptions, that would be used when an Edits or MemberSince variable is set to 0.)
  • (anything else?)

Original task description:

Task title: Values in MediaWiki:rcfilters-filter-user-experience-level-newcomer-description

Found MediaWiki:rcfilters-filter-user-experience-level-newcomer-description/en and it seems like this reflects the level for autopromote, but those levels are different for various sites. For example, at Norwegian (bokmål) Wikipedia they are set to 14 days and 50 edits.

If the values in the message reflects the actual level for autopromote, then they should be picked up accordingly.

There is a similar problem in MediaWiki:rcfilters-filter-user-experience-level-experienced-description/en.

Event Timeline

Restricted Application added subscribers: jhsoby, Aklapper. · View Herald Transcript

It is configurable (wgLearnerEdits, wgExperiencedUserEdits, wgLearnerMemberSince, wgExperiencedUserMemberSince), but it's not actively configured (all the wikis use the same values).

Despite that, it should be made to pick up these settings to be future-proof.

(There's also a product question (@jmatazzoni) of whether to vary the settings per wiki, which should be a separate task.)

The reason we made up our own names ("learner" "Newcomer" ) instead of using the categories (autoconfirmed, extended confirmed) is that these definitions are based on research. So we don't really recommend that wikis conform these to their own user rights categories. However, it's probably a good idea to future-proof this, in case wikis do that .

A_smart_kitten renamed this task from Values in MediaWiki:rcfilters-filter-user-experience-level-newcomer-description to RC filters: The 'X edits' & 'X days of activity' values in the user-experience-level descriptions should be taken from the wiki's configuration, rather than being hard-coded within the system messages.Jul 4 2025, 2:00 PM
A_smart_kitten updated the task description. (Show Details)
A_smart_kitten changed the subtype of this task from "Task" to "Bug Report".
A_smart_kitten subscribed.

I came across this issue myself recently. Gonna try to give it a go.

Change #1170403 had a related patch set uploaded (by A smart kitten; author: A smart kitten):

[mediawiki/core@master] [PROOF OF CONCEPT] recentchanges: Take the values for the "newcomer" and "experienced editor" filter descriptions from the relevant config variables

https://gerrit.wikimedia.org/r/1170403

Change #1170404 had a related patch set uploaded (by A smart kitten; author: A smart kitten):

[mediawiki/core@master] [ALTERNATIVE PROOF OF CONCEPT] recentchanges: Take the values for the "newcomer" and "experienced editor" filter descriptions from the relevant config variables

https://gerrit.wikimedia.org/r/1170404

A_smart_kitten moved this task from Triaged to Code review requests on the Moderator-Tools-Team board.

...having said that, and having now looked at the code here a bit, it seems like this might be a bit more complicated to fix than it first appeared (especially to someone brand-new to the RC codebase like myself). The main problem seems to be that there's currently no defined way to pass any system-message parameters from the PHP code (which defines the filters) to the RecentChanges JavaScript (which renders the system messages); so, in order to pass any parameters through to the RC filter-description messages, that code pathway first needs to be developed.
I've uploaded a couple of hacky proofs of concept to prove that this can be done, but - given what I've said - I'm gonna un-assign myself from this task for now. I might come back to it in the future, but I don't want to stop anyone else from working on it in the meantime if they want to :)

(That being said, if anyone has the time, I would appreciate any comments from the Moderator-Tools-Team on the proof-of-concept patch[es] regarding what you think about them in theory :D (& in particular, about how you think the code should be engineered to allow passing message parameters from the PHP to the JS!).
I'm gonna move this to "Code review requests" just to make sure this task gets seen again now that I've uploaded these proof-of-concept patches, but obviously feel free to move back to "Triaged" as/when desired.)


One open question here that might be worth noting: if we're going to implement the ability to pass parameters into RC-filter-descriptions, should we also be implementing this/should we also implement the same thing for RC-filter-labels?

I prefer the first approach as having the explicitness of a named parameter such as "descriptionParameters" is clearer in my opinion than an array which may contain the param (mostly for quick readability).
Thanks for all your work, and I hope this helps! Also feel free to wait for some more folks on the ModTools team to weigh in on this as well.

I agree with @Kgraessle that the first approach would be better. Another avenue we might explore is to see if we can pass the variables via the ResourceLoader, but I would be OK with the first approach, pending further testing.

jsn.sherman subscribed.

Thank you for exploring some solutions to this problem. I agree that the resource loader is a promising approach. There's nothing actionable left for us on these proof of concept patches, but we should pick up this work and solve the issue using the findings. I'm moving this out of review and into our priority maintenance queue.

No problem! If y'all want to move forward with using ResourceLoader then I'll probably leave the rest of the ticket to you if that's okay (but will code-review the bits that I can), as I'm also not yet super familiar with how RL would work in this scenario 😅

Change #1170403 abandoned by A smart kitten:

[mediawiki/core@master] [PROOF OF CONCEPT] recentchanges: Take the values for the "newcomer" and "experienced editor" filter descriptions from the relevant config variables

Reason:

the proof of concept was reviewed; next steps are as in the task :)

https://gerrit.wikimedia.org/r/1170403

Change #1170404 abandoned by A smart kitten:

[mediawiki/core@master] [ALTERNATIVE PROOF OF CONCEPT] recentchanges: Take the values for the "newcomer" and "experienced editor" filter descriptions from the relevant config variables

Reason:

the proof of concept was reviewed; next steps are as in the task :)

https://gerrit.wikimedia.org/r/1170404

No problem! If y'all want to move forward with using ResourceLoader then I'll probably leave the rest of the ticket to you if that's okay (but will code-review the bits that I can), as I'm also not yet super familiar with how RL would work in this scenario 😅

It's occurred to me that the idea to use ResourceLoader seems potentially similar to T201574: Put RCFilters i18n messages and other config in a ResourceLoader data module. I'm not familiar enough with RL to know how/if that ticket fits into things, but dropping a link to it here in case it does.

Dillon changed the task status from Open to In Progress.Thu, Jan 29, 3:46 PM
Dillon claimed this task.
Dillon moved this task from Eng review to In Progress on the Moderator-Tools-Team (Kanban) board.
Dillon changed the task status from In Progress to Open.Thu, Jan 29, 5:39 PM
Dillon moved this task from In Progress to Ready on the Moderator-Tools-Team (Kanban) board.
Dillon edited projects, added Essential-Work; removed Technical-Debt.
Dillon subscribed.