Community Wishlist Survey 2015/Editing: Difference between revisions
No edit summary |
No edit summary |
||
Line 512: | Line 512: | ||
#{{s}} [[User:Halibutt|Halibutt]] ([[User talk:Halibutt|talk]]) 00:09, 5 December 2015 (UTC) |
#{{s}} [[User:Halibutt|Halibutt]] ([[User talk:Halibutt|talk]]) 00:09, 5 December 2015 (UTC) |
||
#{{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. — <tt>[[User:Rhododendrites|<span style="font-size:90%;letter-spacing:1px;text-shadow:0px -1px 0px Indigo;">Rhododendrites</span>]] <sup style="font-size:80%;">[[User_talk:Rhododendrites|talk]]</sup></tt> \\ 17:49, 6 December 2015 (UTC) |
#{{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. — <tt>[[User:Rhododendrites|<span style="font-size:90%;letter-spacing:1px;text-shadow:0px -1px 0px Indigo;">Rhododendrites</span>]] <sup style="font-size:80%;">[[User_talk:Rhododendrites|talk]]</sup></tt> \\ 17:49, 6 December 2015 (UTC) |
||
# {{Support}} This would be very helpful. [[User:Corinne|Corinne]] ([[User talk:Corinne|talk]]) 03:05, 7 December 2015 (UTC) |
|||
<!--↑Put your text above this line↑--> |
<!--↑Put your text above this line↑--> |
||
<translate> |
<translate> |
Revision as of 03:06, 7 December 2015
This page is translatable, but you can only vote on the English version.
Voting instructions:
- Voting begins on Monday, November 30th and will end on Monday, December 14th.
- Any user with at least 100 edits on any project is eligible to vote. See participation requirements for more details.
- Positive votes marked with
Support and signature will be counted as the proposal's tally. There's no limit to the number of proposals for which you may cast support votes.
- Comments marked
Neutral or
Oppose are acceptable, in order to ask clarifying questions or raise potential problems for discussion, but they will not be counted as negative votes.
- Please do not add new proposals to this page; the proposals phase ended on November 22nd.
Color-coded WikiText editing
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 |
---|
|
Votes
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)
Support --Patrick87 (talk) 18:05, 30 November 2015 (UTC)
Support --Isacdaavid (talk) 02:14, 1 December 2015 (UTC)
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)
Support--Shizhao (talk) 09:17, 1 December 2015 (UTC)
Support —Ynhockey (talk) 09:48, 1 December 2015 (UTC)
Support —Tito☸Dutta 14:44, 1 December 2015 (UTC)
Support --Arnd (talk) 14:44, 1 December 2015 (UTC)
Support tufor (talk) 15:28, 1 December 2015 (UTC)
Support Flinga (talk) 16:19, 1 December 2015 (UTC)
Support It's hard for me to edit without this. Stevie is the man! Talk • Work 16:31, 1 December 2015 (UTC)
Support just like dreamweaver.--Temp3600 (talk) 16:39, 1 December 2015 (UTC)
Support --Urbanecm (talk) 17:42, 1 December 2015 (UTC)
Support --Etamni (talk) 18:03, 1 December 2015 (UTC)
Support --Woodcutterty (talk) 18:54, 1 December 2015 (UTC)
Support --Wesalius (talk) 18:59, 1 December 2015 (UTC)
Support --Fritzmann2002 (talk) 19:19, 1 December 2015 (UTC)
Neutral --Usien6 (talk) 19:22, 1 December 2015 (UTC) // As long as editors could opt-out.
Support Helder 23:48, 1 December 2015 (UTC)
Support Rdrozd (talk) 00:24, 2 December 2015 (UTC)
Support --Ilya (talk) 12:45, 2 December 2015 (UTC)
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)
Support--Manlleus (talk) 15:14, 2 December 2015 (UTC)
Support --AlessioMela (talk) 19:45, 2 December 2015 (UTC)
Support Mule hollandaise (talk) 21:07, 2 December 2015 (UTC)
Support --JQTriple7 (talk) 23:26, 2 December 2015 (UTC)
Support --MisterSanderson (talk) 04:52, 3 December 2015 (UTC)
Support --AS (talk) 09:36, 3 December 2015 (UTC)
Support --Aryan hindustan (talk) 10:30, 3 December 2015 (UTC)
Support: This will make editing a lot easier.--Bowleerin (talk) 11:23, 4 December 2015 (UTC)
Support Nikkimaria (talk) 01:33, 4 December 2015 (UTC)
Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
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)
Support --Ricordisamoa 01:15, 5 December 2015 (UTC)
Support Ardfeb (talk) 00:53, 6 December 2015 (UTC)
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)
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)
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 |
---|
|
Votes
- 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)
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)
- 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)
Support Szalakóta (talk) 16:50, 1 December 2015 (UTC)
- Why not, instead, an option under "gadgets" that, when checked, overrides all other preferences/javascript/whatnot? Eman235/talk 21:16, 1 December 2015 (UTC)
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)
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)
Support Nikkimaria (talk) 01:33, 4 December 2015 (UTC)
Support an option that would disable all custom js and css. -- Fauzan✆ talk ✉ email 16:45, 4 December 2015 (UTC)
Enable Apertium on cy, for Content Translation
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 |
---|
|
Votes
Support --Isacdaavid (talk) 02:13, 1 December 2015 (UTC)
Support --[Google works en - > cy, but is full of errors; NOT an option!] Llywelyn2000 (talk) 15:08, 1 December 2015 (UTC)
Support Litlok (talk) 08:20, 2 December 2015 (UTC)
Support Jason.nlw (talk) 09:59, 2 December 2015 (UTC)
Support EdwardLane (talk) 11:37, 2 December 2015 (UTC)
Support --Drgkl (talk) 11:53, 2 December 2015 (UTC)
Support --Barcelona (talk) 11:54, 2 December 2015 (UTC)
Support Cymrodor (talk) 12:56, 2 December 2015 (UTC)
Support – Ham II (sgwrs / talk) 19:11, 2 December 2015 (UTC)
Support, obviously. Eman235/talk 21:15, 2 December 2015 (UTC)
Support AlwynapHuw (talk) 05:43, 3 December 2015 (UTC)
Support - tucoxn\talk 14:04, 3 December 2015 (UTC)
Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
Support --Rhyswynne (talk) 21:12, 4 December 2015 (UTC)
Oppose Insufficient impact -- only affects a small number of wikis at best. MER-C (talk) 18:28, 6 December 2015 (UTC)
Generate automatic summary /* blah */ when I manually add a section heading when editing
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 |
---|
|
Votes
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)
Support Jenks24 (talk) 10:23, 30 November 2015 (UTC)
Support. --Stryn (talk) 18:55, 30 November 2015 (UTC)
Support Dalba 20:21, 30 November 2015 (UTC)
Support Szalakóta (talk) 16:52, 1 December 2015 (UTC)
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)
Support -- 2ReinreB2 (talk) 17:19, 1 December 2015 (UTC)
Support -- Grüße vom Sänger ♫(Reden) 22:12, 1 December 2015 (UTC)
Support Risker (talk) 03:46, 2 December 2015 (UTC)
Support —Beleg Tâl (talk) 17:09, 2 December 2015 (UTC)
Support – Ham II (sgwrs / talk) 19:12, 2 December 2015 (UTC)
Support I tend to do this manually, but hardly anyone else does. Eman235/talk 21:16, 2 December 2015 (UTC)
Support --Carrotkit (talk) 05:49, 3 December 2015 (UTC)
Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
Support --Jane023 (talk) 16:29, 4 December 2015 (UTC)
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)
Halve edit conflicts
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:
- 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.
- Pre populate all newly created articles with sections such as ==References== and ==See also== or equivalents in other languages
- 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 |
---|
|
Votes
Support 4nn1l2 (talk) 03:07, 30 November 2015 (UTC)
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)
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)
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)
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)
Support --MGChecker (talk) 20:01, 30 November 2015 (UTC)
Support MER-C (talk) 20:05, 30 November 2015 (UTC)
Support Dalba 20:29, 30 November 2015 (UTC)
Support Armbrust (talk) 22:41, 30 November 2015 (UTC)
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. –Davey2010Talk 02:56, 1 December 2015 (UTC)
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)
Support--Shizhao (talk) 09:20, 1 December 2015 (UTC)
Support · · · Peter (Southwood) (talk): 14:00, 1 December 2015 (UTC)
Support —Tito☸Dutta 14:45, 1 December 2015 (UTC)
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)
Support --Andyrom75 (talk) 15:57, 1 December 2015 (UTC)
Support Papuass (talk) 16:23, 1 December 2015 (UTC)
Support Goombiis (talk) 16:26, 1 December 2015 (UTC)
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)
Support -- Tisfoon (talk) 17:46, 1 December 2015 (UTC)
Support --Warp3 (talk) 18:00, 1 December 2015 (UTC)
- 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)
Support Artem.komisarenko (talk) 19:37, 1 December 2015 (UTC)
Support point 1 and 3, not point 2. Gap9551 (talk) 20:04, 1 December 2015 (UTC)
Support StevenJ81 (talk) 21:59, 1 December 2015 (UTC)
Support Alkamid (talk) 07:37, 2 December 2015 (UTC)
Support Especially #1. ...Aurora... (talk) 10:39, 2 December 2015 (UTC)
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)
- 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)
Support Needs careful implementation, but would make life a lot easier for many editors. PamD (talk) 21:35, 2 December 2015 (UTC)
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)
Support Not convinced by #2, though. Three-way diff would be another valid approach. — Arkanosis ✉ 13:55, 3 December 2015 (UTC)
Support - tucoxn\talk 14:05, 3 December 2015 (UTC)
Support edit conflicts are one annoying feature. Graeme Bartlett (talk) 04:16, 4 December 2015 (UTC)
Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
Support Grüße vom Sänger ♫(Reden) 17:20, 4 December 2015 (UTC)
Support Lester לסטר (talk) 18:04, 5 December 2015 (UTC)
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)
Improved diff compare screen
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 |
---|
|
Votes
Support 4nn1l2 (talk) 03:06, 30 November 2015 (UTC)
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)
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)
Support Jenks24 (talk) 10:21, 30 November 2015 (UTC)
Support MER-C (talk) 10:47, 30 November 2015 (UTC)
Support --Gnom (talk) 12:00, 30 November 2015 (UTC)
Support Lugnuts (talk) 12:03, 30 November 2015 (UTC)
Support Badly needed. Debresser (talk) 12:59, 30 November 2015 (UTC)
Support MrX (talk) 15:10, 30 November 2015 (UTC)
Support --Sphilbrick (talk) 16:25, 30 November 2015 (UTC)
Support BethNaught (talk) 17:45, 30 November 2015 (UTC)
Support Tryptofish (talk) 18:12, 30 November 2015 (UTC)
Support. --Stryn (talk) 18:59, 30 November 2015 (UTC)
Support --MGChecker (talk) 20:00, 30 November 2015 (UTC)
Support Dalba 20:28, 30 November 2015 (UTC)
Support Matiia (talk) 20:29, 30 November 2015 (UTC)
Support Voll (talk) 22:06, 30 November 2015 (UTC)
Support Armbrust (talk) 22:42, 30 November 2015 (UTC)
Support --Isacdaavid (talk) 02:17, 1 December 2015 (UTC)
Support YES --YodinT 02:24, 1 December 2015 (UTC)
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. –Davey2010Talk 03:01, 1 December 2015 (UTC)
Support Please. Doug Weller (talk) 09:42, 1 December 2015 (UTC)
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)
Support Casliber (talk) 05:11, 1 December 2015 (UTC)
Support--Kippelboy (talk) 05:35, 1 December 2015 (UTC)
Support - I think this is something many users will enjoy! Alleycat80 (talk) 09:02, 1 December 2015 (UTC)
Support--Gbeckmann (talk) 09:18, 1 December 2015 (UTC)
Support —Ynhockey (talk) 09:48, 1 December 2015 (UTC)
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)
Support And make the line numbers actually mean something usable. · · · Peter (Southwood) (talk): 14:02, 1 December 2015 (UTC)
Support --Arnd (talk) 14:45, 1 December 2015 (UTC)
Support --Continua Evoluzione (talk) 14:52, 1 December 2015 (UTC)
Support--KRLS (talk) 15:13, 1 December 2015 (UTC)
Support – Haltiamieli (talk) 15:17, 1 December 2015 (UTC)
Support — Quoth (talk) 15:19, 1 December 2015 (UTC)
Support tufor (talk) 15:29, 1 December 2015 (UTC)
Support --Nastoshka (talk) 15:40, 1 December 2015 (UTC)
Support --Andyrom75 (talk) 15:57, 1 December 2015 (UTC)
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)
Support Goombiis (talk) 16:27, 1 December 2015 (UTC)
Support a real code typer.--Temp3600 (talk) 16:42, 1 December 2015 (UTC)
Support JohanahoJ (talk) 16:46, 1 December 2015 (UTC)
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)
Support _anything_ that improves the various issues with diff. Stevie is the man! Talk • Work 17:20, 1 December 2015 (UTC)
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)
Support Wugapodes (talk) 17:24, 1 December 2015 (UTC)
Support -- Tisfoon (talk) 17:43, 1 December 2015 (UTC)
Support Jan.Kamenicek (talk) 18:48, 1 December 2015 (UTC)
Support --Wesalius (talk) 19:01, 1 December 2015 (UTC)
Support --Tdslk (talk) 19:04, 1 December 2015 (UTC)
Support Jules78120 (talk) 19:48, 1 December 2015 (UTC)
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)
Support --Woodcutterty (talk) 20:10, 1 December 2015 (UTC)
Support --Akela (talk) 20:59, 1 December 2015 (UTC)
Support Yes, improvement needed. Regards, Kertraon (talk) 21:59, 1 December 2015 (UTC)
Support StevenJ81 (talk) 21:59, 1 December 2015 (UTC)
Support --Grüße vom Sänger ♫(Reden) 22:17, 1 December 2015 (UTC)
Support Helder 23:48, 1 December 2015 (UTC)
Support --Emptywords (talk) 00:08, 2 December 2015 (UTC)
Support Vätte (talk) 01:17, 2 December 2015 (UTC)
Support --Chaoborus (talk) 02:23, 2 December 2015 (UTC)
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)
Support Risker (talk) 03:48, 2 December 2015 (UTC)
Support In veritas (talk) 04:26, 2 December 2015 (UTC)
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)
Support Alkamid (talk) 07:36, 2 December 2015 (UTC)
Support Litlok (talk) 08:22, 2 December 2015 (UTC)
Support Sidevar (talk) 10:33, 2 December 2015 (UTC)
Support ...Aurora... (talk) 10:42, 2 December 2015 (UTC)
Support --β16 - (talk) 11:46, 2 December 2015 (UTC)
Support --Renessaince (talk) 14:22, 2 December 2015 (UTC)
Support — NickK (talk) 14:40, 2 December 2015 (UTC)
Support Matěj Suchánek (talk) 15:46, 2 December 2015 (UTC)
Support --AlessioMela (talk) 19:47, 2 December 2015 (UTC)
Support Smarter diffs in general - yes, please. PamD (talk) 21:37, 2 December 2015 (UTC)
Support SteveStrummer (talk) 02:51, 3 December 2015 (UTC)
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)
Support --V111P (talk) 10:27, 3 December 2015 (UTC)
Support Oh yes please! Dcs002 (talk) 11:40, 3 December 2015 (UTC)
Support — Arkanosis ✉ 13:56, 3 December 2015 (UTC)
Support - tucoxn\talk 14:06, 3 December 2015 (UTC)
- 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)
Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
Support This could save a lot of editor time. Mark MacD (talk) 13:13, 4 December 2015 (UTC)
Support Jmatazzoni (talk) 17:47, 4 December 2015 (UTC)
Support Grüße vom Sänger ♫(Reden) 18:26, 4 December 2015 (UTC)
Support Avgr8 (talk) 20:57, 4 December 2015 (UTC)
Support --Yeza (talk) 16:40, 5 December 2015 (UTC)
Support Zamaster4536 (talk) 12:57, 6 December 2015 (UTC)
Support -- Sir Gawain (talk) 14:25, 6 December 2015 (UTC)
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)
Make it easier to cite different pages from a book as one reference
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 |
---|
|
Votes
Support I've always found using the workaround template a pain. Samwalton9 (talk) 10:12, 30 November 2015 (UTC)
Support TeriEmbrey (talk) 15:59, 30 November 2015 (UTC)
Support --Isacdaavid (talk) 02:18, 1 December 2015 (UTC)
Support--Shizhao (talk) 09:21, 1 December 2015 (UTC)
Support. Anthonyhcole (talk) 10:09, 1 December 2015 (UTC)
Support · · · Peter (Southwood) (talk): 14:03, 1 December 2015 (UTC)
Support GoEThe (talk) 14:57, 1 December 2015 (UTC)
Support — Quoth (talk) 15:16, 1 December 2015 (UTC)
Support --Vojtěch Dostál (talk) 16:15, 1 December 2015 (UTC)
Support Goombiis (talk) 16:25, 1 December 2015 (UTC)
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)
Support in a big way! This was needed years ago. Stevie is the man! Talk • Work 17:24, 1 December 2015 (UTC)
Support This would be a great improvement over the current situation. -- •
• hugarheimur 18:11, 1 December 2015 (UTC)
Support --Warp3 (talk) 18:15, 1 December 2015 (UTC)
Support --Coentor (talk) 18:22, 1 December 2015 (UTC)
Support Jan.Kamenicek (talk) 18:49, 1 December 2015 (UTC)
Support -- Akela (talk) 21:00, 1 December 2015 (UTC)
Support Vätte (talk) 01:21, 2 December 2015 (UTC)
Support Beyond My Ken (talk) 02:14, 2 December 2015 (UTC)
Support Risker (talk) 03:50, 2 December 2015 (UTC)
Support Antepenultimate (talk) 04:50, 2 December 2015 (UTC)
Support--Barcelona (talk) 11:58, 2 December 2015 (UTC)
Support--Manlleus (talk) 15:14, 2 December 2015 (UTC)
Support HughD (talk) 16:02, 2 December 2015 (UTC)
Support PamD (talk) 21:40, 2 December 2015 (UTC)
Support Wittylama (talk) 22:19, 3 December 2015 (UTC)
Support Nikkimaria (talk) 01:33, 4 December 2015 (UTC)
Support Graeme Bartlett (talk) 04:17, 4 December 2015 (UTC)
Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
Support -- Fauzan✆ talk ✉ email 16:47, 4 December 2015 (UTC)
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)
Support -- Sir Gawain (talk) 14:27, 6 December 2015 (UTC)
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)
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 |
---|
|
Votes
Comment This is easy to fix: phabricator:T115375#1838090. Nemo 18:34, 30 November 2015 (UTC)
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)
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)
Support--Manlleus (talk) 15:14, 2 December 2015 (UTC)
Support --AS (talk) 09:40, 3 December 2015 (UTC)
Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
Support Lester לסטר (talk) 18:06, 5 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
</ref>
missing for <ref>
tagerror. Surely it is past time to address such a fundamental issue? AuFCL (talk) 00:32, 13 November 2015 (UTC)
Earlier discussion and endorsements |
---|
|
Votes
Support strongly, at least for <ref> tags. --Purodha Blissenbach (talk) 14:40, 1 December 2015 (UTC)
Support Szalakóta (talk) 16:54, 1 December 2015 (UTC)
Comment What would be the purpose of a nested ref tag? Stevie is the man! Talk • Work 17:35, 1 December 2015 (UTC)
Support Jan.Kamenicek (talk) 18:51, 1 December 2015 (UTC)
Support --Usien6 (talk) 19:28, 1 December 2015 (UTC)
Support Popcorndude (talk) 03:34, 2 December 2015 (UTC)
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)
Support I've run across this at least once. -- Fauzan✆ talk ✉ email 16:49, 4 December 2015 (UTC)
Support. There is a workaround though and I'm using it very often. Halibutt (talk) 00:08, 5 December 2015 (UTC)
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)
Page contributors
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 |
---|
|
Votes
Support--Shizhao (talk) 09:23, 1 December 2015 (UTC)
Support I agree this should be built-in. Stevie is the man! Talk • Work 17:40, 1 December 2015 (UTC)
Support Risker (talk) 03:51, 2 December 2015 (UTC)
Support--Manlleus (talk) 15:17, 2 December 2015 (UTC)
Support This would be incredibly useful. Eman235/talk 21:22, 2 December 2015 (UTC)
Support --Misibacsi (talk) 04:43, 3 December 2015 (UTC)
Support --YBG (talk) 06:10, 3 December 2015 (UTC)
Support — Arkanosis ✉ 13:57, 3 December 2015 (UTC)
Support -- SantiLak (talk) 10:39, 4 December 2015 (UTC)
Support Halibutt (talk) 00:09, 5 December 2015 (UTC)
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)
Support This would be very helpful. Corinne (talk) 03:05, 7 December 2015 (UTC)
Save edits before publishing
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 |
---|
|
Votes
Support 4nn1l2 (talk) 03:10, 30 November 2015 (UTC)
Support בנימין (talk) 07:32, 30 November 2015 (UTC)
Support Samwalton9 (talk) 10:27, 30 November 2015 (UTC)
Comment On the condition there will be no extra step in saving my edits. Debresser (talk) 13:02, 30 November 2015 (UTC)
Support provided this is done only when the user wants it. עוד מישהו Od Mishehu 16:11, 30 November 2015 (UTC)
Support --MGChecker (talk) 20:01, 30 November 2015 (UTC)
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)
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)
Support --Isacdaavid (talk) 02:20, 1 December 2015 (UTC)
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)
Support Ckoerner (talk) 15:15, 1 December 2015 (UTC)
Support --Dodi123 (talk) 16:51, 1 December 2015 (UTC)
Support -- Tisfoon (talk) 17:47, 1 December 2015 (UTC)
Support per Purodha. Stevie is the man! Talk • Work 17:50, 1 December 2015 (UTC)
Support --Warp3 (talk) 18:32, 1 December 2015 (UTC)
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)
Support Artem.komisarenko (talk) 19:38, 1 December 2015 (UTC)
Support --Akela (talk) 21:03, 1 December 2015 (UTC)
Support Yes. Regards, Kertraon (talk) 22:02, 1 December 2015 (UTC)
Support Alkamid (talk) 07:39, 2 December 2015 (UTC)
Support --β16 - (talk) 11:48, 2 December 2015 (UTC)
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)
Support--Manlleus (talk) 15:17, 2 December 2015 (UTC)
Support Yes, please add automatic saving of drafts ala Gmail. —Pengo (talk) 21:18, 2 December 2015 (UTC)
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)
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)
Support Nikkimaria (talk) 01:33, 4 December 2015 (UTC)
Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
Support Jmatazzoni (talk) 17:38, 4 December 2015 (UTC)
Support Halibutt (talk) 00:10, 5 December 2015 (UTC)
Support Tar Lócesilion (queta) 12:58, 5 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:
- 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
- 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:
- Increment season win count
- If a conference game, increment season win count
- If winning percentage template in place, increment win count
- Increment coach win count
- If a conference game, increment season conference win count for the coach
- If winning percentage template in place, increment win count for the coach totals
- Increment all time win count
- If winning percentage template in place, increment win count for all time totals
- Proposed approach when a game is won:
- 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 |
---|
|
Votes
Support This, that and the other (talk) 13:23, 30 November 2015 (UTC)
Support--Shizhao (talk) 09:25, 1 December 2015 (UTC)
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)
Strongly oppose This proposal is all about making original research easier --Usien6 (talk) 19:33, 1 December 2015 (UTC)
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)
Support. And "simple math" is not considered to be OR. StevenJ81 (talk) 22:02, 1 December 2015 (UTC)
Support Elections & disasters too. ...Aurora... (talk) 10:45, 2 December 2015 (UTC)
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)
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)
Tell prospective users what Wikipedia is not for
The problem: prospective users get no explanation before they sign up of what Wikipedia is for, and more importantly what it is not for. They know "anyone can edit", and suppose that means "anyone can post whatever they like". Therefore very many new articles are posted which have no hope of becoming encyclopedic: non-notable Facebook-style autobiographies, CVs, company advertisements, copies of promotional websites, puff pieces about garage bands...
Who would benefit:
- Prospective Wikipedia users who are really looking for a social-networking site or an advertising platform would be spared wasted effort and disappointment.
- New page patrollers and administrators would be saved unproductive, tedious and repetitive work deleting unsuitable pages and explaining, over and over again, why Wikipedia is not for what the disappointed newbies wanted to do.
- If the flood of no-hope new articles were reduced, more time and attention could be given to those newbies who really want to contribute but need guidance.
- With fewer disappointed newbies out there, Wikipedia might lose some of its reputation for being unfriendly.
Proposed solution: the sign-up page you get on clicking "Create account" should say something like:
"Wikipedia is a project to build an encyclopedia. It is not a social-networking site, or a free platform for promotion. If you want to help build the encyclopedia, you will be very welcome; but if what you want to do is tell the world about yourself, your friends, your company, your client, your band, your good cause or your new original theory, this is not the site for you to do that."
For those who want more explanation, a link could be provided to a page giving brief summaries of the policies on autobiography, notability, advertising and conflict of interest. My experience of this problem is on en:wp, but I expect others have it, too: each project should be able to decide what message, if any, to display on the sign-on screen. JohnCD (talk) 09:27, 21 November 2015 (UTC)
Earlier discussion and endorsements |
---|
Note that it's already possible for local admins to add/edit content on the sign-up page, e.g. https://en.wikipedia.org/wiki/MediaWiki:Signupstart. Not sure what tech work would be required here. the wub "?!" 00:22, 25 November 2015 (UTC)
|
Votes
Support Lugnuts (talk) 12:05, 30 November 2015 (UTC)
- Full
Support —Tito☸Dutta 14:46, 1 December 2015 (UTC)
Support Seems like a good idea, so long as the message is diplomatic and unambiguous. I think it might be better to provide links to Wikipedia content guidelines rather than a direct message to new users. Sort of, trying to show prospective users what's expected of them, rather than discourage people from joining altogether. -- 2ReinreB2 (talk) 17:29, 1 December 2015 (UTC)
the need to do something, butSupport
the proposed solution as it comes off snotty and condescending. In its place, I would propose stating what's expected of editors in a professional tone, with appropriate links to details. E.g., "Wikipedia editors from the very new (like you!) to the most experienced are engaged in the serious editing of a comprehensive, high-quality encyclopedia (link 'encyclopedia', as many may not even know what an encyclopedia is and what it should be.). Newly created articles are expected to be about notable subjects. Edits to existing ones are expected to be..." Stevie is the man! Talk • Work 18:29, 1 December 2015 (UTC)Oppose
Neutral per MisterSanderson below. This isn't meant to detract from my previous statement about how it could work. Stevie is the man! Talk • Work 18:05, 4 December 2015 (UTC)
Support-- Akela (talk) 21:04, 1 December 2015 (UTC)
Oppose, this is just useless. Editors who came here to promote something will do it anyway, but good faith editors may think we consider them vandals and leave the project before their first edit — NickK (talk) 14:54, 2 December 2015 (UTC)
Support --Misibacsi (talk) 04:46, 3 December 2015 (UTC)
Support As a one-time popup, it can be written in a nice, encouraging way that doesn't put people off. This won't end the problem, not even close, but if it cuts it by 20% or even 10%, that's not a bad return. Even 5%. It has to be friendly and very readable, not like those stupid EULA's that nobody reads and we all just click OK. Like, have the window say what WP is and is not, and then have new users click on "I want to help make a great encyclopedia" or "I want to meet people who share my interests", or something broader. Just so it doesn't look like an automatic step. Dcs002 (talk) 12:25, 3 December 2015 (UTC)
Neutral. I like the idea, but it's not necessary to bring this to the Foundation's Technical Team, it can be solved locally by tech voluntaries. So I don't want to waste 1 of the 10 projects the Technical Team will implement.--MisterSanderson (talk) 15:53, 3 December 2015 (UTC)
Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
Oppose We don't need to talk about our own history as yet another hurdle to take for someone interested in contributing. Let them come contribute with as few barriers as possible. --Jane023 (talk) 16:32, 4 December 2015 (UTC)
Oppose totally pointless, every test in the past and has shown that it only confuses good faith people, makes them scared and doesn't actually teach them anything, while bad faith people just ignore it and do there thing anyways. —TheDJ (talk • contribs) 22:53, 5 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 |
---|
|
Votes
Support TeriEmbrey (talk) 16:00, 30 November 2015 (UTC)
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)
Support --Isacdaavid (talk) 02:21, 1 December 2015 (UTC)
Support as per Sphilbrick. IJBall (talk) 03:35, 1 December 2015 (UTC)
Support--Shizhao (talk) 09:26, 1 December 2015 (UTC)
Support--Kimdime (talk) 12:12, 1 December 2015 (UTC)
Support —Tito☸Dutta 14:46, 1 December 2015 (UTC)
Support Ckoerner (talk) 15:14, 1 December 2015 (UTC)
Support Goombiis (talk) 16:28, 1 December 2015 (UTC)
Support –Krinkle 16:58, 1 December 2015 (UTC)
Support love this tool on English Wiki. --2macia22 (talk) 17:07, 1 December 2015 (UTC)
Support. We are talking about it on French Wikipedia. --Etiennekd (talk) 18:08, 1 December 2015 (UTC)
Support Stevie is the man! Talk • Work 18:34, 1 December 2015 (UTC)
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)
Support --Usien6 (talk) 19:35, 1 December 2015 (UTC)
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)
- 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)
- 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)
Support StevenJ81 (talk) 22:03, 1 December 2015 (UTC)
Support Helder 23:48, 1 December 2015 (UTC)
Support – Ham II (sgwrs / talk) 19:13, 2 December 2015 (UTC)
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)
Support RefToolbar is so helpful, let's please share it with the other Wikis. PamD (talk) 21:39, 2 December 2015 (UTC)
Support Nikkimaria (talk) 01:33, 4 December 2015 (UTC)
Support SantiLak (talk) 10:39, 4 December 2015 (UTC)
Support — Rhododendrites talk \\ 17:56, 6 December 2015 (UTC)