Last modified: 2014-09-08 11:12:46 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 5645 - Hide signature button from edit toolbar in main namespace
Hide signature button from edit toolbar in main namespace
Status: PATCH_TO_REVIEW
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
unspecified
All All
: Low enhancement with 9 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: edit-toolbar 57727
  Show dependency treegraph
 
Reported: 2006-04-18 20:27 UTC by Kurt
Modified: 2014-09-08 11:12 UTC (History)
17 users (show)

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


Attachments

Description Kurt 2006-04-18 20:27:20 UTC
Description: The user signature button needs to be disabled when a user is
editing articles in the main section of Wikipedia (i.e. pages that are intended
to be articles). This problem leads to user confusion and an unnecessary user
signature in articles.  Further, this will prevent the need for clean up of
articles with Special:Cross-name space page.

Suggested fix: Leave the user signature button in the toolbar on main Wikipedia
articles, but disable its function and have a mouse-over tool tip that reads
"User signatures are disabled in the editing of Wikipedia articles".
Comment 1 Kurt 2006-04-19 02:23:21 UTC
Actually, on second thought, I think it would be better if the mouse-over tip
read something like "Please do not sign Wikipedia articles" since the user
signature wouldn't really be disabled.
Comment 2 Soum 2006-06-23 07:57:50 UTC
why not automatically add the sig on talk pages?
Comment 3 Filip Maljkovic [Dungodung] 2006-06-23 09:35:00 UTC
Where exactly? You don't always put your comments at the end of a talk page or a
section. What you want is actually bug 5392.
Comment 4 Kurt 2006-06-24 21:47:26 UTC
(In reply to comment #2)
> why not automatically add the sig on talk pages?

This bug isn't really about this though.
Comment 5 Andrew Gray 2012-10-01 14:08:52 UTC
Recently discussed on enwiki with (so far) broad support:

https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Proposal:_remove.2Fhide_signature_button_when_editing_articles
Comment 6 This, that and the other (TTO) 2012-10-03 23:52:01 UTC
moving to "site configuration" component, since this is (and was originally) specific to English Wikipedia
Comment 7 Chad H. 2012-10-17 23:27:00 UTC
Moved back to MediaWiki since it actually requires said feature to exist before it could be enabled for enwiki.

Although I'm wondering: is this not something enwiki could accomplish with site JS?
Comment 8 Erwin Dokter 2012-10-28 15:10:21 UTC
This is trivial to do in javascript, but it would be more elegant and appropriate if core did not serve the button in the first place. Other projects may also be well in favor of implementing this feature.
Comment 9 Steven Walling 2013-10-05 01:38:54 UTC
This issue came up again today, as I was watching the video of a remote usability test. This was a new editor, but a very Internet-savvy person. He was thoroughly confused as to why there was a signature and timestamp button in a Wikipedia article. Choice quote: "I feel like I'm in a forum."  

I would prefer we not do this with site JS, since this problem is almost universal on Wikimedia projects. It is conceivable that on other third party instances, sites might encourage signed posts in the main namespace, but not for us.
Comment 10 James Forrester 2013-10-05 01:41:28 UTC
Can't we just trivially hook this on the "is this a Content namespace" flag?
Comment 11 Steven Walling 2013-10-05 01:43:47 UTC
James: I think so.

Removed "enwiki" from the title, since this issue is hardly English specific.
Comment 12 Gerrit Notification Bot 2013-10-05 02:35:57 UTC
Change 87649 had a related patch set uploaded by TTO:
Make edit toolbar Signature button optional in content namespaces

https://gerrit.wikimedia.org/r/87649
Comment 13 This, that and the other (TTO) 2013-10-05 02:45:10 UTC
That patch won't do anything for the 99% of wikis that use WikiEditor, though. WikiEditor has a setting called "hidesig" that is supposed to hide the signature button in namespace 0, but it doesn't seem to be active on WMF wikis. And it only affects namespace 0: if you have other content namespaces set up, they would still get the signature button regardless of whether hidesig is active or not.

It's beyond my capacity to figure out how to make WikiEditor respond to the new global variable I introduced in the above core patch... adding Roan who might be able to help.
Comment 14 Michael M. 2013-10-05 08:22:48 UTC
(In reply to comment #13)
> WikiEditor has a setting called "hidesig" that is supposed to hide the
> signature button in namespace 0, but it doesn't seem to be active on WMF
> wikis.

It should be active, but it just doesn't work, see bug 40972.
Comment 15 p858snake 2013-11-28 11:46:24 UTC
It might be nice (although a separate bug) to update WikiEditor as well so its uses this for its check to avoid duplicate options to disable this.
Comment 16 Nemo 2014-06-05 12:31:23 UTC
(In reply to Steven Walling from comment #9)
> almost
> universal on Wikimedia projects. It is conceivable that on other third party
> instances, sites might encourage signed posts in the main namespace, but not
> for us.

Except on Meta-Wiki, of course. Hiding the talk button on non-talk namespaces caused a lot of confusion in VisualEditor users, but if it's configurable as the patch proposes ($wgShowSigButtonInContentNamespaces) that's not a big problem I hope.
Comment 17 Derk-Jan Hartman 2014-06-21 15:58:09 UTC
Hmm, I'm not so sure about this wgShowSigButtonInContentNamespaces...

Would it not be better to have the visibility of the signature button depend on something that reflects: isTalkPage() || __NEWSECTIONLINK__ or something....
Comment 18 Nemo 2014-07-26 20:37:40 UTC
(In reply to Derk-Jan Hartman from comment #17)
> Would it not be better to have the visibility of the signature button depend
> on something that reflects: isTalkPage() || __NEWSECTIONLINK__ or
> something....

Umherirrender proposed __NEWSECTIONLINK__ too on the patch. However it should only be a last resort IMHO: if such an exception needs to be used often, then we're doing something wrong.

The patch currently does "more" than what the bug summary here asks; I think doing content namespaces only makes more sense. Copying from gerrit: I agree that where a __NEWSECTIONLINK__ is found the page is probably a discussion: but this can happen in any namespace. We can't really assume that a subject namespace is in DocumentMode; there are just some cases where it's likely.

The only property that tells us something meaningful here is whether a namespace is considered a content namespace, because on most (but not all) MediaWikis the main content of a wiki is not discussions. The non-content subject namespaces may be anything, really, and being internal namespaces, touched mostly by non-newbies, they're not worth messing up with just for the rare misplaced signature.
Comment 19 This, that and the other (TTO) 2014-07-26 23:09:44 UTC
I think we have three options here so far:

* Show signature button in all pages in non-content namespaces (as defined  
  by $wgContentNamespaces)
* Show signature button in all talk namespaces, as well as a specified set 
  of extra namespaces (current patch implementation)
* Show signature button on pages where the [New section] tab appears, as
  well as all talk pages

Please comment to say which one you prefer and why. We need some agreement from all involved.
Comment 20 George Orwell III 2014-07-29 05:09:35 UTC
I'd propose there is a 4th option; it being the setting of the existing filter.

Just add

		'filters': [ 'body.ns-talk' ],

... to the 'signature' button's entry in...

		jquery.wikiEditor.toolbar.config.js

... and you're done. The same approach is used for the 'reference' button btw.(see that same .js file if you don't believe me)

This way, all talk pages will automatically generate the 'signature' button while solving the immediate issue of how to stop its generation in the ns-0 namespace. If it was up to me, I'd at least thrown in the Project: namespace (like for Village Pump) along with all the talkspaces...

		'filters': [ 'body.ns-talk, body.ns-4' ],

... but admittedly, adding/excluding individual namespaces beyond all the talk namespaces at once, even if it is the so-called 'Project [Collaboration]' namespace, using this approach may be imposing a bit too much at the expense of flexibility for entities outside of the Wiki Foundation using the same software "we" do.
Comment 21 Nemo 2014-07-29 05:40:40 UTC
George Orwell III, that's TTO's second option.
Comment 22 George Orwell III 2014-07-29 06:04:03 UTC
Really? The 'filter' setting is built in; it just needs to be added then set in the mentioned .js file.

How is that the same as the proposed "current patch implementation" (the '2nd option' or roughly the ~16 patch-sets to date)? It has nothing to do with  $wgShowSigButtonInContentNamespaces  never mind  $wgShowSigButtonInContentNamespaces  in any way, shape. or form.

I agree, however, that both approaches might seek to achieve the same results at the end of the day - my solution would be the equivalent of making 1 edit adding 1 line to 1 existing .js file.

What else am I missing here? Thanks in advance.
Comment 23 George Orwell III 2014-07-29 06:13:05 UTC
amending Comment #22, the 2nd paragraph should have read....


How is that the same as the proposed "current patch implementation" (the '2nd option' or roughly the ~16 patch-sets to date)? It has nothing to do with  ext.wikiEditor.toolbar.hideSig.js  never mind  $wgShowSigButtonInContentNamespaces  in any way, shape. or form.


Sorry about that.
Comment 24 This, that and the other (TTO) 2014-07-29 07:41:00 UTC
(In reply to George Orwell III from comment #22)
> I agree, however, that both approaches might seek to achieve the same
> results at the end of the day - my solution would be the equivalent of
> making 1 edit adding 1 line to 1 existing .js file.

It may seem that simple to you, but it needs to be possible for this type of configuration to be altered *without* editing core JavaScript files, for a couple of reasons:

1. These files are overwritten whenever the MW software is upgraded
2. On a big cluster like WMF's, all wikis run the same, automatically
   updated code base, thereby making per-wiki hacks impossible

That's why we use LocalSettings.php and an extension-based, modular structure. Whatever is decided for MediaWiki as a software package needs to be able to be easily overridden in the WMF's configuration files (or, in the case of option 3, on-wiki).

I still favour option 2 (currently implemented in the proposed patch) as it appears this would be particularly useful for VisualEditor and other such systems, as well as MediaWiki core and WikiEditor.
Comment 25 George Orwell III 2014-07-29 08:41:46 UTC
(In reply to This, that and the other (TTO) from comment #24)
> It may seem that simple to you, but it needs to be possible
> for this type of configuration to be altered *without* editing
> core JavaScript files, for a couple of reasons:

> 1. These files are overwritten whenever the MW software is upgraded

So adding the filter line set to just let the button appear in only ns-talk spaces in this build means that setting could somehow be lost in the next build without the file being further 'touched'? That seems odd.

> 2. On a big cluster like WMF's, all wikis run the same,
> automatically updated code base, thereby making
> per-wiki hacks impossible

So you're assuming there would be a desire somewhere in either real-world or wiki-world usage to negate the button's generation in spite of the all namespaces in question being talk namespaces and only talk namespaces?

> I still favour
> option 2 (currently implemented in the proposed patch) as it appears this
> would be particularly useful for VisualEditor and other such systems, as
> well as MediaWiki core and WikiEditor.

I like option 2 as well - just wish it was not still up for debate not to mention beyond the original scope of the originally reported issue ('Bug 5645 - Hide signature button from edit toolbar in main namespace'). Even when this somehow later morphed into the inability of  ext.wikiEditor.toolbar.hideSig.js  to function as first hoped, its still a solution in search of a problem that to date has only presented itself in theory. 

And how would adding the filter parameter set for only ns-talk pages today affect your content-detection based proposal implemented tomorrow or next week or whenever? Does the designed filter in the extension then become moot if the content-based solution is in place? Would it hamper testing or enhance it in moving forward? 

There seems to be little consistency here other than the search for 'perfection' becoming the enemy of the 'good'.

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


Navigation
Links