In T351937#11583743, @Aklapper wrote:

@AlexisJazz Removing task assignee as this open task has been assigned for more than two years - See the email sent to task assignee on 2025-11-25.
Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome! :)
If this task has been resolved in the meantime, or should not be worked on by anybody ("declined"), please update its task status via "Add Action… 🡒 Change Status".
Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator. Thanks!

In T310262#11572561, @matej_suchanek wrote:

Yes, this is already in prod.

Chose my robot's random revision, thanked for it using the very same code and refreshed history, contributions page, and diff view. All report "thanked". So there might be some circumstances where it still doesn't work, but they are not obvious.

I just thanked https://en.wikipedia.org/w/index.php?title=Talk:Killing_of_Alex_Pretti&oldid=1336001862 through the API but I'm still seeing "( undo | thank)" on the history page.

In T89692#11551942, @Tgr wrote:

Flipping that around would be very simple, although we'd still show an incorrect license.

Sounds sensible to me. If multiple licenses are detected, a note like "Other licenses may be available, click for details" could be displayed.

In T415495#11555094, @Pppery wrote:

TLDR I'm seeing a lot more noise than signal in that copilot example.

In T415495#11554429, @Aklapper wrote:

You'll need thousands of additional hashtags. Even if you do, there's a disconnect between how problems manifest and the components that are affected.

And so far I believe that a bot won't solve that disconnect (yet). My opinion may likely change over the next years.

I'm not saying that some trained bot (what some folks call "AI") would not be useful in the long run.
I am trying to express that so far the bot results which I have seen have not convinced me that the gain outweighs all the mistakes.

In T415495#11553341, @Aklapper wrote:

"Errors in tagging are probably not a huge issue"? Oh, they are, based on what I've seen so far.

I think an AI could outperform most non-regulars. Those who only come here when something breaks. You'll be lucky if they use tags at all. The benchmark isn't the experts here. Of course the experts will do better.

There was a visible dip in editing and surge in error responses.

Works now, thanks!

In T398742#11148630, @Awesome_Aasim wrote:

backwards compatibility isn't going to happen.

That's a shame.

It's not my call of course, but I severely doubt resources would be allocated for that. It's likely not trivial.

In T403653#11148121, @cscott wrote:

If the Parsoid behavior is correct, I'm inclined to resolve this as 'Declined' since the legacy parser is already being deprecated. Parsoid is expected to be the default within a year.

I agree with Jdforrester. Perhaps it's possible to create a tool that could assist user script creators with the conversion of existing scripts in some way, but backwards compatibility isn't going to happen.

Can't seem to reproduce anymore.

Looks like it's an issue with my provider. Using a VPN (without changing country) fixes it.

Seeing this on both beta cluster and production.

I added a default gadget on betacommons, https://commons.wikimedia.beta.wmcloud.org/wiki/MediaWiki:Gadget-LoadFull.js that adds links to the sidebar to load full-size versions of images just once, and to enable this by default.

@Tgr how about changing

You do not have permission to edit this JavaScript page because it may affect all visitors.

to something like

Only interface administrators can edit pages that may affect all visitors. If you are an interface administrator, you may need to enable two-factor authentication.

Saying "may" as non-WMF wikis may not require 2FA.

Encoding speed may be a factor for video, but for now we just need to work out the workflow in the MediaWiki internals.

For reference, recent IGPs can transcode video with negligible power consumption very quickly. Closed source drivers not required. For example:

ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -hwaccel_device /dev/dri/renderD128 -i testinput.mkv -c:v hevc_vaapi -vf scale_vaapi=1920:1080 -b:v 2M -b:a 256k -c:a libvorbis testoutput.mp4

This converts 3840x2160 30fps HEVC video to 1920x1080 30fps HEVC at almost twice the playback speed on my four-year old puny AMD Lucienne chip using the hardware for both decoding and encoding. With 4K HEVC output the speed is halved. (so roughly realtime) This chip is too old to support AV1. As newer chips are designed to handle 8K, they should be very fast with 4K material.

In T211745#10750987, @Aklapper wrote:

but here I read

@vitaly-zdanevich: See the task title which mentions HEIC. Also, "bad" is nonsense. See our required Grade C support, in addition to caniuse.com.

If I specifically ping ESAMS through my VPN, again packet loss:

# ping text-lb.esams.wikimedia.org -c10
PING text-lb.esams.wikimedia.org (185.15.59.224) 56(84) bytes of data.
64 bytes from text-lb.esams.wikimedia.org (185.15.59.224): icmp_seq=1 ttl=54 time=328 ms
64 bytes from text-lb.esams.wikimedia.org (185.15.59.224): icmp_seq=2 ttl=54 time=335 ms
64 bytes from text-lb.esams.wikimedia.org (185.15.59.224): icmp_seq=4 ttl=54 time=231 ms
64 bytes from text-lb.esams.wikimedia.org (185.15.59.224): icmp_seq=5 ttl=54 time=199 ms
64 bytes from text-lb.esams.wikimedia.org (185.15.59.224): icmp_seq=6 ttl=54 time=267 ms
64 bytes from text-lb.esams.wikimedia.org (185.15.59.224): icmp_seq=7 ttl=54 time=216 ms
64 bytes from text-lb.esams.wikimedia.org (185.15.59.224): icmp_seq=8 ttl=54 time=260 ms
64 bytes from text-lb.esams.wikimedia.org (185.15.59.224): icmp_seq=10 ttl=54 time=252 ms

In T124748#10589538, @matmarex wrote:

In T124748#10588324, @Pppery wrote:

https://www.mediawiki.org/w/index.php?title=Data:Data_demo.tab&action=history (@AlexisJazz)

Looks like it was a test for Scribunto data access: https://www.mediawiki.org/wiki/User:Alexis_Jazz/Sandbox – which didn't work (because, in our current configuration, it can only access data from Commons).

Correct, just a test, that page isn't important. Also see T252711 which I guess can also be closed soon.

There are currently 6 bitmap images (45,495,498 bytes / 43.39 MB) with the image/vnd.djvu MIME type. How do you find these?

In T362379#9890395, @SCherukuwada wrote:

@Robertsky We heard back from the property owner who showed us graphs of traffic and traffic levels and said that this was clearly more than what they considered acceptable. Their concern was purely about volume and not about suspicious looking user agent strings.

@Mvolz Maybe some requests previously timed out (not necessarily at the HTTP level) because the CPU was too busy, and those requests now get handled? If that's possible.

I'm kind of curious what happens when one requests https://en.wikipedia.org/api/rest_v1/data/citation/mediawiki/https%3A%2F%2Fen.wikipedia.org%2Fapi%2Frest_v1%2Fdata%2Fcitation%2Fmediawiki%2Fhttps%3A%2F%2Fen.wikipedia.org%2Fapi%2Frest_v1%2Fdata%2Fcitation%2Fmediawiki%2Fhttps%3A%2F%2Fen.wikipedia.org%2Fwiki%2FMain_Page%3Faction%3Dquery%26format%3Djson%3Faction%3Dquery%26format%3Djson?action=query&format=json

@Pppery that task is about auto-patrolling the reverted revision(s), this task is about the reversion itself.

In T362379#9784840, @ppelberg wrote:

In T362379#9782177, @ppelberg wrote:

In T323169#9782173, @ppelberg wrote:

Note: the Editing Team is thinking through a couple of ways we could incrementally improve the current experience.

You can expect to see another comment from @Esanders, @Mvolz , or me before this week is over outlining those approaches.

While the Editing Team has not yet converged on a set of potential solutions that could enable people to reliably use Citoid to generate references for major news websites, the Editing Team has identified two short-term interventions that could improve the current experience...

Intervention	Ticket	Reference(s)
Revise the current error message to explicitly state why people are encountering it	T364594	Current error message:
Leverage Edit Check infrastructure to offer people a call to action from within Citoid	T364595	We're imagining something similar to the current Reference Reliability experience:

In T311308#9775537, @Yann wrote:

It seems I git this bug while editing my talk page on Commons:

[f44aead8-ae05-4f50-870d-6e9d8410df7e] 2024-05-06 19:14:19: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError"

In T362379#9752545, @Mvolz wrote:

In T362379#9729595, @jeremyb-phone wrote:

besides statistics about which tools have this much volume would you also drop some kind of time series graph dashboard with request volume and error volume? thank you.

https://grafana.wikimedia.org/d/NJkCVermz/citoid?orgId=1&refresh=5m&from=now-30m&to=now

Too bad, but I can see where you're coming from. T36958 sounds super interesting.

How about scraping RSS feeds every 10 minutes and caching the results? That's very little traffic. Includes titles, links, author and date.

While npr.org isn't covered by search engine cache, it seems https://www.nprillinois.org/ is. There's no obvious way to rewrite the URLs though, for example compare:

• https://www.npr.org/2024/04/18/1245573728/truth-social-shares-rally-trump-media-technology-djt
• https://www.nprillinois.org/2024-04-18/trump-media-shares-surge-after-a-miserable-run-pros-say-stay-away

In T362379#9729666, @Samwalton9-WMF wrote:

In T362379#9729651, @AlexisJazz wrote:

In T362379#9729541, @Mvolz wrote:

The NYTimes has been blocking us for a while, it briefly worked when we changed datacenters and ergo IP, but they've understandably reblocked us after a few weeks' reprieve!

There's not a whole lot we can do except to ask for IP exemptions - @Samwalton9-WMF would this be something partnerships could try?

..there's no budget to get a VPN for $2/month and spread the traffic across a dozen IPs? Do you need me to pay for it? I can do that.

I don't think hiding our traffic so that our impact is less obvious is the way to go here, not least because as far as I'm aware Citoid identifies itself in the user agent. Much better for us in the long run to work with these orgs to either educate them on what we're doing, or to figure out ways of reducing our traffic volume. We don't want to burn bridges, especially when many of these orgs are current or potential TWL partners.

In T362379#9729541, @Mvolz wrote:

The NYTimes has been blocking us for a while, it briefly worked when we changed datacenters and ergo IP, but they've understandably reblocked us after a few weeks' reprieve!

There's not a whole lot we can do except to ask for IP exemptions - @Samwalton9-WMF would this be something partnerships could try?

In T214989#9705822, @Jack_who_built_the_house wrote:

Run this in the console on Special:BlankPage:

await mw.loader.using( [ 'ext.wikiEditor', 'ext.CodeMirror.v6.WikiEditor' ] );
$( '.mw-body-content' ).append( $( '<textarea>' ) );
mw.addWikiEditor( $( 'textarea' ) );

It works. No?

Cool, that does work!

I just copy-pasted Special:Version from fawikinews, ruwiki and enwiki into a file and checked the diff. Note that I replaced all times with 00:00 because fawiki shows different times.

In T309328#9060806, @Vermont wrote:

before writing off some of the most trusted and dedicated users on Wikimedia as bad faith.

Depends on the project and individual CU.

https://commons.wikimedia.beta.wmflabs.org/w/thumb.php?f=Example.jpg&w=220 doesn't work either, but returns instantly instead of taking ~45s:

Request from (European IP redacted) via deployment-cache-text08 deployment-cache-text08, Varnish XID 396622189
Upstream caches: deployment-cache-text08 int
Error: 500, Internal Server Error at Thu, 28 Mar 2024 16:59:52 GMT

Compare to https://upload.wikimedia.beta.wmflabs.org/wikipedia/commons/a/a9/Example.jpg:

Request from (European IP redacted) via deployment-cache-upload08.deployment-prep.eqiad1.wikimedia.cloud, ATS/9.1.4
Error: 500, Cannot find server. at 2024-03-28 17:03:14 GMT

Beta cluster is actively used to test the Commons app. Must be annoying for testers that upload.wikimedia.beta.wmflabs.org has been down for weeks. I frequently use it to test gadgets. Found a train blocker or two while doing so. But I don't see a solution either. ;-(

In T359768#9656733, @jcrespo wrote:

I'm afraid SREs cannot help here- while it is ATS returning the error to the end user, it is not the source, it is upload.wikimedia.beta.wmflabs.org what is timing out (Failed to connect to upload.wikimedia.beta.wmflabs.org port 443: Connection timed out) , which means it is a beta issue, that we don't own. I couldn't find any team responsible for it at: https://www.mediawiki.org/wiki/Developers/Maintainers#Services_and_administration so returning it to the original tagging.

T354023 explains that, the Gadget: namespace has been removed globally.

Somebody changed it from 2300 to 8. See https://en.wikipedia.org/w/index.php?title=Wikipedia%3AVillage_pump_(technical)&oldid=1214586229#Gadget_being_used_by_-1_users

This is very interesting. Yes, I hack your HTML a lot. It's pretty maintenance-intensive. https://en.wikipedia.org/wiki/User:Alexis_Jazz/Factotum adds multiple buttons/links. (configurable, but it can add like six or seven max I think) Especially because I aim to support all skins, including Minerva.

Thanks for the heads up! I'll keep an eye on this. It seems okay on the patchdemo, but if anything funky happens I'll know where to look.

In T352167#9575683, @hashar wrote:

In T352167#9363925, @AlexisJazz wrote:

I use my own omgtb script, it's extremely convenient. IIRC due to CORS I can't obtain the task from https://train-blockers.toolforge.org/. If you can tell me how the correct task can be found within this domain I can try to update my script.

train-blockers is now emitting emit an Access-Control-Allow-Origin: * header (Gerrit change 978139)

In T340705#9574658, @stjn wrote:

In T340705#9574643, @AlexisJazz wrote:

The current skin has no effect on the result AFAIK? But it's true that the script doesn't filter for skins. If there's a Vector-only default gadget but you're using CologneBlue, well, that gadget isn't loading for you. If there's a Minerva-only gadget but you're using Vector, same. For the purpose of finding low-hanging fruit this doesn't really matter IMHO.

The current skin has no effect, which is a problem for figuring out what contributes to payload on mobile. E. g. I got this in ruWP https://ru.wikipedia.org/?oldid=136342483 but most are gadgets for a namespace/action/etc. or do not load in Minerva.

But this task isn't about figuring out what contributes to payload on mobile. And that pie chart seems very useful to me: it shows instantly that https://ru.wikipedia.org/wiki/MediaWiki:Gadget-wikibugs is the largest default gadget.

In T340705#9574638, @stjn wrote:

In T340705#9161969, @AlexisJazz wrote:

You might find running https://en.wikipedia.org/wiki/User:Alexis_Jazz/EverybodyLikesPie.js to be of some help on these projects. See https://it.wikisource.org/w/index.php?title=Utente:Alexis_Jazz/Sandbox&oldid=3227820 for example.

This isn’t much help because this script assumes that all default gadgets load in the current skin, which isn’t true for Minerva.

@Jdforrester-WMF I just updated a Debian 11 machine to Debian 12. Result: MediaWiki no longer works. Searching the web I stumbled upon https://discuss.freedombox.org/t/mediawiki-upgrade-notes-bullseye-to-bookworm/2609 and ran php update.php.

$ php update.php 
PHP Fatal error:  Uncaught Exception: Unable to open file /usr/share/mediawiki/extensions/LocalisationUpdate/extension.json: filemtime(): stat failed for /usr/share/mediawiki/extensions/LocalisationUpdate/extension.json in /usr/share/mediawiki/includes/registration/ExtensionRegistry.php:199
Stack trace:
#0 /usr/share/mediawiki/includes/GlobalFunctions.php(49): ExtensionRegistry->queue()
#1 /etc/mediawiki/LocalSettings.php(154): wfLoadExtension()
#2 /usr/share/mediawiki/includes/Setup.php(218): require_once('...')
#3 /usr/share/mediawiki/maintenance/doMaintenance.php(83): require_once('...')
#4 /usr/share/mediawiki/maintenance/update.php(319): require_once('...')
#5 {main}
  thrown in /usr/share/mediawiki/includes/registration/ExtensionRegistry.php on line 199

How to resolve this?
Open your LocalSettings.php and delete this line:

wfLoadExtension( 'LocalisationUpdate' );

Now run update.php. This resolved the issue for me and the wiki is loading once more.

In T357184#9530959, @Bawolff wrote:

If MW estimates the transcode will be bigger than that size, then it will refuse to do it. In essence, it will change the error on the VP9 2160P transcode of File:Politparade.webm.

Historically, $wgTranscodeBackgroundSizeLimit was passed to ulimit to prevent files larger than that size from being created, but it seems this was removed in 7d9fb4ce1.

This is the hard limit for max size of a video transcode.

It is?

$ wget "https://upload.wikimedia.org/wikipedia/commons/transcoded/d/d5/Politparade.webm/Politparade.webm.1440p.vp9.webm?download"
HTTP request sent, awaiting response... 200 OK
Length: 4168557856 (3.9G) [video/webm]
Saving to: ‘Politparade.webm.1440p.vp9.webm?download’

@Bawolff what will be affected by this limit?

In T355746#9526785, @Jdlrobson wrote:

@AlexisJazz I found this pretty easy to replicate:

• Visit https://en.m.wikipedia.org/wiki/Talk:H%E1%BB%93ng_B%C3%A0ng_dynasty in Chrome with iPhone SE emulator. Note the page renders correctly.
• Run mw.loader.load('//en.wikipedia.org/w/index.php?title=User:Alexis_Jazz/Bawl.js&action=raw&ctype=text/javascript'); in console. Note it renders incorrectly.

@jhathaway nope. Guess it was a fluke, or one of the Wikimedia mail servers (assuming that's load balanced) was malfunctioning, or maybe Cryptic did something different. I'll just decline this myself, anyone feel free to reopen if it happens again.

@DonTrung Did you clear your browser cache?

Probably nothing to be done here at this point.