Last modified: 2013-08-01 10:29:07 UTC
I note that if an editor uses old markup in VE (like [[link]]), it gets enclosed in <nowiki> tags Could we have an additional tag added to the Edit summary, (similar to the Visual Editor tag we have?) which states somethine like "Old wiki markup" That way, we can keep track of, and rectify all the cases where the old wiki markup is used while using VE, and remedy it rather than clutter dozens of article with nowiki tags which might not be removed for days
Here's an example of an edit which we'd like to be tagged in the future: https://en.wikipedia.org/w/index.php?title=Richard_Rich,_1st_Baron_Rich&diff=562587470&oldid=562435942 In this case, the user didn't even realize they were using the VisualEditor and came to the help desk, confused: https://en.wikipedia.org/wiki/Wikipedia:Help_desk#Problems_editing_with_beta_versions.3F
FYI, in the meantime, I've requested an edit filter to be added to identify nowiki tags in the main namespace on the English Wikipedia: https://en.wikipedia.org/w/index.php?title=Wikipedia:Edit_filter/Requested&oldid=562811538#nowiki_in_main_namespace There's now also one on the French Wikipedia.
There is now an edit filter to detect insertion of nowiki's http://en.wikipedia.org/w/index.php?title=Special:AbuseLog&offset=&limit=500&wpSearchFilter=550
Maybe this is something that should be tested with global filters[1] now that they are available? [1] http://lists.wikimedia.org/pipermail/wikitech-l/2013-July/070253.html
As mentioned, there is now a local AbuseFilter running on enwiki that flags any edit that adds a <nowiki> tag (whether in VisualEditor or wikitext editor; whether accidental or deliberate; whether due to using wikitext markup or because of a bug). I think a global AbuseFilter might make sense to do this globally, but certainly this feels like something better done using AbuseFilter than heavy-handedly inserted by VisualEditor itself, if that makes sense, so I'm going to close this as a WONTFIX - but very happy to reopen if people feel it would be better in VE.
Tell me how an abuse filter can even detect that Visual Editor was involved in the edit before you attempt to close this, please.
Adding a <nowiki> to an article (as opposed to a template or something) is generally unnecessary and probably in need of a second look, regardless of whether VE added it or the editor added it manually. Wikimarkup simply *doesn't look like* real punctuation, so it's uncommon to need to escape it in running text. As such, I tentatively agree with James here: A VE-only filter would be unnecessary since the broader case is really what we need to go after anyway.
Its possible the abusefilter could be made to detect veaction=edit, then the abuse filter could be made more discriminating, and probably block ve edits with nowiki's. There are many cases where nowiki's are ment from the wikitext. In code samples documentation of templates etc. they always explicitly typed indication an intention from the user.
But code samples and template documentation won't be in mainspace, which the current filter checks for. Legitimate uses of <nowiki> in mainspace are quite rare, so far as I know. I suppose the articles on e.g. [[MediaWiki]] might use nowiki'd wikitext to show the readers what wikitext looks like, but other than that...
(In reply to comment #7) > Adding a <nowiki> to an article (as opposed to a template or something) is > generally unnecessary and probably in need of a second look, regardless of > whether VE added it or the editor added it manually. Wikimarkup simply > *doesn't look like* real punctuation, so it's uncommon to need to escape it > in > running text. > > As such, I tentatively agree with James here: A VE-only filter would be > unnecessary since the broader case is really what we need to go after anyway. You miss the point: in an edit-filter, I would advocate simply blocking the edit if it was VE and not allow it to be saved. If a human being consciously did it, there's at least a remote chance that it was a good edit worthy of examination. There *are* legitimate uses of nowiki, usually things involving bolded and italicized possessives, pipe characters inside of text. It's just that none of the ones created by VE have any merit.
(In reply to comment #10) > (In reply to comment #7) > > Adding a <nowiki> to an article (as opposed to a template or something) is > > generally unnecessary and probably in need of a second look, regardless of > > whether VE added it or the editor added it manually. Wikimarkup simply > > *doesn't look like* real punctuation, so it's uncommon to need to escape it > > in > > running text. > > > > As such, I tentatively agree with James here: A VE-only filter would be > > unnecessary since the broader case is really what we need to go after anyway. > > You miss the point: in an edit-filter, I would advocate simply blocking the > edit if it was VE and not allow it to be saved. If a human being consciously > did it, there's at least a remote chance that it was a good edit worthy of > examination. I think that would be an exceptionally-bad thing to do to fellow editors and thus to the wiki at large, but that's a decision for local wikis' communities to make, and not appropriate for the developers to rule on. > There *are* legitimate uses of nowiki, usually things involving bolded and > italicized possessives, pipe characters inside of text. It's just that none > of the ones created by VE have any merit. None? None ever? Not even when a user of VisualEditor creates a bolded or italicised possessive? :-)
(In reply to comment #6) > Tell me how an abuse filter can even detect that Visual Editor was involved > in the edit before you attempt to close this, please. That would be bug 51421 (which is a bug against AbuseFilter); you should follow-up there.
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #7) > > > Adding a <nowiki> to an article (as opposed to a template or something) is > > > generally unnecessary and probably in need of a second look, regardless of > > > whether VE added it or the editor added it manually. Wikimarkup simply > > > *doesn't look like* real punctuation, so it's uncommon to need to escape it > > > in > > > running text. > > > > > > As such, I tentatively agree with James here: A VE-only filter would be > > > unnecessary since the broader case is really what we need to go after anyway. > > > > You miss the point: in an edit-filter, I would advocate simply blocking the > > edit if it was VE and not allow it to be saved. If a human being consciously > > did it, there's at least a remote chance that it was a good edit worthy of > > examination. > > I think that would be an exceptionally-bad thing to do to fellow editors and > thus to the wiki at large As was making VE the default editor in the first place, so it's obvious we don't agree some fundamental points. > > > There *are* legitimate uses of nowiki, usually things involving bolded and > > italicized possessives, pipe characters inside of text. It's just that none > > of the ones created by VE have any merit. > > None? None ever? Not even when a user of VisualEditor creates a bolded or > italicised possessive? :-) True enough. Which is why you should fix the root bug in the first place instead of pushing it downstream for everyone else to deal with: warning newbies about inserting explicit wikimarkup is obviously still inadequate, as this edit filter still fires.
A user at en.wp comments that if this bug remains unfixed that cleaning up the live wiki using AWB will take "about maybe an hour of experienced editor time to manage this, every day forever, because WMF is unwilling to accept feedback on how the software is actually used."
Chris, could you add a link to that comment. Im interested in why the nowiki edit filter isnt sufficient. Preventing the VE nowiki edit is a bit rude, and is sticky tape of the problem with the VE causing these nowikis. In VE, the user cant _see_ the nowiki causing problem all the time. E.g. A space at the beginning of the line isnt obviously the cause of the nowiki. unless VE explicitly tells them where the nowiki is happening, how can we expect the newbie to figure it out.
(In reply to comment #15) > Chris, could you add a link to that comment. It's the second comment by VQuakr at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=566546550#WONTFIX_on_nowiki.27s (that's a permalink to the present version of the page but the discussion may not have concluded yet).
(In reply to comment #15) > Chris, could you add a link to that comment. Im interested in why the nowiki > edit filter isnt sufficient. It isn't sufficient because it disappoints the first human involved, this hypothetical new editor that is so confused by all of our existing material that he's errantly typing wikitext into a source window. VE could *help* him, but instead it pops a warning. The warning obviously isn't working, because we see saves of this material happening constantly. He goes ahead and saves it anyway, and he's bewildered and confused: he did just what the little cheat sheet he got from a friend told him to do, and it didn't work. It's insufficient because it requires a second human being to then review the change, figure out what it was that the first human was actually attempting, and then correct it if he can. It's insufficient because it's in support of a use-case that doesn't exist: there's no reason to put something like [[New York City|the Big Apple]] into articles. If there *were*, it's coming from an editor that is quite skilled enough to go into the source editor. If we need to support putting such things in using the visual editor, a workflow can be designed with a "nowiki" button to do it intentionally. Instead, James Forrester and Erik Moller have decreed that the bug not be fixed, and that volunteers should eagerly flock to monitoring the output of an edit filter that detects each and every time this happens to that these volunteers can fix it. That's repulsive. That's a level of disregard for the volunteers that work on this project that is breathtaking. It's the *reason* that the VE team can fix dozens of bugs each hour and the Wikipedia community still complains that they are non-responsive.
(In reply to comment #17) > Instead, James Forrester and Erik Moller have decreed that the bug not be > fixed, and that volunteers should eagerly flock to monitoring the output of > an > edit filter that detects each and every time this happens to that these > volunteers can fix it. That's repulsive. That's a level of disregard for the > volunteers that work on this project that is breathtaking. It's the *reason* > that the VE team can fix dozens of bugs each hour and the Wikipedia community > still complains that they are non-responsive. That is bug 49686, not this one. Why are we discussing it here?
Closely related problems, Kevin Norris: if they would *fix* 49686, this one would go away. This one can't really be fixed because the base condition that causes it should be prevented, not reported.
(In reply to comment #18) kwwilliams: Unrelated to agreeing or disagreeing with others, could you please assume that people mean well instead of calling names, to keep Bugzilla a friendly place? High-level debates on general development priorities are better placed on https://en.wikipedia.org/wiki/Wikipedia:VE/F instead of a bug report which is only meant to be about a *specific* problem *in the code*. Thanks!
(In reply to comment #20) > (In reply to comment #18) > kwwilliams: Unrelated to agreeing or disagreeing with others, could you > please > assume that people mean well instead of calling names, to keep Bugzilla a > friendly place? I haven't called anyone names. I don't plan on starting to, either. If you can suggest a friendlier wording to describe a conscious decision not to fix a bug and requiring other people to deal with the consequences of the bug every day forever instead, I'm willing to listen to suggestions.
Removing self from CC. Tired of spam. Bug is dead, people.
