Jon Katz says we should also have a look at Gather and its functionality to show changes for a given list of articles.

Showing edit summaries from the repo on the client is a bit complicated, especially since there already is a complex system for edit summaries on the client, it's just not based on the original summary.

Findings and ideas (may not work or need fiddeling):

1. Edit comments are currently not transferred to the client at all. A "comment" field exists in EntityChange metadata, but it's always empty. We need to put the edit comment into the EntityChange sent to the clients:
   1. EntityChange: drop the $comment field, drop setComment, implement getComment based on getMetadata, plus the fallback logic from the old setComment.
   2. EntityChange: Set 'comment' field in metadata in setMetadataFromRC; Set all metadata (including comment) in setRevisionInfo(); retain comment in setMetadataFromUser().

2. We want to re-use the formatter code that turns the autocomment block generated by SummaryFormatter into localized, human readable text. So we want to factor formatting code out of RepoHooks:
   1. create an AutoCommentFormatter class (in lib). It turns .
   2. move code from RepoHooks::onFormat to AutoCommentFormatter.

3. On the client, ChangeHandler currently ignores the (currently empty) comment field from the incoming EntityChange. When creating a RecentChanges entry, ChangeHandler sets rc_comment to the empty string. RecentChanges stores the fields and metadata from the EntityChange in the 'wikibase-repo-change' RC attribute, which is handled by ExternaLRecentChange. However, the 'comment' and 'composite-comment' fields are overwritten with the output of getEditComment() first. This is later picked up and processed by ExternalChangeFactory and ChangeLineFormatter. This should be changed so that ChangeHandler generates and stores human readable summaries in rc_comment, while preserving the original edit summary somewhere in the RC params:
   1. ExternalRecentChange::buildAttributes() should pass $attribs['comment'] to rc_comment (if set).
   2. ChangeHandler::getRCAttributes() should return 'wikibase-repo-change' => array_merge( $fields, $rcinfo ) with $fields and $rcinfo unchanged. $rcinfo['comment'] and $rcinfo['composite-comment'] should not be set.
   3. ChangeHandler::getRCAttributes() should separately return a value for the 'comment' attribute, constructed by calling getEditComment( $change ); if there are multiple coalesced changes in $fields['info']['changes'], getEditComment( $change ) is called fro each of them, and the results combined using Language::semicolonList. If the result is too long (>250 char or so), add "... and N more changes" to the end.
   4. ChangeHandler::getRCAttributes() should drop the "instanceof ItemChange" conditional.
   5. ChangeHandler::getEditComment() should always return a string, a human readable edit summary in the wiki's conent language. If the change is a sitelink change, the summary is generated by SiteLinkCommentCreator. Otherwise, it is generated by AutoCommentFormatter (which needs extra functionality to find and replace the autocomment block).
   6. Side note: investigate whether ExternalRecentChange really has to serialize everything into rc_params.

4. Currently, ExternalChangeFactory::extractComment transforms the array structure generated by the old ChangeHandler::getEditComment() into a slightly different array structure, which is then stored in the comment field of RevisionData, and interpreted by ChangeLineFormatter::formatComment (ExternalChangeFactory and RevisionData pretend the comment field is a string, but it's not, and ChangeLineFormatter actually requires it to be an array). We want ExternalChangeFactory to just pass on whatever ChangeHandler created; we'll leave it to ChangeLineFormatter to either just use rc_comment, or look at the original edit summary that is still present in the meta-data. Note that we have to preserve compatibility with older entries in the RC table for a while. So:
   1. ExternalChangeFactory::newRevisionData should set the new RevisionData's comment field to $this->extractComment( $changeParams ) ?: $recentChange->getAttribute( 'rc_comment' ). Or the other way around?
   2. ExternalChangeFactory::extractComment() should now always return a string (or false). IIt should do nothing and return false (and/or should not be called) for the normal case now; it's just needed for backwards compat with old RC entries: if $changeParams['comment'] is set and is an array, or $changeParams['composite-comment'] exists or is an array, it should run the old logic, plus the old logic from ChangeLineFormatter::formatComment(), to create a human readable comment.
   3. ChangeLineFormatter::formatComment should be dropped; ChangeLineFormatter::format should assume that $rev->getComment() returns a human readable summary string.
   4. Side note: RevisionData should get a changeParams field, set to what ExternalChangeFactory::extractChangeData() returns. This provides ChangeLineFormatter with full access to the original edit summaries and other relevant information. This could be left for later if it's not needed right now.
   5. Side note: consider merging RevisionData and ExternalChange.

To be decided: Should the AutoCommentFormatter class go into lib, services or a new component?

In T101836#1527215, @Lydia_Pintscher wrote:

To be decided: Should the AutoCommentFormatter class go into lib, services or a new component?

Creating a new component is now proposed here: T108681