Community Wishlist Survey 2015/Editing/nl

Voting has CLOSED! Thanks for your votes!

Color-coded WikiText editing

Tracked in Phabricator:
Task T101246

Tracked in Phabricator:
Task T104479

There have been some experiments around color-coded WikiText editing (including an English Wikipedia gadget and a working implementation in the Android app). This could be made into a real feature of the WikiEditor extension.

Earlier discussion and endorsements
Is it like mw:Extension:CodeMirror? --Pastakhov (talk) 17:40, 20 May 2015 (UTC) Yes I low the color coding of text that WikEd gives and miss it when I edit other languages. Sometimes I even work on text from other languages on En Wikipedia because we have better tools. We need a set of tools that the WMF will install on all Wikis that wish to opt in. Doc James (talk · contribs · email) 10:31, 21 May 2015 (UTC) @Doc James: actually you can install for yourself set of tools to be loaded globally. See mw:Help:Extension:GlobalCssJs. If you need some help, you can use my talk page here or @enwiki. --Edgars2007 (talk) 11:47, 12 November 2015 (UTC)  Endorsed 1 --AS (talk) 16:29, 27 May 2015 (UTC) This could be considered part of the "modern wikitext editor" project. Cscott (talk) 18:21, 11 November 2015 (UTC) Yes, the VisualEditor team is definitely planning on doing this as part of the modern wikitext editor project. However, it's not being actively worked on yet and probably won't be for another quarter or two. I leave it up to the Community Tech team whether to include it in their survey, but I don't think they want to take on things that other teams have fairly concrete plans to do :)—Neil P. Quinn-WMF (talk) 20:16, 11 November 2015 (UTC) Actually, let me clarify a couple of things. The project is to build a new wikitext editor with all these features (to avoid suddenly breaking users' workflows and gadgets). This wouldn't help people who strongly want to stick with the existing editor. In addition, syntax highlighting (within the context of a VE-like wikitext editor) is apparently more complex than it seems, and may have a negative impact on performance. So the new wikitext editor will probably include syntax highlighting, but it's not 100% certain, and it may be an opt-in preference rather than the default.—Neil P. Quinn-WMF (talk) 20:43, 11 November 2015 (UTC) I think it's actually *very* useful to include things in the community wishlist which are already on WMF roadmaps. As Neil notes, it's not a near-term project for the Visual Editor team. The community wishlist is an opportunity to rank all these different *community wishes* against each other. If this proposal ends up ranked high on the wishlist, the VE team perhaps should reprioritize their work. Conversely if it is low, they should perhaps continue to defer this. We need these feedback mechanisms to allow the community to weigh in on the priorities of WMF teams. Cscott (talk) 21:57, 18 November 2015 (UTC)  Endorsed--Shizhao (talk) 07:59, 12 November 2015 (UTC)  Endorsed --Edgars2007 (talk) 11:47, 12 November 2015 (UTC)  Endorsed WikiText editor one of features most used by editors is not improved at all. Syntax highlighting is feature from the 1980's, but still missing in MediaWiki in the 2010's, 30 years after --Ilya (talk) 20:06, 15 November 2015 (UTC)  Endorsed--Lsanabria (talk) 12:19, 20 November 2015 (UTC)

Stemmen

1.  Support When helping new editors the first thing I tell them to turn on is the syntax highlighting extension. Samwalton9 (talk) 10:09, 30 November 2015 (UTC)
2.  Support --Patrick87 (talk) 18:05, 30 November 2015 (UTC)
3.  Support --Isacdaavid (talk) 02:14, 1 December 2015 (UTC)
4.  Support The very useful en.WP syntax highlighter has some very old cosmetic bugs and chokes on pages that are too large. Jonesey95 (talk) 05:04, 1 December 2015 (UTC)
5.  Support--Shizhao (talk) 09:17, 1 December 2015 (UTC)
6.  Support —Ynhockey (talk) 09:48, 1 December 2015 (UTC)
7.  Support —Tito☸Dutta 14:44, 1 December 2015 (UTC)
8.  Support --Arnd (talk) 14:44, 1 December 2015 (UTC)
9.  Support tufor (talk) 15:28, 1 December 2015 (UTC)
10.  Support Flinga (talk) 16:19, 1 December 2015 (UTC)
11.  Support It's hard for me to edit without this. Stevie is the man! ^{Talk • Work} 16:31, 1 December 2015 (UTC)
12.  Support just like dreamweaver.--Temp3600 (talk) 16:39, 1 December 2015 (UTC)
13.  Support --Urbanecm (talk) 17:42, 1 December 2015 (UTC)
14.  Support --Etamni (talk) 18:03, 1 December 2015 (UTC)
15.  Support --Woodcutterty (talk) 18:54, 1 December 2015 (UTC)
16.  Support --Wesalius (talk) 18:59, 1 December 2015 (UTC)
17.  Support --Fritzmann2002 (talk) 19:19, 1 December 2015 (UTC)
18. Neutral --Usien6 (talk) 19:22, 1 December 2015 (UTC) // As long as editors could opt-out.
19.  Support Helder 23:48, 1 December 2015 (UTC)
20.  Support Rdrozd (talk) 00:24, 2 December 2015 (UTC)
21.  Support --Ilya (talk) 12:45, 2 December 2015 (UTC)
22.  Support, would make wikicode easier to understand. And especially think of highlighting all curly brackets as counting them manually is annoying — NickK (talk) 13:53, 2 December 2015 (UTC)
23.  Support--Manlleus (talk) 15:14, 2 December 2015 (UTC)
24.  Support --AlessioMela (talk) 19:45, 2 December 2015 (UTC)
25.  Support Mule hollandaise (talk) 21:07, 2 December 2015 (UTC)
26.  Support --JQTriple7 (talk) 23:26, 2 December 2015 (UTC)
27.  Support --MisterSanderson (talk) 04:52, 3 December 2015 (UTC)
28.  Support --AS (talk) 09:36, 3 December 2015 (UTC)
29.  Support --Aryan hindustan (talk) 10:30, 3 December 2015 (UTC)
30.  Support: This will make editing a lot easier.--Bowleerin (talk) 11:23, 4 December 2015 (UTC)
31.  Support Nikkimaria (talk) 01:33, 4 December 2015 (UTC)
32.  Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
33. Neutral: I would support the idea, except w:Wikipedia:WikiEd is already there, I'm using it and it works great. The only thing it doesn't do is highlighting the corresponding brackets (per what User:NickK wrote above Halibutt (talk) 00:00, 5 December 2015 (UTC)
34.  Support --Ricordisamoa 01:15, 5 December 2015 (UTC)
35.  Support Ardfeb (talk) 00:53, 6 December 2015 (UTC)
36.  Oppose - Not opposed to the idea, but to using the wishlist for this. As noted in the "earlier discussion" WMF is going to do this anyway, and it's not something that I think should take precedence from some of the other ideas on the wishlist that would not otherwise be completed [to get it done sooner?]. — Rhododendrites ^talk \\ 17:29, 6 December 2015 (UTC)
37.  Oppose. Yes I want this, but this is not a Community Tech project per Rhododendrites and Neil P. Quinn-WMF. MER-C (talk) 18:10, 6 December 2015 (UTC)
38.  Support Mpn (talk) 18:22, 7 December 2015 (UTC)
39.  Support --Waldir (talk) 14:50, 8 December 2015 (UTC)
40.  Support - Bcharles (talk) 04:13, 9 December 2015 (UTC)
41.  Support Therud (talk) 09:22, 10 December 2015 (UTC)
42.  Support Lsanabria (talk) 15:22, 10 December 2015 (UTC)
43.  Support --Edgars2007 (talk) 08:59, 12 December 2015 (UTC)
44.  Support --NaBUru38 (talk) 03:37, 13 December 2015 (UTC)
45.  Support in the form of some upgrades and bugfixes for w:Wikipedia:WikiEd, in full collaboration with en:User:Cacycle, so that they are happy with the help.  :-)     Specifically, besides lack of bracket-flashers, WikiEd is limited to supporting only desktop browsers (Chrome/Firefox/Safari plus maybe Opera), but does not support Internet Explorer, which still is used by a good-sized chunk of internet denizens. Furthermore, I don't believe there is any special support for mobile browsers, used when doing mobile editing. Because wikiEd generates a custom iframe, it would be a boon were it to be customized for this use-case: entering template-related punctuation for refs and infoboxen, for instance, would be something that could be helpfully improved so that mobile editors don't need to mess with their vkeyb endlessly (or just give up and stop clicking edit). And sure, it is true that Someday there are some plans that the WMF will be working on a Visual-Editor-like-wikitext-editor. But that is an entirely different thing. We already have a default wikitext-editor, the simple <textarea> of the mid-1990s. We already have a syntax-highlighting purely-browser-based improvement on that classic, w:Wikipedia:WikiEd, which is javascript-only <iframe>-based and thus even supports anons, if it were only available as a toggle-on toggle-off default feature of the 'pedia. You can switch back and forth from <textarea> to wikiEd-<iframe>. And yeah, someday there will be the VE-compatible-wikitext thing, which will allow you to switch from visual-editing of WYSIWYG to visual-editing of wikitext. But why wait, when we can upgrade wikiEd, with a laser-focus effort today, to make it site-wide rather than a manually-enabled-gadget or a manually-installed-greasemonkey-script? Think of it as a prototype, which will help field-test what actual wikipedians doing actual wikitext editing, will actually *want* to see in the future VE-style thing. 75.108.94.227 21:52, 13 December 2015 (UTC)

Default user interface mode

People who have been editing for a long time often have highly personalised interfaces, and also have access to a variety of tools/rights that aren't available to new users. These are both important things, but it does make it difficult for existing users to understand the issues facing new users. A practical example of this is, when giving presentations to new users at outreach events, many Wikimedians create a 'fake' user account specifically to be able to show the 'default' user interface on the screen to the newbies. Importantly, the presenter never actually presses 'save' when showing how to edit, because then this user account would get the auto-confirmed userright.

I propose the creation of a user preferece 'mode' that makes both the user-interface and user-rights the "default" for a newly signed-up user. Call it "new user mode", or "default mode". Crucially, editing in this mode would mean that the user WOULD NOT become 'auto confirmed' when they save their edits but WOULD still count the change in their editcount. It could be marked in the history with a #defaultMode tag or something.

Wittylama (talk) 10:27, 21 November 2015 (UTC)

Earlier discussion and endorsements
Wouldn't it be easier to have a preference setting "incognito", which when on, just strips all preferences to the defaults? I think it is best to be able to act as yourself whenever possible. I understand the need, but it should be doable without an extra account. Alternatively, there could be a "Newbie" account that is not a real account (i.e. cannot save edits). This would be a variation of the sandbox theme. --Jane023 (talk) 14:35, 21 November 2015 (UTC) I think that a preference setting called "incognito" implies that you're editing with the user-rights of an anon/IP editor (which is different form a newly registered/non-autoconfirmed editor). Also, "incognito" is a term used in some browsers that implies certain differences regarding privacy and tracking. I think that the word therefore sets an incorrect impression for the user about what it would mean, people might think that "being incognito" means they could leave messages without being identified by either their username or their IP, which isn't true. When you say "it should be doable without an extra account" - yes, precisely. That's what I'm hoping for. Currently, for people to see the default interface they either have to create a new user account, or log-out and edit as an anon, both are sub-optimal approaches. What I'm suggesting is a mode that works while logged-in to your existing user-account. The "newbie" account that cannot actually save an edit is also sub-optimal for that very reason. Wittylama (talk) 09:06, 22 November 2015 (UTC)  Endorsed OK, got it now. --Jane023 (talk) 10:15, 22 November 2015 (UTC)  Endorsed In addition, it could be useful for testing an abuse filter. In many cases, there's a condition like user_age <= 900 which may be fulfilled by a "new user mode". -- Juetho (talk) 10:22, 22 November 2015 (UTC)

Stemmen

1. Oppose this won't really take the place of using a fresh account if that is what is trying to be demonstrated. (e.g. Having to solve captcha's, redlinking your own pages, etc). xaosflux ^Talk 00:22, 1 December 2015 (UTC)
2.  Oppose I sympathize with the rationale for this proposal, but I think coding it up will be rather complicated, with some unknown ramifications. The current workaround of creating a new, 'fake' account doesn't seem unreasonable. At best, this should be a very low priority. Stevie is the man! ^{Talk • Work} 16:52, 1 December 2015 (UTC)

   I understand your perspective Stevietheman. I just wanted to emphasise that the 'fake' user account method has the specific drawbacks that by saving edits it will become auto-confirmed and therefore move away from being a 'new' user account, and it also means that the presenter is forking their contributions (and therefore attributions). Wittylama (talk) 20:51, 3 December 2015 (UTC)

   I agree those are drawbacks. Nevertheless, it doesn't take much work to create a fake account on the rare occasions one needs one. Also note that on someone else's new account one may be mentoring, they will also become auto-confirmed in short order. Overall, while I can see the benefits of this proposal, I think the development effort required to fully deal with all the ramifications keeps me at an 'Oppose', especially with all the other proposals that we need much more. Stevie is the man! ^{Talk • Work} 17:59, 4 December 2015 (UTC)

3.  Support Szalakóta (talk) 16:50, 1 December 2015 (UTC)
4. Why not, instead, an option under "gadgets" that, when checked, overrides all other preferences/javascript/whatnot? Eman235/talk 21:16, 1 December 2015 (UTC)
5.  Support As a presenter, I understand the idea. That would be very useful but as Stevietheman has already pointed out, I think it would be rather difficult to implement. Litlok (talk) 08:19, 2 December 2015 (UTC)
6.  Support – Established editors training new users do need to be reminded what their trainees are going to be looking at when they're setting up new accounts; a "new user mode" sounds perfect, assuming it's possible to implement such a thing. The muddle resulting from the trainer's having a different interface must be off-putting to new users. Ham II (sgwrs / talk) 19:09, 2 December 2015 (UTC)
7.  Support Nikkimaria (talk) 01:33, 4 December 2015 (UTC)
8.  Support an option that would disable all custom js and css. -- Fauzan^{✆ talk} _{✉ email} 16:45, 4 December 2015 (UTC)
9.  Support Juetho (talk) 11:57, 12 December 2015 (UTC)
10.  Support This sounds like a useful idea but if it is as difficult as some people think it should not be a high priority. I would hope they would be a relatively easy way of creating such an option if so it would be worthwhile.--Sphilbrick (talk) 23:14, 12 December 2015 (UTC)

Enable Apertium on cy, for Content Translation

Tracked in Phabricator:
Task T102101

Content Translation does NOT work on cy; it's sitting there redundant, twiddling its thumbs. Enabling Apertium would mean it would be useable. Here's a discussion which leads to a cul-de-sac. Let's address this problem and enable en -> cy translation.

Llywelyn2000 (talk) 12:09, 20 November 2015 (UTC)

Earlier discussion and endorsements
@Runab WMF: in the above link mentions either enabling Apertium or "get a Moses setup in place". Either Apertium or Moses, but at the moment, it's neither! To quote Runab: "We do want to get it started again and would be really grateful if you know someone who can help us speed up the process. At present we are a little short on time and people to take up the challenge to get a Moses setup in place." Llywelyn2000 (talk) 07:18, 21 November 2015 (UTC) Further info here. Llywelyn2000 (talk) As that article mentions, it is a "“gisting” machine translation system for Welsh to English" – someone who knows Welsh would have to actually get involved with Apertium in order to create e.g. transfer rules for the other direction (currently, there are 144 transfer rules cy→en, but only 13 en→cy). If anyone is interested in getting involved with developing an en→cy translator, please get in touch! --Unhammer (talk) 12:46, 23 November 2015 (UTC) … and this would be a good time if anyone is/knows a high school student willing to get involved, since Apertium is now in the Google Code-In competition. --Unhammer (talk) 07:22, 24 November 2015 (UTC)  Endorsed -- Oergell (talk) 12:41, 20 November 2015 (UTC)  Endorsed -- Cymrodor (talk) 17:16, 20 November 2015 (UTC)  Endorsed -- Dafyddt (talk) 15:32, 20 November 2015 (UTC)  Endorsed -- AlwynapHuw (talk) 23:39, 20 November 2015 (UTC)  Endorsed -- Pwyll (talk) 11:20, 21 November 2015 (UTC)  Endorsed – Ham II (sgwrs / talk) 21:57, 21 November 2015 (UTC)

Stemmen

1.  Support --Isacdaavid (talk) 02:13, 1 December 2015 (UTC)
2.  Support --[Google works en - > cy, but is full of errors; NOT an option!] Llywelyn2000 (talk) 15:08, 1 December 2015 (UTC)
3.  Support Litlok (talk) 08:20, 2 December 2015 (UTC)
4.  Support Jason.nlw (talk) 09:59, 2 December 2015 (UTC)
5.  Support EdwardLane (talk) 11:37, 2 December 2015 (UTC)
6.  Support --Drgkl (talk) 11:53, 2 December 2015 (UTC)
7.  Support --Barcelona (talk) 11:54, 2 December 2015 (UTC)
8.  Support Cymrodor (talk) 12:56, 2 December 2015 (UTC)
9.  Support – Ham II (sgwrs / talk) 19:11, 2 December 2015 (UTC)
10.  Support, obviously. Eman235/talk 21:15, 2 December 2015 (UTC)
11.  Support AlwynapHuw (talk) 05:43, 3 December 2015 (UTC)
12.  Support - tucoxn\^talk 14:04, 3 December 2015 (UTC)
13.  Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
14.  Support --Rhyswynne (talk) 21:12, 4 December 2015 (UTC)
15.  Oppose Insufficient impact -- only affects a small number of wikis at best. MER-C (talk) 18:28, 6 December 2015 (UTC)
16.  Support - It's important to support smaller languages, and this one is well-covered by volunteers and has a local chapter to help support events there. Richard Symonds (WMUK) (talk) 14:46, 7 December 2015 (UTC)
17.  Oppose Content Translation is not for machine translation. It's only an auxiliary feature. On ukwiki we don't have machine translation either, but our translators use Content Translation quite often - as a UI that helps to do simple jobs like adapting links and references etc - so you generally don't really need machine translation, the CX is quite usable (unless it's as buggy as it used to be, which I doubt). Besides, the implementation of this would have local impact only. --Piramidion 12:34, 12 December 2015 (UTC)

Generate automatic summary /* blah */ when I manually add a section heading when editing

Tracked in Phabricator:
Task T22307

See the Phabricator request (linked in the right margin). This would be particularly helpful on talk pages. Seems like a relatively easy task. Maybe after sitting on the wishlist for six years someone can be assigned to it. Thanks,

Wbm1058 (talk) 14:53, 16 November 2015 (UTC)

Earlier discussion and endorsements
Endorsed Having the wrong section indicated is worse than having no section indicated at all. Swpb (talk) 19:50, 17 November 2015 (UTC)  Endorsed --Jane023 (talk) 10:47, 20 November 2015 (UTC)  Endorsed I really hate when it indicates the wrong section! --Alexmar983 (talk) 19:47, 23 November 2015 (UTC)

Stemmen

1.  Support I don't think it's a huge time sink to change your edit summary manually, but this would be a nice feature. Samwalton9 (talk) 10:13, 30 November 2015 (UTC)
2.  Support Jenks24 (talk) 10:23, 30 November 2015 (UTC)
3.  Support. --Stryn (talk) 18:55, 30 November 2015 (UTC)
4.  Support Dalba 20:21, 30 November 2015 (UTC)
5.  Support Szalakóta (talk) 16:52, 1 December 2015 (UTC)
6.  Support in clear cases where the new section is the beginning of what's inserted. Stevie is the man! ^{Talk • Work} 16:59, 1 December 2015 (UTC)
7.  Support -- 2ReinreB2 (talk) 17:19, 1 December 2015 (UTC)
8.  Support -- Grüße vom Sänger ♫^(Reden) 22:12, 1 December 2015 (UTC)
9.  Support Risker (talk) 03:46, 2 December 2015 (UTC)
10.  Support —Beleg Tâl (talk) 17:09, 2 December 2015 (UTC)
11.  Support – Ham II (sgwrs / talk) 19:12, 2 December 2015 (UTC)
12.  Support I tend to do this manually, but hardly anyone else does. Eman235/talk 21:16, 2 December 2015 (UTC)
13.  Support --Carrotkit (talk) 05:49, 3 December 2015 (UTC)
14.  Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
15.  Support --Jane023 (talk) 16:29, 4 December 2015 (UTC)
16.  Support - Doesn't save most of the people voting here much time, but that's not the point. The point is that there are lots of newbies and people who don't do this that affect our ability to determine the subject of comments on busy talk pages. — Rhododendrites ^talk \\ 17:33, 6 December 2015 (UTC)
17.  Support as proposer. Wbm1058 (talk) 19:06, 7 December 2015 (UTC)
18. Comment - It could be difficult to differentiate between edits where the new section is the full edit, and those where it is among other edits to other sections of the article. Bcharles (talk) 04:23, 9 December 2015 (UTC)
19.  Support Therud (talk) 09:23, 10 December 2015 (UTC)
20.  Support QuartierLatin1968 (talk) 04:38, 12 December 2015 (UTC)
21. Neutral. It could be useful in some cases but not sure it does not have negative consequences in some other cases. Beagel (talk) 14:56, 12 December 2015 (UTC)

Halve edit conflicts

Tracked in Phabricator:
Task T72163

We all get edit conflicts, those of us who have stayed on wikipedia are largely those who have learned to resolve them, or to do lots of little edits in order to minimise the time lost when we get an edit conflict. There have been many proposals on bugzilla and elsewhere to reduce edit conflicts, but they haven't had resource as keeping new editors didn't use to be a priority. But this is one of the things that new editors find most bitey about wikipedia, and usually it is the newbie who loses the edit conflict because they are taking minutes on their edit and the categoriser or templater only seconds. (V/e of course makes this worse by getting rid of section editing and slowing editors down.)

Currently we don't even have public statistics on number of editors lost through edit conflicts. Simply measuring them and the number of times they predict an editor leaves would either confirm this was one of the biggest causes of good new editors leaving, but actually fixing some of the things that cause edit conflicts would likely take as little resource.

Getting rid of all edit conflicts would require a revolutionary change in the user interface, but halving edit conflicts would take a fairly minor investment.

Specific ways to reduce edit conflicts include:

1. Treat the addition of a template at the top of an article or a category at the end as not conflicting with the alteration of the contents in between.
2. Pre populate all newly created articles with sections such as ==References== and ==See also== or equivalents in other languages
3. Treat # the same as a section heading so two replies in two different threads of the same section would not be treated as a conflict.

WereSpielChequers (talk) 20:54, 10 November 2015 (UTC)

Earlier discussion and endorsements
Obvious  Endorsed. MER-C (talk) 21:36, 10 November 2015 (UTC)  Endorsed Great idea! ONUnicorn (talk) 23:09, 10 November 2015 (UTC) Related: phab:T108664 ("Interactive edit conflict resolution tool") Cscott (talk) 19:33, 11 November 2015 (UTC) Proposal (1) sounds simple enough. (2) is probably not a good idea. (3) should be obviated by Flow. Swpb (talk) 19:42, 17 November 2015 (UTC)  Endorsed Huge wall for newcomers, and for others too. Three-way diff on conflict could help experienced editors there. — Arkanosis ✉ 16:30, 18 November 2015 (UTC)  Endorsed 4nn1l2 (talk) 23:28, 18 November 2015 (UTC)

Stemmen

1.  Support 4nn1l2 (talk) 03:07, 30 November 2015 (UTC)
2.  Support I imagine there are even more methods which could be used to avoid edit conflicts, but the examples given here are a great start. Samwalton9 (talk) 10:08, 30 November 2015 (UTC)
3.  Support - anything we can do to reduce the potential causes of edit conflicts can only be a plus, provided that it doesn't take any noticeable amount of time or hog too much system resources. עוד מישהו Od Mishehu 16:10, 30 November 2015 (UTC)
4.  Support I don't want to prioritize edit conflicts too highly; maybe I've been lucky or maybe I'm editing the wrong places but they don't happen all that often. Annoying when they do and I understand how offputting they could be to a new editor. That said I see the potential for some low hanging fruit. Item 1 sounds relatively simple and straightforward. Item 2 has benefits beyond resolving edit conflicts. I support those two items and other items if relatively simple.--Sphilbrick (talk) 16:58, 30 November 2015 (UTC)
5.  Support Not too sure about #2 (although have no strong prejudice against it), but the others both seem like good ideas. — Bilorv (talk) 19:44, 30 November 2015 (UTC)
6.  Support --MGChecker (talk) 20:01, 30 November 2015 (UTC)
7.  Support MER-C (talk) 20:05, 30 November 2015 (UTC)
8.  Support Dalba 20:29, 30 November 2015 (UTC)
9.  Support Armbrust (talk) 22:41, 30 November 2015 (UTC)
10.  Support - Nothing annoys me more than edit conflicts (Especially if you're replying to someone at ANI and end up getting 6 edit conflicts!), It drives me mad and although I don't think anything can really be done I guess it would be nice if something could be done. –Davey2010^Talk 02:56, 1 December 2015 (UTC)
11.  Support Oh goodness, yes. Edit conflicts are a pain, and I know I cause them with my quick gnome edits, causing pain to someone who is actually trying to add valuable content to an article. Jonesey95 (talk) 05:07, 1 December 2015 (UTC)
12.  Support--Shizhao (talk) 09:20, 1 December 2015 (UTC)
13.  Support · · · Peter (Southwood) ^(talk): 14:00, 1 December 2015 (UTC)
14.  Support —Tito☸Dutta 14:45, 1 December 2015 (UTC)
15. Neutral Question: pre populate with references and see also, when there are no such content in the article? I'm sceptical about that, that's nothing that's done on svwp at least. Suggestion: there was another suggestion, I believe, about adding the headline "references" (and equivalents in other languages) when someone had added a <references />-tag, or similar. Or was it to add such a tag (and header) when someone had added ref-tags? Those are not bad suggestions at least, why not the latter? Afaik ref-s are auto-displayed if a finishing references-tag is missing, but why not perhaps auto-adding? 78.82.170.236 15:41, 1 December 2015 (UTC) (who btw just got an edit conflict.. :) But I was slow.) edit: that comment was me, somehow I was logged out.. Flinga (talk) 15:45, 1 December 2015 (UTC)
16.  Support --Andyrom75 (talk) 15:57, 1 December 2015 (UTC)
17.  Support Papuass (talk) 16:23, 1 December 2015 (UTC)
18.  Support Goombiis (talk) 16:26, 1 December 2015 (UTC)
19.  Support 1 as stated and 3 modified to include * (if not treated as a separate section already -- I'm not sure).  Oppose 2 bitterly as it would create multitudinous empty sections that would make the Wikipedia look like crap. I'm open-minded to other low-hanging fruit. Stevie is the man! ^{Talk • Work} 17:11, 1 December 2015 (UTC)
20.  Support -- Tisfoon (talk) 17:46, 1 December 2015 (UTC)
21.  Support --Warp3 (talk) 18:00, 1 December 2015 (UTC)
22. Partial  Oppose. I disagree with the point 2: Pre populate all newly created articles with sections such as ==References== and ==See also== or equivalents in other languages. I support the remaining two points. Jan.Kamenicek (talk) 18:46, 1 December 2015 (UTC)
23.  Support Artem.komisarenko (talk) 19:37, 1 December 2015 (UTC)
24.  Support point 1 and 3, not point 2. Gap9551 (talk) 20:04, 1 December 2015 (UTC)
25.  Support StevenJ81 (talk) 21:59, 1 December 2015 (UTC)
26.  Support Alkamid (talk) 07:37, 2 December 2015 (UTC)
27.  Support Especially #1. ...Aurora... (talk) 10:39, 2 December 2015 (UTC)
28.  Support : support points 1 and 3 but not point 2, many communities do not agree to add empty sections for the sake of having them for future — NickK (talk) 14:29, 2 December 2015 (UTC)
29. I  Support working on reducing edit conflicts but I strongly  Oppose the point 2. Matěj Suchánek (talk) 15:46, 2 December 2015 (UTC)
30.  Support Needs careful implementation, but would make life a lot easier for many editors. PamD (talk) 21:35, 2 December 2015 (UTC)
31.  Support #1 and 3 and anything else people come up with to reduce edit conflicts. Neutral about #2 (auto-inserting section headers). --Anypodetos (talk) 08:20, 3 December 2015 (UTC)
32.  Support Not convinced by #2, though. Three-way diff would be another valid approach. — Arkanosis ^✉ 13:55, 3 December 2015 (UTC)
33.  Support - tucoxn\^talk 14:05, 3 December 2015 (UTC)
34.  Support edit conflicts are one annoying feature. Graeme Bartlett (talk) 04:16, 4 December 2015 (UTC)
35.  Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
36.  Support Grüße vom Sänger ♫^(Reden) 17:20, 4 December 2015 (UTC)
37.  Support Lester לסטר (talk) 18:04, 5 December 2015 (UTC)
38.  Support the general idea, which addresses a major problem for new users, without wanting to get into the specific "how" myself (certainly not #2, but I imagine there are plenty of ways to go about this) — Rhododendrites ^talk \\ 17:36, 6 December 2015 (UTC)

    Comment. I'd support any proposal to reduce edit conflicts, though this one is fairly minor. I have had many edit conflicts over the years, but I don't recall any of them being because of the addition of a template at the top of the article or a category at the bottom. The one that bugs me the most is bots coming in to do something very minor (such as adding a date on an existing template - usually inline). I would support the notion that certain low maintenance bot edits do not trigger edit conflicts. But surely, better than that, would be an automatic note that popped up if you went to edit an article, and someone was already editing it. A note saying: "User:XXX is currently editing this article so any edits you make will result in an edit conflict, please try again in a few moments. If you continue to have problems, you may wish to contact User:XXX". As with some others, I am not certain about point 2. While I feel adding a reference section to article pages is useful, I am not convinced that every article needs a See also section. SilkTork (talk) 09:19, 9 December 2015 (UTC)

    From reading the instructions, non support comments are not counted, so I have indented my comment so it isn't counted. SilkTork (talk) 09:23, 9 December 2015 (UTC)

39.  Support --Ziko (talk) 13:51, 9 December 2015 (UTC)
40.  Support --Ochilov (talk) 15:18, 9 December 2015 (UTC)
41.  Support except #2 -- Juetho (talk) 11:57, 12 December 2015 (UTC) Comment Each project (Wikipedia, Wikibooks, Wikisource, etc.) has its own conventions to start a page. One project or portal may pre populate, but not via software.
42.  Support the proposal in general. But the description of the issue is a bit inaccurate. This may not be true for the newbies, but as for me, when I get an edit conflict, that's not a problem nearly at all. Of course, it consumes a few seconds and might be annoying, but I never lose my text. If I get a conflict, nothing prevents me from going back in my browser to copy what I've typed, and then pasting it where I intended to. Yes, newbies might not know these «workarounds», so that's really a problem for them. But I really don't understand why should an experienced editor need «to do lots of little edits in order to minimise the time lost» - I could rewrite a whole article in one edit without being afraid that an edit conflict takes place. It's just confusing that there might be experienced contributors that don't know such simple things.--Piramidion 11:55, 13 December 2015 (UTC)
43.  Support, because I often make large edits, which touch a half-dozen places (or more). If somebody has messed with *any one* of those places, e/c. And sure, I can manually find the five places where there *was* not actually a conflict... but that the "overly-cautious" mediawiki software prevented me from saving... and redo them, along with the one bit that actually caused the edit-conflict. I can imagine that VE-users will experience equally bad results, especially as they are starting to get ambitious. Imagine you are a beginning editor. Making a few typo-corrections, gives you a sense of accomplishment. So you start working on bigger changes. You are a good potential wikipedian, so you think hard about them, and you are a beginner at wikitext, so it takes you several preview-cycles to get it exactly right. Finally, your first major edit (or 2nd or 3rd or 4th... but not 1000th... you will get a LOT of edit-conflicts before you hit 1000 edit-count, especially if you make LARGE or complex edits). You click save. Edit conflict! Gumption trap. As for experienced editors, smarter software that doesn't have edit-conflicts will save them some time and annoyance; not much, just a few seconds and a slight amount of annoyance... but multiply the savings across ALL the long-haul highly-active editors, and you have improved efficiency... plus more importantly, morale. 75.108.94.227 22:04, 13 December 2015 (UTC)
44. Neutral I think a better edit conflict UI is the lower-hanging fruit (T108664) --Tgr (talk) 22:45, 13 December 2015 (UTC)

Improved diff compare screen

Tracked in Phabricator:
Task T15466

Tracked in Phabricator:
Task T15462

Don't you just love diffs like this one. It must be possible to improve this diffcompare-view. For inspiration you can look at the wikEdDiff gadget. http://i.imgur.com/R9ZfCA1.jpg

The Quixotic Potato (talk) 06:41, 29 September 2015 (UTC)

[Combined from separate proposal:] When someone moves a paragraph and then edits it, this edit is not shown separately by the "Difference between revisions" functionality. This problem also occurs when someone inserts a blank line above a paragraph and then edits it. Thanks,

--Gnom (talk) 10:12, 12 November 2015 (UTC)

Earlier discussion and endorsements
@The Quixotic Potato: or cleanDiff, which is more like Wikimedia edit diff. Screenshot. --Edgars2007 (talk) 03:17, 3 November 2015 (UTC)  Endorsed Related: phab:T108664 ("Provide an interactive edit conflict resolution tool"), phab:T26617 ("Implement diff on sentence level"). cscott (talk) 18:30, 11 November 2015 (UTC)  Endorsed Very important. WikEdDiff already exists and the only thing that needs to be done is to make it work with the button "Show changes" while editing, right now this only works if the whole WikEd is enabled (then there is a separate button for WikEdDiff). --V111P (talk) 23:22, 12 November 2015 (UTC) @V111P: Not true. You can enable WikEdDiff separately: w:en:User:Cacycle/wikEdDiff. --Edgars2007 (talk) 06:48, 14 November 2015 (UTC) @Edgars2007: I know, but it doesn't work when editing, with the WikEdDiff gadget you can't see what changes you made before saving, so it's not a full replacement for WikEd. We use scripts for formatting and need to be able to look at the changes before saving. I already asked Cacycle on WikEdDiff's talk page about that, but don't know if and when I'll get a response. --V111P (talk) 09:30, 14 November 2015 (UTC) OK, thanks. Didn't notice that. --Edgars2007 (talk) 09:58, 14 November 2015 (UTC)  Endorsed improvements to diff. My pet peeve is when diff gets confused and lists unchanged paragraphs as both - and text. It would also be nice if diff were smart enough to avoid cutting two <tags> in half (start and endpoints of diff-text inside tags) when it would be much cleaner to align on the tag boundary. I'm sure there's a lot that could be improved if diffs were targeted as a project. Alsee (talk) 20:22, 14 November 2015 (UTC)  Endorsed. This sounds like a good idea, since I think it would be a very useful improvement. Would this include improving the diff when removing empty lines, or when moving sections, as in the suggestion below? That would not the least be a useful feature, to the extent that it is possible to achieve. Flinga (talk) 16:43, 17 November 2015 (UTC)  Endorsed 4nn1l2 (talk) 23:24, 18 November 2015 (UTC) @Gnom: answer to your problem is w:en:User:Cacycle/wikEdDiff. --Edgars2007 (talk) 06:50, 14 November 2015 (UTC) Hi, Edgars2007, there are also other user scripts that address this problem. I would like to see one of these solutions integrated into MediaWiki. --Gnom (talk) 09:36, 14 November 2015 (UTC)

Stemmen

1.  Support 4nn1l2 (talk) 03:06, 30 November 2015 (UTC)
2.  Support Smarter/better diffs would be valuable. Digging through a poor diff can be slow and painful. Alsee (talk) 08:42, 30 November 2015 (UTC)
3.  Support This can be a real pain, especially when something as simple as a new paragraph throws it off, highlighting the entire thing. Samwalton9 (talk) 10:05, 30 November 2015 (UTC)
4.  Support Jenks24 (talk) 10:21, 30 November 2015 (UTC)
5.  Support MER-C (talk) 10:47, 30 November 2015 (UTC)
6.  Support --Gnom (talk) 12:00, 30 November 2015 (UTC)
7.  Support Lugnuts (talk) 12:03, 30 November 2015 (UTC)
8.  Support Badly needed. Debresser (talk) 12:59, 30 November 2015 (UTC)
9.  Support MrX (talk) 15:10, 30 November 2015 (UTC)
10.  Support --Sphilbrick (talk) 16:25, 30 November 2015 (UTC)
11.  Support BethNaught (talk) 17:45, 30 November 2015 (UTC)
12.  Support Tryptofish (talk) 18:12, 30 November 2015 (UTC)
13.  Support. --Stryn (talk) 18:59, 30 November 2015 (UTC)
14.  Support --MGChecker (talk) 20:00, 30 November 2015 (UTC)
15.  Support Dalba 20:28, 30 November 2015 (UTC)
16.  Support Matiia (talk) 20:29, 30 November 2015 (UTC)
17.  Support Voll (talk) 22:06, 30 November 2015 (UTC)
18.  Support Armbrust (talk) 22:42, 30 November 2015 (UTC)
19.  Support --Isacdaavid (talk) 02:17, 1 December 2015 (UTC)
20.  Support YES --Yodin^T 02:24, 1 December 2015 (UTC)
21.  Support per Samwalton9 - The amount of times I've come across edits like the above and despite sitting there for 5 whole minutes trying to figure out what the hell's changed you still can't figure it out, An improvement to this would help us all I think. –Davey2010^Talk 03:01, 1 December 2015 (UTC)
22.  Support Please. Doug Weller (talk) 09:42, 1 December 2015 (UTC)
23.  Support The diff screen should be much smarter. The example linked by the proposer is all too common, especially when non-ASCII characters are involved. Jonesey95 (talk) 05:09, 1 December 2015 (UTC)
24.  Support Casliber (talk) 05:11, 1 December 2015 (UTC)
25.  Support--Kippelboy (talk) 05:35, 1 December 2015 (UTC)
26.  Support - I think this is something many users will enjoy! Alleycat80 (talk) 09:02, 1 December 2015 (UTC)
27.  Support--Gbeckmann (talk) 09:18, 1 December 2015 (UTC)
28.  Support —Ynhockey (talk) 09:48, 1 December 2015 (UTC)
29.  Support - I'd also like to see an option to view a simple diff - one that just shows the article text without the wiki markup. --Anthonyhcole (talk) 10:07, 1 December 2015 (UTC)
30.  Support And make the line numbers actually mean something usable. · · · Peter (Southwood) ^(talk): 14:02, 1 December 2015 (UTC)
31.  Support --Arnd (talk) 14:45, 1 December 2015 (UTC)
32.  Support --Continua Evoluzione (talk) 14:52, 1 December 2015 (UTC)
33.  Support--KRLS (talk) 15:13, 1 December 2015 (UTC)
34.  Support – Haltiamieli (talk) 15:17, 1 December 2015 (UTC)
35.  Support — Quoth (talk) 15:19, 1 December 2015 (UTC)
36.  Support tufor (talk) 15:29, 1 December 2015 (UTC)
37.  Support --Nastoshka (talk) 15:40, 1 December 2015 (UTC)
38.  Support --Andyrom75 (talk) 15:57, 1 December 2015 (UTC)
39.  Support Especially if it includes improving the diff when removing empty lines, or when moving sections (as I've meantioned in the earlier discussion, and which was also another suggestion then). The idea with "simple diff" above might also be something. Flinga (talk) 16:17, 1 December 2015 (UTC)
40.  Support Goombiis (talk) 16:27, 1 December 2015 (UTC)
41.  Support a real code typer.--Temp3600 (talk) 16:42, 1 December 2015 (UTC)
42.  Support JohanahoJ (talk) 16:46, 1 December 2015 (UTC)
43.  Support and also suggesting an improvement to identifying where the diff is from on the page. Line numbers aren't always useful. --2macia22 (talk) 17:00, 1 December 2015 (UTC)
44.  Support _anything_ that improves the various issues with diff. Stevie is the man! ^{Talk • Work} 17:20, 1 December 2015 (UTC)
45.  Support Genius plan, though I'm not sure exactly how or what changes need to be made. It seems like the current system's drawbacks are there for a good reason. -- 2ReinreB2 (talk) 17:22, 1 December 2015 (UTC)
46.  Support Wugapodes (talk) 17:24, 1 December 2015 (UTC)
47.  Support -- Tisfoon (talk) 17:43, 1 December 2015 (UTC)
48.  Support Jan.Kamenicek (talk) 18:48, 1 December 2015 (UTC)
49.  Support --Wesalius (talk) 19:01, 1 December 2015 (UTC)
50.  Support --Tdslk (talk) 19:04, 1 December 2015 (UTC)
51.  Support Jules78120 (talk) 19:48, 1 December 2015 (UTC)
52.  Support Any improvement here would be very useful. It seems that a minor relocation of a paragraph already 'hides' the actual change. Gap9551 (talk) 20:07, 1 December 2015 (UTC)
53.  Support --Woodcutterty (talk) 20:10, 1 December 2015 (UTC)
54.  Support --Akela (talk) 20:59, 1 December 2015 (UTC)
55.  Support Yes, improvement needed. Regards, Kertraon (talk) 21:59, 1 December 2015 (UTC)
56.  Support StevenJ81 (talk) 21:59, 1 December 2015 (UTC)
57.  Support --Grüße vom Sänger ♫^(Reden) 22:17, 1 December 2015 (UTC)
58.  Support Helder 23:48, 1 December 2015 (UTC)
59.  Support --Emptywords (talk) 00:08, 2 December 2015 (UTC)
60.  Support Vätte (talk) 01:17, 2 December 2015 (UTC)
61.  Support --Chaoborus (talk) 02:23, 2 December 2015 (UTC)
62.  Support Removing a line space causes the entire section to be marked, very easily to lose vandalism in there.--Loriendrew (talk) 03:44, 2 December 2015 (UTC)
63.  Support Risker (talk) 03:48, 2 December 2015 (UTC)
64.  Support In veritas (talk) 04:26, 2 December 2015 (UTC)
65.  Support Can this actually be fixed? The need for this is so obvious that I assumed some insurmountable technical hurdle must be preventing it from being done. Any improvement here would be most welcome. Antepenultimate (talk) 04:37, 2 December 2015 (UTC)
66.  Support Alkamid (talk) 07:36, 2 December 2015 (UTC)
67.  Support Litlok (talk) 08:22, 2 December 2015 (UTC)
68.  Support Sidevar (talk) 10:33, 2 December 2015 (UTC)
69.  Support ...Aurora... (talk) 10:42, 2 December 2015 (UTC)
70.  Support --β₁₆ - (talk) 11:46, 2 December 2015 (UTC)
71.  Support --Renessaince (talk) 14:22, 2 December 2015 (UTC)
72.  Support — NickK (talk) 14:40, 2 December 2015 (UTC)
73.  Support Matěj Suchánek (talk) 15:46, 2 December 2015 (UTC)
74.  Support --AlessioMela (talk) 19:47, 2 December 2015 (UTC)
75.  Support Smarter diffs in general - yes, please. PamD (talk) 21:37, 2 December 2015 (UTC)
76.  Support SteveStrummer (talk) 02:51, 3 December 2015 (UTC)
77.  Support absolutely. The biggest issue seems to be line insertion (e.g. insertion of a section header) and removal (e.g. deleting an empty line). --Anypodetos (talk) 08:16, 3 December 2015 (UTC)
78.  Support --V111P (talk) 10:27, 3 December 2015 (UTC)
79.  Support Oh yes please! Dcs002 (talk) 11:40, 3 December 2015 (UTC)
80.  Support — Arkanosis ^✉ 13:56, 3 December 2015 (UTC)
81.  Support - tucoxn\^talk 14:06, 3 December 2015 (UTC)
82. I'd support this but I suspect the real issue is too hard for the team. Cosmetic changes made by the WMF usually end up producing inferior software, like Special:MobileDiff/123456. Nemo 14:39, 3 December 2015 (UTC)
83.  Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
84.  Support This could save a lot of editor time. Mark MacD (talk) 13:13, 4 December 2015 (UTC)
85.  Support Jmatazzoni (talk) 17:47, 4 December 2015 (UTC)
86.  Support Grüße vom Sänger ♫^(Reden) 18:26, 4 December 2015 (UTC)
87.  Support Avgr8 (talk) 20:57, 4 December 2015 (UTC)
88.  Support --Yeza (talk) 16:40, 5 December 2015 (UTC)
89.  Support Zamaster4536 (talk) 12:57, 6 December 2015 (UTC)
90.  Support -- Sir Gawain (talk) 14:25, 6 December 2015 (UTC)
91.  Support - Supporting the idea, but my sense is this would be a huge undertaking so I don't know how likely it is. Worth exploring, though. — Rhododendrites ^talk \\ 17:39, 6 December 2015 (UTC)
92.  Support Wbm1058 (talk) 16:05, 7 December 2015 (UTC)
93.  Support Mpn (talk) 18:25, 7 December 2015 (UTC)
94.  Support --Waldir (talk) 14:54, 8 December 2015 (UTC)
95.  Support Although at this point it's obvious this has practically unanimous support. Hopefully that means this gets some developer resources put to it. -- Llywrch (talk) 19:06, 11 December 2015 (UTC)
96.  Support and in particular make it easier to see where the diff only consists of the addition or removal of spaces. It's hard enough looking for punctuation but spaces are impossible. Martin of Sheffield (talk) 22:52, 11 December 2015 (UTC)
97.  Support Frewaz (talk) 23:18, 11 December 2015 (UTC)
98.  Support mainly spaces and punctuations -- Juetho (talk) 11:57, 12 December 2015 (UTC)
99.  Support Nocowardsoulismine (talk) 16:30, 12 December 2015 (UTC)
100.  Support HoboMcJoe (talk) 00:29, 13 December 2015 (UTC)
101.  Support --NaBUru38 (talk) 03:40, 13 December 2015 (UTC)
102.  Support In ukwiki we use FlaggedRevs extension. And have to mark edits as reviewed and appropriate. But sometimes an editor does small edit to a page, like adding empty lines before the paragraphs, and this really looks like the whole article has been rewritten. And there's no way to compare the two revisions except by reading the whole article. A really time consuming and annoying thing.--Piramidion 12:16, 13 December 2015 (UTC)
103.  Support --ESM (talk) 16:13, 13 December 2015 (UTC)
104.  Support --Tgr (talk) 22:43, 13 December 2015 (UTC)
105.  Support --Davidpar (talk) 14:26, 14 December 2015 (UTC)
106. Comment: (strong support), and in particular, please make the diff-view *interactive* so that I can use the mouse (or the finger on touchscreens) to "pull" parts of the diff which were incorrectly positioned by the software, into the correct location. Make sure you field-test the new diff-view with BEGINNING editors, people who have never used git in their life, people who don't live on the command-line. The color-coding and visual cues of the current diff-view are terrible confusing for beginning-wikipedians, in my experience. Be bold in trying to improve this feature, it is crucial to any serious collaborative work on controversial topics (politics/religion/emacs-vs-vim/etc), and in the current primitive state is almost painful to utilize. Go whole-hog on this one, maximize the resources thrown at it. It will be tempting to just take whatever existing FLOSS code for diffs is easily available, and give that a few tweaks. Don't do that. Sure, draw on the existing diff-app-ecosphere: but wikipedia needs a rock-solid diff, one which rarely makes mistakes, is interactively fixable when it does make errors, and overall is instantly clear to beginners who may never have seen a diff-tool in their lives. Thanks, 75.108.94.227 15:09, 14 December 2015 (UTC)

Make it easier to cite different pages from a book as one reference

Tracked in Phabricator:
Task T100645

When I cite different pages from a book within an article, I have to cite the book separately multiple times. We have a "reuse citation" functionality that also works very well in VisualEditor but not for different pages from the same book. See Phabricator tasks phab:T100645 and phab:T15127. Thanks,

--Gnom (talk) 10:07, 12 November 2015 (UTC)

Earlier discussion and endorsements
Comment I think the English Wikipedia already does this with en:Template:Rp. Davidwr/talk 05:54, 16 November 2015 (UTC)  Endorsed I don't recall ever seeing this template used (although I'm sure I could find out how many transclusions there are), but I think most editors are unaware of it, and usage seems more complicated than should be necessary. The ability to name a reference, and then within the subsequent citations, to simply add "page=27" or whatnot would simplify this and help reduce reference clutter on articles that cite multiple pages from the same source. Etamni (talk) 06:14, 17 November 2015 (UTC)  Endorsed I've used en:Template:Rp, and I agree that it would be simpler to be able to write <ref name=blah page=42/>. And simplicity equals adoption. Swpb (talk) 19:47, 17 November 2015 (UTC) Comment Rather than limit things to <ref name=blah page=42/> allowing either that form or <ref name=blah note="page=42"/> where the "note" is arbitrary and can be "chapter=3" or, for non-book items like web sites that require clicks to "un-hide" content or which don't allow direct deep linking, instructions like "Click on 'show more' tab" or "click on News->Archives->June 2015->Storm destroys Atlantis". Davidwr/talk 18:43, 20 November 2015 (UTC)

Stemmen

1.  Support I've always found using the workaround template a pain. Samwalton9 (talk) 10:12, 30 November 2015 (UTC)
2.  Support TeriEmbrey (talk) 15:59, 30 November 2015 (UTC)
3.  Support --Isacdaavid (talk) 02:18, 1 December 2015 (UTC)
4.  Support--Shizhao (talk) 09:21, 1 December 2015 (UTC)
5.  Support. Anthonyhcole (talk) 10:09, 1 December 2015 (UTC)
6.  Support · · · Peter (Southwood) ^(talk): 14:03, 1 December 2015 (UTC)
7.  Support GoEThe (talk) 14:57, 1 December 2015 (UTC)
8.  Support — Quoth (talk) 15:16, 1 December 2015 (UTC)
9.  Support --Vojtěch Dostál (talk) 16:15, 1 December 2015 (UTC)
10.  Support Goombiis (talk) 16:25, 1 December 2015 (UTC)
11.  Support This is why I usually just cite an entire book, but individual page mentions would be very helpful for researchers using Wikipedia as a starting point. -- 2ReinreB2 (talk) 17:24, 1 December 2015 (UTC)
12.  Support in a big way! This was needed years ago. Stevie is the man! ^{Talk • Work} 17:24, 1 December 2015 (UTC)
13.  Support This would be a great improvement over the current situation. -- _{• • hugarheimur} 18:11, 1 December 2015 (UTC)
14.  Support --Warp3 (talk) 18:15, 1 December 2015 (UTC)
15.  Support --Coentor (talk) 18:22, 1 December 2015 (UTC)
16.  Support Jan.Kamenicek (talk) 18:49, 1 December 2015 (UTC)
17.  Support -- Akela (talk) 21:00, 1 December 2015 (UTC)
18.  Support Vätte (talk) 01:21, 2 December 2015 (UTC)
19.  Support Beyond My Ken (talk) 02:14, 2 December 2015 (UTC)
20.  Support Risker (talk) 03:50, 2 December 2015 (UTC)
21.  Support Antepenultimate (talk) 04:50, 2 December 2015 (UTC)
22.  Support--Barcelona (talk) 11:58, 2 December 2015 (UTC)
23.  Support--Manlleus (talk) 15:14, 2 December 2015 (UTC)
24.  Support HughD (talk) 16:02, 2 December 2015 (UTC)
25.  Support PamD (talk) 21:40, 2 December 2015 (UTC)
26.  Support Wittylama (talk) 22:19, 3 December 2015 (UTC)
27.  Support Nikkimaria (talk) 01:33, 4 December 2015 (UTC)
28.  Support Graeme Bartlett (talk) 04:17, 4 December 2015 (UTC)
29.  Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
30.  Support -- Fauzan^{✆ talk} _{✉ email} 16:47, 4 December 2015 (UTC)
31. Neutral or  Support if this means some more love shown to w:template:sfn, which is the best way to cite individual pages, except it's more time-consuming, there's no handy citoid way of doing it and it doesn't work well with the Visual Editor (see T114105 and related tickets). Halibutt (talk) 00:06, 5 December 2015 (UTC)
32.  Support -- Sir Gawain (talk) 14:27, 6 December 2015 (UTC)
33.  Strong support - This seems like a good project for the community wishlist. It's a big pain, it's an even bigger pain to teach someone to do, and it seems like it wouldn't be all that difficult to fix. What about just adding a parameter to the ref tag for "pages" such that <ref name="abc" pages="21-39"/>? (yes, yes easier said than done, but compared to some of the other projects that would make a similar kind of impact to editing, it seems reasonable) — Rhododendrites ^talk \\ 17:42, 6 December 2015 (UTC)
34.  Support--Joris Egger (talk) 21:08, 7 December 2015 (UTC)
35.  Support Gamaliel (talk) 15:49, 8 December 2015 (UTC)
36.  Support I cannot emphasize enough how much easier this would make editors' lives. Daniel Case (talk) 19:20, 8 December 2015 (UTC)
37.  Support - Bcharles (talk) 04:58, 9 December 2015 (UTC)

    I'm not quite seeing the issue here as it's not difficult to copy a full citation, and then paste it where needed, changing the page numbers. It's a simple click, change page number, click, change page number, etc. Whatever solution that is done, would involve the same amount of editing: copy the citation template, click it into place, edit the page number. SilkTork (talk) 09:38, 9 December 2015 (UTC)

38.  Support Override-able page numbers would deal with the majority of cases. In the longer term I'd like to see something much smarter though. - Pointillist (talk) 15:18, 9 December 2015 (UTC)
39.  Support AlbinoFerret 18:32, 10 December 2015 (UTC)
40.  Oppose Once there are multiple pages from the same source you should move the source citation to a different section and use {{sfn}} or {{harvid}} to define the pages. Martin of Sheffield (talk) 22:56, 11 December 2015 (UTC)
41.  Oppose As Martin of Sheffield says, this sounds redundant to {{sfn}} and the like, which is incredibly powerful and slick and ought to be used more. QuartierLatin1968 (talk) 04:42, 12 December 2015 (UTC)
42.  Strong support This request is not redundant with {{sfn}} and {{efn}} and friends. Sure, those are slick templates. And sure, you *can* make a multi-section ref-architecture, which "solves" the problem this proposal is aiming to solve. *If* you are willing to settle for an inelegant solution, with weird syntax, which doesn't make ANY sense to beginning-editors. Or even to intermediate-level editors, for that matter. See also, harvnb, #tag workarounds, and other such things. Anything involving curly-braces in addition to <ref>-tags, is basically a kludge. That goes for general-purpose efn/sfn/etc curly-brace magic. That also goes for special-purpose {{rp}} which kinda-sorta solves this specific problem... but again, in somewhat inelegant fashion. This proposal is to SOLVE the problem, in an elegant fashion: according to implementation-phase-one outlined in phab:T100645, the basic idea is to add to XML attribs to the <ref>-tag, so that editors can modify the underlying {{cite book}} parameters on the fly. Now that is elegant. Even more elegant, would be to add some additional power to the <ref>-tag attributes, so that *arbitrary* portions of the underlying {{citation}} form could be replaced on the fly. So for instance, the main use-case here is about writing an article, sourced to a 999-page book, and wanting to cite specific sentences-or-paragraphs of the article-prose, to specific pages of the book in question. Here is what would be ideal to be able to utilize: first, define the book as a reference. {{reflist|refs= <ref name=stokes'10>{{cite book |title=Isaac Newton |author=Mitch Stokes |year=2010 |isbn=1-59555-303-7 |page=111 }}</ref> }} Next, in the body-prose of the article, say things like <ref name=stokes'10 page=222 /> and later for a different factoid <ref name=stokes'10 page=333 />. Now sure, you can do SOMETHING kinda equivalent using {{rp}} or {{efn}} kludges, that is true. But those are complicated syntax, and *still* limited. Consider the power to override other cite-template-params, besides the page-num, using ref-tag-attribs: what if you were working from the paperback, not the hardback? Simply say <ref name=stokes'10 page=444 isbn=2-60444-292-8 /> to indicate page 444 in the paperback edition. What if you are working from books.google.com? You can override the |url= param like this: <ref name=stokes'10 page=555 url=https://books.google.com/books?id=zpsoSXCeg5gC&pg=PA5552 />. Being able to override the |url= param is *extremely* useful when citing television shows such as C-SPAN's video uploads, for instance, the 2008 POTUS debates: http://youtube.com/watch?v=DvdfO0lq4rQ#t=111s which is distinct from http://youtube.com/watch?v=DvdfO0lq4rQ#t=222s. I would also like to be able to override the |quote= parameter, for when I am pulling five distinct factoids from a 5000-word blog-post, *without* endlessly repeating all the cite-web params. Now, it would be exceedingly rare to need to override cite-template params in ALL these ways (page/isbn/url/quote/etc) during the course of editing a single article... but implementation-phase-two of this proposal, it to store the ref-data as part of wikidata, and thus be able to use the same cite-template-data in multiple wikipedia articles. Unless there is a way to override the cite-template-params, using the ref-tag, this second phase cannot be made to work. Strong support on this idea. See also the related proposal, Editing#Nested_tag_support (and phab:T3310), which would be another way to elegantly solve this problem, albeit probably more difficult to implement without breaking existing wikipedia conventions. 75.108.94.227 18:56, 14 December 2015 (UTC)

Merge the content translation and the visual editor to one tool

The concept of the content translation is very good. The largest editions of wikipedia (especially the english) are main source for articles in other languages. But in the current form of the Content Translation, you can only translate an article, but cannot add information from other sources, add local tamplates, or even change/add media files, until you publish the article. My suggestion is to merge the content translation and the visual editor into one tool, in which translating would be an option.

בנימין (talk) 15:16, 10 November 2015 (UTC)

Earlier discussion and endorsements
Endorsed Do you think you could make a quick mock-up of what a unified UI would look like? I'm all for bringing the tools closer together: it would be nice for all wikis to be able to easily look at the article in a related language as they edit, for instance. Cscott (talk) 19:28, 11 November 2015 (UTC)

Stemmen

1. Comment This is easy to fix: phabricator:T115375#1838090. Nemo 18:34, 30 November 2015 (UTC)
2. Neutral Nemo's suggestion sounds worth exploring, before tearing up the v/e code. Stevie is the man! ^{Talk • Work} 17:32, 1 December 2015 (UTC)
3.  Support I work a lot with the translation tool and this feature would make things a lot easier. At the momement I have to block an article for other people with "inuse" after publication to avoid edtiting conflicts with eager authors who want to fix the same problems I'm going to sort out (have to sort out) after publication due to differences in the structure of articles in different languages. --Drgkl (talk) 11:49, 2 December 2015 (UTC)
4.  Support--Manlleus (talk) 15:14, 2 December 2015 (UTC)
5.  Support --AS (talk) 09:40, 3 December 2015 (UTC)
6.  Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
7.  Support Lester לסטר (talk) 18:06, 5 December 2015 (UTC)
8.  Oppose If Visual Editor becomes the only way to translate, I would stop using Content Translator. I'm not convinced Visual Editor is good for me.--MisterSanderson (talk) 01:31, 14 December 2015 (UTC)

Nested tag support

Some extensions (e.g. mw:extension:Cite) establish tags (<ref> in this case) which are parsed on a "one-off" assumption. I.e. structures like Primary text<ref>Outer footnote<ref>Inner footnote</ref> continuation of outer footnote</ref> continuation of primary text simply will not currently parse, resulting in the dreaded and rather unfriendly

error. Surely it is past time to address such a fundamental issue?

AuFCL (talk) 00:32, 13 November 2015 (UTC)

Earlier discussion and endorsements
Just to extend the generality of the above I have also seen users attempt to nest <poem> tags within <poem> tags to similar levels of frustration (at least there is not a big red cryptic error in this instance but it still does not work.) AuFCL (talk) 05:25, 13 November 2015 (UTC)  Endorsed. If there are technical reasons for not being able to nest these tags, at least clean up the message and be more specific where the problem is. Etamni (talk) 06:17, 17 November 2015 (UTC)

Stemmen

1.  Support strongly, at least for <ref> tags. --Purodha Blissenbach (talk) 14:40, 1 December 2015 (UTC)
2.  Support Szalakóta (talk) 16:54, 1 December 2015 (UTC)
3. Comment What would be the purpose of a nested ref tag? Stevie is the man! ^{Talk • Work} 17:35, 1 December 2015 (UTC)
4.  Support Jan.Kamenicek (talk) 18:51, 1 December 2015 (UTC)
5.  Support --Usien6 (talk) 19:28, 1 December 2015 (UTC)
6.  Support Popcorndude (talk) 03:34, 2 December 2015 (UTC)
7. Comment As Stevietheman said, when does anyone ever use nested refs? Eman235/talk 21:21, 2 December 2015 (UTC)

   FWIW, I've wished for this capability on more than one occasion (e.g. being able to put a 'ref' inside an inline 'note'). But this isn't enough of a priority "wish" for me to vote "support" (at least, not yet)... IJBall (talk) 04:01, 3 December 2015 (UTC)

8.  Support I've run across this at least once. -- Fauzan^{✆ talk} _{✉ email} 16:49, 4 December 2015 (UTC)
9.  Support. There is a workaround though and I'm using it very often. Halibutt (talk) 00:08, 5 December 2015 (UTC)
10.  Oppose - A fine idea, but just not something that happens often enough (and when it does, there's a workaround as noted above) that it would make a markedly lesser impact than many of the other proposals — Rhododendrites ^talk \\ 17:45, 6 December 2015 (UTC)
11.  Support "When does anyone use nested references?" The advice page en:Nesting footnotes explaining that the obvious way to do this doesn't work receives a steady 40 or so views per day. Noyster (talk) 13:31, 7 December 2015 (UTC)

    I expect the link Noyster intended above might (indeed more specifically) have been: en:WP:Nesting footnotes#What_does_not_work? AuFCL (talk) 21:36, 8 December 2015 (UTC)

Page contributors

Tracked in Phabricator:
Task T49721

Before the switch to tool labs (am I using the right jargon?) we had a nifty little tool on the English wikipedia that was much superior to what we have now under Top 50 contributors.

By a simple click of a button one could check out ALL editors who ever edited a page sorted 8 different ways. This is useful when trying to gauge the activity level of w:WP:WikiProjects, and comes in real handy for someone like me who only very occasionally participates on a talkpage, but when they do want to have some background on the potential audience before making a total fool out of themselves.

The tool displayed the list of editors who had participated on the page. There were 4 columns, each of which could be sorted front-to-back and vice verse:

• user ID
• number of edits to the page
• date of first edit
• date of last edit

It was quick and rarely (if ever) failed, while the tool we have now lists only the top 50 editors, cannot be sorted, and is broken a lot.

Thanks for considering this proposal.

Ottawahitech (talk) 19:18, 18 November 2015 (UTC)

Earlier discussion and endorsements
Endorsed action=credits should be made fast and good enough to be enabled on Wikimedia wikis: a lot of interface, tools and external software or data users would benefit from it. Nemo 10:38, 22 November 2015 (UTC)

Stemmen

1.  Support--Shizhao (talk) 09:23, 1 December 2015 (UTC)
2.  Support I agree this should be built-in. Stevie is the man! ^{Talk • Work} 17:40, 1 December 2015 (UTC)
3.  Support Risker (talk) 03:51, 2 December 2015 (UTC)
4.  Support--Manlleus (talk) 15:17, 2 December 2015 (UTC)
5.  Support This would be incredibly useful. Eman235/talk 21:22, 2 December 2015 (UTC)
6.  Support --Misibacsi (talk) 04:43, 3 December 2015 (UTC)
7.  Support --YBG (talk) 06:10, 3 December 2015 (UTC)
8.  Support — Arkanosis ^✉ 13:57, 3 December 2015 (UTC)
9.  Support -- SantiLak (talk) 10:39, 4 December 2015 (UTC)
10.  Support Halibutt (talk) 00:09, 5 December 2015 (UTC)
11.  Support - I don't know the background about who developed it, which will almost certainly have bearing on whether this can be a wishlist project, but definitely a useful tool. — Rhododendrites ^talk \\ 17:49, 6 December 2015 (UTC)
12.  Support This would be very helpful. Corinne (talk) 03:05, 7 December 2015 (UTC)
13.  Support--Joris Egger (talk) 21:10, 7 December 2015 (UTC)
14.  Support SteveStrummer (talk) 01:47, 10 December 2015 (UTC)
15.  Support -- Llywrch (talk) 19:08, 11 December 2015 (UTC)
16.  Support -- Juetho (talk) 11:57, 12 December 2015 (UTC)
17.  Support --Sphilbrick (talk) 23:16, 12 December 2015 (UTC)
18.  Support -- NaBUru38 (talk) 03:42, 13 December 2015 (UTC)

Save edits before publishing

Tracked in Phabricator:
Task T39992

Tracked in Phabricator:
Task T75241

Often I think that I would like to save a edit - meaning, that I have it kept in the system but don't want it to be published yet. You know this difference from Wordpress, where "saving" is different from "publishing". Especially in the Content Translator I'd like to see such a feature. By the way, I sometime experienced problems when I edited in the editor window but the internet connection fell away; saving the text just for safety would be great.

Ziko (talk) 23:41, 20 November 2015 (UTC)

Earlier discussion and endorsements
Endorsed BTW, Ziko, Content Translation saves your translation automatically ;) --KuboF (talk) 23:52, 20 November 2015 (UTC)  Endorsed. Helder 12:13, 22 November 2015 (UTC)

Stemmen

1.  Support 4nn1l2 (talk) 03:10, 30 November 2015 (UTC)
2.  Support בנימין (talk) 07:32, 30 November 2015 (UTC)
3.  Support Samwalton9 (talk) 10:27, 30 November 2015 (UTC)
4. Comment On the condition there will be no extra step in saving my edits. Debresser (talk) 13:02, 30 November 2015 (UTC)
5.  Support provided this is done only when the user wants it. עוד מישהו Od Mishehu 16:11, 30 November 2015 (UTC)
6.  Support --MGChecker (talk) 20:01, 30 November 2015 (UTC)
7. Comment Real-time preview and template parsing and offline storage and editing functionality already provided by Zhaofeng Li's elegant and easily used Scratchpad user script. Try it out with one line copy & paste to browser address bar; install as easily to enable bold editing of forked WP page, saved to browser, not Wikipedia. -- Paulscrawl (talk) 20:22, 30 November 2015 (UTC)
8.  Support. This would be very helpful. Most modern systems do work this way (e.g gmail, MSOffice.) DGG (talk) 02:18, 1 December 2015 (UTC)
9.  Support --Isacdaavid (talk) 02:20, 1 December 2015 (UTC)
10.  Support That functionality is already available in Extension:Drafts which I suggest to be installed on all WMF wikis. Btw. it serves us well on several nonpublic wikis.--Purodha Blissenbach (talk) 14:27, 1 December 2015 (UTC)
11.  Support Ckoerner (talk) 15:15, 1 December 2015 (UTC)
12.  Support --Dodi123 (talk) 16:51, 1 December 2015 (UTC)
13.  Support -- Tisfoon (talk) 17:47, 1 December 2015 (UTC)
14.  Support per Purodha. Stevie is the man! ^{Talk • Work} 17:50, 1 December 2015 (UTC)
15.  Support --Warp3 (talk) 18:32, 1 December 2015 (UTC)
16.  Support The scratchpad suggested Paulscrawl does not seem to be the full-blown alternative of what is requested in this proposal. Jan.Kamenicek (talk) 19:04, 1 December 2015 (UTC)
17.  Support Artem.komisarenko (talk) 19:38, 1 December 2015 (UTC)
18.  Support --Akela (talk) 21:03, 1 December 2015 (UTC)
19.  Support Yes. Regards, Kertraon (talk) 22:02, 1 December 2015 (UTC)
20.  Support Alkamid (talk) 07:39, 2 December 2015 (UTC)
21.  Support --β₁₆ - (talk) 11:48, 2 December 2015 (UTC)
22.  Support. Very useful to save a draft but not publish it for readers. Currently the only way to do it is either to publish somewhere in personal namespace or to save locally on your computer — NickK (talk) 14:50, 2 December 2015 (UTC)
23.  Support--Manlleus (talk) 15:17, 2 December 2015 (UTC)
24.  Support Yes, please add automatic saving of drafts ala Gmail. —Pengo (talk) 21:18, 2 December 2015 (UTC)
25.  Support. There has been more than one time that I have lost a large amount of work due to my computer crashing or something similar. Being able to save drafts would also be very helpful. Andrew Sheedy (talk) 00:55, 3 December 2015 (UTC)
26.  Support This seems like such a simple add-on, hardly demanding any resources. It would be more convenient than my old standby of copy/pasting & saving it in Notepad. Dcs002 (talk) 11:49, 3 December 2015 (UTC)
27.  Support Nikkimaria (talk) 01:33, 4 December 2015 (UTC)
28.  Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
29.  Support Jmatazzoni (talk) 17:38, 4 December 2015 (UTC)
30.  Support Halibutt (talk) 00:10, 5 December 2015 (UTC)
31.  Support Tar Lócesilion (queta) 12:58, 5 December 2015 (UTC)
32.  Support Plus i would suggest that there should a history of those saved edits just like in Etherpad. I have experienced problems when the text disappears in Content Translation and then it saves again and after half an hour all i have is an empty page.--Satdeep Gill (talk) 15:05, 7 December 2015 (UTC)
33.  Support O yes. Support this. And make it automatic so if I press the wrong button I only lose 5 minutes work, not half an hour! SilkTork (talk) 12:38, 9 December 2015 (UTC)
34.  Support --Ziko (talk) 13:48, 9 December 2015 (UTC)
35.  Support --Tgr (talk) 22:49, 13 December 2015 (UTC)
36.  Support --Kew Gardens 613 (talk) 22:59, 13 December 2015 (UTC)
37.  Support --Davidpar (talk) 14:30, 14 December 2015 (UTC)

Simple math in tables

It is my understanding that the developers are working very hard on making it easier to create tables in visual editor. We are not quite there yet, and I have seen a recent setback, but we are close to being able to copy and paste an existing table from a spreadsheet directly into an editing window. At present, this allows cell by cell transfer of data, but does not allow one to do traditional spreadsheet functions such as simple math (e.g. sum of entries in a column, ratio of two cells). While full functionality of a spreadsheet is well beyond the scope of what ought to be available in media wiki, I see tremendous value in allowing some simple concepts such as sums and ratios. (I would also like the ability to have hidden columns, which I suspect are technically possible but may be nontrivial. I'll be happy to explain if the need for this isn't obvious).

Editors who do not follow sports closely may be unaware that we have many hundreds if not thousands of articles with tables of historical results for teams coaches and individual players. As an example, see John Thurston.

In a nutshell, the challenge is that, while it is not hard to add a single year to a template, or update the template when the team wins, the subtotals by coach, by conference versus non-conference, aggregate cumulative results and winning percentages are not automatically updated, but have to be edited separately.

The setup creates two problems:

1. Harder than it should be—Updating a single game is not easy — instead of editing one field, the editor may need to edit eight fields. Or maybe six, or maybe four, it depends
2. Errors persist—If any editor ever makes an error, the subtotals and totals will now be wrong, and a subsequent edit which makes all of the right increments will not correct the problem but preserve the error. (Plus, if some editor notes the subtotals are wrong and corrects them, they may have been wrong because some individual entry was wrong and now the subtotals are right but the individual entry is wrong. When the software does not do the totals, the individual entries and the totals can get out of sync)

To illustrate,

• Existing approach when a game is won:

1. Increment season win count
2. If a conference game, increment season win count
3. If winning percentage template in place, increment win count
4. Increment coach win count
5. If a conference game, increment season conference win count for the coach
6. If winning percentage template in place, increment win count for the coach totals
7. Increment all time win count
8. If winning percentage template in place, increment win count for all time totals

• Proposed approach when a game is won:

1. Increment win count in the conference field, if a conference game, or in the non-conference field if non-conference (the software then calculates all subtotals and ratios).

I've presented this in the context of sports tables, but there are many tables within Wikipedia which require occasional updates. In cases where these tables have subtotals and totals the same problems can persist — that the entries in the subtotals get out of sync. Editors should modify individual entries, and let a computer do the math.

I don't know whether this will fall within the types of things considered in scope. If it is in scope, I'll note that my brief discussion above is far short of adequate, and I'll volunteer to write more fully developed use cases and take a stab at specifications.

--Sphilbrick (talk) 17:23, 16 November 2015 (UTC)

Earlier discussion and endorsements
It may be possible to already do this via Lua Modules. I don't have much experience with writing Lua Modules myself, but maybe someone like Mr. Stradivarius would have a better idea. Ryan Kaldari (WMF) (talk) 03:03, 17 November 2015 (UTC) What Sphilbrick describes isn't quite possible in Scribunto. For someone to be able to edit certain rows of a table with VisualEditor and have other rows of that table updated by Lua modules, you would need to have one module invocation for each cell that you want updated. To do this, you would need to grab the latest wikitext revision of the page and then attempt to parse it to determine the module output. However, there are two problems with this: a) parsing wikitext reliably is really hard (for those who have never seen it, take a look at Parser.php), and b) the module output won't be updated on page preview, as it only uses the latest saved revision of the page. To do this properly in Lua you would need to replace the entire table with a template invocation. However, then you wouldn't be able to edit it with VisualEditor (at least not directly). — Mr. Stradivarius ♪ talk ♪ 07:43, 17 November 2015 (UTC) @Mr. Stradivarius: I was thinking about an all template solution. For example, why can't the Compact election box template on en.wiki compute all the percentages for you based on the votes rather than requiring you to compute and enter them as separate parameters? I imagine this could be handled with some math and rounding functions in Lua, right? FWIW, I don't expect spreadsheet features will be added into VisualEditor any time soon. I just don't think there's enough demand for it given the trade-off of making the table editing interface a lot more complicated (but who knows). I'm not on the Editing team, so I can't speak for them. Ryan Kaldari (WMF) (talk) 00:22, 24 November 2015 (UTC) @Sphilbrick:. "we are close to being able to copy and paste an existing table from a spreadsheet directly into an editing window." Can you link to any info on this? I wrote up a roundabout way to do this: Commons:Convert tables and charts to wiki code or image files. See section titled "Web to LibreOffice Calc to tab2wiki". I guess you can do something similar to solve some of the simple math stuff you are trying to do. Paste the wiki table into LibreOffice Calc, or into a tool at the Wikimedia Tool Labs. Then do the math there. Get the new table back in wikitext format directly, or by pasting the revised Calc spreadsheet into tab2wiki. --Timeshifter (talk) 14:31, 17 November 2015 (UTC)  Endorsed obvious need. Etamni (talk) 06:21, 17 November 2015 (UTC)  Endorsed Might have to use an intermediate tool at Wikimedia Tool Labs. --Timeshifter (talk) 14:35, 17 November 2015 (UTC)

Stemmen

1.  Support This, that and the other (talk) 13:23, 30 November 2015 (UTC)
2.  Support--Shizhao (talk) 09:25, 1 December 2015 (UTC)
3. Neutral I can see the value of this, but the development sink and unknown complexities scare me. Stevie is the man! ^{Talk • Work} 17:58, 1 December 2015 (UTC)
4.  Strongly oppose This proposal is all about making original research easier --Usien6 (talk) 19:33, 1 December 2015 (UTC)
5.  Support I would really like this as I often update tennis statistics. Basic arithmetic is not original research. It should be very simple though, e.g. adding named tags to two cells, and referring to these names in another cell to add the values. I don't think we should have all cells named by default as in common spreadsheets (A1, B2, etc). It is no problem if the initial creation of these tags takes some time, as it saves a lot of effort and errors in the long run. Gap9551 (talk) 20:39, 1 December 2015 (UTC)
6.  Support. And "simple math" is not considered to be OR. StevenJ81 (talk) 22:02, 1 December 2015 (UTC)
7.  Support Elections & disasters too. ...Aurora... (talk) 10:45, 2 December 2015 (UTC)
8.  Support In stories about current events, data updates can be frequent. This will help, and with lots of editors with varying levels of experience attracted to those articles, having an automatic check on the arithmetic is a good thing. Anything that facilitates and helps direct new editors' enthusiasm while building a better encyclopedia is thumbs-up! Dcs002 (talk) 12:04, 3 December 2015 (UTC)
9.  Support Having been frustrated by this more than a couple times in the past (and with a strong objection to the idea above that it's all about original research), I think this would be a great improvement. That said, I think revamping the way MediaWiki handles tables would make this a huge task, so it's probably most reasonable handled through templates (though I won't claim to know what I'm talking about :) ) — Rhododendrites ^talk \\ 17:54, 6 December 2015 (UTC)

Turn RefToolbar into a MediaWiki extension (or add it into the WikiEditor extension)

Right now Reftoolbar is only available on English Wikipedia (although there is a very limited version on Malayalam Wikipedia). It has frequently been requested that it be turned into an extension so that other Wikipedias can also use it.

Earlier discussion and endorsements
Endorsed 1 Yes we need to make adding references as easy as possible. Doc James (talk · contribs · email) 11:37, 27 May 2015 (UTC) Isn't mw:Citoid the extension that aims to cover Reftoolbar's feature set?--Qgil-WMF (talk) 08:13, 2 June 2015 (UTC) I don't believe so. Citoid is for automatic reference creation. RefToolbar is for (mostly) manual reference creation. Kaldari (talk) 17:13, 16 July 2015 (UTC) It looks like there isn't any chance of this happening, since the editing team is building a new WikiText editor that will have the VE citation-building interface. See bug T104479[1] (links from mw m w). Kaldari (talk) 18:41, 29 September 2015 (UTC) Citoid does the automatic reference creation part, but the 'Manual' tab in the cite inspector lets you choose Book/Website/Journal/... templates and uses TemplateData to make completing those easy on any wiki (not just English). As you can now seamlessly switch between VisualEditor and WikiEditor it wouldn't be sensible to invest any more time in RefToolbar, when we already have a superior feature in VE. ESanders (WMF) (talk) 04:46, 12 November 2015 (UTC)  Endorsed--Shizhao (talk) 07:58, 12 November 2015 (UTC)

Stemmen

1.  Support TeriEmbrey (talk) 16:00, 30 November 2015 (UTC)
2.  Support I generally support improvements which will make it easier for editors to add references. Making sure these capabilities exist in all languages is important. Count me as supporting this specific initiative, if a review of the various ways of improving inclusion of references identifies this as a good candidate.--Sphilbrick (talk) 17:02, 30 November 2015 (UTC)
3.  Support --Isacdaavid (talk) 02:21, 1 December 2015 (UTC)
4.  Support as per Sphilbrick. IJBall (talk) 03:35, 1 December 2015 (UTC)
5.  Support--Shizhao (talk) 09:26, 1 December 2015 (UTC)
6.  Support--Kimdime (talk) 12:12, 1 December 2015 (UTC)
7.  Support —Tito☸Dutta 14:46, 1 December 2015 (UTC)
8.  Support Ckoerner (talk) 15:14, 1 December 2015 (UTC)
9.  Support Goombiis (talk) 16:28, 1 December 2015 (UTC)
10.  Support –Krinkle 16:58, 1 December 2015 (UTC)
11.  Support love this tool on English Wiki. --2macia22 (talk) 17:07, 1 December 2015 (UTC)
12.  Support. We are talking about it on French Wikipedia. --Etiennekd (talk) 18:08, 1 December 2015 (UTC)
13.  Support Stevie is the man! ^{Talk • Work} 18:34, 1 December 2015 (UTC)
14. Comment There is a reftool bar on Czech Wikipedia that uses Czech citation templates and is customized for Czech Wikipedia needs. What would happen with it if this proposal was accepted? Would the RefTool bar that would become part of MediaWiki extension override the local Wikipedia RefTool bar? Or would there be two RefTool bars? Jan.Kamenicek (talk) 19:16, 1 December 2015 (UTC)
15.  Support --Usien6 (talk) 19:35, 1 December 2015 (UTC)
16.  Oppose We already have Citoid, which does a great job of inserting references automatically (from a URL) or manually (pretty much the same as RefToolbar). This would a duplication of that work. ESanders (WMF) (talk) 21:03, 1 December 2015 (UTC)

    It should be noted that Citoid is integrated into the Visual Editor that not everyone uses and is Opt-in. Stevie is the man! ^{Talk • Work} 22:40, 1 December 2015 (UTC)

    If you opt in to VE you can still use the wikitext editor for all your editing, and just switch to VisualEditor (mid-edit if necessary) if you want to add a citation. If you opt out of new features you don't get new features... ESanders (WMF) (talk) 00:26, 2 December 2015 (UTC)

    OK, but not everyone agrees that VE is a "new feature" but rather an optional one. In fact, many have rejected it for various reasons. It doesn't hurt VE users or Wikimedia projects to make the reftoolbar available to more wiki users. Stevie is the man! ^{Talk • Work} 17:41, 2 December 2015 (UTC)

17.  Support StevenJ81 (talk) 22:03, 1 December 2015 (UTC)
18.  Support Helder 23:48, 1 December 2015 (UTC)
19.  Support – Ham II (sgwrs / talk) 19:13, 2 December 2015 (UTC)
20.  Support This is a very useful tool and I'm surprised to hear that it's not available in other languages. Eman235/talk 21:26, 2 December 2015 (UTC)
21.  Support RefToolbar is so helpful, let's please share it with the other Wikis. PamD (talk) 21:39, 2 December 2015 (UTC)
22.  Support Nikkimaria (talk) 01:33, 4 December 2015 (UTC)
23.  Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
24.  Support — Rhododendrites ^talk \\ 17:56, 6 December 2015 (UTC)
25.  Support - Bcharles (talk) 05:14, 9 December 2015 (UTC)
26.  Oppose As mentioned above, refToolbar is already available on Czech wiki. It is available on Ukrainian Wikipedia and (I've just checked) on Polish and Russian wikis. So nothing really prevents people from adding refToolbar feature to their wikis. I guess, the Community Tech resources shouldn't be spent on such things.--Piramidion 12:55, 13 December 2015 (UTC)