Page MenuHomePhabricator

Converge infinity values into one constant
Open, Needs TriagePublic

Description

Background

Anywhere MediaWiki accepts an expiry (such as when blocking users, protecting pages, or watching pages), we accept multiple values for infinity: infinite, indefinite, infinity and never. This used to be tested against in each Core component until that was refactored into wfIsInfinity() in 2015 (T68646). Then during the development of Expiring-Watchlist-Items, the Core ExpiryDef class was created which contains the ExpiryDef::INFINITY_VALS constant (T248508). Finally, mw.util.isInfinity() was recently added to the JS interface (T353389).

Usage of these values varies greatly across codebases.

Proposal

Settle on one value and deprecate the others. We appear to only store infinity in the database, so that seems like the one to use. We could however name the constant ExpiryDef::INDEFINITE, because that's usually what we display to users, and infinite, infinity and never misleadingly imply permanence when this is not necessarily true (you can always lift pgae protection or unblock a user, etc.).

The deprecation process could entail:

  • Adding the new ExpiryDef::INDEFINITE constant
    • Probably add a JavaScript constant too, i.e. mw.INDEFINITE (?)
  • Emit a deprecation warning in the action API when a deprecated infinity value is used
  • Add deprecation warning to wfIsInfinity() that ExpiryDef::INDEFINITE should be used instead, and similar for mw.util.isInfinity()
  • Fix all interface messages and their on-wiki overrides to use the new value
  • Update Special:Block, Special:UserRights, action=protect and any other relevant pages to show user-facing errors when deprecated values are used (I think the existing error "Expiry time invalid" is not specific enough)
  • Give communities plenty of time to update gadgets, scripts, etc.
  • Remove all traces of the old values and the isInfinity() methods.

Relevant links:

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Is the values in database consistant? If not, we need to clean up them.

Is the values in database consistant? If not, we need to clean up them.

Good point. On quick glance it seems to be normalized to infinity. As it happens, we're moving to a new block schema soon and have a migration script that could auto-update the values, if we care to do so (T350361). Otherwise, we can stick with infinity. I suspect few end users enter these values manually anyway, rather they use the dropdown (which will continue to say "Indefinite").

Seems like all the relevant tables store infinity, so let's just stick with that to avoid having to write more migrations scripts. We can still name the constant INDEFINITE if we so desire.

There is semantic difference between infinite and indefinite. These blocks are issued indefinitely. Meaning without a KNOWN, defined end date. As opposed to definite (fixed time duration) blocks. Infinite means with no limit, no end, perpetual.

So you indefinitely issue a ban that is infinite. But the infinite block can be appealed and revoked, etc. Only its comparison date is 'infinity'. But no block has ever been issued that is meant to last to the end of the universe.

This is also why en.wp uses indefinite in their messaging https://en.wikipedia.org/wiki/Wikipedia:Blocking_policy to signal that recourse is always a possibility.

Change 995192 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):

[mediawiki/skins/Vector@master] watchstar: use mw.util.isInfinity() instead of comparing to 'infinity'

https://gerrit.wikimedia.org/r/995192

Change #995192 merged by jenkins-bot:

[mediawiki/skins/Vector@master] watchstar: use mw.util.isInfinity() instead of comparing to 'infinity'

https://gerrit.wikimedia.org/r/995192