Replace https://d3js.org/d3.v3.min.js
with

https://cdnjs.cloudflare.com/ajax/libs/d3/3.5.17/d3.min.js

Which seems to be the last of the v3 series. Or of course just use npm in the project to include d3.

Hmm 1000 is exactly the breakpoint for the sticky headset, so now I no longer get a sticky header on the iPad, which I find a bit of a shame.

In T311145#8021833, @Izno wrote:

Will need to special case <link> as well.

@Proc It is stuck on lack of reviewers and Parsoid support, as well as a general agreement between devs that this is actually desirable to support long term inside wikitext (what was once given is hard to take back and needs eternal support).

To clarify further. A long while ago (as we moved to html5) the developers decided that we do not write code to pass a validator, but to work best as it can/should in browsers.
It is known that this usage of style and link by TemplateStyles creates invalid html5, but it works in every browser and is expected to keep working in every browser. It also brings several benefits to the way our documents are generated and forwarded to end users.

I have a branch for this, I still need to write a few extra testcases, but hope to have a patch for review somewhere this week.

OK. i looked into this again... First of all, i don't think we can see this is in any way relevent to the vector-2022 deploy. Don't forget that over 60% of traffic already is on mobile and has always had this experience.

See also: T256528

That is because the MMV description is not a wiki page. You can also not put an image inside a caption for instance, or a graph, or a map.

Apparently this is still broken ?

See also T155919 and T303584
Generally this is a protection to make sure people don't receive multimegabyte shapes.

Resaved as PDF/A and uploaded.

Yeah, so the console says:
Loading font Times-Roman (or substitute) from /usr/local/Cellar/ghostscript/9.56.1/share/ghostscript/9.56.1/Resource/Font/NimbusRoman-Regular
which it doesn't say for other conversions that i have done.

Just leaving this here to note that even on Desktop I'm starting to find this problematic and last year I experimented with some CSS and turned the interface into a vertical tab interface. So I definitely think there is some substance to this getting rid of the horizontal tabs interface.
https://twitter.com/dj_hartman/status/1425426421820936201

After videojs its no longer inconsistent. The new inline player keyword that is being worked on in T241107 should make this predictable in the future.

Should be easy to do by setting cursor to none for .vjs-user-inactive

Probably a font specific problem, by the looks of it.

Unreproducible

The wrappers to call out to binaries has changed twice since this report. This report is therefore unreproducible. If it still does not work on Windows, please open a new ticket against the new version of mediawiki.

Likely similar to T224355

This is now using shellbox, so I’m assuming we can call this resolved. Pls reopen if not the case.

Patch was merged and deployed. Closing

This is probably T167420

What happens here is that the first page and the last page, largely are not individual PDF elements, but its really just one big image. The left part of the image is the last page, the right part of the image is the first page. This image is therefore HALF outside the drawing area of both of those PDF pages.

Hi @Jgiannelos. I believe you have a bit of Swift knowledge ?

Seems very unlikely to me we will ever implement this.
imageinfo is specifically tied to the File namespace and File and Data namespaces work completely differently.

This area of the code was heavily rewritten a couple of years ago. The message listed here is not even in the code any longer.

Considering closed (after deploy). Several other issues remain but they have separate tickets.

This is the same as T310453

I have remuxed all remaining problematic files on commons. Every single one of them had broken metadata for the seekpoints.

This shouldn't be a problem as long as MediaWiki only generates url fragments that are lowercase (which is what it should be doing). In general, thumbor is a tad more permissive than MediaWiki (you can request any language you want, even if it is invalid or plain non-existing) (thumbor is decoupled from MediaWiki state and logic, as it should be). What matters is that MediaWiki shouldn't be requesting such things, and I don't think it does.

Rather strange, I see nothing in the page that could explain this fully. What is unusual is that webpage is not using https:// in its og:url and twitter:url

Its the left margin of the 'ul' element that forms the gallery.

I believe the ffmpeg arguments for copying metadata are:

Not actionable, also there are other tasks related to improving upload reliability for large files and/or chunked uploading that have more details. (and there also have been some improvements over the last 6 years)

There are only 35 files left now. I suspect most of these will require remux'ing

See also T310235

Yes these are well known confusing parts of MW language support. Its difficult to clean up, but I can make some improvements...

I wonder if this might be fixed if in the future with use --accept-language for the renderer

This has been fixed, so i'm closing this. Separate issues should be filed as separate tickets

This is indeed already working

I have a fix for this in the works.
Also i'm splitting this up into more specific problems

I would like to note that this can all easily be implemented for non-wmf wikis. If someone just spent some time on adapting SVGHandler (or created an extension to override SVGHandler).

This is not a new error. What is interesting is that it only seems to occur on Firefox.
Its also not doing much fancy stuff, its just parsing an api JSON response into a variable, so ... maybe it is getting the wrong info as input for the API or something ? Hard to say.

Thank you @Umherirrender

Will be deployed next week

Deploy will follow next week

There is indeed all kinds of confusion around this...

In T55167#7988387, @JoKalliauer wrote:

@TheDJ Should we create a new task for resizing APNG on Thumbor ?

See also: T99280

Was dealt with upstream: https://github.com/commons-app/apps-android-commons/issues/72

All modern browsers support this now, and IE11 is on the way out. https://caniuse.com/?search=apng

This likely broke in commit c259c37033d3f16aa949855d25178e76578bb586 by @Umherirrender, renderLanguage is allowed to be optional here.