I note that in T302623#8566372, it is clear that there is an intention to phase out PHP session handling. This seems like a hard blocker right now.

Just wanted to add an external voice to this task - we (at Weird Gloop) are observing "Math extension cannot connect to Restbase" on a regular basis on our hosted wikis (example link). $wgMathFullRestbaseURL hasn't been changed, so we're using Wikimedia's Restbase API for our rendering. We're considering running our own Restbase server if the instability seems to be related to WMF's infrastructure, but if there's a core issue with Restbase/the Math extension then this wouldn't do much for us. We'd also not really like to support Restbase going into the future, given that WMF is deprecating it.

Now that Turnstile is generally available, I've pushed a patch that implements it into ConfirmEdit. The code for it is very similar to ReCaptchaNoCaptcha, but I felt uncomfortable with inheriting anything from ReCap's classes given that it does have a couple of (mostly server-side API) differences, and T324925 would do a better job at genericifying JS-based captcha implementations. I tested the code on MediaWiki 1.40 across account creation, source editing, and visual editing.

Just adding my two cents here that as an external wiki farm, we'd also like to see user renaming support wiki farms properly, especially now that it is integrated into core. We use a fork of the Renameuser extension, but to upgrade to 1.40, it means that we're likely going to have to make patches to the core implementation instead.

Is there any interest in backporting the fix for this issue to 1.40 once reviewed & merged? I'm not sure if there's a formal process for requesting that, but it is seemingly likely to cause issues on more external MediaWiki installations than just ours.

In T341435#9015002, @Func wrote:

$wgHiddenPrefs[] = 'skin'; seems very broken, other skins would still register their features and preferences if they are not uninstalled.
How skins are managed in your setup? Are there any difficulties with simply only install the wanted skin and not using $wgHiddenPrefs?

I made an account on the beta cluster - this is how the page looks to me with JS disabled.

Hey @Jdlrobson, I just had a look at the page you linked on the beta cluster but I don't actually get the same as you when JS is disabled. However, I'm not logged in, so I'm wondering if that makes a difference in what you see on that page. Maybe try with an incognito window/logged out? (or maybe there's some other variable at play here)

In T336987#8888656, @abi_ wrote:

In T336987#8885001, @JaydenKieran wrote:

In T336987#8882370, @abi_ wrote:

In T336987#8871291, @JaydenKieran wrote:

@abi_ Hey! Translatewiki should have a pending invitation for the repo at https://github.com/jayktaylor/mw-discord/invitations.

Thanks accepted.

Thanks - although weirdly, GitHub seems to indicate that this is not the case (and the invitation has disappeared). Let me know if you need me to send it again. Cheers!

Hmm, you are right. The invitation seems to have disappeared. I'm not sure. Can you resend the invite again? Thanks.

Another request, can you update the documentation for messages like discord-blocktimeformat(https://github.com/jayktaylor/mw-discord/blob/master/i18n/en.json#L24) that use the PHP date time format, to link to the PHP documentation? That should make it easier for translators to understand what each character/symbol does.

FWIW, ?action=purge on https://en.m.wikipedia.org/wiki/Korean_drama appeared to fix the issue on that page for me.

I'm assuming that the full-width toggle is supposed to be hidden when JavaScript is disabled because that's what happens if you just visit other pages (like article pages, or user preferences)

In T336987#8882370, @abi_ wrote:

In T336987#8871291, @JaydenKieran wrote:

@abi_ Hey! Translatewiki should have a pending invitation for the repo at https://github.com/jayktaylor/mw-discord/invitations.

Thanks accepted.

Is there a reason that "will not be carried over" is used here instead of "will not be attributed"? I'm a native English speaker so I can't really speak for those who have it as a second (or third) language, but it seems like it makes sense to remove any potential confusion and ambiguity with the wording - especially for those people. Obviously this isn't just limited to the mobile site/app, but I'm not sure where else this is being discussed.

@abi_ Hey! Translatewiki should have a pending invitation for the repo at https://github.com/jayktaylor/mw-discord/invitations.

In T332805#8857049, @Milimetric wrote:

Is anyone talking/thinking about how these names are going to look in regular use? I was reading the updates here and couldn't help but think about a discussion thread or revision history where you might see activity from different temp users and accidentally group it together, like:

• <<Totally nice reasonable thing>> ~~~~ !2023-12345
  • <<Really Nasty Mean thing>> ~~~~ !2023-12355
    • Hey, @!2023-12345 this is your last warning before we block your account ~~~~ SomeAdmin

I wonder if some more randomness in the layout of the temp numbers would help, like !2023-12-355 and !2023-123-45

Looks like @Rxy has a revert patch here: https://gerrit.wikimedia.org/r/c/operations/puppet/+/535987/

I'd like to see this. We use CodeMirror (and LinkSuggest), but the latter doesn't work with CodeMirror.

I think that regardless of how effective CentralAuth's global locks are, implementing something in the GlobalBlocking extension that allows users to be blocked would be worthwhile, especially for independent wikis who don't utilize CentralAuth.

@Volker_E Well, anywhere that the help buttons are used in conjunction with a form, whether that be a custom gadget/script that utilises OOUI or an extension. Whenever I've used forms elsewhere (outside of MW), tab has cycled through each input on the page, not any guidance or help text. It's a slight annoyance from my perspective that there are extra key presses required to cycle to each input, especially when there is a form with a lot of inputs and each have their own help buttons.

@Volker_E Can we set the button to an access key instead to retain that accessibility? It just doesn't make a whole lot of sense to cycle to the help elements on tab, especially when you're trying to quickly fill in a form. Alternatively, another solution where we can keep this functionality but move it away from tab, as I know access key can behave differently per browser.