Page MenuHomePhabricator

Comment (edit summary) parser option for API
Closed, ResolvedPublic

Description

Author: herd

Description:
Edit summaries (referred to as comments internally, see Linker::formatComment) have their own custom parser, which is possible to duplicate but rather annoying to get 100% correct (also, there are minute differences between versions of Mediawiki).

It would be nice to be able to parse edit summaries via the API in two methods:

  1. add comment= parameter to action=parse, spitting out <parsedcomment> with the HTML
  1. add &parsecomment to all properties returning unparsed comments, for example http://en.wikipedia.org/w/api.php?action=query&prop=revisions&titles=Foobar could have &parsecomment return: <rev ... comment="/* Examples */ capitalization" parsedcomment="(&lt;span class=&quot;autocomment&quot;&gt;&lt;a href=&quot;/wiki/Foobar#Examples&quot; title=&quot;Foobar&quot;&gt;?&lt;/a&gt;Examples:&amp;#32;&lt;/span&gt; capitalization)" />

Not sure of the exact names, but internally and in the api they are called 'comments' rather than 'summaries'. In Linker the action is 'format' but api users will be used to 'parse' already.


Version: 1.15.x
Severity: enhancement

Details

Reference
bz18427

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:34 PM
bzimport added a project: MediaWiki-API.
bzimport set Reference to bz18427.

I've done part 1 locally.

Are we having it as comment, or as summary? Seemingly, we use a mix of both

matthew.britton wrote:

(In reply to comment #1)

I've done part 1 locally.

Are we having it as comment, or as summary? Seemingly, we use a mix of both

We use:

  • 'summary' for actions 'edit', 'rollback' and 'import'
  • 'reason' for lists 'blocks' and 'globalblocks' and all other actions except 'upload'
  • 'comment' for action 'upload' and all other 'prop' and 'list' modules

so yeah... a mix :)

Gurch, you've just made it EVEN worse :P

If it wasn't such a breaking change, i'd suggest we normalise one way or another, but i guess it's not gonna be a good idea...

(In reply to comment #3)

If it wasn't such a breaking change, i'd suggest we normalise one way or
another, but i guess it's not gonna be a good idea...

For breaking changes you'll need a better reason than aesthetics :)

Reedy added a comment.Jan 31 2010, 3:40 PM

Oh Roan, you are boring ;)

Preference for this module then?

(In reply to comment #5)

Oh Roan, you are boring ;)

Yeah I'm good at playing a broken record. You should've seen my in my "File a bug" period.

Preference for this module then?

I think 'summary' is the least ambiguous term.

Reedy added a comment.Jan 31 2010, 5:46 PM

Good fun.

Part one done in r61747

Reedy added a comment.Jan 31 2010, 9:00 PM

r61754 Adds parsed comments to prop=revision

Reedy added a comment.Jan 31 2010, 9:13 PM

[21:05:01] <Reedy> hmm... maybe log events
[21:05:12] <Reedy> deletedrevs
[21:05:52] <Reedy> recentchanges
[21:06:08] <Reedy> usercontribs
[21:06:30] <Reedy> watchlist
[21:06:58] <Reedy> protected titles

Are all these needed/wanted?

All fixed up in r61761