Jump to content

Wikipedia:VisualEditor/Feedback/Archive 2014 1

Add links
From Wikipedia, the free encyclopedia


Create and copy table.

Tracked in Phabricator
Task T54181
Tracked in Phabricator
Task T61192

I want VisualEditor can create more rows of table by click Tab.

I want VisualEditor can copy and paste table data(when copy more columns or more rows) from another place to one like in websites or office excel.

Thank you.Manzzzz(talk) 03:29, 27 December 2013 (UTC)

Hi Manzzzz,
The developers are already working on the ability to create more rows (and columns) in a table. We might see some improvements on that issue in a couple of months.
You can already copy some tables from external websites. That's what I did here. (There's a link to the page that I copied the table from, if you want to try it yourself.) You can also copy out of online spreadsheets, like Google Docs, and offline spreadsheets like Apple Numbers. (I don't have Microsoft Excel, so I haven't tried that.) You can see several examples of tables I've copied and pasted here.
It doesn't seem to copy the table formatting, so they appear as the default (double lines in VisualEditor and invisible lines when you read the page). Whatamidoing (WMF) (talk) 20:07, 27 December 2013 (UTC)

Plese see this https://en.wikipedia.org/wiki/User:Whatamidoing_%28WMF%29/sandbox#Copying_2Manzzzz(talk) 02:53, 28 December 2013 (UTC)

The middle table is the only one you used VisualEditor for, and you pasted the copied table into the middle of a pre-existing table. Wikitext has no idea how to place a table inside another table. Can you try again, and paste it into a completely blank line/new paragraph? Whatamidoing (WMF) (talk) 05:51, 28 December 2013 (UTC)

I think it's great if I can copied table data and paste it on pre-existing table like in MS office Excel or Word. For example:https://en.wikipedia.org/wiki/User:Whatamidoing_%28WMF%29/sandbox#Copying_2Manzzzz(talk) 09:09, 28 December 2013 (UTC)

In Excel, if you paste over an existing table, it replaces the old contents with the new material you're pasting. The alternative is to add cells without removing the old material.

Start with this pre-existing table in the article:

Header Text Here
1 2 3
A B C
α β γ

Copy this table from another website (perhaps it is updated statistics for a football player), and paste it into first cell of the larger, pre-existing table:

Header Text
ŋ dʒ
Б Ґ

There are two possible results:

Do you want the Excel-like behavior that replaces the old contents, or do you want to add the new material while keeping the old? Whatamidoing (WMF) (talk) 19:18, 28 December 2013 (UTC)

The fist one,the Excel-like behavior that replace the old content.Manzzzz(talk) 02:46, 31 December 2013 (UTC)

Thanks. I've filed T61192 to request that function. Whatamidoing (WMF) (talk) 22:04, 1 January 2014 (UTC)
Tracked in Phabricator
Task T61196

Hi.

I am currently editing an article draft in my user space: User:Codename Lisa/Metro-style apps. In editor mode, when I click one of the links, e.g. toolbar or scrollbar, instead of en.wikipedia.org/wiki/toolbar, I get en.wikipedia.org/wiki/User:Codename_Lisa/toolbar.

Best regards,
Codename Lisa (talk) 14:46, 1 January 2014 (UTC)

When I open that page in VisualEditor and click on "toolbar", it assumes that I want to edit the link (I see the icon for the link gadget) rather than opening the linked page. If I control-click and open the link in a new window, it goes to the correct page (both Safari 6 and Firefox 26 on Mac OS 10.8.5, all Vector). So consequently I need browser/OS/skin information from you. Also, can anyone else confirm this, especially in a browser/OS/skin combination that's different from Codename Lisa's? Whatamidoing (WMF) (talk) 19:42, 1 January 2014 (UTC)
Hi. That's Firefox 26 on Windows 7, Vector skin.
Strangely, however, they are working okay now. But as a good measure, I selected the word "window" and linked it. The result of Ctrl+Click was "en.wikipedia.org/wiki/User:Codename_Lisa/window". Best regards, Codename Lisa (talk) 23:34, 1 January 2014 (UTC)
I've filed T61196. It may duplicate an existing one; I wasn't sure. But at least it's in front of the devs. Whatamidoing (WMF) (talk) 23:45, 1 January 2014 (UTC)
Hmmm... From what I am seeing, links created beforehand are okay. Links created in the outstanding edit open in the wrong place. Just tested in my sandbox. So, here is the updated reproduction step:
  1. Edit a user subpage
  2. Create a link to an article on main space, e.g. Book or Girl
  3. Ctrl+Click on the link
  4. Save the page
  5. Re-enter edit mode
  6. Ctrl+Click on the same link again
Expected result: In steps 3 and 6, the article must open
Actual result: In step 3, a subpage with the same {{SUBPAGENAME}} as the link name opens. Step 6 is always successful. Existing links open okay.
Best regards, Codename Lisa (talk) 00:24, 2 January 2014 (UTC)
Thank you! I confirmed it in Safari, and I'm on my way to update the bug report. Whatamidoing (WMF) (talk) 03:43, 2 January 2014 (UTC)
Tracked in Phabricator
Task T61216
Bug report VisualEditor
Mito.money Please app{}
Intention: I was trying to edit Silaum silaus, though the links it changed (see this edit) weren't touched or changed at all by me when I was editing. I've got no idea why this happened.
Steps to Reproduce: I was just editing the page and switching some sentences around - I didn't even click on those wikilinks at all! Really confused. I've not attempted to reproduce it.

Please mention if it's reproduceable/if you attempted to reproduce or not. -->

Results: HTTP links were inserted into the wikilinks for two links which were not being edited
Expectations: For this not to happen
Page where the issue occurs https://en.wikipedia.org/w/index.php?title=Silaum_silaus&diff=588803158&oldid=587979575
Web browser Firefox 26.0
Operating system Windows 7
Skin Vector
Notes:
Workaround or suggested solution

Acather96 (click here to contact me) 12:16, 2 January 2014 (UTC)

Hi Acather96,
If you copied and pasted those links (in the course of "switching some sentences around"), then, yes, can reproduce it, in Firefox only (but on a Mac). I can't find a matching bug report, so I'll make one for you. Whatamidoing (WMF) (talk) 16:47, 2 January 2014 (UTC)
Yep, that was it. I should have been more specific - I was copy and pasting sentences around at the time. Thanks for all the work you guys are doing on VE, it's an amazing project! Acather96 (click here to contact me) 17:36, 2 January 2014 (UTC)

Explanation on hover

In my honest opinion all symbol only icons should throw a tooltip on mouse hover, explaining the function. The icon with the three bars left to the cancel button don't follow this convention, yet. (I miss this function on touch devices every time...) Nobelium (talk) 13:17, 3 January 2014 (UTC)

Added that to 59719. Regards, --Elitre (WMF) (talk) 14:10, 6 January 2014 (UTC)

Yet another spellcheck bug

Procedure. Find or create a bulleted list with the following characteristic: at the end of a line, there must be a wikilink in which the last word is not recognized by your browser's dictionary. While in VE, right-click on the word, click on a suggestion.

Result. Everything works as expected except that a blank line appears underneath the entry you've corrected. Undo (Ctrl+Z) does not remove this blank line. The blank line does not remain when the page is saved.

Example.

becomes


Settings. Monobook on Firefox 26.0 on Windows XP

-- Cryptic C62 · Talk 14:32, 6 January 2014 (UTC)

So this is a display-only bug, and the wikitext gets saved correctly?
I can't confirm this in either Safari 6 or Firefox 26 on a Mac (both Vector). Can someone else please try? Also, is it necessary for the last item in the list to be an unrecognizable spelling? What happens if you have three or more items in the list? I need this information to be able to write up an accurate report for the problem you found.
In trying to reproduce this one, I found another: in Safari, VisualEditor corrects the spelling in the display, but not in the wikitext when I tried to save the page. The displayed correction also un-corrects itself if you hit return to start a new paragraph. So I filed T61748, but that won't help you. Whatamidoing (WMF) (talk) 01:05, 7 January 2014 (UTC)

While in VE, place the cursor inside an existing wikilink. If you type any character, that character is incorporated into the anchor text for that link. If instead you insert a special character from the drop-down menu, the anchor text is broken into two pieces:

-- Cryptic C62 · Talk 14:19, 6 January 2014 (UTC)

A wikilink getting splitted is not new, unfortunately I don't seem able to find the relevant bug right now... Will try again later, but we can always file a new one. Thanks, --Elitre (WMF) (talk) 14:31, 6 January 2014 (UTC)
I can't confirm this in either Safari or Firefox (Mac OS 10.8.5/Vector). Cryptic C62, would you mind switching over to Vector and trying this again? Or can anyone who uses Vector reproduce this? Whatamidoing (WMF) (talk) 01:15, 7 January 2014 (UTC)

Leave the "toolbar" at the top of the screen always

Editing articles would be significantly more efficient if the tool bar stayed at the top of the screen even if the user scrolled to a different section of the article. This way, users would not have to keep scrolling to the top of the article just to select a different option or insert links or media.

To preserve screen space, the option to keep the toolbar pinned to the top of the screen could be defined via a simple checkbox in an options menu, giving the flexibility to work without a pinned toolbar for those who want more screen space. TROPtastic (talk) 04:04, 5 January 2014 (UTC)

That's what it should be doing. What browser and version of the browser are you using ? If you try it with your account on another browser, does it work in that case (if it doesn't work in that case, then perhaps is a gadget or something similar that you have installed for your account). —TheDJ (talk • contribs) 12:53, 5 January 2014 (UTC)
Hi TROPtastic,
Thanks for the note. T55550 had this problem a while ago, and the editor and I thought that it might be due to his touchscreen. Can you tell me about your computer/web browser/Wikipedia screen? Whatamidoing (WMF) (talk) 01:19, 7 January 2014 (UTC)

Upcoming office hours to discuss VisualEditor

Greetings, testers :) The engineering department has planned office hours in the next months to discuss VisualEditor. The first one will be held next week on January 15th, at 2300 UTC; the second will be held a week later, on January 22nd, at 2300 UTC. Please join as Product Manager James Forrester discusses VisualEditor and upcoming plans. Logs will be posted on Meta after each office hour completes. (If office hours are heavily attended, it can be difficult to get to all questions, but if you want to ask a question and cannot attend or do not speak English, please let us know your question here by the day before, just like Elvey already did, and a community liaison will present it among possible discussion topics). Regards, --Elitre (WMF) (talk) 17:44, 7 January 2014 (UTC)

bent arrow

In the VE edit mode, I saw bent arrows (C&P did not capture them). They look some-thing like this: <-| . I suppose this means some-thing "The auto-editor is removing spacing that a human editor has put in (e.g., two spaces before a new sentence), but I am only guessing. I wonder why this mark-up is visible but other amrk-up symbols aren't. (This was in an article on Mongolia's best-student award.) Kdammers (talk) 03:12, 6 January 2014 (UTC)

That's called carriage return and won't be visible anymore once 47790 is fixed. Thanks, --Elitre (WMF) (talk) 14:02, 6 January 2014 (UTC)
I think you may have a typo in the bug number. That one is about blank lines (slugs) at the top of the page.
(No typo, if I read this correctly. --Elitre (WMF) (talk) 17:47, 7 January 2014 (UTC))
Kdammers, this is caused by someone typing out a paragraph like this:
Lorem ipsum dolor sit amet, consectetur
adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, 
quis nostrud
exercitation ullamco laboris nisi
ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit
in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident,
sunt in culpa qui officia deserunt mollit anim id est laborum.

The wikitext parser just ignores this evidence that someone hit return and runs it all together as one paragraph. You know, of course, that to get a separate paragraph, you have to have a blank line between paragraphs, not just hit return once.

The character you're seeeing is this: (except probably smaller, since it will be the same size as any other letter of text on your screen).

It intended to show the current person editing the page that some previous person hit return only once in the middle of a sentence or paragraph (or, more commonly, copied and pasted something without removing stray line breaks). If VisualEditor doesn't show the bent-arrow character there (or something similar), then you won't know that it's there and can't remove it from the underlying wikitext (and it might be important, such as hitting return in the middle of a word that was hyphenated in the original source, which breaks search).

Normally, if you see these in VisualEditor, you may choose to either ignore them or to remove them. You will also encounter them if someone has deliberately used <br> (to make unbulleted lists). Those should be left alone. What you see on the screen will probably be sufficient context to let you know which case it is. Whatamidoing (WMF) (talk) 00:37, 7 January 2014 (UTC)

Adding pictures

Tracked in Phabricator
Task T53798

I finally figured out how to add a picture (but not the accompanying text) using VE. This is at Kim Kwang-kyu. But I don't know how to move it (I can't drag it, and clicking at particular place in the article did not affect its placement. When I first tried to add the picture, I was totally stumped: There are no instructions in VE that I could see. I had clicked on insert and then insert media. the picture that I'd gotten from Wikicommons was there. I tried to save etc. But nothing happened. Only after backing out and closing the edit and then starting again did GUESS that maybe if I clicked on the image it might do some-thing. It did, to my surprise. Why can't there be a little bit of help here, such as "click on the image to have it entered into the article [into a place that we decide and won't tell you how to switch]." (Sorry for that last bit, but VE seems to make some of the most basic things opaque or impossible (e.g., also, starting a new article). Kdammers (talk) 05:39, 30 December 2013 (UTC)

Hi Kdammers,
Wikipedia:VisualEditor/User guide#Editing images and other media files has information about how to resize images and add captions. It sounds like your request is for context-sensitive help. For example, a little "Help" icon within the "add an image" tool that would give you information specifically about adding images. Did I understand your idea correctly? Whatamidoing (WMF) (talk) 21:48, 1 January 2014 (UTC)
Precisely. VE is suppsed to be easy for people not familiar with our usual mark-up, i.e., for people possibly aving experience with WYSIWYG. When it goes beyond simply typing, in-context help is essential. If they have to go hunting for some on-line manual, we have failed. Kdammers (talk) 01:07, 4 January 2014 (UTC)
It looks like there's an enhancement request open for this already. Would you have a look and let me know if there is something specific that should be added? (I kind of like the idea at the end of having VisualEditor call a fixed page name for the help, but letting that page name be redirected to whatever section/page/whatever we want.) Whatamidoing (WMF) (talk) 00:09, 7 January 2014 (UTC)
Tracked in Phabricator
Task T53032
Thanks. I don't see any-thing about getting the accompanying text to go with the image.Kdammers (talk) 03:31, 7 January 2014 (UTC)
It looks like T53032 is about fetching the accompanying description when an image is added. Whatamidoing (WMF) (talk) 00:00, 9 January 2014 (UTC)

Missing highlight when selecting list bullets

Place your cursor at the end of an element in a bulleted list. Use Ctrl+Shift+Left to highlight words in the list item. If n is the number of words in the item, press Ctrl+Shift+Left n times, then hit backspace. The text is removed, but the bullet remains. Fine. However, if you press Ctrl+Shift+Left n+1 times, the entire row of text is deleted. Also fine.

The problem is that when pressing Ctrl+Shift+Left n+1 times, the bullet itself is not highlighted. There is no visual indication of whether hitting backspace will delete the entire line or just the text.

Using Monobook on Firefox 26.0 on Windows XP.

-- Cryptic C62 · Talk 14:39, 6 January 2014 (UTC)

This is consistent with how word processing software works, so I think this is probably "expected behavior". Whatamidoing (WMF) (talk) 00:03, 9 January 2014 (UTC)

multiple ☃ characters

Tracked in Phabricator
Task T61216
Tracked in Phabricator
Task T60419
Tracked in Phabricator
Task T61847
Tracked in Phabricator
Task T61849

I was editing an article and the text suddenly all 'jumped' and multiple ☃ characters were inserted. I mention this for now and see if it happens again. Edgepedia (talk) 16:07, 31 December 2013 (UTC)

The snowmen again ... I reported a bug like this coupla months ago, I forget the number. That time it was VE getting confused about backspacing in the vicinity of a reference - David Gerard (talk) 13:52, 1 January 2014 (UTC)
Hi Edgepedia, can you tell us which article you were working on? Thanks, Whatamidoing (WMF) (talk) 19:44, 1 January 2014 (UTC)
I was editing my sandbox at User:Edgepedia/S&DR sandbox. Something strange happened just afterwards with this edit, but I haven't had any problems today. I made a copy of the sandbox in the stage it was at the time at User:Edgepedia/VE/S&D. Edgepedia (talk) 20:05, 1 January 2014 (UTC)
Edgepedia, are you still running Chrome over Windows 7? Did you copy and paste anything shortly before this happened to you? Was it before or after this problem that resulted in an empty ref (<ref />)? Whatamidoing (WMF) (talk) 21:24, 1 January 2014 (UTC)
Yes, Yes and before. Edgepedia (talk) 21:26, 1 January 2014 (UTC)
I use VE mainly for copy editing, so I'm moving stuff around all the time. This has to be done by cut and paste. Edgepedia (talk) 21:37, 1 January 2014 (UTC)
I believe that snowmen are often a sign of problems with copying and pasting. I just can't figure out what in that very normal page would have been difficult to copy or paste. I'll keep thinking about it. Whatamidoing (WMF) (talk) 22:06, 1 January 2014 (UTC)

Edgepedia, so far, I've found two obviously wrong results simply by

  1. selecting the appendices on the page (click here to edit the original version),
  2. cutting them, and
  3. pasting them right back where they were.

Safari and Firefox give me different results. (Firefox's is much worse, and most of the mess is only visible in diffs.) Would you mind trying that very simple, three-step process in Chrome and saving the results (assuming it lets you save an edit that ought not produce any changes at all)? Thanks, Whatamidoing (WMF) (talk) 22:34, 1 January 2014 (UTC)

Thanks: On Chrome on Windows 7 I get duplication of the appendices, except the last line: [1].
I'll try it on IE on XP at work in a few hours. Edgepedia (talk) 06:58, 2 January 2014 (UTC)
VE is disabled for the version of IE I have. The edit using Chrome under XP made no changes to the saved version of the article, although the appendices had disappeared in VE before the save was made. Edgepedia (talk) 09:03, 2 January 2014 (UTC)
Delaying archiving here, because I still need to check the rest of these for previous reports in Bugzilla and file them if they're not there. Whatamidoing (WMF) (talk) 00:11, 7 January 2014 (UTC)

So let us see what we've got here:

  • T61216, in which cutting and pasting [[Link]] in Firefox 26 produces [http://en.wikipedia.org/wiki/Link Link].
  • T60419, in which cutting and pasting {{commons}} doesn't really work in Firefox.
  • T61847, in which cutting and pasting in Safari produces duplicate section headings.
  • T61849, in which cutting and pasting in Chrome produces increased indentation for lists.

Edgepedia, have you seen any more snowmen? Does anything in T59884 look familiar? Whatamidoing (WMF) (talk) 00:45, 9 January 2014 (UTC)

Incorrect/random bolding and italicization

Bug report VisualEditor
Mito.money Please app{}
Intention: Editing User:Acather96/Love Wins and adding content, I also debolded some text.
Steps to Reproduce: What did you do? Describe how to reproduce the problem, so another person could follow your steps
  1. First
  2. Then
  3. Finally

Please mention if it's reproduceable/if you attempted to reproduce or not.

Results: Erroneous bolding and italicization
Expectations: For this not to happen
Page where the issue occurs https://en.wikipedia.org/w/index.php?title=User:Acather96/Love_Wins&diff=590112456&oldid=589950240
Web browser Mozilla Firefox 26.0
Operating system Windows 8
Skin Vector
Notes:
Workaround or suggested solution

Acather96 (click here to contact me) 19:02, 10 January 2014 (UTC)

Templates and Infoboxes are not getting updated

This is not really related to VE but I don't know where to post it...the templates and the infoboxes on the articles are not getting updated for a reason I can't understand. On this article (at least the time I posted the comment) the link for the next episode is still read even though the article exists. If you click on it though, it WILL take you to the article. And in the template with all the episodes, the last episode (And One to Grow On) is not blue even though the template IS updated with the new link. And it appears that way in all the articles I checked that have the specific template.
I don't know if that's a bug or something temporarily but it's not really nice to be happening. I am sorry for posting here but, I don't know where to do it. Thanks TeamGale 00:51, 10 January 2014 (UTC)

Hi TeamGale,
At the English Wikipedia, these kinds of problems are normally posted to WP:Village pump (technical), where you will find several identical complaints. Something's being slow; it's not you or your computer. You can either wait until the pages get processed correctly (may be a whole day), or you can fix the problem right now by doing a WP:PURGE on the page (the page that is showing a false red link, not the page that the link leads to). The easiest way to purge a page is to go to Special:Preferences#mw-prefsection-gadgets, scroll down to ==Appearance==, and turn on the clock/purge button. Then go to each affected article and click on the clock once. The page will reload and the link should display its true colors.
I've already purged the page that you linked here, so that one should be correct now. Whatamidoing (WMF) (talk) 01:01, 10 January 2014 (UTC)
Thank you so much for answering! I have that clock on my page but I didn't know it could do that! :) And thanks for the link for technical problems! Already saved it in case I'll need it in the future! TeamGale 01:29, 10 January 2014 (UTC)
I had the same experience! I'd turned on the clock so I could see the time, and didn't realize that it had a double function until someone told me (naturally, this was after I'd null-edited a bunch of templates to get them to update). Whatamidoing (WMF) (talk) 01:27, 11 January 2014 (UTC)

Very strange copy-pasting

Can someone please test this and post their results? I'm using FF26 and W7.

  • First, copy some text to your clipboard (no matter what, a sentence or a whole article, doesn't seem to make any difference)
  • Then, open [2] (an old, empty revision of my sandbox to test things from scratch)
  • Now, paste your text.
  • Optional: if you have your own sandbox with some history, perhaps try it there as well to make sure that the behaviour is not dependent on my page (the result may differ, but the underlying reason should be the same)

I get some very unexpected results, but would like to hear from others as well before claiming that it is a VE bug and not something weird on my machine only. Fram (talk) 09:44, 10 January 2014 (UTC)

I copied the first sentence of your message here. It pasted correctly. What sort of results did you get? Whatamidoing (WMF) (talk) 01:26, 11 January 2014 (UTC)
An older version of that page (my sandbox) got copied, instead of what I actually had on my clipboard. I'll do some further tests and let you know the results. Fram (talk) 17:41, 12 January 2014 (UTC)
I can't repeat this in any consistent way so far. I often have problems with copy-pasting in VE, but the pattern escapes me. Fram (talk) 08:09, 14 January 2014 (UTC)

nbsps in ref names

Tracked in Phabricator
Task T60282

I got some garbage when using VE for a typo: diff. Someone's probably seen this before, but it was annoying, so I thought I'd share. --99of9 (talk) 12:09, 11 January 2014 (UTC)

@99of9: this is already a known problem. Could you please detail with which browser (+version) you are seeing this ? Might help in resolving this. —TheDJ (talk • contribs) 13:21, 11 January 2014 (UTC)
I think it was from Chrome, probably one of the latest versions. --99of9 (talk) 20:51, 11 January 2014 (UTC)
I've asked a handful of editors about this. So far, everyone has been using Chrome on either Windows 7 or Windows 8. Of course, Chrome is the most popular browser, so that doesn't completely prove anything.
The non-breaking spaces have been added by scripts. I've found two scripts so far that cause this. One script has been corrected (before the discovery this problem). The other one has not. I'm not sure that ref tags were designed to include HTML codes. Whatamidoing (WMF) (talk) 22:34, 15 January 2014 (UTC)

Impossible to delete templates on iPad

Tracked in Phabricator
Task T62110

I guess the iPad is not officially supported, but nevertheless reporting this bug: it is impossible to delete templates on the iPad (in Safari), because once the template gets selected, the keyboard disappears. --WS (talk) 21:44, 13 January 2014 (UTC)

That is an interesting design problem. I've filed a quick bug report about this, just in case it isn't already on their list of things to do for the mobile interface. If there's anything else that you'd like me to add, then please let me know. Whatamidoing (WMF) (talk) 22:39, 15 January 2014 (UTC)

Undo resize of image

Take a page like Hilbert's arithmetic of ends, resize an image (dragging on a corner); nah, don't like it, want the original size back, so use the "undo" button. Oops, that's not the original size... Perhaps put not only the horizontal size back, but also the vertical one? The code seems to be correct, but the display is screwed up. (Of course, being filled with <math>, this page is pretty useless in VE anyway, but that applie sto loads of pages anyway...) Fram (talk) 09:06, 10 January 2014 (UTC)

It looks like the horizontal resizes to the correct size, but the vertical display is still at the larger (or smaller) size in Safari, too.
Additionally, the selection is also a little odd: it seems to highlight all the way off the right edge of the screen. Does the same display problem happen for you? Whatamidoing (WMF) (talk) 01:24, 11 January 2014 (UTC)
Yep, exactly the same. Fram (talk) 17:41, 12 January 2014 (UTC)
What is the use case for allowing VE to change sizes of thumb images anyway? - Pointillist (talk) 23:52, 12 January 2014 (UTC)
I doubt there is one, image handling in VE is very poor and implemented rather at random. Apparently the devs didn't think "visual" and "images" had anything to do with each other :-D Fram (talk) 07:54, 13 January 2014 (UTC)
Mmm, but the question is why encourage article contributors to override the default size of thumb images as set by users in their preferences? I don't see how this can cause anything but problems: (1) VE doesn't display images the correct size in editing mode, so the starting size is wrong; (2) it resizes using absolute pixel dimensions rather than "upright=" ratios; (3) in general, thumb images shouldn't be manually resized anyway. - Pointillist (talk) 08:27, 13 January 2014 (UTC)
In general you shouldn't resize thumbs. However, if sometimes you should do this—and the MOS says that you should do so for most lead images—then VisualEditor needs to be capable of doing so. So the use case is "complying with the MOS".
When I asked about "upright" a few months, I was told that it was not desirable and defining the width was preferable. I don't know if mobile users would agree with this assessment, and I believe that "upright" will be supported in the future. Also in the future, VisualEditor will display images with the user's (or the site's) default size rather than with MediaWiki's default size (which is what you see now; the English Wikipedia chose to increase the default display size a few years ago). Whatamidoing (WMF) (talk) 20:43, 15 January 2014 (UTC)
Thanks for the feedback, especially the bit about "desirable"/"preferable, which I suspect was a programming POV rather than UX. Which part of the MOS do you have in mind for lead images? - Pointillist (talk) 21:11, 15 January 2014 (UTC)
Wikipedia:Manual of Style/Lead section and Wikipedia:Manual_of_Style/Images#Size. If an infobox is not present, then horizontal lead images are normally presented as 300px wide here at the English Wikipedia. Whatamidoing (WMF) (talk) 03:09, 17 January 2014 (UTC)
I feel the same as Pointillist regarding the bit about "desirable"/"preferable"... When there is a need to resize an image, then using thumb with upright is still nice to individual preferences. Fixed image sizes do not take user preferences into account at all, making the pages less accessible. For this reason, the French Wikipedia recommends using thumb+upright instead of fixed sizes where there is a reason to resize an image. For the same reason, I would propose to make the upright option more prominent in the VE interface than the fixed size options. A per-wiki parametrisable choice to make either upright or fixed sizes options more prominent in the VE interface could also be considered. Klipe (talk) 12:17, 16 January 2014 (UTC)
And I have happy news in this regard: support for "upright" will likely appear in March (insert standard disclaimers here ), along with support for non-thumb images and related options. Whatamidoing (WMF) (talk) 03:09, 17 January 2014 (UTC)

No response so reposting

This looks to have been missed, but this report was never addressed. Thanks, Acather96 (click here to contact me) 18:40, 16 January 2014 (UTC)

I can't reproduce it. Can you? Whatamidoing (WMF) (talk) 03:17, 17 January 2014 (UTC)

New Beta Edit

The new beta Edit option is way faster and more helpfull way that will get more editos on bord...Thanks TheMightyCraken (talk) 03:34, 19 January 2014 (UTC)

Thank you TheMightyCraken, it's nice to hear such words on this page from time to time :) --Elitre (WMF) (talk) 19:59, 22 January 2014 (UTC)

Default summaries

The Wikipedia:VisualEditor/User guide mentions (and even shows the interface for) "You can click on the common edit summaries options, to select and paste a standard phrase to the dialog box." I don't seem to be able to do this, neither here nor at Mediawiki... Fram (talk) 15:04, 13 January 2014 (UTC)

Perhaps User:John Broughton can tell you how he made the screenshot. Whatamidoing (WMF) (talk) 22:44, 15 January 2014 (UTC)
I'd like to say that I had an advanced, not-yet-deployed copy of VE with this additional functionality, and anticipated it being deployed momentarily. But that wouldn't be true. I used the production version deployed here at the English Wikipedia, as of 9 November, to take a screenshot and update the user manual.
In short, this seems a clear case of regression. The developers presumably had a reason for removing this (useful) functionality, and presumably will restore it, once higher priorities are dealt with. -- John Broughton (♫♫) 01:27, 18 January 2014 (UTC)
This is a gadget: under "Editing", "Add two new dropdown boxes below the edit summary box with some useful default summaries":Jay8g [V•T•E] 02:18, 18 January 2014 (UTC)
Thanks. I have now enabled the gadget, but it doesn't seem to make any difference, I still don't get the summaries. Fram (talk) 11:56, 18 January 2014 (UTC)
@Jay8g: That gadget was already enabled in my preferences. I see the dropdown boxes in the wikitext (source) editor, but - as Fram says - they're not visible in VE. So I remain convinced that this was a regression. -- John Broughton (♫♫) 19:41, 18 January 2014 (UTC)
Oh. I see. I didn't even check to see if the gadget still worked. Ideally, the screenshots shouldn't include any customization (such as gadgets):Jay8g [V•T•E] 21:42, 18 January 2014 (UTC)
This is another question we might ask James. Will let you know ASAP. Thanks, --Elitre (WMF) (talk) 20:03, 22 January 2014 (UTC)

Has VE been de-activated?

Tracked in Phabricator
Task T62359

VE no longer appears as an option on any of the articles I have looked at today (e.g., https://en.wikipedia.org/wiki/Schoolhouse_Blizzard). Has it been de-activated either temporarily or permanently?Kdammers (talk) 03:50, 13 January 2014 (UTC)

Hey Kdammers, I can still see its tab. Perhaps you removed its flag from the relevant Beta Features page? Regards, --Elitre (WMF) (talk) 20:23, 15 January 2014 (UTC)
Did you have this problem a few weeks ago, or was it someone else? Whatamidoing (WMF) (talk) 22:41, 15 January 2014 (UTC)
While I can't speak for Kdammers, I can confirm it happened to me twice this evening when I was working on an article. I refreshed the page and the "edit beta" links returned. As you can see from the tags on my article space edits from the last few hours, I used VE quite a bit during this editing session, and I changed nothing in my preferences (which have always allowed VE editing), so this is an unexplained anomaly. Risker (talk) 05:46, 17 January 2014 (UTC)
Kdammers, do I remember correctly that you use Firefox on Windows XP? What's your setup, Risker? Are either of you seeing a general slowdown when this happens (page takes a little longer to appear than you expected, that kind of thing)? Whatamidoing (WMF) (talk) 18:00, 17 January 2014 (UTC)
I was on Firefox/Windows 7 last night, and I did not notice any other issues but it was a small page so even a doubling of the time it would take to refresh would be barely noticeable. Risker (talk) 21:02, 17 January 2014 (UTC)
I use Firefox, but I think it is on Windows 7 for the comuter where it happened. The next day, the tab was back. I did not fiddle with any-thing. Kdammers (talk) 05:44, 18 January 2014 (UTC)
I've filed a bug report. Kdammers, if it happens again, please try refreshing the page. I'd like to know whether Risker's solution works for you, too. thanks, Whatamidoing (WMF) (talk) 00:19, 23 January 2014 (UTC)

Visual aspect not always convincing

This is what I see in VE. Nice! However, this is what the reader will see... And no, I didn't create this on purpose, it is the result of a VE copy-paste (which still doesn't work in any useful way generally). Fram (talk) 09:58, 21 January 2014 (UTC)

Please tell me more about how you did this. Does it happen to all images, or only under certain circumstances? Whatamidoing (WMF) (talk) 00:42, 23 January 2014 (UTC)
You probably have to start with a page with strange markup and results, i.e. the kind you get when you use VE copy-paste. In this instance, I copiedCryptid from enwiki to mediawiki, by opening it in VE in enwiki, using "select all" and "copy", and then paste to an empty page on mediawiki in VE again. This is how it looks normally, and this is the result in VE. Note how the images have completely different captions. In the VE version, I then removed everything but the second image, including the "stray" square closing brackets in the text (which weren't stray brackets but an integral part of the image caption). This gave the result reported above. My initial report makes the problem clearer, but the origin is simple copy-paste in VE, and in any case, I don't think there should be any circumstance where VE renders pages correctly, but normal view makes a mess of it (the opposite is also bad, but less so). Fram (talk) 08:18, 23 January 2014 (UTC)

Any update??

Tracked in Phabricator
Task T59209

Hello. I first reported this bug two months ago and still there is no any change about it? It was reported as duplicate but it's not and it was reopened over a month ago! Can someone please inform us what is going on with it? It's a very annoying bug when you need to reuse a reference! Thanks TeamGale 16:53, 20 January 2014 (UTC)

It is not solced yet (not here, not in the latest release in MediaWiki). I have reopened the issue a month ago, but nothing has happend since then (not an acknowledgment, not a prioritizing, nothing). @Jdforrester (WMF): to see if he has any input. Fram (talk) 17:09, 20 January 2014 (UTC)
Yeah...I know...that's why I am asking...it's really annoying when you want to reuse a reference. Especially if you don't know or forget about the bug and you have to close the reference window to check the number. I was expecting to be fixed till now... TeamGale 23:27, 20 January 2014 (UTC)
The priorities of the WMF devs for VE work in very mysterious ways. And the PR department sucks (if you close a bug as "solved", and it gets reopened, you would expect some reply to that, acknowledging what happened). In other news, bears still shit in the woods. Fram (talk) 07:54, 21 January 2014 (UTC)
Thanks to both of you, I'm adding this to our agenda to hear from James directly. --Elitre (WMF) (talk) 20:01, 22 January 2014 (UTC)
TeamGale, have you tried searching for the ref you want? Just type anything into the box (e.g., author's name or date), and it will filter the list to show only the ones that contain the search string. Also, if the refs are named, then you can see the ref names in light gray on the left (see this screenshot). Whatamidoing (WMF) (talk) 00:33, 23 January 2014 (UTC)

@Whatamidoing (WMF) I tried but still the only thing I see are the numbers of the references. I took a screenshot of what I see before I type anything and when I do. It DOES filter but STILL...nothing to see. If you don't know the number before you open the reference window, you won't be able to choose the reference you want to use and you are forced to close the window, scroll all over the article to find the reference and then open the window again. Lots of unnecessary work and waste of time!! Personally, still things don't look right for me on the screenshot you attached. Why can't we see the whole reference as we were able to do about 2+ months ago?? Anyway...here is the screenshot. Hope it helps and this issue gets fixed this time... TeamGale 04:52, 23 January 2014 (UTC)

I've e-mailed James F about this and requested that he assign this bug to someone. The main focus is on language support, so it may be a while before it is resolved. Whatamidoing (WMF) (talk) 19:24, 23 January 2014 (UTC)

span bug

Tracked in Phabricator
Task T62375

<span about="g0.674951691491155" data-ve-ignore="true"></span> In this edit, VE added <span about="g0.674951691491155" data-ve-ignore="true"></span> after one of the {{convert}} templates I added. I do not know what is different about this section. (Monobook, Firefox 26, Windows 7):Jay8g [V•T•E] 01:54, 22 January 2014 (UTC)

I wonder if it is the same VE bug that caused something like this, where you get a very ugly effect and a very, very long ref with things you normally can't change in VE at all (font of refs? Ugh...) Perhaps in this case it is a copy-paste in VE gone wrong (some redundancy in that sentence can't be avoided ;-) ), perhaps it is simply VE going wrong for no good reason... Fram (talk) 13:03, 22 January 2014 (UTC)
And this one? Fram (talk) 13:08, 22 January 2014 (UTC)
And this one... Fram (talk) 13:09, 22 January 2014 (UTC)
Hi User:Jay8g,
Thanks for your note. I need a little more information. Did you happen to copy and paste that template after you added it? Did you at any time see a duplicate of that template (or possibly something that looked like a busted copy)? So far, that's the only way I've been able to reproduce it the span bug myself. If you're certain that you didn't paste the text (even cutting it and pasting it right back in the same spot), then it may be a different bug (possibly the non-breaking space problem, although that's always been in ref names—so far). Whatamidoing (WMF) (talk) 00:50, 23 January 2014 (UTC)
I'm pretty sure I didn't copy and paste. The nbsp issue is possible, as there was a nbsp there before. However, this seems different than the nbsp ref issue:Jay8g [V•T•E] 01:54, 23 January 2014 (UTC)
OK, see this edit, where a similar thing (<span about="g0.42287685585435686" data-ve-ignore="true"></span>) was added when a nbsp was removed. No copy and paste involved:Jay8g [V•T•E] 01:58, 23 January 2014 (UTC)

Whatamidoing: I've been extensively testing this. What triggers the error:

  1. The original example:add template on right then delete nbsp as well as text directly on each side
  2. Also works when reversed:add template on left then delete nbsp as well as text directly on each side. Note this puts the error on the same side as #1
  3. Also works with extra text between template and text with nbsp:Add text to right of text with nbsp, add template, delete nbsp as well as text directly on each side. Note the extra text (in this case spaces) disappears.
  4. Same as #3, with text already there: add a template, delete all text other than template
  5. Same as #4, with extra text not deleted:add a template, just delete nbsp and text directly next to it
  6. Also works with spaces on either side of nbsp:same as #1
  7. Also works when just deleting nbsp:same as #1 but just deleting the nbsp

Doesn't trigger:

  1. Not adding template or adding anything other than a template
  2. nbsp on its own line
  3. Delete then add template

The pattern seems to be: add a template and delete the nbsp and the error shows up:Jay8g [V•T•E] 03:07, 23 January 2014 (UTC)

It also works when I do something else between adding the template and deleting the nbsp, but not if the nbsp is on a different line then the added template. Therefore, if, in one edit, one adds a template on the same line as a nbsp and then deletes the nbsp, a <span about="g0.[a long number]" data-ve-ignore="true"> is added.:Jay8g [V•T•E] 03:48, 23 January 2014 (UTC)

This is awesome. Thanks.
I did some testing in my sandbox (without saving) using this string: 1&nbsp;mg 2&nbsp;mg 3&nbsp;mg 4&nbsp;mg and I ran across an unexpected difference. I can add a tempate to "3 mg" and remove the nbsp from "2 mg" or "4 mg" without generating any span tags. I only get the error if the template is next to the 'word' that I'm removing the nbsp from. Is that true for you, too? (Feel free to test in my sandbox if you want; there's a section for nbsp's.) Whatamidoing (WMF) (talk) 19:56, 23 January 2014 (UTC)
Whatamidoing:Same here. Interesting, as this would imply that it should trigger the error anyway. I can't figure out the difference:Jay8g [V•T•E] 23:18, 23 January 2014 (UTC)
Whatamidoing:Now I got the error again-without a nbsp: see here (the second one, under Operations). This time, I replaced 2 {{convert}}s with one. I do not know what happened this time:Jay8g [V•T•E] 00:33, 24 January 2014 (UTC)
When I added some plain text to my test, I got the same results that you produced in your sandbox. I think it only affects the nbsp that is closest to (in front of) the template.
The convert template is probably the same bug, because the template will use nbsp's for output. I'll add that to the bug report. Whatamidoing (WMF) (talk) 16:26, 24 January 2014 (UTC)
Oh. I see. I never thought about nbsps in the template:Jay8g [V•T•E] 18:07, 24 January 2014 (UTC)

Getting back to basics

All wikipedia edits are composed of four actions

  • Changing some text
  • Adding a reference
  • Completing an edit summary
  • Saving

It is too easy to concentrate on the first and fourth- omitting the two important ones. (Essential for example on medical articles)

In certain edits I have found on my watchlist- the edit summary is a Edited by ve tag, giving me no idea of the editors intention- examining the edit, there is text but no reference- so the only course of action is to revert it. Bit silly really. If the edit process is changed slightly, so the text change is not saved until a reference has been added or reviewed AND an edit summary completed, we have a viable four-action-edit.

The next problem I am seeing is that when ve adds some code to a well referenced article which is using the now standard {{sfn}} system, that if a reference is added it is in a different format:it doesn't follow the style of the existing article, so has to be manually changed.

A third problem is that transclusion is a silly artificial word that you and I can use with alacrity- but average readers haven't clue what it means. We are putting in unnecessary hurdles for the new editor.

-- Clem Rutter (talk) 00:47, 27 January 2014 (UTC)

But many edits - including the vast majority of my own - do not require the addition of a reference:
  • Stub-sorting
  • Adding categories
  • Adding DEFAULTSORT
  • Fixing typos
  • Adding hatnotes
  • Tagging for various problems
  • Rearranging garbled text into clear English
  • etc etc.
So any mechanism which insisted on addition of a reference would make VE unusable for many editors. (For me it's unusable anyway until the window in which one adds tags and categories ceases to hide the entire article content from which one would be deriving them, so I'm not using it at present.)
I'd be happy to see addition of an edit summary made mandatory, but that isn't just a VE question: I suspect it's listed somewhere under "Perennial proposals". And if it's made technically required, there's nothing to stop an editor just adding "x" or rubbish characters if they can't be bothered to give a proper edit summary.
I quite agree that "Transclusion" is a dreadful term and should be avoided if at all possible.
"the now standard {{sfn}} system"? Not in the articles I most often see - mostly stubs to sort. There's perhaps a gulf appearing between the basically-sourced mass of articles (where we're lucky if we can get one or two reliable sources cited in any clear way) and the {{sfn}}-referenced GAs, FAs and other substantial articles. VE needs to help editors of all articles. PamD 08:30, 27 January 2014 (UTC)
I am glad you added that list. Sure, I was pushing the boundary with suggesting mandatory refs. There is overlap- <ref> Housekeeping tasks per PamD list </ref> appeals, were we to make it mandatory. More likely, is to make references compulsory iff the edit summary fails to contains one a word from a whitelist. This can be tweaked to include other editors preferences. I want to keep design separate from implementation- but code bunnies will delight in using drop down list, then the imperative is leaving the control of the contents of the whitelist to editors on individual wikis and not the coding team. I can see no reason why edit summaries are not mandatory, you can zap a vandal quicker if they add rubbish to the edit summary. -- Clem Rutter (talk) 21:21, 27 January 2014 (UTC)
  • Whether to prompt for or require edit summaries has been listed at WP:PEREN since a few days after its creation in 2006. If you can't get community consensus for it, then I don't think that the WMF is going to even consider the technological changes necessary.
  • {{sfn}} is used on almost one out of every 205 (two hundred five, that's not a typo) articles. That's probably not best described as "standard". But VisualEditor does support it, as you can see here. The only difference is, just like you have to deliberately type {{sfn}} rather than <ref>, you have to deliberately add the sfn template rather than a (truly) standard ref tag. Also, if you add multiple refs during a single editing session, all of them are displayed inline as "[1]". The numbering is correct when you save the page.
  • (Purely unofficially) I hear that WP:PRESERVE has some suggestions about how to handle the addition of unsourced material that don't involve reverting it as the "only course of action". If you don't think that reverting unsourced material is ultimately in the best interest of the project, then you might consider the alternatives there. Whatamidoing (WMF) (talk) 23:04, 27 January 2014 (UTC)

References

Bug report VisualEditor
Mito.money Please app{}
Intention: Make a fairly simple copy edit.
Steps to Reproduce: I made a few unrelated changes to the fix paragraph, which were unaffected, and then tried to swap two sentences using copy-paste. I was sure not to use markup in the VE.

No attempt made to reproduce.

Results: VE broke the ref and rendered the wikilinks in markup as URLs - see this revision
Expectations: Doesn't matter if a ref is invoked after it is first used, so should work.
Page where the issue occurs
Web browser Chrome v.31
Operating system Windows 7
Skin Vector
Notes:
Workaround or suggested solution

Jamesx12345 10:47, 26 January 2014 (UTC)

Hi James,
I believe that the busted link problem ([[Link]] turning into [[https://en.wikipedia.wiki/Link Link]]) will be fixed on Thursday.
For the refs, I notice in the diff that it turned currently the tallest sea stack in Britain.<ref>{{harvnb|Seward|2011|p=230}}</ref><ref name=wlg/> into the tallest sea stack in Britain.<ref /><ref />. I assume this was part of the text you copied and pasted. Did you have any other problems? Did you happen to see an error message along the lines of ""Cite error: The opening ref tag is malformed or has a bad name"? Whatamidoing (WMF) (talk) 23:25, 27 January 2014 (UTC)
I didn't get any error messages when editing, it was only when I saved that I got the error. I can't quite make out exactly what I did, but it did involve copy-pasting some refs. Thanks for the response. Jamesx12345 16:06, 28 January 2014 (UTC)

References list

Tracked in Phabricator
Task T62361

A request about the references list if it can happen. When someone uses the reference list for an article (<references />), while using VE they can see any changes/edits/additions of references at the end of the page where is the list. But if the template {{reflist}} is used, the changes are not visible. Is it possible to make both ways useful for VE and not only the first one? Thanks TeamGale 17:00, 20 January 2014 (UTC)

This sounds like one of those ideas that turns out to be complicated, but it's a good idea, so I'll file the enhancement request. Maybe we'll get it! Whatamidoing (WMF) (talk) 00:35, 23 January 2014 (UTC)
And we have a response: "can't be done". Whatamidoing (WMF) (talk) 05:53, 25 January 2014 (UTC)
@Whatamidoing (WMF) Sorry I missed your answer...I just saw it and the answer on the bug and I don't really understand why. A "it can't be done because that's one of the (many) reasons we discourage people from using it" is not an answer!!! Why? How exactly is by not doing that request will discourage people from using it? The majority of people is not using VE and prefer to use the template than the list. Personally I use the list and I tried to change it in some articles I edit but every time I did it, people change it back! I won't get in fight or start reverting because of that. If the template is that bad and WMF people don't want users to use it, why is it even exist? I am sure you all know in how many articles it is already used! Are WMF people intent to change it in all these articles and disactivate the template? I am sorry but, I just don't get it. People will keep using it either the WMF do the request or not. It won't stop them simple because they don't care or even more simpler, because they don't use VE and it's not a problem for them! It only makes the lives of the rest (few) of us who use the VE harder. Not to mention to a totally new user who tries VE in an old article with the template and they won't understand why they don't see the references updated while they edit! I don't think I was asking too much when I made the request and the answer didn't convince me of why not. I wish I could get a better and more detailed answer of why but what can I say..? Have a nice day and thanks TeamGale 18:45, 27 January 2014 (UTC)
I concur. This is a confusing response. {{reflist}} is used all over the place, often by preference.
A blank "wontfix" doesn't address the reasons for this statement, and they do in fact need addressing. Are you planning to systematically remove {{reflist}}, for example? If not, do you just plan to leave it broken in the hope people will stop using it? Clarification is needed on this point. - David Gerard (talk) 20:17, 27 January 2014 (UTC)
Exactly! If WMF think that by not fixing it will encourage people not to use it they are wrong. Fixed or not, people WILL keep using the template! Especially in articles with lots of references is used by preference because they can make columns while that is something you can't do with the list. I hope we'll get (?) a clearer answer to that. Thanks David Gerard for commenting at the bugzilla as well. TeamGale 20:51, 27 January 2014 (UTC)

For those who haven't read Bug 60361, this is why it won't be fixed: 

(In reply to comment #0)
> Intention:
> <References /> automatically updates as you edit a page.  The {{Reflist}}
> template does not.  Can the handling of the template be improved so that refs
> inside the {{ref list}} template also update automatically?

Unfortunately, no, we can't.

This is one of the (many) reasons why we discourage people from using {{Reflist}}.

No disrespect intended to Jdforrester (WMF), but if there are "many reasons why we discourage people from using {{Reflist}}", shouldn't this be mentioned in its template docs, so that it doesn't become too popular with the uninitiated? The current level of "discouragement" might not be sufficient, given that the template is currently being used on over 2.9 million pages. - Pointillist (talk) 21:31, 27 January 2014 (UTC)

That's a pretty daft reply from jdforrester ("many reasons", what are the others?) but the fundamental problem the VE developers have is that they got the architecture wrong from the off, but can't now admit that. So there are many things that ought to be fixed but now can't. Eric Corbett 21:42, 27 January 2014 (UTC)
It is really beyond belief that anyone should have started coding this thing without researching the way that Wikipedia is used now. Referencing in the main now uses four templates {{reflist}}, {{notelist}}, {{sfn}} and {{efn}} one needs to understand the quaint <ref> system for legacy editing. But <references/> tag is history. Staffers may wish to discourage modern editing- but the function of this beta kit is to support it. -- Clem Rutter (talk) 22:22, 27 January 2014 (UTC)
Don't let's forget LDR and the associated {{r}} template. Is that also to be deprecated by the WMF because VE is deficient? Eric Corbett 22:57, 27 January 2014 (UTC)
You can already use {{r}} in VisualEditor; see this example. Whatamidoing (WMF) (talk) 23:14, 27 January 2014 (UTC)
Are we speaking the same language? That's not at all what I'm talking about, added to which your example seems to depend on the "deprecated" {{reflist}} template. Eric Corbett 00:18, 28 January 2014 (UTC)
My example is copied straight out of the documentation for {{r}}, so I think it reasonable for me to assume that it is a core use case. Whatamidoing (WMF) (talk) 17:03, 28 January 2014 (UTC)
Be that as it may, your example depends on "reflist", so it is hardly convincing in this discussion. Can you use "r" with "references" instead of "reflist"? No? Then that's one more reason not to deprecate or discourage "reflist", but to search for ways to better integrate it with VE. Fram (talk) 07:48, 29 January 2014 (UTC)
I don't know what the other reasons are, but I don't see why they would be relevant. Reflist is an extremely popular template here at en.wp (but not most other projects—Polish has something similar, and perhaps a few others?), largely because of its column settings. I doubt that the WMF would forcibly remove it. James F is pushing for the WMF devs to expand <references /> to support column formatting, so that the main benefit would be available to all projects and all pages, not just those using this template. When the template was used only for columns, or not used even for that, then reading pages using <references /> would be marginally faster, too, and have the same end result, so it would make sense to swap out the template. If that improvement were made, then the VisualEdtor issue would be solved as a fortunate side effect on most pages.
The important point to notice is that James F said "can't", which is not a word that he uses as a synonym for "it's technologically possible, but I refuse to". There is presumably no (reasonable/non-crashing/non-locking-up-your-computer) method of actually doing this in VisualEditor.
Clem, as a point of fact, VisualEditor "supports" the reflist template just like any other normal template. What it doesn't do is refresh the display of that template hundreds of times during an editing session, so that it will always show the current information. (Neither does the wikitext editor, which doesn't update anythingas you edit, or even display refs at all if you're editing a section.) Whatamidoing (WMF) (talk) 22:27, 27 January 2014 (UTC)
@Whatamidoing (WMF) So this can't be done technologically? That's why WMF people can't do it? If that's the case then I (and probably lots of others) got the "can't do it" wrong. Because it came out like the WMF team was refusing to do it. And still it's not clear since you said "There is presumably no (reasonable/non-crashing/non-locking-up-your-computer) method of actually doing this in VisualEditor" which means you don't know for sure either why they can't do it. I am sorry but I am just trying to understand here. James F is pushing for the list to be able to use columns like the template so people would choose to use that instead of the template. Pushing for that is a good thing but, personally, I doubt that people will start using the list more even then. But let's say that they will...what happens with all the articles that already have the template? I am sure you don't expect users to start changing those one by one...right? Anyway...that's really confusing at the moment as it is and it will still be in the future. Thanks for answering. I guess we'll have to wait for the updated version of the list but still...I wish the original request of this post could be done. It would be easier for editors that way. TeamGale 07:11, 29 January 2014 (UTC)
The question asked in the bug was "Can the handling of the template be improved so that refs inside the

template also update automatically?". The answer was "Unfortunately, no, we can't." I don't know why people have misunderstood this simple response. If someone asked you, "Can you do this reasonable thing?" and you said, "Unfortunately, no, I can't", wouldn't you expect the person to understand that you wished it were different ("unfortunately") but in reality you are unable to do so ("can't")?

I have no idea what the community here would do if James F's proposal turns into reality. Perhaps someone would say that it's wonderful to have an option that's less likely to hit the transclusion limits and displays pages very slightly faster for most of us (but perhaps an important difference for people using mobile or on a slow internet connection), and therefore decide to make the substitution (for pages using zero of the template's features) be an AWB fix, on par with correcting the order of the hatnotes and maintenance tags. Or perhaps they'd prefer to leave it alone. The answer might even change over time. After all, the reason isn't being used has changed over time: when I was new, we used the reflist template primarily to change the size of the font. In the first iteration of that template, changing the font size is the only thing that it did. Whatamidoing (WMF) (talk) 23:00, 29 January 2014 (UTC)
You could provide a "preview" button, so that editors can request a refresh. Then again, reflist doesn't even display properly when inserted (when you would suppose that a "refresh" is done anyway), so I think the problem is more serious than just a need to refresh. Still, thanks for giving yet another reason to dislike VE. Fram (talk) 08:35, 28 January 2014 (UTC)
I've entered your idea as T62535. Whatamidoing (WMF) (talk) 17:03, 28 January 2014 (UTC)

VE tab missing again

Tracked in Phabricator
Task T62359

I am using Mozilla on IE 7. I checked my settings: VE is checked. How-ever, the VE tab is not showing. Kdammers (talk) 08:20, 28 January 2014 (UTC)

I'm not getting VE loading, the 'progress bar' just keeps running. I'm Chrome on XP and I had the same problem last night with Chrome on Windows 7. Edgepedia (talk) 12:24, 28 January 2014 (UTC)
Yes, i meant Windows 7 (I can't keep all the MS names straight.) And I still have no VE tap showing. Kdammers (talk) 06:25, 29 January 2014 (UTC)
And suddenly it is back again. Kdammers (talk) 07:06, 29 January 2014 (UTC)
I've made a note. The assumption is that it's a JavaScript transmission problem. Whatamidoing (WMF) (talk) 23:23, 29 January 2014 (UTC)

Visual Editor in other language versions

For fun, I tested random articles in other Wikipedia language versions (all tests FF26 on W7).

  • General remark: lots of translations still need to be done for VE elements.
  • Cebuano: I couldn't get any article to open in VE, I tried [3] and tried [4] and tried [5] and tried even the simplest of articles[6]... The "Edit source" (sic!) worked perfectly[7]. Fram (talk) 15:52, 29 January 2014 (UTC)
There appears to be a bad edit comment in ceb.wiki's common.js that is stopping VE from loading. I've asked a local admin to fix this. Thank you for the heads up, PEarley (WMF) (talk) 18:37, 29 January 2014 (UTC)

Perhaps you can check all wikiversions where VE has been claimed to be deployed? The same problem (perhaps a different cause, but the same result) happens at the "map-bms" (Basa Banyumasan) wiki ([8],[9]). I'm not going to test all versions for you though. Perhaps the WMF can check whether VE actually works at the wiki-versions where they have deployed it? I'm not asking to do any actual editing tests (far from it), just establishing that it works? Makes one wonder how eagerly these versions were awaited of course... Fram (talk) 11:17, 30 January 2014 (UTC)

I suspect some of these languages aren't eagerly waiting for much. :/ [10]. It's kind of depressing going to some of the little wikis and finding mostly "small wiki patrollers" and global userpage additions. With software as customizable as MediaWiki, it seems inevitable that some local communities will have made changes that can unexpectedly impact future software deployments. (In the ceb case, it was this, evidently; no idea what the problem is with map-bms. Something similar? Completely different? Somebody techy will work it out. :))
I appreciate your finding the issues. We have, of course, asked all of the projects where VisualEditor is deployed to let us know if there are problems, but while some of them are active and communicative, some of them are really not. :/ Given that, I agree it seems like a good idea to check the smaller projects. --Maggie Dennis (WMF) (talk) 13:09, 30 January 2014 (UTC)

Nothing much happens

Resolved

Bug report VisualEditor
Mito.money Please app{}
Intention: Trying out visual editor again. Same thing happened when I last tried it months ago.
Steps to Reproduce: # enabled VisualEditor in preferences
  1. go to any page I want to edit
  2. click edit beta tag
Results: a horizontal, animated loading bar starts up at the top right. The text in the article fades to grey.
Expectations: I was hoping to be able to edit text, but nothing seems to happen. The animated bar keeps pulsing.
Page where the issue occurs
Web browser Firefox 26.0 and Chrome 32.0.1700.102 m
Operating system Windows xp
Skin Vector
Notes: My guess is either some general setting on my PC (security maybe?) or sluggish internet connection
Workaround or suggested solution

Derek Andrews (talk) 00:25, 30 January 2014 (UTC)

  • I'd been having this problem for a few days. Weird, same at work as at home. Then I remembered I'd add importScript('User:GregU/dashes.js') to my vector.js page; just removed it and it's back again. Edgepedia (talk) 21:19, 30 January 2014 (UTC)
    • Bingo! I found two lines of code in my js page. window.popupFixDabs = true; window.popupFixDabsSummary = disambiguating %s → %s; Deleted them and VE now works. Thank you. Only problem is I can't remember what this script did. Guess I will find out when something else doesn't work. --Derek Andrews (talk) 01:05, 31 January 2014 (UTC)

VisualEditor does not get math render properly when exiting

Tracked in Phabricator
Task T62728

I have edited Thermal_conduction#Integral_form, when I saved the edit the VisualEditor did not exit correctly. All math was displayed in plain text. (I set math display to MathJax). Gryllida (talk) 00:19, 28 January 2014 (UTC)

(mw:Special:MyLanguage/VisualEditor/Beta_Features/Formulae was also enabled on my account during the problematic exit.) --Gryllida (talk) 00:22, 28 January 2014 (UTC)

It works fine for me. Which browser are you using, I;m using chrome on a mac. Does the test page on mediawiki work? [11] --Salix alba (talk): 11:25, 28 January 2014 (UTC)

Salix alba, Firefox on Windows 7 or Linux. Only with PNG rendering (not with MathJax). --Gryllida (talk) 12:56, 28 January 2014 (UTC)

By the way, I have VisualEditor formulae editing disabled at MediaWiki, so it's not its fault. --Gryllida (talk) 12:59, 28 January 2014 (UTC)

I think you need to refresh the page after finishing with visual editor. There is a bug that when visual editor finishes after a save it does not rerun the javascript on the page. This affects the MathJax renderer, which uses a lot of javascript. Just press refresh/reload in your browsers and things should be fine.--Salix alba (talk): 16:47, 28 January 2014 (UTC)
It's possible that this will magically be resolved on Thursday as a result of the patch for T50560 reaching the Wikipedias. It would be very helpful if you could test it in a few days and let me know whether it really has been fixed. Whatamidoing (WMF) (talk) 17:27, 28 January 2014 (UTC)
WhatamidoingI will test on Friday. Is the expected change already live at test.wikipedia.org? --Gryllida (talk) 00:55, 30 January 2014 (UTC)
WhatamidoingIf Whatamidoing didn't already, please give the bug number. --Gryllida (talk) 00:55, 30 January 2014 (UTC)
GryllidaIt's bug 48560. The bug report is about categories, but I think that what they're doing to solve the category problem will also solve the MathJax display problem as a happy side effect. Whatamidoing (WMF) (talk) 01:35, 30 January 2014 (UTC)
Is this supposed to be already live at Test Wikipedia? Thanks. Gryllida (talk) 01:59, 30 January 2014 (UTC)
(Edit conflict) T53565 is the main (closed) bug where the idea of doing a full refresh is quashed in favour of a fancier way which requires all javascript code to implement some obscure method. The specific one for MathJax I think is T38060. Not sure if the rollout will fix this or not. --Salix alba (talk): 01:53, 30 January 2014 (UTC)

Whatamidoing Salix alba It looks like MathJax provides $().renderTex now and it has to be run every time you need to render math (when doing live preview, or when VE exits). Does VE call it when exiting? Gryllida (talk) 01:59, 30 January 2014 (UTC)

I'm really out of my depth here. Maybe @Krinkle: can shed some light on the matter.--Salix alba (talk): 10:44, 30 January 2014 (UTC)


Whatamidoing Salix alba User:KrinkleThe issue persists. --Gryllida (talk) 15:00, 31 January 2014 (UTC)

I've filed T62728 for you. Whatamidoing (WMF) (talk) 19:00, 1 February 2014 (UTC)

Non-breaking spaces

How does one add a non-breaking space ( ) in VE? Fram (talk) 14:52, 30 January 2014 (UTC)

At this time, I believe that can't be done in VisualEditor. If you type in the HTML code, it converts it to &amp;nbsp;. If you type it from your keyboard (option–space on a Mac), it converts it to a regular space (like the wikitext editor). You can use {{spaces}}. Whatamidoing (WMF) (talk) 19:13, 1 February 2014 (UTC)

Success of VE

Is VE used a lot? On fr-wiki (one of the largest to have VE opt-out instead of opt-in), the last 500 edits to article space were made in 30 minutes (11.38 to 12.08). The last 500 edits made with VE? 02.12 to 12.08, or 10 hours instead of 30 minutes. So now the WMF has to maintain and develop two environments, and has used lots of manpower and money on VE, only to have 5% of the edits made with it? This is now, more than 6 months after deployment. Even looking at only the last 100 edits, it took an hour and three minutes to get 100 VE edits, and only 6 minutes for all edits. That still indicates that perhaps 10% of the edits are made using VE. Can the WMF please provide some figures for, let's say, the 10 or 20 largest wiki-versions, with the percentage of VE edits compared to all edits to the mainspace? And perhaps an indication of growth (if any) over the past half year? Fram (talk) 11:17, 30 January 2014 (UTC)

As you know, VE isn't finished, so it's difficult to say how use will compare when mature. :) I'll pass along your request for data from analytics, but I don't know if they will be able to schedule it at this time since, of course, they've already got assignments they're working on. (Added: Scheduled to ask about this next meeting, early next week.) --Maggie Dennis (WMF) (talk) 12:36, 30 January 2014 (UTC)
Thanks. Of course we can't know how usage will be when mature, but if e.g. the number of users or edits made with it is decreasing in different wikis, then perhaps it is time to reconsider whether it is worth the effort. Throwing time, money and people into something that is getting more and more success may be acceptable; doing the same for something that has less and less success seems less acceptable. If none of the improvements of the last 6 months have made any changes, then why bother? Try to find out what, if anything, would convince the editors that don't use VE to make the switch to it. If there is for most people nothing that would convince them, then don't waste your time on VE anymore. If you get an indication that people are willing to change once X, Y and Z are (properly, not superficially) working, then develop X, Y and Z, test them somewhere, and then deploy VE version 2.0 so that people get the idea that you have listened and made a serious effort to make what they want and need. The current approach doesn't seem to work, so why continue with it? Fram (talk) 12:57, 30 January 2014 (UTC)
Sounds useful, but difficult: how do you find the people not using VE, but who know anything much about it, to ask them why they aren't? A few are still watchlisting this page (well, I am, anyway), and for me the current sticking point is T51969 which I raised as soon as I tried VE in June last year. Until I can see the content of the article while I'm editing categories and templates, by shrinking or moving the dialogue box, it's not fit for (my) purpose. (For a good few weeks I used VE a lot, was complimented on the usefulness of my bug reports, etc. Then I just got too dispirited by it all and gave up.) PamD 13:27, 30 January 2014 (UTC)
I think you've identified a big part of the challenge, Pam. X, Y and Z are not the same for every editor and certainly not for every project. (You know how hard it is to get consensus on English Wikipedia for major changes; imagine doing that with core software for several hundred Wikipedias. :)) James Forrester and 4 liaisons (with some substantial loan time from community advocacy) are trying to make sure that the engineers assigned to VE create a software that is as useful as possible for an incredibly broad user base.
Fram, another issue is in defining success. The intention of VE isn't just to serve the people who are editing now, who would have to make the switch, but to serve the people who might edit for the first time tomorrow or the day after - the people who don't already know wiki code but would like to help out. While VE is meant to serve new users as well as existing editors, the input of existing editors is crucial to helping develop a tool that works in the environments they have. (I use the plural deliberately - Wikipedias have many commonalities but also some surprising differences.) Ideally, by the time we finish, we'll have a product that will make both groups happy.
This has been challenging, obviously, for a number of reasons - including that we (by which I mean all of us - volunteers, staff, everybody) have never done this on this scale before. It's been bumpy, and I'm sure could have been handled better by all involved at different points.
Pam, your experience highlights for me a problem that I don't yet know how to solve. :( I'm not a bug wrangler, but I can imagine that figuring out what fixes/enhancements to implement when is pretty complex and might include considering factors like how many people it serves and how it impacts existing (or planned) features, as well as what the source of the problem is. I suspect that part of the problem is that Bugzilla, which works so well to focus on individual issues, isn't really very good at giving a global picture of development plans. We haven't nailed the communication thing yet. I'm so sorry you were dispirited by the experience.
Hopefully, we'll improve the approach as we learn what works and what doesn't. That's my goal, anyway. I'm not an engineer, but in my own role as a "community advocate", I'm trying to help develop systems of community collaboration that are as successful and smooth as possible. I don't know if you [plural] pay attention to the hiring at WMF, but there's a call for a director of community engagement for product, and I know that making the collaborative process better is itself a major WMF goal. --Maggie Dennis (WMF) (talk) 14:23, 30 January 2014 (UTC)
I'll not comment on WMF-community interaction and the like here, my opinion on this is known. I agree that VE should be both for new and established editors, but if it was really what editors wanted, we would see a steady rise of users (xcluding first-month flurry of "let's try this once" editors), with people who use it continuing to use it, and new users arriving every day (I'm only talking about the large wikipedias here). If, on the contrary, the number of editors using it declines month after month, and e.g. newly registered editors are using it less than IPs, then it would seem that it isn't appealing to new editors either. At the moment, we, and the WMF, don't know, even though it would seem wise to re-evaluate if the money (etc.) spent on this is money down the drain or not. Fram (talk) 14:32, 30 January 2014 (UTC)
It's also complicated in another way: if you want to make a minor change, and it takes you multiple edits to do that in wikitext, but only one in VisualEditor, the number of edits declines, but the same work gets done. For example, I accidentally created an unpaired bracket the other day: that produced my content edit, BracketBot's warning, and the repair. In VisualEditor, the change would have been one edit. (I didn't use VisualEditor because I wanted a specific ref name, which VisualEditor doesn't currently support.) Whatamidoing (WMF) (talk) 19:09, 1 February 2014 (UTC)
Personally I think VE has got a lot better recently. The speed is now good for reasonable size pages and for a certain class of edits its sometimes easier than the wikitext editor. I would say its getting closer to a level where a rollout could be considered.
You can see some stats on the dashboard. The stats tend to reflect how hard the relative communities have campaigned against VE so en and de are < 1% but fr has about 30% for anons, 20% for new registered users and 2-3% for existing registered users.--Salix alba (talk): 13:32, 30 January 2014 (UTC)
Thanks. Fram (talk) 13:57, 30 January 2014 (UTC)

The direct links to stats for VE:

Interesting. --Atlasowa (talk) 21:57, 1 February 2014 (UTC)

VisualEditor is clumsy when editing sections

When I click 'Edit' next to a section, similarly to editing own message in Flow, I expect VE to convert only one section to an edit box, not the entire article. --Gryllida (talk) 22:46, 31 January 2014 (UTC)

Hi, Gryllida. That would seem to be a natural expectation. :) Currently, VE is intended to work differently, it seems. James talked about section editing at the recent office hour, and he said there that he believed section editing would slow VE down. They're working on resolving latency issues in other ways. You can read the full conversation at m:IRC office hours/Office hours 2014-01-22. --Maggie Dennis (WMF) (talk) 14:57, 1 February 2014 (UTC)
Gryllida, one of the questions that interests me is why people want to have access only to one section. The two main reasons people have given in the past are that they believe it would be faster (in VisualEditor, it would actually be slower) or that it's just too much to look at everything, so they're choosing section editing to provide themselves with a little focus. Your reasons might be different, of course, and I would be happy to hear your thoughts on the matter. Whatamidoing (WMF) (talk) 19:48, 1 February 2014 (UTC)
If indeed it would be slower in VE to edit a section rather than the whole article, does that not suggest something to you about the flawed architecture of the product? As to why someone might want to edit only a section rather than the whole article, the potential for reducing edit conflicts springs to mind. Eric Corbett 22:20, 1 February 2014 (UTC)
I asked about that a few months ago, and I was told that section editing hasn't helped with edit conflicts for about seven or eight years now. Apparently, in 2005, MediaWiki wasn't smart enough to handle you editing the first paragraph and me editing the last, but since about 2006 or 2007, it's handled all of that automatically no matter how you edit the page. WhatamIdoing (talk) 03:54, 2 February 2014 (UTC)
Among other answers when this subject was first brought up several months ago, there was also the fact that editing the entire article also means sending the entire article back when you have finished your edit. When you have a slow connection, especially with a small up bandwidth, saving then becomes very difficult or impossible. --NicoV (Talk on frwiki) 21:00, 2 February 2014 (UTC)

Disable Media Resize

How can I disable media resize in VisualEditor? — Preceding unsigned comment added by Xprmnt (talk • contribs) 15:59, 30 January 2014 (UTC)

You can't, sorry. It's one of the worst ideas the VE developers had (apart from, well, implementing VE and using their version of an "agile" approach). Fram (talk) 08:08, 31 January 2014 (UTC)
Hi Xprmnt,
Images are only resized if you click on them and drag them to a different size. However, they aren't displaying at their normal size within VisualEditor if the size is not defined. They are currently displaying at the MediaWiki default (180px) rather than the local default (which is 220px at both the English and Russian Wikipedias). So if you edit a page with a fixed image size (e.g., Hong Kong new year marches) it looks normal, but if you edit a page with the default size (e.g., USS Constellation vs La Vengeance#Aftermath) then it looks small. The size is not actually changed, though, and it will display correctly when you save or read the page. Whatamidoing (WMF) (talk) 19:21, 1 February 2014 (UTC)

I understand that size of image is not really changing. I understand that I can't disable media resize in panel. I ask about how can i disable it with code, delete lines of codes maybe? change something in script. — Preceding unsigned comment added by Xprmnt (talk • contribs) 20:39, 2 February 2014 (UTC)

I still don't know which of the two things you're trying to disable:
  1. your ability to really change the size of an image on the article, or
  2. the way that VisualEditor displays the images at the wrong size.
It might be possible to do the first, but why would you want to? As for the second, you can't (as far as I can tell), but the devs will. It's T49804. It is not the highest priority bug that has been assigned to that developer, but she will get it done eventually. Whatamidoing (WMF) (talk) 16:07, 3 February 2014 (UTC)

Why does wikimarkup suddenly appear?

Tracked in Phabricator
Task T54036
Tracked in Phabricator
Task T62829
Tracked in Phabricator
Task T62830

Start from an "empty" page (it contains some hidden comments, but since you can't remove these with VE...): [12].

Start a simple article in the normal way, with a header and some text.[13]

Now reopen that page in VE: [14] Hey presto, I get == Test == instead of the actual header appearance, due to the invisible and unremovable hidden comments.

Funny, how we are not allowed by the WMF Devs (@Eloquence:) to use wikimarkup (even though it is technically perfectly acceptable, and you need to use it in Templates or the new and utterly useless Gallery editor), but thanks to their unending stream of "incomplete features" (sic), we get to see it anyway. You can now create things like this, but don't you dare to actually type something like that, such a thing is unacceptable. Thanks, VE! Fram (talk) 08:40, 31 January 2014 (UTC)

Would you happen to remember the title of an article featuring hidden comments not generated by a bot or included in a template? Thanks. --Elitre (WMF) (talk) 11:18, 4 February 2014 (UTC)
London includes "<!-- Please do not make significant changes to the lead without discussing them first on the article's talk page.-->", though it's such a big article that it's a pain to load ... though I suppose WMF hav rather better computers and connections than I have! PamD 12:16, 4 February 2014 (UTC)
Thanks. Yes, many of our most prominent or popular articles contain the same text, e.g. Michael Jackson. Other hidden comments appear at e.g. Barack Obama or Creationism. Fram (talk) 12:40, 4 February 2014 (UTC)
Ok, thank you. Will test more and be back ASAP. --Elitre (WMF) (talk) 13:23, 4 February 2014 (UTC)
So, in the beginning, there was a bug about the inability to remove comments even when blanking a page. Now, we have one about the issue Fram encountered, and a bonus one because I just noticed that protection templates don't get removed when blanking a page. Thanks! --Elitre (WMF) (talk) 15:04, 4 February 2014 (UTC)

IE Support

According to this page, and also Wikipedia:VisualEditor, IE support (later versions) has been "temporarily" unavailable since July 2013. This is getting to the limit of any reasonable interpretation of the word "temporarily". When I asked about it here in July 2013, I was told that "we're probably talking weeks rather than months". Please can you put realistic information about timescales on the relevant project pages. It would be better to say "support for IE will not be available in the foreseeable future", if that is the true situation, rather than keep fuelling expectations for something that is never delivered. 86.160.223.11 (talk) 23:14, 1 February 2014 (UTC)

86.160.223.11, that seems reasonable. I'll bring this up in my meeting on Monday and see what I can find out. Philippe Beaudette, Wikimedia Foundation (talk) 03:48, 2 February 2014 (UTC)
The word temporarily does not appear anywhere on the page at Wikipedia:VisualEditor because we removed it a couple of months ago. The statement at the top of this page was presumably overlooked, and I'll fix it n a moment.
The status is that every time they've fixed the known problems with Internet Explorer, they discover a new set of catastrophic problems. The problems that caused it to be disabled in June were indeed fixed in August, but new problems immediately appeared. Last I heard, in the current version of VisualEditor, you can open a page in IE but you cannot save under any circumstances. Since they've been through this cycle of "fixed the known problems, discovered severe new ones" so many times in the last ten or twelve months, they have given up on providing any estimate for completion. Whatamidoing (WMF) (talk) 16:47, 3 February 2014 (UTC)
Thanks. It's true that it doesn't actually say "temporarily" now on that other page. I got my post slightly mixed up. However, it does encourage the idea that IE support will be forthcoming at some point in the foreseeable future, and I wonder how realistic that actually is. 86.128.2.123 (talk) 21:31, 3 February 2014 (UTC)
I suppose that it depends on what counts as "foreseeable future": is it foreseeable if you know it will happen, or only if you know that it will happen within a given time frame? Whatamidoing (WMF) (talk) 04:15, 4 February 2014 (UTC)
I think that information about VE&IE was put in relevant places in July (or even before) merely to prevent that several people reported as a bug that VE was not working for them, as this was a very common complaint back then and one of the few we already, certainly knew the answer to. --Elitre (WMF) (talk) 10:52, 4 February 2014 (UTC)
Just to confirm, I followed up with James about this yesterday. Whatamidoing accurately reports the status: the known broken pieces are close to being fixed. But we don't know what we don't know, and we don't know how soon those things will be fixed. But it is being actively worked. Philippe Beaudette, Wikimedia Foundation (talk) 18:52, 4 February 2014 (UTC)

VE does rather well sometimes!

In this edit, I wanted to remove a stray apostrophe at the end of an italicised wikilink (which I did by positioning the cursor before the final character in the link and hitting the delete button). When I checked the changes before saving I found that VE had deduced that what I really needed was to add a missing apostrophe to the wiki code terminating the italics. Pretty good stuff! --Mirokado (talk) 22:33, 4 February 2014 (UTC)

Mirokado, thank you for the great comment. I'll pass it along to the team. Philippe Beaudette, Wikimedia Foundation (talk) 08:08, 5 February 2014 (UTC)

Bugzilla

Please learn the people at Bugzilla that being more helpful won't hurt. To take a very recent example, look at comment 10 and 12 at [15]. A user gets understandably very frustrated at the total lack of action regarding a bug.

  • The functionality in itself is fairly important
  • It worked for a short while
  • When it failed, the bug was opened (18 November 2013)
  • It was marked as a duplicate and closed on 25 November 2013
  • Wondering when any action would be taken on this bug, I went to Bugzilla, found that this had been marked as a duplicate incorrectly, and reopened it accordingly.
  • Nothing happened for a month and a half, no apology for closing the bug incorrectly, no appointment of anyone responsible for it, no importance, nothing.
  • After John's frustrated outburst about the bug and the handling of the bug, all he gets is "wrong location, please go somewhere else". How does Aklapper imagine that this will lessen the frustration or help resolve anything?
  • Two days later, it finally dawns on someone that this may be a problem: James Forrester (User:Jdforrester (WMF)) wrote:

"Sorry, this bug got entirely missed. For major regression bugs like this, if they've clearly missed out on immediate triage, please shout out-of-band (e.g. on IRC or the various Feedback pages) as otherwise it's likely to continue to get missed for weeks or even months, as in this case. :-( Assigning. Ed, please fix urgently."

No indication that it was his own fault that this bug was missed, and worse, no indication that this was raised multiple times here, e.g. Wikipedia:VisualEditor/Feedback/Archive 2014 1#Any update?? listed the bug number, my reply to the OP contained a ping for Jdforrester, and two WMF people indicated that they would contact Jdforrester directly about this. Apparently, when he is absent, nothing can be done? Of course, when he is not absent, nothing gets done either, the same issue was raised, with again a Ping to him, in Wikipedia:VisualEditor/Feedback/Archive 2013 13#Old bug still didn't get fixed on December 10 2013, again after another user complained that this remained unsolved.

So, Jdforrester, your "ah I didn't see this, next time use the various feedback pages" is complete and utter bollocks, and the response from Aklapper to John Broughton may be classified in the same group of unwanted and unhelpful replies.

@Philippe (WMF): how much more of this nonsense do we have to accept? How much evidence do you need that when someone's job description reads "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.", it would be nice if occasionally some of these things happen? It is obvious that the VE team doesn't "understand what the community wants and needs" (look e.g. at the character insertor), is not "focussed on the things that matter" (like support for the Book: and Category namespaces, really useful, or a tool to get the full size of an image, top priority!), and is not "engaging with and understood by the community", as evidenced by this bug handling (the last in a long list of failures). Fram (talk) 15:41, 4 February 2014 (UTC)

Hi Fram,
I know you're frustrated. If I didn't know the history, I'd still know from your note that you're frustrated. And I get it, really I do. None of us are thrilled with how this deployment has gone. No doubt we've done some things wrong, and I'm probably personally to blame for some of the decisions. I didn't set the timetable, but I could have pushed back, and I didn't. I am responsible, though, for the CLs and their engagement here, and they have a tough job. So does Jdforrester. I know that you have your differences with him, but I would hope you can admit that it's not an easy job he's doing. I respect him for taking it on, even when he and I disagree. I say all of that to say this: at the risk of sounding trite, which I don't mean, I feel your pain. There's nobody on the team who will look you in the eye and say "we've done it perfectly". Because none of us can honestly say that, me included.
With all that said, though, I want to also say this: I understand your frustration, I know that we haven't always done a great job of explaining things or presenting features, and I apologize for my part in that. We really are working hard to fix these issues.
You asked "How much more of this nonsense do we have to accept?". I hope the answer is "none, because you won't be presented with nonsense", but I'm not gong to promise that, because I've learned - the hard way - to be certain not to promise something I can't deliver. I can tell you that Jdforrester isn't intentionally presenting you with "nonsense", and neither am I, and neither is my team. We're all just people, doing our very best to build features that will make the editing community happy. Sometimes (like with the reference inserter), we appear to be getting closer than other times (gallery inserter, oof. Glad we got some changes deployed there).
The logical next question then, is "so what are you planning to do to fix things?" Here's what I'm going to do: I had a meeting with product yesterday, and they committed to, whenever possible, getting our CLs access to the product in order to write documentation early, so that we can hopefully release documentation (including both what a feature SHOULD do and what it DOES NOW) at the same time as we release the feature. And I've got a standard set of questions that I'm going to ask them, and I'll share the answers with my team - who will share them with the community. Those questions include "What is the purpose of the feature?, what works?, what doesn't?, and at what stage in the development life cycle is the feature?" I hope that clear messaging will relieve some of the pressure and tension that we're experiencing and give you a better sense of what to expect.
I notice, though that there's something we haven't said to you... thank you. Your bug reports really are helpful. I don't always love the tone in which they're presented, but I do love that you're finding and helping to debug things. I know you're working in good faith, and I hope you know that I am too. So I appreciate the bug reports, and all the time and energy you've put into helping make this product good. I'm sorry that we're disappointing you. I hope that changes. But in the meantime, know that whether you continue to engage with us on this or not, I appreciate the time and work you've put into it so far.
I know that there are those in the community who will dismiss this note as more platitudes, or accuse me of pandering: I don't really care. It's honest, it's sincere, and I hope you can see that.
Best, Philippe Beaudette, Wikimedia Foundation (talk) 08:41, 5 February 2014 (UTC)
Thanks for the lengthy reply. I hope that it will mean a change in reality as well. I have seen to many promises to blindly believe it, but hope springs eternal. Fram (talk) 08:48, 5 February 2014 (UTC)
@Philippe (WMF): And, after having been indef blocked from Bugzilla, I now have been blocked for the second time at MediaWiki, for daring to point out that Jasper Deng was being extremely arrogant. [16] Good job, I guess the improvements need some time to reach all people at WMF. Fram (talk) 09:02, 5 February 2014 (UTC)

Questions for the WMF

Some general questions, not related to one specific problem or subtool. Depending on the responses to some questions may other questions become irrelevant of course.

  1. When will a general review of VE happen? With review, I mean "Is the effort worth the result in terms of people using it?" At some moment (or preferably on a regular basis), the WMF has to decide where to use its money and people. VE has been in develoment for what, a few years now, and in production for more than 6 months, so some conclusions can certainly already be made.
  2. When will a review of the approach to VE be made (let's call it "agile" for the sake of this discussion)? Is it the right approach, in terms of cost-effectiveness, making fast improvements with the least disruption, and so on? Or do we need to abandon the agile approach completely, or adjust it (e.g. agile to MediaWiki, but slower beyond)?
  3. When will a review of the communication happen? Complaints were made by WMF people that the notes they drop in newsletters and so on are ignored. Is anything being done to research and correct this, to find other means to reach the right people at the right time?
  4. WMF communications are now unchangeable. Even when e.g. an error is found in a status update on Mediawiki, no corrections are made to either that status or to the subsequent weekly and monthly updates.
  5. Testing has been a problem child from the very start, and it still, despite the alleged hiring of a QA team, doesn't seem to have improved. When and how will this be reviewed and improved?
  6. When will the WMF decide what the status of wikitext in VE will be? At the moment, it is forbidden in normal editing (even though it pops up at random anyway), but required for things like templates, galleries, edit summaries, ... This makes no sense.
  7. Will any improvements that have been made for VE but could be useful for normal wikitext editing as well, be made available for wikitext editing? I'm thinking about e.g. the media input selector, where you can see the file you want to insert. Is Wikitext editing still being developed by the WMF?
  8. The WMF is in many ways a black box. No trace can often be found of discussions, analyses, testing, product requirements, and so on. This is rather strange and sad for a wiki-supporting foundation. Even if not everything is made editable, a lot could be made readable so that we can judge what deliberations have been made, which things have been taken into account, and so on. Input could be asked before anything is being developed or before things are deployed.

More questions welcome of course, these are just a few I thought about now. Fram (talk) 13:16, 4 February 2014 (UTC)

Oh, one more:

9. Why does the WMF repeat many of the mistakes they made with VisualEditor again with Flow? Its deployment to enwiki is extremely premature, as was said repeatedly at MediaWiki. We were told many times that it wouldn't be deployed until a minimal set of requirements was reached, but in the end this has been completely ignored. Fram (talk) 14:45, 4 February 2014 (UTC)
(1) Review of VE happens constantly, but I believe that the high level considerations that you're talking about take place in its quarterly review. I'll verify. (Edited to add: Yes, this happens at the quarterly review and also at the Board's annual planning.)
(2) While this is regularly discussed, I expect that a thorough review of community engagement strategies will take place when the Director of Community Engagement (Product) position is filled.
(3) This is also an ongoing discussion and will certainly also be a major focus of the DCE(P), once hired.
(4) If you're talking about mw:VisualEditor/status, that's an archive of announcements. Changing the record there makes the archive of what was announced incorrect. If there is incorrect information in those reports that is making its way forward into tech reports, that's a problem that User:Guillom might have some ideas for handling. He is the Technical Communications Manager.
(5) I'll see if I can find something out. I don't know how the review process works for QA.
(6) I'm told that if a feature requires wikitext to be built, wikitext will be added to build it, ideally following existing conventions, but that for now they are thinking of any feature both in terms of its markup expression and its UI.
(7) Wikitext is open source, of course, so any of the innovations for VE may find their way to wikitext regardless of who does it. In terms of your overall question, I'll have to do some exploration to see what I can find out about that. (Edited to add: The nutshell here is that apparently WMF has done little development of wikitext in years, as its development has been largely driven by individual communities. Work on VisualEditor is actually leading WMF to develop wikitext more.)
(8) There's always going to be tension between figuring out how much time is appropriately spent on documentation and consultation. I'll certainly pass that suggestion along.
(9) The Flow team may be able to address their thoughts on what's going well and not well with their deployment. --Maggie Dennis (WMF) (talk) 14:11, 5 February 2014 (UTC)
Thanks. Fram (talk) 14:38, 5 February 2014 (UTC)
A few updates, inline for easier visibility in context. --Maggie Dennis (WMF) (talk) 19:09, 5 February 2014 (UTC)

The new "gallery" inserter

I don't know if feedback on the new "very basic" Gallery inserter was requested, but I'll give it anyway.

It's ridiculous. It is totally pointless if you don't know wikitext, and of course it is rather pointless if you do know wikitext.

In Wikitext, if you add a gallery, you get example code already, and all the space in the world instead of a very small and cramped window. The minimum the gallery inserter needs is the image selector you get when you use "media".

Of course, when you use a reference in a gallery, you get errors in VE editing mode, but that was only to be expected.

You are obviously aware that this option is "very basic", so why bring it into production anyway instead of waiting until it was useful and had some added value? Some deadline to meet? A bugzilla that needed closing? Nothing else to do anymore? Fram (talk) 08:50, 31 January 2014 (UTC)

Impressive new tool ! And not even tested: take an article, insert a gallery somewhere (I tried in the middle of a sentence), type ??? in the text area, click outside the windows, the gallery is displayed and click Save page => well, nothing happens at all. --NicoV (Talk on frwiki) 12:16, 31 January 2014 (UTC)
Well, I did get it to work, so that may be browser or OS dependent. For once I am the lucky one where it works somewhat (they have probably changed their tests to use my OS/browser combination, to get rid of my annoying "loud complaints" :-) ). Fram (talk) 12:35, 31 January 2014 (UTC)
Old work computer: XP, FF ESR 17.0.2. --NicoV (Talk on frwiki) 12:54, 31 January 2014 (UTC)
It's not expected to insert galleries yet; as James announced at MediaWiki on its release, "There is now a (very basic) editor for <gallery>s, though no scope for inserting a new one or changing its display type yet." It's in production because VE isn't meant to be a feature-finished product. It's a collaborative one, and feedback on the entire VisualEditor is requested - assertively so, at every wiki to which it is deployed. :) Transparent development of VisualEditor gives an opportunity for course modification as developers go. --Maggie Dennis (WMF) (talk) 13:02, 31 January 2014 (UTC)
Well, just a basic ergonomic idea: if it's not supposed to add gallery tags yet, then don't let it add gallery tags and don't add a "Gallery" element in the "Insert" menu. Do we really have to find every announcement made by any member of VE team to know what we are supposed to use and what we shouldn't use ? And VE not being finished doesn't mean that you have to release completely useless features until they become a minimum useful. --NicoV (Talk on frwiki) 13:09, 31 January 2014 (UTC)
And I just tried on frwiki to edit the gallery in "Histoire". After clicking outside the gallery window, text is damaged (<center> is displayed). And still no way to save the page (clicking on the Save page button does nothing at all). --NicoV (Talk on frwiki) 13:28, 31 January 2014 (UTC)
I tried again on the same page but a different computer (Win 7 64bits, Chrome latest edition): no difference at all. Once you have used the gallery editor, text is damaged and clicking on "Save page" doesn't do anything at all. So asking again: any test has been done on this new tool before releasing it into production ? --NicoV (Talk on frwiki) 17:40, 31 January 2014 (UTC)
Hi, NicoV. I just wanted to let you know that I've spoken about this to Philippe Beaudette (who is the Director of Community Advocacy) and that he's talking to the Product team. I think this needs some prompt attention. --Maggie Dennis (WMF) (talk) 20:39, 31 January 2014 (UTC)
What NicoV said. If you don't want this to be used to insert galleries, then don't add it to the "insert" menu. Seems rather obvious... And we know the reasoning behind putting useless, flawed, untested or unwanted features in production. We just don't agree with it. Using "brains" and "manual testing" before putting something in production is a basic requirement. It would be nice to see it put into practice for once. Throwing every piece of code you produce to a live environment to see what will stick is not productive, it's destructive. Why is it that you are happy to request feedback on VE, but ignore the most basic pieces of feedback you have got, like "we don't want it", "make it opt-in", "allow wikitext editing", "test things before putting them here", "don't introduce things with even the most basic features missing"?
Look at e.g. the character inserter (or, yes, this gallery feature): while in theory it is nice to be asked for feedback, it gets annoying very soon if the feedback we can give is for things that should be obvious to anyone with the slightest understanding of what they are building and for whom they are doing this. What we receive is what you would expect from some money-grabbing ruthless company, who has implemented the instruction "we want to be able to insert some characters which are not normally available on our keyboards" quite literally, without any consideration to what is really wanted. The reaction you get is naturally the one you would give to such a customer-unfriendly company. The main difference is that we are not able to get another company to work for us, but that we are stuck with the same people making the same mistakes over and over again, as if they either don't care or aren't capable of improving their work. The continued blind defense of this approach, even by people supposed to understand the community (like the "Senior Community Advocate", the "Community Liaison", and the "Product Manager" (read his job description and weep)), is very disheartening, and illustrative of the wide gap between the WMF and large parts of the editing communities. Fram (talk) 13:39, 31 January 2014 (UTC)
The insert menu is where it will certainly go, unless there's reason to move it. Fram, I'm sorry that you don't like the way this is being done, but also frankly somewhat taken aback to the reference of "blind defense". I am well aware that the community itself is divided on how things should be done, on the micro and macro level, but I don't assume that people whose opinions differ from mine are differing "blindly". --Maggie Dennis (WMF) (talk) 14:06, 31 January 2014 (UTC)
The menu is probably where it will need to be when it's supposed to be working, but why adding it right now when it's not supposed to be working and we shouldn't use it ???? If each time you ask for feedback, your answer is basically "we're doing very good, your remarks are not interesting", stop asking for feedback. --NicoV (Talk on frwiki) 14:25, 31 January 2014 (UTC)
I haven't said that, and I never will, NicoV. :) In terms of the placement, while I'm not an engineer and I'm not helping develop VE, I suspect that the development of the toolbar itself is surely at least as important as the development of the tool. I'm not especially good at adapting to new technology personally - for example, I still can't find half of what I want to use in Microsoft Word since they've moved around the toolbar. Tool placement matters, and the toolbar has already been changed several times to reflect feedback. --Maggie Dennis (WMF) (talk) 14:37, 31 January 2014 (UTC)
Ok, my misunderstanding then. But, honestly, having a "Insert gallery" item in the menu that seems to insert a gallery without any indication that isn't supposed to work is bad. If you just want to test its placement, just display a message when using it, or grey it, but don't let users believe it's supposed to work. --NicoV (Talk on frwiki) 14:45, 31 January 2014 (UTC)
Personally, I think that's a good suggestion, NicoV. I'll pass that along to the developers. Thank you. :) --Maggie Dennis (WMF) (talk) 14:55, 31 January 2014 (UTC)
Defense of your approach, colleagues, ... is normal, probably even commendable. But when the same problems happen again, and again, and again, and the same defense is given every time, then it becomes a "blind" defense. I don't mind that your opinion differs from mine, but when your (plural) approach has been shown time and again to have rather disastrous results, then it is time to reconsider your (opinion about the) approach and try something else. Fram (talk) 14:57, 31 January 2014 (UTC)
While the liaisons and I came into VE after the approach had already been decided, I don't think anybody ever expected that the approach would be unproblematic. Not changing your mind doesn't mean you aren't thinking; it means you aren't convinced that the alternative approach is better. It's a shame you don't like Office Hours, because maybe if you could talk it out collegially with James Forrester you might find more points of agreement* or at least a better understanding of why he thinks that, in spite of the problems, the approach is still the best one. (*It seems to me that it doesn't have to be either/or - there may be some compromises within the approach itself.) --Maggie Dennis (WMF) (talk) 15:17, 31 January 2014 (UTC)
I have little to no respect for or trust in @Jdforrester (WMF): left after too many very unpleasant interactions. I don't believe it is possible to talk this out "collegially" with Jdforrester, or with the WMF in general. The discussions with Whatamidoing on this page are also quite representative of the problem (note that she still hasn't answered a very practical and useful question, after providing the wrong answer twice; this isn't the first time such a thing happened). E.g. the endless claims that there is a QA team, despite the fact that new releases fail the most basic QA tests time and again, is one of the things that has convinced me that discussing this with Forrester or believing anything he says about VE is pointless and stupid. Reading the Office hour logs also doesn't give me the impression that I miss anything useful. But feel free to pass along my question to the next office hours. Fram (talk) 15:46, 31 January 2014 (UTC)

User:Fram, it took me a while to get time to figure out what specifically you were talking about. You seem to be talking about the character inserter. If so, Whatamidoing was right; the change is instant when you update locally. Fortunately, I work with techie people, so I tracked one of them down. :D The reason why your changes didn't show is because there was an error in your code. Now that User:Jalexander fixed it (thanks, James), the character inserter has updated as it's supposed to do. I'm told [17] is a good way to test for that, in case you want to play with the character inserter some more. It can be hard to keep track of those commas, I'm sure. I tried to fix them manually but didn't find them all myself.

While I'm really happy we found this problem, I have to second David Gerard in that thread with regards to tone. It's a lot easier to work together when we remain cordial. :/ --Maggie Dennis (WMF) (talk) 02:44, 1 February 2014 (UTC)

Many bugs for this tool. T62307 means you can't currently save if you do anything with galleries. Fixed on the test wiki will need to wait for rollout here. T45037 main bug for "support galleries". JDF wants something drag and drop able, but priority is low. --Salix alba (talk): 12:13, 1 February 2014 (UTC)
@Maggie Dennis (WMF) - I am afraid it is impossible to give positive assistance without being considered negative- the whole development model you are using almost forces this. I congratulate Fram for his/her persistance and patience. Coders should be protected from general comment and never allowed to take comments personally- that is the role of project management. It is thus essentially not to release code to beta testers before it is robust, and then when it has been destruction tested and fully documented it can be released as a beta. Bugs are thus the responsibility of the QA and testing team. On completion of a period of beta testing they are released into the wild.
Serious comments about the architecture, or even the 4 stage editing process are ignored (write, reference, user summary, save) are ignored as the coders go on to produce yet another widget, which untested, is floating. The coders need a lot of praise for their skill- which they never get due to the development model. I fully understand that this comment will be ignored- or savaged but I write to support Fram. Many before me have tried to say this. If I was listened to, I too could make many helpful suggestions on where to start improving the wikitext editing system. Co-operatively yours -- Clem Rutter (talk) 13:14, 1 February 2014 (UTC)
Clem Rutter, the issue isn't with critical commentary. That's expected and even solicited. But Wikipedia:Battlefield is good guidance wherever there are discussions here. I'm happy to start a separate civil conversation with you or anyone about the approach. I will do my best to communicate your views to product management, but I have to again note that anyone who wants to can communicate them directly through the monthly office hours. If you don't want to, then that's fine; I'm happy to carry your message.
The 4 stage editing process isn't being ignored, though - the designers working on the reference dialog did some massive updates yesterday to mw:VisualEditor/Design/Reference Dialog. I hope you will if interested give good critical commentary there so they can incorporate that feedback.:) The overarching design work is ongoing.
Salix alba, thank you for the update. I know there are high level discussions actively going on about this - as I mentioned yesterday, I brought it to the attention of Philippe, who is talking to Product. --Maggie Dennis (WMF) (talk) 14:41, 1 February 2014 (UTC)
Maggie did, indeed, bring it to my attention, and it occupied the bulk of my attention yesterday. I have been in a series of conversations with the Product team, as they try to figure out what to do to resolve the situation. Obviously, things are complicated: changes to live code are delicate, and there's a strong desire to correct it now, rather than taking the easy course of just removing it (that's not to say that removing it won't be the eventual solution: it is one of several being considered, along with some code fixes and some UI elements). I don't mind telling you that my recommendation was to disable the feature until we get some UI changes. I want to impress upon you that when I took it to Product, they took it very seriously. They're obviously distressed that the code isn't working the way that they had hoped, and they didn't intentionally release a feature that wasn't ready into the field. They don't do that sort of thing. It appears that part of this was caused by something that was already fixed, but not back-ported for some reason. They're rectifying that.
Unfortunately, some key people are either currently traveling or just returned, so they're still trying to wrap their head around the problem. I hope to see some resolution soon, though I hesitate to speculate as to when "soon" is. Philippe Beaudette, Wikimedia Foundation (talk) 18:16, 1 February 2014 (UTC)
Thanks for correcting the inserter problem. As for cordial and civil discussion, I tried that and was ignored completely when my remarks didn't suit people like Jdforrester. Note e.g. a comment made by Whatamidoing above, I know that some people find the Agile approach irritating, but since you systematically search for incomplete features, you are consenting to it and supporting it. This is so outrageous and ridiculous, and it isn't the first time she has made remarks with a similar attitude. She hasn't replied to me (fine) or David Gerrard, who normally is a lot more friendly and patient with the WMF people. Apparently she isn't to be questioned. She (and Jdforrester and others) are supposed to be bridges between the community and the WMF (and devs), but in reality they only do two things: collect errors we find, and communicate the good news from the WMF. They have no interest at all in what the community (or even some parts of it) feel about the situation, the general approach, the priorities, the implementation, the communication by the WMF and how it fails, and so on. They use us as guinea pigs, instead of doing their job. Well, if you want guinea pigs, you shouldn't be surprised if they bite you or shit on your territory.
I have no interest any more in staying civil, it doesn't help with these people at all. They are paid to do a job, and they make a complete mess of it, time and time again, so it is only fair that complaints are being made. If no one listens to unhappy customers, then you get unhappy and angry customers. If there was a way to get a formal and wide discussion about these problems, I would probably start it. But the WMF has no (obvious) open (wiki) location to discuss their performance, they don't seem to follow the "wisdom of the crowd" when it comes to their own work. So I give my opinion here.
And every time they screw up (on average every two weeks), I'll note it here. They have gotten away with their sootging words long enough, and with promises of improvements in the approach. Enough is enough.
Has the QA team discussed and tested the character inserter, or the gallery inserter, before it was put in live environments? Can we see their discussions, opinions, test results? Does the QA team even exist? They seem to be very invisible and inefficient, so one wonders whether they really exist and what they do. People like Jdforrester and the like certainly don't seem to have any interest in putting working and useful software life. Fram (talk) 17:46, 1 February 2014 (UTC)
Stepping in here - Fram, Whatamidoing has a great amount of interest in how the community feels about the situation, the general approach, the implementation and the communication from WMF. She's one of the community's internal advocates. Just as she advocates for the community internally, she also advocates for the wmf here. So I submit that you are only seeing one portion of her work. You have some legitimate gripes with the WMF, but you undermine them with your assumptions about how particular staff feel. I know, for instance, that my communication style makes me come off as cold and all business on wiki. In person, people feel quite differently about me. I submit that some of that may be happening here too. With that said, i've taken your complaint and will be looking for any coaching areas, but I am also not saying that I definitively put blame any one place on this issue. I think it likely an unfortunate clash of communications styles. There's no question that Whatamidoing is blunt in her communications - some people respond very well to that. Some don't. That's why we have several people (Whatamidoing, Elitre, and - at a very high level -Maggie, James and me) tasked to enwiki: to provide several communications styles. Philippe Beaudette, Wikimedia Foundation (talk) 20:01, 1 February 2014 (UTC)
I don't mind blunt. I mind one-sided, evasive, or consistently wrong (or, especially, not admitting to being wrong, the "being wrong" part in itself isn't such a problem). I have no idea what the WMF people we see here do or say at the WMF side (for starters, everything here is out in the open, everything or most thinhs at the WMF side are hidden or lots harder to find, which is rather sad for a wiki / crowdwisdom environment). What you say about her position and comments at the WMF side may be true (I'm not saying it isn't, but I take nothing the WMF says for granted anymore), but we have no way to know or judge this, we can only judge her (and others, this isn't about Whatamidoing alone or even primarily, for me personally e.g. Jdforrester is a much bigger problem and comes across as the main responsible person for the mess we are in (both technically and wrt communication and trust) from what we see here and occasionally at MediaWiki or (in the case of eg Jdforrester) Bugzilla.
And here, we don't get an "you're right, this was stupid, I'll go back to the WMF and let you know the response" even in the most blatant cases, we get evasive responses, a very defensive attitude, and a general I-didn't-hear-that attitude. Usually, the community liaisons (whatever their exact job title) don't give the impression of listening or understanding the community at all, they are only ill-tempered when people dare to criticize the WMF, the development, the new tools, the general approach... They are not responsible for the tools, and presumably Whatamidoing or some others aren't responsible for what gets implemented and what isn't (Jdforrester is though, as far as I can judge WMF structure). But their response to even the best-intentioned and most constructive criticism is often below par if it contains an element of "you shouldn't have put this in production yet, this really isn't useful or thought true", like with the character inserter. And I no longer have patience for that attitude, it isn't helping one bit. Fram (talk) 21:38, 1 February 2014 (UTC)
It's true, Fram, that when I am busy elsewhere, I do not post replies here.
I think it's pretty obvious that you are consenting to this: You voluntarily look at the release notes as soon as they're posted. You then voluntarily go to VisualEditor to look at and test anything that is announced as being either new or fixed. You do this despite knowing that the developers are giving people access to very early, very incomplete versions of new tools. You do this despite knowing that they are using agile methods. Nobody's forcing you to do any of this; you do it of his own free will. You therefore consent to being exposed to these very early, very incomplete, frequently buggy features, and you therefore consent to be directly involved in the development of VisualEditor.
As for your support, it should be obvious that VisualEditor is being improved as a result of some of your feedback. This is very direct, very practical support for VisualEditor's development. Opposition is not normally expressed as providing practical assistance. Even angry or rude practical assistance is still practical support.
As for how you could withdraw your support, which David asked above: you could stop reading about VisualEditor every day; you could stop providing any sort of feedback entirely; you could contact the Board to tell them that you believe the developers needed to change their programming philosophy; you could remove VisualEditor from your own prefs and ignore its existence (this last item is not universally effective, but given your contributions patterns, if you didn't voluntarily seek out opportunities to use VisualEditor, its use by other editors would have almost no direct effect on you at all). You do not make any effort to avoid VisualEditor, you do not make any effort to change the system, and you do take many direct and voluntary seek out and support this system. That's consent and support. Whatamidoing (WMF) (talk) 19:37, 1 February 2014 (UTC)
Goodbye, Whatamidoing (WMF). Please come back once you have corrected as many botched VE edits as I have done here. Oh, and please shut down VE and any development on it, and fire everyone involved, starting with you and JDforrester. Clear enough? Got it through your thick head that I'm not "supporting and consenting" but that, as long as the WMF doesn't give us any choice (you didn't even want to make it opt-in until we forced you), we are not "consenting and supporting", we are fighting the system from the inside.
Si tous les dégoutés s'en vont il n'y a que les dégoutants qui restent That's your "consent and support" for you. I don't have anything left to say to you. Fram (talk) 21:38, 1 February 2014 (UTC)

So when should a new feature be released to a production wiki? In the design of a bit of code there are a number of steps: 1) proof of concept: the basic plumbing needed to make it work and the simplest UI to test it but lacking many options; 2) earliest usable version allows tasks to be done but the UI is basic, no documentation; 3) 50% done UI mainly sorted, documentation started; 4) 90% done, most options work, many corner cases still need sorting; 5) 99% done, nearly everything works, some bugs.

I've been working with some software with a potential customer and producing proof of concept code, which is appropriate there. However for beta testers you need to at least get to stage 2 so its possible use the tool. This might be fine for en wiki where users actually need to opt-in, and by opting in you are implicitly agreeing to be a beta tester. It a little different on fr where the tool is given to anons who don't really know its development code, there I would expect 50% or 90% complete before release.

So gallery and character inserter are still in the early stages. Both barely make beyond proof of concept to usable. As a beta-tester I think oh great, that bit has at least been started. It still to early for serious bug testing work, all which can really be said is "get it to 50% when there is something to test". Screaming and shouting is not going to get it to 50% any quicker. There is a valid question as to whether it should be released in an early stage. For some parts like the equation editor I'm quite glad its released at the just about usable stage. For the gallery tag I'm unsure if its better to have no way of editing a gallery or a very basic and opaque method.--Salix alba (talk): 19:14, 1 February 2014 (UTC)

This would be easier if there were only one "right" way to produce software. But many people would disagree very strongly with your asssertion that the first step is basic plumbing, because Everyone Knows™ that the first step is writing the documentation. As far as I can tell, it depends on which decade you learned to code in. Agile seems to be nearly anti-documentation, so your model might fit with what the devs are doing.
I think for the most part that they are releasing at your step 2. I'm not sure that this gallery inserter rates above 1.5, if that high, but I think that the character inserter barely makes the cutoff for 2. I think that some people would prefer that they released new tools at step 3 or even 4. Whatamidoing (WMF) (talk) 19:44, 1 February 2014 (UTC)
The problem of paralysis by analysis has been recognised for decades, so that's not what this is about. What this is about is the developers not involving their users in identifying requirements, and instead antagonising great swathes of them. Your question below about why an editor might prefer to edit only a section rather than the entire article is rather revealing in that respect. What do you think I'm editing now? The whole article or just this section? Eric Corbett 22:27, 1 February 2014 (UTC)
Some quick responses suggestions here (and made off-wiki) now I'm back online:
Not being able to create galleries
Already fixed, but mistakenly not rolled-out to Wikipedias yet; I've asked for it to be fixed on Monday afternoon, 16:00 Pacific time (the next deployment slot). You can see it working on MediaWiki.org for example; sorry, NicoV that this slipped into production in this state.
Not being able to save a page if you click out of the gallery mid-edit
Another stupid bug, also already fixed and mistakenly not rolled-out; that too will be fixed at 16:00 on Monday.
Default text when you create one so that users have an idea of what to type
This is a possibility; I'm not sure showing "File:Example.png|Caption" will be hugely helpful to newbies, but it would be a start.
Some explanatory text around the basic gallery editor
This is also a possibility, but I'd be cautious about putting too much work into a tool that will be replaced in a few weeks' time or so. As Fram correctly pointed out, this is purely a stop-gap measure per request so that galleries are editable at all, and is certainly not the direction VisualEditor is going in for real editing.
Pulling this feature until it's "better"
This is certainly something we could do; it would help to have a work-list of things to improve, of course.
Putting this feature in as a second-level opt-in "Beta Feature"
A possibility, though this would need some work with Design on the Beta Feature screenshot/etc. which would distract from actually working to improve the feature itself.
Pulling this feature until it's "perfect"
As has been discussed above, this is counter to the Foundation's development philosophy (Cf. "release early, release often"), but it's certainly a worthwhile thing to consider more broadly. I'd note that, were this the case, we'd probably never have shipped a (non-visual) form of the gallery editor at all, as it's not in the vein of our intended proper editor, which would mean that galleries would be un-editable for a few weeks or months whilst that is designed and worked on. It's obviously a subjective judgement whether that would be a good thing or not.
Jdforrester (WMF) (talk) 01:20, 2 February 2014 (UTC)
"which would mean that galleries would be un-editable for a few weeks or months whilst that is designed and worked on. It's obviously a subjective judgement whether that would be a good thing or not." You are aware that galleries were un-editable in VE for "weeks or months"? If that is such a bad thing now that this version of the gallery editor had to be rushed out, then why wasn't it a bad thing the previious half year? Doesn't seem very consistent, to not use it as a show-stopper for the release of VE, but to use it as an excuse to roll out this very premature version (with many flaws to boot, where was the QA team?).
And why did you decide to release the special character insertor in a similar unusable fashion? And why is the upcoming image resizer just as badly thought out? Perfection may not be required, but some minimum requirements perhaps? And testing for those before the roll-out? How many times have the same mistakes been made now? Fram (talk) 09:06, 3 February 2014 (UTC)

So, again, same question: is there no test before rolling out a new feature in production ? Isn't it tested on an internal wiki, then on testwiki before being released in production wikis like enwiki ? Because, if this feature has been tested on testwiki before, how could the fix be "mistakenly not rolled-out to Wikipedia" ? --NicoV (Talk on frwiki) 21:05, 2 February 2014 (UTC)

Hi, guys. I just got out of the morning meeting, and I wanted to let you know that some fixes are going out this afternoon - including the backports to the bug that User:NicoV identified and potentially some example text in the gallery inserter box. I asked about QA testing and was told that QA testing takes two forms – automated and manual. Automated QA testing results are linked in status updates. (For instance, see this one, the main test.) They’re run every 12 hours, to identify what isn’t working so it can be fixed. As new features are added, these tests have to be continually updated because the new features cause them to break. Manually, tests are focused on new areas of code, checked to see if they do what developers expect. QA testers don’t question if the product is well-designed. Product and Design do that. QA testers just test to see if it works as they’re told it should. (Nico, I see we've still got one outstanding question from you - I'm trying to chase down an answer. I'll get back with that as quickly as I can.) --Maggie Dennis (WMF) (talk) 19:25, 3 February 2014 (UTC)
In regards your last question, NicoV, in the case of this particular deployment, it looks like there was a communication disconnect because James was traveling for two weeks. --Maggie Dennis (WMF) (talk) 20:15, 3 February 2014 (UTC)
"QA testers just test to see if it works as they’re told it should." Aren't they supposed to use their brains as well? Asking "why"? It seems that no one at WMF ever does that, asking "why". It is hardly useful to have QA testers whose only input is "your bad idea doesn't generate errors". And of course, even that seems often to be too much to ask (witness the gallery insertor, the copy-paste function, and so on).
I've received word at MediaWiki, concerning the character insertor, that "As far as I know, none of the original design documents are available online." This seems to be a general issue. Please pass this request along: everything at MediaWiki (excluding sensitive issues, HR files and the like) should be made available online as much as possible, to encourage open discussion and to embrace the wiki idea of the wisdom of the crowd. Show us what is decided, and how and why you reached that decision. Show us the test results as well, the feedback you got from the QA team, and so on. It's MediaWiki, remember, and the Wikimedia Foundation. Fram (talk) 08:21, 4 February 2014 (UTC)
By the way, have the QA testers been told that "once you choose "gallery" from the menu, you will have no means to undo this? You will add a gallery (epty or not) whether you want to or not?". Cause that certainly how it works now... Or have they just not tested this thing so far (yes, what an outlandish idea that someone will select something from a dropdown menu, take a look at it, and decide not to use it anyway). Doesn't the QA team have a standard set of requirements every new feature should have at the very least? Does the VE team even have a project leader or something similar? Anyone who takes responsability for the product they deliver? Fram (talk) 08:37, 4 February 2014 (UTC)
Maggie Dennis (WMF). I don't really see the relation between James traveling and what has been deployed: in every project I've worked on, what is deployed is what the QA team has tested and said it was ok for deployment. But, apparently, what you're deploying is not what has been (supposedly) tested. --NicoV (Talk on frwiki) 13:06, 4 February 2014 (UTC)
NicoV, as I understand it, a problem was discovered and a fix was crafted, but due to a communication disconnect around James traveling (and one of the engineers being out sick) the fix was not deployed. User:Fram, I'll pass your request for more transparent documentation along. I'll also note that the reason for early deployment of individual features is precisely to embrace the wiki idea of the wisdom of the crowd. :) And, yeah, that's a problem. I'll check Bugzilla and see if that's been noted. :/ The VE project leader is James Forrester, who is working with a team from different departments within Product and Engineering with some loan from Legal & Community Advocacy. --Maggie Dennis (WMF) (talk) 12:58, 5 February 2014 (UTC)
Thanks. I thought Forrester was the project leader (being the product manager), but I didn't want to blame him for things that perhaps some hitherto unknown project leader was more responsible for. I may be scathing, disrespectful, aggresive and confrontational, but I do try to be fair :-) Fram (talk) 13:05, 5 February 2014 (UTC)
So what happened? The perfect storm.

I've been asked (fairly, it's a good question) what happened with the gallery inserter that allowed it to deploy, but then took all weekend to get fixes in. Basically, mercury went into retrograde and.... the perfect storm. James was on a plane headed home from some well deserved time away. One developer was out sick, and the other who does deployments was on a plane headed for a conference. Erik, the VP-Engineering, was on another plane headed for the same conference. Howie, the Director of Product, was in the office, as was I. When Maggie first called to my attention the feature, I did some quick use testing in the office and decided that it was an unacceptable situation, and went to Howie. He sent mail to James, but we both knew he was in the air. Unfortunately, due to this confluence of events, there wasn't anyone ready who was both a) familiar enough with the code to do any fixes and b) in position to do so and c) had code commit rights.

So, on Monday morning, when all the pieces were in the right place, James and Maggie and I met for a regular check-in, and hashed out what the fix was, and it went out Monday afternoon. It's slower than I would have liked, obviously. But it did get out, and I was pleased to see it. In addition, the backports (fixes of already fixed issues, which hadn't been merged into the main codebase) went out ASAP as well.

It was not a good situation, but I don't think it's a repeatable series... usually there's no problem for James to reach someone who can roll back if necessary. Philippe Beaudette, Wikimedia Foundation (talk) 16:17, 5 February 2014 (UTC)

Thanks Philippe for this reply, but I've the impression it doesn't answer at all my question... Your reply explains clearly why it took several days to fix the gallery inserter after I said here that it wasn't working at all since you weren't able to actually save a page once you've used the tool. I understand that it can take a few days for the fix to be implemented and deployed.
What I was asking, is "how, in the first place, was it allowed to be deployed when it was totally unusable ?" (at least on 2 different configurations for me: XP+FF17 and W7+Chrome). WMF announces that you can edit gallery tags, but nobody actually tested it to see that you can actually really edit gallery tags and save the page? Several people are really wondering if there's actually a QA team for VE related stuff. --NicoV (Talk on frwiki) 17:23, 5 February 2014 (UTC)
Hi NicoV, Some people were able to use it, just presumably on other systems.
QA doesn't test production systems. Their job is to test code before it reaches production. They do not test anything except what's in their extremely detailed test plan (e.g., "Go to Insert menu, verify that these five items are present in this order:" or "Open page, add one character, save page. Repeat on 100 pages. Verify that time from click to redisplay averages less than X seconds"). They do not pass judgment on whether it's any good overall.
Having said that, some of the bug fixes that were on the QA system, and that should have been here, didn't actually make it over here. As a result, it worked for them, but not for us. That's not QA's fault; that is ultimately the fault of "the bramble of legacy shell code" used for deployments, as it was recently described (in a proposal to get rid of said thicket of thorns). Whatamidoing (WMF) (talk) 23:03, 6 February 2014 (UTC)

Feedback request: VisualEditor special character inserter

The developers are working towards offering mw:VisualEditor to all users at about 50 Wikipedias that have complex language requirements. Many editors at these Wikipedias depend on being able to insert special characters to be able to write articles.

A special character inserter tool is available in VisualEditor now. They would like to know what you think about this tool, especially if you speak languages other than English. To try the ⧼visualeditor-specialcharacterinspector-title⧽ tool, please:

Screenshot of TranslateWiki interface
The “insert” pulldown on the task bar of VisualEditor will lead you to the ‘⧼visualeditor-specialcharacterinspector-title⧽’ tool.
Screenshot of Special Characters tool
This is the ⧼visualeditor-specialcharacterinspector-title⧽ inserter. Your feedback on this tool is particularly important.

Comments (positive, negative, or neutral) may be left here. It is really important that the developers hear from as many editors as possible. Thank you, Whatamidoing (WMF) (talk) 00:18, 23 January 2014 (UTC)

special character insert tool feedback

Tracked in Phabricator
Task T62507
Tracked in Phabricator
Task T62770

this tool seems to be less than half-baked - maybe do some developer testing until you are happy, and then ask for feedback again.

issues:

  1. limited # of character sets, with no way to select other sets: this is an important part of special char tool - how do you switch from farsi to greek to hiragana? sure, we can test it with less-than-full set, but surely, the finished product needs some charset-selection widget, no? should it even be demonstrated without such a widget?
  2. editing Cham Choghal-e Sofla:
    1. open the tool after pressing "edit", without actually clicking inside the article (i.e., there is no visible "caret" in the article that marks the insertion position)
    2. press some a special characters, one after the other (the tool stays open, no visible change to the article)
    3. *do* place the caret somewhere by clicking between two characters in the article
    4. click a special character
    5. result: it spits all the previously clicked characters at the very beginning of the article.
    6. use it again, and it spits part of the original article - all hell breaks loose.
  3. the !@#$%^&* thing self-destructs as soon as i enter a single character (except the case described in #2 above), so if i want to add 5 special characters one after the other, i need to open it every time. the least i expect is some checkbox or button for "multiple character insertion"
  4. there is no obvious way to close it if you decide not to insert a special character (say, you opened it by mistake). it seems to close if you click on the page outside the tool, but i think it should have a "close" widget also,

peace - קיפודנחש (aka kipod) (talk) 21:50, 22 January 2014 (UTC)

  • Re the menu seen in File:VisualEditor - Toolbar - SpecialCharacters.png: The mathematics special characters are very limited. At the least I'd think they should include subset/superset/union/intersection. The accents character set looks useless to me (with a Mac keyboard), because they're all easily obtained with option-key combinations; I'd rather see the characters that are hard to type with this keyboard. Also, having the order in the "symbols" menu as degrees-seconds-minutes makes no sense; it should be degrees-minutes-seconds. —David Eppstein (talk) 00:36, 23 January 2014 (UTC)

One minor detail is I'd prefer the dialog be placed near the menu, not underneath the cursor. This is because if the cursor is near the bottom of the screen, I have to scroll down to use select a character. -- Ypnypn (talk) 01:03, 23 January 2014 (UTC)

I was going to test this and detail the individual shortcomings, but really, what's the point? Either you come here and ask for "what would you like to see and get in a 'special character insertion tool'", or you deliver us an at least half-finished but well-thought out product. Now, you present us with something that may not produce instant errors, but which has zero functionality for 99% of the wanted edits. The number of special characters, even for editors at enwiki, is minimal to the extreme; capital letters are missing; you can't add more than one character at a time; and so on.

Go back to the drawingboard, get some user expectations first (it looks as if you don't know what this tool is really supposed to do), look at the "special characters" insertion tool in normal editing mode, but don't bother use with this nonsense. You are only making a fool of yourselves, and aren't winning any souls for VE, while the actual practical benefit of these responses to you will be minimal. Really, you have developers, you always claim to have a QA team, you have enough people willing to give feedback if you simply ask "what would you like to get in this tool", you have an existing example, and still you dare to come here with this? Please, find the one who asked you to get input on this tool, and (assuming it is a paid WMF employee) fire him or her for gross incompetence. How many times will you (WMF) make the same errors before anything changes there? Just leave us alone and do your job. Fram (talk) 12:44, 24 January 2014 (UTC)

Entirely agreed with Fram. It clearly shows that nothing has been learned by the 6 months+ fiasco of VE deployment. The new widget seems so badly thought over, and tries to reinvent the wheel where there's already a working, useable gadget for the wikitext editor. --NicoV (Talk on frwiki) 13:04, 24 January 2014 (UTC)
I disagree with your claim that there are "enough people willing to give feedback if you simply ask". I asked for feedback on this character inserter over a month ago in the en.wp newsletter, and it was also mentioned in Tech/News last month (along with instrutions on how to change its contents to be more useful to the local project). Between them, that request reached more than a thousand users. I received exactly zero responses. Furthermore, without an existing example (i.e., what we have now), most non-technical users have trouble giving feedback. Whatamidoing (WMF) (talk) 22:42, 27 January 2014 (UTC)
What that might suggest to you, and certainly suggests to me, is that everyone is getting bored with this VE crock. Eric Corbett 00:26, 28 January 2014 (UTC)
(What Eric said, plus) have you considered asking it here instead of (or in addition to) through those two channels? If you are looking for people still somewhat interested in VE and possibly willing to give Feedback, then Visual Editor/Feedback might just have been the right place to come to initially, no? Just a thought... Or you could have framed the question here differently, not as a "we will deploy this to 50 Wikis, are there any last-minute changes that need to be maee to this tool we have developed" but as "we would like to develop a tool, but our first mockup is severely deficient and basically useless. How can we turn this into something workable?". Finally, "wihout an existing example"? We have one (or even two), in the wikitext editor, you could have asked people whether rebuilding that one would be a good idea or not. Don't try to invent the lukewarm water please when we already have a working spa. Fram (talk) 07:42, 28 January 2014 (UTC)
I mostly agree with Eric and Fram. Asking feedback about a VE tool should have been done here at least, not only in non-VE related pages... But even without any answer, you could have looked at the already existing special characters insertion tools (2 in wikitext editor, or even in unrelated programs like MS Word) just to get ideas: you would have seen that a "selector" seems mandatory given the number of special characters; that keeping the tool displayed after having inserted one character seems useful. You could also have checked a few pages on enwiki to see how the tool could have been used. For example, I clicked once on "Random article" and found Anton Savchenkov: a few cyrillic characters used to display the name in cyrillic (several characters from the same set, one after an other => "selector" and keeping the tool displayed are useful), and they are used in a {{lang-ru}} template (being able to use the tool in template parameters seems vital, which seems completely overlooked in the current mockup). --NicoV (Talk on frwiki) 08:01, 28 January 2014 (UTC)
Regarding "it was also mentioned in Tech/News last month (along with instrutions on how to change its contents to be more useful to the local project)." I notice that in the en-wp Newsletter (which, due to flagrant unreliablility wrt VE, I don't read anyway, I have no interest in PR pieces), you mention the character insertor in Tech 2013-50, but you don't request any feedback there: "You can now use a basic tool to add special characters to your text. You can add more characters (useful in your language) by editing the MediaWiki interface on translatewiki.net." Furthermore, despite the claim made in the goodnewsshow, I can't add more characters, "You do not have permission to edit this page, for the following reason: This page provides interface text for the software on this wiki, and is protected to prevent abuse."[18] It contains no instructions on how to get the necessary rights. I have now found and requested translator rights, perhaps that will be sufficient? Anyway, can you indicate where you actually requested feedback, instead of just informing that it exists? Fram (talk) 08:24, 28 January 2014 (UTC)

קיפודנחש, it appears that there are 34 different character sets available. The wikitext editor at the English Wikipedia only offers access to eleven of them. Do you think that these eleven are enough here? (Each project can have its own list.)

Also, the < in the top left corner is the "close" button. It's used in several other places in VisualEditor. Several people have complained that its purpose is not sufficiently obvious (an X is generally preferred). Whatamidoing (WMF) (talk) 22:42, 27 January 2014 (UTC)

The problem reported in your #2 is now T62507. Whatamidoing (WMF) (talk) 23:47, 27 January 2014 (UTC)
Whatamidoing: regarding the charset selector, i think there are several separate questions here: one of them (the one you asked) is "which character sets we want to support by default"? i am the wrong person to answer this question - you probably want to consult with the people who maintain the charinsert gadget. BTW, there are two different tools in the wikieditor: one is MediaWiki:Gadget-charinsert.js (11 charsets), and the other is the "Special characters" tab on the wikieditor toolbar (18 charsets). i am not sure it's critical to answer this question right now - if the tool is good, we can fiddle with the actual charsets at any time.
another question, i guess, is "which characters from each set should be available?" (i think another user complained that the Math charset misses some stuff it should contain). again, i am not the right person to answer this question.
i was talking about a 3rd question: "how does the charset selector look, and how does it function?". the purpose of this experiment is to collect feedback about the suitability of some UI tool for a specific task. the "real" product will no doubt contain a charset selector, so i think the mock-up should have one too, regardless of the fact that the mock-up support a tiny subset of character sets that the "real" thing will support. as to the "close the dialog box" control: WMF is introducing several new tools. i think "X" in the top right corner is the expected standard, but we could live with deviation from the standard if all the new toys would at least agree among themselves, but if some of them (such as universal language selector) want to use the top-right X, and some (such as VE) want to use the top-left <, the whole thing becomes a mess. peace - קיפודנחש (aka kipod) (talk) 00:34, 28 January 2014 (UTC)
For some wikis (although perhaps not any of the Wikipedias or Wiktionaries), the need for special characters may be small enough that no selector is needed. The devs are, however, aware of the need for a selector on the Wikipedias. In keeping with their agile programming philosophy, they are requesting feedback as early as possible, not when the product is nearly finished. Whatamidoing (WMF) (talk) 17:20, 28 January 2014 (UTC)
In keeping with their agile programming philosophy? They have failed before applying the first principle: Customer satisfaction by rapid delivery of useful software You need to follow all of it, not just delivery of software. Your customers are not satisfied, and the software is not useful (whether "rapid" applies can be debated). Like someone wiser than me said: "Would you like to click on open the [...] character set [...] every time you wanted to add a letter? I wouldn't." Agile programming isn't presenting customers a block of steel and saying "this is your car, how can we improve it?" Fram (talk) 09:56, 29 January 2014 (UTC)
The agile philosophy does not even hope that customer satisfaction will be the result of the initial delivered product. Notice the absence of any timeline there. In fact, a core tenet is that the customer won't like the initial iteration, which is why Agile plans multiple iterations from the beginning. A block of steel isn't "useful" as a car, so it wouldn't be delivered under Agile. However, a character inserter than can insert only one character is "useful" as a character inserter (in the very limited circumstance that you need to insert only the one character), so it could be.
I know that some people find the Agile approach irritating, but since you systematically search for incomplete features, you are consenting to it and supporting it. Whatamidoing (WMF) (talk) 23:21, 29 January 2014 (UTC)
That's the first time I see such a distorted explanation of agile programming... and such a bad implementation... no wonder VE development is so awful... what about the product owner, which is the stakeholder representative supposed to give developers a good idea of what should be developed in an iteration, and never developers deciding on their own how they should develop a feature. You're just wasting our time with this kind of requests. --NicoV (Talk on frwiki) 06:50, 30 January 2014 (UTC)
I know that some people find the Agile approach irritating, but since you systematically search for incomplete features, you are consenting to it and supporting it. is utter bullshit. I am systematically (well no, rather haphazardly, but I'll let that pass) searching for "incomplete features" (you mean bugs, right? Please leave the PRspeak for the WMF conferences and use normal speech here. Most of the things I report are not "incomplete features" by any stretch of the word) because the WMF doesn't do its job at all. I am not consenting to your "agile" approach, and even less supporting it. I utterly oppose it (at least in the way the WMF misuses it), I utterly oppose VE, and I would like that most people involved with it in a paying role get fired. Please explain to me how you jumped to the ridiculous idea that I consent to and support your agile approach? How would you have expected me to show my opposition? Have I been to nice and friendly until now? I hardly think so. But I don't want to simply state "I don't like VE" and let you ignore this, I want to show how bad the work is that you (WMF) produce, and luckily you are making it very, very easy for me, time and again (the "Gallery" is the next "incomplete feature" you will present, and it is again completely ridiculous, only useful to close a bug in your flawed philosophy of when something is ready, and to meet a deadline; not a single user will be happy with it).
You may remember that I have asked the WMF to stopbringng constant bug-filled updates and instead go back to work for a few months, solve the most egregious errors, and only present us with an update afterwards. You (WMF) refused. So please don't claim that I support your "agile" approach. I don't. Fram (talk) 07:46, 30 January 2014 (UTC)
"since you systematically search for incomplete features, you are consenting to it and supporting it." Er, what? What in your mind would constitute withdrawing consent? Do you literally not understand the concept of not consenting to perceived maltreatment? - David Gerard (talk) 09:44, 30 January 2014 (UTC)
Two thank-yous so far for the above edit. @Whatamidoing (WMF): I await your detailed response - your phrasing is actually disturbing - David Gerard (talk) 14:40, 30 January 2014 (UTC)

Whatamidoing said above: "(along with instrutions on how to change its contents to be more useful to the local project)." I haven't yet found his original instructions, but I have encuontered one rather annoying problem. After having found out where I needed to go to request rights to change the translator page, it turns out that we won't be able to change the contents of this tool, since English is the source code language and only changeable by devs. If this is correct for this page, then it is (another) serious design flow, using your code or metadata as the actual data for your largest customer base... Anyway, the result is that I have not been able to change the selector, so @Whatamidoing (WMF):, what was the purpose of claiming on enwiki that you left instructions on how to change this if this turns out to be unavailable to us anyway? Thanks for yet again wasting my time on a wild goose chase. By the way, I'm quite baffled by your reply here: "How would you like to get to the Greek letters? Would you like a bigger box? (If the box is big enough to show all the characters someone might need, then it won't fit on your screen, but it could be bigger than this.)" (emphasis mine). A helpful editor responded: "Hello, the size of the box is not a problem, but of course it would need a scrollbar[...]" A scrollbar! Is that supported by the WMF, or is it "discouraged" like the reflist template? If you really need such Feedback for dummies at the WMF, then discussing this is really hopeless. Fram (talk) 14:33, 28 January 2014 (UTC)

Would you like to scroll through three screenfuls of stuff to get to the single character that you're after? I wouldn't.
Would you like to click on open the mathematics character set—now close that one and open the Russian one so I can type the name of the Russian mathematician—every time you wanted to add a letter? I wouldn't. I'd rather be able to see two or three character sets at a time, but not a dozen or more. How many sets would you like to see at once? Whatamidoing (WMF) (talk) 17:20, 28 January 2014 (UTC)
The fucking thing closes "every time you wanted to add a letter" anyway, so I need to open a character set every time, even when I don't want to change the set. Please tell, what's wrong with the system used in wikitext editing, where you get all the sets you want (with a scrollbar) on the left side, and all the characters in that set (with a scrollbar) on the right? How many times have you found this system to be unworkable or insufficient? Yes, more sets could be added? Other problems with it? The instances where you need to constantly switch between multiple character sets are very, very rare, and it's hardly cumbersome with the existing wikitext solution. So please take your foot out of your mouth and look at what exists, and try to improve that, instead of acting as if what you present is an improvement in any - single - way and as if it is so hard to find better ideas than those... Fram (talk) 09:29, 29 January 2014 (UTC)

Can it get worse? Well, it certainly can become less clear. I may be doing something wrong here, so please explain what is we should be doing to get it right. As explained, MediaWiki:Visualeditor-specialcharinspector-characterlist-insert/en may not be changed by us mere mortals. However, we can change e.g. MediaWiki:Visualeditor-specialcharinspector-characterlist-insert/fr. But the point of this escapes me. My changes don't become visible either at Mediawiki (after I changed my preferences to language:French), or at the French wikipedia. Some lapse, some waiting time before changes get propagated? No, because none of the earlier versions of that page are used either, what is shown is the blasted /en version, the one we can't change. So, if I'm not mistaken, it looks like despite claims to the contrary, we are not able to / allowed to change this tool anyway. Please, Whatamidoing or anyone else from the WMF, explain to us what you have tried to communicate, what I have done wrong, and what the purposes is of these Mediawiki pages. Because it sure has the appearance that you have again tried to sell us a load of bollocks, and that can't be right. Right? Fram (talk) 14:59, 28 January 2014 (UTC)

Translatewiki.net is a non-WMF private website that actually patches the code for MediaWiki. Changes made there do not propagate instantly. If you want to make immediate changes here, then you need to edit MediaWiki:Visualeditor-specialcharinspector-characterlist-insert (admins only). Whatamidoing (WMF) (talk) 17:20, 28 January 2014 (UTC)

So, @Whatamidoing (WMF):, let's see if I get this straight. You come here to ask for feedback on a tool which is pretty unusable for all practical purposes. You then claimed that you had asked for feedback in the newsletter, but didn't receive any feedback. In reality, you did not ask for any feedback there, you just made an announcement. You also claimed that you did this "along with instrutions on how to change its contents to be more useful to the local project", pointing to the character set on Translatewiki, but it turns out that we can't (not at all for the English one, and not with any result for the other languages). Could you please provide somewhat correct information instead of this? Fram (talk) 09:00, 29 January 2014 (UTC)

Here is an exact copy of the request I made in the newsletter in December:

* There is a new character inserter, which you can find in the new "insert" menu, with a capital Omega ("Ω"). It's a very basic set of characters. Your feedback on the character inserter is wanted here.

Notice all that stuff in bright yellow? That yellow highlight was in the December newsletter. Notice that in English, the concept of a request is not limited to sentences phrased as interrogations. "I request that you give feedback" and "Please give your feedback" and "Your feedback is wanted" are all every bit as much requests for feedback as "Will you give your feedback?" Whatamidoing (WMF) (talk) 23:21, 29 January 2014 (UTC)
You said "I asked for feedback on this character inserter over a month ago in the en.wp newsletter, and it was also mentioned in Tech/News last month (along with instrutions on how to change its contents to be more useful to the local project). Between them, that request reached more than a thousand users." I hadn't seen the newsletter you mention, what I did find was the Tech/News, which did not contain a request at all, only (incorrect) information. This is the Tech News: 2013-50 I mentioned above, where the full text was "You can now use a basic tool to add special characters to your text. You can add more characters (useful in your language) by editing the MediaWiki interface on translatewiki.net." No request there (or fancy colouring), and incorrect information on the "more characters". So "that request reached a thousand users" should probably be reduced to the ones that get the newsletter only, and exclude the Tech News readers? Your sarcasm is noted, just as your lack of answer to any actual remarks about how this "change the inserter yourself!" is supposed to work. I'm glad that you found one thing you had said that was partially correct and which I hadn't noted (due to the lack of any links to your posts and the confusion between the newsletter and the tech news, which you claimed both made the request, and where I had only found the latter). Congratulations on that. Now, do you have any useful replies? Fram (talk) 08:17, 30 January 2014 (UTC)

So, again; I created MediaWiki:Visualeditor-specialcharinspector-characterlist-insert (which you indicated needed to be used) and MediaWiki:Visualeditor-specialcharinspector-characterlist-insert/en (which I thought might be better) (with a minor difference between the two), but neither of those are visible here anyway apparently. Any indication how soon changes made to these pages should have any result? Oh right, "immediate" was what you said.

You know what, please, pretty pretty please, just shut up for a moment, test the things you are telling us, and come back with diffs of actual results, and instructions that actually work. If not, then just stop after the first ten words of the previous sentence. Fram (talk) 09:20, 29 January 2014 (UTC)

Fram, I realise you're pissed off, but please tone it down a bit. No-one's going to answer you talking like that even if you're 100% factually correct - David Gerard (talk) 12:44, 29 January 2014 (UTC)
So what? The WMF people are just talking shit to defend the shit they produce. Their strategy seems to be "let's get rid of all opoosition by exhausting their patience by all means possible, including obfuscation, "misunderstanding", displays of stupidity, frequent memory loss, and worse", so it seems only a friendly gesture to show them that their strategy is actually working. It's bad enough that they produce worthless junk, but the ways in which they are obstructing or ignoring useful and pertinent feedback is staggering. Not just this section, the one above about references makes for enlightening reading as well. Not getting an answer is preferable to the infuriating non-answers the WMF has produced. If people use the money generated by the encyclopedia (ie by us) to develop these things or e.g. to have a job that is described as 'to support these changes by "ensuring that our community is represented in the decision-making process and that our planned software adequately reflects user needs".', then we may expect better service and results. As far as I can judge from the results we get, and from the interactions I have had or seen, none of the WMF people involved in VE (with the possible exception of Elitre) or higher up in the WMF has done their job adequately. Some seem to be incompetent, some seem to have done their best to do the opposite of their job description. MediaWiki doesn't seem to have a complaints department. So they receive the backlash here.
If they give correct, honest information, they get polite replies and questions. If they can't be bothered to check their replies or to think before they post, they don't. It's quite simple. Fram (talk) 13:28, 29 January 2014 (UTC)

I have added the "Latin" set from the standard wikitext insertor to MediaWiki:Visualeditor-specialcharinspector-characterlist-insert. I don't think that the current set-up (with all the other noted flaws) scales very well. Just imagine that a dozen further character sets are added. Has any thought been given on how to solve this before this was implemented? Fram (talk) 12:22, 3 February 2014 (UTC)

Yes, several options were considered. The next iteration of the design just isn't ready for people to look at yet. They aren't wedded to the next design, so if anyone has particular ideas for the best way to include a dozen or more characters sets, then I'll pass them along. Whatamidoing (WMF) (talk) 16:01, 3 February 2014 (UTC)
You mean a dozen characters sets I hope... What about the suggestions that have already been made several times: look at the existing gadgets for the wikitext editor that are already working correctly; add a selector for the character set; ... ? Other suggestions: don't use a window but a toolbar displayed under VE toolbar; use the width of the toolbar to have more characters per row; don't use big buttons; use fixed size buttons when possible; ... --NicoV (Talk on frwiki) 16:20, 3 February 2014 (UTC)
Yes, and I'veamended my statement to clarify. Would you personally prefer a full-width tool to a floating one? As noted above, the floating tool causes problems when your cursor is at the bottom of the page. Whatamidoing (WMF) (talk) 16:34, 3 February 2014 (UTC)
Fram: "Has any thought been given on how to solve this before this was implemented?" Whatamidoing: "Yes, several options were considered." And what? The worst one was chosen? One was chosen at random? People didn't think more was needed? WMF hoped that no one would notice? Perhaps they could have chosen a design that doesn't "cause problems" and has serious possibilities?
Why not use MediaWiki to present, in the "insert drop down" or in a temporary "character insertor" dropdown, multiple solutions next to one another, if you are uncertain which one is to prefer? Character Insertor #1 to Character Insertor #5, for people to test and provide feedback, and the best solution, the one that works, is useful for most people's needs, and is scalable, is then put into production (ie rolled out to other wikis)? Wouldn't that perhaps, just perhaps, have prevented much of the current problems you face? By the way, any link to where these options were considered, who presented ideas, feedback, ...? Fram (talk) 16:58, 3 February 2014 (UTC)
The design work done before this "baby step" toward a character inserter was offered to the community for feedback was all internal, e.g., face-to-face discussions, so you will be unable to see it. What you see now is the first public discussion.
As you've been told, the current version is not the full implementation of the design that they're currently working on; it is only a way to indicate the general outlines: a locally configurable floating box with buttons to click. Furthermore, what they're working on now is likely to be changed as a result of the feedback from other people. For example, given feedback that a floating box is annoying when you're typing at the bottom of the page, they may scrap that aspect. One advantage of taking baby steps is that it's easier to make a decision to start over if you have a better idea, because you are less susceptible to the sunk cost fallacy (since you hsven't sunk as much into it).
If you would like, I can suggest your proposal that multiple versions be publicly presented at the same time. However, I doubt that they will embrace your idea: it's expensive to produce five working versions, and it is highly unlikely to result in consensus. I don't know about you, but I don't remember ever seeing a five-way RFC end in a consensus for one option, and I don't see any reason to think that this would be different. Whatamidoing (WMF) (talk) 17:19, 3 February 2014 (UTC)
"Five" was an example, not knowing how many the "several" options were that you have "considered". And I have seen enough RfCs that ended with consensus for one option (excluding the mostly useless RfC/Us here), but even so, it doesn't need to be a formal RfC, just an open on-wiki discussion, with the people that have already used similar tools in the past and are most likely to need the thing you develop in the future. As for the sunken-cost fallacy, you are aware that you are completely contradicting yourself, no? Now, the result is that you have developed something that you may well need to scrap completely, and that the costs put into it are thrown away completely. With some preliminary discussion, some more thought put into it, some analysis, you wouldn't need to drown the ugly baby you have now created. And you wouldn't have a userbase that felt insulted by the stupidity you ask feedback on.
Asking for feedback is good if you have no idea what to do, or when you have multiple valid or conflicting options; asking for feedback is not good when anyone with some idea of what the tool was going to be used for could have presented you with the basic huge flaws in the current design. Of course it is not the full implementation, that is not the problem or what we are complaining about. That you e.g. are in doubt whether "math" should be included into this character insertor, or whether "hieroglyphics" should be put into or not; fine, no problem, we don't expect a final product. But that anyone thought at any time that an inserter which you could only use to insert one character at a time would be acceptable is beyond me, and that no one, not the Product Manager, not the QA team (were they involved in this in any capacity? Do they exist?), not anyone else there, thought that this could be a show-stopper and a reason to delay this first implementation, even ignoring the extremely limited set of characters and the lack of forethought on how to expand and present this.
You can give all the justifications you like, but I still haven't seen a good explanation for this, nor an indication whether this was tested, and by whom, before this was put into production. It shouldn't be too hard to find the test results and post them (anonymous if you don't want people publicly humiliated)? Fram (talk) 17:50, 3 February 2014 (UTC)
Would you personally prefer a full-width tool to a floating one?. Yes, that's what I meant in don't use a window but a toolbar displayed under VE toolbar. Floating window is just bad for something that is needed to be usable for several characters. And, something that will be able to work inside templates, references, galleries, ... --NicoV (Talk on frwiki) 17:11, 3 February 2014 (UTC)
Thanks for the quick reply. This idea is now T62770. Whatamidoing (WMF) (talk) 17:26, 3 February 2014 (UTC)
By the way, Fram, you should consider deleting MediaWiki:Visualeditor-specialcharinspector-characterlist-insert/en. I don't think it will be useful at all, and it has the potential to create differences in what people see if they have en vs en-gb set as their language of preference. It certainly is pointless while it reproduces the same typos that you created at the correct page name. Whatamidoing (WMF) (talk) 16:34, 3 February 2014 (UTC)
Done. Perhaps you can change all instances of Tech 2013-50 (and if necessary elsewhere) where you claimed that the character set could be changed at Translatewiki, which is incorrect (for enwiki), unwanted (for the others, according to Elitre), and very confusing since it doesn't include the correct place to make or request changes. Fram (talk) 16:48, 3 February 2014 (UTC)
No? As could be expected. Easier to lecture others than to face your own shortcomings. Fram (talk) 08:45, 4 February 2014 (UTC)
I don't write or control Tech/News, and even if I did, it would be inappropriate to retroactively change the historical record of announcements that were made.
Furthermore, thoughtful changes to the defaults for different languages probably are wanted—just not off-the-cuff, semi-random changes by someone who doesn't know the needs of people who speak that language. That's a task that we should leave to qualified translators rather than to people like you and me. Whatamidoing (WMF) (talk) 22:07, 6 February 2014 (UTC)
Oh yes, the great "it's an archive, we can't change that" cop-out. Adding a note to it with a timestamp is impossible? Fram (talk) 08:29, 7 February 2014 (UTC)

Surreal:

  • @Whatamidoing (WMF): "thoughtful changes to the defaults for different languages probably are wanted—just not off-the-cuff, semi-random changes by someone who doesn't know the needs of people who speak that language. That's a task that we should leave to qualified translators rather than to people like you and me."
  • Reality: "A thoughtful creation of a character insertor for different languages is wanted-just not an off-the-cuff, semi-random tool by someone who doesn't know the needs of people who would use such a tool. That's a task we should leave to qualified analysts and knowledgeable editors rather than the current WMF people." Fram (talk) 08:29, 7 February 2014 (UTC)

The new reference dialogue

It looks really good!

VE add reference
VE add reference: pasting the URL
VE add reference: edit ref details

I love the autofill! Let me suggest one more thing: add google.books URL autofill. Have a look at existing tools:

If you paste into http://reftag.appspot.com this URL http://books.google.fr/books?id=4ghCAAAAcAAJ&pg=PA366&dq=planetarium+maschine&hl=da&sa=X&ei=SCCsUvGoLcKl0AXk3YG4CA&ved=0CEUQ6AEwAw#v=onepage&q=planetarium%20maschine&f=false you get:

  • Gabriel Christoph Benjamin Busch (1820). Handbuch der Erfindungen: ¬Zehnten ¬Theils ¬zweyte ¬Abtheilung, ¬die Buchstaben P und Q enthaltend. Wittekindt. pp. 366–.
  • and a named ref (automatically)<ref name="Busch1820">

Nice! See some stats why this is worth the effort:

  • E. Summers. top hosts referenced in wikipedia (part 2), inkdroid. 2010: ...that my previous post about the top 100 hosts referenced in wikipedia may have been slightly off balance since it counted *all* pages on wikipedia (talk pages, files, etc), and was not limited to only links in articles. (...) So I downloaded the enwiki-latest-page.sql.gz, loaded it in, and then joined on it in my query to come up with a new list. (...) We can see a lot more pop culture media present: newspapers, magazines, sporting information.
  • Shilad Sen: As of Jan 1, 2011 there are 6.384.425 total citations in the main namespace for English Wikipedia. Our top-line research questions focus on citations containing URLs, so we broke down our results into citations with a URL (78%) and those without (22%).
The top 5 domains in citations with a URL (2011): 
1. books.google.com (73.777 - 1.48%) 
2. news.bbc.co.uk (52.347 - 1.05%) 
3. www.stat.gov.pl (51.598 - 1.03%) 
4. www.nytimes.com (39.454 - 0.79%) 
5. www.imdb.com (24.993 - 0.50%)
  • Getting to the Source: Where does Wikipedia Get Its Information From? Heather Ford, Shilad Sen, David R. Musicant, Nathaniel Miller. Opensym 2013: 27% of citations referenced URLs that no longer existed, and were removed from our analysis. Of the remaining citations, 80% referenced material intended for viewing in a web browser, almost exclusively web pages (78%), supplemented by a small number of videos (1%) and images (1%). The remainder (20%) referenced material intended for print, primarily PDFs but also digitized books. (...) In order to measure the frequency of cited sources, we extracted all 11M citations that appeared in articles on May 2nd 2012. This analysis is then limited to the 77% of those citations that referenced a URL. Table 5 lists the 20 most cited domain names. (...) 10 of the top 20 publishers are traditional media companies with origins in print or television. (...) The most frequent citations are often to large and wellknown media organizations such as the New York Times or the BBC.
Top 20 most cited domains on May 2, 2012: 
Row	Domain		Information Type		Country	% Citations
1	google.com	search engine and archive	US	1.97%
2	nytimes.com	news and analysis/opinion	US	1.18%
3	bbc.co.uk	news and analysis/opinion	UK	1.04%
4	stat.gov.pl	data/statistics			Poland	0.49%
5	guardian.co.uk	news and analysis/opinion	UK	0.49%
6	imdb.com	directory/archive		US	0.47%
7	archive.org	directory/archive		US	0.45%
8	youtube.com	video				US	0.44%
9	allmusic.com	directory/archive		US	0.41%
10	cnn.com	news and analysis/opinion	US	0.36%
11	yahoo.com	search engine			US	0.36%
12	nih.gov		analysis/opinion			US	0.26%
13	latimes.com	news and analysis/opinion	US	0.26%
14	telegraph.co.uk	news and analysis/opinion	UK	0.26%
15	census.gov	data/statistics			US	0.25%
16	washingtonpost.com	news and analysis/opinion US	0.24%
17	espn.go.com	news and analysis/opinion	US	0.23%
18	independent.co.uk	news and analysis/opinion UK	0.22%
19	amazon.com	directory/archive		US	0.21%
20	time.com	news and analysis/opinion	US	0.21%

So books.google refs really matter, and they are often for old books without ISBN. I'm very happy with your new VE reference dialogue :-) --Atlasowa (talk) 22:41, 1 February 2014 (UTC)

It's a big improvement, isn't it? Your request to support books.google.com is now T62768.
There is more information at mw:VisualEditor/Design/Reference Dialog, if anyone is interested. Whatamidoing (WMF) (talk) 16:58, 3 February 2014 (UTC)
I just wanted to comment and say that I loved it as well. Great job guys! --Nicereddy (talk) 21:16, 8 February 2014 (UTC)

Upcoming office hours for VisualEditor

Hi again, VE testers :)

I just wanted to let you know, so you could mark your calendars if interested, that there are two IRC office hours scheduled to discuss VisualEditor in February.

The first will be held on Saturday February 15 at 1700 UTC and the second will be held on Sunday February 16 at 00:00 UTC. (See Meta for time conversion links.)

Logs will be posted on meta after each office hour completes. You'll find them, along with logs for older office hours on the topic, in a category at Meta.

Please see the main page for office hours on Meta for more information on how to join in. Thanks, and have a nice week, --Elitre (WMF) (talk) 13:29, 10 February 2014 (UTC)

A small (not urgent) bug...

Tracked in Phabricator
Task T62998

Click "edit beta" in a page that contains a table (Episodes section) or an infobox. Then start editing the table or the infobox. Try to add a link on a parameter using wikimark since we can't use VE at this point (something that was discussed in the past I think and hope it will get fixed somehow in the future). After you type the link, click "apply changes". The new added link is not always appearing as a blue link at the edit mode of the page as it should but it does appear right when you save the page. There are many ways to link something and one of them doesn't give a blue link...meaning...

  • [[United States]] → blue link as it should
  • [[United States|USA]] → blue link as it should
  • [[Pink (singer)|Pink]] → blue link as it should but...
  • [[Pink (singer)|]] (using the "|" character but not writing Pink again to earn time) → [[Pink (singer)|]]

I know that when I save the page the fourth way of adding a link will appear right, but for someone who doesn't know that it might be confusing of "Why? What did I write wrong and it's not linked?" I know that this is not really important or urgent but I thought it would be nice to get reported... Thanks TeamGale 11:25, 5 February 2014 (UTC)

Thanks for this note, TeamGale. I was easily able to reproduce this from your description, and I have filed T62998 for you. I really appreciate you reporting even things that seem less important. Whatamidoing (WMF) (talk) 22:45, 6 February 2014 (UTC)
@TeamGale and Whatamidoing (WMF): I (think I) have fixed this myself on my development branch and have submitted a fix; if all goes well, it should be released here next Thursday (in 9 days' time). Thanks for catching this, and the very clear re-production steps! Jdforrester (WMF) (talk) 01:12, 12 February 2014 (UTC)
You are welcome. Thanks for the update Jdforrester (WMF) and for the fix. Hope everything will be OK with the release. TeamGale 02:18, 12 February 2014 (UTC)

VisualEditor does not have a 'view or edit selection source' menu item

Bug report VisualEditor
Mito.money Please app{}
Intention: Add a source code snippet to an article.
Steps to Reproduce: Click edit, and desire to look at source to see how something works or to fix something VE has no interface for. Select and right-click the part of article in question.
Results: The 'switch to source' functionality of VE is ugly (as remarked in 2 previous reports), I have to read a massive amount of source for a small thing; a view or edit selection source context menu item is missing.
Expectations: I expected it to be easy to view and edit a specific part of source and switch back.
Page where the issue occurs https://en.wikipedia.org/w/index.php?title=Cooley%E2%80%93Tukey_FFT_algorithm&diff=595078093&oldid=593715255
Web browser Firefox 25
Operating system Windows 7
Skin Vector
Notes: Web browsers usually have 'view selection source' menu item.
Workaround or suggested solution None.

Gryllida (talk) 02:46, 12 February 2014 (UTC)

I added that for you at 61263. Regards, --Elitre (WMF) (talk) 12:51, 12 February 2014 (UTC)

VisualEditor does not switch to source and back easily

Bug report VisualEditor
Mito.money Please app{}
Intention: Add a source code snippet to an article.
Steps to Reproduce: Click edit, and desire to look at source to see how something works or to fix something VE has no interface for.
Results: The 'switch to source' functionality of VE is ugly — requires a page reload, and has no switch back to VE — and I'm too lazy to use it. Result is an incomplete edit, as linked, with source tag not used and lang not specified, as outlined in the previous report on this page.
Expectations: I expected it to be easy to switch to source and back.
Page where the issue occurs https://en.wikipedia.org/w/index.php?title=Cooley%E2%80%93Tukey_FFT_algorithm&diff=595078093&oldid=593715255
Web browser Firefox 25
Operating system Windows 7
Skin Vector
Notes:
Workaround or suggested solution None.

Gryllida (talk) 02:44, 12 February 2014 (UTC)

This will be possible when 47779 is fixed. In the meantime you'll probably want to edit the table because it duplicates contents from the previous one :) Thank you, --Elitre (WMF) (talk) 12:35, 12 February 2014 (UTC)
I changed my comment because I understand why you reported it that way, it confuses me a bit, but there's no real need for you to do anything about it. --Elitre (WMF) (talk) 12:57, 12 February 2014 (UTC)

Inserting code snippets

Tracked in Phabricator
Task T57533
Bug report VisualEditor
Mito.money Please app{}
Intention: Add a source code snippet to an article.
Steps to Reproduce: Click edit, with a code snippet in clipboard.
Results: I observed no 'source' style in the menu (normal, heading, preformatted, et al)
Expectations: I expected a 'source' style which I can apply, right click the snippet and specify language
Page where the issue occurs https://en.wikipedia.org/w/index.php?title=Cooley%E2%80%93Tukey_FFT_algorithm&diff=595078093&oldid=593715255
Web browser Firefox 25
Operating system Windows 7
Skin Vector
Notes:
Workaround or suggested solution I resorted to using preformatted style and saving the page; it's obnoxiously rude, because someone will have to correct it — by converting to source tag with lang specified — in a separate edit. (The 'switch to source' functionality of VE is ugly — requires a page reload, and has no switch back to VE — and I'm too lazy to use it.)

Gryllida (talk) 02:42, 12 February 2014 (UTC)

I'll note in the meantime that you can use <code> tags in VE - in the formatting options, labelled as "Computer code". Will look for specific bugs though. --Elitre (WMF) (talk) 11:32, 12 February 2014 (UTC)
We could add suggestions to 43133, though. --Elitre (WMF) (talk) 13:11, 12 February 2014 (UTC)
What you wanted was to specify <syntaxhighlight lang="fortran">? That's the same thing as <syntaxhighlight> , which is T57533. Whatamidoing (WMF) (talk) 20:03, 12 February 2014 (UTC)

Template parameter input boxes are very small

Tracked in Phabricator
Task T63289

It's nice that you can see all the parameters at once, as shown in the picture. However, only one and a half lines are shown at a time, so it's really hard to edit some of them. See the "methods" parameter shown; there is actually a whole list there, with many references, but only a very small amount of it is shown.

Suggestion: Make these boxes scrollable, and preferably resizable. - Ypnypn (talk) 16:59, 12 February 2014 (UTC)

We've talked about this before, e.g., Wikipedia:VisualEditor/Feedback/Archive 2013 13#Multiple_issues_-_minimal_space. Would you prefer scrollable to just making them bigger? (On some computers, it appears that they're two lines deep, but it probably depends on your font size and pixel density.) Whatamidoing (WMF) (talk) 20:30, 12 February 2014 (UTC)
Bigger could work, but in some cases (such as the example shown) it would need to be lot bigger. Maybe we could make it parameter dependent, so we can specify (using TemplateData) the size of the field. What do you think? Ypnypn (talk) 00:38, 13 February 2014 (UTC)
I like that idea, but it sounds like a lot of work (for us; we'd have to update the TemplateData on thousands of templates). Perhaps a small increase in the default size (to two full lines, which is what I suspect is intended) would also be a good idea. Whatamidoing (WMF) (talk) 01:00, 13 February 2014 (UTC)
If I can add my opinion...I agree that the space is way too small for the parameters. If it's possible and it is going to be changed, can the increase in the default size to be at least three lines? I would prefer five so we won't have to scroll down to see the whole context but maybe that will be too big? Three will be fine I believe but I wouldn't have problem if it was more. Two lines still seems small for me. I don't know what the others prefer. The sure thing is that it has to get bigger... TeamGale 01:16, 13 February 2014 (UTC)
My 2cts : bigger fields + scrollbars as needed + resizable window would be nice, but also redesign the window so that there's not so much space wasted. Currently, there's more than 50% of unused space vertically (big grey area between each param, big white area before parameter name, big white area between parameter name and value, big white area after parameter value, big padding in each field, ...). I think this is a general problem with VE windows where unused space represents most of the window space. --NicoV (Talk on frwiki) 08:26, 13 February 2014 (UTC)
White space is incredibly important for readability and usability. I'd agree strongly with a three-line default and the ability to resize the input window (vertically) as needed, those seem like obvious and rather vital improvements. --Nicereddy (talk) 05:48, 14 February 2014 (UTC)
Yes, they are important but they could be used correctly: the current version is so full of white space that I find it not very readable. Keeping it readable could be done wisely, not by adding more white space than meaningful content. Suggestions : replace the grey area between parameters by a line (less space wasted, as readable as before), don't use large padding inside the fields, reduce white space between parameter name and value (I don't think that making related closer will reduce readability). --NicoV (Talk on frwiki) 10:07, 17 February 2014 (UTC)
Bug report VisualEditor
Mito.money Please app{}
Intention: I was editing a large table with multiple red links, which I was attempting to remedy. However, when I used VE, the table rendered with all the links blue, thereby making it difficult to figure out what links were in fact redlinks
Steps to Reproduce: #Go to List of International Court of Justice cases
  1. Click on the Edit-Beta tab for VE
  2. See a table full of blue links

Yes, I've reproduced it.

Results:
Expectations:
Page where the issue occurs
Web browser Both Safari 6.1.1 (7537.73.11) and Chrome 32.0.1700.107
Operating system Mac OS X 10.7.5
Skin ? Not sure.
Notes: yes, I can provide a screenshot Screen_Shot_2014-02-10_at_3.49.39_PM.png
Workaround or suggested solution

Erudy (talk) 20:50, 10 February 2014 (UTC)

By the way, I'm a long time editor (starting, I'm not sure, something like 2006 or 2007 or something). I know you guys have gotten a lot of flak for VE. Personally I think it is the future. Every time I use it is getting better and better. I now do about 50% of edits with it, and look forward to being able to ignore wikimarkup in the future. Keep up the good work!!Erudy (talk) 20:59, 10 February 2014 (UTC)

Hi there, Erudy. Thanks a lot for your kind words and for the pretty detailed report! I believe the issue you're encountering is related to bug 37901. I suggest you keep another tab open in view mode, in the meantime. Regards, --Elitre (WMF) (talk) 21:04, 10 February 2014 (UTC)
This long-established problem is one of the several reasons I'm not using VE at present, as it's just not fit for purpose: I work a lot with disambiguation pages, and it's essential to be able to see whether a link is red or blue. When this, and a few other things, is/are fixed, I might come back to using/testing VE. PamD 22:37, 10 February 2014 (UTC)
Sorry to hear that, PamD. So Sherry brought up this again today, and we could learn from James that this is being actively discussed between the Parsoid, Platform and VisualEditor engineering teams. He gave us some hope that we might see some movement on this in Spring, but please just pretend I never wrote that ;) --Elitre (WMF) (talk) 22:14, 11 February 2014 (UTC)
From the sounds of it, even Spring is not likely. It is not an easy thing to do correctly. Whatamidoing (WMF) (talk) 23:17, 11 February 2014 (UTC)
@Erudy, PamD, Elitre (WMF), and Whatamidoing (WMF): Given that this is a really irritating bug, I'm going to knock some heads together and see if we can get a plan in place for making this work sooner rather than later – thanks for the feedback, and sorry for the disruption. Jdforrester (WMF) (talk) 00:57, 12 February 2014 (UTC)
Thanks for your reply. I didn't mean to imply that this would get fixed then, but that hopefully we might have heard more about it by then. But it's good to clarify this for PamD. --Elitre (WMF) (talk) 11:22, 12 February 2014 (UTC)
Very annoying and old bug, which also appears in Flow (preview gives bluelink, but on saving it becomes a redlink). Duplicating many VE bugs in Flow, and adding a bunch of new ones, is perhaps not the wisest move... Fram (talk) 11:33, 12 February 2014 (UTC)
@Jdforrester (WMF): Thank you for giving this some priority. This issue is, as Pam noted, something that experienced editors automatically pay attention to, and value.
I'll also note, for what it's worth, that having a third color [green, I'd argue for] for links to disambiguation, in VE, would be a huge value-add. In the wikitext editor, a color change can be done by using a script (so, only for registered editors), and there is a bot that monitors links from articles to disambiguation pages, and posts to user talk pages (so, useful only for those who read their user pages), but these are kludges. -- John Broughton (♫♫) 19:02, 15 February 2014 (UTC)
@John Broughton: You're welcome, John. Adding a colour for disambiguation pages and redirects is certainly something we can do – indeed, we built support into the new categories in the link suggesting tool – but I feel that that's something that should be decided across MediaWiki rather than just in VisualEditor, as part of moving that user script into possible preferences. Jdforrester (WMF) (talk) 17:58, 18 February 2014 (UTC)
@Jdforrester: Thanks, James, for giving some hope that this might get fixed "Sooner rather than later". Now if we can do something about the fact that the dialog box for templates and categories hides the entire article text .... ? I think that's the main deal-breaker for me, as I spend a lot of time stub-sorting and VE is just not usable. PamD 23:01, 15 February 2014 (UTC)
@PamD: Thanks, Pam. I'm aware of your desire for the dialogs to be draggable, but I still don't see this as a priority given the huge complexity of making it happen in a reliable way for users on different devices, sorry. Making the dialogs smaller so they obscure the text less is a worthwhile effort, though; I will try to get some progress on that. Jdforrester (WMF) (talk) 17:58, 18 February 2014 (UTC)

References in Infobox

Tracked in Phabricator
Task T63505

I would like to be able to add references when editing the infobox. ȸ (talk) 01:16, 17 February 2014 (UTC)

Technically speaking, this is possible. However, like with all infobox editing in VE, you need to know wikitext, and you need to know it even better than in noral wikitext editing, since you get no help (cite templates, whatever) at all here. Template editing is still one of the worst features of VE (together with table editing and quite a few other things). Fram (talk) 08:06, 17 February 2014 (UTC)
You can do this now, if you know the wikitext.[19]
However, your idea is now T63505, and I think they'll agree with you and implement it. Whatamidoing (WMF) (talk) 18:39, 18 February 2014 (UTC)

VisualEditor does not handle equation numbers ({{EquationRef}})

Bug report VisualEditor
Mito.money Please app{}
Intention: Edit Discrete Fourier transform
Steps to Reproduce: Click 'edit beta' for Discrete Fourier transform section 1 (definition)
Results: I saw the equation number styling broken, as shown on the picture.
Expectations: Equation number should have proper styling.
Page where the issue occurs Discrete Fourier transform
Web browser Firefox 26
Operating system Windows 7
Skin MonoBook
Notes:
Workaround or suggested solution

Gryllida (talk) 06:15, 14 February 2014 (UTC)

It works for me, as you can see from the image here (marked by an arrow). The screenshot was taken in Safari 6 on Mac OS 10.8.5, but I get the same results in Firefox 26. Can someone else check? Maybe it's a font-size setting (I've got a fairly aggressive minimum size set in Safari) or a Windows-specific problem. Whatamidoing (WMF) (talk) 18:49, 14 February 2014 (UTC)
For me in Firefox 26 on Windows 7 (tested in Vector and Monobook skin), the equation markers appear in the correct font size. However, the link "Eq.1" appears in normal font style instead of bold italic, although the parentheses appear correctly in bold. So I can't reproduce this issue either. — This, that and the other (talk) 06:22, 15 February 2014 (UTC)

I think the problem is due to an incompatibility of the {{NumBlk}} and {{EquationRef}} templates. Both templates attempt to put the equation number in bold but because they are nested it breaks the nesting rule of html. NumBlk is like 

...
'''({{{3}}})'''
...

where {{{3}}} is the equation number. EquationRef is like 

<cite ...>
<span class="reference plainlinksneverexpand">
  '''
  {{#if: {{{2| }}}|[[#equation_{{{1}}}|{{{2}}}]]|[[#equation_{{{1}}}|{{{1}}}]]}}
  '''
</span>
</cite>

Substituting both templates gives 

...
'''
<cite ...><span class="reference plainlinksneverexpand">
'''
Eqn 1
'''
</span></cite>
'''
...

Blindly changing to <b> means you get 

<b>
<cite ...><span ...>
</b>
Eqn 1
<b>
</span></cite>
</b>

Basically its broken the nesting rule of html. Its no surprise that the normal rendered and parsoid recover this differently.

Normal renderer treats it as two nested <b> blocks <b>...<b>...</b>...</b> 

  <b>
   (
   <cite id="math_Eq.1">
   </cite>
   <span class="reference plainlinksneverexpand">
    <cite id="math_Eq.1">
     <a href="#equation_Eq.1" title="">
      Eq.1
     </a>
    </cite>
    <b>
     <cite id="math_Eq.1">
     </cite>
     )
    </b>
   </span>
  </b>

Parsoid treats it as two consecutive <b> blocks <b>...</b>...<b>...</b> 

  <b data-parsoid="{}">
   (
   <cite id="math_Eq.1" data-parsoid="...">
    <span class="reference plainlinksneverexpand" data-parsoid="..."></span>
   </cite>
  </b>
  <a rel="mw:WikiLink" href="https://en.wikipedia.org/wiki/Discrete_Fourier_transform#equation_Eq.1" data-parsoid="...">
   Eq.1
  </a>
  <b data-parsoid="...">
  )
  </b>

The solution in simply to remove the ''' formatting from either {{NumBlk}} or {{EquationRef}}, however this will break cases when either is used independently. Perhaphs styling using span might help.--Salix alba (talk): 09:33, 15 February 2014 (UTC)

I've now changed {{EquationRef}} to use <span style="font-weight: bold; font-style: italic;" ...>...</span> which should cure any problems. @Gryllida: it would be nice if you could test this.--Salix alba (talk): 10:40, 15 February 2014 (UTC)

Hum still a little VE bug. Somewhere the css style rule 

.ve-ce-mwTransclusionNode span.reference {
  vertical-align: super;
  font-size: smaller;
}

Is being applied, putting the equation number in superscript style. This conflicts with the CSS in view mode which has no CSS for span.reference so it appear in normal style. --Salix alba (talk): 11:14, 15 February 2014 (UTC)

Salix alba, thanks for figuring out what's going on here. I've been a little surprised in the last few months to see just how often people encounter templates that don't work or are incompatible with each other, despite the work of a very dedicated group of editors to find and repair issues with "illegal" or inaccessible HTML. Thank you, Whatamidoing (WMF) (talk) 18:47, 18 February 2014 (UTC)

Unresponsive script, says my Firefox browser

It identified Script: https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cdata%2Cicons-vector%2Cmwcore%2Cmwgallery%7Cext.visualEditor.viewPageTarget.icons-vector%7Cext.wikimediaEvents.ve%7Crangy&skin=vector&version=20140212T024905Z&*:123 Best. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 19:36, 12 February 2014 (UTC)

Biosthmors, indeed, I just had "Script: https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cdata%2Cicons-vector%2Cmwcore%2Cmwgallery%7Cext.visualEditor.viewPageTarget.icons-vector%7Cext.wikimediaEvents.ve%7Cjquery.byteLimit%7Crangy&skin=vector&version=20140213T025830Z&*:158" when editing a large page in VE. Not exactly the same message, but probably related. Problems with editing large pages in VE are an old issue, but the current version seems to be worse in this regard than what we had the last few months. Fram (talk) 09:40, 13 February 2014 (UTC)
Hi Biosthmors,
Problems with bits are likely to be problems with bits.wikimedia, which is sometimes overloaded. If you're getting this consistently (different times of day, different days, and/or always on the same article), then please let me know. Whatamidoing (WMF) (talk) 19:17, 18 February 2014 (UTC)

Categories added in the wrong place

Hi, I saw several edits on frwiki where categories are incorrectly added by VE: example without carriage return between 2 categories. I tried to reproduce it with FF17, XP:

  • If the categories are at the end of the article: problem reproduced, the new category is added without a carriage return and it ends up on the same line as an other category
  • If the categories are not at the end of the article (language links after categories): different problem, the new category is added after the language links and not with the existing categories.

I already had to fix about 10 pages this morning, detected by Check Wiki project, but I fear that we will get a lot more tomorrow. Question as usual: is VE tested before put into production in major wikis? --NicoV (Talk on frwiki) 08:02, 18 February 2014 (UTC)

You might be interested in reading the last office hour log (at least from 00:12:35), where James provides details about VE and testing. Sorry I am not able to address your report ATM, which I had already noticed elsewhere, will take a look ASAP. Thanks, --Elitre (WMF) (talk) 18:24, 18 February 2014 (UTC)
I don't trust anything James is saying for quite a long time, since we frequently have confirmation that many things are not true. WMF keeps repeating that tests are done, but very frequently we see that basic features arrive broken in production wikis, which should have been caught if any serious QA testing was done. --NicoV (Talk on frwiki) 18:44, 18 February 2014 (UTC)
You can see some of the tests that are run at https://git.wikimedia.org/tree/mediawiki%2Fextensions%2FVisualEditor.git/76e011b6715da451062305f2211b3f3e03a0863d/modules%2Fve-mw%2Ftest%2Fbrowser%2Ffeatures if you're interested. This set of tests is run 14 times a week, and the results are publicly available at https://wmf.ci.cloudbees.com/view/r-ve/ Whatamidoing (WMF) (talk) 19:26, 18 February 2014 (UTC)
Yes, great, but as I said so many times, automatic testing for a user interface is a good thing (when they have a good coverage, which is clearly not the case here), BUT never replace manual testing. Why? Because automatic test can only detect failures for which they have been programmed, whereas a human being can see other things than just what is written on his test sheet. --NicoV (Talk on frwiki) 20:10, 18 February 2014 (UTC)
Tracked in Phabricator
Task T63558
Tracked in Phabricator
Task T54204

I'm currently working on fixing all incorrect ISBN numbers on frwiki. I found several articles where ISBN links are damaged by VE, without it being visible to the editor (unless by checking the wikitext diff). See the last line of this edit. It's easy to reproduce with VE:

  • select an entire line containing an ISBN number,
  • copy/paste it to use it as a template for an other book (at this time the wiki text seems correct),
  • delete the end of the ISBN number (backspace) and replace it with the correct number

=> the ISBN link is trashed by VE ([[Special:BookSources/9788871986647|ISBN 978-88-7198-668-]]8), but it seems visually fine. --NicoV (Talk on frwiki) 17:47, 18 February 2014 (UTC)

It's not special to ISBNs. It's the same problem with editing any link, which apparently is a difficult problem to solve. Whatamidoing (WMF) (talk) 18:11, 18 February 2014 (UTC)
Well, ISBN are not all internal links (syntax is only ISBN 978-88-7198-667-8), so they shouldn't be treated by VE as internal links. The original syntax was ISBN 978-88-7198-664-7 (no indication of any link) and not [[Special:BookSources/9788871986647|ISBN 978-88-7198-664-7]], so there's a specific problem with ISBN in VE. --NicoV (Talk on frwiki) 18:27, 18 February 2014 (UTC)
Copying and pasting is not necessary. If you type in an ISBN, VisualEditor treats it like plain text. If you open a page with an existing ISBN, then it treats it like an internal link (because, due to WP:Magic word processing, it actually is an internal link, even if you can't see that from the wikitext. The link class is class="internal mw-magiclink-isbn").
If you click on that ISBN in VisualEditor, you get the link symbol. If you change it, then it gets changed exactly like changing any other internal link—which means that just changing what you can see changes the label instead of the actual link. Try it: my sandbox has a couple in the first paragraph. If you click in the middle of a regular internal link and mash your keyboard, you get a link to the original page with garbage in the label. If you click in the middle of the ISBN and mash your keyboard, you get a link to the original page with garbage in the label. Whatamidoing (WMF) (talk) 19:37, 18 February 2014 (UTC)
You don't really understand: basically you're trying to explain to me that it's normal that VE handles ISBN numbers a lot worse than the rest of MediaWiki. Why would a user replace a simple, esay, working syntax for ISBN numbers, by a cumbersome, error prone one ? That's what VE is doing with ISBN numbers and which requires again other contributors to come after a VE edit to cleanup the mess. The magic word processing precisely allows to deal with ISBN in a clean and easy way, and VE simply trashes that. --NicoV (Talk on frwiki) 20:06, 18 February 2014 (UTC)
I'm thinking about this from the perspective of a user of VisualEditor, not from the perspective of a wikitext user: Why would a user replace a simple, easy working syntax for ISBN numbers with a cumbersome one? Well, probably because most people don't care or even know about stuff that they never see, and a person who uses only VisualEditor isn't likely to see the change. Spelling out the link creates a dirty diff (which is undesirable), but it's not actually "wrong".
(Spelling out the link format isn't actually any more error-prone than leaving it to the wikitext parser; the problem there is the confusing way that VisualEditor handles any kind of link.) Whatamidoing (WMF) (talk) 21:58, 19 February 2014 (UTC)
Why did I say that VE way of dealing with ISBN links was cumbersome and more error prone? Because, in wikitext, you only have to write the actual ISBN number once (so if you want to modify it, you only modify it in one place), while in VE you have to change it in 2 places (the destination of the link and the text itself). So the way VE works opens the way to more errors, inconsistencies and requires human editors to be more careful. It's more error-prone because humans have to be careful. This kind of discussion is hopeless... I also remember you that a overwhelming majority of users are using the wikitext editor (like 90%): you're complexyfying the syntax for 90% users because a tool used by 10% is not smart enough, really great. --NicoV (Talk on frwiki) 22:33, 19 February 2014 (UTC)

Empty <ref /> tag added by VE

Tracked in Phabricator
Task T63503

In this edit on frwiki, VE added an empty self-closing <ref /> tag. What's the point ? And as often, an internal link is inserted as an external link. --NicoV (Talk on frwiki) 12:11, 18 February 2014 (UTC)

Confirmed: [20]. Add a reference, no text, apply changes, done! Again an example of why User:Jdforrester (WMF) probably shouldn't have made the claim that "Also, the numbers of accidental mis-formats (having to fix your syntax after saving) is zero with VisualEditor, obviously." (cf User talk:Jdforrester (WMF)#Office hours). Note that I had noted, with an example, this very problem there on 8 November 2013[21], so over three months ago. Jdforrester never replied to the examples or indicated that he was wrong, but the problems are rather persistent. Fram (talk) 12:28, 18 February 2014 (UTC)
Note that this bug is also a nice example of those instances where the result in VE editing mode is completely different from the one after saving. Often they are just the opposite, with e.g. refs in galleries producing an error during VE mode but giving a correct result in view mode... Fram (talk) 12:56, 18 February 2014 (UTC)
If you actively add an empty reference, then you get an empty reference. VisualEditor should be able to detect these and refuse to let users make this error. Whatamidoing (WMF) (talk) 18:09, 18 February 2014 (UTC)
You're right Fram, WMF will simply deny any problem... VE is a wonderful software, there are no "accidental mis-formats" (a user clicked on a button, so it's not VE's fault), there are no damages to articles, ... --NicoV (Talk on frwiki) 18:31, 18 February 2014 (UTC)
Deny, and don't understand. What VE should do is either refuse an empty ref, or at the very least add correct reference syntax, i.e. the result of this edit, not the starting point. The version I made in wikitext gives the correct error for the problem, the version VE made is just bizarre. Furthermore, it is nice to read the VE defense in the bugzilla report, but what Whatamidoing "forgets" is that you can correct your error easily in Wikitext, but VE doesn't allow you to edit the malformed ref at all. Luckily, you can delete it, but really... Fram (talk) 19:49, 18 February 2014 (UTC)
Fram, we have just said the same thing: You said "What VE should do is either refuse an empty ref" and I said, "VisualEditor should be able to detect these and refuse to let users make this error." Whatamidoing (WMF) (talk) 22:01, 19 February 2014 (UTC)
I said a lot more though, which you ignored/forget/disagreed with/whatever. At Bugzilla, you couldn't let an opportunity pass to dig at wikitext, just like you did at the Jdforrester discussion I mentioned, and equally inappropriate. You (WMF) can't claim that WMF is so much better than wikitext editing because it doesn't allow any grammatical (wikitext) errors at all, and then claim that, when such errors do appear, it is no big deal because wikitext does the same, and even worse at the same time not retract the original claim that such errors are impossible in VE. You can't have your cake and eat it. But as shown in the "image" thread here as well, it isn't the first time that User:Jdforrester (WMF) has used the "office hours" to spread misinformation about VE. Now why would some people have lost all trust in WMF communications in general and VE communications in particular? Fram (talk) 07:39, 20 February 2014 (UTC)

Interwiki linking to other Wikimedia projects

Tracked in Phabricator
Task T63672

This isn't currently possible in VisualEditor, at least as far as I can tell. For example, using wikitext I can link to Flow's MediaWiki article using an interwiki link rather than an external link. Similarly, I can do this across languages, e.g. Idioma inglés on the Spanish Wikipedia.

Has this functionality been discussed? I feel like this could be a beneficial addition to VisualEditor, especially in getting more traffic directed towards less popular, but similarly important projects such as Commons, Wikiquote, Wiktionary, etc.

--Nicereddy (talk) 05:04, 20 February 2014 (UTC)

I think you do it just like adding a normal link. Highlight some text, click the link button and for the link type the appropriate interwiki link like :es:Idioma inglés. Seems to work for me.--Salix alba (talk): 05:51, 20 February 2014 (UTC)
Salix alba is correct :) Keegan (WMF) (talk) 08:16, 20 February 2014 (UTC)
That would be nice if VE could by itself create an interwiki link when the URL given to it matches an interwiki link: for example, if I give VE the following URL https://es.wikipedia.org/wiki/Idioma_ingl%C3%A9s, it should create [[:es:Idioma inglés|Idioma inglés]]. The same of course should be apply for link to the current wiki (create an internal link). --NicoV (Talk on frwiki) 08:36, 20 February 2014 (UTC)
Would you want [[:es:Idioma inglés|Idioma inglés]] or [[:es:Idioma inglés]]? Whatamidoing (WMF) (talk) 17:15, 20 February 2014 (UTC)
I prefer the second one, but both would be ok. It only concerns links without labels given by the user. --NicoV (Talk on frwiki) 17:36, 20 February 2014 (UTC)
Thanks for your quick reply. I've added a note about making links without a label to that bug report. Whatamidoing (WMF) (talk) 19:53, 20 February 2014 (UTC)
This actually does work, but only if you paste in an "http" (not "https") URL (which most of us don't get any more). I've just filed T63672 to make the behavior for http and https match. Whatamidoing (WMF) (talk) 17:29, 20 February 2014 (UTC)

Existing references, again

According to the VE newsletter, the thing was fixed: "When you re-use references, it now correctly displays the references again, rather than just the number and name." Well, yes but no but yes but no but... Take e.g. Barack Obama, a featured article with 349 references. Click anywhere in the text, insert reference, reuse existing reference. Ignore for a second that the numbers you get here don't match the numbers in the article.

Despite the claim of the VE newsletter, it only displays the number and name for reference 2, 26, 41, 43, 45, 47, 53, 60, 61, 62, 63, 65, 67, 70, 73, 87, 92, 98, ... That's 18 case of the first 100 where it still goes wrong. A serious improvement over 100/100, but nothing to be ignored (or missed by some diligent testing).

Another example, todays FA Afroyim v. Rusk; ignore the very ugly edit notice (these are not designed with VE in mind, obviously), and note with joy that none of the references are empty when trying to reuse one. Rejoice, but not for too long. Hmm, the article has 94 references, but the "reuse" box only shows 90 references? Strange. Hey, refs 26 to 28 (original article numbering) are included, but the exactly similar ref 25 ("Perez, 356 U.S. at 59.") is missing. Has it gotten some other number? No, it just isn't there! Three other ones are missing as well, but I haven't wasted time finding out which ones.

I guess I'll put the newsletter back on 'ignore'... Fram (talk) 13:29, 20 February 2014 (UTC)

Thank you for your note. The "missing" refs in Barack Obama are WP:List-defined references, which, as you know, are not supported at this time. You can use {{sfn}} to place refs to existing LDRs, but that's about it.
In the TFA, the "missing" refs are citations placed inside the {{quotation}} box. They "disappear" because <blockquote> is not supported at this time. You will not be able to re-use references from infoboxes or galleries, either. (Refs inside galleries, as you already know, additionally produce a large red error message about not having a ref block, because galleries are treated as a separate page and can't "see" the main one inside VisualEditor.) These are features that VisualEditor will support in the future. Whatamidoing (WMF) (talk) 19:59, 20 February 2014 (UTC)

Advanced image settings? More VisualEditor rubbish.

Tracked in Phabricator
Task T52645

@Philippe (WMF), Whatamidoing (WMF), Jdforrester (WMF), and Mdennis (WMF):

Let's start with the least important complaints, and end with the major trouble, shall we? It's nice that you can add image size, but the behaviour isn't consistent with what VE does anyway (VE always makes width and height the same, the "advanced settings" lets you change one, the other gets adjusted automatically, but they are not the same except for square images!).

Worse is the "Make full size" button. In the earlier version, this was labeled "original size", but after I pointed out that this was incorrect (or at least very confusing), this was changed to "full size". However, this small and easy fix did nothing about the larger problem: why do we have this option?

What may be needed is "Put back default size", for when you have changed the size of the image and no longer knows what the "original", pre-change size was, or what the size would be if you wuold insert the image anew. Hardly top priority, but useful. What we have now though is scraping-the-bottom-of-the-barrel-priority, when there are countless other things to do. Define position (left/right/center)? Thumb? Alt text? Change an image without deleting and readding it? All 100 times more important than what we have gotten now.

And of course, it doesn't seem to work very well. When I (FF26, W7) go to Royal Museums of Fine Arts of Belgium, and change the size from either (or both) of the images beneath the infobox to "full size", I can use the "save button". However, "review your changes" then gives "Could not start the review because your revision matches the latest version of this page.". The same applies to the image at the top of History of Christian meditation, Catholic clergy involvement with the Ustaše, File dialog, ...

And this doesn't only apply when I use "full size", but also when I explicitly give a size, the only other thing I can do in the new "advanced settings". This thing does not work. As usual.

So, let me again, for the 100th time, do the job the paid developers, product manager, and QA team should have done; test it, point out the problems, and even point out the cause of the problems. These new settings, for what they are worth, only work if the image already has a size indication (200px, 250px*250px, whatever), not when it only has a "thumb" indication. Sadly, the latter is the default and by far most common situation. Fram (talk) 13:44, 12 February 2014‎ (UTC)

Same on Chrome, W7. And same feeling that no thought is given before developing something, and that no tests are really done. --NicoV (Talk on frwiki) 14:00, 12 February 2014 (UTC)
(edit conflict) Thanks, Fram. I tested this in my sandbox (Chrome) and received no indication that the change would not save - on preview, it indicated an image size change. It just did nothing on saving. I'll report the bug and note also your recommendations regarding the feature. --Maggie Dennis (WMF) (talk) 14:03, 12 February 2014 (UTC)
Reopened an older bug that may be related. Added your current feedback to MediaWiki. I'll make sure it's raised in the next meeting. --Maggie Dennis (WMF) (talk) 14:26, 12 February 2014 (UTC)
Thanks. Fram (talk) 14:28, 12 February 2014 (UTC)
Alignment and alt text should be available here in about 24 hours. Mediawiki.org will get access to frame settings (thumb/frameless/etc.) at about that time, plus an updated interface for alignment. Whatamidoing (WMF) (talk) 20:17, 12 February 2014 (UTC)
And do these work in all cases, or only in a select few as well? Fram (talk) 08:07, 13 February 2014 (UTC)

This has now been moved to Bug 61270, but this covers only half of the problem, not only does "full size" not work, changing the size in the "advanced settings" (e.g. putting width at 300) also doesn't work (or to be more precise, it gives a result while in VE editing mode, it triggers the "save" button, but it doesn't register as a change for the review changes and doesn't get saved). Please modify the bug or add a second one, whichever fits your mood. Fram (talk) 08:07, 13 February 2014 (UTC)

@Fram: Thanks for the note; though the bug report only mentions the "make full size" button, I've checked and the fix also fixed the manual adjustment of the size as well. You can check this for yourself on MediaWiki.org; next Thursday the fix will make its way here as normal. Jdforrester (WMF) (talk) 04:53, 14 February 2014 (UTC)
I don't edit MediaWiki.org any longer as long as people like user:Jasper Deng, User:Eloquence, Jorm, you, ... rule there. Even compared with enwiki, it's a toxic environment where WMF, admins and friends are treated completely different from "intruders", and where apparently IRC is much too often used to gang up on people and defend the admin culture. So, no, I'll not test this (or anything else, VE or Flow or whatever) on Mediawiki anymore, depriving you of an early warning when the next thing goes completely wrong. Of course, now that you have a QA team, you no longer need volunteer testing anymore. Any explanation of how this bug remained unnoticed? Any empty promises that this time, it is the last time such a thing can happen and things will improve? Perhaps you could put the checklist online of what you expected the QA team to test, and the test results, so that we can judge whether the test list was insufficient or the tests themselves were wrong? Never mind the basic idiocy of having a very strict test list only, and not a free test as well (use the tool like an admin, like an editor, and like a vandal would), which could have avoided this problem, or the single character "special character" inserter, or the "no way not to insert a gallery" problem, just to name a few of the obvious ones from the last few weeks only. Still, apparently there aren't even analysis documents which can be made available, so it seems unlikely that testing documents will fare any better. Fram (talk) 08:00, 14 February 2014 (UTC)
Tracked in Phabricator
Task T63323
Tracked in Phabricator
Task T63324
Tracked in Phabricator
Task T52379

When you're busy getting this right, perhaps you can consider a few further things:

  • It would be nice if, apart from "left-right-center-none", you could actually remove the location as well, since it isn't a necessary attribute
  • A lot more important: at the moment, if you blank the "width" or "height" fields, you inexplicably get Size values are invalid.. No idea whose idea this message was, but on the contrary, having no size indicator is the default. It is beyond me why the WMF would prefer to reject the default state and call it "invalid". I don't know how much the Wikipedia:Manual of Style/Images is similar to habits or rules on other wikis, but it has things like "Alternatively, a fixed size can be specified in the form |XXXpx, where XXX is replaced by a number of pixels, although this should be avoided where possible, since it overrides the user's default." Why do you promote the alternative, which should be avoided where possible, as the only acceptable version in VisualEditor, explicitly labeling the default as "invalid"? Fram (talk) 12:08, 14 February 2014 (UTC)
I believe that the French Wikipedia avoids pixel settings entirely in favor of upright/percentage methods. This option is at T40129. Whatamidoing (WMF) (talk) 18:38, 14 February 2014 (UTC)
Not pixels, percentages, upright, whatever: just plain nothing: Filename, thumb, perhaps left or right, and caption and alt text; no indication whatsoever of size. This is not possible (and treated as "invalid"!) in VE, and not really captured in Bug 38129, even though at enwiki it is the default. Fram (talk) 08:02, 17 February 2014 (UTC)
I believe it's the default in every wikipedia. In French Wikipedia, the default (and by far the most common) is nothing usually with thumb ; when it's not enough then upright/percentage method is advised ; fixed size is rather unwelcome (except for icons). BTW, the French Manual of Style for images says basically the following: to add an image, use file name, thumb, alt text and caption; for image size, only upright is described, not the fixed size options. In the detailed MOS: quite the same, it's clearly said that fixed size should be rare because it's against accessibility. --NicoV (Talk on frwiki) 08:24, 17 February 2014 (UTC)
Similarly, the German Wikipedia makes it clear that there as well, full size is usually not wanted, and fixed size is rarely wanted as well, and thumb (or "mini" as they call it) is the default: "Grundsätzlich sollten starre Bildgrößen nur in Ausnahmefällen verwendet werden." The same in Italian: "Se non necessario è preferibile non forzare una dimensione fissa per la singola immagine, perché annulla le impostazioni personalizzate nelle preferenze del singolo utente." Dutch: " Als ...px wordt gebruikt, wordt die voorkeurinstelling genegeerd, dus doe dat niet zonder goede reden." Basically, it seems that all major Wikipedia versions use thumb without a size definition as the preferred usage, and indicate that using specific "px" size should be the exception? But VisualEditor decides that on insertion, a page should get a fixed size immediately, and that there is no possibility to remove it (change, yes, but not remove). Is there any acceptable reason why the analysts, developers, product manager, thought it would be a good idea to ignore the well-reasoned and preferred image handling method of most (all?) Wikipedia versions for no benefit at all (not adding the px size can't be that hard surely)? Obviously, no analysis or documentation is available, as usual, no evidence that any of this has been discussed with any regular editor anywhere. Who are you actually developing this for? Fram (talk) 09:03, 17 February 2014 (UTC)
As I understand it, the addition of fixed sizes on all new images is due to a challenge in Parsoid, not VisualEditor itself, and it is actually harder to fix (without breaking other things) than one might expect. It is a truism in software development that things users believe "should" be easy are not always so easy. And they obviously aren't ignoring this, since they've assigned someone to fix it at T52379. Whatamidoing (WMF) (talk) 19:09, 18 February 2014 (UTC)
"They" may not be ignoring this, but your project/product manager, User:Jdforrester (WMF), clearly is, since as late as this week, he believes that only some "out-there" features in media settings still need fixing... And no, I don't understand why not adding any size specification is difficult, and I don't really care. It was the WMFs decision to implement it like this, even though it goes against the best practices of the vast majority of their customers. I don't care whether it is a Parsoid or a VE problem either, as a user they are one and the same for me. If either of them can't handle such a simple thing, then probably you have made some fundamental errors in your setup. Not the first time obviously. Fram (talk) 19:41, 18 February 2014 (UTC)

Oh dear, from the 15/2 office hours[22]:

  • [17:55:17] <James_F> There were some missing features, like image settings, that didn't make "the cut".
  • [17:55:31] <James_F> And of course, performance wasn't anything like as good as we wanted it to be.
  • [17:56:27] <James_F> As far as I can see, all of these issues have been addressed, with the possible exception of some of the more out-there features in media settings (like link over-rides or "upright" sizing).

(emphasis mine)

@Jdforrester (WMF):, were you really unaware of the lack of "removal of size" or "insert without defined size", even though that should have been a basic feature (the standard option), and was mentioned here above rather clearly on the 14th, i.e. the day before your office hours? Or do you consider "providing the basic, recommended state for most major wikipedias" one of "the more out-there features in media settings"? One would expect the product ma,nager for visual editor to read the main feedback pages before going into office hours about VE, even ignoring the fact that such a basic missing feature should have been well-known. @Philippe (WMF): if you need more examples of the "communication breakdown" between WMF and the wikis, perhaps you can use this as another example? The difference between the reality we encounter and report, and the Good News Show the responsible WMF people try to feed us? (By the way, apart from this, I wouldn't dare to claim that the issues leading to the en-wiki opt-in situation have all been fixed, but it's interesting to see how the WMF or some of their people perceive things). 12:51, 18 February 2014 (UTC)

Whatamidoing added the bug number for "VisualEditor: Do not add size for standard thumbnail images", which has been open since June 2013, with only "normal" importance though. What I don't see yet is a bug for "Allow the removal of size from images", which is similar (and may be solved by the same fix eventually), but is a different issue nevertheless, and nearly as important. Fram (talk) 19:41, 18 February 2014 (UTC)

Not so hard after all

"As I understand it, the addition of fixed sizes on all new images is due to a challenge in Parsoid, not VisualEditor itself, and it is actually harder to fix (without breaking other things) than one might expect. It is a truism in software development that things users believe "should" be easy are not always so easy. And they obviously aren't ignoring this, since they've assigned someone to fix it at T52379. Whatamidoing (WMF) (talk) 19:09, 18 February 2014 (UTC)"

That bug is from June 2013. It has been assigned since July 2013. It must be very hard to fix this and get the default behaviour, as wanted on all large wikipedia versions, implemented. Strange then that I can do it in two steps, only using VisualEditor (and no copy-paste or other "tricks" to import the file): [23]. Please don't tell me that what I did here can't be handled by VE fairly easily as well. Just use some disruptive, out-of-the-box thinking. Note also how VE is perfectly capable of handling files without pixel size settings [24]. The only conclusion I can find is that yes, they are ignoring this completely, which isn't illogical since Jdforrester doesn't consider it to be important anyway. Fram (talk) 10:01, 21 February 2014 (UTC)

Font change

I made a C&P onto https://en.wikipedia.org/wiki/Hashish, but the size of the font is too large. I can't find any button for changing (or discovering ) font size or type.Kdammers (talk) 08:25, 23 February 2014 (UTC)

@Kdammers: Select the text, then use the dropdown for style selection, which also allows you to make something a header, to change it into 'paragraph' style. —TheDJ (talk • contribs) 15:13, 23 February 2014 (UTC)
Looking at the diff, it appears that you accidentally deleted a line, which caused the entire paragraph to be part of the ==History== section heading. Somebody else fixed it for you fairly quickly. Whatamidoing (WMF) (talk) 05:38, 25 February 2014 (UTC)

Minor issues

  • Spacing of buttons: any reason why "help" and "notices" are put together without a space inbetween, but "options" (three horizontal lines) is separated from those by some empty space?
  • The tooltip of the "notices" button gives "$1 notices". It's nice to see that notices have a price :-)
  • The "options" button (the three horizontal lines) has no tooltip
  • "Help" and "Keyboard shortcuts" have the same icon
  • The "three horizaontal lines" dropdown doesn't have a "dropdown" arrow
  • In the "three horizontal lines" dropdown, "options" has a "screen" icon, and "page settings has a "three sliders" icon. Everywhere else (e.g. in "categories", "insert reference"), "options" has the "three sliders" icon
  • Having in the three horizontal lines dropdown first "options", and then three separate entries which are the exact same as those you find in "options", is overkill. Fram (talk) 08:19, 21 February 2014 (UTC)
  1. Yes. It appears that they went to some trouble to make the shape of the buttons different, so that, when both are present, they look like they're related/connected.
  2. T63891.
  3. True. It's T63892, but I don't know if a tooltip will be added. (It's called the "More settings" menu at the moment.)
  4. As they are both help items, they should have the same icon. "Read the user guide" under the Help menu also uses it, and any other place that help is added will also use that same icon.
  5. It's not supposed to have a dropdown indicator. The apparent goal is to have it be consistent with the mobile interface, which has no dropdown indicator (or tooltip).
  6. This dialog is in transition. The "whole-window options" is not actually the same kind of options system as the "three-sliders options". I don't know if they'll standardize the icon according to the label next to it, change the names for some of them ("Options" vs "Optional settings"? "Options" vs "Page options"?), or keep it all the same. It's internally consistent, if you happen to know what the designers were thinking. It's jut not apparently consistent.
  7. I agree. But as I said, this dialog is in transition, so there are a few oddities present at the moment. This may actually be intentional, because if the goal is to remove those three separate items from the More settings menu and place them under Options, then this "duplication" will help regular users have an idea of where to look when they "disappear" from the More settings menu. Whatamidoing (WMF) (talk) 06:47, 25 February 2014 (UTC)

Placement of transclusion icon

Tracked in Phabricator
Task T53548
Tracked in Phabricator
Task T62652
Tracked in Phabricator
Task T53933

The transclusion (yuk, "template" please) icon should be placed in VE at the upper right corner of the displayed template, not at the location of template in the wikitext. Placing it at the location of the wikitext may technically make sense, but it is totally useless for editors of course, who have no idea of where the icon will appear. This works for files, which may also be located visually quite some distance from where they are in the text, so I suppose that it should be possible for templates as well.

Examples:

Preferably templates shouldn't also be "expanded" over the full width of the article in VE mode, making it sometimes impossible to select other elements of the page.

  • North German Confederation, the "list of member states" template makes it impossible to select the 7 kreuzer postage stamp on the right
  • Kuota, the "portal" links are not editable in VE because the Italian cycle manufacturers box hides it
  • The same happens here.

Note that e.g. in the last example, if you delete the navboxes, you change the issue into the first one I report here, the icon for the portal template is way up high on the page... Fram (talk) 14:14, 25 February 2014 (UTC)

It looks like these are already known. (North German Confederation works for me.) Whatamidoing (WMF) (talk) 22:51, 26 February 2014 (UTC)

Add content and other transclusion mysteries

In a transclusion, you can "add content" (bottom left, [] icon. Why? It adds text outside the template (infobox, whatever), in the body of the article. Mind you, this is a good way to add wikitext while working in VE (e.g. an image without size in pixels), but that can hardly be the purpose, as it runs exactly contrary to what the devs have always defended. So what is the purpose actually?

Looking at that part of the interface, you also get on the left a greyed out "+" and on the right greyed out "up" and "down" indicators. I have never seen these activated, so what are they doing there? Fram (talk) 09:51, 21 February 2014 (UTC)

I think the add content is for infoboxes or the like created with several templates (a begin template, several templates for the contents, an end template). --NicoV (Talk on frwiki) 10:40, 21 February 2014 (UTC)
Perhaps, but you also have an "add transclusion" to add multiple templates in a row. I don't see an actual example where this "add content" would be useful, but any diff of a case where this was used as intended (not to circumvent the wikitext restrictions like I did) is welcome. Fram (talk) 11:13, 21 February 2014 (UTC)
I think something that in wikitext is composed of a begin template (containing for example a table start), content and templates, end template (containing a table end), and that appears as a whole for VE. See maybe Parastagmatoptera_serricornis on frwiki. There's no actual "content" between templates in this example, but it's just an example. I'm also thinking of some situations where you use 2 templates to make a collapsible box, the content between the 2 templates can be simple wikitext. --NicoV (Talk on frwiki) 12:35, 21 February 2014 (UTC)
Hmm, yes, it seems like that is the purpose. No idea whether it is truly necessary, and whether it is wise to allow people to really use it as a "content" field instead of just adding some kind of "break" where needed. Fram (talk) 12:48, 21 February 2014 (UTC)

It is indeed needed for situations where you need one template to balance out another, wrapping content. For instance: {{div col}} and {{div col end}}. You cannot use the one, without also using the other, the result would be invalid. I think the UI for it is indeed slightly confusing to a lot of people. I'd make the presence of these widgets a bit more selective/context sensitive. The information for this could be added in the TemplateData description for instance, and then the widgets presence can be based on knowing that the template needs to be balanced and can wrap content. —TheDJ (talk • contribs) 15:21, 23 February 2014 (UTC)

Note that in the example provided by NicoV, [25], when you edit the infobox to the right, the "up" and "down" arrow become active, so at least they sometimes are alive. I don't dare to say that they sometimes "work" though, since using them in that example gives very strange results, and nothing which seems to me useful. The subtemplates are apparently being moved by those arrows, but in totally unpredictable ways. Only using these up and down arrows, whole parts of the infobox disappear on saving. Some explanation of what this is supposed to do would be welcome, with examples of places where it works as expected, and otherwise preferably these things should be disabled until they work somewhat better than this. Fram (talk) 08:47, 24 February 2014 (UTC)

It doesn't seem unpredictable, but just as usual: not working and clearly not even tested before being put into production. It seems that when you move a template, VE simply removes all of its parameters in the result (but isn't really aware of it, because the removed parameters are not described any more...) --NicoV (Talk on frwiki) 09:20, 24 February 2014 (UTC)
Not only that, it also removes some templates completely, e.g. here one of the two "s-bef" is gone, and in the other one the parameter value is gone (the parameter stays, but the value is gone...). Also, when I click on an "up" or "down", the focus is totally gone, and knowing what actually was done is hard to say the least. Anyway, like you say, again clearly not tested at all. I guess you aren't suprised either :-) Fram (talk) 09:35, 24 February 2014 (UTC)
I think you'll get a better idea of the purpose if you look at something like Kilt#See also. The up-arrow allows you to rearrange the template set like this.
When I asked about this (months ago), it was uncertain whether this system was going to be retained in the long run. mw:Parsoid/MediaWiki DOM spec#Transclusion content and T52546 indicate that the Parsoid team expect to significantly limit this feature. Whatamidoing (WMF) (talk) 05:59, 25 February 2014 (UTC)
Even there, it works badly. The "down" arrow activates the "save page", but doesn't do anything at all. I can move things up, but not back down again (which you are apparently aware of, as you so nicely state "The up-arrow allows you to rearrange the template set"). And, as ha been said, the "purpose" may be what you show, but the "implementation" is totally botched, as usual. A tool which works partially in a very narrow set of circumstances, but causes serious problems in most circumstances, should be disabled until it is fixed. Letting this stay "live" is not a service to the few editors using this. (By the way, while I understand why you try to provide everything in VE, this is a very nice example of how "visual" isn't easier than "wikitext" to edit; just compare the screen you get when editing this "see also" section in VE, with the one you get when you try to edit this in wikitext mode; VE is definitely not the easier or more user friendly option here) Fram (talk) 08:07, 25 February 2014 (UTC)

Example: here all I did was use the "up" button four times: "up" the lowest "content", "up" the lowest s-aft, "up" the lowest "content" again, try to "up" the lowest s-aft again. Result when you want to save it: the s-aft has simply vanished :-) Fram (talk) 08:59, 25 February 2014 (UTC)

So, User:Jdforrester (WMF) or anyone else from WMF, any replies here (to be fair, Whatamidoing has explained the purpose, and a related bug)? Any reason why this aspect (the arrows), which are either just not working (the "down" arrow), or working extremely poorly (the "up" arrow), is still enabled, and not even a bugzilla has been made, or some promises about improvements? Any reason why these things have been put into production in the first place in the state that they are in? The chance of getting the right result with them is infinitesimally smaller than the chance that you'll break something with them. Seems like a first-rate candidate to remove, rethink, improve, test, test, test, and only then bring back to life... Fram (talk) 15:27, 27 February 2014 (UTC)

A simple test of template editing - result: fail

So I thought I'd try out using VE to do something simple for the first time since turning it off during the rollout fiasco. Using the current version of Chrome, I made a simple test page with only a couple of userboxes on it.

VE failing to align two simple float left boxes.
Poorly designed transclusion dialog with a confusing content model and mish-mash of clickable and unclickable elements.
VE treating two boxes as one for no obvious reason.

Going into VE mode displays the boxes out of alignment. Clicking one ("User wikipedia") highlights it. Double-clicking it does nothing. The single click has produced a jigsaw piece icon. Clicking it I get a dialog box called "Transclusion". In it, there are numerous icons. Some of them are clickable, some are clickable but do nothing (blue circles), some are not clickable at all (red circles). Clicking the magnifying glass icon only places the cursor in the "Parameter name" box, which is the complete opposite to the established use of a magnifying icon in a search box on every page on this entire site.

The "Add parameter" section does not advise me what a parameter might be, or where it could be found. Typing anything in it produces a blue bar stating "unknown parameter" (note: the template in question is not parameterized, but VE does not explain that). Clicking the blue bar opens an input area below labeled with whatever you typed. The input area is accompanied with a trashcan icon. Clicking the trashcan icon does not follow the reasonable expectation of deleting the parameter, but instead collapses the parameter input and returns your cursor to the "Add parameter" entry.

Clicking the jigsaw piece icon creates an input area on the right to locate a template by searching and add it to a list of templates visible on the left side of the dialog. So apparently this tool operates in some strange mode where a page is modeled as a list of blocks, or a stream if you prefer. So, rather than editing a given transclusion, you're editing the whole page. Or is it just the area around the template you selected? Who knows? The blocks in the list can't be moved naturally by dragging and dropping them; the user has to do that by clicking some poky little up/down buttons in the corner of the dialog, in the manner of software from over a decade ago.

Using the "add template" feature to add another simple userbox template results in two templates that appear to be joined together. Clicking either highlights both.

I've now turned VE off again.

I'm not going to mince my words: this is crap. VisualEditor was unable to present a reliable and accurate representation of an incredibly simple piece of content. The interface it presented for me to modify it was confusing, violated reasonable and established expectations of GUI elements, and malfunctional.

Everyone associated with this embarrassingly amateurish effort should be ashamed of themselves. — Scott • talk 14:50, 27 February 2014 (UTC)

Hi Scott, as a first remark, editing a template which does not feature TemplateData yet, like the one you chose, is certainly not an optimal experience. Should you want to see how that inspector really works, try a Cite something one (like Cite web). In this case you might argue that you're overwhelmed with content, but at least you can get an idea of how the system is supposed to work on that regard (and I can't think of a simpler example right now, sorry!). Best, --Elitre (WMF) (talk) 15:00, 27 February 2014 (UTC)
Double clicking on the template to open it is on its way, 50996 is patch-to-review. --Elitre (WMF) (talk) 15:09, 27 February 2014 (UTC)
The jigsaw icon piece appearing where it shouldn't (I experienced this while VEditing your page) is the just assigned 51548. --Elitre (WMF) (talk) 15:14, 27 February 2014 (UTC)
Improve the UX of the template editor is being asked by 61822 (note that some of your remarks are no longer valid when you're dealing with a template correctly feat. TemplateData: for example, the magnifier icon is actually a search field that will return useful results when searching among all the possible parameters, and looking into their description, not just to their title - again, something that can be tested via the Cite web template, for example). --Elitre (WMF) (talk) 15:26, 27 February 2014 (UTC)
As for those templates not being draggable, 62006. --Elitre (WMF) (talk) 17:36, 27 February 2014 (UTC)

Most templates have a /doc subpage. Instead of reusing this, a completely new system is built that has to be added to every template. While having the templatedata may ultimately be good, in the short and midrange term it would be much better if the /doc page was visible (or easily accessible) when using a template in VE. Use what is available instead of reinventing the warm water. Fram (talk) 17:59, 27 February 2014 (UTC)

Hi there. What you say is true, although I like the way that information is provided right now in the editor (it's automatically showing compulsory parameters, allows searching among the other ones, gives short explanation...). Still, as some noticed in the past, this might be not enough - 49772 asks at least that the full documentation is linked, for example, and I think we'll see more on that front in the future. I am really clueless when I find a template lacking TD and agree that searching for its user guide manually is... meh. --Elitre (WMF) (talk) 18:19, 27 February 2014 (UTC)
(e/c)/doc is useless, it's interpretable by template wizard editors only, and it is not consistently authored, so you can't program any tool against that information. However, it might be a good idea to show it as a fallback when there is no templatedata. Or at least add a link to the documentation page, if we know it is there. —TheDJ (talk • contribs) 18:36, 27 February 2014 (UTC)
Bug report VisualEditor
Mito.money Please app{}
Intention: I added interwikilinks while i was in de VE edit mode
Steps to Reproduce: i didnt try to reproduce
Results: the VE page reloaded and the edits were gone
Expectations: that my edits were either saved, or the page wouldn't reload?
Page where the issue occurs nl.wikipedia.org
Web browser firefox 27.0.1
Operating system Ubuntu
Skin default
Notes:
Workaround or suggested solution <3 the tool!

Stratoprutser (talk) 11:13, 26 February 2014 (UTC)

Hi Stratoprutser, and thanks for your note. Can you tell me exactly what you did to create these links, and especially whether you were trying to end up with an interlanguage link or an interwiki one ([[:de:Example]] vs [[de:Example]]—the colon may be critical here)? Whatamidoing (WMF) (talk) 22:54, 26 February 2014 (UTC)
Hi, thanks for your feedback, I used the add languages button at the interwikilinks, in the bottom of the left sidebar, while already editing in the ve-mode. There were no interwiki links yet, so I went ahead and added them, which succeeded, but subsequently the VE-page reloaded without further notice, resetting all my edits. At no point did I enter wikitext (so no interlanguage links were involved) :) -- Stratoprutser (talk) 11:28, 27 February 2014 (UTC)
Hi, I think this is not related to VE. This is how that system now works, it instantly adds a new item to Wikidata. In order to add the link succesfully, you actually have to click on a button which says something like "OK, add it to Wikidata and reload the page". Even if you just close the box (rather than clicking there), this is what you get. HTH, --Elitre (WMF) (talk) 12:51, 27 February 2014 (UTC)
To be clear: if you used the tool that you can see in the picture, that adds interlanguage links. That's what I have "in the bottom of the left sidebar". --Elitre (WMF) (talk) 12:59, 27 February 2014 (UTC)
Apparently, James knows a lot about Wikidata! Perhaps he can tell us whether there's something that could be done with regards to this behavior? I mean, I was trying to test Stratoprutser's steps, and in order to do so I ended up "vandalizing" Wikidata, which is certainly not what I was expecting. --Elitre (WMF) (talk) 13:07, 27 February 2014 (UTC)
That's partially related to VE. For articles without existing interlanguage links, the link is different (see fr:Catégorie:1543 en Europe for example "Ajouter des liens"). When using the wikitext editor this link disappear so you can't loose your modifications, while when using VE this link is still here. I can't try what happens if you click on it right now. --NicoV (Talk on frwiki) 13:12, 27 February 2014 (UTC)
Merci, NicoV. That's something I forgot to check after some cache issues I had while testing for this bug. I also now think that s/he might be actually mentioning a gadget which does something completely different. Bugs as 52383 and 52105 seem related. --Elitre (WMF) (talk) 13:42, 27 February 2014 (UTC)
Yup thats what I meant, sorry for the confusion. -- Stratoprutser (talk) 14:36, 27 February 2014 (UTC)
In this case, this is now a Wikidata bug. --Elitre (WMF) (talk) 14:55, 28 February 2014 (UTC)

Edit conflict handling is horrid

In this edit, I ran into an edit conflict. Nothing other than the fact that there were changes that I didn't make (the reversion of the other edit). This situation needs to be improved, especially since inexperienced editors are intended to use this. There at least needs to be a warning of this. A possible solution would be to bump the editor into the source edit-conflict mode, or a new equivalent could be designed:Jay8g [V•T•E] 05:02, 28 February 2014 (UTC)

Hey Jay8g, so, if I understand this correctly, you didn't get the usual wikicode edit-conflict window, right? --Elitre (WMF) (talk) 10:59, 28 February 2014 (UTC)
To be clear: I just tested this, and what happens is you get a first warning message which says "Your changes could not be saved because of an edit conflict. Would you like to resolve the conflict manually?", if you go on, it falls back to the edit-conflict mode we commonly use, with comparison of edits and everything. So if this is not what you saw, please let us know browser/OS/skin. Trying again as an unregistered user will make sure that what you experienced was not caused by some conflicting gadget/setting in your Preferences. Thanks! --Elitre (WMF) (talk) 14:18, 28 February 2014 (UTC)
No, I did not see any of that. If that happened, I would have been perfectly happy (see my suggestion above). I tested it at mw:sandbox (up to date and no customization) in these two edits 1 2 (I saved "edit 1" while having the "edit 2" window open) and it still had no warning (see screenshots) (Monobook (en) and Vector (mw), Firefox 27.0.1, Windows 7):Jay8g [V•T•E] 04:36, 1 March 2014 (UTC)
Added to 55392, thanks. --Elitre (WMF) (talk) 16:27, 1 March 2014 (UTC)

A Suggestion For The Transclusion List

Hi, I know everyone is working hard on debugging, and this is very much a minor suggestion, but would it be possible to have "cite needed" work the same way as "citation needed" when you add it as a template. Red Fiona (talk) 23:11, 2 March 2014 (UTC)

The issue there is that the first one is merely a redirect to the second one, but while Citation needed does have TemplateData and works as intended, the other doesn't feature them. This was already noted in 50964 and it actually has a high importance, thanks for raising this again. --Elitre (WMF) (talk) 17:05, 3 March 2014 (UTC)

Often, the link editor describes a link as a "new page" (red link) when it actually exists ("matching page"/blue link). I have not seen this with other states (redirect/disambiguation), but that does not mean it doesn't happen:Jay8g [V•T•E] 01:08, 2 March 2014 (UTC)

Possibly 37901? --Elitre (WMF) (talk) 16:57, 3 March 2014 (UTC)
Elitre (WMF): No, that it about making redlinks red in the general interface, while this is about in the link editor. Also this is generally (exclusively?) the other way: existing articles (often, but not exclusively, redirects) being shown as not existing (redlinks):Jay8g [V•T•E] 02:05, 4 March 2014 (UTC)
Hi Jay8g, you're right, I linked to the wrong bug. There's instead a number of bugs which do seem related to what you say, but in order to choose the right one, I think I need some more details. Can you please provide examples? In my tests I could only reproduce what you say once, and with regards to a redirect. The way the initial letter is written, and in some cases, even the word length, seemed to matter at some point, according to some Bugzilla reports. Thanks, --Elitre (WMF) (talk) 11:18, 4 March 2014 (UTC)
New York Kennedy exists
I can replicate this intermittantly (some links work correctly, others cause issues). Generally, I select text and then modify the link text until I find a working link (which is why this bug is so annoying). I also found that it happened more in normal editing than in testing (I don't know if there is any connection there). I can't find any connection between the ones that cause the error:Jay8g [V•T•E] 04:53, 5 March 2014 (UTC)
Jay8g, sorry for the delay. I have reopened 49502, and provided a workaround. Please provide more examples if this happens again and is not related to redirects. Thanks! --Elitre (WMF) (talk) 12:46, 11 March 2014 (UTC)

Various messages need to be changed to refer to "switch to source editing"

Several messages need to refer to the "switch to source editing" button. These include:

  • The first-use message ("You can keep using the wikitext editor by clicking the "Edit source" tab instead – unsaved changes will be lost.")
  • The wikitext warning ("Click "Edit source" to edit the page in wikitext mode – unsaved changes will be lost.")
  • The help menu notice ("Click "Edit source" to switch to wikitext mode – unsaved changes will be lost.")

:Jay8g [V•T•E] 22:16, 1 March 2014 (UTC)

So Jay8g, those are MediaWiki messages that can be edited on en.wiki. I can provide their titles, but you'd still need a sysop to change them. Perhaps it'd be better to draft new messages first? A couple of things to bear in mind, in my humble opinion: clicking the Edit source tab still leads to losing unsaved changes, and that's something users might still want to be reminded of; the related 56835 bug isn't fixed yet (I reopened it recently); the position of that feature might change any moment, given that there were complaints about it. HTH, --Elitre (WMF) (talk) 17:18, 3 March 2014 (UTC)
Elitre (WMF): That would work, but a more permanent, core solution (as opposed to a local override) would be better, as this is effectively incorrect information, and a way not to lose changes is useful. As for a replacement, "Click "Switch to source editing" to switch to wikitext mode" would work well for all three:Jay8g [V•T•E] 02:13, 4 March 2014 (UTC)
Not sure about your solution - I'd still be confused, sorry :) Also, see here why James closed a related bug as WONTFIX, while 57699 is still open instead. HTH, --Elitre (WMF) (talk) 12:28, 4 March 2014 (UTC)
On the first-use message, it's probably not important. (They don't haven't made any changes anyway, and it serves as fair warning that the [Edit source] tab is not a good switch-to-wikitext button.) The question on the others is whether the real estate is worth it. In the help menu, it might be. I'm not sure about the wikitext warning. Whatamidoing (WMF) (talk) 17:37, 5 March 2014 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback/Archive_2014_1&oldid=1180253283"