FYI @TBolliger since AHT worked on this feature

Yeah, those are some improvements we should make. If it's an IP address/range block it should probably say "You have been blocked."

Listing the original block target was omitted simply for lack of real estate. We need to also solve for T189717 which is a real estate issue.

In T210273#4774875, @TBolliger wrote:

If it's an IP address/range block it should probably say "You have been blocked."

Actually it would be preferable to make it clear that a block for an IP address/range is not necessarily aimed at the user seeing the block error message, by saying "Your address" instead of "You".

Potential design for the link:

Sydney — we'll want to ask volunteers to re-translate the string

@TBolliger Is the user's talk page the best page to link to? As far as I can see, it doesn't contain block information in mobile frontend, and it only contains block information on desktop if you go to the edit tab... Unless I'm missing something!

Change 489099 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/extensions/MobileFrontend@master] WIP Changes to block message drawer

https://gerrit.wikimedia.org/r/489099

Doh! I meant Special:MyContributions, which should display the information about the IP or user.

@TBolliger Ok, that makes sense! The block details are present in the desktop version, but they still don't seem to be there in mobile frontend:

Destop	Mobile frontend

What do you think we should do? We can still add the link, then file a task to show the block details in mobile frontend, or link to somewhere else, or not have a link? The WIP patch currently has the link and looks like this:

I wasn't sure about lengthening the "OK" message on the blue button, given the narrow width of the screen and possible longer translations in other languages. Perhaps @Amire80 has a opinion?

Can we link to the block log like this?
https://test.m.wikipedia.org/wiki/Special:Log?type=block&page=Koavf

Also, I think the text should be "More info" rather than "Need help?" and I think it's fine to add the link to the right there seems to be plenty of space? or am I missing something?

or even better might be to link to the block list... it looks kinda gross right now, but it at least lists the currently active blocks:
https://test.m.wikipedia.org/wiki/Special:BlockList?wpTarget=185.220.101.31

In T210273#4938231, @Tchanders wrote:

I wasn't sure about lengthening the "OK" message on the blue button, given the narrow width of the screen and possible longer translations in other languages. Perhaps @Amire80 has a opinion?

Thanks a lot for asking!

No, I don't see a problem here at the moment. OK is a common button on all platforms and it has standard translations in many languages, e.g. here.

If there will be a problem, the translators will complain ;)

In T210273#4938269, @Amire80 wrote:

In T210273#4938231, @Tchanders wrote:

I wasn't sure about lengthening the "OK" message on the blue button, given the narrow width of the screen and possible longer translations in other languages. Perhaps @Amire80 has a opinion?

Thanks a lot for asking!

No, I don't see a problem here at the moment. OK is a common button on all platforms and it has standard translations in many languages, e.g. here.

If there will be a problem, the translators will complain ;)

Thanks @Amire80 - sorry I wasn't clear with my question! The button currently says "OK" but there is a suggestion to change it to "Got it" - I'm worried that the translation of "Got it" might be too long in other languages?

...An additional concern might be that someone who is using English but isn't that confident in English might not understand "Got it"?

In T210273#4938271, @Tchanders wrote:

suggestion to change it to "Got it" - I'm worried that the translation of "Got it" might be too long in other languages?

This was intentionally changed to "OK" after the mock up was created, I don't think there is any intention to change it back.

In T210273#4938271, @Tchanders wrote:

In T210273#4938269, @Amire80 wrote:

In T210273#4938231, @Tchanders wrote:

I wasn't sure about lengthening the "OK" message on the blue button, given the narrow width of the screen and possible longer translations in other languages. Perhaps @Amire80 has a opinion?

Thanks a lot for asking!

No, I don't see a problem here at the moment. OK is a common button on all platforms and it has standard translations in many languages, e.g. here.

If there will be a problem, the translators will complain ;)

Thanks @Amire80 - sorry I wasn't clear with my question! The button currently says "OK" but there is a suggestion to change it to "Got it" - I'm worried that the translation of "Got it" might be too long in other languages?

This is also pretty OK. Here's an example with quite a lot of translations:
https://translatewiki.net/wiki/Special:Translations?message=MediaWiki%3ACx-campaign-ok-got-it&namespace=8

Whether you actually use it here is up to you. I'm not sure that it's appropriate; "Got it" sounds lighter and goes well with tutorials or constructive actions, whereas blocking may be less pleasant and justify a more neutral language. But as far as general localization concerns go, it's not bad.

Let's leave the button as "OK" per previous discussions.

I agree with David's suggestion of https://test.m.wikipedia.org/wiki/Special:BlockList?wpTarget=foobar

Change 489312 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/core@master] Make Special:Myblocklist redirect page

https://gerrit.wikimedia.org/r/489312

@TBolliger @dbarratt Thanks, have updated the URL to Special:BlockList. The patch passes in the block ID param rather than the target, since the user attempting to edit might not be the target - e.g. if it's an autoblock or an IP range block.

Change 489312 abandoned by Tchanders:
Make Special:Myblocklist redirect page

Reason:
Filtering by block ID instead of target in Icda4b8

https://gerrit.wikimedia.org/r/489312

In T210273#4943629, @Tchanders wrote:

@TBolliger @dbarratt Thanks, have updated the URL to Special:BlockList. The patch passes in the block ID param rather than the target, since the user attempting to edit might not be the target - e.g. if it's an autoblock or an IP range block.

Perfect! Great work. 🚀

Change 490615 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/core@master] Add block ID query paramater to Special:BlockList

https://gerrit.wikimedia.org/r/490615

Change 490615 abandoned by Tchanders:
Add block ID query paramater to Special:BlockList

Reason:
Using wpTarget=#ID in Icda4b8 instead - thanks Dbarratt

https://gerrit.wikimedia.org/r/490615

Change 489099 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Make block message drawer more informative

https://gerrit.wikimedia.org/r/489099

Beta-cluster is currently read-only and test.wikipedia.org has an older version of MobileFrontend, so had to test on my local version:
MediaWiki 1.33.0-alpha (2e9c34c) 19:31, 14 February 2019
MobileFrontend 2.1.0 (a9a81ec) 17:22, 14 February 2019

But does not have VisualEditor. I don't know if that makes a difference. The pop-up occurs on the page before you get to the editor, so I guess not...

Sufficiently long blocking reasons can mean the top of the pop-up gets cut off (if viewport is small, i.e. on a small mobile phone). Not sure how likely that is, or if it is a major problem.

I notice many blocks on en.wiki use Templates. These don't work in the pop-up (appear as "{{templatename}}"). Perhaps to be expected. Side-effects of supporting templates probably too great. This way I guess is safer.

Otherwise, blocks of usernames and IP addresses (including auto-blocked IPs) appear with the correct reasons, correct expiry (if applicable) and show the correct block when you click "Details".

I saw this on Chromium with responsive design view and also on a Samsung N2, and it responds fine to changing orientation.

If a user is already part-way through editing a page when an admin blocks them, they get an error: "Error, edit not saved." with no other details. I will raise separately.

In T210273#4957523, @dom_walden wrote:

But does not have VisualEditor. I don't know if that makes a difference. The pop-up occurs on the page before you get to the editor, so I guess not...

Yeah you should get to it before that point.

Sufficiently long blocking reasons can mean the top of the pop-up gets cut off (if viewport is small, i.e. on a small mobile phone). Not sure how likely that is, or if it is a major problem.

I'm not sure, probably a good question for @TBolliger

I notice many blocks on en.wiki use Templates. These don't work in the pop-up (appear as "{{templatename}}"). Perhaps to be expected. Side-effects of supporting templates probably too great. This way I guess is safer.

T191939: How to deal with blocked messages on client that require advanced parsing?

If a user is already part-way through editing a page when an admin blocks them, they get an error: "Error, edit not saved." with no other details. I will raise separately.

That's interesting.

Ugh, templates for block reasons. Such a pain, and a tax that someone someday will have to pay.

If you can provide a screenshot of the pop-up cutting off on small viewports, I'd appreciate it. We can probably truncate the block reasons as a certain number of characters/lines. It should also be straightforward for us to calculate a distribution of block reason character counts to help determine how severe of a problem this is.

In T210273#4957732, @TBolliger wrote:

Ugh, templates for block reasons. Such a pain, and a tax that someone someday will have to pay.

If you can provide a screenshot of the pop-up cutting off on small viewports, I'd appreciate it. We can probably truncate the block reasons as a certain number of characters/lines. It should also be straightforward for us to calculate a distribution of block reason character counts to help determine how severe of a problem this is.

This is what it looks like (according to Chromium and Firefox's responsive design view) on the iPhone 5. The bit that tells the user "You have been blocked from editing $wiki" is cut off. This is an extreme but real life example from en.wiki.

Happens on view ports of that size (320x568) when the block reason goes over about 410 characters. Querying the replica table enwiki_p.ipblocks_compat only 6 of 1174140 have block reasons longer than this.

In T210273#4957593, @dbarratt wrote:

In T210273#4957523, @dom_walden wrote:

If a user is already part-way through editing a page when an admin blocks them, they get an error: "Error, edit not saved." with no other details. I will raise separately.

That's interesting.

I think the MobileFrontend only handles a few error conditions helpfully, and otherwise just shows a generic error (ref: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/MobileFrontend/+/master/src/mobile.editor.overlay/EditorOverlay.js#613). We could ask that blocks be handled more gracefully.

I've created T216533: Mobile web "you are blocked" notice should truncate long block reasons to document the long block reason. Not worth addressing for now.

I think we can ignore the use case of "blocked while editing" for now — there are several teams working on improving mobile editing, so these features/technologies are constantly evolving.