Wikimedia Meta-Wiki

Encuesta sobre los deseos de la comunidad 2015/Edición

< Community Wishlist Survey 2015
This page is a translated version of the page Community Wishlist Survey 2015/Editing and the translation is 100% complete.
Other languages:

Edición de código wiki con resaltado con colores

Tracked in Phabricator:
Task T101246
Tracked in Phabricator:
Task T104479

Hay algunos experimentos para colorear el código wiki (incluyendo un accesorio en la wikipedia en inglés y una implementación funcional en la aplicación para Android). Esto se debería implementar como una función real del editor de código.

Earlier discussion and endorsements
Is it like mw:Extension:CodeMirror? --Pastakhov (talk) 17:40, 20 May 2015 (UTC)[reply]
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)[reply]
@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)[reply]
  Endorsed +1 --AS (talk) 16:29, 27 May 2015 (UTC)[reply]
This could be considered part of the "modern wikitext editor" project. Cscott (talk) 18:21, 11 November 2015 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
  Endorsed--Shizhao (talk) 07:59, 12 November 2015 (UTC)[reply]
  Endorsed --Edgars2007 (talk) 11:47, 12 November 2015 (UTC)[reply]
  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)[reply]
  Endorsed--Lsanabria (talk) 12:19, 20 November 2015 (UTC)[reply]

Votos

  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)[reply]
  2.   Support --Patrick87 (talk) 18:05, 30 November 2015 (UTC)[reply]
  3.   Support --Isacdaavid (talk) 02:14, 1 December 2015 (UTC)[reply]
  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)[reply]
  5.   Support--Shizhao (talk) 09:17, 1 December 2015 (UTC)[reply]
  6.   Support —Ynhockey (talk) 09:48, 1 December 2015 (UTC)[reply]
  7.   Support —Tito☸Dutta 14:44, 1 December 2015 (UTC)[reply]
  8.   Support --Arnd (talk) 14:44, 1 December 2015 (UTC)[reply]
  9.   Support tufor (talk) 15:28, 1 December 2015 (UTC)[reply]
  10.   Support Flinga (talk) 16:19, 1 December 2015 (UTC)[reply]
  11.   Support It's hard for me to edit without this. Stevie is the man! Talk • Work 16:31, 1 December 2015 (UTC)[reply]
  12.   Support just like dreamweaver.--Temp3600 (talk) 16:39, 1 December 2015 (UTC)[reply]
  13.   Support --Urbanecm (talk) 17:42, 1 December 2015 (UTC)[reply]
  14.   Support --Etamni (talk) 18:03, 1 December 2015 (UTC)[reply]
  15.   Support --Woodcutterty (talk) 18:54, 1 December 2015 (UTC)[reply]
  16.   Support --Wesalius (talk) 18:59, 1 December 2015 (UTC)[reply]
  17.   Support --Fritzmann2002 (talk) 19:19, 1 December 2015 (UTC)[reply]
  18.   Neutral --Usien6 (talk) 19:22, 1 December 2015 (UTC) // As long as editors could opt-out.[reply]
  19.   Support Helder 23:48, 1 December 2015 (UTC)[reply]
  20.   Support Rdrozd (talk) 00:24, 2 December 2015 (UTC)[reply]
  21.   Support --Ilya (talk) 12:45, 2 December 2015 (UTC)[reply]
  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)[reply]
  23.   Support--Manlleus (talk) 15:14, 2 December 2015 (UTC)[reply]
  24.   Support --AlessioMela (talk) 19:45, 2 December 2015 (UTC)[reply]
  25.   Support Mule hollandaise (talk) 21:07, 2 December 2015 (UTC)[reply]
  26.   Support --JQTriple7 (talk) 23:26, 2 December 2015 (UTC)[reply]
  27.   Support --MisterSanderson (talk) 04:52, 3 December 2015 (UTC)[reply]
  28.   Support --AS (talk) 09:36, 3 December 2015 (UTC)[reply]
  29.   Support --Aryan hindustan (talk) 10:30, 3 December 2015 (UTC)[reply]
  30.   Support: This will make editing a lot easier.--Bowleerin (talk) 11:23, 4 December 2015 (UTC)[reply]
  31.   Support Nikkimaria (talk) 01:33, 4 December 2015 (UTC)[reply]
  32.   Support SantiLak (talk) 10:39, 4 December 2015 (UTC)[reply]
  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)[reply]
  34.   Support --Ricordisamoa 01:15, 5 December 2015 (UTC)[reply]
  35.   Support Ardfeb (talk) 00:53, 6 December 2015 (UTC)[reply]
  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)[reply]
  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)[reply]
  38.   Support Mpn (talk) 18:22, 7 December 2015 (UTC)[reply]
  39.   Support --Waldir (talk) 14:50, 8 December 2015 (UTC)[reply]
  40.   Support - Bcharles (talk) 04:13, 9 December 2015 (UTC)[reply]
  41.   Support Therud (talk) 09:22, 10 December 2015 (UTC)[reply]
  42.   Support Lsanabria (talk) 15:22, 10 December 2015 (UTC)[reply]
  43.   Support --Edgars2007 (talk) 08:59, 12 December 2015 (UTC)[reply]
  44.   Support --NaBUru38 (talk) 03:37, 13 December 2015 (UTC)[reply]
  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)[reply]


Modo de interfaz de usuario por defecto

La gente que ha estado editando por mucho tiempo suele tener interfaces altamente personalizadas, y también tienen una variedad de herramientas/derechos que no están disponibles para los usuarios nuevos. Estas son dos cosas importantes, pero hace díficil para los usuarios existentes entender los temas que encaran los usuarios nuevos. Un ejemplo práctico de esto es, cuando den presentaciones a usuarios nuevos en eventos de promoción, muchos Wikipedistas crean una cuenta de usuario 'falsa' específicamente para poder mostrar la interfaz de usuario 'normal' a los novatos. Es importante que el presentador nunca presione 'guardar' cuando muestre cómo editar, porque entonces esta cuenta de usuario tendría el derecho de auto-confirmado.

Propongo la creación de un 'modo' preferido por el usuario que convierte tanto la interfaz de usuario como los derechos de usuario en el' predeterminado' para un usuario recién registrado. Llámelo "nuevo modo de usuario" o "modo predeterminado". Crucialmente, editar en este modo significaría que el usuario no se convertiría en 'autoconfirmado' cuando guarde sus ediciones, pero seguiría contando el cambio en su cuenta de edición. Podría estar marcado en la historia con una etiqueta de #defaultMode o algo así. Wittylama (talk) 10:27, 21 November 2015 (UTC)[reply]

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)[reply]
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)[reply]

Votos

  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)[reply]
  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)[reply]
    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)[reply]
    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)[reply]
  3.   Support Szalakóta (talk) 16:50, 1 December 2015 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  7.   Support Nikkimaria (talk) 01:33, 4 December 2015 (UTC)[reply]
  8.   Support an option that would disable all custom js and css. -- Fauzan✆ talk ✉ email 16:45, 4 December 2015 (UTC)[reply]
  9.   Support Juetho (talk) 11:57, 12 December 2015 (UTC)[reply]
  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)[reply]

Activar Apertium en cy para la traducción de contenidos

Tracked in Phabricator:
Task T102101

La traducción de contenido NO funciona en cy; está ahi, sentada, redundante, jugueteando con sus pulgares. Activar Apertium permitiría usarla. Aquí hay una conversación que terminó en un callejón sin salida. Resolvamos el problema y activemos las traducciones en -> cy. Llywelyn2000 (talk) 12:09, 20 November 2015 (UTC)[reply]

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)[reply]
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)[reply]
… 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)[reply]
  Endorsed -- Oergell (talk) 12:41, 20 November 2015 (UTC)[reply]
  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)[reply]

Votos

  1.   Support --Isacdaavid (talk) 02:13, 1 December 2015 (UTC)[reply]
  2.   Support --[Google works en - > cy, but is full of errors; NOT an option!] Llywelyn2000 (talk) 15:08, 1 December 2015 (UTC)[reply]
  3.   Support Litlok (talk) 08:20, 2 December 2015 (UTC)[reply]
  4.   Support Jason.nlw (talk) 09:59, 2 December 2015 (UTC)[reply]
  5.   Support EdwardLane (talk) 11:37, 2 December 2015 (UTC)[reply]
  6.   Support --Drgkl (talk) 11:53, 2 December 2015 (UTC)[reply]
  7.   Support --Barcelona (talk) 11:54, 2 December 2015 (UTC)[reply]
  8.   Support Cymrodor (talk) 12:56, 2 December 2015 (UTC)[reply]
  9.   Support – Ham II (sgwrs / talk) 19:11, 2 December 2015 (UTC)[reply]
  10.   Support, obviously. Eman235/talk 21:15, 2 December 2015 (UTC)[reply]
  11.   Support AlwynapHuw (talk) 05:43, 3 December 2015 (UTC)[reply]
  12.   Support - tucoxn\talk 14:04, 3 December 2015 (UTC)[reply]
  13.   Support SantiLak (talk) 10:39, 4 December 2015 (UTC)[reply]
  14.   Support --Rhyswynne (talk) 21:12, 4 December 2015 (UTC)[reply]
  15.   Oppose Insufficient impact -- only affects a small number of wikis at best. MER-C (talk) 18:28, 6 December 2015 (UTC)[reply]
  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)[reply]
  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)[reply]

Generar un resumen automático /* blah */ cuando agrego manualmente un encabezado de sección cuando edito

Tracked in Phabricator:
Task T22307

Ver la solicitud en Phabricator (enlazada en el margen derecho). Esto sería particularmente útil en las páginas de discusión. Parece una tarea relativamente sencilla. Tal vez alguien pueda trabajar en ella después de estar seis años en la lsita de deseos. Gracias, Wbm1058 (talk) 14:53, 16 November 2015 (UTC)[reply]

Earlier discussion and endorsements

Votos

  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)[reply]
  2.   Support Jenks24 (talk) 10:23, 30 November 2015 (UTC)[reply]
  3.   Support. --Stryn (talk) 18:55, 30 November 2015 (UTC)[reply]
  4.   Support Dalba 20:21, 30 November 2015 (UTC)[reply]
  5.   Support Szalakóta (talk) 16:52, 1 December 2015 (UTC)[reply]
  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)[reply]
  7.   Support -- 2ReinreB2 (talk) 17:19, 1 December 2015 (UTC)[reply]
  8.   Support -- Grüße vom Sänger ♫(Reden) 22:12, 1 December 2015 (UTC)[reply]
  9.   Support Risker (talk) 03:46, 2 December 2015 (UTC)[reply]
  10.   Support —Beleg Tâl (talk) 17:09, 2 December 2015 (UTC)[reply]
  11.   Support – Ham II (sgwrs / talk) 19:12, 2 December 2015 (UTC)[reply]
  12.   Support I tend to do this manually, but hardly anyone else does. Eman235/talk 21:16, 2 December 2015 (UTC)[reply]
  13.   Support --Carrotkit (talk) 05:49, 3 December 2015 (UTC)[reply]
  14.   Support SantiLak (talk) 10:39, 4 December 2015 (UTC)[reply]
  15.   Support --Jane023 (talk) 16:29, 4 December 2015 (UTC)[reply]
  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)[reply]
  17.   Support as proposer. Wbm1058 (talk) 19:06, 7 December 2015 (UTC)[reply]
  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)[reply]
  19.   Support Therud (talk) 09:23, 10 December 2015 (UTC)[reply]
  20.   Support QuartierLatin1968 (talk) 04:38, 12 December 2015 (UTC)[reply]
  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)[reply]

Reducir a la mitad los conflictos de edición

Tracked in Phabricator:
Task T72163

Todos tenemos conflictos de edición, los que hemos estado en wikipedia somos mayormente quienes hemos aprendido a resolverlos, o a hacer muchas pequeñas ediciones en orden a minimizar el tiempo perdido cuando entramos en conflictos de edición. Han habido muchas propuestsa en bugzilla y en otros lados para reducir los conflictos de edición, pero no han tenido los recursos ya que mantener a los nuevos editores no era antes una prioridad. Pero esta es una de las cosas que los nuevos editores encuentran más desagradables sobre wikipedia, y usualmente es el novato el que pierde el conflicto de edición porque se toman minutos en sus ediciones y el categorizador o el que pone plantillas solamente segundos. (por supuesto esto se pone peor cuando eliminan la edición y demoran a los editores.)

Actualmente ni siquiera tenemos estadísticas públicas del número de editores que perdemos por conflictos de edición. Simplemente midiéndolos y el número de veces que predicen que un editor se irá podría confirmar que esta fue una de las mayores causas por las que buenos nuevos editores se fueron, pero arreglar algunos de las cosas que causan conflictos de edición podrían costar mucho menos.

Eliminar todos los conflictos de edición requeriría un cambio revolucionario en la interfaz de usuario, pero bajar los conflictos de edición a la mitad tomaría una bastante menor inversión.

Las formas específicas de reducir los conflictos de edición incluyen:

  1. Tratar el agregar una plantilla al principio de un artículo o una categoría al final como no conflictiva con la alteración de los contenidos que hay en el medio.
  2. Pre llenar todos los artículos recién creados con secciones como == Referencias == y == Véase también == o sus equivalentes en otros idiomas
  3. Tratar # igual que un encabezado de sección por lo que dos respuestas en dos diferentes hilos de la misma sección no sean tratados como un conflicto. WereSpielChequers (talk) 20:54, 10 November 2015 (UTC)[reply]
Earlier discussion and endorsements

Votos

  1.   Support 4nn1l2 (talk) 03:07, 30 November 2015 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  6.   Support --MGChecker (talk) 20:01, 30 November 2015 (UTC)[reply]
  7.   Support MER-C (talk) 20:05, 30 November 2015 (UTC)[reply]
  8.   Support Dalba 20:29, 30 November 2015 (UTC)[reply]
  9.   Support Armbrust (talk) 22:41, 30 November 2015 (UTC)[reply]
  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. –Davey2010Talk 02:56, 1 December 2015 (UTC)[reply]
  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)[reply]
  12.   Support--Shizhao (talk) 09:20, 1 December 2015 (UTC)[reply]
  13.   Support · · · Peter (Southwood) (talk): 14:00, 1 December 2015 (UTC)[reply]
  14.   Support —Tito☸Dutta 14:45, 1 December 2015 (UTC)[reply]
  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)[reply]
  16.   Support --Andyrom75 (talk) 15:57, 1 December 2015 (UTC)[reply]
  17.   Support Papuass (talk) 16:23, 1 December 2015 (UTC)[reply]
  18.   Support Goombiis (talk) 16:26, 1 December 2015 (UTC)[reply]
  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)[reply]
  20.   Support -- Tisfoon (talk) 17:46, 1 December 2015 (UTC)[reply]
  21.   Support --Warp3 (talk) 18:00, 1 December 2015 (UTC)[reply]
  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)[reply]
  23.   Support Artem.komisarenko (talk) 19:37, 1 December 2015 (UTC)[reply]
  24.   Support point 1 and 3, not point 2. Gap9551 (talk) 20:04, 1 December 2015 (UTC)[reply]
  25.   Support StevenJ81 (talk) 21:59, 1 December 2015 (UTC)[reply]
  26.   Support Alkamid (talk) 07:37, 2 December 2015 (UTC)[reply]
  27.   Support Especially #1. ...Aurora... (talk) 10:39, 2 December 2015 (UTC)[reply]
  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)[reply]
  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)[reply]
  30.   Support Needs careful implementation, but would make life a lot easier for many editors. PamD (talk) 21:35, 2 December 2015 (UTC)[reply]
  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)[reply]
  32.   Support Not convinced by #2, though. Three-way diff would be another valid approach. — Arkanosis ✉ 13:55, 3 December 2015 (UTC)[reply]
  33.   Support - tucoxn\talk 14:05, 3 December 2015 (UTC)[reply]
  34.   Support edit conflicts are one annoying feature. Graeme Bartlett (talk) 04:16, 4 December 2015 (UTC)[reply]
  35.   Support SantiLak (talk) 10:39, 4 December 2015 (UTC)[reply]
  36.   Support Grüße vom Sänger ♫(Reden) 17:20, 4 December 2015 (UTC)[reply]
  37.   Support Lester לסטר (talk) 18:04, 5 December 2015 (UTC)[reply]
  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)[reply]
    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)[reply]
    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)[reply]
  39.   Support --Ziko (talk) 13:51, 9 December 2015 (UTC)[reply]
  40.   Support --Ochilov (talk) 15:18, 9 December 2015 (UTC)[reply]
  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.[reply]
  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)[reply]
  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)[reply]
  44.   Neutral I think a better edit conflict UI is the lower-hanging fruit (T108664) --Tgr (talk) 22:45, 13 December 2015 (UTC)[reply]

Mejorar la pantalla para comparar diferencias

Tracked in Phabricator:
Task T15466
Tracked in Phabricator:
Task T15462

Apuesto que amas las revisiones de diferencias como esta. Debería ser posible mejorar esta vista de comparación de diferencias. Para una inspiración puedes mirar el dispositivo wikEdDiff. http://i.imgur.com/R9ZfCA1.jpg The Quixotic Potato (talk) 06:41, 29 September 2015 (UTC)[reply]
[Combinado desde propuestas separadas:] Cuando alguien mueve un párrafo y después lo edita, esta edición no se muestra separadamente por la funcionalidad "Diferencias entre revisiones". Este problema también ocurre cuando alguien inserta una línea en blanco sobre un párrafo y luego lo edita. Gracias, --Gnom (talk) 10:12, 12 November 2015 (UTC)[reply]

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)[reply]
  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)[reply]
  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)[reply]
@V111P: Not true. You can enable WikEdDiff separately: w:en:User:Cacycle/wikEdDiff. --Edgars2007 (talk) 06:48, 14 November 2015 (UTC)[reply]
@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)[reply]
OK, thanks. Didn't notice that. --Edgars2007 (talk) 09:58, 14 November 2015 (UTC)[reply]
  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)[reply]
  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)[reply]
  Endorsed 4nn1l2 (talk) 23:24, 18 November 2015 (UTC)[reply]
@Gnom: answer to your problem is w:en:User:Cacycle/wikEdDiff. --Edgars2007 (talk) 06:50, 14 November 2015 (UTC)[reply]
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)[reply]

Votos

  1.   Support 4nn1l2 (talk) 03:06, 30 November 2015 (UTC)[reply]
  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)[reply]
  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)[reply]
  4.   Support Jenks24 (talk) 10:21, 30 November 2015 (UTC)[reply]
  5.   Support MER-C (talk) 10:47, 30 November 2015 (UTC)[reply]
  6.   Support --Gnom (talk) 12:00, 30 November 2015 (UTC)[reply]
  7.   Support Lugnuts (talk) 12:03, 30 November 2015 (UTC)[reply]
  8.   Support Badly needed. Debresser (talk) 12:59, 30 November 2015 (UTC)[reply]
  9.   Support MrX (talk) 15:10, 30 November 2015 (UTC)[reply]
  10.   Support --Sphilbrick (talk) 16:25, 30 November 2015 (UTC)[reply]
  11.   Support BethNaught (talk) 17:45, 30 November 2015 (UTC)[reply]
  12.   Support Tryptofish (talk) 18:12, 30 November 2015 (UTC)[reply]
  13.   Support. --Stryn (talk) 18:59, 30 November 2015 (UTC)[reply]
  14.   Support --MGChecker (talk) 20:00, 30 November 2015 (UTC)[reply]
  15.   Support Dalba 20:28, 30 November 2015 (UTC)[reply]
  16.   Support Matiia (talk) 20:29, 30 November 2015 (UTC)[reply]
  17.   Support Voll (talk) 22:06, 30 November 2015 (UTC)[reply]
  18.   Support Armbrust (talk) 22:42, 30 November 2015 (UTC)[reply]
  19.   Support --Isacdaavid (talk) 02:17, 1 December 2015 (UTC)[reply]
  20.   Support YES --YodinT 02:24, 1 December 2015 (UTC)[reply]
  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. –Davey2010Talk 03:01, 1 December 2015 (UTC)[reply]
  22.   Support Please. Doug Weller (talk) 09:42, 1 December 2015 (UTC)[reply]
  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)[reply]
  24.   Support Casliber (talk) 05:11, 1 December 2015 (UTC)[reply]
  25.   Support--Kippelboy (talk) 05:35, 1 December 2015 (UTC)[reply]
  26.   Support - I think this is something many users will enjoy! Alleycat80 (talk) 09:02, 1 December 2015 (UTC)[reply]
  27.   Support--Gbeckmann (talk) 09:18, 1 December 2015 (UTC)[reply]
  28.   Support —Ynhockey (talk) 09:48, 1 December 2015 (UTC)[reply]
  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)[reply]
  30.   Support And make the line numbers actually mean something usable. · · · Peter (Southwood) (talk): 14:02, 1 December 2015 (UTC)[reply]
  31.   Support --Arnd (talk) 14:45, 1 December 2015 (UTC)[reply]
  32.   Support --Continua Evoluzione (talk) 14:52, 1 December 2015 (UTC)[reply]
  33.   Support--KRLS (talk) 15:13, 1 December 2015 (UTC)[reply]
  34.   Support – Haltiamieli (talk) 15:17, 1 December 2015 (UTC)[reply]
  35.   Support — Quoth (talk) 15:19, 1 December 2015 (UTC)[reply]
  36.   Support tufor (talk) 15:29, 1 December 2015 (UTC)[reply]
  37.   Support --Nastoshka (talk) 15:40, 1 December 2015 (UTC)[reply]
  38.   Support --Andyrom75 (talk) 15:57, 1 December 2015 (UTC)[reply]
  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)[reply]
  40.   Support Goombiis (talk) 16:27, 1 December 2015 (UTC)[reply]
  41.   Support a real code typer.--Temp3600 (talk) 16:42, 1 December 2015 (UTC)[reply]
  42.   Support JohanahoJ (talk) 16:46, 1 December 2015 (UTC)[reply]
  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)[reply]
  44.   Support _anything_ that improves the various issues with diff. Stevie is the man! Talk • Work 17:20, 1 December 2015 (UTC)[reply]
  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)[reply]
  46.   Support Wugapodes (talk) 17:24, 1 December 2015 (UTC)[reply]
  47.   Support -- Tisfoon (talk) 17:43, 1 December 2015 (UTC)[reply]
  48.   Support Jan.Kamenicek (talk) 18:48, 1 December 2015 (UTC)[reply]
  49.   Support --Wesalius (talk) 19:01, 1 December 2015 (UTC)[reply]
  50.   Support --Tdslk (talk) 19:04, 1 December 2015 (UTC)[reply]
  51.   Support Jules78120 (talk) 19:48, 1 December 2015 (UTC)[reply]
  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)[reply]
  53.   Support --Woodcutterty (talk) 20:10, 1 December 2015 (UTC)[reply]
  54.   Support --Akela (talk) 20:59, 1 December 2015 (UTC)[reply]
  55.   Support Yes, improvement needed. Regards, Kertraon (talk) 21:59, 1 December 2015 (UTC)[reply]
  56.   Support StevenJ81 (talk) 21:59, 1 December 2015 (UTC)[reply]
  57.   Support --Grüße vom Sänger ♫(Reden) 22:17, 1 December 2015 (UTC)[reply]
  58.   Support Helder 23:48, 1 December 2015 (UTC)[reply]
  59.   Support --Emptywords (talk) 00:08, 2 December 2015 (UTC)[reply]
  60.   Support Vätte (talk) 01:17, 2 December 2015 (UTC)[reply]
  61.   Support --Chaoborus (talk) 02:23, 2 December 2015 (UTC)[reply]
  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)[reply]
  63.   Support Risker (talk) 03:48, 2 December 2015 (UTC)[reply]
  64.   Support In veritas (talk) 04:26, 2 December 2015 (UTC)[reply]
  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)[reply]
  66.   Support Alkamid (talk) 07:36, 2 December 2015 (UTC)[reply]
  67.   Support Litlok (talk) 08:22, 2 December 2015 (UTC)[reply]
  68.   Support Sidevar (talk) 10:33, 2 December 2015 (UTC)[reply]
  69.   Support ...Aurora... (talk) 10:42, 2 December 2015 (UTC)[reply]
  70.   Support --β16 - (talk) 11:46, 2 December 2015 (UTC)[reply]
  71.   Support --Renessaince (talk) 14:22, 2 December 2015 (UTC)[reply]
  72.   Support — NickK (talk) 14:40, 2 December 2015 (UTC)[reply]
  73.   Support Matěj Suchánek (talk) 15:46, 2 December 2015 (UTC)[reply]
  74.   Support --AlessioMela (talk) 19:47, 2 December 2015 (UTC)[reply]
  75.   Support Smarter diffs in general - yes, please. PamD (talk) 21:37, 2 December 2015 (UTC)[reply]
  76.   Support SteveStrummer (talk) 02:51, 3 December 2015 (UTC)[reply]
  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)[reply]
  78.   Support --V111P (talk) 10:27, 3 December 2015 (UTC)[reply]
  79.   Support Oh yes please! Dcs002 (talk) 11:40, 3 December 2015 (UTC)[reply]
  80.   Support — Arkanosis ✉ 13:56, 3 December 2015 (UTC)[reply]
  81.   Support - tucoxn\talk 14:06, 3 December 2015 (UTC)[reply]
  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)[reply]
  83.   Support SantiLak (talk) 10:39, 4 December 2015 (UTC)[reply]
  84.   Support This could save a lot of editor time. Mark MacD (talk) 13:13, 4 December 2015 (UTC)[reply]
  85.   Support Jmatazzoni (talk) 17:47, 4 December 2015 (UTC)[reply]
  86.   Support Grüße vom Sänger ♫(Reden) 18:26, 4 December 2015 (UTC)[reply]
  87.   Support Avgr8 (talk) 20:57, 4 December 2015 (UTC)[reply]
  88.   Support --Yeza (talk) 16:40, 5 December 2015 (UTC)[reply]
  89.   Support Zamaster4536 (talk) 12:57, 6 December 2015 (UTC)[reply]
  90.   Support -- Sir Gawain (talk) 14:25, 6 December 2015 (UTC)[reply]
  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)[reply]
  92.   Support Wbm1058 (talk) 16:05, 7 December 2015 (UTC)[reply]
  93.   Support Mpn (talk) 18:25, 7 December 2015 (UTC)[reply]
  94.   Support --Waldir (talk) 14:54, 8 December 2015 (UTC)[reply]
  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)[reply]
  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)[reply]
  97.   Support Frewaz (talk) 23:18, 11 December 2015 (UTC)[reply]
  98.   Support mainly spaces and punctuations -- Juetho (talk) 11:57, 12 December 2015 (UTC)[reply]
  99.   Support Nocowardsoulismine (talk) 16:30, 12 December 2015 (UTC)[reply]
  100.   Support HoboMcJoe (talk) 00:29, 13 December 2015 (UTC)[reply]
  101.   Support --NaBUru38 (talk) 03:40, 13 December 2015 (UTC)[reply]
  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)[reply]
  103.   Support --ESM (talk) 16:13, 13 December 2015 (UTC)[reply]
  104.   Support --Tgr (talk) 22:43, 13 December 2015 (UTC)[reply]
  105.   Support --Davidpar (talk) 14:26, 14 December 2015 (UTC)[reply]
  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)[reply]


Facilitar el citar múltiples páginas de libro como una sola referencia

Tracked in Phabricator:
Task T100645

Cuando cito diferentes páginas de un libro dentro de un mismo artículo, tengo que citar el libro de forma separada múltiples veces. Tenemos una función llamada reutilizar cita que funciona muy bien en el editor visual pero no para diferentes páginas del mismo libro. Ver las tareas en Phabricator phab:T100645 y phab:T15127. Gracias, --Gnom (talk) 10:07, 12 November 2015 (UTC)[reply]

Earlier discussion and endorsements
  •   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)[reply]
  •   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)[reply]
  •   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)[reply]

Votos

  1.   Support I've always found using the workaround template a pain. Samwalton9 (talk) 10:12, 30 November 2015 (UTC)[reply]
  2.   Support TeriEmbrey (talk) 15:59, 30 November 2015 (UTC)[reply]
  3.   Support --Isacdaavid (talk) 02:18, 1 December 2015 (UTC)[reply]
  4.   Support--Shizhao (talk) 09:21, 1 December 2015 (UTC)[reply]
  5.   Support. Anthonyhcole (talk) 10:09, 1 December 2015 (UTC)[reply]
  6.   Support · · · Peter (Southwood) (talk): 14:03, 1 December 2015 (UTC)[reply]
  7.   Support GoEThe (talk) 14:57, 1 December 2015 (UTC)[reply]
  8.   Support — Quoth (talk) 15:16, 1 December 2015 (UTC)[reply]
  9.   Support --Vojtěch Dostál (talk) 16:15, 1 December 2015 (UTC)[reply]
  10.   Support Goombiis (talk) 16:25, 1 December 2015 (UTC)[reply]
  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)[reply]
  12.   Support in a big way! This was needed years ago. Stevie is the man! Talk • Work 17:24, 1 December 2015 (UTC)[reply]
  13.   Support This would be a great improvement over the current situation. -- •   • hugarheimur 18:11, 1 December 2015 (UTC)[reply]
  14.   Support --Warp3 (talk) 18:15, 1 December 2015 (UTC)[reply]
  15.   Support --Coentor (talk) 18:22, 1 December 2015 (UTC)[reply]
  16.   Support Jan.Kamenicek (talk) 18:49, 1 December 2015 (UTC)[reply]
  17.   Support -- Akela (talk) 21:00, 1 December 2015 (UTC)[reply]
  18.   Support Vätte (talk) 01:21, 2 December 2015 (UTC)[reply]
  19.   Support Beyond My Ken (talk) 02:14, 2 December 2015 (UTC)[reply]
  20.   Support Risker (talk) 03:50, 2 December 2015 (UTC)[reply]
  21.   Support Antepenultimate (talk) 04:50, 2 December 2015 (UTC)[reply]
  22.   Support--Barcelona (talk) 11:58, 2 December 2015 (UTC)[reply]
  23.   Support--Manlleus (talk) 15:14, 2 December 2015 (UTC)[reply]
  24.   Support HughD (talk) 16:02, 2 December 2015 (UTC)[reply]
  25.   Support PamD (talk) 21:40, 2 December 2015 (UTC)[reply]
  26.   Support Wittylama (talk) 22:19, 3 December 2015 (UTC)[reply]
  27.   Support Nikkimaria (talk) 01:33, 4 December 2015 (UTC)[reply]
  28.   Support Graeme Bartlett (talk) 04:17, 4 December 2015 (UTC)[reply]
  29.   Support SantiLak (talk) 10:39, 4 December 2015 (UTC)[reply]
  30.   Support -- Fauzan✆ talk ✉ email 16:47, 4 December 2015 (UTC)[reply]
  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)[reply]
  32.   Support -- Sir Gawain (talk) 14:27, 6 December 2015 (UTC)[reply]
  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)[reply]
  34.   Support--Joris Egger (talk) 21:08, 7 December 2015 (UTC)[reply]
  35.   Support Gamaliel (talk) 15:49, 8 December 2015 (UTC)[reply]
  36.   Support I cannot emphasize enough how much easier this would make editors' lives. Daniel Case (talk) 19:20, 8 December 2015 (UTC)[reply]
  37.   Support - Bcharles (talk) 04:58, 9 December 2015 (UTC)[reply]
    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)[reply]
  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)[reply]
  39.   Support AlbinoFerret 18:32, 10 December 2015 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]


Combinar la herramienta de traducción de contenidos y el editor visual en una sola herramienta

El concepto de traducción de contenidos es muy bueno. Las ediciones más grandes de wikipedia (especialmente la de inglés) es la fuente principal para artículos en otros idiomas. Pero en la forma actual de la Traducción de Contenidos, tú puedes solamente traducir un artículo, pero no puedes agregar información de otras fuentes, agregar plantillas locales, o incluso cambiar/agregar archivos de media, hasta que publiques el artículo. Mi sugerencia es fusionar la traducción de contenidos con el editor visual en una herramienta, en la cual traducir sería una opción. בנימין (talk) 15:16, 10 November 2015 (UTC)[reply]

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)[reply]

Votos

  1.   Comment This is easy to fix: phabricator:T115375#1838090. Nemo 18:34, 30 November 2015 (UTC)[reply]
  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)[reply]
  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)[reply]
  4.   Support--Manlleus (talk) 15:14, 2 December 2015 (UTC)[reply]
  5.   Support --AS (talk) 09:40, 3 December 2015 (UTC)[reply]
  6.   Support SantiLak (talk) 10:39, 4 December 2015 (UTC)[reply]
  7.   Support Lester לסטר (talk) 18:06, 5 December 2015 (UTC)[reply]
  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)[reply]

Soporte para etiquetas anidadas

Algunas extensiones (por ej mw:extension:Cite) ponen etiquetas (<ref> en este caso) las que son analizadas asumiendo que son "de a una". Por ejemplo estructuras como Texto primario<ref>Nota al pie exterior<ref>Nota al pie interior</ref> continuación de la nota al pie exterior</ref> continuación de texto primario simplimente no podrán ser analizadas, resultando en el odioso y bastante poco amistoso

Cite error: Closing </ref> missing for <ref> tag

error, Seguramente ya pasó el tiempo suficiente como para enfrentar un tema tan fundamental? AuFCL (talk) 00:32, 13 November 2015 (UTC)[reply]

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)[reply]

Votos

  1.   Support strongly, at least for <ref> tags. --Purodha Blissenbach (talk) 14:40, 1 December 2015 (UTC)[reply]
  2.   Support Szalakóta (talk) 16:54, 1 December 2015 (UTC)[reply]
  3.   Comment What would be the purpose of a nested ref tag? Stevie is the man! Talk • Work 17:35, 1 December 2015 (UTC)[reply]
  4.   Support Jan.Kamenicek (talk) 18:51, 1 December 2015 (UTC)[reply]
  5.   Support --Usien6 (talk) 19:28, 1 December 2015 (UTC)[reply]
  6.   Support Popcorndude (talk) 03:34, 2 December 2015 (UTC)[reply]
  7.   Comment As Stevietheman said, when does anyone ever use nested refs? Eman235/talk 21:21, 2 December 2015 (UTC)[reply]
    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)[reply]
  8.   Support I've run across this at least once. -- Fauzan✆ talk ✉ email 16:49, 4 December 2015 (UTC)[reply]
  9.   Support. There is a workaround though and I'm using it very often. Halibutt (talk) 00:08, 5 December 2015 (UTC)[reply]
  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)[reply]
  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)[reply]
    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)[reply]

Colaboradores de una página

Tracked in Phabricator:
Task T49721

Antes de cambiar a las herramientas de laboratorio (¿estoy usando la jerga correcta?) teníamos una pequeña herramienta elegante en la wikipedia en inglés que era muy superior a la que tenemos ahora como los 50 Mejores contribuyentes.

Con el simple click de un botón uno debería poder revisar TODOS los editores que alguna vez editaron una página ordenado de 8 formas distintas. Este es útil cuando se trata de ajustar el nivel de actividad de WikiProyectos, y se hace muy útil para alguien como yo quien solo ocasionalmente participa en una página de discusión, pero que cuando lo hacen quieren tener algo de información de la audiencia potencial para no hacer completamente el rídiculo frente a esta.

La herramienta desplegaba la lista de editores que habían participado en la página. Había 4 columnas, cada uno de las cuales podía ser ordenada de adelante-a-atrás y vice versa:

  • ID de usuario
  • número de ediciones a la página
  • fecha de la primera edición
  • fecha de la última edición

Era rápida y raramente (si es que) fallaba, mientras que la herramienta que tenemos hoy solamente lista los 50 principales editores, no puede ser ordenada, y se rompe con facilidad.

Gracias por considerar esta propuesta. Ottawahitech (talk) 19:18, 18 November 2015 (UTC)[reply]

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)[reply]

Votos

  1.   Support--Shizhao (talk) 09:23, 1 December 2015 (UTC)[reply]
  2.   Support I agree this should be built-in. Stevie is the man! Talk • Work 17:40, 1 December 2015 (UTC)[reply]
  3.   Support Risker (talk) 03:51, 2 December 2015 (UTC)[reply]
  4.   Support--Manlleus (talk) 15:17, 2 December 2015 (UTC)[reply]
  5.   Support This would be incredibly useful. Eman235/talk 21:22, 2 December 2015 (UTC)[reply]
  6.   Support --Misibacsi (talk) 04:43, 3 December 2015 (UTC)[reply]
  7.   Support --YBG (talk) 06:10, 3 December 2015 (UTC)[reply]
  8.   Support — Arkanosis ✉ 13:57, 3 December 2015 (UTC)[reply]
  9.   Support -- SantiLak (talk) 10:39, 4 December 2015 (UTC)[reply]
  10.   Support Halibutt (talk) 00:09, 5 December 2015 (UTC)[reply]
  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)[reply]
  12.   Support This would be very helpful. Corinne (talk) 03:05, 7 December 2015 (UTC)[reply]
  13.   Support--Joris Egger (talk) 21:10, 7 December 2015 (UTC)[reply]
  14.   Support SteveStrummer (talk) 01:47, 10 December 2015 (UTC)[reply]
  15.   Support -- Llywrch (talk) 19:08, 11 December 2015 (UTC)[reply]
  16.   Support -- Juetho (talk) 11:57, 12 December 2015 (UTC)[reply]
  17.   Support --Sphilbrick (talk) 23:16, 12 December 2015 (UTC)[reply]
  18.   Support -- NaBUru38 (talk) 03:42, 13 December 2015 (UTC)[reply]

Guardar las ediciones antes de publicarlas

Tracked in Phabricator:
Task T39992
Tracked in Phabricator:
Task T75241

Frecuentemente pienso que me gustaría guardar una edición - quiero decir, que quisiera dejarla en el sistema pero no quiero publicarla todavía. Conoces esa diferencia de Wordpress, donde "guardar" es diferente de "publicar". Especialmente en el Traductor de Contenido me gustaría tener tal facilidad. A todo esto, a veces he experimentado problemas cuando he editado en la ventana de editor pero se cae la conexión de Internet; guardar el texto por seguridad sería genial. Ziko (talk) 23:41, 20 November 2015 (UTC)[reply]

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

Votos

  1.   Support 4nn1l2 (talk) 03:10, 30 November 2015 (UTC)[reply]
  2.   Support בנימין (talk) 07:32, 30 November 2015 (UTC)[reply]
  3.   Support Samwalton9 (talk) 10:27, 30 November 2015 (UTC)[reply]
  4.   Comment On the condition there will be no extra step in saving my edits. Debresser (talk) 13:02, 30 November 2015 (UTC)[reply]
  5.   Support provided this is done only when the user wants it. עוד מישהו Od Mishehu 16:11, 30 November 2015 (UTC)[reply]
  6.   Support --MGChecker (talk) 20:01, 30 November 2015 (UTC)[reply]
  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)[reply]
  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)[reply]
  9.   Support --Isacdaavid (talk) 02:20, 1 December 2015 (UTC)[reply]
  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)[reply]
  11.   Support Ckoerner (talk) 15:15, 1 December 2015 (UTC)[reply]
  12.   Support --Dodi123 (talk) 16:51, 1 December 2015 (UTC)[reply]
  13.   Support -- Tisfoon (talk) 17:47, 1 December 2015 (UTC)[reply]
  14.   Support per Purodha. Stevie is the man! Talk • Work 17:50, 1 December 2015 (UTC)[reply]
  15.   Support --Warp3 (talk) 18:32, 1 December 2015 (UTC)[reply]
  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)[reply]
  17.   Support Artem.komisarenko (talk) 19:38, 1 December 2015 (UTC)[reply]
  18.   Support --Akela (talk) 21:03, 1 December 2015 (UTC)[reply]
  19.   Support Yes. Regards, Kertraon (talk) 22:02, 1 December 2015 (UTC)[reply]
  20.   Support Alkamid (talk) 07:39, 2 December 2015 (UTC)[reply]
  21.   Support --β16 - (talk) 11:48, 2 December 2015 (UTC)[reply]
  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)[reply]
  23.   Support--Manlleus (talk) 15:17, 2 December 2015 (UTC)[reply]
  24.   Support Yes, please add automatic saving of drafts ala Gmail. —Pengo (talk) 21:18, 2 December 2015 (UTC)[reply]
  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)[reply]
  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)[reply]
  27.   Support Nikkimaria (talk) 01:33, 4 December 2015 (UTC)[reply]
  28.   Support SantiLak (talk) 10:39, 4 December 2015 (UTC)[reply]
  29.   Support Jmatazzoni (talk) 17:38, 4 December 2015 (UTC)[reply]
  30.   Support Halibutt (talk) 00:10, 5 December 2015 (UTC)[reply]
  31.   Support Tar Lócesilion (queta) 12:58, 5 December 2015 (UTC)[reply]
  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)[reply]
  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)[reply]
  34.   Support --Ziko (talk) 13:48, 9 December 2015 (UTC)[reply]
  35.   Support --Tgr (talk) 22:49, 13 December 2015 (UTC)[reply]
  36.   Support --Kew Gardens 613 (talk) 22:59, 13 December 2015 (UTC)[reply]
  37.   Support --Davidpar (talk) 14:30, 14 December 2015 (UTC)[reply]

Cálculos sencillos en las tablas

Tengo entendido que los programadores están trabajando muy duro en facilitar la creación de tablase en el editor visual. No lo hemos logrado todavía y he visto una regresión recientemente pero estamos cerca de poder copiar y pegar una tabla existente en una hoja de cálculo directamente en la ventana de edición. En este momento eso nos permite transferir datos celda por celda pero no no permite una de las funciones tradicionales de las hojas de cálculo: operaciones matemáticas simples (por ejemplo sumar los registros en una columna, la relación de dos celdas, etc.) La funcionalidad total de una hoja de cálculo está más allá de lo que MediaWiki debería soportar pero veo mucho valor en permitir algunos conceptos simples como sumas de datos y divisiones (también me gustaría la opción de tener columnas ocultas, lo que sospecho que es técnicamente posible pero puede que no sea trivial, estaré feliz de explicarlo si la necesidad por esta función no es obvia).

Los editores que no siguen deportes puede que no sepan que hay cientos, o tal vez miles, de artículos con tablas con resultados históricos de entrenadores y jugadores individuales. Por ejemplo John Thurston.

En resumen, el desafío es que no es difícil agregar un año a una plantilla o actualizar la plantilla cuando el equipo gana pero los subtotales por entrenador y por conferencia contra no conferencia, los resultados acumulados agregados y los porcentajes ganadores no se actualizan automáticamente y se deben editar por separado.

La situación actual tiene dos problemas:

  1. Es más complicada de lo que debería: Actualizar un juego individual no es fácil, en vez de cambiar una sola celda, el editor debe editar ocho celdas, o seis o cuatro, eso depende.
  2. Los errores persisten: Si un editor comete un error los subtotales y totales serán incorrectos y una edición posterior que haga todos los incrementos correctamente no corregirá el problema, este persistirá (además, si algún editor observa que los subtotales están mal y corrige el error, es posible que la fuente del error original fuera alguna de las filas individuales y ahora los totales estarán bien pero la fila individual seguirá mal, cuando la aplicación no calcula los totales, las entradas individuales y los totales pueden tener errores de consistencia).

Para ilustrar,

  • Enfoque actual de cuándo se gana un juego:
  1. Incrementar contador de juegos ganados en la temporada
  2. Si es un juego de conferencia, incrementar contador de juegos ganados de temporada
  3. Si está la plantilla de porcentaje de triunfos, incrementar contador de triunfos
  4. Incrementar contador de triunfos del entrenador
  5. Si es un juego de conferencia, incrementar contador de juegos ganados de temporada del entrenador
  6. Si está la plantilla de porcentaje de triunfos, incrementar contador de triunfos del entrenador
  7. Incrementar contador de triunfos históricos
  8. Si está la plantilla de porcentaje de triunfos, incrementar contador de triunfos históricos
  • Enfoque propuesto cuando se gana un juego:
  1. Incrementar el contador en el campo conferencia, si es un juego de conferencia, o en el de no-conferencia (el software después calcula todos los subtotales y porcentajes).

He presentado esto en el contexto de tablas de deportes, pero hay muchas tablas dentro de Wikipedia que requieren actualización adicional. En los casos donde estas tablas tengan totales y subtotales los mismos problemas persisten - que las entradas en los subtotales están desincronizados. Los editores deberían modificar valores individuales y dejar que el computador haga la matemática.

No sé si este entrará en el tipo de cosas consideradas en este ámbito. Si lo está, haré notar que mi breve discusión de más arriba es muy limitada, y seré voluntario para escribir casos de uso más desarrollados y detallar especificaciones.--Sphilbrick (talk) 17:23, 16 November 2015 (UTC)[reply]

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)[reply]
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)[reply]
@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)[reply]
@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)[reply]

Votos

  1.   Support This, that and the other (talk) 13:23, 30 November 2015 (UTC)[reply]
  2.   Support--Shizhao (talk) 09:25, 1 December 2015 (UTC)[reply]
  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)[reply]
  4.   Strongly oppose This proposal is all about making original research easier --Usien6 (talk) 19:33, 1 December 2015 (UTC)[reply]
  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)[reply]
  6.   Support. And "simple math" is not considered to be OR. StevenJ81 (talk) 22:02, 1 December 2015 (UTC)[reply]
  7.   Support Elections & disasters too. ...Aurora... (talk) 10:45, 2 December 2015 (UTC)[reply]
  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)[reply]
  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)[reply]

Convertir RefToolbar en una extensión de MediaWiki (o agregarla a la extensión del Wikieditor)

Actualmente Reftoolbar solo está disponible en la wikipedia en inglés (aunque hay una versión limitada en la wikipedia en malayo). Se ha pedido frecuentemente que la conviertan en una extensión para que otras wikipedias la puedan usar.

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)[reply]
Isn't mw:Citoid the extension that aims to cover Reftoolbar's feature set?--Qgil-WMF (talk) 08:13, 2 June 2015 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
  Endorsed--Shizhao (talk) 07:58, 12 November 2015 (UTC)[reply]

Votos

  1.   Support TeriEmbrey (talk) 16:00, 30 November 2015 (UTC)[reply]
  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)[reply]
  3.   Support --Isacdaavid (talk) 02:21, 1 December 2015 (UTC)[reply]
  4.   Support as per Sphilbrick. IJBall (talk) 03:35, 1 December 2015 (UTC)[reply]
  5.   Support--Shizhao (talk) 09:26, 1 December 2015 (UTC)[reply]
  6.   Support--Kimdime (talk) 12:12, 1 December 2015 (UTC)[reply]
  7.   Support —Tito☸Dutta 14:46, 1 December 2015 (UTC)[reply]
  8.   Support Ckoerner (talk) 15:14, 1 December 2015 (UTC)[reply]
  9.   Support Goombiis (talk) 16:28, 1 December 2015 (UTC)[reply]
  10.   Support –Krinkle 16:58, 1 December 2015 (UTC)[reply]
  11.   Support love this tool on English Wiki. --2macia22 (talk) 17:07, 1 December 2015 (UTC)[reply]
  12.   Support. We are talking about it on French Wikipedia. --Etiennekd (talk) 18:08, 1 December 2015 (UTC)[reply]
  13.   Support Stevie is the man! Talk • Work 18:34, 1 December 2015 (UTC)[reply]
  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)[reply]
  15.   Support --Usien6 (talk) 19:35, 1 December 2015 (UTC)[reply]
  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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  17.   Support StevenJ81 (talk) 22:03, 1 December 2015 (UTC)[reply]
  18.   Support Helder 23:48, 1 December 2015 (UTC)[reply]
  19.   Support – Ham II (sgwrs / talk) 19:13, 2 December 2015 (UTC)[reply]
  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)[reply]
  21.   Support RefToolbar is so helpful, let's please share it with the other Wikis. PamD (talk) 21:39, 2 December 2015 (UTC)[reply]
  22.   Support Nikkimaria (talk) 01:33, 4 December 2015 (UTC)[reply]
  23.   Support SantiLak (talk) 10:39, 4 December 2015 (UTC)[reply]
  24.   Support — Rhododendrites talk \\ 17:56, 6 December 2015 (UTC)[reply]
  25.   Support - Bcharles (talk) 05:14, 9 December 2015 (UTC)[reply]
  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)[reply]
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2015/Editing/es&oldid=27796922"