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

ignatzmice.wiki wrote:

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

ignatzmice.wiki wrote:

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

ignatzmice.wiki wrote:

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

ignatzmice.wiki wrote:

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

kwwilliams wrote:

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.