VisualEditor/Feedback/Archive/2013/11

Seems to have a very big bug on fr.Wiki that could cause lots of damage. VERY FAST ACTION NEEDED

The VE or something else seems to add unwanted caracters with each edit (example). This could do a lot of damage and needs to be adressed fast. Thanks a lot. Letartean (talk) 20:34, 4 November 2013 (UTC)

It was Parsoid, and it was fixed. Thanks for letting us know about this. Elitre (WMF) (talk) 08:57, 5 November 2013 (UTC)

What is the place to report those kinds of bugs for immediate action? In this event, hundreds of pages could have been damaged or even more depending on the moment of the day where the bug happens. Is there a "Emergency switch" somewhere at the local level (on each Wiki using the VE) or at a higher level that can be used to prevent corruption from bugs by disabeling the VE? During this event, all edits made with the VE were causing corruption problems. If this happens again, we need to be able to address the problem in a timeline that is seconds long or at least a couple of minutes long (as opposed to the 45 minutes to an hour that it took that time). Have a nice day. Letartean (talk) 16:24, 7 November 2013 (UTC)

IRC would be that place, either #mediawiki-parsoid or #mediawiki-visualeditor. It only took 10 minutes for Parsoid devs to know about this, and (AFAIK) there isn't a real emergency switch (well, devs will try to revert the broken deployment, but that can go wrong as well, unfortunately). I personally checked all the edits made during that time on fr.wp (and it.wp) and reverted those which were not noticed by patrollers, and my colleagues did the same for other wikis. We did that in the past, and will do it in the future if similar emergencies arise. Thanks. Elitre (WMF) (talk) 16:43, 7 November 2013 (UTC)

$wgVisualEditorNamespaces problem

Hi,

I'm trying to get visual editor to work in other namespaces. I want it to work in my custom namespace NS_PROJ in addition to main and this works fine by adding.

$wgVisualEditorNamespaces[] = NS_PROJ;

But then I also want the user namespace to be able to use visual editor there too.

I have tried:

$wgVisualEditorNamespaces[] = array ( NS_PROJ, NS_USER );

But it doesn't work...

How should this setting by set to get it to work?

BR, Daniel 195.60.68.155 15:50, 12 November 2013 (UTC)

Two things:

1. The constant is NS_PROJECT, not NS_PROJ
2. $array[] = array( $val1, $val2 ); does not do what you think, it adds a single element to $array, containing another array of two values. What you want is either $array[] = $val1; $array[] = $val2; or array_push( $array, $val1, $val2 );

HTH ESanders (WMF) (talk) 16:03, 12 November 2013 (UTC)

Thanks, got it working now.

BR,

Daniel 195.60.68.155 07:48, 13 November 2013 (UTC)

Media Button Placement Re-Think?

I disagree at the placement of 'media' in the more menu. Is this just temporary?

The current Wikitext editor I see as I type places embed file within the first 4 on the list and I think that kind of media priority would be good to continue in the Visual Editor. After all, it's a 'visual' editor.

If we want wiki pages to slowly become more media-rich (and I think they really need to in an appropriate way of course), then having the add media button more prominent will at least remind new editors to think. "Hey, Wikipedia wants appropriate images, is there one I can donate/upload/create to enhance this article while I'm here?" Anything else seems inconsistent with recent campaigns for commons uploads.

As it is, the media button in the 'more' dropdown seems to continue to make media a second class citizen. Just a little less important than Superscript??? Really? MarkJurgens (talk) 03:47, 19 November 2013 (UTC)

As you guessed, the Menu layout is, like pretty much everything else at this stage, highly temporary :)

While we want to make the toolbar simpler and shorter, we must also take a lot of other aspects into account: that's why your feedback on this matter would be highly appreciated at en:Wikipedia:VisualEditor/Feedback/Toolbar.

Bug 38030 and related ones might interest you as well. Thanks. Elitre (WMF) (talk) 14:36, 19 November 2013 (UTC)

I saw you found that page yet, very well. Elitre (WMF) (talk) 14:46, 19 November 2013 (UTC)

December office hours for VisualEditor

Hello. I wanted to tell you that the engineering department is hosting additional office hours to discuss VisualEditor. The first will be held on Monday, 2 December, at 1900 UTC. The second will be held on Tuesday, 3 December, at 0100 UTC. Please join as Product Manager James Forrester discusses VisualEditor and upcoming plans. Logs will be posted on Meta after each office hour completes. (If office hours are heavily attended, it can be difficult to get to all questions, but if you want to ask a question and cannot attend or do not speak English, please let me know your question *at my talk page* by Dec 1st and I will present it among possible discussion topics.)

Thanks! Elitre (WMF) (talk) 18:56, 19 November 2013 (UTC)

Page with incorrect syntax isn't editable in VE for the most part

Pages with broken wikitext might behave differently in the new parser compared to the old one.

mw:localisation gives strange results in VE. From the section "Messages that should not be translated" on, starting with the code text # do not translate or duplicate this message to other languages, it fails rather miserably. At first glance I would blame it on the starting # character in that sentence of code. Of course, that isn't a rare character in code, so VE should be able to handle it. Fram (talk) 13:06, 21 November 2013 (UTC)

I'm not sure what "fails rather miserably" means. Do you mean "changes the font for the rest of the page, in exactly the way it ought to do when the <code> never gets properly closed"?

The line you mention has this for its wikicode:

* append a comment <code># do not translate or duplicate this message to other languages</tt> to the English translation

Those two tags are not interchangeable; you cannot close a <code> tag by providing a </tt>. If that's your only complaint, then you'll find that it looks much prettier now that I've manually corrected the wikitext error. Whatamidoing (WMF) (talk) 20:36, 30 November 2013 (UTC)

"fails rather miserably" means "can't edit it any further", which is the purpose of a visual Editor... And apparently in wikitext, you "can" close a code tag by providing a /tt, as that used to worked quite allright there... You perhaps shouldn't be doing it, and VisualEditor is more rigid, less flexible with these things than wikitext... Anyway, thanks for correcting it. Fram (talk) 10:08, 2 December 2013 (UTC)

I can do minimal editing, i.e., removing whole paragraphs and adding new ones.

If you think it worthwhile, I can file a bug that says, "VisualEditor should provide bug-for-bug compatibility with MediaWiki, so that unpaired HTML elements involving the deprecated tt tag are treated as if they were properly paired anyway", but I'm thinking that's likely to get closed as a WONTFIX. What do you think? Is it worth reporting that VisualEditor works properly even when MediaWiki parsing plays fast and loose with the markup? Whatamidoing (WMF) (talk) 18:23, 2 December 2013 (UTC)

Worth reporting to our devs? Uh, no, obviously not. The chance of them allowing things that are procedurally incorrect but work anyway seems to be minimal. They aren't even inclined to allow things that work and are procedurally correct but don't fit their "worldview" (e.g. wikitext in VE), so adding a bug for this is pointless. Plus, considering that about one in six pages on enwiki renders incorrectly in VE but correctly in view mode (for a number of reasons, some perhaps similar to this one) and that those problems aren't even considered high priority (no, we first need to have VE in books and categories!), I don't think distracting the devs with this would be fruitful. Fram (talk) 09:06, 3 December 2013 (UTC)

This is the way Parsoid works in that page, where the syntax is incorrect. Helder 10:11, 15 December 2013 (UTC)

Skin support

Unfortunately this software is still unavailable for the Modern skin. Seems like a not very large-volume task... IS there a bug number for it? Gryllida 03:45, 27 November 2013 (UTC)

Since I haven't found any, and I am not sure this is coming, do you want me to file one for you? Regards, Elitre (WMF) (talk) 11:14, 27 November 2013 (UTC)

It's been a long time since I've heard anything about this, but on the twin assumptions that my memory is correct and that nothing has changed since then here's the situation:

The Modern skin is not supported by the WMF and hasn't been for a long time. Any changes that need to be made to be compatible with VisualEditor (or anything else) will only happen if a volunteer dev chooses to do it. Unfortunately, Modern isn't that popular (so most volunteer devs won't care about it), and I've been told that it's a bigger task that it seems like it "should" be, so I'm not sure that it will happen any time soon, or ever.

If you wanted to speed this along, then your first step should probably be finding out who is maintaining Modern for other purposes, and asking one of them personally to look into it. If you search and can't find anyone maintaining that skin any longer, then please let me know. Whatamidoing (WMF) (talk) 20:22, 30 November 2013 (UTC)

I asked James about this, and you can find out more in this log from 14:46:51. The TL;DR is that support for Modern or other skins isn't planned (although volunteer developers can try their hand at this if they want to). Thanks. Elitre (WMF) (talk) 15:17, 3 December 2013 (UTC)