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

Contents

Thread titleRepliesLast modified
Special characters001:56, 1 October 2014
global Visual Editor disable for edit section?118:42, 30 September 2014
Infobox on en.wikipedia's The Little Prince200:14, 29 September 2014
How to translate VisualEditor/Design/Table editor100:00, 29 September 2014
problems in korean.123:54, 28 September 2014
Visual Editor Programming: No <nowiki> around html tags please319:15, 25 September 2014
You are all awesome118:08, 25 September 2014
Indents310:42, 24 September 2014
character inserter - Icelandic110:04, 24 September 2014
JavaScriptless experience1012:54, 21 September 2014
Insertion of underscores to piped links119:24, 16 September 2014
Special characters2015:52, 11 September 2014
VisualEditor available on Internet Explorer 11007:33, 11 September 2014
HTML comments and 'draft mode'100:18, 5 September 2014
bug 49904 not on roadmap716:24, 3 September 2014
Redirects in link suggestions309:22, 3 September 2014
inserts "nowiki", why?613:58, 30 August 2014
The wiki-markup detector sometimes mis-detects611:04, 29 August 2014
Dialog box still hides content400:47, 24 August 2014
VE freeze in Chrome when switching to code editor322:24, 21 August 2014
First page
First page
Previous page
Previous page
Last page
Last page

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

global Visual Editor disable for edit section?

I have a unified account and I would like to make it so that I can set something so that on all wikipedias clicking on editing a section goes to the old text editor rather than the Visual Editor. Any ideas?

Naraht (talk)15:41, 29 September 2014

I don't know how to do this myself, but I believe that you could create a global.css file at Meta to hide the "edit" ({{int:editsection}}) label.

Whatamidoing (WMF) (talk)18:42, 30 September 2014
 

Infobox on en.wikipedia's The Little Prince

The infobox on w:en:The Little Prince seems to be impossible to edit with VisualEditor. When I tried, it turned into a bunch of code gobbledygook.

Mr. Granger (talk)01:14, 13 September 2014

The refs in the infobox cause the info box to add a broken COinS identifier into the caption. When rendering in 'read' mode, the recovery from the brokenness results in something reasonably workable. In VE edit mode however the recovery system isn't (and for various technical reasons probably never will be) nearly as effective and you get a result that is closer to what is actually "defined" and that means broken rubbish.

You can see the same brokenness if you copy paste the first parts of the article and put them in en:Special:ExpandTemplates and check "Show raw HTML"-there. The caption is totally broken (If you can read HTML that is).

The solution is to either not use those refs in those fields (specifically the one for country it seems), or to fix the COinS generator in [[:en:Template:Infobox book}}

TheDJ (Not WMF) (talkcontribs)09:48, 13 September 2014
 

Hello. I happened to find the VE table editor very useful to add data to a table. I'd like to translate VisualEditor/Design/Table editor into my lang. Where or how can I translate that page ?

Regards.

miya (talk)15:36, 20 September 2014

I could mark it for translation. Would that page really be useful to you in its current state?

When the table editor is "live" soon (November? December?), some information about how to use it will be added to Help:VisualEditor/User guide.

Whatamidoing (WMF) (talk)00:00, 29 September 2014
 

problems in korean.

i can't type anything korean character in ve.

14.52.81.22716:24, 20 September 2014

What kind of keyboard do you have?

Whatamidoing (WMF) (talk)23:54, 28 September 2014
 

Visual Editor Programming: No <nowiki> around html tags please

Hello! I want to develop a VE gadget which wraps the selected Text with a <div class='mw-collapsible'>...</div>. I found out how to replace the text. But the editor puts a nowiki-tag around my replacement. How can I prevent this? Greetings, Till-Jonas

Till.jonas.meyer (talk)12:17, 24 September 2014

Maybe eranroz can help you?

Helder20:31, 24 September 2014

I don't speak Hebrew or which language these interesting characters come from...

79.194.201.4908:28, 25 September 2014

The simplest solution is to wrap text with template in similar way to VisualEditor gadgets#Adding templates and VisualEditor gadgets#Replacing text. Using template instead of html tag may be preferred choice as it is more natural in wiki. But if you really want to add div with no templates, than you should probably create annotation class (e.g to inherit ve.dm.Annotation) and than use

var	fragment = ve.instances[0].getModel().getFragment();
fragment.annotateContent( 'set',  'collapsible');//assuming there is collapsible definition...

You can ask for tips and extra help on ve.dm in general in #mediawiki-visualeditor on freenode IRC.

Eran (talk)19:15, 25 September 2014
 
 
 

You are all awesome

I just taught a class how to edit Wikipedia using the VisualEditor. I hadn't tried it in awhile, but it appears to have very near full functionality now. Teaching the class was relatively painless; the only difficulty came with showing them how talk pages work. Thank you all very much, and please pass this feedback on to the developers!

Ed [talk] [en:majestic titan]18:01, 25 September 2014

Well, thanks a lot Ed. I'm pretty sure everybody will appreciate your kind note. Best,

Elitre (WMF) (talk)18:08, 25 September 2014
 

I just tried moving around some text with indents. VE made a real mess of the indents, removing some that it was not intended to remove and increasing the indent of other lines. On trying to put this back right I found that the increase and decrease indent icons are greyed out. Is this a bug, or just not implemented yet? Is there really no way to adjust indents in VE?

SpinningSpark01:23, 24 September 2014

Indenting in VE is only meant to work with lists until bug 48010 is fixed. Best,

Elitre (WMF) (talk)10:00, 24 September 2014

So if VE is screwing around with the indenting of something that isn't a list then that would be a bug, right?

SpinningSpark10:25, 24 September 2014

It is possible that you had a issue which also affects lists so it might be already known (see this example), but generally speaking you might go on and write about it on Bugzilla, worst case scenario is it's a duplicate. Thanks,

Elitre (WMF) (talk)10:42, 24 September 2014
 
 
 

character inserter - Icelandic

Here is some feedback on the character inserter, focusing on using it for Icelandic.

There are three usecases here. Firstly the native icelandic users that use an icelandic keyboard, then secondly non-icelandic users that are writing icelandic words, such as the given name of an icelandic person and then thirdly the usecase for old icelandic texts at wikisource and wherever they are mentioned on wmf projects.

Usecase 1: Usecase one does not really involve the character inserter at all, as there has been an icelandic keyboard in Windows and Mac since the 1990´s.


Usecase 2: In order to know what characters people without an icelandic keyboard setting need, we need to specify what keyboard they do have, or just assume that they have as small subset of icelandic characters as possible. Lets take the english keyboards as an example and exclude the characters that are allready in the character inserter. An UK keyboard user would need the "Ðð", "Ýý" and "Þþ" characters, an united states keyboard user would need the "Ðð", "Íí", "Óó", "Ýý" and "Þþ" characters. An us international keyboard user would not need any accents.

If we assume that the user has no characters with diatrics or other specific icelandic characters, which I would think would be as small of an subset of Icelandic characters as possible, then the characters mentioned for the US keyboard (the native one) would need to be added. I would like to add though, that Icelandic does use an opening qutation mark that is placed at the base of an character - so the qoutation marks become „”. This character can´t really be added in other keyboard layouts (except Romanian and others), so I would propose adding that aswell.


Usecase 3: Lastly I would like to mention the third and final usecase, for old icelandic texts. In old icelandic texts, the current quotation marks are not used, but there are entirely different quation marks, which look like so: << >>. This is a problem, as these symbols are not present in the current icelandic keyboard layout. US keyboard users would probably not have a problem with this, however. I am not certain that I have mentioned all necessary characters for this usecase, but I do think that is it. Despite that icelandic alphabet has changed considerably during the past decade, the old icelandic alphabet was closer to the basic latin letters then than it is now, and this does not give any issues for the character inserter.

Snaevar (talk)11:20, 21 September 2014

Hi User:Snaevar, I'll leave a message on is.wp so we can improve the inserter there. Best,

Elitre (WMF) (talk)10:04, 24 September 2014
 

JavaScriptless experience

Hi. I'd like to know why VisualEditor tab doesn't show up when I disable JavaScript.

From what I could see, the server should be able to send the thing (either HTML or wiki markup) to my browser, where I could edit it. Browsers are quite capable of entering edit mode for chunks of HTML: https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Content_Editable

Then click Save and have the browser sends the new HTML back to server. Seems trivial.

Gryllida09:51, 31 August 2014

Basically, the browers are all broken as hell. There is a bit of a technical explanation to this in one of the Wikimania 2014 talks. Specially starting from this point. The audio is a bit bad, but if you crank up the volume it should be watchable. complete VE techtalk.

TheDJ (Not WMF) (talkcontribs)22:46, 31 August 2014

Would the browser be broken just as much as to make me uncomfortable, or would it also return garbage and break the page?

I'd watch these things, but a transcript would be nice. I learn by reading (I already have a couple videos overdue since March 2014, but I'm not touching them despite sincere interest in the topic).

Gryllida22:57, 31 August 2014
 

What TheDJ said, essentially.

To be fair to the browser manufacturers, our needs are significantly more complex than basic ContentEditable. The vast majority of VisualEditor's codebase (of which there is a lot) is for providing nice ways to edit content that doesn't exist in the ContentEditable world (like images or templates) and stopping browsers from letting you do things you can't (like changing the colour of the border on a thumbnail'ed image). There's also the entertaining litany of browser-specific quirks and bugs that we have to work around in this area, which is only semi-standardised.

As so often, if a quick glance at something means it "seems trivial" when people are spending several years working on it, you've may not have looked deeply enough. :-)

Jdforrester (WMF) (talk)23:14, 31 August 2014

A bit hard to read the grey stuff, sorry for being out of current style here...

Yeah, visual editor doesn't edit templates very visually atm. All these raw arguments to type in. :-)

I can see another current problem with templates - a lot of template workflows are carried out manually, or manually using JavaScript: some documentation and use-cases. As you see, they are typically resolved by JavaScript, using parsoidObj or using manual parsing.

I'd like to see this happen server-side with aid of workflow definitions in templates markup. For instance, imagine that draft submission works like this: {{submit}} is often replaced by {{tasks|add sources|remove copyrighted material|another common task|custom comment}} and a {{review-rejected|custom note on sources|custom note on copyright|review comment|...}} on a draft talk page.

There should be means to add a button on the {{submit}} template which opens a form that asks reviewer for

  • a list of tasks: add sources and rm (C) material
  • comments on each: perhaps a helpful suggestion, reviewer probably found a source. Possibly a note which specific portion is copyrighted.
  • and a full review comment

Then, when form is submitted, the two edits are made -- {{submit}} replaced with {{tasks}}, and a new {{review-rejected}} is placed on the talk page.

How would we do it? Start with backend - have an API which easily allows to replace templates and pass params around like that. Probably Parsoid already exposes that, dunno. Once an API is clear, time to work on an implentation, and as this goes through forms, I imagine it's also, in theory, doable for JavaScriptless users too.

Gryllida02:11, 4 September 2014

Workflow templates are very much in the world of Flow's potential area, rather than VE itself. I don't really have any plans in the editing world for this kind of template, though potentially I could be convinced.

Jdforrester (WMF) (talk)22:14, 10 September 2014
 

On brokedness of contentEditable: I'd ideally like more details here, to understand the scope of the problem.

Gryllida02:11, 4 September 2014

Even disregarding any browser brokenness, contentEditable without JavaScript might as well just be plain text. Without JavaScript to allow you to insert HTML, all you'd be able to do is delete formatted text and extend existing formatted text, which is hardly makes a usable editor.

110.148.190.24707:50, 4 September 2014

Actually, some basic OS shortcuts like  Ctrl+B etc. work, but yes, it's very limited.

Jdforrester (WMF) (talk)22:11, 10 September 2014

Not by default they sure don't.  Ctrl+B opens the bookmarks sidebar.

110.148.190.24712:54, 21 September 2014
 
 

He Gryllida,

On VE and ContentEditable. Starts at 1:13:20 into the video. All captioned in English... SRT is downloadable. http://amara.org/en/videos/LyzbQUH2ljH0/info/social-machines-x-reaction/?tab=video

TheDJ (Not WMF) (talkcontribs)01:25, 9 September 2014
 
 
 

Insertion of underscores to piped links

In this edit, VisualEditor added underscores to the targets of several piped links for no apparent reason.

Mr. Granger (talk)18:32, 16 September 2014

Yes, this was caused by bugzilla:70894 and a recent change in VisualEditor (bugzilla:70897). We have made an emergency change to remove the code that is causing this issue (at a cost of letting Internet Explorer corrupt pages instead, but there are fewer of them). Sorry for the disruption.

Jdforrester (talk)19:24, 16 September 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
 
 
 
 

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
 
 
 

VisualEditor available on Internet Explorer 11

VisualEditor will become available to users of Microsoft Internet Explorer 11 during today's regular software update. Support for some earlier versions of Internet Explorer is being worked on. If you encounter problems with VisualEditor on Internet Explorer, please contact the Editing team by leaving a message here. (Please subscribe to the global monthly newsletter to receive further news about VisualEditor.) Happy editing,

Elitre (WMF) (talk)07:33, 11 September 2014

HTML comments and 'draft mode'

Regarding bugzilla:49603 I think those, with exception of draft namespace, should only be shown when the user clicks an extra button (i.e. 'enter draft mode'). Doing otherwise is confusing -- I'm reading "foo bar" and click edit; suddenly a "foo (!) bar" where the (!) opens a comment. This is likely to confuse people I believe (and certainly gets in my way where I'm not editing a draft in the draft namespace -- where the comments are a helpful means to collaborate).

BTW, in draft mode, these comments should be more readily visible. See: http://core0.staticworld.net/images/article/2013/08/libreoffice-1-100049022-orig.png

Gryllida04:48, 3 September 2014

I'm not sure that I understand, so here's an example:

w:en:No Child Left Behind Act contains a hidden HTML comment in the first sentence–inside the article title, actually. The purpose of that comment is to stop people from making the article title wrong. It has been very effective since I added it as a volunteer a few years ago. People open the page to "correct" the date in the title, see a note that tells them their guess about the date is wrong, and they go away without (re-re-re-re-re-)introducing that error into the article.

It appears that you are saying that, if the person who believes the title to be wrong is using VisualEditor, then you don't want him (or her) to see that comment at all, or even to know that the comment exists, unless s/he specifically clicks on a button to show comments first. Have I understood you correctly?

Whatamidoing (WMF) (talk)00:18, 5 September 2014
 

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
 
 
 

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
 
 
 

Redirects in link suggestions

I recently used VisualEditor to make this edit to w:en:University of North Carolina at Chapel Hill student housing. I wanted to add a wikilink to w:en:Wilson Library, so I selected the text "Wilson Library" and clicked the link button. When I did, a little box popped up with two suggestions for targets I might want to link to: "Wilson Library" (a redirect) and "Wilson Library Bulletin". I intended to link to the redirect, but the system automatically selected the other target instead, and because I wasn't paying very close attention, I didn't notice the mistake after I made the edit.

I would suggest that in situations like this, where a redirect exists that matches the linked text exactly, the redirect should be the target automatically selected by the system, rather than another page that matches the linked text less closely.

Thanks for your consideration!

Mr. Granger (talk)19:02, 31 August 2014

I agree, and the bug report has already been filed. Thank you for taking the time to post this note.

Whatamidoing (WMF) (talk)22:44, 2 September 2014

What is the bug number?

John Vandenberg (talk)09:19, 3 September 2014

It appears to be 69716, John.

Elitre (WMF) (talk)09:22, 3 September 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
 
 
 
 
 

The wiki-markup detector sometimes mis-detects

  • Problem: The wiki-markup detector sometimes finds wiki-markup which isn't there making it impossible to save (w/o going through source which is just time wasting).

NickGibson3900 (talk)

Elitre (WMF) (talk)09:47, 29 August 2014

Hi, can you please provide an example? Clicking on the notice makes the warning go away, though. Best,

Elitre (WMF) (talk)09:49, 29 August 2014

Just realised it does go away when clicked on but it still needs fixing this is because it doesn't go away. For example I went to a random article on wp:en and went to VisualEditor. I added two [[ at the end of the page. The WikiMarkup notice came up, so I removed the [[ so it was exactly the same as when I first started but the WikiMarkup notice didn't go away.

NickGibson3900 (talk)10:04, 29 August 2014

Bug 51701 was fixed months ago and I can't reproduce your issue. Can you please tell me your browser/skin/operating system? Thanks.

Elitre (WMF) (talk)10:08, 29 August 2014

MAC - OS X 10.9.2

NickGibson3900 (talk)10:22, 29 August 2014

Not sure if it's a regression, I filed bug 70168 for you. Best,

Elitre (WMF) (talk)10:36, 29 August 2014
 
 
 
 
 

Dialog box still hides content

In response to the pleas just published I thought I'd give VE another shot, having trialled it a lot in earlier days and given up in sheer exasperation at its inadequacy. Sadly, there's no progress on one of my main complaints, probably my major problem with VE: the dialog box hides the content of the article. So if I'm adding a categoroy or a stub template I need to have memorised all the relevant details from the article before calling up the dialog box. I can't shift the box, or shrink it, so that I can read the article: it just hides it. I might persevere for a while, as the developers seem desperate for feedback, but for me this is the killer problem: it's just not fit for purpose.

PamD (talk)21:30, 8 August 2014

Is that bugzilla:49969?

Helder23:47, 14 August 2014

Yes, it's the bug from last year, and I've got the message: devs aren't interested in helping editors like me. I'll do a bit more testing of your VE, but at present it's pretty useless for me.

PamD (talk)18:56, 18 August 2014
 

At the moment, it looks like progress is stalled because VisualEditor's windows are created via OOjs UI WindowManager, and OOjs UI WindowManager doesn't understand the idea of re-sizing.

The story as it reached me is this: The design team has to expand OOjs UI WindowManager (major effort) followed by the editing team implementing the changes (moderate effort), and then we will have what we need. Immediate problem: I don't think that anything about OOjs UI WindowManager is anywhere on the design teams' goals for this fiscal year.

Whatamidoing (WMF) (talk)21:54, 18 August 2014

=/

Helder00:47, 24 August 2014
 
 
 

VE freeze in Chrome when switching to code editor

Edited by another user.
Last edit: 22:15, 21 August 2014

After editing https://fr.wikipedia.org/wiki/Adaptation_humaine_%C3%A0_la_haute_altitude for a while, I needed to switch to code, said that I would keep my changes and nothing happened except the page became grayed and froze. Clicked the green Save button but nothing. I can see my text but cannot select/copy it. Is it lost ???

in case it helps, here is what I see in the Chrome Console

JQMIGRATE: Logging is active load.php?debug=false&lang=fr&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20140814T1…:150
mediawiki.jqueryMsg: helppage: Unknown operation "ns" load.php?debug=false&lang=fr&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20140814T1…:164
console.trace() load.php?debug=false&lang=fr&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20140814T1…:164

(repeated many times)

mw.log.log.warn load.php?debug=false&lang=fr&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20140814T1…:164
'Range.detach' is now a no-op, as per DOM (http://dom.spec.whatwg.org/#dom-range-detach).
Discontiguous selection is not supported. Adaptation_humaine_%C3%A0_la_haute_altitude:1
Uncaught TypeError: undefined is not a function Adaptation_humaine_%C3%A0_la_haute_altitude:502
84
Uncaught TypeError: Cannot read property 'getInternalList' of null Adaptation_humaine_%C3%A0_la_haute_altitude:79
Uncaught TypeError: undefined is not a function Adaptation_humaine_%C3%A0_la_haute_altitude:435
12
Uncaught TypeError: Cannot read property 'getInternalList' of null Adaptation_humaine_%C3%A0_la_haute_altitude:79
Uncaught TypeError: undefined is not a function

Goulu (talk)20:16, 16 August 2014

This looks like there are a lot of broken scripts in use on French Wikipedia, or perhaps by your user account. That will bring any piece of software to it's knees. You might want to ask a local user that has knowledge of Javascript if he can assist you to clean that up, you should have a lot fewer errors with any of the tools (especially those as complex as VE), if you have no JS errors from other software.

TheDJ (talk)10:56, 18 August 2014
 

User:Goulu, thanks for this report. I was able to switch to the text editor in Safari on that article just now. Do you have any large or unusual gadgets or preferences set for your account? Would you mind logging out (or opening a 'private browsing' window) and trying it again?

Whatamidoing (WMF) (talk)21:41, 18 August 2014
 

I don't know if this is related but fr:MediaWiki:Gadgets-definition#Boutons shows a few gadgets which are loading the module "mediawiki.action.edit" in every page, even if not in edit mode, and even if the user didn't disable the WikiEditor toolbar or if the classical toolbar is disabled.

Helder22:24, 21 August 2014
 
First page
First page
Previous page
Previous page
Last page
Last page