In T346460#9183129, @Pols12 wrote:

In y opinion, the best design to solve this issue is to add line numbers which quickly help to find the line m4in the editor.

@KSiebert @MusikAnimal I'd still really appreciate a look from CommTech - it really should not take an experienced MediaWiki developer more than a couple of hours, and will help tick off another Community Wishlist item.

In T24509#3704230, @Krinkle wrote:

Implementation proposal:

[...]

3. Ensure external modifications of to change tags (e.g. via ChangeTags::addTags) get published to the RCFeed.

The PageNotice extension is now installed at enwiktionary beta. I was unable to identify any issues regarding the site notice, which is also enabled there. See for instance https://en.wiktionary.beta.wmflabs.org/wiki/Reconstruction:foo.

For completeness I will repeat the comment by @Urbanecm on the Gerrit patch:

I went ahead and updated the wiki page to list PageNotice as stewarded by active volunteer (this is the same what we did for recently(ish) deployed RealMe or GlobalWatchlist and what is done for several other components, like AbuseFilter or ProofreadPage. I believe "Active volunteer" matches the current reality, and mw:Developers/Maintainers should, first and foremost, respect and document the reality.

You need to understand the extreme simplicity of the PageNotice extension; its single PHP file is only 100 lines long. The risk level associated to not having a WMF team assigned to this extension is negligible.

Thanks very much for that detailed explanation. It is most unfortunate that this gap exists, and speaks perhaps of a disconnect between WMF teams and volunteer developers, and a need for WMF staff members who specialise in liaising between the two groups.

In T61245#9150469, @hashar wrote:

There is no point in randomly pinging people that previously did a Code-Review: +1 on another change.

Just noting here that the patch for beta is still awaiting a +1 so it can be deployed - the deployers are apparently insisting on a +1 prior to deployment now: https://gerrit.wikimedia.org/r/668156

The experience of getting things done as a volunteer (in my case, getting a new extension deployed) is already incredibly difficult if you "don't know the right people", so I'd not support anything that would add hurdles to that experience.

I put a local workaround in place on enwiktionary for the time being. You can still reproduce the bug on the mobile domains of other language Wiktionaries.

My time is limited, but this extension is simple and I would be happy to continue as maintainer. I added myself at Developers/Maintainers.

Patch was merged, @DannyS712 any further action required on this task?

This is apparently because of https://github.com/reedy/AutoWikiBrowser/blob/b1d41ae2bef0390adfd6224888a37faa07ddfa25/AWB/Main.cs#L3454:

The patch needs a look from someone who knows about MediaWiki DB performance, as this query joins some very large tables.

I'm wondering if Community-Tech might have a moment to look at this, in view of

IIRC raw bits of the XML upload or foreign wiki export will often get spewed out in the error message - in particular, XML tags.

In T309574#8012386, @Izno wrote:

"It should be the same" is not a bug. Do you have proof to indicate this behavior has changed from some earlier date?

In T309574#8008914, @Izno wrote:

This is supposed to have five lines, where the second and fourth lines are blank:

I see this as expected behavior. Do you have proof that these used to be rendered?

Not going to happen. An additional database query on page load isn't acceptable for such a slim benefit.

This was wish #23 in this year's Community Wishlist Survey. In Community-Tech 's prioritised list of wishes, it came in at #2.

WingerBot on enwiktionary is affected: https://en.wiktionary.org/wiki/Special:Contributions/WingerBot

Good idea! I'll do that. Thanks.

Just in case anyone is wondering, I have a completed patch for this, but I had serious issues running the EditPage tests locally, which meant I wasn't able to write any tests. I idled in some of the above mentioned IRC channels for a few days but spotted precisely 0 active humans in any of them, which didn't really make me feel very welcome. One day I might be able to return to it.

Thank you very much to the Search team for your efforts to make this happen!

@Quiddity I'm so sorry, I only just saw this - the change isn't deployed yet, so the message should have read "You will soon be able ...". Would it be possible to pull the message from this week's Tech News? By next edition, the code should be deployed so it will be able to be reused as is in the next edition.

In T215716#7757991, @MPhamWMF wrote:

this patch is ready to move ahead with code review and merging.

In T265716#7729403, @MusikAnimal wrote:

The first approach is always a safe assumption, I think, but this is not necessarily true for the second approach. It might be an edge case, but if someone explicitly set a watchlist expiry on a page, it may be reasonable to assume they intended to unwatch it at that exact time. For example, say it's Today's Featured Article, which they only watch for 24 hours. They have the "Add pages where I have performed a rollback to my watchlist" preference set to watch for 24 hours. If they revert an edit at the 23rd hour, they probably don't care to watch for another 24 hours on that particular page. So all in all, in my opinion is approach #1 of only applying an expiry if one doesn't already exist seems the most logical.

In T215716#7726070, @Gehel wrote:

• Since we have multiple search interfaces (SpecialSearch, AdvancedSearch, MediaSearch), it is a bit confusing on which of those interfaces are impacted by this setting

I proposed this in the Community-Wishlist-Survey-2022 and it only got 25 votes (#135 in the ranking), but I'm working on it myself nonetheless.

In T215716#7724472, @Ladsgroup wrote:

Is there a way to move this to another tab? Having one tab with only one option is weird plus having many tabs is bad UX.

In T215716#7716703, @tstarling wrote:

it seems like the simplest thing, less than one day of work.

On mw.org at least, only wikipedia: is affected.

The mystery here is why only the wikipedia: interwiki appears to be affected. If this is indeed the case, it's not actually a blocker to deploying to group2 (Wikipedia sites don't use the wikipedia: interwiki). But it's a bad regression on the group0/group1 sites currently impacted, including big ones like Commons, Meta and Wikidata.

Repurposing this task slightly in light of my comment at T66184: Allow searching also by new/target name on moving log page.

This task looks set to come in 10th in the Community-Wishlist-Survey-2022 ; it didn't look particularly difficult to code up, so I thought I'd have a crack.

In T170737#6760087, @matmarex wrote:

Probably… but there's now also T224321: Run populateCategory.php and I'm not sure what's the difference.

Isn't the problem of generating abstracts already solved by the Page-Previews extension?

@Reedy or anyone else - any chance of a look at that patch?

It seems that content.parser-output.less is no longer being included in the minified CSS. @Jdlrobson @Ammarpad @matmarex

We have noticed a rendering change on English Wiktionary after this deployment. The first report was 22:44 UTC yesterday, a few hours after the deployment.

In T108792#6802631, @TTO wrote:

On enwiki on the beta cluster, the "Import as subpages" option is selected by default for both XML and transwiki import. It should default to "Import to default locations" in the first instance, then when the form is reloaded, the option the user previously selected should be chosen.

On enwiki on the beta cluster, the "Import as subpages" option is selected by default for both XML and transwiki import. It should default to "Import to default locations" in the first instance, then when the form is reloaded, the option the user previously selected should be chosen.

@Reedy I see agreement at the Beer Parlour; what are the next steps?

I posted at https://en.wiktionary.org/wiki/Wiktionary:Beer_parlour/2021/January#PageNotice_extension_again to start a discussion/vote.

This task is assigned to me, but I am so far out of the loop at this point that I don't think I can make any useful contributions to it any longer. (Yes, despite appearances, <poem> is surprisingly subtle and requires the attention of someone with a decent, up-to-date understanding of MediaWiki parsing infrastructure.)

Based on:

Not sure why this task was assigned to me; I don't have, and have never had, shell access.

I guess I created this task for my own reference, but never got around to doing it. The issue still exists. The function doesn't get a lot of use though.

Thanks for the explanation!

Thanks. To be 100% clear, does that mean that this extension has successfully passed its security review?

Re number 6, there are already many avenues to deface the wiki if you have edit access to the MediaWiki: namespace. Editing MediaWiki:Sitenotice would have a similar effect as creating a page notice. I don't think the fact that this extension adds another avenue is of any special concern.

In T61245#5389385, @Reedy wrote:

Extension wants converting to extension registration before we'd deploy it (should be trivial)

I am still happy to act as maintainer of this extension; I rewrote it a few years ago, and it is awfully simple (barely 100 lines of code). Plus I am irregularly active on English Wiktionary :)