Moving back to in-dev to fix up the expiry field handling.

Thanks for the PR. I've merged it.

I could be looking at the wrong design in the link above, but is there meant to be a pipe between the two links?

As a short-term workaround we can fix the font-size just for Special:Block. This means adding a fix in core for something that belongs to an extension, but it's not a big thing and we can remove it later.

Okay, I think this is actually fixed this time! Sorry for the to-and-fro. The way the edit and remove links work has changed now, and there's no menu. Instead, each is just a link. The edit link is not linked to anything, because editing happens in the form, but the remove link is still a link to Special:Unblock and so should update appropriately. I've tried reproducing this bug, and can't, but then I was obviously doing something wrong last time so I don't know. :-)

https://ocr.wmcloud.org/ is updated to 1.6.4 with Madurese support. (It's not really support, it's "mapped to another language code or mapped to a general character recognizer" but still at least is presumably mapping to a more useful model than the default.)

Thank you for tagging this task with good first task for Wikimedia newcomers!

I've tested the above image and the test passage looks to get è now but not ḍ (and are there any ṭ there?)

Sorry, scratch my last comment, IP ranges do work, e.g.: https://commons.wikimedia.org/wiki/Special:Contributions/78.135.181.142/16

It looks like Google supports Madurese, so this should be a matter of adding the config for that, and then selecting it when proofreading.

There are still more bits for review, sorry. :-)

@HMonroy A follow-up might be needed, to not show the contribs link for IP ranges (SpecialBlock.php currently only shows it if target is a UserIdentity).

(Copying my comment from Gerrit to here.)

I definitely would discourage forcing this step when a username is already provided.

(Moving back to in-review as there are more patches for review.)

The same applies for "There is a new feature that allows you to issue multiple blocks against a single account" which would read fine as "…a single target".

I think this is all done, and backported to 1.43.

We talked a bit the other day about how to interpret having both a user and blockid param, and I think we decided to throw an error if both are provided. The description currently says "No need for a username/ip", but I don't think we want to support changing the target of a block, so I'll change that.

I am not sure if we have progress on getting a wikidata sidebar link?

It looks like this bug is T379947. We can add a workaround for Special:Block for the time being, until that's resolved.

I think this is coming from MobileFrontend, where it's setting font-size: 0.9em — and we're nesting fieldset elements, making things even smaller. Similarly for legends, which are set to 0.8em. Perhaps these shouldn't be set in ems? Codex sets things in rems, and core in mediawiki.skin.defaults.less provides variables to use (but I assume there's a reason MobileFrontend isn't doing this).

Another PR, for fixing the above name error and switching to route attributes: https://github.com/wikimedia/ToolforgeBundle/pull/70

Done and released in 2.5.3.

Done and released in 2.5.3.

Thanks for the PR!

Another issue when upgrading:

Thanks @AS1100K, manually mentioning PRs is the correct way to do it now. There's no automatic tracking of GitHub PRs here; that only works for Gerrit and Wikimedia's GitLab (the latter we do intend to migrate to at some point: T324410).

This looks like it was fixed as part of T379162, where the target field was changed to treat blur as the same as selecting a value from the dropdown.

In T379966#10330020, @JJMC89 wrote:

In T379966#10329984, @Samwilson wrote:

(Note that it is the block (or rather, a part of the block's log entry) that is suppressed, not the user.)

Users are suppressed by (re)blocking them with hidename selected (requires the hideuser right). This results in the log entry being in the suppression log instead of the block log and hides the user(name) from most contexts on the wiki - their contributions and log entries, user lists, and user selection fields on forms.

It looks like things are working again! Uploads started working on 16 November.

(Note that it is the block (or rather, a part of the block's log entry) that is suppressed, not the user.)

Worse than just not having an uppercase initial letter, the suppress log types were not being localized at all.

Moving back to development, to fix the issue where not all log entries are shown if there are more than 10 and some are not block or reblock.

Jason Scott has suggested that the IA could be blocking us, so I've emailed info@archive.org to see if there's anything that can be done. I wouldn't be surprised if the Toolforge IPs have been blocked, considering they must see somewhat higher traffic from them. It sounds like IA is still in recovery mode, so we should be patient.

❌ AC5: Confirm that "Autoblock any IP addresses used" option is shown. "Autoblock any IP addresses used" is not shown as seen in screenshot

But I still think it's a bit confusing to show "change block" and "unblock" next to block entries that have already expired.

letype=suppress will not just include blocks. It will also include things like suppressing a page. If you suppress the page User:<target>, in Special:Block/<target> the Suppressed blocks table will include a row for the suppression of that page.

and to show Active Blocks even when multiblocks is not enabled