This is an archive of past discussions about MediaWiki:Watchlist-messages. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Please add The [[Wikipedia:New pages patrol/Reviewers|New Page Review team]] will be asking the WMF for [[Wikipedia:New pages patrol/Coordination/2022 WMF letter|attention to the PageTriage software]]. Please review and if you support it, consider signing it.The New Page Review team will be asking the WMF for attention to the PageTriage software. Please review the request and if you support it, consider signing it. MB04:32, 20 August 2022 (UTC)
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Please add The Guild of Copyeditors' September Drive runs from the 1st September 0:00 UTC to 31st September 23:59 UTC. Sign up [[Wikipedia:WikiProject Guild of Copy Editors/Backlog elimination drives/September 2022|here]]. Thanks, Zippybonzo | Talk (he|him) 07:51, 26 August 2022 (UTC)
On hold till 30 AUG
Suggested tweak:
@Zippybonzo: made some tweaks, see above. Tried to make it more of an "invitation" than an "announcement"; as this is long and not extremely formal (like an election), the timestamps on the WLN probably aren't necessary, used more standard date formats because a lot of people use things that adjust their display of dates. We have a somewhat undocumented manual of style for these - maybe we'll write it up one day! — xaosfluxTalk14:15, 26 August 2022 (UTC)
@Stephen, voter participation is quite low in the Wikimedia movement - I believe it was in the low 20 percents last year and the low ten percents the year before. I personally feel that widespread encouragement of voters is crucial to electing a representative Board of Trustees that guides the movement in such crucial times. 🐶 EpicPupper(he/him | talk)00:13, 25 August 2022 (UTC)
@Stephen I think the Central Notice banner was a bit buggy and overly appearing, it will still be around though some people have them suppressed. In general, I agree that we shouldn't overly duplicate things that are on CN with WLN, but there is a history that elections get extra notifications. Even our own arbcom election, we use this banner, plus send out tens of thousands of talk page notices! So, I'm not going to just pull it, however if a consensus of the community finds this useless through discussion I would certainly then. Perhaps you could start a follow up at Wikipedia:Village_pump_(miscellaneous)#The_2022_Board_of_Trustees_election_Community_Voting_period_is_now_open - or invite people to this request from there. — xaosfluxTalk00:28, 25 August 2022 (UTC)
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Hi @Xaosflux, our current banner will only reach Meta-Wiki and Commons. We didn't want to disturb the Wikipedia community, but also would like to reach them, hence the thought for the WLN. For us to activate banners on Wikipedia, we would need assurance from more editors that it's ok :) What do you think? MPourzaki (WMF) (talk) 20:52, 7 December 2022 (UTC)
@MPourzaki (WMF) these are likely both OK; we usually run these for a week so lets make sure we don't get negative feedback on the other post and can move forward with both the CN and WLN likely. — xaosfluxTalk21:05, 7 December 2022 (UTC)
The CN was activated, it will likely only be "shown once" for editors. We usually run these for a week - so let's see about this one for maybe Monday. — xaosfluxTalk10:33, 9 December 2022 (UTC)
Mock ups
Mockup 1
Mockup 2
Discuss mockups
@EpicPupper, Ed Erhart (WMF), and MPourzaki (WMF):; I placed a mock up above. We strive to keep these simple with a single call to action. In this case the call to action it "to vote"; I'm not sure if the "who" wants this to be done is best described as the movement group, the WMF, or someone else though. Any feedback before go-ahead? — xaosfluxTalk14:51, 12 December 2022 (UTC)
MPourzaki (WMF): This is a watchlist notice (so a bit different than a banner, there is no "diet"), so it will show to anyone who is looking at their watchlist, has not hidden watchlist notices, and has not dismissed the message, until it is removed or until the 19th. (xaosflux will it show on the day of the 19th?) –xenotalk04:27, 15 December 2022 (UTC)
It should "stop showing" once it is the 19th, sometimes these act up a bit because the (un)hiding is client side though. — xaosfluxTalk11:53, 15 December 2022 (UTC)
xaosflux: Should it instead display until the 20th then? I guess there would be 1 minute where it might show and a person could not vote, but I think the 23h59m of voting invitations still ongoing during the day would outweigh that offside chance. A looming deadline can be very motivating :). –xenotalk23:08, 15 December 2022 (UTC)
@MPourzaki (WMF) no, it is any logged in user that goes to Special:Watchlist. We usually use WLN's to advertise things that can be of interest to all editors, mostly: local contests, elections, the monthly Signpost publication. Some editors never go to this page, some use it constantly. — xaosfluxTalk20:33, 15 December 2022 (UTC)
The one example I looked at for the Signpost used {{Display/watchlist}}, which is why I suggested that perhaps it should have a parameter. But maybe the Signpost notice doesn't sufficiently bother anyone... isaacl (talk) 16:37, 16 December 2022 (UTC)
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Hi, I was wondering if a notice about the planned deployment could be added. I think the wording of the banners (which only appear once for every desktop user now) could be reused. It'd be ideal in terms of predictability if the date and hour were added as well:
The reason why I'm requesting this in addition to the banners is that we'd like to use different subtle methods instead of pushing annoying communication through a limited number of spaces. SGrabarczuk (WMF) (talk) 02:23, 13 January 2023 (UTC)
@SGrabarczuk (WMF) yes, I think we should. Think this verbiage can be improved, will work something up below. We generally have a few components in these, agree "what is happening" (which can include that opt-in direction), "when is it happening" are important; there is normally one primary "call to action" which I think would be best with a "give feedback" type link. What is the best page for feedback to be left?. — xaosfluxTalk16:09, 13 January 2023 (UTC)
I'm not sure if we're interested in receiving general feedback because it'd mostly be WP:ILIKEIT/WP:IDONTLIKEIT. I'll discuss with my team mates if we prefer asking for any specific feedback.
Regarding sending local people to a different wiki, I understand, that's against habits and feels like a barrier. No one loves having to send outside of their natural habitat. On the other hand though, I think we may take the advantage of the fact that there's no language barrier. People will be able to see what discussions are taking place, learn about the existing viewpoints, see if anyone has raised their issue already, etc. They'd be more informed. That would be more useful both for users and for us. SGrabarczuk (WMF) (talk) 17:20, 13 January 2023 (UTC)
I think many people would go to VPT anyway, because that's what they always do (WP:THURSDAY etc.). So now we're instructing them to go there (not that it's in our power to change that, we just accept the reality) and we're suggesting MediaWiki as a place to write about general things, but on the talk page of the local landing page, we're admitting that writing there does also work for us.
{{Display/watchlist
|until= January 27, 2023
|cookie= x
|text= The new <u>desktop</u> skin ([[wp:Vector 2022|'''Vector 2022''']]) will be enabled for all readers and most editors using the legacy Vector skin on 18 January 2023 at 15:00 UTC. Editor may enable this early, or revert once the change is made in [[Special:Preferences#mw-prefsection-rendering|preferences]].
}}
Noted some more above, there really isn't a good "opt-out" of getting the change force upon you. (Trying to get people to set up a global pref and override is likely to lead them to worse problems). — xaosfluxTalk19:10, 16 January 2023 (UTC)
Any interest in changing or revert once the change is made in preferences to or revert in preferences once the change is made? I find the second one to be clearer. It avoids an issue where the reader associates "in preferences" with the wrong part of the sentence. –Novem Linguae (talk) 21:39, 16 January 2023 (UTC)
@ZI Jony what exactly do you want it to say? You get a sentence or two, which should have only one bolded link as your "call to action" (what you want people to click). — xaosfluxTalk21:12, 16 January 2023 (UTC)
Feminism and Folklore 2023 writing contest is going on. Participate, write/improve articles and win prizes.
@ZI Jony there has been some opposition as the scope of the editors this may be relevant to appears to be small. Are there any other wikiprojects associated with Wikipedia:Feminism and Folklore? Another option would be to massmessage the project members of such projects. — xaosfluxTalk11:22, 18 January 2023 (UTC)
@ZI Jony any more thoughts on this, the discussion so far seems to suggest that this project is too niche to advertise to all editors on this notice. — xaosfluxTalk00:07, 21 January 2023 (UTC)
Anything but adding this to the WLN. Without WMF staff acknowledging this as a possibility this is clearly beyond what community consensus can determine WP:CONEXCEPT. This is a WMF decision that is solely in their hands and considering the "vibe" around the deployment it seems beyond unlikely for this to go anywhere. Terasail[✉️]00:59, 20 January 2023 (UTC)
While I agree that this RfC, less than a day after the deployment and not communicated at all within the talk page, was preemptive, the deployment wasn't an office action, if that's what you mean. Aaron Liu (talk) 01:14, 20 January 2023 (UTC)
You are looking at the wrong bullet. The right bullet to read is
Some matters that may seem subject to the consensus of the community at the English-language Wikipedia (en.wikipedia.org) are in a separate domain. In particular, the community of MediaWiki software developers, including both paid Wikimedia Foundation staff and volunteers, and the sister wikis, are largely separate entities. These independent, co-equal communities operate however they deem necessary or appropriate, such as adding, removing, or changing software features (see meta:Limits to configuration changes), or accepting or rejecting some contributions, even if their actions are not endorsed by editors here.
The skin configuration is not a software feature though. What we want to change is a sitewise configuration that doesn't require any new commits to MediaWiki. Aaron Liu (talk) 01:26, 20 January 2023 (UTC)
That's just because I do 90% of these, but since I'm in the opinions I'm not going to just close it as a not done in my direction unless it just goes stale. — xaosfluxTalk19:38, 28 January 2023 (UTC)
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Hi all, I'm requesting the following notice to go on the watchlist on 1 March (UTC) to whenever it will expire or be replaced. Please shorten or correct is needed.
Sign up here for the ongoing, month-long Guild of Copy Editors' March copy-editing drive. Have fun, improve articles and earn barnstars!
Aoidh's RfA is closed to further comments. If its watchlist notice is still up when an admin checks Bri's request, perhaps it may be prudent to remove the RfA notice? Just to reduce confusion. Rotideypoc41352 (talk·contribs) 22:14, 10 March 2023 (UTC)
The RFA watchlist notice is automatic, and is difficult to turn off manually. We'd have to shut down NovemBot Task 7, then edit User:Amalthea/RfX/RfA count to 0. Not sure it's worth it. If anyone has ideas for how to get NovemBot to easily detect when an RFA gets automatically placed on hold (this is currently hard because RFAs getting automatically placed on hold is done with template magic at the moment, resulting in no changes to wikicode), I'm all ears. –Novem Linguae (talk) 22:23, 10 March 2023 (UTC)
@Novem Linguae I think it would make sense to edit your bot to account for this case in the future? If necessary we could also temporarily remove the RfA template from this page. --Trialpears (talk) 02:21, 11 March 2023 (UTC)
Thanks for the ping. As mentioned above, editing the bot to account for this case is easier said than done. Would probably need to scrape HTML since the template does its work quietly (no changes to wikicode). I can look into this more the next time there is a crat chat. For now, I feel having the watchlist notice up for an extra hour is an acceptable tradeoff. Although I am certainly open to other opinions and suggestions. –Novem Linguae (talk) 02:43, 11 March 2023 (UTC)
That should't be necessary? Just look for {{hide until|20:29, 10 March 2023 (UTC)|text={{rfah|autohold=yes}}}}, take the date and add a week. If it's after that time the RfA shouldn't be included in the list. I don't know how you've implemented it so I may be missing something though. --Trialpears (talk) 02:56, 11 March 2023 (UTC)
Current implementation is a regex that counts transclusions on the page WP:RFA. Code is here and here. Your algorithm would probably require a loop with an API call in it, and date math. Pull requests welcome. –Novem Linguae (talk) 03:03, 11 March 2023 (UTC)
March Signpost notice
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
The March edition is very small and we are going to have another one out in a couple weeks; we do not really need a watchlist notice for this one (the script posts this request automatically). jp×g18:34, 20 March 2023 (UTC)
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
The Core Contest is running again this year and a watchlist notice would definitely help bring in participants. I'm think something like this (though suggestions/alterations are most welcome):
Editors are invited to sign up for The Core Contest, an initiative running from April 15 to May 31, which aims to improve vital and other core articles on Wikipedia, .
{{Display/watchlist
|until= April 5, 2023
|cookie=xxx
|text=Editors are invited to '''[[Wikipedia:The Core Contest/Entries|sign up]]''' for [[WP:The Core Contest|The Core Contest]], an initiative running from April 15 to May 31, which aims to improve [[Wikipedia:Vital articles|vital]] and other core articles.
}}
Request for newcomer mentors
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
{{Display/watchlist
|until= April 30, 2023
|cookie=xxx
|text=A portion of new users are automatically matched with [[Wikipedia:Growth Team features|mentors]] to help guide and support them; experienced editors are invited to '''[[Wikipedia:Growth Team features/Mentor list|sign up]]''' to be a mentor.
}}
We don't have a mechanism built out for that on the WLN, but I'll replace "expereienced" with extended-confirmed to call it out. — xaosfluxTalk13:35, 12 April 2023 (UTC)
@Xaosflux Does MediaWiki:Group-extendedconfirmed.css not work for the watchlist notice? Also I think the original wording is fine since the requirement of 90 days is more than that of extended confirmed, and extended confirmed is a bare minimum requirement rather than the goal which is experienced users. Galobtter (talk) 03:25, 13 April 2023 (UTC)
@Galobtter yes, that isn't built in to the gadget and template that runs it, yes you could hide the text line - but I think it will make a blank notice that will look worse and still need dismissing. — xaosfluxTalk08:59, 13 April 2023 (UTC)
People on mobile (at least those with mw:Reading/Web/Advanced mobile contributions turned on), could see watchlist messages but had no way of dismissing them. Now they should see the messages and have the dismiss button. Let me know if I broke anything anywhere, or if there's any display issues on mobile. Galobtter (talk) 22:48, 14 April 2023 (UTC)
GOCE April Blitz
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Something along the lines of this, The Guild of Copy Editors' April Blitz runs from April 16 to 22, come, join in and earn barnstars! Sign up [[Wikipedia:WikiProject Guild of Copy Editors/Blitzes/April 2023|here]]. Zippybonzo | Talk (he|him) 15:16, 8 April 2023 (UTC)
Request withdrawn The blitz is starting tomorrow and there is not enough time for people to read the message and join the blitz. Zippybonzo | Talk (he|him) 06:54, 15 April 2023 (UTC)
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
A watchlist message like this might be beneficial.
At 14:00 UTC on the 26th April all Wikimedia servers are going to read only mode, meaning your edits won’t be saved for approximately an hour. See here for more information. Zippybonzo | Talk (he|him) 08:03, 20 April 2023 (UTC)
Ditto. How about something more specific: "There is a request for comment proposing automatically revoking administrative privileges due to being blocked for more than 28 days" - jc3700:39, 18 April 2023 (UTC)
On hold@Extraordinary Writ, Galobtter, and Jc37: yes, this could merit a WLN. What we need: (a) ensure that the RfC is somewhat stable and is likely to run for a while; (b) probably something even blander, not assuming that any RFC title will be the final verbiage. From my quick read, there is:
This seems to have already started to fork to be not about that, but about changing the arbcom rules (such as in this section) - or possibly just to be some sort of advisory motion. (Back to the "is this rfc stable" question).
A WLN should be short, have one call to action (in this case "participate in this rfc") and be neutral. So the first thing I want to know is how stable is this RFC, and what is the limit to the scope of it before "shoo, go start a new rfc" is called. — xaosfluxTalk00:06, 23 April 2023 (UTC)
It's calmed down noticeably in the last few days, although I wouldn't complain if you wanted to wait a bit longer to make sure there are no new proposals. Something like "A request for comment about the process for revoking administrative privileges is open" would probably be broad enough to cover everything that's currently on the table, I think. Extraordinary Writ (talk) 22:53, 23 April 2023 (UTC)
To me, “RfC… is open for feedback” sounds like the RfC itself is in the works, e.g. still in the idea labs. I think it should be changed to “RfC… is open”. Aaron Liu (talk) 01:11, 25 April 2023 (UTC)
It's already "multiple proposals" too, If this was on another page it would be multiple sentences (with statements like ...interested editors are invited to comment at the discussion....), but we try to keep WLN very short to not monopolize the top of the screen. — xaosfluxTalk10:09, 25 April 2023 (UTC)
@Aaron Liu no I mean the original RFC was proposing one thing, but since it has morphed and is now includes multiple proposals. So the rfc doesn't contain only "A proposal". — xaosfluxTalk13:42, 25 April 2023 (UTC)
Call for New Members - Wikimedia Foundation Elections Committee
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
{{Display/watchlist
|until= April 25, 2023
|cookie=xxx
|text='''[[m:Wikimedia_Foundation_elections_committee/Nominations/2023|Applications are being accepted]]''' until 11:59 UTC, 25 April 2023 (UTC) in the [[m:Wikimedia_Foundation_Board_noticeboard/Wikimedia_Foundation_Elections_Committee_-_2023_Call_for_New_Members|call for New Members to join the Wikimedia Foundation Elections Committee]], the group that oversees the community-and-affiliate seat selection process for the Board of Trustees.
}}
Any interest in switching from passive voice to active voice, and reducing the number of links?
The Wikimedia Foundation Elections Committee, the group that oversees the community-and-affiliate seat selection process for the Board of Trustees, is '''[[m:Wikimedia_Foundation_elections_committee/Nominations/2023|accepting applications]]''' until 11:59 UTC, 25 April 2023 (UTC).
The Wikimedia Foundation Elections Committee, the group that oversees the community-and-affiliate seat selection process for the Board of Trustees, is accepting applications until 11:59 UTC, 25 April 2023 (UTC). –Novem Linguae (talk) 11:59, 23 April 2023 (UTC)
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Hi all, I'm requesting the following notice to go on the watchlist on 1 May (UTC) to whenever it will expire or be replaced. Please shorten or correct is needed.
These apparently come out twice a month now, and unless dismissed, stay up for a week (50% of the time). I use several devices. Is there any way for me to add something to my .js or .css file so I don't have to see and/or dismiss signpost spam 6 times a month, without losing the ability to see actually useful announcements? Floquenbeam (talk) 16:11, 8 May 2023 (UTC)
This could happen, but 3 pieces of work have to happen: (1) update the template, etc to include an additional class; (b) admins could add this new class as part of new notices; (c) message requesters would really need to request this class on their message requests because no one will remember it otherwise. — xaosfluxTalk18:02, 8 May 2023 (UTC)
As SP already has T:CENT and a huge mass message distribution, not sure if it really needs to be in WLN anymore though -- normally WLN is a short blurb asking editors to do something, in this case the call to action is mostly "read me". — xaosfluxTalk18:03, 8 May 2023 (UTC)
I'm not sure whether WLN is needed either. I also see that JPxG rescinded the (automatic) watchlist request back in March (diff). Maybe it should just go up for the first edition of each month only? But, I think the publication dates hae been tweaked or delayed for recent editions, so I don't think we could reliably note the publication date for the mid-month edition, as a couple people suggested in the WT:SIGNPOST thread. DanCherek (talk) 22:18, 8 May 2023 (UTC)
I also believe that the Signpost notices go up way too frequently. The call to action could or should be seen as "subscribe if you are interested". If so, I suggest that maybe two watchlist messages per year might be an appropriate schedule. Schwede6623:09, 8 May 2023 (UTC)
I very much like the general idea of, X times a year, a notice that (a) there's a new signpost, and (b) subscribe if interested in a talk page notice for each issue. My choice of X would be 2-4, but if others want it to be 6, I won't complain, and if they want it to be 12, I'd probably grit my teeth and accept the compromise. Floquenbeam (talk) 13:07, 9 May 2023 (UTC)
Yeah -- if I recall correctly, when this came up last time, everyone seemed to like the idea of once a month. It's just that the publishing script automatically adds this section to MWT:WLN... I need to fix a few other things with that, so I will try my best to get on it soon. The only reason I haven't fixed all yhis crap yet is because it is a relatively complicated piece of code, made by someone who isn't around much these days, written in that language that the evil guys speak in Lord of the Rings, the sun is in my eyes, my pants are too tight, I was having a heated gaming moment, etc, blah blah blah. jp×g01:08, 9 May 2023 (UTC)Specifically, once a month, for a week or a few days or however often; the idea being that it should only be there a decided minority od the time. Having a Signpost notice atop the watchlist 50% of the time is not only a pain in the ass for everyone else, but defeats the purpose of even having one in the first place. jp×g01:10, 9 May 2023 (UTC)
Well, I suggested once a month at the beginning. EpicPupper suggested once a month and alternating between the start of the month and mid-month, which would alternate the gap between messages between two weeks and six weeks. I don't think that's ideal. Other people suggested shorter periods of time, but in terms of annoyance, it still means twice as many notices to dismiss. As suggested by Schwede66, perhaps the focus could be subscription drives instead of notifications for individual issues, and they could happen less often than monthly. In that case, the posting notification request can just be removed from the publication script. I also think a new dedicated template, similar to how RfA notices use {{RfA watchlist notice}}, that used a watchlist-message-Signpost CSS class would be good to allow users to suppress all Signpost notifications if desired. isaacl (talk) 16:37, 9 May 2023 (UTC)
The supressing possibility would be good. I'd also agree that a 3 day notice for signpost releases should suffice. Nosebagbear (talk) 11:26, 17 May 2023 (UTC)
ARBPOL proposed amendment
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
The last proposed amendment was also a watchlist notice, so this is requested as well. It may not take that long, but since a max time is requested...5 days? A week? Nosebagbear (talk) 11:12, 17 May 2023 (UTC)
I'm requesting that the following notice go on the watchlist on 1 July (UTC), to last until it's appropriate for it to expire. Please shorten or correct is needed.
Sign up here for the ongoing, month-long, Guild of Copy Editors' July copy-editing drive. Have fun, improve articles and earn barnstars!
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Requesting a watchlist notice for the August 2023 GAN Backlog Drive, to run starting late July (29th/30th) until an appropriate time in August -- the drive runs until the 31st, so I'm thinking 23rd or so would be enough that anyone who wants to be involved certainly would be by then. Feel free to drop it somewhat earlier if something pressing comes up.
Sign up now for the August 2023 Good Article Nominations Backlog Drive. Review articles and earn barnstars!
(feel free to request any readability/flow changes to that, it's a quick draft)
Done We don't really add notices longer than >7 days unless they are of prime importance so it's set to expire on August 1st. qedk (t愛c)11:47, 25 July 2023 (UTC)
Hmm, maybe this should've been added on July 29th (as it seems from the request). Apologies for the early addition, any administrator is free to revert or modify as necessary. --qedk (t愛c)11:52, 25 July 2023 (UTC)
GOCE September drive
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Please add the following notice to the watchlist:
Sign up here for the month-long Guild of Copy Editors' September copy-editing drive. Have fun, improve articles and earn barnstars!
WikiProject Women in Green - October Good Article Editathon
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
I'd like to request that this notice be added to the watchlist -- one week would be perfect. If the message length needs adjusting, I'm happy to make edits.
Sign up here for WikiProject Women in Green's "Around the World in 31 Days" Good Article (GA) editathon, running through October 2023. Learn new GA skills, help improve articles about women and women's works, and earn a special barnstar!
I dismiss it every time, and it's been happening consistently for years. No, I don't see how it possibly could either. Which is why I wanted to know if I was the only one. —Cryptic16:08, 23 October 2023 (UTC)
@Cryptic check your gadgets here: Special:Preferences#mw-prefsection-gadgets, make sure you have "Display watchlist notices" and "base style for watchlist notices". Next, if you are still using cologneblue try checking your settings in User:Cryptic/cologneblue.css about the watchlist-messages class, you have some !important in there about the padding, which your browser could be getting confused about when it is already in display:none. — xaosfluxTalk17:46, 23 October 2023 (UTC)
I have no "base style for watchlist notices" gadget, but don't see anything of relevance in MediaWiki:Gadget-WatchlistBase.css anyway. "Display watchlist notices" is checked - I had forgotten it was a gadget, and thought it was in mediawiki core (or at worst an extension), and didn't have the energy to go searching for it there. mw.storage.get('hidewatchlistmessages') does give me just "[594]", and the twisty little maze of parserfunctions at {{RfA watchlist notice}}looks like it'll not emit the li element at all if there's no live rfa, which in turn would get the old cookie value expunged; but if so, it would be affecting everyone. Bleah. I don't see how removing the padding and margins could affect this either - or if it did, why it wouldn't keep the notices from being dismissable at all - but I'll try to remember to view with safemode=1 next rfa. —Cryptic19:31, 23 October 2023 (UTC)
So after the last rfa closed but before I viewed my watchlist, mw.storage.get('hidewatchlistmessages') gave me "[596,597,598]" - the cookie numbers for the RFA, AFC, and GOCE messages. After going to Special:Watchlist but before the AFC item expired, it was just "[597,598]", and after that expired and I viewed my watchlist again, it's now "[598]" - there's no li.watchlist-message items with class .cookie-ID_596 or .cookie-ID_597, so expungeOldNotices() removes them. (If there's no li.watchlist-message item at all, addDismissButton() returns early and so expungeOldNotices() never gets called.) When RFA's no longer empty and so {{RfA watchlist notice}} starts emitting a li again, before the cookie's updated, I'm pretty sure it's going to be visible immediately; and then if the cookie's bumped, it'll become visible again even for people who've dismissed the newly-resurrected li.watchlist-message.cookie-ID_596.So - unless there's something really screwy going on and the cookie's not getting removed for anybody else (perhaps the July 2021 fix discussed at MediaWiki talk:Gadget-watchlist-notice-core.js worked for me but it's still broken for almost everyone else? Seems dubious) - there's a couple potential solutions here:
Change when the cookie's bumped here: instead of "whenever a new RFA is listed" to "whenever the last RFA is delisted, and whenever a new RFA is listed when there's already one on the page". Which is clumsy to put into text, but works out to change incrementing the cookie from "#/rfas changes from 0→1, 1→2, 2→3, etc" to "#/rfas changes from 1→0, 1→2, 2→3, etc".
Have the RFA-counting bot emit a cookie value on its own. No idea if the non-gadget version of watchlist messages needs cookies to be digits-only (nothing stopping the gadget version from using arbitrary strings except the regex in addDismissButton()) or, if so, they need to be strictly increasing.
Stop trying (and failing) to be clever in Template:RfA watchlist notice. Increment the number of rfas in the watchlist message manually, the same time the cookie is incremented.
Comment out the {{RfA watchlist notice}} transclusion here after the last active RFA closes; uncomment it when bumping the cookie number.
As a bonus, either of solutions #2 and #3 will fix the scenario where the cookie is incremented between RFA's #1 and #2, someone views their watchlist with it saying "2 current RFAs" and dismisses, the cookie is increased for the second RFA, and the person sees "2 current RFAs" again. #3 and #4 also let the first new RFA have a delay before being watchlisted, like the edit notice says it will, instead of displaying immediately. (#2 will always display RFAs immediately; and #1 - like now - displays the first RFA immediately, and subsequent concurrent ones when someone bumps the cookie. Just not display the first RFA a second time if the previous RFA cookie was expunged.) —Cryptic20:04, 5 November 2023 (UTC)
So far you are the only person that has reported this issue. There is a purposeful delay from when we a new RFA exists to when we increment the cookie by design, to avoid bothering people for ones that will be SNOW closed. What skin are you using? If it is cologneblue, do you have this problem with other skins? There could be something odd there, it is a very rarely used skin. — xaosfluxTalk20:39, 5 November 2023 (UTC)
Most people won't know to ask here.I use Cologne Blue, yes, but I am 100% certain it's irrelevant. Identical html is emitted for ul#watchlist-message in monobook, and vector, and vector-22, and I didn't test them but I'm sure it does for MinervaNeue and Timeless too, because it's defined here (via {{Watchlist-messages}}) and not by MediaWiki. There's currently exactly one list item in it, .watchlist-message.cookie-ID_598, and MediaWiki:Gadget-watchlist-notice-core.js::addDismissButton() very plainly says to remove all non-current cookies from mw.storage if there's at least one li.watchlist-message. This is easily verified by plopping mw.storage.get('hidewatchlistmessages') || mw.storage.session.get('hidewatchlistmessages') into a console.If you've dismissed the current messages and get just "[598]" like me, what do you think that's going to immediately result in when User:Amalthea/RfX/RfA count changes and so {{RfA watchlist notice|format=watchlist|cookie=596}} starts emitting <li class="watchlist-message watchlist-message-RfX cookie-ID_596"}}>{{RfA watchlist notice/text}}</li> again? And if you're getting something else, how are you not seeing that as problematic after this edit you made explicitly so that those values get removed? —Cryptic22:04, 5 November 2023 (UTC)
If you're the only one encountering this error, Cryptic, it is far more likely that it's something on your end vs. something on Wikipedia's end. Most people would ask this question on WP:VPT; are you seeing any similar questions in its archive? (I'm not, but I've only tried a couple searches.) Ed[talk][OMT]22:28, 5 November 2023 (UTC)
Done. I moved the bolding and shortened it a bit. Hopefully this addresses your concerns, even though I did not add or remove any links. –Novem Linguae (talk) 12:14, 22 November 2023 (UTC)
