Wikipedia:VisualEditor/Feedback/Archive 2015 1

Add links
From Wikipedia, the free encyclopedia

Table cell can't be edited if it in sort column

Tracked in Phabricator
Task T85648

Dtyger (talk) 09:07, 10 December 2014 (UTC)

Hi Dtyger,
Is your question about List of highest funded crowdfunding projects? I just tried to edit it, and I was able to change a cell in a sorted column. (I didn't save my change, because that would have made the article worse.) Did you double-click inside the cell before trying to type? That's one odd thing about how VisualEditor is handling tables at the moment, and it's not very intuitive. Whatamidoing (WMF) (talk) 18:41, 10 December 2014 (UTC)
Tracked in Phabricator
Task T85462
Yeah, my question is about List of highest funded crowdfunding projects. I've tried to edit sort column in Firefox 37.0a1 (nightly) and no success, but I can successfully edit all other columns. Dtyger (talk) 05:11, 31 December 2014 (UTC)
If you look at User:WhatamIdoing/Sandbox, you'll see a copy of the top of the table. I edited it in Firefox. All the columns except the refs column are "sort columns". I could edit each cell except the (green) ones whose formatting are set by {{yes}}. Were those the only cells you were trying to edit? Whatamidoing (WMF) (talk) 01:02, 1 January 2015 (UTC)
Can I ask about the type of tables on pages like The Vampire Diaries (season 6) ?? I asked about it over a month ago and there should be an update two weeks later but I didn't see anything new. Those tables still can't be edited with VE. TeamGale 00:17, 15 December 2014 (UTC)
Is anyone still checking this page?? Where are the updates and answers?? There are threats that are going to be archived without any answer...not sure if some already did... TeamGale 05:07, 18 December 2014 (UTC)
Can't help you with your question, but I took the liberty to slightly decrease the archive ratio (from 5d to 10d). Maybe that'll help to get older questions answered more often. (5d was definitely too fast with the current traffic). GermanJoe (talk) 05:23, 18 December 2014 (UTC)
Thanks for that. It will sure archive discussions later and leave them for more days in the page and hopefully everyone will get an answer. But no matter the traffic, the VE people should check this page at least once a day, maybe once in two days imo. They can't leave things unanswered for so long. I see things waiting an answer for 4-5 days, maybe even more. And like I said, I don't know if things were archived without any answer at all. I can understand not be checking in the rate it used to happen but, so many days? It's unacceptable. Thanks again for your help. TeamGale 07:18, 18 December 2014 (UTC)
This page usually gets read every day (not always on weekends and holidays), but there isn't always time to publicly reply to every comment on the day that it's posted.
There has been no change to the status of editing tables that aren't really tables, but are tables built out of complex templates that individually produce odd scraps of HTML. The relevant dev has been told about the problem (that specific example, in fact), and I think I can reasonably promise that it will not be fixed for at least another few weeks, and probably not for several months. Whatamidoing (WMF) (talk) 20:05, 18 December 2014 (UTC)
I never asked to get an answer the same day. I remember when the traffic was much more on the page, the comments were getting an answer almost within an hour (at least most of them). I know that this can't happen right now due to the traffic. What I said was that 2-3 days is a reasonable time to get an answer, isn't it? And you say that the page gets read usually every day. So in 7 days there was not a 30min time to answer to the comments??? That's a little odd if the page is indeed gets checked every day. And it's even more odd that the moment someone complained for no answers, all the comments were answered the same day. Anyway...I don't think what I was saying and asking was unreasonable. Personally I respect the work you are doing with VE and was always very patient with the time bugs were needed to get fixed. I suppose an update or an answer to a comment/question within 2-3 days is not too much to ask.
As for the update thanks. I can imagine that it was the specific example that was given since I was the one who reported it over a month ago. I was told then that it would take at least two weeks to get fixed and at the moment I could not get a bug number since the database was moved. I guess since I was told it was going to take at least two weeks and didn't have any bug number to check, it's normal to ask for an update after a month, right? Can I get a bug number or report now? Thank you. TeamGale 09:44, 19 December 2014 (UTC)
Don't mean to be rude but I see that 10 days for threats to go to archive are still not enough to get an answer? TeamGale 07:34, 29 December 2014 (UTC)
I've filed this as T85462, but I suspect that it's going to be marked as a duplicate soon. I've just been unable to find out which of the bugs it's actually duplicating, because most of the team is on vacation for the holidays, including the dev who does most of the table work. Whatamidoing (WMF) (talk) 18:51, 29 December 2014 (UTC)
Thanks TeamGale 10:36, 31 December 2014 (UTC)

Custom text for links

It would be nice if when creating a link in the VisualEditor, I can use custom text. So a link pointing to the wiki page "US Declaration of Independence" can instead just display the text "Declaration of independence". I have to always stop using the VisualEditor whenever I want to link because of this limitation.Lugevas (talk) 17:09, 1 January 2015 (UTC)

VE will do this. Type "Declaration of Independence" (or whatever text you want to use), then select that text and press Ctrl-K (for Windows machines; I don't know the shortcut keys for other OSes). Then overtype the default text with the name of the article you want to point to. Mike Christie (talk - contribs - library) 17:18, 1 January 2015 (UTC)
Thanks, I will do that from now on and continue to use VE.Lugevas (talk) 19:42, 2 January 2015 (UTC)

Remain in edit mode after Save

Tracked in Phabricator
Task T68847
Bug report VisualEditor
Mito.money Please app{}
Intention: Save time by not having to click edit again after saving
Steps to Reproduce:
Results:
Expectations:
Page where the issue occurs
Web browser Chrome 39.0.2171.95
Operating system Windows 8
Skin
Notes:
Workaround or suggested solution

Lfstevens (talk) 19:56, 5 January 2015 (UTC)

This has been suggested before (twice, I think). Originally, the idea was to make it work as much like the wikitext editor as possible, which means not permitting saves without also exiting. However, making it work more like a word processing program (where people normally save periodically without exiting) is being considered.
The major foreseeable downside is that it might be slow (possibly exactly as slow as saving the page, exiting, and re-opening the page, although that's not certain). Whatamidoing (WMF) (talk) 22:07, 5 January 2015 (UTC)

Editing a bare url

I haven't figured out a way to cover an existing bare url reference using VE. What I'd like is when I open the dialog, to see two fields, one for the url and one for the covering title.

Here's the process:
  1. Select the link (called a "simple link" by VisualEditor).
  2. Open the link inspector (press Command-K or click on the 'links in a chain' icon in the toolbar).
  3. Click the 'Add label' button at the bottom of that box.
  4. Click inside the middle of the now-visible URL.
  5. Type the label that you want.
  6. Delete any remaining parts of the URL that you don't want.
NB that if you skip step #4 and just start typing, you will only get to add a single character, which is almost certainly not what you want.
User:John Broughton, do you remember writing this out in the user guide? I don't remember making screenshots for it, so I bet this is another thing that needs to be explained. (At what point do we start splitting the user guide into multiple pages?) Whatamidoing (WMF) (talk) 22:17, 5 January 2015 (UTC)
Tracked in Phabricator
Task T53798
@Whatamidoing (WMF): No, I'm fairly sure I didn't explain this in the user guide, because content that is a url plus a title only is relatively rare in articles: these semi-naked urls are normally found only in the External links section, infoboxes and similar templates, and image captions. And it's much cleaner to type the title first, select it, and then add the link.
As for multiple pages, I agree that the longer the User guide gets, the less useful it is. But that's part of a more general problem - for help within VE, it would be far better to have lots of context-specific links - so, for example, the "Insert media" dialog should have a help link that leads to a page with both VE-specific information and information about policies and guidelines for media in Wikipedia articles - or at least, links to other pages about media in Wikipedia. In other words, VE help should be the gateway into everything an editor needs to know about editing, but in a layered way - a bit of general information, then VE specific information, then links to more and more information on other, non-VE pages. -- John Broughton (♫♫) 21:35, 6 January 2015 (UTC)
I believe (I might be wrong) that in-software help means writing an official non-Wikipedia-specific version and sending it out to translatewiki.net for translation, and that local updates require intervention by an admin. Is it worth that? Whatamidoing (WMF) (talk) 18:44, 9 January 2015 (UTC)

Change cite type

VE provides no way to switch the type of a citation from, e.g., web to journal. This can happen when one editor adds a ref that is latter completed by another editor.

You are correct: This cannot be done at this time. I've talked to the product manager, and it is uncertain whether that will ever be possible. The challenge is that VisualEditor has no way of changing parameters' names, either, and if the parameters being used weren't exactly matched, then you'd have to delete them and re-add all of those. It could end up being much more difficult than removing and re-adding it (especially once mw:Citoid allows automatic formatting for all the commonly used books and websites). Whatamidoing (WMF) (talk) 22:11, 5 January 2015 (UTC)
To restate, once Citoid works, all you'll need to do in this circumstance is (a) delete the Cite Web reference, (b) start a Cite Journal reference, (c) type/paste the PMID into the cite, and (d) close the new reference (because Citoid will handle all the other parameters). That's actually easier than editing the reference using the wikitext editor.
However, all this does raise an interesting point: what if the reference is used multiple times? If it is, deleting and creating a new citation in VE isn't particularly efficient: you have to go every place the old citation was, delete it, and then do a Cite Re-use. Is it perhaps worth complicating VE further by adding a Cite Replace option/dialog? -- John Broughton (♫♫) 20:55, 6 January 2015 (UTC)
I'd be happy to see people's opinions on this. Currently, I'm thinking no, but I could be convinced the other way. Whatamidoing (WMF) (talk) 18:45, 9 January 2015 (UTC)

Working with citations inside tags

Tracked in Phabricator
Task T52474

It appears that if you have a ref inside a group note (e.g. inside a tag) and delete all other copies of the ref, VE is unable to transfer the base text to that copy of the ref, so the citation is lost. This makes sense because as I understand it VE is not yet able to work inside these tags. Hence I suspect this isn't worth a bug, but I thought I'd mention it here in case someone sees a reason to log it. Mike Christie (talk - contribs - library) 01:54, 8 January 2015 (UTC)

Thanks for your note. It appears that this is part of phab:T52474. Whatamidoing (WMF) (talk) 18:56, 9 January 2015 (UTC)

Navigation with cursor keys adjacent to an image

Bug report VisualEditor
Mito.money Please app{}
Intention: Use shifted cursor keys to select text
Steps to Reproduce: Click on the first letter of a word, with an image to its left

Use shift-down arrow to extend the selection. Shift-down arrow a second time has no visible effect. Please mention if it's reproduceable/if you attempted to reproduce or not. -->

Results: Instead of extending the selection by 1 line, it selects the whole paragraph.
Expectations:
Page where the issue occurs
Web browser Chrome 39.0.2171.95
Operating system W8
Skin
Notes: I've seen other anomalies when using extend select
Workaround or suggested solution

Lfstevens (talk) 20:38, 5 January 2015 (UTC)

Lfstevens, I can't reproduce this in Safari or Firefox on my Mac. Does this happen to you every time, in every article? Can someone else with Windows 8 give this a try and let us know if it happens to you, too? You can click here and scroll down to the ==Character formatting== section to find a left-aligned image if you want to test it in my sandbox. Whatamidoing (WMF) (talk) 22:35, 5 January 2015 (UTC)
@Whatamidoing: I just checked Partition of Bosnia and Herzegovina.

On Firefox Nightly 37.0a1 (2015-01-04) I placed the cursor a the beginning of the subhead Bosnian Croat involvement. I then typed shift-down-arrow once. That highlighted the line. I pressed it a second time and it selected the next two paragraphs. A third time had no effect. A fourth time selected the next two paragraphs and a quote.

On Chrome, the 2nd sda selected the next paragraph. The 3rd selected the following paragraph. The 4th selected a further paragraph. The 5th selected several paragraphs. Lfstevens (talk) 03:47, 6 January 2015 (UTC)

Lfstevens, thank you for this detailed response. I've been e-mailing the dev about this. Is the presence of an image actually necessary? I had some weird cursoring yesterday (in Safari 6.2.2 on Mac OS 10.8.5) on an image-free page. Whatamidoing (WMF) (talk) 18:47, 9 January 2015 (UTC)
Tracked in Phabricator
Task T86794

I tried Kludge. I put the cursor on Recapitulation. The first 4 sdas operated correctly, but the next several caused a screen flash, but the selection did not extend to the indented para below. Lfstevens (talk) 18:56, 9 January 2015 (UTC)

That's a separate bug; the indented paragraphs are "alienated content" and can't be selected or edited. Whatamidoing (WMF) (talk) 18:09, 14 January 2015 (UTC)

Cursor focus in edit summary

After the recent changes the cursor does not automatically focus in the edit summary window when you save, which I think it should. I'm pretty sure it used to. Chrome, Windows 7. Mike Christie (talk - contribs - library) 13:58, 10 January 2015 (UTC)

Thanks for the note. It's a known bug. The fix is at mediawiki.org, and should be here in about an hour. Whatamidoing (WMF) (talk) 18:50, 14 January 2015 (UTC)

Redirect bug

Tracked in Phabricator
Task T86827
Bug report VisualEditor
Mito.money Please app{}
Intention: Making a redirect
Steps to Reproduce: First i clicked Page options then Page settings, checked Redirect this page to (enterd destination page) but not Prevent this redirect being updated when target.. finally i got redirect but also text __STATICREDIRECT__. And yes it is reproduceable just try to make redirect
Results: I got redirect, and option that i did not wanted
Expectations:
Page where the issue occurs
Web browser Firefox 34 x32
Operating system Win7 x64
Skin Vector
Notes:
Workaround or suggested solution

Milićević (talk) 15:36, 11 January 2015 (UTC)

Thanks. This appears to be fixed in the test wiki, but not at mediawiki.org yet. I'll see if they can pull the patch forward so that it gets here sooner. Whatamidoing (WMF) (talk) 20:03, 14 January 2015 (UTC)

Table editing

I just tried out the VE table editing tools at the telephone numbers in Australia article. It worked really well; big thanks to the VE team for putting so much work into this. So much easier than mucking around with the horrible mess of pipes and stuff that make up our table syntax.

My only issues were that it took me a while to realise that the text style dropdown turns into a table cell style dropdown when you select a cell. I think a right-click pop-up menu to change cell styles, merge cells, etc. would be a useful addition. And I ended up having to switch to source editing, because I wasn't able to change the background color of the cell.

Anyway, well done to the VE team for making table editing a pleasure rather than a pain! — This, that and the other (talk) 05:20, 11 January 2015 (UTC)

Thanks for the feedback, This, that and the other. The team agrees with you that the location of various controls needs to be changed. James F has been a little less certain whether setting table cell colors is a good idea. Would that "encourage" people to use colors in inappropriate places? Whatamidoing (WMF) (talk) 18:54, 14 January 2015 (UTC)
It's an interesting question. I think it should eventually be provided, although it doesn't necessarily need to be very prominent in the interface. In the long run, though, we will want to be able to edit tables like those at Comparison of operating systems using VE, as they are an absolute pain to edit using wikitext. That would require support for {{yes}}, {{no}}, etc. type templates, which might have to be provided using custom enwiki-specific (or at least Wikipedia-specific) code. — This, that and the other (talk) 23:42, 14 January 2015 (UTC)
It might be possible to add it, but then disable it per-wiki (or maybe even per-namespace). But that wouldn't stop people from copying rainbow-colored tables over. Whatamidoing (WMF) (talk) 17:34, 20 January 2015 (UTC)

Can't add text or another template inside existing reference, after Cite web

I can't see any way to anything to an existing reference using {{cite web}} reference other than template parameters. For example, a typical usage of {{cite additional archived pages}} is <ref>{{cite web|...}} {{cite additional archived pages|...}}</ref>. But VisualEditor just brings up a Cite web dialogue when I try to edit an existing reference formatted with {{cite web}}, without any way to add anything after that template. - Evad37 [talk] 01:51, 15 January 2015 (UTC)

I haven't done this for a while, but the process is (or at least used to be  ;-) selecting the ref (the "[1]") and then choosing "Basic" from the "Cite" menu. Whatamidoing (WMF) (talk) 17:32, 20 January 2015 (UTC)
Thanks @Whatamidoing (WMF): That does actually work, but it isn't mentioned in Wikipedia:VisualEditor/User guide, and it certainly isn't intuitive – i.e. it breaks the convention of clicking on the little popup to edit a VE block (templates, images, other edits to refs). Maybe the Cite web (etc) dialogues could have a button at the top to take you to the basic editor, in addition to 'Cancel' and 'Apply changes' - Evad37 [talk] 02:17, 21 January 2015 (UTC)
Yes, it's a little weird. (It was even weirder; for a while, double-clicking on the ref and double-clicking on the popup tab produced different results. [or "is" weirder? I haven't checked the status of that bug for a while, but I expect that it was solved.) Your solution was proposed once upon a time, but that was before the dialogs changed (back in August 2014), so the answer might have changed. I'll ask James F about it again. Whatamidoing (WMF) (talk) 06:36, 22 January 2015 (UTC)

Some hidden comments are visible in VE, some not

Tracked in Phabricator
Task T73085

See Ebola virus disease in VE edit mode. Hidden comments within the text sections are shown by "!" characters in a circle (nice solution by the way). But hidden comments at the start or end of paragraphs are not shown (possibly because they are in a line on their own). This may be a known problem, not really sure - just wanted to double-check to avoid duplicating a bug. If yes, is a fix for the problem in work? GermanJoe (talk) 02:36, 21 January 2015 (UTC)

Yes, it's known; no, there's unfortunately no solution on the horizon. It will be fixed, but "someday" rather than "soon". This particular problem (on a line by itself with only regular text nearby, rather than complicated things like tables) may be solved before the full problem is solved. Whatamidoing (WMF) (talk) 06:41, 22 January 2015 (UTC)

Splitting a paragraph produces a nowikied leading space

Bug report VisualEditor
Mito.money Please app{}
Intention: Split one paragraph into two.
Steps to Reproduce: #Load or create a page with one or more lines of text.
  1. In VisualEditor, press enter to split the line/paragraph into two.
  2. Save or review changes

This appears to be completely reproduceable.

Results: The first word of the new second line/paragraph is preceded by "<nowiki> </nowiki>
Expectations: No leading space, with or without the nowiki.
Page where the issue occurs article diff 1, article diff 2. Sandbox testing. Note the double nowiki if the first character after the split point is a space.
Web browser Firefox 30
Operating system Linux (Xubuntu 13.10)
Skin Monobook
Notes: The article diffs are not mine, I spotted them in a discussion about the issue at user talk:Redrose64. T78137 notes that intentionally adding a leading space is not possible in VE. Since finding that though, the phabricator search just produces a server error so I can't see if this issue is tracked.
Workaround or suggested solution

Thryduulf (talk) 16:30, 29 January 2015 (UTC)

Comment - I also have the same issue. The OS used is windows 7 with the chrome browser. Mbcap (talk) 17:31, 29 January 2015 (UTC)
Quick reply: it's a known bug. It happens to me in Firefox on my Mac. I find it very irritating. However, I hvaven't heard of them making any progress on it. It isn't 100% reliable, and I'm not sure how to make it happen every time. Whatamidoing (WMF) (talk) 21:48, 29 January 2015 (UTC)

Weird sup tags created

This sup tag contains style, class and an empty nowiki tag: [1]. Nothing was necessary and we should keep HTML code simple. -- Magioladitis (talk) 08:18, 28 January 2015 (UTC)

@Magioladitis: Looks a lot like the user subst'ed a {{citation needed}} template. I'm not sure why they did that: to add a substituted template using VE you literally have to type "subst:fact" (or whatever template) into the template name field. Very strange. — This, that and the other (talk) 11:09, 28 January 2015 (UTC)
User:Nikpapag, do you remember making this edit? Whatamidoing (WMF) (talk) 21:50, 29 January 2015 (UTC)

Cite from URL

Tracked in Phabricator
Task T89043
Tracked in Phabricator
Task T89045

The option, under the Cite menu, to paste or type a URL and have VE (Citoid, I assume) build a citation is great. But [unfortunately, there always seems to be a "but"]:

  • It would be far preferable, after the URL is put into the dialog, and then the user clicks "Insert", that the dialog box remain open, showing the citation that has been built. If Citoid were perfect, then of course it would be fine to close the dialog. But it's not perfect - in the MSNBC article whose URL I used (http://www.msnbc.com/msnbc/obamas-real-record-poverty ), VE/Citoid didn't add a date (though it did create an accessdate), it put "|MSNBC" in the title, it didn't list a publisher, and it didn't create first and last fields for the author's name. So I want the dialog to stay open so I can fix these.
  • The Cite from URL dialog retains the last URL used when opening. It should not. First, it's unlikely that the user is going to want to use the same URL twice. Second, it's contrary to Wikipedia procedures to create two distinct but identical citations. That's why "Re-use" is an item in the Cite menu. So, can we nix the retained URL thing, please? -- John Broughton (♫♫) 21:04, 1 February 2015 (UTC)

Editing transcluded pages

If you go to Windows 10, in the table, and click the edit link, VisualEditor loads as if you clicked any other edit link on the page. The problem is, since the table is transcluded from Template:Windows 10, you can't actually edit the table from VisualEditor.

In short: If you try to edit part of the page, you can edit everything except that part of the page.

But that's just the initial user experience. The actual effect is much worse:

  1. The URL changes to affect the template page, but the article page is still the one shown.
  2. Cancel by clicking read, and the URL bar still shows the template page, even though the article page is shown.
  3. Refresh the page, and the template is now shown, as expected.
  4. Click back, and the URL shows the template page, and VE open. The browser shows the template page without VE.
  5. Click back again, and the URL shows the article page, but the browser still shows the template page.
  6. Click back again, and I'm taken to the site I was at before Wikipedia.

The was all in Firefox, Windows 7.

Suggestion: Either don't show edit links to transcluded sections, or have VisualEditor open the source page for editing. And make sure the URL and screen are in sync, always. -- Ypnypn (talk) 04:51, 5 February 2015 (UTC)

You can't edit templates (anything in the Template: namespace) in VisualEditor, so it's unsurprising that it doesn't let you edit the Template: page.
When I click the first "edit beta" link inside the table, the resulting URL is https://en.wikipedia.org/wiki/Windows_10?veaction=edit#6.4.9841 in Safari but https://en.wikipedia.org/w/index.php?title=Template:Windows_10&veaction=edit&vesection=T-1 in Firefox 35. I think that it's a Firefox-specific bug.
I have not been able to reproduce #5 (in a single attempt), but you are correct that this is a problem. I'll file it in Phabricator and post the bug number (maybe two) later. Thanks, Whatamidoing (WMF) (talk) 18:42, 5 February 2015 (UTC)

Cut-and-paste fails

Every once in a while, I think "VE is really close to being production-ready", and then I try a major editing session and walk away shaking my head. Today it was cut-and-paste. Sometimes it works, sometimes it doesn't. (I was working on the article Aaron Schock.) In general, it seems that if I cut some text that (which included a footnote; not sure if that's critical) and then pasted it in the article immediately following a footnote, the paste fails. (Instead, VE seemed to be inserting what was the prior text in the clipboard.) But this wasn't consistent enough problem to report exactly how to replicate it. It did occur a number of times in different places in the article.

What is replicable, I'm sure, is my failed attempt, in VE, to rearrange the templates in the section "Electoral history" of that article. (The norm for articles about politicians is to have election results shown in chronological sequence, not reverse chronological sequence.) I can't get VE to even cut or copy a template (when I right-click); the closest to doing so is the option to "copy image", which is pointless (pasting produces nothing).

[P.S.: For the sake of the imminent "What would it take to get the Wikipedia community to buy into VE" discussion, I'll also note that Aaron Schock is yet another article where VE can't edit the majority of (quite numerous) citations, because the text of these is embedded within the reflist template in the References section. These may be an abomination, programming-wise, but they are also a reality - yet something else that the wikitext editor can handle that VE can't.] -- John Broughton (♫♫) 06:12, 5 February 2015 (UTC)

  • @John Broughton: there are a couple ways to rearrange templates in VE. You should be able to simply click and drag. In addition, if you first click on a template to select it, and then right-click, you should get a copy (though not a cut) option which works correctly. If you right-click without selecting the template first, you won't—which seems like a bug that should definitely be fixed. At any rate, I tried rearranging the templates on Schock's article and was able to use both those methods successfully. —Neil P. Quinn (talk) 18:21, 5 February 2015 (UTC)
  • Are you two using the same browser and OS? I've been finding that cut-and-paste bugs are not only browser-specific, but also depend on how long I've been editing. I almost never encounter them when I first open a page, but if I've been doing a lot of work (John's "major editing session"), then they appear. I have had them appear on pages that contain zero ref tags, so I'm not sure that the ref tag is necessary (in Safari, at least). Whatamidoing (WMF) (talk) 18:45, 5 February 2015 (UTC)
    • @Neil P. Quinn: Thanks for the new information. If I have a chance, I'll check how that works for me (I'm using a Mac - latest OS - and Firefox - ditto, though sometimes I edit with Chrome). -- John Broughton (♫♫) 01:04, 6 February 2015 (UTC)

@Whatamidoing (WMF): I'm using the latest Firefox on the latest OS X—same as John. Interestingly, I just tried Chrome 40.0.2214.111 and Safari 8.0.2. In both, I could (1) drag templates normally and (2) select a large chunk of content that included a template and then copy and paste it properly. However, unlike Firefox, right-clicking a template gave no 'copy' option (only the 'copy image' option which did nothing), even if I left-clicked it first. I can think of several bugs that could be filed about these behaviors:

  1. In Firefox, the inability to copy a template using the right-click menu without left-clicking first.
  2. In Chrome and Safari, the inability to copy a template using the right-click menu under any circumstances.
  3. In all browsers, the non-functional 'copy image' option (and 'save image' etc.) when right-clicking a template.

Which do you think I should do? My instinct is all of them, and they can be given low priority if necessary.—Neil P. Quinn (talk) 03:29, 6 February 2015 (UTC)

parsoidserver-http: HTTP 503

"Something went wrong". And, of course, I had done a lot of minor editing of an article (Nikolai Myaskovsky).

So - what does this error message mean? I ask because there seems a small chance that I might be able to salvage my editing session if I can figure out what parsoid objects to. (And yes, I tried switching to the wikitext editor; that failed as well.) -- John Broughton (♫♫) 04:59, 7 February 2015 (UTC)

I was able to use VE to edit and save other articles, both before and after getting this error, so I don't believe it means "Service unavailable", except in the sense that "Server failed to perform as expected". I'm looking for a clue as to what parsoid found indigestible.
[Also, copying and pasting the text I edited (leaving out, for example, the templates at the bottom of the article), to another VE editing window, resulted - when trying to save the text - in the same error message.] -- John Broughton (♫♫) 05:04, 7 February 2015 (UTC)
I'm not sure what that one means. It might be a generic undefined error message, rather than one thing. User:SSastry (WMF) should be able to tell us whether it is related to Parsoid. (I'm assuming that the problem happened shortly before you posted this note, and not during the system-wide outage on the 5th, but if my assumption is wrong, then please correct me.) Whatamidoing (WMF) (talk) 20:41, 9 February 2015 (UTC)
Hi User:John Broughton, it may have been a transient server error. I was updating Parsoid code around the same time that you report this error (See the 5:10 am UTC entry for Feb 7 at https://wikitech.wikimedia.org/wiki/Server_Admin_Log). The service was being updated and restarted in the 20 min period before that log entry there (I don't have the exact times recorded). So, the specific Parsoid server that your request went to might have been restarting at the same time. Can you still reproduce the error now when you try to make the same edits in VE and save them? SSastry (WMF) (talk) 20:53, 9 February 2015 (UTC)

Reference visible as wikitext

Tracked in Phabricator
Task T89041

For some reason, the reference at the end of the second paragraph of this section shows up as wikitext when I edit it in VE. Mike Christie (talk - contribs - library) 17:26, 8 February 2015 (UTC)

The named ref was missing a "=" character (added). Still a bit weird, that this caused no other problems outside of VE. GermanJoe (talk) 17:49, 8 February 2015 (UTC)
Thanks for figuring that out. Displaying the broken wikitext isn't a terrible response by VE, but I wonder if it could be handle better, perhaps with a signal that there's a syntax error of some kind there. It could certainly figure out that this is meant to be a ref tag, I would think. Mike Christie (talk - contribs - library) 18:43, 8 February 2015 (UTC)
<ref name"Smith"> is processed the same as <ref> when you're reading a page. Unknown (including invalid) 'commands' are ignored. I'm not sure whether it is desirable to have VisualEditor treat invalid wikitext like it's working. A flag that says something's wrong might be useful. Whatamidoing (WMF) (talk) 21:41, 9 February 2015 (UTC)

Cite from doi, PMID, and ISBN

It's great (as I said in the prior post) to have Cite from URL in the Cite menu. So, a question - existing codes for citing from a doi, a PMID, and/or an ISBN are much better than the current Cite from URL, in terms of building complete and accurate citations. Is there any expected timeline for adding these options to VE? I ask because having these options could move the needle considerably towards the conclusion that "VE is actually a better editor than wikitext, now, for most things". -- John Broughton (♫♫) 21:09, 1 February 2015 (UTC)

Yes, all three of those will be supported, and probably soon(ish). Whatamidoing (WMF) (talk) 07:21, 3 February 2015 (UTC)
(Quick update: The latest word is that ISBNs require some sort of contract with a provider, which in turn probably requires explaining how Wikipedia works to the provider.) Whatamidoing (WMF) (talk) 22:10, 9 February 2015 (UTC)

Firefox cut and paste

Tracked in Phabricator
Task T89025
Tracked in Phabricator
Task T89031

I came to report cut-and-paste problems in Firefox too, probably the same as the section above. My example is replicable, I'm on the latest Firefox on Windows. Please report and fix. PS this annoying bug and having to figure it out and report it interrupted what was shaping up to be a good editing session :-(.--99of9 (talk) 05:10, 6 February 2015 (UTC)

Thank you, 99of9! I really appreciate your effort to discover the minimal reproducible case. Whatamidoing (WMF) (talk) 20:37, 9 February 2015 (UTC)
Ok, thanks for logging it. --99of9 (talk) 03:10, 10 February 2015 (UTC)

Great job

Hello!

I want to congratulate you for a good piece of software. Much better than the Wikitext bug.

--93.213.136.127 (talk) 18:19, 13 February 2015 (UTC)

Thanks for the compliment. I'll pass it along to the dev team. Whatamidoing (WMF) (talk) 20:01, 13 February 2015 (UTC)

Backspacing

When trying to backspace it doesn't work very well. You go automatically to the top of the page. Ferraricaliforniat (talk) 19:51, 15 February 2015 (UTC)

Ferraricaliforniat, thanks for this note. That sounds very annoying. What computer and browser are you using? Whatamidoing (WMF) (talk) 23:05, 15 February 2015 (UTC)

{{sfn}} not detected in reference counting

Tracked in Phabricator
Task T53522

For example, in Ionic compound, the first reference is created by sfn, but VE fails to count it, so when you go into edit_beta mode, all the in-line citations up top get renumbered, and no longer correspond with the numbered list in the references section itself. --99of9 (talk) 03:08, 10 February 2015 (UTC)

{{sfn}} is not supported. However, if you change the {{reflist}} to MediaWiki's core function <references />, the numbering will be internally correct (it will omit all sfn's and citations that are transcluded, but #1 in the ref list will correspond to a "[1]" in the article). The <references /> has the additional advantage of being slightly faster and also being familiar to the millions of people who have used a MediaWiki wiki before, but haven't done much editing at the English Wikipedia itself. Whatamidoing (WMF) (talk) 20:03, 10 February 2015 (UTC)
{{reflist}} is used more than <references />, probably far more. The two are also in no way equivalent to each other. The reflist template reduces the font size of citations, and at this point I'd guess that the vast majority of experienced editors find full-size citation text to be jarring. The template also can be used to put citations into double columns, something I'm not a fan of, but a number of editors do like.
All of which is to say that the idea of changing {{reflist}} to <references /> in articles in order to get VE to work better is just a non-starter. -- John Broughton (♫♫) 16:12, 13 February 2015 (UTC)
If the reflist template has no parameters, there is no difference, except that the template takes slightly longer to produce the same output. The font size on the core function was changed years ago. Look at Theriac#Notes to see the native version, and compare it to the reflist version. There's no difference in the appearance.
The core function doesn't support columns yet, but for single-column lists, we probably should be using the core function. Whatamidoing (WMF) (talk) 20:01, 13 February 2015 (UTC)
@Whatamidoing (WMF): Thanks for pointing out that the font size for <references /> has been changed; I wasn't aware of that. So, to return to the main point of this discussion: Are you suggesting that the solution to how VE handles {{sfn}} is for editors to individually remove, article by article, the {{reflist}} template, replacing it with <references />?
Jumping in here (on the assumption that the answer to John's question above will be "no"), it seems there are two ways out of this: either VE fixes the problem that prevents dynamic redisplay of this template or the template becomes unnecessary because core functions can do everything it does. The former is preferable but extremely hard to do, it's been reported here, and the latter seems unlikely because templates are used in almost infinitely inventive ways. Would it be possible to compromise on a manual refresh in VE? It's clear VE knows how to display these templates correctly on initial page load, so why not allow a user to hit a "refresh unsupported templates" button, or something like it, to bring the display up to date? Mike Christie (talk - contribs - library) 20:06, 16 February 2015 (UTC)
Whatever the possible solution could be, it would be really helpful, if WMF-developers could make a clear statement about their position on "hack" templates and how they plan to address the whole issue: 1) Name the affected templates 2) Clarify, why some (all) of them can't be supported 3) Make a suggestion for a realistic way to move forward. Ignoring the problem for over 1 year now isn't really a constructive approach. I apologize, if such a statement was made somewhere, but I haven't seen it yet. GermanJoe (talk) 20:34, 16 February 2015 (UTC)
If it were up to me, we (meaning all of us as volunteer editors) wouldn't use the reflist template by default or in the Article Creation Wizard. We might consider putting the plain reflist template on the list of things to be removed as part of semi-automatic fixes in AWB or similar scripts. I really don't want to flood watchlists by sending a bot around to change it. In practice, if I'm editing in VisualEditor, and I want to see the current reference list, then I manually replace it. It's not difficult.
Joe, given the number of templates at en.wp, it's probably unreasonable to expect a complete list of all templates that are affected. In general, any source that appears on the page via transclusion of <ref> tags (e.g., {{sfn}}, but also things like some infoboxes) is not supported, in the sense that those transcluded refs do not appear in the reference list on the page and cannot always be edited or re-used. Sometimes this is a minor inconvenience; occasionally this is a major problem. For example, VisualEditor can't rescue refs if they've been re-used in the article, but the original is in the template and the template gets deleted. From what I've heard here and there, it's possible that this will get fixed eventually, but there's a lot of infrastructure that has to change before it's possible. Whatamidoing (WMF) (talk) 06:45, 17 February 2015 (UTC)
It's a bit confusing, that Jdforrester set this bug to "WONTFIX" then (?). Unfortunately this topic is covered in a lot of related - sometimes duplicated, sometimes overlapping - phab bugs. So it's difficult to see what the actual situation is (thanks for the above information on that). GermanJoe (talk) 15:05, 17 February 2015 (UTC)
I don't think that they're planning to fix this specifically, and they definitely don't want to add special handling for it. The situation is more like, in the course of doing some other work, this might "accidentally" get fixed. Whatamidoing (WMF) (talk) 20:30, 17 February 2015 (UTC)

VE still not fit for use, for me

I tried using VE a lot in its early days but abandoned it because of one major problem, probably one of the first bugs I reported (yes, found it on 21 June 2013). I've still kept this page on my watchlist, though I hardly look at many of the changes to it. But there seems to be some discussion around about "things which need to be fixed before it's acceptable", so I thought I'd have another look at VE.

No good.

If I'm trying to add a category, a defaultsort, or a template (eg a stub template), the box in which to do so still obscures most of the article content and can't be shifted out of the way or reduced in size. So I can't see the content I need to read (date of birth, spelling of geographical area, whatever).

There's a discussion at Phabricator as https://phabricator.wikimedia.org/T51969 but it seems to have got sidetracked onto the idea that it's only for categories and defaultsort that this is a problem. Another major area where it's a problem is in adding stub tags, e.g. where I go to add a "nationality-sport-bio-stub" tag and then find there are subdivisions by date of birth or position of play. Also geographical entity stubs where I need to get the spelling of the unfamiliar placename correct.

Until I can see what I'm doing when editing, VE is pretty useless for me. Let me know when it's fit for purpose. PamD 12:48, 15 February 2015 (UTC)

I agree with Pam that this problem makes VE unusable for a lot of editors, but I'm not sure that's the same thing as a requirement for general release, since VE is optional. It will be years, if ever, before VE can do everything the wikitext editor can do, so there will always be some editors who prefer to use wikitext. I think the main requirement for having VE visible by default is that it does no harm -- there should be no corruption of articles caused by bugs in VE. Perhaps other people might feel there are other prerequisites but that has to be the most important one. Mike Christie (talk - contribs - library) 13:46, 15 February 2015 (UTC)
I completely agree with Mike that the main requirement for making VE opt-out is no damages to articles. And clearly, VE is far from being ready for that in regards to bugs that damage articles: some reported months ago are still here (and I don't have the feeling that the VE team is willing to fix them before extending again VE to new users), and new releases bring new ones (see the 2 I reported above).
Missing features and features that don't provide enough help for some editors are important, but I don't think they are the one that are a problem for activating VE on a larger scale. No damage to our work is the most important element. --NicoV (Talk on frwiki) 14:47, 15 February 2015 (UTC)
Tracked in Phabricator
Task T73085
OK, what about the fact that hidden comments aimed at preventing editors from damaging articles are ... well, hidden. See Three-letter_acronym#Examples for an example. There are plenty of other cases where the comment text is informing editors about the consensus achieved after long discussion. An editor who doesn't see the hidden comment will, of course, be likely to edit in ways contrary to its advice/request/requirement. Not damaging the encyclopedia in the same way that totally mangled code damages it, but damaging it through Good Faith editing, in a way they wouldn't damage it if they saw the message left for them by other editors. I'm sure it had a bug number, not sure what happened to it, but it hasn't been fixed. PamD 19:24, 15 February 2015 (UTC)
That's a known bug. It sounds like some progress (covering the case you linked) could be made with a reasonable effort, but that a perfect and complete solution (covering comments placed in non-existent lines, e.g., between formatting elements in a table) might be more difficult. Would you like to nominate it for the Q3 blockers list? All you have to do is change the "Comment" pop-up on the bug to "Associate projects", and then put in the Q# project. (It auto-completes, so if you type "Q3", it'll find the exact name of the project for you.) Whatamidoing (WMF) (talk) 23:04, 15 February 2015 (UTC)
Pam, I agree on this one: everything that leads to damaged articles should be taken into account before wanting to activate VE by default on a larger scale. --NicoV (Talk on frwiki) 17:07, 16 February 2015 (UTC)
I also agree with Pam; I think this should be fixed before general release. Another example of an issue that does not directly cause corruption but can lead to it is T52474, which is apparently a display bug but can lead to a lost citation with a certain sequence of user edits. If everything in this category were fixed, I would probably support general release, assuming nothing egregious was left that affected usability. Mike Christie (talk - contribs - library) 20:10, 16 February 2015 (UTC)
On the strength of these comments, I've added that one to the Q3 nomination list. It'll be on the list for Wednesday's meeting. It's really quick and easy to nominate a bug, so please feel free to do this yourself on any bug that you think represents a serious problem for editors (especially new editors). Whatamidoing (WMF) (talk) 22:22, 16 February 2015 (UTC)
The only stoppers that I can see are of the form: anything which unintentionally damages articles must be fixed before release. This includes snowmen, accidental WP:EGGs, due to the user being unable to tell which part of a pipe or piped text he is editing, empty section headers, empty pipes, damage due to the inability to edit within tables (now mostly fixed), damage due to improper editing of templates within templates (I don't know whether it's fixed), bad reference editing, etc. I don't consider the "current" (at least the last time I checked) inability to edit references with multiple usages a show-stopper, as long as VE fails to edit, rather than damaging links. The important thing is that any bug which damages articles without immediately giving the user a clear explanation of what the damage is, and the ability to cancel it if unintentional, needs to be prevented, even at the expense of making some articles uneditable by VE. I haven't looked at the current list of bugs; in fact, I haven't opened a Phabricator account. Most of the excess "nowiki"s except those which create pipe elements containing only nowikis, could be fixed by a bot, and only make editing a little more difficult than it would be otherwise. Also, we need a clearly marked "abort editing session" button. Working "undo" buttons (including indicating to the user exactly what was undone) would be useful, but I wouldn't consider their absence a show-stopper. I'll have to think about whether the inability to update references listed by {{reflist}}, rather than by <references />, should be a show-stopper. (I know that's part of Parsoid rather than VisualEditor, but, if a show-stopper, it doesn't matter which module the bug is in.) — Arthur Rubin (talk) 06:41, 20 February 2015 (UTC)
I don't know the status of the invisible comment display, but at the very least, accidentally moving an invisible comment should be forbidden. — Arthur Rubin (talk) 06:52, 20 February 2015 (UTC)

Existing ref damaged with nowiki tags

Tracked in Phabricator
Task T90448

Hi, in this edit, an existing reference has been damaged by VE by putting nowiki tags around the opening ref tag. The result is that a correct reference has been replaced by escaped ref tags in the middle of the text. --NicoV (Talk on frwiki) 22:18, 22 February 2015 (UTC)

Parsoid edge case bug. Created T90448. SSastry (WMF) (talk) 15:56, 23 February 2015 (UTC)

Html tags and styles added

Tracked in Phabricator
Task T86401

I am not sure if someone reported this before: [2]. -- Magioladitis (talk) 09:46, 20 February 2015 (UTC)

I'm getting tired of fixing these. another one. Bgwhite (talk) 07:28, 21 February 2015 (UTC)
Thanks for the note. The fix is supposed to arrive here in about 39 hours. Whatamidoing (WMF) (talk) 16:38, 23 February 2015 (UTC)

HTTP 503 errors

For the fourth of fifth time, I've had an edit fail catastrophically - I can't save the edit at all. I can rescue text (by doing a copy/paste to another place), but citations are irrevocably lost. As you can imagine, this makes me quite reluctant to use VE.

I think I've been able to replicate the problem, so I invite someone else to do this:

Update: it now appears to me that only steps 1 (of course), 4, and 5 are needed - the problem is with ending a VE session by using "Cite from URL". Those inclined to test this theory need to enable that functionality via their vector.js page - see User:John Broughton/vector.js for specifics.

  1. Open Seaside, Florida for editing in VE.
  2. In the “Design”section, at the end of the text, press Return/Enter to start a new paragraph.
  3. Paste in this text:  Seaside has no private front lawns. Sod is not allowed, only native plants in front yards.
  4. Put a footnote at the end of that new text: In the Cite menu, select Cite from URL, then use: http://www.nytimes.com/1998/06/04/garden/breaking-ground-seed-reseed-secede.html
  5. Save page. Put “Adding info and cite” as the edit summary. Click “Save page”

What happens then, to me, is the “Save page” button fades to grey. Clicking “Review your changes” generates the following error message, as does resuming editing and trying “Switch to source editing”:

Error loading data from server: Unsuccessful request: parsoidserver-http: HTTP 503.

If someone else successfully makes this edit, please revert the change and post here. I'll then try it again, using both my registered account and another (declared alternative) account to see if the problem persists, and if so, if it's somehow tied to my browser or computer. [I tried both Chrome and Firefox for the above, so I doubt this is browser-related.] -- John Broughton (♫♫) 19:48, 22 February 2015 (UTC)

True, something odd is going on (Windows XP, FF 35.01). While I get no 503 error, the save windows hangs (with disabled save button and an eternal "Saving ..." progress message on top of the save window, when I try to add this citation via Cite from URL at the end of "Escape to Create". Second problem: Cancelling and playing around with save/discard I managed to loose the "Cite from URL" menu item from the VE menu somehow - but can't reproduce it now :/ (the menu item reappeared after leaving and re-starting Firefox). Ignorant guesses: Either the cite function is not ended correctly (and completely) or there is some problem in interaction between cite function and core VE interface. GermanJoe (talk) 21:14, 22 February 2015 (UTC)
Also got the 503 error now, after inserting the cite URL and trying to switch to "edit source" mode with "keep changes" option. GermanJoe (talk) 21:24, 22 February 2015 (UTC)
Some more test info (sorry for the triple-post): The created "cite news" structure appears to be corrupted somehow: Try copy-pasting the cite news item into a completely different article (even after closing your browser and disabling cite URL): the session will hang again. Manually creating a new "cite news" object and copying the single parameters step by step creates a correct citation though and can be saved. GermanJoe (talk) 21:51, 22 February 2015 (UTC)
John, the Citoid service is unstable, and the script you're using to access it is purely experimental. I recommend turning it off, and using the regular (i.e., non-experimental but non-automatic) Cite templates. Once the Citoid service can reliably stay up for more than three minutes in a row, then we'll get the proper tool here. Whatamidoing (WMF) (talk) 16:43, 23 February 2015 (UTC)

Wikimania form issue

Bug report VisualEditor
Mito.money Please app{}
Intention: Other users tried to sign a Wikimania proposal linked at the above link
Steps to Reproduce: n/a, reproduced
Results: "Won't let me put in tildes, won't let me put in my UserName. Won't let me do anything. Just says <no wiki>."
Expectations: Ostensibly to sign the proposal
Page where the issue occurs wm2015:Submissions/How_to_Pick_Up_More_Women
Web browser
Operating system
Skin
Notes:
Workaround or suggested solution

czar ⨹ 13:48, 23 February 2015 (UTC)

Thanks for the pointer. I have replied there. Whatamidoing (WMF) (talk) 16:50, 23 February 2015 (UTC)

br tags inserted inside titles

Tracked in Phabricator
Task T74246

In this edit, a br tag was inserted by VE inside a title which is totally useless and makes wikitext more complex. --NicoV (Talk on frwiki) 15:28, 23 February 2015 (UTC)

Known, but no clear idea why it's happening, and James F indicates that they've made no solid progress on it. Whatamidoing (WMF) (talk) 18:15, 23 February 2015 (UTC)

Useless span tags

Tracked in Phabricator
Task T78540

In this edit, completely useless span tags were added by VE. --NicoV (Talk on frwiki) 17:27, 23 February 2015 (UTC)

That looks like phab:T78540. My bet is that the editor is using Safari, because this problem happens to me all the time in Safari. It's already on the Q3 blocker list. Whatamidoing (WMF) (talk) 18:19, 23 February 2015 (UTC)

Re-use cites doesn't work if cite is in a template

Bug report VisualEditor
Mito.money Please app{}
Intention: I was trying to re-use a cite that is within an infobox template
Steps to Reproduce: #Went to this revision
  1. Delete reference 3, in the first paragraph, and the same cite to reference 3 in the History section.
  2. From the cite menu, choose re-use
  3. Attempt to choose the reference 2, in the infobox, but it doesn't appear.

I haven't checked this on other pages

Results:
Expectations:
Page where the issue occurs https://en.wikipedia.org/w/index.php?title=Russian_Jews_in_Israel&oldid=648740331
Web browser Safari 6.1.6
Operating system Mac 10.7.5
Skin Default
Notes:
Workaround or suggested solution I suspect the only workaround is the wikitext editor

Oiyarbepsy (talk) 04:41, 25 February 2015 (UTC)

It's a known problem. Transcluded refs are 'invisible' to VisualEditor. I don't expect this to get fixed any time soon (although there's some hope for it being fixed eventually). Whatamidoing (WMF) (talk) 23:43, 25 February 2015 (UTC)

Meeting at 00:00 UTC Thursday

The next bug triage meeting will be at midnight UTC on Thursday, which is 16:00 PST on Wednesday for West Coast folks. This one is timed to be easier for some people in Asia to attend. Information about how to join is at mw:Talk:VisualEditor/Portal, but as of this message, the "follow this link" will take you to last week's meeting, which won't be very useful. I'm trying to track down the new link (WebEx requires a new link every single week) and it will be posted there before the meeting starts (because if it isn't, then I can't join the meeting, either.  ;-) .

Minutes from the last one can be read on wikitech-l here. Whatamidoing (WMF) (talk) 05:19, 24 February 2015 (UTC)

Tracked in Phabricator
Task T74048
I hope all the bugs that damage articles are taken into account. An other bug that damage articles is the one where categories get moved in the middle of link inside references, like this edit which also contains an other bug: span tags with id current-appletv spread in the articles in middle of words... --NicoV (Talk on frwiki) 07:30, 25 February 2015 (UTC)
That one was accepted two weeks ago. If you've figured out anything about how to reproduce it, then the devs would still like to have more information. Whatamidoing (WMF) (talk) 23:47, 25 February 2015 (UTC)

Multiple damages

In just one edit, it's obvious that VE is not ready to be activated by default:

  • Categories moved inside a ref tag
  • Completely useless nowiki tags added with italics/bold around them: why VE added italics/bold around nothing ?
  • Several comments outside a table moved inside the table in the middle of sentences (same situation for each apparently)

Honestly, it's been more than a year and a half, how long do we still have to fix so much damages in a production wikipedia? --NicoV (Talk on frwiki) 17:44, 25 February 2015 (UTC)

I think that the last item will be fixed with the patch for phab:T73085. The other two have been discussed above. Whatamidoing (WMF) (talk) 23:54, 25 February 2015 (UTC)

Not possible to add special characters/nonstandard punctuation into citations

Tracked in Phabricator
Task T62657
Bug report VisualEditor
Mito.money Please app{}
Intention: Trying to add an endash into a citation date parameter to clear a flagged formatting error
Steps to Reproduce: While editing using VE,
  1. Click "Cite" in the toolbar, select "Cite News"
  2. Type in data, including publication date of "August-September 2009"
  3. Save edit. An error message appears beside the reference information in the reference section: "Check date values in: |date= (help)"
  4. This is reproduced at User:Risker/comment
Results: The error message was caused because of the use of an ordinary hyphen instead of the regulation endash. I could not find a workaround to fix this in VE, because the "special characters" don't operate at the same time as the cite option is functioning.
Expectations: It didn't occur to me that this would be an issue; however, having seen that it is impossible to add this particular special character from my keyboard, it means that one probably can't add any other characters that do not appear on a standard keyboard, either.
Page where the issue occurs Integral House
Web browser FF 36.0
Operating system Win7
Skin Monobook
Notes:
Workaround or suggested solution Entered the information using wikitext editor.

Risker (talk) 03:13, 26 February 2015 (UTC)

It's a known problem. I can offer several workarounds, of widely varying practicality:

  • Follow the directions in Wikipedia:How to make dashes to type dashes from your keyboard.
  • Don't use a citation template. Select "Basic" from the Cite menu instead. The "Basic" editor will let you use VisualEditor's Special Character tool.
  • Buy a Mac, and use the simple keyboard shortcuts (⌥ Option- for an en dash), or use its native Edit > Special Characters palette.
  • Wait until phab:T62657 is resolved.

There is significant work being done on the special character tool. It will completely change during the coming weeks. Whatamidoing (WMF) (talk) 18:45, 26 February 2015 (UTC)

Triage meeting this Wednesday

Howdy. This is your reminder that the upcoming VE triage meeting will be held on Wednesday, 4 March at 08:00 PST (16:00 UTC). Full information about how to join the Webex call or the IRC channel, and the links to the IRC logs and minutes for the last appointment, live as usual at mw:Talk:VisualEditor/Portal. I'm looking forward to seeing you there! --Elitre (WMF) (talk) 18:35, 2 March 2015 (UTC)

Addition of nowiki tags

Tracked in Phabricator
Task T91287

This is the latest manifestation of an old problem. I simply tried to add a space using VE. Δρ.Κ. λόγοςπράξις 07:07, 28 February 2015 (UTC)

Dr.K., I see the space you added. To the best of your memory, did you click on or interact with the ref tag at all? Also, what's your browser and OS? Whatamidoing (WMF) (talk) 18:53, 2 March 2015 (UTC)
Never mind about the browser/OS information; it happens everywhere. The problem is in the wikitext: the ref tag is <ref name="telegraphDowning> when it ought to be <ref name="telegraphDowning"></nowiki>. Whatamidoing (WMF) (talk) 19:00, 2 March 2015 (UTC)
@Whatamidoing (WMF): Hi Whatamidoing. We just had an edit-conflict! Thank you for letting me know. I'm glad it was resolved. For historical reasons I just wanted to mention that I remember after doing the edit being surprised to discover that VE would add "nowiki" tags so far down the sentence from the point I inserted the space. I never got close to that ref tag. Thank you again and take care. Δρ.Κ. λόγοςπράξις 19:08, 2 March 2015 (UTC)
The rule of thumb seems to be that anything on the same line (of wikitext, not that it's easy to tell what's on the same line when you're in VisualEditor) is fair game. If you edit (only) other lines on the page, then it doesn't nowiki the invalid wikitext. Of course, the ideal solution would be that we don't have invalid wikitext anywhere, but that's a bit unrealistic for a project that anyone can edit. Typos will happen despite the best of intentions. Whatamidoing (WMF) (talk) 19:18, 2 March 2015 (UTC)

Italicizing wikilinks

I made this edit to italicize wikilinked words. VisualEditor behaved incorrectly, creating a piped link and putting the italic characters inside of it instead of simply adding the italics characters to the outside of the square brackets. Another editor had to make a second edit to fix it. When will this problem be resolved? Many thanks. --Albany NY (talk) 19:15, 1 March 2015 (UTC)

I don't know when it will be fixed, beyond "not very soon".
Actually, I'm not entirely sure that it ever will be fixed, because it's not actually "incorrect", and it didn't really need "fixing". Both methods are correct. It's just not the way I would type it in wikitext, because I wouldn't want to bother typing the name of the link twice. Whatamidoing (WMF) (talk) 19:12, 2 March 2015 (UTC)
Thanks for the reply. I would argue that the non-piped method is clearly superior because the piped link makes the wikitext more difficult to read. Is this a bug that the developers are working on? --Albany NY (talk) 21:49, 2 March 2015 (UTC)
I agree with Albany NY, and probably others also since an other contributor, Cyphoidbomb, took the time to fix this. Creating complex wikitext syntax for something that should be simple is really annoying, and I think it should be considered as a bug, a bug that should be fixed before wider release. --NicoV (Talk on frwiki) 22:14, 2 March 2015 (UTC)
Although I would agree this is not a bug, since wikitext will continue to be used I think this would be a useful enhancement. As Albany says it makes the wikitext much easier to read. Mike Christie (talk - contribs - library) 23:11, 2 March 2015 (UTC)
Let me be clearer: I don't personally like it, either. I do almost all of my reading in diff mode, so these things are very visible to me. However, it's not actually a bug. Realistically, and not unreasonably, replacing one technically correct approach with a different, also correct approach is naturally much lower on the priority list compared to, say, getting rid of the nasty [[Link|<nowiki/>]][[Link]] bug. I think it's useful to recognize the priority level, even though we are all unanimous in our agreement that one of the approaches is better than the other. Whatamidoing (WMF) (talk) 00:51, 3 March 2015 (UTC)
I agree -- I just wasn't clear that this was going to be considered as a future enhancement; I think it should be. But I entirely agree with you on the priority. Mike Christie (talk - contribs - library) 01:07, 3 March 2015 (UTC)

Invisible unicode characters

Tracked in Phabricator
Task T85943

I've noticed that when I create an article with VE, which I often do by going into VE on another article and cutting and pasting the whole article to give me the format and sections, Yobot will come along after me and make an edit like this. Any idea what's causing this? Mike Christie (talk - contribs - library) 12:30, 4 March 2015 (UTC)

I have no idea, of course, but Catrope said that his first guess is a zero-width space (which sounds like an oxymoron). I found a simpler diff, and I left a note about it an existing task that seemed relevant. Whatamidoing (WMF) (talk) 18:16, 4 March 2015 (UTC)

Preview Option?

Tracked in Phabricator
Task T62535

Looks and works excellent most of the time. Well done, all of you. A suggestion for future improvement, though, would be to add an option to preview what you've edited before clicking "Save page". This could be either a live preview, which I think is still in beta (no? yes?), or at least a non-live one. :) Yay for Wikipedia! SarahTehCat (talk) 17:47, 3 March 2015 (UTC)

Hi SarahTehCat,
Thanks for sharing that idea. You're not the first person to think this would be helpful. VisualEditor is a rich-text editor rather than WYSIWYG, so there are some differences between what a page looks like in VisualEditor and what it looks like when saved. I've added your suggestion of using Live Preview. (I'm not sure what its status is.) Whatamidoing (WMF) (talk) 18:21, 4 March 2015 (UTC)

Human readable ref names

Tracked in Phabricator
Task T52568

I love the cite re-use feature, but one thing that would make it a bit better is human-readable ref names. Over at Russian Jews in Israel, we have a cite that's <ref name=":0">blah blah</ref> and all the later ones are <ref name=":0"/>. It would be nice if Visual Editor generated human-readable names, such as, in this case, <ref name="www.wsws.org">, using the last name for books and news, and the domain for urls. Oiyarbepsy (talk) 00:27, 26 February 2015 (UTC)

  • I was just coming here to report this same issue. In particular, automatically generating refnames using numbers is really problematic because the "name" given to the reference doesn't match the number generated for the reference. A parameter that allows the user to add a reference name would go a long way in alleviating this issue. While the URL may be one possibility, it could be quite long for some references, so an actual parameter where the user can determine the refname should be considered a priority. Risker (talk) 02:29, 26 February 2015 (UTC)
    • Not the URL, but just the domain name - like en.wikipedia.org instead of en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&action=edit&section=15 Oiyarbepsy (talk) 02:57, 26 February 2015 (UTC)
      • This is a long-standing request. It's apparently on the list for "someday". Actually, (if memory serves) the feature was (very) briefly available in 2013 (or was that only in testing?). I don't remember why it was removed. Whatamidoing (WMF) (talk) 18:27, 26 February 2015 (UTC)
        • Yes, the user should, when using a cite, have the option to specify the name. But VE should suggest a name - that is, the user should always have the option of not typing anything because he/she is satisfied with VE's suggestion.
        • A problem with using a url to generate a (suggested) name is that some cites [to off-line sources] lack that. And many citations aren't even formatted as a template, so one can't assume that VE can even use a value within a parameter such as title=. So perhaps VE should use part of a URL if there is one (I suggest the segment just before .com or .org - that is, the text just before the generic top-level domain, such as "wikipedia"), and if no url exists, the longest text string in the citation, adding "1" or "2" or whatever to avoid duplication. -- John Broughton (♫♫) 02:21, 3 March 2015 (UTC)

Suggestions

I'm not confident in using Phabricator, so I don't know if these suggestions have already been made, and if so, how they were dealt with. But, nevertheless, I'd like to know if they could make it to the list for the next Triage meeting for acceptance. I listened in to the call on the last meeting but wasn't sure if I could add anything useful so stayed silent :-)

  1. Show Categories while in VE mode. It is possible to add/view/remove categories as part of the "page options dropdown menu on the right hand side of the toolbar. I think this is a bit "hidden away" for a standard feature of an article, but more to the point is that any categories which the article is in are NOT visible to the editor while in VE mode. Unless you know to look, you would never know that they exist. Hiding the categories while in VE mode seems to be deliberately designed to be different from how the "reader" will see the article, which seems to go against the principle WYSIWYG. Wittylama 17:31, 25 February 2015 (UTC)
  2. Section editing. I'm SURE this has been discussed somwhere, but doesn't the inability to edit just 1 section make edit-conflicts a whole lot more likely? Speaking of which, I would also say that a a edit-conflict screen that is consistent with the UI of the VE should be part of the VE rollout criteria.
  3. While not directly the VE-coding team's responsibility, I would like to see at least 1 pre-existing documentation page for en.wp style conventions written to include parallel instructions for how to achieve the "correct" formatting in both traditional and VE modes. Perhaps for example Wikipedia:External_links#How_to_link which could be augmented with info already produced for Wikipedia:VisualEditor/User_guide#Editing_links. Eventually the communities of all wikis will need to rewrite all documentation to explain to people who have ONLY used VE what is the correct methodology. I think there should be at least 1 example of how this should be achieved. Perhaps a two-column approach for every example - "the old way, and the VE way". This is NOT the same as the VE User Guide which has been produced for people learning to swap from the old to VE systems. Rather, this is about starting the process of updating documentation of the normative approach to a task: the expectation is that VE will be used for normal editing, and 'code editing' will be for unusual circumstances. We need to have at least 1 example of documentation that conveys that.
  4. Adding template within a template doesn't show as intended. This is a genuine bug report (as opposed to feature request). See this edit. While in Visual Editor I double-clicked to open a pre-existing "blockquote" template, and moved the cursor to the "source" field within the VE template dialogue popup. I then clicked "show options", "add template" and typed in "cite book" to chose the template I wanted to add to that field - so far so good. I put in some placeholder content ("test test, 1, 2, 1900") and saved the edit. As you can see (here's the code-editor view of the same edit, what should have appeared as a footnote within the "blockquote" template appears without "ref" tags and outside the blockquote template. It also adds a bunch of blank fields to the code view that I never input data for: {{Cite book|title = test test|last = 1|first = 2|publisher = |year = 1900|isbn = |location = |pages = }}.
  5. Screen jumping when focusing on external links. This is another "genuine" bug report, but more difficult to reproduce consistently (which is part of what makes it so irritating). Go here: User:Wittylama/SAI, which is (at the time of writing) a userspace sandbox article with LOTs of tables. This makes the load time for VE VERY LONG (that's not the problem though, just a warning). Now, once you're in VE, focus the cursor one of the links inside one of the tables by double-clicking. Then, focus the cursor on a different link in a different table (sometimes this requires double-clicking to activate, sometime triple-clicking. I'm not sure why yet). After you've clicked between a few different links (try alternating between internal article, external website, external PDF and internal footnote links) you'll see that the screen jumps around seemingly randomly. Sometimes it goes right back to the top of the article, sometimes it refocuses the window with your selected link on the bottom row of the screen, sometimes it moves smoothly. It's all very random...

I hope this is useful! Please tell me if you need more info. Wittylama 17:31, 25 February 2015 (UTC)

Thanks for the list, Wittylama. Can you remind me which browser/OS you're using? It's probably relevant to the last one. Whatamidoing (WMF) (talk) 23:51, 25 February 2015 (UTC)
Hi Whatamidoing (WMF), I'm on Chrome (v.40) in Mac (OSX 10.10). So, quite up to date!
I've meanwhile found a more precise way to replicate the screen jumping issue: Go to the article I mentioned, User:Wittylama/SAI, open VE and scroll down a few page lengths until you get to the "awards" section. You will see a colourful table his is the first table called "Ribbon color" with a footnote inside the second cell of the first column. Activate the cell, then try to activate the footnote to edit it. You will be jumped right back up to the top of the page. When you scroll back down again the activation of the footnote works correctly the second time. Can you replicate that? Wittylama 12:01, 27 February 2015 (UTC)
@Wittylama: I can help with one of the questions posed. Edit conflicts are determined (by VE and the wikitext editor) on a (roughly) paragraph basis, not a section basis. So, no, opening an entire article for editing (in VE) doesn't increase the likelihood of an edit conflict - if you edit one section only, and another editor is editing a different section, there will be no edit conflict. [And yes, this should be in the documentation for Wikipedia, and isn't.]
As an aside, the way the wikitext editor handles edit conflicts is a known abomination. If VE had a much better way to deal with those, that would certainly be an incentive to experienced editors (as in, those who do lots of editing) to switch to VE. -- John Broughton (♫♫) 16:44, 28 February 2015 (UTC)
The documentation does mention this (e.g., Help:Section#cite_ref-1). But people already know that it doesn't, because we all heard this once upon a time.
Wittylama, I just upgraded to 10.10 myself, but I haven't installed Chrome. I think Safari may be having the same problem, though.
In terms of a better edit conflict system, I wonder if you would prefer something that looks like the other diff display. It shows the page, with text highlighted in red or green to show additions and removals. I can never remember where the page is, so I'll have to call on my distributed memory system to find the link for you. Whatamidoing (WMF) (talk) 18:50, 2 March 2015 (UTC)
@Whatamidoing (WMF): The alternative diff displays currently available are:
HTH. Quiddity (WMF) (talk) 21:07, 2 March 2015 (UTC)

@Whatamidoing (WMF): - The place on en.wikipedia.org to see how to minimize edit conflicts is here - WP:Edit conflict. I see that you edited that page in December 2013, seven years after the developers changed the code for how edit conflicts are determined. So yes, most experienced editors here may have heard that the documentation says conflicts are by section - and that's because the documentation did say that, until just over a year ago. Unfortunately, most of us lack the time to keep rechecking technical documentation pages (hundreds?) to see what has changed and what has not. -- John Broughton (♫♫) 02:06, 3 March 2015 (UTC)

And to do that, I had to track down a couple of devs to make sure that the information was right. Getting docs updated is a constant problem. Even if you had time to read through all 59 policies and many hundreds of guidelines, you would frequently not get accurate information. Whatamidoing (WMF) (talk) 18:34, 4 March 2015 (UTC)

VisualEditor meeting

This was announced in the newsletter and spammed to several mailing lists, but here's another reminder: The first of a weekly series of open meetings about VisualEditor will be tomorrow (Wednesday, 11 February 2015) at 12:00 (noon) PST (20:00 UTC). These meetings are related to the Engineering team's priorities for the current quarter. We will discuss the release criteria for VisualEditor, jointly prioritise the work of the team, and talk about the bugs and features which are most important to you, including this list of tasks that have been nominated for higher priority.

We particularly welcome the presence of volunteers who enjoy contributing MediaWiki code. The joining instructions have been posted on MediaWiki.org. The meeting will use w:WebEx, which for some computers may require installing a plug-in, so please review the instructions well in advance. Whatamidoing (WMF) (talk) 20:05, 10 February 2015 (UTC)

I was interested in participating, until I looked at the list of 72 tasks to be discussed. Of those, I count five as adding functionality for all users, two as being helpful to beginners, and 65 about fixing bugs, making things run faster, and other matters that tend to result in glazed eyes among non-programmers.
The five "added functionality" tasks include two "rework" tasks (my word) - phab:T76398 and phab:T76397 - and one enabling task (phab:T89054), so what's left under "adding functionality" is just phab:T62768 (the task discussion is about using an ISBN to generate a citation) and phab:T53798 - contextual help everywhere. Nothing about increased table-editing functionality. Nothing about how VE should handle the tens of thousands of articles where it now can't edit citations because their text is within a reflist template. Nothing about the inability to navigate around (or copy from) the main text when adding a category to an article. And I'm sure I'm leaving out lots of feedback about missing functionality, or less-than-ideal design decisions, as posted at WP:VE/F or WP:VE/KP and tracked in Phabricator.
I don't want to minimize the importance of bug fixes, speed improvements, etc. Performance issues and editing glitches are definite turnoffs; people who aren't been paid to edit (and no one is) are generally unwilling to use tools that have a high frustration factor. So have at it. I'm just noting that experienced editors, such as myself, who aren't interested in doing programming, aren't likely to find much of this meeting to be of interest. -- John Broughton (♫♫) 06:20, 11 February 2015 (UTC)
Thanks, but no thanks. That seems like a feeble attempt to say that the community is involved, but it looks like again as just a smoke screen: WMF as decided that VE will be ready (same story as before...) in less than 2 months, and that's all. But there are still bugs that damage articles on a daily basis, which have been reported for months, and still nothing (visible?) is being done about them (nowiki, deleted categories, empty titles, links with wrong destination, ...). Also, is there any recent study about VE related to vandalism ? My impression on frwiki is that the percentage of vandalism is more important among contributors using VE. Added to the bugs, I really have the feeling that VE is not productive at all on frwiki. --NicoV (Talk on frwiki) 12:36, 11 February 2015 (UTC)
Is there a list of bugs/enhancements that the VE team regards as prerequisites to another release on en-wiki? That is, is there a definition in functionality terms of what is required for VE to be ready? Mike Christie (talk - contribs - library) 12:46, 11 February 2015 (UTC)
Mike Christie, the purpose of the meetings is to determine what should be regarded as prerequisites to another release here. This list of tasks shows the ones that have been nominated or accepted so far for that status. The current list is not complete, so if there are particular things you'd like to have added, then please let me know.
NicoV, I haven't seen any recent studies about VisualEditor except small-scale user testing with new editors (e.g., "Question: Can you figure out how to add an external link? Answer: Um, no.") However, the overall impression is that the amount of vandalism has not increased at fr.wp, and if the total vandalism is the same, then which editor is being used to do it is not likely to be relevant.
John Broughton, if you have specific bug numbers that you would like added, then please let me know. Whatamidoing (WMF) (talk) 18:31, 11 February 2015 (UTC)
Tracked in Phabricator
Task T89618
In addition to the very old bugs I have cited, what about fixing the new ones that damage articles:
Don't you think that, before talking again about putting again VE by default for everyone, it should be nice to have a version that doesn't damage articles? --NicoV (Talk on frwiki) 11:24, 15 February 2015 (UTC)
Hi NicoV, thanks for this. The first might be phab:T89383, which should be fixed in the next update. I've left a note for Jean Po (the only logged-in editor in those diffs). From the bug comments, the bug is in a component of Parsoid that is called "selser".
I can't reproduce the second one. I could (once, but not since then)) add a duplicate category (which should not be permitted), but I can't give different sort orders to the two cats. It keeps blanking one. It's a logged-out editor, so a low chance of finding out any further information.
By the way, is it usual at the French Wikipedia to specify a category sort order that is exactly the same as the article title? Whatamidoing (WMF) (talk) 22:58, 15 February 2015 (UTC)
No, it's not usual, I don't know it's that way on this article (but it's very old). --NicoV (Talk on frwiki) 04:37, 16 February 2015 (UTC)
Whatamidoing (WMF), I tried reproduce the second one without any success, but I saw an other minor one: when I set the sort key for "Villes et villages fleuris" to "Catégorie:Villes et villages fleuris", then VE thinks there's no modification to the page. --NicoV (Talk on frwiki) 04:53, 16 February 2015 (UTC)
Thanks for the update, NicoV. Does it sound like phab:T74168 again to you? Also, there was another bug a while ago (reported as Chrome only, but possibly intermittent) that seemed to depend on whether you used the Return key or the mouse to close it, so it would be helpful to have the exact details on what you did. Tomorrow's a US holiday, but User:Krenair might be working anyway, and he's probably the best person to deal with this anyway.
(I wish that I had a screenshot or diff of the time that I added a second copy of an existing category. Now I'm worrying that I had a typo or something in it, and I've got no way to prove that it really was a duplicate.) Whatamidoing (WMF) (talk) 05:15, 16 February 2015 (UTC)
No, doesn't look like phab:T74168, it really seems to be the "Catégorie:..." in the sort key that makes VE miss the modification (it worked with other things, but not with "Catégorie:..." several times). I think I used the mouse to close the dialog, no Return key. --NicoV (Talk on frwiki) 05:34, 16 February 2015 (UTC)
Jean Po replied that he's using Firefox on Windows 7. Perhaps testing should focus there. Whatamidoing (WMF) (talk) 20:53, 17 February 2015 (UTC)
Whatamidoing (WMF), I completely disagree with your sentence "if the total vandalism is the same, then which editor is being used to do it is not likely to be relevant". VE usage is probably around 10% of total edits, so its impact on total vandalism could be easily masked by other factors: for example, if vandalism is twice as frequent with VE (figures exagerated of course), it would only account for an increase of 10% of total vandalism and other factors (better tools developed to fight vandalism, ...) could easily compensate this increase (if not even hidden by normal fluctuations). --NicoV (Talk on frwiki) 10:44, 16 February 2015 (UTC)
Under those circumstances, then total vandalism would not be the same, would it? In your scenario, total vandalism has increased.
VisualEditor is being used for about 14% of mainspace edits at the French Wikipedia. If vandals were exactly as likely as any other editor to use VisualEditor, then you would naturally expect 14% of all acts of mainspace vandalism to occur in VisualEditor. However, their choice of editing environment is not randomly distributed: Vandals are almost always inexperienced editors, which means that they have a higher likelihood of choosing VisualEditor, and high-volume editors (very) disproporationately use the wikitext editor. Inexperienced editors (and espeially IPs) are far more likely to vandalize an article that high-volume registered editors like you and me. In fact, at the moment, 40% of the edits made by IPs used VisualEditor, and 60% are in the wikitext editor. Since most (but by no means all) vandals are logged-out users, I would not be the least bit surprised to learn that 40% of vandalism happened in VisualEditor, solely because 40% of the group that is most likely to vandalize an article is using VisualEditor.
What matters from the perspective of RecentChanges patrol work is not the editing environment that a vandal chose. What matters is how many times I have to clean up a vandal's mess. If I had to clean up 100 acts of vandalism "yesterday", all of which were perpetrated in the wikitext editor, and "today" vandals are splitting their time 40-60 with VisualEditor and the wikitext editor, but it's still a total of 100 acts of vandalism, then there has been no change in the amount of vandalism. The undo button works identically in both cases; the vandal's choice of editing environment cannot impose an extra burden on me.
What would be worrisome is if vandalism went up—if, for example, the introduction of VisualEditor resulted in the same 100 acts of vandalism in the wikitext editor plus another 40 acts of vandalism in VisualEditor. However, there's no evidence that there has been any change in the amount of vandalism at all. Whatamidoing (WMF) (talk) 21:26, 16 February 2015 (UTC)
Whatamidoing (WMF), are there any statistics available on vandalism ? Because you look like you're carefully avoiding to say that "there's evidence that there has been no change in the amount of vandalism"... --NicoV (Talk on frwiki) 08:32, 17 February 2015 (UTC)
I don't believe that any research on that question been done specifically at the French Wikipedia, which is what you would need to answer a question about what's happened at the French Wikipedia in particular. Previous (now somewhat elderly) research showed no increase in vandalism here at en.wp. I don't know if a final report was ever published. Whatamidoing (WMF) (talk) 20:34, 17 February 2015 (UTC)
NicoV, based on your bug reports and feedback, we spent a couple weeks reworking the nowiki insertion algorithm for quote tags since it disproportionately affects non-english wikis like fr, it, ru, etc. While the problem is non-trivial, we feel we improved it significantly. Those fixes were deployed on Jan 5th, 2015. If you see more problematic nowikis for quotes, can you please point me to diffs so we can work on those? Thanks. SSastry (WMF) (talk) 21:33, 16 February 2015 (UTC)
Tracked in Phabricator
Task T68628
Tracked in Phabricator
Task T55548
Hi SSastry (WMF). I wasn't often connected to Wikipedia in the last 2 months (travelling, only came back 2 days ago), but I can see that the situation about nowiki for quotes seems to have improved a lot during this time, and I really thank you for that. I don't recall seeing this kind of problems since I came back (I will tell you if I find some).
But, I still think that there are other situations where adding nowiki tags could be prevented in VE. A few examples from edits in the last hours on frwiki:
  • nowiki around an extraneous whitespace at the beginning of a line, like in Bni Hadifa: even with the nowiki, the whitespace is not visible in the end result, so it could be entirely removed instead of escaped. Other examples: Gyropalette
  • nowiki after an internal link because the whitespace has been included at the end of the link text, like in Ophrys: it would be better to put the space after the link (no nowiki needed) than inside the link. Other examples: Lycée en France
  • nowiki that result in a link not covering all the text, like in Charpentier (1) or (2): it's very rarely what the contributor intended to do
  • Empty title with nowiki, like in Emmaüs Solidarité. Other examples: Kelt 550
  • Existing internal link replaced by an escaped internal link, like in Gare de Nogent-sur-Seine
  • Italics formatting around no text, like in Ben Affleck
  • Strange construction, like in Hervé Marly where a nowiki is after a link with no displayed text...
  • nowiki around a dash in a table, like in Malika Ayane: not entirely sure about this one, but would putting a space between the pipe and dash give the same result?
As you can see with examples that happened in only the last few hours, there are still a lot of problems with nowiki in VE... If they could be fixed like the problem with the quotes has been fixed, that would be great. --NicoV (Talk on frwiki) 22:13, 16 February 2015 (UTC)
NicoV Great! Good to get that confirmation about quotes. As for the rest of the scenarios, in Parsoid, we have resisted changing content we receive from clients, since as a general principle, it is hard to know what is intended vs what is okay to change / fixup since Parsoid caters to clients that is not just the VE. That said, there are some scenarios in your examples above where we could perhaps safely fixup without harm. The whitespace at beginning of line, whitespace at end of link, empty title without content, empty italic/bolds are perhaps scenarios Parsoid can fixup. The other scenarios are a bit more unclear. For example, putting a space between a pipe and a dash will eliminate the nowiki but change rendering in some cases. Similarly, nowikis because of links not covering entire text, or because of link-wikitext chars in text, or the strange construction case are not something Parsoid can fixup arbitrarily since it is possible to imagine scenarios where the HTML rendering that Parsoid receives is exactly what was intended by the client asking Parsoid to convert it to wikitext. But we'll take a look at the other 4 cases and work on them. Thanks! SSastry (WMF) (talk) 00:45, 17 February 2015 (UTC)
SSastry (WMF), thanks for the answer. I don't think that all the problems I reported above should be fixed by parsoid, but some could be prevented (or at least happen a lot less frequently) by changing VE itself (either the GUI or the behavior) and not relying on Parsoid on cleaning up the mess. --NicoV (Talk on frwiki) 08:29, 17 February 2015 (UTC)
As I understand it, VisualEditor never adds nowiki tags, so all of the diffs involving nowikis are Parsoid's territory. The italicized nothing might be due to someone typing something, italicizing it and then removing the text. It looks like the system is trying to preserve the character formatting (just like a word processing document preserves your font and character settings even if you blank the text). Whatamidoing (WMF) (talk) 20:40, 17 February 2015 (UTC)
Whatamidoing (WMF), I didn't mean that VE was adding the nowiki tags, but that what VE gives to Parsoid sometimes requires either adding nowiki tags or changing wikitext. I believe VE should be smarter rather than relying on Parsoid to clean up everything behind it: for example, when editing a table cell, it's obvious when you look at wiki syntax that a "-" at the beginning of a cell is a problem. VE should know that, and for example silently add the extra whitespace in front to have a simple wikitext rather than having to end up with a nowiki tag.
A word processing document like MSWord doesn't preserve your font and character settings in every situation, it's a lot smarter:
  • put some bold characters in a middle of a word, select them and delete them: bold is not kept
  • put some bold characters in a middle of a word, delete them one at a time with backspace: bold is kept if you don't move the cursor (so characters are bold if you start typing again), but is lost if you save or move the cursor (no unnecessary formatting is kept).
--NicoV (Talk on frwiki) 13:50, 19 February 2015 (UTC)
Nico, VisualEditor doesn't deal with wikitext. It "thinks" in HTML. The process is like this: you open a page. The (wikitext) file is sent to Parsoid. Parsoid converts it to HTML and sends the HTML to VisualEditor. You make whatever changes you want, and save the page. VisualEditor sends the HTML back to Parsoid. Parsoid converts the HTML to wikitext, and sends the wikitext back to the database. In theory (although not in practice at the moment), it is possible to use VisualEditor without Parsoid to edit an HTML page directly.
Your analogy to word processing documents is missing the critical point: the unnecessary italics weren't in the middle of the word. They were at the end of the last word in a line, where many (but not all) word processors do retain the "unnecessary" formatting. Personally, I'd be in favor of removing pointless formatting, but the current behavior isn't entirely unreasonable for the model. Whatamidoing (WMF) (talk) 01:13, 20 February 2015 (UTC)
Whatamidoing (WMF), I don't think making a distinction between wikitext or HTML is relevant: VE should be able to handle situations where there's a space before the dash in the table or where the dash is escaped by a nowiki tag... So it could be smart enough to do a correct thing. Discussion moved to dedicated section #Table cells disappearing when adding a "-"
Tracked in Phabricator
Task T71950
SSastry (WMF), I found an edit where nowiki doesn't seem well handled for quotes. --NicoV (Talk on frwiki) 13:35, 19 February 2015 (UTC)

The results from the first meeting were sent out in e-mail: https://lists.wikimedia.org/pipermail/wikitech-l/2015-February/080803.html By the way, the next meeting is about 36 hours away, and only eight more items are in the nomination list so far, and a couple of those were leftover from last week. If you've got ideas about what should be considered, then please add them (or give me the bug number, and I'll add it for you). Sooner is better than later, so that yours will be more likely to be discussed this week. Whatamidoing (WMF) (talk) 05:43, 17 February 2015 (UTC)

For me, every bug that leads to damages in articles. For example, the one where categories are moved inside a ref tag like this edit (I don't know the bug number). --NicoV (Talk on frwiki) 07:09, 17 February 2015 (UTC)
And preventing the addition of empty gallery tags, like in Ludovic Bruni. --NicoV (Talk on frwiki) 16:48, 17 February 2015 (UTC)
Phab:T74048 (about categories) was accepted last week.
The diff for the empty gallery tag is tagged as "Switched". Therefore, that may have been added in the wikitext editor (there's a button in the wikitext editing toolbar that adds galleries). I can't get VisualEditor to add empty gallery tags (in Safari/Mac). Can anyone else? Whatamidoing (WMF) (talk) 20:51, 17 February 2015 (UTC)
This edit that shows 2 problems: category moved in the middle of the article and comments moved in places where they won't be useful any more. --NicoV (Talk on frwiki) 06:29, 18 February 2015 (UTC)
These are probably the same Safari-only bug, and they should have disappeared at 16:00 PST on Tuesday. Whatamidoing (WMF) (talk) 18:39, 5 March 2015 (UTC)
This edit where VE created an internal link with only a nowiki tag as the displayed text + other damages to internal links. --NicoV (Talk on frwiki) 10:18, 19 February 2015 (UTC)

gR8!!!!!!!!!!!!!!!!!!!!!!!!

I never had time to learn WikiMarkup (i get it mixed up with HTML. NOw I can finally edit Wikipedia! FrodoBaggins (blackhat999) (talk) 22:33, 5 March 2015 (UTC)

VE Category Editor

Just wanted to say that I liked it, and that it works really well for me. Red Fiona (talk) 22:29, 6 March 2015 (UTC)

Category update

A patch has been submitted for Bug T74048. They're backporting it today, so the problem should disappear in less than two hours. If it's still happening, say, tomorrow morning, then please let me or User:Elitre (WMF) know, so that we can get their attention back on the issue ASAP. Whatamidoing (WMF) (talk) 22:23, 3 March 2015 (UTC)

Tracked in Phabricator
Task T91913
Hi Whatamidoing (WMF), it doesn't seem to work in all cases:
I'm adding a comment to the phabricator task. --NicoV (Talk on frwiki) 07:58, 7 March 2015 (UTC)

Bolding displayed incorrectly after paste and edit

Tracked in Phabricator
Task T91672
Bug report VisualEditor
Mito.money Please app{}
Intention: I was trying to create bolded text.
Steps to Reproduce: Edit any page in VE. You don't have to save the page to see this error, so I used "Create beta" to create a page with a nonsense name.
  1. Type a a Ctrl-B b b Ctrl-B c c to produce this: aabbcc
  2. Copy this string and paste it on a new line
  3. Go to the start of the line and press the Del key twice to remove the two "a" characters.
  4. Press right arrow, then left arrow to move the cursor between the two "b"s and then back to the front.
  5. Now type a character: e.g. "x". It will be in bold: xbbcc
  6. Go the end of the line and hit Enter. The "x" will unbold: xbbcc

This is reproducible.

Results: The "x" was bolded when first typed, and unbolded after Enter was pressed.
Expectations: It should not have been bolded in the first place.
Page where the issue occurs Add URL(s) or diffs
Web browser Chrome 40.0.2214.115 m
Operating system Windows 7
Skin Vector
Notes: Any additional information. Can you provide a screenshot, if relevant?
Workaround or suggested solution None needed; the incorrect display corrects itself.

The above is low priority since it's really just a display bug, but I thought I'd pass it along. Mike Christie (talk - contribs - library) 02:00, 5 March 2015 (UTC)

I can't reproduce this in Safari or Firefox on my Mac, so perhaps it's Chrome-only or Windows-only.
Shouldn't the characters be bolded? If you place your cursor next to a word that starts with bold-faced text, then having bold-faced text appear when you start typing is not unreasonable. For example, if you intend to type "Dear, dear, dear Santa," except you left out the first letter so that it read "Dear, dear, ear Santa,", then when you went back to correct your typo, I think you'd expect the new first letter to take the same formatting as all the following letters, no? So perhaps the actual bug is "didn't take the logical character formatting (but looked like it did)". Whatamidoing (WMF) (talk) 18:37, 5 March 2015 (UTC)
Yes, it's not quite clear what it should do. Apparently bolding and then changing its mind is definitely wrong, though. I tried this in Word 2010 on Windows 7 and got slightly different results depending on how I did it. aabbcc following by del, del at the start of the line gives me bold characters if I start typing. However, if instead of the del, del I type right-arrow, right-arrow, so that the cursor is between the normal a and the bold b, I get normal font, not bold. I don't think I mind too much which way it goes so long as it's consistent. NicoV says somewhere else on this page or in the archives that other word processors try to guess what it is you're likely to do rather than simply making the behaviour dependent on keyboard position, and it looks like that's correct. That might be rather a lot of complication for a relatively minor usability point, though, especially with the higher priority bugs waiting to be addressed. Mike Christie (talk - contribs - library) 18:44, 5 March 2015 (UTC)
I have an idea! Instead of having a computer program try to read your mind and guess what you want, why not place a sequence of special characters (maybe something like <b> and </b>) around the text you want to have display in bold? Wouldn't that be a remarkably flexible and precise way to control the formatting?—Kww(talk) 16:21, 7 March 2015 (UTC)
if (isIntendedJustAsWisecrack(priorComment)) {
print("Agreed.");
} else {
print("If potential editors were never discouraged by anything that looks like code, I'd agree with you.");
}
-- Mike Christie (talk - contribs - library) 16:33, 7 March 2015 (UTC)

Table cells disappearing when adding a "-"

Tracked in Phabricator
Task T91866
Tracked in Phabricator
Task T88318

I managed to damage an existing table with VE: for the first two lines of the table, I tried to put in the 3rd cell the same content as what was in the 1st cell ; the result with VE is a damaged table (2 cells have been fused) and the content I tried to add is nowhere... An other case of VE damaging articles... --NicoV (Talk on frwiki) 13:33, 23 February 2015 (UTC)

Whatamidoing (WMF), any phabricator task for the bug I've reported ? (table damaged when trying to add contents in cells) --NicoV (Talk on frwiki) 14:19, 5 March 2015 (UTC)
I can't reproduce it, and there have been two regular updates since then. Can you still make that happen? Whatamidoing (WMF) (talk) 18:23, 5 March 2015 (UTC)
Whatamidoing (WMF), yes I reproduced it easily:
  • double click in the cell (1,1) after the "-" and add the "a"
  • same for cell (1,2)
  • double click in the cell (3,1) and add the "-"
  • same for cell (3,2)
VE still displays all the cells, but when you look at the wikitext or save, both cells (3,1) and (3,2) have disappeared. I'm using Chrome 40 on W7. --NicoV (Talk on frwiki) 18:45, 5 March 2015 (UTC)
I've created T91866 in phabricator to report this problem. I don't know how to nominate it for Q3 blocker: how can I do this? --NicoV (Talk on frwiki) 07:51, 7 March 2015 (UTC)
It's easier to do than to explain: Pretend that you're going to add a comment. But change the "Comment" pop-up menu to say "Associate project". That will give you a new blank for the name of the project. Type Q3 in the blank, and the Q3 blocker project should pop up in the search results. (You can add comments at the same time, if you need to add more information or explain which of the Q3 criteria it's related to.) Save as you normally do. Check the list at the top to make sure that Q3 is present. Whatamidoing (WMF) (talk) 17:17, 7 March 2015 (UTC)

Kudos for the table editor

Removing rows in Comparison of Office Open XML software would have been much more annoying in the wikitext editor. The table editor let me do the simple thing I wanted to do in a reasonably discoverable manner. Nice one - David Gerard (talk) 12:57, 6 March 2015 (UTC)

Thanks for your note. (Removing columns is an even bigger win.  :-) Whatamidoing (WMF) (talk) 03:48, 7 March 2015 (UTC)
D-: Oh my goodness yes - David Gerard (talk) 10:27, 8 March 2015 (UTC)

Triage meeting tomorrow

Hi again. This week's triage meeting will happen on Wednesday, 11 March 2015 at 12:00 (noon) PST (19:00 UTC). We hope to see you there, but in case you can't make it, please remember you can still nominate "blocker" tasks in advance on Phabricator, or you can read the IRC logs and minutes which are usually published shortly after the end of the meeting, so you can catch up on what was discussed. So see the meetings page on mediawiki.org for details (notice the new format, a Google Hangout). Thank you, and talk to you soon, --Elitre (WMF) (talk) 19:55, 10 March 2015 (UTC)

Quick heads-up

The devs have been doing a lot of performance work, and they've just figured out that the "beta" label (Mediawiki:visualeditor-beta-appendix, which only exists on the English Wikipedia) is costing editors a performance hit every time they read a page. They're probably going to yank it out sometime next week. The only change is that "Edit beta" will become the normal "Edit", and navigating pages will be slightly faster. Whatamidoing (WMF) (talk) 03:52, 7 March 2015 (UTC)

Why lie to users? I think it may have made it out of alpha, now, but it certainly wouldn't be "production" if this were a commercial product (other than Microsoft). — Arthur Rubin (talk) 05:49, 7 March 2015 (UTC)
Why not remove the word "edit" and just call it "beta"? What are the two different tabs going to say? Needless to say, I find the idea that removing the beta label is being done for performance reasons fairly laughable: the political mileage to be gained by claiming it is out of beta is too obvious, and the people that will be making the claim haven't regained my trust in any regard.—Kww(talk) 06:01, 7 March 2015 (UTC)
WP:AGF - David Gerard (talk) 10:28, 8 March 2015 (UTC)
An assumption is something one makes before one has enough evidence to make a decision. I have more than enough evidence to have made a decision.—Kww(talk) 18:48, 8 March 2015 (UTC)
Strange, I checked my calendar, and it's not April's fools day... +1 to the above remarks. --NicoV (Talk on frwiki) 07:43, 7 March 2015 (UTC)
The implementation of the addition of "beta" by referring to a file on Wikipedia has a slight, but probably not noticeable, performance cost; an honest name for the tag "Edit beta", or even "Visual Edit", with the current "Edit source" being changed back to "Edit", would have no performance cost. — Arthur Rubin (talk) 09:18, 7 March 2015 (UTC)
Changing Mediawiki:Vector-view-edit to whatever you wanted would have no effect on performance. It's the Mediawiki:visualeditor-beta-appendix label itself, not the letters in it, that matters. (About 20 ms per page view – as I said, only a slight improvement.)
The standards for the MediaWiki labels require verbs. "Beta" is not a verb, so it is not compliant. "Edit visually" would be, although it sounds a bit clunky to me.
However, given that you have to go to Beta Features to enable it, and since it starts with a warning that it's "still in beta", and since nobody is claiming that it's "out of beta" (indeed, nobody is even bothering to define what it means for software to be "in beta" in the first place), I doubt that there is any political mileage to be gained, even if they cared about that. This will only affect people who have opted in, and the only result is to make not using it be faster (and incidentally, take up slightly less space on their screens, which I suppose some UI person might argue is making it less obvious and less likely to be used, but I doubt that it will actually matter, given that we're talking about people who voluntarily opted in). Whatamidoing (WMF) (talk) 16:45, 7 March 2015 (UTC)
"The standards for the MediaWiki labels require verbs". The possibilities for snark are endless, but I refuse to pick such low-hanging fruit.—Kww(talk) 17:19, 7 March 2015 (UTC)
I'm not quite as reserved. Nevertheless, I'll similarly avoid the obvious, really low-hanging snark, and merely point out that this "standards for the MediaWiki labels require verbs" is so well adhered to as to bring us tabs on this page labelled "Project page" and "New section". That's without even trying to look for others. Begoon talk 14:05, 11 March 2015 (UTC)
"New section" is non-compliant, and only exists at the English Wikipedia.[3] The actual label is "Add section", which is a verb.
There isn't any action associated with "Project page", so I don't think that it could be a verb. Whatamidoing (WMF) (talk) 16:20, 11 March 2015 (UTC)
On frwiki, there's "Historique" which translate back into "History" instead of "View history". It's obvious there's no verb requirements... What about changing the "Edit" translation itself to "Edit (beta)" which would be a lot more honest... --NicoV (Talk on frwiki) 16:24, 11 March 2015 (UTC)
I don't particularly care whether it says "beta" or not on en-wiki at the moment, because only users who have opted in see it. I think some indication that this is beta needs to be made if/when VE stops being opt-in only, unless the community agrees otherwise. Mike Christie (talk - contribs - library) 16:31, 11 March 2015 (UTC)
Agreed. –Prototime (talk · contribs) 18:04, 11 March 2015 (UTC)
Why not just change Mediawiki:Vector-view-edit to say "Edit (beta)", allowing you to get rid of the other page while maintaining beta? Sheesh, people, instead of snarking at each other, you could actually try to find a solution, you know. Oiyarbepsy (talk) 17:44, 7 March 2015 (UTC)
I'm not sure what all the fuss is about, but thanks for the heads up. –Prototime (talk · contribs) 23:10, 7 March 2015 (UTC)

I've always fount the way they did the label very annoying. Personally I've some javascript which changes the tabs to say "Edit" and "VE Edit". This make it quite clear which is which with the minimum of visual clutter. I don't particularly feel it needs to say Beta.--Salix alba (talk): 19:09, 11 March 2015 (UTC)

Just left this feedback in the survey, duplicating it here

  1. Paging down is broken, particularly in my usual zoom (enlarged twice); about 3 lines are missing when I page, so paging is useless if I'm looking for something or checking my work. For people who don't know it's broken, it's even worse, since they won't know they're missing things they should be seeing.
  2. The menu turns enormous when you zoom in a lot. Even just zooming twice, the menu takes two lines. It makes it harder to see things I need to see, and most of that two-line menu is white space.
  3. The screen used to sometimes shift and obscure the first half of each letter, in a way that wasn't fixable without exiting; I haven't seen this problem recently.
  4. "Clear styling" kills links; that's not usually why I want to clear the styling, and re-adding links can be a pain.
  5. Adding unstyled words next to styled text is a pain.
  6. New: VE now scrolls to the bottom of the article every time I save, losing my place.

Thanks for working on this. - Dank (push to talk) 23:43, 13 March 2015 (UTC)

Tracked in Phabricator
Task T86636
P.S. As far as I know, VE can't handle hard spaces (&nbsp;); I've tried to insert them using VE with no luck. Correct me if I'm wrong. - Dank (push to talk) 14:48, 14 March 2015 (UTC)
P.P.S I use VE every day for copyediting. - Dank (push to talk) 23:07, 14 March 2015 (UTC)

Space character at the end of an internal link

Tracked in Phabricator
Task T92896

Is there a phabricator task for preventing VE to create hideous links like [[1970|1970 ]] (like this edit with multiple edits like that). I can't find it... Is it nominated for Q3 blockers ? --NicoV (Talk on frwiki) 18:00, 16 March 2015 (UTC)

I thought that this was in Phabricator, but the closest I can find right now is phab:T53023, which isn't very close. Whatamidoing (WMF) (talk) 20:25, 16 March 2015 (UTC)
Ok, I created T92896. --NicoV (Talk on frwiki) 20:50, 16 March 2015 (UTC)

VE triage meeting this week

Hello again, as you guessed I'm here to announce that the VE team will conduct the next triage meeting on Google Hangouts and IRC this Wednesday at 4pm PST, that is 11pm UTC. As usual, you'll find other info about how to participate at mediawiki.org, and we hope to meet you there. Best, --Elitre (WMF) (talk) 17:03, 17 March 2015 (UTC)

Actually, it's 16:00 PDT, as the US has already switched to daylight savings time (*groan*). Whatamidoing (WMF) (talk) 06:36, 18 March 2015 (UTC)

<span lang="FR"> repeatedly and other things

Tracked in Phabricator
Task T71494
Tracked in Phabricator
Task T93045

In a serie of edits, the article fr:Zach Galifianakis was so damaged that I had to revert everything.

  • 1st edit: many span tags added, even sometimes a hierarchy of span tags (1 added inside an other one, also added by VE).
  • In this edit: also creation of internal links like [[MediaWiki:Badtitletext|,]]
  • In this edit: a dir="ltr" was even added to a span tag previously created by VE
  • See history for other edits that have damaged the article

--NicoV (Talk on frwiki) 18:42, 16 March 2015 (UTC)

That's a mess. I've pinged the devs. "Badtitletext" should never appear. Whatamidoing (WMF) (talk) 20:27, 16 March 2015 (UTC)
On English pages too, ie [4]. Lots of span tags and weird line breaks. VQuakr (talk) 07:35, 17 March 2015 (UTC)
Thanks. I've noted the bug numbers, and nominated them for the Q3 blockers list (as "corruption"). BTW, if you run across diffs that are particularly clean (nothing else going on, easy to figure out what the editor was doing), then please feel free to post those, too. Whatamidoing (WMF) (talk) 06:48, 18 March 2015 (UTC)

Weird bug with VE

Tracked in Phabricator
Task T75741
Bug report VisualEditor
Mito.money Please app{}
Intention: Linking to articles within references or infoboxes
Steps to Reproduce: Earlier, I was testing out VisualEditor by creating the article Haruka Chisuga. While adding an infobox to the article, when linking to Iwate Prefecture, for some reason, during the preview, the hyperlink shows up as red, even though I know that an article with such a title existed! The same thing happened when I tried to link to a an article using the "publisher" field of citations. In this case, I wanted to link to the article Oricon, and once again, despite there being an article at Oricon, the link showed up as red!
Results: Not only that, but when I saved the article, the Oricon link(and other "publisher" hyperlinks) showed up correctly as blue! Why the glitch? It easily confused me.
Expectations: While editing with VisualEditor, added hyperlinks, when added to references or templates, should appear blue rather than red.
Page where the issue occurs https://en.wikipedia.org/w/index.php?title=Haruka_Chisuga&diff=651781397
Web browser Google Chrome (version 41.0.2272.89 m)
Operating system Windows 8
Skin Vector
Notes:
Workaround or suggested solution

Narutolovehinata5 tccsdnew 14:12, 17 March 2015 (UTC)

Thanks for the note, Narutolovehinata5. This looks like a regression. It's already been fixed at least once, and must have come un-fixed in some of the recent changes. Whatamidoing (WMF) (talk) 06:54, 18 March 2015 (UTC)

Suggestions

I feel like that the visual editor is lacking functionality. There should be a button to add raw code, as well as a way to add internal things, like categories. — Preceding unsigned comment added by MrWonka (talk • contribs) 15:51, 18 March 2015 (UTC)

MrWonka,
Thanks for your note. Do you want to add wikitext formatting, or do you want to add actual code, as in what you see in Facade pattern#Example?
It's easy to add categories. See mw:Help:VisualEditor/User_guide#Editing_categories for the simple instructions. Whatamidoing (WMF) (talk) 00:08, 19 March 2015 (UTC)

Phabricator and Firefox

 Resolved

I don't know where to report problems with Phabricator, I'm reporting it here mainly because my main use of Phabricator is for VE bugs... Until recently at work, I was using a very old Firefox (17 ESR) and phabricator was unusable: I didn't report it because of the very old Firefox. I've now upgraded to Firefox 31.2 ESR, and phabricator is still totally unusable. It looks like no CSS stylesheet, icons, ... are available: it's just text and hyperlinks over a blank background, no boxes, no icons, things that are probably supposed to be hidden are displayed (Column Prototype. This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.).

Looking at the page source code, I think it's probably because all resources are coming from a different domain name (phab.wmfusercontent.org) than phabricator itself (phabricator.wikimedia.org). Could you fix this so that phabricator can be used in environments where some extra security measures have been activated ? --NicoV (Talk on frwiki) 08:43, 18 March 2015 (UTC)

Thanks for the note. I'll find one of the Phab experts for you.
Are you running NoScript? Whatamidoing (WMF) (talk) 23:51, 18 March 2015 (UTC)
Thanks. Not using NoScript, scripts are authorized on my browser, my guess is that our proxy prevents getting resources from other unrelated domains (I've the same kind of problems with Media Viewer). --NicoV (Talk on frwiki) 09:02, 19 March 2015 (UTC)
NicoV: Thanks for bringing this up. phabricator.wikimedia.org loads some content (like CSS) from phab.wmfusercontent.org. This is intentional (for the story behind, see phab:T367 and phab:T72013) and a more secure setup (if the cookie domain was the same, someone could try to use session fixation). The current setup might be improvable though, see phab:T670#1007026. I'm wondering why you don't see similar problems on www.mediawiki.org as the frontpage loads some content from bits.wikimedia.org and upload.wikimedia.org. Your browser's network console might provide more information. (And for the records, mw:Phabricator/Help is a good place to bring up Phabricator related stuff.) --AKlapper (WMF) (talk) 10:48, 19 March 2015 (UTC)
AKlapper (WMF), thanks for the answer. I haven't yet read the phabricator tasks you linked (too awful at work), but here's the output of my console when I try Phabricator main page. I looked at the content of all the wmfusercontent.org requests and they seem to be blocked by my company proxy (Blue Coat ProxySG), which is configured to work as a whitelist (only authorized domains...). I have to check if I can request adding this domain to Blue Coat ProxySG (http://sitereview.bluecoat.com/sitereview.jsp)
GET https://phabricator.wikimedia.org/ [HTTP/1.1 200 Connection established 687ms]
GET https://phab.wmfusercontent.org/res/phabricator/f1eab25d/core.pkg.css [HTTP/1.1 200 Connection established 1047ms]
GET https://phab.wmfusercontent.org/res/phabricator/2bd3c675/rsrc/externals/javelin/core/init.js [HTTP/1.1 200 Connection established 1047ms]
GET https://phab.wmfusercontent.org/res/phabricator/65e04767/core.pkg.js [HTTP/1.1 200 Connection established 985ms]
GET https://phab.wmfusercontent.org/res/phabricator/834a1173/rsrc/js/core/behavior-scrollbar.js [HTTP/1.1 200 Connection established 985ms]
GET https://phab.wmfusercontent.org/res/phabricator/5b2f5a08/rsrc/externals/javelin/lib/Scrollbar.js [HTTP/1.1 200 Connection established 985ms]
GET https://phab.wmfusercontent.org/res/phabricator/0c404426/rsrc/js/application/conpherence/behavior-durable-column.js [HTTP/1.1 200 Connection established 985ms]
GET https://phab.wmfusercontent.org/res/phabricator/f960d43d/rsrc/externals/javelin/lib/Quicksand.js [HTTP/1.1 200 Connection established 1000ms]
GET https://phab.wmfusercontent.org/res/phabricator/834a1173/rsrc/js/core/behavior-scrollbar.js [HTTP/1.1 200 Connection established 906ms]
GET https://phab.wmfusercontent.org/res/phabricator/5b2f5a08/rsrc/externals/javelin/lib/Scrollbar.js [HTTP/1.1 200 Connection established 1156ms]
GET https://phab.wmfusercontent.org/res/phabricator/0c404426/rsrc/js/application/conpherence/behavior-durable-column.js [HTTP/1.1 200 Connection established 843ms]
GET https://phab.wmfusercontent.org/res/phabricator/f960d43d/rsrc/externals/javelin/lib/Quicksand.js [HTTP/1.1 200 Connection established 843ms]
ReferenceError: JX is not defined phabricator.wikimedia.org:14
--NicoV (Talk on frwiki) 11:10, 19 March 2015 (UTC)
AKlapper (WMF), I've made a request to Blue Coat to add wmfusercontent.org to their classification. I've read phab:T367 (very short) but phab:T72013 is restricted access. The proposal in phab:T670#1007026 would probably solve most of problems since all wikimedia.org subdomains are probably accessible. --NicoV (Talk on frwiki) 18:06, 19 March 2015 (UTC)
Request accepted and it works now, great :-) --NicoV (Talk on frwiki) 08:04, 20 March 2015 (UTC)

VE meetings this week

This is the last chance in this quarter to inform the developers about VisualEditor's bugs they need to prioritize now. Show up on Google Hangout this Wednesday, 25 March 2015 at 12:00 (noon) PDT (19:00 UTC), or read the page at mediawiki.org to nominate a task for review even if you're not planning to attend the meeting. Talk to you later this week, then!

Related to VE, this Friday 27 March at 15:00 UTC an office hour about VE will be held on IRC. Previous logs and other information, including how to participate, can be found at Meta. It will be the last office hour in this format, but we'd like to discuss alternative formulas which are more useful for everybody. Therefore, please see and comment the related Phabricator task, or just come and discuss the future of these conversations with us on Friday. Best, --Elitre (WMF) (talk) 18:26, 23 March 2015 (UTC)

Links with action=edit&redlink=1

Tracked in Phabricator
Task T93627

Hi, in this edit and this edit, external links with action=edit&redlink=1 were created instead of internal links. --NicoV (Talk on frwiki) 17:33, 18 March 2015 (UTC)

That looks like user error: you get that by pasting in that URL. I think that wasn't really wanted in this case, but it might not be in all cases (e.g., anyone using VisualEditor to write software documentation at mediawiki.org might want to include the "wrong" link style). Whatamidoing (WMF) (talk) 00:12, 19 March 2015 (UTC)
The problem is that if you're looking at an article with an internal link [[Inexisting page]], that's the link that is given to the user. Why favor the almost never used cas agaisnt the usual case, favor the experienced editor against the newbie ? --NicoV (Talk on frwiki) 08:59, 19 March 2015 (UTC)
The alternatives appear to be less favorable than that. The choices are:
  1. automatically convert the link to what the newbie probably meant (force the 99%), and make it impossible for the experienced editor to make a link to this URL (prohibit the 1%), or
  2. let the newbie make a "mistake", and let the experienced editor link to that URL when s/he wants to.
I don't have strong feelings about it, but that's the tradeoff. If you believe that people like me should be prohibited from adding such links deliberately, then I can file a bug report that way. The only significant restriction is that requests along the lines of "Magically guess whether the user actually meant to link to the URL that he pasted" will be declined. Whatamidoing (WMF) (talk) 16:53, 19 March 2015 (UTC)
I think you're a bit restrictive in options ;-) First, it wouldn't be impossible, you could just go back to wikitext for example, and given how often you would need it (1% is probably way above the truth), I don't think it would be a problem. Second, what about other options, like having a setting to inhibit this behavior if you really need to write such a link ? (a little icon in the dialog box that would pop-up a menu with options ?). I would really prefer VE behaving by default so that it tends to do what newbies wanted to do, and let experienced editors find a not too much visible option for doing exactly what they want. --NicoV (Talk on frwiki) 17:52, 19 March 2015 (UTC)
At your request, I've filed a task to handle "99%" action (which is probably more like 99.99%) more sensibly. Whatamidoing (WMF) (talk) 18:37, 23 March 2015 (UTC)

Unnamed ref tags emptied of their contents

Tracked in Phabricator
Task T93228

In this edit, the contents of existing ref tags was deleted by VE, making the ref tags invalid (big red messages displayed in the article). VE shouldn't be able to end up with empty unnamed ref tags. Please nominate for Q3 blockers. --NicoV (Talk on frwiki) 09:19, 19 March 2015 (UTC)

I thought that was fixed about a year ago. Whatamidoing (WMF) (talk) 16:57, 19 March 2015 (UTC)
Apparently, it's back. I created the task in Phabricator. --NicoV (Talk on frwiki) 17:56, 19 March 2015 (UTC)
Thank you. It's been fixed in Parsoid. I'm not sure how soon that fix will reach you, though. Whatamidoing (WMF) (talk) 18:32, 23 March 2015 (UTC)
The first fix was deployed Thursday morning PST (19th March) -- it would not save pages that might be corrupted. The second fix to eliminate the problem altogether went out Thursday evening PST. See mw:Parsoid/Deployments. The bigger issue was a failure in Parsoid's testing setup to catch the bug that cropped up when VE was switched to talk to Parsoid via RESTBase instead of talking to Parsoid directly. We are on track to fix those testing holes (https://phabricator.wikimedia.org/T93315 and https://phabricator.wikimedia.org/T93316). SSastry (WMF) (talk) 21:53, 23 March 2015 (UTC)

Multiple damages

Hi, in this edit, VE did multiple damages to the article:

  • Tracked in Phabricator
    Task T93759
    Replacing correct DEFAULTSORT by an incorrect Category (starts with [[ but ends with }})

Please nominate all those problems for Q3 blockers. --NicoV (Talk on frwiki) 07:46, 24 March 2015 (UTC)

I created the five Phabricator tasks and added them to Q3 blockers. --NicoV (Talk on frwiki) 15:49, 24 March 2015 (UTC)

em tags

Tracked in Phabricator
Task T85377

In this edit, an added paragraph got em tags around a coma. --NicoV (Talk on frwiki) 17:48, 18 March 2015 (UTC)

Do you think that might have been copied from a document or website? I had something else develop em tags upon pasting (in Safari). Whatamidoing (WMF) (talk) 00:13, 19 March 2015 (UTC)
No idea where that comes from, but I don't see the point of copy various formatting tags (em, strong, ...): it clutters the wikitext (usually for nothing), there often are wikitext alternatives, and excessive formatting is discouraged on most wikis. --NicoV (Talk on frwiki) 09:05, 19 March 2015 (UTC)
If we drop them, then you can't paste in formatted bibliographic citations.
I thought that it was meant to convert it to wikitext, though. (That probably annoys people who are interested in the semantic distinction between <em>...</em> and <i>...</i>.) I'll have to ask around to find out what the current thinking is. Whatamidoing (WMF) (talk) 16:55, 19 March 2015 (UTC)
Well, on the wikis I know, best practice is to format citations using templates that ensure a common look&feel for all citations, so I think keeping the format from something copied on a web page or a document is not very useful. That's why I don't really see any interest in copying complex formatting from other sources than the same wiki (for which you would copy the wikitext). --NicoV (Talk on frwiki) 18:01, 19 March 2015 (UTC)
Here at en.wp, the use of citation templates is "neither encouraged nor discouraged". I believe that there is one Wikipedia where no citation templates exist (by choice). I have the impression that they're not much used at de.wp either. {{Cite web}} at de.wp has only 38,000 transclusions (compared to 1.9 million here). But perhaps I'm comparing the wrong templates, since that one is only used a few hundred times at fr.wp. Whatamidoing (WMF) (talk) 18:30, 23 March 2015 (UTC)
If you're looking at the templates with English names in other wikis, yes, they're not used a lot. In de.wp, you have de:Vorlage:Internetquelle for example which is transcluded in about 117k pages (I don't know how many other templates are used for formatting citations, but de:Kategorie:Vorlage:Zitation is far from being empty). In fr.wp, you have fr:Modèle:Lien web which is transcluded in more than 290k pages, and is also only one template among others... --NicoV (Talk on frwiki) 18:46, 23 March 2015 (UTC)
Thanks. I had assumed that it would redirect to the sensible local name, but apparently that's not the case.
phab:T85377 is the task number for the original question here. It appears that the answer is "probably". Whatamidoing (WMF) (talk) 18:06, 24 March 2015 (UTC)

Infobox added at an editathon with VE, whoo-hoo!

Delighted to report that an attendee at yesterday's Women in STEM Editathon at DC Public Library was spotted adding an infobox to a biography using the Visual Editor. We experienced source-only editors were suitably impressed. Congrats to all on the development team! When you feel you have VE infoboxes fully up and running and ready for prime time, perhaps you could promote this using a banner ad ... It would be a useful, gnomish activity for public-spirited new editors. --Djembayz (talk) 13:43, 22 March 2015 (UTC)

Thanks for letting me know, and for helping out at the edit-a-thon!
The WMF stays as far away from content as possible (on orders from the Legal team), so I doubt that they will run a sitebanner about that, even for something so marginally content-oriented as whether a page should have an infobox. But if you try it out a few times and think that would be a good idea, then you could request that yourself by posting a note at MediaWiki talk:Sitenotice, or (easier) by posting a message at any page where relevant gnomes might be found.
I would say that whether it feels "ready for prime time" depends upon your view of two main factors: whether someone has added WP:TemplateData to the particular template, and whether you can remember all of the facts that you want to add. The dialog covers all of the text, and it can't be moved. For some people/some infoboxes, that means that the process is open the dialog, add the name, close the dialog, look up the date, open the dialog, add the date, close the dialog, look up the place, open the dialog, add the place, etc., which is very inefficient. But when you know the material and TemplateData exists on the infobox you want to add, it is pretty cool. Whatamidoing (WMF) (talk) 18:19, 23 March 2015 (UTC)
I tend to open another copy of the article in a new tab when adding infoboxes (even using source) for ease of reference. Thryduulf (talk) 11:11, 25 March 2015 (UTC)
It's comforting to hear that I'm not the only one who does that. I use it mostly to keep track of reference numbers (previous vs current). I don't do a lot of infobox work, although I'm trying to get the new |field= added to more pages with {{infobox disease}}. Whatamidoing (WMF) (talk) 16:30, 25 March 2015 (UTC)

Add tooltip / menu button to edit table cells

Tracked in Phabricator
Task T93908

It isn't immediately obvious that you need to double click a table cell in order to be able to edit its contents. I suspect the easiest way to resolve this is to add a tooltip that says "double click to edit" when hovering over a table cell. Additionally there could be a menu icon that is activated when a table cell is selected (single click) which you click to open the cell for editing. The latter will be more work but might be more accessible. Another option would be a dismissable dialog when a table cell is selected (single click) that says the same as the tooltip - this would get very annoying though and a "don't show this again" option would be essential. Thryduulf (talk) 11:18, 25 March 2015 (UTC)

Thanks for this. I have complained about this non-intuitive behavior before, and your practical, constructive suggestions made a fine recommendation for Phabricator. Whatamidoing (WMF) (talk) 17:02, 25 March 2015 (UTC)

Multiple damages to internal links

This edit resulted in multiple damages to internal links:

  • The classic [[2008|2014]] which shows an ergonomy problem for changing the displayed text of links
  • The classic [[2008|''<nowiki/>'']] which creates an internal link with nothing displayed (nowiki + italic formatting)
  • A new one for me : the link to "Conseil général (France)" which has been applied to several parts of the text (but not at the only place that was correct)

As with most of the problems that result in unintentional damages to an article, please nominate for Q3 blockers. --NicoV (Talk on frwiki) 12:00, 30 March 2015 (UTC)

BTW, on frwiki, the first problem happens frequently enough that we have an abuse filter for it. --NicoV (Talk on frwiki) 22:52, 30 March 2015 (UTC)

Alex Trebek

I got a automated message on my talk page regarding VE, so I thought I would try another edit with it. I noticed there was a typo in the template name at the bottom of the Alex Trebek article; it is Template:Daytime Emmy Award Outstanding Game Show Host 1984–93 but it should be Template:Daytime Emmy Award Outstanding Game Show Host 1984–1993. I cannot for the life of me figure out how to add the missing "19" using Visual Editor. Suggestions? 28bytes (talk) 01:46, 27 March 2015 (UTC)

I made the edit, but I agree it's not very clear how to do it. Once you click into a template you're editing that template, so you can't replace it. I selected and copied the text of the (typoed) template, and then did Insert->Template-><paste>, and corrected the spelling. Then I applied that and deleted the incorrectly spelled template. Net actions: mouse select, Ctrl-C, click, "19", click, click, Ctrl-V, apply, click, DEL. I thought a bit about how this might be made easier and I don't see a good interface for doing it; the advantage of wikitext in this case is that you don't have to navigate hierarchical structures -- if you know what field or value to change, you can cursor right to it and fix it. Total actions would be just click, "19". The only possibility I can think of would be a "change template" button, or something like it, inside the template dialog, but I don't think it would be used often. Mike Christie (talk - contribs - library) 11:56, 27 March 2015 (UTC)
Thanks Mike. 28bytes (talk) 17:06, 27 March 2015 (UTC)
I think the "change template" button (or similar) would be a good addition. For example, on frwiki, historic lists of elected people are usually done with a template for each elected person. For the currently elected person, we use fr:Modèle:Élu actuel, and we replace it with fr:Modèle:Élu when there's a new one elected, keeping almost all the arguments with the same values. See fr:Modèle:Élu actuel for a full example. --NicoV (Talk on frwiki) 17:22, 27 March 2015 (UTC)
It's been considered before, but the team thought it wasn't very helpful. There's a 'change image' type of button in the media dialog, so the thing is presumably possible from a technical standpoint. The question seems to be whether it would be useful in the template dialog. The main problem is that parameters aren't standardized, so usually changing the name (only) of a template causes it to break, or is little different in the end from deleting it and adding the new one from scratch. Whatamidoing (WMF) (talk) 22:40, 30 March 2015 (UTC)
That's why I thought it would be low value. I can see NicoV's point, though; and there are probably other situations where this could be useful, where the parameters are mostly the same. I think this is low priority, but it shouldn't be dropped, just placed low in the queue. Mike Christie (talk - contribs - library) 22:47, 30 March 2015 (UTC)
Other examples of the same kind of uses: on frwiki when an external link in {{Lien web}} (equivalent to {{Cite web}}) is detected as broken, the easy way to mark the link is to use {{Lien brisé}} (broken link) instead with exactly the same arguments. --NicoV (Talk on frwiki) 22:57, 30 March 2015 (UTC)

Copying and editing links

Here's a sequence of steps I just tried that left me baffled. I have a simplified version of this set up in one of my sandboxes, so please try this for yourself there. I have nothing in there but "Cat", linked to "cat (disambiguation)", like so: Cat. I wanted to turn this into a list of two links, with Dog replacing Cat in the second one, so I did this:

  • Cursor to the left of the C, then shift-rightArrow three times to select the word.
  • Ctrl-C, rightArrow, <comma>, <space>, Ctrl-V. I now have "Cat, Cat." with both linked to the same cat dab page. The link menu for the second Cat is showing.
  • Click edit in the link popup menu and change the second link to "Dog (disambiguation)". Click Done. The word "Cat" is still highlit and the menu is still visible showing that it links to "Dog".
  • Start typing to replace "Cat" with "Dog" in the visible text. What happens is that the "D" of Dog takes over the link, and the "og" is now unlinked text.
  • Hit Save. This is important as something else weird happens if you don't.

I think there are two things wrong with this. First, if leaving the link selected is intended to be useful, it ought to allow typing more than one character -- it seems pointless to have one typed character exit the dialog and become the visible text of the link. There can't be any real-life situations where that's useful. I can see that allowing the user to keep typing and making that the visible text of the link might bring its own problems, but the current situation is certainly wrong. What's more, it silently destroyed the underlying link target -- that is, it changed "[[Dog (disambiguation)|Cat]]" into "[[D]]<nowiki/>og". (And that stray <nowiki/> is presumably another error.) I don't think replacing the underlying target is the right behaviour, but even if we were to decide that that's OK, I think it should not silently destroy the link.

Second, it doesn't seem to be consistent. If you have [[cat (disambiguation|cat]], which displays as "cat", and you click on the link in VE, select Edit, then Done, then type "xyz", you don't get "[[x]]<nowiki/>yz", you just get "xyz".

I asked a while back for a link to be unselected after clicking "Done", and the request was denied, I think for consistency reasons. If we're going to leave the link selected, I think this behaviour needs to be fixed. However, I still tend to think that unselecting the link would be simpler and more intuitive, even if it does bring some inconsistency into the interface.

There is a weird corollary to this. If you follow the instructions in the bullet list above, including the save, and then vedit again and select "Cat", choose "Edit", "Done", and type "xyz", you'll get the results I give above. However, if you follow the instructions above, and omit the save step, and go ahead and select "cat" and click "Edit", "Done", and type "xyz", the link to the "D" of "Dog" will vanish, even though you're not typing near it. If you now save, you'll find the page consists of nothing but "xyz, Dog". I've been able to reproduce this twice.

This is my candidate for weirdest VE bug so far. Mike Christie (talk - contribs - library) 00:23, 31 March 2015 (UTC)

Citoid!

mw:Citoid, the automagic citation filling tool, is on its way at last. It's been up at the French and Italian Wikipedias for a while, with positive feedback overall. The time isn't firmly settled, but Wednesday evening UTC is most likely.

It depends upon good TemplateData. Wikipedia:TemplateData/Tutorial explains how to write the basics by hand, but the TemplateData GUI tool is usually faster and easier. It also depends upon external services like Zotero. If your favorite website isn't working, it probably needs a new Zotero entry.

It's not perfect. In particular, the design is less than ideal. There is a book-with-bookmark button for Citoid, next to a now-unlabeled "Cite" menu for filling in citations the old way. If you have suggestions on how to improve it, then please leave comments where the designers are most likely to see them, at mw:Talk:VisualEditor/Design/Reference_Dialog. If you have other suggestions or run into problems, then please leave feedback here.

Before you ask: yes, after getting all the bumps smoothed out, the plan is to make it available in the wikitext editor as well. However, that will likely not be for some months yet. Happy editing, Whatamidoing (WMF) (talk) 00:02, 25 March 2015 (UTC)

Update: This has been delayed for a few days. DOIs aren't working as well as expected, and there are some patches going out soon (or perhaps already out by now? I think it's on a Thursday update cycle, however). Monday (late) is the more likely time now. Whatamidoing (WMF) (talk) 01:48, 26 March 2015 (UTC)

It's here!

There are a few known problems. Also, the design for the toolbar needs some work. I'll get a screenshot up later, but the short story is that you click the "book with bookmark" icon to get Citoid, and the now-unlabeled "⌄" drop down menu to find the manual versions. Please try it out and post your feedback. Whatamidoing (WMF) (talk) 02:20, 31 March 2015 (UTC)

Citoid question

I click on the bookmark logo and opt for "Or use the full citation dialog to fill in the details yourself". After filling in the fields, I would expect to wind up with a well-formed, footnoted citation. Instead, I get something like this:

Jay Z launched Tidal in March 2015.Izundu, Chi Chi (March 15, 2015). "Will new music streaming service Tidal make the waves artists want?". BBC.

Is this a feature or a bug? Barte (talk) 05:12, 1 April 2015 (UTC)

Barte, thank you very much for the report, which I brought to Phabricator. ATM, if you instead select the Cite options from the drop down next to the Citoid icon, then the citation works just fine. Apologies for the inconvenience, and let us know if you find other issues. Thank you, --Elitre (WMF) (talk) 05:47, 1 April 2015 (UTC)
Thanks Elitre (WMF). I know it's early for Citoid. Barte (talk) 06:35, 1 April 2015 (UTC)
Thanks for this note. The patch is already written. The fix should arrive here in about two hours. Whatamidoing (WMF) (talk) 16:16, 1 April 2015 (UTC)
I see on Phabricator the formal description of the problem: "inserts a cite template, not a cite template in a reference" Barte (talk) 16:26, 1 April 2015 (UTC)

Mess in reference naming

Tracked in Phabricator
Task T94712

I had to do a lot of modifications to fix all the mess made by VE in this article. As the history of the article consists of many edits with VE, I didn't dig in it to find when the problems appeared. In addition to the useless and completely silly span tags spread everywhere, there were several references with the same contents but with different names including strange reference names (:0322, ...).

If someone inserts the same content into the ref, then it will get a different number. There are people who duplicate refs deliberately here, but I don't know how common that is. I think that automatic unification of exactly identical refs would be possible (e.g., upon saving). What do people think? Would it be a good idea? Whatamidoing (WMF) (talk) 22:44, 30 March 2015 (UTC)
Yes, I get the different number thing, but I thought that VE was using incremental numbers, so I don't understand the reference named ":02322" added by VE in this edit... I would have expected a reasonable number for the reference name.
Concerning the unification of identical refs, project CheckWiki can list pages containing articles with such duplicate references (detection #81) but it's not activated on every wiki. Maybe VE could do that, but having meaningful names before would be a lot better. --NicoV (Talk on frwiki) 11:24, 1 April 2015 (UTC)
The numbers are weird, aren't they? I've filed that as phab:T94712 and sent it directly to James F. By the way, he particularly appreciated you finding the second diff there, since a diff showing just the problem being added helps them isolate the problem. Thanks. Whatamidoing (WMF) (talk) 18:20, 1 April 2015 (UTC)

Span span span span span span span span span

Tracked in Phabricator
Task T71494

What on earth is this?—Kww(talk) 04:55, 3 April 2015 (UTC)

Bloody Vikings. Adam Cuerden (talk) 05:04, 3 April 2015 (UTC)

Empty titles with nowiki tag

Tracked in Phabricator
Task T51452

Hi, in the Tech News 2015/14, it says that VE won't leave empty titles with nowiki tags any more. Each bug linked (phab:T57769, phab:T61647, phab:T52100, phab:T51452) says WMF-deploy-2015-03-25_(1.25wmf23). And on frwiki, it's 1.25wmf23 in the Version page. My understanding was then that it's supposed to be fixed in frwiki, no ? So, why this edit 17 hours ago ? --NicoV (Talk on frwiki) 16:00, 2 April 2015 (UTC)

12h after: https://fr.wikipedia.org/w/index.php?title=Nahhalin&diff=prev&oldid=113480458 --NicoV (Talk on frwiki) 05:33, 3 April 2015 (UTC)
I reopened the task. --Elitre (WMF) (talk) 07:28, 3 April 2015 (UTC)

Correct link changed to link with nothing displayed but a whitespace

When will this kind of things will be fixed ? Please stop VE from creating useless internal links with only a whitespace displayed. This is one of the many bugs that should be nominated as Q3 (?) blockers. --NicoV (Talk on frwiki) 06:01, 3 April 2015 (UTC)

I put a note here (I may have chosen the wrong task, but still). We are now in Q4, I see they're now using Editing Department 2014/15 Q4 blockers as a tag. Here is the list of what's already on it. --Elitre (WMF) (talk) 07:28, 3 April 2015 (UTC)

Snowmen

Still weird characters added by VE in articles, with a user pasting spanish text in frwiki:

--NicoV (Talk on frwiki) 19:12, 30 March 2015 (UTC)

It's not pasted. It's translated on the fly (sometimes even without the user realizing it) with a browser's plugin. (Are there many cases where snowmen need to be deliberately added to an article? If not, what about an edit filter?) --Elitre (WMF) (talk) 19:26, 30 March 2015 (UTC)
I think it's probably very rare when snowmen or other similar characters need to be added to an article. We already added an edit filter for this VE bug in september 2013, so this VE bug is damaging articles for at least 18 months. Any plan to stop damaging articles in a near future ? --NicoV (Talk on frwiki) 19:41, 30 March 2015 (UTC)
And as you can see in T59124, my last comment about this problem almost 2 months ago was simply ignored. --NicoV (Talk on frwiki) 19:45, 30 March 2015 (UTC)
There have been developments since. --Elitre (WMF) (talk) 07:39, 3 April 2015 (UTC)
And it took 17 months to be fixed because instead of looking for a solution (which seems to be trivial in the end) at the beginning, JF simply marked it invalid with bogus explanations. And it's only by asking regularly that at least someone looked for a solution... --NicoV (Talk on frwiki) 12:05, 3 April 2015 (UTC)

Odd Thing at Top of an Article

I don't think it's a bug, but when you open the article about Kate Gynther (https://en.wikipedia.org/wiki/Kate_Gynther) in VE, the first line is a jigsaw puzzle piece, followed by a line break symbol then another jigsaw puzzle piece. I'm not sure if it relates to the pictures in the article but it didn't seem to be. Red Fiona (talk) 22:43, 4 April 2015 (UTC)

They are from the zero content producing templates; {{Use Australian English}} and {{Use dmy dates}}. Click the puzzle pieces and they will tell you this. —TheDJ (talk • contribs) 23:27, 4 April 2015 (UTC)
Thanks.Red Fiona (talk) 00:10, 5 April 2015 (UTC)

Citoid - some feedback

1. Not particular to Citoid, and so certainly reported elsewhere, but still: It would be really nice, when one adds a citation, to have the new citation appear in the list of citations. It's particularly problematical to have the citations renumber themselves, in the body of the text, as they do, but to have the list unchanged (so now the numbers in the body of the text don't match what is in the list, by number).

2. It's baffling to have the cite icon (castle?) sitting next to the drop-down for cites, and the two of them not behaving the same way as the paragraph, list/indentation, and insert icons and their related drop-downs. By this, I mean that for those three other icons and their adjacent down-pointing carets, it makes no difference whether one clicks on the icon or the caret - one gets the same menu choices. That's not at all true with the Cite icon (clicked on, it opens a dialog, primarily for Citoid) and its adjacent pull-down menu (which lacks a "Cite by URL or DOI" option, but lists six other options).

I understand that (eventually) most people will use Citoid, most of the time, so being able to access it directly on the toolbar (by clicking the Cite icon) saves one click. Fine. But that's no reason to exclude Citoid from the pull-down menu accessible via the caret. If Citoid is not on the regular pull-down menu, it's quite possible that a lot of people won't find it.

3. Clicking on the Cite icon opens a dialog with Citoid, plus this link: "Or use the full citation dialog to fill in the details yourself". That link wording may be technically correct, but it's both verbose and unclear. (A menu list may, technically, be a dialog, but that's not how most people think of it). The wording "Or use another type of citation" is both shorter and clearer.

4. I'm not found of YYYY-MM-DD as a date; I'd rather use Month DD, YYYY. I understand that preferences do vary. But it's going to get really old, really fast, to have to change the date format, every single time I use Citoid, to my preferred format. Is there, or could there be, some way to set a preference, so editors don't have to change the format, every single time they use Citoid?

5. After this sequence: click the "Cite" icon, paste a URL, click "Lookup", and click "Insert", then VE displays the citation in (what appears to be to me, anyway) a dialog, with the option of clicking "Edit". If I'm not interested in editing that citation, then I assume that I should press [esc] to dismiss the dialog - that's what I do with other dialogs. Nope - if I press [esc], VE thinks I'm trying to exit VE, and asks me whether I really do want to exit VE, or not. Such inconsistency is disconcerting.

6. If I insert a citation using Citoid, and click somewhere to avoid the Edit dialog (or non-dialog), then decide I don't like the citation and click Undo, on the toolbar, the citation is converted to an empty Basic citation. It takes a second "Undo" to completely remove it. I don't understand why a single "Undo" doesn't remove it completely. -- John Broughton (♫♫) 02:51, 5 April 2015 (UTC)

Citation lookup

Hot damn! That lookup button is what I've wanted all my life. Great improvement, hope to see more of it. Popcornduff (talk) 13:28, 7 April 2015 (UTC)

Internal link created as an external link

Tracked in Phabricator
Task T94334

In this edit, a link to a local wiki page was created as an external link. Please nominate as Q4 blocker, as this is basic behavior. --NicoV (Talk on frwiki) 19:18, 7 April 2015 (UTC)

Thank you for reporting. I think this is phab:T94334, which was already accepted as a blocker and is currently being worked on. Guillaume (WMF) (talk) 21:36, 7 April 2015 (UTC)

Text moves when inserting link after scrolling

Tracked in Phabricator
Task T95360
  1. Edit a long article with VE, such as https://en.wikipedia.org/wiki/Evolution_of_insects?veaction=edit
  2. Scroll down a screenful, let's say so that the section header "Fossils" is visible at the top of the editing window.
  3. Click to place the cursor near the top of the editing window, let's say at the word "wings" in the first line of the "Fossils" section. Alternatively, double click on the word "wings" to highlight it.
  4. Create a link by hitting Ctrl-K or clicking on the link icon.

Result: Visual Editor will scroll the text spuriously, which is unnecessary and irritating.

The effect occurs whenever a link is created right after the user has scrolled the text. The effect is bigger if the link is created near the top of the editing window.

This is on Windows 7 with Chrome 41 and IE 11, using the vector skin, logged in or not doesn't make a difference. Also recently reported at phab:T95360 with no echo. AxelBoldt (talk) 20:36, 9 April 2015 (UTC)

Citations Wish List

  • Using the template is great for the first cite of a source, but terrible for the second cite from the same source. I.e., for p. 100 from the source I use the template gadget. For p. 102 from the same source, do I want to hunt up the editor, author 1, author 2, etc. etc.? OK, so I reuse the same source, change the page number and save. Darn. It has now changed the original page, too. Nasty. Slade Farney (talk) 06:59, 29 March 2015 (UTC)
    • I haven't tried to do this for a while, but this ought to work: Select the old one, and choose Cite > Basic to open it. Select and copy the contents. Close the tab. Click where the new ref should go, and choose Cite > Basic to create a new one. Paste in the contents from the first one. Edit the template to change the page number.
      Eventually, the Editing team is supposed to look at the Cite.php tool and see whether this kind of problem can be solved at the source, by making it easy to define page numbers (maybe something like <ref name=Smith 2010 page=135>). Whatamidoing (WMF) (talk) 14:27, 10 April 2015 (UTC)
  • Many of the professional journals have multiple editors and sometimes the articles have multiple authors. The current template forces the user to hunt up the surname and Christian name separately. Can that be shortened to one search and click causing both fields to be added at once? Slade Farney (talk) 06:59, 29 March 2015 (UTC)

Can no longer create articles with VE

Tracked in Phabricator
Task T96115

I tried with both Chrome and IE on Windows 7. The page just blanks and hangs. This worked a couple of weeks ago; I've created several pages with VE. Mike Christie (talk - contribs - library) 01:58, 3 April 2015 (UTC)

Mike Christie, is it still so? I can't reproduce in those browsers (although my Windows is 8 - I also tried with Monobook). Thank you, --Elitre (WMF) (talk) 07:17, 3 April 2015 (UTC)
Yes; I just tried clicking on a redlink and then clicking "Create" instead of "Create source", and it just hangs. Mike Christie (talk - contribs - library) 10:38, 3 April 2015 (UTC)
Weird. Can you tell me the browsers'versions and which skin you are using, so I can file a task for you? Thanks a lot, --Elitre (WMF) (talk) 10:44, 3 April 2015 (UTC)
Chrome 41.0.2272.118 m, and IE 11.0.9600.17501; Vector. It seems to always happen if I try creating a file; it's hung a couple of times on editing short articles too, so it may not be specifically creation that's broken. Mike Christie (talk - contribs - library) 10:53, 3 April 2015 (UTC)
And I'm not certain of this, but it seems to only happen when using the tabs to switch from edit source to edit, or create source to create. I have had no problems when I click on "edit" directly; it's switching from wikitext to VE that seems to do it. Mike Christie (talk - contribs - library) 10:55, 3 April 2015 (UTC)
Uhm. There isn't a real switch from wikitext to VE though - those are 2 separate actions, the real switch is from VE to wikitext - which also seems to work for me. Creation of a page in the File namespace also works for me. --Elitre (WMF) (talk) 11:06, 3 April 2015 (UTC)
Mike Christie, I'm wondering if this may be related to some interfering gadget, or issues with Javascript in the browser... Can I ask you to perform a last test while not logged in (just use an incognito window so you don't actually have to log out?) Thanks! --Elitre (WMF) (talk) 11:09, 3 April 2015 (UTC)
I don't think I can create an article as an IP, can I? Mike Christie (talk - contribs - library) 11:10, 3 April 2015 (UTC)
Adding ?veaction=edit at the end of the URL should work. --Elitre (WMF) (talk) 11:18, 3 April 2015 (UTC)
It works in incognito mode. Hmm. Any idea what causes the problem, and how to find and fix it? Mike Christie (talk - contribs - library) 12:32, 3 April 2015 (UTC)
The routine would be checking your preferences and deactivate gadgets one by one, checking every time if that made a difference. Scripts may be the cause as well, even if you didn't change your .css/.js pages recently. Good luck, let us know :) --Elitre (WMF) (talk) 12:36, 3 April 2015 (UTC)
It turns out that the feature labelled "Ask a question" feature for the Wikimedia Foundation's "Teahouse" project" causes the problem. I've no memory of what that feature is, or why I enabled it, so I just turned it off and everything is now fine. Who would be the right person to track down the cause of the conflict? Mike Christie (talk - contribs - library) 22:05, 3 April 2015 (UTC)
I'll take a look. Whenever you need help with a technical issue and don't know where to turn, WP:VP/T can be your first stop. BTW Teahouse is not a WMF project. —TheDJ (talk • contribs) 09:09, 4 April 2015 (UTC)
I have that gadget enabled though and didn't have Mike's issue, TheDJ. Thanks, and have a nice weekend everybody. --Elitre (WMF) (talk) 10:27, 4 April 2015 (UTC)
Yeah, I wasn't been able to find anything wrong there :( —TheDJ (talk • contribs) 13:41, 4 April 2015 (UTC)
It stopped working again for me, and after some more experimentation I now suspect that the problem was caused by Disconnect, a plugin I have installed. I've whitelisted Wikipedia and it now seems to be OK. Mike Christie (talk - contribs - library) 19:29, 4 April 2015 (UTC)

This problem is back again. I'd appreciate any pointers on what else might be causing it. It's happening for me in both Chrome and IE, Windows 7. I've disabled every single gadget, and disabled all my Chrome extensions, but I still can't create articles in VE. The only thing that works is using an incognito tab in Chrome, and of course I can't actually create the article that way since IPs can't create articles. Mike Christie (talk - contribs - library) 01:41, 8 April 2015 (UTC)

Hi Mike,
The next step is to try blanking User:Mike Christie/vector.js and User:Mike Christie/common.js. Since it happens in two browsers, it's probably something in your account, rather than browser extensions.
Also, can anyone else reproduce this problem? Whatamidoing (WMF) (talk) 14:59, 10 April 2015 (UTC)

DEFAULTSORT added after category

Tracked in Phabricator
Task T52882

In this edit, the DEFAULTSORT has been added after the category. Usually, DEFAULTSORT are put before the categories, not after. --NicoV (Talk on frwiki) 10:17, 10 April 2015 (UTC)

This is phab:T52882; I've added a comment specifically about the DEFAULTSORT issue. The problem is mostly cosmetic, though, so I'm not sure it's a blocker. Guillaume (WMF) (talk) 17:54, 10 April 2015 (UTC)
Thanks, I agree it's mostly cosmetic, that's why I didn't ask to nominate it --NicoV (Talk on frwiki) 17:57, 10 April 2015 (UTC)

Internal links with only nowiki as displayed text

Tracked in Phabricator
Task T95730

Is there any plan to fix this in a near future ? Recent example on frwiki. Of course, as I already reported it several times and said it several times, this should be nominated as Q4 blocker. --NicoV (Talk on frwiki) 14:37, 10 April 2015 (UTC)

Has this issue been reported in Phabricator? (either by you or by someone else) I can't find it off-hand but since you seem to be familiar with it, you might have more luck finding it. Also, anyone can nominate issues as blockers, and since you're very active in identifying issues, I do encourage you to nominate them directly. (Of course, I'm happy to do it as well.) Guillaume (WMF) (talk) 17:38, 10 April 2015 (UTC)
I have reported it here for what seems countless times (last time, mentioned here, reported again here (many problems reported there, most of them seem to be simply ignored) for 2015, didn't check 2014). The only thing related I could find is phabricator:T72286 which is marked as resolved.
When I find the tasks in Phabricator, I try to nominate them, but access to Phabricator from my office is not 100% functional. When I don't find them, I sometimes create new phabricator tasks. --NicoV (Talk on frwiki) 17:53, 10 April 2015 (UTC)
Thank you! Since phab:T72286 is marked as fixed, and I'm not sure if it's exactly the same issue, I've created phab:T95730 and nominated it as a blocker. Guillaume (WMF) (talk) 18:14, 10 April 2015 (UTC)

Classic awful formatting

It happens quite frequently that paragraph formatting is awful with VE, like in this edit:

  • Sentences on several lines
  • em tags

--NicoV (Talk on frwiki) 10:22, 10 April 2015 (UTC)

Did you check the material to see whether it's a WP:COPYPASTE problem? If you paste separate lines into VisualEditor, then it faithfully records what you pasted, exactly like the wikitext editor. This will be useful for formatting poems and lists, and it has always been useful for signalling possible copy-and-paste copyright violations to more experienced editors. Whatamidoing (WMF) (talk) 14:30, 10 April 2015 (UTC)
Tracked in Phabricator
Task T96006
Whatamidoing (WMF), I did try copy/pasting and VE behavior is totally wrong, even more than what I first believed:
  • Edit the page in the wikitext editor to copy the text that is on several lines, then cancel the edit
  • Edit the page in VE and paste the text you have just copied: VE displays the text on several separate lines, but if you look at the diff, it's similar to the existing text so it should be displayed as a single paragraph (with the CR lines displayed in VE). VE behavior is totally inconsistent between existing text and added text : added text is not at all displayed as it will result once the modification is saved.
Please nominate as Q4 blocker, as it is a basic feature that what is displayed in VE should look like what the end result will be. --NicoV (Talk on frwiki) 14:44, 10 April 2015 (UTC)
I think it's the same issue as in (8) in #Empty ref tags and other things. I agree that the behavior of VE is confusing, since what VE shows is not what the page looks like. Whatamidoing (WMF): Since MediaWiki (always?) collapses strings of spaces to a single space, are there any cases where we need to enter several spaces at all? If not, then VE could simply collapse them as well. Guillaume (WMF) (talk) 17:42, 10 April 2015 (UTC)
We should keep two spaces for French spacing (improves legibility of wikitext in monospace fonts). Other than that, I see no reason to have 'word space space space space space word'. But 'word line break word' (what's shown in the diff) is a different story: we can't collapse that because it might be intended to be on separate lines. Whatamidoing (WMF) (talk) 19:17, 10 April 2015 (UTC)
Do you mean English spacing? Guillaume (WMF) (talk) 19:21, 10 April 2015 (UTC)

Dragging template past end of list at end of article

Tracked in Phabricator
Task T95800

See this edit; when you drag a template down it is impossible to drag it past a list at the end of the article and it gets appended to the last line of the list. --WS (talk) 22:48, 9 April 2015 (UTC)

Filed as phab:T95800. Thanks for the report. Quiddity (WMF) (talk) 04:40, 11 April 2015 (UTC)

Internal links split into several

Tracked in Phabricator
Task T96004

In this edit, you can see that VE created several consecutive internal links to the same target. For example [[Championnats du monde de BMX 2011|2011 (]][[Championnats du monde de BMX 2011|copenhagen,DEN ]][[Championnats du monde de BMX 2011|)]] instead of [[Championnats du monde de BMX 2011|2011 (copenhagen,DEN )]]. --NicoV (Talk on frwiki) 09:18, 12 April 2015 (UTC)

Empty list items

Tracked in Phabricator
Task T96005

In this edit, VE added empty list items. It should be smart enough to replace them by empty lines. --NicoV (Talk on frwiki) 09:21, 12 April 2015 (UTC)

Language links added in the middle of the text

Tracked in Phabricator
Task T95850

Hi, in this edit (and others for the same page), language links have been added by VE in the middle of the page. It's probably a user mistake, but I think VE should never let that happen. --NicoV (Talk on frwiki) 07:07, 12 April 2015 (UTC)

The user pasted a full external link https://en.wikipedia.org/wiki/Frank_Marino which was converted to an interwiki link. This is editorially discouraged.. But what if the user wanted to do that ? I know plenty of pages that have interwiki links. Usability design issue... —TheDJ (talk • contribs) 10:12, 12 April 2015 (UTC)
TheDJ, if the user pasted a full external link, then it should had been converted to [[:en:Frank Marino]] (which is a link in the text, that's what the user wanted to do and did) and certainly not to [[en:Frank Marino]] (which is a language link outside of the text, and not at all what the user wanted to do). It's only VE that behaved incorrectly here. --NicoV (Talk on frwiki) 10:39, 12 April 2015 (UTC)
@NicoV: ah you are right. In my scenario, the link gets prefixed, but in this case it did not. The user must have typed it manually then. The link editor should probably protect against this. —TheDJ (talk • contribs) 11:11, 12 April 2015 (UTC)

Potential bug that caused the global removal of a word from an article

Hi. I'm not sure exactly to say about this potential bug because it was not my edit. However, I noticed in going through the history of List of awards and nominations received by Taylor Swift that this edit caused every instance of the word the to be removed. I assume that this was not vandalism. The edit was made by Rikripley using VisualEditor on January 19, 2015. I realize this is from three months ago, but I've never seen anything like this before. Unfortunately, I can not offer any more details, as I did not make the edit. NinjaRobotPirate (talk) 16:07, 11 April 2015 (UTC)

I think someone just used find and replace incorrectly. —TheDJ (talk • contribs) 09:54, 12 April 2015 (UTC)
Yes, that was my first thought, but the editor does not seem to be a newbie. Anyway, I wanted to put this out there in case it is actually a bug with VE. If it never shows up in any other edits, then I think we can assume that you're right. NinjaRobotPirate (talk) 13:39, 12 April 2015 (UTC)

Can't add citation on iPad (and very hard to report this bug too)

Clicked Edit on section (opened whole article in VE) - scrolled by stroking to spot to add sentence, tapped to bring up soft keyboard, typed in sentence. Looked around on screen for the add citation button, discovered the VE tool bar was not on screen, scrolled up but not there. Eventually just saved the sentence and then tried to add the citation as a subsequent edit. But nothing worked despite various attempts. Problem seems to be that as soon as you click the location for the citation, the soft keyboard displays and the VE tool bar disappears entirely or is greyed-out, making any citation or toolbar action impossible. Note on the iPad I lose this input if I switch to another app for version info, making it very hard to include URLs and other info Kerry (talk) 02:02, 12 April 2015 (UTC)

Bug report VisualEditor
Mito.money Please app{}
Intention: add sentence with citation to article William Birdwood, 1st Baron Birdwood re upkeep of his grave
Steps to Reproduce:
Results:
Expectations:
Page where the issue occurs
Web browser
Operating system
Skin
Notes:
Workaround or suggested solution

Kerry (talk) 01:52, 12 April 2015 (UTC)

@Kerry Raymond:, what kind of iPad, and what version of Safari were you using ? The reported user agent string from http://whatsmyuseragent.com would help the developers to pinpoint the problem. Also were you using VE on the mobile or the desktop version of the website ? —TheDJ (talk • contribs) 10:04, 12 April 2015 (UTC)
iPad2. Safari does not have a version number on iPad as it is part of the OS, which is iOS8.3 for my iPad2. Desktop version - I was offered both "edit-source" and "edit" and not the "pencil". Note, it is impossible to obtain this information on the iPad while reporting the bug (I am doing this now from a PC with the iPad beside me). Reporting the bug from the iPad was almost impossible, took me several attempts to get as far as I did. I nearly gave up so I am guessing bugs from iPads are very under-reported. Kerry (talk) 23:03, 12 April 2015 (UTC)

br tags inside titles

Tracked in Phabricator
Task T68846

In this edit, a title was created with a br tag at the beginning of it. --NicoV (Talk on frwiki) 09:15, 12 April 2015 (UTC)

This is phab:T68846; I also found one of those last week, and nominated the task as a blocker. Guillaume (WMF) (talk) 16:49, 13 April 2015 (UTC)

Nesting templates

Tracked in Phabricator
Task T52182

I suggest that you should make a way to nest templates in other templates. (i.e, putting a normal template GUI inside template parameters if {{ is detected instead of having to type out the template.) Thanks. PhilrocMy contribs 17:10, 13 April 2015 (UTC)

Empty ref tags and other things

Tracked in Phabricator
Task T54037

I don't know if everything listed here is still happening, but a few problems in this edit:

  • Ref tag emptied by VE. I've seen a few of them recently since WP:WCW is now finding them in error #85
  • Bold/Italic formatting incorrectly put:
    • including whitespace before and after actual text: this is useless and makes thing more difficult to edit afterwards
    • around whitespace: totally useless and unnecessary complex wikitext
    • around ref tags: totally useless and unnecessary complex wikitext
    • around punctuation: totally useless and unnecessary complex wikitext

Please nominate all the problems as Q3/Q4 blockers, as they all require someone else to come after VE to clean up articles. --NicoV (Talk on frwiki) 20:09, 6 April 2015 (UTC)

For the reference, I don't know if it's a known bug, so I'll let someone else comment. The issue about formatting of spaces before and after the text is phab:T54037; it's already a blocker and is being worked on. For the rest, I'm not sure what the problem is; It looks like the user purposefully added a lot of bold formatting, but there's not much VE can do about it. Did VE add formatting that the user didn't add? Guillaume (WMF) (talk) 22:32, 6 April 2015 (UTC)
There are many VE edits where bold/italics formatting are put in strange places, that requires someone else to clean up. I think it's probably a VE ergonomic problem since it happens so frequently: most of the useless formatting are not really visible and I don't think VE applies formatting smartly enough. --NicoV (Talk on frwiki) 05:34, 7 April 2015 (UTC)
If you link to specific edits, I can look into it to see if it's a known bug, or report a new one. However, if the users are adding bold/italics themselves and you think they shouldn't add it, then that's a social/policy issue. They probably don't know that bold/italics is sometimes discouraged in articles; helping them learn and understand community guidelines and the manual of style is part of the welcoming and mentoring of any new Wikimedian. Guillaume (WMF) (talk) 16:15, 7 April 2015 (UTC)
(1) First example of useless bold: deleted text has been replaced by a nowiki in bold. --NicoV (Talk on frwiki) 21:14, 7 April 2015 (UTC)
(2) Second example:
  • Whitespace character added between a bold text and a colon, the whitespace is added inside the bold text. --NicoV (Talk on frwiki) 21:24, 7 April 2015 (UTC)
  • First character of a word in bold is put in uppercase, the first character is not anymore in bold
(3) Third example: whitespace at the end included in bold
(4) Fourth example: comma at the end included in bold
--NicoV (Talk on frwiki) 21:24, 7 April 2015 (UTC)
Thank you, this is helpful. (2) and (3) are both instances of phab:T54037. In (2), I'm not sure what happened to the capital letter. I tried to reproduce the issue, but in my tests the formatting "bleeds" to the left so the first character is indeed in bold; let me know if you know how to reproduce it. (4) doesn't seem like a bug, since I imagine that the user included the comma in the bold. I'm looking into (1) since I'm not sure what happened. Guillaume (WMF) (talk) 17:54, 8 April 2015 (UTC)
Guillaume (WMF) It's quite possible that the user included the comma in (4), the problem is that it seems to happen quite frequently with VE without the user noticing the problem (because a comma in italic is not a lot different visually from a comma not in italic). With the amount of articles with this same issue I've already fixed, I would say there's a problem in VE ergonomy for that, because I've never seen a case where it was correct to do so. And I'm probably not the only one fixing them: for example, AWB and WPCleaner detect that as a potential problem on frwiki (as there's a typography rule coded for AWB saying that a whitespace should be present after a comma). --NicoV (Talk on frwiki) 18:11, 8 April 2015 (UTC)
Tracked in Phabricator
Task T95500
I agree; the problem is how to avoid discouraged formatting while still allowing the user to do what they want to do. We don't want autocorrections to become too smart for their own good and frustrate users. I've opened phab:T95500 to discuss this; it's not a blocker but it would certainly help new users avoid that kind of mistakes. Guillaume (WMF) (talk) 23:16, 9 April 2015 (UTC)
A few other problems spotted in the last edits with VE on frwiki:
Hey NicoV, Guillaume (WMF) alerted me to this, and it turned out that it was an inconsistency in Parsoid's serialization algorithm for which I've submitted a fix. Depending on review and additional testing, it will go out Monday or Wednesday next week. SSastry (WMF) (talk) 14:35, 10 April 2015 (UTC)
And that's less of 20mn of VE edits on frwiki. --NicoV (Talk on frwiki) 19:17, 8 April 2015 (UTC)
(10) Other example with several problems: silly span tags, whitespace included in italic, punctuation included in italic, italic just around a whitespace, italic up to the middle of a word. --NicoV (Talk on frwiki) 21:06, 8 April 2015 (UTC)
(11) Frequent problem with internal links where only the text or the target is modified but it's clearly not the user's intent. It's frequent enough that we have an abuse filter for this that detects such problem but just for links to years. But sadly no other situations are tracked by an abuse filter. --NicoV (Talk on frwiki) 15:20, 9 April 2015 (UTC)
Thanks again for all the links; it takes time to figure out what happened in each case, but it's really useful to discuss specific diffs.
(5) For the italics issues with '«' and '»' quotes, my guess is that this was due to the user selecting them (or not) when adding the italics. I haven't been able to reproduce an issue wzith formatting specifically linked to French quotes. The only possible improvement I can see helping there is phab:T95500. Same for the comma. As for the nowiki, I genuinely have no idea what happened. You've seem many diffs; do you have any hypothesis about what caused the nowiki??
(5) I think you misread the diff: the user added the quotes around the text which was already in italics (not the other way around), he has no mean in VE to decide if he is selecting also the italic marker or not, so that's VE which is deciding where the quotes are added. --NicoV (Talk on frwiki) 18:12, 10 April 2015 (UTC)
You're right, I misread it. The problem is that VE bleeds formatting only in the direction of the writing; this means that if you're writing after text in italics, VE continues to write in italics, and if you're writing after text that isn't in italics, then VE continue to write text that isn't in italics. This continuity is usually the expected behavior. In this particular case with quotes, it was a problem, but I'm not sure how it could be made better. Guillaume (WMF) (talk) 17:32, 13 April 2015 (UTC)
(6) I'd attribute this to user error; when testing this, the text entered after "Lieutenant" is in italics, since the formatting bleeds to the text; I imagine that the user noticed the italics, selected the text (but missed the opening parenthesis) and removed the italics. The text before and after the parenthesis was in italics, so it should have been obvious that the parenthesis was in italics as well, even if it wasn't very visible.
(7) That was a bug. Subbu beat me to commenting :) Thanks to your report, he fixed it. It will take a few days to be deployed.
(8) This was due to user error. I managed to reproduce the issue: the user apparently attempted to merge all the "2012" entries by having a succession of newlines (one line for the venue, one for the award, etc.), but they couldn't get the formatting they wanted because of the bullet list. So instead, they just added a ton of spaces at the end of each pseudo-line so that the content would appear on the next line. I'm not sure if VisualEditor can do much in this type of scenario to prevent that mistake.
(9) I can't reproduce this issue; in my testing, the colon doesn't get included in the link, so I'm not sure what happened there, except if the user manually re-applied the link to the text including the colon. This might be something that phab:T95500 could help with.
(9) It's not an isolated issue (I find articles with this kind of problem quite often), so I doubt it's the result of a complex user manipulation like that. --NicoV (Talk on frwiki) 18:14, 10 April 2015 (UTC)
(10) The span issue looks like phab:T71494 but it's supposed to be fixed. Maybe the issue is the mix of French and English text; I've asked the team and opened phab:T95708 to track it (nominated as a blocker). Regarding the italics on spaces etc., it's phab:T54037 again, and phab:T95500 for the comma.
(11) This one is annoying indeed, I agree. I'm not sure how to handle it, though. On the one hand, you want the link to stay the same in some cases, but in other cases like dates, it's unintuitive to keep it. It's clearly a case of user error, but I don't know how to avoid it. Maybe the best we can do is watch for that edit filter, and tell users when they make that mistake so they don't make it again.
Guillaume (WMF) (talk) 17:30, 10 April 2015 (UTC)
(11) My only idea would be something like: change the link dialog to have both target and text editable in it, and go automatically through the link dialog when editing a link: user starts typing in the link, the dialog displays having already taken into account the key typed, and the dialog would close when Enter key is pressed. The problem with the edit filter is that it finds only a small percentage of the problems because this also happens frequently with every kind of titles. --NicoV (Talk on frwiki) 18:08, 10 April 2015 (UTC)

Spacebar does not work when adding wikilink

Tracked in Phabricator
Task T96001
Bug report VisualEditor
Mito.money Please app{}
Intention: I am trying to add a space to add a new word while adding an wikilink, and no space will be added.
Steps to Reproduce: Steps taken:
  1. Click on the wikilink button.
  2. Add a word.
  3. Add a space to type a new word.
Results: The space was not created.
Expectations: That a space would be created.
Page where the issue occurs https://en.wikipedia.org/w/index.php?title=List_of_United_States_television_markets
Web browser Google Chrome 41.0.2272.118 m
Operating system Windows 7
Skin Vector
Notes: Screenshot:
Visual Editor error - space unable to be created
Workaround or suggested solution If you add the first letter of the new word, you can arrow over and a space is able to be created.

Presidentman talk · contribs (Talkback) 22:30, 13 April 2015 (UTC)

Stub template improper placement

Bug report VisualEditor
Mito.money Please app{}
Intention: Per WP:STUBSPACING, attempted to put a stub template two spaces after the categories at the end of the article.
Steps to Reproduce: Take a random stub, try to move the stub template or add a stub template to an article
Results: awkwardly places the stub template
Expectations: double spacing should work
Page where the issue occurs https://en.wikipedia.org/w/index.php?title=Aboti_Brahmin&diff=656129603&oldid=656126694 See the awkward placing https://en.wikipedia.org/w/index.php?title=Aboti_Brahmin&diff=656129718&oldid=656129710 corrected by normally editing
Web browser Google Chrome Version 41.0.2272.118 (64-bit)
Operating system Gentoo
Skin Vector
Notes:
Workaround or suggested solution

Ugog Nizdast (talk) 15:27, 12 April 2015 (UTC)

A related bug: when the article ends with a list, and you move a stub template down, it gets added as a line on the list and it seems impossible to move it to its own line. --19:47, 14 April 2015 (UTC)

nowiki around several lines, apparently for only 1 space at the beginning of a line

Tracked in Phabricator
Task T96093

In this edit, VE added nowiki tags around several consecutive lines, while the only thing that seems requiring a nowiki (and again, a correct solution would simply be to ignore the whitespace rather than adding useless nowiki tags) is a whitespace at the beginning of the first line. --NicoV (Talk on frwiki) 22:11, 14 April 2015 (UTC)

nowiki tags added around opening curly braces of an existing template

Tracked in Phabricator
Task T96090

See this edit, where an existing template has been damaged by VE. --NicoV (Talk on frwiki) 21:59, 14 April 2015 (UTC)

Interesting ... :) {{''}} is an actual transclusion. Parsoid doesn't parse that as a transclusion (it parses as plain text) and on serialization, it gets nowikied. Will have to fix the parser to recognize that. SSastry (WMF) (talk) 03:32, 15 April 2015 (UTC)

Span tags and external links

It seems that VE doesn't even handle correctly the span tags it adds in many places. For example, in this edit, the user added internal links over places where VE has already added useless span tags: the result is several consecutive external links pointing to the same URL, some of them only for a whitespace character that was previously wrongly inserted into a span tag by VE. Again, lot of work to fix this mess. --NicoV (Talk on frwiki) 13:46, 29 March 2015 (UTC)

Span tags should be fixed as of the deployment that is happening now. Please let me know if you see any more. Whatamidoing (WMF) (talk) 18:21, 1 April 2015 (UTC)
Whatamidoing (WMF) Obviously not fixed at all, multiple span tags, one inside an other, with even more useless lang="FR" attribute (on frwiki)... --NicoV (Talk on frwiki) 05:08, 3 April 2015 (UTC)
The task says it's fixed for 1.25wmf24, which isn't here yet AFAIK. --Elitre (WMF) (talk) 07:37, 3 April 2015 (UTC)
Thanks Elitre (WMF), I didn't check what tag was in the task since the first answer was saying "happening now"... --NicoV (Talk on frwiki) 07:58, 3 April 2015 (UTC)
No problem, of course! --Elitre (WMF) (talk) 10:42, 3 April 2015 (UTC)
Thanks Elitre (WMF), I see that frwiki is now running with 1.25wmf24, so hopefully there will be no new problems with span. --NicoV (Talk on frwiki) 08:15, 10 April 2015 (UTC)
I apologize for the confusion. I shall have to remember to ask them "which wiki?" the next time they say "being deployed now". It must have been in the deployment train at mediawiki.org at that time. Whatamidoing (WMF) (talk) 14:35, 10 April 2015 (UTC)
Elitre (WMF), Whatamidoing (WMF) No problem. But it doesn't seem to be fixed in all cases (example) --NicoV (Talk on frwiki) 22:07, 14 April 2015 (UTC)
That one is slightly different, so I've given it a separate report at phab:T96101. Whatamidoing (WMF) (talk) 23:09, 14 April 2015 (UTC)
Elitre (WMF), Whatamidoing (WMF) Other examples showing the problem is not completely fixed. This time, it's span tags without attributes, around simple whitespace: https://fr.wikipedia.org/w/index.php?title=Lyc%C3%A9e_Paul_Eluard&diff=prev&oldid=113829511, https://fr.wikipedia.org/w/index.php?title=Lyc%C3%A9e_Paul_Eluard&diff=prev&oldid=113829346, https://fr.wikipedia.org/w/index.php?title=Lyc%C3%A9e_Paul_Eluard&diff=prev&oldid=113828982 --NicoV (Talk on frwiki) 06:33, 15 April 2015 (UTC)

<code> tags added around closing bracket of an external link

Tracked in Phabricator
Task T96064

Why is VE adding code tags around the closing bracket ? And the second time, in addition to adding again code tags, it removes the previous closing code tag, leaving an unbalanced code tag ? --NicoV (Talk on frwiki) 18:40, 14 April 2015 (UTC)

Other example: https://fr.wikipedia.org/w/index.php?title=%C5%92uf_%28cuisine%29&diff=113846801&oldid=113846663, https://fr.wikipedia.org/w/index.php?title=%C5%92uf_(cuisine)&diff=prev&oldid=113846663, https://fr.wikipedia.org/w/index.php?title=%C5%92uf_(cuisine)&diff=prev&oldid=113846421 --NicoV (Talk on frwiki) 06:45, 15 April 2015 (UTC)

Still several problems in Wikignomish editing

OK, I thought I'd try VE again. Just a simple few edits to The Shadow Girl: italicise the title in the text and the title; stub-sort it; add a DEFAULTSORT.

1: Italicise title in lead - no problem.

2: Add {{italic title}}: first it took a while to find how to add a template (Insert, Template - but somehow wasn't obvious). It's tedious to have to click "Add template" and then "Implement changes" (or some such wording): why not just the one click? But more importantly: it displayed two jigsaw icons. So I assumed I'd added it twice. Deleted one - both disappeared. Re-added the template: two icons again. Very confusing.

3: Stub-sort: I'd rather hoped that I could edit {{stub}} into {{2010s-novel-stub}} but it turned out that all I could do was to delete the first and then add the second. Not too bad, but clunky.

4: DEFAULTSORT: Once I'd remembered that this isn't a template, it's a "page option" ... it displays the existing sort key, and won't let me edit it, or even copy it to paste and modify, I just have to type the whole desired sort key from scratch. In this case I could remember and easily retype the title, but if the title had been longer or more awkward to spell it would have been a real pain. I just wanted to cut "The" from the front and add ", The" at the end - but VE just refuses to co-operate. In the trad editor I can easily copy and paste the article title, edit it to the desired sort key, and then stick the "DEFAULTSORT" tagging around it.

5: And it added the {{DEFAULTSORT}} after the stub tag, which is against WP:MOS (specifically, see WP:ORDER).

So another fairly depressing experience of trying to use VE. Most of my complaints are perhaps of the "I don't like it" variety, but adding double jigsaw icons for the {{italic title}} seems significant and clearly "wrong". PamD 19:33, 4 April 2015 (UTC)

My two cents as a fairly frequent VE user (content and text, not gnome work, though): I agree on (2); sounds like a bug to me, and I agree that eliminating clicks would be nice. Re (3), a "change template" suggestion was discussed above and would be a nice enhancement for several common situations such as this one. I initially thought it would be rarely used but perhaps that's not the case. Re (4) I agree the default text should appear as editable text in the default sort field. Not sure about (5) -- what if other wikis disagree on the order of these elements? If it turns out there's consensus across most wikis then OK, that would be nice to have. Mike Christie (talk - contribs - library) 22:00, 4 April 2015 (UTC)
Regarding 4, you mean that you are confused by the textfields place holder, that appears when there is NO content ? Like the word "search" in the search field ? —TheDJ (talk • contribs) 23:31, 4 April 2015 (UTC)
It's not a placeholder like "search": it doesn't display "Sort key", it displays the article title. Well, perhaps slightly confused in that I hadn't thought of it as being dummy text in the same way as the word "search". OK, frustrated that VE can put that text there but not in any useful way, while still making it difficult or impossible to find a copy of the article title which I can copy and paste into that box to edit to form the DEFAULTSORT. Or even read to copy-type, if it's too long to memorise from its appearance in that box. It would be vastly more useful for editors if instead of displaying the article title in the "DEFAULTSORT" box it inserted it there as editable text, as the desired outcome is always a variation of that text - sometimes just a case of changing one letter from "é" to "e" in a long and complicated string of characters which may be in an unfamiliar language. PamD 09:57, 5 April 2015 (UTC)

I'm glad that you gave it another try. I'd also like to know what you think of the Citoid tool. (Click the book-with-bookmark icon, not the Citation drop-down menu.)

  1. Good.
  2. It's two clicks because you need an opportunity to add parameters (there are two parameters for that template).
    The double puzzle icon problem is now phab: T95720.
  3. Swapping templates is phab:T95718.
  4. You are correct that {{DEFAULTSORT}} is a magic word, not a template. You were looking at (pale gray) placeholder text, because the DEFAULTSORT key had never been set before. If it automatically adds it as editable text, then it would be even worse: It's part of the categories, so VisualEditor would add it, without you noticing the addition, when you looked at categories; for sentence-case titles of more than one word, it would almost never add what en.wp wants; there would be no way to tell whether the text that was auto-added was exactly what you wanted (and needed to make no changes to) or if you just didn't notice. This is a "least bad" choice. On the question of copying and pasting, I can add that you can paste text into the field (if you copied it from elsewhere, e.g., the URL) and that when you are changing a pre-existing DEFAULTSORT, you can copy and paste it normally.
  5. Software written to work on 800+ WMF wikis and thousands of others cannot realistically be expected to know the WP:ORDER at each one of them. For better or worse, making it follow en.wp's order (instead of some other wiki's order) was considered and rejected a long time ago. Whatamidoing (WMF) (talk) 17:35, 10 April 2015 (UTC)
By the way, I've just filed #4 as phab:T96116, on the grounds that even if it's not technically 'wrong', it's definitely not 'great', either. Perhaps someone will think of a way to make that task easy. Whatamidoing (WMF) (talk) 06:52, 15 April 2015 (UTC)

Links dialog does not permit spaces at the end of the target

Tracked in Phabricator
Task T96001
Bug report VisualEditor
Mito.money Please app{}
Intention: Create a link to an article with spaces in the title: e.g. [[Science Fantasy|Science Fantasy (magazine)]]
Steps to Reproduce: # In VE, highlight a word in the article text with the mouse.
  1. Ctrl-K to bring up the link dialog
  2. Type "Science Fantasy (magazine)". The spaces aren't accepted and you get "ScienceFantasy(magazine)".
Results: Spaces typed at the end of the link are not accepted.
Expectations: These spaces should be accepted even if trailing spaces are not normally needed, because the user needs to be able type targets containing spaces.
Page where the issue occurs N/A
Web browser Chrome 41.0.2272.118 m
Operating system Windows 7
Skin Vector
Notes: N/A
Workaround or suggested solution You can go back and add the spaces, so this is an annoyance, not a showstopper. However, this is a heavily used dialog and I think fixing this should be high priority.

Mike Christie (talk - contribs - library) 14:29, 12 April 2015 (UTC)

This bug has been patched and was backported today, so you should no longer encounter this problem. Whatamidoing (WMF) (talk) 07:30, 15 April 2015 (UTC)

Cancel buttons, icon help text

  • Please add Cancel buttons to all VE windows (including the main window). The current approach with Escape key for some windows is confusing and easily causes accidental misclicks (it's also against commonly accepted interface standards to mix different layouts for the same functionality in one application).
  • Icons for "Character style", "Simple lists" and "Table functions" have no help information when hovering over them with the cursor. All symbolic main elements should have help text, regardless of how clear they seem to be. GermanJoe (talk) 02:10, 6 April 2015 (UTC)
The second is a request for tooltips on everything, rather than tooltips on all buttons (where button ≠ dropdown menu), right? Whatamidoing (WMF) (talk) 07:22, 15 April 2015 (UTC)
@Whatamidoing (WMF): Ideally tooltips should be provided for all such button and menu elements of the finished product, yes. But from my experience, complete help functions and online information are usually among the last features getting added to developed applications ;). For now, at least all common main functions should be properly supported with tooltips. GermanJoe (talk) 17:43, 15 April 2015 (UTC)

ISBN management ?

Tracked in Phabricator
Task T54204
Tracked in Phabricator
Task T63558
Tracked in Phabricator
Task T95311

When will ISBN correctly managed by VE ? For example, in this edit, an ISBN was added by VE with the [[Special:BookSources/...]] syntax instead of the ISBN syntax. In addition, it usually comes, like in this example, with an incorrect link: the link is not to the ISBN but to an other totally unrelated. Apparently, the user did a copy/paste of the line below and then edited it. Please also nominate for blockers: article is damaged with incorrect link and overly complex syntax. --NicoV (Talk on frwiki) 05:54, 7 April 2015 (UTC)

I think this is a mix of phab:T54204 and phab:T63558 (now nominated as a blocker). I've also created phab:T95311 about the inconsistent behavior, and nominated it. Guillaume (WMF) (talk) 16:41, 7 April 2015 (UTC)
Guillaume (WMF), an other example of really bad handling of ISBN by VE... --NicoV (Talk on frwiki) 21:58, 15 April 2015 (UTC)

Weird deletion

With this edit, I just fixed a bug where VE deleted a "}"; I wasn't editing in that vicinity. This is the second time exactly this odd deletion (in this exact spot) has happened in VE ... and it's only happened (for me) in this one article. - Dank (push to talk) 18:57, 13 April 2015 (UTC)

Dank I confirmed that is an issue with Parsoid. I'll have to check if this is a bug in Parsoid or something happening because of wikitext markup errors that is tripping up Parsoid. SSastry (WMF) (talk) 15:25, 14 April 2015 (UTC)
Thanks kindly. Unwatching for now, but ping me if you like. - Dank (push to talk) 15:47, 14 April 2015 (UTC)
Fix in https://gerrit.wikimedia.org/r/#/c/204206/ SSastry (WMF) (talk) 22:43, 15 April 2015 (UTC)

Minor quips

I just started using Visual Editor on my Windows PC using Chrome and it's awesome. I have a couple quips:

  • Every time I paste something onto the page, it does this weird scrolling thing, where it shoots back up to the top of the page, then I lose my spot
  • When I go to add a news citation, each time I click on one of the parameters, the information and trash icons show up in such a way that it moves the input field I just clicked on further down the page; very annoying.

CorporateM (Talk) 07:22, 14 April 2015 (UTC)

That doesn't sound very "awesome" to me, more like a PITA. Eric Corbett 17:18, 14 April 2015 (UTC)
I get a slightly different but also irritating effect with pasting; after I paste text, the screen scrolls so that the place where I pasted it is at the bottom of the screen. This isn't as bad as scrolling to the top, since at least the text I'm working on is still visible, but it shouldn't do this. Chrome, Windows 7. Mike Christie (talk - contribs - library) 01:57, 16 April 2015 (UTC)

Random duplication

All I meant to do was this edit but VE threw in a load of unwanted duplication of existing material. Asus Transformer Pad TF300T (Android), Opera browser, Vector skin. — RHaworth (talk · contribs) 19:43, 15 April 2015 (UTC)

Thanks for the report. This is a Parsoid bug. Tracked here: https://phabricator.wikimedia.org/T96197 SSastry (WMF) (talk) 22:46, 15 April 2015 (UTC)
RHaworth, there was a markup error on that page that caused Parsoid to barf on it (which we will fix independently). But, meanwhile, I've fixed the markup which should prevent this kind of error on that page on future VE edits. SSastry (WMF) (talk) 00:08, 16 April 2015 (UTC)
Now with a fix for review so that future buggy markup like this will not trip up Parsoid. SSastry (WMF) (talk) 02:53, 16 April 2015 (UTC)

Blue loading bar stuck.

User agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; .NET4.0E; .NET4.0C; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729; rv:11.0) like Gecko

Hello WikiAdmins, In the new beta VisualEditor, it will load the page but the blue loading bar is sitting there and its not letting me edit anything, I refreshed a couple of times then it worked properly. Please fix it sometime soon. From -Micahmpj

Micahmpj (talk) 00:41, 16 April 2015 (UTC)

Thanks. It happened to me, too, this morning. I'll pass the report along. Whatamidoing (WMF) (talk) 19:26, 16 April 2015 (UTC)

Insert special character drop down doesn't work in basic cite dialog

The Ω that marks the special character drop down is visible in the basic cite menu, but it doesn't seem to be usable -- nothing happens when you click on it. Windows 7/Chrome. Mike Christie (talk - contribs - library) 11:52, 5 April 2015 (UTC)

Mike Christie, can you double-check that? It works for me, but it is very slow to open. Whatamidoing (WMF) (talk) 07:16, 15 April 2015 (UTC)
I have all my extensions and gadgets disabled, and it's working now (and is only a little slow). If it doesn't work after I reenable gadgets and so on I will post another note. Mike Christie (talk - contribs - library) 00:59, 16 April 2015 (UTC)

Category added before the end of the article

Tracked in Phabricator
Task T96496

Among other problems, this edit shows a category added before the end. --NicoV (Talk on frwiki) 08:03, 19 April 2015 (UTC)

Article swallowed as a note.

Tracked in Phabricator
Task T96555
Bug report VisualEditor
Mito.money Please app{}
Intention:
Steps to Reproduce: Edit Axial Seamount: like so.
Results: Most of the article gets swallowed by the note, making editing impossible.
Expectations:
Page where the issue occurs https://en.wikipedia.org/wiki/Axial_Seamount?veaction=edit
Web browser Latest Firefox
Operating system Windows
Skin We still support MonoBook? Jeez people.
Notes: Screenshot
Workaround or suggested solution

ResMar 22:56, 19 April 2015 (UTC)

I tried to reproduce it: I clicked on your link, and ended up in VE with the blue progress bar filling up and then staying display without any message or any way to edit the article... FF 31.2, XP (unfortunately) --NicoV (Talk on frwiki) 07:49, 20 April 2015 (UTC)
This is a Parsoid bug. We have a fix for this specific breakage, but in general commenting out ref-tags will behave differently in Parsoid right now. A quick way of getting that page editable in VE is to remove the commented-out ref tag in that article. SSastry (WMF) (talk) 17:25, 20 April 2015 (UTC)

Media search relevance sorting isn't great when long PDFs get involved

Tracked in Phabricator
Task T95223

When I use the Visual Editor media search feature (which is a great feature idea!) and put in specific keywords to find an image that I know exists, my desired image is often buried in the results after several rows of PDFs that aren't relevant to my search (that have no relevant keywords in the title or description), apparently because my search keywords are found in the text of the long PDFs.

For example, if I search for "The Marsh San Francisco Valencia" while looking for File:The Marsh, San Francisco.JPG (which includes "Valencia" in its description), that image shows up at the end of the fourth row. The first results are File:U.S. Intelligence Law for American Journalists (Part 1 of 2).pdf, File:Atlas-of-European-history-1909.pdf, File:All the Year Round - Series 1 - Volume 19.pdf, and other long PDF documents that don't have my keywords in the file title or description.

The same thing happens if I search for "Valencia Tool & Die" while looking for File:974 Valencia St., San Francisco.jpg (which has "Valencia Tool & Die" in its description) - that image shows up in the sixth row, after a few relevant images and many non-relevant PDFs.

I imagine this could be adjusted to work better for the most common types of media embedding that people are doing with VisualEditor - perhaps PDF full-text search shouldn't be part of Visual Editor media search? Dreamyshade (talk) 03:45, 6 April 2015 (UTC)

It's the same search software that Commons uses. Whatamidoing (WMF) (talk) 07:21, 15 April 2015 (UTC)
Hi Whatamidoing! That's interesting, the results are sorted differently when I search Commons and when I search within Visual Editor. For example, on Commons "The Marsh San Francisco Valencia" has the relevant photo as result #1, but within Visual Editor it's result #22. Dreamyshade (talk) 08:55, 21 April 2015 (UTC)

Unlabeled toolbar buttons are confusing

Tracked in Phabricator
Task T95233

I've recently started using VisualEditor since it helps making editing fun - thanks! I have a problem with it though, especially in recent versions - unlabeled toolbar icons are confusing, especially when they are uncommon metaphors. I can guess what the underlined italic A means, and what the link and bulleted list icons mean, since they're familiar from other word processing programs. But the bookmark icon for citations and the omega icon for special characters are not very obvious or familiar to me, and I'm an experienced computer user - I imagine they would be even less familiar to people who aren't as familiar with user interface conventions. The "hamburger" icon for more options is also likely to be unfamiliar for many newcomers. A lot of inexperienced users/editors are likely to be cautious about clicking icons experimentally if they don't know what they mean, since they're likely to be concerned that clicking the wrong button can mess something up or take an unexpected action. I'd suggest providing text labels along with icons as part of the Visual Editor toolbar for better usability for everyone, or at least testing this with real people to make sure a lot of people find it adequately usable. :) Here's an article about this topic in general.

Related to this problem, I find it confusing that clicking the cite icon does one action, and clicking the drop-down arrow next to the cite icon does a different action. This is inconsistent with the other icons and drop-down arrows in the toolbar. I would suggest making clicking the icon bring up the drop-down toolbar, and having the Citoid automatic option be an item in the list (labeled "automatic" or whatever makes sense). Dreamyshade (talk) 00:04, 6 April 2015 (UTC)

Thanks for this.
On desktop, if you hover over the unfamiliar icon, you should get a tooltip that identifies the icon. But 'hovering' isn't helpful for people on mobile devices. Whatamidoing (WMF) (talk) 07:19, 15 April 2015 (UTC)
Thanks Whatamidoing! I see that most of the toolbar buttons have alt text (although seemingly not the bold/italic button or the bulleted list button), but I don't think this is enough; those tool tips take a moment to pop up, and not everyone knows that hovering for a moment will get them more information. :) If they can't have normal text labels, the type of solution that Phabricator uses for labeling its editing toolbar icons (upon hovering you instantly get a popup of an obvious black-and-white text label) seems helpful, for example. Dreamyshade (talk) 09:01, 21 April 2015 (UTC)

server 500 error

Bug report VisualEditor
Mito.money Please app{}
Intention: Save my changes
Steps to Reproduce: I don't have a reproduction, but am finding this error more often lately. I do have a bad paragraph of text that contains refs. When I paste it into my article, it generates that error. I can't save the page to preserve or inspect the bad paragraph. I also can't switch to wiki-editing, so I don't know how to get the paragraph to you. When I open the ref in VE, it says basic, but no contents appear. Removing the ref allows the save to proceed.
Results: can't save changes
Expectations: happy ending
Page where the issue occurs
Web browser Chrome Version 41.0.2272.101 m
Operating system W8
Skin Monobook
Notes:
Workaround or suggested solution redo the work

Lfstevens (talk) 17:10, 5 April 2015 (UTC)

Lfstevens: This is very likely a Parsoid issue and could be fixed by https://gerrit.wikimedia.org/r/#/c/202996/ -- your edit (copying paragraph that contains refs) and inability to save seems related to that fix. If testing goes well, this will be deployed Monday (13th April) afternoon. SSastry (WMF) (talk) 14:25, 10 April 2015 (UTC)
Lfstevens, with luck this will have been fixed by now. Can you re-check and let us know? Whatamidoing (WMF) (talk) 07:17, 15 April 2015 (UTC)
Hasn't recurred lately. Lfstevens (talk) 22:06, 21 April 2015 (UTC)

Unable to edit any article with VE

In fact, the problem I reported just above seems to be general, I can't edit any article with VE from my office.

Here's an example of FF console output (FF 31.2, XP): 

Une demande multi-origines (Cross-Origin Request) a été bloquée : la politique « Same Origin » ne permet pas de consulter la ressource distante située sur https://rest.wikimedia.org/en.wikipedia.org/v1/page/html/Axial_Seamount. Ceci peut être corrigé en déplaçant la ressource sur le même domaine ou en activant CORS. Axial_Seamount
"One of the load requests failed (unhandled)." load.php:154
console.trace(): load.php:154
mw.log</log.warn() load.php:154
mw.libs.ve.targetLoader.requestPageData/restbasePromise<() load.php:3
.Deferred/promise.then/</</<() load.php:47
jQuery.Callbacks/fire() load.php:45
jQuery.Callbacks/self.fireWith() load.php:46
done() load.php:135
.send/callback() load.php:141

"Use of "wgPageName" is deprecated. Use mw.config instead." load.php:154
console.trace(): load.php:154
mw.log</log.warn() load.php:154
mw.log</log.deprecate</<.get() load.php:154
<anonyme> index.php:1

"Exception in store-localstorage-update:" load.php:175
"[Exception... "Persistent storage maximum size reached"  code: "1014" nsresult: "0x805303f6 (NS_ERROR_DOM_QUOTA_REACHED)"  location: "<unknown>"]" DOMException [NS_ERROR_DOM_QUOTA_REACHED: "Persistent storage maximum size reached"
code: 1014
nsresult: 0x805303f6
location: https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150415T205722Z:173] load.php:175

"Exception in store-localstorage-update:" load.php:175
"[Exception... "Persistent storage maximum size reached"  code: "1014" nsresult: "0x805303f6 (NS_ERROR_DOM_QUOTA_REACHED)"  location: "<unknown>"]" DOMException [NS_ERROR_DOM_QUOTA_REACHED: "Persistent storage maximum size reached"
code: 1014
nsresult: 0x805303f6
location: https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150415T205722Z:173] load.php:175

It really seems that your tendency to make more and more cross-origin requests is a problem. --NicoV (Talk on frwiki) 07:54, 20 April 2015 (UTC)

Sounds like for some reason the CORS headers are not properly passed to your browser. Didn't you also have CORS problems with MMV ? I don't remember exactly if it was you that was behind a CORS header stripping enterprise proxy... Regardless, it looks like they are going to move the new rest api onto the main domain for various other reasons. That change is being tracked at phab:T95229, —TheDJ (talk • contribs) 18:57, 21 April 2015 (UTC)
Yes, it's me, same sort of problem with MMV, hence the rant about the cross-origin requests ;-) I usually don't use VE, except for trying to reproduce problems I'm reporting, so it's not a big issue for me, but the fact that it simply stops without any message may be quite confusing for contributors. --NicoV (Talk on frwiki) 22:06, 21 April 2015 (UTC)

Citoid suggestions

Tracked in Phabricator
Task T96118

I am an experienced, 10 years, Top 100 most active contributors, and I am more and more impressed with your progress. Good job. In particular, your recent Citoid is excellent; it does a much better job than http://tools.wmflabs.org/refill/ . It is, however, not as intuitive as it could be. It activates if you click the button, but it is missing from the pull down list next to it. I just spend one minute remembering how to access it - I was looking for it on the pull down menu. So I suggest that at minimum, you add it to the pull down list; or combine the both into one. I'll also note that the text formatting, bullets and insert menus all have the icon and the V symbol close together and working as one button. The reference one doesn't, and by being different it is confusing. So combining seems like the most logical choice. Have the Citoid in the top, under, hmmm, Citoid or Autoformat URL or something. --Piotr Konieczny aka Prokonsul Piotrus| reply here 02:26, 20 April 2015 (UTC)

Thanks for the compliments. I believe that your sentiments about the current design are universally held, including the product manager and the design research team. However, it appears that it will take at least another month, and probably longer, to get a new design up. In the meantime, I'm asking for a temporary patch to put an item for Citoid in the drop-down menu. Whatamidoing (WMF) (talk) 17:52, 22 April 2015 (UTC)

Two things

If you hang out at this board much, then you might want to go to Special:Preferences#mw-prefsection-gadgets, almost all the way to the end of the page, and choose "Enable tracking bugs on Phabricator using the {{tracked}} template." We use that template a lot on this page, and the gadget will fill in the title and status.

Also, I know we've talked off and on about getting some decent data about VisualEditor, and it looks like our wish will finally be granted. User:EpochFail posted a barebones draft of his plans at m:Research:VisualEditor's effect on newly registered editors/May 2015 study. I'm still sorting out the details, but so far, this will affect only newly created accounts for about a week (whatever he needs to get statistical significance). Nothing changes for IPs or for current editors. I'll post more when I hear it. If you've got good ideas for metrics he should look at, then feel free to post over there. Whatamidoing (WMF) (talk) 19:31, 16 April 2015 (UTC)

Whatamidoing (WMF) So, if I understand correctly, you decide to go against the RfC that took place a long time ago about VE ? Will you (VE team) be monitoring each edit made by the newly registered editors who were selected for having VE activated by default, and then fix all the damages ? --NicoV (Talk on frwiki) 08:06, 19 April 2015 (UTC)
I don't believe that any RFC, here or elsewhere, has ever precluded a temporary test, and especially not a test that has been suggested independently by multiple volunteers. Even if it had, then WP:Consensus can change is still the policy here at the English Wikipedia.
Given the speed with which RecentChanges patrollers act here, I believe that it's impossible to guarantee that staff would check and fix all edits before other editors do. The volume with this test design would also be low, on the order of 0.5% of edits each day. However, some staff will certainly be monitoring any edits; that's standard procedure during a test. Whatamidoing (WMF) (talk) 18:02, 22 April 2015 (UTC)

True section editing separated from immediate reference editing

From Wikipedia:VisualEditor#Limitations: "In VisualEditor's model, editing sections would be paradoxically slower than editing the whole page."

I bet one big reason is that VisualEditor deals with references in a comprehensive way, unlike the wikitext editor.

Maybe a way around this would be to allow true section editing almost immediately. And BEFORE references can be edited or added. Let that function show up later, maybe 10 to 20 seconds later depending on how long it takes VE to set up comprehensive editing capability (dealing with references used for multiple facts in an article). --Timeshifter (talk) 03:21, 15 April 2015 (UTC)

No that's not the reason. The reason is primarily that there is no true section division in wikicode (anything preceding or following it can influence what is in a section and what is in a section can effect what is outside of the section). So to fully interpret (render) a section, you need the entire wikicode. This is relevant because we are converting between wikicode and a 'rendered model' of the page (otherwise you can't do wysiwyg). So no matter what you display, you always have to convert the entire page back and forth, and it is that conversion step that takes the most time. So whatever you do for section editing, you basically just need more steps, not less and it all is rooted in the fact that wikicode sections are 'sloppy'. —TheDJ (talk • contribs) 06:21, 15 April 2015 (UTC)
I admit to being clueless about how VE works internally. But I have edited web pages, and HTML is sloppy too. I mean that how the page looks depends on the screen width and resolution. One can drag the right or left side of a browser window and change how the page looks. The text flows around stuff. Stuff moves around. Unless some absolute placement of some parts is done.
I suggested previously that we might do true section editing by ignoring stuff like tables and images protruding from above the section. That is what the wikitext editor does. One can not edit or preview how that stuff will effect the section one is currently editing in wikitext. One can drop some {{clear}} templates of various types here and there. But how it works is not seen until the whole page is seen or edited. --Timeshifter (talk) 13:21, 15 April 2015 (UTC)
I've been trying for some 20 minutes to come up with a good explanation on why you are underestimating the complexity, but ... it's too hard to try and communicate these problems properly :( —TheDJ (talk • contribs) 17:14, 15 April 2015 (UTC)
I can imagine some of the difficulties due to trying to edit HTML via VE layered over Wikitext. VE has to save to both HTML and wikitext. It's not like email where one can do minor WYSIWYG editing of HTML email. That is the model I would like to follow. Editing of email. See next subsection. --Timeshifter (talk) 04:38, 16 April 2015 (UTC)
VisualEditor isn't saving wikitext. In fact, it doesn't directly save anything at all. It hands its HTML over to Parsoid, and Parsoid saves the wikitext. When you open a page, Parsoid retrieves the wikitext, converts it to HTML, and gives the HTML to VisualEditor. Whatamidoing (WMF) (talk) 18:52, 22 April 2015 (UTC)

VisualEditor Lite for true section editing

Rather than try to completely rewrite VE in order to allow true section editing maybe there needs to also be a VisualEditor Lite. :) Something for quick edits of sections. Not for templates, or anything complex. Or anything extending down from the preceding section. Most people just want to add or change a few things via WYSIWYG and quickly save. Then they may dive into wikitext or regular VE for the complex stuff.

Now, when I click a VE edit link I never know how long I will have to wait for it to load. It can take around 20 to 30 seconds to load VE for the Barack Obama page, for example. So I very rarely use VE. If I had a VisualEditor Lite I could save a lot of time while editing. Because now I spend way too much time previewing. But the alternative is constantly waiting for VE to load. I do a lot of minor edits on various pages. So it would probably be a wash to use VE more. Preview time versus loading VE time.

At least with wikitext editing I don't have to deal with nearly as many bugs as with VE. Stuff just works with wikitext editing since it has been developed for so long. That is another reason for a VisualEditor Lite. Since its goals would be smaller, the number of bugs would be smaller too. In the end I bet far more people would use VisualEditor Lite. This would also encourage more people to use regular VE too. I would use it to check for duplicate references. Now I just save my wikitext edit, and see afterward if there are duplicate references at the bottom of the article. I hear that table editing and template editing is getting better with VE. So I may start using it more, but I would be so much more motivated if I could jump start and learn with VE Lite. --Timeshifter (talk) 00:57, 16 April 2015 (UTC)

@Timeshifter: I doubt very, very much that the VE development team wants to manage two versions of VE (normal and lite) rather than just one.
More constructively, I suggest that for now you use VE with smaller articles, which will load fairly quickly, and when you encounter a larger article that you want to fix, you use section editing in the older wikitext editor. -- John Broughton (♫♫) 17:25, 17 April 2015 (UTC)
This might work for some pages. But it is hard to predict in many cases how long it will take for an article to load VE. So your idea is untenable in many or most cases.
It would be nice if Wikimedia would start, and adequately fund, a VE Lite team. Some of the money could come from the regular VE team. Some money could be raised by donations specifically targeted for VE Lite. The money spent would probably get better results than the same amount of money spent on regular VE. Better results in how many editors use the VE Lite editor vs VE regular. --Timeshifter (talk) 05:45, 20 April 2015 (UTC)

Spurious span tags

Tracked in Phabricator
Task T94509
Tracked in Phabricator
Task T95708
Tracked in Phabricator
Task T96101
Tracked in Phabricator
Task T96673

Hi, it has been reported several times with the last release, but nobody seems to answer either here or on phabricator. Could you work quickly on this one, I'm tired of seeing articles being as damaged as this one. --NicoV (Talk on frwiki) 09:42, 20 April 2015 (UTC)

Me, too. Every time I cut and paste something in Safari, I have to remember to check for span tags. I'll ask around about it tomorrow. Whatamidoing (WMF) (talk) 07:05, 22 April 2015 (UTC)
Ed thinks he's got them, but he's not sure if plain <span> tags will be fixed by the same thing that's supposed to fix the <span lang=EN-US> ones. Whatamidoing (WMF) (talk) 19:07, 22 April 2015 (UTC)

Confusing split between insert and "menu"

The insert menu is fine, but I was puzzled there is no option for inserting categories. Instead, the "menu" button on the right hides a bunch of "other" features. Categories and languages seem like they really should be moved to the insert pull down menu. Page, advanced settings and find and repalce can be left there, but it seems to me like you have room to split the find and replace into a new button, and then the "menu" can be just advanced options (merge page settings and advanced settings into one, I don't understand the arbitrary split between them). --Piotr Konieczny aka Prokonsul Piotrus| reply here 02:44, 20 April 2015 (UTC)

The idea is that "metadata" and "article content" are separate concepts and therefore should be handled separately. There is even some talk about maybe (far in the distant future) taking metadata link categories and interlanguage links out of the aticle text, and making a separate database structure for it.
I believe that the split between "Page settings" and "Advanced settings" is mostly practical: they don't want to bury some options so far below the scroll that most people will never find them. Whatamidoing (WMF) (talk) 19:10, 22 April 2015 (UTC)

Citoid with DOI's

I've just been looking at the output from Citoid with a doi.

Citoid:

{{Cite journal|title = Curvature formulas for implicit curves and surfaces|url = http://linkinghub.elsevier.com/retrieve/pii/S0167839605000737|journal = linkinghub.elsevier.com|access-date = 2015-04-21}}

Using {{cite doi|10.1016/j.cagd.2005.06.005}}:

{{Cite journal | doi = 10.1016/j.cagd.2005.06.005 | title = Curvature formulas for implicit curves and surfaces | journal = Computer Aided Geometric Design | volume = 22 | issue = 7 | pages = 632 | year = 2005 | last1 = Goldman | first1 = R. }}

We can see it misses a lot of details, author name, volume, issue, pages. It got the journal wrong as well. While the link does take you to the right place its not actually the doi link. In its current state it would be better to use a {{cite doi}} template.--Salix alba (talk): 06:16, 21 April 2015 (UTC)

Of course that only works because that doi information has already been retrieved once before, by Citation_bot. But perhaps Mvolz has some ideas how we can improve here. First of all, if we aren't even able to retrieve doi's for Elsevier articles using Citoid, then where does Citoid support DOI ?.. Second, perhaps we can index all our own doi templates, and use them as a secondary translator for URLs... I would suggest you file a ticket in phabricator. —TheDJ (talk • contribs) 18:40, 21 April 2015 (UTC)
We need to know if the problem is this one doi or one journal, or if it's all of Elsevier. Whatamidoing (WMF) (talk) 19:32, 22 April 2015 (UTC)

Something weird happened when I changed capitalisation in a couple of wikilinks

Tracked in Phabricator
Task T52678
Bug report VisualEditor
Mito.money Please app{}
Intention: Just changing the first letter in a couple of piped wikilinks from capitals to lower case
Steps to Reproduce: I haven't tried to reproduce it. I used the standard text editor to correct it
Results: The first letter of each wikilink ended up outside the square brackets
Expectations: I expected the first letter of each wikilink to be inside the square brackets.
Page where the issue occurs https://en.wikipedia.org/w/index.php?title=Pharmaceutical_industry&diff=656994465&oldid=656992271
Web browser Mozilla/5.0
Operating system Windows NT 6.3; WOW64; rv:37.0
Skin Monobook
Notes:
Workaround or suggested solution Leave VE and fix it in the old editor

Anthonyhcole (talk · contribs · email) 15:47, 19 April 2015 (UTC)

Hi Anthonyhcole,
It's a known bug. It's one of those that's a bit harder to fix than it should be.
The workaround is to change the order that you type in: If you want to turn Abc into abc, then first click between A and b, and type the new a: Aabc. Then remove the initial A to end up with what you want: abc. It's not elegant, but it works.
The de-linking is visible in VisualEditor, but only via the slight color change. Seeing the color change is usually when I remember that I need to work around this bug. Whatamidoing (WMF) (talk) 17:37, 22 April 2015 (UTC)
Got it. Thanks What! --Anthonyhcole (talk · contribs · email) 02:11, 23 April 2015 (UTC)

1 avertissement ? (1 warning)

Hi,

On frwiki, I've disabled VE in my preferences and just use it by replacing action=edit by veaction=edit when I want to try something. So I tried on my test page, and under the warning sign, I get a popup saying "1 avertissement" (1 warning) but nothing else... What's this ? --NicoV (Talk on frwiki) 16:53, 22 April 2015 (UTC)

It's because there is a 'semi' empty content edit notice in fr:MediaWiki:Editnotice-2. Recently some changes were made to the edit notice system to provision a few common patterns. This will make it easier for VE and Mobile to deal with edit notices, by making behavior of editnotices more consistent and predictable across all the different individual wikis. By changing fr:MediaWiki:Editnotice-2 to only emit content if there should be content, instead of leaving an empty div, this should be fixed. —TheDJ (talk • contribs) 17:06, 22 April 2015 (UTC)
Thanks TheDJ, MW messages have been modified by a sysop on frwiki. --NicoV (Talk on frwiki) 08:25, 23 April 2015 (UTC)

Wikisyntax replaced by HTML syntax

Tracked in Phabricator
Task T97280

In this edit, VE replaced wikisyntax by HTML syntax :

  • ''' by <b>
  • === by <h3>, == by <h2>
  • [[Image:...]] by <figure>
  • '' by <i>

--NicoV (Talk on frwiki) 11:22, 27 April 2015 (UTC)

Weird bug when adding photo

Bug report VisualEditor
Mito.money Please app{}
Intention: Adding a photo from commons to an article
Steps to Reproduce:
Results:
Expectations:
Page where the issue occurs https://no.wikipedia.org/w/index.php?title=Hilarion_Alfejev&diff=prev&oldid=13951674
Web browser Firefox unknown version (work computer)
Operating system Win7
Skin Vector
Notes:
Workaround or suggested solution

Profoss (talk) 18:35, 24 April 2015 (UTC)

Hey Profoss, how exactly did you add the pic to the page, can you describe the steps? Did you do something else? I tested (in FF as well)and nothing weird happened. --Elitre (WMF) (talk) 18:45, 24 April 2015 (UTC)
@Elitre (WMF), it was fairly straight forward, I started up the media insertion tool, copy pasted the name of the photo from Commons into the bar (at this point the page looked alright) and pressed save. I have never seen this bug before and never since. Profoss (talk) 11:47, 25 April 2015 (UTC)
This was T97155 which has since been fixed. SSastry (WMF) (talk) 15:34, 25 April 2015 (UTC)
@SSastry (WMF), lovely! thanks! Good to see that I wasn't the only one experiencing it. Profoss (talk) 15:08, 27 April 2015 (UTC)
You weren't, and thanks a lot for your report! --Elitre (WMF) (talk) 15:58, 27 April 2015 (UTC)

Citoid error

Citoid seems to have problems with some unicode characters. For example trying to format [5] it produces the title "Kielce: To by�a matka ca�ego �wiata - c�rka Ireny Sendler opowiedzia�a nam o swojej mamie" instead of "To była matka całego świata - córka Ireny Sendler opowiedziała nam o swojej mamie". --Piotr Konieczny aka Prokonsul Piotrus| reply here 06:48, 27 April 2015 (UTC)

Seems like it is interpreting the document as UTF-8, but it is in the 8859-2 charset as indicated by the Content-Type HTTP response header. —TheDJ (talk • contribs) 14:32, 27 April 2015 (UTC)
See [6]. --Elitre (WMF) (talk) 16:01, 27 April 2015 (UTC)

Speed check

This relates to Timeshifter's comments about VisualEditor "Lite" above. Would a few of you do a quick check on speed for me? Here's what you need to do:

  1. Read Barack Obama. Just click the link to see how long it takes for the page to finish loading. (In my case, it takes longer when I'm logged in because of multiple scripts.)
  2. Open it in VisualEditor. See how many seconds elapse between clicking the "Edit" link and when it looks like you could start typing. (The cancel/don't save.)
  3. Open it in the wikitext editor. Same measurement: how many seconds before you can type?
Real-world results table
Username Browser/OS Read time VisualEditor Wikitext editor Comments
User:WhatamIdoing Firefox 36/Mac OS 10.10 15 13 8
User:Whatamidoing (WMF) Safari 8/Mac OS 10.10 5 6 4
User:NicoV Chrome 42/Win 7 8-9 13-14 7-8 Using Timeline tab in Chrome developer tools
User:NicoV Chrome 42/Win 7 5 7-8 4-5 Just counting seconds
User:Dreamyshade Chrome 42/OS X 10.9 4 6 3
User:Ypnypn Firefox 37/Win 7 8 60 5 The 5 and 60 seconds may be off by about 1-2 sec
User:Ypnypn Chrome 42/Win 7 5 6 5 May be off by 1 second
User:GermanJoe Firefox 37.01, XP 20 28 15 from Germany, old PC, some scripts
User:Mike Christie Chrome 42/Win 7 64-bit 2.9 3.3 2.8 manual timing with iPhone stopwatch. First time I opened the article it took 13 seconds, but it's reliably around 3 seconds now. I see I have the fastest times so far; this may partly explain why I like VE more than some other editors do. 8Gb of RAM might be helping too.
User:Mike Christie Chrome 42/Win 7 32-bit 2.8 3.3 2.8 manual timing with iPhone stopwatch. 8Gb of RAM; this time it took about 9 seconds the first time I opened the article, but after that it takes under 3 seconds.
User:Timeshifter Firefox 37.0.1, Win Vista 32-bit 22 22 5 timing via date/time control panel clock. 9 year old PC. 3 GB RAM. Maybe we could provide a number from one to five on all articles indicating the relative VE loading time in Firefox. One being fastest, five being slow loading like Barack Obama page.
User:Timeshifter Firefox 37.0.1 safe mode, Win Vista 32-bit 9-15 22 5 I restarted Firefox in safe mode (all addons disabled). Time to load for reading was faster. VE and wikitext load times unchanged. I did a few runs, and cleared caches between each run (via history menu).
User:Timeshifter Chrome 42, Win Vista 32-bit 6 8 4 Did several runs. Cleared all caches between runs (via history settings). I dislike using Chrome though, due to almighty Google spying on all we do.
User:Redfiona99 Chrome 40, Linux, Mint 7 6 3
User:Redfiona99 Firefox 36, Linux, Mint 6 16 3 The two runs were done back to back on the same machine.
User:This, that and the other Firefox 37, Windows 8.1 (WOW64) 39 [1] 22 [2] 3 Notes: [1] I have the "auto-number headings" preference turned on, which means MediaWiki has to re-parse the page just for me (it can't use the parser cache). That probably helps to explain the high load time. [2] Failed the first time after 31 seconds, with error "Error loading data from server: HTTP 0. Would you like to retry?" (my translation of this: "the request timed out"). Then I clicked OK, and it took 22 more seconds.
User:NicoV Firefox 31.2 ESR, Win XP 12 10 3-4 Just counting seconds
User:John Broughton Firefox 37.0.1, Mac OS 10.10.3 8 21 3
User:SPage (WMF) Browser/OS Read time VisualEditor Wikitext editor Comments
Your turn!


I'm expecting some variability in the results. One of the things I'm curious about is whether Firefox is always the slowest, or if it's just my account (or the thirty-odd tabs I have open in Firefox). Whatamidoing (WMF) (talk) 19:05, 22 April 2015 (UTC)

Thanks to everyone who has posted information so far: User:NicoV, User:Dreamyshade, User:Ypnypn, User:GermanJoe, User:Mike Christie, User:Timeshifter, User:Redfiona99, User:This, that and the other. This is really great. If you haven't added your numbers yet, then please do!
I'm not surprised that it's faster the second time around. It probably has a lot of the page cached by that point. It looks like Firefox is slower than Chrome, which is consistent with what I'm hearing out of the lab. At a glance, our numbers seem more diverse but slower on average than theirs. I don't think that this is surprising, but it's good to have real-world data. Whatamidoing (WMF) (talk) 21:56, 27 April 2015 (UTC)

<a> and <style> tags added by VE

Tracked in Phabricator
Task T97279

In this edit, VE added <style> with CSS code and <a> tags.

The <a> tags are forbidden and I doubt the style tags should be used with CSS inside. --NicoV (Talk on frwiki) 11:16, 27 April 2015 (UTC)

With all of the "badges.instagram.com/static/images/ig-badge-sprite-48@2x.png", I'm going to guess a copy-paste problem. It might be interesting to see whether anyone with an Instagram account can replicate this. Whatamidoing (WMF) (talk) 22:04, 27 April 2015 (UTC)

Fail to load VE immediately after a VE save

Tracked in Phabricator
Task T97069
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36

I'm working on User:Whiteghost.ink/Scheepvaarthuis. When I make any edit using VE and save, if I then immediately try to "edit" again the system gives me this message:

"Error loading data from server: ve-api: Revision IDs (doc=658818023,api=658818363) returned by server do not match. Would you like to try again?"

If I press cancel, refresh the page, then "edit" again, it works fine. However, this problem appears every time I save a change and want to continue editing.

I'm using v42 of Chrome on OSX 10.10.

Whiteghost.ink (talk) 10:00, 23 April 2015 (UTC)

Hi Whiteghost.ink,
Thanks for this report. I've linked the bug here in case you want to track it. This should be fixed here now. Whatamidoing (WMF) (talk) 22:11, 27 April 2015 (UTC)

VisualEditor Feedback

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2376.0 Safari/537.36

It's perfect. Honestly, I wish editing Wikipedia was like this all along.

7degreedarkness (talk) 23:38, 21 April 2015 (UTC)

Thanks for the compliment, 7degreedarkness. Happy editing, Whatamidoing (WMF) (talk) 22:12, 27 April 2015 (UTC)

Insert media a bit confusing

I am teaching editing Wikipedia to ESL university students. They find inserting pictures in Visual Editor a bit confusing. Not all get that insert picture is a "unwritten" part of insert media. I'd therefore suggest changing "Media" to "Pictures and other media". It may take two lines, but space is not really an issue. Second, it is not really clear you can search for things through the search bar, nor that it accepts File:Name for specific files. Both me and all my students found it a bit confusing; particularly as the Wikipedia/Commons image search is still pretty bad. What we do is we go to a relevant category, look at the commons gallery there, chose a picture, copy the file name and paste it into the Insert Media. In other words, we find the current search promising but poor, and the fact that the tool doesn't say you can paste it File:Name into it confusing. The tool should understand and parse file names, with or without the File:, as well as URLs to wikipedia/commons images (simply remove the http blah blah junk). The window would benefit from a comment that you can paste specific file names / links there, as well as from a link to the Commons gallery. It could use template Commonscat and other commons templates, or just check whether relevant categories / pages exist on Commons,or just have links to them "relevant galleries may exist on Commons" or such. In summary, what most newbies see when they use it is a selection of mostly bad images. They don't know how to get more, nor how to link the ones they found on Commons or elsewhere. PS. Linking to Creative Commons BY-SA and such image searchers may be useful, too, but that's probably for after we get the basic functionality polished. --Piotr Konieczny aka Prokonsul Piotrus| reply here 02:37, 20 April 2015 (UTC)

I've been using VisualEditor for a little while now, and I didn't know until reading this that I could just paste a filename into the media search box if I know which image I want to use. That kind of workflow is convenient for me, especially since I often upload photos to Commons and then go insert them into Wikipedia articles, and I agree that it would be nice to make this more discoverable. Dreamyshade (talk) 09:07, 21 April 2015 (UTC)
Piotr Konieczny,
Here's a list of some of the ideas here:
  1. Change the name from "Media settings" to "Pictures and other media". Length is a problem when translating (e.g., to Russian), but this is a large dialog box, so it might still be okay.
  2. Make the search icon (magnifying glass) more prominent.
  3. Make it possible to search for https://commons.wikimedia.org/wiki/File:Sandbox.png instead of just "File:Sandbox.png" or "Sandbox.png" (both of which already work).
  4. Add a tooltip or GuidedTour that tells people how to search for files.
  5. Search won't find non-Files on Commons. Galleries and Categories can't be inserted, so it's not appropriate to add them to results. However, it could provide a "Click here to go to Commons" link, which could be a link to the same search term at Commons, including cats and gallery pages.
Does this sound like a fair description of your ideas? Whatamidoing (WMF) (talk) 22:22, 27 April 2015 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback/Archive_2015_1&oldid=1144966637"