Wikimedia Meta-Wiki

Опитування побажань спільноти (2015)/Редагування

< 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:

Кольорове кодування при редагуванні вікірозмітки

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

Вже були деякі експерименти з кольоровим кодуванням вікірозмітки (включно з відповідним ґаджетом в англійській Вікіпедії та робочою імплементацією в додатку для Android). Це можна було б перетворити на справжню функцію в розширенні WikiEditor.

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]

Голосування

  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]


Стандартний режим інтерфейсу користувача

Люди, що вже давно редагують, часто мають сильно персоналізований інтерфейс, а також доступ до різноманітних інструментів/прав, недоступних для нових користувачів. Обидва ці фактори — дуже важливі, однак це створює труднощі, коли досвідчені користувачі намагаються зрозуміти проблеми, що виникають перед новими користувачами. Як практичний приклад, під час зустрічей, спрямованих на популяризацію, чимало Вікімедійців створюють «фейкові» облікові записи спеціально для того, аби мати змогу продемонструвати новачкам «стандартний» інтерфейс користувача на екрані. Що важливо, той, хто веде презентацію, ніколи насправді не натискає кнопку «зберегти», коли показує, як редагувати, оскільки тоді такий новостворений обліковий запис отримає статус автопідтвердженого.

Я пропоную додати в налаштування користувача «режим», який робить інтерфейс користувача та його статус «стандартними» для недавно зареєстрованих користувачів. Назвіть його «режим нового користувача» чи «стандартний режим». Найголовніше те, що, при редагуванні в цьому режимі, користувач НЕ СТАВАТИМЕ «автопідтвердженим» після збереження редагувань, але вони, все ж, зараховуватимуться до його внеску. В історії вони могли б позначатися тегом #defaultMode чи чимось подібним. 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]

Голосування

  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]

Увімкнути Apertium на cy для Перекладу вмісту

Tracked in Phabricator:
Task T102101

Переклад вмісту (Content Translation) НЕ працює на cy; він там просто зайвий, сидить та байдикує. Увімкнення Apertium у ньому означало б, що його можна використовувати.Ось тут обговорення, що веде в глухий кут. Тож давайте вирішимо цю проблему та увімкнемо переклад для 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]

Голосування

  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]

Генерувати автоматичний опис редагування /* опис */ при ручному додаванні нового заголовка розділу

Tracked in Phabricator:
Task T22307

Див. запит на Фабрикаторі (справа є посилання на нього). Це буде особливо корисно для сторінок обговорення. Видається порівняно легким завданням. Можливо, перебуваючи в списку побажань вже протягом шести років, хто-небудь врешті візьметься за нього. Дякую, Wbm1058 (talk) 14:53, 16 November 2015 (UTC)[reply]

Earlier discussion and endorsements

Голосування

  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]

Наполовину зменшити конфлікти редагувань

Tracked in Phabricator:
Task T72163

У всіх нас бувають конфлікти редагувань, і ті, хто залишився, щоб редагувати Вікіпедію — це в першу чергу люди, що навчилися вирішувати такі конфлікти, або ж виконувати велику кількість дрібних редагувань для того, аби мінімізувати втрачений час, коли стається конфлікт редагувань. Було багато пропозицій на Баґзіллі та деінде, аби зменшити кількість випадків конфліктів редагувань, однак для відповідної роботи не вистачало ресурсів, оскільки збереження нових редакторів раніше не було пріоритетом. Однак це — одна з тих речей, які нові редактори вважають найбільш непривітними у Вікіпедії, і зазвичай це саме новачок програє конфлікт редагувань, оскільки своє редагування вони виконують протягом декількох хвилин, тоді як люди, що проставляють категорії чи додають шаблони витрачають на це лічені секунди. (Візуальний редактор, звісно, ще більш погіршує ситуацію через неможливість редагування певного розділу окремо, а також через сповільнення редакторів.)

Зараз у нас немає навіть публічної статистики щодо кількості редакторів, втрачених через конфлікти редагувань. Простий підрахунок таких конфліктів, а також кількості випадків, коли редактор покидає сайт, могли б підтвердити, що це — одна з основних причин, чому хороші нові редактори покидають проекти, однак дійсне виправлення деяких з тих речей, що спричиняють конфлікти редагувань, забере приблизно стільки ж ресурсів.

Повне усунення конфліктів редагувань вимагало б революційних змін до інтерфейсу користувача, але щоб зменшити їх наполовину, достатньо порівняно незначного вкладення ресурсів.

До конкретних шляхів зменшення кількості конфліктів редагувань належать:

  1. Додавання шаблону на початку статті чи категорії наприкінці мають розцінюватися як редагування, що не конфліктують зі зміною решти статті.
  2. Попереднє заповнення всіх заново створених статей такими розділами, як == Примітки == та == Див. також == чи їхніми іншомовними еквівалентами.
  3. Трактування символу # як заголовка розділу — таким чином дві відповіді у двох різних гілках не будуть трактуватися як конфлікт редагувань. WereSpielChequers (talk) 20:54, 10 November 2015 (UTC)[reply]
Earlier discussion and endorsements

Голосування

  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]

Вдосконалений екран порівняння версій

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

Ну хіба Вам не подобаються порівняння версій, такі як ось це? Мала б бути можливість вдосконалити цей перегляд порівняння версій. Для натхнення, можете глянути, як працює ґаджет wikEdDiff. http://i.imgur.com/R9ZfCA1.jpg The Quixotic Potato (talk) 06:41, 29 September 2015 (UTC)[reply]
[Приєднано з іншої пропозиції:] Коли хтось переміщує параграф, а потім редагує його, це редагування не відображається окремо для порівняння тексту при використанні функції «Відмінності між версіями». Ця проблема також виникає, коли хтось додає порожній рядок над параграфом, а потім редагує його. Дякую, --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]

Голосування

  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]


Спрощення цитування різних сторінок книги в одній примітці

Tracked in Phabricator:
Task T100645

Коли я цитую різні сторінки книги в межах однієї статті, мені доводиться давати посилання на книгу по декілька разів. У нас є функція «повторного використання» приміток, яка теж досить добре працює у Візуальному редакторі, але вона не розрахована на вказування різних сторінок однієї й тієї ж книги. Див. завдання на Фабрикаторі phab:T100645 та phab:T15127. Дякую, --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]

Голосування

  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]


Обєднання Перекладу вмісту та Візуального редактора в один інструмент

Концепція Перекладу вмісту дуже хороша. Найбільші мовні версії Вікіпедії (особливо англомовна) є основними джерелами для перекладу статей на інші мови. Але в поточній формі Перекладу вмісту Ви можете лише перекласти статтю, та не можете додавати інформацію з інших джерел, додавати локальні шаблони, чи навіть змінювати/додавати медіафайли, аж доки не опублікуєте статтю. Моя пропозиція полягає в тому, аби об'єднати Переклад вмісту та Візуальний редактор в один інструмент, в якому переклад був би всього лиш опцією. בנימין (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]

Голосування

  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]

Підтримка взаємного накладення тегів

Деякі розширення (напр., mw:extension:Cite) працюють на основі тегів (<ref> у цьому випадку), які розцінюються як «одноразові», і подвійні теги не допускаються. Тобто, структури на кшталт Основний текст<ref>Зовнішня виноска<ref>Внутрішня виноска</ref> продовження зовнішньої виноски</ref> продовження основного тексту при поточній системі просто не розпізнаються, в результаті чого з'являється страхітлива та досить-таки непривітна

Помилка цитування: Відсутній тег </ref> за наявності тегу <ref>

помилка. Напевно, це вже запізно для виправлення такої фундаментальної проблеми? 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]

Голосування

  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]

Дописувачі сторінки

Tracked in Phabricator:
Task T49721

Перед переходом на tool labs (сподіваюся, я використав коректну назву?), в англійській Вікіпедії ми мали чудовий невеличкий інструмент, який був значно більш просунутим у порівняння з тим, що ми зараз маємо під заголовком Top 50 contributors.

Простим клацанням кнопки можна було перевірити ВСІХ редакторів, які коли-небудь редагували певну сторінку, при чому їх можна було сортувати 8-ма різними способами. Це буває корисно, коли треба оцінити рівень активності у різних вікіпроектах, і стає справді зручно для когось, такого як я, хто лише дуже зрідка бере участь в дискусіях на сторінках обговорень, але хоче мати хоч якесь уявлення про потенційних слухачів, перш ніж робити з себе цілковитого дурня.

Той інструмент виводив список усіх редакторів, що редагували певну сторінку. Було 4 колонки, кожну з яких можна було сортувати у два боки:

  • ID користувача
  • кількість редагувань на сторінці
  • дата першого редагування
  • дата останнього редагування

Інструмент працював швидко і рідко (якщо взагалі) давав збої, тоді як поточний інструмент подає лише 50 редакторів із найбільшим внеском для цієї сторінки, і цей список не можна сортувати, а також інструмент часто ламається.

Дякую за розгляд пропозиції. 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]

Голосування

  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]

Збереження редагувань перед публікацією

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

Часто я думаю про те, що хотів би зберегти редагування - тобто, хотів би зберегти його в самій системі, але все ще не публікуючи. Вам відома ця відмінність значень із Wordpress, де «збереження» відрізняється від «публікування». особливо мені б хотілося бачити таку функцію в Перекладі вмісту. До речі, іноді в мене виникали проблеми, коли я редагував у вікні редактора, і в цей час зникало з'єднання з інтернетом; зберігати текст лише з міркувань безпеки було б чудово. 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]

Голосування

  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]

Прості обчислення в таблицях

Я так розумію, що розробники важко працюють над тим, аби спростити процес створення таблиць у візуальному редакторі. Нам ще порівняно далеко до досягнення цієї мети, і нещодавно я спостерігав регрес у цьому плані, але ми вже наближаємось до того, щоб мати змогу копіювати та вставляти наявні таблиці із електронних табличних аркушів безпосередньо у вікно редагування. Станом на зараз, це дає змогу переносити дані клітинка за клітинкою, але не дозволяє користувачам виконувати традиційні табличні функції, такі як проста математика (напр., сума даних, поданих в одній колонці, співвідношення між двома клітинками). Тоді як функціонал електронних табличних аркушів виходить далеко за межі того, що має стати доступним у MediaWiki, я вбачаю величезну цінність у впровадженні деяких простих концепцій, таких як можливість визначення суми чи співвідношення. (Я б також не проти мати можливість приховувати колонки, що, я підозрюю, технічно можливо, але може бути нетривіальним завданням. З радістю поясню, якщо потреба в цьому для когось буде неочевидною).

Редактори, що не стежать за спортивними подіями уважно, можуть бути не в курсі, що ми маємо численні сотні, якщо не тисячі, статей з таблицями, в яких містяться історичні спортивні результати команд, тренерів та окремих гравців. Як приклад, перегляньте статтю про Джона Терстона.

Якщо коротко, основна проблема полягає в тому, що хоча це й неважко додати один рік до шаблону, чи оновити шаблон, коли команда перемагає, але проміжні підсумки за тренером, за конференцією, проти загальних, збірних результатів поза конференцією, а також відсоток перемог не оновлюються автоматично — їх треба редагувати вручну.

Такий стан речей створює дві проблеми:

  1. Важче, ніж повинно бути — оновлення єдиної гри є непростим завданням — замість зміни одного поля, редакторові іноді доводиться редагувати цілих вісім полів. Або, може, шість, чи чотири — залежно від статті.
  2. Помилки зберігаються — якщо будь-коли будь-який редактор зробить помилку, проміжні результати, так само як і загальні результати будуть хибними, і наступне редагування, яким буде просто доданий наступний приріст до загалу — не виправить помилки, а збереже її. (Крім того, якщо будь-який редактор помітить, що проміжні підсумки хибні і виправить їх, вони можуть все ж залишитися хибними, якщо хтось зробив помилку деінде, в окремій клітинці — загальний підрахунок даних в таблиці буде вірним, але індивідуальна клітинка міститиме хибну інформацію, тому й підсумок буде хибним. Якщо програмне забезпечення не вираховує загальну суму самостійно, то окремі дані та загальна сума можуть бути невідповідними.)

Аби проілюструвати,

  • Поточний підхід, коли команда/гравець отримує перемогу:
  1. Збільшується кількість переможних сезонів
  2. Якщо це конференційна гра, збільшується кількість переможних сезонів
  3. Якщо наявний шаблон, що подає відсоток перемог, збільшується кількість перемог
  4. Збільшується кількість перемог для тренера
  5. Якщо це конференційна гра, збільшується кількість переможних сезонів у конференції для тренера
  6. Якщо наявний шаблон, що подає відсоток перемог, збільшується загальна кількість перемог для тренера
  7. Збільшується кількість перемог за весь час
  8. Якщо наявний шаблон, що подає відсоток перемог, збільшується загальна кількість перемог за весь час
  • Пропонований підхід, коли команда/гравець отримує перемогу:
  1. Збільшення кількості перемог у полі для коференції, якщо це конференційна гра, або ж у звичайному полі, якщо це не конференційна гра (потім програмне забезпечення самостійно вираховує всі загальні суми та відсоткові співвідношення).

Я презентував це у контексті спортивних таблиць, але у Вікіпедії існує багато інших таблиць, які теж час від часу потребують оновлення. У випадках, коли ці таблиці мають проміжні та загальні сумарні результати, для них можуть бути актуальними такі ж проблеми — дані в таблиці можуть не узгоджуватися із сумарними значеннями. Редакторам в таких випадках просто треба буде відредагувати індивідуальні значення і дозволити комп'ютерові виконати решту обчислень.

Не знаю, чи це потрапляє в сферу тих типів речей, які вважаються прийнятними для цього опитування. Якщо підпадає, то я хочу зауважити, що моє коротке пояснення вгорі є далеко не адекватним, і я добровільно беруся виписати значно краще підібрані приклади для пояснення, а також відповісти на зауваження щодо специфікацій.--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]

Голосування

  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]

Перетворити RefToolbar у розширення MediaWiki (або додати його до розширення WikiEditor)

Станом на зараз, ґаджет Reftoolbar доступний лише в англійській Вікіпедії (хоча існує дуже обмежена його версія у Вікіпедії мовою малаялам). Вже досить часто люди висловлюються на користь перетворення цього ґаджета у розширення, яке б могли використовувати й інші Вікіпедії.

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]

Голосування

  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/uk&oldid=27796944"