Ah of course. 2 birds, 1 stone

This was fixed by https://gerrit.wikimedia.org/r/561285 as part of T237190

Someone wrote a lexer, but it isn't upstreamed yet:
https://github.com/nikeee/pygments-lexer-graphviz/tree/master/graphviz

This doesn't seem to be a problem any longer. Please reopen if i'm mistaken.

This is fixed with https://gerrit.wikimedia.org/r/571354

wrong syntax highlighting extension..

I have to say.. I don't think I have ever been as happy and satisfied with as small a change I have made as this.. God this does wonders for meta.wm readability.

1. ID3:
   • module.audio-video.asf.php ASF fileformat metadata extraction (unlikely to be in use)
   • module.graphic.bmp.php BMP plotting (unlikely to be in use)
   • module.graphic.jpg.php IPTC parsing This function does not require the GD image library.
   • module.tag.apetag.php APE audio format coverart extraction (unlikely to be in use)
   • module.tag.id3v2.php coverart/attachment extraction (unlikely to be in use)
2. BitmapHandler indeed only as fallback
3. IPTC parser This function does not require the GD image library

List of all grants: https://meta.wikimedia.org/wiki/Special:ListGrants
Maybe add transcode-reset to uploadeditmovefile grant ?

BTW. it seems that the transcode-status right (on WMF) is currently configured only for sysop. With this patch, it means that most users can reset a 4 hour 4K video (using transcode-reset permission granted to auto confirmed users), but only sysops can look at Special:Transcode statistics. That seems a bit extreme to me. I'm not sure to which other groups we should extend that right however.. auto confirmed is a LOT of people and in between are a lot of scoped groups, but none that seem particularly relevant.....

This is because minerva disables float on all tables.

.content table {
    float: none !important;
    margin-left: 0 !important;
    margin-right: 0 !important;
}

I don't think there is a quick solution for this, i don't want to start !important'ing mbox style statements. ideas ?

Technically, role=presentation removes semantic meaning from dom elements and its children (makes a table not be a table), while aria-hidden removes 'content' from the accessibility dom tree.

I think we can call this resolved. The only remaining uses are in some 3rd party skins.

i gave you some more details to work with :D

This issue likely no longer exists... The inputs for that page got redone somewhere in the last 1,5 year.
@Nikerabbit can you confirm and close the ticket if so ?

@KarlFrei actually that might be happening later this year: T236892 mostly because the graphoid service is lacking maintainers.

Will be coming to you whenever the release train starts rolling out again..

Apparently ace searches line by line and thus cannot do multiline regex
https://stackoverflow.com/questions/35289002/ace-editor-multiline-regex
https://github.com/ajaxorg/ace/issues/2869

Lol, I already 'fixed' this once before in T126010, but it had a typo in the CSS.

Thank you @MattFitzpatrick and @PerfektesChaos
Apologies that it took so long

This seems like a situation where you should be using a "<prev index next>" style of navigation, instead of a big box with links. Positioned either top or bottom (or both)

A change was made in how audio players load, and this ticked is therefor no longer valid (as this subtitle mode is no longer in use)

@Volker_E seems like a quick win ?

Possibly similar to T222894

Confirmed on beta:

audio caption ui was since removed

abandoned because i can't move this forward. whoever wants to fix it can take over the patch

I think both were fixed.

This also partly relates to T111565: [EPIC] Enable mediawiki.page.ready on Minerva (collapsible templates (including infoboxes) and sortable tables).

The Commons main page was fixed a while ago.

In T37704#5829140, @AronManning wrote:

@TheDJ: Is there any research (database query) that tells us what percentage of pages use inline styles? (My guess is between 50% and 100%)

In T37704#5829014, @Ciencia_Al_Poder wrote:

One big problem of styles loaded through a stylesheet is that they either block the rendering of the page, or cause a reflow, being both bad for performance.

I think the point Is not getting across entirely. If someone wants to take over maintenance and spent their free time to maintain the extension for the next couple of years to support the extra overhead of extra functionality, u can do so. But lacking that person, please don’t expect someone else to do this work for u.
There is also no bandwidth nor priority at the foundation to support this for the community.

Went back to revision https://en.wikipedia.org/w/index.php?title=Wikipedia:Files_for_discussion/2015_December_5&oldid=693875619
and I no longer see the described problem.

This is one of those things that seems so simple, but in reality is really hard, because we use floating images and have lots of assumptions in existing content.
I believe the biggest challenge here was the thumbnail frame wrapping (which is one of the reasons minerva doesn't have a frame)

This was about a single article PDF rendering, now handled by Proton, where it is fixed.

This was about a single article PDF, now handled by Proton, where it is fixed

This was a about an error in rendering a single article pdf, which is now handled by Proton, where it is fixed.

This was about a single article PDF, which is now handled by Proton, where it is fixed.

This was about a single page PDF, now handled by Proton, where it is fixed

This was about a single article PDF render, which are now handled by Proton, where it is fixed.

This was about a single page PDF. Now handled by Proton, and we no longer do attribution indexes, so this is no longer a problem.

This was about single page PDFs. Fixed with the new Proton renderer.

This seems fixed with the new Proton renderer.

Hmm, intersting. The H2 does tell the browser to avoid a pagebreak right after it. Perhaps it is because there is another header right after the H2...

PDF rendering via new Proton services now work for this article

PDF rendering works now with the new Proton PDFs

No longer an issue with the new Proton PDF rendering

This seems to work now with the newer Proton PDF rendering

Seems fixed to me. Download as PDF works now that it is using Proton.

there havent been further reports of this. considering it closed