Community Wishlist Survey 2019/Editing

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

Community Wishlist Survey 2019

Editing
27 proposals, 247 contributors, 399 support votes

Go-previous.svg Citations  •  Maps Go-next.svg

Contents


Tool for easy science editing using linked dictionary

Support Edit proposal/discussion

  • 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.
  • More comments:
  • 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)
  • @Manavpreet Kaur: 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)
  • 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)

Voting

Easy talk page posts by email

Support Edit proposal/discussion

  • 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.
@Dyolf77, Krishna Chaitanya Velaga, Sannita, Sargoth, and DerHexer:
@Doc James, Martin Kraft, Rehman, Masti, and -revi:
@Bachounda, Masssly, 0x010C, علاء, and May Hachem93:
@Armineaghayan, Mardetanha, NahidSultan, and Ijon:
Thanks. Blue Rasberry (talk) 18:59, 17 November 2018 (UTC)
  • Would be nice to have a tool that makes [1] 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?
    • Information requested to be added or removed: ADD TEXT HERE
    • 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)

Voting

Syntax highlighting of special characters

Support Edit proposal/discussion

  • Problem: In the Wikipedia 2017 wikitext editor, special characters are not highlighted. This makes it difficult to distinguish between em- and en- dashes. In the previous but not officially supported editor, the em- and en- dash had either an m or n above the dash to let the editor know which one was in use. Because I cannot tell which dash is in the text, I find myself deleting the old dash and inserting the correct one to make sure the correct one is in the final copy.
While the minus special character looks slightly different than the em- or en- dash, it is hard to see on its own. The minus special character is important for articles with mathematical formulas.
  • Who would benefit: Anyone who edits Wikipedia and is concerned about the correct use of special characters, specifically the dashes.
  • Proposed solution: Some sort of syntax highlighting for special characters. How it was done before is good enough for me. Others might have a better solution—just don't make it so you have to hover the mouse pointer over it.
  • More comments:

Discussion

  • "the old editor" - that was a user created editor btw, not an officially supported one. May I suggest framing the problem more generically and removing references to specific technology choices? State your problem "It is hard to distinguish/find non-visible or very similiar characters like nbsp, em-en dashes)", before discussing specific technologies. —TheDJ (talkcontribs) 09:35, 30 October 2018 (UTC)
    • Thank you for the suggestion. Hopefully the changes I made read better. I had no idea the older editor was not officially supported and user created—it was simply the editor I always remember using. It's also the default if I don't choose the "new" editor as a beta feature.PopularOutcast (talk) 23:05, 30 October 2018 (UTC)
      • Some of them are, and some of them aren't – and there are a lot of them. See mw:Editor for one (possibly incomplete) list. Whatamidoing (WMF) (talk) 20:03, 2 November 2018 (UTC)
  • No matter how one chooses to describe the problem, there are characters which cannot be easily visually distinguished. Some way to identify them would be useful. · · · Peter (Southwood) (talk): 11:53, 30 October 2018 (UTC)
  • You could also add non-Latin characters that are basically visually identical to latin characters (e.g., А and A, use ctrl-find, they're not the same character). GMGtalk 12:15, 30 October 2018 (UTC)
  • Side effect of this should be replacing   with e.g. colored space-like character (), so readability of source text will be better. JAn Dudík (talk) 12:40, 30 October 2018 (UTC)
  • I have run into other editors with this problem as well. There was some desire to enter the characters as HTML entities like — which I think makes wikitext harder to read and edit, especially for novice editors. One important change that got consensus in that discussion was that on the English Wikipedia, the "insert character" widget below the edit box needs to have hover text that gives the name of each character. Otherwise it's hard to know if you are inserting an emdash, endash, hyphen, or minus. -- Beland (talk) 19:09, 4 November 2018 (UTC)

Voting

  • Support Support Debenben (talk) 18:32, 16 November 2018 (UTC)
  • Support Support PopularOutcast (talk) 00:21, 17 November 2018 (UTC)
  • Support Support Also agree with JAn Dudík's comment. re   Akme (talk) 04:12, 17 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 08:01, 17 November 2018 (UTC)
  • Support Support Tractopelle-jaune (talk) 09:45, 17 November 2018 (UTC)
  • Support Support Libcub (talk) 10:46, 17 November 2018 (UTC)
  • Support Support I have had this problem with the 2010 editor too. — pythoncoder (talk | contribs) 19:44, 17 November 2018 (UTC)
  • Support SupportThanks for the fish! talkcontribs 20:05, 17 November 2018 (UTC)
  • Support Support JAn Dudík (talk) 20:13, 17 November 2018 (UTC)
  • Support Support Szalax (talk) 09:19, 18 November 2018 (UTC)
  • Support Support NMaia (talk) 10:26, 18 November 2018 (UTC)
  • Support Support Afernand74 (talk) 17:49, 18 November 2018 (UTC)
  • Support SupportTheDJ (talkcontribs) 10:55, 19 November 2018 (UTC)
  • Support Support Especially like Beland's discussion point: when hovering above a toolbar character, about to enter it by clicking, the name of the character should be displayed so we know for sure what character we are about to enter. Jc3s5h (talk) 11:10, 19 November 2018 (UTC)
    • Small note, that technically would likely be considered to be a separate issue from this proposal. —TheDJ (talkcontribs) 13:36, 19 November 2018 (UTC)

Make Wikipedia more accessible to the visually impaired

Support Edit proposal/discussion

  • Problem: So far, editing/using Wikipedia or other Wikimedia Foundation projects require full usage of our visual, because of keyboard-input method. We need to find a way to expand Wikimedia Foundation project interface to be able to accommodate the visually impaired people so that they also can get the benefit of this free knowledge for mankind of Wikipedia. (I rewrite this statement from the previously written at Community Wishlist Survey 2019/Programs and events section)
  • Who would benefit: People having difficulties in their visual in using Wikipedia.
  • Proposed solution: Make Wikipedia (and other Wikimedia Foundation projects) to be visually impaired-friendly. First, for searching the articles in Wikipedia, we need to create a sound-sensitive input method so that they can easily search any article by speaking (e.g. into microphone input) and automatically convert it into wording and automatically search the related article names from it. Second, for each article, there must be a button that can be clicked (or sound activated mode) in which it will then read out all of the wordings inside one particular article to the user.
  • More comments: So far the closest works for this kind of project is Wiki in Audio (including Wikimedia:Spoken articles, Wikipedia:WikiProject Spoken Wikipedia, Meta:Wikisound). But what I have understood so far, those sound must be fully recorded, thus disabling the spoken voice to speak out when the article gets expanded. So, it is better to make each of the word to be spoken one by one, instead of recording a voice for the whole article continuously. Maybe a more similar approach would be like the voice button at Google Translate, in which it will speak out each word one by one.
  • Phabricator tickets:
  • Proposer: Chongkian (talk) 04:12, 6 November 2018 (UTC)

Discussion

  • The reason I don't think this is possible is that speech-to-text and text-to-speech software is subject to patents held by various companies. The software that runs Wikipedia is required to be open licensed just like the content. Patents last about 20 years, so speech-to-text and text-to-speech technology that is not restricted by patents is from 1998 and so not very good. Also, just to let you know, w:Wikipedia:Manual of Style/Accessibility is a guideline in the Manual of Style that covers accessibility. AHeneen (talk) 08:32, 6 November 2018 (UTC)
    • @AHeneen: I partially disagree. Free text-to-speech software and technology has existed for ages (Orca comes to my mind as an example). I don't know about speech-to-text though. --AKlapper (WMF) (talk) 11:37, 6 November 2018 (UTC)
      • AKlapper (WMF), Gnangarra: For copyleft and other open-source voice-to-speech software, see Speech recognition software for Linux. If you can speak or understand speech, Voxforge is copyleft and could use your contributions. The voice-assistant en:Mycroft (software) was a copyleft version of Cortana/Alexa etc., but then they relicensed it, and I don't know of a copyleft equivalent. HLHJ (talk) 01:44, 18 November 2018 (UTC)
        • @HLHJ: there's a need for it to be incorporated somehow into the mobile Wikipedia app, with step like pending changes for the obvious spelling/grammar reasons. Gnangarra (talk) 03:28, 18 November 2018 (UTC)
  • For the second part of this proposal (text-to-speech), see mw:Wikispeech. Also see phab:T194014 about making Wikispeech available in Wikimedia projects. --AKlapper (WMF) (talk) 11:37, 6 November 2018 (UTC)
  • Not really needed; blind people like me use screen readers, and helping those who don't is way way beyond the scope of what almost 99.99999% of websites do. Graham87 (talk) 11:50, 6 November 2018 (UTC)
  • @Comp1089: may be interested. --Tohaomg (talk) 15:52, 8 November 2018 (UTC)
  • I also use a screen reader, so the text-to-speech thing is not an issue in most cases. However, text-to-speech (input and/or reading) is not supported in a great number of languages, which is a real problem. For instance, due to the unavailability of a voice able to read Bashkir (or Kazakh) Cyrillic script, I always have to write the text in Latin transliteration (and then convert it to Cyrillic, if it is a Wikipedia article). Advocacy for creating/developing screen reading voices for as many languages as possible will probably be a task of the Para-Wikimedians Community User Group.
    As far as speech-to-text is concerned, enabling all people to search through the content using their voice seems a rather good idea. This may also come in handy when a blind/visually impaired user is for some reason unable to use a keyboard. (On a side note, there also are sighted people who cannot do that either, e.g. due to movement impairment). However, introducing such a technology to all Wikimedia wikis will definitely require a lot of time and other resources. --Comp1089 (talk) 19:05, 8 November 2018 (UTC)
  • Voice search does already exist in the Android and iOS Wikipedia apps via standard integration with their operating systems. However, very good points above about limited language support, and those apps only help on the Wikipedias. Quiddity (WMF) (talk) 22:16, 8 November 2018 (UTC)
  • observation isnt the fact that all speech to text and text to speech are propriety software as reason to develop a open source version so that everyone can share in the sum of all knowledge, I assume the visually impaired fall into the subset of everyone, also as tool it could help with contributions from smart and mobile devices. Gnangarra (talk) 01:17, 9 November 2018 (UTC)
  • @Graham87: Sorry for abusing this thread for a more specific question. I would be interested if you can understand Wikipedia pages with mathematical content. I guess mathematical articles that make heavy use of template-hacks are the worst, I would guess most of them are not really accessible at all. However also for math formulas using the normal <math> tags, speakText generation is disabled (phab:T120938), so the screen-reader would have to pick up the hidden MathML and generate text itself. Does this work well? Is this sufficient to understand more complex formulas, or do you need the interactive "accessibility explorer" that gets shipped with normal MathJax and pages like math.stackexchange.com use? At least for someone like me who is not used to screen-readers, this accessibility explorer where you can navigate with arrow keys is the only way how I might understand a more complex formula.--Debenben (talk) 19:49, 12 November 2018 (UTC)
I think I may respond here either. I do experience difficulties reading the more complex formulæ. The solution you suggested seems to work best with NVDA. @Graham87:, which screen reader do you normally use? --Comp1089 (talk) 21:02, 12 November 2018 (UTC)
I use JAWS with its inbuilt math viewer, which works well for simple formulae (and is slow but eventually works for more complex ones) ... it's usually good enough for me. Graham87 (talk) 01:28, 13 November 2018 (UTC)
Hi, @Chongkian: As was mentioned in the discussion, building a voice-to-text (and a text-to-voice) system is quite out of scope for the Community Tech team, and there are already several tools that already exist that are providing very good solutions. The problem statement itself -- improving the accessibility functions of Wikipedia for the visually impaired -- is extremely important, and we will be happy to tackle that; if the wish is voted into the top 10, we will be doing an accessibility audit on Wikipedia's main functionalities and tackle the necessary fixes, while scoping the size of the work to be realistic for the team to achieve as part of the survey. Thank you for participating in the survey! MSchottlender-WMF (talk) 01:31, 14 November 2018 (UTC)
Sounds good. Is there any way to make those graphs for which we have the raw data accessible to the blind? Graph Template Collection] graphs, for instance. Separately, how about having colour filters for the colourblind, who often can't read graphs and diagrams (mentioned here)? Or at least a way to auto-tag problematic images... HLHJ (talk) 08:02, 14 November 2018 (UTC)
I believe we all should do this one by one, and step by step. Of course we can't have everything that is accessible to normal people to become accessible to the visually impaired. We can always start first with the text to audio reading thing, including all of the article searching, and probably searching of categories or even switching between different languages (of course we shall start from the major world's languages first). And then we shall see how we can "visualize" (in a broader sense) on all of those visuals (picture, graphs, videos) to the visually-impaired people. Those with full or partial color blind, probably we should have some equivalent (either upload it double-ly/redundantly (how to put this into words? - like the ability to easily switch between visual editor or normal coding) black & white graphs/images, but with color description (pointers telling this section is what color & that section is what color). Or maybe in the future, every image uploaded to Commons, we can always give the voice input (beside naming typing input), so that the uploader or other Wikipedia users can record the voice (or type the description and convert it into voices) to describe the photo (e.g. "A photo with a kid on the left, sitting looking into a pond with 5 ducks swimming towards him during late afternoon."). Basically it goes back to our childhood when our mothers read a storybook to us before we go to sleep, or during the era of radio before television appear, where people fully depend on sound for "visualization" when hearing a story (equivalent to "watching movie" nowadays) broadcasted from radios. Chongkian (talk) 07:32, 15 November 2018 (UTC)

Hi all, thank you so much for all of the great & beautiful response :') Chongkian (talk) 07:27, 15 November 2018 (UTC)

Also check out this proposal..... *excerpt*

Problem: Available Text to Speech for all wiki Articles (Wikispeech extension). Let the articles talk when Required.
Wikispeech logo.svg
Proposed solution:
1. "Wikispeech" is a text-to-speech tool (in Beta) to make Wikimedia's projects more accessible for people that, for different reasons, have difficulties reading. At first make it available for en wikipedia . then asign more developer so that it can have cortana/siri/google assistant like "precise accent" & "natural voice".then make this extension/api integrate with mediawiki software. And please make the voice more natural like this "Cortana,Alexa" or "Google Assistant".
2. Google text to speech api is licenced under apachi 2.0 . Is it possible to ask them to make a github fork with CC/GFDL licence only for official wiki project, cause this proposal also humanitarian? They have natural-sounding speech with 30 voices, available in multiple languages and variants.

—The preceding unsigned comment was added by Ahm masum (talk) 20:07, 15 November 2018 (UTC)

Voting

Make the math tag support non-Latin languages

Support Edit proposal/discussion

  • 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 <math> tag (that is, the "mathematical formula" function).

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

  • 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"? Failed to parse (syntax error): {\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 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: Failed to parse (syntax error): {\displaystyle \ce{2H2{+}O2->[点燃] 2H_2O}}
or,
Comment Comment expected output: in zh as: 2H2+O2点燃—>2H2O
Over here, TeX does not support Chinese. 脂肪酸钠 (talk) 07:33, 7 November 2018 (UTC)
Comment 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>:

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> [2] (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>:

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.[3] 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 [4] 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)

Voting

  • Support Support Debenben (talk) 18:28, 16 November 2018 (UTC)
  • Support Support Boehm (talk) 18:57, 16 November 2018 (UTC)
  • Support Support Please add support for Arabic script 4nn1l2 (talk) 02:01, 17 November 2018 (UTC)
  • Support Support Cohaf (talk) 02:03, 17 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 04:29, 17 November 2018 (UTC)
  • Support Support Leiem (talk) 05:47, 17 November 2018 (UTC)
  • Support Support JAn Dudík (talk) 20:15, 17 November 2018 (UTC)
  • Support Support, but only if reasonably technically feasible. HLHJ (talk) 06:42, 18 November 2018 (UTC)
  • Support Support NMaia (talk) 10:24, 18 November 2018 (UTC)
  • Support Support Shizhao (talk) 02:46, 19 November 2018 (UTC)
  • Support Support Zeromonk (talk) 08:22, 19 November 2018 (UTC)
  • Support Support Emptyfear (talk) 15:42, 19 November 2018 (UTC)
  • Support Support Paweł Ziemian (talk) 21:11, 19 November 2018 (UTC)

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

Support Edit proposal/discussion

  • 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)

Voting

Avoid links to disambiguation pages

Support Edit proposal/discussion

  • Problem: On nl-wiki, a link to a disambiguation page is in general seen as an unwanted link, that should be resolved to one of the option on that disamb-page.
  • Who would benefit: The reader (gets better links) and the maintainer of these wrong links.
  • Proposed solution: Give a warning before saving the page, that disamb-links are available. If a user persists and saves anyways, we at least tried.
  • More comments:
  • Phabricator tickets: T97063, T198936
  • Proposer: Edoderoo (talk) 12:29, 30 October 2018 (UTC)

Discussion

  • An example of the kind of page/link this should discourage would help voters to better understand this proposal. AEzell (WMF) (talk) 22:34, 30 October 2018 (UTC)
  • There are rare cases where links to disambiguation pages are actually correct. We should probably only warn them when the new content being added contains a disambiguation link (rather than when any of the saved content contains a disambiguation link). Kaldari (talk) 04:28, 31 October 2018 (UTC)
  • Yes, sure. Hatnotes often link to disambig pages though, so those would need to be excluded (can presumably be done fairly easily).
  • There was a similar proposal on the English Wikipedia in 2016 (see en:Wikipedia:Village pump (proposals)/Archive 133#Confirm on save when adding links to disambiguation pages), which didn't pass. There was some useful discussion there. Uanfala (talk) 18:45, 4 November 2018 (UTC)
    • Hmm, useful? Frustrating. When I press save, I want to save. Basta. When you close your eyes, you never see any problem ;-) But it still needs to be solved. On the Dutch wikipedia only, we get about 100 new disambiguation links added every day, and it's a sjid-load of work to get them link to the right page(s). And often it's the same user over and over again making that mistake. Maybe one change to my idea: implement this initially for users that are logged in with their account/password, and skip this question for ip-users. Users with an account are assumed to be more wiki-wise then ip-people. Edoderoo (talk) 07:58, 5 November 2018 (UTC)
  • Every mandatory requirement/warning/error message becomes one more step that prevents people from making a change. That's probably bad in a lot or even most cases. This one won't be getting my support. --Izno (talk) 01:37, 6 November 2018 (UTC)
  • What if we had a function to have any link that goes to a page with a disambig tag of any sort be colored bright green, or something like that. For links that are intended to go to disambig pages, maybe a special piped command or something to not make them stand out as needing correction. KConWiki (talk) 03:06, 6 November 2018 (UTC)
    • I already have this in my css. We only should make this default to all users that login with an account. Edoderoo (talk) 06:33, 7 November 2018 (UTC)
      • After I enabled orange disambig links, I got much better at not including them in articles. Support making orange disambig links the default. HLHJ (talk) 07:13, 14 November 2018 (UTC)

Voting

  • Support Support Liuxinyu970226 (talk) 04:47, 17 November 2018 (UTC)
  • Support Support Libcub (talk) 10:37, 17 November 2018 (UTC)
  • Support Support ديفيد عادل وهبة خليل 2 (talk) 13:14, 17 November 2018 (UTC)
  • Support Support Yes - most good-faith editors would welcome an alert telling them how to improve their page by linking to the article they want instead of to a dab page! I use the "colour them orange" gadget and find it really helpful. PamD (talk) 18:31, 17 November 2018 (UTC)
  • Support Support per PamD. Edoderoo (talk) 20:05, 17 November 2018 (UTC)
  • Support SupportThanks for the fish! talkcontribs 20:09, 17 November 2018 (UTC)
  • Support Support ALWAYS 3rd-color in Preview, unless special link-prefix says ignore. Wikicat (talk) 22:44, 17 November 2018 (UTC)
  • Support Support Tim Landscheidt (talk) 02:47, 18 November 2018 (UTC)
  • Oppose Oppose per Izno. However, I agree that this is a problem, so if the warning was opt-in, I would support it. Another good idea mentioned above is to add a preference to give dab page links a different colour. — Bilorv (talk) 03:28, 18 November 2018 (UTC)
  • Oppose Oppose I agree with Bilorv that this is something that could be added to preferences as an opt-in (for example, I have my preferences set to alert me that I am trying to save without providing an edit summary) but can deter new editors. AHeneen (talk) 06:28, 18 November 2018 (UTC)
  • Support Support Ainali (talk) 11:40, 18 November 2018 (UTC)
  • Support Support — Draceane talkcontrib. 18:04, 18 November 2018 (UTC)
  • Support Support -- Whats new?(talk) 22:28, 18 November 2018 (UTC)
  • Support Support Waddie96 (talk) 07:54, 19 November 2018 (UTC)
  • Support Support Ahecht (TALK
    PAGE
    ) 16:30, 19 November 2018 (UTC)

Include section name in the diff

Support Edit proposal/discussion

  • Problem: When reading the revision diff, mostly it is hard to understand, which part of the page the diff line belongs to, because line number does not help so much - there is no line numbering in view mode.
  • Who would benefit: Everyone who opens page diffs.
  • Proposed solution: Regularly the differ does not show the changed line only, but also a line before and a line after, with no changes. I propose to show also the line with the most bottom subsection name the changed line belongs to, on both sides, as is, with equality signs. It's just one more line, but it will help to know exactly where you are. If there are many changes in the same subsection, the name will show only once, of course. This way the diff will be just a little longer - because section names are always shorter than regular lines and take less vertical space, but much more useful. Now we should copy all the time some part of changed line and search it using the browser searching mechanism.
  • More comments: There are two possibilities for using this feature - articles and talk pages, including forums as village pump, and it will help in both.
  • Phabricator tickets: None.

Discussion

  • I like it. It can be a possibility to infer the section automatically or in case the user is editing a section already infer a better section if there is one that's deeper than the one that's being edited. Dixtosa (talk) 11:41, 30 October 2018 (UTC)
  • Agreed, If there is any value to line numbers it escapes me. This would be useful · · · Peter (Southwood) (talk): 11:48, 30 October 2018 (UTC)
  • Maybe changing UI it's a better way. —The preceding unsigned comment was added by Talueses (talk)
    Maybe indeed, but as the change is smaller, it has more chances to be implemented. IKhitron (talk) 21:08, 31 October 2018 (UTC)
  • I like this solution, it gives more context.   — Jeff G. ツ please ping or talk to me 03:03, 11 November 2018 (UTC)
  • IKhitron, would this be implemented instead of line numbers, or in addition to them? I support this solution, but I think line numbers should be kept as well, for they are very useful on CSS and JavaScript files' diffs. Guycn2 · ☎‏ 05:55, 17 November 2018 (UTC)
    Line numbers besides 1-3 have no value, there is no real connection between them and the place in the article, if there are infoboxes, galleries and such in the article, or even lines, that are connected into one paragraph without any indication in the text. Something that can really be seen in the article would be very helpful. I'd say: instead, but if someone sees any value in line numbers (I can't come up with a reason now), you can as well leave those. Grüße vom Sänger ♫(Reden) 11:24, 17 November 2018 (UTC)
    Hi, Guy. I really do not care. I can thing about another need of numbers - for example, if you see in diff lines 351 and 353 you can guess they are close. But it isn't so important, and isn't part of this proposal. IKhitron (talk) 14:40, 17 November 2018 (UTC)
  • Regarding the UI, I would suggest taking inspiration from the functionality (but not the formatting) for displaying context in source code diffs formatted as standard GNU diffutils patches (which is also the Git diff format). There, the context (function heading) is displayed along with the affected line numbers at the start of each chunk. Here's an example:
diff --git a/gtk/gtkmenushell.c b/gtk/gtkmenushell.c
index 4788590..cb94c64 100644
--- a/gtk/gtkmenushell.c
+++ b/gtk/gtkmenushell.c
@@ -585,18 +585,45 @@ gtk_menu_shell_button_press (GtkWidget      *widget,

   if (!menu_shell->active || !menu_shell->button)
     {
-      _gtk_menu_shell_activate (menu_shell);
+      gboolean initially_active = menu_shell->active;


diff --git a/gtk/gtkwidget.c b/gtk/gtkwidget.c
index 58ce2db..921c22a 100644
--- a/gtk/gtkwidget.c
+++ b/gtk/gtkwidget.c
@@ -2443,6 +2443,13 @@ gtk_widget_class_init (GtkWidgetClass *klass)
                                                               0.0, 1.0, 0.04,
                                                               GTK_PARAM_READABLE));

+  gtk_widget_class_install_style_property (klass,
+                                           g_param_spec_boolean ("window-dragging",
In the sample above, the first chunk:
@@ -585,18 +585,45 @@ gtk_menu_shell_button_press (GtkWidget      *widget,
modifies 18 lines of the gtk_menu_shell_button_press() function, starting at line 585, and the result is 45 lines long starting at line 585 in the output file. (I've trimmed the diff length so those counts aren't accurate.) The detailed line numbering would be overkill for us, but the function heading represents the equivalent context to our section headings.
So instead of adding the section line into to the diff output (when it may be pretty far from the chunk being displayed), and rather than replacing the line numbers, I suggest the section title be shown following the line number at each diff chunk, even where it's redundant with the previous chunk(s). (If it's on the same line as the line#, it's not taking up any extra space anyway.) My edit here might be preceded with
Line 22: ===Discussion===
in the diff view. -- FeRDNYC (talk) 15:51, 17 November 2018 (UTC)
I still don't get it, what this line numbers are good for at all, except in some very special outliers like .css or .js pages. Nobody can see and follow them in any article that if bigger then a stub. Grüße vom Sänger ♫(Reden) 17:39, 17 November 2018 (UTC)

Voting

TemplateWizard in VisualEditor

Support Edit proposal/discussion

  • Problem: An extension which guides users through the filling-in of templates, called TemplateWizard, was recently deployed in the 2010 WikiEditor. It works neither in 2017 WikiEditor nor in VisualEditor ('cause they are based on the same code, I guess). In the VisualEditor, there is a native widget, which does a very similar job like the TemplateWizard, just isn't that user-friendly and that nice. I can't possibly understand, why there are two code-wise completely different solutions for one problem, which should have only one UI solution.
  • Who would benefit: All users who switch between editors – nowadays they face different UI with different abilities for the very same purpose.
  • Proposed solution: Just join them! And use the newer one! So implement the TemplateWizard into VE!
  • More comments: Already discussed here and mentioned above in #Intra-template VisualEditor
  • Phabricator tickets:
  • Proposer: YjM (talk) 00:35, 10 November 2018 (UTC)

Discussion

  • The VE template editor supports a lot more use cases than the wikitext one, specifically editing existing templates on the page, and editing multi-part templates such as tables built from multiple templates. The VE template editor works in the 2017 wikitext editor as well. It would not be possible to use the TemplateWizard in VE as it in based on editing wikitext directly, not Parsoid HTML, but ideally the UIs would be more similar. ESanders (WMF) (talk) 13:50, 10 November 2018 (UTC)
  • This is a great a idea. I think there could be a categorized template system or framework for different article types with pre-polluted instructional and example content to aid in producing/constructing better quality articles. The instructional sample content could advise editors on how to justify data or information and how to better qualify sources. Bab-a-lot (talk) 16:29, 11 November 2018 (UTC)

Voting

Cross-Platform AutoWikiBrowser

Support Edit proposal/discussion

  • Problem: As a Apple mac user, I am most concerned that there is no opportunity to utilise AWB when editing
  • Who would benefit: Apple users who are unable to use AWB
  • Proposed solution: further development of T157271 to allow for cross-platform usage of AWB
  • More comments:
  • Phabricator tickets: T157271
  • Proposer: :JarrahTree (talk) 10:47, 10 November 2018 (UTC)

Discussion

@JarrahTree: Have you tried JavaScript Wiki Browser at en:User:Joeytje50/JWB?   — Jeff G. ツ please ping or talk to me 03:19, 11 November 2018 (UTC)

thanks for notification - have applied for permission to use the browser :JarrahTree (talk) 15:29, 11 November 2018 (UTC)

Voting

  • Support (as suggestor) :JarrahTree (talk) 00:00, 17 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 08:02, 17 November 2018 (UTC)
  • Support Support ديفيد عادل وهبة خليل 2 (talk) 13:14, 17 November 2018 (UTC)
  • Support Support Atsme📞📧 15:40, 17 November 2018 (UTC)
  • Support Support web-based AWB? yes, please czar 21:31, 17 November 2018 (UTC)
  • Support Support JWB is nice but yes, this would be welcome. ~ Amory (utc) 12:32, 18 November 2018 (UTC)
  • Support Support This would make me a much more effective gnome. Jonesey95 (talk) 20:00, 18 November 2018 (UTC)
  • Support Support Viswaprabha (talk) 23:23, 18 November 2018 (UTC)
  • Support Support I would like to see AWB become web based and perhaps even have some server side actions. Wikidata integration would also be cool ;) ·addshore· talk to me! 10:05, 19 November 2018 (UTC)
  • Support Support Courcelles 15:11, 19 November 2018 (UTC)
  • Support Support Sadads (talk) 18:48, 19 November 2018 (UTC)

Allow preview edit on protected page

Support Edit proposal/discussion

  • Problem: Requested edits to protected pages, especially templates, may be untested, leading to rejection or delays as problems are resolved.
  • Who would benefit: Readers, as templates are fixed more accurately and promptly; editors requesting edits to protected templates; editors fulfilling such requests.
  • Proposed solution: Allow an editor to preview an edit to a protected template even if they would not be permitted to commit the edit.
  • More comments: "Preview page with this template" is extremely useful but has no effect when testing in a sandbox. Of course, the editor should see a prominent warning before working on the page that it would not be possible to save the change. Once an editor is happy with their work, I would expect them to copy and paste the edited source into a sandbox ready for promotion by a template editor. The feature could apply to all pages or just to templates and perhaps modules. If there are concerns that editors will waste time writing material that cannot be saved, then it could be an opt-in preference (off by default).
  • Phabricator tickets:
  • Proposer: Certes (talk) 12:04, 9 November 2018 (UTC)

Discussion

  • I note it's possible to use Special:TemplateSandbox to test edits to protected pages as described at mw:Extension:TemplateSandbox#Usage. That is less convenient that doing it from a edit preview, though. Anomie (talk) 12:29, 9 November 2018 (UTC)
  • Could anger users as unsaveable: The idea of such editing, as an unsaveable protected page, is a topic for en:computer psychology, and most likely the better solution would be copy-to-sandbox, as noted above. The general strategy would be to avoid giving users "enough rope to hang themselves" just as dangling several nooses in a room could increase the risk of accidental hangings. Even as an opt-in mode, some users might imagine the page as saveable, before they realized the warnings. It would be very dangerous to allow preview editing unless the sandbox-save was understood as the only result, because enticing a user to spend hours editing the protected page, as if somehow useable, would likely trigger severe infuriating anger or livid outrage, because users often ignore short warnings of how the editing of a protected page could become a huge waste of time. The inability to edit a protected page really gets the user's attention, as no chance to save changes, rather than foster a false hope that careful, excellent changes surely would be saved. As for enable a run-preview of user-sandbox templates, that is a separate topic. -Wikid77 (talk) 10:19, 10 November 2018 (UTC)
Yes, we need to avoid that problem. This screen shouldn't be accessible via the normal Edit tab. Perhaps the header which appears on View Source could have an "Edit without saving for preview only" button. This item is a proposal rather then a completed design. At the time of writing I wasn't aware of Special:TemplateSandbox, which does the job in a roundabout and awkward way. Improving that special page to allow a /sandbox suffix rather than a prefix, and giving it more publicity (a mention on the View Source header?) might be a better solution, as the user could save the sandbox in the right place ready for promotion by a template editor or admin. Certes (talk) 10:33, 17 November 2018 (UTC)
The problem with Special:TemplateSandbox using a "/sandbox" suffix is that you'd wind up picking up the sandboxes of every template with a sandbox, not just the one you're trying to check, and many of those are likely to be outdated or broken. If you want to test with an existing /sandbox-suffixed page, you can create a redirect to it under an appropriate prefix. Anomie (talk) 14:18, 17 November 2018 (UTC)

Voting

  • Support Support James Martindale (talk) 19:36, 16 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 08:04, 17 November 2018 (UTC)
  • Support Support Libcub (talk) 10:36, 17 November 2018 (UTC)
  • Support Support Atsme📞📧 15:49, 17 November 2018 (UTC)
  • Support Support ANY protected-page editing should warn like Preview, change "Publish" to "PROPOSE", and only save in History (with "PROPOSED" tag) or handle like Extension:Moderation Wikicat (talk) 01:56, 18 November 2018 (UTC)
  • Support Support Ainali (talk) 11:41, 18 November 2018 (UTC)
  • Support Support Noting the very real concerns in the #Discussion section. ~ Amory (utc) 12:30, 18 November 2018 (UTC)
  • Support Support Viztor (talk) 03:45, 19 November 2018 (UTC)
  • Support Support Weegaweek (talk) 07:53, 19 November 2018 (UTC)
  • Support Support Benjamin (talk) 10:27, 19 November 2018 (UTC)
  • Support Support - tucoxn\talk 18:54, 19 November 2018 (UTC)

Easy way to reference pictures

Support Edit proposal/discussion

  • Problem: If you want an unambiguous reference to a figure in the text, you currently have to number all figures manually or write "see figure on left/right/below... the second one in this paragraph... the one where the electric field lines are marked in red" and hope that nobody changes the picture or its location and the reader already knows how to distinguish electric from the magnetic field lines. Re-submission of Community_Wishlist_Survey_2017/Editing#Automatically_create_a_reference_id_for_pictures_with_a_label
  • Who would benefit:
  • Proposed solution: If you write <figref>Particle-path.png</figref> in the source code, all figures in the article are numbered automatically and <figref>Particle-path.png</figref> is replaced with the number that [[File:Particle-path.png|caption of the figure]] has been assigned. See scholarpedia for an example of how it can be implemented.
  • More comments:
  • Phabricator tickets: T7600
  • Proposer: Debenben (talk) 17:05, 11 November 2018 (UTC)

Discussion

Voting

Change formatting of particular cells in VisualEditor

Support Edit proposal/discussion

  • Problem: Editing would be much easier if while working on tables we could change colours of particular cells in VisualEditor. I hate switching to source editing and typing ‘align-center’ every time I need it.
  • Who would benefit:
  • Proposed solution:
  • Phabricator tickets: phab:T54180
  • Proposer: DS limak (talk) 14:07, 4 November 2018 (UTC)

Discussion

@DS limak: Is this phab:T54180? --AKlapper (WMF) (talk) 00:46, 5 November 2018 (UTC)

@AKlapper (WMF): Yes, it is. DS limak (talk) 06:53, 5 November 2018 (UTC)

Voting

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

Support Edit proposal/discussion

  • 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.
  • More comments:
  • 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)
@HandsomeBoy: 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)

Voting

  • Support Support Liuxinyu970226 (talk) 04:42, 17 November 2018 (UTC)
  • Support 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 Support Zeromonk (talk) 07:59, 19 November 2018 (UTC)
  • Support SupportTheDJ (talkcontribs) 13:50, 19 November 2018 (UTC)

Autocomplete summaries in VisualEditor

Support Edit proposal/discussion

  • Problem: In Wikitext editor the summary field automatically drops down an autocomplete suggestion field with possibilities already used in a history. But in VE there is no such autocomplete option.
  • Who would benefit: Every VE user (and NWE in the future as well)
  • Proposed solution: Add some dropdown under or over VE summary field with some autocomplete suggested values
  • More comments:

Discussion

  • @Dvorapa: This is an interesting suggestion! Can you elaborate, a bit? Where would you envision these autocomplete suggestions come from? You mention 'history' -- is that where we'd pick them up, from the user's recently used summary text? Or from the recently used summaries for the x amount of revisions in the specific article? Also, I don't see a drop-down for the edit summary in the wikitext editor; is that a gadget, or am I looking at the wrong place? Mooeypoo (talk) 01:02, 30 October 2018 (UTC)
    In wikitext editor the summary field autocompletion is a feature of every browser. It can autocomplete from any summary used in the browser ever. In VE this feature is completely missing. For us who are really used to use it, this is really a blocker not to use VE (or NWE in the future). --Dvorapa (talk) 06:46, 30 October 2018 (UTC)
    The one is a single line field, and browsers keep automatically keep history for that. VE uses a textarea, for which the browsers don't keep history and for which support for autocomplete and autofill is also quite shaky. —TheDJ (talkcontribs) 09:31, 30 October 2018 (UTC)
    Since browser support can be spotty, I'd recommend that this be a server-side feature (recent summaries from x amount of revisions by that particular editor). --Ahecht (TALK
    PAGE
    ) 16:25, 30 October 2018 (UTC)
    The browser support is not good, I know. But there already are some simple hacks online, like the one using contenteditable field. Or the one breaking input filed into multiple lines. But the server-side option would do as well. --Dvorapa (talk) 14:28, 10 November 2018 (UTC)
    Oh, okay, thank you, I wasn't sure if this was a gadget that uses some specific guesses or not. As was mentioned, the difference is likely textarea vs input; browsers give you an autofill for "simliar" fields you've used for inputs, not for textareas. We could do something here, though, even as a gadget or extension to VE (or generally,actually) to display some suggested values to prefill into that box. The question of where those values will be taken from will have to be answered, but we can discuss and hash that out, as long as you don't expect this to be some smart(sy?) Artificial Intelligent machine ;) MSchottlender-WMF (talk) 20:59, 30 October 2018 (UTC)
    I just miss the original 2010 wikitext editor behavior. I can just type first one-two letters, press Arrow-down and finally Enter. Routine edit saved with reused summary within 4 keys pressed. In VE I always have to write the whole thing, then press Shift+Enter, not such fast job here. --Dvorapa (talk) 21:19, 30 October 2018 (UTC)
    Note that the AI version is phab:T54859. Whatamidoing (WMF) (talk) 20:01, 2 November 2018 (UTC)
  • I like the idea. Gryllida 22:18, 30 October 2018 (UTC)
  • I really miss this in WTE2017 whenever I get dropped into one of the old interfaces. --Izno (talk) 03:44, 3 November 2018 (UTC)
  • I would appreciate such a possibility too. --Peter Gröbner (talk) 08:59, 4 November 2018 (UTC)
  • As a Wiktionarian, I would like to have this working, and it can be with some buttons to click to indicate if it was about a definition change, etymology change, addition of a picture, addition of an example, addition of a synonym, etc. It could be very useful Noé (talk) 10:28, 10 November 2018 (UTC)
    @Noé: There already is an existing gadget that adds buttons/dropdowns with pre-defined/adjustable summaries to click - on cswiki, enwiki, huwiki and skwiki I think. But the purpose of this wish is an autocomplete field (summaries already used in history). --Dvorapa (talk) 14:28, 10 November 2018 (UTC)
    I've ported and improved the huwiki gadget to cswiki, therefore I have some experiences with these if you would be interested. --Dvorapa (talk) 14:30, 10 November 2018 (UTC)

Voting

Make default edit summaries available for all wikis

Support Edit proposal/discussion

  • 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 @NKohli (WMF) 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)
@NKohli (WMF), 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)

Voting

Simplified/semi-automated conversion for units of measurements

Support Edit proposal/discussion

  • 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.
  • 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 Support SEMMENDINGER (talk) 19:19, 16 November 2018 (UTC)
  • Support Support James Martindale (talk) 19:32, 16 November 2018 (UTC)
  • Support Support Tom Ja (talk) 20:06, 16 November 2018 (UTC)
  • Oppose 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 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 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)
    @Liuxinyu970226: 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 Support Hiàn (talk) 04:38, 17 November 2018 (UTC)
  • Support Support Libcub (talk) 10:35, 17 November 2018 (UTC)
  • Support Support ديفيد عادل وهبة خليل 2 (talk) 13:14, 17 November 2018 (UTC)
  • Support Support Atsme📞📧 16:07, 17 November 2018 (UTC)
  • Support SupportThanks for the fish! talkcontribs 20:16, 17 November 2018 (UTC)
  • Oppose Oppose Redactyll (talk) 15:40, 17 November 2018 (UTC)
  • Support Support Viswaprabha (talk) 23:04, 18 November 2018 (UTC)
  • Oppose Oppose Waste of scarce resources as mentioned by 4nn1l2. Waddie96 (talk) 07:54, 19 November 2018 (UTC)
  • Support 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)

Avoid VisualEditor edits changing only the link text or only the link target

Support Edit proposal/discussion

  • Problem: There is an uncountable amount of VisualEditor edits changing only the link text, not the target, especially dates, like this (it’s far less common the other way round, but it should be accounted for as well).
  • Who would benefit: Readers by not getting confusing links, editors (mostly bot owners) by not having to fix them.
  • Proposed solution: I don’t know. It’s a long-standing problem, no ideal solution appeared so far. The main task is to find the solution, not to develop it.
  • More comments:
  • Phabricator tickets:
  • Proposer: Tacsipacsi (talk) 17:49, 11 November 2018 (UTC)

Discussion

This was touched upon in T55973#2792012, I agree that we could try to catch common errors like this. ESanders (WMF) (talk) 18:37, 15 November 2018 (UTC)

Voting

Flag edits by new editors (editor retention tool)

Support Edit proposal/discussion

  • 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.
  • More comments:
  • 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 Support Stussll (talk) 00:51, 17 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 04:25, 17 November 2018 (UTC)
  • Support Support Gnangarra (talk) 09:37, 17 November 2018 (UTC)
  • Support Support Barcelona (talk) 18:56, 17 November 2018 (UTC)
  • Oppose 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)
  • Support Support NMaia (talk) 10:29, 18 November 2018 (UTC)
  • Support Support Timeshifter (talk) 15:15, 18 November 2018 (UTC)
  • Oppose Oppose reminds me of the StackExchange New Contributor Indicator --Frozen Hippopotamus (talk) 11:22, 19 November 2018 (UTC)
  • Support Support Zeromonk (talk) 08:25, 19 November 2018 (UTC)
  • Support Support Benjamin (talk) 10:29, 19 November 2018 (UTC)

Keep the lightweight text editor

Support Edit proposal/discussion

  • Problem: A few days ago, the normal wikitext editor was decapitated of a lot of usability with the deletion of core tools from the software. It was said that the 2017 text editor should be used as an alternative, but it ain't. It's just some extension to the VE, and thus takes hours to load its heavy burden of clutter before you are able to edit anything. The good old text editor on the other hand is fast and furious, and has more than enough tools to edit anything, unless it gets ditched by some short-sighted devs.
  • Who would benefit: All power users that are used to their well-known tools to edit their thousands of articles, and those with no high-end machines and connections, that can't really use anything as cluttered as the VE and its derivates.
  • Proposed solution: Keep and maintain the good old editor, including the tools like toolbars and such.
  • More comments:
  • Phabricator tickets:
  • Proposer: Grüße vom Sänger ♫(Reden) 21:21, 8 November 2018 (UTC)
  • Note: This proposal originated from another, very richly discussed and widely supported wishlist-entry, which was most unfortunately discarded.

Discussion

  • Sänger, for the record, when the 2006 wikitext editor was removed, editors were given the option to use either the 2010 or the 2017 wikitext editors. While the 2017 editor is, as you describe, based on Visual editor, the 2010 wikitext editor isn't. The 2010 wikitext editor is just as lightweight as the 2006 one, isn't based on Visual Editor in any way, and only differs slightly in the locations of buttons (buttons are larger, and some are located in subpanels such as "Advanced", "Special Characters", or "Cite"). To enable it, just choose "Enable the editing toolbar" in the "Editing" section of your preferences. --Ahecht (TALK
    PAGE
    ) 23:30, 8 November 2018 (UTC)
A) The editor is just the white window I just write in, the buttons and menus are not the editor, but tools for the usage of that editor. This proposal/wish is about the core of that, 2017 is no alternative, it's far too slow.
B) The 2006 toolbar and the 2010 toolbar are fine, but there was a collateral damage. And there was not any option, the toolbar above and the special character line beneath the editor simply vanished in thin air. Nobody was warned about that (except perhaps the nerds in some tech-news gibberish).
C) The 2010 is not es flexible ans adoptable as the 2006 I've been told by heavy users of it (I didn't customise it, but I believe those that did and need this). Those are the ones that should have been asked beforehand, whether they want something new or different, not just devs.
Grüße vom Sänger ♫(Reden) 23:47, 8 November 2018 (UTC)

It would be most helpful to first study the very richly discussed and widely supported original wishlist-entry, which has been first archived, then moved to the forum.

For the charinsert-part, there is a potentially reusable char-insert replacement in a nearly finished state on de:WP and currently under test on beta, discussion (in german) here. However, a global gadget to replace the one-click customizable toolbar is still dearly missed and the current workaround barely a band-aid. So, given that a rollback doesn't look like a realistic option anymore, it would be most welcome to code a global gadget that at least replicates, what was lost in close dialogue with not only nerds, but real authors. Best regards --Eloquenzministerium (talk) 00:20, 9 November 2018 (UTC)

  • Панель 2010 и 2017 года не являются полноценными заменами панели 2006 года! И проблема не в оформлении, хотя оно тоже дико не привычно. Они хуже: там много лишнего, а нужное трудно найти. Легче это нужное найти под окном редактирования, но самое главное есть в панели 2006 года.Авгур (talk) 03:13, 9 November 2018 (UTC)
Welcome to our russian-speaking friend, here's a machine-translation: "The panel of 2010 and 2017 are not full replacements of the panel of 2006! And the problem is not in the design, although it is also not wildly familiar. They are worse: there is a lot of superfluous, and the necessary is hard to find. It is easier to find what you need under the editing window, but the most important thing is in the 2006 panel"
Indeed. --Eloquenzministerium (talk) 10:17, 9 November 2018 (UTC)

The light-weight WikiEditor still exists (among the gazillions of other editor options that all need people to maintain them), I'd say? --AKlapper (WMF) (talk) 12:55, 9 November 2018 (UTC)

And people who maintain them is exactly the description of the WMF (and the software part of WMDE). That's the very essence of the pure existence, especially that of software dev employed by the WMF: To maintain the existing software according to the wishes if the content editors (in regard of editing interfaces, some can of course as well cater the readers wishes, but editors, i.e. the very core of the wikiverse, should have precedence). Grüße vom Sänger ♫(Reden) 16:35, 9 November 2018 (UTC)
Everyone, it would be helpful in this discussion area if we could just talk about what the technical need is, and not talk about the WMF/contributor relationships. That's obviously a long-standing and difficult concern, and it won't reach resolution here. We also don't need to get into comparisons of the 2006 vs 2010 vs 2017 editors. Sänger has posted a proposal with a specific techical request that the Community Tech team will investigate and address, if this proposal is voted up into the top 10. At that time, Community Tech will be able to figure out the best technical solution that will give the people who voted for the proposal the functionality that they need. -- DannyH (WMF) (talk) 17:33, 9 November 2018 (UTC)

Per some discussion at Community Wishlist Survey 2019/Editing/Put mw.toolbar back, this can already be done. While I don't know what the preference is called in other language, in English, go to the Editing tab in Preferences, uncheck the checkbox which says "Enable the editing toolbar (This is sometimes called the '2010 wikitext editor')". This proposal should be archived. --Izno (talk) 16:17, 10 November 2018 (UTC)

Unfortunately, the 2010 editor is much more memory consuming and significantly slower than the 2006 one. Maybe, there is some way to make it loading faster and consume less memory? Ankry (talk) 17:31, 10 November 2018 (UTC)
This proposal is not "re-add the toolbar" per the discussion at the other proposal. This proposal is "make the standard text area available", which it already is if you uncheck the preference. --Izno (talk) 18:25, 10 November 2018 (UTC)
This proposal is there as a security measure, as some really had the gall to mention the VE-extension, that is a nearly unusable time-hog, as an alterative to the light-weight editor. Thwe plain text editor is the core of heavy editing, and it's surround by a small amount of tools, like toolbars, CharInsert and such. With the deletion of one heavy used tool of this editor, and such making it nearly unusable for a lot of editors, the devs showed their contempt to this editor, and my fear was, that this is the first step of the deletion of the whole editor, because those non-editing devs that seem to run the place may have the impression, that the VE-extension is a viable alternative. It's not. Grüße vom Sänger ♫(Reden) 22:45, 10 November 2018 (UTC)
I have seen multiple discussions come to the conclusion that the plain text area is what MediaWiki should ship by default, regardless of any toolbars or other editors. It's not going anywhere. --Izno (talk) 23:17, 11 November 2018 (UTC)
  • How is this a different proposal than Community Wishlist Survey 2019/Editing/Put mw.toolbar back? Why are there essentially two proposals for the same thing? Repeating my comment from there: 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:24, 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 —The preceding unsigned comment was added by Itti (talk) 10:48, 17 November 2018

@George Ho: Regarding your question in your vote: I'm talking about the basic white field, a plain an simple text editor without any VE clutter. The surrounding tools like buttons and stuff like CharInsert is what the other wish is about. Of course any of these tools should be shipped with the editor as default, just a plain white box without anything around it would be bad as well. I want to make clear, that Texteditor2017 is not what it says on the outside, as it's just an extension of the VE, and is contaminated with all the clutter and extreme time-lags that VE creates. Grüße vom Sänger ♫(Reden) 10:07, 17 November 2018 (UTC)

I'd recommend that editors evaluate TE17 for themselves. I'm only one voice but I can apportion its weight to affirm that it is possible for one's individual experience to culminate with an entirely different conclusion. Mine certainly did. Pozdrowienia od--John Cline (talk) 13:55, 18 November 2018 (UTC)

I can't work out what this wish is asking for. "Keep and maintain the good old editor" - which mw:Editor? If the 2003 wikitext editor, well, that still exists and isn't going away, so this is effectively a wish asking WMF to not do something which they are not planning on doing. And "including the tools like toolbars and such" - isn't the other wish elsewhere in this section of the Wishlist talking about toolbars? Or are we once again getting confused between the blue toolbar above the edit window and the character insertion tools below it, which are entirely separate pieces of functionality? This, that and the other (talk) 10:18, 19 November 2018 (UTC)

That's the problem with all this Special language talking, everybody means something else with the same word.
I'm talking probably about the thing that's called the default MediaWiki editor, which is an HTML <textarea> on the page you linked. There are only two light-weight tool-sets for this editor over there: the 2006, and the 2010, and there is the wikEd, that for me was as well just a tool-set for the lightweight editor, but needs more ressources on the computer. It's just like customising the LibreOffice menue buttons, the editor itself stays the same.
The so-called 2017 wikitext editor is something completely different: It's just an extension to the VE, and ist thus as heavy-weighted as the VE itself. I especially don't want that to be viewed as a good alternative, it's not.
And then there are a lot of very special UIs, that cater only very selected projects and needs. They are something, the special interest groups that need them should decide about.
This wish is to keep the default MediaWiki editor, which is an HTML <textarea>, and keep and maintain one or two sets of tools for it, and look very dilligent whether you brake anything, if you delete one of the good old work horses, to not create any collateral damage for the most valued power editors. The Software is for the Content editors, not the other way around. Grüße vom Sänger ♫(Reden) 13:48, 19 November 2018 (UTC)

Voting

  • Support Support Chaddy (talk) 20:09, 16 November 2018 (UTC)
  • Support Support --Alraunenstern۞ 20:56, 16 November 2018 (UTC)
  • Support Support --Itti (talk) 21:39, 16 November 2018 (UTC)
  • Support Support Atamari (talk) 21:43, 16 November 2018 (UTC)
  • Support Support --Wi-luc-ky (talk) 21:58, 16 November 2018 (UTC)
  • Support Support --Wahrerwattwurm (talk) 22:51, 16 November 2018 (UTC)
  • Support Support Don't know which "lightweight text" the proposal meant: the 2003 wikitext editor (the one without toolbars) or the 2006 wikitext editor (the one with old-school toolbars). Either way, I support keeping both. Those are very good and quicker alternatives to 2010 and 2017 ones. George Ho (talk) 23:08, 16 November 2018 (UTC)
  • Support Support --Gestumblindi (talk) 23:23, 16 November 2018 (UTC)
  • Support Support --Summer ... hier! (talk) 23:28, 16 November 2018 (UTC)
  • Support Support --Rmcharb (talk) 23:29, 16 November 2018 (UTC)
  • Support Support Rhadamante (talk) 00:52, 17 November 2018 (UTC)
  • Support Support Rschen7754 02:41, 17 November 2018 (UTC)
  • Support Support Akme (talk) 04:20, 17 November 2018 (UTC)
  • Support Support As substitute for the unduly ignored wish to keep the existing tools working. --Fano (talk) 04:34, 17 November 2018 (UTC) (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.)
  • Support Support Liuxinyu970226 (talk) 04:41, 17 November 2018 (UTC)
  • Support SupportW. Edlmeier (talk) 07:42, 17 November 2018 (UTC)
  • Support Support -- Ra'ike (talk) 08:30, 17 November 2018 (UTC)
  • Support Support Peterdexheimer (talk) 08:35, 17 November 2018 (UTC)
  • Support Support ZellmerLP (talk) 10:06, 17 November 2018 (UTC)
  • Support Support --Silewe (talk) 10:10, 17 November 2018 (UTC)
  • Support Support --Alinea (talk) 11:25, 17 November 2018 (UTC)
  • Support Support --J. Patrick Fischer (talk) 10:57, 17 November 2018 (UTC)
  • Support Support Aspiriniks (talk) 11:48, 17 November 2018 (UTC)
  • Support Support -- Bertramz (talk) 12:34, 17 November 2018 (UTC)
  • Support Support --Privat-User (talk) 13:14, 17 November 2018 (UTC)
  • Support Support - Squasher (talk) 14:12, 17 November 2018 (UTC)
  • Support Support --Rote4132 (talk) 14:52, 17 November 2018 (UTC)
  • Support Support Doc Taxon (talk) 16:13, 17 November 2018 (UTC)
  • Support Support --Schlesinger (talk) 16:45, 17 November 2018 (UTC)
  • Support Support I do not believe VE will ever be good enough. РоманСузи (talk) 17:32, 17 November 2018 (UTC)
  • Support Support Taurus404 (talk) 18:10, 17 November 2018 (UTC)
  • Support Support Jmv (talk) 18:12, 17 November 2018 (UTC)
  • Support Support --Bubo 18:13, 17 November 2018 (UTC)
  • Support Support Barcelona (talk) 18:58, 17 November 2018 (UTC)
  • Support Support O.Taris (discuter) 19:14, 17 November 2018 (UTC)
  • Support Support Nk (talk) 20:08, 17 November 2018 (UTC)
  • Support Support --Hadibe (talk) 22:29, 17 November 2018 (UTC)
  • Support Support Boehm (talk) 22:35, 17 November 2018 (UTC)
  • Support Support --Altkatholik62 (talk) 22:42, 17 November 2018 (UTC)
  • Support Support Keith D (talk) 23:07, 17 November 2018 (UTC)
  • Support Support As with #Put mw.toolbar back. I do not necessarily want it to have the same editor as I did have before. I just want to a) have a toolbar, b) not have to wait a few seconds before the menu is loaded, especially on mobile NickK (talk) 23:41, 17 November 2018 (UTC)
  • Support Support Tim Landscheidt (talk) 03:05, 18 November 2018 (UTC)
  • Support Support فرهنگ2016 (talk) 10:53, 18 November 2018 (UTC)
  • Support Support --voyager (talk) 13:57, 18 November 2018 (UTC)
  • Support Support Joschi71 (talk) 15:03, 18 November 2018 (UTC)
  • Support Support Timeshifter (talk) 15:05, 18 November 2018 (UTC)
  • Support Support Bruce1ee (talk) 17:42, 18 November 2018 (UTC)
  • Support Support --[[kgh]] (talk) 23:57, 18 November 2018 (UTC)
  • Support Support Benjamin (talk) 10:27, 19 November 2018 (UTC)
  • Support Support β16 - (talk) 11:00, 19 November 2018 (UTC)
  • Support Support Tkarcher (talk) 13:27, 19 November 2018 (UTC)
  • Support Support Courcelles 15:09, 19 November 2018 (UTC)
  • Support Support --Hildeoc (talk) 15:12, 19 November 2018 (UTC)
  • Support Support - tucoxn\talk 18:52, 19 November 2018 (UTC)
  • Support Support --Ghilt (talk) 19:56, 19 November 2018 (UTC)

Warn of other revisions saved during edit-preview

Support Edit proposal/discussion

  • Problem: When editing in wikitext editor, the saving of other, intermediate revisions should be warned during each edit-preview, in case user intends further extensive edits after an edit-preview. Perhaps list:
    • Other user(s) saved 2 revisions
    • Last revision time: 18:03, 10 November 2018 (UTC)
    • Recent revision count: +17 in past week
Those revision stats could be shown at top of edit-preview, above the edit-intro text.
  • Who would benefit: People who edit hot-topic pages could be spared major en:wp:edit-conflicts, when hoping other users aren't as busy, on the same page, to cause further edit-conflicts. The warned user could decide to save-page soon, or postpone further edits until a quieter time period. I have abandoned many, many 1-hour edits after seeing another editor had changed 15 paragraphs, as 3 revisions, in the same spots I was trying to revise. I really don't want to force-save my revision to edit-conflict another user's ongoing work, so just warn in edit-preview how 3 other revisions have been saved since I began this edit-session of the page.
  • Proposed solution: Focus on major, valuable improvements to the most-used wikitext editor, as improvements which could help thousands of editors per day.
  • More comments:
  • Phabricator tickets:
  • Proposer: Wikid77 (talk) 18:03, 10 November 2018 (UTC)

Discussion

  • I like the idea. Although I usually get edit-conflicted by a bot dating my tags, so maybe I just need a setting to make Anomiebot wait. HLHJ (talk) 07:52, 14 November 2018 (UTC)

Voting

Put mw.toolbar back

Support Edit proposal/discussion

  • Problem: The mw.toolbar was removed
  • Who would benefit: All active authors
  • Proposed solution: Restore the toolbar
  • More comments:
  • Phabricator tickets: task T30856
  • 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 Support Bring back the charinsert in German Wikipedia! Chaddy (talk) 20:02, 16 November 2018 (UTC)
  • Support Support Atamari (talk) 21:43, 16 November 2018 (UTC)
  • Support Support --Alraunenstern۞ 22:18, 16 November 2018 (UTC)
  • Support Support Stefan »Στέφανος«  22:40, 16 November 2018 (UTC)
  • Support Support --Wahrerwattwurm (talk) 22:53, 16 November 2018 (UTC)
  • Support Support --Summer ... hier! (talk) 23:27, 16 November 2018 (UTC)
  • Support Support --Rmcharb (talk) 23:28, 16 November 2018 (UTC)
  • Support 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 Support As substitute for the unduly ignored wish to keep the existing tools working. --Fano (talk) 04:34, 17 November 2018 (UTC) (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.)
  • Support Support Liuxinyu970226 (talk) 04:41, 17 November 2018 (UTC)
  • Support Support Ghilt (talk) 08:16, 17 November 2018 (UTC)
  • Support Support Peterdexheimer (talk) 08:41, 17 November 2018 (UTC)
  • Support Support --Gereon K. (talk) 09:33, 17 November 2018 (UTC)
  • Support 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 Support--Silewe (talk) 10:12, 17 November 2018 (UTC)
  • Support Support--Alinea (talk) 11:28, 17 November 2018 (UTC)
  • Support Support FF-11 (talk) 10:40, 17 November 2018 (UTC)
  • Support Support Cbyd (talk) 10:49, 17 November 2018 (UTC)
  • Support Support --J. Patrick Fischer (talk) 10:50, 17 November 2018 (UTC)
  • Support Support --Kpisimon (talk) 11:03, 17 November 2018 (UTC)
  • Support Support --Adelfrank (talk) 11:10, 17 November 2018 (UTC)
  • Support Support -- Bertramz (talk) 12:35, 17 November 2018 (UTC)
  • Support Support --Privat-User (talk) 13:23, 17 November 2018 (UTC)
  • Support Support - Squasher (talk) 14:13, 17 November 2018 (UTC)
  • Support Support --Rote4132 (talk) 14:53, 17 November 2018 (UTC)
  • Support Support Doc Taxon (talk) 16:13, 17 November 2018 (UTC)
  • Support Support Townie (talk) 16:49, 17 November 2018 (UTC)
  • Support Support Jmv (talk) 18:11, 17 November 2018 (UTC)
  • Support Support --Bubo 18:17, 17 November 2018 (UTC)
  • Support 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 Support Nk (talk) 19:58, 17 November 2018 (UTC)
  • Support Support --Hadibe (talk) 22:34, 17 November 2018 (UTC)
  • Support 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 Support Keith D (talk) 23:12, 17 November 2018 (UTC)
  • Support 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 Support Tim Landscheidt (talk) 03:07, 18 November 2018 (UTC)
  • Support Support Ankry (talk) 03:14, 18 November 2018 (UTC)
  • Support Support Per Rhadamante. Or create a new toolbar that is easily customizable! Jules78120 (talk) 10:02, 18 November 2018 (UTC)
  • Support Support --voyager (talk) 13:58, 18 November 2018 (UTC)
  • Support Support Joschi71 (talk) 15:04, 18 November 2018 (UTC)
  • Support Support Timeshifter (talk) 15:08, 18 November 2018 (UTC)
  • Support Support JackPotte (talk) 21:55, 18 November 2018 (UTC)
  • Support Support Benjamin (talk) 10:29, 19 November 2018 (UTC)
  • Support Support --Phi (talk) 15:03, 19 November 2018 (UTC)
  • Support Support --Hildeoc (talk) 15:13, 19 November 2018 (UTC)
  • Support Support Emptyfear (talk) 15:36, 19 November 2018 (UTC)

Visibility of articles needing defaultsort tags for leading articles

Support Edit proposal/discussion

  • Problem: When new pages are created that begin with the articles "A", "An", or "The", editors do not always remember to use the defaultsort tag.
  • Who would benefit: Users who are looking for WP articles in categories alphabetically
  • Proposed solution: Create a Wikipedia function to show special page of any page that starts with "A", "An" or "The" (or foreign language articles?) that does NOT have a defaultsort tag present. Maybe a newly created tag that could be put next to defaultsort tag that signifies "Yes, we do want 'The The' to sort under 'The'." and that new tag would exclude it from being listed as needing to be reviewed for a defaultsort.
  • More comments: In the above, the homonym "articles" is used with two different meanings.
  • Phabricator tickets:
  • Proposer: KConWiki (talk) 04:09, 6 November 2018 (UTC)

Discussion

@KConWiki: I read this 2 times and I'm still unclear what you are proposing. Please dumb this down for me ;) —TheDJ (talkcontribs) 10:02, 6 November 2018 (UTC)

As far as I can tell, it's requesting a special page that would report something like https://quarry.wmflabs.org/query/31004. Anomie (talk) 16:56, 6 November 2018 (UTC)
Which, unsurprisingly, illuminates a good chunk of pages which don't qualify for the point of the special page. As it happens, I don't think we should add a special page as part of CommTech given there is a known work around. --Izno (talk) 18:47, 6 November 2018 (UTC)
Sorry for the lack of clarity - Thanks to Anomie for running that query - out of curiosity is it possible to run one for "The" instead of "A"? Thanks KConWiki (talk) 04:16, 7 November 2018 (UTC)
That query does all three of "A", "An", and "The". It's just that the first several all begin with "A". Anomie (talk) 13:27, 7 November 2018 (UTC)

Alternatively, maybe category collation should take "A", "An" and "The" into account, and only require defaultsort if you really want the sorting to begin with "A". BWolff (WMF) (talk) 16:05, 17 November 2018 (UTC)

Voting

Route users through knowledgebase before contacting OTRS

Support Edit proposal/discussion

  • Problem: The "Contact us" page at en:Wikipedia:Contact us generates a lot of mail to OTRS, many of which are sufficiently answered with boilerplate templates. The OTRS info-en queues are constantly backlogged. Many of the incoming emails (such as those pointing out errors in articles) would be more appropriate if posted to an article talk page instead, others would be best answered by online knowledgebase articles displayed to the user in response to a query. OTRS volunteers continually face a flood of emails that must be handled manually when many of these emails could be pre-filtered by an automated help system. This would free up OTRS volunteers to focus on more difficult and complex requests.
  • Who would benefit: Less workload for OTRS volunteers. Wikipedia community may end up getting more participation. Ceasing public exposure of email addresses would reduce the incoming spam load to OTRS also.
  • Proposed solution: Remove the email addresses from the "Contact us" pages and set up a system that guides the user to a solution before attempting to contact OTRS. The workflow would look like this:
    1. User has a question, goes to help page, which asks "What do you want to know or need help with?"
    2. User selects from list of common topics: I want to request an article, I want to write an article, I found an error, I want to be unblocked, I forgot my password, delete an article, etc.
    3. Depending on the topic, there may be another list: "I want to write an article" would provide options such as: I want to write about myself, I want to write about my company, I want to write about my band, etc.
    4. Depending on the selection, the user is shown a knowledgebase page which would be the boilerplate template that OTRS volunteers would manually respond with anyway — or is directed to one of the help desks or one of the reference desks.
    5. The knowledgebase page, if reached via this support flow, has a button at the bottom asking if this was helpful.
    6. If not, then the user is not shown an email address but is directed to a web form to fill in.
    7. If the message deals with an error in the article, the user is given an option to post the message to the appropriate article talk page rather than emailing, pointing out that the message will have a wider audience that way.
    8. If the user proceeds to emailing, the web form is processed so that an email is sent to the appropriate OTRS queue.
  • More comments: Much of the above can be accomplished by rearranging the pages in the "Contact us" hierarchy. OTRS agents should also be able to add new topics to the flow above, and create new pages, to prevent future mailings. We don't have to hide the OTRS email addresses, but rather show them as a last resort after the user has had a chance to get an answer without emailing. The system we have in place now absolutely doesn't scale, as evidenced by the backlogs and not enough bodies.
  • Phabricator tickets:
  • Proposer: Anachronist (talk) 01:39, 11 November 2018 (UTC)

Discussion

  • Very cool!   — Jeff G. ツ please ping or talk to me 03:26, 11 November 2018 (UTC)
  • Great idea! Ciell (talk) 09:05, 11 November 2018 (UTC)
  • I support this. Good stuff. Ww2censor (talk) 09:34, 11 November 2018 (UTC)
  • This would be useful for OTRS. It would also be useful in many other places. There is a sort of decision tree which new users can go through in the en:Wikipedia:Article_wizard, where new users can answer questions to land on the support they need. One way this could be developed is as a decision tree, chatbot, or whatever other publishing format this takes, and only for OTRS. Another way this could go is to technically develop interactive knowledgebases for general application in any situation. Blue Rasberry (talk) 13:46, 11 November 2018 (UTC)
  • I support this as long as the email “info-[language]@wikimedia.org” is not removed from contact pages and support pages. People should still be able to email in directly, although a form like this would be nice to allow the more common questions to be answered without taking volunteer time. Vermont (talk) 17:39, 11 November 2018 (UTC)
    I agree, the email addresses shouldn't be totally hidden. I added a note to that effect the comment in my proposal above. Anachronist (talk) 16:20, 12 November 2018 (UTC)
  • Not in favour of this. I have read thousands of OTRS tickets, and generally speaking they are written by people who do *not* want to edit Wikipedia. All of the other solutions offered on that page require editing. Some of them even refer the person to convoluted policies (e.g., en:Wikipedia:Dispute resolution) which even experienced Wikipedians have difficulty following. I'd like to see some evidence that a form is more likely to result in customer satisfaction than an email would; someone still has to respond to the form. I'd also like to see mock-ups of forms that would be able to feed directly into the OTRS system. I do not think that the proposal has shown that it will improve workflow, improve customer satisfaction, or reduce the frequency that individuals feel they need to contact someone. Risker (talk) 18:44, 14 November 2018 (UTC)
    For tickets that result in a templated response (from our "knowledge base" of templates), the users should see this before writing an email. Companies who must provide technical support (Dell and A2 Hosting come to mind from personal experience) have similar systems in place because they have already been proven to improve workflow and reduce the need for manual communication. The intent of the proposal here is to provide some directed guidance and information to users before they send an email. Consider also that OTRS is not only in English, but also in other languages where agents are desperately understaffed. Some sort of guided direction and filtering is in order here. Anachronist (talk) 19:31, 14 November 2018 (UTC)
The "knowledge base" is almost exclusively geared to directing the person to edit Wikipedia themselves. That is not a good solution, and is very unfriendly to customers. (I already don't think we're customer-friendly when it comes to many of the responses we make to OTRS customers.) It may make OTRS agents happy, but it does almost nothing for the encyclopedia, and makes work for the editors and admins on the project who get stuck reverting or deleting junk or COI articles/edits. It expects that the OTRS customer actually *wants* to edit Wikipedia; many of them don't want to do that, and some of them already tried that and felt they were treated very poorly. (And in honesty, a lot of them *are* treated poorly.) So no, I think this is precisely the wrong solution to issues. Let's go back to backing up the perception of backlogs and overwork with some real evidence. Enwiki OTRS has about 100 tickets in it as I write; when I first started working on it many years ago, the typical backlog was 3-5 times that high. I don't have access to see the backlogs on other language queues, but this proposal is written in a way that is pretty specific to enwiki. So - let's get some information on the actual backlogs, the percentage of queries that are completed within 24 hours/72 hours/one week, how this compares to years previous, etc. I do have the sense that, just like in many areas of the project, some OTRS agents are feeling fatigued and frustrated. That doesn't mean the system isn't working, or that it should be revamped. It probably means it's time to recruit more OTRS agents and allow those who have been diligently making a large number of responses to slow down a bit. Burnout is a real problem - I know, I've been there - but the best solution for it is fresh faces to allow the most dedicated to take it a little easier. And I do think there is room for improvement with OTRS, but I don't think this would be one that leads to better customer relations, especially when the customers we're talking about are frequently concerned with what they see as serious problems in articles about themselves. Risker (talk) 01:01, 15 November 2018 (UTC)
I strongly disagree that throwing more bodies at a problem is not a good solution, when it's possible to implement a reasonably simple way to provide information to users before they write email. The impression you're giving is that this proposal is to replace humans with an automated process, and that's a straw man, not what is being proposed. Customers will still have the option to communicate with OTRS. Basically I'm proposing two things: that users be given information specific to their question before they contact OTRS, and that they are offered to post their question or complaint on an article talk page for broader exposure. They are not prevented from contacting OTRS. And so far, no one objecting has identified the harm in that. Anachronist (talk) 07:40, 15 November 2018 (UTC)
  • I Would support this as it will bring down the workload for OTRS agents. FitIndia Talk 20:20, 14 November 2018 (UTC)
  • An extremely poor idea, unless reworked to just be an alternative, not an obligatory step, in which case it's just a poor and impractical idea. . We want to encourage people to contact us for problems, not set an extra barrier. Sometimes the knowledge base will be a preferable way, but not always and certainly not for all people. We here are relatively accustomed to working with complex processes, and many of us are not all that happy with asking strangers questions. The general public probably does not share either of these characteristics.
If we do it at all, we should make it an equal option , not a barrier. (And for it to even work in a minimally acceptable way, ,we would first have to rewrite the "knowledge base" into a form that is comprehensible by non-wikipedians. Based on my own experience, that will be very much harder than writing individual answers--and the hardest part of the rewriting will be figuring out what actually happens, and what would be the right way for things to work. To try to put policy into a knowledge base means having clear and non-self-contradictory policy. But very little of our policy is actually of that nature, as a little experience at any process like AfD will show--everything actually depends upon the interpretation, and while the two ends of what we accept or reject may be clear, a great deal comes in the middle, where what actually happens can be almsot random. To get this right is a multi year project, and the writing doesn't need the WMF. Once we've rewritten our documentation successfully ,then willl be the time to consider it. If a few good volunteers made it a priority, and received a some technical support from the Foundation, we might be ready in two or three years (assuming we agree on what should be said, which in practice will mean revisiting almost every guideline we have and rearguing it from scratch) -- but I wouldn't count on it. And then we'd have to maintain it . Don't understimate that, because we have never been able to fully maintain anything. DGG (talk) 05:58, 15 November 2018 (UTC)
Sure, make it an equal option. We are not at the stage of making architectural decisions about how this is structured. In my view, however, doing nothing is not an option. Anachronist (talk) 07:41, 15 November 2018 (UTC)
  • Just so we are all aware here. Any admin with the interface editor right can create .js forms that execute from other areas of the project. I have confidence in our WMF developers to create gadgets and what not but to expect them to create multi-language, in depth, form resources when they don't know exactly what we are going for is just a waste of their time and resources. All that will do is for them to make something for someone who actually cares about the project to tell them they are all wrong making nobody happy. It would just be easier to have someone else do it. Which isn't that hard if you know javascript. --Majora (talk) 21:55, 15 November 2018 (UTC)

Voting

  • Support Support --Tohaomg (talk) 18:30, 16 November 2018 (UTC)
  • Support Support Support as long as info(at)wikimedia.org isn't removed from anywhere. Vermont (talk) 21:26, 16 November 2018 (UTC)
  • Oppose Oppose I dislike the idea of shoving people off through a "knowledge tree" when all they want to do is report some vandalism. Many people who email into OTRS don't want to edit but they still report problems. That is only one example but I can think of many more where this will do more harm than good especially if this is something that is mandatory instead of a side link that can be explored. On top of that, even if we were to do this it is silly to take up time and resources of the WMF when this can be done by anyone that knows javascript (and has the proper rights to put the script into the mediawiki namespace). Not to mention the required maintenance that would have to be done as policy and consensus changes. This should simply be handled and maintained by the people who have the most invested in it, the people that want it most. That way it can be exactly what they want. --Majora (talk) 21:43, 16 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 08:08, 17 November 2018 (UTC)
  • Support Support Jc86035 (talk) 10:52, 17 November 2018 (UTC)
  • Support Support The English Wikipedia OTRS agents discussed this in the OTRS-en-l email list. Blue Rasberry (talk) 14:24, 17 November 2018 (UTC)
  • Support Support Ciell (talk) 17:44, 17 November 2018 (UTC)
  • Support Support Geoff Who, me? 22:25, 17 November 2018 (UTC)
  • Oppose Oppose For the reasons stated by Majora and Anachronist.PopularOutcast (talk) 00:52, 18 November 2018 (UTC)
  • Support Support Enthusiastic support. These guides should be much more widespread across all Wikis. It empowers people. Joalbertine (talk) 17:20, 18 November 2018 (UTC)
  • Oppose Oppose Maybe think about a way to make it a bit easier to create a step-by-step guide, interactive flowchart etc., but this can already be done even without using a scripting language like js. No coding is necessary at all. Implementing one such instance of a guide is not something that should be done by software developers. Please keep software and content strictly separate. --Vexations (talk) 21:08, 18 November 2018 (UTC)
  • Oppose Oppose I think this would be very hard to actually roll out and would be mired by many of the same cross community problems as we have seen with VE, Structured Discussions etc. It would sound nice in theory, but everyone wants something different out of it and before you know it, you are in years of development. —TheDJ (talkcontribs) 12:57, 19 November 2018 (UTC)

Tool for easy user buttons

Support Edit proposal/discussion

  • 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|}} Button Globe.png Coordinates
X hello Hello world Button bienvenido.png insert hello world
O speedy {{Delete}} Button tidyman.png 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)

Voting

Improve diff viewer - how it handles line breaks

Support Edit proposal/discussion

Discussion

  • I would add to the proposal that split/merged paragraphs should be detected correctly as well. --NaBUru38 (talk) 18:37, 7 November 2018 (UTC)
  • There was some work done on diffs in the past year or two and I'm not sure it ended up in the right spot. --Izno (talk) 20:28, 7 November 2018 (UTC)
    • That was WMDE Technical Wishes/Show text changes when moving text chunks, and as they describe in the page there, the related code is intensely complicated. I think this proposal and the new phab task are probably duplicates of phab:T7072. Quiddity (WMF) (talk) 00:00, 8 November 2018 (UTC)
      • Updated phab tickets section above.. I don't think the proposal is a duplicate, since the ticket you linked is not assigned to anybody, the community tech team can work on it. --Gryllida 00:06, 8 November 2018 (UTC)
        • Don't worry about things being assigned. If CommTech can take it on, we can change who is assigned. :) --Izno (talk) 23:49, 8 November 2018 (UTC)
    • Izno: moving paragraphs is better now (see link shared by Quiddity); however, this proposal is about edits which involve splitting a paragraph. --Gryllida 19:53, 17 November 2018 (UTC)
  • It's probably way beyond the scope of this proposal, but it'd be amazing if the diff view gained the ability to expand context above and below the displayed changes, ala GitHub's diff viewer. (This would be especially valuable for Pending Changes review. Turns out, to properly interpret someone else's changes can often require far more context than the existing changes view displays.) -- FeRDNYC (talk) 10:51, 17 November 2018 (UTC)

Voting

  • Support Support I can't understand why diff viewer still has many problems after all of these years. 4nn1l2 (talk) 01:03, 17 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 08:02, 17 November 2018 (UTC)
  • Support Support (as suggestor) hopefully this improves collaboration and edit review. :) Gryllida 08:08, 17 November 2018 (UTC)
  • Support Support Yeah, this is very hard to understand what actually changed. ‐‐1997kB (talk) 10:07, 17 November 2018 (UTC)
  • Support Support Libcub (talk) 10:44, 17 November 2018 (UTC)
  • Support Support Atsme📞📧 15:51, 17 November 2018 (UTC)
  • Support SupportThanks for the fish! talkcontribs 20:17, 17 November 2018 (UTC)
  • Support Support if it can be disabled in compare method of API. Iluvatar (talk) 20:42, 17 November 2018 (UTC)
  • Support Support The Diff viewer has been improved in the last years, but is still not very satisfactory. It can't handle split/merged paragraphs, and see also the proposal "Include section name in the diff" Megatherium (talk) 20:49, 17 November 2018 (UTC)
  • Support Support Tim Landscheidt (talk) 02:45, 18 November 2018 (UTC)
  • Support Support Galobtter (talk) 06:52, 18 November 2018 (UTC)
  • Support Support NMaia (talk) 10:28, 18 November 2018 (UTC)
  • Support Support — Draceane talkcontrib. 18:03, 18 November 2018 (UTC)
  • Support Support Benjamin (talk) 10:28, 19 November 2018 (UTC)
  • Support Support β16 - (talk) 11:04, 19 November 2018 (UTC)
  • Support Support Ahecht (TALK
    PAGE
    ) 16:33, 19 November 2018 (UTC)

Wikitext substitutions should work in ref and gallery blocks

Support Edit proposal/discussion

  • 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

Voting