# Community Wishlist Survey 2019/Editing

Editing
27 proposals, 430 contributors, 882 support votes
The survey has closed. Thanks for your participation :)

## Make the 2010 editor lighter and faster or create a new lightweight editor

• Problem: The 2010 editor is much slower and much more memory-consuming than the just removed 2006 editor. Unfortunately, this seems to be now the only tool that offers an interface to various extensions like CodeMirror or ProofreadPage. This is especially visible when opening simultaneously about 50 pages for offline editing. But not only.
• Who would benefit: advanced users who make a lot of on-wiki edits
• Proposed solution: optionally disable or some rarely used features of the editor (eg. the "Help" or "Special characters") or make them loadable on demand (non-existent in the page structure until clicked on). Or make an alternative, simple, lightweight tool that allow to configure easily which elements are of interface are created and which are not by users who are not technically skilled. Note: this is about not creating unnecessary HTML code, not about removing them from existent interface as the latter is unlikely to save memory and fasten browser operation.
• More comments: "Advanced" wiki users may have no programming skills or no HTML knowledge to create an optimized environment by themselves. They may have some skills that allow them to create/modify the wiki content efficiently if supported by efficient tools.
• Phabricator tickets:
• Proposer: Ankry (talk) 17:20, 10 November 2018 (UTC)

### Discussion

As having worked on this editor in the past, can you describe why/how/where it feels 'slow' to you (or anyone else who wants to answer) ? Some of my personal hunches are

• "because it's later than the rest of the page"
• The animations on the toolbar sections. FYI, allowing for configuration is a sure way to ADD to the load time
• Syntax Highlighting —TheDJ (talkcontribs) 12:14, 19 November 2018 (UTC)

## Put mw.toolbar back

• Problem: The mw.toolbar was removed
• Who would benefit: All active authors
• Proposed solution: Restore the toolbar
• Proposer: Itti (talk) 14:20, 6 November 2018 (UTC)

### Discussion

• This is a duplicate of Community Wishlist Survey 2019/Editing/Keep the lightweight text editor. --Izno (talk) 15:26, 9 November 2018 (UTC)
• This proposal is fine as it is, and it can stay. -- DannyH (WMF) (talk) 21:13, 9 November 2018 (UTC)
• What's the difference? Part of the point of the pre-voting phase is to improve proposals so that we don't have voting on many similar proposals, thus potentially diffusing the vote for a particular proposal. If there is a difference, is it significant to the degree that it should be a separate proposal? --Izno (talk) 01:03, 10 November 2018 (UTC)
The difference is, that the other proposal was dealt with as an emergency, especially in the discussion dealt primarily about immediate band aid to fix the most urgent problems, while it was meant as a long term issue, that the tools should be kept, i.e. restored. And it differs from my proposal, as this is about the tools surrounding the lightweight editor (buttons, CharInsert...), while mine was about the lightweight editor itself (the plain white box you write in in text mode). Grüße vom Sänger ♫(Reden) 09:05, 10 November 2018 (UTC)
But you can already get to the plain white box? Maybe the other proposal should be closed if that's what the other proposal is about. You turn off the preference called in English "Enable the editing toolbar (This is sometimes called the '2010 wikitext editor'.)". --Izno (talk) 16:15, 10 November 2018 (UTC)
As for CharInsert, that didn't go away. German WP had a bug in their Javascript which disabled it. --Izno (talk) 16:18, 10 November 2018 (UTC)
• This is a proposal that will get a lot of support for no reason other than old toolbar’s removal happening exactly around the time of CWS 2019. Sad state of affairs, really, these events should’ve not coincided so that there would’ve been a fairer vote. stjn[ru] 09:20, 17 November 2018 (UTC)
Hi stjn, you should look at it on a different way. This desire for a stable, simple working basis, which is offered to a user in all language versions for his work, is a deep and serious desire. It is a basis for good work. Many Greetings Itti (talk) 09:47, 17 November 2018 (UTC)
I think the concern is that, split as it is into two proposals, and the timing, these two will easily make it into the top ten and take two of the coveted top ten slots, resulting in less work on development of new features. — Insertcleverphrasehere (or here) 11:05, 17 November 2018 (UTC)
Oh, I see. I think that is not necessary, they can handle it like one. --Itti (talk) 11:20, 17 November 2018 (UTC)

### Voting

•   Support Bring back the charinsert in German Wikipedia! Chaddy (talk) 20:02, 16 November 2018 (UTC)
•   Support Atamari (talk) 21:43, 16 November 2018 (UTC)
•   Support --Alraunenstern۞ 22:18, 16 November 2018 (UTC)
•   Support Stefan »Στέφανος«  22:40, 16 November 2018 (UTC)
•   Support --Wahrerwattwurm (talk) 22:53, 16 November 2018 (UTC)
•   Support --Summer ... hier! (talk) 23:27, 16 November 2018 (UTC)
•   Support --Rmcharb (talk) 23:28, 16 November 2018 (UTC)
•   Support The 2010 edit bar is not even remotely close to a proper replacement of the old toolbar. Its original buttons are 95% useless, and the system of different panels to access buttons is horrible (same design flaws as Vector, where you need to scroll menus to access functions - especially when you are a sysop). Rhadamante (talk) 00:52, 17 November 2018 (UTC)
•   Support As substitute for the unduly ignored wish to keep the existing tools working. (And if I had the buttons I'm used to you would even get a proper signature. Its a shame that I have to write my text in de and than copy and paste here because nothing works. And don't dare you deleting because not proper signed. Check the Version History if you have any doubts who writes here.) --Fano (talk) 04:34, 17 November 2018 (UTC)
•   Support Liuxinyu970226 (talk) 04:41, 17 November 2018 (UTC)
•   Support Ghilt (talk) 08:16, 17 November 2018 (UTC)
•   Support Peterdexheimer (talk) 08:41, 17 November 2018 (UTC)
•   Support --Gereon K. (talk) 09:33, 17 November 2018 (UTC)
•   Support --Grüße vom Sänger ♫(Reden) 10:16, 17 November 2018 (UTC) Typical autistic dev decision, made without proper consultation of the working base of the content project here.
•   Support--Silewe (talk) 10:12, 17 November 2018 (UTC)
•   Support--Alinea (talk) 11:28, 17 November 2018 (UTC)
•   Support FF-11 (talk) 10:40, 17 November 2018 (UTC)
•   Support Cbyd (talk) 10:49, 17 November 2018 (UTC)
•   Support --J. Patrick Fischer (talk) 10:50, 17 November 2018 (UTC)
•   Support --Kpisimon (talk) 11:03, 17 November 2018 (UTC)
•   Support --Adelfrank (talk) 11:10, 17 November 2018 (UTC)
•   Support -- Bertramz (talk) 12:35, 17 November 2018 (UTC)
•   Support --Privat-User (talk) 13:23, 17 November 2018 (UTC)
•   Support - Squasher (talk) 14:13, 17 November 2018 (UTC)
•   Support --Rote4132 (talk) 14:53, 17 November 2018 (UTC)
•   Support Doc Taxon (talk) 16:13, 17 November 2018 (UTC)
•   Support Townie (talk) 16:49, 17 November 2018 (UTC)
•   Support Jmv (talk) 18:11, 17 November 2018 (UTC)
•   Support --Bubo 18:17, 17 November 2018 (UTC)
•   Support Should never have been removed in the first place, but many companies want to move on to newer versions, like Google and Microsoft. WMF shouldn't be like those companies; rather they should re-create or reinsert the good ol' '06 toolbar. George Ho (talk) 18:19, 17 November 2018 (UTC)
•   Support Nk (talk) 19:58, 17 November 2018 (UTC)
•   Support --Hadibe (talk) 22:34, 17 November 2018 (UTC)
•   Support --Altkatholik62 (talk) 22:37, 17 November 2018 (UTC) Wikimedia is not at all a profit-driven company which needs new features to increase their turnover. Think of an old proverb, and never touch a running system.
•   Support Keith D (talk) 23:12, 17 November 2018 (UTC)
•   Support I am an admin of Ukrainian Wikipedia. I liked the old toolbar and I spent hours of my volunteer time trying to reproduce mw:Contributors/Projects/Removal of the 2006 wikitext editor, without success. I am also active in many wikis (like Commons or Meta) where I am not an admin and there is no gadget available. I now have a choice between spending more time on trying to fix the problem I did not cause or spend more time on each edit. I hate this choice, so please put the toolbar back NickK (talk) 23:30, 17 November 2018 (UTC)
•   Support Tim Landscheidt (talk) 03:07, 18 November 2018 (UTC)
•   Support Ankry (talk) 03:14, 18 November 2018 (UTC)
•   Support Per Rhadamante. Or create a new toolbar that is easily customizable! Jules78120 (talk) 10:02, 18 November 2018 (UTC)
•   Support --voyager (talk) 13:58, 18 November 2018 (UTC)
•   Support Joschi71 (talk) 15:04, 18 November 2018 (UTC)
•   Support Timeshifter (talk) 15:08, 18 November 2018 (UTC)
•   Support JackPotte (talk) 21:55, 18 November 2018 (UTC)
•   Support Benjamin (talk) 10:29, 19 November 2018 (UTC)
•   Support --Phi (talk) 15:03, 19 November 2018 (UTC)
•   Support --Hildeoc (talk) 15:13, 19 November 2018 (UTC)
•   Support Emptyfear (talk) 15:36, 19 November 2018 (UTC)
•   Support Mend My Way 23:53, 19 November 2018 (UTC)
•   Support for the same reasons I gave on the linked proposal. Iridescent (talk) 10:17, 20 November 2018 (UTC)
•   Support«« Man77 »» [de] 13:02, 20 November 2018 (UTC)
•   Support --Mirkur (talk) 15:45, 20 November 2018 (UTC)
•   Support --Herbert Ortner (talk) 19:24, 20 November 2018 (UTC)
•   Support Novak Watchmen (talk) 00:29, 21 November 2018 (UTC)
•   Support Zunter (talk) 12:45, 21 November 2018 (UTC)
•   Support RIT RAJARSHI (talk) 19:42, 21 November 2018 (UTC)
•   Oppose This was sunset. Deliberately. I'm shocked if people haven't figured out and/or are not used to the combinations necessary to hand-type the buttons in. --Izno (talk) 01:41, 22 November 2018 (UTC)
Nur geht es nicht um Sonnenäufgänge oder bunte Bildchen. Benutzer benötigen die Symbole, wenn sie anspruchsvolle Artikel schreiben möchten. Das ist so ziemlich das Gegenteil von dem, was du schreibst. Ich bin schockiert, wie man so abfällig über die Bedürfnisse anderer urteilen kann. --Itti (talk) 07:47, 22 November 2018 (UTC)
@Itti: Nie jest ładnie pisać w swoim języku, jeżeli piszesz na stronie na której wszyscy posługują się językiem angielskim. PMG (talk) 17:32, 26 November 2018 (UTC)
@PMG: Es ist einfacher, in der Sprache zu schreiben, die man gut spricht und sich die Antwort in der Sprache des anderen übersetzt. Dann ist das Ergebnis besser, als wenn jeder versucht, in einer dritten Sprache mehr schlecht als recht zu schreiben. Das hat nichts mit Unhöflichkeit zu tun, sondern mit Effizienz. It is better to write in the language you are good and the other will translated this. The result is much more better, as if everybody is trying to write a third language in with both are not save. This is not a kind of unpolitness it is more efficient. Regards --Itti (talk) 21:11, 26 November 2018 (UTC)
•   Support --DaizY (talk) 08:45, 22 November 2018 (UTC)
•   Support Boehm (talk) 12:14, 22 November 2018 (UTC)
•   Support--Parpan05 (talk) 07:57, 23 November 2018 (UTC)
•   Support--Engelbaet (talk) 12:31, 23 November 2018 (UTC)
•   Support --Steindy (talk) 23:40, 23 November 2018 (UTC)
•   Support -- IWI (chat) 10:33, 24 November 2018 (UTC)
•   Support Dirk Beetstra T C (en: U, T) 04:04, 25 November 2018 (UTC)
•   Support like the comment of User:Itti -- Biberbaer (talk) 17:49, 25 November 2018 (UTC)
•   Support - 20:32, 26 November 2018 (UTC)
•   Support -- User: Perhelion 17:05, 27 November 2018 (UTC)
•   Support Quedel (talk) 23:20, 27 November 2018 (UTC)
•   Support Mautpreller (talk) 14:47, 6 November 2018 (UTC)
•   Support DaB. (talk) 15:12, 6 November 2018 (UTC)
•   Support Magiers (talk) 15:13, 6 November 2018 (UTC)
•   Support Orci (talk) 15:15, 6 November 2018 (UTC)
•   Support Schlesinger (talk) 15:23, 6 November 2018 (UTC)
•   Support Herzi Pinki (talk) 15:25, 6 November 2018 (UTC)
•   Support XenonX3 (talk) 15:48, 6 November 2018 (UTC)
•   Support Maimaid (talk) 16:06, 6 November 2018 (UTC)
•   Support Neitram (talk) 16:09, 6 November 2018 (UTC)
•   Support Freimut Bahlo (talk) 16:17, 6 November 2018 (UTC)
•   Support Saluk (talk) 16:07, 6 November 2018 (UTC)
•   Support Zinnmann (talk) 16:23, 6 November 2018 (UTC)
•   Support JuTa (talk) 16:33, 6 November 2018 (UTC)
•   Support -jkb- 16:53, 6 November 2018 (UTC)
•   Support Benowar (talk) 16:59, 6 November 2018 (UTC)
•   Support Asio otus (talk) 17:00, 6 November 2018 (UTC)
•   Support --Si! SWamP (talk) 19:13, 6 November 2018 (UTC)
•   Support -- Ra'ike (talk) 22:01, 6 November 2018 (UTC)
•   Support --Jocian (talk) 22:34, 6 November 2018 (UTC)
•   Support --Gestumblindi (talk) 22:37, 6 November 2018 (UTC)
•   Support ----Alfred Kiefer (talk) 04:35, 7 November 2018 (UTC)
•   Support --Phzh (talk) 08:15, 7 November 2018 (UTC)
•   Support --Eingangskontrolle (talk) 09:23, 7 November 2018 (UTC)
•   Support --Ket (talk) 09:57, 7 November 2018 (UTC)
•   Support --PowerBUL (talk) 15:09, 7 November 2018 (UTC)
•   Support --Den man tau (talk) 15:34, 7 November 2018 (UTC)
•   Support --Lutheraner (talk) 16:37, 7 November 2018 (UTC)
•   Support --Doc.Heintz (talk) 17:12, 7 November 2018 (UTC)
•   Support Jossi2 (talk) 19:32, 7 November 2018 (UTC)
•   Support --Frank Schulenburg (talk) 20:45, 7 November 2018 (UTC)
•   Support --Fano (talk) 01:04, 8 November 2018 (UTC)
•   Support --Eloquenzministerium (talk) 04:49, 8 November 2018 (UTC)
•   Support --Anatoliy (talk) 22:16, 8 November 2018 (UTC)
•   Support --Tusculum (talk) 19:51, 28 November 2018 (UTC)
•   Support --Snookerado (talk) 17:59, 29 November 2018 (UTC)
•   Support Wiklol (talk) 21:09, 29 November 2018 (UTC)

## Make the math tag support non-Latin languages

• Problem: There should be a public plugin on web for putting LaTaX into Chinese, so it is not difficult to implement the content in zh supporting wikis modified by the [itex] tag (that is, the "mathematical formula" function).

(网络上应该有公开的使LaTaX中文化的插件，所以私以为使[itex]标签所修饰内容（也就是“数学公式”功能”）支持中文应该是不难实现的).)

• Who would benefit:
• Proposed solution:
• Phabricator tickets: T50032
• Proposer: 脂肪酸钠 (talk) 15:08, 4 November 2018 (UTC)

### Discussion

This was posted in Chinese. I've translated it into English, but kept the original Chinese. --Omotecho (talk) 16:21, 6 November 2018 (UTC)

@脂肪酸钠: Could you provide an example what "putting LaTeX into Chinese" means? Basically LaTeX is a file format, and Chinese are languages and scripts, so I am not sure I understand what is requested here and how these two are related. Thanks a lot! --AKlapper (WMF) (talk) 03:28, 7 November 2018 (UTC)
I think it's supposed to be "put the Chinese into the math", not "put the math into the Chinese"? $\displaystyle 标 = 签$ <- doesn't work too well. --Izno (talk) 04:21, 7 November 2018 (UTC)
@Izno:You are right. Thanks. 脂肪酸钠 (talk) 07:33, 7 November 2018 (UTC)
Comment allow me to indent a few lines below so that discussion is better threaded. 10:50, 7 November 2018 (UTC) -->
OK.脂肪酸钠 (talk) 11:16, 7 November 2018 (UTC)
Example: <chem>2H2{+}O2->[点燃]2H2O</chem>
present output: $\displaystyle \ce{2H2{+}O2->[点燃] 2H_2O}$
or, ${\displaystyle {\ce {2H2{+}O2->[burn] 2H_2O}}}$
Comment expected output: in zh as: 2H2+O2点燃—>2H2O
Over here, TeX does not support Chinese. 脂肪酸钠 (talk) 07:33, 7 November 2018 (UTC)
Comment @脂肪酸钠: kindly check if my edit above is correct. I am trying to support you convey your idea in en as a translator.this proposal might benefit local languages, if LaTex shows in local language. Thank you to post your idea. Omotecho (talk) 10:50, 7 November 2018 (UTC)
It's perfect.脂肪酸钠 (talk) 11:16, 7 November 2018 (UTC)
As a note, this isn't just Chinese--there are a number of languages with this problem. I've added the Phabricator task. --Izno (talk) 13:08, 7 November 2018 (UTC)
For Chinese, it would be nice if Chinese styling commands can be supported. C933103 (talk) 16:01, 13 November 2018 (UTC)

@脂肪酸钠: Thank you for all your input. We are kind of working on this, but unfortunately it takes very long and it would be awesome if we could get some support from WMF (see phab:T195861 and Community Wishlist Survey 2019/Reading/Functional and beautiful math for everyone). If you just want to avoid the error, you can use <chem>2H2{} + O2 ->[\text{点燃}] 2H2O</chem>:

${\displaystyle {\ce {2H2{}+O2->[{\text{点燃}}]2H2O}}}$

However in most browsers, the rendering of 点燃 is very bad which is due to our current math extension setup. This means for a proper solution of the issue, we do not only need to remove the texvcjs which is responsible for the error, but we also need a better rendering that is equivalent to the client-side html rendering other websites use.

Side remark: Please do not use the old workaround with curly brackets around the plus anymore. Apart from removing the normal spacing this can render completely different in some cases. We are planning to make it work according to the specifications without workarounds, i.e. <chem>2H2 + O2 ->[点燃] 2H2O</chem> [1] (you can test the normal behavior at the bottom with \ce{2H2 + O2 ->[点燃] 2H2O}) and for this currently replacing those kind of workarounds with the workaround I used above, because that is a workaround which renders the same without texvcjs (the culprit for falsely removing necessary spaces) and up-to-date mhchem (without bug in {} implementation).

Please also do not try to fix the bad text rendering with workarounds like <chem>2H2{} + O2 ->[\mbox{点}\;\,\mbox{燃}] 2H2O</chem>:

${\displaystyle {\ce {2H2{}+O2->[{\mbox{点}}\;\,{\mbox{燃}}]2H2O}}}$

because that will probably look bad for other people and look even worse if one day those rendering problems are fixed.

I would be very happy if you want to support us in phab:T195861, (testing different rendering solutions/devices, give some feedback, replacement work, investigating strange errors, code-review, translation and information for editors...).--Debenben (talk) 13:25, 15 November 2018 (UTC)

@Debenben: Your first style of "点燃" makes the ~10% right part of "点" and ~10% left part of "燃" overlapped-rendered (which by using that on zhwiki locally, you will trigger an AbuseFilter and so you can't publish your edits). Please, use your second example instead. --Liuxinyu970226 (talk) 04:32, 17 November 2018 (UTC)
• "Make LaTeX use UTF-8, properly, natively"... what a wonderful idea. Apart from anything else, sometimes one wishes to cite people whose names are not straight ASCII characters! But as I recall this has a long history... there are kludges, but LaTeX3 has been in the works for over a quarter-century.[2] I'm not sure why, but something must be difficult. HLHJ (talk) 06:42, 18 November 2018 (UTC)
Well, it works on math.stackexchange.com and 70000 other websites [3] so I would say it is feasible. We just have to use MathJax the right way and for this we might need some help to integrate it properly into the resource loader.--Debenben (talk) 20:57, 19 November 2018 (UTC)

## Simplified/semi-automated conversion for units of measurements

• Problem: Currently, converting units of measurement on Wikipedia between the Imperial and Metric system or otherwise requires the editor to go through a lengthy process of searching for and generating a convert template, cutting the measurement which they wish to convert, pasting the component parts of the measurement into the various sections of the convert template, adjusting the convert settings and applying all of that . This process then has to be repeated again and again if the editor wishes to convert multiple units, such as in a data table or specifications list.
• Who would benefit: Novice editors who are not sure how to convert units, seasoned editors who wish to convert units more quickly, especially in situations such as large data tables, when creating a page, or when carrying out repeat/copy edits across a large number of pages. (EDIT: As other editors have pointed out the conversion tool is used outside of the Anglosphere, although not to the same extent as within it. For instance, users have cited certain Russian units as well as many historical/traditional units. An unsigned user also said that the convert template is used on around 80 wikis. In addition, I know that, for measurements such as horsepower, there are a variety of units, such as hp, kW, PS and CV that are used globally today.)
• Proposed solution: I propose a tool somewhat similar to auto-correct, which, when a unit of measurement is detected, may highlight or otherwise ask the user in a non intrusive way if they wish to convert that unit, and subsequently provide a button or single click solution that creates a convert template for them with the magnitude of the measurement and unit already entered into the template in their respective categories. The interface could open up when you right click, prompting you to convert the units, and then offer you a straight, one click conversion to metric/imperial that automatically fills in the "unit to", "unit from" and "value" boxes and leaves the other settings as default.
• More comments: Currently, what most editors, or at least myself, do is create an empty convert template and copy it so they can then paste it throughout an article and input units into it. This is inefficient, however, as you still have to input all the values which can be lengthy, and it also removes your ability to copy anything else.
• Phabricator tickets:
• Proposer: TKOIII 20:11, 29 October 2018 (UTC)

### Discussion

• See also related phabricator task (phab:T190813 [converting en:Module:Convert to extension) and phab:T77978 - unit conversion in Wikidata). eranroz (talk) 18:31, 10 November 2018 (UTC)
• It's a bit odd that the United States is the last country defending the Imperial System. What would Benjamin Franklin think? Actually, technically, the US uses Customary Units, which are significantly different from the British-defined Imperial units. A US pint is ~95mL less than an Imperial pint, for instance. The UK still uses Imperial for a few purposes, such as beer and roadsigns. The former British Empire largely uses metric. The only country still officially using the Imperial standard is Belize.
The convert template is not just about Imperial/metric. It can handle weird historical units from old sources, for instance. According to the Phab ticket it is used on ~80 wikis. We need better unit conversion, especially on Wikidata (I recently had a Wikidata query return unitless temperatures).
For ambiguous measurements, like "pint", I'd support prompting, but if the editor's input is in metric, I'd oppose the prompt. I'd rather have a bot do it and save the editor's time. I don't like having computer programs nag me to do something they could do better. :) HLHJ (talk) 23:48, 17 November 2018 (UTC)

### Voting

•   Support SEMMENDINGER (talk) 19:19, 16 November 2018 (UTC)
•   Support James Martindale (talk) 19:32, 16 November 2018 (UTC)
•   Support Tom Ja (talk) 20:06, 16 November 2018 (UTC)
•   Oppose. Sorry, but this is just the problem of Anglosphere. I believe the limited resources of the Community Tech team should be spared for proposals which have a greater, if not global, impact. There are many local problems with MediaWiki or WMF projects such as the limited support for Iranian calendar. Do I want to see a broader support for the Iranian calendar here? Yes. Do I want to assign this laborious task to the Community Tech team? No, because that would be selfish. 4nn1l2 (talk) 00:50, 17 November 2018 (UTC)
•   Support it's a genuine global problem and solution seems lightweight, good to have it on board. Cohaf (talk) 00:57, 17 November 2018 (UTC)
•   Support @4nn1l2: Please note that at least Russian use Cyrillic-based unit symbols (e.g. кг) instead of Latin-based (e.g. kg), so this should also be useful for Russian users. Liuxinyu970226 (talk) 04:28, 17 November 2018 (UTC)
Do Russians use Imperial units? 4nn1l2 (talk) 04:33, 17 November 2018 (UTC)
@4nn1l2: Sometimes yes, and they even translate them, e.g. they translate inch as "дюйм". --Liuxinyu970226 (talk) 04:37, 17 November 2018 (UTC)
•   Support Hiàn (talk) 04:38, 17 November 2018 (UTC)
•   Support Libcub (talk) 10:35, 17 November 2018 (UTC)
•   Support ديفيد عادل وهبة خليل 2 (talk) 13:14, 17 November 2018 (UTC)
•   Support Atsme📞📧 16:07, 17 November 2018 (UTC)
•   Support 20:16, 17 November 2018 (UTC)
•   Oppose Redactyll (talk) 15:40, 17 November 2018 (UTC)
•   Support Viswaprabha (talk) 23:04, 18 November 2018 (UTC)
•   Oppose Waste of scarce resources as mentioned by 4nn1l2. Waddie96 (talk) 07:54, 19 November 2018 (UTC)
•   Support I think it would be nice to have basic unit conversion between many units provided by default as a Lua module to any and all wiki. —TheDJ (talkcontribs) 12:53, 19 November 2018 (UTC)
•   Support Novak Watchmen (talk) 00:37, 21 November 2018 (UTC)
•   Support As this proposal's creator, I wholeheartedly support this ;) TKOIII (talk) 18:19, 21 November 2018 (UTC)
•   Support Poslovitch (talk) 20:30, 22 November 2018 (UTC)
•   Support Dreamy Jazz (talk) 13:26, 26 November 2018 (UTC)
•   Support Filipović Zoran (talk) 19:34, 26 November 2018 (UTC)
•   Support General Rommel (talk) 00:46, 27 November 2018 (UTC)
•   Support Minoo (talk) 20:49, 27 November 2018 (UTC)
•   Support Ogat (talk) 02:18, 29 November 2018 (UTC)
•   Support Dumbassman (talk) 18:01, 29 November 2018 (UTC)

## Easy talk page posts by email

• Problem: A huge number of people send emails to Wikimedia projects requesting edits to Wikipedia articles, Wikimedia Commons files, and elsewhere. The experienced Wikimedia community base knows this process as OTRS. People sending emails are typically very lost and confused, but in almost all cases, what they really want and need is for their comment by email to go onto the talk page of a Wikipedia article or Commons file page. Instead, all these texts and requests get lost into the private OTRS system where only a few OTRS agents review them. OTRS is currently a catch all for emails to any Wikimedia project, but actually, what it should be is a system for inviting people to on-wiki systems to make public requests about wiki editing. Separate from public requests and outside the scope of this problem, OTRS also gets private questions on sensitive issues, and those issues should stay in OTRS and not be changed by this proposal.
While a billion plus people know Wikipedia somehow they have no awareness that wiki talk pages exist or that they can post messages there. Instead work queues back up in OTRS with requests that the client wants to be publicly discussed.
• Who would benefit: People making what they intend to be public edit requests by email would benefit by getting their request successfully delivered to the Wiki community of reviewers and editors. The Wiki community would benefit by massively increasing the number of people actively contributing to Wikimedia projects. If we could make it easier for new users to post to talk pages we would get a huge number of new account registrations, an actual constructive edit from new accounts (most new accounts have no edits ever), actual new user positive on-wiki engagement, thoughtful suggestions with wiki editors, and relief for wiki administrators whose time should not be spent explaining talk pages.

Sample form which should output a post to a Wikimedia talk page
• Proposed solution: We need a pathway in OTRS for the email response team to return an automated form to people who send emails. The form needs to setup their email for posting to a Wikipedia talk page and ask the person writing if they agree to post it publicly by Wikipedia's terms of use. There should be a form with three fields - Wikipedia article name (or file for Commons, or equivalent for any other Wikimedia project), subject line, and message. To complete the form a user has to either log in or create an account. The user posts a message in the form and the tool output is posting the form text to the bottom of the talk page. The tool automatically signs the user's wiki name to the post and tags it with a "help me" template. This on-wiki review replaces the private OTRS review in the majority of email requests which want public discussion with Wikipedia editors and reviewers.
• More comments: If we had a way to convert the labor of the people making these thoughtful requests by email into requests on Wiki talk pages, we could realistically increase the number of Wikimedia users making substantial and thoughtful edits to Wikimedia projects by 10% with very little outreach or technical development.
• Phabricator tickets:
• Proposer: Blue Rasberry (talk) 17:18, 10 November 2018 (UTC)

### Discussion

• Sample form - the tool would look like this, and have the output of posting text live to a Wikimedia project. Blue Rasberry (talk) 18:04, 10 November 2018 (UTC)
• Cool idea. --Izno (talk) 19:06, 10 November 2018 (UTC)
• Yes, very cool!   — Jeff G. ツ please ping or talk to me 02:37, 11 November 2018 (UTC)
• Great idea! This will also reduce the traffic to OTRS and volunteers will have more time to deal with other tickets. KCVelaga (talk) 04:10, 11 November 2018 (UTC)
• Great idea, minor quibble. Sending HTML e-mails is insecure and high-bandwidth, and some servers filter them out. I suggest sending a link to a secured web page, ideally instead of an HTML email, but if there's some good reason as well as one. HLHJ (talk) 07:29, 14 November 2018 (UTC)
• Good idea, which keeps the general idea ofa free-form submission, but makes it a little easier. It's a better way to go than to try to get i nfixed check the boxes system. DGG (talk) 05:44, 15 November 2018 (UTC)
• pinging participants in wm2018:OTRS agents - I am requesting your vote of support for this OTRS proposal in the annual Wikimedia Community Wishlist survey. Please also consider Community_Wishlist_Survey_2019/Editing#Route_users_through_knowledgebase_before_contacting_OTRS.
@Doc James, Martin Kraft, Rehman, Masti, and -revi:
@Bachounda, Masssly, 0x010C, علاء, and May Hachem93:
Thanks. Blue Rasberry (talk) 18:59, 17 November 2018 (UTC)
• Would be nice to have a tool that makes [4] easier to use. User:Harej has already started to build something similar here. It just needs a bit more work. Would make a nice tool for the subjects of articles to provide feedback to the talk page. User:Bluerasberry wondering your thoughts on adding boxes for the following?
• Explanation of issue: ADD TEXT HERE
• References supporting change: ADD URL AT LEAST
• Doc James (talk · contribs · email) 19:05, 17 November 2018 (UTC)
@Doc James and Harej: I would certainly be willing to collaborate with Harej. If any designer recommends adding more steps then I support it. In general, more steps means less participation. More steps increases the value of the content, but people already write detailed emails for edit requests that get lost to OTRS, and my first priority is recovering the labor and thought of those emails. We rarely get Wikipedia talk page posts that are long but long email requests are routine. To start the conversation I would like to turn the 1 step of sending an email into 2 steps, email and simple form which is a unorganized box for text. Additional features make the user do steps 3, 4, and so on. Someone else can decide how hard to push for more steps. Blue Rasberry (talk) 20:23, 17 November 2018 (UTC)
• Simplest case A simpler case than my proposal could be a plain text box for input and assistance registering an account. If we have an account and the text of a comment, then even without sorting the issue or an article title, we could dump all these responses into a noticeboard or public queue. From there, OTRS agents (or anyone else, it is public at this point) could move the requests and comments to the appropriate talk page. If we did this we would greatly increase Wikimedia contributions and reform the OTRS system to focus on private requests, and leave public requests to public channels. Blue Rasberry (talk) 20:26, 17 November 2018 (UTC)
• We could combine these two solutions by having a "I don't know" default for the "Which Wikipedia article?" question. HLHJ (talk) 00:53, 18 November 2018 (UTC)
As you said a lot of talk pages related wishlists are out of scope, Why not this one? --117.14.243.161 03:29, 26 November 2018 (UTC)
Hi, we saw this proposal as being more about improving the OTRS system. The talk page-related proposals that we archived were about changing the way that talk pages work, in one way or another. -- DannyH (WMF) (talk) 00:46, 27 November 2018 (UTC)

## Flag edits by new editors (editor retention tool)

• Problem: Wikipedia is steadily losing editors. If a new editor has all their edits reverted, they are much less likely to become a long-term editor (survival drops from three-in-five to one-in-five). Even one revert discourages newbies. Revising or tagging new editors' edits does not have the same discouraging effect. It can even be taken as praise[5]; personalized constructive criticism is especially helpful.[6]

In other words, every time I help two to three new editors make their first retainable, productive edits, I win Wikipedia a long-term editor and multiply my contribution; and to do this I need to treat the new editor with additional care. Problem is, I don't know who they are, and the user interface makes it difficult for me to not auto-bite newbies.

Experienced editors can deal with a bold revert and a line of jargon, and it's efficient, but it scares new editors off. I want to know when I am interacting with a new editor, so it's easier for me, as an editor, to behave in ways that promote editor retention. For instance:
1. leaving edit summaries which are educational and comprehensible to a newbie (e.g. link all jargon), so the newbie can learn community norms
2. tagging edits with Inline cleanup tags, so the newbie can learn what is wrong with their edits
3. fixing edits (rephrasing copyvio or bias, sourcing, etc.), so the newbie can learn how to make good edits
• Who would benefit: Increasing retention is critical to the long-term survival of our community.
• Proposed solution: An icon-style flag on edits, saying this edit was made by a new editor, would be nice. It would also let me rescue edits others have reverted. A list of edits by new editors can already be generated by using filters in Recent changes, but I'd like to see the information in the article history, so I see it in my regular editing practice (that is, without going to a dedicated page, like Recent changes, or using specialized tools such as Snuggle or STiki). Others may prefer a similar flag in watchlists.
While I hope it would prompt help, such a newbie flag might also stigmatize new editors, and thus hurt their integration into the community. This should be tested. One alternative might be to flag only reverted edits by good-faith new editors, and have an edit notice prompting anyone reverting a new editor (especially using a tool) to be aware that this is a new editor, so they can react appropriately.
As I need to mention in the edit summary if I am fixing an edit of a declared-COI editor, a (different, obviously) COI flag for COI edits would also be useful. Flagging edits by vandals reverted with "rvv" with yet another flag might also be an easy extension.
Since helpful advice when reverting good-faith newbies almost always includes a referral to the Teahouse, it might be nice to have that added to the revert notice automatically for the first 2 months/100 edits (or empirically-determined thresholds).
I'm very much open to suggestions here, as I am aware that many others have more knowledge and experience than I in this area.
• Phabricator tickets:
• Proposer: HLHJ (talk) 04:15, 30 October 2018 (UTC)

### Discussion

Re-scope
Discussion of rescoped proposal

The proposal has been changed as above; comments on the new proposal are welcome here. MMiller (WMF), do you have views on how the modified proposal might interact with the Growth Team's work? As DannyH said, the proposal had morphed into a bit of a "have a Growth Team" proposal, but it's smaller now. HLHJ (talk) 01:40, 15 November 2018 (UTC)

### Voting

•   Support Stussll (talk) 00:51, 17 November 2018 (UTC)
•   Support Liuxinyu970226 (talk) 04:25, 17 November 2018 (UTC)
•   Support Gnangarra (talk) 09:37, 17 November 2018 (UTC)
•   Support Barcelona (talk) 18:56, 17 November 2018 (UTC)
•   Oppose Old serious editors now dislike Wiki because any newcomers can wreck well done pages, which requested hours of effort. Once the time all stubs were welcome, now this phase is ended: all main subjects are covered, quality of articles is now needed. Too much indulgence with newcomers has the only effect that old serious editors will leave Wiki. A ntv (talk) 08:23, 18 November 2018 (UTC)
• This is an interesting hypothesis, A ntv, that wiki maturity caused the abrupt transition from exponential growth in editor numbers to a slow decline. However, the same transition occurred at the the same time on many, but not all, other wikis, which mostly have far fewer articles than the English Wikipedia.[11] It seems that old editors are leaving at the same rate as they did before the transition, but we are getting fewer new editors, leading to a steady net loss of editors.[12] Possible causes are discussed on Research:The Rise and Decline. HLHJ (talk) 23:24, 18 November 2018 (UTC)
• IMHO the abrupt transition occurs, in any Wikis, when the easy-to-find-sources (i.e. mainly online other encyclopedia or similar) have been fully used to create new articles (fun and rewarding job). After that the number of contributions depends from two items: a) the easiness to find sources (google book / libraries), and b) the need to defend the articles from troll/newcomers. In the future, to improve an article or create an interesting new article of true encyclopedic interest, it will be more and more difficult to find sources (libraries or scientific papers) and off-line work it will take more and more time. Editors who use now most of the time in selecting sources, are less and less interested in taking care of the newcomers who write trivial articles on not-encyclopedic people or make edits without even having read all the article they modify. Please protect the old editors.A ntv (talk) 07:52, 20 November 2018 (UTC)
• Research:The Rise and Decline and its associated paper discuss this theory, citing it as having been proposed by Suh et al. in 2009. There is limited evidence to support it; in a sample of human-rated newbie edits, good-faith newbies dropped moderately from 92.2% to 79.8% of all new editors during 2005 (total editor numbers were rising sharply and Wikipedia was much in the news, so this probably represents more vandals), and newbie edits to longer articles are more likely to be rejected, for instance.
The transition occurred at the same time on de-wiki, tho, and they not only have fewer articles, they have much less well-developed articles (and a lower requirement for sourcing). A substantial proportion of the editors can read English at a near-native level, too. If writing useful new work had become more difficult because de-wiki editors had exhausted the easy sources and easy article topics, one would expect that the monoglot German-speakers might be less productive, while the people with good English would still be just as productive (as comparison with en-wiki clearly shows that there are plenty more usable English-language sources, and article topics). I have not seen any evidence of this.
You are, however, now very likely to get an edit on either wiki rejected if it isn't initially perfect. If it has grammatical errors, formatting errors, or is unclear to the reviewer, it will probably get reverted, and it probably won't get fixed by someone else. The learning curve for new editors has become precipitously steep, and anyone who does not scale this learning cliff does not become a regular editor. The effects of learning-curve steepness on retention are known from video games. Most people won't climb cliffs. To keep going, they need a hike, not too steep, not too flat, continually challenging. As you say, the old editors need care; if we lose old editors faster than we train new ones, our community will dwindle and die. But we will lose old editors, if only to death, and we must train new editors fast enough to replace them. Currently we don't; editor number are falling, and areas of the wiki are falling silent. It's starting to feel like a ghost town. HLHJ (talk) 04:52, 21 November 2018 (UTC)
• I think that the best prophylactic against wrecking answer is the edit-approval (Sichten) system used on German Wikipedia PJTraill (talk) 23:14, 26 November 2018 (UTC)
• The edit approval system of the German wikipedia marks edits by newbies (less than 30 edits). It is positive feedback to get an edit approved. Minoo (talk) 21:36, 27 November 2018 (UTC)
• I think it's 50 confirmed edits or 150 edits, and 30 days of registration (policy). I don't know what proportion of edits by good-faith new editors are rejected under this system, and I'm not sure if anyone has tested what effect this has on recruitment and retention. HLHJ (talk) 03:46, 28 November 2018 (UTC)
•   Support NMaia (talk) 10:29, 18 November 2018 (UTC)
•   Support Timeshifter (talk) 15:15, 18 November 2018 (UTC)
•   Oppose reminds me of the StackExchange New Contributor Indicator --Frozen Hippopotamus (talk) 11:22, 19 November 2018 (UTC)
• That sounds like a useful experience, Frozen Hippopotamus. Thank you for the link. Do you know how it worked out long-term? Are there stats? The page you linked to has some comments which seem pertinent; one I liked was "Build the new user experience so that it explains how to use the site instead of relying on users to "be nice" by explaining it to them"; taking this view, this tool suggestion (which I frankly think is better than mine here) might be preferred to the help desk focus, though in practice they are probably complementary. The StackExchange comments also ~contain the ones I made here: testing the effects and making the new-user notice invisible unless the interaction is going to be negative. HLHJ (talk) 05:31, 20 November 2018 (UTC)
• I've since quit SO/SE, not because of this feature but because of the general low quality of the user contributions, especially the questions on SO (different story). Having been a simple user of these sites, I have no insight into how the feature was received once implemented. SE (the company) is not very keen to share raw data or stats about the success of such features. It may be difficult to measure, especially if there is no A/B test (half with, half without a feature) done. --Frozen Hippopotamus (talk) 08:01, 20 November 2018 (UTC)
• That's unfortunate, to say the least, but thank you for the info. I would strongly oppose making any changes that might significantly affect the editor community without good A/B testing. HLHJ (talk) 04:52, 21 November 2018 (UTC)
• It sounds as though you dislike the SE New Contributor Indicator, but I think it a quite reasonable (in spite of the flak in the answers on the linked page), though more important there than here. PJTraill (talk) 23:14, 26 November 2018 (UTC)
•   Support Zeromonk (talk) 08:25, 19 November 2018 (UTC)
•   Support Benjamin (talk) 10:29, 19 November 2018 (UTC)
•   Support BugWarp (talk) 01:15, 20 November 2018 (UTC)
•   Support Novak Watchmen (talk) 01:13, 21 November 2018 (UTC)
•   Support RIT RAJARSHI (talk) 19:38, 21 November 2018 (UTC)
•   Support I often look how many edits a contributor has when reviewing changes, but this would help too. PJTraill (talk) 23:01, 26 November 2018 (UTC)
•   Support WeegaweeK ❀  t  c  08:46, 24 November 2018 (UTC)
•   Support It will be of benefit for newbies. I know that some experienced Wikipedians dislike newbies' inexperience, but it's not the reason why we choose to discourage them. It is a way to balance newbies and the experienced, although it may not be the best. Mariogoods (talk) 13:35, 25 November 2018 (UTC)
•   Support — AfroThundr (u · t · c) 02:10, 26 November 2018 (UTC)
•   Support Dvorapa (talk) 13:17, 27 November 2018 (UTC)
•   Support Reminds me of the way rookie drivers on motorsports circuits have special identifiers on their cars (and how rookie firefighters also have markings on their helmets) Though I think new contributors should be informed of this and allowed to opt out ... some may not wish to be so singled out. Daniel Case (talk) 04:20, 28 November 2018 (UTC)
•   Support Tgr (talk) 08:12, 30 November 2018 (UTC)

## Tool for easy user buttons

• Problem: Users can make their own buttons for better editing, which insert to edit area some templates, parts of code or patterns.

This can be done by editing user javascript page. But majority of users is not skilled enough to make these buttons, only some of them copy it from other users, but when some problem occurs, they are not able to repair it.

• Who would benefit: Editors using wikitext editor.
• Proposed solution: Make some extension, where every user can easily make his own buttons.

Tool can be based on User:Krinkle/Scripts/InsertWikiEditorButton.js. There will be table in the special:preferences

active name text before cusrsor text after cursor picture tooltip
X coord {{Coord|lat |lon|}}   Coordinates
X hello Hello world   insert hello world
O speedy {{Delete}}   nominates for deletion
Values from table will be copied to script (with escaping problematic characters) by tool and user can easily make another buttons without care about script changes or about malicious script.
• More comments: This extension will create user javascript on active wiki or can create global script on meta.
• Phabricator tickets: T136152

### Discussion

Arkanosis, Trizek, doesn't frwiki have something similar to this? I seem to recall that being touted as an advantage there. Whatamidoing (WMF) (talk) 20:23, 2 November 2018 (UTC)

Whatamidoing (WMF): no, the only things we have are:
• a large collection of gadgets, each providing buttons around a common theme (references, patrolling…);
• a framework which is not mediawiki.toolbar but which provides the exact same features except it doesn't break everytime a non-backward compatible change is made in core, and that people can use in their own user scripts to add custom buttons.
Maintenance of the local code has been a nightmare for years for the few of us who work on it — a double nightmare actually, as we have to support both mediawiki.toolbar, the local framework and the mix thereof. Hopefully, with mediawiki.toolbar being retired, we'll be able to make both APIs use the same backend.
I think JAn's idea is quite good, given maintenance is a nightmare because of user scripts, not because of core or gadgets. If people had a way to setup their buttons without having to write code that breaks every few months, not only would they be happier, but maintainers like us would be too.
Best regards — Arkanosis 12:47, 3 November 2018 (UTC)
I agree with that maintenance need. Thank you for that proposal, JAn Dudík. I'm really looking forward an easy way to add buttons, no matter what's the editor. Trizek from FR 11:33, 5 November 2018 (UTC)

## Make default edit summaries available for all wikis

• Problem: The purpose of edit summaries is to understand an edit at a glance, and oftentimes the summary is simple: "reply", "expansion", "basics", or a copy of a bolded !vote ("delete"/"merge"/"keep"). Sometimes editors forget or can't be bothered with writing an edit summary, even though there is a dropdown option with a list of suggestions, and the edit history becomes poorer. And it takes a few seconds even for editors who do leave edit summaries. That's many seconds across many edits. Additionally, edit summaries tend to be filled with acronyms/jargon that are hard for passersby to decipher (these could be expanded/linked to give context).
• Who would benefit: All editors, anyone reading article history
• Proposed solution: As an editor, I want the text editor feature to suggest suggestions for edit summary as a native feature. I want the edit summaries to be approachable for neophytes whenever possible, with acronyms expanded and linked for context.
• More comments: As a place to start, take the dropdown of suggested edit summary options and have the editor (standard or VE) suggest summaries when applicable. There's also room to do things like automatically convert shorthand like WP:5P to [[Wikipedia:Five pillars]] so as to be more approachable to new editors.
• Phabricator tickets: T54859 (VE)
• Proposer: czar 11:37, 3 November 2018 (UTC)

### Discussion

• "The dropdown of suggested edit summaries" is entirely a browser-side item. Of course, there is an entire corpus of edit summaries with attendant changes... You'll have to lean on one of the AIs dealing with vandalism. --Izno (talk) 20:11, 3 November 2018 (UTC)
Czar Hello. Izno is correct. The dropdown on suggested edit summary options you mention is actually a list of edit summaries you have entered in the past that your browser remembers. If you change your browser, you won't see them again. I like the wish but it's a tad bit challenging because we will need to make it work across all languages/wikis. On english it is probably not very hard to do something like this with a gadget maybe but making it work for all wikis is going to be very complex. -- NKohli (WMF) (talk) 00:26, 6 November 2018 (UTC)
Re: the dropdown suggestions, I was referring to the checkbox in Gadgets preferences labeled, "Add two new dropdown boxes below the edit summary box with some useful default summaries". My impression is that these are standard, not based on edit summaries I've entered in the past. Either way, the point is less about using those summaries as sample cases than the larger AI element. czar 02:22, 6 November 2018 (UTC)
Ah, I see what you mean. It is a gadget. I think a good place to start would be to first make some default summaries available for all users in all editors. Right now you only see it if you have enabled the gadget. What you suggest about predicting the edit summaries based on article text - that's technically challenging until we get a hold of some artificial intelligence systems sadly. -- NKohli (WMF) (talk) 18:37, 6 November 2018 (UTC)
Czar Hello. We discussed this in our team meeting today and there was consensus that we cannot do anything predictive because making it work across different languages will be very challenging and a huge project for Community Tech team. What we can do instead is to allow wikis to add a list of standard edit summaries which are presented to all users on the wiki when they are adding the edit summary (can be an optional dropdown or suggestions as they type etc). If you think that changing the scope for this wish is fine, please reply back to me and I will rename the proposal (or you can do that if you prefer). If we cannot change scope, we will need to turn this wish down because it is too big for our team. I'm sorry about the inconvenience. Thanks in advance. -- NKohli (WMF) (talk) 22:04, 13 November 2018 (UTC)
Hi and appreciate your looking into this. Would your described dropdown differ from the dropdown currently available in the enwp Gadget menu ("Add two new dropdown boxes below the edit summary box with some useful default summaries")? If not, the existing gadget would suffice. I think the opportunity here to use patterns to automatically generate edit summaries to create smarter edit histories and/or save editor time. If the scope is too big for the Community Tech team, would there be a better place to suggest such a feature for another team (WMF or independent) with different resources? czar 00:53, 14 November 2018 (UTC)
@Czar: The main difference would be that the solution we devise would bring this functionality to all wikis and not be restricted to English Wikipedia. In addition to that we can look into making the default summaries more configurable by the community (not hardcoded into the gadget like it is). We can also provide UI improvements (such as auto-complete suggestions when user starts typing something that matches up with a stored summary). The reason it is so hard to do predictive summaries is because we don't currently have any machine learning in place which can do any pattern detection with edits diffs. I don't know of a good place for you to suggest this right now but I will be sure to bring this to the attention of other teams in the Foundation. I know there are a couple of other projects that are working on Machine Learning features. Hopefully they will consider adding this too. Czar, can I go ahead and rename and tweak this proposal? Thank you. -- NKohli (WMF) (talk) 01:43, 14 November 2018 (UTC)
, yes, please! Thank you. czar 01:49, 14 November 2018 (UTC)
Thanks so much, Czar. If you disagree with any of the changes I make, please do let me know and I will fix them. -- NKohli (WMF) (talk) 01:59, 14 November 2018 (UTC)
FYI, on enwiki I've read complaints about mobile's canned edit summaries that imply that vandals or clueless newbies tend to just hit one at random. If the feature is not opt-in, I wouldn't be too surprised if enwiki configures an empty list of canned summaries. Anomie (talk) 15:18, 14 November 2018 (UTC)
There are wikis which have summary buttons. And I many cases I had problem, my edits dint't fit tinto these summaries. JAn Dudík (talk) 13:23, 20 November 2018 (UTC)

### Voting

•   Support Braveheidi (talk) 01:30, 17 November 2018 (UTC)
•   Support Liuxinyu970226 (talk) 04:44, 17 November 2018 (UTC)
•   Support Nimrodbr (talk) 10:34, 17 November 2018 (UTC)
•   Support Libcub (talk) 10:42, 17 November 2018 (UTC)
•   Support ديفيد عادل وهبة خليل 2 (talk) 13:21, 17 November 2018 (UTC)
•   Support NMaia (talk) 10:25, 18 November 2018 (UTC)
•   Support Stryn (talk) 22:21, 18 November 2018 (UTC)
•   Support -- Whats new?(talk) 22:26, 18 November 2018 (UTC)
•   Support I'm also concerned about writing accessble edit summaries vs. using incomprehensible jargon--better auto-complete would help Rachel Helps (BYU) (talk) 18:57, 20 November 2018 (UTC)
•   Support Vulphere 23:32, 20 November 2018 (UTC)
•   Support Novak Watchmen (talk) 00:27, 21 November 2018 (UTC)
•   Support I forget to write edit summary very often. RIT RAJARSHI (talk) 19:22, 21 November 2018 (UTC)
•   Support It's pretty much the same as "Autocomplete summaries in VisualEditor". They should be combined somehow. Amir E. Aharoni (talk) 09:25, 27 November 2018 (UTC)
•   Support YFdyh000 (talk) 17:16, 27 November 2018 (UTC)

## Add key mapping for Yoruba, Igbo, and Hausa to ULS

• Problem: Recently I publicized a project within my local community that involve volunteers translating some particular words from English to some local Nigerian languages. I was surprised when everyone of the participant didn't know how to apply diacritics to their translations using their keyboard, even though they understand how it is used. I've been on Wikipedia for quite a while, and I still didn't have an appropriate solution for them on the spot. I understand that there might be some persons within those WP language communities that can do this well, but its either awareness level on it is still low, or its still not as easy or convenient as it should be. Some months ago, i contacted a major editor in one of the local languages on behalf of a new editor in my community on how the new editor can use those special characters, and the response I got was that I used use Google, and she provided me with a link on Google. This was not easy for me to understand, not to talk of explaining to another person. If we must consolidate contents in local languages, this is a concurrent issue. I think Hausa is the only local Nigerian language that doesn't need special characters. My email is full of translations for Yoruba and Igbo, but I can't use them or train volunteers on how to use them without an easy way of applying the diacritics.
• Who would benefit: Any language Wikipedia that doesn't have a specialized keyboard for its words.
• Proposed solution: Add support for Yoruba, Igbo, and Hausa to the IME keyboard. It'll have a huge impact in editing those local language WP.
• Phabricator tickets:
• Proposer: HandsomeBoy (talk) 15:29, 4 November 2018 (UTC)

### Discussion

Thanks for the reply AKlapper and MusikAnimal (WMF), I'll be glad if my proposal is reworded to provide availability to include those languages.HandsomeBoy (talk) 23:30, 13 November 2018 (UTC) Regards. HandsomeBoy (talk) 23:30, 13 November 2018 (UTC)
Great! I would suggest "Add key mapping for Yoruba, Igbo, and Hausa to ULS". Does that sound okay? If so I'll be happy to move the proposal for you to the new name. MusikAnimal (WMF) (talk) 23:33, 13 November 2018 (UTC)
Hi HandsomeBoy, I have taken the liberty of renaming and rewording your proposal. Feel free to reword it more if anything looks off. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 03:11, 15 November 2018 (UTC)
• This is clearly an important thing to do. Yoruba has over 80 million native speakers, Igbo has 50 million, and Hausa (which sometimes uses tone marks) has 40-odd million native speakers and about half again as many using it as a second language, as it is a lingua franca. Obviously we also need an easier way for new users to find the key mappings they need and ask for them on Phab if they don't (have slightly changed the word selection of the proposal). HLHJ (talk) 00:38, 18 November 2018 (UTC)

It's a good request, but I had already done this for Yoruba (and I can improve it if needed), and it can be done for Hausa and Igbo, too. It's a thing that will take less than a day once the layout is defined well, so it doesn't really need to be in the wishlist. The wishlist is for projects that take several weeks. So just contact me and we'll figure it out quickly. --Amir E. Aharoni (talk) 09:24, 27 November 2018 (UTC)

This wish is now fulfilled :)

See:

Thanks for asking this! --Amir E. Aharoni (talk) 07:10, 14 December 2018 (UTC)

### Voting

•   Support Liuxinyu970226 (talk) 04:42, 17 November 2018 (UTC)
•   Support Not sure if this is the right forum, but it needs doing, which is a more important consideration. Surprised it hasn't been done already. HLHJ (talk) 00:43, 18 November 2018 (UTC)
•   Support Zeromonk (talk) 07:59, 19 November 2018 (UTC)
•   SupportTheDJ (talkcontribs) 13:50, 19 November 2018 (UTC)
•   Support Novak Watchmen (talk) 00:36, 21 November 2018 (UTC)
•   Support Sannita - not just another it.wiki sysop 00:44, 24 November 2018 (UTC)
•   Support Gce (talk) 16:40, 24 November 2018 (UTC)
•   Support Uanfala (talk) 19:54, 24 November 2018 (UTC)

## Wikitext substitutions should work in ref and gallery blocks

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

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

• Phabricator tickets: T4700: Pre-save transform skips extensions using wikitext (gallery, references, footnotes, Cite, status indicators, pipe trick, subst, signatures)
• Proposer: bdijkstra (talk) 09:27, 5 November 2018 (UTC)

### Discussion

Gallery, tables, templates, pictures, etc should be fully functional for formatted texts. RIT RAJARSHI (talk) 18:52, 21 November 2018 (UTC)

### Voting

•   Support Liuxinyu970226 (talk) 08:09, 17 November 2018 (UTC)
•   Support Any chance? JAn Dudík (talk) 20:15, 17 November 2018 (UTC)
•   Support Viswaprabha (talk) 23:20, 18 November 2018 (UTC)
•   Support Ahecht (TALK
PAGE
) 16:31, 19 November 2018 (UTC)
•   Support Novak Watchmen (talk) 00:27, 21 November 2018 (UTC)
•   Support Gallery, tables, templates, pictures, etc should be fully functional for formatted texts. RIT RAJARSHI (talk) 18:52, 21 November 2018 (UTC)
•   Support Wargo (talk) 23:33, 22 November 2018 (UTC)
•   Support Helder 13:10, 25 November 2018 (UTC)
•   Support Dvorapa (talk) 13:06, 27 November 2018 (UTC)
•   Support XanonymusX (talk) 17:00, 29 November 2018 (UTC)

## Tool for easy science editing using linked dictionary

• Problem: There is no tool to facilitate science editing, which makes it difficult for the editors to work in the field. Also, the terms used are different in different languages and there's no link between them. It will be great if we have a tool, where if they add their language code and english name for the subject, it automatically gives the name in the desired language.
• Who would benefit: It will be a lot more convenient for the editors to work and the content so generated will be veritable.
• Proposed solution: if we can link the dictionary with editing by creating a tool with which by adding a command, the editor will be able to add the local language term for anything using the english word (the command will pick the desired language translation from wiktionary or dictionary). This will dismiss the necessity to know the specific terminology in their native language. Also, it will keep standard terms for the same word in different languages and will also link them all.
• Phabricator tickets:
• Proposer: Manavpreet Kaur (talk) 20:25, 8 November 2018 (UTC)

### Discussion

• I think this tool should maybe wait a year or two more because we are still integrating the structured dictionary into Wikidata. --Izno (talk) 00:21, 9 November 2018 (UTC)
• What is "science editing"? --AKlapper (WMF) (talk) 12:49, 9 November 2018 (UTC)
I interpreted "science editing" to mean "editing in topics related to science". --Izno (talk) 15:19, 9 November 2018 (UTC)
Izno correct. By science editing I meant editing in topics related to science. I appreciate your input, but we can also work on a pilot project for one language where we can link wiktionary and wikipedia, and later we can also work on wikidata integration.- Manavpreet Kaur (talk) 15:19, 10 November 2018 (UTC)
• There are a lot of languages that simply don't have a term for a lot of scientific concepts. We might need to make terms up. HLHJ (talk) 07:15, 14 November 2018 (UTC)
• To be clear, I think this would be a wonderful project to undertake on Wikiversity, Manavpreet Kaur. I believe engineers in Iceland did something similar about a century ago. Since creative scientific lexicography involves creating knowledge, though, this would have to be done on Wikiversity, not Wiktionary. HLHJ (talk) 05:42, 22 November 2018 (UTC)
• Interesting... but hard enough for native speakers to explain some things in ONE language, let alone NON-native speakers in TWO, especially with precise topics like science. Wikicat (talk) 21:53, 17 November 2018 (UTC)
• Actually, I believe the German government has such scientific word lists for German, as they require some grant proposals to be written in German, and German scientists have to look up the German scientific words as most scientific communication is in English. We could probably get these data donated to Wiktionary and/or Wikidata. Icelandic also has a formal list, I think, but not sure if there's a science-specific one. Generally, soliciting donations of such lists seems like a good idea. HLHJ (talk) 05:42, 22 November 2018 (UTC)
• Thank you everyone for showing interest in the proposal. Actually the need was realized when we were creating medical articles. A lot of editors were reporting issues that finding appropriate medical terms in their native language was difficult and time consuming. Also, the different terms used in different languages for one subject matter also leads to confusion. So, in order to facilitate the editors to create content and also to standardise the terminology being used, it will be better if we have some linked system of providing translated names (for desired language) for the standard medical terms (in English)in a single command. We can run the pilot on one language and can later make it available for other languages. -Manavpreet Kaur (talk) 20:01, 23 November 2018 (UTC)