Working.

Sorry, I missed this tag for language converter.

I shut down the bot and upgraded it.

@TheDJ Thanks. Hope this will help more people who are confused like me.

Please be more clear about the UA policy enforced here. I am always setting the Api-User-Agent header in my code with my Wikipedia username inside, but my bot still stopped working. My code always set the Api-User-Agent header rather than User-Agent header, because the same code may run in a browser or outside a browser. The most probable reason my code stopped working is that the Api-User-Agent header is null and void, just because User-Agent header is missing, right?

Shouldn't anonymous users be able to edit talk pages and project chat at least? Why protect the whole website, including talk pages?

Thank you for making thumbnails of this file available again!

This has caused some maintenance queries to return results which have already been fixed. Especially visible when the number of jobs is large. Purging the item doesn't work. How to force reloading a list of items in WDQS?

Yes, happens quite often during uploading.

Firefox now doesn't display the spaces between lines of Chinese text by default. However, Chrome still doesn't support it.

Actually, the user would likely first create an item, then add the native label, then add a description, then add statements and move on to the next item. When the check is enabled, it's likely the user just sees he can't use this particular description and writes another description, or in automated editing, ignores this error. So not particularly effective overall, only QuickStatements can benefit from it since it creates the item in full in one edit.

Now haslabel:mul search keyword is working, I think this task is completed.

Almost no new PDF file thumbnails can be generated from codfw: https://commons.wikimedia.org/wiki/Special:NewFiles?user=&mediatype%5B%5D=OFFICE&start=&end=&wpFormIdentifier=specialnewimages&limit=50&offset=
The situation is a lot better when switching to eqiad. But the thumbnails rendered in eqiad somehow aren't shared with codfw, so when switching back to codfw, the thumbnails are still not loading.

If another qualifier is used to specify whether "mul" is always accepted, then the number of qualifiers already equal to adding "mul" as a second accepted language as proposed above as a workaround.
Because it's not clear how this extra parameter is defined, and whether this extra parameter would be too complex to implement, I think it's better to discuss how the more flexible parameter should be added as the next feature to support. Better not to block "mul" deployment due to this (There are other more serious issues to fix in "mul" language code than this one).
And many times languages with non-Latin alphabets still use a Latin label, such as "MediaWiki" and "PHP". These labels shouldn't be added to a specific language merely because a property constraint opt-out of accepting "mul" label.

If we are going to prevent labels that are the same as mul from being entered, then mul must be accepted all the time.

Due to T266155, I have to keep refreshing the category page, about 5~10 times, until all 200 thumbnails are generated. Therefore some "cache hits" are actually caused by cache misses. Especially true for those newly uploaded files, or when thumbnails are deleted but Thumbor fails to regenerate them.

P31 of chemical compound is "type of chemical entity" Q113145171 instead of chemical compound now. So descriptions of chemical compounds still needs to be copied from P279 rather than P31 by bots.

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.