kurthalomieu wrote:

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.

soumyasch wrote:

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.

kurthalomieu wrote:

(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.

swalling wrote:

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?

swalling wrote:

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'.

Change 87649 had a related patch set uploaded (by GOIII):
Hide edit toolbar Signature button in non-discussion namespaces

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

Patch-For-Review

I believe TTO's implementation at https://gerrit.wikimedia.org/r/#/c/87649/ is the right way to fix this bug. It allows the problem to be solved consistently for all editors (core, WIkiEditor, VisaulEditor), while giving projects like Meta (or 3rd party wikis) the flexibility to display the signature button on content pages if they want to. Yes, it may be overkill, but projects don't have to use the configuration option if they don't want to.

Change 87649 merged by jenkins-bot:
Hide edit toolbar Signature button in non-discussion namespaces

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

Thanks, Ryan, for looking at this.

This task is now resolved, at long last, which is a good thing. However, it is a sad indictment on the Wikimedia development community that this easy-to-fix issue remained open for more than 9 years. Hopefully the next nine-and-a-bit years will see tasks resolved more quickly, and not left to languish just because they are seen as "trivial" or "unimportant" in the eyes of some developers.

Needs config in wmf-config for Meta-Wiki, Probably special.dblist and wikimedia.dblist wikis as well?

ah yeah, totally forgot about that :( Thanks!

Actually, seems like the config was already added by @Nemo_bis almost a year ago in 6c6cbb0b90828dcfcce4486274f2178bfb1adb65. There is no need to list metawiki explicitly, since it belongs to special.dblist.

What about village pumps and similar non-talk-namespace discussion pages? Usually pages with __NEWSECTIONLINK__ are considered talk pages, but this patch does not seem to do that.

In T7645#1524503, @Tgr wrote:

What about village pumps and similar non-talk-namespace discussion pages? [..]

wmf-config does have NS_PROJECT in the $wgExtraSignatureNamespaces array. Maybe we should move that to core?

For what it's worth, I just ran into this issue on an internal wiki. A few users have been using the timestamp button to sign comments in the main namespace. Thank you for providing $wgExtraSignatureNamespaces. :-)

Change 237331 had a related patch set uploaded (by Nemo bis):
Configure $wgExtraSignatureNamespaces for it.wikipedia

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