Last modified: 2013-07-30 16:55:46 UTC
When a user inserts [[links]] or {{templates}}, VisualEditor automatically wraps them into <nowiki> tags. Experienced contributors who are very used to using this syntax sometimes add it inadvertently. It would be a nice touch to show an unobtrusive warning to remind users that they need to use VisualEditor's menu to insert links, templates & other wikisyntax. LiquidThreads does this well when users insert their signature manually with ~~~ into their post
Why is this marked low priority? It is causing problems on the live wiki with people unable to figure out why their edit has not worked - the VE hides the nowiki tags it has inserted so its impossible to determine the cause unless one knows about this feature (which I've not seen in documentation) or uses the misnamed edit source.
"What Chris said". I'd like to know the rationale for the priority rating on this; it's the biggest source of article corruption.
*** Bug 50581 has been marked as a duplicate of this bug. ***
I have already suggested bug 50527 as a possible solution to this problem. An automatic tag and then manual correction would be a simple-to-implement interim measure, if not long term.
And bug 50093 for an alternative [[ suggestion.
A permanently dismissible first-use reminder may be sufficient. I suggest we try that and see if it significantly reduces incidents of wikitext insertion. See bug 50601 for discussion.
(In reply to comment #6) > A permanently dismissible first-use reminder may be sufficient. I suggest we > try that and see if it significantly reduces incidents of wikitext insertion. > See bug 50601 for discussion. Habits die hard. When you've been entering wikitext manually for the past 12 years, it's _really_ hard to change your habits. I really doubt a "first-use reminder" will be enough; I still expect people to add [[ inside VisualEditor in 5 years. All drivers learn what the speed limits are before they get their driving license, but there are still speed limit signs on the roads :) A guided tour is indeed a great idea, but _in addition_ to an always-shown-when-wikitext-is-detected warning, not as a replacement, imho.
(In reply to comment #4) > I have already suggested bug 50527 as a possible solution to this problem. An > automatic tag and then manual correction would be a simple-to-implement > interim > measure, if not long term. Bug 50527 proposes that the edit go through, WITHOUT warning the editor of his/her mistake; instead, the edit summary gets a tag showing that a problem exists with the *completed* edit. Given that the software can detect this error, it makes more sense to give the editor who made the mistake a chance to fix it *before* the edit is completed - ideally, not to allow the edit to be completed with the error intact within in. That way, (a) the editor is more likely not to make the mistake again, and (b) if the editor who made the mistake fixes it before finalizing his/her edit, there is no need for a second (corrective) edit (and no need for someone to be monitoring recent changes for the tag proposed in bug 50527).
(In reply to comment #7) > (In reply to comment #6) > > A permanently dismissible first-use reminder may be sufficient. I suggest we > > try that and see if it significantly reduces incidents of wikitext insertion. > > See bug 50601 for discussion. > > Habits die hard. When you've been entering wikitext manually for the past 12 > years, it's _really_ hard to change your habits. I really doubt a "first-use > reminder" will be enough. Yes, this. I recognized the problem first time I did it, and it still happens.
Change 73569 had a related patch set uploaded by Catrope: Warn users when they are typing wikitext https://gerrit.wikimedia.org/r/73569
Change 73569 merged by jenkins-bot: Warn users when they are typing wikitext https://gerrit.wikimedia.org/r/73569
Feature to do this is now merged and will be deployed tomorrow.
Just tried this out - seems to be an issue. If you are scrolled down far enough on an article, the warning is never seen. It's tied to the top of the page. You can go all the way through the save process and only see the message once the new version loads. I suspect this might be reducing the effectiveness of the notice. (FF 22, OS 10.6.8)
The little box is not nearly obtrusive enough. It should be a popup (like the "are you sure you want to thank this user?" popup) that says the same thing as the warning, but requires confirmation (even a sole "OK" button would be fine, so long as it actually disrupts the editor's typing).
I'm reopening this as it seems to be the best place. There is definitely an issue with the warning being only on top and so you really don't have to be scrolled down that much before you don't see the warning.
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Wikitext_warning_probably_won.27t_be_seen_by_most_editors for some more detailed info on pieces of it.
Actually this is a general problem with jsMessages is general. They should be placed at a fixed position on the page.
Created MW bug for position fixed. Due to the possibility of false positives, having a blocking confirmation box may be too obtrusive.
Depends on bug 51432
(In reply to comment #18) > Created MW bug for position fixed. Due to the possibility of false positives, > having a blocking confirmation box may be too obtrusive. I dunno. I don't see a lot of false positives coming out of Filter 550. If you're really concerned, there could be a setting in the VE prefs to turn it off. (I definitely would NOT want a "don't show again" in the popup itself—too easy to get rid of it without clearly understanding what it means.)
What about having the balloon (https://github.com/wikimedia/jquery-tipsy ?) pointing exactly to the position where the wikitext was found?
(In reply to comment #21) > What about having the balloon (https://github.com/wikimedia/jquery-tipsy ?) > pointing exactly to the position where the wikitext was found? That might work pretty well too, especially if the balloon is a prominently "warning" color (as suggested somewhere by someone). I personally would be in favor of a big in-your-face notification, but I accept that not everyone will.
(In reply to comment #19) > Depends on bug 51432 This was already reported as bug 50870, adjusting.
The continued flow of markup errors shown by http://en.wikipedia.org/w/index.php?title=Special:AbuseLog&wpSearchFilter=550 is a pretty good indication that the warning either isn't obtrusive enough or clear enough. We're still seeing about 20 articles an hour corrupted because of this. I think this really needs a positive checkoff dialog, and the article shouldn't be saved until the editor has agreed that he really wants strings of brackets and pipes in his text. Having these in legitimately is an extremely rare case, especially for a novice editor. I'd block the edit with the edit filter if I could, but VE isn't able to display edit filter messages properly.
Another possibility: provide a side by side view of the two options the user has, and ask for confirmation: https://en.wikipedia.org/w/index.php?oldid=564535137#bug49820
(In reply to comment #24) > The continued flow of markup errors shown by > http://en.wikipedia.org/w/index.php?title=Special:AbuseLog&wpSearchFilter=550 > is a pretty good indication that the warning either isn't obtrusive enough or > clear enough. We're still seeing about 20 articles an hour corrupted because > of > this. > there was a problem with the message (it opened at top of page instead of top of screen), because of bug 50870. since this bug is fixed, the message will become more effective (afaik, this fix was deployed on July 22). personally, i think that the right solution is outlined in bug 51897. however, ATM 51897 is marked as "low". if you think like i do, maybe you should lobby to bump up the priority of 51897. peace.
If it's not one thing, it's another ... The popup message is now visible no matter where in a page the wikitext is being entered. So that's progress. The popup is still too inconspicuous for my tastes (and a great opportunity for A/B testing), but that's not what I'm posting about. My concern is with the link that the popup message includes (the label is "wikitext"; the target is [[Help:Wiki markup]]). If that link is clicked, the system **asks the user whether he/she wants to leave the editing page**. That's a bit user-unfriendly. I realize that smarter users can right-click and then open the link in either another tab or a new page, avoiding the question of whether they want to leave their editing session. But if we're aiming at the average user, it would be great if this link were pre-defined as opening another window, so that a simple click on the link didn't result in a perturbed user.
Change 76701 had a related patch set uploaded by Esanders: Set links in wikitext warning to load in new window https://gerrit.wikimedia.org/r/76701
(In reply to comment #27) > If it's not one thing, it's another ... Welcome to software development.
(In reply to comment #27) ... > I realize that smarter users can right-click and then open the link in either > another tab or a new page, avoiding the question of whether they want to > leave > their editing session. But if we're aiming at the average user, it would be > great if this link were pre-defined as opening another window, so that a > simple > click on the link didn't result in a perturbed user. Reported on bug 52093.
Change 76701 merged by jenkins-bot: Set links in wikitext warning to load in new window https://gerrit.wikimedia.org/r/76701
The issue that caused this to be reopened (bug 52093) has been fixed and will be deployed soon; consequently, reclosing this.
