VisualEditor/Feedback

Post your feedback about using the visual editor.

If you have never provided feedback before, you can learn how to do it effectively. If you are reporting a problem directly on this page, please include your web browser, computer operating system, and wiki skin (usually Vector, sometimes Monobook). The feedback tool within the visual editor will include your user agent details instead.

You can use this page to tell the Wikimedia developers your ideas and issues about using the visual editor: this is the only feedback page actively monitored by WMF staff. The Contributors team welcomes your feedback and ideas, especially on user interface decisions and the priorities for adding new features. All comments are read, in any language, but personal replies are not guaranteed: the team will try and go through reports here at least once a week. Need more attention? Report directly in Phabricator. Please note that the Wikimedia Foundation does not provide support for installing VisualEditor on third-party wikis. Please report bugs involving Parsoid at Talk:Parsoid instead.

You may also want to read a guide to optimize the visual editor's experience on your site, which details work necessary on the community side (such as translating or setting up citation systems).

View open developer tasks – Report a new bug in Phabricator – Join the IRC channel – Test the visual editor! (no account required)

Previous page history was archived for backup purposes at VisualEditor/Feedback/LQT Archive 1 on 2015-07-30.

Issue:

There seem to be a considerable number of bad uses of markup when an apostrophe is used.

Steps to reproduce:

1. Go to Sandbox
2. Type a single apostrophe: '
3. Select the apostrophe (highlight it)
4. Set it as bold (Ctrl + B)
5. Save page

Possible solutions

1. Always use the html entities for those so it becomes ''''''' ; or
2. Wrap it around html tags, so instead of '''<nowiki/>'''' it becomes <b>'</b>

Notes:

I came upon these after seeing it in an article and searching for them. There are plenty of ridiculous examples:

https://en.wikipedia.org/w/index.php?title=Kilteel&diff=prev&oldid=616000454

The Archaeological Survey of Ireland notes a 16th or 17th century house in Blackchurch whose site has yet to be identified, presumably the <nowiki/><nowiki/>'<nowiki/>''stump of a castle''<nowiki/>'.<ref>KD015-011</ref> <nowiki/><nowiki/><nowiki/><nowiki/><nowiki/><nowiki/><nowiki/><nowiki/><nowiki/><nowiki/><nowiki/><nowiki/>

https://en.wikipedia.org/w/index.php?title=Belle_%28Beauty_and_the_Beast%29&diff=prev&oldid=837869142

<nowiki/><nowiki/><nowiki/><nowiki/>{{rquote|left|As Disney heroines go, Belle was an iconoclast. 

https://en.wikipedia.org/w/index.php?title=Andrzej_Grzegorczyk&diff=prev&oldid=830828900

<nowiki/>''<nowiki/>''<nowiki/>''<nowiki/>'''<nowiki/><nowiki/><nowiki/>'''''

https://it.wikipedia.org/w/index.php?title=HMS_Britannia_%281904%29&diff=prev&oldid=98332054

<nowiki/><nowiki/><nowiki/><nowiki/><nowiki/><nowiki/><nowiki/><nowiki/>''<nowiki/><nowiki/>''

See more: https://en.wikipedia.org/w/index.php?title=Special:Search&limit=500&offset=0&profile=default&search=insource%3A%2F%5C%3Cnowiki%5C%2F%5C%3E%5C%3Cnowiki%5C%2F%5C%3E%2F

Alternatively, the parser should be smart enough to normalize these nowikis and simply remove all markup(apostrophes) that will result in no content being rendered at all.

@SSastry (WMF), is any of this covered by your existing collection of nowiki bugs?

Duplicate of Topic:Uo546m23vejl3t41

The citation function, type "automatic" of the "beta" function of the "beta wikitext editor" is to mixing/switching the texts. For example, for the IBM about FIPS 140–2 function adds publisher (IBM Knowledge Center) in the title, and add url (www.ibm.com) to work/author...

"<ref>{{Citar web|url=https://www.ibm.com/support/knowledgecenter/pt-br/SSSHTQ_8.1.0/com.ibm.netcool_OMNIbus.doc_8.1.0/omnibus/wip/install/concept/omn_con_fipssupport.html%7C|title=IBM Knowledge Center|work=www.ibm.com}}</ref>". ~~~~

Tracked in Phabricator
Task T194945

Resolved.

There is a problem, very frequent at least in the french Wikipedia, where the first paragraph of the intro "fuses" with the infobox if you use the Visual Editor.

See this example: https://fr.wikipedia.org/w/index.php?diff=147963144 (edit link: https://fr.wikipedia.org/w/index.php?title=Tintin_au_pays_des_Soviets&oldid=147961827&veaction=edit).

Thank you for your work.

Are you concerned about what readers see in the article, or about what the wikitext looks like in the editing box?

I'm concerned about the text acting weirdly in visual editing mode. Try to hover your mouse over the first sentence:

"Tintin au pays des Soviets (titre complet sur la couverture : Les Aventures de Tintin, reporter du « Petit Vingtième », au pays des Soviets) est le premier album de la série de bande dessinée Les Aventures de Tintin, créée par Hergé, dessinateur belge" in this example: https://fr.wikipedia.org/w/index.php?title=Tintin_au_pays_des_Soviets&oldid=147961827&veaction=edit.

The problem, affecting the editing (fluidity or accessibility), should appear clearly.

As you can see here, I dodged the problem by adding a lane between the end of the infobox and the beginning of the article's intro.

Confirmed, it's bugged when I try it. In the link above, in VisualEdit mode, it does not appear possible to directly edit the lead sentence. Trying to click on that sentence is treated as a click on the infobox. As a bizarre workaround, if you edit the infobox you can scroll down to see&edit the lead sentence in the infobox's "Content" field.

It's the dreaded Complex Transclusion dialog box.

Braaark, do you find that this happens consistently with certain infoboxes, but not with others? For example, I can trigger the bug with Modèle:Infobox Cinéma (film) but not with Modèle:Infobox Organisation.

Yes, that happens consistently with certain infoboxes like:

* for books (Infobox Livre),
* for albums (Infobox Musique (œuvre)),
* for journals (Infobox Revue),
* for films (Infobox Cinéma (film)),
* for comic book titles (Infobox Comic book)
* and for comic strips (Infobox Bande dessinée)

(those are the involved infoboxes I noticed so far, all from the french Wikipedia).

That suggests that the problem is with the infobox templates. Do those particular templates use HTML tags to set absolute positioning (such as <span style="position:absolute;">)? That was a problem once, at a different wiki, and it produced the same symptoms.

I don't know. As I'm not used to HTML language, I signaled the problem here (in french, in the french WP's infobox project page).

@Whatamidoing (WMF), Alsee:: The problem has been solved. It was caused by our template w:fr:Modèle:Infobox/Titre en italique (more informations: , ).

Erabiltzaile agentea: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/17.17134

URL: https://eu.wikipedia.org/wiki/Konposatu_inorganikoen_nomenklatura?veaction=edit

Kaixo, artikulu horretan ez dit uzten aldaketak argitaratzen, eta besteetan bai, ez dakit zer egin. Ematen diot "Aldaketak argitaratu" teklari, eta ez da ezer gertatzen, hórrela gelditzen da. Eskerrikasko

EVERY SINGLE TIME I open a new topic that hasn't been made before I get that little pop up telling me that I'm making a new page. I know ! It's like Navi from Zelda. Yeesh!

Can I turn it off?

These are likely editnotices, which are specifically added by the community of editors to show up every single time when editing a page or a namespace. Talk to your local community if there are notices that you think should not be shown.

@TheDJ I'm learning development and decided to start my own personal self hosted mediawiki wiki so I am the guy in charge of that, but I don't know how to do that, and I'm having trouble finding documentation on how to turn them off. Any pointers?

We used to be able to click on a reference (bringing up the pop-up with the edit button), copy, and then paste within the article or even between articles if you had both pages open in VisualEditor. This was very useful since it allowed editors to quickly reuse the the same source without using the "reuse" tab, which often got unwieldy and slowed down performance on long pages. Recently, doing this instead just produces [x] in plaintext upon pasting. Is there any way to get the old functionality back?

EDIT: Chrome 69.0.3497.100, macOS High Sierra 10.13.6, Vector

This works for me today. Are you still having this problem?

Yeah. The copy paste function just seems to get rid of all the wikiformatting: references, links, etc.

Well... I was thinking about upgrading to High Sierra, so maybe I'll do that now, and see whether I have the same problem.

I think it's actually something with Chrome. There's been a few isolated incidents of not being able to "Cmd C + Cmd V" into the address bar.

Copying refs and links in Visual Editor works if I right click and select "copy" and right click and select "paste", though "paste and match style" does not work and just results in plaintext. I've also figured out that this solves the Chrome address bar issue as well.

For the record, I'm running Google Chrome Version 70.0.3538.77 (Official Build) (64-bit), and I've now upgraded to macOS Mojave Version 10.14 (18A391).

Agente de utilizador: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36

URL: https://pt.wikipedia.org/wiki/Mar%C3%ADlia_Coutinho?veaction=edit

Não sei como editar nada aqui. Tenho um texto pronto que um amigo preparou em inglês, minha língua primária de publicação.

A informação nesta página está ERRADA e pode gerar problemas legais para mim.

O que devo fazer?

It would be great if the editor could detect, when I am about to add a duplicate citation.

I just tested it this way and it showed me no warning:

1. Add an URL via automatic tool (tab) there.
2. Go somewhere else and add another URL, paste exactly the same URL as before.
3. And it created exactly the same text and did not notify me, one was there already.

I think checking whether one is about to re-add exactly the same URL would be an easy check, you can add.

Does this sound like phab:T126488 to you?

Yes, exactly!

Användaragent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36

URL: https://sv.wikipedia.org/w/index.php?title=Henrik_rosenkvist&veaction=edit&section=0

Det blir liten bokstav i efternamnet. Vet inte hur man ändrar.

Agente de utilizador: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0

Using the Visual Editor (in Portuguese Wikipédia), when adding a template you need to click the mouse button 5 times, in addition to typing at least the start of the template name you want, which is a pain and can be optimized. The steps are (in portuguese): click "Inserir", click "Predefinição", type the first letters, click the correct one in the search list, click "Adicionar predefinição", click "Inserir".

I suggest 3 changes to improve the user experience:

• Put a template button in the top bar outside of the "Inserir" (insert) menu, as there's plenty unused space there and it would eliminate one click;
• When the pop-up appears, show a list of last-used template, or of common ones, before the user starts typing. With that we eliminate the typing AND another click in most cases;
• When typing is needed (if it's not in the proposed list or if that suggestion is not accepted), clicking the correct one in the search list should automatically go to the next page (the one showing the template description) and skipping the need to click the "Adicionar predefinição" (add template) button. That is a completely useless, and the most annoying, step.

If this is implemented, it would reduce the process to just 3 clicks in the best case (if the template wanted appears in the suggestion list), or to 3 clicks + some typing in the worst case. In addition, it would help the user if he doesn't remember the name of the template, making it much more user-friendly.

You can do all of this from the keyboard:

1. Type {{ to open the Insert template dialog.
2. Start typing the name of your template. Use arrows and the ↵ Enter or Return key to select the one you want, and press it again to add the template.
3. If you need to fill in parameters, use the Tab ↹ button to navigate to the correct box(es) and type the parameter contents.
4. Press ⇧ Shift+↵ Enter to insert the template into the article.

The only "click" I made in that entire edit, including saving the page, was to put the cursor on the line that I wanted to edit.

For your specific suggestions:

• There is plenty of unused space in the toolbar – if you have a wide screen and good eyesight, which is not true for all editors. If you have a smaller computer screen or zoom in, then there is no available space in the toolbar. Multiple editors have told me that the toolbar wraps onto a second fat line on their computers.
• T96710 proposes a separate, manually curated list of common templates, which would be very handy at wikis that use only a few templates heavily (e.g., Wikivoyages). However, unless it wins the m:Community Wishlist (starts Monday), I don't expect that to be prioritized during the next year.
• If the template is automatically added, then you will have no opportunity to notice that you have accidentally clicked the wrong template. But if you are confident, you could just press the ↵ Enter key.

I really appreciate and am impressed by the way you have analyzed this workflow. Thank you for posting it.

Thanks for the appreciation.

I didn't know about the "{{" shortcut. I now see it is in the help dialogue, but I guess I never checked the shortcuts. And for me, the 4th step is different, using Ctrl instead of Shift key (different systems, I guess).

Regarding your points:

• I see 2 solutions (ideally, both implemented, but only 1 would be enough): check the screen size and zoom level, and only show it if it fits (better for basic users); or simply let the user customize the toolbar (better for advanced users).
• Yeah, that is exactly one of the suggestions I thought. The other (better, in my opinion) is similar to T109253, either recording the last 5 (unique) templates used, and showing them in reverse chronological order, or recording the last 100 used and showing the 5 most common ones. The numbers are just examples, but I believe a per user customization is better than a per project one (and perhaps is easier to achieve than having a project consensus). Here's an example of the proposed design: File:Frlara-1.png
• I didn't say adding the template automatically, but making the click confirm the selection and go directly to the next step where the information are inputted (skipping the "Add template" button, but not the "Insert" button at the next page). If that is still not acceptable, a "Back" button besides the "Insert" one could be added to let the user correct that mistake.

Thank you for your work.