In T363159#9735404, @Aklapper wrote:

Hi, could you please provide URLs as requested before?

On enwiktionary, LQT was only ever enabled on a limited number of pages, mostly user talk pages. When pinged regarding the potential removal of LQT, these users did not comment (most of them are only sporadically active). I do not foresee any community concern if LQT were to be removed from enwiktionary.

@xcollazo thanks for sorting this out quickly! Much appreciated.

Noticed this too. Only wikidatawiki and enwiki have managed to generate a full dump.

In T356159#9533353, @Ladsgroup wrote:

I don't think page notices are time sensitive (similar to templates).

In T61245#9527504, @UOzurumba wrote:

When should it be included?

@Ladsgroup thanks for taking a look.

In T61245#9498555, @Jdforrester-WMF wrote:

I don't think it's appropriate to rush this into production for everyone without a quick discussion in an appropriate place e.g. on Meta, but it's not a huge issue if there's clear documentation on what it is and how it can be used.

The plan is to enable the extension first on testwiki (done), then on enwiktionary, then on all other wikis.

I hope it is okay to directly assign this task to you, @Ladsgroup .

In T61245#9369815, @TTO wrote:

enable PageNotice on all production WMF wikis (with $wgPageNoticeDisablePerPageNotices = true).

Good point, I hadn't used the IP to edit, so that explains the behaviour.

My interpretation of this task, given its placement in MediaWiki-Core-Snapshots, is that a way to export images using the existing Special:Import/Export infrastructure is wanted. Currently you can only export/import the file description page, not the file itself. See also the duplicate T143591: Special:Import does not import the actual file.

This task is requesting a generic way to import images from one MediaWiki wiki to another using Special:Import.

The testing on beta has proceeded without any issues. Now it's time to enable the extension on the production cluster.

Tests have been written in the intervening 9 years.

On English Wiktionary, one of our gadgets suddenly broke. This brokenness was first reported at 18:52 UTC and I was able to resolve it by removing a reference to $.isReady from the gadget. See discussion.

Line numbers are now provided at the top of each hunk thanks to T346460, so I'm narrowing this task to a feature request for code pages specifically.

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?