FWIW I have not been having this issue recently with enwiktionary at least. My Pywikibot settings look like

@Fabfur any idea why my pywikibot script is getting 429 errors every 200 pages it's pulling down? It pulls down about 7 pages a second, which is what pywikibot seems limited to. This is not a lot of pages. every 200 pages i get this:

WARNING: Http response status 429
ERROR: Traceback (most recent call last):
  File "/opt/homebrew/lib/python3.11/site-packages/pywikibot/data/api/_requests.py", line 702, in _http_request
    response = http.request(self.site, uri=uri,
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/lib/python3.11/site-packages/pywikibot/comms/http.py", line 289, in request
    site.throttle.retry_after = int(r.headers.get('retry-after', 0))
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: invalid literal for int() with base 10: '11.000'

@cscott Thank you for reverting.

@cscott Yes, and many others. I don't understand though why you need to know this instead of just reverting.

I can guarantee you there is more breakage; we have not had a chance to look into all the places that use mw.ustring.lower() but I guarantee you it's quite large.

You have to understand that mw.ustring.lower() and mw.ustring.upper() are used all over the place and none of the existing code expects the output to randomly get passed through NFC.

For example, [[facci]] displays /fàtt͡ʃi/ instead of /'fat.t͡ʃi/.

All of the pages that use {{it-pr}}, for example, are generating incorrect output.

Ditto what @Theknightwho says.

@cscott I am one of the major developers of Wiktionary code, and I have been a software developer since the 1990's. Functions in libraries provide contracts, and you can't simply change a contract like this without expecting major breakage of all users of the code. Suddenly changing a contract because you think it's the "right thing to do" is not in fact the right thing to do; it shows a basic lack of understanding of how software development works. Please revert this change as soon as possible, thank you.

See https://phabricator.wikimedia.org/T390512.

I have raised this to the highest priority as it presumably means all MediaWiki sites are broken.

BTW by "change is gone" I mean the history no longer shows my commit, and the version that appears is the one from the previous commit.

@xcollazo Thank you for triaging this bug. However I notice that the broken dumps are still present on dumps.wikimedia.org, and there is still no indication on the site that the dumps are broken. This seems a very bad user experience and will likely reduce trust in Wikimedia in the future. I would recommend you take action ASAP (today if possible) to rectify this, either by adding a prominent notice on the site that the dumps are broken or removing/hiding the dump files entirely.

BTW I'm going to have to redo at least a day's worth of work because of this.

@xcollazo Hi Xabriel. IMO the corruption is the latest dumps is a *HUGE* issue. I only just discovered it now when trying to figure out why some pages were not being found that should have been found. Why is this bug report still marked as "needs triage" instead of "major bug" and why is there no notice no dumps.wikimedia.org that the dumps are corrupted?