If these automated descriptions weren't in WDQS (and consumed triples), how could the label service fetch them and bring it into results? Generating descriptions on the fly couldn't work well with queries with too many results. Other queries using schema:description couldn't work at all.

Keep your words, don't delete everything at once. I can easily imagine a situation when I would re-visit a category 31 days later, but all the thumbnails are gone because they all expired one day ago at the same time, as these thumbnails are all generated 31 days ago so had the same expire time.

Yes, the thumbnails can be regenerated. But with a page load time of 10+ seconds... This is unacceptable for hot traffic to search results, categories and galleries. What's worse is when the user goes to next page, few thumbnails can render because T266155, as said above. I encounter this situation regularly. It's a very bad experience. But at least if I loads a category successfully it will continue to load for anyone, for now. The prerendered thumbnails are exactly meant to prevent this from happening.

Is it possible to keep prerendered thumbnails indefinitely? I don't want to see search results full of broken thumbnails because these thumbnails are automatically cleared.

Thumbor is currently heavily overloaded (T337649). As a result, traffic to thumbor should be reduced as much as possible until things improve.

Supposed to be fixed by T332125.

An actual 100Mbps WAN transit link suffering from network congestion could likely trigger this timeout. My fastest internet connection is 100Mbps theoretical, but I never download it successfully, actual speed is near 30Mbps. Anyway, 10Mbps link speed could definitely trigger the timeout. Not everyone in the world can have access to true 100Mbps network.

Why not upload all these files on Commons so that they can be used on any Wikimedia project? I have been able to upload PDFs from 1GB to 3GB on Commons 100% successful with the method I mentioned, so maybe the tool you use could be improved.

These files are uploaded at the request of another Wikimedia user. I have PDFs up to 8GB, but they will be splitted to parts below 4GB. Not having to use server-side upload is a huge achievement for Wikimedia engineers and myself, before that even 2GB PDFs have to be uploaded with server-side upload.
But at that time these 2GB PDFs can have their thumbnails once on Commons, like https://commons.wikimedia.org/wiki/File:%EF%BC%88%E5%85%89%E7%B7%92%EF%BC%89%E7%BA%8C%E4%BF%AE%E5%BB%AC%E5%B7%9E%E5%BA%9C%E5%BF%97_-_%E5%85%89%E7%B7%92%E5%8D%81%E4%B8%80%E5%B9%B4_(1885).pdf. Something must be broken since then.

In fact the file key has been changed when uploadstash-file-not-found error occured. Need to go to Special:UploadStash to find the new correct key and manually recover, see https://commons.wikimedia.org/wiki/User:MidleadingBot.

Seems already resolved

Not resolved.
See https://commons.wikimedia.org/wiki/Special:Log/Daphne_Lantier

PDF files as big as 2.13 GB have been uploaded to Commons with some tweaks to API requests. This was never imaginable before. Thanks!

Yeah, but regardless of that, if this feature can be aware that the hyphens may be part of language converter and do not make mistake because of it, we can use this feature on zhwikisource.

The hyphens at the end of these zhwikisource pages are not real hyphens, but is part of MediaWiki-Language-converter syntax. We needs to identify these usages and do not join them incorrectly.

Chinese Wikisource already has reached a consensus to enable this feature as soon as possible. I have notified the community at https://zh.wikisource.org/wiki/Wikisource:%E5%86%99%E5%AD%97%E9%97%B4#%E5%B0%86%E9%A1%B5%E9%9D%A2%E4%B9%8B%E9%97%B4%E7%9A%84%E7%A9%BA%E6%A0%BC%E7%A7%BB%E9%99%A4%E7%9A%84%E4%BB%A3%E7%A0%81%E5%B7%B2%E9%83%A8%E7%BD%B2%E4%BA%8E%E7%BB%B4%E5%9F%BA%E6%96%87%E5%BA%93%EF%BC%8C%E9%9C%80%E8%A6%81%E5%A4%A7%E5%AE%B6%E6%8A%95%E7%A5%A8%E5%90%AF%E7%94%A8 . In fact, a gadget to do the very same job has been available for months at Chinese Wikisource. They were not enabled by default due to performance concerns of doing massive regular expression replacements over the entire article. This patch is the most efficient and easy solution to the problem.
Also, Korean, Japanese and Vietnamese Wikisources might be interested in this improvement? Anybody to notify them?

MediaWiki:Mobile.css stops loading on all wikis, including English Wikipedia. Switch to mobile view and examine all resources loaded: styles defined in MediaWiki:Mobile.css cannot be found.