from T101836#1414639:

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.

NOTE: the plans above assume that it's ok (for now) to have edit summaries in the client wiki's content language. For multilingual wikis, this isn't very nice, but it's consistent with other edit summaries there.