Last modified: 2014-10-03 18:49:26 UTC
The ability to sign posts is useful outside of talk name spaces. For instance http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback is in project space. While that might one day be in flow there are many other project space items where its useful to be able to sign. For instance lists of project members. Some uses have guest books in the User: space which can be signed. You can't even enter them manually due to bug 49820. A button to insert this would be good, possibly done at the same time as bug 38029 which would insert symbols. This was discussed at http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Let_me_sign.21
The VisualEditor isn't going to be in project space at any point in the near future, however.
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_07#Let_me_sign.21 ^Updated link
I think it is important to enable signatures in VE. I have found it useful in a few circumstances; and regretted having to drop out of VE just for that one addition. This is the only feature blocking VE from being useful in a much wider variety of contexts, in my opinion. (And it's odd for all sig options to be missing when reminders about how to sign and where to sign are some of the most prominent in the MediaWiki interface otherwise.)
I just noticed this is flagged as lowest-priority enhancement... again surprising considering the importance and prevalence of signing in wiki culture and other MW docs.
That's probably something to do with the fact that the VE isn't really being used in discussion namespaces. This is not, by far, the only feature blocking VE from being useful in many other contexts. A lot of the discussion namespaces have their own idiosyncratic protocols and templates and formats that parsoid and the VE will then have to directly support, which is likely to be some (unknown) additional amount of work, and that'll all be done just in time for us to start releasing Flow, which does auto-signing. I can understand the low prioritisation ;).
Will Flow be applicable to all namespaces? There are lots of article-style pages that temporarily or permanently would benefit from inline comments in the middle of what is otherwise a full-text long-form page. In those cases* I don't see how the Flow design will help. Signatures are useful in most namespaces, whereas "idiosyncratic protocols and templates and formats", with unknown amounts of associated work, seem like higher-hanging tasty fleshy vegetalia. * Examples: wikis that don't separate talk from content; wikis that have two layers of talk: limited inline v. permanent talk-threads; articles or main pages that tabulate membership or participation or otherwise include tables that include user signatures.
(In reply to comment #6) > Will Flow be applicable to all namespaces? There are lots of article-style > pages that temporarily or permanently would benefit from inline comments in > the > middle of what is otherwise a full-text long-form page. In those cases* I > don't see how the Flow design will help. Like what? Some examples, please? > > Signatures are useful in most namespaces, whereas "idiosyncratic protocols > and > templates and formats", with unknown amounts of associated work, seem like > higher-hanging tasty fleshy vegetalia. > Sure, and work on those namespaces is best done when we actually discuss _deploying_ in those namespaces - and when it is fully working for the primary target of the VE (i.e., the mainspace). > * Examples: wikis that don't separate talk from content; wikis that have two > layers of talk: limited inline v. permanent talk-threads; articles or main > pages that tabulate membership or participation or otherwise include tables > that include user signatures. Actual examples for each example...?
To clarify, this is a "WONTFIX" for VE as it is (and will be) enabled on WMF projects, but if someone wants to write a plugin for VE for other wiki hosts using it that want to try to make VE work in discussion namespaces (and don't want to use Flow). There are a number of meanings of "Lowest" priority, and this is one of the confusing ones. Sorry. :-(
Adding a signature with VisualEditor can be simulated using a template: ---template code:--- {{{Sign}}} <noinclude> This template allows to sign using Visual Editor by adding this template as you can't enter four tildes <nowiki>~~~~</nowiki> in VE. Enter the template in VE. Hit Add template. Enter <nowiki>~~~~</nowiki> in the field. Hit Insert template. Hit Save page. Enter edit summary. Hit Save. Doone.</br> <templatedata> { "description": "A template to sign using Visual Editor. ", "params": { "Sign": { "aliases": [ "Signature" ], "label": "Sign by entering ~~~~ in the field below", "description": "Field to enter signature, that is four tildes", "default": "Please enter four tildes here", "required": true } } } </templatedata> </noinclude> ---end of template code--- Usage: Enter the template in VE. Hit Add template. Enter ~~~~ in the field. Hit Insert template. Hit Save page. Enter edit summary. Hit Save. Example: See https://www.mediawiki.org/wiki/Template:VESign. Application of template tested on https://www.mediawiki.org/wiki/User:Ad_Huikeshoven/test. Evaluation: There might be nicer methods to accomplish the same, maybe using JS (I have no experiene writing JS). When there is a switch over to Parsoid rendering the templates mid-edit rather than relying on PHP parser the above solution will probably break, as will probably do any solution to bug 51146.
Whoa, that's scary. Please don't do that. I wrote a script to implement signatures properly. This definitely isn't what the editor was designed to do, but, as it was noted in earlier comments, this has its use cases. https://meta.wikimedia.org/wiki/User:Matma_Rex/visualeditor-signature.js Please comment about it on the script's talk page, not here :) I'd be happy to include more translations (there are just two words to translate). I think the only thing missing is an icon that would match the look-and-feel of existing ones. I'd be happy to add it, too, if only someone drew one (SVG).
(In reply to SJ from comment #3) > I think it is important to enable signatures in VE. I have found it useful > in a few circumstances; and regretted having to drop out of VE just for that > one addition. The use case I would like mention is adding your name to the list of interested attendees at the program pages of https://wikimania2014.wikimedia.org/. Bartosz tools works wonderfully outside content name space. However, it explicitly doesn't work on content name space in which the program pages at the Wikimania site reside.
I replied at [[meta:User talk:Matma Rex/visualeditor-signature.js]].
I wonder what should we do with this bug? I think it should be marked either RESOLVED WONTFIX or RESOLVED FIXED, but I'm not sure which is more appropriate.
Being a basic building block of a wiki which is currently missing from VE I would not mark this as Resolved until there is a solution integrated in VE. Better then to leave it open and hope that some volunteer takes it on if it is deemed to be outside of the scope for Wikimedia to implement. Adding a signature should be as easy or easier (for the user) as adding an image or template. Also since there is nothing preventing signatures from being added to any namespace in the wikitext editor there should be no hard-coded exceptions in the VE-solution (although there could of course be site-wide setting disallowing them.
(In reply to Lokal_Profil from comment #14) > Being a basic building block of a wiki which is currently missing from VE I > would not mark this as Resolved until there is a solution integrated in VE. > Better then to leave it open and hope that some volunteer takes it on if it > is deemed to be outside of the scope for Wikimedia to implement. There is never going to be a "sign post" feature integrated into VisualEditor as deployed on WMF servers. That's the whole point of Flow. From a perspective of "VisualEditor for WMF users", this is WONTFIXed. This bug is not marked as "WONTFIX" though, because it's entirely plausible that someone might want to run VisualEditor on a wiki without Flow (or LQT or Message Wall or whatever). Maybe we should bundle up Bartosz's code into a VE plug-in that's available for users (but not on by default)?
That sounds fine by me. So it would be enabled with a $wg config variable? I wonder if it would make sense to let users enable it for themselves (by loading a RL module in common.js, for example).
(In reply to Bartosz Dziewoński from comment #16) > That sounds fine by me. So it would be enabled with a $wg config variable? That was my thought, yes. > I wonder if it would make sense to let users enable it for themselves (by > loading a RL module in common.js, for example). It doesn't; either VE namespaces are signable or they're not. A per-user setting doesn't make sense. "Assigning" to Bartosz given he's done all the work here. :-)
Actually, a $wg config variable for this is not a very good idea. We should just be smart and display the signature button in the namespaces that need it (and no others). Core MediaWiki currently has no way to do this (other than the implied assumption that all talk namespaces need signatures), but there happens to be a patch pending that would introduce one (https://gerrit.wikimedia.org/r/87649). We should just wait for that to be implemented, and then use the same logic as wikitext editor when deciding whether to enable signatures or not.
It seems that bug 5645 which I thought to be a dependency is not going to be fixed in a useful way. The only way to proceed would be reimplementing the namespace selection logic in VE, which I'm wary of. I don't know how to proceed with this, I guess we'll be stuck with the gadget for the time being.
I am raising the priority of this bug. VisualEditor is now enabled for talk pages on Meta, yet I can't insert my signature using VisualEditor, which is a major shortcoming. Please fix!
(In reply to Pine from comment #20) > I am raising the priority of this bug. VisualEditor is now enabled for talk > pages on Meta, yet I can't insert my signature using VisualEditor, which is > a major shortcoming. Please fix! What talk pages is it enabled for? Can you give an example? It doesn't appear on the talk pages I just looked at. This feels like a distinct bug. Please read the history of this bug for why this is explicitly outside of the plans for VisualEditor; it's fundamentally the wrong approach. Resetting priority.
Perhaps someone enabled VE on talk pages when they shouldn't have? It's enabled on https://meta.wikimedia.org/wiki/Grants:APG/Comments
Ah, I see. That's not really labeled as a talk page on Meta, but it probably should be. I'll try to take care of that.
(In reply to Pine from comment #22) > Perhaps someone enabled VE on talk pages when they shouldn't have? > > It's enabled on https://meta.wikimedia.org/wiki/Grants:APG/Comments Argh. That's not a talk page. You can tell because the talk page would be https://meta.wikimedia.org/wiki/Grants talk:APG – this is really unhelpful of people to use the wrong namespace. I'm sorry about that. :-(
Yes, I've moved it to talk space. Sorry I didn't catch that earlier.
