Page MenuHomePhabricator

MediaWiki:Globalblocking-block-intro should match MediaWiki:Blockiptext
Closed, ResolvedPublic

Description

Author: mike.lifeguard+bugs

Description:
The form at Special:Block hides the other field when you use it - global blocking should do the same.

The local block form also has a dropdown of predefined block reasons - global blocking should do the same.

Please also match the default MediaWiki:Globalblocking-block-intro to MediaWiki:Blockiptext.


Version: unspecified
Severity: enhancement

Details

Reference
bz18098

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 10:33 PM
bzimport set Reference to bz18098.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Mar 22 2009, 3:15 AM

(In reply to comment #0)

The form at Special:Block hides the other field when you use it - global
blocking should do the same.

Reported separately at bug 18412.

mike.lifeguard+bugs wrote:

(In reply to comment #0)

The local block form also has a dropdown of predefined block reasons - global
blocking should do the same.

See bug 18413

Please also match the default MediaWiki:Globalblocking-block-intro to
MediaWiki:Blockiptext.

Changing the summary to leave this as the only request for this bug.

Why should it match?

mike.lifeguard+bugs wrote:

(In reply to comment #3)

Why should it match?

Because these system messages differ only in whether the block is local or global? Of course I don't mean it should be an exact copy - it needs to say that the block will affect all wikis.

But for example, there's no mention of adhering to policy. This makes little difference for Wikimedia, since MediaWiki:Globalblocking-block-intro is only relevant at Meta, and I've already changed the message, but it might matter for third-party users. But as I say, it's utterly trivial.

Marking this bug as Lowest priority.

I've done this in a batch to (usually enhancement request) bugs where:

  • It is not clear that this bug should be fixed.
  • It is not clear how to fix this bug.
  • There are difficulties or complications in fixing this bug, which are not justified by the importance of the bug.
  • This is an extremely minor bug that could not be fixed in a few lines of code.

If you're interested in having one of these bugs fixed, your best bet is to write the patch yourself.

Adding many blockers of bug 38638 to the list of "easy" bugs, to mark them as candidates for [[mw:Google Code-in]] tasks (gci2013). If you think this bug is not suitable, remove the keyword.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 27 2015, 9:14 AM
jrbs added a subscriber: jrbs.

Not a matter of tone, merely of consistency.

Nemo_bis set Security to None.
Meno25 removed a subscriber: Meno25.Feb 22 2016, 5:58 PM
Restricted Application added a subscriber: JEumerus. · View Herald TranscriptFeb 22 2016, 5:58 PM
Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptMay 8 2016, 8:35 AM

Dropdown in Special:GlobalBlock already added.

Since there already is a dropdown, could this be closed as fixed?

MarcoAurelio closed this task as Resolved.EditedOct 5 2016, 1:59 PM
MarcoAurelio moved this task from Backlog to Done on the good first bug board.

I agree. The other remaining request to match the text is declined. Local and global blocking are different things and globalblock-intro is descriptive so IMHO there's no need for that.