Wikipedia:VisualEditor/Feedback/Archive 2013 5

References

I am missing the way how to add references. Juandev (talk) 12:17, 29 March 2013 (UTC)

It appears that adding or editing citations and references is not yet available. I want to suggest a feature for when cites are enabled: autofill. It would make it much easier for editors if they could just paste a URL and have the title, author and date automatically filled into the correct cite template. Perhaps this could be implemented only for the most-cited websites, which we're familiar with the structure of; maybe an automated script could identify titles, dates and bylines for any website; or maybe a combination of both could be used. Another useful function would be to automatically add a references section when an article's first cite is made, rather than spit out an error that there's no references section.

And why wait? These features could be added to the current editor. I'm sure they would increase the number of cites by taking away the burden. Pdxuser (talk) 02:33, 27 April 2013 (UTC)

Yeah, for me as an experienced editor, and for many of the "new" editors that I work with adding citation is an important task. I felt almost helpless and like an idiot because I couldn't figure out how to add a citation. Back to the old way I go! :) SarahStierch (talk) 04:32, 3 May 2013 (UTC)

@SarahStierch: As said before, references are hugely important and of course we won't "ship" before they're ready. Indeed, we hope to make them available in the next few weeks (albeit in basic form). Jdforrester (WMF) (talk) 21:03, 8 May 2013 (UTC)

Odd issue with white space

I tried to clean up white space on this rev of Belmont Report, in section "The Belmont Report Today". It highlit the white space in green and said I couldn't edit it. I was able to remove the white space by placing the cursor on the line above and using the delete key instead, though I then got a "review" screen showing I had duplicated a paragraph! I can try to reproduce the exact sequence if it's of interest. Mike Christie (talk - contribs - library) 00:33, 4 April 2013 (UTC)

@Mike Christie: The reason you got the selection highlighted in green is that the whitespace is converted into a number of <br />s which VisualEditor can't currently handle (and so it stops you from breaking it). You should, however, have been able to select over it and replace it by pressing delete/backspace or typing. Sorry for the confusion. Jdforrester (WMF) (talk) 21:18, 8 May 2013 (UTC)

Edit summaries have no 'memory'

With a normal edit summary (in Firefox on a Mac), I can type it once, and it's stored in the browser, so if I want to use the same edit summary a hundred times (and I do), I don't have to re-type the whole thing. I just start typing WPM and it pops up the options, the first of which for me is going to be WPMED assessment per WP:MEDA. With this edit summary system, it doesn't seem to know about the previously used ones, so I either have to re-type the whole thing, which is tedious, or give a less informative edit summary, which I think most editors will find very tempting. Can this be fixed? WhatamIdoing (talk) 01:56, 11 April 2013 (UTC)

I second this. While a textarea is nice, it encourages people to write essays for their summaries, and it also lacks browser autocomplete support. — This, that and the other (talk) 09:52, 19 April 2013 (UTC)

This is a big issue for me too. I do mostly small repetitive edits and I really miss the ability to double click on the edit summary box and select from among the edit summaries I have used in the past. Thank you. SchreiberBike (talk) 05:04, 7 May 2013 (UTC)

I'd noticed this too; have filed as an enhancement. Note that quite soon this box will be a mini-VisualEditor surface, however, which changes things. Jdforrester (WMF) (talk) 21:33, 8 May 2013 (UTC)

Tried to add a {{cn}} tag

I tried to add a {{cn}} tag to an article. It added it, but it also added <nowiki> tags around the whole paragraph.

I tried to report this in the "report error" dialog, but failed to submit my report as I couldn't find a "submit" button or the equivalent. Maproom (talk) 07:33, 14 April 2013 (UTC)

@Maproom: You don't add wikitext to articles via the VisualEditor ever; when you type something in that would otherwise be wikitext, it gets "escaped" for you by the back-end to stop accidental breakage. In this particular case, templates are coming soon but not yet supported - sorry for that. The "report error" dialog is now fixed. Jdforrester (WMF) (talk) 21:20, 8 May 2013 (UTC)

Cannot scroll to the text at the left side.

The text on the left side of the article hides behind the language links. I cannot scroll to this text at the left side. Tirkon (talk) 11:58, 14 April 2013 (UTC)

@Tirkon: That's very odd! What browser and skin were you using? Does it happen on all pages, or just some of them (and if so, which ones)? Jdforrester (WMF) (talk) 21:39, 8 May 2013 (UTC)

Redirects

Please make it work on redirect pages (where the sole content is #redirect article) --Mahanga (Talk) 23:00, 5 March 2013 (UTC)

This is one of the things we want to get to soon. Thanks for the feedback! Jdforrester (WMF) (talk) 17:44, 27 April 2013 (UTC)

@Mahanga: As an update, the code to avoid editing a redirect and ending up with the text of the target page is mostly done; the steps to have something useful to edit through VisualEditor for redirect pages may take a little longer, sorry. Jdforrester (WMF) (talk) 23:19, 11 May 2013 (UTC)

Noticeable but simple bug

Tracked in Phabricator
Task T49452

On any page with VE enabled, click "edit source". The "edit source" tab is not displayed as "activated" on the action=edit page - you can see the activated tab "flash" away as VE JavaScript is loaded. — This, that and the other (talk) 10:11, 19 April 2013 (UTC)

@This, that and the other: As the template says, this has been fixed and will be deployed as part of the new version of the site's software on 20 May. Sorry for the bug! Jdforrester (WMF) (talk) 22:32, 11 May 2013 (UTC)

Edit tab loses accesskey

Tracked in Phabricator
Task T49396

After the last update, my accesskey accessor for edit mode is no longer connected to either of the edit tabs it seems. —TheDJ (talk • contribs) 10:14, 19 April 2013 (UTC)

I encountered the same problem. It still works on talk pages, though. WhatamIdoing (talk) 15:24, 19 April 2013 (UTC)

@TheDJ and WhatamIdoing: As the template says, this has been fixed and will be deployed as part of the new version of the site's software on 20 May. Sorry for our mistake! Jdforrester (WMF) (talk) 22:32, 11 May 2013 (UTC)

Oldid gets lost

Tracked in Phabricator
Task T49453

When you are on the 'edit source' page of an oldid page, then click 'edit' (for the VE), the VE opens the latest version, instead of the oldid. —TheDJ (talk • contribs) 10:16, 19 April 2013 (UTC)

@TheDJ: Sorry about this bug; will make sure it gets fixed soon. Jdforrester (WMF) (talk) 22:33, 11 May 2013 (UTC)

Unwanted spans

Tracked in Phabricator
Task T49737

This resulted in several re-used refs getting screwed up in parts of the article that I didn't touch. WhatamIdoing (talk) 15:21, 19 April 2013 (UTC)

This is proving to be a serious problem for me. I've had to discard several attempts to make minor changes (like capitalization) because of the VE changing <ref name=Something /> into this busted <ref name=Something></span>. WhatamIdoing (talk) 00:11, 23 April 2013 (UTC)

Same, I can't use it without it adding <span></span> after refs, or editing other parts of the page, even chemboxes! No-one can even edit them at the moment with VE; is this some built-in article maintenance? You can't possibly attribute many of these edits to those trying to edit the page, if VE goes ahead and edits (read breaks) the rest of the article. Tomásdearg92 (talk) 02:30, 25 April 2013 (UTC)

@WhatamIdoing and Tomásdearg92: Sorry about this nasty bug. As the template says, this has been fixed and was deployed here as part of the site's software on 6 May. Jdforrester (WMF) (talk) 22:37, 11 May 2013 (UTC)

Undefined article link problem

Tracked in Phabricator
Task T49413

Also, I tried to link to the article Stroke, and the list showed the article as an option, but when I clicked on it, it then said 'undefined' and when I tried to click elsewhere to get away from that dialog box, it deleted the entire paragraph (which naturally I didn't save, so there's no diff, but I did review it and saw that it really was trying to delete it). WhatamIdoing (talk) 15:21, 19 April 2013 (UTC)

@WhatamIdoing: Apologies for letting this bug through. As the template says, this has been fixed and was deployed here as part of the site's software on 6 May. Jdforrester (WMF) (talk) 22:39, 11 May 2013 (UTC)

autocomplete

Tracked in Phabricator
Task T49413

i tried to create a link using autocomplete, but when i pressed the actual link, the value in the texbox changed to "undefined". קיפודנחש (aka kipod) (talk) 22:13, 19 April 2013 (UTC)

Can you add with which browser + version this occurred ? I gather you:

1. Selected text
2. Clicked the insert link button
3. Starting typing an internal link
4. Selected a internal link from the list
5. The value you saw in the textfield became 'undefined'

Is that a correct summary ? I think I was able to reproduce this issues in Safari 6. I also note that after that, if I try to click outside of the dialog, the dialog will become white, but will not close. On the console I see: "TypeError: 'undefined' is not an object (evaluating 'dataElement.attributes.title')" —TheDJ (talk • contribs) 13:30, 20 April 2013 (UTC)

yes, i think it's good summary. i was not very precise, and disabled visEd immediately after i encountered the issue. i believe i tried it with Chrome (either 26 or 27 beta - i have both on on different machines, and can't recall which i used when this happened). peace - קיפודנחש (aka kipod) (talk) 19:58, 22 April 2013 (UTC)

I've got this problem in Firefox 20.0 on a Mac. WhatamIdoing (talk) 00:06, 23 April 2013 (UTC)

@קיפודנחש, TheDJ, and WhatamIdoing: Hey, sorry for not seeing this until now; the bug was found and the fix deployed here on 6 May. Jdforrester (WMF) (talk) 22:40, 11 May 2013 (UTC)

<syntaxhighlight lang=""> not supported yet

Tracked in Phabricator
Task T49579

<syntaxhighlight lang="c"> ... </syntaxhighlight> isn't rendered as expected Tobias (Talk) 22:25, 19 April 2013 (UTC)

@Church of emacs: This has been fixed and was deployed here in late April. Jdforrester (WMF) (talk) 22:45, 11 May 2013 (UTC)

Strange markup in reference section

Tracked in Phabricator
Task T50367

When doing a small copy-edit, I looked at the review window and it had added </ol> after <references >. That is, the line now looked like <references ></ol> I figured I should see what happened if I saved, and it turns out that nothing looks abnormal, except for the continuing presence of that markup. It also removed a space between the words "Paperback" and "ISBN" for some reason. Risker (talk) 00:47, 23 April 2013 (UTC)

@Risker: Hey Risker; the corruption of the <references /> blocks was a very irritating bug, which we fixed and got deployed here on 6 May; sorry for not responding sooner. I will hunt down the cause of the "Paperback ISBN" -> "PaperbackISBN" in your edit for you. P.S.: Definitely reproducible; have filed as a bug. Jdforrester (WMF) (talk) 23:23, 11 May 2013 (UTC)

Shift + Left/right arrow

Tracked in Phabricator
Task T49711

I expected shift+left arrow or shift+right arrow to adjust the text selection, not to be a shortcut for deleting characters. John of Reading (talk) 17:58, 23 April 2013 (UTC)

@John of Reading: Sorry about this nasty bug (that was specific to Firefox). We've put in a quick fix which will be deployed here as part of the site's software update on 20 May. My apologies for not spotting it before it was deployed. Jdforrester (WMF) (talk) 22:46, 11 May 2013 (UTC)

Visual editor has problem with <div dir="rtl"><div>

In User:Yamaha5/sandbox I tested it for farsi every thing was OK except <div dir="rtl"> which cause the test disable. in fa.wiki because of mixture of farsi and english we use direction inside the text so it will cause problem for RTL languages Yamaha5 (talk) 23:49, 26 April 2013 (UTC)

@Yamaha5: I've added support for <div> elements, so you will be able to edit text inside them (once the new software is deployed here on 20 May).

However, adding the ability to label text as ltr or rtl, or mark it up in a different language, is a larger piece of work, which I hope will progress quickly to make it easy for mixed-text editors. Jdforrester (WMF) (talk) 22:52, 11 May 2013 (UTC)

Citations are a big gap

The main reason that I'm not currently using the Visual Editor is that I can't insert citations, and with verifiability being a pillar of Wikipedia, I can't really work without them. Slashme (talk) 15:00, 29 April 2013 (UTC)

@Slashme: Yes, I agree; we're working on references (and templates to go with them) right now, and we hope to make that available soon. Jdforrester (WMF) (talk) 22:53, 11 May 2013 (UTC)

Unable to consolidate paragraphs

Tracked in Phabricator
Task T50366

I tried to make the article Victory Corps into one paragraph, but the Visual Editor will not let me delete the line breaks. Maybe it is because the lines end with citations? Andrew³²⁷ 15:45, 29 April 2013 (UTC)

@Andrewman327: It looks like the problem is indeed the paragraph-ending-with-citations, yes; thanks for the bug report! I've added it to our bug tracker and we'll get it fixed as soon as possible. Jdforrester (WMF) (talk) 23:03, 11 May 2013 (UTC)

Shift + arrow

At the moment, shift + arrow has the same behaviour as delete or backspace, rather than highlight, which is different from the browser's normal behaviour. What happened? Deryck C. 11:00, 6 May 2013 (UTC)

@Deryck Chan: Sorry about this bug; we've fixed it and the code went out here on 6 May, as part of the regular deployment cycle. Jdforrester (WMF) (talk) 23:38, 11 May 2013 (UTC)

Could not save

It worked well to make a link, but nothing happened when I clicked on Review and save. Ziko (talk) 19:42, 6 May 2013 (UTC)

I experienced the same problem while fixing a typo. AutomaticStrikeout (T • C • Sign AAPT) 01:25, 7 May 2013 (UTC)

@Ziko and AutomaticStrikeout: Sorry to hear this - can you give me any more information so I can track it down and get it fixed? For example, what browser were you using; does this regularly happen on a given page, on all pages, when making a certain kind of edit? Thanks for any details you can give us! Jdforrester (WMF) (talk) 23:40, 11 May 2013 (UTC)

To answer your questions, I'm using Firefox and I only tried it on one page. AutomaticStrikeout  !  C  Sign AAPT  00:02, 12 May 2013 (UTC)

@AutomaticStrikeout: Thanks! Do you still get it? I think it might be something we fixed a couple of weeks ago (and which would have been updated around the time of your post here) - if you still get it, we'll need to investigate and fix it better. :-) Jdforrester (WMF) (talk) 01:51, 12 May 2013 (UTC)

Okay, it worked this time. AutomaticStrikeout  !  C  Sign AAPT  02:00, 12 May 2013 (UTC)

Warning: Unresponsive script

Three times when trying to edit List of European regions with alternative names, I received the message "Warning: Unresponsive script A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete. Script: http://bits.wikimedia.org/wiki.riteme.site/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2CloadingSpinner%2CmwEmbedUtil%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20130507T025610Z:106".

"Stop script" lead to an indefinite wait. "Continue" seemed to work ok. I'm using Firefox 20.0.1. Thanks for all the work on this big project. SchreiberBike (talk) 05:15, 7 May 2013 (UTC)

@SchreiberBike: Sorry about this; this is caused by your browser thinking that VisualEditor is taking so long that you probably don't want to wait for it (once you click "Stop script", VisualEditor is dead). We've just made some improvements to the performance of the software which will get deployed here on 20 May - hopefully you will see far fewer (ideally, none) of these in future! Jdforrester (WMF) (talk) 23:49, 11 May 2013 (UTC)

General observations

I've been using the new editor for most of this evening and there's lots of good here. This will really cut down the learning curve for new editors. Possible problems:

• I occasionally use the search and replace function and would miss it if it were not available.
• What will happen to the display of hidden text in the edit view? Things like notes to future editors.

Thanks, SchreiberBike (talk) 07:00, 7 May 2013 (UTC)

@SchreiberBike: Thank you! We really hope to make the learning curve for how to edit (rather than what to edit) a lot shallower and shorter. Search-and-replace functions supplied by your browser should still work, unless you mean that we should build our own version into VisualEditor? HTML comments are currently preserved but not displayed to editors (and can't be edited or new ones created); we hope to come up with a solution soon after the 'beta' is released more widely. Jdforrester (WMF) (talk) 23:59, 11 May 2013 (UTC)

Thanks for your response. I figure that these things are on a prioritized list and some will make it soon, some later, some not at all, and there will probably be good new things no one is anticipating. The search and replace function I was talking about is visible in the top right of the edit window when the "Advanced" menu is selected. It has the following code behind it. "<a class="tool tool-button wikiEditor-toolbar-spritedButton" href="#" alt="Search and replace" title="Search and replace" rel="replace" style="background-position: -70px -214px;"></a>" I'm not aware of any feature in Firefox, but I see that there are some add ons available. Thanks, SchreiberBike (talk) 00:14, 12 May 2013 (UTC)

@SchreiberBike: Aha. I was completely unaware of that tool. :-) Have created an enhancement request for this. Jdforrester (WMF) (talk) 01:17, 12 May 2013 (UTC)

What sort of feedback?

Is the goal to make VisualEditor equally or even more efficient than the old editor (you can make changes as fast or faster)? Is the goal to make the VisualEditor as powerful as the old editor (you can make the same changes)? --Atethnekos (Discussion, Contributions) 17:14, 7 May 2013 (UTC)

@Atethnekos: Our overall ambition is to replace the need for the wikitext editor entirely. We have a number of goals before we'll get there; yes, we want to be more efficient than the old editor for existing users who are used to wikitext (as well as new users who may never need to learn wikitext); yes, we want users to be able to make all (or at least, almost all) of the changes in VisualEditor that they can using wikitext, and potentially other things that are very hard to do in wikitext (like a visual sheet music editor - though that will take some time). Jdforrester (WMF) (talk) 00:05, 12 May 2013 (UTC)

Modern skin?

I know that right now this only works with Vector and Monobook. When it's rolled out site-wide, will it work with Modern skin and all the other skins used on Wikipedia?— Maile (talk) 20:00, 7 May 2013 (UTC)

@Maile66: Probably not; as said when the entirely-dead skins were removed, we are only working on support for Vector and Monobook skins for all the efforts here at the Foundation. Modern and CologneBlue were kept because a volunteer offered to keep them up-to-date, but I've not heard of any efforts to work on the integration of VisualEditor into those skins yet, no. Very happy to advise anyone who wants to work on getting the skin support done. Jdforrester (WMF) (talk) 00:08, 12 May 2013 (UTC)

Ability to add an multimedia image/video from visual editor

A simple drag and drop interface would be excellent. ∞4 (talk) 23:10, 8 May 2013 (UTC)

@Infiniti4: We're working on both a media-insertion tool (to add a file from Commons or the local wiki) to the page, and also drag-and-drop support for moving images and paragraphs around the document, to come very soon. For file uploads, including drag-and-drop from your computer into the browser window, that will come in longer time, once we've got the core editor working well. Jdforrester (WMF) (talk) 00:13, 12 May 2013 (UTC)

Unusable for math

I just tried this on a couple of articles with mathematical formulas (in one case coded as <math>, in the other as a mixture of wiki formatting and html). The visual editor appears to be completely unusable for such cases. It has no support for <math> at all (or if there was support it was not obvious how to make it work), but even in the wiki-formatted equation (a simple example: x² − y²) it was unusable because it did not provide a way to generate superscripts and entities like &nbsp; and &minus; that are necessary for proper equation formatting. —David Eppstein (talk) 01:13, 7 May 2013 (UTC)

@David Eppstein: Yes, we've decided that <math> elements aren't as high-priority as references and templates. We will get to them as soon as we can - indeed, there's a Google Summer of Code student who's hoping to build a visual equation editor for VisualEditor - but I hope you can understand my focus on the core editor for now. Jdforrester (WMF) (talk) 23:43, 11 May 2013 (UTC)

Well, just realize that this means that if/when you deploy, either (1) there's a big class of articles that the VE won't be usable for, and a big group of editors who edit those articles who'll become convinced that VE is a bad idea, and difficult to un-convince, or more likely (2) new editors will try to use VE on math articles, fail badly at properly formatting the math, get turned off from editing Wikipedia, and severely annoy the long-term math editors who have to clean up the mess. —David Eppstein (talk) 02:24, 12 May 2013 (UTC)

@David Eppstein: I understand your frustration, but I would argue that being able to edit the ~99% of articles which do not have a <math> tag, but do have a <ref> tag, is more important. I look forward to us building a visual equation editor for you in the future. Jdforrester (WMF) (talk) 22:25, 12 May 2013 (UTC)

Question

Will it be compulsory to use Visual Editor as it could alienate a large number of regular users who are very used to the current system. Although I do agree it will help new/casual users. Personally I tried 2 simple edits using Visual Editor and found it took me a lot longer, and wasn't 100% sure if it actually worked until after! Mark999 (talk) 01:31, 7 May 2013 (UTC)

@Mark999: It definitely will not be mandatory to use VisualEditor; all users will have access to the "normal" wikitext editor as well. I hope that with time you'll find using VisualEditor quick and easy; very happy to hear your thoughts on what you found hard/challenging to find or do! Jdforrester (WMF) (talk) 23:47, 11 May 2013 (UTC)

Though a good thing is/could be to make sure internal links are actually to the correct page and not to redirect pages or pages that don't exist to avoid/get rid of red links. Something along the lines of Dab solver. Mark999 (talk) 02:12, 7 May 2013 (UTC)

@Mark999: Yes, that's one of the improvements we're thinking about doing early on, once the core editor itself is in place. Jdforrester (WMF) (talk) 23:47, 11 May 2013 (UTC)

I'm happy with those replies, I did trial the editor once but will again over the week and give more in depth feedback. Mark999 (talk) 11:30, 12 May 2013 (UTC)

Can't see my previous edit, when I go to edit again

Tracked in Phabricator
Task T49682

When making repeated edits, I am not shown the edit that I last made. Pineapples100 (talk) 20:51, 3 May 2013 (UTC)

@Pineapples100: Sorry about this bug; we've now fixed it and the code will be going out to mediawiki.org on Monday, and here on 20 May, as part of the regular deployment cycle. Jdforrester (WMF) (talk) 23:37, 11 May 2013 (UTC)

Thanks for your help! I look forward to re-checking out how the VisualEditor works. — Preceding unsigned comment added by Pineapples100 (talk • contribs) 14:58, 13 May 2013 (UTC)

Green/white stripey boxes off - just grey out parts that you can't edit.

On User:Adjwilley (Monobook, Firefox) the green/white stripey boxes seem to be offest to the right and down a little...in other words, they're not covering what they're supposed to be covering. They are also really annoying, and my very first impression when I scrolled and saw this weird box sitting there was that it was a bug in the program. I really don't like the look of them at all.

As an alternative, why don't you just lighten everything you can't edit by say 50-75%. Text would be grey, infobox outlines would be grey, colors in pictures would be washed out, and it would be obvious that you can't edit it. (Other computer programs often do stuff like that for stuff you can't edit.) I figure that definitely beats blanking pictures and then trying to cover the ugliness with an even uglier green stripy box. I mean, that's just weird. ~Adjwilley (talk) 18:20, 8 May 2013 (UTC)

@Adjwilley: The amount of content that's going to be non-editable with the VisualEditor is going to be vastly reduced when we get references, templates and images into editing in the next few weeks. However, yes, the treatment we give to the remaining such items is something to re-visit. Part of the original concept here was to make editing mode look as close as possible to reading mode, and only highlight that something was 'wrong' and not easily modified at the last possible moment (on hover), so it needed to "pop". A lower saturation just on hover might be a bit odd, though; once we've got the new features live, we should consider whether they should be highlighted as un-editable all the time, I agree. Jdforrester (WMF) (talk) 18:44, 8 May 2013 (UTC) P.S.: Moved here from my talk. Jdforrester (WMF) (talk) 00:10, 12 May 2013 (UTC)

Thank you! That makes a lot more sense now. My opinion was to just have it greyed out/saturated as un-editable all the time, not just on mouseover. ~Adjwilley (talk) 18:10, 13 May 2013 (UTC)

Section Headings

Ok weird one. [[1]], press edir, type in a heading between the line with the reference and table, select it and make it 'heading 2'. It becomes a header, but removes the 'Books' one at the bottom. Google Chrome on XP. Edgepedia (talk) 18:49, 13 May 2013 (UTC)

Edit tooltip; Notices

Great work overall, thanks to all!

• After enabling the visual editor in my editing preferences, I get two links at the top of each page: "Edit" and "Edit Source". The former's tooltip (shown when hovering over the link) says "Please use the Preview button before saving". This tooltip should be moved to the "Edit Source" link, since the visual editor doesn't have a preview button; the Review and Save button is the only way out.
• After starting the visual editor on an article, a notice window pops up.
  • It is unclear how to get rid of that window. In Chrome, I had to click inside of it to make it go away. That is unintuitive; clicking into the article should also dismiss the window; a small "dismiss" button would also be nice.
  • My notice window contained first a notice about the alpha version of the visual editor, then a vertical line, then a redlink saying "Page notice". What is the latter trying to notify me about, why is it there?
  • I don't want to see the same notice window each time I start the visual editor; there should be a simple way to permanently dismiss it.

AxelBoldt (talk) 20:37, 9 May 2013 (UTC)

@AxelBoldt: The tooltip is now fixed in our "master", and will get deployed to wikis from Monday (it will arrive here on 20 May). Sorry about that mix-up.

On the general point about page notices, these are deliberately meant to be high-visibility and not just go away when you click elsewhere. They'll contain the "you're not logged in" warning, the BLP warning, the "this article is protected, don't abuse your +sysop rights" warning, etc. The notice about VisualEditor being still in alpha will go quite soon (once we have the main editing features in place).

The red "page notice" message is because of the one-off way that the English Wikipedia has per-page notices implemented through templates; every time we adjust our code to make it go away, some sysop here alters that code without telling us and it re-appears. Will get that fixed - sorry.

Jdforrester (WMF) (talk) 00:50, 12 May 2013 (UTC)

This surprises me Jdforrester. As far as I know, this part of the editnotice system hasn't changed for over 3 years. —TheDJ (talk • contribs) 08:33, 14 May 2013 (UTC)

Link color is not extended when extending link

Go to an article that contains a link (blue). Click immediately after the link; the link symbol will appear. If you now start typing, the link text will be extended (as can be checked by later Review). Problem: the blue link color is not applied to the newly entered text. AxelBoldt (talk) 22:47, 11 May 2013 (UTC)

@AxelBoldt: Sorry about this; we used to have it extending both in the screen and the back-end, but this broke some time ago without us noticing. For now, we've made a change so that you can't extend links from the end (unlike bold/italics). This will get deployed out to wikis from Monday, and here on 20 May. Jdforrester (WMF) (talk) 01:11, 12 May 2013 (UTC)

@Jdforrester (WMF): Checking the latest version on mediawiki.org, it seems to me that the handling of links is now unintuitive. It should work in the same way as bold/italic: conceptually adding a link to some text and changing the font of some text are similar actions. It should work like this: while typing, if I hit Ctrl-K and choose a link target, I should then be able to enter the link text until I hit Ctrl-K again. Also, placing the cursor at the end of some pre-existing link text should allow to extend the link text, unless or until the user hits Ctrl-K or clicks somewhere outside the link text. AxelBoldt (talk) 19:28, 14 May 2013 (UTC)

Can't remove an item from a list

Tracked in Phabricator
Task T49795

Tracked in Phabricator
Task T50385

In User:AxelBoldt/Sandbox there's a list. If I try to use the visual editor to remove an item from the list (using backspace), I can remove the list item's text, but I cannot get rid of the corresponding bullet point, leaving a list with empty items. If a list item's text is empty, hitting backspace should remove the entire item including its bullet point. AxelBoldt (talk) 23:05, 11 May 2013 (UTC)

Hey, sorry about this bug; we fixed it but it broke again. A big priority and I'll make sure it gets fixed as quickly as possible. Jdforrester (WMF) (talk) 01:46, 12 May 2013 (UTC)

@Jdforrester (WMF): Thanks for filing the bug reports. Do you have some sort of automatic regression testing set up, where we could add test cases? AxelBoldt (talk) 18:45, 12 May 2013 (UTC)

@AxelBoldt: Unfortunately, we have unit tests for logic but not for UI components (and browser interaction); we've tried to get a Selenium framework up off the ground, but integrating it with our continuous integration set-up still hasn't been done. :-( However, this is a key priority, and I will push again for us to get something in place this week. If you have some suggested test cases I can take them here and make sure we build them into it when it's available. Jdforrester (WMF) (talk) 22:30, 12 May 2013 (UTC)

@Jdforrester (WMF): It seems all bugs I reported are now fixed on mediawiki.org; thanks! I will keep track of them on mw:VisualEditor:TestAxelBoldt. The only minor issue left: if I remove an item from a list by placing the cursor at the end of the item and hitting backspace, once the last character is deleted a spurious empty line appears below; further backspacing removes the empty line and the bullet point. AxelBoldt (talk) 19:18, 14 May 2013 (UTC)

@AxelBoldt: Glad to help. :-) You're right about the double-new-line - this is, I believe, 48385 which I will try to get fixed this week. Thanks for the report! Jdforrester (WMF) (talk) 20:16, 14 May 2013 (UTC)

Disable on .js and .css pages

Tracked in Phabricator
Task T49456

The VisualEditor probably should be disabled on .js and .css pages, as it looks weird on such pages. jcgoble3 (talk) 06:18, 12 May 2013 (UTC)

@Jcgoble3: Yes - we've got this tracked and soon to be merged into our main codebase; hopefully we'll be able to deploy this quote soon. Jdforrester (WMF) (talk) 22:32, 12 May 2013 (UTC)

@Jcgoble3: As an update, it is now fixed and will be deployed here as part of the fortnightly code release on 20 May. Jdforrester (WMF) (talk) 18:39, 14 May 2013 (UTC)

A few problems

I noticed a few problems when experimenting with the new Visual editor today so I wanted to bring them up.

1. It doesn't allow categories or templates to be edited
2. If a category is added it inserts nowiki tags around it
3. When I edited an article recently here and inserted a category, the visual editor app also changed a category to reflect United States at the end rather than North Dakota.
4. The new app to me is confusing in the sense that you don't know when your in edit mode and when your not. It should be clearer when your in edit mode.
5. How do you wikilink in the new editor?
6. The app does not allow references or html. It nowiki's it out. So if a user inputs a reference its gong to show up like its part of the text. This is a critical problem if references cannot be included without going to full edit.
7. Images cannot be added or edited.

Kumioko (talk) 20:32, 12 May 2013 (UTC)

@KumiokoCleanStart: Thanks for your comments; my responses, split by point:

1,6,7

Yes, a number of core editing features that we're working on are not yet available in the opt-in alpha: these are references, templates, categories and images. They will all be coming soon, ahead of our "launch" when the beta is made available to all users by default.

2

If you insert content that happens to look like wikitext, the system automatically puts <nowiki> tags around it, yes. If we did not do this, then users who did not know wikitext would unexpectedly break for them, which undermines the whole purpose of editing through VisualEditor.

3

This looks like it is a bug with Parsoid, which I will report; thank you!

4

Again, this is rather deliberate - we're trying to encourage readers to edit more (as well as existing users), and one of our design objectives has been to make the editor look as close as possible to "you're reading, but have a cursor" rather than being an alien environment. However, I take the point that it can be a bit jarring, and we're considering ways we could make it a little clearer without damaging the illusion.

5

You can insert a link by pressing the link button in the tool bar, or the "normal" keyboard shortcut: Ctrl+K. This works either on a selection of existing text, or if you haven't selected anything, it will insert at the cursor.

Hope this clarifies some things! Jdforrester (WMF) (talk) 22:45, 12 May 2013 (UTC)

Thank you for the quick responses and I'll let you know if I see anything else. If I may offer a suggestion on #4. If the article were merely a little lighter, maybe 90% instead of 100% then it would look slightly different enough so that the reader knew they were in edit mode but the same enough to ensure they were editing the text directly.

Another note, I would prefer if it would allow me to add the edit summary directly rather than in a follow on popup box and I think others would too. Would that be possible? Kumioko (talk) 23:09, 12 May 2013 (UTC)

@KumiokoCleanStart: Making the article text lighter might work well - I'll raise this with the team. On "add[ing] the edit summary directly", do you mean that you expect the edit summary would hang permanently above the page, and would scroll down (above the toolbar?) as you edit? This is a possibility, but removes our ability to scale well on small screens (netbooks, mobiles, tablets, etc.), to give space for the more complex workflow items that we hope to build later ("you haven't put any references in this new page, are you sure you wish to save?" and similar), and also might be a bit clunky. Let's think about it. Jdforrester (WMF) (talk) 00:41, 13 May 2013 (UTC)

I think there are several ways to do it that could still make it scaleable. I agree that for some devices it might be clunky but it seems like we would be able to sense what they are editing with so if we see its an Ipad or like device we could have a tab somewhere (I was thinking on the very top or bottom of the page that could be suppressed by default but the user could click on it before saving and then add the summary. Then if the summary wasn't added the system could pop up the add summary box as it is now if there was no summary input. To me the top and to the left of my username would be best (there is a lot of real estate up there for most of us) although I realize that for some like admins and such that have additional rights it might not be a good place. Another possibility might be to add it at the bottom of the edit box above where it says "This page was last modified... Using the Northern Plains National Heritage Area article as an example I envision it being between the stub tag and the blue line. But as a static locked bar like the one at the top with the preview button in it. Of course that could vary depending on the device. I think its important not to take a Windows 8 approach to this and make it one size fits all. The system could be smart enough to detect (or allow the individual to select) the type of device and then system could adjust as necessary to maximize the experience. We shouldn't force a one size fits all (like Windows 8 or Facebook Timeline) and then make a lot of people mad in the hopes of finding some that like it. Anyway, just my opinion and thanks for the quick responses. I'll let you know if I find any more issues. Kumioko (talk) 01:11, 13 May 2013 (UTC)

Just noticed something else. The New editing tool doesn't seem to line up with the notifications logic quite right. When I have them both going at the same time the New edit tool overrides the new Orange bar on the notifications and I just see the itty bitty shitty little red number with no orange bar. :-) Kumioko (talk) 01:44, 13 May 2013 (UTC)

@KumiokoCleanStart: Sorry about that - I will talk to the Notifications team to make sure their code doesn't break when using VisualEditor. Jdforrester (WMF) (talk) 16:25, 14 May 2013 (UTC)

Table editting - able to add returns

Tracked in Phabricator
Task T50460

When editing a table [2], I was able to add returns that screwed up the result. Edgepedia (talk) 05:42, 13 May 2013 (UTC)

@Edgepedia: Sorry for this bug - I've filed it (tracked above) and will work out what went wrong. Jdforrester (WMF) (talk) 16:49, 14 May 2013 (UTC)

"Review and save" or?

I tried this Visual Editor for the first time and got as far as the choice between "Something is wrong" and "Looks good to me". I assumed this was a pair. That is, that the choice was between "Something is wrong with my edit" (in other words," go back to editing before proceeding to save") or "Save" (in other words, "publish". I clicked the former (ie, the "Something is wrong" button) only to discover myself in some sort of complaint mode. Then I couldn't get out. Erp! So I had to abandon the whole edit enterprise.

The choice ought to be between "Go back to editing" and "Save/publish". Buttons for reporting a software problem should not be mistakable for an editing function. The mindset of a person in the middle of the editing operation is that the text is wrong, not the programming. -- Whiteghost.ink (talk) 10:32, 13 May 2013 (UTC)

• That's a really good idea. It would be great if we could (optionally) go back to editing after reporting a glitch, instead of just losing all the changes we've made. It shouldn't be an all-or-nothing process. -- The Anome (talk) 12:19, 14 May 2013 (UTC)

@Whiteghost.ink and The Anome: Sorry for the confusion - it is possible to escape from the "Something is wrong" dialog, by clicking the "^" (which escapes from all the multi-screen workflows back to the editor) or the "<" which takes you back a screen. Clearly these buttons aren't obvious enough, which is worrying as they're the common design language throughout the inspectors and dialogs system. Did they not look like buttons at all to you, did they not seem like they would help you with your issue, or did you just not see them? More generally, the "Something is wrong" functionality will be removed quite soon (removing one of the two feedback tools) before we transition from 'alpha' to 'beta'. Jdforrester (WMF) (talk) 16:36, 14 May 2013 (UTC)

Editing a redirect edits the source article

Tracked in Phabricator
Task T47808

I wanted to fix a redirect going to the wrong place, I hit "edit" and the visual editor loaded up the source page. This was *not* what I was expecting. David Gerard (talk) 16:17, 13 May 2013 (UTC)

I get this too; attempting to edit a redirect (such as NHRA) brings up the contents of the redirect's target page. jcgoble3 (talk) 19:00, 13 May 2013 (UTC)

@David Gerard and Jcgoble3: Sorry about this; the first part of this bug is being fixed which will make redirects a bit useless (until VisualEditor can change #REDIRECT magic words, which will come in longer time. Jdforrester (WMF) (talk) 16:38, 14 May 2013 (UTC)

Link editor doesn't note disambiguation pages or redirects

VE's link editor is nice and unobtrusive, but it will happily link to a disambiguation page or to a page that's a redirect without telling you. Try "_John McLaughlin_ played _jazz-rock fusion_", both phrases show as a blue link with a checkbox. But linking to a disambiguation page is a mistake, and editors will want to know the title to which they're actually sending a reader. Maybe the scrolling list of links could have annotations: "disambiguation page" (in red?), and "redirects to _jazz fusion_" (in orange?). S Page (WMF) (talk) 03:05, 14 May 2013 (UTC)

@S Page (WMF): Both of these are nice-to-haves. Noting that the target page is a "disambiguation page" would require some back-end infrastructure to know whether a page is one to be available to the link inspector. Also, I strongly worry about over-loading the user with extra information - it's never wrong to link to redirects or disambiguations, just non-optimal. As with the wikitext editor, users should check the targets to which they're linking. Jdforrester (WMF) (talk) 16:41, 14 May 2013 (UTC)

Incorrect. It is wrong to link to a disambiguation page via a non-disambiguated name. If you want to intentionally link to a dab, it should be via [[Article title (disambiguation)]], not [[Article title]]. See WP:INTDABLINK. (Linking to redirects is a different issue, and much more likely not to be an error.) —David Eppstein (talk) 05:06, 15 May 2013 (UTC)

Capitalization of linked words, and paper-cut bugs in general

Tracked in Phabricator
Task T50060

Although the visual editor project, when finished, will represent a great leap forward for Wikipedia, and the underlying Parsoid technology is impressive, alpha-testing this editor is truly an exercise in pain. Try this: take a page that has an un-linked lowercase word already in it, visit it with the Visual Editor, and use the link tool to turn that word into a link. The linked word still displays as lowercase in the visual editor, and goes blue to indicate that it's a link. Now save it. The word is now saved to the page with its first letter capitalized. As far as I can tell, this problem does not occur with linking words which were created in the visual editor itself.

I reported this ages ago in the feedback tool, and it's neither been fixed, nor has anyone acknowledged it. How hard can this be to fix? Are error reports at least read by a human being, and entered into a bug tracking system, or are they just glanced at occasionally in aggregate, or just ignored?

Believe me, I'm not unsympathetic to the travails of developers, having been one myself, but if trivial paper cut bugs like this, for one of the simplest possible editing changes, cannot be fixed, either there's something badly wrong with the underlying design, or the development process is collapsing under the weight of the workload in fixing bugs. I know there are far more serious and complex bugs that need fixing, but it should at least be possible to fix low-hanging fruit like this by having a fast-track process for this sort of bug. Doing so would greatly improve the experience for alpha testers, who could then use the editor more, to make more extensive edits, and thus exercise more complex bugs. (See also the comments higher up this page about avoiding data loss every time we report a bug.)

Could we possibly have a bit of feedback from the developers about what's going on, so we can at least be a bit more sympathetic to their plight? Having bug-by-bug feedback would also help motivate alpha testers; it's painful just reporting bugs apparently into a void. -- The Anome (talk) 12:05, 14 May 2013 (UTC)

@The Anome: Hey; really sorry that you gave some feedback on this before and we hadn't responded - I had not seen it, no. Do you know where you gave feedback about the VisualEditor? Did you instead give feedback about Parsoid (the "Something is wrong" workflow)? If so, it goes to a private server for review for serialisation bugs and won't have been seen by me, sorry. This is one of the reasons why I want to get rid of that process.

The specific bug has been independently reported last week and we'll get it fixed this week. Jdforrester (WMF) (talk) 16:46, 14 May 2013 (UTC)

Yes, I did. I was under the impression that those "something is wrong" reports were being treated as bug reports, as that's what that kind of reporting is normally for; I actually thought it was quite a good idea to put a bug report form in that place in the workflow. At this point, if we had a "sad face" icon, I'd put one in. I've used that form to report multiple problems on multiple occasions, under that same misapprehension. How frustrating! I wonder how many other people have being doing the same, for the same reason, and feel similarly frustrated by having their bug reports ignored?

You're quite right, if they're not being treated as bug reports, we should get rid of that process entirely, as it just creates frustration for all involved; a major paper-cut bug all by itself. Instead, at that point in the workflow, we should have some pointer to a real bug-reporting process that actually gets read by people. Sorry about the intemperate language -- I now understand why my reports were appearing to be ignored. -- The Anome (talk) 17:12, 14 May 2013 (UTC)

@The Anome: They are being treated as bug reports, but on the conversion of the provided HTML to wikitext (which is the responsibility of Parsoid) rather than the editing of the HTML. On reflexion, it isn't very clear (it was a last-minute addition to check for Parsoid bugs - originally there was just this feedback form). Jdforrester (WMF) (talk) 18:28, 14 May 2013 (UTC)

I came to report a bug quite like this, diasambiguating hive at [3], but when I attempted to "report a problem" in the interface, I got no response from pressing the "Report a Problem" bug, the window stayed up. OSX Chrome 26.0.1410.65 . --j⚛e decker^talk 01:49, 15 May 2013 (UTC)

Spellchecking

I've tested it on two articles. On one it worked OK if very slowly, but it lost the, for me indispensable, spellchecker which I otherwise have via Firefox. The other it insisted on removing the first and last bites of a paragraph that I wanted left untouched. So I've gone back to the old system. Might test again when you allow section editing. ϢereSpielChequers 07:18, 13 May 2013 (UTC)

See here. Okeyes (WMF) (talk) 06:37, 14 May 2013 (UTC)

@WereSpielChequers: Your lack of your browser's native spell-checker working is definitely a problem - which version of Firefox were you using? Does the spellchecker trigger on other websites that use native spell-checker (like GMail or Facebook)? Jdforrester (WMF) (talk) 15:55, 14 May 2013 (UTC)

Thanks James, it works really well in Firefox on Windows. The spellchecker comes up, it only edits what you want it to edit and it is acceptably quick. My previous, problematic attempt was in Firefox under Ubuntu. Not so much chalk and cheese as caviar and catfood, will try to work out versions of Firefox and Ubuntu. ϢereSpielChequers 17:12, 14 May 2013 (UTC)

@WereSpielChequers: Still a bit worrying. Will try to see if I can get my Ubuntu/Firefox image up and running and test spell-check there. Thanks for the report. Jdforrester (WMF) (talk) 18:30, 14 May 2013 (UTC)

Back on my Ubuntu machine. one edit went fine. then I tried to fix a typo and had an entire infobox of code come up as being added in preview. So I then edited just the section which appeared to take me back to the normal editor. But instead of adding one byte it removed 3 I think just spaces, but not something I intended to do. Oh and it is a little slow, though nowhere near as slow as last night. ϢereSpielChequers 19:30, 14 May 2013 (UTC)

Just did another search, first edit went fine, then I hit a 69kb article, visual editor was going to screw up and make a bunch of unrequested changes, so I edited the section which worked. But Visual editor still not showing spellchecker in ubuntu/firefox. ϢereSpielChequers 20:17, 14 May 2013 (UTC)

@Jdforrester (WMF):, this is a good example of the problem. When I fixed a typo the visual editor also took out an unneeded space, I wouldn't greatly mind that apart from the hassle of me working out what it did taking longer than the actual minor edit that I was doing. But for anyone using this to avoid seeing lots of code, well the change suddenly showed that you had also changed a wholly different paragraph than the one you were editing. If the idea of the visual editor is to reach out to those who don't want to be editing templates and so forth then this needs fixing. ϢereSpielChequers 04:59, 15 May 2013 (UTC)

And this time I saved what the vis editor wanted to do, then reverted and edited the section. Note the third edit I made to the article was the typo fix that I was actually trying to do. ϢereSpielChequers 05:08, 15 May 2013 (UTC)

Whilst this time it took out both a space and an unmatched '', but again when I saw the change I was about to make it was telling me that visual editor was getting me to make changes in some humongous template. As for this one I was trying to change one forth to a fourth and all I can do with visual editor is revert myself and go back to the old editor. ϢereSpielChequers 05:18, 15 May 2013 (UTC)

Deleting an entire paragraph

Suppose an article has three paragraphs and you want to remove the second one entirely, merging the first and the third into one. There are several methods that work, but two that do not:

1. Select the second paragraph without the trailing carriage return, then hit backspace: an empty line remains (as expected), but further backspace cannot get rid of it, no matter where you position the cursor.
2. Position the cursor at the end of the second paragraph and keep hitting backspace until the paragraph is gone. Again, a spurious empty line is left behind that one cannot get rid of with further backspacing.

The only way to get rid of the spurious empty line is to select everything from the end of the first to the beginning of the third paragraph and hit backspace. You can try it out at user:AxelBoldt/Sandbox. AxelBoldt (talk) 17:43, 14 May 2013 (UTC)

@AxelBoldt: Happy to say that this is now fixed in the new version that will be deployed here on 22 May - you can test it out on MediaWiki.org. Sorry for our having broken this. Jdforrester (WMF) (talk) 18:33, 14 May 2013 (UTC)

Entering italic/bold text

I am typing some text in the visual editor and I would like the next word to be italic, so I hit the Italic button and type the word. First problem: the word is not displayed in italic (even though upon review the wiki text contains the correct italic markup.) Second problem: at the end of the italic word I would like to revert to standard text, so I click the italic button again, but this click is apparently being ignored and I cannot leave italic mode. The exact same problems occur when trying to enter bold text. AxelBoldt (talk) 17:56, 14 May 2013 (UTC)

@AxelBoldt: Happily this is also (mostly) fixed - you can see here on MediaWiki.org. Sorry for us screwing this up. The fixed code will be deployed here as part of the regular fortnightly releases on 22 May. Jdforrester (WMF) (talk) 18:36, 14 May 2013 (UTC)

change in interface

As Ryan commented on the VP:T, " it just changed from giving me an edit tab and a visual editor tab to an edit tab (that is the visual editor) and an edit source tab. " -- which also keeps the shortcut key from calling the normal editor. I've found it very confusing. The tab added should be "visual editor", which is explicit for what is after all not yet our usual editor, and does not yet have some key functionality, such as the ability to edit references. The way I've dealt with it is to remove the preference; I suspect others will do likewise: if the intention was to induce more people to use it, it will have the opposite effect. . Haven't we learned yet to stop making unannounced changes in the interface, including unannounced changes to widely used test features. DGG ( talk ) 21:44, 19 April 2013 (UTC)

@DGG: The change to the tab's label was advertised on VPT (and other places) approximately ten days before it came into effect; it appears that you didn't see the notice, which is unfortunate. As stated there, it is part of our efforts at making the interface look more like how it will appear to new users when deployed for everyone, so that you can give feedback on how it works (or doesn't). Jdforrester (WMF) (talk) 22:43, 11 May 2013 (UTC)

I don't mind the change to the tabs at the top, but I'd really like to get that shortcut key working again. I would like a separate shortcut key for the visual editor and the regular editor in fact. Mike Christie (talk - contribs - library) 22:09, 19 April 2013 (UTC)

@Mike Christie: Sorry about this - it's now fixed and will be deployed here on 20 May. Jdforrester (WMF) (talk) 22:43, 11 May 2013 (UTC)

On the same note, the edit tabs on all pages which can't be edited by VisualEditor should have 'Edit source' instead, to keep things consistent. FallingGravity (talk) 06:10, 13 May 2013 (UTC)

I have the same issue with the "wrong" label for the buttons especially that it jumps back and forth between name spaces and I will deactivate again until this is changed back. I would think you can test the look and feel when it does everything it should do i.e. in late Beta and not Alpha. So my Feedback is "The Label does work but does not make sense now"--Saehrimnir (talk) 13:53, 16 May 2013 (UTC)

Backspace

The notice warned me that it might be "slow". Well, I held down the backspace key for "a while", and then "poof" several paragraphs disappeared.

What happened to "undo"? Neither the left curving arrow nor <Ctrl-Z> functioned after the backspace poof. (No kidding.)

But anyway, thanks for this wonderful advance in editing. An awesome milestone, yea? — CpiralCpiral 06:29, 17 May 2013 (UTC)

Which browser and version did you use ? —TheDJ (talk • contribs) 06:48, 17 May 2013 (UTC)

Copying a barnstar

Hi, I just used this to copy a barnstar then had to edit source to clean up the mess. I thought you'd like to see this as the edit I had to undo was a great example of how the visual editor can make a shedload of changes that you weren't planning to do. ϢereSpielChequers 07:12, 19 May 2013 (UTC)

Editing linked words

I've just edited a linked phrase this edit required this cleanup "interpet" was an unrelated typo, only linked by the outstanding bug that using the visual editor under Ubuntu deprives me of Firefox's spellchecker which highlights such typos for me. ϢereSpielChequers 08:58, 19 May 2013 (UTC)

Strange symbol

I've just had a very strange symbol added to my edit by visual editor. Rather than abandon the edit I thought I'd save it and show you the cleanup. I'm pretty sure that symbol is not on my keyboard. ϢereSpielChequers 09:28, 19 May 2013 (UTC)

Bug 48346 - David Gerard (talk) 17:50, 19 May 2013 (UTC)

cleanup

this also involved some additional changes - I thought I was just fixing a typo. ϢereSpielChequers 11:26, 19 May 2013 (UTC)

Timeout

this was a second attempt after failing with "error saving to server timeout" ϢereSpielChequers 10:16, 19 May 2013 (UTC)

Can't submit error reports

If problems are found in review of an edit, you can type in a description of the problem but pressing the "submit" button doesn't seem to do anything. ~KvnG 23:13, 19 May 2013 (UTC)

Logged out problems

Having left an editing pane open overnight and being logged out by the system I found that I can't resume in the morning - I get "Error loading data from server unsuccessful request - invalid token" That despite having to log in multiple times. Then a couple of hours later I got the wonderfully opaque "Error loading data from server: badtoken: invalid token: Would you like to retry?" then when I clicked OK to that I got the same line with a box and "prevent this page from creating additional dialogues" after several attempts to click OK on that without ticking that I didn't want additional dialogues - after all I am testing this thing, I closed that pane opened the page in another pane and opted to edit source. ϢereSpielChequers 11:47, 20 May 2013 (UTC)

Thanks for enabling the VE in Safari on Mac OS X 10.6.8! :)

Thanks for enabling the VE in Safari on Mac OS X 10.6.8! :) It's good to be finally part of the show. :) Aschmidt (talk) 20:46, 22 May 2013 (UTC)

Duplication

Somehow, removing a handful of </br> substantially increased the number of characters on the page. Here's the diff: [4] WhatamIdoing (talk) 23:14, 21 May 2013 (UTC)

This might be another instance of {{tracked|48592}}. WhatamIdoing (talk) 22:26, 23 May 2013 (UTC)

Paste doesn't always work; wierdness

Ctrl-P does not paste copied or cut text. Selecting Paste from context menu only work sometimes. Editing near the paste makes pasted text disappear.

I just did 2 edits on Herschel Space Observatory. First edit in lead worked. Second edit, in End of Mission, undid my first edit. User:Finell —Finell 03:28, 1 May 2013 (UTC)

I've never heard of Ctrl+P being used for pasting. The standard shortcut for pasting is Ctrl+V. jcgoble3 (talk) 04:15, 1 May 2013 (UTC)

@Jcgoble3: Yes, we're not binding to Ctrl+P (and won't; that's mostly used by browsers already, for printing things, and we shouldn't break existing behaviour without a decent reason).

@Finell: On the topic of pasting only working sometimes, and editing near pasted content making it disappear, could you tell me what browser you were using, and whether this occured on all pages or just a few of them? Jdforrester (WMF) (talk) 23:09, 11 May 2013 (UTC)

I meant Ctrl+V. I was using Chrome (up-to-date). It happened on several pages on several different days.

When Visual Editor became the default editor for the Edit link on a page, why wasn't it also made the default editor for the edit section links?

Why won't Visual Editor work in MSIE? Is it the same reason that wikEd won't work in MSIE?

I really hope Visual Editor succeeds. Personally, using Wiki markup was never a problem for me; I am less poductive using Visual Editor than with the "legacy" editor. However, a simpler editor should help a broader population peaple feel confortable contributing to Wikipedia. That is a very important strategic goal for Wikipedia and for other Wikimedia projects. That is why I am testing it.—Finell 05:40, 16 May 2013 (UTC)

@Finell: Was your failed pasting happening on Mac, Windows, Linux, or something else? When you say "sometimes", does it fail on some pages always, in certain context (e.g. pasting into a table), or just randomly? I've not heard any other reports and it's really hard to track down with more information, sorry.

We didn't over-ride the section edit links during the alpha because we want VisualEditor to be used for testing alongside regular editing before VisualEditor supports key items like references and templates.

VisualEditor should work in Internet Explorer version 9 and above; if you can't get it to work in those, please tell us. I don't know about "wikEd", but VisualEditor requires a number of key technologies and standards that Microsoft didn't implement until IE9, and coming up with an entirely separate version of VisualEditor just for supporting IE8 would be hugely expensive.

Finally, thank you for your kind words; we too hope that it will be useful to newbies, though also for experienced editors. Jdforrester (WMF) (talk) 08:48, 24 May 2013 (UTC)

Clickable references

Even though you can't edit references, it still should be possible to click on the links inside them (probably opening in another tab). Also, the "Review and Save" popout needs the 'Cancel' and 'Preview' buttons. FallingGravity (talk) 20:57, 9 May 2013 (UTC)

@FallingGravity: References will be editable very soon, at which point the links will "magically" work to click (in the same way that links in normal paragraphs do). I disagree that the save dialog needs a preview button (the entire point of VisualEditor is that what you edit is the preview). For cancelling out of the editing, the "Cancel" button next to the "Review and Save" button (soon to go back to being just "Save") is meant to suffice (or just the back button in your browser). Jdforrester (WMF) (talk) 01:01, 12 May 2013 (UTC)

By preview, I'm thinking more of switching from the VisualEditor to the source code editor (although I guess this wouldn't necessarily have to be inside the Review and Save). I'm guessing this is a planned feature/bug. FallingGravity (talk) 02:17, 12 May 2013 (UTC)

@FallingGravity: Ah, right, yes, that's something we're considering but almost certainly won't be done until after the 'beta' launches. Sorry for my confusion! Jdforrester (WMF) (talk) 22:26, 12 May 2013 (UTC)

I've occasionally wanted to have a third option: Something's wrong (and tell the devs about it), Looks good to me, Something's wrong and take me directly to the source so I can fix it. I don't know if anyone else would want that, though. WhatamIdoing (talk) 04:35, 21 May 2013 (UTC)

@WhatamIdoing: We're considering building the ability to switch (without saving) between VisualEditor and wikitext modes for the whole page at once (rather than elements of it), but this will need some work from us and I've prioritised it to be after the 'beta' launch. Jdforrester (WMF) (talk) 09:02, 24 May 2013 (UTC)

Improper upper case on links

Tracked in Phabricator
Task T50060

Tracked in Phabricator
Task T50476

Suppose an article contains the text "red blood cell" which is not linked. Using the visual editor, I highlight the text and click on the link icon. The proper link target is suggested, and I select it. Everything looks fine, but when reviewing the change, I see that the link [[Red blood cell]] (with upper case R) was created. This does not match the preview and creates spurious capitalization in the article. AxelBoldt (talk) 22:27, 11 May 2013 (UTC)

Thanks for this bug report - it's an irritating bug, and sorry for the inconvenience. I'll make sure we get it fixed very soon. Jdforrester (WMF) (talk) 01:05, 12 May 2013 (UTC)

@Jdforrester (WMF): The bug is now fixed, however there remains a slightly strange behavior: if I highlight "Example" (without quotes) and hit CTRL-K, the correct link target (upper case "Example") is pre-selected; if I highlight "example" instead, I get a red-linked target of lower case "example". The link shouldn't be red. Both versions yield the correct wikitext upon review. AxelBoldt (talk) 17:08, 22 May 2013 (UTC)

@AxelBoldt: Sorry, yes, this is bug 48476 which is now fixed in 'master' and will get deployed to meta on 27 May and here on 3 June. Jdforrester (WMF) (talk) 08:55, 24 May 2013 (UTC)

Paragraphs duplicated

There are two paragraphs here. Open the VisualEditor, and add an extra return at the end of the first para, and then delete it (Strange, now the second para is small!) Do this a few times and this is the result. Edgepedia (talk) 11:58, 24 May 2013 (UTC)

Here [5] I move a paragraph using cut and paste, and it left the comments behind! Edgepedia (talk) 06:16, 25 May 2013 (UTC)

This could be related to Bug 48592. Edgepedia (talk) 06:24, 25 May 2013 (UTC)

No change

Click on a wiki-linked phrase and changing the target seems not to change the article. Selecting the whole link works before clicking on the anchor symbol works. Edgepedia (talk) 15:38, 24 May 2013 (UTC)

@Edgepedia: I cannot reproduce this. I click on a linked phrase, then click on the anchor symbol, then choose a different target, then hit Enter (or click on the back arrow, or click outside of the selection box), and upon Review and Save the target has been changed correctly. If on the other hand I click on a linked phrase and directly start editing, the linked phrase is changed as expected while the target stays the same. Did you mean something else? AxelBoldt (talk) 19:51, 26 May 2013 (UTC)

Thanks for trying, will come back if I work out how to replicate the problem consistently. However, on the subject of links I just found I couldn't link to an article section. On typing the #, the link went red, and removed the # and target before saving. Edgepedia (talk) 20:46, 26 May 2013 (UTC)

@Edgepedia: Links to article sections also work for me. The trick is: once you have entered the target with #, you need to press Enter twice for it to have an effect. If instead you click the back button or click outside of the selection dialog, your choice will be ignored. This is very unintuitive; I have complained about it here. Cheers, AxelBoldt (talk) 23:29, 26 May 2013 (UTC)

Blank lines before section headings

I corrected the section heading levels (from level 2 to level 3, to create subsections), and it removed the blank lines after the section heading (fine, if you want) and before it, which is not okay. I corrected it manually. WhatamIdoing (talk) 16:38, 26 May 2013 (UTC)

@WhatamIdoing: I'm just wondering btw, were you not able to spot these changes in the diff that is being presented before you save, or was the problem that you were unable to interpret what the changes in the diff meant for the visual outcome (because you had been fooled by the visual editor's alternative rendering perhaps ?). —TheDJ (talk • contribs) 19:42, 27 May 2013 (UTC)

It was visible in the diff, but I couldn't find a way to fix it inside VE. When I've encountered this (twice?) before, the choice in VE seems to be "zero blank lines" or "two blank lines". (In the past, I've just cancelled the edit and done it in the old editor.)

Also, since all I did was click the section heading and use the menu to change the setting from "Level 2" to "Level 3", it shouldn't have been messing with any of the other paragraphs anyway, so this shouldn't have happened in the first place. WhatamIdoing (talk) 00:53, 28 May 2013 (UTC)

Wikipedia:Edit filter to detect Google Translator text

The following discussion is marked as answered. If you have a new comment, place it just below the box.

---

not working well: see examples

• 14:52, 27 September 2013 https://wiki.riteme.site/w/index.php?title=Grohe&diff=574747274&oldid=568425516
• 02:49, 28 September 2013 https://wiki.riteme.site/w/index.php?title=Savages_(band)&diff=574821568&oldid=574151855

--Frze ^{> talk} 06:15, 28 September 2013 (UTC)

I can't see a VE problem there: I think this belongs to the Technical Village Pump? --Elitre (WMF) (talk) 11:38, 30 September 2013 (UTC)

FYI. It was reported to VP a month ago and now there is an edit filter. -- Magioladitis (talk) 21:33, 1 October 2013 (UTC)

References

The following discussion is marked as answered. If you have a new comment, place it just below the box.

---

When you add a reference (and it is added between say 1 and 2) then it will assume the number two with it's identifying information but the information regarding that reference will not be added. See my added references under the discription column on this page (Hypersensitivity Reactions)... all on the right hand column of the page be from the same source. (Le, Tau) but it doesn't show up like that. 83462 17:27, 28 September 2013 (UTC) — Preceding unsigned comment added by Johndheathcote (talk • contribs)

I think this might be 54341 but I don't know if the patch is live yet. Thanks, --Elitre (WMF) (talk) 11:43, 30 September 2013 (UTC)

Actually, I also tested this here and I got what you call the expected result, which is, all the information pointing to the same reference. I think you had added a duplicate one, instead. So, if you try again in a sandbox, delete the former references and reuse the Le, Tau one you should manage to do what I did. The ref name can be confusing, but the number will display correctly. --Elitre (WMF) (talk) 11:59, 30 September 2013 (UTC)

Major bug causing hidden reference corruption (loss of added citations, redirection to other citations)

I have twice now in the last few days experienced a bug in which an existing reference has a name of :0 added to it, and also an unrelated reference that I have added is also changed to :0 and the citation within the reference is removed. I think because of the latter problem, this bug has now regressed to worse than it was originally - I don't remember experiencing the latter problem before the last few days.

The error is only visible after clicking either of the two buttons on the save form. Many editors will not initially notice this error at all, assuming that their citations will have been saved OK. Moreover, other editors will often assume good faith and assume that an existing reference, added by an editor in good standing, does indeed substantiate the point cited, without checking, so the incorrect reference may remain for a very long time.

I have added a note to that bug report because I think it is another manifestation of the same bug, but it may in fact be a different bug which is interacting with that bug to produce this overall highly unfortunate effect.

I think this is a serious bug which should be fixed ASAP, and I think everyone adding citations should be aware of it, or should stop using VE until it is fixed.--greenrd (talk) 11:28, 29 September 2013 (UTC)

I do think it is going to be fixed soon, because although the status is "new", it's marked as a regression, and these kind of issues definitely have a priority. Thanks, --Elitre (WMF) (talk) 16:24, 1 October 2013 (UTC)

Greenrd, it looks like the update happened as scheduled today. Could you please try to replicate this and let us know whether this problem has been fixed? Whatamidoing (WMF) (talk) 00:32, 4 October 2013 (UTC)

Preview doesn't take into account Undo/Redo

The following discussion is marked as answered. If you have a new comment, place it just below the box.

---

Tracked in Phabricator
Task T53947

Hi,

If you undo your last modifications then go to preview your changes, the modifications that you have just undone are still displayed in the modifications... (tested on frwiki) I didn't test to see what is being done when saving the page. --NicoV ^{(Talk on frwiki)} 14:27, 29 September 2013 (UTC)

Yes, this is T53947 which has been assigned a "normal" priority to fix. Thryduulf (talk) 12:50, 30 September 2013 (UTC)

Office Hours to discuss VE

The engineering department is hosting two office hours this week to discuss VisualEditor. The first of these will be held on Monday, 30 September, at 1900 UTC. The second will be held on Wednesday, 2 October, at 0000 UTC. Please join as Product Manager James Forrester discusses VisualEditor and upcoming plans. Thanks! --Elitre (WMF) (talk) 08:54, 30 September 2013 (UTC)

No interest in joining IRC. Please take a look at Wikipedia:Village pump (technical)#Disallow VE software changes from the WMF for the foreseeable future. Fram (talk) 09:28, 30 September 2013 (UTC)

27 unconfirmed bugs

There are 27 unconfirmed bugs that match 'VisualEditor', including ones raised back in July. Anyone with some spare time can help by opening one and trying to reproduce the problem and adding a comment there (or here if you dont want to open a bugzilla account). John Vandenberg ^(chat) 09:44, 30 September 2013 (UTC)

I've done a couple, but I note that while my reports automatically get assigned a status of "NEW", those by Whatamidoing are only "UNCONFIRMED" by default. I've got no idea how this default is set (or why we have the respective levels we do), but I see no reason why their reports shouldn't be confirmed by default. Thryduulf (talk) 13:06, 30 September 2013 (UTC)

User:AKlapper (WMF) can give their account the canconfirm right, which should make their bugs NEW by default. --Krenair ^{(talk • contribs)} 13:26, 30 September 2013 (UTC)

Users who have "canconfirm" rights in Bugzilla have a dropdown on enter_bug.cgi where they can choose between "UNCONFIRMED", "NEW" and "ASSIGNED" as initial status of a bug report. However I admit I have set up a regex so that users who use a @wikimedia.org address for their account in Bugzilla automatically have "canconfirm" and "editbugs" permissions. The entire problem whether to hand out or not these permissions by default is covered in bugzilla:40497. --AKlapper (WMF) (talk) 13:52, 30 September 2013 (UTC)

Thanks Thryduulf; I've confirmed a few more, and we're down to 16 unconfirmed. John Vandenberg ^(chat) 14:46, 1 October 2013 (UTC)

Sorry I think I added another one :p (it's not really unconfirmed, I'm asking testers at it.wp to try to reproduce again, since it was old stuff, and I think it actually got solved somehow, so...) --Elitre (WMF) (talk) 16:20, 1 October 2013 (UTC)

There will likely always be a few genuinely unconfirmed bugs, such as where you need more information or it requires specific hardware for example. Anyway, we're down to 9 now. Thryduulf (talk) 00:05, 2 October 2013 (UTC)

Thanks Thryduulf. It is good to see it down to a manageable level. If someone is adding canconfirm, Jan's bugs are often left unconfirmed for quite a while, but I have always been able reproducible them. He isnt using a @wikimedia.org address on bugzilla, so will have slipped past the regex. John Vandenberg ^(chat) 13:51, 2 October 2013 (UTC)

Based on past experience, the default setting for most bugs I file ought to be "duplicate". Whatamidoing (WMF) (talk) 00:34, 4 October 2013 (UTC)

Visual Editor/Status

On MediaWiki, there is a page called Visual Editor/Status ([6]), which has a kind of "release notes" for old and new VE updates. These notes then get published to the wikis, e.g. Wikipedia:Village pump (technical)#VisualEditor weekly update - 2013-09-26 (MW 1.22wmf19).

How does one correct errors in that page though? Even though it is a wiki, you are not allowed to edit it (as I was told by a MediaWiki admin, "copies of official correspondence that was already posted crosswiki"), and no one at MediaWiki seems to care that the page contains errors, and while they were quick to dismiss my changes as trolling, they have made no effort whatsoever to actually correct the page.

This is a release that will be rolled out to many wikipedia versions on Thursday (including this one), so correcting it before that date seems quite useful. It makes no sense to promise wiki's things you know aren't going to work in the way described, so correcting the page and if necessary posting a new version is only logical.

Can some people (e.g. from the WMF) take a look at the situation and take the necessary actions? I'm not asking to reinstate my version, but the current one isn't acceptable. Can some people also take a look at everything that went on around those edits and take the necessary actions to prevent similar things to occur again? From checking that the page reflects what actually is going to be implemented, to providing clear instructions as to who is or isn't allowed that page (perhaps protect it if it is that official), and so on? Learning from problems is always a good thing. Fram (talk) 12:23, 30 September 2013 (UTC)

I think mw:Talk:VisualEditor/status was the place to alert about that, since that's the way it traditionally works for non-editable pages, although generally speaking adding a simple note to James' talk is also a good move, especially in this case, because it makes sense to me that such an update is eventually corrected by the person who published it - or his coworkers. But I don't think this was an improvement to that page. For everything else, answers from Qgil (who is WMF) should do - also, sometimes it is possible to find answers in Bugzilla threads. As I do from time to time, I'd also like to remind that All comments are read, but personal replies are not guaranteed (from the top of this page). Thanks, --Elitre (WMF) (talk) 14:00, 30 September 2013 (UTC)

Elitre, that's not a "non-editable page", that page is perfectly editable, it just turned out that some people didn't want it to be updated. Contrary to what happened here, at the user guide, where I didn't want to edit it, but was expected to... It's a bit hard to know what you (WMF people) want actually, and it sometimes looks like you only want to give good news and want to oppress criticism in "official" pages. Fine by me, but then don't pretend that you are a wiki and expect collaboration.

Further; perhaps you don't consider my edits an improvement, but "no one", here or there, has indicated what would have been an improvement or has made any attempt at correcting the obvious errors. You know how people feel about the WMF and VE; what did you expect? A thumbs-up? Just like everyone else, you have not indicated what parts of my edit were incorrect. I just have to accept that it was "not an improvement", if not outright "trolling". Never mind that I was the only one to test that release and to note my remarks.

I have no interest in mentioning this at Jdforrester's talk page, the only question I have posted there is answered very unsatisfactory; more importantly, he asked for feedback to be posted either here or at VTT, and I did both. If he wants feedback on his own talk page, he should have requested this, but it would have been a bad idea, IMO. We have public feedback pages, and we have wiki functionality; now you tell me that both were bad options to get this corrected. Too bad, I'm not going to use other means, or at least not go begging at Jdforrester's talk page to get this changed. The last time he needed to change something, he had to be forced, and he took it very ungratefully.

I don't see how "for everything else, the answers from Qgil should do"; you are releasing that version to many wiki-versions on Thursday, but people should just know that the release notes are incorrect and that the correct answers can be found in Bugzilla? It is good that Qgil has made these Bugzillas, don't get me wrong, but why would that be sufficient?

Finally, I don't expect personal replies, I don't care about personal replies. I expect that action is taken when problems are reported, and the least one can do is to correct release notes (or present an addendum or errata) when they have been shown to be incorrect. Fram (talk) 14:53, 30 September 2013 (UTC)

I'll make my words clear - I thought that page had some sort of protection, good to know it hasn't. But I still think that pages with press releases or similar "official" statements, even if anybody can edit them, should be corrected by the people who issued them if the problem is not, say, a mere typo - and that's why general purpose pages (like this one) might not work well in similar situations. Even if you left a note here, like you did now, the only thing others can do about it is reporting that to James so that he can act about it, because he's speaking for him and his team, so I wouldn't want to put words he never said in his mouth (there are many things someone can do when fixing a mistake, strike text, rephrasing, apologising... None of this should happen when the author is not informed). Also, I'll make it even clearer: I don't think we should ping James or leave a message in his talk in every occasion, but we definitely should do this in particular ones (his updates usually do not need to be corrected!). Bugzilla is usually enough because, you know, devs watch that space. The fact that a bug is new does not mean, for example, that they don't know anything about it, but just that none of them is assigned to fix it yet. Actions are taken when people can take them, but this should go without saying. Regards, --Elitre (WMF) (talk) 15:26, 30 September 2013 (UTC)

Thanks for the reply. A few things; he specifically requested feedback here or at VPT: "feedback gratefully received, either here or on the enwiki-specific feedback page." (not part of the "press release" as you call it, but his personal comment to it) If you request feedback at two locations, the least you can do is monitor these pages as well... I left my feedback there and here the 27th, he has since responded to other things, so there was time and opportunity to act upon it. He didn't, so I did. And got blocked for it (and for some still unclear reason then my talk page access got removed as well, very user-friendly interactions at Mediawiki!). And I usually don't interfere in which Bugzilla items should be taken up first or by whom, but this is a time-sensitive issue, it needs to be changed or added to before Thursday, or it becomes meaningless. It is unclear to me whether this (the release notes) even belong at Bugzilla, it has been made clear that release schedules and basically incorrect releases are not a Bugzilla concern, so whether this stood any chance there? By the way, since we are discussing Jdforrester now, Jdforrester (WMF) may be the polite thing to do. Fram (talk) 15:43, 30 September 2013 (UTC)

New References Bug

The following discussion is marked as answered. If you have a new comment, place it just below the box.

---

Tracked in Phabricator
Task T56445

I turned VisualEditor back because it's very useful for what I was doing, but now I can't add references using the pulldown menu. If the page already has references, it either doesn't add the reference at all, on this page (https://wiki.riteme.site/wiki/Vladimir_Gojkovi%C4%87), or adds it as the second reference when it's not really the second reference (https://wiki.riteme.site/wiki/Nataliya_Pyhyda). The really odd thing is that when I look at it using Edit Source, it's down as ref = 0. I hope that helps. Red Fiona (talk) 23:23, 30 September 2013 (UTC)

Edit to add - the bug sounds a lot like the problem Greenrd was having further up the page.

Hi there, it's a known one, although I don't remember the bug number now, I'll locate it later and add your examples. Thanks, --Elitre (WMF) (talk) 16:05, 1 October 2013 (UTC)

54445, as I wrote before, I do think it is going to be fixed soon, because although the status is "new", it's marked as a regression, and these kind of issues definitely have a priority. Thanks, --Elitre (WMF) (talk) 16:25, 1 October 2013 (UTC)

Anarchism - images appear out of place, and overlap with references

Tracked in Phabricator
Task T53664

On Anarchism, many of the images appear out of place; the image in "Organized labour" now appears in "Russian Revolution and other uprisings of the 1910s". Some have dropped down into the references section. In Chrome, this causes the references block is narrower and longer, with images on each side; on Firefox the images and references appear overlapping. One part of the problem is that that {{Anarchism sidebar}}/{{Individualism sidebar}} and {{Libertarian socialism sidebar}} are rendered as expanded in VE, but not in normal mode - there is no way to preview what the page will look like when the sidebar is not expanded; that appears to be Bugzilla:51664. When in normal view mode (not VE), and expand all of those sidebars, a large area of whitespace opens up above "Internal issues and debates", and the images appear there. In the VE, that whitespace is filled with text. So there is a discrepancy between how the page is being rendered in VE and non-VE. I have documented most of this on bugzilla 51664, so please don't rush to create a new bug unless you've properly triaged the problem.

Has the misplaced images problem been seen elsewhere? Is it occurring on pages where it didnt occur previously? John Vandenberg ^(chat) 04:03, 1 October 2013 (UTC)

Hi there. Just a quick note from me, mainly to say that I'm glad to see you again in this page. I think it's not the first time I read something about this topic - and in the last archive of this page you'll find a slightly related thread. I'll add links ASAP, anyway. Thanks, --Elitre (WMF) (talk) 16:14, 1 October 2013 (UTC)

Hi user:Elitre (WMF) its good to be back; I had given up, because significant bugs were not being fix promptly yet it was default for newbies and being rolled out further.

I would appreciate a link, as I couldnt find it in the last archive. I noticed that we have two sets of archives for this /Feedback page; some end with 01-xx, and others end with 1-5, and it is the latter ones that are the most recent. I would like to have the archive pages named consistently, and it would probably be a good idea to build one or more meta-lists of issues raised here and the status of each issue. For example Wikipedia:VisualEditor/Feedback/Archive_2013_5#Complete_article_becomes_a_template_in_VE was archived but not triaged. I have fixed the template, but there still might be an enhancement to be raised in pariod/VE/parser so that either parsoid and the php parser do the same thing, or the new technology reports a useful warning so it is easier to diagnose the next wikitext that does that. John Vandenberg ^(chat) 13:08, 2 October 2013 (UTC)

I'm fixing the archives right now. Nobody touch anything for the next few minutes! — Scott • talk 13:28, 2 October 2013 (UTC)

Hi there, just a temporary answer about the bug you raised, I was thinking of this in that a user (IMHO correctly) pointed out that making sure that pictures comply to guidelines is the first step to troubleshoot issue, and one that even I might sometimes neglect.

Thanks Scott for being bold, please fix links here later? :p (I think it's a bot that archives threads, so, we must make sure it knows how we'd like things to be done from now on, I guess.) Also, we might want those pages to be redirects, because archives are not infrequently linked on Bugzilla.--Elitre (WMF) (talk) 13:33, 2 October 2013 (UTC)

The page renames that we just done mean that all links to the most recent five will be broken, and a redirect isnt possible. John Vandenberg ^(chat) 14:03, 2 October 2013 (UTC)

All done. I was just about to comment on what you've pointed out. It's even slightly odder than that; for no reason that I can discern, the "_03" archive was never created. So, while the archive names with leading zeroes now redirect to the un-prefixed versions, 3 was left unused, meaning I was able to redirect that one. So, four out of the most recent five (1, 2, 4, 5) can't be redirected due to other archives having been moved into their former locations. As incoming links from Bugzilla can't be edited, I've placed a hatnote on those with links to the appropriate renumbered archive in each case; there's not much more that can be done.

Regarding the bot, the archives are now all in a format consistent with its configuration. (I'm going to allow myself a gentle tsk, tsk at whoever set it up in the first place....) I've also modified the listing at the top of this page to be easier on the eye (because Special:PrefixIndex really isn't); it will require manual updating but that's not going to be a huge effort. — Scott • talk 14:23, 2 October 2013 (UTC)

The numbers originally corresponded to the month. I don't think that there were any threads whose last comment was in March. (There were less than a dozen started in March, and I believe that each of them received a response from Jdforrester in April.) Whatamidoing (WMF) (talk) 00:44, 4 October 2013 (UTC)

Railway templates consuming entire page width

Some railway templates are consuming the entire page with, while most others that use BS-header do not (but most have niggly layout issues that are Bugzilla:50714 ). A few of the problematic pages are:

• Ontario_Northland_Railway: VE
• Brunswick-Magdeburg_railway: VE
• East_Lancashire_Railway: VE
• Channel_Tunnel: VE
• Ravenglass_and_Eskdale_Railway: VE

I havent found the commonality in the pages that are problematic among them. Maybe a WP:WikiProject Trains regular will have more luck; I'll leave them a note. John Vandenberg ^(chat) 07:41, 1 October 2013 (UTC)

I've left a note at WT:RDT as well, which will hopefully attract an expert. Thryduulf (talk) 09:51, 1 October 2013 (UTC)

Backwards typing

Seeing the above section (the "snowmen" ref and the search for the oddest VE problem), what about this one?

Type some text, add a ref, remove the ref using backspace, then change your mind and use the "undo" arrow of VE. No, change your mind again and use the "undo" arrow once more, again removing the ref. Now type. Notice anything strange? Yep, I'm typing backwards.[7]

Other tests produced the snowmen, or the insertion of huge chunks of text by VE. [8]

There seems to be something seriously rotten in the state of VE. Fram (talk) 09:00, 3 October 2013 (UTC)

Easy way to check the "backwards typing": go to [9], put the cursor after ref 1, backspace, undo arrow, type. Enjoy! Fram (talk) 09:55, 3 October 2013 (UTC)

Oh, even easier: cursor in front of ref, use the "back arrow" on your keyboard once (so the ref number gets "blue"), and type. Is this a bug of an easter egg? Fram (talk) 09:55, 3 October 2013 (UTC)

Wow! That's really weird! I tried to reproduce it because I was curious and it's a really weird bug! Although when I put my cursor at the end of the "backwards typing" and clicked space, I could type straight again! TeamGale 10:03, 3 October 2013 (UTC)

Let me guess: you are using Firefox? TeamGale, I also need to know your OS and WP skin for the other bug down here. Thanks, --Elitre (WMF) (talk) 10:34, 3 October 2013 (UTC)

Fram, not an easter egg here, maybe an invitation to learn RTL languages? --Elitre (WMF) (talk) 10:34, 3 October 2013 (UTC)

@Elitre (WMF) Sure! Windows 8 and Vector skin. And yes, I use Mozilla TeamGale 10:51, 3 October 2013 (UTC)

Yes, me use Firefox too. And Firfefox has updated just this week, I believe, so that may be the cause. Fram (talk) 11:13, 3 October 2013 (UTC)

Anyway, it's at 54917 now. Thanks, --Elitre (WMF) (talk) 11:33, 3 October 2013 (UTC)

Yeah, I just got this too. It's weird and annoying. I assume the new bidi work. FF 24.0 on Windows 7 - David Gerard (talk) 20:01, 3 October 2013 (UTC)

Hey Fram, David Gerard, can you please try again and report how you are able to reproduce now? Because it works for me as well on both en. and fr.wp. Although the issue looked different from the one it was merged with, what we actually report are "symptoms" of a problem, if James merges it means they have been recognized as due to the same "disease" ;) Thanks, --Elitre (WMF) (talk) 09:53, 4 October 2013 (UTC)

[10] this is my recent test, the same as described above. Gives the same results. I've just tested it with random article at Kesarin Chaichalermpol, an article I hadn't visited before, to avoid caching issues, and I get the exact same result: I'm still typing backwards. I don't get the snowmen, but I only got these once by accident anyway. Fram (talk) 10:01, 4 October 2013 (UTC)

My test case is X window system, but I can't effectively test it while 54946 isn't fixed - David Gerard (talk) 12:12, 4 October 2013 (UTC)

Wrong numbering of references

Tracked in Phabricator
Task T53289

This probably has already been mentioned somewhere, but it can't hurt to bring it to your attention again; when you have a reference in the infobox and references in the article, the infobox ref will normally get number 1, and the refs in the article will get 2-X. Opening it in VE however, numbers the references in the text as 1-X instead (while also leaving a ref 1 in the infobox), which means that ref 1 in the text matches ref 2 in the reflist (since strange enough theer the numbering is still correct). Rtaher confusing... Check e.g. this random article. Fram (talk) 09:49, 3 October 2013 (UTC)

Indeed this is known. It is a recent reappearance of a bug that was first fixed in late July. It was targetted to be fixed by today's release, but that hasn't happened and no new target has been set. Thryduulf (talk) 11:00, 3 October 2013 (UTC)

Testing auto feedback function

Resolved

Just testing to see if this works, please ignore! Fram (talk) 10:06, 3 October 2013 (UTC)

It worked like a charm! Wanna test to see if it works on Bugzilla as well? ;) --Elitre (WMF) (talk) 10:39, 3 October 2013 (UTC)

Update, it does work on Bugzilla indeed! --Elitre (WMF) (talk) 12:58, 4 October 2013 (UTC)

Strange adventures in redirect land

Creating a redirect directly in VE doesn't work, this is a known bug: [11]

Changing incorrect redirect syntax (created in wikitext) into a redirect in VE does work however[12], also tested in [13]!

Bonus: when you go to a redirect source page, you can't open it in VE (perhaps to be expected), but you can't edit any of the older versions in VE any more either! (e.g. this was edited by me with VE, but now no longer can be opened with VE).

Curiouser and curiouser... Fram (talk) 12:26, 3 October 2013 (UTC)

Is any of that actually a problem? Thryduulf (talk) 14:02, 3 October 2013 (UTC)

Yes, it is a problem that a page that is now a redirect can not be edited in VE, even not when starting from a non-redirect version. And it is worrying that things that are not allowed directly, are not a problem when done indirectly. It is obvious that VE can support wikimarkup, but that this has, apparently deliberately, been disabled. Until recently, I thought that the devs didn't want to do the extra coding necessary to allow wikimarkup, but it looks more and more as if they have made extra coding to disalloww it, but that they have missed some instances (Elitre and I have also been playing with methods to get square brackets in VE). And of course (but that one is covered in Bugzilla), it is a problem that one can't normally create a redirect in VE. Fram (talk) 14:06, 3 October 2013 (UTC)

Hmm. I now understand the not being able to edit non-redirect versions of present redirects, I'll bugzilla that. The markup issue would seem to be that it isn't recognising all markup as markup, but I don't fully understand what you're saying there, sorry. As for changing incorrect redirect markup into correct markup, that would seem like desirable behaviour and a workaround for the inability to directly create redirects. Thryduulf (talk) 15:06, 3 October 2013 (UTC)

Desirable but highly inconsistent. It's a flaw in their "no wikitext allowed!" approach, one that hopefully will be extended to all wikitext :-) Fram (talk) 06:49, 4 October 2013 (UTC)

Unable to edit old versions is now T56921. Thryduulf (talk) 15:16, 3 October 2013 (UTC)

Thanks. Fram (talk) 06:49, 4 October 2013 (UTC)

editing in Beta

1.not all programs support Beta. Micro 7 does not to my loss since it is the usual public computer I use.It works on a few upgraded units.

2. I have the expertise and experience to edit but not the computer savy needed for Wiki text. Beta is great when it works but it is frustrating with locked pages, strange jumps on page, and I think not all internet providers allow it to work.

I may give up on editing your pages unless it works. I have written one section 5-6x only to lose it before getting to "submit". Please consider that there is a large pool of computer illiterate scholars out there who know their subjects well but who cannot edit in your present format.Can you suggest a tutor/assistant editor for me to hire in the Bethlehem, Pa. area? iwitness972 Iwitness972 (talk) 18:36, 3 October 2013 (UTC)

Welcome to Wikipedia. Thanks for your feedback. We are working on these problems. VisualEditor will not work on some older web browsers like early versions of Internet Explorer, but we hope to get it working on all of the common modern ones (including recent versions of Internet Explorer, although that's not working properly yet—last I heard, you can do most things, but you can't save any of the changes made in IE).

You might be able to find someone in your area by leaving a message on the talk page for Wikipedia:WikiProject Pennsylvania. Whatamidoing (WMF) (talk) 00:58, 4 October 2013 (UTC)

VE removing paragraph gaps

In a long article, VE decided to turn the double-newlines between paragraphs into single newlines - thus turning the text in question into one wall of text. Here's an example edit - go down to Line 205 and you'll see VE removing the gaps between paragraphs. Compare before and after. This is some pretty serious VE damage - David Gerard (talk) 20:35, 3 October 2013 (UTC)

Thanks for the bug report. Reproduced, test case found, and added to T56946. This is a bug in Parsoid's HTML generation (en edge case that requires a few different conditions to be present at the same time which this article has -- see bug report for details). Since Parsoid does not wrap them in paragraph tags, when VE sends that HTML back, those paragraphs get collapsed. Should be simple to debug and fix. Will be on this tomorrow. Ssastry (talk) 23:09, 3 October 2013 (UTC)

New version doesn't do what it promised

Apart from the things I had already discussed earlier (reflists are not movable, many templates are also not movable, and when they do move, they have the same bugs as files had in moving), another promise of the new v19 version that doesn't seem to materialize: emptying section headers still adds "nowiki" tags: [14]. Fram (talk) 06:35, 4 October 2013 (UTC)

I have reopened the bug 50254. I have asked there for a diff of where this was ever tested and supposed to have worked correctly. Fram (talk) 06:47, 4 October 2013 (UTC)

See also [15], where an editor moves a section and VE leaves an empty header with a nowiki in. Did this already happen or is the new version, which is supposed to have solved this, actually worse than the previous one? Fram (talk) 07:53, 4 October 2013 (UTC)

I'll look at these points ASAP, but in general, do we all try a few refreshings/edits before testing right after a new deployment? Because cache issues can trick us. Thanks, --Elitre (WMF) (talk) 09:57, 4 October 2013 (UTC)

Shut down my computer, started again this morning, tested whether other changes (like moving templates) worked (yes, for some, as expected), so assume that no caching issues are remaining. Fram (talk) 10:03, 4 October 2013 (UTC)

Ok, I was about to say that the issue was actually 50100 (not solved yet), then I saw the discussion on Bugzilla, so we now know of [16], thanks. (PS: I actually don't know if it's better to use pages not edited recently for tests or not, because the problem with the cache is not just on our side - like when you add TemplateData to a template, you won't see any results until you don't perform a null edit on the template itself.) --Elitre (WMF) (talk) 10:52, 4 October 2013 (UTC)

Template search suggestion not working in Monobook.

In Monobook, when I first open the dialogue and type a character into the "add template" text field, the field will get grey stripes for a second, and then the suggestions drop down menu will appear for a split second but then disappear again (too quick to use). Pressing backspace and trying again doesn't do anything, clicking away and clicking back and trying again doesn't do anything. Closing the dialogue and reopening it will cause the behaviour to repeat, however, but of course to no use. Behaviour is normal with Vector skin. FF 24 Win7. --Atethnekos (Discussion, Contributions) 07:40, 4 October 2013 (UTC)

I can't remember the last time it worked properly in Monobook, although I do remember it did. --Atethnekos (Discussion, Contributions) 07:44, 4 October 2013 (UTC)

I'm bugzillaing that right now. Thanks a lot and, in the future, please don't hesitate to report issues as soon as you encounter them :) --Elitre (WMF) (talk) 10:16, 4 October 2013 (UTC) PS: Now at 54965.

Display of changed Wiki-links in VE

Tracked in Phabricator
Task T56984

A small (very small) bug: mouse display of links doesn't get actualized, when the editor leaves the small edit dialog to change links without pressing the "<" button (just by clicking somewhere else in the text the edit dialog closes aswell). Example: change German to "German language|German" in some test article and leave the link editor without pressing "<". The mouse display should show "German language" as internal link info, but still shows "German". However, "German language|German" is correctly saved to the source text (just the display is wrong). GermanJoe (talk) 13:33, 4 October 2013 (UTC)

Confirmed and reported as T56984. Thryduulf (talk) 17:51, 4 October 2013 (UTC)

A weird piece of VE damage, adding a reference and getting snowmen

Tracked in Phabricator
Task T56712

Dig this. What I was trying to do was add PladaoOffice and a reference link, which appeared to add correctly in the VE. Then I noticed there was a full stop after "SunShine Office", so I clicked on it to put the cursor there, and VE added a pile of "☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃", and more each time I clicked again. Note also that my carefully constructed reference is gone, leaving only "<ref name=":0" />", and it's added another spurious one of those higher up - David Gerard (talk) 14:00, 1 October 2013 (UTC)

Something like this? Maybe it's VE's way to tell us that the Season is coming... --Elitre (WMF) (talk) 16:02, 1 October 2013 (UTC)

(edit conflict) this looks like T56712 so I've copied your report there. First time I've seen VE produce snowmen for a while! Thryduulf (talk) 16:07, 1 October 2013 (UTC)

That's the one. I vote that "whackiest new VE bug". It was in Firefox 24.0, Ubuntu 12.04 distro version - David Gerard (talk) 16:21, 1 October 2013 (UTC)

I don't. I mean, after 54642 came out? That's an interesting one. --Elitre (WMF) (talk) 16:27, 1 October 2013 (UTC)

Yeah, but that didn't add snowmen - David Gerard (talk) 16:49, 1 October 2013 (UTC)

Yep, but snowmen are sooo July-version of VE! --Elitre (WMF) (talk) 17:01, 1 October 2013 (UTC)

No snowmen, but another contender in the odd bugs stakes is T53893, which requires a pretty specific set of circumstances. Thryduulf (talk) 00:01, 2 October 2013 (UTC)

Yeah, that was good as well, but I don't think you wanna play this game with me. --Elitre (WMF) (talk) 15:35, 2 October 2013 (UTC)

Thryduulf, it looks to me like T53893 / [17] is doing the right thing, now, but maybe I havent understood it. I'll have to try to reproduce bugzilla:52107 again. John Vandenberg ^(chat) 16:06, 2 October 2013 (UTC)

This bug is really annoying! Every time I add a new reference I can't do anything after it because whatever I click on my keyboard the snowmen appear! Even clicking backspace to delete them multiplies them along with already existing text! Only way to get out of there is to cancel my edit and lose the work I've done! :/ Basically, VE can't be used almost at all at this point, since every addition to an article has to have a reference too! Is there any information about when this bug will get fixed? TeamGale 04:35, 3 October 2013 (UTC)

I'm getting the same - it appears literally impossible to add a reference that works in VE - I get snowmen and a bogus reference tag (see [18]) - David Gerard (talk) 20:25, 3 October 2013 (UTC)

I know! I literally stopped every attempt to add refs with VE! :( My last one was this. I wrote the text and then tried to add one of the two refs. I added the first one and went to check my changes to see if it was OK and it was not. VE had added a name to the ref that was already on the article and put that name on the new one too. So, I came back and deleted it and then saved saying that I would add the refs with the source and that's what I did. Not to mention that when I deleted the ref, the cursor moved automatically to the beginning of the paragraph, sign that if I had started typing or click anything on my keyboard, the snowmen would appear! :/ I really hope it gets fixed the sooner as possible cause there are many people who won't notice the name changing on the refs and it can destroy a whole article! TeamGale 21:25, 3 October 2013 (UTC)

I see James has marked the bug (which might also be the backwards typing bug) super-urgent and a patch will be deployed ASAP - David Gerard (talk) 21:37, 3 October 2013 (UTC)

Thank you all so much! TeamGale 22:31, 3 October 2013 (UTC)

Roan says that the patch has been deployed. Does anyone want to find out whether it's working properly? Whatamidoing (WMF) (talk) 00:47, 4 October 2013 (UTC)

I don't know whether this has been solved (I only got the snowmen once yesterday in all my tests :-( ), but the related "backwards typing" which was marked as a duplicate of this still happens, so I have reopened that bugzilla entry. Fram (talk) 07:13, 4 October 2013 (UTC)

Hello. I tried to test it a minute ago but I encounter another problem...the drop down menus don't appear at all! I tried to add a wiki link on the main text and VE didn't show me the suggestions that much to what I am typing. I ignored it at the moment but a minute later when I clicked on "More" to add a reference, the drop menu didn't appear again. I ended up adding the ref with the source again so, I don't know if the bug is fixed... TeamGale 11:52, 4 October 2013 (UTC)

Testing, will let you know ASAP. --Elitre (WMF) (talk) 11:55, 4 October 2013 (UTC)

Update: OK, I just tried it to another article and it was working. I went back to the previous article I was editing and it was working there too. Maybe it was something temporarily? Plus, I didn't add but I edited a reference on an article with VE and it didn't seem to give me any troubles. TeamGale 12:06, 4 October 2013 (UTC)

Still trying to find out when it happens and when it doesn't, but it definitely isn't totally under control yet: [19]. Fram (talk) 12:11, 4 October 2013 (UTC)

In my case, it happens when I have multiple refs in a row and try to remove a ref from between other refs.[20] Fram (talk) 12:15, 4 October 2013 (UTC)

I was actually concerned about the drop down menus not working: Fram, are you able to duplicate this as well? Thanks, --Elitre (WMF) (talk) 12:43, 4 October 2013 (UTC)

I haven't encountered that one yet (and it is one that is rather hard to ignore :-) ). Fram (talk) 12:52, 4 October 2013 (UTC)

Yep, and I tried with Mb/Vector on FF but wasn't lucky. TeamGale, I am afraid I have to ask you a few more details. Do you recall the exact steps it took you to get to the point where the menus did not work? (also, it would be helpful to know your version of the browser). Thanks! --Elitre (WMF) (talk) 12:57, 4 October 2013 (UTC)

On the other side, I was able to reproduce a bug which places pawns (those in your sandbox are not snowmen, Fram!) when deleting a ref between other two, even if those refs are not editable. I'm hoping to hear from someone on IRC if that has to do with this snowmen one or is a new one, and then I'll file it. --Elitre (WMF) (talk) 14:03, 4 October 2013 (UTC)

Now at 54976. I have to admit I am somehow disappointed that a Konami code when VEditing will not trigger an Easter egg. --Elitre (WMF) (talk) 15:07, 4 October 2013 (UTC)

@Elitre (WMF) Just got back. I made an update on my previous comment that it was working later. It was only a five minutes thing. Probably there was a change happening at the moment...? I don't know. But yes, I can describe what I was doing. I was editing this article. At first I wanted to add a wiki link to the name of an actor. I highlighted the name and click Ctrl+K as always. It didn't give me the drop down menu but when I clicked enter, I got the wiki link. I thought it was weird but I continued the editing. I typed my new text and when I finished I clicked "More" to add a ref but again, no drop menu appeared. I saved the article and added the ref with the source. Then I came here and wrote about it and then I went to edit another article. There, I was getting the drop down menus normally. I went back to the first article I was editing and I could get the drop down menus there too. If I encounter with this again, I'll let you know. P.S. I am using Mozilla. TeamGale 15:53, 4 October 2013 (UTC)

Ok, thanks, now covered by the bug you took the screenshot for. --Elitre (WMF) (talk) 11:34, 7 October 2013 (UTC)

Categories

Just wanted to ask...how can we add categories with VE? In the past I could do it by clicking on "Page settings" but now when I click on it nothing happens! Is there somewhere else a button that adds categories? I searched everywhere but I can't find it. If it's still on the "Page settings" then something is not working right... Thanks TeamGale 09:54, 3 October 2013 (UTC)

Tested this. FIrst click on "page settings" gives no results. Second click opens the page setting window. But I can't do anything there. Has the new version for Thursday already been installed? Or is there some other reason that it has gone so bad today? Fram (talk) 09:57, 3 October 2013 (UTC)

Hi everyone, I just tried and succeeded after a few attempts (cache problem?). I'll keep watching this issue and will certainly file a bug if the thing does not solve itself for everyone; I don't think I can hear from anyone on IRC about this right now since it's the middle of the night in SF, thanks for your tests and reports! --Elitre (WMF) (talk) 10:05, 3 October 2013 (UTC)

(edit conflict)Actually this one with the categories is happening for a while for me. Just when I first found it I was in a hurry and couldn't leave a feedback. Then I totally forgot about it till now that I needed to use it again. It's weird that no one else mentioned it here before though.

Elitre, I don't know if it's a cache problem but I'll try to clean my cache again and re-test it. But the "after a few attempts" is still not right for me. Shouldn't this happening in the first attempt? TeamGale 10:12, 3 October 2013 (UTC)

Update: Nop, still happening the same for me even if I clean cache, cookies etc... TeamGale 10:20, 3 October 2013 (UTC)

Hi TeamGale, of course it should always work ;) Here is what I did (I did not actually refresh my cache); I tested it on en.wp, and the dialog was blank. I moved to it.wp and fr.wp, and it was ok there. I came back to en and this time I could see it normally. I read your notes which suggested that it still didn't work, and then successfully made that edit. I can't remember whether I switched browser in the meantime, because it does not seem to work with Firefox yet (like the unrelated bug above). Digging into this as we speak. --Elitre (WMF) (talk) 10:50, 3 October 2013 (UTC)

Hmm...it seems to be only a Mozilla issue. I just tried it with Mozilla on Greek WP and it still doesn't work. But when I tested it on Google, it was working just fine. TeamGale 11:00, 3 October 2013 (UTC)

54322 reopened. Thanks, --Elitre (WMF) (talk) 11:22, 3 October 2013 (UTC)

It seems to work for me today. Whether that is due to the new release or something else, I don't know. Fram (talk) 11:56, 4 October 2013 (UTC)

Yep...categories also seem to work today for me too :) TeamGale 12:07, 4 October 2013 (UTC)

Having looked a bit more at categories, I encountered another strange phenomenon. On Opel Laubfrosch, which has a lot of categories, the order of the cats on the page settings tab changes. Initially I get 8 categories, from "Opel vehicles" to "compact cars". But when I e.g. click on the drop down button next to 1920s automobiles, and then click again in the "categories" window (to close the drop down without any changes), I get 10 cats instead of 8, and in a different order. "Vehicles introduced in 1924" and "Sedans" are doubled (explaining the increase from 8 to 10), and the 3rd one is now no longer "1920s automobiles" but "1930s automobiles"... This can go on for quite a while, with the occasional disappearance of a cat as well apparently (normally the last one). Things start to break down, with the page settings then no longer working, or it being no longer possible to add a cat, and so on. (By the way, ordering cats seems to be impossible in VE?) Fram (talk) 09:53, 7 October 2013 (UTC)

So, 55405 is for this issue, while 50809 is about sorting cats. Thanks, --Elitre (WMF) (talk) 11:33, 7 October 2013 (UTC)

Template parameters, alternative names

I think I might be blackballed, but I'll give it a go anyway:

If I start a new template and type in "citation needed", I get the "Month and year" parameter already included, and an option to click on "Reason for citation" to add that parameter. But if I start a new template and instead type in the short "cn", the TemplateData isn't loaded, although I can still manually enter the parameters and it works fine, just more slowly (e.g., [21]). FF 24. Win7--Atethnekos (Discussion, Contributions) 05:30, 4 October 2013 (UTC)

Yep this a known bug (T52964). Quite a big one in my view.--User:Salix alba (talk): 06:23, 4 October 2013 (UTC)

Thanks.--Atethnekos (Discussion, Contributions) 06:26, 4 October 2013 (UTC)

What if the TemplateData was included on the redirect page (e.g., on [22] itself) within noinclude tags? Would that be a good fix, a bad fix, or not a fix at all? --Atethnekos (Discussion, Contributions) 07:00, 4 October 2013 (UTC)

I tested that method out with the template sandbox, and it definitely fixed it, I didn't notice anything weird about it. But is it too uncouth to be put into practice? --Atethnekos (Discussion, Contributions) 07:14, 4 October 2013 (UTC)

So I recreated the sample at [23], so if you try putting in template with VE using Cn/sandbox, everything seems to work fine. The only issue I foresee is (and this is obvious) that updating Template Data at the main template page does not update it for the redirects as well (of course). But it seems to be an alright fix otherwise. --Atethnekos (Discussion, Contributions) 07:25, 4 October 2013 (UTC)

Hi, do you want me to add your notes to that bug? Regards, --Elitre (WMF) (talk) 13:01, 4 October 2013 (UTC)

I don't think so. I was just wondering, would this be an acceptable fix to apply? Because I could start doing it right now. --Atethnekos (Discussion, Contributions) 15:46, 4 October 2013 (UTC)

I don't think that putting template data on redirects is a good thing. Redirect pages typically have no more than three things: the #REDIRECT [[]] itself; some templates like {{R to section}}; some categories. See Wellington (Somerset) railway station for an example which has all three. As noted above, it is easy for the TD on the redir to get out of synch with the main template; but besides that, some templates have several redirects - see for example those for Template:Citation needed. Setting up all of those is a big task, and keeping them in synch would be a nightmare. If VE is the problem, VE should be fixed. --Redrose64 (talk) 17:54, 6 October 2013 (UTC)

But as it is right now, TD on all redirects are out of sync with the main templates: It doesn't show up at all. --Atethnekos (Discussion, Contributions) 18:05, 6 October 2013 (UTC)

This needs to be solved in a "real" way, but as an interim measure, I think that it might be worth copying the TemplateData into the redirects for a small number of the most commonly used ones, including cn and fact. That will need to be undone someday (so that the today's TemplateData doesn't permanently override the master copy, once a real solution is in place), so it would be wise to keep a list. Perhaps making a list at the end of the TemplateData page would be the best choice. Whatamidoing (WMF) (talk) 18:32, 8 October 2013 (UTC)

Template documentation header problem

Hi.

I am not sure if it is a VisualEditor bug but then, I don't have any other answer for the question "what has caused this issue?" Here we go.

• First screenshot: Shows Firefox v24.0 loading Template:Documentation/start box, no user has has logged on, the template renders exactly as its code (revision 560807734) logically leads us to believe it would. Now, as you open the next screenshot, pay attention to what you see in front of "Template documentation": You see "[View] [edit] [history] [purge]". It is transcluded in every template that uses {{documentation}} and [view] brings up view mode. So far so good.
• Second screenshot: Same web browser, I am logged on. The links now read: [Edit source] [edit] [history] [purge]". Problem? Well, this template is transcluded in every template that uses {{documentation}} and clicking [edit source] does not bring up source editing screen; it is still view mode, with the link by mistake saying "edit source".

I tried bypassing my browser cache but that did not do anything good.

Best regards,
Codename Lisa (talk) 10:25, 4 October 2013 (UTC)

Hi there, VE can't be used in the Template namespace, so it can't cause issues there - although you might get errors with templates while you are editing a page with it. Maybe Wikipedia:Village_pump_(technical) can help you? Thanks, --Elitre (WMF) (talk) 10:35, 4 October 2013 (UTC) PS: since you get that error once you are logged in, there might be something "wrong" among your Preferences - like a gadget or some kind of code misbehaving in your .js pages.

Hello, Elitre. I just tried disabling VE in Preferences -> Editing and the problem went away. So, I am afraid with all due respect, it does seem to have something to do with VE. Best regards, Codename Lisa (talk) 10:41, 4 October 2013 (UTC)

(edit conflict) P.S. I tried disabling all gadgets before reporting but I will try disabling .js page too. Best regards, Codename Lisa (talk) 10:43, 4 October 2013 (UTC)

(edit conflict) P.P.S. All gadgets, commons.js and commons.css are out of action. Nothing. Best regards, Codename Lisa (talk) 10:52, 4 October 2013 (UTC)

I'll test this properly ASAP, I still don't think VE gets to decide how links are called in other namespaces - something might have been renamed, but I guess this is not done by VE developers? Also, some people wrote code changing the name of the labels after VE arrived, not sure if you're using that code. We'll see :) Thanks, --Elitre (WMF) (talk) 10:46, 4 October 2013 (UTC)

Hi. You might want to look at Special:PrefixIndex/User:Codename_Lisa/ and tell me if you want anything else disabled. Best regards, Codename Lisa (talk) 10:54, 4 October 2013 (UTC)

Hi again, I have now moved it here because, although VE seems related, the issue might still be due to some overlapping on-wiki settings that do not require an intervention from VE developers. If this is the case instead, I'll be happy to file a bug ASAP for you. Thanks :) --Elitre (WMF) (talk) 11:43, 4 October 2013 (UTC)

This does sound like a carry over from how the section edit tabs are renamed for VE. Some javascript somewhere is modifying the display of various classes. Looking at the html

<span class="mw-editsection plainlinks mw-editsection-expanded" id="doc_editlinks" style="direction: ltr;">
 [<a href="/wiki/Template:Infobox_book/doc" title="">view</a>] 
 [<a class="external text" href="//wiki.riteme.site/w/index.php?title=Template:Infobox_book/doc&amp;action=edit" title="">Edit</a>] 
 [<a class="external text" href="//wiki.riteme.site/w/index.php?title=Template:Infobox_book/doc&amp;action=history" title="">history</a>]
 [<span class="noprint plainlinks purgelink"><a class="external text" href="//wiki.riteme.site/w/index.php?title=Template:Infobox_book&amp;action=purge#" title=""><span title="Purge this page">purge</span></a></span>]
</span>

This is the same as in the section edit links which also use <span class="mw-editsection mw-editsection-expanded" style="direction: ltr;">. The upshot of this is that the css/js which changes the labels also affects the links in the documentation page. It could be fixed by adding a not(.plainlinks) to the appropriate code, if I could find it.

I would say more could be done to have a simple class for VE edit links, the css you need to find just these is much harder than it needs to be.--User:Salix alba (talk): 12:35, 4 October 2013 (UTC)

Hi User:Salix alba, can I copy your comments at the Tech VP? If there is more action required on my side please let me know :) Thanks, --Elitre (WMF) (talk) 13:06, 4 October 2013 (UTC)

Yep no problem. --User:Salix alba (talk): 16:38, 6 October 2013 (UTC)

Bugs are now randomized, apparently

Once one bug disappears (like the page settings not working, or the snowmen), another strange one seems to appear instead. Something has become very unstable apparently. \

The new one (for me at least, perhaps it already existed): when I edit a page in Beta (my sandbox, or a main space page), I get next to the page title two pale blue links, "edit source / edit beta", which bring me to the section editing for the lead. I don't get these pale links for other sections, only next to the title. I can't remember these being there, and I can't see the use for them (and if they have a use, they would probably be wanted for other sections as well). Fram (talk) 12:01, 4 October 2013 (UTC)

Hi Fram, will add this to my tests. --Elitre (WMF) (talk) 12:39, 4 October 2013 (UTC)

No luck here either. Can you please take a screenshot, so that I can add it when I file a bug? I'll find your specs somewhere in this page. Thank you, --Elitre (WMF) (talk) 13:16, 4 October 2013 (UTC) PS: as you can imagine, Edit links where they don't belong and when you are already editing a page do not make much sense :)

File:VE error Fram 1.jpg! Fram (talk) 13:35, 4 October 2013 (UTC)

Ok, thanks. FF v.24, I assume, and you don't have any gadget that might be conflicting? --Elitre (WMF) (talk) 13:47, 4 October 2013 (UTC)

FF24 indeed, and I don't think I have any conflicting gadgets, certainly no personalized js or anything only standard gadgets like Twinkle or Hotcat, which I haven't activated or deactivated recently. Fram (talk) 13:50, 4 October 2013 (UTC)

Tnx, at 54971 now, unconfirmed status since I couldn't reproduce but maybe others can. --Elitre (WMF) (talk) 13:58, 4 October 2013 (UTC)

Note that I only get this when the page has at least one section header. Pages without section headers don't have this behaviour. Fram (talk) 14:12, 4 October 2013 (UTC)

I see this at User:Thryduulf/sandbox3 (which has multiple section headers), and at this version of sandbox4 with 1 section header. I don't see it at the previous revision which had no section headers. Thryduulf (talk) 17:58, 4 October 2013 (UTC)

@Fram and Elitre (WMF): what skin are you using? I see it when using Monobook but not when I tested it in Vector. Thryduulf (talk) 18:04, 4 October 2013 (UTC)

I have the standard one (Vector? The one that was introduced as the default a few years ago). Fram (talk) 07:01, 7 October 2013 (UTC)

Yes, that's Vector. Cheers. Thryduulf (talk) 09:33, 7 October 2013 (UTC)

Fram, what's your setting at Special:Preferences#mw-prefsection-gadgets for "Add an [edit] link for the lead section of a page"? Does the problem go away if you disable that gadget? Whatamidoing (WMF) (talk) 18:35, 8 October 2013 (UTC)

That gadget was "on". And indeed, with that gadget "off", the edit links disappear in VE mode, and when I turn it back one, they reappear. Nice catch! Fram (talk) 07:34, 9 October 2013 (UTC)

Double check

The article Double check has "Be6++" in the caption of the first chess table, when it should be "Be6+" (the lede says "+", not "++", is "almost always" used.)

I cannot, for the life of me, figure out how to remove that extra plus sign using VE. I can't place my cursor in the caption. Double-clicking in the caption or the chess board does nothing. Clicking the little puzzle piece gives me a dialog with a bunch of numbered parameters but no clue how to edit the caption. Can someone walk me through the steps to do what I'm trying to do?

Also, when I click "edit this page - beta", VE appears to take all the chess pieces off the boards and move them below the chess boards. 28bytes (talk) 20:17, 4 October 2013 (UTC)

The caption appears to be set by parameter 61. To make this intuitive, someone needs to write TemplateData for the template. If you aren't comfortable doing this yourself, then a request on the template talk or at Wikipedia talk:WikiProject Chess is probably your best bet (I don't grok chess and don't understand the notation so it's probably best if I don't do it!).

Your second point is probably related to the known issues about templates that involve aligning multiple images - railway route diagrams and sports team shirts are also affected by this. I can't immediately find the relevant bug(s) though, sorry. Thryduulf (talk) 23:48, 4 October 2013 (UTC)

Unfortunately, that is the least of your worries. Chess templates can not be edited in VE, and the rendering of articles containing the chess templates is broken in VE. Even if you do find parameter 61, altering it will cause the VE or Parsoid to create a dirty diff. See bugzilla:51932. Perhaps the TemplateData should say that this template is not supported yet. Or is there some way to disabled VE on this template?

The chess templates were designed to be readable and editable in source mode. The existing design doesn't translate well into VisualEditor. It might be more useful to have the chess boards rendered by an extension that understands a chess notation.(i.e. bugzilla:23401) e.g. we now have extensions for maths, chemistry and music notations .. why not chess too? Latex has the ability to render chess boards. Also there is an extension that adds PGN support. See bugzilla:23401 John Vandenberg ^(chat) 23:52, 9 October 2013 (UTC)

Cite journal template is missing a Title field

Status	New:
Description	The cite journal template is pretty messy and could use a look -- e.g., there are a whole bunch of duplicated parameters, for example there are approximately 20 billion parameters that are variants on Author. To be super-clear, I am talking about Cite Journal, not one of the variants such as Cite Journal-Web
To duplicate:
Operating system	Ubuntu Cinnamon
Web browser	Chrome
Site	enWP
Workaround
Skin	Vector
Resolution
Bugzilla

Sue Gardner (talk) 17:23, 5 October 2013 (UTC)

Oh blah, I just realized I was wrong. I originally filed this reporting that the Cite Journal template was missing an Article Title field, but I realize now it's there just labeled Source Title. I will keep this bug report here though, because the messiness of the template deserves a look anyway. It's probably worth renaming Source Title to Article Title too -- the latter feels more intuitive. Feel free to close/resolve this if you want :-) Sue Gardner (talk) 17:27, 5 October 2013 (UTC)

Not really a Visual Editor issue, though: Template talk:Cite journal would be a more appropriate place for the discussion. The only Visual Editor deficiency that feeds into this is the lack of cut-and-paste, because most people using the normal wikitext editor would simply copy an existing instance of the template and edit it, not try to start from scratch.—Kww(talk) 17:52, 5 October 2013 (UTC)

I followed Kww's suggestion, so everybody interested in this issue please comment about it here. Thanks! --Elitre (WMF) (talk) 11:49, 7 October 2013 (UTC)

I've changed the TemplateData for {{cite journal}} so that there is simply a "title" parameter.[24] It looks like this was copied from another cite template with a different description. The rest of the bug report is a bit to vague to really be actionable, the duplicate parameters are needed so that all the transclusions work.--User:Salix alba (talk): 00:44, 8 October 2013 (UTC)

VE issues with pages starting with a full stop (period)

I've just reported T57493 and T57494 which both relate to VE problems on pages starting with a full stop (.), e.g. .mp, talk:.uk.

• T57493 is that articles starting with . do not load in VE. The URL changes but the page remains in view mode. This only affects article-space pages, e.g. .mp. User:Thryduulf/.100 and user:.anaconda are not affected.
• T57494 is that talk pages starting with . have a VE edit button when they shouldn't. This only affects article talk pages, e.g. talk:.mp, not e.g. user talk:Thryduulf/.100.

I am noting this here as I have only been able to test in Firefox 24 on linux. It would be useful if people with access to other systems/browsers could verify whether they are affected too. Cheers, Thryduulf (talk) 01:42, 9 October 2013 (UTC)

I get the same for Chrome on a Mac. In the error console I get

Exception thrown by ext.visualEditor.viewPageTarget.init: mw.Title: Could not parse title ".mp"

Looks like both bugs are dups of T40081 which will has been fixed. It should go live by Thursday 17 October.--User:Salix alba (talk): 04:59, 9 October 2013 (UTC)

@Thryduulf and Salix alba: Yes, unfortunately we found this bug in MediaWiki and had to undertake a major re-write of a core part of MediaWiki's Javascript (mw.Title) to make it actually do what people expect (i.e., work like MediaWiki's Title.php). This will incidentally fix bugs in UploadWizard, Page Curation, Notifications and, yes, VisualEditor. Sorry for the disruption. Jdforrester (WMF) (talk) 15:52, 9 October 2013 (UTC)

Succession boxes

I am very impressed by how well succession boxes work with VE. While I'd appreciate a more WYSIWYG way of editing them, the current setup works quite nicely, with the various templates placed neatly into one dialog.

Thank you!

— Preceding unsigned comment added by Ypnypn (talk • contribs) 15:58, 9 October 2013 (UTC)

@Ypnypn: Thanks! Making a transclusion editor that can handle even the most complex sets of templates and other transclusions (like {{#tag:Foo|bar|baz}} was a big challenge, and we don't think it's anything close to perfect yet, but I'm glad you found it at least workable. A more WYSIWYG-like way of editing table-like templates (most especially, infoboxes) is something we'd like to get around to doing at some point in the future, yes. Jdforrester (WMF) (talk) 16:10, 9 October 2013 (UTC)

Infoboxes still get deleted

The following discussion is marked as answered. If you have a new comment, place it just below the box.

---

One bugzilla that was related to this was recently closed, others seem to still be open, so just to let you know that despite the extremely low number of VE Edits still ebing made, this still is a problem, e.g. [25]. Fram (talk) 13:43, 4 October 2013 (UTC)

Yep, I think the main one is 47790 which is assigned. --Elitre (WMF) (talk) 13:46, 4 October 2013 (UTC)

The solved one is 54446, no idea if it is really solved or not though, it certainly seemed to be only a minor aspect of this problem. Fram (talk) 13:53, 4 October 2013 (UTC)

@Fram: It looks like we're getting somewhere; Ed is working on a patch for T57336 which should help a lot.--Eloquence* 21:34, 5 October 2013 (UTC)

I hope so, it looks to me like the single most common major VE problem (yet another example), at least of those that still get saved by editors; nowiki errors just result in people not making the edit, which is probably even more problematic but less visible. Fram (talk) 09:30, 7 October 2013 (UTC)

@Fram and Elitre (WMF): A fix has landed in master; if you have time help with testing, please see my last comment in T57336.--Eloquence* 18:44, 9 October 2013 (UTC)

Eloquence, I attempted several times to reach that test wiki, but I only got a 503 error message :/ . It's possible that the Thursday deployment occurs before I am able to try again. Thanks, --Elitre (WMF) (talk) 20:53, 10 October 2013 (UTC)

Drop Down Menus

The following discussion is marked as answered. If you have a new comment, place it just below the box.

---

Tracked in Phabricator
Task T57343

OK...I was encounter again with this weird thing and I was trying to understand when it's happening. What I noticed is that while I was getting more down to the page, the drop down menus were getting "shorter" and sometimes disappear at the very end. I tried it to many pages to see if it was happening everywhere and it does. I don't know exactly how to describe it that's why I took screencaps from the page. All three are from the same page, in different height. See how the drop down menu of "more" can be seen entirely at the top of the page and how it gradually disappear as I get closer to the bottom. It's really weird!! The same thing happens when I am trying to add a wiki link in the article's text and to be honest, that's how I notice the gradually disappearing.
P.S. I uploaded the screencap as a free own work but I don't know if that is right. If it's not, can you please change/add the license on the upload page to fit the right criteria. Thanks. TeamGale 11:13, 5 October 2013 (UTC)

I'll look at the bug report in a moment, but everything you need to know about screenshots for bug reports should be at Wikipedia:Screenshots of Wikipedia. If there is something missing from it do please add it (or ask on the talk page). Do also say if you can think how to make it more prominent. Thryduulf (talk) 22:13, 5 October 2013 (UTC)

I can reproduce the bug using Vector in Firefox 24 on Linux but not when using Monobook. I've reported it as T57357, but it would helpful if you could confirm that you were using Vector skin in Firefox 24 on Windows 8? Thryduulf (talk) 22:35, 5 October 2013 (UTC)

Thanks for the link and all the help. Didn't know there was a link with instructions. I'll use it if I'll need to upload a screenshot again. I updated the screenshot with what I am using but I'll write it here as well. Firefox 24, Windows 8 and Vector skin. Hope everything is OK now. TeamGale 08:47, 6 October 2013 (UTC)

I can confirm that the lower you go on a page, the less you see of the drop-down menus. A contender for most bizarre error, this one. On a page like Opel Laubfrosch, I only can access "strikethrough" from the "more" menu and nothing from the "paragraph" menu when I am at or near the bottom of the page. (That page is also a nice indicator of the infobox probem; when you are removing empty spaces at the top in VE mode, you are actually removing infoboxes which are "below the fold", not visible to the editor (on most regular screen - resolution combinations). Fram (talk) 09:40, 7 October 2013 (UTC)

Thanks for the report and the screenshot. (I changed the bug number since it was a dupe.) Reassuring Fram that the easily deleted infobox bug instead is going to be fixed quickly, since Eloquence seems to be pushing for this to happen. --Elitre (WMF) (talk) 10:51, 7 October 2013 (UTC)

I can't reproduce this bug in Safari 6/Mac OS 10.7.5 (Vector). However, I can reproduce this in Firefox 24, except that it's even more extreme: only a little bit of scrolling (one [blank] line of article space [the 'fake' space due to the infoboxes]) starts shortening the 'More' dropdown menu, and by the time the first section heading, ==The name==, is off the screen, I can't see anything in the menu. Whatamidoing (WMF) (talk) 18:44, 8 October 2013 (UTC)

I couldn't reproduce this bug in either Firefox 24 or Chrome 30 (Windows 7, Vector). I wonder if it's specific to Unix-based operating systems? --Dan Garry, Wikimedia Foundation (talk) 20:31, 8 October 2013 (UTC)

The fix was deployed yesterday. I can't reproduce it now. John Vandenberg ^(chat) 00:08, 10 October 2013 (UTC)

Can't reproduce it anymore either, seems like it's OK :) Thanks TeamGale 08:51, 10 October 2013 (UTC)

Reversing text direction bug is back

The following discussion is marked as answered. If you have a new comment, place it just below the box.

---

Tracked in Phabricator
Task T56917

Editing Microsoft Works (this version, I've edited this section of the article since):

1. Go down to "File format compatibility".
2. Select text "abandoned in 2007, which has been experimentally published as wps_test" - type "libwps", highlight it and italicise it from the toolbar.
3. Select text " works for extracting" after footnote [15]. Note, select the space immediately after the footnote!
4. Start typing to replace the highlighted text. You are now typing Latin right-to-left.

The bug doesn't seem to be triggered with just step 3 - I needed to do step 2 as well - David Gerard (talk) 12:56, 13 October 2013 (UTC)

And now I can't duplicate it editing that old version per my instructions. ARGH Heisenbug - David Gerard (talk) 13:25, 13 October 2013 (UTC)

Go to Asset allocation, position the cursor behind the first reference, backspace once (to highlight the ref), start typing, and there you go. I don't thinh the reverse text bug was supposed to be solved yet anyway... Fram (talk) 10:01, 15 October 2013 (UTC)

Pawn inserting text between convert and ref

I don't have time atm to see whether this is a duplicate or not, but at [26] try inserting anything between the close parenthesis at the end of the conversion template and the reference and you get exactly one pawn.

Inserting anything before the reference in the paragraph above gets you the reverse typing bug. Thryduulf (talk) 12:02, 15 October 2013 (UTC)

Inadvertently (and invisibly) going bold

The first difference in this diff explains the title. When you go to the old version of the article, and position your cursor after the comma, press backspace, and then add something else instead (a hyphen, dash, whatever), you are adding that part inside the "bold" title. In this case, the difference between bold or not bold is invisible (to me), but I don't think this behaviour is always wanted (and wouldn't happen in wikitext editing). Fram (talk) 12:08, 16 October 2013 (UTC)

Unnecessary changes

The following discussion is marked as answered. If you have a new comment, place it just below the box.

---

VE seems to make unnecessary changes. I wouldn't mind so much if it always helped to maintain the layout of invisible elements, but normally it just screws them (like infoboxes, or position of templates), without any effect on the rendered page but with a less easily readable wikitext editing window.

What I notice now though are totally unnecessary and hard to explain changes to ref names. For some reason, VE decides that all ref names need to be in quotes, which is not true at all and doesn't help one bit. It also decides that between the final quote and the forward slash, there needs to be a space. All this has no effect on the rendered page, and doesn't make the wikitext page any easier (or harder) to read, so why does VE bother doing this, which only helps to make diffs a lot longer.

Take a look at e.g. [27]: can you easily see if any significant change has been made, and what that may be?

First difference; <ref name="globsec-arjun"/> becomes <ref name="globsec-arjun" /> Further: <ref name=nomorearjuns> becomes <ref name="nomorearjuns">

and so on. I have not found the actual significant difference between the old and new version. What is the purpose and benefit of this? If VE would always make the "invisible" layout clearer and better, fine, but VE doesn't care one bit about wikitext layout, so I don't get this useless editing. Fram (talk) 09:27, 7 October 2013 (UTC)

The space before a trailing / in a HTML tag (ie. <tag />) is the canonical form according to HTML standards (AIUI). Using canonical forms where possible is generally a good thing, so newly added and amended tags should certainly be in that format. However, the value of converting tags that are irrelevant to the edit performed is almost certainly outweighed by the disadvantages of diff complexity and user confusion though. I'm sure that we've discussed something like this before though, but I can't immediately find anything in bugzilla or the archives. Hopefully @Elitre (WMF): will have better luck. Thryduulf (talk) 09:54, 7 October 2013 (UTC)

Oh yes, I have no problem with VE using whatever method they want for newly created named refs and the like (although the ref name":0" for a first named ref is really poor, no idea why they went with an initial colon and started at "0" instead of "1", this seems a developers habit, having a version zero to start with instead of starting with version 1 like the rest of the world), I only wonder why they would want to convert existing, unproblematic ones (something that e.g. in AWB is expressly disabled and discouraged as pointless busy-bodying). Fram (talk) 09:59, 7 October 2013 (UTC)

Although I can't provide the bug number, we had already asked for the diffs to be marked more clearly. As for the renaming, can you please link a diff where this happens again today? I need to mention it on Bugzilla, I thought this had been fixed. --Elitre (WMF) (talk) 10:46, 7 October 2013 (UTC)

Renaming? Currently named refs are not renamed, it seems, they have quotes added to their name though ("X" instead of X); new named refs get the ":0" name and so on. If you mean something else, I have misunderstood your question. Fram (talk) 10:51, 7 October 2013 (UTC)

Yes, I meant this :0 name thing :) --Elitre (WMF) (talk) 10:52, 7 October 2013 (UTC)

OT PS: is there a way I can switch between WP skins with just 1 click, does anybody know? --Elitre (WMF) (talk) 14:37, 7 October 2013 (UTC)

Not directly AFAIK. You can add ?useskin=skin (or &useskin=skin if the URL contains "index.php?"), which lasts until you load a different page. skin is either "monobook" or "vector" (there are other options but VE only supports those two). Thryduulf (talk) 16:42, 7 October 2013 (UTC)

Yes, VE/Parsoid shouldn't be making dirty diffs -- and these kind of dirty diffs is an exception rather than the rule. This is a bug. @Elitre:: could you please throw this into a bug report? I am rushing out now and wanted to respond to this before running out. Ssastry (talk) 23:18, 7 October 2013 (UTC)

55461 then. Thanks, --Elitre (WMF) (talk) 08:54, 8 October 2013 (UTC)

On a related point, do we have a bug open to complain about using :0 as the "name"? If not, I think we should start one. Something like Word0 (any word taken out of the ref that isn't already in use, plus any number if you want) would much be better. Whatamidoing (WMF) (talk) 22:22, 8 October 2013 (UTC)

WhatamIdoing, I believe that's not intended, and 54445 was fixed for that reason? That's why, Fram, I'm asking you if you're aware of references still getting the 0, because I want to throw those diffs on Bugzilla, if any. Thanks! --Elitre (WMF) (talk) 14:37, 10 October 2013 (UTC)

If I find some, I'll drop a note here. I have checked some 60 VE edits on French Wikipedia, containing a truckload of vandalism and a few nowikis[28][29] and misuse of section headers for text[30], but not a single one used a ref, so no luck there. Looking at the English Wiki, I have another example of unnecessary ref name changes here.

So I created an example of my own, here, and yes, refs still get the ":0" treatment. I've undone the change immediately afterwards, if anyone was worried :-) Fram (talk) 15:01, 10 October 2013 (UTC)

Thanks for the test (and for reverting it immediately, of course). I want to ping the team on IRC on this, so, just double checking: all you did, Fram, was reusing Sparaco's reference after the word "Netherlands". Am I right? Thanks, --Elitre (WMF) (talk) 19:16, 10 October 2013 (UTC)

Yes, I simply inserted a reference, and made sure that when using an existing reference, I took one that didn't have a ref name yet. Nothing else, no fancy tricks. I don't know whether it made a difference that I inserted the new instance of the ref before the original one, that can be tested if needed. Fram (talk) 19:45, 10 October 2013 (UTC)

Ok, I have some answers here. I asked James on IRC if VE adding that ref name 0 was a bug (because we thought it was). He said No, what was wrong is that it shouldn't do that unless the name is needed (i.e. the reference is re-used). He confirms that it auto-names references (as ":0", ":1", ":2", … to avoid clashes with names that humans would pick). James also added that If a reference is removed, the others are renumbered in the page but not in name, no (which means, they can change from being [3] to [2], but should not change from ":3" to ":2", for example). I asked why we are using numbers, and learned that we could use :a, :b, :c instead, except that that assumes you can use a Latin keyboard (Arabic numerals are much more common). Unfortunately, it seems that working out what to put instead of just a number (or a letter) is hard for VE, so it can't, like I suggested, pull out the name and surname of an author (for example). At this point, since in a given text a mix between named and numbered references can be found very easily, the name and the number of the reference can't match. So starting with 0 or with 1 doesn't really make a difference, I guess. HTH, --Elitre (WMF) (talk) 20:10, 10 October 2013 (UTC)

Thanks. I would prefer to get it started at 1 instead of 0, but that is really a lowest-priority request. More useful would be the possibility to let the editor give the ref a name at the moment that a ref name is created, but even that is probably not really a top priority. Fram (talk) 20:31, 10 October 2013 (UTC)

Hey Fram, so I discussed this with Ed and he pointed out that starting at 1 would make it more likely for some of the numbers to match up, especially for new VE-created articles, which surely would increase the confusion that the two are somehow related? It is my understanding that this system actually replaces the former one which enabled the user to choose a name (this is seen as a metadata, so not something a typical VE user should worry about). Maybe it's not the perfect place, but it's probably something worth raising at mw:Talk:VisualEditor/Design/Reference Dialog? Thanks. --Elitre (WMF) (talk) 21:01, 10 October 2013 (UTC)

I don't understand why "starting at 1 would make it more likely for some of the numbers to match up, especially for new VE-created articles". Now you start at 0, and the second auto-numbered ref is 1. Does this mean that as soon as you get two or more numbered refs, the chance of an accidental match increase? If so, please use a different scheme, e.g. A1 to Z9, or whatever decreases that chance. If not, then please explain what the difference between 0 and 1 actually could cause (preferably with an example), as I don't understand this objection. Fram (talk) 07:50, 21 October 2013 (UTC)

Yes, I think this is about accidental matches. Especially from the perspective of the less experienced editor, it might be desirable for <ref name=":1" /> to match with . I've asked James F why they're using such an odd naming scheme, and the answer is that it's this system is multilingual ("A" doesn't exist in many languages/many users' keyboards) and also that they want something that is unlikely to have been added manually by a user. Your suggestion of "A1", for example, might be a logical choice for a user working on A1 paper or A1 steak sauce. Whatamidoing (WMF) (talk) 18:43, 22 October 2013 (UTC)

For the record, similar unnecessary changes are still being made today, [31]. Fram (talk) 15:58, 21 October 2013 (UTC)

Navbox template placed after citation template

The following discussion is marked as answered. If you have a new comment, place it just below the box.

---

Tracked in Phabricator
Task T57856

See this edit; I deleted a stub template that was placed between a reference template and a navigation box template, which resulted in both templates ending up on the same line with the navbox displaying all messed up. --WS (talk) 12:50, 8 October 2013 (UTC)

Hi WS, I'd wait for the usual weekly deployment to happen before attempting to reproduce it, the potential bug (or something it depends on) might have been fixed in the meantime. --Elitre (WMF) (talk) 21:03, 10 October 2013 (UTC)

I have no idea when the weekly deployment takes place, but the same still happens now. --WS (talk) 09:04, 16 October 2013 (UTC)

Hi Wouterstomp,

Normally, it happens on Thursdays in the early afternoon (California time). But I just tried it myself (the update should have finished about three hours ago), and the same thing happened. So you are now responsible for the creation of T57856. Thanks for reporting this. It is a somewhat unusual combination of factors in this particular article, and it might not have been noticed for a long while if you hadn't taken the time to tell us about it. Whatamidoing (WMF) (talk) 23:49, 17 October 2013 (UTC)

Typical examples of remaining VE problems / bugs

These are all known, I believe, but it doesn't hurt to bring them in the spotlight again (and perhaps some of them were already supposed to be fixed or thought to be very rare).

• Wikilinks get divided, and subdivided, and so on: here, scroll to the bottom of the diff. The already divided link to Motor vehicle theft now becomes three links instead of two. It doesn't seem to have been intentional...
• Exact formatting is difficult: here we get the typical example that bolding a complete wikilink puts the "bold" wikiformatting inside the piped link, instead of outside an unpiped link; and a comma which shouldn't have been bolded gets bolded as well.
• A similar thinh happens here, where one letter is not included in a wikilink. This seems to be an accident, not a stylistic quirk done on purpose.

That's three times in about 30 edits. They are minor problems, but when you get them so often, they again become quite annoying. Fram (talk) 13:38, 11 October 2013 (UTC)

Going from memory, which may be faulty:

1. Known, bad, and apparently difficult.
2. This isn't "wrong", even if it's not the way that most experienced editors choose to format the page. The comma will get bolded if the user selects the comma when applying the bold text formatting.
3. The belief here is that the person didn't select the whole word. So the choice is to let the users make the errors—producing a lot of E[[xamples]] when users only select the last seven characters instead of all eight—or to prohibit all users from deliberately linking only part of a word when they want to.

On that last item, I'm personally tempted to take the other alternative: I can't remember making a link that involved only the last part of a word/really not wanting the whole word to be linked. It's possible that other people are trying to make links like Trans-[[Siberian]]. But I'd prefer a more significant solution, like being able to see and edit the link and the label separately in the link tool. Whatamidoing (WMF) (talk) 19:40, 15 October 2013 (UTC)

For all its nuances and learning curve these types of problems never occur with the Wikitext editor! Just like anything, there is going to be a learning curve. Many things are much more difficult in VE than they are in Wikitext. I'm sure eventually the WMF will get the problems sorted out and the software will be worth the effort that's been put into it. These continuing problems emphasize though how extremely important it is to properly test the software before its being released. These are easy examples of things that should have been caught when it was being developed not a year later. Its problems like this that show the decision to disable it as a default editor, incuding and expecially for anons was the right one. 138.162.8.58 (talk) 20:01, 15 October 2013 (UTC)

There are advantages to both systems. For example, if everyone used VisualEditor, then BracketBot wouldn't need to send messages to a couple hundred editors every day about their link-breaking typos. The link tool in VisualEditor never produces link-breaking [[mismatched bracket]s. List formatting (especially converting existing paragraphs into a properly formatted list with no WP:ACCESS-violating intervening blank spaces) is easier and faster in VisualEditor. Several people have said that VisualEditor allows them to focus more on their writing and less on the existence of of brackets, templates, and other infrastructure.

But there are things that VisualEditor simply can't do yet (adding rows to a table, for example), problems it currently has (I'd say that nobody wants to add links with only a space, like the [[link| ]] shown in #1, except that I actually did that a while ago), and things that it might never be as appropriate for (can you imagine writing a complex template in VisualEditor?). The eventual goal is for VisualEditor to be good enough that people who want to use it will be able to edit any page they want. This requires real-world testing on complex and diverse pages, not just the multiple kinds of tests that are done by the staff or other knowledgeable people. Whatamidoing (WMF) (talk) 22:44, 15 October 2013 (UTC)

True, but because the WMF got the order reversed (starting way to soon with real world testing on all pages, including complex and diverse pages, when it didn't even work properly on simple standard pages), it will now be much harder to get back to the ideal scenario (and acceptance of other new tools like Flow may also get a lot harder). And of course, as long as things in VE stil require knowledge of wikitext (eg in templates), and other common things are simply impossible in VE, it is a bit useless as a replacement for wikitext editing anyway. While the current low figures for VE editing are of course due to the opt-in, the editing figures before the opt-in were low as well and showed no signs of increasing either. Perhaps it had been better to focus on making wikitext editing more robust (eg incorporating the checks that bracketbot does in the "save" function) and more user-friendly (introducing a few improvements VE has into wikitext editing, like the file preview selection or the templatedata?). Well, it isn't too late to start doing these things of course. Fram (talk) 07:22, 16 October 2013 (UTC)

More examples of bug 3. When do people actually "want" to have one letter black instead of blue or red? Ever? Then why is this the default behaviour from VE in these cases? [32][33] Fram (talk) 16:02, 21 October 2013 (UTC)

I can't think offhand of a time when people would want one letter to be unlinked, but if you will look at my previous message, you will see that I specifically linked only part of one word ("WP:ACCESS-violating") and that partial link makes sense there. Do you want VisualEditor to prohibit that? Or do you think it should only prohibit it if there is just one letter being left unlinked? Whatamidoing (WMF) (talk) 18:37, 22 October 2013 (UTC)

I want VE to give "me", the editor, the choice, e.g. by allowing wikitext to be entered directly, as requested by the enwiki community and categorically rejected by the WMF devs. Now VE makes the choice for me, and usually makes the wrong choice because very occasionally, like in your example, this behaviour may be desirable. If VE can't give me the choice for whatever reason (none has been given by the devs), then it should default to the most common desired result, which is that the remainder of the word is also included in the bluelink, not that it is excluded by a nowiki. Similar as to when people add double square opening and closing brackets: in 99% of the cases, they want to wikilink, but VE defaults to the 1% exception. Fram (talk) 19:24, 22 October 2013 (UTC)

Example: [34] Fram (talk) 11:59, 23 October 2013 (UTC)

Another one: [35]. This is really much too common, while the opposite (a "wanted" nowiki in these circumstances in an article) is very rare. And remember thatmany of these don't even get saved, but get abandoned after the "nowiki" warning appears. Fram (talk) 12:03, 23 October 2013 (UTC)

And this is the front instead of back variation (which doesn't even generate a nowiki), where an editor wants to change a capital S into a lowercase s, and the result is that [[Mad Men (season 6)|Season Six]] changes into s[[Mad Men (season 6)|eason six]]... I don't have to dig very far to find these, simply open a few recent VE edits and you are bound to encounter this. Now imagine that everyone uses VE instead of wikitext... Fram (talk) 12:08, 23 October 2013 (UTC)

VE disabled for anons

Tracked in Phabricator
Task T57900

This was probably an intentional change, but I now find that VE is disabled for anons. i.e. if the anon user happens to add ?veaction=edit in the URL, it no longer loads VE.

It would be nice if the VE backend (php) recognised ?veaction=edit , maybe with &debug=true also enabled, and loaded VE irrespective of user preferences. That would allow testing in many browsers without logging in - which is a bugger because logging into a second browser causes the first browser to be logged out.(bugzilla:49890) Are other people experiencing the same issue? I dont want to raise a bug if there is a good reason why veaction=edit in the URL shouldn't force the VE backend to load VE. John Vandenberg ^(chat) 01:28, 13 October 2013 (UTC)

I am not sure this can be done given the current status of VE at en.wp. Please don't hesitate to request this on Bugzilla, especially if you think it's technically doable! There is a very vaguely related thread on Wikimedia-l, but I guess you already noticed it. --Elitre (WMF) (talk) 17:57, 15 October 2013 (UTC)

It is technically doable, even easy, as the current behaviour is controlled by the JavaScript only. Bug 55900 raised. John Vandenberg ^(chat) 21:55, 18 October 2013 (UTC)

jdforrester has said on the bug "I feel that this conflicts with the expressed will of the community (to prevent anonymous users from being able to use VisualEditor)." Perhaps we need to review the previous community discussion, and start a new one if this bug conflicts with the prior decision. John Vandenberg ^(chat) 07:42, 20 October 2013 (UTC)

Can someone point me to the discussion about the anon editing being disabled? I think it was on AN, but I wasnt paying much attention when this happened. (@Kww:) The RFC needs to be closed. I've proposed wording for the closure at Wikipedia talk:VisualEditor/RFC#Closure. --John Vandenberg ^(chat) 01:22, 21 October 2013 (UTC)

I wasn't very involved with that one, John. I'm more infamous for WP:VisualEditor/Default State RFC.—Kww(talk) 02:43, 21 October 2013 (UTC)

Thanks for that link Kww; I'd forgotten where that one was. From a quick look at that (esp this), it seems the community doesn't mind that anonymous users were able to use VE; we just don't want the UI to be pushing anons to be using it. Some comments in #2 indicated a preference for preventing anons from using VE, but some people (e.g. User:Wikid77 and user:Sameboat) explicitly wanted 'veaction=edit' to continue working as before. John Vandenberg ^(chat) 03:20, 21 October 2013 (UTC)

That's a case that wasn't elucidated well in the RFC. My main question is why someone would be wanting to participate in testing experimental software but not willing to register.—Kww(talk) 04:02, 21 October 2013 (UTC)

What does registering have to do with giving feedback? IPs are allowed to give feedback as much as anyone; indeed, they already have been giving it. Orange Suede Sofa (talk) 04:08, 21 October 2013 (UTC)

user:kww, VE is one of the few cases where the user prefs override URL parameters. If someone is wanting to test a bug in a variety of browsers (and devices), logging in every time is a real pain in the butt because of feature/regression bugzilla:49890. Due to the beta status, it should be as easy to test as possible. John Vandenberg ^(chat) 05:41, 21 October 2013 (UTC)

I'm not some kind of ultimate authority that you need to convince. The RFC was pretty clear that it shouldn't be made available to IPs by default. It didn't preclude making it available to IPs by some mechanism. I'm queasy about saying that simply adding the URL parameter constitutes making it unavailable by default, but there's probably an answer out there.—Kww(talk) 05:48, 21 October 2013 (UTC)

Hatnote cleanup problem

There does not seem to be a way to delete the first of two hatnotes without leaving extra space at the top of the article. 28bytes (talk) 03:20, 15 October 2013 (UTC)

I couldn't figure out how to do it, either. What's your browser/OS/skin? I tried it in Safari on a Mac. Whatamidoing (WMF) (talk) 22:40, 19 October 2013 (UTC)

Firefox 24.0/Windows 7/Monobook. 28bytes (talk) 16:48, 20 October 2013 (UTC)

Likewise, on Firefox/Mac. John Vandenberg ^(chat) 07:46, 20 October 2013 (UTC)

Thanks for the replies. My quick search (on "hatnote") at Bugzilla showed nothing, so this needs to have a bug filed. I don't have time to do it right now, but either I or someone else will do it soon, and we'll post the bug number back here. Whatamidoing (WMF) (talk) 18:49, 22 October 2013 (UTC)

Now at 56234. --Elitre (WMF) (talk) 10:00, 28 October 2013 (UTC)

Refrences numbered incorrectly

The following discussion is marked as answered. If you have a new comment, place it just below the box.

---

References are numbered incorrectly within Visual Editor if some are included in templates. Its very annoying to see there is something wrong with a ref number X at the bottom of the page, the locate ref X in the text (after starting to edit), only to discover it is the wrong ref. Found it is in bugzilla as bugzilla:51289 - Evad37 (talk) 16:02, 15 October 2013 (UTC)

Thanks for searching for this, and congratulations on finding the bug you were looking for. I agree that it's annoying. It seems to be fairly difficult to solve the problem. Whatamidoing (WMF) (talk) 22:40, 19 October 2013 (UTC)

Not a bug report

This is an edit where VE did the job superlatively well and was far easier to use than doing the same thing in wikitext would have been. The references all cut'n'pasted properly too (and I liked the way they renumbered instantly). Thank you! - David Gerard (talk) 23:06, 17 October 2013 (UTC)

You mean things like adding the same ref twice to the same sentence?

New features include:<ref>{{cite web|url=http://www.libreoffice.org/download/3-6-new-features-and-fixes/ |title=3.6 New Features and Updates |publisher= [[The Document Foundation]] |date= |accessdate=2012-08-09}}</ref><ref>{{cite web|url=http://www.libreoffice.org/download/3-6-new-features-and-fixes/ |title=3.6 New Features and Updates |publisher= [[The Document Foundation]] |date= |accessdate=9 August 2012}}</ref>

You do the same at another junction as well... And note that the "instant renumbering" you applaud is actually rather buggy as well, since the numbers in VE mode are not the same as the numbers in view mode (i.e. in VE edit mode, the first ref in the text has number 1, but it has number 8 in the ref box at the bottom, which is the number it has in the view mode as well). This is due to a problem with refs in the infobox which has been reported quite a while ago but hasn't been fixed yet.

By the way, I love what VE does with the "supported file formats" table (the read and write columns). Apparently it isn't, well, supported in VE :-) Fram (talk) 07:13, 18 October 2013 (UTC)

Draf template images are way too big (ptwiki)

Tracked in Phabricator
Task T53628

Some draft templates (a template for when the article is still a draf) in ptwiki are ridiculous big: 1, 2. Though the template has a size parameter most of time, it seems that the parameter is not passed when in VE.

I fixed the issue by adding a fixed width div in the image placeholder but some users got unhappy with the change, also because they seems a bit pessimistic about the VE. I also think that these images should be as smaller as icons not 20mb heavy downsized to 20x20px but this is another issue...

Issue was related here but got no responses.

Thanks for any feedback on this.

Dianakc (talk) 18:36, 18 October 2013 (UTC)

@Dianakc: This is due to a bug in the wikitext which Parsoid doesn't handle in the same way as MediaWiki right now. pt:Predefinição:Esboço-mitologia uses pt:Predefinição:esboço personalizado, setting the "tamanho" parameter as "50px" which is passed into pt:Predefinição:asbox as the "pix" parameter. This is meant to just be a number (e.g. "50"), as the template adds "px" anyway, which means it becomes "50pxpx" which currently causes Parsoid to choke and needs to work around - see bug 51628. In the short term, if you fix the template it will go away after Parsoid has a chance to re-parse the page - I've just done this for that template. Sorry for the bug. Jdforrester (WMF) (talk) 19:50, 18 October 2013 (UTC)

Thanks @Jdforrester (WMF): I was not able to figure out. Dianakc (talk) 19:59, 18 October 2013 (UTC)

Cursor "disappears"

Tracked in Phabricator
Task T57925

Hello. Just a little thing that's kind of annoying. I don't know exactly how to describe it but I'll try. Since the new launch on Thursday, the cursor disappears when I try to add a new parameter to the templates. What I mean...before, when I was adding a template, after clicking for a new parameter, the cursor was automatically in the box where I write the title of the parameter. Now I have to click on the box first. Also before, when the new parameter was added, the cursor was automatically in the box where I write the content of the parameter. Now I also have to click on the box first. It might be a small thing but it's kind of annoying to move the mouse back and forth, especially when you have 5-6 parameters to add to a template (e.g. for a reference) and it takes more time.
P.S. I like that the "add summary" box is now in the middle of the screen :) TeamGale 16:55, 19 October 2013 (UTC)

Extra clicking sounds annoying. I'll file a bug report for you. I've confirmed the need to click in the "Add parameter" field (where it says "Parameter name" and also lets you search for any parameters that are known via TemplateData) to start typing. Are you still on Firefox 24, Windows 8 and Vector skin? I checked in Safari on a Mac, so this is almost certainly universal. Whatamidoing (WMF) (talk) 22:18, 19 October 2013 (UTC)

Thank you so much. I was thinking I would get used of it but nop, still annoying after two days and time consuming! :/ Yep...still there! :)) FF24, W8 and Vector TeamGale 22:25, 19 October 2013 (UTC)

Taking your fingers off the keyboard is always annoying, and for some users, minimizing mouse/trackpad use is an WP:ACCESS issue. At the moment, the only alternatives are hitting the tab key seven times, or shift-tab three times, and these are just not practical alternatives. I'm really grateful that you reported this. Whatamidoing (WMF) (talk) 22:32, 19 October 2013 (UTC)

Sure not practical at all. Just read the report, thank you so much and you are welcome. Just wanted to add that the same happens after you add the parameter with the context box. Again you have to click with the mouse to the box where you write the context something that before didn't happen. Maybe this can be filed as the same bug? TeamGale 22:39, 19 October 2013 (UTC)

"Add summary" apparent glitch

I made a one-word change to Northeim that called for a some-what lengthy explanation. After about two and a half lines, the vertical bar (cursor) kept blinking, but I could not add text. This means that my explanation was cut off in mid-sentence. (The material I typed was saved when I gave up and clicked to save.)Kdammers (talk) 04:33, 20 October 2013 (UTC)

Kdammers, the edit summary window is limited to 255 characters. You can see how many chars. are remaining on the right-hand side bottom of the summary window. For explanations that are too complicated to explain in 255 chars., maybe a talk page post is more useful? PEarley (WMF) (talk) 20:40, 20 October 2013 (UTC)

To be slightly more exact, edit summaries can't exceed 255 characters, whether one is using VE or the older wikitext editor. And yes, if more explanation than that is needed, "See talk page" as an edit summary, plus a posting on the article's talk page, is the way to go. -- John Broughton (♫♫) 00:27, 22 October 2013 (UTC)

Okeh, I see it now: barely visible light gray on light gray, with no explanation. (I don't have contrast problems when I edit in source code.)Kdammers (talk) 00:50, 23 October 2013 (UTC)

The number is not really about characters, but about bytes. I corrected this in the User Guide as well, please feel free to check if that was done correctly! --Elitre (WMF) (talk) 10:44, 23 October 2013 (UTC)

Talk page seems inflexible.

In VE I can't see any way to use italics. I don't see any icons, unlike in "edit source." (Control-i brings up a new pane when I try that,using Firefox.)Kdammers (talk) 05:13, 20 October 2013 (UTC) --That is, on the talk page. Kdammers (talk) 08:31, 20 October 2013 (UTC)

The Italics button is the stylized "I" next to the bold "B" on the VE toolbar. Should be the fifth button from the left. I'll look into the keyboard shortcut issue - we have been seeing a few Firefox bugs of late. I'm confused by the "talk page" part of this report, though - VE is not currently enabled for talk page editing. Regards, PEarley (WMF) (talk) 20:45, 20 October 2013 (UTC)

Thank you for the response. The VE/talk page is a mistake on my part. I edited the talk page after looking at the article in VE and falsely assumed that I was still using VE. Kdammers (talk) 05:56, 21 October 2013 (UTC)

No problem, Kdammers. We appreciate your testing and reporting. PEarley (WMF) (talk) 17:05, 21 October 2013 (UTC)

Emptying a ref

Contrary to what had been claimed ("you can't make syntactically incorrect statements in VE"), you can apparently do this, e.g. emptying a named ref so that it gives a " Cite error: The named reference prisa was invoked but never defined " error. See here for an example. No idea how the editor did it, I have not tried to reproduce it. Fram (talk) 08:16, 21 October 2013 (UTC)

Hey Fram. I've tried to reproduce it, without success. I've asked the editor if they can shed any light on what led to the ref being partially deleted. I'm guessing from the editor's edit summary that they were intending to remove the reference as "redundant", but as to why the ref tags stayed in place, I'm not sure. Hopefully the editor remembers the actions they did in that edit. PEarley (WMF) (talk) 17:04, 21 October 2013 (UTC)

It looks like WhatAmIDoing has reproduced it, see here. Fram (talk) 09:57, 22 October 2013 (UTC)

Ah, good stuff WAID. I'm unsure as to what we can do to avoid this - perhaps have VE strip out the ref tags if the reference dialog content is empty? PEarley (WMF) (talk) 22:31, 22 October 2013 (UTC)

Please bring back VisualEditor

Why was this removed!? It was much easier to edit articles with the VisualEditor than by editing this nightmarish source code directly. Especially editing the middle of tables, ugh. We should be free to choose which editor we prefer, not forced to slog around in line noise like we're stuck in the dark ages. 71.167.70.47 (talk) 21:01, 21 October 2013 (UTC)

Go to your preferences -> Editing tab. There's a checkbox to enable it. --Frederico1234 (talk) 21:46, 21 October 2013 (UTC)

@Frederico1234: Anonymous editors don't have preferences. And at the moment, the WMF appears disinclined to provide an easy way for them to opt into using VE - see #VE disabled for anons, above. Someone wanting to use VE is - at least at the moment - needs to have a useraccount (free! no personal information required!); then they can go to their preferences and enable VE. -- John Broughton (♫♫) 00:22, 22 October 2013 (UTC)

1 notice

Tracked in Phabricator
Task T57951

When I open User:Fram/sandbox with VE, I get at the top a box, beneath the triangle exclamation mark symbol, saying "1 notice" (left), "X" (right), and (bottom right, redlinked) "Group notice Page notice". I get the same in mainspace articles, without the "group notice". I don't think having an empty "notice" is useful for anyone... Fram (talk) 11:55, 22 October 2013 (UTC)

I think this only turns up in admin accounts. Do you have an alternate non-admin account to test it in? Whatamidoing (WMF) (talk) 19:20, 22 October 2013 (UTC)

Yep, seems only to happen to admins. Still annoying though :-) EngFram (talk) 12:17, 23 October 2013 (UTC)

Probably obvious, but EngFram is my non-admin account ;-) Fram (talk) 12:19, 23 October 2013 (UTC)

Returns

When I open Jill McCorkle in VE, I get some "hard return" symbols (enter arrows) in the lead, after "MA" and after "Bennington College". I don't think a WYSIWYG should show these (or else it should show "all" layout markers). Fram (talk) 11:58, 22 October 2013 (UTC)

I think this is probably a "working as designed" issue. These appear when the wikitext is on two lines, but are part of one paragraph. Most editors want to remove such things, and if they aren't displayed in VisualEditor, then people can't remove them.

What other layout markers do you think people would want to see? Whatamidoing (WMF) (talk) 19:24, 22 October 2013 (UTC)

Well, no idea actually... Fram (talk) 12:21, 23 October 2013 (UTC)

It might be good to be able to see hard spaces, which are required in some circumstance as described by WP:MOS#Non-breaking_spaces. Maybe there should be an option in VE to toggle between showing all layout markers and showing everything as WYSIWYG. - Evad37 (talk) 12:50, 23 October 2013 (UTC)

File thumb a lot smaller in VE than in reality

Noticed at Samuel Gordon (New York) that the thumb image is a lot smaller in VE than in read mode. This seems to be true for other articles as well, e.g. Metropolitan line (1933–88), so it doesn't seem to be article-related. Windows 7, Firefox 24. Fram (talk) 12:14, 22 October 2013 (UTC)

Same here for Samuel Gordon (New York): Windows 8.0, both Firefox 24 and Chrome 30, thumbnail preference 200px. - Pointillist (talk) 12:54, 22 October 2013 (UTC)

Is this happening for you on other pages? Is it all images, just this one? What's your default thumbnail size at Special:Preferences#mw-prefsection-rendering? Whatamidoing (WMF) (talk) 19:26, 22 October 2013 (UTC)

For me, it happens on multiple pages (that's why I gave two examples), and my preferred thumbnail size is 220px. I get the same at e.g. Brooksby. Fram (talk) 19:30, 22 October 2013 (UTC)

Me too, but it isn't consistent. I've just tried another test:

1. Log in under Chrome 30, Windows 8.1 on
2. Change thumbnail preference to 120px
3. Navigate to Florence_Baptistery#Baptistry_doors
   Note that both South Doors and East Doors images are the same width.
4. Navigate to Florence_Baptistery?veaction=edit#Baptistry_doors
   South Doors has become wider and East Doors is a little narrower.
5. Change thumbnail preference to 300px and repeat
   Exactly the same effect happens: South Doors has become wider and East Doors is a little narrower.
6. Log in under Safari, iOS 7 on iPad 2 landscape, still with 300px preference, and repeat
   Exactly the same effect happens: South Doors has become wider and East Doors is a little narrower.

A possible factor is the size and DPI settings of the original images. I downloaded them and examined the image sizes with Photoshop. South Doors is 3222 pixels wide at 298 pixels per inch. East Doors is 431 pixels wide at 72 pixels per inch. - Pointillist (talk) 20:55, 22 October 2013 (UTC)

I've found the likely reason for the discrepancy between the South and East Doors above. The amount the image is resized is a function of whether it is portrait or landscape. Try editing User:Pointillist/TestImages with VisualEditor to see what I mean. - Pointillist (talk) 22:04, 22 October 2013 (UTC)

Clueless

In VE, there are a few icons, most of which are common to word processors like MSW. But there are functions in word processors that are either missing or hard to find in VE. I just added an ISBN to Jill McCorkle. It went in as plain text. Since all the other ISBNs were hyperlinked, I tired to do that in VE. There is no paint-brush to copy format, so I tried using the link icon. since there are no instructions, I fiddled around for a while before giving up. Then I hti the pull-down more and tried every-thing that seemed likely: nope, at best some complicated confusing panes opened up. So I gave up. (If my computer were faster, I'd've switched out fo VE adn quickly made the change in code, but I thought it more important to leave a message here.) Kdammers (talk) 00:57, 23 October 2013 (UTC)

ISBN are usually automatically hyperlinked by MediaWiki. ISBN 1234567890 gives ISBN 1234567890 without having anything to do. VE isn't doing this also ? --NicoV ^{(Talk on frwiki)} 14:25, 23 October 2013 (UTC)

It works fine, if you know about prefixing the number with the ISBN magic word. Unfortunately, this isn't made clear at Help:ISBN. I've fixed the Jill McCorkle article and I've clarified the hatnote at Help:ISBN so it is easier to find the instructions at WP:ISBN. - Pointillist (talk) 15:07, 23 October 2013 (UTC)

Kdammers, the ISBN linking thing, as mentioned above, is a bit different than standard wikilinking. We are working on a complete redesign of the reference editor, details are here (and feedback is welcome on the talk page). When that goes live, ISBN linking will be a simple matter of pasting the number into the field given by the dialog window. NicoV, the "magic words" method does work in VE, see:[36] and result: [37] PEarley (WMF) (talk) 18:50, 23 October 2013 (UTC)

I don't see it working: if I type ISBN 1234567890 in VE, it's not displayed as ISBN 1234567890 (the link is not displayed in VE). Its only displayed correctly once saved, because MW parser does the trick, not VE. --NicoV ^{(Talk on frwiki)} 20:57, 23 October 2013 (UTC)

Of course, you are correct. I have updated the guidance at WP:ISBN accordingly, but it would be simpler if we had a Template:ISBN that created ISBNs instead of complaining about the lack of them. - Pointillist (talk) 22:34, 23 October 2013 (UTC)

Example of problematic VE editing

• North Shore Medical Center: editor tries to cleanup an article, needs 5 VisualEditor edits to get it right, and then makes a non-VE edit anyway to add a hidden comment... Problems include putting an image in the middle of a sentence[38] and adding too many single quotes[39] (something I thought wasn't possible in VE?). Here you get a new section header with a trailing space (but no leading space), which is not a real error but sloppy anyway, and which VE could easily strip out. The editor corrects this, and adds a hidden comment, in his final, non-VE edit[40].

It's just a random example that caught my eye, indicating some of the common problems and some rather uncommon problems with VE. While VE slowly improves, it seems that very few of these day-to-day problems get fixed (the infobox deletion one is a recent good exception to this rule), while very low priority ones like "showing the size of an image while resizing it" become available. Fram (talk) 11:41, 23 October 2013 (UTC)

Chess icon

I was trying to convert bad material into a comment in the article on Gerald Celente. When I came to the end of the comment and tried to close it (using html in lieu of any idea what else to use), I got what looks like a chess pawn when I previewed it: ♙. Kdammers (talk) 05:28, 24 October 2013 (UTC)

Hi. I'm sorry for the complication. Since you didn't save it (understandably), I'm not entirely sure what syntax you used. I was able to leave a hidden comment in my sandbox with ordinary hidden comment syntax, with no pawns ([41]). It looked okay in preview in a couple of articles. Can you specify what you used so I can make sure that this particular pawn bug is already tracked, or track it if not? If that is the syntax you used, can you tell me what browser and operating system you were on? :) --Maggie Dennis (WMF) (talk) 14:11, 24 October 2013 (UTC)

Unfortunately, I don't recall exactly what I typed, but it was some-thing like --!> . My opening appeared as wysiwyg, i.e., it did not get converted, undoubtedly because the close was the pawn. I was using Mozilla on Windows 7. Kdammers (talk) 13:09, 27 October 2013 (UTC)

I can't duplicate this issue. :/ Using Mozilla, I was able to get it to accept <!--test--> (without the additional !) without any issue, and when I tried <!--test--!> it just broke the page completely. (Interestingly, it did not show in preview that it would, although when you try to do the same edit in standard editor it does. --Maggie Dennis (WMF) (talk) 13:38, 5 November 2013 (UTC)

Drag and drop redux

The following discussion is marked as answered. If you have a new comment, place it just below the box.

---

Tracked in Phabricator
Task T58578

Demonstration

This was previously mentioned atWikipedia:VisualEditor/Feedback/Archive_2013_12#Moving_links_on_the_page_from_outside_the_VE_surface_into_the_VE_surface. But I've now made a video with audio for demonstrating the issue, which should appear to the right. This in FF 24 Win 7 with Monobook. --Atethnekos (Discussion, Contributions) 03:48, 30 October 2013 (UTC)

Well that's a fun one, Atethnekos. Thanks for the excellent vid. I've added it to Bugzilla. PEarley (WMF) (talk) 19:58, 4 November 2013 (UTC)

VE section edit links not working

The following discussion is marked as answered. If you have a new comment, place it just below the box.

---

The section edit links for VE are not working properly. When I mouse over the link, the "&veaction=edit&section=1" is added to the end of the link, however, when I click on the link, it doesn't add that part, just adding "&veaction=edit". This means that the page doesn't scroll to the right place. (As a side note, I noticed this because when switching between VE and source edit the it leaves off the section part. I don't know if these are related or separate, or even if the latter is intentional.) (This shows up at least on Tonopah Air Force Base and User:Jay8g/sandbox.) (Windows 7, Firefox 24, monobook):Jay8g [V•T•E] 04:23, 2 November 2013 (UTC)

Jay8g, I'm having trouble duplicating this (same browser/skin, but Mac OS). I'm seeing the desired behaviour - page scrolls down so "Background" section is at top. The url is appended to "&veaction=edit" as you describe, but it still works. I'll have to try this on a Windows machine when I have access to one. Could you re-test, if you get a chance? Thanks, PEarley (WMF) (talk) 20:11, 4 November 2013 (UTC)

Seems to be working now:Jay8g [V•T•E] 01:53, 5 November 2013 (UTC)

Thanks! PEarley (WMF) (talk) 02:45, 5 November 2013 (UTC)

References

At the National English Ability Test, I am trying to clean up a minor point and correct an error, both in the references. One (footnote 5) has an extra set of parentheses and a changed font: (in (Korean)). The other (footnote 3) incorrectly indicates that the reference is in Korean. When I try to use VE to edit, I get the section pale-blued. When I click any-where in this, I get a stronger blue with a white rectangle in the upper right-hand corner with what is supposed to be a books icon. Nothing can be changed in the blue screen. when I click on the icon, I get https://wiki.riteme.site/wiki/National_English_Ability_Test?veaction=edit, which is a blank white screen with the same icon followed by "Reference list," a cog icon followed by "Options," and "Use this group" above an entry box. There is also a big X in the upper right-hand corner and a "Apply changes in the bottom right-hand corner. The only operative part of this screen is (other than the X and, presumably, the "Apply changes" is the entry box. What in the world does this have to do with editing the text? what "groups" are being referred to? What am I supposed to type into the box -- some sort of group name?? In other words, using VE I have no idea at all how to make the two simple changes I mentioned at the start. (I recall having encountered the blue screen before, but I can't remember what the explanation was. In any case, if we are trying to make editing easier for people thinking in terms of WSIWYG word processing, this is not the way to do it.)Kdammers (talk) 07:40, 2 November 2013 (UTC)

The blue screen you have encountered indicates a template. It exists because the only actual content in the section is {{references}}. I think this is a difficult one on our projects for any brand new editor - if a newcomer click "edit source" on the reference section, I suspect they'd be equally confused. :) They won't see the text there, either - just {{references}}. VisualEditor, just like the source editor, requires editing the individual reference. The big difference, of course, is that if a person uses source editor and edits the page instead of the section they'll find the text they're looking for. To edit it in VisualEditor, they have to click on the individual reference and find the parameter that contains the issue. Clearly, that is an additional barrier to modifying references.

There's talk at mw:VisualEditor/Design/Reference Dialog (and its talk page) about the reference system. I'll note this concern there. --Maggie Dennis (WMF) (talk) 13:53, 5 November 2013 (UTC)

There's another report of some problems in this article at Wikipedia:Village pump (miscellaneous)#I can't clean up a site. T58755 is being fixed so that the initial problem (typing ref tags in by hand) will be flagged with the usual warning against using wikicode. Whatamidoing (WMF) (talk) 14:48, 8 November 2013 (UTC)

Category adding not working

[42] People in Hindu mythology Redtigerxyz ^Talk 05:25, 3 November 2013 (UTC)

Hi there, can you please confirm you followed the procedure described here? Thanks, --Elitre (WMF) (talk) 13:09, 5 November 2013 (UTC)

Works now. Don't know why it didn't work then? Followed the same procedure. --Redtigerxyz ^Talk 05:45, 10 November 2013 (UTC)

Thanks for the reply. The code's been updated since then, so maybe it was just something that got silently fixed. Whatamidoing (WMF) (talk) 22:06, 10 November 2013 (UTC)

Italics

The following discussion is marked as answered. If you have a new comment, place it just below the box.

---

In the article on Michael Tellinger, much of the text is (erroneously) in italics. But when I went to fix it using VE, what is in italics is not what is in italics on direct viewing!Kdammers (talk) 07:08, 3 November 2013 (UTC)

The problem was a stray <cite> tag. I fixed it. The regular PHP parser seems to leave that tag open all the way to the end of the article where Parsoid closed is at the end of the paragraph which is why you see different rendering. Ssastry (talk) 16:54, 3 November 2013 (UTC)

Visual editor having issues with accent marks

The following discussion is marked as answered. If you have a new comment, place it just below the box.

---

Tracked in Phabricator
Task T58583

Edited Egidio Arévalo's page. This happened - https://wiki.riteme.site/w/index.php?title=Egidio_Ar%C3%A9valo&diff=580200791&oldid=577924442. I'm undoing and then making my changes using 'change source'. Not sure if this is a pre-existing bug or something new. Red Fiona (talk) 19:55, 4 November 2013 (UTC)

Further information. It's not just the Arévalo page. https://wiki.riteme.site/w/index.php?title=Andr%C3%A9s_Ayub&diff=580203236&oldid=572220148 Red Fiona (talk) 20:13, 4 November 2013 (UTC)

On frwiki, it seems that every edit with VE trashes the article really badly (example). Is the VE team going to say again that they are testing it before releasing it into production ? Honestly, letting go something like that into production is a shame, and clearly demonstrates that no real QA is done. --NicoV ^{(Talk on frwiki)} 20:17, 4 November 2013 (UTC)

By the way, do they expect us to clean up their mess again and again ??? --NicoV ^{(Talk on frwiki)} 20:20, 4 November 2013 (UTC)

I can imagine it being a lot worse for French because accented letters are a lot more frequent. Red Fiona (talk) 20:30, 4 November 2013 (UTC)

HELP !!!!! PLEASE STOP VE ON FRWIKI, Articles are completely trashed by VE every minute. --NicoV ^{(Talk on frwiki)} 20:32, 4 November 2013 (UTC)

This has been fixed, it was a problem with the Parsoid parsing libraries update (not VE) which has been reverted. If you do not mind me rolling back edits in the mainspace on fr.wp, NicoV, I'll help clean up any broken edits. Keegan (WMF) (talk) 21:12, 4 November 2013 (UTC)

Sure, if you want to do reverts, you're welcome. Other wikis may ask the same. Honestly, I'm not interested in the distinction between VE and Parsoid, wherever the problem happened it shows that quality, tests and stability are less than enough for production software. --NicoV ^{(Talk on frwiki)} 23:06, 4 November 2013 (UTC)

The question however then becomes why people are intent on making a distinction between VE and the rest of the Wikipedia software stack to begin with of course. Just saying, this might as well have been a change in the Timeline rendering lib and hardly anyone would have come stomping WMF developers. Building out the test infrastructure is a continuous process and ppl have only begun doing this about 3 years ago. Never forget the amateurish and volunteer driven origins of the project as a whole, from article to server. They are the causes for all results we have achieved, both negative and positive. —TheDJ (talk • contribs) 10:58, 5 November 2013 (UTC)

First of all, for users, VE and Parsoid seem closely related since Parsoid is the parser that is used by VE, and for me it seems that Parsoid was developed mainly because of VE, even if it can be used for something else. Then, disctinction between VE and the rest is made because WMF insist on deploying VE in production when a majority of users clearly think that VE is far from being stable enough for production. --NicoV ^{(Talk on frwiki)} 12:50, 5 November 2013 (UTC)

Dear User:TheDJ, I don't think I was particularly stompy. There was a problem, that I narrowed down to definitely being a problem with VE rather than the traditional editor, and I put an entry in to VE Feedback as instructed.Red Fiona (talk) 14:50, 5 November 2013 (UTC)

Dear User:Redfiona99, my commentary was not directed at you, you made a proper analysis and created a useful report. —TheDJ (talk • contribs) 17:29, 5 November 2013 (UTC)

• Likely related in some way to T52296 Risker (talk) 20:53, 4 November 2013 (UTC)

I am not sure about this, Risker; I'll ask. --Elitre (WMF) (talk) 12:49, 5 November 2013 (UTC)

BTW, I did ask, and it was completely unrelated. --Elitre (WMF) (talk) 15:42, 7 November 2013 (UTC)

Is this a bug that only had this result in VE? Then, for all our purposes, this is a VE bug. Which part of VE is responsible for it, or whether technically it is a Parsoid bug that only affects VE, is for us 'readers, editors, VE testers) not relevant. If my car crashes into the wall each time, then I don't want to here "there's nothing wrong with the car, it's those new tyres we have been placing on all our cars". The end result is the same, the cause is the same (VE editing), and which part of the WMF development is actually to blame underneath is not really what we care about, comments like "it was a problem with the Parsoid parsing libraries update (not VE)" or TheDJs comment seem to miss this point or try to make some distinction to divert blame away from VE. — Preceding unsigned comment added by Fram (talk • contribs) 13:33, 5 November 2013 (UTC)

But Wikipedia is NOT a business like a car manufacturer, as much as that might be desirable, and you are not commercial consumers. It is a non-profit organization that is significantly smaller than all it's directly comparable commercial competitors (top 10 websites), founded to serve a lot of volunteers that together made something very useful.

I would say, that a proper postmortem analysis took place, in a very transparent way, which will result in new type of test to prevent similar problems in the future. That, regardless of all the emotions, is all that is actually important. We all know or SHOULD know that our legacy code and infrastructure sucks and the only reason it was stable was due to LACK of change, because we all built together, from software to articles.

The VE/Parsoid team has by now, built the majority of test coverage that we actually do have, a huge service to all of us. We have given them crap to work with and that crap will stink for a LONG time, there simply is no avoiding it. There is no point in blaming the VE team for much of what they are being blamed for, without at the same time blaming everyone (volunteer or not) who built everything that came before the age of VE. Things like this happen and it can be much worse and it needs to be prevented as much as possible, but that is exactly what people are working on right now. Just because you don't want to be interested in the details does not make your fingerpointing and 'root cause' analysis a positive contribution, let alone a valid analysis, it is nothing more than an incorrect emotional response. —TheDJ (talk • contribs) 17:26, 5 November 2013 (UTC)

"The VE/Parsoid team has by now, built the majority of test coverage that we actually do have, a huge service to all of us." Can you explain what you mean? I have no idea what you are trying to say here, or what "test coverage" you are referring to. "We have given them crap to work with"? Which "we" is that? "an incorrect emotional response."? What exactly was incorrect about it? That the end result for readers and editors is that in this episode VE edits caused errors that wikitext editing didn't cause?

I note that you are a volunteer developer at MediaWiki, so perhaps you feel personally attacked when people have a problem with VE, and when you read the emotional responses by editors like NicoV. Have you seen the amount of work and time NicoV has put into VE testing and corrections? Have you noticed the amounbt of time I have done for the same here on en-wiki? Is creating VE hard because it has to take into account all kinds of old tricks, workarounds, and so on? Probably. But that doesn't mean that "it is too hard to do it right, so we'll deploy it as is anyway" is the right answer. I'm trying to see if you have actually worked with visualeditor on en-wiki, but get a time-out, so I guess the answer is "no". The people who are complaining here are the ones that have actually tried it or are still trying it, and are the ones that have cleaned up after VE editing caused loads of problems which some basic testing should have found (and many of which were noted before it was deployed).

Do you really think that your response, or the one shifting the blame from VE to Parsoid, will make anyone think twice and get a better impression of VE? Hardly anyone uses it here anymore, which is a good thing, because then such a bug only causes minor damage. On French Wikipedia though (and probably on many other ones like Spanish), it will have caused serious problems. Have you seen this? "Recommendations: Manually test VisualEditor on non-English wikis before and after deployment. Added to the deployment instructions." See also here. So please don't give me any crap about the "test coverage" that the VE/Parsoid team has built. The testing is still being done in live environments by unwilling and unknowing volunteers, and not (or at least very insufficiently) by the VE/Parsoid team. This has been noted time and again, and is now finally acknowledged by the changes at Mediawiki, but not by you apparently. Yes, responses are emotional, some people are thoroughly fed up by both the errors and by the responses of some people; but being emotional doesn't make them incorrect. Fram (talk) 08:15, 6 November 2013 (UTC)

Trying to avoid making this a mega discussion, but I will answer you

1. test coverage
2. parsoid parser tests, test subdirs of VE, and basically all the infrastructure that is hidden behind this page is to a large degree present due to the requirements of the VE and parsoid teams.
3. We: is everyone who has participated in creating Wikipedia, front to end.
4. Incorrect emotional response.. If you read it again, I'm talking specifically about the 'analysis'. The response overall being emotional is logical, but it is the problem analysis that is incorrect due to being oversimplified, something that is clouded by the emotional response but does result in finger pointing. These are the kinds of responses that leads companies to putting up telephone help desks. The sole purpose being to filter out appropriate information (write bug reports, count complaints) and filtering out noise for the rest of the organization.
5. Yes I'm a volunteer developer. And I have been and am a developer in many projects in and outside of Wikimedia (although less for Wikimedia lately). This kind of feedback is far from uncommon in the software world. It would be nice if Wikimedia/MediaWiki could be perfect or even close to not problematic, but I can tell you now that it is simply not gonna happen. The world of software and websites changes too quickly, personnel is too expensive/rare, and we are way too far behind. The only way to do this is gradually and take lessons from everything that we do. To invest in quality while building the changes instead of before we start making changes.
6. I have a lot of respect for anyone who puts time into making Wikipedia. But I don't like it if people pretend that one task is more important than the other, or that Wikipedia should NOT be laborious. It has always been laborious for all of us, including our volunteers. If volunteers don't want to do a certain task, then they shouldn't and in general someone else will pick it up. If you don't want to do vandal fighting, don't do it. If you don't want to help improve the next generation of Wikipedia, just write articles and let someone else report problems and correct articles after a problem. When you do want to, be as productive at it as you can be.
7. "Do you really think that your response, or the one shifting the blame from VE to Parsoid, will make anyone think twice and get a better impression of VE?", no I'm just hoping that people would stop the blame game and start collaborating in building a better Wikipedia.
8. There are 5 recommendations: Prevention of this specific bug in the long term, prevention of this specific bug in the immediate term, ability to mitigate the effect of a single Parsoid bug, theoretical possibility of Parsoid problem detection inside VE, and an ops recommendation that even I don't understand. To ridicule one of them is a failure or unwillingness to understand the process. At the very least it again does not result in improving the process.
9. Yes, real life editors are being used for testing, they are the best representation of how real life editors respond and interact.
10. I am personally very grateful to all the work that you and NicoV have been doing and I get that it can be incredibly frustrating, but the software stack and its stability is much more complicated than finding a problem and then pointing at "VE" or "Parsoid". Again much of all of this is a direct effect of how Wikipedia came into existence to begin with. Complain about the problems often and insistent, but try to do a little bit less fingerpointing, it is a negative contribution that will have negative effects, unlike complaining about problems which will have positive effects.

I hope that answers your questions. —TheDJ (talk • contribs) 12:38, 6 November 2013 (UTC)

Emotional ? Yes, I was emotional when I reported it: several articles were trashed every minute on frwiki alone and that's been 4 months that we are dealing with fixing all the damages done by VE on production wikis. Many problems were even reported before this go live insanity, and some of them are still not fixed. Was there anything false in my posts ??? "Test coverage" ? Well, it seems to me that you're referring to automated testing, which is a good thing, but anyone with experience will tell you that it's not enough and manual testings by a human are always necessary, especially when dealing with UIs and free inputs from users. It's not the first time I complained about this lack of manual testing, and the fact that the non-English wikis were not tested at all (for example, the bug with the space characters that were multiplied before ":", one that should have been seen before going in production if any manual test was done on non-English wiki). So after 4 months, the postmortem discovers that manual tests should be done ??? Well, we've been saying that for quite a long time. --NicoV ^{(Talk on frwiki)} 09:06, 6 November 2013 (UTC)

There were already test cases protecting against such errors. It's just that that part of the tooling was not used in the test case, hiding bugs in tooling setup. This is one of the common pitfalls of test cases, you end up having to test everything around you as well. There were also manual tests, but you can't run all manual tests all the time, there isn't enough man to take care of it. Instead the developers are looking at and starting to use frontend testing with Selenium, but that again can only test what it was setup to test and thus often, only that which has gone wrong once before. —TheDJ (talk • contribs) 12:38, 6 November 2013 (UTC)

Thanks for the reply.

1 + 2; I don't see what "test coverage" has been built that is a "huge service to all of us" and that is relevant to the case at hand. If they do a lot of tests, but not the right ones, then it isn't really a huge service but a huge waste of time, both at the back-end and at the front-end.

3; parsing your statement, you claim "everyone who has participated in creating Wikipedia, front to end, [has] given them crap to work with and that crap will stink for a LONG time, there simply is no avoiding it." That, if I may say so, is a typical developers' statement. Our product is good, it's the consumer that sucks. :::::4; oversimplified is not the same as incorrect. That companies don't want to listen to angry customers is their loss. The right way to turn angry customers into happy customers is listening to them, taking them serious, not complaining that actually, technically, it's not component X but component Y that is to blame, even though the customer has only used component X, and it is component X that in the background uses component Y; and that actually, you shouldn't blame the people responsible for the change that caused the problem, because next time they will do better. "Filtering out the noise" has caused much of the current problems; WMF apparently didn't realise the disconnect they had with the community here, or the length people would go to implement the RfC. Making sure that emotional responses are ignored is the best way to create another such fiasco.

5; "The only way to do this is gradually and take lessons from everything that we do." That's the problem with the people who have followed the results of VE; no evidence that any lessons have been learned is visible, if not even the most basic testing on non-en-wikis is being done (even though they have a lot more VE edits than we do obviously).

6; Oh please. "If you don't want to help improve the next generation of Wikipedia, just write articles and let someone else report problems and correct articles after a problem." If you don't want to help improve the current "generation" of Wikipedia, then go somewhere else.

7; " I'm just hoping that people would stop the blame game and start collaborating in building a better Wikipedia." All the people complaining about this bug (and the many other ones) do so because they want a better Wikipedia. Some of us feel though that VE, or some aspects of it, or some implementations of it, are not helping in building a better Wikipedia at all, but are simply huge timesinks that could have been avoided by e.g. better testing before implementation, as acknowledged at MediaWiki. You can hope whatever you want, but people are not going to stop putting their fingers on sore spots, and if those sore spots are e.g. lack of testing by the WMF and the developers, then tough luck. But your false dilemma that people can't both look for deeper causes for recurring problem, and work on building a better Wikipedia at the same time, no, even worse, your suggestion that those are exact opposites, won't fly.

8; You're being cryptic here. Which "one of five recommendations" has been ridiculed?

9; "by unwilling and unknowing volunteers", in a live environment, not in a test environment. Have you any indication how many (if any) "real", personal (i.e. non-automated) tests were done before e.g. this Parsoid update that caused these VE problems?

10; Thanks, but no. It's not as if I contain a "bad WMF" statement in every error I post here. But sometimes, like here, it is just too serious to let pass without additional comments. A problem that causes nearly every edit on French (and presumably Spanish, Finnish, ...) Wikipedia to be a serious degradation of the article quality should have been detected earlier. It's not a Firefox 25 only thing, or an admin-only thing, or an unusual set of circumstances like the navbox problems; it's something that was very easy to detect (I'm not saying easy to diagnose or correct, that is not what we are discussing here) with some basic testing, something which had been requested for months, and was promised over and over again. If similar things happen again, I (and others) will put the blame where we believe it is due. This may have negative effects, but I doubt that they outweigh the negative effect of errors like this one. Fram (talk) 13:24, 6 November 2013 (UTC)

OK, my attempt has clearly failed. On to other things, thank you for discussing —TheDJ (talk • contribs) 13:41, 6 November 2013 (UTC)

"There were also manual tests": if it's true, they failed to detect a bug happening on almost every edit on most of the non-English wikis (probably almost all since most languages other than English use accent marks, or non US-ASCII characters) and that completely trashes articles. That's what I'm currently pointing at, something that was already reported several times as missing over the past months: manual tests on non-English wikis before production. Doing basic manual tests is mandatory for me, because as I said before automated tests often miss obvious bugs because they only check what they have been programmed to check. And doing basic manual tests, like monkey tests, doesn't often require a lot of man power: having 1 person doing 1 day testing before each release on a test wiki would probably prevent such wide damaging bugs (I'm not talking about bugs requiring specific conditions). --NicoV ^{(Talk on frwiki)} 14:39, 6 November 2013 (UTC)

For anyone interested in the technical details, the Parsoid team switched to a new form parsing library, and the new one defaulted to ISO-8859-1 rather than UTF-8. It appears that the problem was fixed on all wikis approximately 65 minutes after the update. Whatamidoing (WMF) (talk) 16:33, 8 November 2013 (UTC)

VE mangles every non-ascii character

The following discussion is marked as answered. If you have a new comment, place it just below the box.

---

See this diff - it garbles Japanese characters, accented characters, even mdashes. Basically, anything that's not ASCII. Presumably this is the same bug as the section above, I just want to bring it to your attention that it's not just the FR wiki, it's everywhere- as of now, VE is worse than useless on pretty much every page in every language. --PresN 20:43, 4 November 2013 (UTC)

Thanks for the notice, PresN, that was a very ugly moment. See above about the fix. Keegan (WMF) (talk) 21:25, 4 November 2013 (UTC)

Error introduced in VE, but can only be solved in wikitext editing apparently

An editor made a lot of edits to Robert Lecker using VE, but gradually created a problem which strangely can only be corrected by wikitext editing aparrently... The problems seem to start here (scroll down and search for "The Annotated Bibliography of Canada's Major Authors"), and become worse here and here. Attempts to solve it only move the problem, here and here. Removing it in wikitext mode is no problem though[43].

Going back to that final VE edit, and opening it in VE[44]: put your cursor behind the strange quote marks (in the Anthologies section), and start backspacing. Hurrah, they're gone! You get a wiki-markup warning, but that doessn't stop us. Now, on "save page", choose "review your changes": the marks you just removed with backspace are back there!

So, three VE questions / problems: why were these created in the first place, why can't we remove them, and why does the end result differ from the VE mode (i.e. they can be removed in VE mode, but reappear on saving anyway). Fram (talk) 09:30, 6 November 2013 (UTC)

When I tried to remove it, VE told me I was attempting to use MediaWiki markup. I forced through the save anyway, and it completely ignored that edit, as you observed. The one thing it had going for it - it did give me a link to the standard editor when it refused to let me use MediaWiki markup.

I don't know how he did it. :/ Anybody else have any ideas? --Maggie Dennis (WMF) (talk) 16:41, 7 November 2013 (UTC)

Tough linking

It's hard to prove that this is a VE bug and not simply an editor error, but I've seen enough similar cases to fear the former: this edit creates [[Homeschooling in the United States|homeschooling]][[̩|.]]. I don't think the editor intended to link the period separately... Fram (talk) 09:42, 6 November 2013 (UTC)

Especially with a link to nothing... --NicoV ^{(Talk on frwiki)} 09:47, 6 November 2013 (UTC)

Well, it links (through a redirect) to Combining character, if you aim your pointer very carefully... Fram (talk) 09:50, 6 November 2013 (UTC)

My mistake, what you wrote almost looks like "[[|.]]" on FF 17 (except for a tiny pixel on the first "[": "[[̩|.]]"). --NicoV ^{(Talk on frwiki)} 10:05, 6 November 2013 (UTC)

No problem, I have no idea what the almost-pipe symbol actually is, it probably caused the problem in the first place? Fram (talk) 10:23, 6 November 2013 (UTC)

Here as well, ''Arundo donax''(giant reed) gets changed into ''[[Arundo donax]]''[[Arundo donax|(]]<nowiki/>giant reed). Fram (talk) 12:24, 7 November 2013 (UTC)

This is a known problem. Apparently fixing it, while still allowing people to link only parts of the word when they want to, is very difficult. Whatamidoing (WMF) (talk) 16:45, 8 November 2013 (UTC)

File placement problem, and lack of hidden comments

Tracked in Phabricator
Task T51603

Tracked in Phabricator
Task T54657

This edit again indicates the problem for users to place files correctly (i.e. not breaking sentences), and also indicates that the possibility to add hidden comments should be given (or, if it exists, made more noticeable to editors). Fram (talk) 09:44, 6 November 2013 (UTC)

These appear to be known concerns. For the image location issue, it's complicated: if you can't put an image in the middle of a sentence, then you can't add inline images (like this: ). Whatamidoing (WMF) (talk) 16:44, 8 November 2013 (UTC)

Difference between view mode and VE editing mode

Minor, but any feedback is welcome, no? ;-) In Wisconsin v. Yoder, with my screen resolution (it will be different for others), the text "The parents' fundamental right to freedom of religion[...]" forms the second line of the lead in regular view and in VE mode (fine so far). Due to the double space between "8th grade." and "The parents' fundamental" though, in VE the line starts with an empty space, instead of left aligned as it should be. Is this intentional? It is not WYSIWYG, since such double spaces are not shown with double width in view mode. Fram (talk) 09:55, 6 November 2013 (UTC)

I believe that it's intentional. VisualEditor is not actually meant to be WYSIWYG. It is meant to use WYSIWYG techniques where those techniques are useful, and to not use them where they would prevent editors from seeing and being able to make certain kinds of changes (e.g., removing stray double spaces). Whatamidoing (WMF) (talk) 16:47, 8 November 2013 (UTC)

Simple mobile test

I tried to add {{who}} after "by one of their graduates." on Cornerstone Community#Training using Google Chrome on my Samsung Galaxy Note locked to vertical viewing. Positioning the cursor works well.

1. The toobar isnt visible like it is in the desktop version. I have to move the page so that the toolbar is visible, and the cursor is no longer visible, ...
2. When I click 'More' in the toolbar, the drop down list is exposed, however the page then scrolls down to the cursor position. I need to scroll back up to the top of the page to click 'Transclusion'
3. When I click 'Transclusion', the transclusion dialog appears, with the left hand side consuming about 80% of the width, resulting in the template name textbox being barely visible.
4. But I can put the cursor in the template name dialog, which causes the phone to zoom in on that textbox, and I type in 'Who'. The list of possible templates appears, mostly off the screen to the right, but it includes {{who}}} and I can 'press' that entry. Nothing happens. The 'Add template' button isnt visible of course. I then press Go on the Samsung keyboard and it does add the Who template to the left hand side.
5. The 'Apply changes' button isnt visible.

I am stuck in a dialog that doesnt work, with the dialog including lots of whitespace but not the button I need. I then realise I can pinch the screen for the rest of the dialog to become visible. Success! John Vandenberg ^(chat) 11:23, 7 November 2013 (UTC)

Transluction-edit puzzle button issue

Status	New:
Description	The transluction-edit puzzle button don't appear on {{multiple image}} with vertical direction. (see Headquarters box)
To duplicate:
Operating system	Linux Mint
Web browser	Firefox
Site	Internet Archive
Workaround
Skin	Vector
Resolution	1280x1024px
Bugzilla

Rezonansowy (talk • contribs) 15:06, 7 November 2013 (UTC)

Could you look for the icon to the upper right of the infobox? This sounds like T54547, an old problem, where the icon is shown near the position of the template in the source text, not near the position of the "real" object in the editor window (the infobox "pushes" the template box downwards). The problem is over 3 months old, but hasn't been fixed yet unfortunately. GermanJoe (talk) 15:17, 7 November 2013 (UTC)

Yes, that's what I meant. --Rezonansowy (talk • contribs) 16:28, 7 November 2013 (UTC)

Some templates can't be moved.

But I have no idea which ones can and which ones can't. At Petabyte, the one at the start can't. Why? The navbox at the end has the typical navbox problem, and simply disappears. The reflist can be moved, but that's hardly necessary of course... Fram (talk) 15:40, 7 November 2013 (UTC)

I believe that the common theme is that you can't move templates that are floated. Whatamidoing (WMF) (talk) 17:27, 8 November 2013 (UTC)

Category box shows after switching from source to VE

After switching from source editor to VE, the category box shows up at the top of the page, between the toolbar and the editable area (Monobook, FireFox 25, Windows 7):Jay8g [V•T•E] 03:08, 8 November 2013 (UTC)

This is also happening for me (Vector, Chrome 30, Win7), but only on pages with no categories, or only hidden categories. To test it in articles, go to Special:NewPagesFeed and look for articles with no categories. - Evad37 (talk) 03:34, 8 November 2013 (UTC)

Strange typing

I have noticed similar things quite regularly, but never could find an example that was reproducable...

Open [45], click the ref ([1]), click the ref icon, click on the image, click the image icon, and start typing (e.g; "Caption"). The "C" goes to the second line, and "aption" appears on the first line. It is impssible to remove the C, as far as I can tell. Further typing, e.g. after the C, may reveal further strange results... Saving this shows that it is not simply a VE display problem, but that things get actually saved like this... [46]

Further tests show me that if I add an image or open one without a caption, and start typing the caption (any caption), I always get this result. FF25, Windows 7. Fram (talk) 15:27, 8 November 2013 (UTC)

I can reproduce the weird 'C' being placed on the second line, and not being able to remove it, however when I tried to save the diff only shows 'aption'. FF25/Linux John Vandenberg ^(chat) 17:24, 8 November 2013 (UTC)

Moving a navbox deletes it

Tracked in Phabricator
Task T58923

When testing on Yersinia pseudotuberculosis, I moved the Template:Gram-negative proteobacterial bacterial diseases navbox from the bottom a bit higher. I dropped it after the "IPR015227" text a few lines higher. The result is that the navbox disappears from view, and in "review your changes" it is simply deleted. I haven't saved this result, doesn't seem to be a point in saving this... Further tests show that it doesn't really matter where I place the navbox, it always gets deleted. Testing on other articles indicate that this happens with all navboxes (test on Albert I of Belgium, which takes quite a while to open though...) Changing the order of the navboxes works, but as soon as you want to place it higher on the page, it disappears completely. Fram (talk) 09:31, 29 October 2013 (UTC)

I've duplicated this issue on your example page, Fram, but when I try it on Dunn Peak, the problem doesn't appear: [47]. Going to try it in a few different scenarios to try to figure out what the trigger is. PEarley (WMF) (talk) 15:58, 29 October 2013 (UTC)

Okay, haven't isolated the issue, but I'll post my results so far. If anyone spots something in common within the groups of test cases, let me know.

Test scenario: Click once on a "navbox" type template at the bottom of a page. Click and drag the item and drop at the top of an External links section.

Navbox disappears upon dropping: Page:Yersinia pseudotuberculosis Temp: Template:Gram-negative proteobacterial bacterial diseases, Page: Albert I of Belgium Temp: Template:Belgian princes, Page: Vancouver Canucks, Temp: Various, within Template:Navboxes

Navbox drops where it should: Page: Dunn Peak Temp: Template:Columbia Mountains, Page: Waging Heavy Peace: A Hippie Dream, Temp: Template:Neil Young, Page: British Columbia, Temp: Various, within Template:Navboxes PEarley (WMF) (talk) 16:49, 29 October 2013 (UTC)

Bumping, still haven't found a trigger for this. PEarley (WMF) (talk) 19:20, 4 November 2013 (UTC)

All of the problems contain a sister link template like {{Commons}}. Of the ones that are working, the only one containing a sister template is the last, and that has its navboxes wrapped in the {{navboxes}} template. The last also has a long list of external links, so that the ELs are taller than the sister link templates. So that's two things we could check. Whatamidoing (WMF) (talk) 14:42, 8 November 2013 (UTC)

What I'm thinking here is that the sister templates are floated, and we can't move floated templates. But my subsequent testing isn't obviously confirming my theory (nor is it exactly disproving it, either). Whatamidoing (WMF) (talk) 22:07, 10 November 2013 (UTC)

Well... I spent almost an hour testing various things, and I've learned something: the navboxes stop disappearing if you break all the refs. By "break", I mean change <ref> into the completely broken [ref>. I have no idea why this makes navboxes quit disappearing, but perhaps I can claim to be confused at a more advanced level now. If anyone wants to play with it, you'll find the articles in User:Whatamidoing_(WMF)/sandbox2. Whatamidoing (WMF) (talk) 20:37, 11 November 2013 (UTC)

Baruch Spinoza references in captions

The following discussion is marked as answered. If you have a new comment, place it just below the box.

---

This bug page [48] has the note "RESOLVED FIXED", but the references 19 and 20 in Baruch Spinoza which are in image captions disappear from the references list in VE and the numbering becomes discombobulated. Win7 FF 24.0 Monobook. --Atethnekos (Discussion, Contributions) 05:42, 12 November 2013 (UTC)

I thought this could be related to another, still open bug, but I can't find which one (the two in the "see also" field for example are not resolved, but look different). If nobody has further ideas on this, I'll reopen that one. (For the record, those refs are now 20 and 21, I think.) --Elitre (WMF) (talk) 12:11, 12 November 2013 (UTC)

Quick RfC, improving the current Template:VE Bug

Hi everybody! Some of you use Template:VE Bug in order to report bugs here. It's great that such a form exists, and I wish that other wikis had adopted it as well; I'd just like to suggest a few improvements for a very simple reason, we do know that a well written report helps developers a lot when they review, assess and assign bugs. Everybody knows that VE bugs can't really be triaged by anyone without knowing browser (and its version), skin, description and URL (or title at least) of the page where the error happened (I'd add that the OS seems needed as well). Many of us are familiar with this How to report a bug guide, and I would like to suggest that we slightly change the form so that some of those suggestions are included. For example, it would truly help if the Description field also prompted the user to include:

• Steps to Reproduce:
• Actual Results:
• Expected Results:

(Please take a look at bug 55856 for an example of how this process might be easily described).

Also, looks like templates like Tracked and Answered one very popular on this wiki, and thus the related fields of the current VE Bug form are unused.

Even if you don't actually use the form to report, please keep in mind that the elements in bold are the key, and I am planning to remind this at the top of this page soon :)

For those who are good at templates instead, please comment and suggest improvements of my mockup version for a new report form. Thank you all so much. --Elitre (WMF) (talk) 12:18, 22 October 2013 (UTC)

Thanks. I've left a slightly modified version at User:Elitre (WMF)/Sandbox2, with a note. - Pointillist (talk) 13:27, 22 October 2013 (UTC)

Thanks a lot, user:Pointillist! I'll copy your comments here so that we can keep discussing about this:

<<Main differences from Elitre (WMF)'s original:

Expected and Actual directly follow Description, so it is easy to see whether the bug is already known without reading the entire report.

Expected, Actual and Steps broken out into separate cells, so each one has a permanent label in the left column.

OS/browser etc have lower prominence.

Notes fields added for optional test config stuff.>>

So, the web browser is actually a key element. Many browsers are whitelisted, but not all of their versions are, and there might be new issues coming up immediately after a new browser version is released.

The Workaround or suggested solution field is quite unused, so I'd leave that at the end.

The Notes field is helpful, and we might suggest there to get a screenshot, for example. (Unfortunately, unlogged users can't currently use VE on en.wp. This does not help, in that we do read often here about something going wrong that isn't really VE's fault, and it takes a lot of time, effort and patience to check/change/disable all the enabled gadgets and preferences). --Elitre (WMF) (talk) 10:36, 23 October 2013 (UTC)

The bugzilla form looks good. Only thing is Component section, I really don't understand the different components. Whats ContentEditable and TechnicalDebt about? I tend to just file under general and let someone else make it more specific.--User:Salix alba (talk): 18:11, 28 October 2013 (UTC)

I think I share your concern, doesn't really help much ;) The point is, it's perfectly ok to go with General. --Elitre (WMF) (talk) 21:47, 30 October 2013 (UTC)

In the meantime, I present you... the brand new Bugzilla report form! --Elitre (WMF) (talk) 21:38, 25 October 2013 (UTC)

I changed User:Elitre_(WMF)/Sandbox2 again so that it mirrors the new form. If people get used to it, they'll be able to use Bugzilla autonomously in no time! Will "deploy" this tomorrow, if that's ok for you. Thanks a lot everybody, --Elitre (WMF) (talk) 21:47, 30 October 2013 (UTC)

FYI your link to the brand new Bugzilla report form demands a Buzilla login (which recommends using an anonymous disposable email account etc). Any chance you could link to a bug report using the new bugzilla form? - Pointillist (talk) 22:47, 30 October 2013 (UTC)

A screenshot is on its way, --Elitre (WMF) (talk) 22:52, 30 October 2013 (UTC) Now at File:Guided bug report form.png. Thanks a lot for pointing this out. --Elitre (WMF) (talk) 23:00, 30 October 2013 (UTC)

That was quick! Looks good to me, but what do the regular bug reporters think? - Pointillist (talk) 23:12, 30 October 2013 (UTC)

Well, I was hoping to find out in this thread, but several of them seem pretty tired ;) Regulars! Chime in! --Elitre (WMF) (talk) 23:14, 30 October 2013 (UTC)

Pointillist, User:Salix alba, User:Thryduulf Hey, since I don't usually publish templates... can someone make User:Elitre_(WMF)/Sandbox2 official? I am not sure we want to overwrite the original one. Also, would a link to mw:How_to_report_a_bug be enough as documentation, for the time being? Thanks, --Elitre (WMF) (talk) 13:08, 4 November 2013 (UTC)

I'm really not the person you need to ask about templates! Sorry, Thryduulf (talk) 15:49, 4 November 2013 (UTC)

Now moved to {{VE Bug2}} which I guess makes it official. Testing

Bug report	VisualEditor
Mito.money	Please app{}
Intention:	Somewhere to report bugs
Steps to Reproduce:	Do this paste in blank template fill in fields
Results:	a nicely formatted report
Expectations:	VE devs will instantly fix the bug
Page where the issue occurs	Template:VE_Bug2
Web browser	Chrome
Operating system	Mac OSX
Skin	Vector
Notes:	This is not really a bug report
Workaround or suggested solution	write it by hand

--User:Salix alba (talk): 16:39, 4 November 2013 (UTC)

Thanks!!! I created Template:VE_Bug2/bug_template, so that it can be linked on this page as we did before. Salix, can you check if this is ok as well? --Elitre (WMF) (talk) 16:56, 4 November 2013 (UTC)

It should be live now. Thanks everybody. --Elitre (WMF) (talk) 14:19, 12 November 2013 (UTC)

Toc Toc. Who's there?

When using VE, the TOC disappears (tested in Flags of counties of the United States and Auto racing). I don't think this happened already before the weekend, I think I would have noticed it... FF25, Windows 7. Fram (talk) 14:56, 12 November 2013 (UTC)

I'm here, and you missed 49224! --Elitre (WMF) (talk) 14:59, 12 November 2013 (UTC)

Thanks! Funny how we (well, I) can miss things that have been lacking for so long... Fram (talk) 15:17, 12 November 2013 (UTC)

Some positive feedback

I did a significant copy-edit of an article today, using VisualEditor as much as possible. There were still a few things I had to use wikitext for (in particular, accented letters and some odd template stuff), but on the whole I was able to complete the edits with just VisualEditor. I would not have been able to do that four months ago. Good work on the steady progress. Risker (talk) 06:40, 15 November 2013 (UTC)

Hey Risker. Your words are appreciated. Did you have a chance to test the "Switch to wikitext" feature yet? Regards, --Elitre (WMF) (talk) 12:31, 15 November 2013 (UTC)

Bitching about testing

I have been told by some that I shouldn't blame WMF (devs, systems, whatever) for the shortcomings of VE, but seriously, sometimes it can't be helped. If it tunrs out that my reason for this post is based on flawed information, then please let me know. Otherwise:

The switch between VE and wikitext editing has been active now for a few weeks, and was announced at e.g. mw:VisualEditor/status#2013-10-monthly as one of the major new features of the month in VE.

As far as I can tell, this has never worked in Firefox (see Wikipedia:VisualEditor/Feedback#Messages should reference ability to switch to source editor. If correct, this means that a major new feature has not been tested on one of the two or three main browsers for VE. Coupled with the serious failure of early November with accents, which revealed that new VE releases were (until then) not tested on non-enwiki versions, makes it obvious that the criticisms which were raised multiple times and which led in part to the RfC fiasco here, have not changed anything at WMF (or whichever part of WMF is responsible for this) concerning this.

Why should we believe anything the WMF tells us wrt to testing, feedback, learned lessons, and so on if it looks as if in reality all we get is a big "fuck you, we don't do testing, you are still the guinea pigs" anyway? Why would we believe that the approach to e.g. Flow will be any better? Fram (talk) 14:10, 15 November 2013 (UTC)

New categories not rendered

The following discussion is marked as answered. If you have a new comment, place it just below the box.

---

When I add a category, it does not appear on the page after saving. John Vandenberg ^(chat) 04:46, 8 November 2013 (UTC)

Same here. It isn't shown directly after saving, even though it is present. Refreshing makes it visible. Another issue I noted: can categories please always get a new line? This looks terrible. Fram (talk) 09:33, 8 November 2013 (UTC)

Did adding categories work properly in the past? I guessing it is a regression, as I doubt that VE was rolled out to Category pages when adding of parent categories does not work properly, and nobody has noticed until now. John Vandenberg ^(chat) 17:30, 8 November 2013 (UTC)

Adding a category actually works; the bug you are looking for is 48560, though. --Elitre (WMF) (talk) 15:08, 12 November 2013 (UTC)

Thanks Elitre (WMF) for finding the relevant bug for me; I don't think it is appropriate to say it 'works' if the category doesn't appear after save, and it also emits silly layout (is there a bug for that?), which causes bugzilla:56880 to become very prominent. John Vandenberg ^(chat) 00:36, 14 November 2013 (UTC)

This "silly layout of new categories" issue might be Parsoid not doing the right thing. Will take a look tomorrow. Ssastry (talk) 02:49, 14 November 2013 (UTC)

Now fixed @ https://gerrit.wikimedia.org/r/#/c/95432/ ... will be deployed Monday. Ssastry (talk) 16:48, 14 November 2013 (UTC)

Ssastry, thanks, it's always a pleasure to have you around here. Please tell Parsoid on our behalf that it needs to behave, will you? :) --Elitre (WMF) (talk) 13:38, 15 November 2013 (UTC)

Elitre, yes, I have been training for a long time in the art of talking to inanimate objects .... I remain hopeful that one of these days .... Ssastry (talk) 16:19, 15 November 2013 (UTC)

Space between ":" and characters count increase

Tracked in Phabricator
Task T58733

The following discussion is marked as answered. If you have a new comment, place it just below the box.

---

Hi, I noticed that several edits by VE on frwiki are modifying the regular space character before ":", replacing with an other whitespace character, but probably an odd one since the count of characters is increasing by 1 for each character replaced. Examples: [49], [50], ... This is again a problem making dirty diffs and leaving strange characters (but invisible) in articles. Could something be done about this so that normal space characters are not replaced by something else ? --NicoV ^{(Talk on frwiki)} 12:07, 5 November 2013 (UTC)

Hi, isn't that 48570? It's been patch-to-review for a while now, so let's ping User:Ssastry about it. --Elitre (WMF) (talk) 12:15, 5 November 2013 (UTC)

No, it seems a different one: 48570 is about adding space characters (every time, a space character is added before ":"), the one I'm reporting is about space characters being replaced by an other whitespace characters (only one character, but counted as 2 by diff because it's not an ASCII character). --NicoV ^{(Talk on frwiki)} 12:27, 5 November 2013 (UTC)

Well, subbu will tell us. Here I think I had noted what you refer to, that was later marked as a duplicate of 48570. --Elitre (WMF) (talk) 12:32, 5 November 2013 (UTC)

Hi Elitre, I have the impression that is different because the result is quite different: 48570 and 51024 resulted in many regular space characters before a ":", while the problem I'm reporting results in one special whitespace character before a ":". We'll see ;-) --NicoV ^{(Talk on frwiki)} 12:42, 5 November 2013 (UTC)

It's a win for everybody that I'm not a dev :D --Elitre (WMF) (talk) 12:47, 5 November 2013 (UTC)

Yes, it is not T50570. I closed it (should have done it long back :)). This is a different error. I have a suspicion what that might be. We'll investigate and fix it. Thanks for the report. Ssastry (talk) 16:18, 5 November 2013 (UTC)

Any news about this one ? It's regularly making dirty diffs on frwiki, and nothing seems to have changed. Is there any bugzilla for this ? --NicoV ^{(Talk on frwiki)} 15:00, 15 November 2013 (UTC)

Hi NicoV, Yes, it is T58733. I thought I added you and Elitre to the bug report, but maybe I added some other NicoV :). It has been fixed and will be deployed on Monday. Ssastry (talk) 16:05, 15 November 2013 (UTC)

Oups, my bad, probably missed the mail. --NicoV ^{(Talk on frwiki)} 16:23, 15 November 2013 (UTC)

Quick! Hide in the middle of the text!

The handling of hidden elements (some templates like italictitle, persondata, ...; and of course categories) in VE really messes up the wikitext layout of pages. See e.g. here, where a whole lot of text is added after the persondata and categories, but before the stub tag. While this happens in wikitext editing as well, in VE it is much easier and can be done by editors not wanting to do this but getting this result anyway. Luckily, the editor noticed this and corrected it in the wikitext editor[51], which again makes one wonder what the added value of VE is. Fram (talk) 08:56, 18 November 2013 (UTC)

citation needed

Here, at "humor effect", you get a citation needed with a reason. In VE mode, you get a "span title =" which shouldn't be there... Fram (talk) 14:05, 7 November 2013 (UTC)

I tested this, and I guess it depends on the inverted commas. --Elitre (WMF) (talk) 14:54, 12 November 2013 (UTC)

The template's docs say not to use double quotation marks, and, indeed, things behave oddly if you don't follow the instructions and correctly if you do. Whatamidoing (WMF) (talk) 20:55, 18 November 2013 (UTC)

Strange result

Here, something went wrong. Note the editor succeeded in introducing wiki-markup into the VE text :-) Probably not a very common bug (or occurrence, "bug" may be the wrong word here), but indicative that the wiki-linking feature perhaps isn't as intuitive as hoped. Fram (talk) 14:52, 6 November 2013 (UTC)

I just found out that if you want to add a word between brackets in VE, it will actually suppress the opening ones, but it will leave the closing ones. Note that you can still re-add the opening ones, and that my edit did not trigger the wikimarkup warning. Not sure if this is known, will investigate more tomorrow. --Elitre (WMF) (talk) 21:21, 7 November 2013 (UTC)

Bumping this, --Elitre (WMF) (talk) 14:44, 12 November 2013 (UTC)

I can't replicate this. When I type [[This]], I get the expected result of <nowiki>[[This]]</nowiki>. Whatamidoing (WMF) (talk) 20:28, 18 November 2013 (UTC)

About what Fram is reporting, that is not unusual AFAIK - when you add wikicode, you just get a warning message and what you do will not work properly, but you can still save. About what I said instead, it does happen to me, so it's now at 57207. --Elitre (WMF) (talk) 21:40, 18 November 2013 (UTC)

I've added a note about which browsers I've tried. It might be specific to Chrome or to Windows. But it's hard to know, since it's not happening consistently for you. Whatamidoing (WMF) (talk) 22:29, 18 November 2013 (UTC)

How do I insert a picture?

I want to copy an image from one site (characters in the t.v. show "Bones") to another site, (List of fictional anthropologists). I got the picture to copy (using the source file) onto the media page (though there was no explanation of what to do), but then I was stumped. There was no "paste," "apply," "do" or any other similar button (to say nothing of there being no explanation there or at the guide (https://wiki.riteme.site/wiki/Wikipedia:VisualEditor/User_guide) page. All I saw was a big X. Suffice it to say that I didn't succeed in getting the picture onto the page. Kdammers (talk) 01:39, 8 November 2013 (UTC)

As far as I know, you can't. Someday in the distant future probably... Fram (talk) 09:35, 8 November 2013 (UTC)

Then why is there a media button? In any case, if it is non-operative, there should be a notice to that effect. Kdammers (talk) 12:02, 8 November 2013 (UTC)

The feature, AFAIK, is working as intended. It lets you choose pics from local wikis or Commons, you just need to give it a keyword. The guide does explain how it works. Thanks, --Elitre (WMF) (talk) 12:28, 8 November 2013 (UTC)

Kdammers, you asked "How do I insert a picture?" and later "why is there a media button?" The answer to those is: you can insert a picture using the media button, it works (more or less, e.g. don't try to insert it at the left side...). But what you actually wanted to do, was copy an image from one article to another using VE. This is not possible (although it would of course be very useful). What you have to do is determine the file name (which is impossible in VE! You have to do it in wikitext), and then type that name into the destination article into the box you get when you chose "media". Obviously, if you are savvy enough to open wikitext to find the filename, you'll probably simply copy-paste the full "file" text and open the other article in wikitext as well...

Elitre, I presume you misunderstood the intended question (understandably, it wasn't very clear), but I hope that you don't mean that the lack of copy-paste (and many other features) in the "media" feature is "working as intended", but that the feature works for the few things it does, but is severely lacking in many others. If it truly was the intention that the "media" option only would offer what it does now, then I don't think VE will ever be considered non-beta. Fram (talk) 12:38, 8 November 2013 (UTC)

Fram, we are all aware that copy/paste for VE has not reached that point yet. My point was merely that, right now, the Media option does what is explained in the Guide :). As a wikipedian, I'd be quite concerned about copy/pasting of images which are not already uploaded on our servers with full information about author, license and so on (particularly for those wikis like it.wp for which Fair Use is not an option). --Elitre (WMF) (talk) 12:46, 8 November 2013 (UTC)

I'm discussing copy paste from one enwiki article to another, obviously. I'm totally in agreement that copy-pasting images from outside Wikipedia is a rather bad idea generally. Fram (talk) 13:30, 8 November 2013 (UTC)

Fram, yes I can insert pictures using wikitext, but my concern is with improving VE. I just noticed that for some sites (e.g., Asian pear, when I go to media in VE, I get a gallery of possible images that are insertable with one click on a chosen image. So, for some sites 'media' works for me with-out my having "think" at all, i.e., I found it intuitive. But for other sites, where there is no gallery (where does the gallery come from?), it sounds to me like You are saying is that I should enter the file name into the rectangle to the right of the magnifying glass. Okeh, but then what? Entering the file name alone does not activate any-thing. Hitting enter does not activate any-thing. The X will only kill it. Kdammers (talk) 08:03, 9 November 2013 (UTC)

I never thought to click on the "Insert Media or the icon next to it, since that seemed like nothing more than the title. But checking back I tried it, but clicking on them didn't do any-thing any-way. Kdammers (talk) 08:05, 9 November 2013 (UTC)

@Kdammers: Regarding your question of where the gallery comes from, the user guide says "Clicking the 'Media' icon opens a dialog that automatically searches this Wikipedia and Wikimedia Commons for media files, using the name of the page you are editing." So in the case of "Asian pear", the search functionality is finding a lot of matches. On the other hand, if you go to (for example, a random article I just went to) Marsh Lake (Nova Scotia), the search doesn't find anything.

Regarding "Entering the file name alone does not activate any-thing," that's not my experience. If you paste the file name in (but not "File:", which isn't part of the file name), you should see definitely see the image you want (from Wikimedia Commons).

If that still doesn't work for you, please let us know the file name of the image/picture, and the article you were trying to add the image to. -- John Broughton (♫♫) 02:09, 10 November 2013 (UTC)

There are some problems (predating VisualEditor) with Commons' search indexing that especially affect images that were uploaded recently. Most of them process through in a day or two, but searching for an image that you just uploaded a few minutes ago can sometimes be an exercise in frustration (regardless of whether you're searching for it inside VisualEditor or at Commons in the regular search box). There are bugs open on the problem: Commons' search indexing needs to be improved, and VisualEditor needs (IMO) to be able to add images based on exact file names. Whatamidoing (WMF) (talk) 02:15, 10 November 2013 (UTC)

You might also want to see 37932 and 38031. --Elitre (WMF) (talk) 13:35, 11 November 2013 (UTC)

Well, now it DID work when I entered (a different - I can't remember what the other file name was) file name. But now I have another problem. How do I put a label underneath the picture? Simple typing does not work. Should I have labeled (if so, how?) before it got inserted? Is there some special place for adding text associated with illustrations? Kdammers (talk) 02:28, 15 November 2013 (UTC)

Hi, you're trying to add a caption, if I understand correctly? This section of the user guide has a section about it, please report if the described procedure doesn't work for you. Thanks, --Elitre (WMF) (talk) 13:43, 15 November 2013 (UTC)

Thank You, Elitre. For me that was hardly intuitive, even though after the fact it seems logical. But, even so, it doesn't exactly work for me. When I try to type in the caption, The letters don't appear in the order I type them: "Emily DeSchanel" appears as "mily DeSchanel" and "E" down a line. The "E" could not be erased. By using the back key, I started over (2 times, i.e., a total of three tries), and got the same result. Then when I went back to the article and started again, I got a long list that looks some-thing like this:

"E" "ily DeSchanel" "mily DeSchane" "ly DeSchan" etc. when I tried to erase this mess, I could only erase some of it, leaving a list about 5 or ten lines long with one and two letters per line. Other than backing out (or adding stuff), I can't seem to do any-thing with this.Kdammers (talk) 09:24, 16 November 2013 (UTC)

Yes, I noted that problem here some time ago (even forgot to add it to the list of most problematic remaining problems in the section above, there are just too many of those remaining...). At the moment (and for some time already), you can't add a decent caption to an image. Makes the image handling a bit useless of course. I have complained to @JDForrester (WMF): about the many problems with file handling, but received the response "@Fram: I'm immensely puzzled by this - VisualEditor has not remotely "eliminated nearly all functionality" from media files. We have repeatedly and clearly said over the last nine months that the rest of the functionality (all of it) is coming, but is less of a priority. If you're going to mis-represent that, how can we have a proper conversation about the matter on which we should focus and when? Jdforrester (WMF) (talk) 18:13, 11 October 2013 (UTC) " (see User talk:Jdforrester (WMF)#Office hours). This and other similar responses coming from someone whose paid job description is "My job is to help make sure the VisualEditor team understands what the community wants and needs, is focussed on the things that matter, and is engaging with and understood by the community." makes one understand the rift between some of the main people at WMF and the people for who they supposdly are developing software (see also Erik Möller, the WMF Deputy Director, and User:Jorm (WMF), the "Senior Designer, Wikimedia Foundation" for examples of this rift). I don't think VE will be out of BETA mode anytime soon... Fram (talk) 08:12, 18 November 2013 (UTC)

It won't be, and that's the key. Now checking if anyone has filed this issue. --Elitre (WMF) (talk) 21:45, 18 November 2013 (UTC) Now at 57211, and thanks for reporting this: I suspect that many new features are coming on that front, though. --Elitre (WMF) (talk) 22:02, 18 November 2013 (UTC)

I suspect that this is specific to Firefox. I have no trouble adding an image with a caption, or even adding a ref to a caption in Safari. But I get the same results in Firefox 25. It would be useful if someone would try to add a caption in Chrome and let us know the results. Whatamidoing (WMF) (talk) 22:53, 18 November 2013 (UTC)