After:

• removing the white-space: nowrap
• removing the width: auto that prevented the toc from taking the full width
• adding a max-width: max-content so that on wide screens it doesn't take useless estate (now the auto is away)
• slightly reducing the text size for one to still be able to sort of see the top of the section

looks like this:

Nothing to do on XTools' side.

Fixed.

Fixed in #622.

Note: some users are still reporting major usability issues with editing window height, though it doesn't happen to me and I don't understand exactly what has been done. From this:

Something new has just lost my ability to resize the edit window in the Page namespace. I will have to stop editing until this is fixed, since I cannot see enough of the text at one time to be able to proofread. I had a properly sized window until a few minutes ago, when I started a new page without window resizing. This problem exists on other Wikisource projects in their Page namespace equivalent as well, not just here.

Well, works now, so nothing more to say I suppose.

@Samwilson The changes introduced in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ProofreadPage/+/1229438 to modules/page/ext.proofreadpage.page.edit.js, and more specifically

		// Initialize the height of the text UI to match what the resizing bar has stored.
		mw.hook( 'ext.WikiEditor.resize' ).add( ( resizingBar ) => {
			$editForm.find( '.wikiEditor-ui-text' ).css( 'height', resizingBar.getResizedPane().height() );
		} );

are breaking proofreadpage editing layout in at least some situations. It adds a very low height constraint (in my case 448px), which makes it impossible to see the whole image:

Deployed.

Deployed.

@Fnexy : This is not enough information for us to do anything.

Indeed, that, and we removed a user parameter that is I think still used, and we had a problem with slash support.

Errs as 404, probably we broke the deletionsummary routing. Looking into it.

@Kallichore It's been fixed already, just gotta deploy the change.

Don't intend to work on moving to -s everywhere in the near future.

Had to be undone because of mistake, to be redone.

Been deployed for a while I think?

Indeed.

(Typo of loadinganimation for loadingAnimation.)

@Stephan.Klage : this is (by far) not enough information to be acted upon. At least provide the URL you got the error on.

Gah, we'll have to go for - I suppose. AFAICS only 2 tools are affected for now: pages & globalcontribs. I've done it in #593. @MusikAnimal : Could you take a look? (Side note: beyond this issue the pagination in PC has issues; like no "back" buton; but that's a question for later). (Also, it appears that CI is broken again).

After some digging, it looks like up to https://github.com/TecharoHQ/anubis/pull/1155 (which was pushed on Sept 27, so about two months after we added anubis), anubis always redirected multiple slashes! That was fixed in v1.23, but there's a good chance we still have the old version.
@MusikAnimal : please tell me we're currently running on <v1.23 so we can finally get rid of this issue; and if so, could you please try and upgrade it?

Fix deployed.

Thanks for the report! looking into it.

Fix merged, will go live next deployment.

Deployed.

Fix merged (what was I thinking? I *think* I remember testing back then. But anyhow). @MusikAnimal : could you deploy that please?

Working on it.

I've temporarily commented out our two uses to prevent all the prod crashes.

Uh-uh, based on the 30 failmails with Unknown column 'revs.rev_sha1', I think we're too late on this one.

Thanks for the report!
We had a too greedy regex. Fix merged, will go live next deployment.

Pretty sure this is the same issue; triple-slash redirected to simple slash (here redirected to https://xtools.wmcloud.org/globalcontribs/NguoiDungKhongDinhDanh/all/2025-10-22T20:53:29Z, which is a 404 for the same reason as on the other side).

Quick testing (1, 2) suggests that the time to join on slots and content etc is negligible; I'm getting about the same run times by doing that as by fetching revision.
Plus, losing revert detection for the crushing majority of edits (2020 is pretty recent) would be a shame. It'd be nice if the tag was retroactively added, but it looks like that's not planned.
(Oh my, they said "in three weeks" on Oct 3, which means we likely have only a few days to fix it.)
Also, on revert implementation: would it be unreasonable to look for more than 1 sha1 back? MW does 15.

Noting for reference that in the end we do have access to information_schema.tables, which makes our life tremendously easier.

Done better by Musikanimal in #571.