It now looks like this:

I agree.

Is this something that should be considered for GlobalPreferences as well?

@Quiddity that's true. Although, then they'll still all look the same. Or are we allowed to change their colour (I guess doing so is possible with OOUI)? I'd have thought not.

Like this?

The appearance of the orange (or white-on-blue) checkboxes are down to different browsers and operating systems, unfortunately (e.g.). They're all just native checkboxes and so there's not all that much we can do with them.

I'm not sure if it's related to this, but I'm not able to close T176298; there's no status field. (It's the first time I've seen a 'bug' task, so perhaps I'm missing something; maybe only the assignee can close it or something?)

Thanks @Nikerabbit, make sense.

That's not the same issue. That one's about the fact that the status colours are not being loaded on Index pages; it's being tracked as T114318.

This is a bug with old XTools. The equivalent query on new XTools is https://xtools.wmflabs.org/ec/sr.wikipedia.org/Zoranzoki21?uselang=sr-ec which is also full of English strings! :-( Can you help?

Ok, we'll just remove the comments from the code, and stick with a single user right.

Is this just because Vector hasn't tagged any stable version yet?

This is one of the problems that composer.lock is supposed to fix, because then all dependencies are locked to a specific commit and cannot be changed. The other part of that idea is that one should never run composer update in production, but only ever composer install.

The URL of the thumbnail:

Chunked uploading docs: https://www.mediawiki.org/wiki/API:Upload#Chunked_uploading

I've changed the title of this task — do you think that sounds okay? It's not a massive task, perhaps, but a pretty big new feature I think. Probably needs more discussion about quite what the goal is here.

Sorry for the delay in responding to this! (I only just saw it, I'm not sure why it didn't notify me.)

Yeah I wondered about that. Purple looks a bit like a visited link (but better than blue I think):

Cool! The patch above is ready for review then.

Should the text between the braces in { Syntax Highlighting } be all-blue or all-black?

The form is currently looking like this:

I've switched ws-cat-browser to use wikireplica-analytics.eqiad.wmnet and all seems great.

How important is it that the GlobalPreferences checkboxes for BetaFeatures are OOUI?

No, sorry, what I was getting at is that you have to examine the X-Forwarded-Proto header, rather than the port number, because all requests come in on port 80 from the proxy (because we can't see the original request, for privacy reasons).

This is what's done in IA Upload:

Yeah, good point about being less to maintain. A help page is likely to be forgotten about.

Thanks @RobH and @Legoktm! All looks good now.

Cool, thank you!

Patch looks good to me. The OOJS stuff can be tackled in the UI work of T68869.

Personally, I don't think core needs a new preferences tab. Could it perhaps be enabled optionally, or by checking for the existence of Echo?

I've updated the patch to show spinners within (at the right end of) the project, user, and page name fields, and removed the spinner from the namespace dropdown (because it's the change in the project input that makes that happen, so that's where the spinner is now).

What happens in the situation on a farm when different wikis set different defaults for their preferences (via $wgDefaultUserOptions)? If a preference is global-only, what is its default value?

This will no longer be required after T173476, because we'll override the Preferences class and so can inject things to Preferences::getPreferecnes().

Is this the same as T174201: The order of messages "Codemirror-popup-syntax" and "Codemirror-popup-highlighting" should not be hardcoded ?

What about sort of combining the back link with the form section header?

As the first part of this, I've added a new hook to core, called PreferenceFactory'. This will mean we can replace the Preferences` object that's used by SpecialPreferences with our own LocalPreferences object, and so do whatever we want (i.e. modify the form and the preferences list appropriately).