Soft blocks are created like so:
```
$block = new Block( [
'address' => $ip,
'byText' => 'MediaWiki default',
'reason' => wfMessage( 'softblockrangesreason', $ip )->text(),
'anonOnly' => true,
'systemBlock' => 'wgSoftBlockRanges',
] );
```
On https://en.wikipedia.org/wiki/MediaWiki:Softblockrangesreason the custom message uses table wikitext markup.
The mobile editor before launching will check the 'blockinfo' state of the page using:
https://en.m.wikipedia.org/w/api.php?action=query&format=json&prop=revisions&rvprop=content|timestamp&titles=Offset_printing&meta=userinfo&uiprop=blockinfo&formatversion=2&rvsection=0
The mobile editor when it encounters such a block will attempt to render the blockreason for the block in JavaScript. To do this it currently uses the jQuery message parser, assuming the message is simple. It does so like this:
```
parser = new mw.jqueryMsg.parser();
ast = parser.wikiTextToAst( blockReason );
```
This throws an exception on the softblockrangesreason message - see T191470#4108889
This is particularly problematic on API based clients such as apps and mobile web and means we cannot render blocks.
= Possible solutions
* Provide HTML in the blockinfo API responses or have a way for clients to render these blocks. T191558 & T194530
* Make a request to [[ https://www.mediawiki.org/wiki/API:Parsing_wikitext | API:Parsing_wikitext ]] to parse the wikitext on the server.
* Limit the wikitext that can be used in a block message inside the Block class. Forbid the use of tables.
* Upgrade jQuery msg to be able to handle more types of wikitext.
* When blockinfo has a recognized `systemblocktype`, ignore the reason field in favor of some custom logic.