OK, I see. So, it's not a bug, it's by design. A pity. Could you please add a fake class to the message span, so it can be removed in personal style files? Thank you.

Yes. Until now there was only the icon. Now there are both the icon and the text. It's very confusing, because in the menu with no separators it looks like two buttons.

Do you mean by this that T428855 is not a bug, it's by design? But why?

Sure it's a subtask? I'm talking about a future dynamic atomatic adding there, not just search results.

In T426606#11958911, @Samwalton9-WMF wrote:

@IKhitron Can you clarify how this differs from the existing namespace filter available on Special:Watchlist? I'm not sure I understand, so any clarity you can provide would be helpful!

In T427330#11957548, @Izno wrote:

On WP:AN, not since I last readded the label I don't believe, no.

I see.

It was not my impression that tools needed to reassert the label each time they modify a page, anyway.

No, it is not what I had in mind. I thought that maybe it's T423778: Edits through API reset watchlist labels.

@Izno, when editing these pages, did you use any tools that use Action API editing? Hot-cat, Cat-a-lot, Discussion tools, Convenient discussions, and so on. And if you did, could these specific edits be the ones that remove the labels, according to time when they were made?

Thanks a lot.

I'm not sure. The case

rect 4112 456 5244 1248 [[Help:Wiki_Replicas]]

doesn't work either for me, the title attribute is not created for the area tag. Is this the same problem? Thank you.

Yes, it's exactly what I did. You can see the Feature tag on the top. Of course, I didn't leave the bold font headers, but the rest done as is.

I wouldn't do it this way, because it can be accidentally, but I understand why do you want it. Maybe better decision will be restart the timer instead of continuing, so the user would have enough time to pay attention and return inside the popover?

In T426040#11912514, @TheresNoTime wrote:

Have updated the description to reflect the timeout of 5 seconds

Thanks. As I already said, it's not enough IMHO. So could you instead add to the description that

• Clicking on any place inside the popover kills the timeout

please? This way if the user needs it, they can "freeze" the popover on the screen and think about the expiration time and the right labels, without being afraid it disappears every moment. Thank you.

Please clarify in the description:

• The "clicking anywhere off of the popover closes it" means that's it or, for example, clicking on a blank target link outside the popover will close it and also open the link in a new tab.
• How long are the timeouts.

Thank you.

Well, it reveals now that stewards can edit closed wiki forever, as for T421796#11898319 and T421796#11898350. Closing this task as Invalid.

Thank you. It changes the situation. I'm closing T421724: Discontinue Wikinews support on Global Watchlist as Invalid.

Firefox does not load at least 4 minutes for me any picture, just waiting icon.

Thanks for the explanation. In this case, can you recommend a browser, or OS, or something, where we can see it exactly as intended? I don't think this bug is a part of the plan.

It doesn't work for me in most browsers, and in those two it works, I get

Is there a date if and when the stewards will not be able to edit either?

What does

user talk pages of user talk pages

mean?

In T417359#11886315, @Samwilson wrote:

Yes, the plan is that at some point it'll be unconditionally available on all wikis. We talked about leaving the feature flag in place, but the feeling is that MediaWiki already has so many config options and that each one adds a cost that isn't worth it in this case (similarly for watchlist expiry).

@Samwilson, could you tell me, please, does this mean that at some point it will be impossible to have a wiki without labels, in Wikimedia or out, in production or on some testing wiki, except for those that do not use versions 1.47 and later? And if the answer is yes, when it will happen? I'm asking because I need to decide if to spend a lot of coding time to adjust my code in a MediaWiki extension to the case when there are no labels installed on a wiki, or I can skip that part. Thank you.

I see. Looks like there will not be any problems with T421724: Discontinue Wikinews support on Global Watchlist.

Wait. Why is this done? There are a lot of wikis on SiteMatrix, marked as closed.

Great, thanks.

Can you add it to the Patch Demo above, please?

I tried. It looks nice on content pages, but maybe there is some clash with the Discussion Tools or something.

After this discussion, new facts about technical details and T424422: Urgently increase Global Watchlist Live Updates mode timeout I propose a new plan:

1. Wait until May 4 (or a little later, when the Wikinews will be closed).
2. Run SiteMatrix API call for closed wikis, extract a string flatten array of these wikis and save it in a JSON file in Gerrit.
3. Starting from 30 day later, about June 3, ignore every wiki in the list on js side.
4. From the same day disallow the wikis in the list in the sites settings validator on php side.

I believe the dialog should appear immediately, but I can see it disturbs to some people. You should do something, I think, otherwise you will lose a lot of potential label users (exactly as it was with Reading lists in the last few days because of watchstar removal). So, this is my suggestion:

1. Clicking on watch or on unwatch works immediately as before.
2. But either of them, not just watch as before, creates a bubble notification for some time, as before. But instead of expiry dropdown it has only one button now, "Organize watching". If clicked, it opens the dialog window with expiration dropdown and labels.
3. There is a need to add a blue button "Confirm and close" to the Dialog window.

In T417847#11878849, @stjn wrote:

Discord (and maybe some other apps) offers to skip the confirmations with Shift-click. I think that's sensible as a way for experienced editors to adjust to it, as long as it's shortly mentioned in the popup.

Great idea. Shift-(or Ctrl, your choice)-click for simple permanent watch without labels and simple unwatch will be wonderful.

In T417847#11878789, @Ponor wrote:

how many people really use the labels?
and if anyone uses the labels.

As far as I can check it's not much for now, it's very new. But I expect this change from "some people" to "most of the people" if and when I'll finish the project I'm working on for the last few months and will continue to work, probably more months. It's very complicated, but it's worth it to give a new service to the users.

I really think that now, with Dialog, you should change the behavior in one point: when clicking on Unwatch, the dialog should disappear, instead of invitation to watch again. This will help many people, especially those that oppose the new layout because of three-clicks unwatching, instead on one earlier.

In T417847#11877950, @Samwilson wrote:

more likely to appear in the tools menu, if Reading Lists is enabled
If you're already talking about this, IMHO removing the watchstar instead of adding one more icon should not happen.

I prefer the unwatch dialog on unwatch click too. I always wanted not to have a redundant click for the expiry change. About the new Vector bug, please make sure after you solve it to check on RTL page too.

I see. Great, thank you. Good thing you told me, I've opened 10 main pages on random Wikinews wikis to create an account, so I could properly test my code after the closing.

Thank you.
But the querry 104505 that returned 450 answers yesterday, gives only 3 now. I'll try understand what happens and which results versikn is the right one.

Please see T423998: The imagelinks replica in hewiki is not available.

In T421796#11830353, @Pppery wrote:

RecentChanges/Watchlist don't interact with wiki closures at all. Hence, 30 days after the wiki is closed they won't display any content (other than the occasional global rename or edit by a steward)

About discussiontoolsedit, I saw that it worked many times on Patch Demo, so, looks like it is somehow non-determinstic.

See also T421796: Close 31 editions of Wikinews on 2026-05-04 (make them read-only), at T421796#11830353.

Are the technical details already known? I'm interested specifically in a question what exactly will happen when sending Action API query calls on updated data, like Recent Changes of Watchlist.

In T423027#11812709, @tstarling wrote:

In T423027#11812690, @IKhitron wrote:

Does this mean I can try to recheck once again now?

Yes.

Does this mean I can try to recheck once again now?

Thank you.

In T423055#11812591, @Aklapper wrote:

You could check/search on https://phabricator.wikimedia.org/mail/.
(I have not experienced a problem with my Phabricator mail notifications in the last hours.)
Setting status to stalled per last comment.

I just changed my Phabricator mail address to another one, to see if the problem will be there too or it is not for all.

Sure, both possibilities are good for me.

Thank you. Sure, I will stop, if you think it's better. But as it looks for me, it's not that the recheck reply does not invoke the Jenkins bot, it's the Gerrit UI does not allow to write it at the first place, even as a simple text that anybody can read. Of course, I do not know how it is build from inside.
UPD: Many comments appeared now, at least three times more than I sent. Part of them have the word "recheck", others are empty somehow.

Looks like it's more than that. I tried to send recheck many times, but there is no way to write a replay.

Much better, thank you. It has logical problems now, but at least it works, partially. (For example, a click on "save" saves the new version, but shows an error message "was not saved, same as original".) If you need details, please ping me, for some reason Phabricator subscription mailing does not work today, maybe a ping will. Thanks.

Of course. But I prefer not to be selfish.

So for some namespaces, otherwise noone can reach it without remembering the page name.

Sounds great, but can you please add a link to this special page to MediaWiki:Noarticletext? Otherwise, it's pretty unreachable. Something like "You can create this page or create it with a different content model".

@Lucas_Werkmeister_WMDE, just to tell you that I did not forgot your comments. After T417319 will be done, I'm going to start with them. Sorry it takes so much time, but working on multiple changes with the same leading file is worse, IMHO.

In T421724#11775460, @matmarex wrote:

In T421724#11775406, @IKhitron wrote:

In T421724#11775392, @matmarex wrote:

I'm not sure if this really requires any changes to GlobalWatchlist.

Why do you think so?

It works with other closed projects, right? I don't know how the Wikinews closure is going to be handled, but I am guessing that they will work the same way. It doesn't seem like the best use of our time, if the end effect is likely going to be the same as if we did nothing.

I see. But I can't imagine any case when I send an API call to a closed project and it fails before beeing sent. The technical details are expected soon. I didn't suggest such a thing for the closed projects earlier, because usually jt means they are not so popular. Not like in Wikinews, 31 projects on all kinds of languages.
UPD: And the issue of API call saving wasn't ever such relevant as now.

I have no problem for checking it once, manually, and adding to the list of the closed projects, but make it permanent seems too much for me. Don't know which one you meant.

I meant that ideally, GlobalWatchlist would be able to check the list of closed wikis (automatically updated) and skip checking projects if they exist in that list. I wouldn't want to have to manually update a copy of that list somewhere.

I see. It can be done for wikifarms that have CentralAuth and SiteMatrix both deployed, sure thing.

In T421724#11775392, @matmarex wrote:

I'm not sure if this really requires any changes to GlobalWatchlist.

Why do you think so?

I can add other closed projects to the watchlist, e.g. https://aa.wikipedia.org/, and it doesn't seem to have any bad effects. Closed projects can also still be edited by stewards on the rare occasions that it is necessary.

If you really want to avoid redundant API calls, I would suggest skipping all closed projects when fetching the local watchlists, rather than doing anything specific to Wikinews (you can see them struck-through at https://meta.wikimedia.org/wiki/Special:SiteMatrix, or in the API at https://meta.wikimedia.org/wiki/Special:ApiSandbox#action=sitematrix&smstate=closed&smlangprop=site, or at https://noc.wikimedia.org/conf/highlight.php?file=dblists/closed.dblist).

The patch is ready. I will open it to review very soon, after the extension bottleneck will be released, there is one very important change waiting for review a month and a half.
Here is the result, most of the first half shows pages without labels defined, the rest is with labels: