@TBolliger shouldn't this be tagged anti-harassment? Sorry if I'm missing something. Are you looking for input specifically from @alexhollender ?

@TBolliger I'm still confused. This bug was raised by you and my team isn't planning to work on this but it's been marked as "tracking work by other teams". Please let me know if you're expecting something from us here.

I'm not expecting anything from your team and I cannot prioritize this for my team either. It sounds like neither team is planning on working on this in the foreseeable future. No surprise — it will require a lot of work to very little end-user benefit.

Thanks for the clarification @TBolliger ! understood! It will indeed!

Some possible ways to solve this:

1. Strip templates and/or comments
2. If the reason has a template or a comment, do not show the reason
3. If the reason has a template or a comment, replace with a "probable match" reason (e.g. {{spam}} to Inserting spam)

Comments should be stripped. If templates cannot be displayed, then a link to the user's talk page is better than nothing. Details won't always be on there though (e.g. IP range blocks).

Summarising my comments from T219661:

On Special:Blocklist we use the commit message parser which only allows links and comments:

{{echo|Template}} [[reason]] ''italics'' '''bold''' you're blocked! /* comment */

On desktop we use the full parser and this is widely used to show reason information. I suspect this was originally an accident as the field is a single line and limited by the same amount as commit messages (currently 500 chars), but given the communities now use this feature widely, it appears there is no going back.

It appears that the many users affected by T-Mobile range blocks, which of course will (for the most part) only affect mobile devices, are not able to see any of the helpful templates intended to be viewed in the block notice on mobile, because of this issue.

For example, instead of: https://en.wikipedia.org/wiki/Template:TMOblock
They see: https://pbs.twimg.com/media/EYA4F5AXkAA42k7?format=jpg&name=medium

To nearly all potential editors who view this message, the page and template links are meaningless, the message is meaningless and unclickable, and there's no apparent way to get around the block. This is an extremely pressing bug that should be fixed as soon as possible.

As @Esanders mentions in T189717#5070532, the bug is a result of an unintentional feature. A possible (but probably unacceptable) solution would be to remove the feature. A more likely solution would be to:

1. Update the info endpoint (with ApiBlockInfoTrait) to respect the errorformat parameter. T189717#6364215
2. In MobileFrontend request the blockreason in html format.
3. If the reason contains any block-level HTML elements then the we know it cannot be displayed in the drawer.
   1. Replace the reason with a "View Reason" link (or popup?) to a new Special Page (perhaps Speical:BlockReason/BLOCKID?) that outputs the reason. This page could also be used for transcluding a block reason somewhere else on wiki.
4. If the reason only contains inline elements the reason can be displayed in the drawer (we may want to add a way to truncate this and link to the details if it's too long)

A couple of other things from the perspective of the editing team:

1. This message is shown to a user who has expressed an interest in editing and, for these large range blocks, is likely not a vandal.
2. We tell the user "Your account has been blocked". This is confusing because they probably don't have an account and aren't signed in. This wording should be changed.
3. The only call to action is "OK" (aka "Oh well"). After this task is resolved there may also be a "See reasons/details" CTA, but as someone who just wants to edit, there should really be a direct CTA to get around the issue, i.e. "Create an account" (provided account creations aren't blocked as well).

To point (2) we should display messages like:

• "This IP address has been blocked from editing, but you can still edit by signing in or creating an account."
• "This IP address has been blocked from editing, but you can still edit by signing in." (if account creation is blocked)
• For hard IP blocks (where logged in users are still blocked because of their IP address):
  • "This IP address has been blocked from editing, but you may be to edit by signing in." (as they may still be able to edit if their account is exempt)
  • We should also avoid say "you" / "your account" if they are signed in and hard IP blocked.

To point (3) we can then either link the words "signing in" and "creating an account", or provide separate buttons at the bottom of the drawer.

To point (2) we should display messages like: ...

+1, these are great suggestions.

In T189717#6212341, @dbarratt wrote:

1. Update the info endpoint (with ApiBlockInfoTrait) to respect the errorformat parameter.

Since T191558 was declined it seems that using the Parse endpoint is more appropriate.

Alternatively, we could limit what can be provided in the block reason as suggested in T191558#4208848. @kaldari do you still think that would be a good idea?

@dbarratt - My idea would probably be controversial. Parsing the blockreason is probably easier.

In today's engineering meeting we discussed:

1. We should keep the drawer
   1. It should show a text version of the reason if its available.
   2. If a text reason is not available we'll show a link to see the full reason. We didn't decide whether the link will take the user to a new page or an expanded version of the drawer
2. The reason field doesn't always have a reason, for example the template for anonblock.
3. As @Esanders points out in his comment it is important to tell the user what actions they can take.

The actions that can be taken will depend on the block. Specifically the following properties of the block

1. Is it an IP only block or a hard IP block (even logged in users would be blocked)
2. Does the block not allow new users to create an account?
3. Is it a partial or a full block?
4. Is the user currently logged out?

We'll have to come up with messaging and actions for all permutations of the above properties.