Page MenuHomePhabricator

Strikethrough blocked/locked accounts anywhere they are displayed
Closed, DuplicatePublic

Description

It would make the lives of admins, stewards, vandal fighters, abuse filter editors much easier if they could tell at a glance which users in a page history, abuse filter log, watchlist, or recent changes list have been blocked or locked. There is currently a client-side gadget on English Wikipedia that basically does this (https://en.wikipedia.org/wiki/MediaWiki:Gadget-markblocked.js), but it is slow and buggy since it has to make client-side API queries for all the users listed on a page (in batches of 50). It would be much better if this were handled on the server side and the blocked usernames were simply wrapped in a special CSS class. This would also make the feature possible on all wikis.

Open questions:

  • What sort of styling would be best? The markblocked gadget uses opacity: 0.7; text-decoration: line-through for temporarily blocked accounts and opacity: 0.4; font-style: italic; text-decoration: line-through for indefinitely blocked accounts.
  • Should this depend on a preference? If so, should it be on or off by default?

Event Timeline

A CSS class seems reasonable to me. I don't think a user preference is needed. The default styling (if any) can be overridden by users using user subpage CSS, but that seems like a very uncommon use-case that is not worth the Special:Preferences user interface clutter.

A) I strongly support the general idea (and I've used the Russian or English gadget for many years) -- it would be great to make this feature more efficiently implemented, and more widely available via CSS wrap. (The gadget is the ~30th most popular on the Wikipedias, per https://meta.wikimedia.org/wiki/Gadgets/wikipedia )

B) Using most of the current gadget's styling makes sense, and is consistent. (though it would also be good to check the local variations, to see if any of them use different styling.) But we'd need to remove the italic for languages that don't use that type of styling, or just not implement the italic nuance at all.

C) The gadget version has the block log summary as the tooltip, which can be very useful supplementary information. Would it be possible to add that feature to this proposal?

D) Would this function on talkpages like the gadget does, and if so might it cause any additional page-caching concerns? I.e. on long talkpages (e.g. archives, or admin noticeboards, etc), would it still work to render blocked-users' signature links with the strikethrough? and might that increase the rate of cache invalidation by any significant amount? (I assume it would work, and would not cause significant problems, because talkpages are mostly only seen by logged-in editors; but I figured I'd ask!)

E) However, I'll echo the concerns raised by PaleAqua during the Enwiki Gadget proposal discussion:

Only concerns I have is how increased ease of information on blocked users might impact wiki interactions. For example consider users that are mostly good editors that have crossed a line in a content dispute and rightly have been short term blocked for that, as a gadget such a block would be visible to a larger percentage of editors. Self-requested vacation blocks would show up as well. I slightly worry that on the average person seeing a blocked username might just assume that it means they are a vandal. I know the block log information is in the tooltip, but I can't imagine that is checked out often. Still I find it useful when I history dive articles to key in on changes to which to pay extra attention.

Hence I think we should further discuss about what configuration to use by default... I lean weakly towards: default-on, hidden-preference, not-shown-to-IPs. But it's worth asking others.

Note that https://meta.wikimedia.org/wiki/MediaWiki:Gadget-markblocked.js is also a Gadget on Meta, being the 9th non-default most used with 967 users so far according to https://meta.wikimedia.org/wiki/Special:GadgetUsage

I modified its parent task, T169461 to be a MediaWiki task, and not an AbuseFilter task (because we already know that in core and in CheckUser this feature is helpful and requested).

This task is effectively a duplicate of T169461 now, as the only "extra" thing it asks is for the said links (which will have a class) to have a strike-through appearance (which means it simple asks for a specific rule inthe CSS definition for that class). Am I misunderstanding, i.e. is it asking for anything more than that?

This comment was removed by Huji.