Wikipedia talk:VisualEditor

Subpage Index

Are you here to leave feedback about VisualEditor?

Wikipedia has a place for that!

Please leave your feedback on mediawiki.org or file a task on the Phabricator bug tracker.

If you need help editing with Visual Editor, consider asking at WP:Teahouse.

Note. VisualEditor only shows up in some namespaces, most notably in main namespace (articles) and in user namespace. No talk pages. A good place to play around is in a sandbox in a subpage in your user namespace (User:YourUserName/sandbox3) or this page if you're not logged in. For a sandbox of your own, create it here.

This is the talk page for discussing improvements to the VisualEditor page.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Archives: 1, 2, 3, 4, 5, 6, 7, 8: 100 days

Traylblazor

Recording artist and songwriter Traylblazor Music (talk) 06:39, 6 August 2024 (UTC)[reply]

Courtesy link: Draft:Traylblazor

Please review the following: Wikipedia:Autobiography, Wikipedia:Notability (music), Wikipedia:Plain and simple conflict of interest guide. Folly Mox (talk) 08:53, 6 August 2024 (UTC)[reply]

consistently creates referencing errors

I notice that edits credited to Visual Editor often cause referencing errors. There's an observable pattern: some reference named "fooey" ends up being moved, or edits happen nearby, and it gets renamed to "fooey2". Of course, "fooey2" is not defined. Why does this happen? It's pretty frequent. -- mikeblas (talk) 01:35, 16 September 2024 (UTC)[reply]

Can you please link to a couple of diffs to show these edits happening? It would be even better if you could reproduce it to confirm that people are not manually messing up these refs and just happen to be using VE. – Jonesey95 (talk) 17:44, 16 September 2024 (UTC)[reply]

Unfortunately, I'm not a Visual Editor user, so I'm not able to provide steps to reproduce the issue. My ~~completely blind guess~~ sense is that the problem happens when text (with reference tags) is moved within the article. Maybe moved in one operation, paybe cut and pasted -- dunno. Maybe asking these users what they did would be a way to get the answer you want.

Here are five observations. Some of them contain more than one reference anchor renamed in the pattern that I've identified.

This last one is a bit different because it spans a add-remove-restore editing pattern:

https://wiki.riteme.site/w/index.php?title=Jack_Schlossberg&diff=1246531722&oldid=1246515638

Hope that helps. -- mikeblas (talk) 15:06, 20 September 2024 (UTC)[reply]

This looks like phab:T125034, which @ESanders (WMF) declared (then) to be a symptom of phab:T134228. @Trizek (WMF), I don't know if there is bug report already open on this, but I'm sure that the Editing team would appreciate one. WhatamIdoing (talk) 16:51, 20 September 2024 (UTC)[reply]

Thanks, WhatamIdoing. This looks similar to the first bug, and I have been admonished not to reopen old bugs, so T375306 it is. – Jonesey95 (talk) 22:10, 20 September 2024 (UTC)[reply]

Six years ago? Great memory! Thanks for looking into it. I'm hopeful for a fix, since this is a common source of undefined reference names. -- mikeblas (talk) 22:50, 20 September 2024 (UTC)[reply]

The human brain is pretty good at remembering irritating things. ;-) WhatamIdoing (talk) 00:53, 21 September 2024 (UTC)[reply]

A commenter on that phab ticket and I are unable to replicate this bug. Does anyone here know how to make it happen? – Jonesey95 (talk) 02:10, 23 September 2024 (UTC)[reply]

Everything I ever knew about it is in Phab. WhatamIdoing (talk) 03:27, 23 September 2024 (UTC)[reply]

And everything I know is here. There are many dozens of artifacts like this in the corpus, so it happens all the time. -- mikeblas (talk) 01:56, 7 October 2024 (UTC)[reply]

Frequently dumps reference definition after {{references}} tag

Here's another. It seems like Visual Edtior can be tricked into dumping a footnote after the {{reflist}} tag. It'll generate an undefined reference error, since the {{reflist}} invocation clears the references name table.

Again, not a Visual Editor user so I can't

One more, note that there's a pre-existing condition here:

[6]

Maybe this one can be fixed, too? -- mikeblas (talk) 16:25, 30 September 2024 (UTC)[reply]

@Mikeblas, these are all new editors. They're probably clicking at the end of the ref list in the hope that the new ref will get added to the end of the list. WhatamIdoing (talk) 05:56, 2 October 2024 (UTC)[reply]

Could be, but aren't new editors exactly the editors that Visual Editor is meant to help? -- mikeblas (talk) 09:08, 2 October 2024 (UTC)[reply]

Since they're adding refs at all, it probably is helping them. My main point, though, is that "the software put the ref exactly where I told it to" does not sound like a software bug. WhatamIdoing (talk) 16:55, 2 October 2024 (UTC)[reply]

"The software let the user put a reference where it doesn't belong" does sound like a software bug. And we have evidence that happened. -- mikeblas (talk) 19:38, 4 October 2024 (UTC)[reply]

If it's a bug, then it's Bug-for-bug compatibility with wikitext, which English Wikipedians declared to be highly desirable feature.

I think this is probably better thought of as a design challenge instead of a bug. The software does what the user tells it to do, so it's not "unwanted and unintended". By "design challenge", I mean that it will be challenging to design a response that allows this:

Create citation first, while I've got the source information in my copy/paste buffer.
Now go back and type the sentence/paragraph in front of it.

but does not allow this:

Create citation on an empty line somewhere after a references list.

You're welcome to file a Phab: task if you think this problem is worth documenting. WhatamIdoing (talk) 21:18, 4 October 2024 (UTC)[reply]

Good software protects users from doing things that are wrong. Input validation prevents us from providing input that's unacceptable for future processing: I shouldn't be able to enter "Smithville" when prompted for my phone number. The flight control software in a 747 won't lift the landing gear when there's still weight on the wheels even though it's exactly what's indicated as intent by the pilot who presses the "Gear Up" button. Similarly, a wiki editing tool shouldn't allow users to add constructs where they're anachronistic.

Given bad input, it's a bug to allow that input to break the article's rendering. If there's some cultural reason you can't call this a "bug", that's fine, but to me the absence of a fundamental feature is also a bug. Adding an input validation feature would make Visual Editor better. New users (these users who all got in trouble here) most often need the most protection from things like input validation. And experienced users would benefit too, since they sometimes make mistakes.

Maybe it's time to re-evaluate the goal of "bug-for-bug compatibility" and try to improve things like input validation in the editing tools so it's harder to create broken content.

I don't see the challenge in your scenarios. The first has no references list. Add a footnote anywhere. The second has a references list; a footnote can only be added before that references list. -- mikeblas (talk) 01:54, 7 October 2024 (UTC)[reply]

I think the time to reject the goal of bug-for-bug compatibility was in July 2013, or approximately the same day the English Wikipedia demanded that as a design goal. Realistically, I have no hope of that happening until the parser unification project is completed. That project reached a significant milestone recently, but it appears to be operating under Hofstadter's law, so it could be years before it is deployed here.

The simplest way to stop people adding lost refs is to only accept refs on a line that is non-blank. However, that would make the first scenario impossible. (The first scenario could have a reference list on the page.) The second scenario could have multiple ref lists (cf. WP:REFGROUP, or the common practice of putting reflists in each section on a talk page). More pointfully, the second could be intended to have a subsequent reference list even though it hasn't already been placed on the page. WhatamIdoing (talk) 06:37, 8 October 2024 (UTC)[reply]

Once a goal is set, it never changes, even more than a decade later? That seems like a crazy way to run a long-term project. Before this goal was carved in stone, did nobody at all think that new information might discover new information that led to new decisions? Is the project really unable to hear feedback and make changes?

How many articles have multiple reference lists on purpose? How many are correctly placed by these new users? Of course, if this is really necessary, making a warning about it would be fine to: do you really want to make multiple reference lists? That barely makes sense, and you probably don't want to. But type "I REALLY WANT TO" and then press "I know what I'm doing".

Meanwhile, here's another case where a VisualEditor helped a user make a bad edit. -- mikeblas (talk) 15:31, 14 October 2024 (UTC)[reply]

"Is the project really unable to hear feedback and make changes?" I don't know; have you tried to get a significant change through one of our policies recently? It's an uphill task. And just in case I wasn't clear, this was a decision made by experienced editors at the English Wikipedia.

I think there is a chance of it being changed in the future. One option is getting the new mw:Edit check to produce a warning message. This has the advantage that we could control who sees it (e.g., warn the newbies, but not you or me). The other, as I indicated above, is to wait until the parser unification project is done, and see if it could be put it in a list of "small" changes that could be handled during a general update. VisualEditor hasn't been under active development for years (just maintenance, which is substantial), but I assume that the parsing work will result in some additional work. WhatamIdoing (talk) 19:07, 14 October 2024 (UTC)[reply]

Getting a bug fixed shouldn't involve a policy change. I think you're dead wrong in arguing against fixing this.

Here's another example, which was followed up by another edit to add another spurious footnote. -- mikeblas (talk) 22:20, 18 October 2024 (UTC)[reply]

I'm not arguing against changing something here. I'm telling you that finding a way to fix this:

without violating this community's self-chosen rules for the visual editor (e.g., if editors can screw up this way in the wikitext editor, then they need to be able to screw up exactly the same way in the visual editor) and
without breaking actually useful and relevant editing processes (like putting the ref on the page before typing the content)

will be difficult. If you want "easy", you could set up Special:AbuseFilter to warn people when any ref tags are below the reflist.

Also, I'm telling you that, as always, the relevant WMF staff are already assigned to other projects, so it's unlikely to happen this year anyway. WhatamIdoing (talk) 02:52, 19 October 2024 (UTC)[reply]

Telling me this is not a bug is not arguing against changing something? Why do I feel like you're being dismissive and condescending at every turn? There really, really is room for improveent here, even if it has to start with reverting a decision to not be any better than the status quo. -- mikeblas (talk) 18:56, 20 October 2024 (UTC)[reply]

{od}

Yes, @Mikeblas, it's true that telling you that there is a distinction between a feature and a bug is not arguing against changing the software. You are free to dismiss the distinction as mere pedantry if you'd like, though if you ever decide to file a ticket at phab: about this, I'd suggest that you click on "Request a Software Feature" instead of clicking on "Report a Software Bug".

I feel like you're operating under the assumption that I'm in charge of fixing this, or deciding if someone else is allowed to fix it, so you need to convince me personally that it's "a bug". I wonder why that is. WhatamIdoing (talk) 19:48, 20 October 2024 (UTC)[reply]

No such assumption -- I've reported only a few bugs (including this one) in Phab, but I have zero insight into the software engineering process in use here. It is a relief to become certain that you're not in charge of fixing this, as I'd hate to learn that the chance for improvement lies with someone so obstinate and complacent. -- mikeblas (talk) 20:05, 20 October 2024 (UTC)[reply]

So far, I've provided you with practical information that I believe is trustworthy:

Not all unwanted behaviors are called bugs.
There are non-software community reasons that lean towards not disallowing the behavior that you dislike. Not all behaviors that are unwanted by some people are unwanted by everyone.
This behavior might be addressed through design changes, or at least partially addressed, but there are potential risks to such changes. For example, would you rather have a misplaced ref, or no ref?
This behavior could be addressed through mw:Edit check (which is basically Clippy for the visual editor).
This behavior could be addressed (right now, without any dev involvement, and without interfering with anyone's pre-posting editing process) through Special:AbuseFilter.
If you want a "big" fix by the devs (or software designers), you will probably be waiting for years, at least until the parser project finishes.

You've responded by insisting that it should be labeled a bug.

BTW, AFAIK nobody who works on the software ever reads this page. That's why there's a note at the top of the page recommending other places for reporting problems. WhatamIdoing (talk) 20:21, 20 October 2024 (UTC)[reply]

(You screwed up your out-dent, by the way.)

You've fixated on: is it a bug or not? Since you're not involved in fixing it, how is your opinion of the label relevant? I've opened a bug in Phabricator. If it is re-categorized as a work item or feature request or design idea or left-handed flinglebot, I don't care. I do, though, expect the issue is evaluated with an open mind towards making forward progress on the product. That's why your excuse-making doesn't land well.

If the overall attitude you have to feedback is prevalent through other people actually involved in the fix (and I'm afraid it is, as it's not the first time I've seen this kind of complacency and culture-centrism) then I think you're right: nobody can expect improvements to be made in any reasonable time. -- mikeblas (talk) 20:59, 20 October 2024 (UTC)[reply]

(No, I did that on purpose. Template:Outdent would have prevented you from being able to use the Reply tool for the next comment. That is a bug, but it's not one that I have any hope of being fixed this decade.)

I don't think I've made excuses for anything. I've assigned blame in a few cases. That's generally considered the opposite of making excuses. I've pointed out that solving the problem might harder than it looks, which is not the same as saying that the problem is fine. I also think that bullet list shows a lot more information coming from me than merely telling you that intentional behavior isn't what coders call "a bug".

I think you can expect your feature request to be evaluated with not merely an open mind, but with sympathy. However, given the current stats, I don't think you should rely on that evaluation happening this year. There's a chance that someone will stumble across it, but AFAIK there is nobody systematically processing these tickets any longer. (I base this belief on the fact that there are more than a thousand un-triaged tasks open against that project, plus the fact that the Editing team has been re-assigned to other work.) WhatamIdoing (talk) 21:56, 20 October 2024 (UTC)[reply]

Exclude transcluded unbalanced code

See Template talk:Sticky table start#Visual editor issues. When using VE to edit Template:COVID-19 pandemic data/United States medical cases by state or NCAA Division I Football Championship#Appearances by team, or any table that is wrapped in Template:Sticky table start and Template:Sticky table end, the table content is editable as a parameter and difficult to edit.

I've narrowed the issue down to having two opening div tags in the start and two closing div tags in the end templates. Adding the div tags around the table without the templates did not cause an issue. Reducing the templates' div tags to one each did not cause an issue, which seems like some correction or allowance is being made during parsing. This seems related to Limitations > Template issues > Unbalanced code.

Both div tags are needed in the templates. Is there a way to fix this? Maybe exclude the div tags from VE's parsing since the sticky feature is not needed when editing content? Jroberson108 (talk) 02:21, 13 October 2024 (UTC)[reply]

As I understand it, there are no easy and reliable ways to fix this. WhatamIdoing (talk) 19:49, 20 October 2024 (UTC)[reply]