Additionally when the event has been much larger a very common theme and point of feedback in our feedback surveys is that it is impossible to have a conversation with too many people in the room.

In T220212#5260551, @Multichill wrote:

Wikimedia technical events like the developers meetings (hackathons) and the summit always had a strong MediaWiki and MediaWiki extensions focus. Less attention was given to the development happening on top of that. A lot of attention for the things happening behind the API, but not a lot on the consumers of the MediaWIki API (and the databases in case of the API not being sufficient). So maybe for this event in the selection process get some (heavy) consumers involved? I would look in the corner of bot and tool developers. This shouldn't be done if it waters down the scope too much or the group would become too large. Focus is important for this event to be successful.

Right I remember now. This is of course because otherwise a, sorts after capital Z, which is even less desirable. Therefor, this is dependent on localeCompare, like T32674: Use sort collation config in JavaScript (jquery.tablesorter)

https://commons.wikimedia.org/wiki/TimedText:Big_Buck_Bunny_with_VTT_acid_test.webm.en.vtt
https://commons.wikimedia.org/wiki/File:Big_Buck_Bunny_with_VTT_acid_test.webm

The core now validates all SRT and VTT subtitles, due to the great work of @brion It's just the old player doesn't understand proper SRT with markup (only our old warped version of it).
The new player should support VTT with markup if your browser supports VTT with mark-up, and our core will automatically convert the SRT to VTT if needed. But the new player isn't live yet.

Well, we definitely can't have wiki links anymore, as that is not part of any webstandard that we intend to follow (or even exists as a matter of fact). The mark up is a different thing. You cannot use wikicode anymore, only official SRT or VTT markup. And the SRT markup specifically is currently caught between a rock and a hardplace as we transition between the two technologies. I welcome more contributors. I mean i've only been trying to make progress on this for 5 years now... 5 years to replace a video player.

Example pre and post:

Thanks for the work @Ebe123 !

There is an abusefilter... and i think this kind of abuse is exactly what we have abusefilter for... Dont think any further action is required really.

Yes i know.

@Sj this probably has the best most recent information. https://www.mediawiki.org/wiki/Topic:Uxkv0ib36m3i8vol

I think we should consider adding it, but:
1: it needs a better name that is not the extension name
2: we need to check if it is safe to show from a performance point of view

@Billinghurst well it's not a production level tool, so outages like these are to be expected.

This is not an issue with SyntaxHighlight. Maybe the original user thought of another extension, but this extension doesn't have the problem described.

yummy https://en.wikipedia.beta.wmflabs.org/wiki/Special:ApiSandbox#action=query&format=json&meta=languageinfo&liprop=code%7Cbcp47%7Cdir%7Cautonym%7Cname%7Cfallbacks%7Cvariants&licode=en%7Cde%7Cnl%7Csimple%7Csh%7Czh-hant

Btw. Im pretty sure this wont get prioritized anytime soon, but maybe we should provide a warning text on Special:ElectronPdf ? “Its currently not possible to create pdfs of old revisions, here is the download for the current revision ?

Also note that there are still several 'missing font' tickets open, specifically:

• T37568: Emoji characters not supported by fonts of PDF rendering stack
• T172392: Provide Cherokee fonts to render servers for Proton

Those are the two i ran into today at least, there might be more.

Not sure if it applies here, but please remember that we allow Api-User-Agent as an alternative to User-Agent for Javascript solutions.

Results with Proton

This is still an issue with current generation Proton PDF rendering

No issue with current generation of Proton PDF rendering.

Not an issue with current generation Proton PDF rendering. Book rendering not taken into account.

This is not an issue with current Proton PDF rendering. Only existed in either OCG-PDFRenderer or maybe even only in the pediapress PDF rendering.

Both seem fixed now.

Fixed with Proton rendering as far as I can tell.. no longer considering book rendering of course.

Mostly fixed, though I note that in PDF the background of the legend of chart is missing, while in print it's there.
https://en.wikipedia.org/wiki/Brussels

Seems to work with Proton, though a bit hard to reproduce since we don't support making PDFs of old revisions.

Not an issue with Proton PDFs. Would still be an issue with books most likely.

This now works for PDF rendering at least (again books is sort of dead), but i note the template is hidden with "noprint"

Correction, this was a pure Collection report of course, not the newer PDF rendering.

In PDFs, license info comes from the printfooter, which for wikimedia introduces wikimedia-copyright message, but that is an override of the defaults

Proton version:

Seems fixed, but a bit hard to judge from a screenshot at that font size. error 8 "should be italic" no longer seems true for the current versions of the article, but see no reason why that problem should still exist.

And the issue {{NFPA 704}} in PDF

This seems fixed with proton.

This seems fixed with proton and 1 column layout:

I'm leaving a book rendering out of this, since.. well let's be honest ;)

This seems fixed with proton and 1 column layout:

There is still an issue here with Proton. It seems the images of

Version with Proton

https://www.wikidata.org/api/rest_v1/page/pdf/Wikidata%3AMain_Page
Hmm..

The stalling/blocking ticket was closed, so I guess this can be 'unstalled'. Needs implementation via T213368: Support language variants in Proton ???

This requires extending the font packs that the servers use with Cherokee fonts that are available open licensed (and distributed in Debian).

Output of Proton.. still blocked on SVG of course.

Screenshots and links to examples pages and PDF output would be welcome.

Seems to work for current production now: https://en.wikipedia.org/wiki/Template:Infobox_film/doc
Making use of Proton + RESTBase

Also an issue with Proton. I suspect this is Chromium dynamically choosing a viewport suitable viewport width, to accommodate the panorama picture in the article in question.. (the file is Wrecked ammunition train3.jpg). It probably also happens for very wide tables on a page.

New service in place now, Not sure if similar issues occur for Proton Do we have any idea why this happened with ElectronPDF ?

This seems fixed with Proton deployed.

In T210651#5233028, @Pchelolo wrote:

The original issue report message was before the switch to the new PDF renderer, so it is 100% not related. The Electron renderer was experiencing some issues before we switched to proton, might be related to that.

Download as PDF - not working
Waiting takes forever and still no PDF downloads. Tried again and again.

Yeah, inline samples, or at least per component linking to the specific class in the php doc. Not one link in the header that is "he, here is the index for all the documents, good luck finding the classname (that we didn't tell you about) of the component you were looking at on the previous page and already forgot about"

@Krinkle

21:12 #wikimedia-tech: < Krinkle> thedj: Is this still something we want to do? https://phabricator.wikimedia.org/T132946

WebVTT acid test: http://captionatorjs.com/git/video/acid.vtt

Note to self, there is a WebVTT acid test on http://captionatorjs.com/git/video/acid.vtt
We'll probably want to incorporate that into our testing.

Primarily because we didn't intend that to be a user visible page at any time.... it's also rather performance heavy at times.

This bunching up and margin cutting starts happening on anything under 980px wide.. And then it DOESNT compromise margin there where you really need it, the translation page...
That's not mobile device, that's a normal non-fullscreen desktop size.... It's even worse on mobile sure....

Ah we switched from getCaptionsFromMediaWikiSrt to getCaptionsFromSrt probably. The first just 'takes' some html processing, the latter strips all html.

API serves up:

We are switching to WebVTT (HTML5) and as such are dropping markup for SRT subtitles. For that reason, there will be a period where this will not be possible.

@Bstorm i'm super busy with work and no time to analyse potential impact. Suggest crossing fingers and pray.

It seems like any customisation or extendability of CodeMirror by JavaScript developers was completely left out of development by Community Tech team.

Slightly related btw is T209673: Transcodes are not reset for undeleted video file

Fil: vs. File: it's serving up the translated namespace, instead of the canonical one for Commons files.

[Error] Failed to load resource: the server responded with a status of 400 () (api.php, line 0)https://commons.wikimedia.org/w/api.php?action=timedtext&title=Fil%3ADu_gamla%2C_du_fria.ogg&lang=sv&trackformat=srt&origin=%2A
[Error] Failed to load resource: the server responded with a status of 400 () (api.php, line 0) https://commons.wikimedia.org/w/api.php?action=timedtext&title=Fil%3AUnited_States_Navy_Band_-_Sweden.ogg&lang=de&trackformat=srt&origin=%2A

Sure, go right ahead implement the feature and submit a patch. Everyone can contribute.

Im pretty sure i explained this to ar.wp before... The proper way to fix this is to generate html with TWO classes, like class=“infobox infobox_v2”. And make sure that any visual changes in v2 override the visual changes of infobox.

I suspect a redirect loop when the oauth token is returned to svg-translate or something like that.

We have another table update ticket now in T185997: Transcode logging should also log the server on which the transcode process ran. Might be smart to combine both. Both should be possible to roll out as optional fields, so the db change can be done whenever we want (which i think is a requirement these days anyways).