Jump to content

Wikipedia talk:VisualEditor/Archive 8

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 5Archive 6Archive 7Archive 8

Disable "This is not an article; this is a disambiguation page," box

Hi, Is there any way I can disable the "This is not an article; this is a disambiguation page," light brown box that comes up?, I find it more of a hinderance than of help, Many thanks, Kind Regards, –Davey2010Talk 18:31, 9 October 2023 (UTC)

It looks like that pop-up is how VE displays {{Disambig editintro}}. Presumably, you could hack your personal .js file to hide it. There is some related discussion at MediaWiki talk:Common.js. – Jonesey95 (talk) 00:18, 10 October 2023 (UTC)

Infobox references/citations

I deleted 2 references from an infobox using Source editor {one was already in the article's References list, the other is now after I added text and the reference to the article which should have been added over a year ago}. Should I have been able to delete them using VE? Mcljlm (talk) 16:16, 19 October 2023 (UTC)

Where can I find the percentage of edits to date that were made using VE?

Félix An (talk) 06:12, 1 November 2023 (UTC)

You might be able to get that from Wikipedia:Request a query, but I suggest that the question you're asking might not tell you what you really want to know. For example: since Wikipedia's creation, or just since the visual editor existed? Or during the last year, so you can find out about current usage patterns? And do you want to include bot edits? Twinkle and AWB? Or just "manual" edits by humans? WhatamIdoing (talk) 06:33, 1 November 2023 (UTC)

Auto-save / Saving a draft

If I edit an article but accidentally close the tab before saving (or my browser crashes), is a draft auto-saved? Or is there a way to save a draft before publishing the changes? —danhash (talk) 20:47, 22 November 2023 (UTC)

https://en.wikipedia.org/wiki/Gilbert_Stuart

If possible, I'd like to switch the black and white image of William Curtis (on the page with many examples of GS's work) with a iPhone color image of the same picture sent to me by the owner as a replacement. Can someone help me? I can email the image and the permission. Thanks. devan03@Emory.edu

DEvans2 (talk) 15:38, 10 January 2024 (UTC)

Please post your request at Wikipedia:Help desk. – Jonesey95 (talk) 23:38, 10 January 2024 (UTC)
thanks. DEvans2 (talk) 21:48, 11 January 2024 (UTC)

A better way to handle limitation workarounds

I'd like to suggest we make it clearer when there are tools or procedural workarounds that can mitigate any of the items listed in section § Limitations, as well as tactics for avoiding any of the known limitations in the first place. For example: for the numeric ref names issue, we have script User:Nardog/RefRenamer to fix it after the fact. The first item in the list, "Not available in talk or discussion namespaces", has what appears to be a possible workaround (the Reply tool) but the way it is worded and styled as part of the same paragraph as the limitation, makes me a bit unclear as to whether this is being touted as a workaround or not.

I can see a couple of ways to do this:

  • a completely separate section on workarounds and avoidance strategies; if there's any advantage here, it's probably that the number of bullets will be a lot smaller than in the limitations section.
  • interpolated additions to each bullet that has any kind of workaround, maybe in the style of a definition list or a FAQ were you have a main bulleted entry, followed by a more indented, and possibly differently styled, response.

I think I prefer the latter, although it will make the Limitations section a little longer. For example, we might have:

  • Not available in talk or discussion namespaces – On the English Wikipedia, VisualEditor is not enabled for any talk pages, on the Template or Wikipedia namespaces, and on several of the namespaces that are rarely edited. The "Edit" button for VisualEditor is not available on pages where VisualEditor cannot be used.
    • Workaround: The Reply tool has a visual mode based on VisualEditor, as well as a wikitext mode with a live preview.
  • Slower – Loading longer pages into VisualEditor can be significantly slower than the source editor for some users.[1]
  • Data in merged cells is deleted – If rows or columns are moved across them.
    • Workaround: Unmerge the affected areas before moving, and merge them again afterwards.
  • Numeric reference names – Currently, VE automatically adds numeric ref names with a colon prefix, i.e., ":0", ":1", ":2", and so on. There has long been interest in having VE support named references.
    • Repair: After the fact, numeric reference names may be converted to mnemonic names using user script RefRenamer.
  • Wikilink changes – May unnecessarily turn a simple link into a piped link when a change to the link text involves redirects.
    • Workaround: You can do it in two steps; once you have a link and want to change something, the link text and link target are changed in separate ways. 1) Click the link and then "Edit" to change the link target; and: 2) Change the link text. Alternatively you can delink it, alter the link text, and link it again.

and so on. (Styling note': I would avoid bullet character on the indented lines, but couldn't figure out the markup for that above.) Also, we should probably add phab links inline, where available. Thanks, Mathglot (talk) 03:28, 2 February 2024 (UTC)

Added adapted version of PrimeHunter's workaround for piped links, as suggested at WP:VPT. Needs proofreading to see if I got your basic idea right, and if I adapted it properly from the specific 'Romans' case to the general case. Mathglot (talk) 22:43, 2 February 2024 (UTC)

Traylblazor

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

 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)

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)

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)
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:
Hope that helps. -- mikeblas (talk) 15:06, 20 September 2024 (UTC)
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)
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)
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)
The human brain is pretty good at remembering irritating things. ;-) WhatamIdoing (talk) 00:53, 21 September 2024 (UTC)
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)
Everything I ever knew about it is in Phab. WhatamIdoing (talk) 03:27, 23 September 2024 (UTC)
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)

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)

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

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:

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

@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)
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)
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)
"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)
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)
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)
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)
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)
"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)
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)
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)
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)
{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)
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)
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)
(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)
(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)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:VisualEditor/Archive_8&oldid=1292406015"