Last modified: 2013-09-23 05:51:47 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T44231, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 42231 - MediaWiki:Globalblocking-ipblocked should have a specific message for WMF projects
MediaWiki:Globalblocking-ipblocked should have a specific message for WMF pro...
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
WikimediaMessages (Other open bugs)
unspecified
All All
: High normal (vote)
: ---
Assigned To: Nemo
: i18n
Depends on:
Blocks: messages SWMT
  Show dependency treegraph
 
Reported: 2012-11-17 20:18 UTC by MA
Modified: 2013-09-23 05:51 UTC (History)
14 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description MA 2012-11-17 20:18:18 UTC
Extension:GlobalBlocking is a tool that allows blocking IP addresses in all wikis. This extension is not just restricted to WMF so it has standard messages so anyone can install in on different wikis.

Some stewards think, however, that the message the globally blocked user gets should be Wikimedia-specific so it is the same for all WMF projects and all users get the same instructions about where and how to appeal.

Actually the message requires the user to contact the globally blocking steward on their talk or by email, which sometimes isn't possible either because globalblocking disables the ability to post on all wikis except at Meta.

What we would require is a similar message just for WMF projects, as follows:

***********

'''Your IP address has been [[m:Global blocks|blocked on all wikis]].'''

The block was made by $1 ($2). The reason given for the block is ''$3''.

* Start of block: $4
* Expiry of block: $5
* Your current IP address is $6.

To discuss the block, please post a request for review at [[m:Steward requests/Global|Steward requests/Global]] on Meta-Wiki.

Please include all above details in any queries you make regarding this global block.

***********
(Can be tweaked of course)

Why? - We already have a procedure and a page for global blocks and locks requests and discussions. Pointing to the blocked users to the stewards' talk page prevents that other stewards are not aware of the action taken and may slow down user assistance.

ENWP for example has customized their local message to instruct the users better about what to do. Notwithstanding most of the wikis have not. Having a global WMF-specific message would at least point all users to the requests page. I think it can be an improvement.

Regards.
Comment 1 Alex Monk 2012-11-17 20:22:23 UTC
According to Siebrand on Gerrit change #31672, where we're trying to do a similar message overriding for Wikimedia sites:

>I'm blocking merge for this, because conceptually there's something very wrong here. Can you please give this some thought, and tell me why this would work?
Comment 2 billinghurst 2012-11-17 23:34:40 UTC
At this point the global blocking message says discuss with the blocking person.  This is neither effective or productive when there is a large team of people acting as stewards at Wikimedia for 700+ wikis.  Consider also that individuals come and go, so we may actually pointing people to a dead end (stewards do retire before their blocks end)

Stewards need to be able to have the ability to
* edit the message
* to display their message universally
* look to have a message in the local language (if volunteers will do so)

As Marco Aurelio has said we need the additional ability to include links to a specific page.  I would add that we may be looking to add email links, as at the moment we specifically need to add that in the block reason and a default addition may be seen to be more effective.

Here the stewards see that pointing users/complainants to a central page, and/or to a universal email address (in OTRS) is a better systematic and responsive methodology.  Having a better ability to globally configure a universal message/template is highly desirable.  Giving stewards the tools to manage their affairs and information in real time (or close to) is the next step in maturing global block.

FWIW I am sure Krenair's comment is relevant, I just don't get the importance/relevance myself.  I must be lacking a link to another information piece.
Comment 3 Alex Monk 2012-11-18 00:35:05 UTC
(In reply to comment #2)
> FWIW I am sure Krenair's comment is relevant, I just don't get the
> importance/relevance myself.  I must be lacking a link to another information
> piece.

Basically in that Gerrit change we tried to override a message (what this bug is about - but a different message) by setting it in the WikimediaMessages extension. But Siebrand -2'd it with a confusing message and has not elaborated.
It seems he thinks this should not work and that it should be done some other way, I don't know how though...
Comment 4 Jasper Deng 2012-11-18 03:48:43 UTC
There should still be the right balance of local control, while still allowing stewards to send the message through.
Comment 5 James Forrester 2013-02-22 00:25:54 UTC
Bumping this - I assume that siebrand's concern is that the normal way of achieving this in the WikimediaMessages module is to use a hook in core around the message that can be replaced by a WMF-specific message. You do not just over-ride the message with a conflicting definition.

E.g. the "hook" for "edit page copyright warning" allows MediaWiki:copyrightwarning to be replaced by MediaWiki:wikimedia-copyrightwarning as it calls a function ('efWikimediaEditPageCopyrightWarning') that returns that string instead of the default.

Thus, for centralauth-block-already-locked we should create a hook around that message and create a new message, wikimedia-centralauth-block-already-locked (or similar) that has the Wikimedia-specific aspects (in this case, the meta reference).

Does that make it clearer?
Comment 6 Nemo 2013-02-22 05:07:44 UTC
There's also a much simpler way to fix this, i.e. follow the usual MediaWiki approach as in 

'searchresulttext'                 => 'For more information about searching {{SITENAME}}, see [[{{MediaWiki:Helppage}}|{{int:help}}]].',

Just replace "You can contact $1 to discuss the block." with: "For additional information and if you believe the block was made in error, see [[{{MediaWiki:Globalblocking-infopage}}]] or contact $1". 
MediaWiki:Globalblocking-infopage should default to "Project:Global blocks", can be translated and can be easily overwritten with a link to Meta which will have specific instructions like "user SRG" or "write OTRS", see also https://meta.wikimedia.org/wiki/Talk:No_open_proxies#Instructions_on_appeals_and_translations

Remember also not to introduce bug 15259 with this message too; it seems it's fine now.
Comment 7 Nemo 2013-09-07 15:47:15 UTC
(In reply to comment #6)
> can be translated and can be easily overwritten with a link to Meta which
> will
> have specific instructions like "user SRG" or "write OTRS", see also
> https://meta.wikimedia.org/wiki/Talk:
> No_open_proxies#Instructions_on_appeals_and_translations

The new process is ready for linking: <https://meta.wikimedia.org/wiki/No_open_proxies#Global_exceptions_and_appeals>
It will take a few days to wait for comments/objections and mark for translation, but a patch can now be worked on to link it.
Comment 8 Gerrit Notification Bot 2013-09-16 16:55:27 UTC
Change 84343 had a related patch set uploaded by Nemo bis:
Add custom error messages to blocked users for global and Tor blocks

https://gerrit.wikimedia.org/r/84343
Comment 9 Gerrit Notification Bot 2013-09-23 02:34:26 UTC
Change 84343 merged by jenkins-bot:
Add custom error messages to blocked users for global and Tor blocks

https://gerrit.wikimedia.org/r/84343
Comment 10 Nemo 2013-09-23 05:51:47 UTC
Fixed! Thanks Tyler for the code review.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links