Jon (WMF)

Hi, I wish you happy holidays and a happy new year, may it be full of beautiful wiki things!

You too! Hope you had a good one!

Is there a task or anything to identify MediaWiki messages which should be emitted inside (or with the class) mw-parser-output? And/or what facility is for that on the parser side? I vaguely recall a task lying around for such.

Anyway, the reason I'm asking: I've recently moved module:message box to TemplateStyles and turned off MediaWiki:Gadget-enwp-boxes.css and several messages became unstyled (e.g. MediaWiki:Editinginterface) when viewed where they are output (e.g. when you click the edit button with 2003/2010 editors). I would prefer not to repeat lots of <div class="mw-parser-output"> and I'm sure it would be appreciated for i18n. (I guess the module can output that div if I need it in the meantime.)

Feel free to summon others who might help if you don't know the answers.

I found T183603 and T281540.

I'm sorry I do not understand the issue here. When you moved module:message box to template styles what specific styles did you lose? Is it possible to get a minimum test case and an expected result that differs from the actual result?

If it relates to external links, then yes the above task would be the relevant one but as I noted in phab:T281540#7218824 I possibly don't understand the problem well enough to guide on this one.

I... actually don't know what's going on now with the specific pages above. I'm going to let the job queue and/or cache work for a couple more days to see if that's what's going on...

In the general, the takeaway should be that 1) messages that get run through the parser should get a div/span with class mw-parser-output, and 2) I thought there was a task that was about tracking such messages down.

I think User:SSastry_(WMF) would be the best person to talk to about that. I don't really know much about how the parser and how it works with templates but yes that should be how it works. Anything coming from the parser should be inside a mw-parser-output element.

From https://github.com/wikimedia/mediawiki/blob/master/includes/parser/Parser.php#L697-L702 it points to https://phabricator.wikimedia.org/T37247

Mass-subscribing hundreds of people on Phabricator is very disruptive, and not an acceptable way to notify people. Please stop doing it. (Links: phab:T252467, phab:T254287.)

Also, if you could unsubscribe all the people you added to T254287, that would save everyone a lot of trouble.

I don't see what the problem with mass-subscribing people is. If you don't want to be subscribed to the task, then you can of course unsubscribe from it.

Pppery, many (most?) people who were subscribed only ever created an account on Phabricator to post a single bug or comment years ago. Subscribing them means that every comment and change results in them receiving an email about it, pointing to a confusing page on a mostly-unfamiliar platform, often about an issue they know nothing about.

Hey there

I'm guessing this message came in while I was in the process of sending out the message, as I have mass unsubscribed everyone from that task based on feedback from yourself on https://phabricator.wikimedia.org/T252467#6134791. I had to do this via a script which took a little longer than anticipated as Phabricator doesn't have the facility to unsubscribe all.

> Subscribing them means that every comment and change results in them receiving an email about it, pointing to a confusing page on a mostly-unfamiliar platform, often about an issue they know nothing about.

This is only true if they don't unsubscribe or are not mass unsubscribed by the task creator. In this particular tech notice I have unsubscribed everyone after adding them. My understanding is all the people I subscribed should get one email relating to the notice itself.

It would help me to understand where you are coming from. This technical work is important to fix and we don't have a good process yet for communicating with editors to make these changes.

My current approach is

1) identify potential editors

2) Ping them on phab ticket

3) unsubscribe all and ensure they are not in the description so they don't get further notifications.

I did try an alternative approach on wiki but Echo only works if users have been present on that wiki so it was not a very useful mechanism for targeting users across several wikis. For me posting to every user talk page on the target wiki doesn't scale as there is no bot I know of that does that.

I am open to ideas for improvement if you have a better approach, but I don't see one right now other than break things and expect editors to fix retroactively which seems like a far worse situation than a minor annoyance of being pinged on a phabricator ticket.

Am open to any ideas you have.

I would recommend using m:MassMessage. For the Main Page issue, the message could have been sent to the talk pages of all affected main pages (main pages are usually heavily watched), and for the CSS selector update, the message could have been sent to either the talk pages of the affected stylesheets/gadgets (typically watched by those involved in maintaining them), or to the authors' talk pages.