VisualEditor/Feedback

From MediaWiki.org
Jump to: navigation, search
Share your feedback
Report bugs

Your feedback about the VisualEditor beta release

This page is a place for you to tell the Wikimedia developers what issues you encounter when using VisualEditor on Wikimedia projects. This page uses LiquidThreads, so you need to click "Start a new discussion" (not the ordinary "Edit" link) to post your message.

VisualEditor is still a beta version and has a number of known issues and missing features. We do welcome your feedback and ideas, especially on some of the user interface decisions we're making and the priorities for adding new functions.

Add a new commentView known bugsReport a new bug in BugzillaJoin the IRC channelTest VisualEditor! (no account required)

Archives generated by MiszaBot:
VisualEditor/Feedback/Archive/2011/12 VisualEditor/Feedback/Archive/2012/01 VisualEditor/Feedback/Archive/2012/02
VisualEditor/Feedback/Archive/2012/03 VisualEditor/Feedback/Archive/2012/04 VisualEditor/Feedback/Archive/2012/05
VisualEditor/Feedback/Archive/2012/06 VisualEditor/Feedback/Archive/2012/07 VisualEditor/Feedback/Archive/2012/10
VisualEditor/Feedback/Archive/2013/05
Start a new discussion
First page
First page
Previous page
Previous page
Last page
Last page

VE can't handle Template:Extension

Edited by another user.
Last edit: 19:31, 23 October 2014

If I roll over the {{Extension}} box on Extension:Campaigns I see a jigsaw icon which brings up a template editor, but it's blank.

S Page (WMF) (talk)01:21, 11 June 2013

When I click in that template I don't see any icon until I change the zoom from 100% to e.g. 90% or 110% (and if I keep the new zoom, click outside the template, and then click on the template again, the icon is not shown either - I need to change it again to see the icon, even changing it to 100% is enough).

On the other hand, if I go to https://www.mediawiki.org/wiki/Extension:Campaigns?debug=1 and click in the content from section "Installation" (generated by Template:ExtensionInstall), I get the following error in the console (on Google Chrome 27.0.1453.110): Uncaught Error: No focused node to edit (from ve.ui.MWTemplateDialog.js).

Helder12:36, 12 June 2013

Yeah, this is a pair of selection bugs we're working on; sorry about this. :-( Hope to get them fixed very soon.

Jdforrester (WMF) (talk)16:36, 12 June 2013
 
 

bug 49904 not on roadmap

Bug 49904 is not on the roadmap. To me, the lack of subst: support is often a blocker for me.

Martijn Hoekstra (talk)18:43, 8 August 2014

I think the right question there, is what is it in your workflow that requires subst ? And for what reasons is that subst'ing then being applied in this workflow ?

TheDJ (talk)17:44, 11 August 2014

Mostly speedy deletion patrol on en.wiki. I often replace speedy deletion requests with PRODs which must be subst:ed (for a reason I'm not 100% sure of). I'm not sure why this is the right question. Is subst:'ing templates deprecated or discouraged?

Martijn Hoekstra (talk)10:00, 14 August 2014

Because VE is not wikitext and subst is an extreme form of wikitext. If there is something you need, then the developers want to understand why you need it. In certain cases, an alternative solution might be sought.

For instance, I can imagine that in this case that they would reimplement some of the annotations for templates, or even for subst itself, to make sure that something like this just happens automatically. In other cases, perhaps an editor is just looking for 'action favorites' or something which. They are not trying to reimplement wikitext, they are building an editor that supports what you need to do and that is backwards compatible with wikitext syntax.

Looking specifically at PROD, it indeed seems to be implemented as a templated action for a set of templates, that insert current information (and thus need to be replaced).

TheDJ (talk)10:30, 14 August 2014

This line of reasoning still somewhat troubles me. I don't need much convinving that Wikitext is a heaping pile of terrible, or that this is difficult, and, frankly, just wrong. In my mental model a template substitution is similar to a macro application (and happens at "save-time"/"compile time") where a transclusion is similar to a function application (and happens at "display-time"/"run time"). In the VE model "display time" comes before "save time", while in the wikitext model the situation is reversed. I understand that brings challenges with it as the available context is different. I truely understand the brokenness of being able to detect during parsing (which happens at save time in case of template substitution) to detect if you're in a "save time" context or a "display time" context and adjust output accordingly. I feel your pain when I have to think about unsubst, and deciding at "save time" you're not going to do the substitution and just return the wikitext, including the brackets. This is all crap.

When I think about implementations I feel your pain even more; when following the wikitext model, this would mean that the content is substituted as soon as it is entered, but from a usability perspective this is terrible, as there is no way to go back and change the substitution afterwards if you just insert the VE model of the parsed template (if that is even possible, node fragments ftl) - parsed in "save time mode" - right into the VE model being edited. (While I acknowledge the terrible, I could live with this as a first stab at it by the way).

But template substitution is a fairly often used feature - and if it is used fairly often, there are valid use-cases for it. At an intellectual level I understand the desire to know why it is wanted, and what those use cases are, but the bottom line is that you can bet on it there are such use cases, even if you don't yet know them, and they'll just need to get implemented, no matter how much they suck on a technical level. It also means that knowing and understanding the use case won't influence the implementation.

I realise my earlier response was curt, and this response still has some irk in it. The reason for this is that - although I haven't edited much over the past months - I think I'm one of the few people on en.wp who tries to do everything with VE primarily, first of because it can be an amazing product (it is when it works, which is most of the time), and secondly because when I'm doing admin tasks I run across a larger part of the long tail of features than most other tasks, and I can provide the team with feedback on what is working for me and what isn't. A response that I interpreted as "well, we'll be the judge if we find the work you're doing now in wikitext valuable enough to carry over to VE", while at the same time aiming to ultimately completely replace wikitext (again, the latter is a good thing). For me, that doesn't really feel inviting to keep providing that feedback. I hope you can see this perspective as well.

Martijn Hoekstra (talk)09:16, 25 August 2014

I am not aware of an ultimate goal of replacing entirely wikitext with visual editing.

Nnemo (talk)14:16, 21 October 2014
 
 
 
 

User:Martijn Hoekstra, thanks for this note. This may be fixed this Thursday (appearing at the Wikipedias the following Thursday).

Whatamidoing (WMF) (talk)22:00, 18 August 2014

User:Martijn Hoekstra, subst'ing templates is working now.

While I'm happy to have you using VisualEditor (and telling me when you encounter problems!), have you considered using Twinkle for this work? It might save you a little time.

Whatamidoing (WMF) (talk)23:29, 2 September 2014

Thanks, that's great to hear! The problem with Twinkle for this is that I like to notify the tagger personally, and twinkle is a little peculiar with edit summaries when replacing CSD with PROD

Martijn Hoekstra (talk)16:24, 3 September 2014
 
 
 

Adding a link to an image caption

I seem to be unable to easily add a wikilink to an image caption using VisualEditor. When I open the "Media settings" window to edit the caption, I can click the "Link" button to add a link, but then the program doesn't seem to think I've actually made any changes to the caption, because it won't let me click the "Apply changes" button. Am I doing something wrong, or is this a bug?

Mr. Granger (talk)18:55, 11 October 2014

User:Mr. Granger, what's your OS and web browser? Is this still a problem today? (There's been a software update since your message was posted.)

Whatamidoing (WMF) (talk)00:21, 17 October 2014

Yep, it's still happening. I'm using Mac OS X 10.9.5, and the problem occurs in both Firefox and Safari.

Mr. Granger (talk)01:18, 17 October 2014

User:Mr. Granger, thank you. This is now tracked as bug 71065. It's on the list for the next round of work, and it's assigned to Moriel, who is awesome, so I think you can expect that to get fixed soon (plus the usual two weeks for new code to reach the Wikipedias).

In the meantime, it appears that the temporary workaround is to make some other change in the caption.

Whatamidoing (WMF) (talk)17:37, 23 October 2014
 
 
 

Cancel button

Hello, I'm experienced wikipedian. But when I tried VE last time I couldn't find some Cancel (editing) button. I think it's very important because of average internet users. Not everybody knows it could be canceled by clicking to Article link. Reloading is useless. So some people could be pushed to saving it.

Dominikmatus (talk)16:54, 13 October 2014

Well, also if you use wikitext editor, there is no cancel button. I don't think that it's needed. Users can just click the "article tab" or alternatively click the cancel button in the browser.

Stryn (talk)19:08, 14 October 2014

Yes there is. There's even one on this edit window right now. There is no cancel button in the browser. That doesn't even make sense, how would the browser know what "cancel" means in this context?

101.160.157.7103:04, 15 October 2014

Not a "button" though. Anyway, in August User:Jdforrester (WMF) commented on Bugzilla, "We just removed the Cancel button because user testing showed that it wasn't helpful. Any link out of the editor leaves the editor…"

Elitre (WMF) (talk)10:58, 15 October 2014

The technicality of if it is a "button" or link is irrelevant to the user. Clicking it does a thing either-way. And quiet buttons (which the VE one was) look identical to links.

121.214.105.20004:27, 16 October 2014
 

In what way is a cancel button "not helpful"? Is it deemed to be harmful in some way? I understand that it is not necessary, but that can be difficult for a new user to grasp. It is not self-evident that navigating away from the page is the way to cancel the edit, and besides, that seems to me like crashing out of a program to stop it - a bit of a kludge, not very clean, and counter-intuitive.

SpinningSpark23:47, 16 October 2014

Apparently nobody actually used it (except me, because I cancel a lot of sandbox edits when I'm sorting out bug reports). Also, I think it was removed several weeks before anyone said anything about it. It's been gone for a couple of months, and this is only the second or third time anyone's mentioned it (except me).

Whatamidoing (WMF) (talk)00:14, 17 October 2014
 
 
 
 
 

Extreme lag in updating link suggestions

New articles seem to take forever to get on the suggested links list. I created an article last night and it is still redlinked in the suggestion list now, 6 or seven hours later

SpinningSpark08:56, 22 October 2014

VisualEditor can only supply what (old) Search gives it (at en.wp).

Whatamidoing (WMF) (talk)16:20, 23 October 2014
 

Special characters

Here's another thread about the special character inserter; the other one has gotten kind of long. Some questions to consider:

  • Do you normally use a character inserter? The one in your computer, or the one in the Wikipedia/MediaWiki editor?
  • Which character sets are useful to you? Should it include all 18 of the character sets provided in the wikitext editor's newer toolbar at the English Wikipedia, the 10 present in the older editor toolbar, or some other combination of character sets?
  • How many special characters would you like to see at one time?
    • Should there be a "priority" or "favorites" section for the 10 or 12 characters that most editors need most often? Is it okay if you need an extra click to go beyond the limited priority set?
    • How should the sections be split up? Should they be nested? Ordered?
    • How should the sections be navigated? Should there be a drop-down? A nested menu?
  • The wikitext editor has never included many symbols and characters, like ℗ and ♀. Do you find that you need these missing characters? If the character inserter in VisualEditor includes hundreds or thousands of special characters, will it be overwhelming? How will you find the character you want? What should be done for users without enough space to display more than a few dozen characters?
  • Should the character inserter be statically available until dismissed? Should it hover near the mouse? Should it go away on every selection or 10 seconds after a selection with no subsequent ones?
  • Some people believe that the toolbar already has too many options—how would you simplify it?
Whatamidoing (WMF) (talk)00:00, 18 February 2014
  • Change the "<" to an "X" - I would change the current "<" button to an "X" and move it to the top right. The "<" doesn't make sense as it's not inherently attached to any sidebar, so the arrow points at nothing in particular. This is also a problem I have with the Gallery dialog.
  • Moving the dialog like a window - The dialog should be movable by the user as though it was a separate window (e.g. grab the header and drag it elsewhere in the browser.), rather than attached to the location of your cursor in the edit window.
    • To add on to this, I think all of the Insert dialogs should have this functionality, I oftentimes want to look at the picture I'm captioning in the gallery or the text which is located nearby it. However, I can't do this without closing the dialog and then opening it back up again.
  • The dialog is too vertically lengthy - Limit the height of the dialog box vertically and add a scroll bar. The entire box should be visible when it's first opened. Currently, the bar is very long and can go all the way to the bottom of the article in some cases.
  • Change the sections into tabs - It shouldn't look like Wikipedia's section headers, it should be a tabbed interface a la a browser. This would also help with the aforementioned height of the dialog.
  • Add a search bar to the dialog - I'm not sure how this would be done from a technological perspective, but I would assume it's possible to add "tags" of some sort to each symbol. For example, á and other variations of "a" or "A" with accents would be tagged with "A". This way, you can search for a letter (e.g. "a", "c", "e", "i", etc.) and it will bring up all variations of that letter. For symbols with actual titles, like the tilde (~), these would be tagged with their actual name. The tags wouldn't be visible to the user, they'd simply allow symbols to be searched more easily. This would be especially useful if a large amount of symbols were added to the dialog.
  • Organize the buttons into a proper, aligned grid - Currently, the horizontal width of each button containing a symbol differs greatly. This makes it a lot harder to search through, as your eye randomly skims through the unorganized list of symbols. Preferably, every symbol would be contained inside a button with the same horizontal size, all lined up similarly for ease of navigation for editors.

Hopefully these are helpful, I look forward to future progress!

Nicereddy (talk)01:09, 18 February 2014

Thanks for this, it's really helpful – some replies.

Change the "<" to an "X"

As you say, this is a consistent design for all inspectors; I agree that it's worth looking at this again.

Moving the dialog like a window

This is quite a lot of work (and yes, if we wrote this functionality it would also be something we build for all inspectors and dialogs). Would this be more valuable than (say) TheDJ's suggestion of it appearing as a hovering block at the bottom of the window (in the same way but the opposite end of the view to the toolbar)?

The dialog is too vertically lengthy

We can very easily make it only sized to the window (maybe with a minimum height, like we do for dialogs). Should the page scroll down so that you get to see enough of the dialog, too? Right now we don't do this for inspectors, but it might make them a bit easier to use when your cursor is at the bottom of the page.

Change the sections into tabs

The problem here is that the sections are defined by local communities; what would we do if there were 10 sections? 20? 50?

Add a search bar to the dialog

This could turn what should be a quite simple and quick to use interface into something that's very "heavy", and I think it'd only be useful for a minority of characters, and only to some users who already know that they're looking for an "a"-related character (for example, would you expect "α", "א", "æ" and "ɐ" to show up when you typed in "a"?). Would it be better if we had some way of organising the characters so that all the As were clustered together in each section, like was suggested here?

Organize the buttons into a proper, aligned grid

This could be very helpful, yes – I'd note that the WikiEditor's special character panel uses this approach, to its credit. Do you think that we should hard-code a maximum width and show buttons with labels centred regardless of their actual width, or should the width of the buttons on screen alter as the widest character currently shown gets wider or narrower? I think the first option is probably better, but it's not a great choice to need to make. Note that users' browsers/system/font selection (amongst other issues) can make it unpredictable how wide this will be (and indeed which character is widest), which may be a little confusing.

Jdforrester (WMF) (talk)22:03, 21 February 2014

Thanks for replying!

Would this be more valuable than (say) TheDJ's suggestion of it appearing as a hovering block at the bottom of the window

I would definitely prefer the hovering block to its current state, especially if it had a minimize feature that saved its contents but kept it in a "dock"-esque footer-bar. Though, generally I do believe the ability to control it myself would be preferable over having it locked in anywhere, but if it's too much work that's perfectly understandable.

Should the page scroll down so that you get to see enough of the dialog, too?

I don't think it should. Most users probably wouldn't want the editor to move their viewing space without consent or warning, and this would probably make for a bad user experience.

I believe you're referring to the fact that if the user were to be selecting text in (for example) the bottom 200 pixels of the screen, the inspector wouldn't have enough room to open and part of it would be cut off? If I'm misunderstanding please correct me, but the "right-click" dialog already handles this problem quite well. When you right-click near the top of the screen the menu opens downward, but if you right-click near the bottom it opens upwards in order to fit itself into the given area. Making it dynamically able to open above/below the cursor would likely be preferable. Of course, the dock functionality mentioned above would fix this if implemented, and make this issue essentially irrelevant.

what would we do if there were 10 sections? 20? 50?

This kind of contradicts your next point (with regards to the search box) about it being a quick-to-use dialog. If it's capable of reaching 20+ sections, there's probably something wrong with the dialog or its purpose. That would mean hundreds of potential choices in the dialog and there's no good way of organizing that (without a search box ;) ). Currently, it's so large it's cumbersome to look through and my eyes don't scan through it in any real order because it's so condensed. These problems may be fixed by the improved grid but, assuming they aren't, perhaps we could settle at both tabs and sections? Max it to a reasonable number of tabs, e.g. 6, and then allow sections to serve as subheaders for each tab.

Either way, I think collapsible sections will be necessary if you want the dialog to be reasonably usable.

This could turn what should be a quite simple and quick to use interface into something that's very "heavy", and I think it'd only be useful for a minority of characters, and only to some users who already know that they're looking for an "a"-related character (for example, would you expect "α", "א", "æ" and "ɐ" to show up when you typed in "a"?).

With regards to its simplicity and speed, I think this would make it more complicated at the back-end, but the user-facing interface would be much quicker and easier to find exactly what you're looking for. The simplicity may be complicated a bit by a search bar, but we're talking about a huge, difficult-to-organize list of characters. I wouldn't imagine most users would immediately think "simple" upon viewing it.

And while I can understand that users may not understand the features of the search bar immediately, a simple tutorial or note would make it evident and understandable reasonably quickly.

Would it be better if we had some way of organizing the characters so that all the As were clustered together in each section

This would definitely be a good way of organizing it, but again I feel like everything would just be smoother with the Search dialog.

Do you think that we should hard-code a maximum width and show buttons with labels centred regardless of their actual width

I think the approach which uses a maximum size for each panel in the grid is preferable, especially since issues could come up if there was, for whatever reason, a character which was especially long or tall. That character would cause all of the buttons to become that same size and create a really odd-looking interface, especially if the buttons weren't squares.

Note that users' browsers/system/font selection (amongst other issues) can make it unpredictable how wide this will be (and indeed which character is widest), which may be a little confusing.

I may be completely wrong here, but is it not possible to override the user's font selection for this specific dialog? That way all users would see the same size/type of font in the Special Characters window? Obviously not the best way of solving the issue, assuming it's even possible, but its the only I could think of.

Cheers,

Nicereddy (talk)06:24, 23 February 2014
 
 
Edited by another user.
Last edit: 15:52, 11 September 2014

Do you normally use a character inserter? The one in your computer, or the one in the Wikipedia/MediaWiki editor?

Yep. I'd normally use Extension:CharInsert gadget first as its most convenient, I like the way it has a <select> drop down as I can quickly go to the set of chars I want and does not take much screen space. I find then the wikitext character inserter has a bit too much scrolling involved and is greedy in screen space. If neither of the two has the character i want I'll use my Mac's Character Viewer, I've done some work on the unicode pages and sometimes need exotic symbols.

Which character sets are useful to you? Should it include all 18 of the character sets provided in the wikitext editor's newer toolbar at the English Wikipedia, the 10 present in the older editor toolbar, or some other combination of character sets?

I tend to use the maths symbols and greek letters. For maths articles I need a more extensive range of maths symbols than is provided by VE. The set provided by CharInsert has most things I'm likely to use: − × ÷ ⋅ ° ∗ ∘ ± ∓ ≤ ≥ ≠ ≡ ≅ ≜ ≝ ≐ ≃ ≈ ⊕ ⊗ ⇐ ⇔ ⇒ ∞ ← ↔ → ≪ ≫ ∝ √ ∤ ≀ ◅ ▻ ⋉ ⋊ ⋈ ∴ ∵ ↦ ¬ ∧ ∨ ⊻ ∀ ∃ ∈ ∉ ∋ ⊆ ⊈ ⊊ ⊂ ⊄ ⊇ ⊉ ⊋ ⊃ ⊅ ∪ ∩ ∑ ∏ ∐ ′ ∫ ∬ ∭ ∮ ∇ ∂ ∆ ∅ ℂ ℍ ℕ ℙ ℚ ℝ ℤ ℵ ⌊ ⌋ ⌈ ⌉ ⊤ ⊥ ⊢ ⊣ ⊧ □ ∠ ⟨ ⟩ {{frac}} &nbsp; &minus; <math></math> {{math}}. I need all the upper and lower case greek letters. I normally only edit in English so fancy accent characters are of little use to me.

How should the sections be navigated? Should there be a drop-down? A nested menu?

The way Extension:CharInsert works on en wikipedia is about ideal,

Extension-CharInsert.png

A simple drop-down and a set of characters, a minimum of styling, surrounding boxes or buttons are just distractions. This gives a high density of characters using minimal screen space.

How many special characters would you like to see at one time?

Lots, probably 70 at a time, I need all upper and lower case greek letters. Not bothered by accents on them.

Should there be a "priority" or "favorites" section for the 10 or 12 characters.

Possibly, would I need to set this up?

The wikitext editor has never included many symbols and characters, like ℗ and ♀. Do you find that you need these missing characters?

Sometimes, if it very exotic I may use the unicode escape sequence &#x24C5; to give Ⓟ
Different users are likely to want very different ranges of characters, how about making it possible to add a particular unicode block to the set of possible sets. Say for example I want to add a page about a Russian mathematician like [[en:Vladimir Arnold]]. Then I want to add Cyrillic script. Even on en.wikipedia I guess some users will want most scripts for adding native names.
Salix alba (talk)08:07, 18 February 2014

Thanks! Some replies and queries in-line:

I find then the wikitext character inserter has a bit too much scrolling involved and is greedy in screen space.

Yeah, this was something we were particularly keen to avoid repeating, though I feel we've yet to find a design that is better and yet meets the other requirements.

Should there be a "priority" or "favorites" section for the 10 or 12 characters.
Possibly, would I need to set this up?

I was imagining a "commonly-used" section that the tool defaults to displaying, rather than a per-user set of favourites (though if there's demand for it we could do the latter too, at some point).

Sometimes, if it very exotic I may use the unicode escape sequence Ⓟ to give Ⓟ

Unicode currently has over 100,000 characters defined; I think trying to have a tool that displays even "most" of them is probably unnecessary. Maybe an advanced button that can insert a character by Unicode code (so, in your case, you'd enter "24C5")?

Jdforrester (WMF) (talk)22:12, 21 February 2014
I was imagining a "commonly-used" section that the tool defaults to displaying, rather than a per-user set of favourites (though if there's demand for it we could do the latter too, at some point).

I would think most editors will request a personalized favorites section, as different editors may prioritize specific characters over others. An editor who primarily edits pages about math would likely want different "favorites" than someone interested in famous Spaniards or Russians.

Nicereddy (talk)06:27, 23 February 2014
 
 
  • The most basic set é ü etc i do straight from the keyboard.
  • The more complex but oft used chars, I do from MediaWiki:Edittools (JS version of en.wp)
  • I NEVER use the Special characters drop down in WikiEditor. (I think we should do some analytics gathering on that usage there btw)
  • Since Mac OS 10.9 I use the OS version, because: It has a helpful keyboard shortcut that works OS wide now. Very nice categories, search and variants.
  • Ideally, it should have like 6 categories of chars that you might often use on that wiki and ability to lookup and add other categories to your profile.
  • Per category I would expect max 25 chars, multiline
  • I would expect a fixed positioned footer (in view, consistently accessible, but out of the way) or a dock able floating panel or something the like.
  • I would expect it to be available until dismissed. Auto disappearing is nice in theory, but dismissing after 2 secs is too quick for multiple actions and dismissing after 10 secs would probably be too 'unexpected' for users.
TheDJ (talk)10:47, 20 February 2014

Thanks.

I NEVER use the Special characters drop down in WikiEditor.

We've heard that from a number of people, which confirms our suspicions that EditTools (which was meant to be switched off when the WikiEditor special character inserter was rolled out, but never got axed) serves the needs of most users, particularly in terms of quick-and-easy UX.

(I think we should do some analytics gathering on that usage there btw)

Hmm, yeah; patches welcome. ;-)

Since Mac OS 10.9 I use the OS version, because: It has a helpful keyboard shortcut that works OS wide now. Very nice categories, search and variants. … Ideally, it should have like 6 categories of chars that you might often use on that wiki and ability to lookup and add other categories to your profile. … Per category I would expect max 25 chars, multiline

Mac OS X's native character inserter has 11 top-level categories, and yet misses a bunch of characters insertable in WikiEditor – IPA, Cyrillic, Arabic, Hebrew, … – and the "arrows" category has (at rough count) 300 characters alone. I don't think we'd want all of these, but drawing the line at 25 might be hard. :-) There are 20 variants of "A" in the Latin group, and another 27 of "A" in the Latin extended group, for example.

I would expect a fixed positioned footer (in view, consistently accessible, but out of the way) or a dock able floating panel or something the like. I would expect it to be available until dismissed. Auto disappearing is nice in theory, but dismissing after 2 secs is too quick for multiple actions and dismissing after 10 secs would probably be too 'unexpected' for users.

Perhaps a pop-out panel that disappears on each use, or can dock down to the bottom of the page to be persistent?

Jdforrester (WMF) (talk)02:16, 22 February 2014

disappearing after each use, prevents you from inserting multiple characters in sequence (not that i personally use that feature, but some folks do)

TheDJ (talk)02:55, 25 February 2014
 

James, you need to play more with the character palette of Mac OS X.

In my Mac OS X character palette, I have dozens of top-level categories of characters. One of them is phonetic alphabet, there are also cyrillic, arabic, hebrew…

Nnemo (talk)15:54, 1 June 2014

Perhaps I need to upgrade to the latest OS. I've been unable to find these characters in the character palette (which are combinations; all the pieces are there, but not the assembled units):

k̚ t̪ d̪ s̺ s̻ θ̼ s̬ n̥ ŋ̊ a̤ a̰ β̞ r̝ e̘ e̙ u̟ i̠ ɪ̈ e̽ ɔ̹ ɔ̜ n̩ ə̆ ə̯ ə̃ ȷ̃ z̴ ə̋ ə́ ə̄ ə̀ ə̏ ə̌ ə̂ ə᷄ ə᷅ ə᷇ ə᷆ ə᷈ ə᷉ t͡ʃ d͡ʒ t͜ɬ k͈ s͎


and I have only ten top-level palettes: Arrows, Parentheses, Punctuation, Currency Symbols, Pictographs, Bullets/Stars, Math Symbols, Letterlike Symbols, Emoji, and Latin.

Whatamidoing (WMF) (talk)17:59, 2 June 2014

…Or you need to play with the System Prefs. Even on my good old Snow Leopard, I have many exotic categories in my Character Palette.

Nnemo (talk)15:11, 5 June 2014
 
 

There is a keyboard equivalent for the Character Palette of Mac OS X now ? What is it ? I am egoistically interested. :-)

Nnemo (talk)16:15, 21 October 2014

Nnemo, If I'm thinking of the right thing, it's only for common Latin letters. Press and hold the letter 'a' for about two seconds, and see if a little menu with eight variations on 'a' appears. It only seems to work on "common" letters. I get nothing by holding down 'k', for example.

It works in 10.8, but I don't know if it works in 10.6 or 10.7.

Whatamidoing (WMF) (talk)22:04, 21 October 2014

Ah if it's this feature, I know it. I turned it off because I prefer the repeatttttttttttt (there is a trick to turn the feature off). This feature came after Mac OS X 10.6, it is one of those imports from iOS. Thank you anyway, but James seems to be speaking about something else.

Nnemo (talk)13:50, 23 October 2014
 
 
 
 

you should do this in categories, like all types of a=á,å,â,... similar for phonetics etc. and include keyboard shortcuts, so when a is pressed in editor all sounds and forms of a are present. for math simbols you could include short words that indicate symbols like 3(Dot)5 or something like LaTeX or similar. I don't think the tool would be very useful otherwise, because it takes way too much time looking for characters.

93.103.171.2916:56, 20 February 2014

Thanks. I was not referring to character input though, it was a more general question of how to extend the functionality of the VisualEditor. In my specific case this would be a custom popup dialog (action: dialog) that inserts a link to a picture recently uploaded by the editing user.

Simulo (talk)09:54, 21 February 2014
I was not referring to character input though, it was a more general question

I think the user was responding to the general request for input on the character input tool, rather than your question, and just responded on the wrong thread; I've moved it here instead.

In my specific case this would be a custom popup dialog (action: dialog) that inserts a link to a picture recently uploaded by the editing user.

Interesting! It was suggested in bug 60398 that we do this in VisualEditor itself, and there's a work in progress commit to do this which you might be interested in.

Jdforrester (WMF) (talk)02:22, 22 February 2014
 
 

Thank you for inviting me here. Indeed the tool "special characters" is very important. I am very content, how it works with the conventional source editor (as I admire wikipedia technology in general, just to let you know that criticism here is on a very high level), but the tool in the beta editor, as it is now, is useless for me.

1) The box should not be fixed within the text (better with the toolbar), otherwise I have to open and to close it again. I just opened it and then the box was hiding the word, which I wanted to correct.

2) The design is nice, but it has not the characters I need (even for IPA this is not enough, not even for the vowels, and where are the consonants and semivowels?).

3) If I tell you precisely which characters I need, you will never satisfy the users. Users should choose between different languages, let's say between Cyrillic or even Glagolitic for those who work with Slavic sources, and polytonic Greek, or phonetic alphabet. The current choice for everybody is not useful, because the Latin alphabet does not often need diacritics. You need some for Spanish, others for Slavic languages who do not longer use Cyrillic (Polish needs ł,Ł,ą,ę,ó,ś,ń,ź,ć, and ż; Czech Š,š,Č,č,Ž,ž etc.), while other would like transcribe the Arabic or Persian alphabet. I advice to compose certain choices which are adapt to different user profiles. Please don't hesitate to ask questions.

Platonykiss (talk)19:08, 6 March 2014

Platonykiss, thanks for your thoughts. Real use cases are what James is looking for, so "I need ALL the characters!" or "I don't need any of them" are both useful information for him :) This said, wikis can already change those sets locally in the meantime if they urgently need something that is missing.

Elitre (WMF) (talk)13:23, 11 March 2014
 

“the Latin alphabet does not often need diacritics”

Platonykiss, I bet that you are not a native francophone.

Nnemo (talk)16:00, 1 June 2014

Though I am regularly in France, I am not a fan of the French keyboard. I do not need it to have all characters I need to write in this language, or to say it in a way useful for you, I do not need your tool at all to write in those languages. This is probably not an anglophone perspective to it, I suppose... ;D

Platonykiss (talk)11:00, 17 August 2014
 
 
 

VE help menu in ruWP

In ruWP use page "report an error in the article". VE panel has a menu "help" (?) -> Leave feedback. Anonymous user often confused and leave error message on the page "Leave feedback". Whether it is possible locally in ruWP add a new menu item "(?) -> report an error in the article" under the item "(?) -> Leave feedback about VE"?

Sunpriat (talk)13:48, 22 October 2014

Why has Ctrl-V suddenly stopped working?

Why have Ctrl-X and Ctrl-V suddenly stopped working? It was working fine earlier tonight. I've tried two different PCs with two different operating systems both logged in and logged out so I'm pretty sure its not me at fault. Browser=FF32.

SpinningSpark23:40, 16 October 2014

It's happening for me, too, so it's not just you.

This is now tracked as bugzilla:72164. Thanks for the report.

Whatamidoing (WMF) (talk)00:06, 17 October 2014

Any chance of a heads up on how this has happened? The current VE version is dated 9 October, that is, it apparently hasn't changed since this bug materialised. There would seem to be something seriously wrong with VE version control.

It is extremely inconvenient. I use these keys all the time. Apparently, this same bug can cause random bits of the article to end up deleted so it needs fixing as a matter of urgency.

SpinningSpark20:39, 19 October 2014
 

Hi, Ctrl+V is do not work in Visual editor in my firefox, explorer, chrome. Do not work drag and drop.

I.Sáček, senior (talk)10:58, 19 October 2014

User:I.Sáček, senior and User:SpinningSpark, this is supposed to be fixed now. Please check and let me know if it's working for you.

Whatamidoing (WMF) (talk)21:40, 21 October 2014

Quick check, it's not working in either monobook or vector. Am I supposed to restart my browser or something?

SpinningSpark22:34, 21 October 2014

The version is still showing as 9 October so presumably nothing has changed (unless this is more poor version control). I would copy-paste the full version info, but not even select is working in the help window, let alone copy-paste - not very useful.

SpinningSpark22:39, 21 October 2014
 
 
 
 

Can't desactivate the VisualEditor

Hello, I come from the Spanish Wikipedia, and I do not really like the function of the visual editor, sometimes I'm wrong and when I pressed the button to press to edit code.

I tried to turn it off through preferences but not disabled and if I try to disable other beta function is deactivated correctly

as I can disable it?

And sorry for my bad English, I'm using google translator.

Feefre (talk)21:31, 31 May 2014

Hello User:Feefre. All you need to do is removing the flag near "Editor visual" here, then click on the Guardar button. After this, you'll only see one Editar tab which provides access to the wikicode editor. If this still doesn't work for you, please let us know which browser, skin and operating system you're using. Thank you.

Elitre (WMF) (talk)15:46, 2 June 2014

I've the same. I use Win 7 x64. This is because the option "Automatisch alle neuen Beta-Funktionen aktivieren" - "Automatic all Beta-features activated" is on. This is a bug.

Perhelion (talk)09:13, 7 June 2014

This is not a bug; it is acting as intended. The checkbox you have chosen causes all Beta Features, including VisualEditor, to be enabled for you every time you check your preferences. If you don't want all Beta Features to be loaded, uncheck this box.

Jdforrester (WMF) (talk)20:45, 9 June 2014

This box being enabled by default may be considered a bug. I consider that enabling beta features by default is a bug.

Nnemo (talk)16:26, 21 October 2014

It isn't checked by default.

Elitre (WMF) (talk)16:29, 21 October 2014
 
 
 
 
 

Clearing formatting and links

This is a general question for anyone who wants to share an opinion:

The "Style text" (character formatting) menu in VisualEditor has options like bold and italics. At the end of the menu, there is "Clear formatting", which removes bold, italics, etc., and also removes any [[link]]s. This is consistent with what some web-based software does (like Gmail). Do you think this is a good approach, or would you rather have "clear formatting" retain any links to other pages/other websites?

Whatamidoing (WMF) (talk)04:51, 25 June 2014

I did not know that links were formatting. ;-) In my opinion, indeed this is inconsistent, and "Clear formatting" must keep links.

Nnemo (talk)14:31, 21 October 2014
 

inserts "nowiki", why?

The VisualEditor inserts "nowiki" into text at meaningless places, where it is unnecessary. Please correct this.

Misibacsi (talk)20:51, 9 August 2014

Hi there, can you please provide examples? There might be several different reasons for that, including user's mistake (ignoring wikitext warning, for example). Thanks,

Elitre (WMF) (talk)21:43, 9 August 2014

What examples do you want? Don't you believe it?

Misibacsi (talk)20:22, 26 August 2014

This is not about believe, it is about being able to reproduced, leading to a determination of cause, which is a requirement for fixing.


You call a mechanic because your car is broken. You tell him: "My car is broken". The mechanic says: "Bring it over". You: "you don't believe it ?" :)

TheDJ (Not WMF) (talkcontribs)21:51, 26 August 2014

OK, check these: https://hu.wikipedia.org/w/index.php?title=Budapesthez_kapcsol%C3%B3d%C3%B3_filmek_list%C3%A1ja&diff=15059584&oldid=15059344 and look for "nowiki" on the right side

https://hu.wikipedia.org/w/index.php?title=Hinduizmus&diff=prev&oldid=14841836

Take note: "Címke: VisualEditor" on the right side

https://hu.wikipedia.org/w/index.php?title=Jenolan-barlangrendszer&diff=prev&oldid=15040431 Take note: "Címke: VisualEditor" on the right side

https://hu.wikipedia.org/w/index.php?title=Dagerrot%C3%ADpia&diff=next&oldid=14961778 "nowiki" on the left side

https://hu.wikipedia.org/w/index.php?title=Szud%C3%A1n&diff=prev&oldid=14953802 on the right side

Misibacsi (talk)14:59, 29 August 2014

It is slightly different than bugzilla:66210 (which has to do about starting the line with characters that have formatting meaning in wikitext)

These however are all examples of the linktrail problem. Basically it means the user selected part of a word to make that a link, and not the other part. This is not 'normal' within the our world, but apparently something that people do. It's very difficult for Editor software to guess, if the user intended to link the entire word, or not. So it serializes it the way that the editor defined it in HTML, with part of the word outside of the link. The only way to represent a link that has an unlinked trail, is by adding a in between the two parts.

This is bugzilla:37939, it's not really a bug, it's just annoying and would be good if we can find an unobtrusive way to tell VE users not to do that. But influencing people's behavior, without pissing them off can be a bit tough, so it will take a while to figure this out.

TheDJ (Not WMF) (talkcontribs)13:58, 30 August 2014
 

"But I cannot bring my car over, it is broken !"

Nnemo (talk)13:50, 21 October 2014
 
 
 
 

Spurious edits to references and removal of "recommended" template

This diff (for "Tove Jansson" in the Swedish Wikipedia) illustrates a simple edit with Visual Editor gone horribly wrong. The only changes I consciously made were to correct the spelling of "Tuulikki" which was wrong in a few places. But the diff shows (1) the removal of two words and addition of a "clarify" link (line 89); (2) the removal of two references (lines 247 and 260); (3) changes within a reference (publisher, location, and ISBN) (line 279 in the new version); (4) change in a link (line 303); (5) ISBN of same (line 303); and finally (6) the removal of the "recommended" template (line 324). Several of these look like correct edits, but how did they creep in here? Several others are definitely wrong (can't make sense of the ISBN changes, for example).

Eeera (talk)05:07, 20 October 2014

I copied the whole article to my sandbox and tried to edit it, and the result is just fine. My guess is that without noticing (maybe a cache issue?) you edited an old version of the page (could be early September), thus "reverting" the article partly to an older version. User:Jdforrester (WMF) will tell us more.

Elitre (WMF) (talk)08:28, 20 October 2014
 

Chinese Wikipedia lead section editing

When the "edit" button of the lead section is clicked, instead of directing to the "section 0" VisualEditor page, it is directed to "section 1" instead. I understand that whichever edit button (whether it is "section edit" or "entire page edit") you click, you can still edit any part of the article.

However, the edit summary is default to /* Name of first section */ following edits after the lead section (i.e. section 0) edit button is clicked. Is there any ways to solve?

Also, I see that most of the Chinese instructions in VisualEditor are incorrectly translated/need to be copyedited. Are all users allowed to change user interface of local VisualEditor?

HYH.124 (talk)09:58, 13 October 2014

Hello, User:HYH.124.

  • The edit link for the lead section is a local gadget. It should be corrected to match the behavior of the one at the English Wikipedia. They recently found and fixed this problem at en.wp.
  • Translations are done both locally and non-locally, and the answer depends on which thing exactly you want to change. If you can give me an example (or a screenshot with the problem circled), then I can help you figure out what would be most useful. We are always interested in finding good translators!
Whatamidoing (WMF) (talk)00:19, 17 October 2014
 

Handling <pre><ref></pre> with trailing slash does not work correctly

Hi VE team!

On Polish Wiki we often use "Przypisy-lista" or "Przypisy" templates that work almost the same way to "reflist" template on English Wikipedia. A lot of our users (including me) group their source references in the bottom part of the article, inside the reflist-like template and refer to them using

<ref name="MyFavouriteBook" />

(with trailing slash) in the "body" of the article and "register" them fully using Cite web and similar templates. If I click in Visual Editor on such a reference, no information from the related reference appears, although full citation template is used in the reflist and the field translated as "Use existing reference" is grayed out. It is very misleading and prevents the users from adding another reference or even checking existing one when in edit mote. As coverage with sources is a critical issue on all Wikipedia projects, I'd like to see improvements in this area. Note: "Odn" template (reference to a book in Bibliography section) works well. Standard

<ref>

fails.

Examples:

Bonvol (talk)20:05, 14 October 2014

I'm sorry that you have encountered this problem.

These are list-defined references that have been wrapped in a template. List-defined references do not work now, but probably will in the future (2015?). References contained in any template are effectively hidden from VisualEditor. I do not know if this problem is solvable.

Whatamidoing (WMF) (talk)00:11, 17 October 2014
 

How can i get the VisualEditor extension for my companie's knoledge based system, which are based on MediaWiki?

How can i get the VisualEditor extension for my companie's knoledge based system, which are based on MediaWiki?

95.131.179.21013:48, 14 October 2014

Problem with parameters of zh template

I recently used VisualEditor to add a zh template to w:en:Confucius Institute in this edit. I selected the "s" and "p" parameters, but for some reason VisualEditor added the parameters "simplified Chinese" and "pinyin" instead. These parameters are evidently not supported by the template, so it didn't display correctly until I used the source editor to change the parameters to "s" and "p". I would appreciate some help understanding what went wrong. Thank you!

Mr. Granger (talk)17:45, 2 October 2014

It should be a bug in Visual Editor that puts the explanatory full names of the parameters instead of the usable names. Two ways to fix this: either VE changes to use the short names only or the template itself changes to support full names.

Lyuflamb (talk)01:56, 3 October 2014
 

It appears that the TemplateData is backwards on that template. (I hope that's not a common problem.)

Whatamidoing (WMF) (talk)02:00, 3 October 2014

Ouch. I see. Any fast lane for fixing it?

Lyuflamb (talk)02:09, 3 October 2014

WhatamIdoing fixed it with this edit; it should now work fine. I hope!

Jdforrester (WMF) (talk)20:01, 3 October 2014

It will only work if an admin has made a null edit, or the system has caught up on its own. If it's still not working, then please let me know, and I'll go beg a favor from an admin.

Whatamidoing (WMF) (talk)21:48, 9 October 2014
 
 

Ah, I see. Thanks for fixing it!

Mr. Granger (talk)20:20, 3 October 2014
 
 

Defect with Google Japanese Imput(Google日本語入力使用時に不具合発生)

大変申し訳無いのですが、日本語での書き込みについて失礼致します。 日本語版ビジュアルエディターを「Google日本語入力」で文字入力をする際、漢字への変換がされないばかりか文字入力時に強制的に確定され、ひらがなでの文字入力しかできません。 使用環境は、Mac OSX10.9.4、Google日本語入力 1.13.1880.1、Google Chrome 37.0.2062.124です。

8F02E (talk)23:20, 8 October 2014

Thank you for leaving a message. I am sorry that VisualEditor is working incorrectly in Japanese.

User:Shirayuki and User:Miya, can you help us? User:DChan (WMF) is the most relevant developer. I'd like to be able to give him an accurate description of this problem.

Whatamidoing (WMF) (talk)21:45, 9 October 2014
 

Shortcuts to add common templates asking for improvement (proofreading templates)

Although Visual Editor is a huge step in user experience for Wikipedia, it only benefits authors, or at least conceptually so. Most readers who only need introductory information have little to no incentive to engage in editing. But these are people Wikipedia should rely on in finding minor bugs, spelling errors, missing citations, etc., in general proofreading. But current barrier on proofreading is still too high for general public to participate.

The current minimum steps for a Wikipedia reader with no editing experience to add a "citation needed" template to a sentence are the following:

1. Know the template system
If registered:
2. Open Visual Editor
else:
2. Search for template:citation needed
3. Insert the template

The first step is the biggest barrier under the assumption.

My ideal proofreading mechanism is proofreading as reading. I want to select any part of the content and choose from a list of proofreading templates right away. Such UX can also serve to teach readers that Wikipedia is not an authoritative source, and to cultivate their habit of critical reading.

Lyuflamb (talk)01:50, 3 October 2014

This is a good idea. It would help the general improving of the articles.

Nnemo (talk)08:30, 5 October 2014
 

It's not at all clear that having novice editors apply templates to articles is a good idea, let alone a high priority. For example, the documentation page for the citation needed template has a large section titled "When not to use this template"; novice editors can't be expected to read (or fully understand) all the documentation pages for all possible templates.

Which raises a more general issue: How many different templates could be applied when doing proofreading? If you take a look at this page, you'll see dozens and dozens of possible templates, and those are just for "cleanup". Do we really want to show all these templates to a novice, and expect him/her to understand which one to use? How would we do that in a compact way, since the full page is so lengthy?

Personally, I'd rather novice editors work on wording, and adding information, and adding citations. We already have plenty of templates in Wikipedia articles, in my opinion.

John Broughton (talk)01:13, 8 October 2014
 

Semantic MediaWiki

Sooner or later people will probably ask if and how they can add SMW tags. Is this supported?

I noticed btw that parts of text sometimes block the insertion of the cursor. Also, when you start typing something, the cursor sometimes jumps to another section, and when you try to select a string (shift+arrow), it gets deleted instead.

Cavila MW 1.17, MySQL 5.5.23, Php 5.3.10, SMW 1.7.112:27, 6 September 2012

It will be possible to extend the VisualEditor (and Parsoid) to support each 'node type', which could include a bunch of things we expect to see from YouTube videos to pop-out image galleries. We don't have an exact plan for which node types we'll be working on at WMF or when (though our priorities are listed here), but we'd welcome other people writing an extension to provide support for SMW tags.

On the cursor/insertion issue, yes, sorry about that; we hope to replace the code that leads to that breaking soon.

Jdforrester (WMF) (talk)17:44, 6 September 2012

Thanks. Sounds like promising developments!

Cavila MW 1.17, MySQL 5.5.23, Php 5.3.10, SMW 1.7.114:28, 9 September 2012

Hello, is VisualEditor supported in the current Semantic Form version, can we use it to edit the free text fields in the forms?

197.163.180.5014:39, 7 October 2014
 
 
 

Special characters

Why is the Insert:Special_character glyph an Ω symbol. Ω is not available as a special character, nor is any of the Greek alphabet for that matter. I just started an edit in VE on the basis that I would be able to do this and then find I cannot complete it. How annoying.

SpinningSpark01:56, 1 October 2014

It's not an uncommon choice for that icon: it's the same symbol Google Docs uses, for example. Which character were you looking for? The list of the available ones is customizable on a per-wiki basis. Best,

Elitre (WMF) (talk)11:20, 1 October 2014

I was looking for lowercase lambda, but that is beside the point. The whole greek alphabet is needed, along with all the accents and breathings. How am I supposed to write electrical engineering articles without Ω? It is the symbol for ohms. Oh, and by the way, Google Docs does have Ω.

Are you saying the available symbols are controllable by local admins? If so, where? Another consideration, if all the symbols currently available in the standard editor were to be put in VE, would they all have to go on the same page? Currently, they are spread across several pages through a drop down menu. Google docs, which you seem to like so much, does the same.

SpinningSpark12:41, 1 October 2014

The character inserter is not in its final form yet (there are previous discussions about it on this page as well). There's more information at VisualEditor/Special characters. HTH,

Elitre (WMF) (talk)13:24, 1 October 2014

I have tried to make the common problem of misformatted changes be more obvious in the help page.

Whatamidoing (WMF) (talk)02:23, 3 October 2014
 
 
 

This is called a false promise.

Nnemo (talk)08:32, 5 October 2014
 
First page
First page
Previous page
Previous page
Last page
Last page