Destroyed transcodes of another file by overwriting it. It seems that overwriting a file with chunked upload and then purge page cache is a secure way to reproduce with sufficiently large video files.

https://commons.wikimedia.org/wiki/File:WikiCon_2023_-_20_Jahre_kleine_Wikipedia-Sprachversionen_dupe.webm is an exact copy of https://commons.wikimedia.org/wiki/File:WikiCon_2023_-_20_Jahre_kleine_Wikipedia-Sprachversionen.webm - and it just works fine. Maybe I chose the wrong component when filing this issue? Anyway please stop saying that something is wrong with the file :)

In T351557#9342719, @TheDJ wrote:

Spent an hour digging through the logs but couldn't find anything. It seems the transcode jobs are never queued, which is uncommon.
Reverting fixes it. What software did you use to modify the file ?

Ughh, I managed to break another one by re-uploading / uploading a new version.

An assessment if the issue can be fixed or a workaround like if a re-upload would help, would both be appreciated. Thanks!

There is a new report on c:COM:Forum and T291137

as meaning to return no results (or as an error)
go through a deprecation process

output in pages using a template is cached

The script moved to the expose-data tool

T35947 also requests improvements to the user's file list. Should the improvements be done in core or through this extension?

I thought we nuked jquery.ui.

@DannyS712 I consider it unexpected behaviour. However phrasing it as a question I was hoping to get more productive comments compared to a "request" because nobody has to be defensive. Now please let's, according to mw:Bug_management/Phabricator_etiquette, focus on the issue?

@Marostegui Community interest in this extension does not appear to be overwhelming and yesterday T66548 was declined. The extension can't be deployed, at any time.

@Krinkle Thanks for the analysis.

Is there a work-around?

API returns warnings about Unrecognized parameters at Wikimedia Commons.

Wondering if issues are tracked here or in https://github.com/Toollabs/convert

The final recommendation for a particular software package request may ultimately be to use the job grid for now until a system for using customized containers is created.

Logs from https://tools.wmflabs.org/convert

In T69074#4404237, @Pastakhov wrote:

I got the same problem, please explain what value was increased.

Added the instructions by Bryan to the Web help of Tool Labs. Right now it is under the Tomcat/ Java Server section while it could be a general one.

Contents have been migrated to the new instance static2. Old one (mediahandler-tests-static) still in place in case forgot something; can be safely deleted at the deadline. Sorry for the long delay; I am reading my E-Mail and from the deadline I judged I could queue this for now to happen. Thanks for trying so hard to reach me and sorry again.

BTW, it serves the <s>Chemical Markup Editor</s> SVG Editor of https://mol.wmflabs.org

I will upgrade <s>the project soon.</s> move the data to a fresh instance, soon.

Done. Thanks for the reminder.

Should this task be associated to MediaWiki-extensions-MolHandler?

Is that a result of enabeling MathML?

Wrong or too generic MIME type causes browser not to render svgs in <img> tags.

While doing this minification, it might be necessary remove languages different from the content language of the article the SVG is used in (i.e. the content language) from [[ https://commons.wikimedia.org/wiki/Help:Translation_tutorial#Using_the_same_file | SVGs containing translations in <switch> elements ]]. Otherwise the browser might decide about which language is best suited resulting in undesired behaviour for visitors of e.g. public libraries? [Not extensively tested yet ... but the lang attribute on the HTML element appears to be ignored in Firefox]

Something new:

In T134196#2267207, @Luke081515 wrote:

I have time, so going to deploy your patch today.

There be'll a follow-up for directory mtime not always updated and/or invalidation time is based on "$wmfConfigDir/."

In T130018#2263380, @Dereckson wrote:

It hasn't been announced. Should be in the next tech news.

It shouldn't be too difficult for me to find a commons sysop or GEI to disable the gadget.

In T132930#2256910, @matmarex wrote:

Deployed. @Steinsplitter, filter 140 can be disabled/deleted now, if you could. :)

I've proposed deploying this to production on May 4th, pending no issues with it on beta: https://wikitech.wikimedia.org/w/index.php?title=Deployments&action=historysubmit&type=revision&diff=459726&oldid=458830.

In T131844#2236324, @Legoktm wrote:

Confirmed working on beta.

While it works on action=edit depending on the user's personal configuration, it's always broken on [[Special:Upload]].

@greg Anything left that I could do except waiting?