Last modified: 2014-09-08 11:12:46 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".
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.
why not automatically add the sig on talk pages?
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.
(In reply to comment #2) > why not automatically add the sig on talk pages? This bug isn't really about this though.
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
moving to "site configuration" component, since this is (and was originally) specific to English Wikipedia
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?
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.
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.
Can't we just trivially hook this on the "is this a Content namespace" flag?
James: I think so. Removed "enwiki" from the title, since this issue is hardly English specific.
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
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.
(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.
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.
(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.
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....
(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.
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.
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.
George Orwell III, that's TTO's second option.
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.
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.
(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.
(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'.
