Or just allow multiple sitelinks and treat them like constraint violations. That would fix T54564: Allow sitelinks to redirect pages to fix the 'Bonnie and Clyde problem' too, in a way. Enforcing one sitelink per language has always been somewhat of an outlier from Wikidata's generic "assume users know what they are doing and don't force rigid schemas on them" approach.

@Tgr wrote

Or just allow multiple sitelinks and treat them like constraint violations.

Yes, but currently, we have a unique key on that, and the table isn't small. A schema change is an option, sure.

But we'll have that discussion if it's clear that we actually want to do this... do you agree that prepareSave() should conceptually be bound to edits, not revision creation?

I think there are two separate issues here:

• Should prepareSave be allowed to check for global consistency? I'd agree that global state requirements do not mix well with the conceptual model of a wiki; implementers should be discouraged from relying on state outside the content object itself. (At a glance, current extensions don't do anything like that, apart from Wikibase.)
• Should checks happen on import / undelete? I suppose both approaches are justifiable; on one hand, it would be nice to offer a consistency guarantee when content is created (e.g. undeleting something after the code or configuration has been changed in a backwards-incompatble way should trigger an error). On the other hand, when an edit save fails, the problem can be surfaced to the user, who can fix it; but when an undelete or import fails, there usually isn't any feasible way to recover. So it would definitely be good to avoid errors in those cases. (Same goes for a rollback, somewhat, although in that case the user could be asked to do a manual edit instead.) Only checking after edits is maybe the less disruptive option.

(Also prepareSave seems like a misnomer; everything uses it for validation, not preprocessing or such.)

prepareSave() is indeed a misnomer, but this is hard to fix. There is an isValid() method which we could call when performing an edit, but that returns a boolean. It does not provide a way to report anything helpful to the user.

We could introduce a new method, but adding methods to the Content interface is always problematic, since there is no way to provide backwards compatibility for extensions that implement the interface directly.

In T143761: Fix Content validation - something to replace Content::isValid() I outlined why the current usage of both prepareSave() and isValid() are problematic, and we should either fix prepareSave() or introduce a new message and deprecate the other two.

Removing MCR-SDC milestone, since this isn't needed for SDC.

The task needs some rewording since T287159 / https://gerrit.wikimedia.org/r/c/mediawiki/core/+/732962 moved/renamed the function and replaced the old usages.