In T159062#10778791, @Aeyeu wrote:

Redirects that aren't clicked on in the wiki or clicked on from an old link off-site, basically it has no web traffic

I still haven't seen a clear response to the two points I made in my 2017 comment:

@Wargo's regression fix has been deployed.

In T381058#10576528, @Jdlrobson-WMF wrote:

Thanks to the community for all the efforts here. This looks really to be deployed whenever you are ready.

In T17000#2912219, @Joe wrote:

In T17000#2912186, @Aklapper wrote:

The pleasure of having tasks mixing up the general MediaWiki code base and the specific configuration of Wikimedia sites. :(
Should we split of the Wikimedia site request into a separate task? Feels way cleaner.

Well the two things were quite entangled, but I think it would be fair to separate the tasks.

I would just close this to be honest. The issue is 12+ years old, the reporter doesn't even have a Phabricator account, etc.

In T369466#10593282, @Lakejason0 wrote:

Thus, we would need to split the clauses (granted, revoked, etc.) using semicolonList.

In T384060#10591679, @ssastry wrote:

In T384060#10585483, @TTO wrote:

(As an aside, it's difficult to debug this, because TemplateSandbox does not use Parsoid even when the relevant user preference is set.)

Does it help if you used the "?useparsoid=1" in the query param?

The code in question has since moved to Module:links#L-438--L-451.

In T381058#10450109, @Jdlrobson wrote:

I evaluated the top 500 articles on Wiktionary and from what I can see, dark mode has more accessibility issues than light mode.
Please address the issues flagged here and we can reassess:

• https://night-mode-checker.wmcloud.org/enwiktionary/light.html
• https://night-mode-checker.wmcloud.org/enwiktionary/night.html

@Pppery added a project: TestMe.

It seems to have sorted itself out in the end - the 2024-12-01 labswiki dump is now fully complete.

It looks like it sorted itself out in the end.

Thanks again, @BTullis!

Thanks for looking into this, @BTullis!

Checking the dumps progress page, the timestamp of labswiki's progress has been updated to

2024-11-27 21:40:51

but everything else is exactly as it was on 25 November.

I don't mean to interrupt, but I think, given that LQT remains in active use on a couple of wikis - indeed, it is still enabled by default on all talk pages on ptwikibooks - some further community engagement work is required before switching it off. (I would still prefer to see LQT pages frozen in wikitext, which would ultimately allow the extension to be undeployed altogether rather than just set to read-only mode. But I can understand that the resources to do this may not be there at present.)

In T45646#10028555, @cscott wrote:

• We could also make a site-wide configuration variable for "copyright is raw html", and default it to false, and set it to true only for german wikipedia.

On English Wiktionary we have worked around this by adding min-width: fit-content to headings. This seems like a sufficiently non-hacky solution that it could be added to the official Minerva skin CSS.

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