Page MenuHomePhabricator

API: Provide parsedtags information
Closed, DeclinedPublic

Description

As the developer of DannyS712-Global_watchlist.js, I want an option to, via the watchlist api, retrieve the parsed html of tags associated with an edit, instead of just the plain text

Use case:
Some tags render as links, and the features of the normal watchlist (including this rendering) should be available via the API as well

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

In SpecialWatchlist, tags are parsed via ChangesListSpecialPage::getChangeTagList
In ApiQueryWatchlist, info is retrieved from WatchedItemQueryService::getWatchedItemsWithRecentChangeInfo, and tags are processed with:

if ( in_array( self::INCLUDE_TAGS, $options['includeFields'] ) ) {
	// prefixed with rc_ to include the field in getRecentChangeFieldsFromRow
	$fields['rc_tags'] = ChangeTags::makeTagSummarySubquery( 'recentchanges' );
}

this rc_tags value should not be changed, since it should still be possible to get the unparsed tags associated with edits. I would suggest parsing the tags within the API.

DannyS712 moved this task from Unsorted to Next on the User-DannyS712 board.Nov 29 2019, 12:08 PM
Anomie closed this task as Declined.Dec 2 2019, 2:03 PM
Anomie added a subscriber: Anomie.

As the developer of DannyS712-Global_watchlist.js, I want an option to, via the watchlist api, retrieve the parsed html of tags associated with an edit, instead of just the plain text

The Action API normally does not provide UI HTML from general-purpose endpoints. It's up to the client to format the results as needed, using endpoints such as action=parse if necessary to produce HTML from wikitext.

Yes, some older endpoints do provide UI HTML. We're trying to move away from that.

DannyS712 moved this task from Next to Archive on the User-DannyS712 board.Dec 11 2019, 1:32 AM

Yes, some older endpoints do provide UI HTML. We're trying to move away from that.

@Anomie - I'm not sure I understand the reasoning here. Can you walk me through it? It seems to me like the vast majority of use cases for the API would prefer HTML over Wikitext, especially for things like comments and tags. Since we don't have a client-side parser, that means forcing them to do another round trip. Why do we want to do that?

In general in MediaWiki over the past few years we've been trying to move towards separation of concerns. Separating fetching of structured data from generation of UI HTML is one of those separations.

Producing HTML brings dependency on the parser, and on the current user's preferences. It also potentially brings a need for additional parameters to control parser options, and can result in bugs like T247661.

It seems to me like the vast majority of use cases for the API would prefer HTML over Wikitext,

That seems like a hard one to estimate. How much of the use of the API is for UI-generating gadgets and apps, versus bots and data access and scripts that add functionality rather than UI? My own guesstimate would be that bots (including various scrapers that never log in) make up the vast majority of Action API requests.

Since we don't have a client-side parser

mediawiki.jqueryMsg seems like it would probably suffice for turning the tag name messages' wikitext into HTML as requested here.

Producing HTML brings dependency on the parser, and on the current user's preferences. It also potentially brings a need for additional parameters to control parser options, and can result in bugs like T247661.

Thanks for that break down. I now understand much better why we're moving away from supplying parsed results.

That seems like a hard one to estimate. How much of the use of the API is for UI-generating gadgets and apps, versus bots and data access and scripts that add functionality rather than UI? My own guesstimate would be that bots (including various scrapers that never log in) make up the vast majority of Action API requests.

In my mind, things like HTML links and transcluded templates are more content than UI. I think it makes sense to have separation of concerns, but maybe we have different opinions on where the line of separation should lie. Regardless, it sounds like it would be tricky to fix this without causing other problems.

mediawiki.jqueryMsg seems like it would probably suffice for turning the tag name messages' wikitext into HTML as requested here.

That's true, and probably true for some other use cases as well. I'll see if I can help push things in that direction. Thanks.

Aklapper removed a subscriber: Anomie.Oct 16 2020, 5:28 PM