Talk:VisualEditor

Previous discussion was archived at Talk:VisualEditor/Archive 1 on 2015-09-01.

See w:Template_talk:Draft_categories#Functionality_with_VisualEditor.

@Jdforrester (WMF), regarding your summary "Please don't forum-shop. One cross-post is enough," both of these are invites to the English Wikipedia post where discussion was intended to be centralized. Invites are by definition not forum shopping; please familiarize yourself with the talk fork guidance and be sure to respond at the centralized location next time rather than at the other invite, where you created a fork.

There won't be any real answer at any time.

Instead of the normal editing possibilities, on talk pages we are restricted to either only use the wikitext editor, or to this Flow environment, with its massive restrictions on next to everything. Why is the VE not enabled anywhere on talk pages?

Hi there. This question comes up a bunch, and has been answered at length a few times before, but I can't find any of those right now, sorry.

The short answer is that VE is a content editor, and is designed to make writing (long-form) content. In dozens of ways, we've optimised it around writing articles for Wikipedia, Wikivoyage and other wikis. The use cases of a semi-free-form-but-with-odd-rules discussion box are fundamentally incompatible. Providing VE for talk pages would mean making massive compromises both on being a good content editor and on being a good discussion editor. It's an anti-pattern, and it's not going to happen.

I know you have a personal animus with Flow, and that's unfortunate, but it's the option available if you think talk pages don't work well (with which I would agree).

It's just about an editor, the difference between a plain text editor and a wysiwyg editor. There shouldn't be any big difference between editing a text on either the front or the back side of any page. A talk page is as well nothing much different to any other content page, only the content is a bit different.

It's like the difference between old fashioned WordPerfect and the wysiwyg version of the same program. Some prefer the classic mode, some the ve, but the resulting page is just the same.

Why was this definitely not solved question closed? Your answer was just a straw man, not a real one. It's everything but closed.

Sorry, I didn't see a question in your response, just implicit accusations of bad faith and incompetence. :-) If you could re-write one that'd be great, otherwise there's nothing more to say.

Why isn't the VE running on talk pages?

VE is a text editor, and thus should be fully capable of editing on any page, at least simple talk pages.

VE is a text editor,

As I explained, this is not true.

To just quote the first sentence from the other side:
The VisualEditor project aims to create a reliable rich-text editor for MediaWiki.
So why do I have the impression, that either the other side is plain wrong or your "argument" is just a straw man?

The visual editor cannot (abuse HTML definition list formatting to) fake the indentation of paragraphs. Therefore, you are likely to find using it in a talk-page discussion to be frustrating at this time.

...yet. An editor that's capable of editing tables, using templates, setting references etc.pp. is incapable of abusing colons for indentation? Should I really believe this?

Why do I think of a nice idea to push the software pet project that's not as much liked by the community as by the WMFers?

I think you may have to wait until phab:T6521 is resolved.

BTW, there are a few wikis that have the visual editor enabled in the Project: namespace, and which also have some discussions in that namespace (e.g., https://www.wikidata.org/wiki/Wikidata:Project_chat ), and we hear complaints about problems on those pages. I don't think that it would be a good idea to expand the use of the visual editor on such pages at this time.

You insist without any real merit, that a wikipage is not the same as a wikipage. In principle all wikipages behave in absolutely the same manner, they were edited with exactly the same editor up to some time ago, when you a) tried to get so-called structured discussions, first with Liquid Threads, something that failed, now with a bit different layout system Flow, something that as well is stuck in limbo. But if you discount these, the article page uses the same syntax as the talk page, the user page uses exactly the same syntax as the talk page, with one of two available editors the can be edited in exactly the same way as everything else in the wikiverse. With the other one, the VE, you claim that these exactly same pages are magically somehow different, and one of them can't be edited in a wysiwyg-way.

BTW: Using colons to indent, instead of some software hack created by those many devs paid by content creators and talk page users, is frustrating as well, but you choose to ignore this for quite some time and preferred to create shiny new bling instead of boring maintenance. That's at the core of this, not the proclaimed, but not existing, differences between those pages. And the phab is just a strawman as well, if you mange to get templates programmed somehow, the indentation problem should be non-existing. Unles you deliberately choose not to do something about it, to keep this strawman alive.

Hmmm. Does "support VisualEditor on talk pages" have an associated Phabricator Maniphest task?

I tend to agree with Sänger, though I'd perhaps phrase it this way: VisualEditor should work with all regular (non-Special) wiki pages. This includes user pages, talk pages, portal pages, pages in the MediaWiki namespace, etc. It's an extensible editor that we've already installed and committed to supporting. We've seen time and again that the arbitrary distinction put up between VisualEditor support by namespace is confusing and annoying to users.

I think there are talks about unifying the wikitext and VisualEditor editors. Eliminating or masking the difference between the two or more editors that we have may somewhat neatly resolve this issue.

To see the result of these "talks", go to Special:Preferences#mw-prefsection-betafeatures and enable the "new wikitext mode" beta feature.

NB that it's not really about "unifying the [old] wikitext and VisualEditor editors". This will not merge the code for EditPage.php or Extension:WikiEditor with Extension:VisualEditor. The only thing that's being unified is the user experience, i.e., the user gets VisualEditor's black-and-white toolbar and VisualEditor's built-in tools (such as pasting a URL to a Wikipedia page and getting an internal wikilink instead of an external link) everywhere. There will still not be any visual mode on the talk pages.

And there is still no believable reason given, why a wikipage is not a wikipage. It's just futile justification lyricism for not wanting to do anything against Flow.

Short update:

In the current Community Tech survey the VE is used in discussions, so the whole "argument" with the non-suitability was proven as a straw-man by the WMF on one of its own pages, yet they still insist that a wikipage is not a wikipage.

See this archived proposal as an example (and as another attempt to stifle any discussion about VE on talkpages for pure political reasons). Grüße vom Sänger ♫^(Reden) 12:26, 3 December 2017 (UTC)

This seems like something that really should be reopened now that previous proposals for a complete talk page overhall have been left behind. Talk pages are wikitext, it seems silly to arbitrarily disable the visualeditor, when so many users use it successfully to edit pages. It's actually more difficult to edit talk pages than the articles themeselves now, because on in articlespace you have a pretty functional and usable WYSIWYG editor for any and all purposes, whereas on the talk pages you either have to use the "reply tool", which is a kind of crippled visualeditor that works well-enough-ish most of the time to post new comments (but you're screwed if you want to edit or fix a mistake/formatting once you've posted your reply), or edit the wikitext directly. The pages are literally wiki pages! It seems bizarre not to let users interact with them the same way as any other page on the wiki...

the link mr Sänger posted above is dead now, a bit of rooting around and I found it, here: https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2017/Archive#Release_VE_on_Talk_pages

All this drama about talk pages is all a bit before my time being a regular contributor to wikipedia so has somewhat gone past me, but looking at it in retrospect, copying and pasting from the structured discussion FAQ here, I think I have figured out the reason this was never done:

Instead or in parallel of Structured Discussions, will VisualEditor be enabled on talk pages?

No. This question comes up quite often.

• VisualEditor (VE) is designed to edit content, plain pages of text.
  • Talk pages aren't encyclopedic content. Many of the tools and design patterns that make VE nice to use to edit content make it poor to use for discussions.
  • To make it usable for discussions, we would have to remove or break many of those patterns in VE.
• Traditional talk page discussions often appear fairly well-structured through the use of section headers, indentation and the like. However, this kind of structure cannot be parsed by software to determine with certainty who has replied to whom.
  • In Structured Discussions, each post is independent with a unique ID, linked to other posts and to a Topic (also with a unique ID), with a specific history, and all posts can be targeted precisely. It would be possible in the future to have conversations at multiple places, to move topics or replies, and to create sub-discussions with Structured Discussions. Classical talk pages, using VE or not, do not currently have that feature, and adding it might prove cumbersome.

That is to say, it was deemed counter to the goal of implementing the real reform they wanted to implement, to move away from wikitext pages altogether (because wikitext pages cannot be "parsed" properly as discussion threads)

and, of course, that may all be true, but... this project was essentially abandoned in the end right? And they decided to stick with wikitext talk pages? So, not weighing in on whether that was a good or bad decision (I personally couldn't care less lol), with the decision to stick with essentially "normal wiki pages" as the format talk pages are written in having been decided, surely there's no longer any reason not to just enable the (already perfectly adequate) WYSIWYG editor on talk pages? It seems all of the animus behind not doing so has long since evaporated now, no? After all, there is no plan to replace the wikitext talk pages with a format that meets the requirements cited as the reason for not enabling visualeditor anymore...

This thread on en.wp is the story of a 70k+ editcount editor hitting "convert" over and over in VisualEditor and causing the loss of information from existing citations. Plenty of diffs in the thread. I don't know whether this problem comes from Citoid's output or from VisualEditor not checking existing template parameters to ensure it's not deleting anything, so crossposting to both talkpages. Folly Mox (talk) 11:25, 14 May 2024 (UTC)

This flaw is heartbreaking.

An article I created was impacted by this: a user used the "Convert" button in visual editor, and they thought they were "improving" the article ... and the edit convinced them it was better (citation in footnote looked cleaner). The user did not realize that the Citoid script was deleting some information from the citation!!!! (usually author name, publication date, publisher name, ... but also other data).

My article lost data from about five citations (about 1/3 of those that Convert script was applied to). But the user that used Convert script has done over 50,000 edits with that tool (I think that # is correct, I have not confirmed it). Does that mean that perhaps 10,000 citations have had data deleted?

This needs to be addressed ASAP !! [Signed user Noleander, cannot get signature to work here]

I am no programmer or website creator, so please pardon my very layman language.

When using the automatic cite-tool in VisualEditor the result from the source vary. I had the following result using just the url to a random article for New York Times and a random article from Swedish source Sveriges Radio:

• Trebay, Guy (22 maj 2013). ”The Architecture of Seduction” (på amerikansk engelska). The New York Times. ISSN 0362-4331. Läst 23 februari 2024.
• Radio, Sveriges (23 augusti 2022). ”Operationsresorna – Rumpförstoring i Turkiet | Del 1/2 - P1 Dokumentär”. sverigesradio.se. Läst 23 februari 2024.

The New York Times article is perfect. The Sveriges Radio have at least the following problems: "Sveriges Radio" is interpreted as the author (first and last name). sverigesradio.se should be written as Sveriges Radio". This error from Sveriges Radio is very consequent.

Many other Swedish sources works as badly, but others dont. Among the once working fine are many small local papers. That has led me to believe there is some standard or harmonised guideline for how to fill in a header for web pages, that is not very work intensive. And that Visual Editor uses this standardized way.

What should I tell the webmaster at Sveriges Radio, so they can standardise and harmonice its headers in the same way?

Maybe there is no use to try to discuss with webasters?

What, and how, can a user do to improve the VisualEditor source tool to interpret information from sources?

Hmm. Not a word. Have I posted this in the wrong place?

User:LittleGun, the citation generation backend for VisualEditor is Citoid. The output of this library is deeply unreliable for many webpages for a number of reasons. There's some history of discussion at Talk:Citoid from around a year ago, but it doesn't seem like much has changed in the interim. Folly Mox (talk) 11:28, 14 May 2024 (UTC)

So I was upgrading MW from 1.39 to 1.40 and following the guide here and here, I set $wgReadOnly in the LocalSettings.php, all things good, after completing the upgrade I started checking some of the pages for content and forgot to delete $wgReadOnly from config.

When trying to edit a page with VisualEditor, I was getting this error: Unable to fetch Parsoid HTML

I was sure this was an upgrade issue but it turns out that deleting the property is the fix.

Installed software

Product	Version
MediaWiki	1.40.1
PHP	8.1.14 (fpm-fcgi)
ICU	67.1
MariaDB	10.6.11-MariaDB-1:10.6.11+maria~ubu2204
Lua	5.1.5
Pygments	2.11.2

• In MW 1.39, VisualEditor still works when $wgReadOnly is set.

Cheers

VE-0.1.2 on MW-1.39.4 does allow the selection of "packed" for a gallery but does not include it in the resulting Wiki-code. Thus galleries always appear in mode "traditional". Am I the only one experiencing this issue? If not, could somebody point me to the right place for filing a bug report? I have never done it before. Thanks!

You might try the Project:Support desk.

Hi,

I would love to be able to use the VisualEditor in projects and projects talks pages, please consider make it possible. Thank you for your attention,

This requires a config change. As long as there is community consensus (e.g., a discussion on that wiki) and no technical problems (e.g., the namespace does not contain huge pages like w:en:WP:ANI), then the team is happy to honor such requests. The instructions are in m:Requesting wiki configuration changes.

Hi, FYI someone finds a bug, see this discussion on frwiki for more detail.

https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/VisualEditor/+/edec1ab393071499d9bb0056eb7c86952581de28

I remembered here about this interface message: https://translatewiki.net/wiki/MediaWiki:Visualeditor-preference-betatempdisable/en

I think it needs to be reformulated.

Fixed by @Matma Rex. Thanks :)

Tracked in Phabricator
Task T336101

Hi, many users are reporting that a mass adding of the magic word __SOMMAIRE__ ( like __TOC__) is happening on the French Wikipedia (1, 2), when editing with VisualEditor. Do you know anything about this?

User:SSastry (WMF), is this phab:T336101?

Yes, it is.