@suffusion_of_yellow - It looks like we may have a fix for this issue. If possible could you use the build listed below and try to see if this problem persists on the build?

https://releases.wikimedia.org/mobile/android/wikipedia/stable/wikipedia-2.7.50358-r-2021-05-11.apk

Thanks!

I tried on a few random IPs, and most of the time I saw a (correctly parsed) block message. But once I saw a message claiming that my user account had been blocked. No, I didn't write down the IP; sorry.

Is there some way to convince the app to connect to https://test.wikipedia.org? That would make testing this much easier for me, since I'm not a admin on my home wiki. But I don't see it in the language list, and when I try follow a link from the app to test.wikipedia.org, it opens in the browser.

@suffusion_of_yellow To be able to connect to testwiki, follow these steps:

• Enable Developer mode in the app (go to Settings -> About, and tap the Wikipedia globe logo seven times)
• You will then be able to add "Test" as one of your languages in the app, and then select it as your search language when searching.

So it seems that the only kind of block that gives me any details is a global block:

All tests done on testwiki, with the app version linked above. See my logs for the IPs involved.

@suffusion_of_yellow I'm able to reproduce your test cases, and it looks like this is another limitation of the API: all of the messages you see are in fact coming from the API response.

In the case of a local block, the API returns a generic message of You have been blocked from editing, but it does also return a structured json representation of the block information, which we are currently ignoring (since we're relying on the parsed message from the API). It seems that we'll need to parse that data ourselves and transform it into a similar message to what you see on desktop.

I'm putting this task back into Doing, and we'll see if we can add some manual parsing of the block info structure.

@suffusion_of_yellow The updates in today's alpha should improve the behavior for this and T276147. Please check it out when you can.

Tested in 2.7.50359-alpha-2021-05-27 on testwiki

The block reason is there now, but not parsed. The reason I used was [[foobar]] {{Uw-nothereblock}} and that's exactly what I saw; there was no link to foobar, and the template (which exists) was not expanded.

User and IP blocks and not distinguished (even when logged in from a hardblocked address), and partial blocks are no longer shown as partial. It's just "Your username or IP address has been blocked" followed by the unparsed reason.

There also a link at the bottom to contact the blocking admin, but there's no way to do that without evading the block. There should be a link to the blockee's own talk page instead; which is possibly the only page they can edit.

In T276149#7121405, @suffusion_of_yellow wrote:

Tested in 2.7.50359-alpha-2021-05-27 on testwiki

The block reason is there now, but not parsed. The reason I used was [[foobar]] {{Uw-nothereblock}} and that's exactly what I saw; there was no link to foobar, and the template (which exists) was not expanded.

The API does not seem to provide us a parsed block reason.

User and IP blocks and not distinguished (even when logged in from a hardblocked address), and partial blocks are no longer shown as partial. It's just "Your username or IP address has been blocked" followed by the unparsed reason.

There also a link at the bottom to contact the blocking admin, but there's no way to do that without evading the block. There should be a link to the blockee's own talk page instead; which is possibly the only page they can edit.

The message that is shown now is modeled after the message shown on Test wiki. The message on testwiki doesn't seem to distinguish between user and IP blocks (it always says "Your username or IP address has been blocked"), and it has links to contact the blocking admin, not a link to the blockee's talk page.

I'm placing this task back in our backlog, while we think about more comprehensive ways of showing block messages.

! In T276149#7122539, @Dbrant wrote:

The API does not seem to provide us a parsed block reason.

The mobile web interface just uses an extra call to api.php?action=parse I think. See T261944.

The message that is shown now is modeled after the message shown on Test wiki. The message on testwiki doesn't seem to distinguish between user and IP blocks (it always says "Your username or IP address has been blocked"), and it has links to contact the blocking admin, not a link to the blockee's talk page.

Indeed, it seems the default MediaWiki:blockedtext message does include that bad advice. It's customized on enwiki with some template magic that distinguishes between users and IPs, and includes enwiki-specific advice about appeals. Now I frankly don't know what the block appeal procedure is on all 700+ WMF sites, so would it be possible to allow individual wikis to override the app's message, too? Does the app draw any of its message from MediaWiki: namespace, the way the web interface does?

@suffusion_of_yellow Today's alpha version contains updates that I believe should solve the remainder of these issues. The app will now read the local wiki's MediaWiki:blockedtext message, and explicitly parse the block reason and inject it into the message. The only limitation is the kind of styling that we can apply to the message, since we're limited by our native components' capabilities for displaying arbitrary html. Nevertheless all the relevant information and links should be there.

@Dbrant: That link is a 404 but I tested on 2.7.50362beta-2021-06-04, which is the latest on https://releases.wikimedia.org/mobile/android/wikipedia/betas

The block message is still unparsed, and I'm not seeing anything I put at MediaWiki:Blockedtext. I tried with a copy on enwiki's blockedtext, and also with a very simple message with no style.

@suffusion_of_yellow Whoops, sorry about that -- the same link to the alpha version should work now. This sometimes happens when Github has a hiccup with our CI pipeline.

(All this also applies to T276147. Only responding in one place.)

Ok, getting there! Now the block is message is parsed. But:

1. All the links in the message (on testwiki) go to enwiki instead. I don't know if that's a testwiki-specific problem; it might take me a while to find an admin on a non-English wiki to block me but I can look for one if you like.
2. The links open in the browser, not the app. This might be because I have Firefox set as the default for wikipedia.org links, but if I'm following a link from inside the app, it should obviously always open in the app.
3. The message seems "stuck" on an old version of MediaWiki:blockedtext. Deleting the page, recreating the page with different content, re-blocking with different settings, logging in, and clearing the app's data do not fix this. Are you fetching that page from the REST API? That's notorious for caching issues.

Great, thanks. To address your points:

1. This is somewhat of a limitation of our low-level network handling at the moment: if the links in the error message are relative URLs, they are assumed to be relative to the first language wiki that you have selected in the app. So if you have { English, Test } selected in the app, then the relative links in the error messages will be assumed to go to enwiki. This isn't ideal, but it will require a slightly deeper refactor. (and most app users don't have more than a single language selected.)
2. Another limitation I'm afraid we'll need to deal with for the moment: The way the app is structured, if we ask it to load an article, it will close any modal workflow that was currently open. For example, if you were in the Editing screen, and then tap on a link that causes a new article to be displayed, it will close the Editing screen and not allow you to go "back" to it. Therefore, for the time being, we need to bounce these links to an external browser explicitly.
3. I am using action=parse to get the contents of the MediaWiki:blockedtext page, not the REST api. But again note that we're getting MediaWiki:blockedtext from the first language wiki you've got selected, due to the same limitation as #1.