The way categories are currently edited in VisualEditor is not WYSIWYG at all. Can something like HotCat be added as well?
(Personally, I don't find the "Page Settings" == "Edit categories" intuitive.)
VisualEditor is not intended to be "WYSIWYG" as a main criterion. :-) If you mean that you'd expect categories to be editable in the place in the skin where they can be edited, that's something we've thought about but is very complicated (how do you show and set hidden categories? what about non-Vector skins - do we just abandon them? etc.).
We're not totally wedded to the name of "Page Settings", though note that it covers categories, language links, "magic word" page settings (REDIRECT, NOTOC, DISPLAYTITLE, etc.) and possibly other things too (one suggestion was to put maintenance templates in here (like "unsourced", "orphaned", "spam-like" or whatever - either wiki-specific ones, or build them into MediaWiki in some way). If you have a better name for this collection of things we'd love your ideas. :-)
It's just that to me, Settings implies user-specific preferences, not metadata.
Yes, though we have very carefully used the term "preferences" for users rather than "settings", I worry that this distinction may not have been kept clear in other languages.
Ooh sounds cool that we will have an interface to play with magic words :)
Why not call the link "Categories and metadata"? Sure, it's verbose (and a long string - it might fail the German test), but 100% clear. Most users won't understand the term "metadata", but then, most users probably won't need to tweak langlinks, magic words, etc. "Page settings" is quite vague, and the overlap with "preferences" is problematic (MW might be making a clear distinction between the two, but many other software programs/websites/smartphones etc. regrettably do not).
I think we need to be very careful to avoid putting needlessly-complicated words in front of potential new editors that are likely to scare them away rather than encourage them; "metadata" sounds intimidating, confusing and is not just very unlikely to get users to click the button, but will also add a tone of complexity and technical speciality that will dissuade users from staying.
So, if we can't use "metadata" (and we really, really shouldn't), what else? "Page data"? "Page details"? I also think splitting out the message to name categories differently from other meta-data is the wrong approach - it tries to box people into not setting things like DISPLAYTITLE which are very useful. Just because editing through wikitext makes these very hard to discover doesn't mean we should discourage users from using them in software (that's what community policy and socialisation is for).
Let's not mix things with other skins. The VisualEditor hs its own interface, and it should more or less mimic the look and feel seen in the default skin, or in the Monobook skin, where editable categories to include/modify remove in the wiki code of the page will be at bottom of page.
The HotCat extension behavior is perfect (and much more practical to use than the very basic (insufficient) interface currently presented in the VE. I also vote for the integration of HotCat in the VE (or something very similar). Except that this edit will be possible without having to open a menu, and nothing will be saved before saving the whole page visually edited.
This should not be hidden in that menu. Make the categories visible and editable at the bottom of pages.
For now I'll stick with HotCat, or with editing them in the wiki code editor.
My opinion is that both editors should be integrated, so that you can switch back and forth between the partially editable preview and the wiki code view during the edition. There would then be later a single "edit" tab on wiki pages (the current working mode would still use the user's preferences, if he only wishes to use the wiki code editor. We should always be able to see at any time every wiki code being modifed by any edit action in the VisualEditor, by just clicking a button.
Also, the editable preview panel (or the wiki code editor) will be scrollable, the interface at top may become a right-side properties pane, fixed on the page and not scrolling (the option buttons will be there in this properties pane.
Still missing as well in the VisualEditor: no support for the very useful characters selector (needed for I18n or for editing IPA and Maths symbols, or some useful punctuations like bullets, rarely present on keyboards). That's another reason why I still prefer not using the VisualEditor by default.
Another reason is that if the VE is your default, there's no way to edit a section in the wiki code editor, only visual editing is present. As long as the two editors are not integrated, we should still have two edit links: "" and "[edit code]" at end of editable sections, if the VE is enabled in user's preferences.
Lots of template transclusions also offer a specific edit link. Their action uses only the wiki code editor. If both actions "edit" and "editVE" were merged into a single one (with a simple switch to show either the editable preview or the wiki code) it would be simpler. And the "Show preview" button could disappear below the wiki editor (it would just remain a "Save page" button), but the "Save" button could also show the actual rendering without the limitations of the editable preview.
- "(Personally, I don't find the "Page Settings" == "Edit categories" intuitive.)"
+1. I thought VE still couldn't edit categories until I read this thread.
Which is why I do suggest taking a look at its user guide from time to time to find out what it can do :) Maybe not covered there yet in all languages, but available from the icon with the 3 bars, there's the option to easily switch to wikitext (one-way only for now).
While adding a new section the section below disappeared. Even worth, undo did not work.
These problems occurred when I was using VE on zh.wp:
- When I create a new section and then start typing in the title of the section, the section header ate up the section below after I hit space to confirm the character I want. This makes it impossible to create new sections in VE on zh.wp (and I suspect, all other CJK language wikis).
- When I start typing at the end of a wikilink i.e. [[link]]*, VE adds the new text into the link i.e. equiv to [[link|link*]] and only ends the link if I add a spacebar. This is useful behaviour for European languages but makes VE nearly unusable in Chinese, Japanese and other languages where the ASCII spacebar isn't normally used in the middle of a sentence.
When I hit delete (on the keyboard) at the end of a paragraph, weird things happen.
Suppose I have:
A foobar B C foobar D E foobar F == foobarbaz == foobar
- When I hit delete at B, the paragraph break is removed correctly, but the cursor jumps to the beginning of the previous paragraph (A).
- When I hit delete at D, the paragraph break is also removed correctly, but the cursor jumps to or the right-hand side margin of the paragraph before that (to the right of B).
- Sometimes the paragraph break is removed, and the first letter of the next paragraph is moved to the beginning of the previous paragraph (can't figure out the conditions of this, only observed it once and can't replicate it).
- When I hit delete at F (just before a section header), the section header disappears... this might be the correct behaviour, but sadly hitting Ctrl+Z does not restore the section header.
This is an easy one - When setting the date at which an external web site was accessed, it is hard to know whether day precedes month (as it usually does in civilized regions of the English-speaking diaspora), or vice versa. SOLUTION: On the dialog box for editing, show the format as either YYYY/DD/MM or YYYY/MM/DD
Which template are you talking about? The text around the input box for each template is written on-wiki using TemplateData - it sounds like you want to tweak that?
/// moved from general Beta Features feedback
The warning about unsupported browsers only appears in the description of VisualEditor. This means that on wikis such as the Italian one, where you only have the description of Formulae among Beta Features, you are not warned that checking the box or not is not going to make a difference if your browser is not supported - since you won't get VE anyway. Writing this in IE so using my regular account, --Elitre (talk) 10:57, 1 December 2013 (UTC)
On the beta preferences page where the Visual Editor is enabled, the following text appears:
The following browsers are not supported:
- android < 3
- firefox <= 14
- opera < 12
It would be very helpful if each item linked to the respective Wikipedia pages for each browser (allowing more information about it, such as when the first supported version was released). Furthermore, it would look much more professional if the names were capitalized. Finally, the name "Internet Explorer" ought to be used in order to be consistent with the other unabbreviated browsers (also it is much more recognizable than "msie").
Add a link. Paste in URL. Save. Done. :-)
There's no distinction in VisualEditor between external and internal links, because why make one up?
Because now we get editors formatting external links as internal ones (which malfunctions), and vice versa? Yes, this happened in wikitext editing as well, but this was a good chance to fix this (or at least make the difference clearer. Why is the default (add a hyperlink, click the link icon, enter, enter) to add double brackets? It should be single brackets, or it looks all wrong in view mode. I don't really understand why you claim that there is no distinction between them...
You're totally right that that malfunction is a recent bug (specifically, bug 57416), and clearly shouldn't be happening - our apologies for that not being fixed yet.
However I disagree that, absent this bug, adding two separate link workflows which are indistinguishable to the user (and you'd better believe we'd have a request within days to magically transition between the two if needed). Our job is to make things simpler, not more complex. The whole point of VisualEditor is that the arbitrary mechanism by which you make a link, be it one, two or twenty square brackets, is invisible to the user. Rules that are yet more complex, like different kinds of link, are certainly not going to be exposed to the user unless there's a good reason for it, and I'm not aware of one right now.
I don't think that's Fram's complaint.
Fram appears to want this:
- Press Control-k to enter the link inspector
- Hit return twice
to result in
[http://example.com] in the file (which will look like  on the page)
rather than what it actually does, which is to put
http://example.com into the file (which will look like
http://example.com on the page).
At the moment, it does neither, it adds double square brackets. Single ones seem to be the most logical thing, with perhaps a default "link title" request, so that you get example.com as result.
I don't think we really want to encourage the creation of auto-numbered external links, so a link with target
http://example.com and anchor
http://example.com should turn into
http://example.com in wikitext which is equivalent to
[http://example.com http://example.com], rather that
If you have a good system that distinguishes between internal and external links and adds the number of brackets accordingly, then I see no reason why there should be two interfaces.
Unfortunately this software is still unavailable for the Modern skin. Seems like a not very large-volume task... IS there a bug number for it?
Since I haven't found any, and I am not sure this is coming, do you want me to file one for you? Regards,
It's been a long time since I've heard anything about this, but on the twin assumptions that my memory is correct and that nothing has changed since then here's the situation:
The Modern skin is not supported by the WMF and hasn't been for a long time. Any changes that need to be made to be compatible with VisualEditor (or anything else) will only happen if a volunteer dev chooses to do it. Unfortunately, Modern isn't that popular (so most volunteer devs won't care about it), and I've been told that it's a bigger task that it seems like it "should" be, so I'm not sure that it will happen any time soon, or ever.
If you wanted to speed this along, then your first step should probably be finding out who is maintaining Modern for other purposes, and asking one of them personally to look into it. If you search and can't find anyone maintaining that skin any longer, then please let me know.
Last edit: 16:49, 3 December 2013
I asked James about this, and you can find out more in this log from 14:46:51. The TL;DR is that support for Modern or other skins isn't planned (although volunteer developers can try their hand at this if they want to). Thanks.
- (This has previously been discussed in VisualEditor/Feedback/Archive/2013/05)
When I go to "Review and save", why can't I just tab from the edit comment textbox to the save page button? (But I can tab to the "minor edit" checkbox? And why isn't "save page" the default behaviour of hitting enter when "minor edit" is highlighted by tabbing?)
The save dialog is being completely re-written soon, and I believe that at least most of these concerns are already on the list.
Since I cracked my trackpad a few weeks ago, I'm even more than usually sympathetic to the desire to do everything from the keyboard.
It's great to see that we can finally edit templates on VE! I've got a comment about how to bring up the template-editing dialogue. The flag-like icon is often tucked away in an obscure position on the screen (and why is it a flag anyway?). My suggestion would be the double-clicking a template brings up the template-editing dialogue, to save people hunting around for the icon.
Template editing has been up for about five months now. It is definitely better than it was on its first days, but there is still some work to be done.
AFAICT, the icon is always at the far right-hand side of the screen. It's supposed to be a puzzle piece, which you may think is appropriate given how puzzling it can be. ;-)
The request for double-clicking is bug 50996, with a jargon-riddled title that most of us mere mortals can't make heads or tails of. ('Search' fortunately picks up the description, or I'd never have found it.) It has been generalized to double-clicking on anything, e.g., images as well as templates.
Since this request was filed by the head of the WMF's developers (and since of course I agree with you wholeheartedly), I was hoping that it would get a little extra attention, but so far, they seem scrupulously fair and even-handed in their request prioritization. :-p
mw:localisation gives strange results in VE. From the section "Messages that should not be translated" on, starting with the code text # do not translate or duplicate this message to other languages, it fails rather miserably. At first glance I would blame it on the starting # character in that sentence of code. Of course, that isn't a rare character in code, so VE should be able to handle it.
I'm not sure what "fails rather miserably" means. Do you mean "changes the font for the rest of the page, in exactly the way it ought to do when the <code> never gets properly closed"?
The line you mention has this for its wikicode:
* append a comment <code># do not translate or duplicate this message to other languages</tt> to the English translation
Those two tags are not interchangeable; you cannot close a <code> tag by providing a </tt>. If that's your only complaint, then you'll find that it looks much prettier now that I've manually corrected the wikitext error.
"fails rather miserably" means "can't edit it any further", which is the purpose of a visual Editor... And apparently in wikitext, you "can" close a code tag by providing a /tt, as that used to worked quite allright there... You perhaps shouldn't be doing it, and VisualEditor is more rigid, less flexible with these things than wikitext... Anyway, thanks for correcting it.
I can do minimal editing, i.e., removing whole paragraphs and adding new ones.
If you think it worthwhile, I can file a bug that says, "VisualEditor should provide bug-for-bug compatibility with MediaWiki, so that unpaired HTML elements involving the deprecated tt tag are treated as if they were properly paired anyway", but I'm thinking that's likely to get closed as a WONTFIX. What do you think? Is it worth reporting that VisualEditor works properly even when MediaWiki parsing plays fast and loose with the markup?
Worth reporting to our devs? Uh, no, obviously not. The chance of them allowing things that are procedurally incorrect but work anyway seems to be minimal. They aren't even inclined to allow things that work and are procedurally correct but don't fit their "worldview" (e.g. wikitext in VE), so adding a bug for this is pointless. Plus, considering that about one in six pages on enwiki renders incorrectly in VE but correctly in view mode (for a number of reasons, some perhaps similar to this one) and that those problems aren't even considered high priority (no, we first need to have VE in books and categories!), I don't think distracting the devs with this would be fruitful.
It says in the minutes of 27th March under things that won't work:
But will already existing tables (done through mediawiki syntax) be able to be edited in the release planned for 1st July? It seems to work fine in the test sandbox. This is something that would be very useful for us since we sometimes have large tables edited by several users. This work can be very tedious using wiki syntax.
Editing the contents of existing tables' cells will work, but you won't be able to alter the structure (add/remove columns/rows, merge cells, set background/etc. formatting).
How in any way is this acceptable? You're saying that an editor who wants to do anything with a table other than edit a cell has to switch to Vector to do so? At what point in the future do you think that Visual Editor will be able to edit everything related to a table - a few months after July 2013? A year or two? In the meantime, will you be recommending to new editors that they abstain from any more complicated table editing, or that they learn Vector as well as VisualEditor in order to have the full range of editing options?
I think that it's totally appropriate for projects that are primarily based on text, templates, images and references to have an editor which can do those well, rather than poorly with additional support for very complex tables that are currently outwith the capacity of editors familiar with wikitext, let alone newbies. The VisualEditor in no way makes it harder to edit a table than it currently is (quite the reverse). Yes, more progress would be nice, and so would a unicorn, but we have to work within reality.
We will focus on a table editor after the beta is launched, but I can't make up a date of it being ready at this stage as we aren't sure what facilities users will definitely need from such a tool (obviously add/remove row, column, cell; merge cells; mark cell(s) as 'header'/'footer'/'body'; add/remove caption - but there are other things that users might want to do as well, and I'm not going to declare it "done" when we've only hit those four functionalities.
Also, you mean "wikitext", not Vector, which is a skin. :-)
Sorry, apparently I misunderstood - the first production version (July?), not the beta (April/May?), will be able to do more than just edit existing cells in a table. That's fine.
Hello. I wanted to tell you that the engineering department is hosting additional office hours to discuss VisualEditor. The first will be held on Monday, 2 December, at 1900 UTC. The second will be held on Tuesday, 3 December, at 0100 UTC. Please join as Product Manager James Forrester discusses VisualEditor and upcoming plans. Logs will be posted on Meta after each office hour completes. (If office hours are heavily attended, it can be difficult to get to all questions, but if you want to ask a question and cannot attend or do not speak English, please let me know your question *at my talk page* by Dec 1st and I will present it among possible discussion topics.)
I disagree at the placement of 'media' in the more menu. Is this just temporary?
The current Wikitext editor I see as I type places embed file within the first 4 on the list and I think that kind of media priority would be good to continue in the Visual Editor. After all, it's a 'visual' editor.
If we want wiki pages to slowly become more media-rich (and I think they really need to in an appropriate way of course), then having the add media button more prominent will at least remind new editors to think. "Hey, Wikipedia wants appropriate images, is there one I can donate/upload/create to enhance this article while I'm here?" Anything else seems inconsistent with recent campaigns for commons uploads.
As it is, the media button in the 'more' dropdown seems to continue to make media a second class citizen. Just a little less important than Superscript??? Really?
As you guessed, the Menu layout is, like pretty much everything else at this stage, highly temporary :) While we want to make the toolbar simpler and shorter, we must also take a lot of other aspects into account: that's why your feedback on this matter would be highly appreciated at en:Wikipedia:VisualEditor/Feedback/Toolbar. Bug 38030 and related ones might interest you as well. Thanks.
I have some suggestions-complains about the VE. I guess some of this has been told by other users, but i can not review all of these comments.
- The Visual Editor takes to load, I guess that images could be to loaded with less resolution.
- Use the cancel button [X] as standard to close windows/boxes, trash can icon could be confusing.
- I guess the template editor is developing but, however, is meaningless to use the VE to avoid the source code characters (as [ ] < > ) only to encounter with it in the template editor. The template editor should work equally as the VE itself.
- Also, it should be a template gallery as the multimedia gallery.
- When you embed an image, you should to put the option to write the label by default. Basically all of the images in the Wikipedia have label, is absurd to have to edit the image later only to put a label. (But, if the image is embedded without a label, the image should not appear with a blank label by default, just in case).
- You should to put an image alignment button (left, center, right) in the menu bar.
- Menu bar should have two rows that include the rest of the options that were put in the "more" button. Anyone would not mind by that, I think.
- You should to put the text format buttons and the hyperlink/references buttons in a separate groups, Is more intuitive, I guess.
- Right now the references tool is so useless. I think this can be the ideal tool to standardize the style/format of the references. But what is the sense of push the references button an get a box that allows you only write plane text? The box should to show buttons in that you select the kind of source that you are quoting (book, magazine, web page, video, and so on) and to predetermine the fields to fill (title, author, year, etc). Also, the immense space below the text box could to show the used references in the article in a list and give the option to use the selected reference. That also would merge the references button with the list of references.
- And you can put an iside note tool. I mean, If I am working in an article and I find something in that I want to work later I should be able to put a mark with a note (as "review spelling").These notes should not be saved with the article, of course.
I have installed the latest Visual editor extension from GIT master on my local wiki. I get the new More group menu with four items Media, Reference, Reference List, Transclusion, but I cannot see the other new controls for underline, subscript etc. Am I not suppose to see them as I do on the mediawiki site?
Also it would be very nice if the editor buttons would be configurable in some way. I mean that you configure the ones you use the most to not be contained in a group/menu. For example we use strikethrough quite a lot which would be a bit difficult to reach on a menu. But I guess there will be keyboard shortcuts and that could be a solution too.
Exactly what I was thinking! Let's hope the manual will show the options soon!
I also want to know how to enable more tools. Anybody knows?
These are good ideas to make VE more configurable. We should look at options for this in the future. However, at present, developer time is being prioritized towards fixing known bugs, and implementing functionality improvements that the community has asked for, such as copy/paste, table support, reference dialog improvements, etc.
Daniel, as for your version lacking the new formatting options, I'm not sure why you're not getting them. Try re-installing the latest version? I'll ask around.
I'm trying to get visual editor to work in other namespaces. I want it to work in my custom namespace NS_PROJ in addition to main and this works fine by adding.
$wgVisualEditorNamespaces = NS_PROJ;
But then I also want the user namespace to be able to use visual editor there too.
I have tried:
$wgVisualEditorNamespaces = array ( NS_PROJ, NS_USER );
But it doesn't work...
How should this setting by set to get it to work?
- The constant is
$array = array( $val1, $val2 );does not do what you think, it adds a single element to
$array, containing another array of two values. What you want is either
$array = $val1; $array = $val2;or
array_push( $array, $val1, $val2 );
Seems to have a very big bug on fr.Wiki that could cause lots of damage. VERY FAST ACTION NEEDED
The VE or something else seems to add unwanted caracters with each edit (example). This could do a lot of damage and needs to be adressed fast. Thanks a lot.
It was Parsoid, and it was fixed. Thanks for letting us know about this.
What is the place to report those kinds of bugs for immediate action? In this event, hundreds of pages could have been damaged or even more depending on the moment of the day where the bug happens. Is there a "Emergency switch" somewhere at the local level (on each Wiki using the VE) or at a higher level that can be used to prevent corruption from bugs by disabeling the VE? During this event, all edits made with the VE were causing corruption problems. If this happens again, we need to be able to address the problem in a timeline that is seconds long or at least a couple of minutes long (as opposed to the 45 minutes to an hour that it took that time). Have a nice day.
IRC would be that place, either #mediawiki-parsoid or #mediawiki-visualeditor. It only took 10 minutes for Parsoid devs to know about this, and (AFAIK) there isn't a real emergency switch (well, devs will try to revert the broken deployment, but that can go wrong as well, unfortunately). I personally checked all the edits made during that time on fr.wp (and it.wp) and reverted those which were not noticed by patrollers, and my colleagues did the same for other wikis. We did that in the past, and will do it in the future if similar emergencies arise. Thanks.