Page MenuHomePhabricator

[MEX] M3.1.2 - Spike - Improve Publish Info Option 1: Statement-Specific Summary Detection
Closed, ResolvedPublic

Description

In order to gain a better understanding of the level of effort and impact each option would have, we will create a prototype of the solution.

Timebox: 8 hrs?

From T403149: [MEX] M3.1.2 - Investigate options for improving information saved while publishing

Option 1: Statement-Specific Summary Detection (Recommended)

Level of Effort: Medium (2-3 weeks)

Create a new StatementChangesAnalyzer class (or whatever the the name you see fitting the most) to detect when multiple statements with the same property are being added and generate specific summaries.

Technical Implementation:

// New class: StatementChangesAnalyzer.php
class StatementChangesAnalyzer {
    public function analyzeStatementChanges(ChangeOpResult $changeOpResult): array {
        // Analyze ChangeOpResult to detect:
        // - Number of statements added per property
        // - Whether all changes are to the same property
        // - Types of changes (add/remove/modify)
    }
    
    public function isSinglePropertyMultipleStatements(array $changes): ?array {
        // Check if multiple statements are being added to a single property
    }
}

Code Changes Required:

  1. New Class: StatementChangesAnalyzer.php
  2. Modified Class: EditSummaryHelper.php - Add statement analysis logic
  3. New i18n Messages: Add messages for new summary actions
  4. Tests: Comprehensive test coverage for new functionality

Expected Result:
This will create a new comment value in the comment table in the database.
The used key wbeditentity-batch-single-property can be changed as well, this is just an exanple.

comment_text: /* wbeditentity-batch-single-property:4|P31|3|0|0 */ Added 3 statements for P31

Benefits:

  • ✅ Provides specific information about property changes.
  • ✅ Maintains consistency with existing Wikibase patterns.
  • ✅ Extensible for future enhancements.
  • ✅ Doesn't break existing functionality.

Disadvantage:

  • ❌ Requires new analysis logic.
  • ❌ Medium complexity implementation.

Event Timeline

Hm, a first problem becomes apparent pretty quickly.

public function analyzeStatementChanges(ChangeOpResult $changeOpResult): array {
    // Analyze ChangeOpResult to detect:
    // - Number of statements added per property
    // - Whether all changes are to the same property
    // - Types of changes (add/remove/modify)
}

What is this supposed to analyze? The ChangeOpResult doesn’t contain a full diff, only as much information as the ChangeOp saw fit to put inside, which according to the interface may just be a single boolean (isEntityChanged()).

We could add more information to the ChangeOpResult, but I think that’s basically option 2 (T407875).

I guess we could pass the the ChangeOp into the EditSummaryHelper and analyze that instead?

I guess we could pass the the ChangeOp into the EditSummaryHelper and analyze that instead?

Nope, that doesn’t work either. The ChangeOp contains all the statements we sent, even if only some of them actually have changes (and it doesn’t even begin to tell us which parts of the statement changed).

I feel like that about wraps it up for this option… let’s move it to peer review to see if anyone thinks I missed something, and meanwhile I’ll move on to option 2.

After playing around with XDebug for a bit, I have to agree… I don't see any way to do this short of comparing the statement in the ChangeOp with the base revision (which is not only inelegant but also entirely at odds with the current structure of the editing code).