2017 Community Wishlist Survey/Editing

From Meta, a Wikimedia project coordination wiki
Jump to: navigation, search

2017 Community Wishlist Survey

Editing
28 proposals, 65 contributors

Go-previous.svg Citations  •  Miscellaneous Go-next.svg

Contents

Modify leading for users who disable enhanced editing toolbar

Edit proposal/discussion

  • Problem: Those using the Enhanced RefToolbar (aka RefToolbar 2.0), i.e. most users, can see w:leading space (or "line-spacing") on the editing window/screen bigger. However, those who disable the Enhanced (Ref)Toolbar can see leading on the window smaller as always since the debut of Wikimedia projects. This makes the text within editing window less readable and less easy to edit for those who disable the Enhanced toolbar. The issue was previously addressed at Meta-wiki's Tech venue, which contains a link to screenshots showing the difference between the two versions.
  • Who would benefit: Users who disable the Enhanced (Ref)Toolbar in various projects
  • Proposed solution: Increase the leading ("line-spacing") from 1.1em to 1.5em (or something similar to the editing window with the Enhanced toolbar). If done, the text within the editing window would be for those users more readable and easier to edit.
  • More comments:
  • Phabricator tickets:

Discussion[edit]

Do you mean the WikiEditor editor? If so, you want to modify the 2003 editor. I’m not sure if it’s worth adding more CSS to it—this is the most basic editor, so size may be an important factor. (The 2006 editor, with which the old RefToolbar works, is currently being deprecated, and will be removed in the near future.) —Tacsipacsi (talk) 14:53, 7 November 2017 (UTC)

Yes, the 2003 editor, Tacsipacsi. I'm unsure about the 2006 editor as removing it is planned, but I am using it and hope that it can be adjusted also before being removed from all projects. --George Ho (talk) 16:23, 7 November 2017 (UTC)
Removing this is postponed again and again, but last update says 2017Q4 (i.e. anytime this year), while the results of this survey will be ready as late as the middle of December, so the toolbar may be removed even before it becomes clear whether this proposal is supported at all. (You can use custom CSS in the meanwhile.) However, the exact date of the toolbar removal makes no difference as if this change is made, it doesn’t make sense to add this CSS to the toolbar and leaving the toolbarless interface still without readable textbox, it should be applied—or not applied—for both the 2003 and the 2006 editor (if the latter is still alive). —Tacsipacsi (talk) 20:18, 7 November 2017 (UTC)
I modified the title of this proposal to make it more clear what it is referring to. Hope that's OK. Kaldari (talk) 06:33, 8 November 2017 (UTC)

VisualEditor Template Suggestion

Edit proposal/discussion

  • Problem:

Some situations need templates like maintenance's ones, inserting special characters hard to have on a keyboard (e.g. non latine script or phonetic symbols) or structured content like Wiktionary (i.e. pages organizing through templates in section titles).

Time going, Wikitext editor have been improved by users to add templatelists for editing like Hebrew Wikipedia. Missing those customized shortcuts to call templates (or special characters) is a great lack now in the Visual Editor and the new wikitext editor.

There is already a way to define most used special characters on VE/NWE. That system should exist for templates, and should be customizable/overrided by user. Those elements have to be easier to create than is it now, and easy to access.

  • Who would benefit:
    • As a wiktionarian, I see how import this could be for Wiktionary. It may benefit to everyone by suggesting templates for the rigid structure of the content (like synonyms section) and templates such as register or geographical tags (template used at the beginning of a definition, useful to categorize).
    • As a wikipedian, I sometimes need to tag some articles with inline templates such as Citation Needed. Have a shortcut to access that template without searching for it would be very would help.
    • On Wikivoyage, Listing templates have to be easy to access, because they are heavily used.
    • Please add your concern if you have a different perspective on this matter!
  • Proposed solution: A customable list of templates/chracters to insert, defined at different levels. This list should appears in the dialog and permit classification and documentation for the templates suggested.
    • project-wide (crucial for Wiktionary, Wikivoyage)
    • at the level of a namespace (e.g. Wikipedia: typographic templates for articles)
    • at the level of a project (e.g. mathematical content in Wikipedia)
    • for a user only (my favorite templates).
  • More comments:
    • Actually, in my opinion, template suggestion is a necessity to make the visual editor and the new wikitext editor (NWE) useful for Wiktionary, and more helpful for advanced users who like to be efficient when they edit.
  • Proposer: Noé (talk) 20:22, 9 November 2017 (UTC), modified by Trizek from FR per Noé's request, 09:59, 10 November 2017 (UTC)

Discussion[edit]

This could be a nice feature for VE. As the VE is more heavily based on backend (many API queries) it may be possible to get a list of common templates relevant to the page based on statics (e.g dynamic suggestions, not a fixed list). Having said it, it is quite simple to add to VE menus button for adding very common templates - please see mw:VisualEditor/Gadgets#Real examples for gadgets/scripts that interact with VE (specifically VeDirectionMarkTool). eranroz (talk) 10:45, 17 November 2017 (UTC)

ContentTranslation extension for others wikis

Edit proposal/discussion

  • Problem: ContentTranslation is an extension currently used in Wikipedia that allows you to translate items in other languages more conveniently, it has the advantage of adapting the source templates and avoiding complicating the wiki-code. The problem is that this extension was only created for Wikipedia, it would be interesting if other projects such as Wikinews or Wikiquote could take advantage of this tool in order to facilitate the translation of content between the different languages of these wikis as it is done in Wikipedia.
  • Who would benefit: All users.
  • Proposed solution: Adapt ContentTranslation to the needs and characteristics of the rest of the projects with the objective that it can work optimally in them.
  • More comments: This would make it possible to take advantage of this extension in these projects and encourage the translation of articles in these projects. In addition, outside of this, I think that the automatic translator of the extension could also be improved since that would allow generating less workload to correct the words.
  • Phabricator tickets: None.

Discussion[edit]

CT is bugged. It helps, but you always need to clean up generated code manually. And many problems solved in VisualEditor long time ago still present in CT. --Igel B TyMaHe (talk) 08:59, 14 November 2017 (UTC)

  • Keep developing CT further with more wikis and keep debugging it.--Nizil Shah (talk) 12:31, 14 November 2017 (UTC)

Support multiple diff variants

Edit proposal/discussion

  • Problem: We currently have a side by side comparison for diffs, but this often makes it difficult for people to find small changes inside a sentence. For a long time many editors have been using wikEdDiff, navigation popups diff and other JS based inline diffs, to gain more insight into changes.
  • Who would benefit: Editors and curators
  • Proposed solution: Add a toggle to a diff, to switch from viewing the difference in split (current) mode, to viewing it in unified mode. We can even add a third button for visual diffs, when this becomes more widely available. Take inspiration from github. In the past often performance has been a blocker for alternate diff views. To counter this, only do the inline diff on the client side on demand, instead of the server side.
  • More comments:
  • Phabricator tickets:

Discussion[edit]

Potentially related Phabricator tickets: https://phabricator.wikimedia.org/maniphest/?ids=156439,26617,146781,7072,15462#R --AKlapper (WMF) (talk) 21:35, 7 November 2017 (UTC)

  • Recent Example: A hacked, split-line edit from 12 Nov 2017, as evidence of hard-to-see changes in enwiki page "en:Territory", see: [1]. -Wikid77 (talk) 17:53, 13 November 2017 (UTC)
    (FWIW I think the visual diff makes that pretty understandable, though. Elitre (WMF) (talk) 11:16, 14 November 2017 (UTC))
    The diff algorithm being unable to recognize that the old and new paragraph are related is a separate issue from how the output of the diff algorithm is formatted. Let's keep those discussions separate. --Tgr (WMF) (talk) 09:44, 18 November 2017 (UTC)

A notice: there is a similar proposal in the section Reading, namely Simple diff. --Vachovec1 (talk) 14:47, 15 November 2017 (UTC)

Related: T38902, T117279 --Tgr (WMF) (talk) 09:44, 18 November 2017 (UTC)

Create discussion entry automatically from edit summary

Edit proposal/discussion

  • Problem:

On editing an article, it seems to be a good idea to insert a remark on a questionable point in the edit summary – the effort to insert it on the discussion page is much greater. But experience shows, that very often no one comes the way to handle the problem. So the remark gets lost in the history.

  • Who would benefit:

Editors

  • Proposed solution:

Create a possibility to insert a discussion entry from a part of an edit summary automatically.

  • More comments:

Maybe the part could be the summary ending identified by an introducing string as for example "Discussion:". Disadvantage: Only experienced users would be aware of this possibility. A better implementation would be great, but it should not affect the simplicity of the editing page. So to add a new choice possibility as "Edit summary and discussion entry" seems to be bad.

  • Phabricator tickets:
  • Proposer: Griot (talk) 07:36, 10 November 2017 (UTC)

Discussion[edit]

Why can't the user go to the dicussion page and create a topic? Is it because it's difficult or time-consuming? -- NKohli (WMF) (talk) 19:42, 10 November 2017 (UTC)
It's not difficult, but it takes time and seems to be unnecessary, hoping that there are users, which have the article on their watchlist and can & will handle the problem. But experience in the German WP shows, that this hope is too optimistically in more than 50% of the cases. --Griot (talk) 09:56, 11 November 2017 (UTC)

Voice edit

Edit proposal/discussion

  • Problem:

Reading Wikipedia by (smart) mobile phone is convenient for many use cases. However editing Wikipedia on mobile phone is hard, partly because of the keyboard on (smart) mobile phone. Voice input in mobile phone would be a lot faster, but some specific functionality - such as wiki link - is not support natively.

  • Who would benefit:

Most editors, who may find voice input is easier in a more mobile / ubiquitous computing world, in major languages with Speech-to-Text (STT) supports advanced enough (Vietnamese, my native language, is one of such languages)

  • Proposed solution:

Support voice input for mobile - integrating with default voice input of the mobile OS (Android - Google service by default, iOS - Apple service by default) or can be setup by user to use their preferred STT service .

By "support voice input", I mean, for example, Wikipedia application can allow certain "voice syntax" for wiki link. The syntax, beside default definition, can be setup by user to their preference.

  • More comments:
  • Phabricator tickets:
  • Proposer: Tttrung (talk) 08:20, 10 November 2017 (UTC)

Discussion[edit]

Consider regional languages too-- Shagil Kannur (talk) 05:10, 11 November 2017 (UTC)

An interesting idea. Worth to look deeper into it. If the devs think thay can make it work, why not? --Vachovec1 (talk) 18:34, 12 November 2017 (UTC)

The way voice editing experiences like this have historically worked is that the person records what they want written, and then someone else transcribes it and makes any corrections necessary. Nowadays, voice recognition is generally good enough that the first person can use text-to-speech for automated transcription, but it will always require human checking due to the error rate. The only areas where human checking is not required are areas where small errors are not critical, and only short bits of speech are recorded to allow the user to easily correct themselves, such as Alexa, Siri, Duolingo, and similar. A fully text-to-speech driven environment, where the user also uses text-to-speech to correct previous errors, is possible, but tends to be so cumbersome to use that people only use them if they have no choice, such as blind users. Developing software solutions for this that work in a performant manner on mobile devices in the web browser is extremely hard, which is why the operating systems of phones typically include this in an integrated fashion. General text-to-speech solutions already exist in most modern mobile phones, and even in older or lower-spec phones used in emerging communities. Making a system that allows the user to use wikitext on top of that adds extra complexity, even ignoring the user customisation aspect. In short, this proposal has obvious value, but I think it's such a large undertaking that I don't see it happening within the scope of this wishlist. --Dan Garry, Wikimedia Foundation (talk) 12:35, 17 November 2017 (UTC)

Transwiki template

Edit proposal/discussion

  • Problem: Various same templates are used on different project usually imported a day from Wikipedia project. But template on Wikipedia where communities are more active are up dated while templates on other projects are not if administrator don't care about it.
  • Who would benefit: Every project users
  • Proposed solution: Creating a transwiki template function witch provide the use of Wikipedia's template on all project but without hindering template already present on projects to avoid traditional community protesting reaction to change.
  • More comments:
  • Phabricator tickets:

Discussion[edit]

Potentially related links: mw:Manual:$wgEnableScaryTranscluding, mw:Wikimedia Developer Summit/2017/Cross-wiki templates, translatable, reusable, manageable, phab:T6547, phab:T91162. --AKlapper (WMF) (talk) 20:40, 8 November 2017 (UTC)

Other potentially related: phab:T22153, phab:T121470 Trizek (WMF). (talk) 09:27, 9 November 2017 (UTC)

Maybe close to 2017 Community Wishlist Survey/Wiktionary/Share conjugation (among other things) templates on www.wiktionary.org proposal? Noé (talk) 19:45, 9 November 2017 (UTC)

  • Yes please!! Centrally hosted templates and Lua modules will solve the decade-long jumble that Wikidata is persuading us to solve. Deryck C. 21:48, 11 November 2017 (UTC)
  • I was always a big fan of this idea, but as a community developer i've encountered so much inter wiki problems lately, that i'm beginning to doubt the value in this. I see an increasing demand for control within wiki's and centralising things will put a lot more burden on individual template and module authors to balance the requests of those communities. We will thus see many forks, which will just move the problem to an area with less clear governance structures. Instead, maybe we should create a tool or something that makes it easier to compare versions/age/differences of these between wikis ? —TheDJ (talkcontribs) 15:09, 15 November 2017 (UTC)
  • The biggest problem with having global gadgets/templates is the fact that it's currently not possible to localize them. I like TheDJ's idea. Even something to do easy exporting/importing of templates between wikis (one-click buttons to "Update" templates by copying them from another wiki, for example) seems like a better idea for now until someone comes up with a brilliant idea for how we can localize templates and gadgets without making the wikis totally unusable for everyone. -- NKohli (WMF) (talk) 01:25, 18 November 2017 (UTC)
  • Localization is not hard (just use messages; see also T156210), but the visual flexibility of templates would be lost through centralization. Maybe the way to go is to centralize Lua modules but not templates? Large wikis seem to be moving towards mostly Lua-driven templates for the more complex use cases anyway, and for a library there are good ways to handle local variations. --Tgr (WMF) (talk) 11:48, 18 November 2017 (UTC)

Special character and charset bar above edit window

Edit proposal/discussion

  • Problem:

Currently you have to scroll down below the edit window, if you want insert special characters, quotation marks, brackets or wiki markup.

  • Who would benefit:

Everyone using the default editor

  • Proposed solution:

The bar for special characters, quotation marks and wiki markup should be above the edit window. Or at least an option, to move it up.

  • More comments:
  • Phabricator tickets:

Discussion[edit]

The new toolbar does precisely that. Have you tried checking Enable enhanced editing toolbar in your preferences in the Editing tab? Max Semenik (talk) 19:57, 15 November 2017 (UTC)

Remind users to update TemplateData when template was edited

Edit proposal/discussion

  • Problem:

If a template is edited, TemplateData can stay outdated without notice.

  • Who would benefit:

Afterall every VE user

  • Proposed solution:

Notify template editor, that he/she should also update TemplateData after editing, removing or adding parameters in template.

  • More comments:
  • Phabricator tickets:

T138219

  • Proposer: Dvorapa (talk) 14:38, 10 November 2017 (UTC)

Discussion[edit]

@Dvorapa: As written on 2017 Community Wishlist Survey, please narrow your proposals down to three proposals. This is your 4th proposal, if I count correctly. Thanks! --AKlapper (WMF) (talk) 15:08, 10 November 2017 (UTC)

I see, sorry for me, done ✓ All of them are in scope of Czech community, maybe they will be adopted by somebody from Czech community soon. --Dvorapa (talk) 16:28, 10 November 2017 (UTC)

I agree with the Proposer that the documentation portion of templates needs major work in many instances. Ottawahitech (talk) 14:33, 18 November 2017 (UTC) Please ping me

This request doesn't seem great. At some point we will have MCR, which will obviate the need to go look at separate pages in most/many cases--instead, you'll see another editor for the TemplateData and will presumably update it at the same time as you make the template-proper-changing edit. --Izno (talk) 04:00, 19 November 2017 (UTC)

Dividing section name from edit summary

Edit proposal/discussion

  • Problem: When you write an edit summary, then there are suggestions for your edit summary, which contain many edit summaries you have written in your last edits. But when you edit only for example the section "2012" and want to write "link fix" into the summary, then there are suggested all the summaries, you wrote "link fix" in the last times and that contain "2012" in their section name. So for example "/*2012–2014/* link fix". This is really unnecessary, because I always have edited the section "2012" and never "2012–2014", when I would write this edit summary. And also when I have already written a hundred times "link fix" in the edit summary, but never in a section called "2012", then there are no suggestions for this one.
  • Who would benefit: Uhm... everyone using edit summaries.
  • Proposed solution: The edit summary suggestions should not include the section name, but only the real summary. When I write "link f" then I should get exactly one suggestion for "link fix", where it does not matter in which sections I have written this summary in the past.
  • More comments:
  • Phabricator tickets:

Discussion[edit]

Can't you just triple-click the default summary before starting typing (or select it all other way) so that you overwrite it? In your case it probably does not matter which section you have fixed the link in indeed, while there are cases where it is important (for example if one is voting in an RfX page) --Base (talk) 20:44, 15 November 2017 (UTC)

Ain't that a suggestion by your browser instead of the wiki-software? Grüße vom Sänger ♫(Reden) 09:36, 16 November 2017 (UTC)
  • "then there are suggestions for your edit summary" - this is not a MediaWiki feature. Are you talking about a gadget which does this? -- NKohli (WMF) (talk) 01:33, 18 November 2017 (UTC)
    This is pretty standard browser behavior for all forms. --Izno (talk) 03:39, 19 November 2017 (UTC)

You might want to remove the section title because it or your comment is long and you don't have enough space, for example. Moving the section title out of the edit box would make that impossible. (Although with the new increased comment field length that might be less of a concern.) --Tgr (WMF) (talk) 11:55, 18 November 2017 (UTC)

Nested templates in template parameters in VE

Edit proposal/discussion

  • Problem: In VE there is no chance to add nested template into template parameter without knowing wikitext.
  • Who would benefit: Users working with templates composed of more parts nested into the main one.
  • Proposed solution: Add some possibility to achieve this.
  • More comments:
  • Phabricator tickets: T52355
  • Proposer: Dvorapa (talk) 14:41, 10 November 2017 (UTC)

Discussion[edit]

@Dvorapa: As written on 2017 Community Wishlist Survey, please narrow your proposals down to three proposals. This is your 5th proposal, if I count correctly. Thanks! --AKlapper (WMF) (talk) 15:08, 10 November 2017 (UTC)

I see, sorry for me, done ✓ All of them are in scope of Czech community, maybe they will be adopted by somebody from Czech community soon. --Dvorapa (talk) 16:28, 10 November 2017 (UTC)

Provide easy interface for replacements in the Visual Editor

Edit proposal/discussion

  • Who would benefit: At least fawiki, hewiki, rowiki and ruwiki users, presumably many more
  • Proposed solution:
    What most of the scripts needs are:
    • A utility function for doing replacement (similar to ve.dm.Document.prototype.findText maybe ve.dm.Document.prototype.replaceText)
    • The replacement should be able to keep the annotations
    • Advance use: sometimes (as you can see in fawiki) replacements are context aware. It may be too far to support such complex replacements within ve itself, but providing documentation how to do it would be great.
  • More comments:
    • Moved from Bots and gadgets to Editing as we supposedly would want a general solution rather than a gadget on a few select wikis. Max Semenik (talk) 19:48, 8 November 2017 (UTC)
  • Proposer: Strainu (talk) 07:45, 7 November 2017 (UTC)

Discussion[edit]

  • I support this request. I think this is a major blocker for advanced gadgets for VisualEditor, hence blocker for wider adaption of VE for experienced users. eranroz (talk) 10:36, 17 November 2017 (UTC)

VisualEditor: Allow editing of auto-generated references before adding them

Edit proposal/discussion

  • Problem: It's only a small thing but one that bugs me. When you use the VE's ability to autogenerate a reference based on a URL, oftentimes there will be need to manually fix the generated ref. However, currently you have to first save the incorrect reference before editing it.
  • Who would benefit: Everyone using VE
  • Proposed solution: I propose another button "edit" on the autogenerated reference besides add to fix mistakes immediately.
  • More comments:
  • Phabricator tickets:
  • Proposer: SoWhy 19:19, 10 November 2017 (UTC)

Discussion[edit]

Similar, yes, although that solution would skip the "insert" button which my proposal would keep. On a side note, people should really use better descriptions of their feature requests in Phabricator because when searching for previous proposals, I could not find that one. Regards SoWhy 16:39, 13 November 2017 (UTC)

Make it possible to format tables in VisualEditor

Edit proposal/discussion

  • Problem: Currently it's not possible to do many different things for tables using visual editor. You can add rows and columns, but you can't for example add background colours or set text alignment. You always need to change to the wikitext editor if you want to add background colours, and for newbies it may be very difficult to add html code.
  • Who would benefit: Table editors.
  • Proposed solution: Implement more tools for table editing.
  • More comments:
  • Proposer: Stryn (talk) 18:38, 16 November 2017 (UTC)

Discussion[edit]

Inline styles are both technically inferior (they make it impossible to have different presentation for different devices, screen sizes etc) and result in poor readability and maintainability of the wikitext. We shouldn't encourage them. TemplateStyles should be the preferred solution for table styling. (That still requires the ability to edit classes of table cells, if not their other properties, though.) --Tgr (WMF) (talk) 12:22, 18 November 2017 (UTC)

There are some pretty valid uses, such as aligning text right for number values as well as setting sort values on individual cells. (Though, I agree, the typical "PRETTY COLORS!" type is pretty obnoxious.) --Izno (talk) 03:53, 19 November 2017 (UTC)
There are valid use cases for formatting table cells, but editing inline CSS is not the right implementation for them. Define the styles somewhere else and implement some kind of HTML class editor in VisualEditor. --Tgr (WMF) (talk) 06:27, 19 November 2017 (UTC)

VisualEditor: Allow references to be named

Edit proposal/discussion

  • Problem: One cannot enter a name for a reference in the VisualEditor which will assign ":0", ":1" automatically to references used multiple times.
  • Who would benefit: Everyone using VE
  • Proposed solution: Allow editors to assign individual names to references when clicking on a reference in the VE
  • More comments: According to the Phab ticket, it was deemed too complicated for Q3 back in 2015 but since then there was no further updates. I'm certainly not a master coder but I don't see how this is really a complicated problem, considering that apparently this was once possible and has been removed.
  • Proposer: SoWhy 19:26, 10 November 2017 (UTC)

Discussion[edit]

Endorse. A piece of code of type <ref name=":0"> is ugly and very unhelpful (especially when editing in wikitext mode). --Vachovec1 (talk) 10:48, 11 November 2017 (UTC)

Agree with above. Maybe take the first authors last name and add the year of publication to it? Doc James (talk · contribs · email) 21:52, 13 November 2017 (UTC)
Endorse. A user came into -help with this exact concern and some ideas were discussed around it, eluding to the auto-generation Doc James is mentioning. There seems to be some good suggestions in the comments of the phab tickets. Although it gets a bit iffy for online references. One person suggested domain, underscore, page name (If only a bare url is given) (e.g. bbc_magazine-23969607), which isn't horrible but not a ton better than just [domain]-[sequential number]. Either way, this is a vast improvement over the current system. Drewmutt (^ᴥ^) talk 03:37, 14 November 2017 (UTC)

Endorse. If there's one thing I hate, it's reffing an article in VE then having to tediously go back through in source mode to rename all the refs. Premeditated Chaos (talk) 23:30, 14 November 2017 (UTC)

There are two problems being conflated here:

  1. Allowing manual addition of reference names
  2. Automatically generating a reference name based on properties of the reference

The difficulty of solving the first problem depends on the class of user you're aiming the solution at. If you're aiming it at advanced users, it doesn't seem to difficult, for example, to add a reference name field to the dialogue shown when you edit a reference. I don't know exactly where it'd go, but that doesn't seem too complex to figure out. If you're aiming it at new users, it's significantly more complex. Newer users using visual editor probably won't understand what a "reference name" is given that it doesn't affect anything about the article layout in visual editing mode, so you'd need to explain it to them. Putting it in the edit dialogue is probably too late for them, so you'd need to add it earlier in the workflow, which would increase the complexity of the basic workflow of adding a citation, which does not seem like an acceptable tradeoff. So, designing it for newer users would involve a lot of time and thought, since the risks of disrupting their workflows are much higher.

The second problem isn't too complicated in principle, but the devil is in the details. The biggest issues are hash collisions and incorrect assumptions about the structure of references, see phab:T169841#3411881 for more details on that. A fallback would be necessary, which would likely be the numerical system. These problems can be mitigated of course, but we might end up with a situation that isn't much better than the current one. That could be acceptable if the current situation is suboptimal enough.

A combination of these two solutions might be nice; use some automated system to generate nice(ish) reference names to solve the problem with newer users, and add a reference name field to the edit reference dialogue for advanced users. That means the workflows of new users are not changed at all, and advanced users have nice ways of changing things in the visual editing environment.

For the record, since I've often had people quote thinking-out-loud brainstorming like this like it's some form of immutable truth, I want to point out quite clearly that brainstorming is exactly what this post was. Things could turn out to be more simpler or more complex than I imagine, or the solutions I brainstormed here might not be the ones that are worked on, if the item is worked on at all. :-)

--Dan Garry, Wikimedia Foundation (talk) 12:55, 17 November 2017 (UTC)

@Deskana (WMF): My post was about the first one, which should be easy. Useful autogenerated names would be neat but it would usually be sufficient to be able to name them manually. I do think the auto-generate problem should be a separate post here to avoid said conflating. Regards SoWhy 18:06, 18 November 2017 (UTC)
I'd use a manual field myself, but a simple automatic one shouldn't be difficult--such as the first character of the title field if present followed by a number, or the year field similarly. DGG (talk) 02:13, 20 November 2017 (UTC)

Review individual edits

Edit proposal/discussion

  • Problem: Revisions may persist for long periods of time because they're good edits and no one has a problem with them, or they may persist for long periods of time while being bad edits, simply because no one has noticed them and reverted them. Editors waste time verifying revisions that have already (silently) been verified by other people, while not noticing ones that haven't been reviewed.
  • Who would benefit: Editors, everyone
  • Proposed solution: Have an "upvote" or "reviewed" button next to revisions that indicates that you've looked through the diff and verified that it's a good change. A number on the revision history log will indicate how many people have reviewed it.
  • More comments: This would have no bearing on what revision is shown to viewers or anything like that. It would just be a helpful way to see at a glance which revisions have been checked by real human beings and are considered trustworthy/valid, and which diffs have not been viewed, and may need more attention to catch vandalism or poor quality changes. It's also psychologically similar to the "Thanks" feature, in that people can see that their edits were approved/appreciated by others and they aren't laboring in vain. It would also show editors that the revisions they're undoing were approved by multiple other people, making them think twice before wholesale revert warring. It would also help in finding the original source of subtle vandalism that has gone unnoticed for a while, so it can be reverted.
  • Phabricator tickets:

Discussion[edit]

mw:Help:Patrolled_edits exists. Not sure if what you're asking for is covered at least partially by https://phabricator.wikimedia.org/T25792, https://phabricator.wikimedia.org/T147012, https://phabricator.wikimedia.org/T19237, or other tasks that exist on the subject. Elitre (WMF) (talk) 15:31, 13 November 2017 (UTC)

FlaggedRevs can be configured to work like that. --Tgr (WMF) (talk) 12:13, 18 November 2017 (UTC)

Ping users from the edit summary

Edit proposal/discussion

  • Problem: I recently saw a person wondering how to notify someone of a change, without necessarily leaving a message on the chat page.
  • Who would benefit: Every editor
  • Proposed solution: The solution would be to allow notifications when a user page is linked in a change summary.
  • More comments: A recurrent subject, which has not yet been resolved. It doesn't seem so complicated to implement. There would surely be some details to review, such as revert messages that send useless pings.

Discussion[edit]

I agree it is very time consuming to try and communicate with every editor/user one encounters. Even sending thanks can be cumbersome. There are also other reasons users are reluctant to post on a talkpage. Ottawahitech (talk) 14:50, 18 November 2017 (UTC) Please ping me

Generate reference from ISBN

Edit proposal/discussion

  • Problem: To add references of books manually is way too long and at the same time it may be automatized
  • Who would benefit: Editors, having more time to edit, Wikipedia recieving more bites
  • Proposed solution: Write a code, which will be taking data from ISBN, ČSN (Older Czech code) and other national databases and generation reference. User will just have to add e.g. page from, which it is cited.
  • More comments: I know, there is a bug about this. The last news are the our developers is waiting to the database owners. But I wonder, weather there is just one database. Google is able to get such data, so why Wikipedia not. More over there might be other local databases - e.g. Czech used before the switch to ISBN in 1990s ČSN. Ask User:Mormegil, who knows about it and is able to tell you weather, the database is ready to use.
  • Phabricator tickets:
  • Proposer: Juandev (talk) 06:47, 11 November 2017 (UTC)

Discussion[edit]

Have you tried a RefToolbar gadget? It can fill in the pre-defined template form from given ISBN, URL, DOI or PMID, if the pertinent information is available. --Vachovec1 (talk) 18:50, 12 November 2017 (UTC)

  • Juandev, so you actually mean from other services similar to ISBN - this one's already been working in the visual and 2017 wikitext editors, since last May. Elitre (WMF) (talk) 15:13, 13 November 2017 (UTC)

Wikitext substitutions should work in ref and gallery blocks

Edit proposal/discussion

  • Problem: Links ending in |]], substitutions with {{subst: and tilde-timestamps (~~~~~) don't behave as expected within <ref> and <gallery> blocks. (Amongst others.)
  • Who would benefit: Article wikitext editors.
  • Proposed solution: Resolve that substitution and pipe tricks work inside other mediawiki tag extensions
  • More comments: More generally speaking: common wikitext substitutions that editors would expect to work in all reader-visible places, do not work in some contexts.

    mw:Extension:Cite has not evolved with other components of wikiediting. Substitution (subst:) and pipe tricks from inside custom tags like <ref> fail unless one pushes with more complicated use of {{#tag:}}. Such use can be problematic due to the misinterpretation of | and {{!}}. To note that the identified problem also applies to use of <poem>.

  • Phabricator tickets: T4700: Pre-save transform skips extensions using wikitext (gallery, references, footnotes, Cite, status indicators, pipe trick, subst, signatures)
  • Proposer: bdijkstra (talk) 16:49, 8 November 2017 (UTC)

Discussion[edit]

@Bdijkstra: Could you please fill in the missing sections and provide a meaningful summary? Thanks! --AKlapper (WMF) (talk) 20:37, 8 November 2017 (UTC)

If I had a solution I would have submitted a patch. What else can I fill in there? Summary is now more meaningful, though less precise. --bdijkstra (talk) 21:57, 8 November 2017 (UTC)

Find & Replace feature

Edit proposal/discussion

  • Problem: It is hard to observe wrong punctuation
  • Who would benefit: every editor
  • Proposed solution: Create a button in the Visual Editor in the Find & Replace dialogue to mark non-typographic Quotation marks, non-typographic apostrophes, wrong dashes and double spaces etc and then the editor can decide whether it has to be changed or not.
  • More comments:
  • Phabricator tickets:
  • Proposer: Dexxor (talk) 10:12, 18 November 2017 (UTC)

Discussion[edit]

Converter from Latex and/or MSword

Edit proposal/discussion

  • Problem: Despite VE, many people still end up writing content in googledocs, MSword or LaTeXand wanting to copy it over (especially in editathons and WikiJournal article submissions). Additionally, many possible maths-focussed contibutors would benefit from being able to copy over equations writtn in LaTeX.
  • Who would benefit: Complete novices. Those who have written content outside of wikimedia but now wish to import it. Editathon organisers. WikiJournal editors receiving article submissions in formats other than wikimarkup. Mathsy types who want to paste in equations.
  • Proposed solution: It's pretty easy to convert between MS word, Googledoc, LaTeX, and PDF, so being able to convert to wikimarkup from any of these would be extremely helpful, even if it needed manual tweaking afterwards to deal with references and images to import to commons.
  • More comments:
  • Phabricator tickets:

Discussion[edit]

Re-use a citoid citation in VisualEditor's wikitext mode

Edit proposal/discussion

  • Problem: As you can read in the Phabricator ticket, currently in VE's wikitext mode we cannot re-use citations as we can in VE. This function of VE is one of the best; the software makes us the necessary code, we have to just insert them by clicking anywhere we want. However, it doesn't work if we use wikitext mode. First, we have to switch to VE mode to use this function, then switch back. It's not comfortable and logical.
  • Proposed solution: Add this function to wikitext editor too.
  • More comments:

Discussion[edit]

Auto-save feature in Visual Editor and WikiText Editor

Edit proposal/discussion

  • Problem: We have nice new editor surfaces, like Visual Editor and WikiText Editor 2017, which are planned to use as default in the future. But despite of the old editors, the new ones loose the not-yet-saved content in case of a browser/system crash or an accidentally closed tab. We should offer a function to save the session data, at least as well as it worked until now.
  • Who would benefit: every editors
  • Proposed solution: Implement a kind of auto-save feature for VE (see the ticket)
  • More comments:
  • Proposer: Samat (talk) 15:54, 18 November 2017 (UTC)

Discussion[edit]

Other duplicated Phabricator tickets: T169965, T175489 etc. Samat (talk) 15:54, 18 November 2017 (UTC)

Same in Flow: T139804 (Note that Phabricator and ContentTranslation already have autosave so the common objection that this would result in evil users storing illegal things in the drafts and causing liability is moot.) --Tgr (WMF) (talk) 22:40, 19 November 2017 (UTC)

This is basic functionality, and should have been available from the start. There are various browser-level workarounds , but it should be a basic facility. DGG (talk) 02:16, 20 November 2017 (UTC)

Automatically create a reference id for pictures with a label

Edit proposal/discussion

  • Problem:

There is a problem, when an article has e.g. different pictures included. To address the pictures within the article, an unambiguous reference to the picture is necessary.

Example:

  • There are three pictures in the article, with the captions: "Figure 1: xyz", "Figure 2: abc", "Figure 3: klm".
  • In the text they are referenced with fig. 1, fig. 2, and fig. 3.
  • Now another picture is added between fig. 2 and fig 3.
  • The former figure 3 has to be renamed to figure 4, and the new figure gets the number 3.
  • This procedure is difficult an prone to errors, when there are dozens of figures in the article.
  • Who would benefit:

Editors of article with a large number of figures.

  • Proposed solution:
  • A figure, which should get a number, is provided with a unique label. (e.g. in the example above "xyz", "abc", "klm")
  • The figure gets a certain number for each label.
  • The labeled figure's caption starts with "Figure ###", where ### is the number of the label.
  • In the text fig. "abc" is replaced by fig. ###.
  • More comments:
  • Phabricator tickets:
  • Proposer: Boehm (talk) 20:42, 18 November 2017 (UTC)

Discussion[edit]

Automatic translations of Infoboxes

Edit proposal/discussion

  • Problem: The translation of InfoBox standards like Speciesbox, chembox, Infobox biography takes long time and looks with no value added. Since the field are standards, the translation can be automatic cross wiki languages.
  • Who would benefit: All user doing articles translation cross wiki languages.
  • Proposed solution: Create a link in edit menu related with automatic translation of Infobox standards.
  • More comments: Development will improve the translations produtivity.
  • Phabricator tickets:

Discussion[edit]

Endorse. We need greater integration between languanges. This proposal is the very least we should aim to. B25es (talk) 19:26, 11 November 2017 (UTC)

Are you talking about ContentTranslation? Doesn't it do that already if you have added the English parameter names via TemplateData? --Tgr (WMF) (talk) 07:43, 18 November 2017 (UTC)

Make Thanks and Undo links easier to distinguish

Edit proposal/discussion

  • Problem: Location of Undo proximity to Thank tool
  • Who would benefit: All Wikipedian Users
  • Proposed solution: Please relocate Thank tool away from Undo
  • More comments: It gives me headache when I accidentally clicked on diff one
  • Proposer: IM3847 (talk) 02:44, 9 November 2017 (UTC)

Discussion[edit]

Hi @IM3847:. Thanks for your proposal. Do you also have a location in mind where the "Thank" button can be moved to instead? -- NKohli (WMF) (talk) 21:15, 9 November 2017 (UTC)
Good idea. I have seen many complaints since notifications have been implemented from editors/users(?) who feel that notifications are used to harass them. BTW where can users find more about notifications and interact with the developers about them? Ottawahitech (talk) 14:24, 18 November 2017 (UTC) Please ping me</Smsll>

Release VE on Talk pages

Edit proposal/discussion

  • Problem: Currently VE is disabled on talk pages without any proper reason. This makes editing, especially for new users, more complicatted.
  • Who would benefit: Everyone, but especially new users.
  • Proposed solution: As I said in the headline: Simply enable VE on talk pages, it's possible.
  • More comments:
  • Phabricator tickets:

Discussion[edit]

Why do you need VisualEditor on talk pages? VisualEditor is for content editing, not for discussions. If you want to ease usage of talk pages for newcomers, you need Flow Structured Discussions. AFAIK, it can be turned on anywhere on request. --Tacsipacsi (talk) 22:47, 6 November 2017 (UTC)

Agreed. Structured Discussions is ideal for this. NMaia (talk) 23:27, 6 November 2017 (UTC)

Hey, VE here, although those, who want to push the weak forum impersonation Flow by prohibiting VE on talk pages claim it's impossible on such pages. I could even indent with colons, which they proclaim to be impossible with the VE. A wikipage is a wikipage is a wikipage.

No Flow is a bad way, it completely breaks the look and feel of wikipages and creates a deep rift between up to now all in all similar. It makes formerly flexible semi-structured discussions, that could easily be edited in different structures if needed, into completely inflexible forumesque pages, that lack proper structure in longer discussions. Flow is a dead-end-street, unfortunately ruthlessly pushed by some paid people inside the WMF, even with measures as denying VE on talk pages without any proper reason. Grüße vom Sänger ♫(Reden) 05:30, 7 November 2017 (UTC)

There are projects with VE enabled for project namespace = commuity discussions (Village pump etc.). And there are problems with formatting (VE uses <blockquote> instead of ::::. So VE should support discussion. JAn Dudík (talk) 08:28, 7 November 2017 (UTC)

I think this would be rather controversial, and thus I don't think it's a good one for the community tech team to take on. It's not the 'interpret what each community thinks about this'-team. —TheDJ (talkcontribs) 17:21, 7 November 2017 (UTC)

The persistent error is forgetting that a page-is-a-page, and that anything can appear anywhere. The error is the idea that "Article pages are supposed to be content edited in VE, and Talk pages are supposed to be chats edited in Flow". I am no fan of VE, but VE has valuable uses. If I want to edit a table on a talk page, it is extremely disruptive that VE is deliberately crippled to not allow it. I have to take the absurd workaround of copying the table to a non-talk page, pasting in the table to edit in VE, swapping to wikitext mode, copying the wikitext, quitting-without-saving, then returning to talk to paste in the edited table. Any and all "content" can be copied to talk pages to discuss and work on. The idea that talk pages don't contain "content" is just plain wrong. This error is one of the main reasons that Flow was such a flop. Flow was built on the idea that Talk pages are supposed to be chatboards. Talk pages are a wiki-workplace. Alsee (talk) 06:44, 8 November 2017 (UTC)

What about making it optional for those who want it to be? --Artix Kreiger (Message Wall) 15:30, 8 November 2017 (UTC)
Having preferences is technically cumbersome in comparison to giving everybody the same setting, I guess. I think that Flow is the better alternative although discussion should be had on removing infinite scroll, allowing it to use the same markup as regular wikiediting and offering assistance for people who e.g run archivebots and would need to modify their bots. Jo-Jo Eumerus (talk, contributions) 16:37, 8 November 2017 (UTC)
Flow is an extremely dumbed down, completely inflexible, single-purpose forum impersonation only suited for chit-chat, not for discussions about content, article structuring etc. The only asset it has is that it's shiny new bling, not boring maintenance of existing software, and that's why it's pushed by the WMF.
Unless Flow will one day be as flexible and as manageable as current wikipages, it's not worth anything. And a wikipage is a wikipage is a wikipage, regardless whether it's article-, user- or talk-page, all behave in the same way, all are editable in the same way, all have the same look-and-feel. Except the deliberate and hostile exemption of VE from talk pages. Grüße vom Sänger ♫(Reden) 16:53, 8 November 2017 (UTC)

I realise that Visual Editor is not going to die, but it make writing training material a nightmare. Take the instruction. Open the editor- until recently you has to open Edit source for the project page and Edit for the talk page. That has been fixed on (en). Lets look at an image- Add local description and Add local description source are the options on (en) but normally we will want to View on commons and here there is no option to use VE just the option Edit which here does what Edit source does on (en). So can I suggest that these issues are thought about before they are implemented- and the implications to other projects.

Further if I am on (de) I edit with Seite bearbeiten- but will wikiswitch to grab text such as a reference when replicating an article- (de) doesn't use VE so the obvious choice edit. So I am asking for the tabs to be consistent- Edit to mean edit everywhere and Visual edit used in the rare places where VE is allowed.--ClemRutter (talk) 20:52, 8 November 2017 (UTC)

  • I support this idea. At editathons I'm consistently seeing an increased willingness for non-scientists to engage with Wikipedia once I introduce them to VisualEditor. They stay and edit, only to be thrown off by the lack of a visual option on talk pages when they need to discuss something. If a Wikimedia project wants to enable VE for talk pages, let them do it. Deryck C. 22:13, 9 November 2017 (UTC)
  • I support this idea aswell. We do not need three ways to edit Wikipedia, two is enough. As this is controversial and we already have a VE team, this team may not be best to work on it though. Doc James (talk · contribs · email) 21:55, 13 November 2017 (UTC)
  • In Flow discussionpost can be edited in VE. The question remains in the indentation. VE automatically adds asterisk indentation by the Tab and the war of asterisks and colons will stop. And there is a new beta visual preview ... it would be interesting to compare versions use. --Sunpriat (talk) 09:50, 15 November 2017 (UTC)
    Wrong, not discussions can be edited in VE, only single posts can be edited in VE. There is no way to restructure a huge discussion, who answered whom is very hard to comprehend in huge discussions. Flow is only suitable for chitchat, not for real discussions. For real discussions flexible and adoptable talk pages are needed, and VE is only forbidden on talk pages to push Flow, no other valid reason was given. Grüße vom Sänger ♫(Reden) 16:34, 15 November 2017 (UTC)
    • Yes, it was a comparison with flow-posts. After VE (without Flow) for restructuring there is always a whole Wikitext page. --Sunpriat (talk) 18:09, 15 November 2017 (UTC)
  • This question is often brought up, despite the fact that I made the decision and documented it last year, in discussion with you. VisualEditor (VE) is designed to edit content — pages of prose, as used on Wikipedias, Wikiversities and Wikivoyages in particular, and to a lesser extent on other Wikimedia wikis. Every tool, every interaction, every habit is built to support that kind of editing, and thus make other kinds of editing harder. Providing users with an appropriate experience after enabling VE on talk pages would require major a rewrite of the software, and changes to the fundamentals of the editor which would make it worse for editing content. Either we would have the editor work in some mixture of code that works poorly for both, or we would add complexity, confusion and slowness by trying to act differently in different contexts, destroying user trust in the system "just working". There are definitely problems with the current ("legacy") discussion system, and I understand why people have problems with the structured discussions system too, but this "solution" doesn't fix either issue. We aren't going to ruin content editing to provide a shroud of bad discussion editing. Sänger, I know that you don't like my decision, but this isn't the way to convince me to change it. Jdforrester (WMF) (talk) 18:24, 15 November 2017 (UTC)
A wikipage is a wikipage is a wikipage, full stop. You have not delivered a single argument until now. Grüße vom Sänger ♫(Reden) 20:15, 15 November 2017 (UTC)
  • @Jdforrester (WMF): I am wondering if there is a clear strategy/plan to handle the community pages and discussion pages in the future. From your answer I don't see this, but I hope you (generally: people working on this area at WMF/voluntarily) do have a view. This is a question which comes up time to time, and we need a direction to go straight. Current situation (different editing experience/surfaces on different pages) is not optimal at all. Samat (talk) 23:58, 17 November 2017 (UTC)
    • I just realized that I can edit this page with VE. Isn't this page a "discussion page"? Samat (talk) 00:02, 18 November 2017 (UTC)
No, it's not. -- NKohli (WMF) (talk) 01:16, 18 November 2017 (UTC)
S/He, who can read, has a clear advantage ;) If I look at the header of this section, and look at what's done here, this is a discussion. But for those who desperately want the VE kept away from discussions, to push their pet project Flow, it cannot be one, that would be heresy. It's teh same with the new, completely unsubstantiated renaming of Flow to "Structured Discussions", as if current discussions were not structured. Of course they are, only in a more flexible way, restructurable according to the needs of the course of discussions, while Flow is an extreme rigid corset, suitable only for short chitchat. Grüße vom Sänger ♫(Reden) 10:12, 18 November 2017 (UTC)
  • Regardless of whether we eventually move to Flow, we need the facility now, both for article talk and for user talk-- and possibly for WP and WPTalk also. DGG (talk) 02:18, 20 November 2017 (UTC)

Auto format on save

Edit proposal/discussion

  • Problem:

The syntax of wiki source code can be formatted differently. If there would be a “coding guideline“ for wiki code, it would be uniform and easier to read. The coding guideline would affect both HTML syntax and wiki syntax. This would concern unneeded white space at the end of a line, spaces in tags or in table syntax, for example. The HTML parts of the source code could get consistent with XTHML.

  • Who would benefit:

every editor

  • Proposed solution:

When a edit is saved the source code will be formatted automatically accordind to the guideline. The coding guideline could be developed and applied incrementally.

  • More comments:
  • Phabricator tickets:

Discussion[edit]