Page MenuHomePhabricator

API list=blocks should allow bkprop=parsedreason
Open, Needs TriagePublic

Description

Exactly what it says on the tin. I can get parsedcomments for almost every single revision and log entry module... except this one.

https://en.wikipedia.org/w/api.php?action=query&list=logevents&leprop=timestamp|ids|title|comment|parsedcomment|type&letype=block

Also, why is the relevant parameter called reason when almost every other module calls them comments?

Event Timeline

MER-C created this task.Apr 5 2018, 7:35 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 5 2018, 7:35 PM
Anomie moved this task from Unsorted to Needs Code on the MediaWiki-API board.Apr 6 2018, 1:08 PM
Anomie added a subscriber: Anomie.May 14 2018, 2:21 PM

See also T191939: How to deal with blocked messages on client that require advanced parsing?, there's already ambiguity between when a block reason should be interpreted as full-featured wikitext versus comment-style limited wikitext. In either case, action=parse already exists (use its summary parameter to parse as comment-style limited wikitext).

Personally, I'd lean towards deprecating and removing the "parsedcomment" properties from other API modules as well.

Also, why is the relevant parameter called reason when almost every other module calls them comments?

No idea. For edits it's referred to as "summary" in some places, for images it's referred to as "description", and for logging table entries it's "comment".

@Anomie: Can you elaborate a bit on the reasoning for moving away from supplying parsed comments in the API response? This seems like it would necessitate more round-trips for mobile clients which isn't ideal.

MER-C added a comment.May 15 2018, 7:08 PM

How would that interface with an API-driven frontend (T111588)? Getting a listing of contributions/log entries/blocks with 500 entries (therefore 500 parsed comments) would be a lot more awkward.

@Anomie: Can you elaborate a bit on the reasoning for moving away from supplying parsed comments in the API response?

I've somewhat talked myself out of the idea, at least for the "get a listing" use case @MER-C mentioned.

The underlying reasoning is that incorporating UI text into API responses tends to add complexity in accessing various user preferences and other options that alter the parsing, and the dependencies of the parser itself. On the other hand, neither of those are too bad for the "wikilinks and section links" version used for parsing log comments and edit summaries.

The underlying reasoning is that incorporating UI text into API responses tends to add complexity in accessing various user preferences and other options that alter the parsing, and the dependencies of the parser itself. On the other hand, neither of those are too bad for the "wikilinks and section links" version used for parsing log comments and edit summaries.

That makes sense. I think the best solution here is to limit block comments to simple summary parsing (i.e. links). People should not be putting tables and templates into block comments. If they need to include detailed information, they can link to a wikipage. Then we could provide the parsed block reasons the same as we do other types of comments.