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://en.wikipedia.org/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]

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]