Current screenshot, September 2024.

I should have been able to shorten the url as normal.

This is by design. Blocked users are not allowed to do this action.

The fix for this causes T372569.

You're welcome Sam.

Thank you for the details.

@RamzyM-WMF Can you add more info about what exactly to modify? For instance to add additional question or a particular checkbox. It's not currently clear what to do from the request

So you do not see the contradiction in what you're saying? Fine

In T368166#10157331, @stjn wrote:

In T368166#10157198, @Ammarpad wrote:

Or to make [[link]] less link-y and behave like {{Tl}}?. I honestly think that's better, but not blocker to this enhancement

Making link area smaller is generally never a good idea, so I don't think this is a good idea either. I wasn’t suggesting it to be a blocker.

In T368166#10130709, @stjn wrote:

In T368166#9914943, @SD0001 wrote:

https://patchdemo.wmflabs.org/wikis/66b1838f1a/wiki/Main_Page and https://patchdemo.wmflabs.org/wikis/66b1838f1a/wiki/MediaWiki:Gadget-abc.js show this working.

Would’ve been a bit more consistent to make {{Tl}} the whole link, too. Though I understand it might’ve been just replicating how CodeLinks does it.

In T343667#10017381, @kostajh wrote:

Duplicate of T267477: CannotCreateActorException when renaming the currently-logged-in user?

Yes it is.

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

If a file was uploaded correctly the API should always respond with:

{'upload': {'result': 'Success',...

Yess... until there's an error when sending the success response itself

Do you know why it affects only Citizen skin? Other skins seem to work fine

I had to hide these links for my account several years ago because of how distracting it was (to me). Good to see this is being moved to a better place.

In T53540#3216534, @Catrope wrote:

If you create the notification on meta, then cross-wiki notifications will ensure that the user still sees it, but it will appear to come from meta, which may be confusing.

I think this would be better than the status quo and it seems it's clearly easier/less effort to do than the perfect solution.

LanguageNameUtils::isValidBuiltInCode() is badly named. It does not actually do what its name says and ResourceLoader relies on it too much to prevent issues like this, cf. T64849

bring feature parity with local blocks,

Is this a part of some larger work/goal? Either way this task does not state why that'd be useful, and it should. Parity on itself should not be a reason. I said this because I'm struggling to understand how globally blocking a user from all – say portal – namespace across all wikis would be useful.

In T374064#10120332, @Ammarpad wrote:

The actual global block log shows it with the correct timestamp: https://meta.wikimedia.org/wiki/Special:Log?type=gblblock&page=188.212.100.0/22.

Seems to be because that's done by core log formatter.

The actual global block log shows it with the correct timestamp: https://meta.wikimedia.org/wiki/Special:Log?type=gblblock&page=188.212.100.0/22.
So presumably it affects only the log extract shown somewhere else.

I suppose it just needs to be excluded from this check.

In T326058#10108167, @Bugreporter2 wrote:

But that assumes that the welcome patch would fix everything, which I doubt it would.

I don't think this task should be a parent with these subtasks, because it implies the need to devise individual solutions at different places and pages (for each subtask). All these subtask should be merged here. The change needs to happen at only one place in core if desired.

For comparison, Page watch feature retains both pages (since old page may not necessarily become a redirect, although that's the common case). I think for Topic subscription it's sufficient to just move subscribers to the new page or it should do both for parity with the Page watch and user expectation.

Yes, sorry I am busy IRL and forgot about this. Anyone should feel free to pick it up.

The documentation is correct, and I think the change applied is correct too.

The hide-if statement of reason field is commented out as we can't figure out how to hide it if gfw is empty. We would like assistance to set up that parameter.

hide-if logic does not currently support multi-value fields, so it cannot be used with gfw field

OK, that's fine

@Bluetube11 That's a lot of IP addresses with these ranges.

I think it's already configurable. You can point the link to any local page via MediaWiki:Helplogin-url.