I'd like to suggest an improvement for VE: since it's quite easy for a new editor to delete a <references/> tag without noticing, that would be nice if VE prevented saving such error (or at least put a warning) when the article was ok before editing and damaged after editing (error message displayed in the article). --NicoV(Talk on frwiki)16:05, 30 October 2013 (UTC)
Hey NicoV - I'd love to do this (or better yet, just put a <references /> tag at the bottom of a page if there isn't one there), but unfortunately the widespread use of encapsulated reference lists (using the {{reflist}} template and its brethren) means VisualEditor has no idea whether or not there's a reference list on the page until it's gone through the Parsoid path for conversion into wikitext and been saved in MediaWiki. There are a number of enhancements around about this, most noticeable of all is to move all the functionality of the {{reflist}} template into the Cite extension so that the template can be replaced, and a few more. Sorry it's not so easy as it may appear. Jdforrester (WMF) (talk) 19:40, 30 October 2013 (UTC)
@Jdforrester (WMF):, is there a central location for discussing the long-term strategy for citations/references? I'd like to add my two cents to the case for storing a durable identity for reference sources – separate from article space – to which citations would connect. - Pointillist (talk) 22:58, 30 October 2013 (UTC)
@Pointillist: Though the linked workshop might interest you (thanks, Elitre!), there's a wider discussion to be had about replacing the existing references system with a proper citation system allowing cross-page and cross-wiki sharing of sourcing information and tracking. I've got some rough thoughts that I should probably write up at some point, but there's no current discussion about them, sorry. Jdforrester (WMF) (talk) 00:51, 31 October 2013 (UTC)
@John Vandenberg: I don't think that that's a great solution - it adds complexity to the user without making a lot of useful things possible (e.g. noticing that a new edition of a book has come out and pinging all the editors of pages using that citation about there being a library nearby with a copy). We should consider it a short-term hack, and not spend too much time trying to make it better, I think. Jdforrester (WMF) (talk) 00:51, 31 October 2013 (UTC)
@John Vandenberg: Exactly - though I'm not sure that that's the best solution, it's a lot better than yet another namespace. :-) Possibly we'd want to look at something built off Wikidata rather than try to import a totally new technology, but we'll see. Jdforrester (WMF) (talk) 06:07, 31 October 2013 (UTC)
Separate source from citation, so source can be re-used in multiple articles
Store sources somewhere in a structured form, a bit like an in-house collaborative zotero. Maybe allow editors to sandbox their sources while preparing a major edit?
Make citation easier: if you select a stored source, the appropriate template is pre-populated for you. Must be easy to use—"More Kirk, Less Spock."
There's some hierarchy possible, e.g. a citation can refer to a quote on a specific page of an article published in a book, e.g. {{cite book |page=417 |quote="Lorem dolor sit amet..."|author= Baron-Cohen S |authorlink= Simon Baron-Cohen |chapter= The evolution of brain mechanisms for social behavior|title= Foundations of Evolutionary Psychology |editor= Crawford C, Krebs D (eds.) |publisher= Lawrence Erlbaum |date=2008 |isbn=978-0-8058-5956-0}}
Tools allow stored sources to be searched/listed by title, publisher, author/editor, URL, ISBN, DOI, PMI.
There's something like categories for grouping sources together for ease of discovery.
Each stored source has a talk page (board) where independence, reliability, editions/translations, updates of URLs etc can be discussed
If implemented as a shared space like WikiData, any discussions/notifications should Flow/Echo to other wikis appropriately—thread about citing source X in article Y is visible on both X and Y's talk pages.
Editor can easily navigate from source to "where cited" for maintenance and curation purposes.
Big wins: easy to cite; easy to maintain sources; drives up article quality; attracts/retains the sorts of editor we need. - Pointillist (talk) 10:54, 31 October 2013 (UTC)
(After) feedback
I just worked on a page and had a problem (reported above). So, I used the feedback option. I have two issues with that option. First, it is not clear that the feedback will be posted with-out (at least as far as I can see) any indication of what site the editor is on when s/he fills out the form. I had assumed that that information would be included automatically ( like in some discussion articles on requests for deletion etc.). Since /If it isn't, the editor fling the feedback should be given a heads up, since viewing the specific site is often needed for others to understand the problem, and the editor might not come back for a while or might have edited a lot of sites and not remember which one had the problem. Second, after completing the feedback and sending it, I was still on the VE page, but I cannot save the page (the button is light green and inactive). It seems the only way to exit is to cancel, losing any changes I might have made (actually, after writing the feedback, I don't remember if any of my changes were made in that session, so it's possible, there are no changes to be lost, but still....)Kdammers (talk) 02:13, 8 November 2013 (UTC)
It works for me. Can you test it again, making sure that you have changed the page before leaving feedback? Fram (talk) 09:29, 8 November 2013 (UTC)
Well, yes. It seems to be because there were no changes made. But, as I noted, some-one might not remember if s/he's made changes. (I can't tell if it works otherwise, at the moment, since VE is claiming I used wikieditor, when I have not, only clicking on the link icon and typing plain text.)Kdammers (talk) 12:10, 8 November 2013 (UTC)
So, I just tested. I could leave my feedback, and I could save my edit later. What I think might be slightly confusing there, is that the bug report goes to Bugzilla, and this is not mentioned. We might work on this, I'll let you know. As for the feedback here instead, the page where the comment is posted is clearly mentioned twice, and can be opened elsewhere by right-clicking. I am not sure if or how this should be furtherly improved. --Elitre (WMF) (talk) 12:42, 8 November 2013 (UTC)
The report is going to bugzilla???? What the heck? Bugzilla isn't even an SUL project, it displays non-public information... Geez, guys. It should transclude onto this page. Risker (talk) 03:04, 9 November 2013 (UTC)
So the story is that the feedback tool is not specific to VisualEditor. The only thing that VisualEditor has any control over is the link (to this page). But James A is going to see whether it's possible to get the rest of the text clarified for everyone, which would obviously include us, too. Whatamidoing (WMF) (talk) 22:58, 18 November 2013 (UTC)
I use VE once in a while for simple edits. Today I made this edit to add quotation marks for song titles and used the edit summary "added quotation marks". When I checked my edit after saving, I was surprised to see that VE correctly added some additional quotation marks in <ref name> tags, but was happy it was consistent with my edit summary. :-) GoingBatty (talk) 00:45, 11 November 2013 (UTC)
I think we've seen VE doing this before, and it's an unnecessary and undesirable change: quote marks are not needed round single-word reference names, and personally I carefully choose single-word or hyphenated names to avoid the unnecessary clutter (and extra keystrokes) of using quote marks. I don't know why VE does this "genfix", but it shouldn't do so. See WP:NAMEDREFS: "Quotes are optional if the only characters used are letters A–Z, a–z, digits 0–9 and the symbols !$%&()*,-.:;<@[]^_`{|}~". PamD08:37, 11 November 2013 (UTC)
I asked about this, and it turns out that while quotation marks are "optional", they're only optional because they added some code to cope with people forgetting them. The Correct™ approach is to use quotation marks for all ref names, and so VisualEditor adds them. However, VisualEditor should only be adding them to the specific paragraphs and/or refs that you changed during that edit, not all over the page.
This is due to a bug in Parsoid that is only triggered under specific circumstances (a cacheing problem + a timeout error), and since the fix went live here a couple of days ago, you shouldn't see it any longer... or at least, we should see it much less. Please report any new instances of this. Whatamidoing (WMF) (talk) 23:07, 18 November 2013 (UTC)
Just confirming this bug. It complains there is no reflist for refgroup 'N', but the page does contain {{Reflist|group=N}}. I've tested with a longer group name, and without any group name. The group name isnt part of the problem. --John Vandenberg(chat)05:05, 14 November 2013 (UTC)
If the refs are actually displayed within the gallery (the only way I could think of was to make them part of a caption; see here), then the error does not appear. I think that the gallery itself is being treated as if it were a completely separate page. As a result, this may be one of those things that is automatically resolved as soon as any gallery editing is supported at all. I filed it as T59216. Whatamidoing (WMF) (talk) 23:36, 18 November 2013 (UTC)
Type or change some of the text (I was adding a new first line).
Select and cut (⌘ Command+x) some pre-existing text (I cut mine from the third line).
Notice that what you typed on the first line has been undone.
Paste what you cut (in my case, at the end of the first line).
Notice that what you typed on the first line has been redone.
I ran into this over at office.wikimedia, but office is also running MediaWiki version 1.23wmf3 (2ac963d), so it should behave the same here. I particularly want to know whether this is a Mac/Safari/Vector issue, or if it also happens elsewhere. Thanks, Whatamidoing (WMF) (talk) 20:21, 14 November 2013 (UTC)
Confirmed, mostly, with Vector/Chrome 30/Windows 7 – except that the first letter of the line does not disappear. The missing text only reappears when the cut text is pasted onto the line with the missing text. - Evad37[talk]00:14, 15 November 2013 (UTC)
Just tried out VisualEditor for the first time on ATV: Quad Frenzy - I was amazed, this really does look like the future. This will engender a massively improved user experience, I could honestly see this having a relatively large affect on editor retention. One piece of constructive criticism that prevents me from switching fully to VE is this - it has no ability (I believe) to integrate with the current reference gadget I use - it is one the far right of my editing toolbar, and is two {{ brackets on top of CITE, and two more }} brackets beneath that. This is a tool I use constantly when creating content and immeasurably useful, so to not be able to use it is in my view, the hamartia of VisualEditor at the moment. Would you consider integrating it? Keep up the amazing work! Acather96 (click here to contact me) 19:39, 16 November 2013 (UTC)
There is currently discussion about improving the Referencing with VisualEditor here, but unfortunately it's still in the very early planning stage. -- Ypnypn (talk) 01:49, 18 November 2013 (UTC)
I looked the feedback page and I can't find if someone mentioned that. I don't know if it was mentioned before and it was archived but I think it's new. When I try to add a reference that already exists I can't see the list of them. I mean, when I was clicking to "choose an existing reference" in the past, I could read the whole references content. Now when I do that, I can only see the numbers of the references and not their content. To find which reference I need, I have to get out of the window, find it on the main text and see its number so I can choose it. I don't know if it has to do anything with it but, I feel like after the last VE update few days ago (last Thursday), some things got messed up :( TeamGale23:03, 16 November 2013 (UTC)
I'm seeing the same thing (FF 24.0, Mac OS). I can see just a few characters for a couple of references, on the far right of the dialog box, out of 20 or so, but essentially it's just numbers on the left side of the dialog box, and a vast empty space in the middle and right side. So, yes, "Use an existing reference" is completely f***ed up, now - yet another regression. -- John Broughton(♫♫)05:36, 17 November 2013 (UTC)
When editingKLM, when I hit save page I got Error:Unknown error below the edit summary box and a greyed out save page button. However, the edit still saved without any indication that it did so. I actually went to save the page again, not thinking that it had done anything, but luckily checked the history and canceled before it could save (Monobook, Firefox 25, Windows 7):Jay8g [V•T•E] 19:40, 16 November 2013 (UTC)
Well, this is odd: Apparently the second time I hit save it actually did save (see here), and decided to add quotes around everything, despite the fact that it did not do this during any normal edit, and it changed nothing else:Jay8g [V•T•E] 19:46, 16 November 2013 (UTC)
I've run across that unknown error before, too, and it's always saved for me. I've never figured out what's causing it.
Adding the quotation marks around the ref name is (1) technically correct and (2) not supposed to be happening unless you edited that paragraph (or possibly unless the ref itself).
I'm wondering if these two might be related—if whatever caused the unknown error triggered the addition of the quotation marks. Does that seem plausible? Whatamidoing (WMF) (talk) 20:17, 18 November 2013 (UTC)
AFAIK the Unknown error message is what you get when you edit a "large" article (I'm now convinced this defines possibly each article slightly larger than 100kb) and it may or may not result in the system actually being unable to save the edit (since you can also get it for apparently no reason). 53093 does not report anything about quotes, though. --Elitre (WMF) (talk) 20:28, 18 November 2013 (UTC)
This was likely an issue with one of the Varnish caches in production. It ran out of backend connections, which caused some requests to fail. Since this was so rare it was fairly difficult to track down. Sorry for the inconvenience. -- Gabriel Wicke (talk) 01:09, 19 November 2013 (UTC)
Main missing or poorly working aspects (mainspace)
So, what do you consider the main remaining missing or poorly working aspects of VE? I'll list a few I think of right now, feel free to add your own (I'm bound to froget some very common ones). It may give an indication of where the most urgent problems are situated and which things shouldn't be forgotten... Fram (talk) 15:34, 7 November 2013 (UTC)
Galleries can't be used
Tables can hardly be used
Copy-paste removes all markup
Redirects
File handling (location, replacing, sizing, ...)
Scrolling (with arrows, or after copy-paste of text)
Wiki-markup isn't supported
...but Wiki-markup is necessary in templates
Citation templates
Performance, obviously
Different look in VE than in view mode (whitespace between templates and so on, compare e.g. Internet Archive standard and in VE mode)
Reference numbering in VE mode restarts in text when there are refs in the infobox
PLus many more minor bugs (minor in the sense of less often occuring, not necessarily of having less serious consequences, e.g. the problems on moving navboxes)
Some more:
Hidden comments <!-- ... --> aren't shown
Special characters (no way to insert them, no way to know if existing spaces are ordinary spaces or non-breaking spaces)
Redlinks are not red
Transclusion editing interface: It is horribly inefficient for editing, showing only one parameter value at a time, and requiring scrolling/looking through the list, and then clicking on each parameter you want to edit. A design that is more like the interface reftoolbar uses for the cite templates - ie, being able to see and edit many parameters AND their values all at once - would be a huge improvement. Also, if many templates are used consecutively, such as {{jctint}} and related templates (which build a table row-by-row), it is impossible to edit just one of these templates - the transclusion editing interfaces groups everything together on the left-hand scroll list, making it difficult to find the spot you want to edit - especially if the same template with the same parameters is used repeatedly (maybe 20+ times) in the group of templates.
@Fram and Evad37: We're in agreement on most of these issues and "just" need to work through them (each of them tends to be far more complex in practice than it looks at first glance). Regarding differences between view/edit mode, some of them can't be helped if you want to preserve e.g. line-breaks in the wikitext during roundtripping (which is debatable in the long run). Some are due to the "slug" user experience; see bugzilla:47790. Some are Parsoid output issues that will be gradually improved. Regarding wiki markup in templates, the goal is to render mini-VE invocations for filling in template parameters except in cases where it's absolutely not possible to do so. And as you know we're not going to support raw wiki markup in VE itself.
Citations and transclusion user experience is one of the highest priority issues and you'll see some significant improvements there soon. Our main concern is to not get too drawn into the specifics of one wiki or set of templates, but come up with good solutions that leverage e.g. community-editable template metadata and enable editors to create a pleasurable and efficient experience working with various templates.--Eloquence*02:43, 9 November 2013 (UTC)
"And as you know we're not going to support raw wiki markup in VE itself." Yes, I know. I still haven't seen a single convincing reason for this, so I will continue to list this as a serious shortcoming of VE, even when every edit can be done in VE, but a lot more so as long as editors still need wikitext editing anyway, in VE and for things not supported by VE at all, and as long as VE shows wikitext in things like "review your changes". You shouldn't expect people (new editors) to learn wikitext editing, and then tell them that they can't use even the most basic wikitext markup in VE, not because VE can't handle it (it can handle it perfectly allright), but because the devs (or their bosses) explicitly but inexplicably don't want it. 10:11, 15 November 2013 (UTC)
Yes, it does seem odd that VE is smart enough to detect wiki markup being entered, but not smart enough to turn it into properly formatted text. It would be magic if it could turn [[link]] into link, '''bold''' / ''italic'' into bold / italic, and {{cn}} into as I type. - Evad37[talk]12:32, 15 November 2013 (UTC)
Yes, we know. A long time ago, I still thought that the decision not to support wikicode had a technical reason, but it has since become abundantly clear that the only reason is that the devs don't want this, even though they aren't the ones using it. The complete disdain for the editors for which they are developing this software is quite surrealistic (see also the "bitching about testing" section). Anyway, "it never will" is to be taken with a grain of salt, it would never become opt-in either, until the WMF was taken out of the equation and enwiki took things into their own hands. Fram (talk) 08:03, 18 November 2013 (UTC)
It's a design decision, not a technical limitation.
Dave, the question isn't being smart enough to turn it into properly formatted text. The question is being smart enough to know when I mean for [[Example]] to be a link to that article and when I mean for that to be something else: perhaps an explanation of how to use wikicode to make a link (e.g., on dozens of Help: pages), or perhaps part of a direct quotation, or perhaps when I'm merely adding it for decorative value (e.g., as ASCII art, like [[-]]-[[-]]-[[-]]-[[-]]). In the mainspace, here at the Wikipedias, an experienced editor who types double-square brackets almost always means for that to be a link. But outside of encyclopedia articles, or if the user is less experienced, it is much harder to guess what the actual intent is. Whatamidoing (WMF) (talk) 22:38, 18 November 2013 (UTC)
The main space is all I care about really, VE is hardly used outside of it anyway (in user sandboxes, but these are intended to be mainspace articles anyway). I know that VE has to decide one way or another, but why have the devs chosen to go with the least likely solution? The logical thing would have been to interpret things like they are most often intended, not like they are least often intended. Even better would of course be a choice (a "nowiki" button if you really need to have a nowiki), but absent that, the devs have decided that hundreds of double square brackets will not be recognised as wikitext because one or two will be needed to be shown as such, perhaps, someday. Worse, when actual practice of Wikipedia indicated the scale of this problem, they still refused (and refuse) to change their stance, taking a dogmatic "NEVER!" approach instead. I'm sorry (not really), but design decisions should be taken to accommodate the editors, not at the whim of the devs. There is no excuse to continue to ignore the wish of the editors in this case. Reopen the discussion, see what is wanted, needed, and possible, and then again make a design decision. But as it stands now, the "final" decision and the way it is made is totally unacceptable. Fram (talk) 07:59, 19 November 2013 (UTC)
MS Word figured out how to handle auto-formatting years ago: Assume that certain text patterns should be auto-formatted, provide an easy undo option for one-time cases where you don't want the auto-formatting, and have advanced preferences to disable auto-formatting if you mostly work in those fringe areas. It's a bit disappointing that the decision seems to be mostly ideological, rather than looking at the needs/wants of the community and technical feasibility. - Evad37[talk]09:27, 19 November 2013 (UTC)
Elitre, you reference Erik Moeller above, who said "We're listening, but in this case we're saying no, and that decision is final. We can elaborate a bit more on the why if that helps, but parsing wikitext in VisualEditor is absolutely not going to happen.". Well, yes, a lot of elaboration would be welcome. Who is the "we" that is saying "no"? The devs? The Foundation? Erik solo? A cross-wiki RfC to see what the editors actually want? "That decision is final". Why? Consensus can change, people can come to new conclusions based on actual experience, needs can be greater than anticipated, ... So why is this "final"? "Elaborate a bit more on the why" is very cynical, as I have not seen any "why" so far, so elaborating more on it is hardly possible. Just start by giving us the why, and what that why is based on, and who made that decision. @Eloquence:. Fram (talk) 08:03, 18 November 2013 (UTC)
Opening Cat in VE (FF25, W7) opens the edit notice. Due to the very small box, I can not see the whole edit notice though, and it is apparently impossible to scroll down in it or to it. Furthermore, the functionality it had in wikitext editing (click "show" to display the long text) doesn't work in VE, it is automatically shown and no show-hide button is available. The two big red lines of text also partially overlap, again due to the small window of the page notice (WMF devs seems to like small windows, see also Flow...). Fram (talk) 08:41, 19 November 2013 (UTC)
By the way, this has been noted before I think, but a reminder can't hurt. Individual page notices, like the one above, are (more or less) shown, but general ones (like the BLP notice you get on every page in cat:living people) are apparently not shown. Which is of course a pity... Fram (talk) 12:39, 19 November 2013 (UTC)
Articles like Sainte-Croix-sur-Mer take very, very long to open in VE (although, probably due to caching, it goes a lot faster on a second try), and have troubles displaying their contents correctly in VE.
In the infobox, the red dots that show where the subject is located on the maps, are totally off.
It is also rather annoying that some templates take up much more "blue" (selected) space than actual space. This is most obvious with the (invisible!) "clear-left" template (beneath the "historical populations" template)
This made me also realise another problem with VE. Imagine that you find the population figures for 1932, and want to add them to the hist pop template. In wikitext, this is very easy. In VE, this is extremely laborious in comparison. Not user friendly at all. — Preceding unsigned comment added by Fram (talk • contribs) 2013-11-15T14:28:57
Odd: it took me only six or seven seconds to open that page (for the first time). Perhaps there was a general slowdown when you were editing?
The red dots are completely off the map for me. I'm not sure that it's entirely reasonable for VisualEditor to process that code, though. Have you looked at Template:Infobox settlement?
I think the size of clear-left might depend on the size of the element directly above it.
I agree that some kinds of templates are harder to work with in VisualEditor, especially the ones with unnamed parameters. It would be nice if infobox-type templates could have their contents directly edited. I'm not sure why this is set up as a template though: it's just a basic table. Also, did you notice the location of the puzzle icon for the historical population data? For me, it's all the way over on the right-hand side of the screen (the far right of the infobox, just above the map of France). Does the same thing happen to you? Whatamidoing (WMF) (talk) 19:36, 18 November 2013 (UTC)
While my "very long" was about minutes, not seconds, I still don't think that 6 seconds to open a page of 1403 bytes is really acceptable... (It opens very fast in wikitext mode). But for me, in VE, it now also opens in a few seconds, so that part seems to have been a temporary glitch. As for "I'm not sure why this is set up as a template though: it's just a basic table."; it makes calculations for you, has tooltips, and anyway, table editing in VE sucks big time, so it wouldn't solve this problem anyway! The advantage of using a template is obviously also that you get consistency across all our articles, instead of everyone having their own table, with extra columns, colours, headers, interpretations, ... And yes, the puzzle icon is at the far right, as usual with most templates (e.g. with the stub template as well). That is a known annoying aspect of VE which I usually don't bother to mention even. Fram (talk) 08:11, 19 November 2013 (UTC)
"I'm not sure that it's entirely reasonable for VisualEditor to process that code, though." The template "infobox settlement" is transcluded more than 400,000 times, i.e. this is used on ca 1 in 10 of our articles, as a major visual aspect of it. The template football kit (below), which may have the same or a very similar issue, is used on an additional 25,000 pages. Template chembox, used on nearly 10,000 additional pages, same problem. Not enough? Template taxobox, used on yet another distinct group of 234,000 pages, has the same problem as well... I think it is entirely reasonable to expect a VisualEditor to process our most often used, very prominent templates correctly on an essential visual aspect of them. If that means redesigning the templates, the some VE devs can come over and fix it as far as I am concerned. But simply accepting that these templates will not be rendered correctly in VE is (once again) throwing the arms up in defeat and admitting that VE will never deliver what it set out to do. Fram (talk) 08:27, 19 November 2013 (UTC)
If I'm double counting somehow, please correct me, but otherwise you may add to the above another 146,000 instances of Template:Location map... I think personally that it is entrely reasonable to expect a VisualEditor to correctly precess visual elements used on 1/5th of the Wikipedia articles if it wants to be taken seriously, but YMMV. Fram (talk) 12:55, 19 November 2013 (UTC)
The hack that is causing this is to make sure that other absolute positioned elements don't cause even more havoc in VE. I've added a bit more info to the ticket. The absolute positioned elements (topicon, coordinates, FA/GA icons etc) have always been rather problematic (with multiple breakages in the past) and this is another proof of how they complicate issues. It might be difficult to fix without making changes to the templates indeed. I guess that is why it has not been followed up yet. It falls into the 'glitch' category though I think. Many pages use this template, but it's not causing data corruption nor is it extremely visible to the uninitiated. By investigating this issue I did find 3 other bugs though that seem rather fundamental. So some good came out of it. —TheDJ (talk • contribs) 17:20, 19 November 2013 (UTC)
The DJ, thanks for your response, but I fear that your response at the ticket is again symptomatic of the incorrect view you and other devs seem to have. VisualEditor is not the goal, it is a means to make editing easier. Comments like "Ideally, we would just get rid of absolute positioned elements (.topicon, coordinates, FA/GA etc icons), but that's probably going to be near impossible." are so wrong that I feel it may be hard to explain to you what is the problem with it. There is absolutely nothing ideal about getting rid of these elements, they are a very useful aspect of maps and other position-defined elements. If VE can't handle these, then VE has to change or an alternative method that can be used in view mode and VE mode needs to be found. But "VE can't handle this, so we should get rid of these elements"? No, that's the opposite mindset of what we actually need. Fram (talk) 09:02, 20 November 2013 (UTC)
As for "nor is it extremely visible to the uninitiated.", have you looked at pages like FC Barcelona or ant? I think most of the "uninitiated" would notice some differences in the display between fr:Azincourt and this (cause this bug happens on all wikis, not just here...) Fram (talk) 09:02, 20 November 2013 (UTC)
Mozarteum University of Salzburg: the table (at "Grand concert hall organ") looks distinctly different in VE than it does in view mode. I'm aware that table editing is to be avoided in VE, but table display usually works a bit better than this ... (something very similar happens with a table of images near the bottom of Oldsmobile) Fram (talk) 09:38, 20 November 2013 (UTC)
Antwerp: the images at the right of the "Buildings, landmarks and museums" section suddenly become left aligned images in the middle of the section... The same or something very similar happens at e.g. Oldsmobile, Proteasome, and all 1,800 pages that use Template:Stack. Fram (talk) 10:26, 20 November 2013 (UTC)
Thank you for asking and for the update! Maybe if they change the whole dialog, this one might not be needed ;) Thanks again. I'll wait. TeamGale20:27, 20 November 2013 (UTC)
Trouble making a link with a template as an anchor
Say I want to make: [w] How would I do this simply in VE? Whenever I select the template and go to the link inspector, after I type in the destination for the link and leave the inspector, it inserts a new anchor with the same text as the destination. The work around I found was to type text on either side of the template, and then select all of that text and the template, and then turn that into the link, and then afterwards delete the unneeded text. Is that the optimal way? Firefox 25.0.1; Windows 7 Professional SP1 64-bit; Monobook skin.--Atethnekos(Discussion, Contributions)07:10, 21 November 2013 (UTC)
Arc de Triomphe: the "Arc de Triomphe through history" section, and some sections below. Note, apart from the bungled layout, how in the galleries (through template gallery, not the gallery function), the captions are displayed twice in VE. Fram (talk) 12:58, 19 November 2013 (UTC) Note that Template:Gallery is used on nearly 10,000 pages, which all have the same problems (see e.g. Dessert)
I just added two references to an article on Clarence Mulford that had no references. When I finally got them in, the VE announced that I didn't have a references list format. No, I didn't, since I was using VE and not wikiedit. There seemed to be no way to add such a thing (and why isn't it automatic in VE?), so I just went into wikiedit and added it. Kdammers (talk) 14:07, 20 November 2013 (UTC)
This can be done in VE by going to the "more" section on the toolbar, and choosing either "reference list", which will add the same as you did in wikitext, or by choosing "transclusion" in the same "more" drop down menu. Note that with the latter, you don't actually see the result in VE mode, only after you have saved, which is of course annoying. None of this is very intuitive though... Fram (talk) 14:38, 20 November 2013 (UTC)
Which is why the reference dialog is being revamped, and in the future we might even have VE add the reference list autonomously when it's needed. --Elitre (WMF) (talk) 12:42, 21 November 2013 (UTC)
Indentation
I don't know if this is a bug, a quirk, a trait, or a statement by VE; but out of curiosity, I tried to put something into real-world style, i.e., start a paragraph with an indentation. I did this because, aside from the fact that I really dislike the block style, new editors might also try this. What I got was a message that I had made no change, so my "editing" would be abandoned. Interesting. Kdammers (talk) 02:59, 21 November 2013 (UTC)
You can have numbered or bulleted lists in VE, and then change their indentation. As a VE developer noted here, "we don't support any sort of indentation outside of lists yet". There are several bug related to indentation, but 48010 looks like the one you'd be more interested in following. Thanks, --Elitre (WMF) (talk) 12:53, 21 November 2013 (UTC)
Line with template, pawn
Take a page that has only {{ipa|w}} in the source. E.g., [5]. Enter VE. Place cursor after the template. Cursor key left. This selects the template. Cursor left again. Template is deselected and cursor is placed to the left of the template, at the start of the line. Press "a". A pawn appears and is selected. Firefox 25.0.1; Windows 7 Professional SP1 64-bit; Monobook skin. --Atethnekos(Discussion, Contributions)07:18, 21 November 2013 (UTC)
Testing this (FF25, W7, Vector) in live articles with IPA, I get the same and different (but probably related) issues. First, I get the "reverse typing" bug frighteningly easy. Go to Hanki, put your cursor somewhere after the IPA template, move back with the arrows until you select the IPA and then once more, and start typing... Opposite works as well, cursor in front of IPA, right, right (so the cursor is after the IPA, and start typing backwards! Try again: cursor in front of IPA, move right (with arrow) beyong the IPA until the cursor is just in front of the first wikilink (village) (or any other wikilink in the article). Start typing, and you get a pawn. You can get other amusing effects by testing different situations (like a case where you can type one character, and the second and all following ones are again pawns), but I don't think listing these will help in pinpointing and solving this (old) problem.
It is also not restricted to IPA, it seems that any template can cause this issue. On Selan (Dungeons & Dragons), put your cursor at the start of the text (ie before "In the..."), arrow left (select infobox), arrow left (deselect infobox), start typing; pawn! If, on the other hand, you use arrow left (select infobox), arrow right (nothing, a bug in its own right), arrow right (cursor is in front of "In the..."), start typing, you again start typing backwards. On refs, I get the reverse; the backwards typing happens when I end in front of the ref number, the pawn happens when I start typing to the right of the reference (a always, after selecting and deselecting it using the arrows). Fram (talk) 09:50, 21 November 2013 (UTC)
Expanded a bit on Bugzilla. Also reported 57358 reported on fr.wp. For your bug about the snowman, Nico, sorry I didn't get to that before. I wouldn't know how to reproduce; would you? (I don't think that a particular character in that word generated it, or fr.wp would be invaded by armies of snowmen; I suspect a copy/paste problem). As said in the past, asking the editor looks like the best option if we can't provide details about how the error is generated. --Elitre (WMF) (talk) 16:04, 21 November 2013 (UTC)
Hi, Elitre, I don't know how to reproduce it: copy/paste problem seems possible but strange because the line has not been modified, except for an added br at the end (which is also useless, because br are never necessary or useful at the end of a list element). I'm not interested in tracking how problems were created (I would probably be more enthusiast if it was a beta test, and not an unfinished application delivered to every one for almost 5 months), I'm just reporting some of the incorrect edits made by/with VE when I stumble upon them. --NicoV(Talk on frwiki)16:59, 21 November 2013 (UTC)
Numbered list blank line
Take a page with:
#One # #Two In view mode this appears something like:
If I go to Plato, enter VE, right click, select all, and then press some letter or number, a pawn will appear. Also, if I review changes, there is still material left is the "your text" section. Firefox 25.0.1; Windows 7 Professional SP1 64-bit; Monobook skin. --Atethnekos(Discussion, Contributions)06:37, 21 November 2013 (UTC)
Hi there, do you manage to get that also for this page? Because with your same configuration, I don't, so this depends on the page you're editing, I think. On some of my sandboxes, after I select all the text, nothing happens if I start to type. On others, the text will go away as expected, the typed letters will appear regularly, and if I check the diff there's nothing particular to notice. When I can reproduce what you describe instead, it will get even weirder, but it takes me a few more passages. I'm going to describe details in a bug now. Thanks for reporting this. --Elitre (WMF) (talk) 13:35, 21 November 2013 (UTC)
Switching from VisualEditor to the wikitext editor
So now you can switch from VE to the text editor to change tables or image galleries. Does this mean such things will not be supported in the future? Or does it mean a general abandonment of VE for all but simple text? KonveyorBelt18:58, 22 November 2013 (UTC)
No! This just means that you can switch easily now, that's it. And in the future that's going to work both ways, so those "features" are definitely coming. Have a nice weekend everyone, --Elitre (WMF) (talk) 19:08, 22 November 2013 (UTC)
I noted some weeks ago that some navboxes disappear when you try to move them in VE. I can add now that the "authority control" template has the same problem (disappears after moving, "save button" freezes after you have reviewed that change). Tested on David B. Feinberg. Fram (talk) 10:04, 15 November 2013 (UTC)
Oh, and stub templates as well apparently! Tested on Tessie Santiago.
Gennady Golovkin contains two succession boxes. Only the one at the bottom of the page is disappearing when I drag it. Is that true for you?
Also, I'm finding that only templates at the end of the page are disappearing. Templates that have (visible) text beneath them do not seem to disappear. (Categories and persondata don't count.) You can try this out at https://en.wikipedia.org/w/index.php?title=User:Whatamidoing_(WMF)/sandbox2&oldid=582563673 if you want; I piled a bunch of templates at the end, and then added a line of plain text at the very bottom. Do any of those disappear for you (without first moving them underneath the line of stray text)? Whatamidoing (WMF) (talk) 19:17, 20 November 2013 (UTC)
I'm not even seeing the other succession box at Golovkin? The "awards and achievements" box. Which other box do you consider to be a "succession box" there? The professional boxing record? That one seems to have all kinds of problems as well (style parameter), but doesn't have the "disappearing trick" enabled. But indeed, using your test, it seems that the problem is with (some?) templates originally placed after the last bit of plain text only. Which is still quite a lot of templates of course ;-) Fram (talk) 22:38, 20 November 2013 (UTC)
Yes, the professional boxing record is also a succession box. It begins with {{S-start}}.
I imagine that in several months, or in over a year, I'm not sure, VE will be deployed again on the English Wikipedia. When I have it enabled in my preferences I see "edit source" vs. "edit beta". Can this be changed? Why can't we have "edit" and "edit visual" when it comes back out? Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 14:56, 20 November 2013 (UTC)
When the WMF thinks it is no longer a Beta version, they will probably propose to turn it back into opt-out and to change the name (labels on the display I mean). I suppose that an RfC will be had then to determine whether the editing community here agrees with that assessment and these proposals. This doesn't look to be something that will happen in the near future (next six months) though, IMO. Fram (talk) 15:13, 20 November 2013 (UTC)
Thanks. Right now (to edit this section), I clicked an "edit source" tab instead of an "edit" tab. Can that be changed back to "edit"? Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 15:47, 20 November 2013 (UTC)
@Biosthmors: It is possible to use custom javascript/css to change the labels - there are some simple instruction at User:Evad37/rename editors that should work (no guarantees, though) for renaming "Edit source" to "Edit" (as per before VisualEditor), and renaming "Edit beta" to "VE". - Evad37[talk]16:40, 20 November 2013 (UTC)
I don't think that anyone on staff is spending much time thinking about these details right now. However, in past discussions with other editors, the following arguments against your proposed changes keep reappearing: "Edit source" is parallel with "View source" (the label you see if the page is fully protected); "Edit" vs "Edit source" correctly implies that VisualEditor is the less technical option; and, since many people work at more than one WMF wiki, there is value in being consistent with what the other ~270 Wikipedias and hundreds of other non-Wikipedia WMF projects are doing (so that if you go to another project, you'll have a reasonable chance of figuring out the interface). Whatamidoing (WMF) (talk) 18:43, 20 November 2013 (UTC)
No, "Edit" vs. "Edit source" implies that VE is the default editing option, which it isn't and won't be for a long time probably. "Edit source" vs. "Edit visual" may be acceptable as being sufficiently neutral perhaps. Fram (talk) 22:43, 20 November 2013 (UTC)
I have no particular opinion on that. I'm just reporting what other people have said in the past about these ideas. ("Edit visual" would doubtless also draw complaints for being ungrammatical; you probably meant "Edit visually".) Whatamidoing (WMF) (talk) 00:06, 23 November 2013 (UTC)
VisualEditor newsletter for November 2013
VisualEditor newsletter for November 2013: " An incompatibility between VisualEditor and the deployed Parsoid service that prevented editing categories and language links was fixed." Really? So the message on the "language" dropdown menu, "This is a list of pages in other languages that are linked to this one; for now, it can only be edited in source mode.", or the fact that indeed these languages can't be changed in VE, is a myth? Glad that is solved then... Fram (talk) 10:14, 26 November 2013 (UTC)
Logs of Users Sarkar,अभय नातू,गौरी,Absh.thamke,14.96.188.18 are not relevant for VE purposes.The rest would be relevant.This info may help you save your time .
Hi. The change review window is too small. It helps me spot accidental edits which might not be visible in the WYSIWYG view but I have to struggle a lot with it. Best regards, Codename Lisa (talk) 16:14, 23 November 2013 (UTC)
Hello, Elitre. No, that's not it, although my review Window is just as small (by design). You see, oo-ui-window-frame-small is set to retain a maximum width and height of 600×400, which is a small subset of .oo-ui-dialog .oo-ui-window-frame which enforces a maximum dimension of 800×600. Both are too small in comparison to the source mode's review screen that sports a vertically expansible 1358×475 and gets larger with my monitor.
I can, of course, use Firebug to disable width, max-width and max-height properties in both selectors and get a comfy 1581x716 scrolling window which is very lovely. Try it! You'll love it!
To quote from VisualEditor Newsletter, November 2013: "Switch from VisualEditor to the wikitext editor: [...] Note that this new feature is not currently working in Firefox." True. This feature does not work in Firefox. A white screen appears and remains.
Hey Lisa. That would be awesome, if VE could automagically diagnose its own problems :) I'll ask around, but I don't think this can happen. Will let you know. Thanks, --Elitre (WMF) (talk) 16:36, 25 November 2013 (UTC)
Right now, those bugs are exceptions - I mean, it's not that the feature was designed not to work with FF: we just found out something goes wrong with it. Anyway, I filed your request as an enhancement at 57621. Thanks, --Elitre (WMF) (talk) 21:04, 26 November 2013 (UTC)
Also, Codename Lisa, could you please test again? The problem with that feature was solved, so if it still does not work for you (it works for me with FF on both en. and it.wp, for example), I'll need to know your skin and OS. Thanks, --Elitre (WMF) (talk) 14:55, 28 November 2013 (UTC)
If I go to Sentinelese language, enter VE, I see four "↵" characters at the bottom of the page. If I select them, and then press delete, they disappear. However, when I go to save and review changes I get the message "Could not start the review because your revision matches the latest version of this page." Firefox 25.0.1; Windows 7 Professional SP1 64-bit; Monobook skin. --Atethnekos(Discussion, Contributions)01:08, 26 November 2013 (UTC)
The easiest in VE I found to change an image that's not a thumb into an image that is a thumb (e.g., [[File:Philbar.png]] into [[File:Philbar.png|thumb]] was to resize the image, then go to save and review changes, then I can see the file name for the image, then I go through the regular method of inserting an image now that I have the file name, and it inserts it as a thumb, and then I delete the old, non-thumb image. Is this the easiest way? Firefox 25.0.1; Windows 7 Professional SP1 64-bit; Monobook skin.--Atethnekos(Discussion, Contributions)01:33, 26 November 2013 (UTC)
The easiest method I found for doing the reverse (change a thumb file into a non-thumb file) I think is similar, but it takes two VE sessions. So again, open VE, resize the image, and then review changes, this gives the filename. Then type "<br></nowiki>[[Filename.png]]". Then save, then open in VE again and delete the "<br>" and the "</nowiki>" which are on either side of the image, and delete the thumb image as well. --Atethnekos(Discussion, Contributions)08:43, 26 November 2013 (UTC)
To be clear, you type that string "<br></nowiki>[[Filename.png]]" into VE where you want the non-thumb image. You get a "Wikitext markup detected" warning, but it works after saving. --Atethnekos(Discussion, Contributions)08:46, 26 November 2013 (UTC)
Neat. Not very "intuitive" or "visual", but neat nevertheless! Of course, in these cases doing it in wikitext editing probably makes more sense :-D Fram (talk) 09:08, 26 November 2013 (UTC)
Images and other media files are being worked on. They're looking to add better controls for size, location, type, alt text, alignment, links, and borders within the next few months. Whatamidoing (WMF) (talk) 23:04, 28 November 2013 (UTC)
nts transclusion tag not appliable
I'm trying to use the visual editor to mark at numeric field with an tag so that the column sort works properly. I can see the nts transclusion pop up for existing entries but I don't see how to add the same tag to a new entry in the table. There is an option to add a new template but I want to pick an existing template. Is this feature missing or am I missing something? Robertbaertsch (talk) 13:22, 27 November 2013 (UTC)
Hi Robert,
Which article are you looking at? VisualEditor's support for tables is pretty limited at the moment, but it would help me to see exactly what you were trying to do. Whatamidoing (WMF) (talk) 23:14, 28 November 2013 (UTC)
That template has a lot of whitespace and indentation. I'm surprised that it works in the plain renderer, because we have had lots of trouble with such constructs in infoboxes in the past. Anyway, it seems that some of that whitespace indentation led the parsoid parser to introduce a pre element into one of the tables, breaking the structure. By removing some whitespace (using a comment in the template instead), i was able to correct the problem. But I haven't fully grasped the exact problem yet. —TheDJ (talk • contribs) 10:11, 29 November 2013 (UTC)
Both the notice on first opening VE ("You can keep using the wikitext editor by clicking the "Edit source" tab instead – unsaved changes will be lost.") and the wikitext warning ("Click "Edit source" to edit the page in wikitext mode – unsaved changes will be lost.") need to be changed to reference the newly added ability to switch to the source editor without losing unsaved changes:Jay8g [V•T•E] 05:09, 8 November 2013 (UTC)
Works fine for me (Vector, Chrome 30, Win7) on all sorts of pages. Some take a little time to load, but all show up with the diff in the preview area, and the changes carried through to the source editor below. My thanks to whoever implemented this feature, that one less bit of custom coding/hacking to load from my common.js - Evad37 (talk) 10:11, 8 November 2013 (UTC)
(ec)No, still doesn't work. I get the "you are about to change" message, but then the VE page gets "bleached" out, as if an opaque glass is put in front of it, and nothing further happens. I can still use the toolbox at this time, and can edit the article in VE, but it doesn't have the normal look. Probably some preference interfering with it? Fram (talk) 11:15, 8 November 2013 (UTC)
Hey John. There's no need to raise a bug for that. There are a few bugs about that feature (the first is already patch-to-review while the second, 56835, likely depends on another patch-to review one) that prevent a lot of users from even just testing it. When they are addressed, I (and other liaisons) will be glad to make sure that all the related messages and pages in, well, all languages reflect that this major feature is up and running. --Elitre (WMF) (talk) 13:35, 15 November 2013 (UTC)
I've filed a bug report anyway. If they don't need it, then they can close it. I think that Fram's point about not necessarily doing this until it works on Firefox is worth considering, but it's on the list of things to be done at some point. Whatamidoing (WMF) (talk) 02:05, 28 November 2013 (UTC)
I hadn't, because of 57422. AFAIK, the feature works with FF, but the patch for the IP bug will be effective as of Dec 5th. When it is, sysops can update the messages on en.wp if they want to. --Elitre (WMF) (talk) 16:28, 29 November 2013 (UTC)
Stuck in a pop-up
I went to make a simple edit (addition of one word before a blue link) in Osteon, using VE (Firefox/ME7). I wanted to check if the blue-link article (I believe it is 'cortical bone') also needed the edit. After I moused over the blue-link and got a pop-up, I could not do any-thing after that. I couldn't close the pop-up; I couldn't type in the article text; I couldn't save; I couldn't exit. The only way out was to close with-out saving. Kdammers (talk) 06:54, 19 November 2013 (UTC)
Is ME7 a mobile/smartphone system? Although it is possible to open VisualEditor on some tablets and smartphones, it is not supported yet. I wouldn't be surprised if very little of it worked, and I wouldn't recommend it. Whatamidoing (WMF) (talk) 20:55, 19 November 2013 (UTC)
The same thing happened this morning when I tried to edit a different page and mistakenly typed in left double brackets. I got an error message for using wikitext, but I couldn't go backqrads or any-thing. I erased the double brackets but I still couldn't save etc. I had to close VE and start again.Kdammers (talk) 09:41, 23 November 2013 (UTC)
I apologize for the delay. Do you mean that you're using Internet Explorer? Windows Explorer doesn't sound like it is relevant. I was under the impression that VE was disabled for IE (precisely because it tends to hang). If you're using IE (what version?) and able to see VisualEditor at all, please let me know. Whatamidoing (WMF) (talk) 02:13, 28 November 2013 (UTC)
VE does not load for me in my IE10. If I reach the VE description in the Beta tab, it will explain:
The following browsers are not supported:msie <= 10
When using the Category dialog I added "Category:Computer humor", which was accepted and caused the page to translate into "Category:Category:Computer humor. Preferably the template would automatically detect the use of a "Category:" tag and remove it. Nicereddy (talk) 23:47, 30 November 2013 (UTC)
If this is meant to be used by the layman, "Transclusion" isn't a good term for the option of adding a template. Is there an explanation for the word chosen? Nicereddy (talk) 00:47, 25 November 2013 (UTC)
We've already asked for that, and the response was that more than just templates are happening there (or will be), and that "transclusion" is technically correct. I'm adding the bug number, so you can see the response if you want. (It sounds like we might be slowly wearing him down. ;-) Whatamidoing (WMF) (talk) 02:21, 28 November 2013 (UTC)
Fair enough. I'm all for technological accuracy, but it is a bit bothersome that such an uncommon word is being used where a more simplistic term may be helpful in reaching the point of the project, that being Wiki editing by the layman. Hopefully discussion on this issue will continue. Nicereddy (talk) 06:28, 1 December 2013 (UTC)
Override default right click behavior while in text editor
When highlighting text in the Visual Editor, if you right click editing of the page could be sped up further by opening the toolbar when right clicking on that text. For example, if I were to highlight text and then right click on said highlighted text a (modified?) version of the toolbar would appear above/next to the text highlighted. This would allow for faster editing without requiring the user moves their mouse across the screen. While I realize this is possible with keyboard commands, it may be preferable for many users.
Similarly, using the right click on any section of the page, regardless of whether or not any text is highlighted, the toolbar would show up as a dialog which would allow for easier use of its various functions. Nicereddy (talk) 00:51, 25 November 2013 (UTC)
What do other people think? I'm such a keyboard-shortcut person that this wouldn't make much difference for me, but would anyone else benefit from this? Whatamidoing (WMF) (talk) 22:31, 28 November 2013 (UTC)
This page doesn't seem to get much traffic, so I figured I'd reply again. Most modern text editors, e.g. Google Docs, Microsoft Office, iWork, etc. have this feature in some capacity and I find it beneficial for a huge number of reasons. It's a common pattern which many users may expect upon introduction to the VisualEditor, as the VisualEditor is essentially a specialized version of the common text editor. Despite being what most would consider a "power user" I very rarely use keyboard-shortcuts for the majority of programs/websites as they vary so widely across different programs. However, I do use this quite often and I feel like the casual editor may benefit from this as well since keyboard shortcuts aren't something the general public uses, but right-click seems to be a simple-enough feature for most to comprehend.
It isn't something that I would consider a priority, but it would be a very nice feature. I'd prefer if it were added in a similar manner to Google Docs', where it transfers the functions of the toolbar into the right-click dialog one would expect. Nicereddy (talk) 06:36, 1 December 2013 (UTC)
Help:WikiHiero syntax
We can now also edit Help pages with VE. This seems to work for some pages, if anyone would need it (you know, those people that need to edit help pages but don't know wikitext sufficiently to be editing them directly, a very elusive group indeed); but don't try it with Help:WikiHiero syntax, it has caused FF25 (on W7) to crash twice in two tests. Can someone confirm this, and does it happen with other (help) pages as well? Fram (talk) 14:34, 26 November 2013 (UTC)
It must be one a Windows-specific problem. It takes me about 30 seconds to get the page open in Firefox, but it opens without any errors. Is your computer short on memory or anything like that? Can you open any page that contains a hieroglyphic, like https://en.wikipedia.org/wiki/Egyptian_triliteral_signs?veaction=edit?
Just tested it on the page you linked (Egyptian triliteral signs), and no problem there. The Help:WikiHiero syntax page is so far the only one where I have that problem. I'ld indeed like some other people testing this as well, obviously if I'm the only one, and it's only one page I don't need to edit anyway, then this can be ignored, but if there are others with the same problem, then it should be filed as a bug... Fram (talk) 09:59, 2 December 2013 (UTC)
Yeah, I'm going to file this and other. NicoV, no need to report bugs here as well, several editors at fr.wp are really helpful with tests there, so keeping everything in just one place helps :) Thanks! --Elitre (WMF) (talk) 16:20, 29 November 2013 (UTC)
Ralph Day; reference 1 and 3 are not editable in VE. You can open the edit ref box and change them, but you can't see what is actually there at the moment. The same applies in a different way to Gordon Guasco, which has a bare URL, but not as a ref but as an external link. Not editable... Cecilia Östlund has one not as a ref or external link, but in the text. We have currently over 2,000 pages tagged with Template:Cleanup-bare URLs, and many more that don't have the template but that have bare URLs nevertheless (e.g. my examples). Fram (talk) 09:26, 29 November 2013 (UTC)
Welcome to the English Wikipedia, Xusinboy Bekchanov. I see you've been doing a little testing on the Uzbek Wikipedia; thanks!
This seems like a good idea to me. Have you used the one in the regular wiki editing window? I don't use it myself, but is that the sort of thing you'd like? Whatamidoing (WMF) (talk) 22:08, 1 December 2013 (UTC)
I use this function occasionally and I think the current source editor "Find and Replace" function would work perfectly fine, albeit it'd be preferable if it got a design makeover. --Nicereddy (talk) 02:18, 3 December 2013 (UTC)
Unfortunately, I don't believe Global Notifications are possible at the moment. I'd at least like some sort of notification hub if users are worried about getting too many notifications at once. The hub would contain all notifications, the notification badge in the toolbar would only contain notifications for the wiki project you're currently at? --Nicereddy (talk) 06:06, 3 December 2013 (UTC)
The {{tl}} template doesn't display anything when editing a page in VE. Not really a problem for articles, but is definitely a problem for help pages. For example, look at the "Aliases" section of Help:Template in VE. I'm using Vector/Chrome/Win7. - Evad37[talk]06:22, 3 December 2013 (UTC)
Just installed IE11 and decided to check out Visual Editor (according to Wikipedia:VisualEditor, "Internet Explorer 11 users are currently able to use VE", though the message when you actually try to use it "You are using a browser which is not officially supported by VisualEditor" gives a slightly different impression).
Most pages do not load at all, at least within my patience span. The "progress bar" keeps churning around but nothing happens. I managed to get the edit screen up for a three-line article, but when I typed a character and then hit backspace the whole paragraph disappeared and was irretrievable with "Undo". The same happened with "Delete": the whole paragraph is irretrievably deleted. Then I put the cursor on the end of a line and hit "Enter" to create a new paragraph but nothing happened.
Then I highlighted some text and clicked the "bold" button and again the paragraph disappeared. Same with "italic". Sometimes, instead of the paragraph disappearing, nothing happened.
So, basically, the first most trivially simple editing tasks that I tried all failed spectacularly. I assume that either the message "Internet Explorer 11 users are currently able to use VE" has been put up in error, or there is some local configuration issue or other local problem with my setup. 86.129.17.245 (talk) 23:51, 2 December 2013 (UTC)
Yeah, sorry, my mistake – I forgot to ensure that the blacklist covered IE11 when it came out. IE11 indeed does not work, and is not expected to right now. Have added it to the blacklist which will come out next week in the new version of the code. Jdforrester (WMF) (talk) 03:31, 3 December 2013 (UTC) Update: IE11 blacklist for VE is now deployed on all wikis. Jdforrester (WMF) (talk) 00:31, 4 December 2013 (UTC)
@Jdforrester (WMF): any word on the timeframe for that James ? Or do the features have priority now over investing into the headache that is IE ? Or are there more fundamental problems with IE support ? —TheDJ (talk • contribs) 08:53, 3 December 2013 (UTC)
If there genuinely are big technical problems with getting it to work with IE because IE itself is so buggy then continuing lack of support may be justified. However, some people have an irrational bias against IE, and hence build up its problems while forgiving or working around equally irksome problems in other products. I hope that such bias plays no part in the decision here. 81.159.107.134 (talk) 20:30, 3 December 2013 (UTC)
The major problems with IE are IE's non-standard "security" model (which means we're going to need to fake up a local-to-each-wiki "server" request point to proxy requests back to the actual server – see this note on MSDN), the different ways IE has cursor interactions in contentEditable surfaces (to be entirely fair, there's no actual standard for this, it's just that IE doesn't do what most of the other browsers do), IE's different IME event sequences which mean typing would produce different results (fun; again, no standard - thanks, W3C), and a more comprehensive audit of what does and doesn't work before we'd switch it on. This is against a backdrop of rapidly-falling IE usage – IE9+ is about 11% of Wikimedia traffic for readers, and we believe lower for editors; IE6-8 (which we can't support for various technological reasons) is about 5.3% – which means that we've focussed on things that are needed by more of our users for now. It's still very much something we want to get done, and sooner rather than later. Jdforrester (WMF) (talk) 00:39, 4 December 2013 (UTC)
VE sometimes changes things unrelated to your actual edit. Perhaps there is a good reason for this, I don't know, but it is rather surprising and not always beneficial.
I noticed the addition of "nowikis" here? The initial problem is not VE related, in an earlier edit someone removed the first curly bracket from the Persondata template. But when testing this, I noticed that VEacts strange here: if you start at the same version as the linked edit above (i.e. here), then without making any changes, you see that "review changes" displays again the | instead of the nowikis. Now, if you change anything in the article (e.g. adding a comma after "2010"), and you again use "review changes", you'll note that the | in the persondata template are no longer shown. This means that whatever you change in the article, the "|" gets removed (not just included in nowikis, but completely removed). This seems to be unwanted behaviour. Fram (talk) 11:11, 4 December 2013 (UTC)
Parsoid currently doesn't always handle broken table wikitext correctly. Because of the missing '{', that code does not parse as a table and the "|" chars get lost since they are no longer in a table. We do have a bug (T54618) to improve our handling of stray "|" cells outside tables, but this is lower priority than other higher priority bugs since these instances are not that common and it is better to fix up the broken table wikitext. Ssastry (talk) 19:23, 4 December 2013 (UTC)
I don't get why the "|" are removed though, and not simply (preferably) left alone or (at worst) put between "nowiki" tags. I agree that this doesn't have high priority, since it isn't that common, but still... Fram (talk) 09:34, 5 December 2013 (UTC)
This is just a side effect of how Parsoid converts wikitext to HTML. Early in the process, Parsoid converts "|" to <td> tags. But the HTML builder library we use to build a HTML5-spec conformant HTML5 document throws them out because <td> tags are invalid outside a table. So, when we get the DOM to process further and emit a serialized HTML string, we've already lost the <td> tags (originally "|" chars). Of course, we have various tricks in our bag to detect situations like this which we've already deployed to detect the various cases of broken/unbalanced/stray wikitext and handle them, but we need to expand those tricks to this use-case as well. Hence this is more a matter of prioritizing our time usefully (plus also about not cluttering our codebase with unnecessary complexity for questionable benefit). The bug report linked above has some explanations of how we might tackle this. Hope this helps. Ssastry (talk) 16:45, 5 December 2013 (UTC)
Phantom notice
I wanted to add the names of some articles I recently created to a list I keep, and hovering over the /!\ symbol near the top shows "1 notice." What notice is it talking about? 28bytes (talk) 01:46, 6 December 2013 (UTC)
I've been getting empty notices on every page, with just the redlinks to create a page or group edit notice. I believe this is only shown to template editors and admins, so that they create edit notices. - Evad37[talk]03:30, 6 December 2013 (UTC)
VE now works for portal space (which was hardly a priority, but anyway...). Looking at e.g. Portal:Current events, you start with an edit notice that isn't valid in VE (you can't paste the code given there in VE and expect it to work). Apart from that, there is very little I can do here, as the page exists of other subpages. So I look at the subpages, e.g. Portal:Current events/News Browser. Hmm, not a lot I can do here... Oh, I can move the documentation above the globe bar, instead of below it. This is fun! Luckily I use preview and know some wikicode before I save this, because moving the documentation moves it from inside "noinclude" to outside "noinclude" tags, creating a totally different result. Useful!
Another subpage is Portal:Current events/2013 November 26. In wikitext editing, you start with a full screen of notes and warnings; none of these is visible in VE though. Then again, you can't do anything here either with VE, even though the contents are here, not on another subpage! So, while this technically seems to work, the actual usefulness of this (and need for it) seem to be absolutely minimal.
But it also works for Books! Why? No one knows... Looking at e.g. Book:American comic strips before 1918, in VE it starts with messing up the header, as it is unable to show the links in it correctly... Considering that this header is used in every single book, this again is a rather clear test fail, as usual. Apart from that, the basic features seem to work. Well, until you try them, that is. In VE editing mode, the new line I added as a test was properly indented with the other items, but on saving, it was left aligned, with no possibility to get it aligned with the rest of the items[6]. Seeing that this is the standard layout used by many books (e.g. Book:Adele or Book:Mathematics), this means that no, we can't use VE to create or properly maintain Books. So the point of the announcement in Wikipedia:VisualEditor/Updates/November 20, 2013 totally escapes me, unless the meaning is "we are wasting time on useless aspects of VE, instead of fixing the many truly necessary but buggy ones". Luckily, by not testing these changes properly, you are not wasting too much of your time. Small blessings. Fram (talk) 12:57, 26 November 2013 (UTC)
Justr tried in here, and changing a link turned what is now one link into two separate links (with the same target), because VE has trouble handling a partially italicized text in a link apparently. Technically speaking, some things work; practically speaking, it is hard to understand why anyone at WMF thought this was a priority or something to proudly announce, since you can't add items properly, you can't reorder things, the header is a mess... but indeed, you can in some circumstances edit the existing links. What are the odds that people who don't know enough about wikitext (and so need VE) will end up at a book, and not make a mess of it when editing it? Disable it for books and save us a lot of trouble and little benefit. Fram (talk) 08:11, 29 November 2013 (UTC)
Perhaps I'll first let you know when there is some actual intentional VE edit to a book (or most of the other added namespaces), as these are almost completely absent anyway (hence my question of who thought that this was a priority...). But how did you do that? If I add a ":" or a ";", I get nowikis around it. And the "increase / decrease indentation" tab isn't active. Fram (talk) 07:53, 3 December 2013 (UTC)
I copied and pasted a few lines from an existing section, and then I edited them to say what I wanted.
When I edit Keith Murray (rapper) in VE, open the infobox, and look at the parameters on the right side, I notice strange boxes to the right of the parameter names, sometimes light gray, sometimes dark gray, without any possibility to select them, without any explanation, and without any apparent logic. Sometime sthe dark gray box is the same as the parameter name (Landscape), sometimes it is something different (Image caption), and sometimes it is missing completely (native name). Sometimes there are two of them (Website).
When I start typing parameter names, I get strange results (e.g. typing "Website" gives a different result from selecting Website, even though they look the same in the parameters list) I presume the boxes indicate acceptable parameter names, but this is not clear at all, and I am still struggling to see any difference between what's in the white and gray boxes. Fram (talk) 10:33, 4 December 2013 (UTC)
When adding a category to a page using the VisualEditor it doesn't show the new category at the bottom of the article after pressing "Save page". The category is added, but you have to refresh the page to see the change. Nicereddy (talk) 01:13, 7 December 2013 (UTC)
I got it to work but it required quite a bit of trial and error. In order to add one number you need to add a transclusion tag, enter nts, add a parameter with the name "1", then enter the number into the text box. Could this be made easier. What does "nts" stand for? — Preceding unsigned comment added by Robertbaertsch (talk • contribs) 22:53, 7 December 2013
Hi Robertbaertsch,
nts stands for {{Number table sorting}}. It looks like no one has created the WP:VisualEditor/TemplateData for it, which means that—well, I'm impressed that you figured it out, because if I'd encountered it in my early days, I probably wouldn't have. So congratulations, and I'll ask someone to add TemplateData, which will (I hope) make it slightly less confusing next time. Whatamidoing (WMF) (talk) 02:43, 8 December 2013 (UTC)
Can't save a new page!!!
I tried to create a new article TWICE but I wasn't able to save it!! The first time I clicked "Preview your changes" to take a look of it (I always do that) but the page kept loading and loading with no result! When I took the decision that nothing was going to happen, I said to give it one more try and start all over again. The second time around I skipped the "preview your changes" and I went straight to the "save"! Again the same thing happened! I left it like that for 20min hoping that it will be saved but nothing! It kept loading and loading! I faced the same issue with the previous article I created but the second time that one was saved and I thought that I just spent to much time to finish it because I left it open for a while and then came back to finish! But this time it was not the case! I am not willing to spend another 1-2hours to try for a third time! If this is a bug please fix it! I lost my work twice and till this gets solved I am not willing to take any risks again to create a page with VE and that makes me really sad because even though I can use the source to create a page with VE is so much easier! I am using Firefox 25, Windows 8. TeamGale09:05, 16 November 2013 (UTC)
Believe me I did that...but it still needs a little editing when you copy/paste it back to WP! Because the references can't be copy/pasted. Neither the infoboxes etc! Only simple text can be copied! And re-find and add about 10 references takes time. Having said that, I don't believe C&P is the solution... TeamGale09:45, 16 November 2013 (UTC)
TeamGale, VE isn't intended to really create new pages, use images, use references, use templates, use wikitext, use ... well, anything apparently. You can use it to make some cosmetic or minor changes, but for anything slightly more complicated, you just have to be very lucky to be able to proceed correctly with it. This is intended to welcome new editors, increase editor retention, and keep Bugzilla filled until eternity. The only people really happy with Ve seem to be the people that developed it, I guess that their technical end-of-year target has been met, doesn't matter if anyone uses it or is satisfied with it. It now has been live on enwiki for nearly half a year and we are still at the most basic errors stage, which isn't surprising since the software isn't being tested in any significant way before being deployed. Happy editing! Fram (talk) 08:20, 18 November 2013 (UTC)
This is the kind of page you get with the new, intuitive, WYSIWYG editor. The big red error is corrected by the same editor using the wikitext editor[7], indicating how fast people move on from the new, better, editor to the old, much too complicated one. Don't you love irony and meta-irony? Fram (talk) 08:26, 18 November 2013 (UTC)
Fram With all do the respect, I am sorry but, I created around 70 articles and since the day I found VE I was only using VE. I created 40 articles out of 70 (more than 50%) with VE without having any problems of saving the page and without getting any errors! (This was my first with VE in case you want to take a look and this the last one I was able to save just 3 days ago!) If you are careful, avoid existing known bugs and don't forget anything, you won't get errors. The pages I am interested in creating, believe me VE can create them perfectly fine. I don't think I am delusional asking for this to get fixed.
To come and tell me after 40 articles that VE is not suppose to create new articles seems kind of funny to me. I might be a minority but, I am one of the few users (and also new user) who are happy with VE and I am using it a lot! I am switching between the two editors very easily and when there is something I know I can't do with VE, I use wikitext. I am not in the category of "how fast people move on from the new, better, editor to the old, much too complicated one", I don't give up easily and yes, I spent time to learn VE like I spent time to learn wikitext. And there were moments I got frustrated but like I said, I don't give up easily and after a while I could work with VE without having any major problems till now.
Anyway, what I am saying is that I was able to save a new page with VE before and now I can't. I don't know if this is a bug or not, but since it was something I could do in the past months and now I can't, I had to report it. Till this gets fixed, I will use wikitext to create any new pages the way I was doing it before VE, not because I prefer it but because right now I am forced to do it. Thanks again and thanks to all the WMF for their hard work these last months! Personally, I appreciate it a lot! TeamGale10:40, 18 November 2013 (UTC)
Good for you. Looking at your VE edits, I'm rather curious about what happened e.g. here Do you remember whether you mistyped somehow or whether VE mangled these? Fram (talk) 11:20, 18 November 2013 (UTC)
That was a bug that was existing at the moment. When someone was trying to add categories with VE it was adding them like that. I missed it on my "review" before saving the edit. I only saw it after the save. I came here to report it but someone else had reported it already. It got fixed now :) TeamGale16:06, 18 November 2013 (UTC)
I'm sorry you're running into problems. Did you create the page you wanted in wikitext? I just created a simple page in my sandbox, so it's certainly possible right now. Whatamidoing (WMF) (talk) 19:41, 18 November 2013 (UTC)
Whatamidoing (WMF) Yes, I created the page with wikitext. I don't know if it has to do with how long is the page. I'll give it a try again with my next page using VE and I'll let you know. TeamGale23:01, 18 November 2013 (UTC)
Hi TeamGale, if you run into this again, please post the name of the page that you ended up creating in wikitext. It's possible (but not very likely, I'd guess) that there is something specific about the page you were trying to create. Mine was quite small and simple (two sentences and a {{db-author}} tag), so perhaps bigger or more complex pages aren't working, even though little ones are. Whatamidoing (WMF) (talk) 23:10, 18 November 2013 (UTC)
Elitre (WMF) Hmm...yeah, I am not sure if the two are related because I didn't get any "error" message. Only the load bar loading for about 20min without result.
Whatamidoing (WMF) If that helps to find the issue earlier because I don't when I'll create a new page, that was the page I was trying to save: link. I saved the first half with wikitext and then added the second half with VE without having any problems. TeamGale23:21, 18 November 2013 (UTC)
This turned out to be an issue with one of the Varnish caches in production. It ran out of backend connections, which caused some requests to fail. Since this was so rare it was fairly difficult to track down. Sorry for the inconvenience. -- Gabriel Wicke (talk) 01:07, 19 November 2013 (UTC)
I see. Thanks for clarifying and explaining. That means everything will be OK now? If it happens again I'll let you know. Thanks again :) TeamGale23:58, 19 November 2013 (UTC)
Did you get the same error message as before / did it mention Parsoid? This time the Varnish logs are looking clean, so this might be another issue. -- Gabriel Wicke (talk) 19:11, 25 November 2013 (UTC)
Hello. I am not really familiar with technical terms so I don't know :( What I am getting is a never ending loading bar when I click save. I don't get any error message...nothing...just the bar loading and loading but never saves. It also happens if I click on "review your changes". I tried that too to see if I'll get the same and I do. The bar also loads forever without showing my changes. In case you need it, I use Mozilla 25.0.1, Windows 8 TeamGale00:45, 26 November 2013 (UTC)
Elitre (WMF) I didn't attempt again since the last time I posted here till I would have any updates of what is might be going on. Losing a work of 4-5hours is not funny :( TeamGale04:49, 3 December 2013 (UTC)
Search for '503' in Wikipedia:VPT for current discussion of the general issue. The situation is being monitored, but is not completely fixed yet. The issue is not specific to VE. -- Gabriel Wicke (talk) 17:40, 3 December 2013 (UTC)
Hi TeamGale and Elitre (WMF), this was caused by general production issues unrelated to Parsoid or VE. Apparently, editors had problems saving wikitext as well. This was November 25th around the same time TeamGale ran into issues (See this thread on VPT if you are curious about those reports). Ops are monitoring the servers and doing what they can, but this is not Parsoid-specific. Hope that helps. Ssastry (talk) 17:43, 3 December 2013 (UTC)
Gabriel Wicke Ssastry I read the threads you linked and that was the same answer I got the first time I reported it. The only thing is that in my case...I do NOT get any error mistake OR my edit saved! And it never happened to me on wiki text, only on VE. Sorry if I am getting repetitive but, what I get is a loading bar...loading forever (I left it up to 20min) and nothing happens!! NO error...NO save!!! If it would save it it would be great but it doesn't! And the whole work is lost! Is that the same thing as the problem you mentioned? It seems different to me... TeamGale23:57, 3 December 2013 (UTC)
P.S. It happens when I try to create/save a NEW page! Not when I edit an already existent one...never met it while editing existent pages. TeamGale00:08, 4 December 2013 (UTC)
The missing error message actually sounds as if it could be a client-side (VE) issue, possibly browser-specific. Could you check the browser's JS error console for any clues? I have also alerted the VE folks. Thanks! -- Gabriel Wicke (talk) 03:31, 4 December 2013 (UTC)
Thanks for the clarification. My browser is still Mozilla Firefox 25.0.1 Any idea where and how I check the browser's JS error console? I tried to find it but no luck :/ And what exactly do I need to search for there? TeamGale08:41, 5 December 2013 (UTC)
A small update...for the first time this happened to me while editing a page and not while I was trying to create a new one. I am sorry if I am being annoying but, if someone can direct me of how I can check the browser's JS error console so I can see if that's the same problem as the one you've mentioned I would really appreciate it. This is something that I am sure all of us wants to get fixed and soon. Thanks TeamGale06:45, 7 December 2013 (UTC)
So, TeamGale, here is what you need to know. Don't be afraid, the procedure looks fairly easy. You need to be on the page which doesn't allow you to save, after/while the error is happening. You can then launch the console as explained here. Look at the picture on that page; it will show you how everything is being recorded by default. We don't need this, so in you console just toggle off everything in that toolbar by clicking the corresponding button, *except* for the JS (Javascript) one. This should leave you with only messages and/or errors generated by the Javascript part. Select what you see (click on the first message, then hold Shift and reach the last one: you are now ready to copy. Otherwise you can right click to Select all and right click again to Copy). Just paste everything here. Thanks. --Elitre (WMF) (talk) 11:46, 7 December 2013 (UTC)
It looks like the first step is pressing Control-Shift-K (Windows) or Command-Option-K (Mac). From there, you can use copy and paste to get a plain text copy of anything that appears or looks relevant. Whatamidoing (WMF) (talk) 02:08, 8 December 2013 (UTC)
Thank you so much for the instructions. So, to be able to do that I'll have to encounter with the problem. I'll have it in mind if it happens again to do it and copy here the info. Thanks again! TeamGale05:22, 9 December 2013 (UTC)
Watch this page defaults as checked, even though my Preferences is set to do the opposite
In any normal work environment, you and the rest of the WMF devs working on VE would have been canned a long time ago... Ya know I'm right (talk) 06:44, 10 December 2013 (UTC)
I reported this bug a while ago that its status says "RESOLVED DUPLICATE of bug". The duplicated bug says "resolved fixed" but that's not true. I still encounter with the specific problem about the usage of existing references. TeamGale06:42, 7 December 2013 (UTC)
TeamGale, that should have been fixed on the 5th, meaning this error shouldn't be happening anymore on Mediawiki.org, and next week the "patch" should be live on en.wp as well. I'll check this and other issues reported on this page ASAP. As for how to retrieve the data the Parsoid team asked, I'll try to find instructions (I'll have to Google this as well, I don't remember how this is done). Thanks for your patience! --Elitre (WMF) (talk) 10:54, 7 December 2013 (UTC)
Oh, I see. I was just wondering if there was a mistake on the bug report since I needed to use an existing reference and I found the problem again. Thanks for the clarification. TeamGale05:25, 9 December 2013 (UTC)
As far as I can tell, this still happens on MediaWiki as well, i.e. when I ask "use an existing reference", it only gives numbers between square brackets, but nothing more. So, Teamgale, I wouldn't hold my breath that this is actually resolved-fixed (the number of regressions, reopened bugs, and so on, is getting impressive, and it seems that for every solved one, three new ones pop up.) Fram (talk) 10:12, 10 December 2013 (UTC)
Looking further into this, the problem was that @Jdforrester (WMF): incorrectly merged this bug with another one, and the other one was fixed (or reported as such, I haven't tested that one, we should leave something for the QA team). The two bugs were unrelated, and I have reopened it accordingly. Very annoying. Is there anything being reported here or at Bugzilla that we can actually trust to be true? It doesn't seem like it, and it only seems to be getting worse. Fram (talk) 10:22, 10 December 2013 (UTC)
Thanks Fram When I read the answer I didn't have time to check the two bugs and I just answered here. Later I forgot to come back and check them. Thanks again for noticing it and for reopening the bug. TeamGale02:11, 11 December 2013 (UTC)
Chess pawns after references
Sometimes, if I add a space after a reference, a chess pawn will show up. It usually happens if there is a line of text after a reference that I am working with.--¿3family6contribs16:08, 11 December 2013 (UTC)
This (and the related reverse typing bug) should be solved after the next update of VE here (planned for tomorrow, despite the other problems this update creates or contains). I haven't checked thoroughly whether it will really be solved or not though, I have noticed that the new version inserts clouds and snowflakes sometimes, so at least we won't have a shortage of funny unwanted characters yet. Fram (talk) 19:39, 11 December 2013 (UTC)
Thanks for your note, Blahma. This is a known problem caused by VisualEditor not being able to understand the ref in the infobox. (The numbering will be off by more than one, if the infobox has more than one ref in it.) Ed Sanders is working on it, and the devs consider it a high-priority bug, but apparently it's not an easy one to fix. Whatamidoing (WMF) (talk) 23:07, 11 December 2013 (UTC)
AT the article on Metropolitan (magazine), there is a section with a short list of famous contributors. They didn't seem to be any any particular order, so I tried to put them in alphabetical order using C&P in VE (Windows 7/Mozilla). The square bullets got left hanging, and then after about the fourth shift, when I cut Jack London and tried to paste him, he was gone. I could not paste that line, nor could I step back to see ti. Then when I tried some-thing else, the whole thing went kaploohey, with only one item left in the list, and that with two bullets. I could not step backward. So I gave up. I'll use the source editor. But I seem to recall having had a problem with modifying lists using VE before. Is any-one working on this problem?Kdammers (talk) 08:03, 13 December 2013 (UTC)
For me the copy action fails on the reference or something. Both lists and references seem to work substantially better for me on mediawiki.org, so perhaps some improvements have already been made to next weeks release. I'll see if I can get some info on that. —TheDJ (talk • contribs) 09:59, 13 December 2013 (UTC)
Hi Rezonansowy, It's not possible to use VisualEditor on talk pages at the moment. Would you like it to be? Given that WP:Flow may replace the talk pages in the next year or two, I'm not entirely sure that turning on VisualEditor would be worthwhile, but if people really would like it, then I could ask. One potentially major problem, though, is that people use asosciation-list formatting (colons) to indent messages on talk pages, and VisualEditor's ability to handle that is very limited at the moment. Whatamidoing (WMF) (talk) 22:59, 13 December 2013 (UTC)
I'm not really a technical person, so I could easily be wrong, but I don't believe that it's possible right now to write a userscript that would actually do this, while the devs have disallowed VisualEditor's use in that namespace. Whatamidoing (WMF) (talk) 23:13, 13 December 2013 (UTC)
That's why I post here, let's answer them and create this userscript for enable this. I propose userscript, because not anyone needs this feature enabled or has it in his prefs, it's for some people like me (yes I would like to have VE on talks). --Rezonansowy (talk • contribs) 00:12, 14 December 2013 (UTC)
One basic feature needed for talk pages is the ability to sign posts. VE can't do this at all, you can't even enter the --~~~~ manually. There is a bug for this somewhere and its unlikely to be fixed in the near future.--Salix alba (talk): 00:49, 14 December 2013 (UTC)
Rezonansowy, I don't think that you understand the problem. Yes: feel free to write a userscript that puts an "Editbeta" button on your talk page. Feel free to have that button invoke VisualEditor. It's very easy to do this: Just append ?veaction=edit to the end of the URL. Feel free to click on that button. But I do not think that the button created by your userscript will do anything when you click on it.
As I've said, I'm not an expert. I could be wrong. And you're welcome to knock yourself out trying, if that's what you want to do. I wish you all the best with it, and, if you are successful, then I hope you'll let me know. But I really don't think that you will be successful. Whatamidoing (WMF) (talk) 02:44, 14 December 2013 (UTC)
Why bother with testing or Bugzilla? Your complaints will be dealt with by incapable hands anyway
Why bother? Testing isn't done by the WMF devs, reports of failures and errors get no, evasive, or wrong answers, bugzilla reports get closed prematurely and incorrectly all the time. Do the people at WMF really want help? They really need help, that has been shown over and over again, but the only ones that don't seem to have gotten the message seem to be working at (or at least being payed by) WMF.
"[...] It does not apply to anything copied from an internal source, i.e., any page produced by Mediawiki. Whatamidoing (WMF)" Completely wrong
"If, however, you open the source page in VisualEditor [...] then you will see that rich copying and pasting works. Whatamidoing (WMF)" Again wrong!
"Just a thought, copying between en.wp and mediawiki.org is probably not the most reliable testcase, since they use different versions of VE. That might be influencing your results. TheDJ" Wrong, but written to be helpful, not as an "I know better", so no problem there.
Bugzilla:
Closed by JDForrester (WMF) 2013-11-26 as Resolved-Fixed
Reopened by me, with reference to my tests here, 2013-12-09 08:20:51 UTC
Closed again by Jdforrester (WMF) 2013-12-10 17:06:29 UTC as Resolved-Fixed without any comment there or anywhere
Reopened by me 2013-12-11 08:16:38 UTC
Closed again by Andre Klapper 2013-12-11 12:39:57 UTC , this time with an unsatosfactory comment, basically stating that the WMF doesn't care if a fix has many known bugs, and that apparently bugs are not a problem preventing deployment as long as the literal, technical minimal requirements are met. Furthermore, Bugzilla is too lazy too follow a link to enwiki discussions and expects that the discussion gets repeated there, in new bugs I have to submit.
With my apologies to the few WMF people involved in this who try their hardest to be user friendly (Elitre comes to mind), but in general, you are not worth the money the WMF (i.e. the Wikipedia readers) spends on you, nor the time lost on you. That the initial release of VE was a catastrophe was bad; but that the repeated fiasco's since then have not learned you anything, and that all your promises to the contrary have been shown to be pure bluster, is much worse. Fram (talk) 13:06, 11 December 2013 (UTC)
TheDJ (volunteer) opened a new ticket, 58318, confirming one of my testcases, but this time in Safari (so it fails in Safari and in Firefox at least). He indicated that this ticket blocked ticket 41193 (" Derk-Jan Hartman 2013-12-11 13:19:08 UTC Depends on: 58318")
But who cares about this? Not the WMF devs in the form of User:AKlapper (WMF), who again closed the ticket, without adressing theDJs issue. ( Andre Klapper 2013-12-11 13:49:39 UTC )
I supppose that, since the deployment is dependent on this bug being fixed (it was the first and most important of the bugs listed in the status report), it has to be closed at all costs. Deadlines being more important than getting it right, not for the first time. Fram (talk) 14:51, 11 December 2013 (UTC)
Who needs bugs when you get "fixes" like this?
Let's recap what this magnificent, ready-to-go-live new feature actually can do, since bug 41193 is closed. The bug was to "Support copy and paste from other VE instances". To make it easier, I have only tested this with copies from and to MediaWiki, so different versions of the VE software don't come into play. My tests are done using FF25 and W7 (quite a common combination), we know that there are at least bugs with Safari as well, we have no reports from tests with other combinations.
External links? Y This seems usually to work (not completely the same, but near enough). Mind you, external links in templates go completely haywire though...
Internal links? N I took one line from FAQ, "where do I donwload MediaWiki?". One single line, that's all. [8] Most other examples below contain further cases of internal links gone wrong
References? N I tried to copy [9] (the whole page), to get a page with a reference (not common on Mediawiki). The result is baffling but amusing[10]. If you go to the reference at the bottom of that page, and click the "arrow" at the left (taking you up to the place in the same page where that reference is used, no?) then suddenly you end at the original page, in VE edit mode!
List bullets? N[11], section Display, gives [12] Note how multiple lines from the original are squashed together in the copy
Images? N I found an image in [13], section Code, Status: but the result [14] has no image, as part of the syntax is lacking...
Templates? N I tried copying the template from here, on the right: the result is [15]. Something simpler? {{Note}} changes into <span class=""><span class=""></span></span><span class=""> </span>'''Note'''<span class="">:</span> [16]
Tables? N Taken from [17], but the result is not quite the same [18], not the contents (yuk) nor the layout.
Code? N I tried to copy the code from FAQ, section "How do I add extra namespaces?", but the result [19] is not quite the same as the original, and looking at the actual code underneath makes this even more obvious
Further bugs? N, e.g. the sudden appearance of (actually quite nice) clouds as section headers[20]
Further bugs part 2? N But extremely funny! No idea what happened here, but I tried to copy a section from [21], section "Development releases", and nothing more. The amazing result, starting from an empty page, is [22]. Don't ask me where that template at the bottom left comes from, I didn't ask for it!
Further bugs part 3? N, again funny, perhaps the same as the one above: From [23] I copy the short sentence see the {{git file|project=mediawiki/core|file=resources/mediawiki.ui/sourcefiles|sourcefiles}} subdirectory. (shown here in wikitext format, but everything here is copied using VE only!), which looks originally like "see the resources/mediawiki.ui/sourcefiles subdirectory". The end result of this one sentence? [24] Don't you love it?
Further bugs part 4? N If I want to copy Flow Portal/Design/FAQ, I can't. I can't paste it into my sandbox, and if I paste it in multiple parts, I can't save it (the save button doesn't work).
The above list, obviously, isn't exhaustive...
WMF devs, stop protecting your jobs, your deadlines, your colleagues, your pride, your ass, and admit that this thing sucks extremely big time, and that none of you have done any decent testing on this. Again. As always. Stop this deployment, reopen the bug, and fix the bloody thing until at least most of this works. Just do the job you are being payed for, but don't bother us with your stupid toys until they actually work sporadically.Fram (talk) 21:28, 11 December 2013 (UTC)
...according to Jdforrester, all the above is not important, the thing is fixed and will stay fixed: "James Forrester 2013-12-11 22:00:49 UTC Your attempts to re-write history notwithstanding, Fram, this is and remained fixed.[...]" Unbelievable... Fram (talk) 22:11, 11 December 2013 (UTC)
Its worth paying a bit of attention to Andre Klapper's comment. Bugzilla is very closely linked to the code and there is some bit of code to allow cut and paste to happen. This is now in the code base [25]. Bug 41193 relates to that particular bit of code, so is rightly fixed. Just because the code to allow cut and paste to happen does not mean cut and paste works completely. There are lots of cut and paste related bugs T35105 seems to be the main tracking bug and ideally there should be a bug for each of the non working features. This works better for the devs as they can fix each issue in turn. As a stopgap I've added the above comment as a new bug T60354. Please don't reopen bug 41193 again I I'm watching a related bug and get sent an email every time it changes state and its getting annoying. --User:Salix alba (talk): 22:40, 11 December 2013 (UTC)
Bugzilla's system isn't obvious to most people, but Salix alba has it right. An enhancement report is normally closed whenever anything at all works for it. Then we get to open dozens of "bug" reports to tell them all of the problems, and often a handful of additional enhancement reports to extend the feature to cover cases that weren't originally envisioned, but would be useful.
Another way of looking at it is this explained by Andre: The item in question is "Support copy and paste from other VE instances (surfaces)" at least a little bit, not "Implement functionality to copy and paste from other VE instances and make sure that it works in 100% of all cases". If it is possible to do it under any circumstances at all, then that report should be closed, and all of the specific limitations need their own reports and their own code patches. Whatamidoing (WMF) (talk) 23:02, 11 December 2013 (UTC)
But it was possible, you could copy-paste from rich surfaces, but you ended with plain text, but without errors usually. Now, in some very easy cases, you end up with formateted text, but way too often, with errors included. This is announced to everyone as the mosy important update of the new version, put first and in bold: "You can now paste rich content copied from external sources (not just as plain text), including other VisualEditor surfaces (bugs 41193, 48170, 50128, and 53828). " If you (WMF devs, Jdforrester) believe that this is so important, and that fixing the bug 41193 is responible for this, then it should work most of the time, not every now and then only. Implementing this fix is something you all should be ashamed about, not something to shout proudly to the world.Fram (talk) 05:49, 12 December 2013 (UTC)
The problem is not me reopening the bug, the problem is shortsighted devs closing it again, despite the terrible state this is in. If they hadn't closed it again and again, you wouldn't have received all these mails either... It is ridiculous to state that something works if this is only technically true, but not in any practical sense of the word. This is a typical tech-oriented vision, where the actual need that the bug is supposed to fix is totally forgotten, and the obvious negtaive consequences totally ignored. "An enhancement report is normally closed whenever anything at all works for it." is a terrible thing to say. Fram (talk) 05:49, 12 December 2013 (UTC)
Note that above I have been referred to T35105, which is supposedly the main bug for this feature. After thorough testing and due diligence, what is the latest that Product Manager Jfdorrester thought this bug needed?
James Forrester 2013-12-03 00:51:46 UTC Re-prioritising down, as the main work is now complete. Priority: Highest → Normal
Yep, this feature, where almost nothing works as it should, is no longer of highest or even high priority, but now of "normal" priority, since "the main work is now complete"! I'm glad that has been solved then. I understand that the people claiming that I was disrupting them and keeping them from more importan things when I tested their software are reported bugs, can't be bothered to actually make the bug status reflect reality one tiny bit. It probably isn't included in their job description. Oh wait, that's not correct, the job description is the things they don't do. Fram (talk) 08:15, 12 December 2013 (UTC)
2. I suspect this might be caused by JS errors being thrown because of a copy action on the originating surface. All following copy actions from the source surface (even small ones) might then become corrupted I suspect. bugzilla:58379
6. I was not fully able to reproduce this, but there seems to be in issue in the paragraph following the template. bugzilla:58384
7. This seems to be because this table also doesn't render properly in the original surface to begin with. bugzilla:58387
8. I was not able to reproduce this [28], but again, if 2. occurred in the original source surface before your action, then this might cause that I guess. Also it seems that the syntax highlight classes are not dynamically loaded when you paste this content into the target. I reported this as bugzilla:58388
9. Clouds seem to be the result of pasting something over existing content. bugzilla:58389
Thanks for your tests. It seems that you get less problems with Safari than with FF for this functionality. Lucky you :-) Fram (talk) 11:30, 12 December 2013 (UTC)
Thanks to everybody here trying to explain how Bugzilla and development workflows work, for turning unresolved problems into specific and separate bug reports (because that's how the bug report lifecycle works), and for keeping meta-level "the WMF folks are doing it wrong" discussions out of specific bug reports, because they are meta problems. They are not directly related to getting a specific bug report fixed (though that bug report might still serve as a good example for the meta problem). The misexpectations and misunderstandings covered in this thread look like good examples why there's currently work going on to create a mw:Bug_management/Bugzilla_Etiquette... Fram: "Testing isn't done by the WMF devs" ignores the ongoing QA activities that you seem to not follow. You are welcome to contribute more automated tests for areas which miss tests. Personally speaking, I don't try to protect my job (because I wouldn't work for WMF if I didn't want to) or my deadlines (because I don't have any strict ones that I am currently aware of). I care about my ass because I like sitting on it. As a Bugzilla maintainer I also like protecting any Bugzilla users from hostile behavior and aggressive comments, may these users be community members or newcomers or coworkers or volunteers or whatever. So I don't see good reasons to play the "Foundation vs. Community" or "us vs. them" card here, because I would not react any differently if somebody is hostile towards a maintainer (of a piece of software maintained in a bugtracker that I maintain) who is a volunteer or works for some random company. But of course you are free to question my self-understanding. :) --AKlapper (WMF) (talk) 12:26, 12 December 2013 (UTC)
As far as I can tell, you both have misunderstanding of how the process should work. If Fram is correct as to how the latest version works, the enhancement probably should be set to "normal" and the specific errors Fram reports should be set to "highest" as bugs, and they should be linked in both directions. If this were done, Fram might still complain, but the bugzilla system might be considered to be working correctly. I haven't checked to see whether it has been done. — Arthur Rubin(talk)16:36, 12 December 2013 (UTC)
Since the enhancement report is closed (the feature exists and works for at least limited cases, including nearly everything I've personally tried to do), then changing its priority is pretty pointless. Individual bugs need to have their priority set based on their specific situation. Whatamidoing (WMF) (talk) 20:14, 13 December 2013 (UTC)
""Testing isn't done by the WMF devs" ignores the ongoing QA activities that you seem to not follow. You are welcome to contribute more automated tests for areas which miss tests." Can I please have a "head-against-desk" emoticon here? I don't give a flying shit about your automated tests. I don't care about the QA activities. I only care about the results. Every two weeks, we get a new deployment, and every two weeks, it is filled with bugs that should have been found with the most basic human testing. Even JDforrester had to admit this time that he didn't understand how these bugs (e.g. the scolling to the bottom of the page when opening a page in VE) were not seen by anyone before I noted them. So don't give me no shit about "you are welcome to contribute more automated tests"; these are clearly insufficient, and for that reason more and better human testing has been promised time and again, but none has been delivered. So, no matter what you and others claim, I'll continue stating that "Testing isn't done by the WMF devs (or any employee of the WMF)", since the end result, no matter if they booked 8 hours a day for testing or not a single one, is the same as if no tests were done. Your testing sucks big time, and has caused havoc aplenty; if you haven't understood that little fact from this thread, then this truly is hopeless. And while you may not see good reasons to play the us vs. them card at Bugzilla, there is more than enough reason to play that card from the enwiki point of view. "Them" aren't learning anything from their many previous mistakes, and "us" have to clean up after them, or prevent them from creating more problems. Basically, "they" are pushing rubbish to us, and "we" have to test it because "they" haven't done any decent testing (I.e. the kind that finds the most basic bugs at least). Fram (talk) 20:41, 12 December 2013 (UTC)
I didn't read all of this comment as I stopped at the second "shit". There are likely very valid points in these lines, but they are unfortunately blurred by the non-constructive tone chosen. But I guess I repeat myself. --AKlapper (WMF) (talk) 16:27, 13 December 2013 (UTC)
The @AKlapper (WMF):-readable version of my previous post: ""Testing isn't done by the WMF devs" ignores the ongoing QA activities that you seem to not follow. You are welcome to contribute more automated tests for areas which miss tests." Can I please have a "head-against-desk" emoticon here? I don't give a flying pig about your automated tests. I don't care about the QA activities. I only care about the results. Every two weeks, we get a new deployment, and every two weeks, it is filled with bugs that should have been found with the most basic human testing. Even JDforrester had to admit this time that he didn't understand how these bugs (e.g. the scolling to the bottom of the page when opening a page in VE) were not seen by anyone before I noted them. So don't give me no nonsense about "you are welcome to contribute more automated tests"; these are clearly insufficient, and for that reason more and better human testing has been promised time and again, but none has been delivered. So, no matter what you and others claim, I'll continue stating that "Testing isn't done by the WMF devs (or any employee of the WMF)", since the end result, no matter if they booked 8 hours a day for testing or not a single one, is the same as if no tests were done. Your testing sucks big time, and has caused havoc aplenty; if you haven't understood that little fact from this thread, then this truly is hopeless. And while you may not see good reasons to play the us vs. them card at Bugzilla, there is more than enough reason to play that card from the enwiki point of view. "Them" aren't learning anything from their many previous mistakes, and "us" have to clean up after them, or prevent them from creating more problems. Basically, "they" are pushing rubbish to us, and "we" have to test it because "they" haven't done any decent testing (I.e. the kind that finds the most basic bugs at least). (reposted by and at) Fram (talk) 08:44, 16 December 2013 (UTC)
Update 2013-12-05 (MW 1.23wmf6) (planned for implementation at enwiki and most other wikis), described at mw:VisualEditor/status#2013-12-05 (MW 1.23wmf6), should not be implemented here. Deployed at MediaWiki, I found two serious errors affecting many (all?) users. Furthermore, the most important new feature of it only works so-so as well. I have noted these things at mw:Talk:VisualEditor/status, but replies there tend to be erratic and unwelcoming. Fram (talk) 14:32, 6 December 2013 (UTC)
Bug 58089
VE scrolls down to bottom of the page (confirmed for FF by other editor). This is the one that really confirms my fears about the crap that the WMF (or its VE Product Manager at least) hsa been trying to sell us for months now. The problem: if you open a page in VE, the cursos is nicely at the top, but the image, the thing you see, is the bottom of the page... Totally useless, and totally obvious for every human tester worth his salt. Please remind me, how many times has it been said that yes, everything gets tested by humans, but yes, we will do even better in the future? Bullshit. @Jdforrester (WMF):, are you trying to defend your team and testers out of some misplaced sense of loyalty, or are you simply incompetent, or worse? How many such failures will you need before you see the light? "Switching to Wikitext, oh, that doesn't work in Firefox" or "Who would have thought that other language wikis would use diacritics and accents?" are just a few weeks old, and now this. The updates can't be trusted, the status reports on them can't be trusted, and the WMF excuses can't be trusted. Do you really believe that this is the way to get enwiki (and nl-wiki and dewiki) to reembrace VE anytime soon? Never mind that, do you really believe that that is the way "agile programming" works and software should be deployed? I have to go and test at MediaWiki (where some WMF people made it very clear that I'm ot really to be trusted or welcome) to prevent these "improvements" to be deployed here. I don't think anyone else is doing this, perhaps because they still believe that the WMF handles this, or (more probably) because they can't be bothered with VE anymore at all. Congratulations! Fram (talk) 14:32, 6 December 2013 (UTC)
Bug 58090
This may well be related to 58089 above (let's hope so). When you are editing the text, and you add a reference or a template, the cursor is not placed at (or better yet behind) the ref or template you inserted, but at the top of the article. The page hasn't scrolled up though, so this isn't really obvious. If you start typing after adding a ref or template, you are editing the start of the article, not the place where you were. How this hasn't been noticed isn't clear, but one rant per post is enough. Fram (talk) 14:32, 6 December 2013 (UTC)
Rich content?
The new update introduces a long awaited improvement: "You can now paste rich content copied from external sources (not just as plain text), including other VisualEditor surfaces". And indeed, you can, but you shouldn't expect it to work very well... I've done two tests, described at MediaWiki, one from another MediaWiki page, and one from an enwiki page, and both contained immediately obvious errors. My third, more ambitious attempt (still one section only) can be seen at [29]. I think there is still some work to be done before this feature can really be considered to be ready for implementation.
As a final test of this bug, I thought, let's play fair, let's just copy the announcement of this change from the status page to my mediawiki sandbox. Nothng fancy, no cross-wiki copy, just the most basic thing this faeture is supposed to do. [30] is the result. I wonder what kind of "rich content" we are supposed to copy-paste with this, I haven't seen much beyond plain text that works. This was important enough to be put first in the status report, and bolded, and even this sucks big time. Fram (talk) 14:32, 6 December 2013 (UTC)
I believe that you will find that the word external in the phrase "copied from external source" is important. This statement is exclusive to material "copied from an external source", such as a newspaper website. It does not apply to anything copied from an internal source, i.e., any page produced by Mediawiki. Whatamidoing (WMF) (talk) 02:33, 8 December 2013 (UTC)
Then what does " including other VisualEditor surfaces" in that same sentence mean? Which VE surfaces are not produced by MediaWiki? And why would it supposedly work with non-MediaWiki VE text, if it doesn't even work with MediaWiki VE text? Perhaps some examples of what is supposed to work, and what isn't, can be provided? Fram (talk) 11:34, 8 December 2013 (UTC)
Apart from that: whose idea was it that straight copying from an external source like a newspaper website would be a good idea anyway? And comparing what can be done in the current VE to what the new feature is supposed to do indicates that in the new version, you get more layout, and more unwanted layout. I don't see it saving any work at all. Anyway, I'ld still like an answer to whatr "including other VisualEditor surfaces" means, if it doesn't apply to anything produced by MediaWiki... Fram (talk) 08:09, 9 December 2013 (UTC)
Looking more closely, I think you are wrong here @Whatamidoing (WMF):. The first of the four bugs this is supposed to have solved is 41193, which is the one I tested and posted here. This one, which seems to me to be the most important one, is clearly not solved, or not in a workable fashion. Fram (talk) 08:18, 9 December 2013 (UTC)
A page in "view" mode is not "a VisualEditor surface". If, however, you
Many people have requested rich copying from sources so that, for example, book titles remain italicized. If you personally don't see a purpose for that feature, then you don't have to use it. Whatamidoing (WMF) (talk) 22:40, 9 December 2013 (UTC)
How is it user friendly that you have to open the other page in VE as well? Anyway, this is what I did originally, and have tested here again, and here again on a blank page. And here a simple copy from a VE-open page in enwiki to my MediaWiki sandbox. With a more complex one like a copy from part of Staldenried to here, I even get a new symbol; now that we may be finally rid of the pawns and snowmen, we get clouds! So, no, it doesn't work for me, and probably for many other people. Can you test it with the same text I did (all of it preferably), and indicate which browser and OS you use?
As for "if you personally don't see a purpose for that feature", please don't put words in my mouth. I see a purpose for that feature "if it would work most of the time", not as it is now. A bit like VE in general, one could say. Fram (talk) 09:41, 10 December 2013 (UTC)
Side-by-side comparison of the same short text, copied from wikitext to wikitext, and from VE to VE: [31]. Note that in preview, this gives two times the exact same result. Apparently the VE preview mode is more lenient than the VE save mode, which is a Bad Thing™Fram (talk) 09:55, 10 December 2013 (UTC)
I'm still trying to see what works, but the results are not encouraging at all. Copying one simple template from a MediaWiki page[32] to my MediaWiki sandbox gives rather unexpected results. Again, the preview is clearly better than the actual result, e.g. the flower image is visible in the preview, but not in the saved page.[33]
If I take a complex page, like here, you can see a whole array of problems, like links not working, images disappearing, first words of piped links with multiple words messing up things, and so on. The things that should have been tested before announcing that it is ready and closing the bug as resolved-fixed. Note that many of these have now become impossible to easily resolve in VE, e.g. the file definitions are now links which return "undefined" when you click on them, and the language links at the bottom are now no longer accessible. Basically, in all my tests, the only conclusion I can draw is that this works when you use text without any markup (so not "rich text"), and gets progressivley worse the more wikimarkup is present.
I also have the impression that the speed of VE has considerably decreased again with the latest release at MediaWiki, e.g. when opening [34] I get a script error. When choosing "continue", the page opens but (as with other pages at MediaWiki) it renders incorrectly in VE (from "Alter the database" on). Fram (talk) 13:42, 10 December 2013 (UTC)
Just a thought, copying between en.wp and mediawiki.org is probably not the most reliable testcase, since they use different versions of VE. That might be influencing your results. —TheDJ (talk • contribs) 15:49, 10 December 2013 (UTC)
You may have noticed that I also tried to copy from within MediaWiki, i.e. with the same version of VE, which failed as well. Plus, we are supposed to believe that this handles all kinds of rich content (the happy announcement has no restrictions whatsoever), but a previous version of VE is enough to disrupt this? Anyway, it may not be the best testcase, but at least it is a testcase. That's more than what all the WMF devs together had done for this VE version, apparently, considering the major bugs that were not noticed (in general and for this specific feature). Fram (talk) 08:04, 11 December 2013 (UTC)
Bug 41193
@Jdforrester (WMF):. Why did you reclose bug 41193? Without any comment, changes, replies, anything? You have been shown time and time again that you are wrong, that testing is insufficient (or simply non-existant), that bugs which are closed are not fixed, that bugs which you consider duplicates are not duplicates at all (e.g. bug 57209 discussed below), and so on. Perhaps you had a good reason to close the bug as "resolved fixed", but we can't read your mind. If you close a bug as resolved-fixed, and people report serious problems with it and reopen it, then the least you should do is explain your swift reclosing.
Your job description is "My job is to help make sure the VisualEditor team understands what the community wants and needs, is focussed on the things that matter, and is engaging with and understood by the community." Please start doing your job. Fram (talk) 08:27, 11 December 2013 (UTC)
Note that the above was removed by Jdforrester[35] with the edit summary " WP:NPA; resolved off-wiki.". The NPA is probably "please start doing your job", which is commenting on his edits (or actions as dev, which is equivalent). Criticisms of failures in your job here are not "personal attacks", just like people complaining about admins abusing their tools are not issuing personal attacks. As for "resolved off-wiki", you probably mean mw:Talk:VisualEditor/status#2013-12-05 (MW 1.23wmf6), where you replied to one minor point which was fixed in the meantime, ignoring (not noticing) the other issues with the first examples I gave there? You were pinged about the longer discussion here (so I presume you had seen it as well), which contained plenty further evidence of problems. Apparently that wasn't sufficient either.
For your (i.e. @Jdforrester (WMF):s) convenience, I compiled Wikipedia:VisualEditor/Feedback#Who needs bugs when you get "fixes" like this?, which is basically what the WMF devs should have done initially, when they created but before they deployed this "fix"; or failing that, what they should have done when people reported that the fix wasn't ready to be deployed, with some examples. Instead, all you (WMF devs) did was giving incorrect replies, not answering at all, avoiding the issue, and complaining about the tone of the posts, as if that was the most important issue and came out of the blue.
Jdforrester, this started with the two major regressions, something which the most basic testing should have found, about which you said "you're quite right, not sure how this slipped through. :-(" You may have not been quite sure, but it is extremely obvious to me, and probably to everyone who has followed this page for the mast half year: it slipped through because you still don't do any testing worth that name, and it costs you dearly time after time.
Please don't try to claim that the Bug 41193 fix had been tested at any length. If it was tested, and these problems weren't found, fire the testers. If it was tested, the problems were found, but people decided to push the fix through anyway, then fire the people that made this decision. If it wasn't tested, then fire yourself and whoever else is supposed to be responsible there (Erik Moeller and the like) for repeatedly lying to us with rather severe consequences. Fram (talk) 21:58, 11 December 2013 (UTC)
Snowflakes and clouds
While apparently the pawns and snowmen errors have been fixed (at first glance) we now get clouds and snowflakes instead. Very seasony, that last one, but unwanted behaviour nevertheless. Here I put in VE a square bracket and then an URL, and I get a snowflake on the next line. Do things in a different order, e.g. first put the URL, and then put the end and front squer brackets, and it works allright. Very strange, and doesn't seem to happen before this new version... Fram (talk) 10:42, 10 December 2013 (UTC)
I can't reproduce this. You just typed [http://example.com (in that order) and it produced a black cloud with the formatting for a level-2 section heading? Whatamidoing (WMF) (talk) 22:46, 11 December 2013 (UTC)
No, it produced a snowflake. The Clouds appear when I copy-paste over a previous text sometimes, I'm still trying to find a rule for this but it has happened repeatedly. But the snowflakes appear every time I do this. Fram (talk) 05:42, 12 December 2013 (UTC)
I think that's a sun (with rays of light), rather than a snowflake.
What I want to confirm is that you get this just by typing in the beginning of a URL (minus any label or closing bracket), without clicking on anything else, because I can't make that happen, either using the same URL or another in Safari, or in Firefox. Does this appear in Review Changes, or only after you save the page? Does it only happen on new/previously blank pages? Does it only happen if the URL is the very first thing in the page? Whatamidoing (WMF) (talk) 20:08, 13 December 2013 (UTC)
This seems to have been fixed (there have been some fixes between the MediaWiki deployment and the enwiki deployment, or it would have been a rather bad deployment overall). I'll let you know if and how it reappears. Thanks for testing this and letting us know the results! Fram (talk) 08:58, 16 December 2013 (UTC)
Conclusion
The major new feature doesn't work as it should do, and at least two major new bugs are introduced: please, please do the sensible thing for once, and do not implement this update anywhere. Fram (talk) 14:32, 6 December 2013 (UTC)
So you "really" claim that people test things before deployment? Really?
Then how do you explain the "new look" of the toolbar at MediaWiki after the 12-12 deployment? [36] now shows the "More" dropdown button in a new, much more stylish format: <visualeditor-toolbar-insert>. Dropping it down, the last entry is the <visualeditor-specialcharacter-button-tooltip>, which opens the <visualeditor-specialcharacterinspector-title>
Yep, the above "nowikis" are the actual text you see. Catchy, isn't it? Of course, being blocked on Bugzilla, I can't file a bug there :-))))
I then tried to edit my sandbox, but on saving, I got "Error: The modification you tried to make was aborted by an extension hook". Nice... I'll let the testers figure out on their own how to reproduce that one though. Further tests still included clouds, and all known problems. But with a better toolbar, credit where credit's due! Fram (talk) 21:17, 12 December 2013 (UTC)
At least someone reads this page, since the above problems with the new toolbar have now disappeared. See, that wasn't so hard! Fram (talk) 05:49, 13 December 2013 (UTC)
It was a problem in the deployment of the new way the localization messages are stored. Since other messages were cached it wasn't affecting them. That's why after continuous deployment to the labs servers, all software is deployed to the tests and mediawiki.org servers first. These servers are part of the production platform, but they are not critical and allow us to test how things behave under 'production deployment' conditions. These kind of deployment issues can then be fixed before the next tier of servers receives the release. —TheDJ (talk • contribs) 09:39, 16 December 2013 (UTC)
Please test this with different browsers and OS and so on
Using the first article I found with "random article", I tested the "rich text copying" feature which finally has been released to enwiki, despite misguided requests to the contrary.
Eupithecia albibasalis gives [37] for me, with FF25 and W7. Hey, it's nearly the same as the original, no?
So, can some people test this same article as well, and present their results, with their OS, Browser, and other relevant info? It may be at best informative, and at worst very amusing. No need to post your results at Bugzilla though, the WMF devs are, after their own extensive testing, of course aware of all these issues already. Fram (talk) 21:31, 12 December 2013 (UTC)
What do you (anyone) expect the result to be, if you copy and paste an HTML table that was generated by a template? Do you expect to get the original template or the HTML table that the template produced? Whatamidoing (WMF) (talk) 22:54, 13 December 2013 (UTC)
The copy operation should contain as much information as possible. The paste operation should determine how the contents of the clipboard should be used, which depends on context. Ideally copy and paste between a read-only page on a mediawiki site and a VE session on the same site should result in a copy of the original code being placed into VE session. That isnt easy, as it will require either embedding the wikitext into the read-only page, or that the read-only page contains markers that allow the VE paste operation to fetch the relevant wikitext segment from the revision of the read-only page to put into the VE session. The former is more efficient in some instances, such as navboxes, etc, but for complex wikitext the latter is better. Good copy and paste of navboxes would be an easy win. See bugzilla:52091. I expect new users will be trying to copy and paste infoboxes too (as that is conceptually easier than transclusion), however an intuitive VE plugin to create Infoboxes would mostly remove that use case. John Vandenberg(chat)07:16, 14 December 2013 (UTC)
What John Vandenberg said. If I copy part of a VE page to another VE page, I expect to get the same end result, i.e. layout, information, and underlying wikitext. I hope, Whatamidoing, that you don't mean that the result I get is the result the "rich paste" developers intended? Fram (talk) 08:48, 16 December 2013 (UTC)
I tries this with Vector/Chrome32/Win7. First I tried copying from the article in VE edit mode [38]. Apparently the infobox wasn't copied, even though it appeared to highlighted (which I did using the mouse). Next I used CTRL+A to make sure everything was highlighted, which resulted in [39]. I then tried copying from the article in normal read mode, which gives [40]. The good news? Bold, italic, and bolded italic text copys alright. Templates seem to copy over alright, if you copy them from VE edit mode, and actually manage to highlight them. The bad news? Links are either being completely messed up, when copied from VE mode, or not being copied over at all, when copied from read mode. The reference that isn't inside the infobox template is copied over as as an empty <ref /> tag, or as plain text, depending on the source. - Evad37[talk]09:35, 16 December 2013 (UTC)
Thanks. Apparently Chrome givs better results than FF. I also use "select all" in VE edit mode, but still I can't copy the infobox correctly (I get about the same result when I copy from "edit-mode that you get when you copy from "read" mode...) Fram (talk) 10:00, 16 December 2013 (UTC)
Diligent testing by Fram
I switched this thing off wayback but follow the /Feedback page hoping to learn that the left hand understands what the right hand and the rest of the movement is doing. So cringing from afar can pass on my admiration and respects to Fram for her/his tenacity in staying with the subject. I know from other walks of life that expressing the beliefs of hundreds of volunteers can get to be a lonely job- when they recognise that you are saying exactly what they wanted to say, they walk away and let you get on with it. Frams views are universally shared- and should be treated with reverence by WMF and the advice followed to the letter. — Preceding unsigned comment added by ClemRutter (talk • contribs) 22:28, 11 December 2013 (UTC)
I agree completely, but I have to say that Fram's tone is sometimes overly aggressive. He seems to be frustrated that there are limits to what is delivered when and at what quality and the rate at which those improve. The quality levels in terms of development that some people are expecting are at least some 3 years out. This is not going to change in a few months. Quality processes grow organically, you cannot just 'put them in place'. Well you can, but then they'd never get anything done, the foundation would bleed money or the teams would self collapse. In the mean time, there is this gigantic site and community that needs to be kept going. We should not forget that the foundation in terms of software development is only some 4 years old. Before that time (and also largely overlapping) it were just a few folks doing some volunteer style work, but doing it fulltime so they were hired, because someone NOT doing it was worse). Also these improvements are often made at the most important yet least visible parts first but that is hard to see as an outsider. Complain, complain often, just don't let it get too emotional, because that is just counter productive. If you take a 2 year overview, progress has been enormous. And if you start stamping on folks toes, don't be surprised that the other person won't extend you a hand. Goes for both parties.... —TheDJ (talk • contribs) 00:28, 12 December 2013 (UTC)
"He seems to be frustrated that there are limits to what is delivered when and at what quality and the rate at which those improve." is partially right. I'm mostly frustrated at the lack of improvement in the testing, and the gaps between what is promised and what is delivered. I don't expect greater speed, more improvements, ... on the contrary I have asked to stop pushing the two-weekly deployments and instead work on it for a few months so that what gets delivered then is coprehensive and thoroughly tested, so that we don't have to worry that almost nothing of what was promised as new features is actually working. Contrary to what a WMF dev said, I don't expect 100% correctness from the first or second time. What I expect is that most normal elements you may expect from a new feature are in place and working, and that it is thoroughly tested before implementing it at live environments.
My frustration stems from the repeated promises that things will change, testing will be done, and so on, which always turn out to be falsehoods; and the gap between what the devs know they have done, and the way they present it here. I probably wouldn't have had a problem if 41193 was closed, if it wasn't announced as if this bugfix meant that VE copy-pasting was now an important feature of VE that finally worked. I also wouldn't have been so frustrated if I had seen some evidence that the basic tests I did for that feature, revealing easily a lot of major flaws, had been done and documented by the WMF team; but on the contrary, it isn't sufficient that you do their work for them and point them to the many problems with clear examples: no, you also have to bring these individually to Bugzilla for them, where they often get closed prematurely or incorrectly marked as duplicates anyway.
And there comes a time when enough is enough, and for me this is now. It has been exemplified by Jdforrester, who as Product Manager supposedly leads the team, and put into words by User:Whatamidoing (WMF) in a section here above, which explains the problems better than I could ever do (bolding twice mine, italics in original):
"An enhancement report is normally closed whenever anything at all works for it."
"If it is possible to do it under any circumstances at all, then that report should be closed"
These two statements are quite mind-boggling, coming from the "Community Liaison", whose job is "ensuring that our community is represented in the decision-making process and that our planned software adequately reflects user needs". So in reality, this is translated into "we don't fix bugs thoroughly or nearly completely or even adequately, we fix them minimally, on a purely technical level". It's the behaviour you expect from a commercial venture, where the goal is maximal profit by delivering only what you very explicitly asked for, but without a care for what you probably wanted or needed; but to see this attitude expressed so clearly and casually at the WMF is frightening.
The goal of the WMF devs should not be to close as many bugs as possible or to meet deadlines no matter what the result is; the goal of the WMF dev is to provide tools that are useful, working, and reasonably bugfree so that readers and editors of Wikipedia (and other MediaWiki sites) can do their job better, get better results. They seem, as a group (the VE ones at least), to have totally lost that focus, that understanding, that link to their customers. And I see no improvement at all, rather the opposite. Fram (talk) 08:03, 12 December 2013 (UTC)
Making sure that the devs hear about the commuinty's needs does not include me changing the culture of another community. Your complaint is basically the lumpers and splitters problem: You want to lump all of these specific problems into a single report; they want to split them out so that every single tiny sub-problem gets its own separate report. I don't care. My interest is in making sure that they fix all the problems, not in making someone follow a particular process for tracking the problems. If a dozen separate reports on closely related problems is what it takes to (eventually) get all the problems fixed, then I've got no problems with that approach. If they chose the other way around, then I'd find a way to work within that, too. Whatamidoing (WMF) (talk) 23:10, 13 December 2013 (UTC)
And I now have been blocked from Bugzilla by one of the involved devs on that thread, for "Warned in a private email to stop being aggressive". Funnily enough, another, more friendly editor there posted me a link to the Bugzilla etiquette, which contains things like "Do things in public. Unless you were asked to email somebody with specific information, place all information relating to bugs in the bug report itself. Avoid sending private email; no-one else can read your mail if you do that." Which is what I did, but what the blocking Bugzilla admin didn't (and which I only saw after the block was made, I don't constantly check my wikimails). Oh well, it will at least stop the requests to put these things in Bugzilla :-) The email was rather short, but contained a link to the WMF code of conduct policy, which starts "All Wikimedia staff and members of the Board of Trustees are required to abide by this Code of Conduct. It is also intended to provide guidance for volunteers.". As far as I know, I'm not Wikimedia staff not a member of the Board of Trustees... Desperate times and people require desperate measures I suppose? Fram (talk) 10:31, 12 December 2013 (UTC)
You are a volunteer, but that does not give you a free pass. Our Bugzilla is a community too and one where people don't like this kind of behavior. The problem might have escalated quicker because you "don't speak developer" and that is unfortunate. However you had been warned multiple times on wiki, bugzilla and apparently on mail. It's a shame it had to come to this, because you do useful work (and that has been recognized by multiple people). But just being useful is not enough. —TheDJ (talk • contribs) 11:01, 12 December 2013 (UTC)
Oh, I'm not amazed that I am blocked there. I didn't think one of the people involved in closing that bug would be the one to pull the trigger, but then again... I understand that people don't like that kind of behaviour, but they don't seem to understand the problems with their behaviour (both in attitude and actions). E.g. when someone reopens a bug (not some vandal IP, but someone who does, as you put it, useful work) with a link to a discussion, then you don't simply close that bug again without at least leaving a comment (and e.g. at that time pointing me to Bug 33105, which was only introduced to the discussion by Quim Gil in comment 21). That's a lot more "passive-agressive" than what I was warned for. Not one WMF person in that whole discussion did some introspection and considered what they perhaps had done wrong or where this could have been avoided by them. Most projected their anxiety on my comments, reading things into them that weren't there to begin with. My respect for the bunch of them is utterly, and probably irretrievably, gone, due to their inaction and lack of clue. Fram (talk) 11:25, 12 December 2013 (UTC)
You were not blocked from Bugzilla by one of the involved devs, you were blocked by me after warning you. As much as the Code of Conduct only legally applies to WMF folks, as much is the Bugzilla etiquette which contains things like "Do things in public." not in place yet either (still work in progress), plus you've also been warned publically in the bug report by others anyway. Hence not really desperate times here, just the expected behavior when people intentionally ignore warnings to be more friendly and respectful. --AKlapper (WMF) (talk) 12:33, 12 December 2013 (UTC)
Oh and by the way, I agree that just silently reclosing a bug report without any explanation isn't good constructive behavior either (but I don't know any potential previous discussions between developers and you outside of Bugzilla). Just to set things and expectations straight here. --AKlapper (WMF) (talk) 12:36, 12 December 2013 (UTC)
I was blocked from Bugzilla by a WMF employee who had previously closed the bug I complained about (considering it not fixed at all), so yes, that counts as "involved" in my book. And the desperate times are not about me being blocked, but about the pure one-sidedness of the discussion, with no one interested in adressing the actual issues, extensively detailed here (oh right, that's the wrong place, but it'll be the place you'll have to find them from now on anyway :-D ). I'm glad that you at least consider some of the other behaviour as not constructive either, it's a start. Fram (talk) 20:31, 12 December 2013 (UTC)
WP:INVOLVED is a policy created by and for the English Wikipedia's community. Bugzilla is a separate community and is not required to abide by the rules created by any of the projects they support. Whatamidoing (WMF) (talk) 23:10, 13 December 2013 (UTC)
And yet AKlapper, who blocked me there, did it based on the Foundation policy for their employees, which doesn't apply to me or to Bugzilla. Fram (talk) 08:46, 16 December 2013 (UTC)
This conversation shall be immortalized when the VisualEditor team tries to return VE to opt-out on en.wp. You guys <redacted> Ya know I'm right (talk) 13:41, 12 December 2013 (UTC)
Deployment on en.wikipedia of the new toolbar? And some comments about that new toolbar.
I like the looks of the new VE toolbar, but while it's available at mediawiki, it's not on the English Wikipedia. Is there an expected date for the changeover, here? (I ask because I'd like to update the User Guide.)
Also, a side comment: Why not "Format" or "Formatting" or "Format text" (with a down arrow) rather than the italicized, underlined, capital "A" as the icon for the list of formatting choices? There certainly is plenty of room on the toolbar for that word.
More generally, why are the four pulldown menus on the toolbar handed in four different ways?
"Paragraph" is boxed, has a pull-down indicator
"A" is not boxed, no pull-down indicator [And it lacks a word as a title, as noted above]
"Insert" is not boxed, has a pull-down indicator
The icon of three horizontal bars is similar to the "A" (not boxed, no pull-down indicator) but the first menu choice (page settings) is just a way (a longer way) to get to the second and third choices (categories, language links), and therefore is pointless. (In the larger scheme of affairs, I think that the page settings icon should be visible on the toolbar, as well as the "switch to source editing" icon; then there were be no need for whatever the icon with three horizontal lines is supposed to represent.)
Displaying all menus consistently (I'd vote for following the "Paragraph" approach) really would help an editor easily figure out that these are ways to get are multiple choices, whereas all the other icons on the toolbar are single click-to-use options. -- John Broughton(♫♫)00:50, 17 December 2013 (UTC)
Probably in the next tier release. In general en.wp is 1,5 week behind on mediawiki.org. Schedule for deployments.
The expected changeover date is this Thursday (lunchtime in San Francisco).
The main idea behind icons is that you don't have to translate them 280 times. This one is supposed to get a pull-down indicator, but it wasn't ready as of the MW deployment date. Check back in a week (and the word is that if you want to make screenshots, it's worth holding off for a couple of weeks, because there are multiple visual changes on the way).
I believe that the 'page settings' item will eventually have useful stuff in it (stuff VisualEditor can't do right now).
I believe that the three-bar icon is the usual wiki icon for 'click here to find a menu'. It appears in the mobile interface as well (only I believe that the colors are reversed: white bars on a black background). So this is a bit of internal consistency that will make sense to some of our users, although I didn't know what to make of it when I first saw it, either. Whatamidoing (WMF) (talk) 01:25, 18 December 2013 (UTC)
Hi John, thanks for your feedback, and please, let's keep the ideas coming, James is really looking forward to reading opinions on the new toolbar/features, keeping in mind that nothing is in its final state yet, of course. --Elitre (WMF) (talk) 16:51, 19 December 2013 (UTC)
"The main idea behind icons is that you don't have to translate them 280 times." Of course, when you use an icon, you need to have a tooltip (screentip, mouseover text, whatever you call it) to explain the button, and that tooltip needs to be translated 280 times. So, benefit of the icon in this regard: zero. Seems like the main idea behind icons hasn't been really thought through then? Fram (talk) 09:19, 18 December 2013 (UTC)
@Fram: - there are no tooltips for the four icons that are pull-down menus, just for individual icons. Whether there should be tooltips for everything is another question, but yes, for menus, an icon without text currently requires no translation whatsoever.
@Whatamidoing (WMF): I'm not sure I understand your last point. I thought the indication of a pull-down menu was a down-arrow. Also, there are four pull-down menus on the toolbar (paragraph, format, insert, and page), so why does it make any sense to put an icon for one of them that says "Hi, I'm a menu"? That sort-of-implies that the other three really aren't menus (clickable to see choices)?
John, have you used the mobile site much? If not, then File:Main-menu-dark.png shows the menu (expanded). The three-bar icon is what gets you to the menu. There is no arrow. My guess is that a down-arrow is the "Hi, I'm a menu" mark only if there is a something to add it to, not if the arrow would be all by itself. But I don't know what the reason was for creating this three-bar thing. All I know is that the three-bar icon for the "miscellaneous stuff" menu in VE looks a lot like the three-bar icon for the "miscellaneous stuff" menu in the mobile interface. (I'm looking forward to your advice and reactions on the other page.) Whatamidoing (WMF) (talk) 06:04, 20 December 2013 (UTC)
John Broughton, the menu's don't have a tooltip, but they should of course have one (e.g. explaining the three bars). Fram (talk) 09:06, 20 December 2013 (UTC)
Multiple issues - minimal space
Example of inconveniently small input box for multiple issues, within lavishly white-spaced dialogue box.
I thought I'd have another go with VE. Tried to edit some tags within "Multiple issues": why is the window for the "issues" only about 1 1/2 lines high, when there is a vast amount of empty white space in the whole editing window? It's irritating not to be able to see all the existing issues without scrolling down (no scroll bar, just have to move cursor down through this mini-window). Generally very un-user-friendly. Using Firefox. Could do a screenshot if necessary, if others don't have this experience. PamD12:02, 20 December 2013 (UTC)
Aaargh. As a revision exercise I decided to refresh my memory about how to do a screenshot. Painful, but here we are. PamD12:48, 20 December 2013 (UTC)
That article was deleted an hour after your first post here, but the problem of course exists on all of the multiline parameters. Acrylic paint is even worse IMO, because it starts and ends with blank lines (at least for me, in Safari 6.1 on a Mac). So you might normally be able to see two lines, and there are only two lines there, but it believes that there are four, so it sets up a scrolling box.
I know they're doing a lot of work on transclusion dialogs now, but I don't know exactly what they're planning. I wonder if it would be possible to have the size of the box expand to accommodate larger content. Since most parameters need only a single line, I don't think we would necessarily be happy with, say, three fixed lines for everything. Also, it appears that it's set to be two lines, but that seems to vary (a lot) depending on browser and font choice. What do you think would be good? Whatamidoing (WMF) (talk) 19:49, 23 December 2013 (UTC)
Kant
If I edit Immanuel Kant, place my cursor at the end of the page, and then cursor back one with the left cursor key, the browser freezes for a while (it says "Not Responding" in the title bar) and then when it comes around it has selected all of the material from the bottom up to and excluding the "See also" heading, and there is a transclusion puzzle piece image link over the selection in the top right corner. If I enter the transclusion dialogue through that link, there are "Content" sections which include text fields. Many of these fields are too small to read much of the text within them easily, an example being the Content section above the "Navboxes" template section. Firefox 25.0.1 Windows 7 Professional SP-1. --Atethnekos(Discussion, Contributions)02:57, 20 December 2013 (UTC)
I get only a brief spinning beach ball, but what's selected looks stranger than what you describe, with a narrow column (just about the size of the middle ref column) that goes up for a screenful or so, ending right in the middle of the line that says [dubious—discuss]. I tried this in Safari 6.1 on Mac OS 10.8.5, so I suspect that it will happen to anyone. Can you tell me whether you see the odd column in the center? You might have to shrink your font size to get three columns of refs first: it's a 30em-wide ref column, so a narrower screen/larger font will only have two or even one column.
If you test here, where I've removed the {{multicol}} template, it works correctly. The reason it isn't working is visible in the diff: Someone used the wrong templates. To produce correct HTML, {{Multicol}} requires {{Multicol-break}} and {{Multicol-end}}. Instead, someone combined {tl|Multicol}} with {{Col-break}} and {{Col-end}}. These are not interchangeable, and one result of using mismatched templates is an unclosed div tag. If you manually supply the missing div tag, then VisualEditor works fine. I've fixed it at Immanuel Kant, but there may be dozens of similarly broken pages on the English Wikipedia. Whatamidoing (WMF) (talk) 00:18, 24 December 2013 (UTC)
Also if I place my cursor at the end of the "See also" heading and then cursor forwarddown one with the right down cursor key, the cursor ends up on the right side of the bottom of the "See also" section. If I type a letter then however the letter appears underneath the "Authority control" template. --Atethnekos(Discussion, Contributions)03:05, 20 December 2013 (UTC)
If I do this, my cursor ends up at the very bottom of the page, under the authority control template. I suspect that VisualEditor (or perhaps Parsoid) can't cope with columns right now. Whatamidoing (WMF) (talk) 06:22, 20 December 2013 (UTC)
...and, as has been reported, it can't cope with using the arrow keys in many, many circumstances either. It is somewhere on Bugzilla, not with the priority it deserves though. Basically, arrow keys are not usable in VE most of the time. Fram (talk) 09:00, 20 December 2013 (UTC)
In Firefox on a Mac, I get the same effect as Atethnekos. The cursor location at ==See also== is probably correct: that's the end of the item (the series of templates). But it should place typed characters there, not at the end of the page. And, as explained above, if you either use matching column templates or add the missing div tag, then this problem also clears up. Whatamidoing (WMF) (talk) 00:18, 24 December 2013 (UTC)
Don't see visual editor with Firefox nightly or chromium on Linux
Scientus, I'm glad that worked, at least. In your description above, it sounds like if you go to Special:Random, then you don't see the Editbeta button—you just see [Edit], not [Edit source] and [Edit beta]. Did I understand that correctly? Is that still true? If so, please look at WP:VisualEditor/Opt-in#Troubleshooting for a quick round of the obvious questions, and then let me know how things stand. Whatamidoing (WMF) (talk) 05:46, 18 December 2013 (UTC)
As above, I thought it time to give VE another try.
But:
Still no way to see whether the article has any categories while editing it, short of going to the "Categories" option.
This then obscures the entire article, so I should have memorised the chap's date of death before checking whether the "1869 deaths" category was there or not, as having discovered it's not there I want to add it. Even more of a problem if I'm adding "Category:Villages in Foofoofoo district" and need the spelling. The latest incarnation of this bug seems to be T51969. No sign of any progress.
The article title is in the "Default sort" box by default, but can't be edited there to change it - it's delete or nothing, so you'd better spot that the title appears in the Firefox tab because that's the only place you can see the surname and forename you want to add. (Because, of course, this box hides the entire article content).
There may be some improvements (the very existence of an attempt to help with Multiple Issues is one, I suppose), but on balance it just doesn't work for the kind of edits I do. I'll look out for news from Bugzilla to tell me it's beginning to be anything like fit for purpose, but today it ain't. Good Luck, but 'Bye for now. PamD12:10, 20 December 2013 (UTC)
I'm going to put this on my list of things to hassle James F about at the next staff meeting. I don't know if it's technically complicated or anything, but a lot of editors need this to work. At minimum, we need to be able to slide a box out of the way, even if that means sliding it off the screen rather than resizing it. Whatamidoing (WMF) (talk) 00:32, 24 December 2013 (UTC)
I am still not sure if the new way/layout of adding references (and not only) is good or not. What I know is that on my first try to use it, I don't like it :/ Except of the issue that Pam is mentioning above (Multiple issues-minimal spaces) which is kind of annoying and not helpful since you can only watch one line of what you are typing, when I click on one parameter, the cursor "jumps" to the one above and I have to click it again to make it go where I want. Even worse, when there is no any parameter above, it takes me back to the beginning. I don't know how to explain that exactly. To reproduce it, try to add a reference to an article. It will show you the box with "source title" and "url" parameters already existing and on the right a list of the rest parameters. Don't choose any of the ones on the right and click on the "source title" to add the title. Can you see what is happening? This "jumping" happens almost every time I click on a parameter on the left to add its context! And please bring back the big box where we could write each parameter's context and see what we were writing instead of that line. When you have a list of guests to add in an episode is not helpful at all! FF26 Windows 8 TeamGale17:05, 20 December 2013 (UTC)
I tried it out, and I see what you mean. Here's what I did:
Insert > Reference
Insert > Transclusion
Type "Cite web" into the box. Hit return twice.
Click "URL access date" to add that parameter to the list. Cursor jumped back to "Add parameter" (not unreasonable; you might want to add lots of parameters before filling any of them in).
Click "URL access date", which is now the first item in the left-hand column's list of parameters, so I can add today's date to my reference. Cursor jumped back to "Add parameter" (definitely unreasonable).
Repeat that step as many times as you feel like.
Give up and click on the second parameter, which is "Source title". Cursor jumped to the parameter box for "URL access date".
Click on the third parameter in the list, which is "URL". Cursor jumped to the parameter box for "Source title". The only way to fill in any information for the last parameter in the list is to scroll down the list in the right-hand column.
I'll file the bug in a minute. Thank you for telling us about this very annoying problem. I apologize for not getting it tested and reported on Friday afternoon, when you originally posted this. Whatamidoing (WMF) (talk) 00:57, 24 December 2013 (UTC)
Thank you so much for filing it! It's really annoying! And it's easy to re create it since whatever parameter you click it jumps to the previous one! I hope it can get fixed soon. Thanks again! TeamGale01:31, 24 December 2013 (UTC)
VisualEditor has turned into a powerful tool. One that I'd consider very seriously. Powerful but not reliable. Everytime I make an edit with VisualEditor, there is a chance that my changes are not saved and I receive an "Unknown Error".
Have you checked the page history to see whether allegedly unsaved changes are actually getting saved? We've got a known problem with "Unknown error" actually resulting in correctly saved pages, despite claiming not to do so. Whatamidoing (WMF) (talk) 19:51, 27 December 2013 (UTC)
I think that puts us into T55093's territory. Do you have any guesses about what might trigger it? Some people have thought that it's more likely on large pages, but I'm not so sure that size is exactly the issue. Whatamidoing (WMF) (talk) 23:33, 27 December 2013 (UTC)
Hello again. I have no guesses that aren't as of yet debunked. But here is something totally unrelated that might give you an idea: I can no longer open toolserver.org over HTTPS. I receive an error that says "Error code: ssl_error_no_cypher_overlap" (Firefox) or "ERR_SSL_VERSION_OR_CIPHER_MISMATCH" (Chromium). Obviously, a lot has changed during the move to WMF Labs. Does VisualEditor not rely on some sort of backend outside en.wikipedia.org domain?
Maybe I should look for some sort of debugging tool to give you something more than guess.
You mean in on en.wikipedia.org? I couldn't have "seen" with eyes because VE has these AJAX loading and saving sequences that hide such error. But I will enable Firefox dev tools next times and keep an eye on the networking transactions. Best regards, Codename Lisa (talk) 23:50, 28 December 2013 (UTC)
Codename Lisa, Whatamidoing: One thing that I have noticed relating to a cause is that the few times that I have seen this error are often when I have taken a while to go from clicking edit to saving the page. Perhaps this could be the issue. Has anyone else noticed this connection?:Jay8g [V•T•E] 18:44, 30 December 2013 (UTC)