matthiasmullie added a comment.
1. The relevant part in this summary (that we want removed) comes from `Wikibase\Repo\ChangeOp\ChangeOpRemoveStatement::getSummaryArgs`; that one must be prevented from returning the summary args (or its direct caller, `Wikibase\Repo\ChangeOp\ChangeOpRemoveStatement::apply` prevented from using it; further relevant code lacks information about this data that would make this possible without becoming an unstable hack) Unfortunately, the path down there is rather long: - `WikibaseRepo.ServiceWiring.php` constructs `Wikibase\Repo\ChangeOp\ChangeOpFactoryProvider` (in `"WikibaseRepo.ChangeOpFactoryProvider"`) - `ChangeOpFactoryProvider` ends up creating and returning a new instance of `Wikibase\Repo\ChangeOp\StatementChangeOpFactory` (in `getStatementChangeOpFactory`), but uses a myriad of private properties in order to do so - `StatementChangeOpFactory` creates & returns a new `Wikibase\Repo\ChangeOp\ChangeOpRemoveStatement` instance (in `newRemoveStatementOp`) - Said `ChangeOpRemoveStatement` is the one where we could adjust the kind of data that it returns, but actually getting there would require extending from, and in some parts largely duplicating, 3 classes in between. It's also not inherently isolated to MediaInfo entities so would need additional checks to ensure things continue to work when both extensions run side by side. In short: while not entirely impossible to override that way, this would be a hacky job, and a significant maintenance burden for both projects. 2. Before being stored, the data generated via above descriptions end up being processed in `Wikibase\Repo\SummaryFormatter::formatArg` (via `Wikibase\Repo\SummaryFormatter::formatAutoSummary`). It wouldn't be the ideal place to work with this, but it's a shorter chain of direct object creation, as we could "simply" override whatever end up being created in `WikibaseRepo.ServiceWiring.php`'s `"WikibaseRepo.SummaryFormatter"`, either directly in that class, or by passing it a custom `SnakFormatter` (of which we have no custom ATM, would probably also be "not trivial" to extend from Wikibase's default and produce a different result in (only) this case) that blanks out the data in this case. Still, that's a pretty massive initialization, and not really a class the lends itself well to being extended. 3. Changing the summary on display is not an option; AFAICT, core doesn't offer a way to transform the summary beyond the "autocomment" part (the stuff that gets turned into the grey "Removed claim:" part) 4. MediaWiki runs another hook (`onMultiContentSave`) pre-save that exposes the summary & allows it to be manipulated. At this point, we have only the formatted comment available without further context, but thanks to the autoformat summary & the coordinates format, we can quite reliably detect both the action (remove statement) and value (something that resembles a coordinate) and update it as needed (remove the coordinate). This is a little hacky, but it's very contained & has minimal risk (worst case is that the comment format changes at some point, at which point coordinates simply stop being removed from the comment, which is what we already have at this point). Given the challenges with other options, this is a good enough solution as far as I'm concerned. TASK DETAIL https://phabricator.wikimedia.org/T298700 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: matthiasmullie Cc: matthiasmullie, CBogen, Aklapper, AntiCompositeNumber, karapayneWMDE, toberto, Invadibot, maantietaja, Y.ssk, Muchiri124, Akuckartz, Nandana, Seddon, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, 4nn1l2, Taiwania_Justo, Scott_WUaS, Ixocactus, Wong128hk, Abit, Wikidata-bugs, aude, El_Grafo, Dinoguy1000, Steinsplitter, Mbch331
_______________________________________________ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
