Merged and released in 2.5.0.

Yep, looks like it's better now. We heard back from them and they said that it was because of another client using lots of resources and that they'd redistribute the load.

There's a user script that @Ruthven set up with the above code:

The above patch is ready for review.

@Yaron_Koren yep, and thanks!

Why not Bootstrap 5.2, the latest version?

It seems to be intermittent. The last few days it was working, but now it's not again.

Patch is released in 2.4.0, and deployed.

It's one process per request at the moment isn't it? But no, apart from the recent slowness with Transkribus no one's complained; I guess it's just quick enough, and doesn't get a vast amount of traffic.

In the delete prompt, if there are scores, we could prompt the user to grab the wikitext table of scores (e.g.) and suggest that they store them on-wiki.

Version 2.0.6 of wikisource/api is released now, so wscontest can be updated to use it.

The error message popup is not accessible to screenreaders (at least not when I tested it with NVDA, Orca and VoiceOver). Therefore, the user does not know what is causing the error.

I think this is a Edit Recovery bug.

Just to confirm: this is for PDF export isn't it? For epub, I'd imagine that it's up to the ereader to display whatever it wants.

I'm not sure, I think it'd be tricky via CSS only.

We need to request an increase of quota for the Wikisource project (currently 6 / 8 instances; 16 / 16 VCPUs; 32.0 GB / 34.1796875 GB RAM).

I think that basically the job queue is too long at the moment for it to be an interactive process. I've emailed Transkribus to ask if anything's changed. If it's not and this is how it's going to be from now on then we need to change how jobs are submitted and monitored (e.g. make it easier to submit a whole set of pages at once, from the Index page?).

Yep, I think it definitely makes sense to parse description as wikitext. This was certainly an oversight in the initial patch.

Great!

Sylheti Wikisource (Q120844812) has been redirected to Multilingual Wikisource (Q18198097), and all is working correctly now.

PR: https://github.com/wikimedia/wikimedia-ocr/pull/105

The above job 6158378 is now 1256 in queue (up ~150 in five minutes, at which rate it might be processed about 45 minutes from now; let's see if it is).

When it crashes, is it quick to crash or does it take some tens of seconds?

The result is an array containing the EngineResult object.

I've been experimenting to reduce the size of the CSS, but haven't really made any headway I'm afraid. :-( Splitting the PhonosButton.less styles makes not much difference (e.g. down to 118.92 KB from 119.75 KB uncompressed).

@Jonathan3 Can you test with Cargo's current master and confirm that this is okay now?

How about we add some better output for debugging this, as a first step? https://github.com/wikimedia/wikimedia-ocr/pull/103

And a non-google one (there's been a few others in the last couple of days too):

Do other numbered lists show correctly?

This error has happened again, a few times. For example:

In T334454#9016276, @MusikAnimal wrote:

It's standard practice to clear the cache on deploy, and it's in the deploy script.

The more I think about this the more I wonder how to do it in an intuitive way. If we split the stored data by user there are lots of ways that we get confused:

@Jdlrobson are you working on this? It's assigned to you.

Looks like we're trying to create a title while reporting an error with that same title. Instead, we'll catch that error and just show the title and not a link to it.