Jump to content

Community Wishlist Survey 2021/Archive

Add links
From Meta, a Wikimedia project coordination wiki

This page is an archive for Community Wishlist Survey 2021 proposals that won't go on to the voting phase. Proposals may be archived for various reasons, including: the proposal is too vague, the idea is technically unfeasible, the problem has already been solved, an existing product team is already working on it, the proposal is a social/community change rather than a technical one, or the proposal is asking to remove features that WMF product teams have built.

Only members of the Community Tech or Community Relations teams should move proposals into or out of the Archive. If your proposal has been archived and there's still time before the voting phase starts, please continue the discussion on your proposal! You may be able to fix a problem with the proposal, and get it back in the survey. Once the voting phase starts on December 8, 2020, we can't move any proposals out of the Archive.

Cómo poder enviar mensajes

¿Cómo Volver A Mandar Mensajes Otra vez si se saturó solamente con Unefon ilimitado

Discussion

Add the special characters menu on the mobile visual editor

Request withdrawn Withdrawn by proposer (too many proposals)

  • Problem: The mobile browser version of the visual editor does not have the special characters menu of the full visual editor.
  • Who would benefit: Mobile visual editors.
  • Proposed solution: Add the special characters menu.
  • More comments:
  • Phabricator tickets:
  • Proposer: Keepcalmandchill (talk) 04:26, 17 November 2020 (UTC)[reply]

Discussion

Editing infos about hurricanes

NoN Unclear / incomplete proposal

Discussion

Add Better Bots

NoN Lacks a clear problem statement

Discussion

The right category for the photos

Withdrawn by proposer (too many proposals)

  • Problem: Linking the right category during the upload of a photo is not evident for all commonors. It will be ore easy to have a button in the category page to invite users to upload photos directly to the same category.
  • Who would benefit: any user navigating through photos and catgeories
  • Proposed solution: a new button in the category page to invite users to upload more photos into the category.
  • More comments:
  • Phabricator tickets:
  • Proposer: Yamen (talk) 13:24, 21 November 2020 (UTC)[reply]

Discussion

wikidata downloading

Discussion

we need to download wikidata for our organizational wiki. thanks a lot mobile:09381899129

Adding "shark", "environment", etc. to the stub type

NoN Proposes change that does not require engineering 한국어: 토막글 종류에 "상어", "환경" 등 추가하기

  • Problem: There are fewer types of stubs.
한국어: 토막글 종류가 적습니다.
  • Who would benefit: Editors
한국어: 편집자
  • Proposed solution: You can increase the stub type.
한국어: 토막글 종류를 늘리면 됩니다.

Discussion

grouping, labelling, tagging in watchlists

NoN Unclear/incomplete proposal

Discussion

From OSM to Wikidata

Withdrawn by proposer (too many proposals)

  • Problem: Many information are available on OpenStreetMap that can be imported into Wikidata and therefore benefit from the work done by OSM community. Currently it's very hard to export data from OSM and import it into Wikidata: besides the problem of licence that probably can be sorted it requires technical skills to export the data.
  • Who would benefit: All
  • Proposed solution: a tool to input a filter (e.g. schools in a specific town/country) and then export data that will be imported into Wikidata.
  • More comments:
  • Phabricator tickets:
  • Proposer: Yamen (talk) 13:33, 21 November 2020 (UTC)[reply]

Discussion

Allow viewing page history in the mobile app

NoN Proposes an existing feature

  • Problem: The mobile app has no option of viweing the edit history for a page.
  • Who would benefit: Mobile users.
  • Proposed solution: Allow page history to be viewable on mobile.
  • More comments: I really don't see any reason why the mobile would not include such a key function for editing.
  • Phabricator tickets:
  • Proposer: Keepcalmandchill (talk) 03:51, 17 November 2020 (UTC)[reply]

Discussion

CORRECTION: I'm wrong, please withdraw this proposal Keepcalmandchill (talk) 03:52, 17 November 2020 (UTC)[reply]

No problem. For the record keeping I'm going to archive this rather than delete the page. Best, MusikAnimal (WMF) (talk) 04:20, 17 November 2020 (UTC)[reply]

Expiratory entries in watchlists

NoN Proposes existing feature

  • Problem: I don't want to watch a page for the entirety of the universe.
  • Who would benefit: Anyone with the same problem
  • Proposed solution: Next to "watchlist" you can check a box if you want it to be automatically removed from your watchlist at a certain point in time.
  • More comments:
  • Phabricator tickets:
  • Proposer: HeartGlow30797 (talk) 14:43, 22 November 2020 (UTC)[reply]

Discussion

Create a mobile app

NoN Proposes an existing feature

  • Problem:
  • Who would benefit:
  • Proposed solution: wikipedia should have a app so that it will be easy and faster to use because so many people don't know about wikipedia because it a website not a app so let make to app so billions of people will have access to it on a moblie app just like google
  • More comments:
  • Phabricator tickets:
  • Proposer: JEFFERY WASHINGTON OMOCARO (talk) 21:40, 17 November 2020 (UTC)[reply]

Discussion

Have our own dictionary but with words that are not found in google dictionary

NoN Proposes existing project espoñol: Tener nuestro propio diccionario pero con palabras que no se encuentran en google diccionario

Discussion

COmo lo dije en el titulo

wikt:? — Draceane talkcontrib. 21:52, 29 November 2020 (UTC)[reply]

A new style for the webpage

NoN Unclear/incomplete proposal

Discussion

  • Hi Fredrich Mauro! Could you elaborate on the technical problem you're seeing? This proposal as written presents not a problem, but an opinion. What specifically about the mobile web site is old, and how do you envision it being fixed? We need you to be more clear so that voters know what they're voting for. You can learn more by reviewing our documentation on the proposal phase. I'm going to archive this proposal for the time being, but we can move it back once it's more clear. Thanks for participating, MusikAnimal (WMF) (talk) 00:37, 18 November 2020 (UTC)[reply]

Moving categories

NoN Requires community consensus

  • Problem: The non-mover and non-admin users are not allowed to move categories. Sometimes, they may wish to move a category to a new category due to error in category name or wrong category.
  • Who would benefit: All users.
  • Proposed solution: Let autoconfirmed and extended confirmed users to move categories.
  • More comments: All what's above.
  • Phabricator tickets:
  • Proposer: Empire AS (talk) 07:06, 22 November 2020 (UTC)[reply]

Discussion

Any Valid Information.

NoN Does not propose a technical change

Discussion

I want anyone to add their valid information at any Wikipedia pages. As long as their valid from any sources at all. If some users doesn't believe it's true. Then, that specific editor must provide their evidence from any valid source at all. So, then they can be added and not removed. So, can you accept then implement this suggestion? Please reply.

Please review the documentation before creating anymore proposals. Thank you, MusikAnimal (WMF) (talk) 01:19, 20 November 2020 (UTC)[reply]

Requests or Suggestions

  • Proposed solution: La place de position du bandeau d'informations internes serait plus adaptée ailleurs sur la page, en bas ou sous une autre forme, pour libérer le haut qu'il serait préférable de réserver au titre.
  • Proposer: Jeanlouis11170 (talk) 20:47, 17 November 2020 (UTC)[reply]

Discussion

Enable visual editing on the mobile app

Request withdrawn Withdrawn by proposer (too many proposals)

  • Problem: Visual editing is not possible on the mobile app.
  • Who would benefit: Mobile and visual editors
  • Proposed solution: Add visual editing as a feature of the mobile app.
  • More comments: Both the mobile app and visual editing are intended to make it easier to edit. But why haven't these two great things been incorporated into one?
  • Phabricator tickets:
  • Proposer: Keepcalmandchill (talk) 04:06, 17 November 2020 (UTC)[reply]

Discussion

Nope, not on the beta app. Keepcalmandchill (talk) 12:52, 17 November 2020 (UTC)[reply]
@Keepcalmandchill and @Strainu, the mw:Mobile visual editor is available to editors using a web browser (click the button shown in this screenshot), but not in the apps. Because of technical differences, I understand that it would have to be "a" visual editor, and not the same software that's used when you edit in a web browser. Creating the software would probably be a multi-year project. Whatamidoing (WMF) (talk) 01:32, 2 January 2021 (UTC)[reply]

Zoom article editing event creation link

NoN Requires community consensus

  • Problem: People lack opportunities to connect with others doing meaningful, factual things.
  • Who would benefit: Anyone looking to join others to make a difference. Democracies that depend on constituencies living in reality.
  • Proposed solution: On every article page, create a button that enables the user to create a Zoom virtual event for people to collaborate to improve that article. The event is then listed in a common event calendar searchable by date and article subject area.
  • More comments:
  • Proposer: John 14:23 (talk) 05:20, 27 November 2020 (UTC)[reply]

Discussion

  • @John 14:23: Thanks for your proposal. It would be up to the community to agree on the process and technologies to use for this type of problem. I am going to archive this proposal. Thank you again for participating in this survey! Harumi Monroy 00:14, 04 December 2020 (UTC)[reply]

Any Valid Informations.

NoN Does not propose a technical change

Discussion

Anyone who provides a valid information from any kinds of sources can be added or edited to the Wikipedia pages. As long as they;re true information. So, can you forward then accept then implement it? Please reply. — The preceding unsigned comment was added by EJY257 (talk)

Similar to your other proposal, this seems to be about changing the content of articles, which is something that is not done through the Community Wishlist Survey. Please seek assistance from your local wiki, if needed. You can learn more about the Survey by reading our documentation. Thanks, MusikAnimal (WMF) (talk) 20:54, 18 November 2020 (UTC)[reply]

Traduceri Notițe

NoN Outside the scope of Community Tech

  • Problemă: Imposibilitatea editării notelor și traducerii automate a template-urilor.
  • Cine ar beneficia: Toți editorii wiki + vizitatorii paginilor deoarece ar crește gradul de corectitudine.
  • Soluția propusă: Repararea acestora.
  • Mai multe comentarii: -
  • Ticket Phabricator:
  • Propunător: Dairrow (talk) 18:43, 18 November 2020 (UTC)[reply]

Discuție

Give reason when reverting edits

Original title: Every edit done by me was reverted by someone without knowing the fact whether I added the value to article or not, Such monopoly should be stopped for betterment of Wikipedia. NoN Proposes a social/policy/licensing change rather than a technical feature

  • Problem: Edits on Wikipedia are reverted by auditors, that discourages the editors for further edits.
  • Who would benefit:
  • Proposed solution: Every edit's revert should be given a reason so that the editor's feelings does not get hurt.
  • More comments:
  • Phabricator tickets:
  • Proposer: Darshan Singh knl (talk) 11:07, 22 November 2020 (UTC)[reply]

Discussion

No unregistered users

NoN Proposes a social/legal change rather than a technical feature

Discussion

  • Requiring account registration goes against the founding principles of Wikimedia. As such I'm archiving this proposal. Thanks for participating.
español: Requerir el registro de una cuenta va en contra de los principios fundacionales de Wikimedia. Como tal, estoy archivando esta propuesta. Gracias por participar, MusikAnimal (WMF) (talk) 19:47, 30 November 2020 (UTC)[reply]

Add dark mode for desktop website.

NoN Declined in a previous survey

  • Problem: No Dark mode for web app (PC)
  • Who would benefit: The readers as your eyes dont
  • Proposed solution: Add dark mod in the settings (Web Wikipedia)
  • More comments: None, thank you
  • Phabricator tickets:
  • Proposer: Unieo: Mikhail's Unieo (talk) 05:21, 23 November 2020 (UTC)[reply]

Discussion

All As "Edit" Only.

NoN Does not propose a technical change

Discussion

All of the Wikipedia pages will have the "Edit" button. There won't be anymore "View Source" button anymore in the future. So, anyone can edit and/ add any valid information at all or any Wikipedia pages. So, can you forward then accept then implement this suggestion? Please reply. — The preceding unsigned comment was added by EJY257 (talk)

Hi EJY257! It sounds like you're asking all pages to be unprotected. The protection of pages is up to local administrators. The Community Wishlist Survey is for proposing technical changes and new features. We do not handle administrative duties of wikis. For this reason I'm archiving this proposal, but thanks for participating nonetheless! MusikAnimal (WMF) (talk) 20:50, 18 November 2020 (UTC)[reply]

Admins

NoN Proposes social change and/or opinion

Discussion

Wikipedia administrators should be scientists and specialists, not gamers with inflated subjective self-importance and violating the Wikipedia Rules. They consider themselves the masters of Wikipedia, although banging on the keyboard quickly is just a skill. Konstantine Gunin (talk) 09:27, 26 November 2020 (UTC)[reply]

Adding a reference

NoN Not a proposal

Discussion

I wish somehow someone will add the following to the References section of the Wikipedia article on Louis Harold Gray. It’s clear from my bungled efforts that I can’t do it. Thanks. That’s all. O Underwood

Wynchank, Sinclair (2017). Louis Harold Gray, FRS: A Founding Father of Radiobiology. London, England: Springer International Publishing. ISBN 978-3-319-43396-7. OSUnderwood (talk) 09:49, 22 November 2020 (UTC)[reply]

Please edit the article directly or request edits be made on the talk page. This is the Community Wishlist Survey. We don't make content changes through this process. MusikAnimal (WMF) (talk) 19:56, 22 November 2020 (UTC)[reply]

NoN Does not require engineering resources / out of scope

  • Problem: There are not enough links on the encyclopedia pages. Please consider adding more links
  • Who would benefit: The Users
  • Proposed solution: The Users should add more links like links of the meanings of words that are difficult.
  • More comments:
  • Phabricator tickets:
  • Proposer: Saregamapadhanisa (talk) 09:30, 21 November 2020 (UTC)[reply]

Discussion

text to speech

NoN Proposes existing solution

  • Problem: More than 95% of the content in Wikipedia is in text format and needs to be read.
  • Who would benefit: Almost everyone! However, people with poor vision will benefit the most.
  • Proposed solution: Almost all cloud providers offer Text to Speech conversion API. In addition, there are many free libraries are available that do Text to Speech.
  • More comments:
  • Phabricator tickets:
  • Proposer: Ssathya (talk) 21:51, 19 November 2020 (UTC)[reply]

Discussion

Take a look to mw:Extension:Wikispeech -Theklan (talk) 09:34, 20 November 2020 (UTC)[reply]

Searching of words in the page

  • Problem:
  • Who would benefit:
  • Proposed solution: There should be an option by which we can search for a keyword we are looking for in the page. This helps us in saving time.
  • More comments:
  • Phabricator tickets:
  • Proposer: Excellenc1 02:50, 17 November 2020 (UTC)[reply]

Discussion

Quién se beneficiaría

NoN Lacks a clear problem statement

Discussion

la sintaxis de las entradas podría ser más limpia y más similar al resultado final. Mi meta es mejorar wikipedia para ser una pagina que podamos buscar cualquier cosa y encontrar resultados verdaderos no como brainly.lat porque hay uno puede hacer cualquier cosa con preguntas y respuestas. Les dejo mi propuesta: pueden mejorar mejor calidad , no errores, una portada limpia. Mi meta es poder desarollar una mejor pagina que se pueda utilizar bien

Dynamic Spidergram

NoN Unclear / incomplete proposal

Discussion

Add a tutorial

  • Problem: For people who want to make their own documentary on something but they are new to it and want to add things, but they don't know how to.
  • Who would benefit: It would benefit beginners and people who don't know how to edit.
  • Proposed solution: Like on the programming on khan academy, there should be videos explaining how to do something, while at the same time you can interact with it.
  • More comments: I understand there are youtube videos of this but if you like editing at school, I think it's a great solution.
  • Phabricator tickets:
  • Proposer: Apersonthing3000 (talk · contribs) 23:47, 22 November 2020

Discussion

  • @Apersonthing3000: Thanks for the proposal! This sounds like a great idea, but it's a content-editing project, rather than something that requires technical software development work, and as such is out of scope for the wishlist. Commons supports the uploading of videos, and they can be displayed wherever required on the wikis. As this is a non-technical proposal, I'll archive it. —Sam Wilson 07:50, 23 November 2020 (UTC)[reply]

College Football Template

NoN Proposes a social change rather than a technical feature

  • Problem: When editing the page of an American football coach the colors of his or her teams are always displayed (even college teams) throughout the NFL player or coach template, however when it comes to the college football template it will not show any NFL team colors throughout
  • Who would benefit:
  • Proposed solution: I propose that the 32 NFL teams are added to the college football template, for when a college coach spend a year or two in the NFL
  • More comments:
  • Phabricator tickets:
  • Proposer: Bigmike2346 (talk) 23:49, 17 November 2020 (UTC)[reply]

Discussion

  • @Bigmike2346: Hi! This does not require engineering resources from developers. Simply update the template yourself as desired or contact maintainers of that template to make the changes for you. For this reason I'm going to archive this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 00:04, 18 November 2020 (UTC)[reply]

Recommendation for Survey instructions

NoN Not a technical proposal

  • Problème:
  • Qui en bénéficierait:
  • Solution proposée: Ce point fondamental doit être mis au tout début de la présentation/page : "La proposition doit concerner une modification technique et non une politique ou une modification sociale"
  • Autres commentaires:
  • Tâches sur Phabricator:
  • Proposant: Tifroumi (talk) 14:44, 20 November 2020 (UTC)[reply]

Discussion

  • Translation: This fundamental point must be put at the very beginning of the presentation / page: "The proposal must relate to a technical modification and not a policy or a social modification". Quite frankly I agree! We can add something like this to the edit intro. Thanks for the suggestion, though for future reference you can use the talk page for this rather than create a proposal. MusikAnimal (WMF) (talk) 19:51, 30 November 2020 (UTC)[reply]

Allow watermarks on photos if requested by the content owner.

NoN Proposes existing solution

  • Problem: I have lost original work (Kodachrome transparancies) but would still like to use my photos here.
  • Who would benefit: People in my position who have digitized work but are missing original content.
  • Proposed solution: 1. Change policy to allow usage; or 2. Supply a watermark-removal service.
  • More comments:
  • Phabricator tickets:
  • Proposer: BrettA343 (talk) 23:52, 20 November 2020 (UTC)[reply]

Discussion

Wikipedia Live Videos

NoN Proposal is very broad, out of scope, and may require consensus

  • Problem: We should be able to see live footage of things (ex: Hurricanes, tropical storms, tornados, e.t.c ).
  • Who would benefit: Users and Editors.
  • Proposed solution: Make Live footage.
  • More comments:
  • Phabricator tickets:
  • Proposer: Avishai11 (talk) 17:15, 19 November 2020 (UTC)[reply]

Discussion

  • There is no infrastructure to allow for live video feeds, and I'm afraid inventing this may be too out of scope for this survey. Regardless, we don't have reporters on the ground working for us, rather content is written by volunteers based on previously released sources. Live video feeds could also be abused; e.g. start with a video of the tornado and turn into something inappropriate. For this reason it may require broader consensus before implementing this technology. As such I'm going to archive this proposal, but thank you for participating in the survey! MusikAnimal (WMF) (talk) 20:42, 19 November 2020 (UTC)[reply]

Antworten auf Diskussionen via mobiler Webseite

  • Problem: Wenn man auf einer Diskussionsseite in mobiler Ansicht antwortet und sich nicht im Wikitext-Modus befindet, dann werden Antworten nicht eingerückt, sprich der zusätzliche Doppelpunkt wird nicht gesetzt. Dieser Bug dürfte sich vermutlich schnell lösen lassen.
  • Who would benefit:
  • Proposed solution:
  • More comments:
  • Phabricator tickets:
  • Proposer: --Smarti (talk) 18:06, 16 November 2020 (UTC)[reply]

Discussion

Tracked in Phabricator:
Task T267813

תרגום - לא ניתן לתרגם פרקים ולהעביר אותם לערך קיים בעזרת ויקיפדיה תרגומים

NoN On roadmap of another team

Discussion

Механизм удаления аккаунтов

  • В Википедии и других википроектах много неактивных участников и бессрочников,аккаунты которых не имеют смысла.Предлагаю для решения это проблемы создать механизм удаления аккаунтов:
  • Дополнительные комментарии:
  • Ссылка на задачу в Фабрикаторе:
  • 'Создал: GAZ1979 (talk) 17:12, 17 November 2020 (UTC)[reply]

Обсуждение

More access to things

NoN Incomplete / unclear proposal Magyar: több hozzáférés dolgokhoz

  • Problem: little access to things
    Magyar: kevés hozzáférés dolgokhoz
  • Who would benefit: Hungarian accesses
    Magyar: magyar hozzáférések
  • Proposed solution:---
  • More comments:
  • Phabricator tickets:
  • Proposer: Koch1991 (talk) 17:14, 17 November 2020 (UTC)[reply]

Discussion

  • @Koch1991: Thanks for your proposal. Could you please elaborate further on what you want to achieve? As it stands there isn't enough information here to act on. Thanks! (Sorry for posting in English.) Sam Wilson 02:02, 18 November 2020 (UTC)[reply]
  • I'm going to archive this proposal for the time being. Once the problem statement is made more clear we can move it back. Thanks for participating in the survey.

    Magyar: Egyelőre archiválni fogom ezt a javaslatot. Amint a problémameghatározás világosabbá válik, visszahelyezhetjük. Köszönjük, hogy részt vett a felmérésben. MusikAnimal (WMF) (talk) 23:32, 19 November 2020 (UTC)[reply]

Suivi que d'une partie d'un article

  • Problème: Pouvoir suivre qu'une partie d'un article
  • Qui en bénéficierait: Tous les utilisateurs de Wikipédia
  • Solution proposée: Ajouter un lien de suivi au niveaux des sections de l'article
  • Autres commentaires: Sur des articles très long et souvent modifiés par les contributeurs, il est nécessaire de visualiser toutes les modifications effectuées les unes après les autres, afin de visualiser les changements intervenus dans les sections qui m'intéressent.
  • Tâches sur Phabricator:
  • Proposant: --13:47, 25 November 2020 (UTC)Thierry74 (talk)

Discussion

Video tutorials

NoN Does not propose a technical change

  • Problem: It is often very complicated for new users to edit or contribute despite the plethora of information that exists.
    (fr): Il est souvent très compliqué pour les nouveaux utilisateurs de comment éditer ou contribuer malgré la pléthore d'information qui existe.
  • Proposed solution: To help them quickly identify this, it would be appropriate to make video tutorials that show how to contribute in all languages and this automatically on the home page of new users.
    (fr): Pour les aider à cerner rapidement cela, il serait opportun de faire des tutoriels vidéos qui montrent comment contribuer dans toutes les langues et ce automatiquement sur la page d'accueil des nouveaux utilisateurs.
  • Proposer: --Ross.Patrick (talk) 06:09, 17 November 2020 (UTC)[reply]

Discussion

Rechtschreibprüfung (D)

NoN See Community Wishlist Survey 2021/Editing/Spellchecker

Diskussion

Dark Mode

NoN Declined in a previous survey

  • Problem: Wikipedia does always have white theme
  • Who would benefit: Everyone that want to save their eyes
  • Proposed solution: Create Dark Mode on whole Wikipedia page
  • More comments:
  • Phabricator tickets:
  • Proposer: Kindle Uzer (talk) 15:53, 19 November 2020 (UTC)[reply]

Discussion

  • This was the #2 wish in the 2019 survey. We investigated and even began work, and as much as we wanted to finish it we unfortunately had to stop due to some technical challenges and conflicts with the Desktop Improvements project. You can learn more by reading our status report. This is not to say dark mode won't happen some day; I think it definitely will, but I'm afraid it won't be from Community Tech. As such I'm going to decline this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 02:18, 18 November 2020 (UTC)[reply]

Editing through wikipedia mobile app

NoN Proposes existing feature

  • Problem: The Wikipedia app on google play is read-only. Users are not able to contribute by editing. Editing through mobile web browser is trouble to many people.
  • Who would benefit: The Wikipedia mobile app users
  • Proposed solution: Editing feature in the mobile app.
  • More comments: Editing through mobile web browser is trouble to many people. It would be better if editing feature is also available in the app.
  • Phabricator tickets:
  • Proposer: Huzaifa abedeen (talk) 03:35, 25 November 2020 (UTC)[reply]

Discussion

one-click removal from the watchlist

NoN Proposes existing feature

  • Problem: If you see a page on a watchlist you no longer want to watch it takes a 3 mouse clicks to remove it (click on the page, click to remove from the watchlist, click to return to the watchlist, plus time to find where you were)
  • Who would benefit: people who want to control their watchlist
  • Proposed solution: add a link "[remove from watchlist]" next to each item to allow quick removal
  • More comments:
  • Phabricator tickets:
  • Proposer: Jarekt (talk) 21:47, 20 November 2020 (UTC)[reply]

Discussion

Enlaces rojos

NoN Unclear/incomplete proposal

Discusión

Mi idea es rapida y sencilla aunque no se podria llevar a la practica es crear bots para identificar enlaces rojos utiles de aquellos que no lo son y eliminar los que no lo son y poner enlaces rojos para paginas que si se podrían crear nuevas paginas utiles para la comunidad y los lectores anonimos,esto benefeciaria a ciertos articulos en todos los idiomas llenos de estos enlaces faltos de utilidad y pondria estos enlaces posibilitando la creacion de nuevos articulos utiles para tod@s esa es mi idea para mejorar wikipedia protente Dr.Mas20

ejercicios para desarrollar en medio de un articulo

NoN Proposes existing solution

  • Problema: comprensión de explicaciones en algunos temas, por ejemplo matemáticas, idiomas, alimentación, programación, etc..
  • A quiénes beneficiaría: principalmente a estudiantes y personas con curiosidad sobre un el tema.
  • Solución propuesta: añadir ejercicios dinámicos en el articulo después de la explicación, de manera que el lector pueda intentar resolverlo y pueda confirmar la solución una vez realizado el intento, y así poder conocer por si mismo su comprensión de lo explicado.
  • Más comentarios: pienso que simplemente se pueden añadir ejercicios de algunos libros de texto o de otras páginas web.
  • Informes de Phabricator:
  • Proponente: Dairo Quintero Vargas.

Discusión

Wikipedia API

NoN Unclear proposal

  • Problem: it isn't too easy to develop new bots for Wikipedia.
  • Who would benefit: the community, the readers, the editors and the programmers.
  • Proposed solution: creating a Wikipedia Developer Platform just like Twitter has a Twitter Development. Creating an API that gives easy access to Wikipedia.
  • More comments: No more comments.
  • Phabricator tickets:
  • Proposer: Albin Schmitt (talk) 22:57, 18 November 2020 (UTC)[reply]

Discussion

Single out the content translation module

Withdrawn by proposer (too many proposals)

  • Problem: Content translation module needs to be activated in beta features per wiki, and is definitely problematic considering the code to be the same across multiple languages. Also, this is limited to Wikipedia when the module can be used in multiple occasions (e.g. wikiversity)
  • Who would benefit: Anyone who would need to use this module + wikipedia(and other projects') event participants
  • Proposed solution: Turn the current translation module into a standalone website/product (i.e. translate.wikimedia.org), and let it import pages from any Wikimedia sites and export it at any sites' user namespace
  • More comments: I suppose the whole thing needs to be manually checked considering the whole controversy behind the "bad translation" thing due to bad moderation that can be done(external force nonexistent). Thus, I suggest turning off the export to mainspace and restrict it to only export on user namespace unless the community had a thereshold to open it.
  • Phabricator tickets:
  • Proposer: 1233 （T / C） 06:01, 19 November 2020 (UTC)[reply]

Discussion

Wikiübergreifende Beobachtungsliste

NoN In Entwicklung

  • Problem: Wenn man Seiten in verschiedenen Wikis beobachtet (WikiCommons, Wikidata, en.wikipedia, de.wikipedia usw), fällt es schwer, den Überblick über alle Beobachtungslisten zu behalten.
  • Wem würde dieser Wunsch helfen: Benutzern, die in mehreren Wikis tätig sind.
  • Lösungsvorschlag: Eine Gesamt-Beobachtungsliste, in der die Änderungen von beobachteten Seiten aus allen Wikis zusammengefasst wird.
  • Weitere Kommentare:
  • Phabricator-Tickets:
  • Antragsteller: Grullab (talk) 10:58, 17 November 2020 (UTC)[reply]

Diskussion

Rich search suggestions for desktop

  • Problem: Search on the mobile website displays suggestions that include the Short Description and a thumbnail image. The search on the desktop website does not.
  • Who would benefit: All users of the desktop website
  • Proposed solution: Update the search on the desktop website to display the same rich suggestions as the search on the mobile website.
  • More comments:
  • Phabricator tickets:
  • Proposer: — GhostInTheMachine talk to me 17:09, 25 November 2020 (UTC)[reply]

Discussion

This is already being worked on as part of the Desktop Improvements project. the wub "?!" 17:33, 30 November 2020 (UTC)[reply]

GhostInTheMachine, hello and thank you for submitting this proposal! Since this is already being worked on as part of the Desktop Improvements project, we will be archiving this wish. You can follow this feature request via the Desktop Improvements project. Thank you! IFried (WMF) (talk) 00:08, 3 December 2020 (UTC) [reply]

Centralization of templates

NoN Outside the scope of Community Tech

  • Problem: Projects use similar templates but without joining the efforts of its developers in the different languages and above all this system is preventing the harmonization of the content. Although Wikidata has made it possible to do a some links, it is rare to align with templates from other projects.
  • Who would benefit: Everyone, especially developers and translators.
  • Proposed solution: Create a common meta space where all templates would be centralized and used independently of the project.
  • More comments: This has to be one of the biggest challenges of the projects for the years to come. Centralizing templates would allow the different language versions to evolve more jointly. This will also greatly facilitate translations. Without forgetting the concerns on licenses when copying the templates to another project.
  • Phabricator tickets:
  • Proposer: Baidax (talk) 16:55, 30 November 2020 (UTC)[reply]

Discussion

Return to default table sorting

NoN Proposes existing feature

  • Problem: When sorting wikitable sortable, the sorting order is changed by the selected column. If there is no numbered column (e.g. 1-2-3-4…), a page reload is the only way to return to the default sorting.
  • Who would benefit: Readers
  • Proposed solution: Add a button to the corner of the table that would reset the table to the default sorting.
  • More comments:
  • Phabricator tickets:
  • Proposer: — Draceane talkcontrib. 21:34, 29 November 2020 (UTC)[reply]

Discussion

Add more machine translators to the translation editor

NoN Proposes existing feature and financial/licensing change

  • Problem: The only machine translator available is the Google one, which is imperfect in many ways (can't handle dates very well, for example).
  • Who would benefit: Translators.
  • Proposed solution: Add more translation software options, such as Bing or Yandex translators.
  • More comments: This is of course not relevant to English Wikipedia. But it would be important for other languages, especially since Google Translate is most useful in English translation.
  • Phabricator tickets:
  • Proposer: HappyMihilist (talk) 16:09, 18 November 2020 (UTC)[reply]

Discussion

ブロック期間。

NoN Proposes a social/policy change rather than a technical feature

  • 問題点: 明らかに間違っていることを書く者、嫌がらせをする者はブロックし、少なくとも数ヶ月か半年か.....長期間利用できないようにするのがいいと思います。wikipediaさんが現在どれだけの期間、利用できなくなるのかあまり調べていませんが。気になったので書かせていただきます。こういう人たちにいちいちかまうのは、かなり時間を無駄にしていると思いますので。ブロックすることを決めているのは一部の方々だと思いますが。その方々が不憫です。
  • 誰の役に立つか: ブロックすることを決めている方々。
  • 提案された決議:
  • その他のコメント:
  • Phabricator チケット:
  • 提案者: Taroukotarou (talk) 21:24, 17 November 2020 (UTC)Taroukotarou[reply]

議論

  • This proposal seems to be political or asks to change social behaviour on one or more projects. The Wishlist Survey is for requesting technical changes and improvements to the software you use. We can't help with the issue you speak of here. Regards, MusikAnimal (WMF) (talk) 17:22, 1 December 2020 (UTC)[reply]

CommunityCare

NoN Proposes a social/policy change rather than a technical feature

  • Problem: Die deutschsprachige Wikipedia verliert seit Jahren engagierte User. Diese werden völlig alleine gelassen und ihnen kann unter dem aktuellen Gruppendruck nicht einmal mehr von Freunden und Kollegen Hilfe angeboten werden.
  • Wem würde dieser Wunsch helfen: Es geht darum, dass das editieren wiederum Spass macht und das Grundprinzip von NPOV wiederum zur vollten Geltung gebracht werden kann.
  • Lösungsvorschlag: In Sperrverfahren bekommen die ausgeschlossenen AUTOMATISCH eine (professionelle, WMDE, WMAT, WMDE finanzierte (Wikimedia 2030 Ziel: Inklusion) und mit entsprechenden Kompetenzen ausgestattet) "Pflichtverteidigung" zur Seite gestellt.
  • Weitere Kommentare: Wir haben bei WikiDienstag.ch eine Definition zu #CommunityCare entwickelt, welche 3 Punkte umfasst:
  1. To be a Party Host and
  2. To be a Traffic Cop (Not Police Officer).
  3. Always be a Full-time Enabler

Diskussion

Disallow IP editing on Meta

NoN Requires community consensus and/or legal approval

  • Problem: Currently IPs are allowed to edit on Meta as well as on other WMF projects. One could make a case for allowing IP editing on content building WMF projects where some editors occasionally want to make a few edits without registering an account. But nobody comes to edit here on Meta without knowing exactly what they are doing. The practice of allowing IPs to edit on Meta only serves to enable sockpuppetry, block evasion and straightforward vandalism.
  • Who would benefit: Everybody.
  • Proposed solution: We should require mandatory account registration for editing on Meta. Or, at a minimum, have a rule that IPs are not allowed to participate in any Meta RfCs and other polls.
  • More comments:
  • Phabricator tickets:
  • Proposer: Nsk92 (talk) 21:15, 17 November 2020 (UTC)[reply]

Discussion

  • This is just a configuration change. No engineering is required for this to happen, so it doesn't need to go through the wishlist. All it needs is community consensus and possibly also approval from WMF legal. If you wanted to disallow contribs from IPs to RfCs, that can probably be achieved using AbuseFilter, but again it would need consensus. For these reasons I'm going to archive this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 21:28, 17 November 2020 (UTC)[reply]

Thanking unregistered users

NoN Needs consensus / conflicts with privacy enhancement project

  • Problem: Not being able to thank an unregistered user
español: No poder agradecerle a un Usuario No Registrado.
  • Who would benefit: Unregistered users
español: Los usuarios No Registrados.

Discusión

español: De hecho, no se llegó a un consenso sobre cómo manejar esto en el pasado. Independientemente, no deberíamos intentar implementarlo en este momento porque entra en conflicto con IP Editing: Privacy Enhancement and Abuse Mitigation. Por eso voy a archivar esta propuesta, ¡pero gracias por participar en la encuesta! MusikAnimal (WMF) (talk) 22:51, 23 November 2020 (UTC)[reply]

Dark theme

NoN Declined in a previous survey

Discussion

[User: PittsburghPlays] - Definitely a feature they should add. Been waiting for years!

  • This was the #2 wish in the 2019 survey. We investigated and even began work, and as much as we wanted to finish it we unfortunately had to stop due to some technical challenges and conflicts with the Desktop Improvements project. You can learn more by reading our status report. This is not to say dark mode won't happen some day; I think it definitely will, but I'm afraid it won't be from Community Tech. As such I'm going to decline this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 02:18, 18 November 2020 (UTC)[reply]

Sandbox shortcut in Simple English, Yoruba Wikipedia,Meta with others

NoN Proposes an existing feature

  • Problem: Provision of sandbox sidebar in simple English Yoruba Wikipedia Meta and others
  • Who would benefit: All users will benefit due they will be able to navigate around easily to their sandbox.
  • Proposed solution: Addition of sandbox in the sidebar.
  • More comments:
  • Phabricator tickets:
  • Proposer: Tbiw (talk) 21:58, 17 November 2020 (UTC)[reply]

Discussion

The sidebar can be customised per-wiki by editing MediaWiki:Sidebar. A more general suggestion that may be relevant is Community Wishlist Survey 2021/Miscellaneous/Customizable sidebar. H78c67c (talk) 07:09, 18 November 2020 (UTC)[reply]

There's already mw:Extension:SandboxLink which adds a link to the current user's sandbox to the personal tools menu (same menu that has links to user/user talk pages and preferences, for example) that can be enabled on any wiki that requests it. Majavah (talk!) 07:56, 18 November 2020 (UTC)[reply]

В Википедии добавить кнопочку для гуглоперевода статьи.

  • Проблема: не все статьи есть на родном языке, много времени уходит чтобы перевести
  • Кто выиграет: читатели
  • Предлагаемое решение: встроить автоперевод - добавить кнопочку для гуглоперевода статьи
  • Дополнительные комментарии:
  • Ссылка на задачу в Фабрикаторе:
  • Предложил(а): denis_73 (talk) 20:37, 17 November 2020 (UTC)[reply]

Обсуждение

В каждом броузере уже есть такая функция. Воспользуйтесь ей. SSneg (talk) 21:39, 20 November 2020 (UTC)[reply]
denis_73, Спасибо, что отправили это желание! Мы храним это желание, потому что оно выходит за рамки. Однако мы рекомендуем вам взглянуть на это. Вам может быть интересно: https://www.mediawiki.org/wiki/Content_translation IFried (WMF) (talk) 21:12, 3 December 2020 (UTC)[reply]

Make wiki easier for most people

NoN Proposal too broad / out of scope

  • Problem: A lot of things are complicated and nerdy requiring a lot of knowlegde about the system
  • Who would benefit:
  • Proposed solution: A user interface which is more friendly to people who do not know a lot about all the nerdy stuff. Clean up clutter, less is more. Cleaner menues, better visuals.
  • More comments:
  • Phabricator tickets:
  • Proposer: Raven rs (talk) 01:16, 18 November 2020 (UTC)[reply]

Discussion

  • Hi Raven rs! While I think many people will agree there is a learning curve to MediaWiki, this proposal does not do much beyond broadly stating the problem. In the Wishlist Survey, we ask you to present specific problems and (ideally) specific solutions that can be tackled reasonably by our team. This proposal as written is much too broad. Redesigning the whole system does not fit within our scope. You can learn more about the survey by reading the documentation. For now I'm going to archive this proposal, but if you have more specific and smaller ideas to improve MediaWiki, please clarify and we can move your proposal back. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 04:04, 18 November 2020 (UTC)[reply]

سلام

Bonjour et ne sois pas fatigué Apprenez du code à utiliser qui est très important

Autorize OpenDocument import

NoN Requires community consensus

  • Problem: Actually, it's autorized to import : tiff, tif, png, gif, jpg, jpeg, webp, xcf, mid, ogg, ogv, svg, djvu, stl, oga, flac, opus, wav, webm, mp3, midi, mpg, mpeg.
  • Who would benefit: All
  • Proposed solution: WikiCommons could autorize OpenDocument filetype.
  • More comments:
  • Phabricator tickets:
  • Proposer: ComputerHotline (talk) 07:46, 17 November 2020 (UTC)[reply]

Discussion

See c:Commons:Project_scope#PDF for the policy. On Wikisource PDF and DjVu is used only from scans and then the text improved. There is no need for that with OpenDocument. Also in the policy it states that text only files are not permitted (you would copy the text to an wikipage, if it is out of copyright, in that case).--Snaevar (talk) 23:12, 28 November 2020 (UTC)[reply]

Remove (very) old entries from the block log

NoN Requires community consensus

  • Problem: At face-value a user's block log can be used to the detriment of on an editor.
  • Who would benefit: Everyone to avoid time-sinks debating the behaviour of an editor who made mistakes in the past, but has improved.
  • Proposed solution: Much like penalty points for driving (in the UK), older blocks should be expunged from the log after a sufficient amount of time has passed (5, 8, 10 years??)
  • More comments:
  • Phabricator tickets:
  • Proposer: Lugnuts (talk) 14:57, 28 November 2020 (UTC)[reply]

Discussion

Administrators can hide log entries. You have to discuss the wish in your local community. Technically nothing can be done here.--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 15:10, 28 November 2020 (UTC)[reply]
  • I don't think it's possible to automatically hide old log entries right now, but it seems extremely unlikely this would get implemented as it's contrary to the open principles of MediaWiki. Regardless, each community would have to make that decision for themselves. I'm going to archive this proposal as needs consensus. Thanks for participating, nonetheless! MusikAnimal (WMF) (talk) 15:42, 28 November 2020 (UTC)[reply]

searching categories on commons

NoN Same as Community Wishlist Survey 2021/Categories/Display categories before pages

  • Problem: When typing to search field in comons, suggester suggest names of files and galleries, but not categories. ALso after search there are in results on the first place galeeries and then files. Categories are on the n-th page, when there are more than 20 results
  • Who would benefit: All users who search images for known thema with more images
  • Proposed solution: add option to include categories in basic search
  • More comments:
  • Phabricator tickets:
  • Proposer: JAn Dudík (talk) 21:29, 24 November 2020 (UTC)[reply]

Discussion

  • Possibly this is just something that needs a change of the default configuration. At the moment you have to click on 'search categories' to see the category search results; that could become the default, or a mix of categories/files/galleries could be the default. Searching categories should work a lot better now that the infobox is in so many categories (particularly for multilingual search). Thanks. Mike Peel (talk) 08:32, 27 November 2020 (UTC)[reply]
  • Categories are included in the default search, they just come last so you may never see them. Display categories before pages seems to propose the same thing, so I'm going to archive this wish in favour of that one. Hope this is okay :) MusikAnimal (WMF) (talk) 01:00, 3 December 2020 (UTC)[reply]

Einspruchsmittel gegen Administratorwillkür

NoN Proposes a social/policy change rather than a technical feature

  • Administratoren agieren selbstherrlich wie Gutsherren und kleine Könige, gegen ihre Entscheidungen sind keine Einspruchsmöglichkeiten und Rechtsmittel vorhanden:
  • Allen einfchen Mitgliedern außerhalb der Wiki-Hierarchie:
  • Strafmaßnahmen durch Administratoren und andere Funktionsträger mit erweiterten Rechten bewirken die Einblendung einer »Einspruch«Schaltfläche. Die Einsprüche werden direkt zu einem in jedem Wiki zu schaffenden Gremium weitergeleitet, das personell nicht mit der Administratorenhieraerchie verbunden ist. Der Wechsel von Personen zwischen beiden Gremien wird konsequent ausgeschlossen. Administratoren werden zusätzlich rechenschaftspflichtig, ihre Amtszeit und Wiederwählbarkeit wird begrenzt. Die Einsprüche werden in der Sprache des Gemaßregelten abgehandelt. Unbefristete Maßregelungen werden abgeschafft. Administratoren, die ihre erweiterten Rechte missbrauchen, riskieren ihrerseits eine Sperrung, in schweren oder wiederholten Fällen den Ausschluss. Maßnahmen gegen Administratoren werden öffentlich gemacht.:
  • Weitere Kommentare:
  • Phabricator-Tickets:
  • Antragsteller: Falk2 (talk) 12:27, 29 November 2020 (UTC)[reply]

Diskussion

accents for foreign languages and names

NoN Proposed existing feature

  • Problem: When typing in names that have various types of accents over individual letters, there is no simple way to get an accent.
  • Who would benefit: Newer editors creating or expanding pages.
  • Proposed solution: Create a choice of symbols. In Microsoft word I can just go to symbols and there are many accents to choose from. In microsoft word I can go to "symbols" and choose from many.
  • Phabricator tickets:
  • Proposer: ~SallystantonsaundersSallysstantonsaunders (talk)

Discussion

Searching for the intersection of articles

NoN Proposes existing solution

  • Problem: Trying to find articles that share or don't share a relationship (articles sharing category A and category B; articles linking to both article A and article B; articles using template A and template B; articles using category A, category B, but not category C; etc.).
  • Who would benefit: Those exploring/browsing wikipedia, but also those looking for inconsistencies or gaps across defined topic areas, categories, and pages without appropriately assigned topic areas/categories.
  • Proposed solution: Method to see attributes of an article and/or attributes of a second article, select/deselect these attributes, and allow the user to search for articles with similar intersections (an 'intersection' meaning containing the same selected and deselected attributes). I believe Advanced Search allows for this in some ways, but not in such a manner where it self-populates the attributes of an article for you in order to assist the user in query building further.
  • Phabricator tickets:
  • Proposer: Engineerchange (talk) 05:10, 18 November 2020 (UTC)[reply]

Discussion

Name people without accounts "Guests"

NoN Already in progress

  • Problem: If you are not logged in, and you try to edit a page, it says that it will share your IP address. Not only is this annoying, but it is invasive for privacy.
  • Who would benefit: Anyone who is edits and does not have a account
  • Proposed solution: Name people without accounts "Guest", then a unique number. This will remove the problem as it will not share the IP addresses, and it allows moderators to track down vandalism with the number.
  • More comments:
  • Phabricator tickets:
  • Proposer: BCM28 (talk) 15:37, 17 November 2020 (UTC)[reply]

Discussion

OCR tool

NoN Already in road map for Community Tech team

Discussion

Contributions from under-resourced countries

NoN Proposes a social/policy change rather than a technical feature

  • Problem: Many countries have limited resources available to support creating and improving articles on Wikipedia, with few newspapers and the like having archives readily available online, etc.
  • Who would benefit: Any one trying to contribute from most of the world.
  • Proposed solution: After I have spent many hours crafting an article from the meagre resources available, DO NOT delete it or object to it or anything like that, just because it does not meet the extreme standards of the very few massively rich countries with infinite resources available online for free. This is why Wikipedia is so heavily biased towards content about well-resourced countries. Otherwise, it is completely pointless that I waste my time trying to improve Wikipedia. Of course, it will be fantastic if instead of complaining about the lack of references, you were to fund the Wikipedia contributors to go and seek out the needed references in the paper-based archives in countries lacking massive online archives of everything.
  • More comments:
  • Phabricator tickets:
  • Proposer: Drackles (talk) 22:13, 26 November 2020 (UTC)[reply]

Discussion

What is the right venue?

Dark color theme

NoN Declined in a previous survey

Wikibooks project in French with dark color theme.
  • Problem: Colors of wikimedia projects are white or near white, which on long view time causes damage to eyes, and consume more energy on laptop.
  • Who would benefit: Everyone
  • Proposed solution: Add a preference to activate a dark color theme for desktop/laptop computer.
  • More comments: This preference should activate an alternative stylesheet with dark colors for every wiki elements. And colors used in pages and templates should use alpha components to appear differently on white and dark background color.
  • Phabricator tickets:
  • Proposer:  ◄ David L • talk ► 08:05, 20 November 2020 (UTC)[reply]

Discussion

  • This was the #2 wish in the 2019 survey. We investigated and even began work, and as much as we wanted to finish it we unfortunately had to stop due to some technical challenges and conflicts with the Desktop Improvements project. You can learn more by reading our status report. This is not to say dark mode won't happen some day; I think it definitely will, but I'm afraid it won't be from Community Tech. As such I'm going to decline this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 20:04, 20 November 2020 (UTC)[reply]

To be able to delete small sized articles

  • Problem: Whenever I move an article, old page redirects to the renamed article. And if old and new names of the page are unrelated, we have to delete the old one. It is frustrating to consult a authorized person everytime we do this. It would be good if at least extended confirmed users could delete small sized pages.
  • Who would benefit: User who don't have extensive authorities and therefore cannot delete pages.
  • Proposed solution: Users who have at least some experience should be able to delete small sized pages.
  • More comments:
  • Phabricator tickets:
  • Proposer: Visnelma (talk) 23:23, 20 November 2020 (UTC)[reply]

Discussion

উইকিনিউজ পুরোপুরিভাবে চালু করা

  • সমস্যা: উইকিনিউজ পুরোপুরিভাবে চালু করা
  • কে উপকৃত হবে:সঠিক খবরের পাঠক
  • প্রস্তাবিত সমাধান:যাচাই-বাছাই করে দ্রুত উইকিনিউজ চালু করা
  • আরো মন্তব্য: এতে ফেইক ও ভূয়া নিউজ ছড়িয়ে পড়া রোহ হবে
  • ফ্যাব্রিকেটরে টিকেট:
  • প্রস্তাবকারী:TAUSIFnAKBAR TAUSIFnAKBAR (talk) 16:54, 19 November 2020 (UTC)[reply]

আলোচনা

আপনাকে আগে বাংলা উইকিসংবাদে অবদান রাখতে হবে। একটা সক্রিয় সম্প্রদায় গড়ে তুলতে হবে। তারপর ভাষা কমিটি উইকিসংবাদ চালুর অনুমতি দিবে। এখানে অবদান রাখুন। আফতাবুজ্জামান (talk) 05:10, 23 November 2020 (UTC) [reply]

Ryan and Shane's Bridge

NoN Out of scope

Discussion

Okay so..... this is the first thing I've ever posted on Wiki. I made an account just for this. On the Old Alton Bridge Wikipedia page, it is listed as "Old Alton Bridge, also known as Goatman's bridge". I believe that the bridge has been stolen by Ryan Bergara and Shane Madej from Buzzfeed Unsolved, and therefore, it isn't Goatman's bridge anymore. I say, either make this read "Old Alton Bridge, also known as Goatman's bridge, or Shane and Ryan's bridge," or "Old Alton Bridge, also known as Shane and Ryan's bridge." Thank you. — The preceding unsigned comment was added by Why am I Evan Heere (talk)

Hi Why am I Evan Heere! This is the Community Wishlist Survey, where you propose ideas for technical improvements to software used in the Wikimedia movement. We do not handle or moderate Wikipedia content through this survey.

I see Old Alton Bridge is currently protected. You can use this link to request changes be made, or simply start a discussion on article talk page. Hope this helps, MusikAnimal (WMF) (talk) 01:04, 19 November 2020 (UTC)[reply]

A bot

NoN Unclear proposal / out of scope

  • Problem: too many content getting deleted as inapropriate if you share content from your own blog,link(is that not free information??)...etc... knowing where and when to share content would improve speed of posting accurate content to wikipedia platform it self...also once you would know where you can post what it would make it easier to post new content who ever you would be...new to wikipedia or pro...
  • Who would benefit:
  • Proposed solution: A bot that would tell you if text you submitted is good or bad and if bad it then would be revieved but if good then it would be automatically submitted instead of waiting or later deleted as inapropriate. Solution for this problem is simple : automatic bot that would know what where to put maybe a categories(or similar to like youtube has livestream or upload)which would included also new sites content information, also it would check if for like site content(not posting virus or porn...) but it would include content with https:// safe sites and content
  • More comments:
  • Phabricator tickets:
  • Proposer: Fortniter2728 (talk) 16:54, 19 November 2020 (UTC)[reply]

Discussion

  • Hello Fortniter2728! I admit I am unable to make much sense of your proposal. But what I can tell you is no bot will be able to tell you whether or not the content you try to add to the wiki will stay, because humans make these decisions. I have archived this proposal for the time being as unclear/out of scope. You can learn more about writing a good proposal by reading the documentation. Thanks, MusikAnimal (WMF) (talk) 17:58, 19 November 2020 (UTC)[reply]

Add Wikipedia categories to the Wikidata element

NoN Proposes existing feature

  • Problem: It should be easy to find (via Wikidata Query Service) pages that are miscategorised (e.g. no birthplace category on the Wikipedia page even though a place has been entered in Wikidata).
  • Who would benefit: Wikipedia editors
  • Proposed solution: Add Wikipedia categories to the Wikidata element. Indeed, each category has a wikidata element. It must be possible to link the category to the Wikipedia pages that contain it via Wikidata. The difficulty lies in the number of elements across all the languages of Wikipedia.
  • More comments:
  • Phabricator tickets:
  • Proposer: Pelanch3 (talk) 08:29, 24 November 2020 (UTC)[reply]

Discussion

Enable visual editing for talk pages

Withdrawn by proposer (too many proposals)

  • Problem: Visual editing is disabled on talk pages.
  • Who would benefit: Visual editing users.
  • Proposed solution: Enable visual editing for talk pages.
  • More comments: Visual editing is far more intuitive for the average non-experienced user, and it would good to encourage more talk page participation by allowing the visual editor to be used there as well. And even more experienced editors such as myself can greatly prefer visual editing.
  • Phabricator tickets:
  • Proposer: Keepcalmandchill (talk) 04:01, 17 November 2020 (UTC)[reply]

Discussion

A proper image and video search results page

NoN Proposes existing solution

  • Problem: The search page is not too bad to search text pages, but utterly terrible to search images or videos. On my 1920x1080 computer, this search only shows 5 minuscule thumbnails at a time. On my 1280x720 mobile phone, this search only shows two minuscule thumbnails at a time. The search page shows more white background than anything.
  • Who would benefit: Readers
  • Proposed solution: The search page should show images and videos with a tiled grid format, like Google or Creative Commons. There should be an option to change the thumbnail size. When the user clicks on an image, it should show the full-size preview.
  • More comments:
  • Phabricator tickets:
  • Proposer: NaBUru38 (talk) 18:14, 21 November 2020 (UTC)[reply]

Discussion

Editable edit summaries

NoN Outside the scope of Community Tech

  • Problem: It is common for editors to make an error in an edit summary, or wish to expand the edit summary. There is no ability to fix an edit summary after an edit is submitted. Editors will sometimes make a null edit just to correct a prior edit summary.
  • Who would benefit: All editors.
  • Proposed solution: Allow edit summaries to be edited by the person who made the edit. This could perhaps be limited to that editing session to prevent suppression of edit summaries that are being used in dispute resolution.
  • More comments:
  • Phabricator tickets:
  • Proposer: Hammersoft (talk) 13:05, 25 November 2020 (UTC)[reply]

Discussion

Add articles with templates about problems with the content into the 'suggested edits' que

  • Problem: The suggested edits are all very basic and boring, and not that useful to the community.
  • Who would benefit: Editors looking to improve articles.
  • Proposed solution: Add articles which have been flagged with a template of common problems (poorly written, lack of sources, etc.) into suggested edits.
  • More comments: The suggested edits function should also be itself added to the web version.
  • Phabricator tickets:
  • Proposer: HappyMihilist (talk) 16:17, 18 November 2020 (UTC)[reply]

Discussion

Thanks for your response and clarification, HappyMihilist! We will be archiving this proposal, since it is directly related to the Growth team work (and we don't reverse the work of other teams or work on projects that other teams are currently working on). However, this feedback may be very useful for the Growth team to see. For this reason, we recommend that you file a Phabricator ticket and tag the Growth team, where you can directly interact with them about the Suggested Edits feature. Thank you! --IFried (WMF) (talk) 21:37, 2 December 2020 (UTC)[reply]

Separate pages for editors and Users, So authentic information can only be provided to users

NoN Requires community consensus / proposes existing feature

  • Problem:
  • Who would benefit:
  • Proposed solution: There should be separate pages for users and editors of a same topic/page, so only authentic information can be provided to users. In such a way that, Information edited/added/removed from editors' page appearing on users' page only after being reviewed by a confirmed user(editor)/ or only after a certain time period ( like 24 hours). So users are only shown authentic information/fact instead of any random edit by any random editor. It will increase more authenticity of information/fact/data on Wikipedia. Thank you.
  • More comments:
  • Phabricator tickets:
  • Proposer: Zainalee (talk) 05:01, 20 November 2020 (UTC)[reply]

Discussion

  • Hello Zainalee! Part of the reason Wikipedia became so successful is its philosophy that everyone should be able to edit. There are of course some topics that are subject to more misinformation, but fortunately there many solutions to deal with this. What you are describing sounds a lot like pending changes protection. This level protection means edits from new users must be reviewed before they are visible to most readers. The threshold of what constitutes a "new user" in this context is configurable, and it's even possible to make a second layer of protection where only experienced users are immediately visible. This is not currently enabled, but it can be if there is consensus to enable it. That will need to be decided by the community, and not here in the Survey. As such I'm going to archive this proposal. Nonetheless we thank you for participating! MusikAnimal (WMF) (talk) 20:43, 20 November 2020 (UTC)[reply]

Relatively unknown music bands

  • Problem: musicians all over the world are competing with each other. They are sometimes doing interesting things but do not have the funds to have a PR department, like the bigger bands have. This creates the idea that only big, rich music groups are relevant, while it also takes away possibilities for starting and unknown bands.
  • Who would benefit: These starting and unknown bands would now be able to point at a wikipedia entry, which makes them visible and more relevant. It may not be the taste of millions but the field of live music entertainment is diverging into smaller clusters.
  • Proposed solution: a new category 'unknown music bands' in where they can share their bio, and music, so as to be more visible to the world. I really hate it when I hear 'we're not going to include your 'garage band' and have to give in to the demand that my relevance is connected to the number of publications (a very contemporary view in the science industry) while these media are owned by a tiny group of people whose taste may or may not be similar to that of these unknown bands. Take them out of obscurity!
  • More comments: Most media are converging their views, thus excluding interesting developments as the shovel guitar, or cigarbox guitar, or home made electric cello. This of course also has economic effects: if my pages constantly get pulled, my PR is as well failing.
  • Phabricator tickets:
  • Proposer: Basvossen (talk) 21:04, 25 November 2020 (UTC)[reply]

Discussion

  • @Basvossen: Thanks for your proposal, but this is a content-related proposal and not something relating to technical software development, and so is out of scope for the Wishlist Survey. I'll move it to the archive. —Sam Wilson 00:40, 26 November 2020 (UTC)[reply]

Fonctions très utiles

NoN Invalid proposal

Bonjour l'Équipe Tech ! Je m'appelle MrLune. Voici ma liste des idées pour Wikipédia (site) :

Astérix (signe) = Que pour les utilisateurs

  • Un thème sombre sur le site sinon je vais encore avoir des yeux qui se réveil pas le jour !
  • Une UI révisée car celle-ci traîne depuis longtemps
  • Un bouton "Révoquer" pour enlever des modifications car c'est plus pratique surtout pour les mobiles*
  • Des bandeaux plus petits (comme le Wikipédia espagnol ou anglais)
  • La possibilité de modifier le texte gris en dessous du titre de page car parfois y'a rien ou sinon c'est un mauvais texte*
  • Le système bloque automatiquement la permission de créer des pages utilisateurs sans être la cible (en gros bloquer une adresse IP de créer la page d'un admin)
  • Une redirection automatique pour plus d'accents, pour les majuscules ou les tiret-bas (_) (je sais pas comment ça s'appelle)

C'est tout ! J'espère que touts les idées (ou une d'entre elles) sera mise dans le site :).

Cordialement MrLune (talk) 18:07, 20 November 2020 (UTC)[reply]

Discussion

  • @MrLune: Bonjour MrLune! Vous devez créer une proposition distincte pour chaque idée. Si vous pouvez utiliser le bureau, veuillez le faire car il utilisera les modèles lorsque vous créerez vos propositions. Il existe actuellement un bug qui pose des problèmes aux personnes soumettant des propositions sur mobile. Vous êtes également limité à ne faire que trois propositions au maximum. Pour plus d'informations, consultez la documentation.

    "Un thème sombre" Je suis désolé, ça ne peut pas être fait. Voir Community Tech/Status report for 2019 wishlist#Night Mode pour plus d'informations. Merci d'avoir participé à l'enquête! MusikAnimal (WMF) (talk) 21:30, 21 November 2020 (UTC)[reply]

avance tecnologico

NoN Unclear proposal / needs clarification

  • Problem: slowness of the page and little progress
español: lentitud de la pagina y poco avances
  • Who would benefit: better experience and quality of the reader and for greater speed when opening the page, the beneficiary will be the reader and the users
español: mejor experiencia y calidad del lector y para mayor rapidez al abrir la pagina el benificiado sera el lector y los usuarios
  • Proposed solution: enable the page for faster reader
español: habilitar la pagina para mayor rapidez para el lector

Discussion

I believe this does not have much to do with bots and gadgets, unless gadgets are severely affecting page performance, which I cannot comment on with much certainty. H78c67c (talk) 19:36, 20 November 2020 (UTC)[reply]

Create a Wiktionary mobile app

NoN Outside the scope of Community Tech

  • Problem: Much like Wikivoyage and other Wikimedia projects, Wiktionary is rather inconvenient to use on a mobile browser. In addition, it also runs into the same issue of trad/simp switching being difficult when using the Chinese version on mobile.
  • Who would benefit: Existing Wiktionary users as well as language learners, enthusiasts, and people who need to look up words in a dictionary in general.
  • Proposed solution: Create an app similar to the Wikipedia app with a better UX. Have a solution similar to said app with different traditional and simplified versions being displayed as needed.
  • More comments: Adding a pop-up dictionary to look up highlighted words or phrases would be great, and I think it would be the most useful feature for many people.
  • Phabricator tickets:
  • Proposer: MSG17 (talk) 17:33, 26 November 2020 (UTC)[reply]

Discussion

Documentation page for Wikidata items and properties

NoN Does not propose a technical change

  • Problem : Wikidata is great but it still a very complex universe. My opinion is that there is a lack of comprehensive resources in Wikidata and a lack of documentation. Properties have a documentation template which is hidden in the discussion page (see Property documentation). This is page is messy.
  • Proposed solution : One could imagine something clearer with real questions such as How many items use the property? What is the nature of (p31) of items using the property, etc. My opinion is that documentation should also be discoverable. It should have its own tabset. Documentation for properties is great but one could also imagine documentation pages for items. My idea would be to develop some simple template in the style of notebooks. One example would be what I have done for one first names : Notebook for first name Ada(sorry it's in French). The idea is to have a set of questions and corresponding SPARQL queries.
  • Who would benefit : Readers and beginners. It would be easier to understand how properties and items are related to each other.
  • Proposer : PAC2 (talk) 05:25, 17 November 2020 (UTC)[reply]

Discussion

  • I don't feel qualified to speak to the specific solution, but I very much agree that making Wikidata more beginner-friendly should be a priority. {{u|Sdkb}} talk 03:27, 19 November 2020 (UTC)[reply]
  • We also agree there's quite a learning curve to Wikidata! However the Wishlist Survey is a means to ask for technical changes and improvements, while this seems to be about documentation. For this reason I'm going to archive this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 04:11, 2 December 2020 (UTC)[reply]
@MusikAnimal: my proposition was unclear. The idea was to create documentation pages for items wikidata:Q5/Documentation and create a tabset in the page menu between item and talk pages. So it's somehow a technical change. PAC2 (talk) 07:51, 9 December 2020 (UTC)[reply]

User rights to control entire section of Wikipedia

NoN Requires community consensus

русский: Создание флага, который позволит человеку управлять всем разделом википедии

  • Problem:
  • Who would benefit:
  • Proposed solution: I suggest introducing the "language section agent" flag. That is, a person who will have all the rights in a certain section of Wikipedia. In my opinion, this person should be alone, as there will be less chaos and disagreements. In this case, applicants for this flag must be elected by the participants.
русский: Я предлагаю ввести флаг "агента языкового раздела" . То есть человека, который будет иметь все права в определённом разделе википедии. По моему мнению этот человек должен быть один, так как так будет меньше бардака и разногласий. При этом претенденты на данный флаг обязательно должны избираться участниками.

Discussion

  • This would require widespread consensus from the community before doing any technical work. For this reason, I'm going to archive this proposal, but thank you for participating in the survey! MusikAnimal (WMF) (talk) 00:45, 22 November 2020 (UTC)[reply]
    русский Это потребует широкого согласия сообщества перед выполнением какой-либо технической работы. По этой причине я собираюсь заархивировать это предложение, но спасибо за участие в опросе! MusikAnimal (WMF) (talk) 00:45, 22 November 2020 (UTC)[reply]

Dark theme on web version

NoN Declined in a previous survey

  • Problem: No dark theme
  • Who would benefit: Everyone
  • Proposed solution: Dark theme on web version would be good for people like me who reads at night.
  • More comments:
  • Phabricator tickets:
  • Proposer: Tercose 03:44, 17 November 2020 (UTC)[reply]

Discussion

Seconded. Keepcalmandchill (talk) 04:29, 17 November 2020 (UTC)[reply]

Bot for automatic archiving discussion

NoN Out of scope

  • Problem: We need to archive old discussion manually. Many wikis (especially big wikis) has their own bot. But most wikis doesn't have a Bot (one of main reason they don't have any technical person who can run a bot)
  • Who would benefit: All
  • Proposed solution: Create a global bot (similar to en:User:lowercase sigmabot III)
  • More comments:
  • Phabricator tickets:
  • Proposer: আফতাবুজ্জামান (talk) 20:14, 24 November 2020 (UTC)[reply]

Discussion

Create WikiVoyage mobile app

NoN Outside the scope of Community Tech

  • Problem: Using a mobile browser is a clunky experience while traveling.
  • Who would benefit: WikiVoyage users.
  • Proposed solution: A mobile app with an improved experience over mobile browser with ability to save pages for offline access while traveling.
  • More comments: Adding ability to sign in and check off places you have visited would be useful as well.
  • Phabricator tickets:
  • Proposer: Aventuristo (talk) 21:24, 18 November 2020 (UTC)[reply]

Discussion

  1. I think this will be useful for those who love to travel and explore.--आर्या जोशी (talk) 06:57, 21 November 2020 (UTC)[reply]

GlobalRecentChanges

Withdrawn by proposer

  • Problem: The users cannot see all recent changes from all Wikimedia projects.
  • Who would benefit: The users who want to patrol on all Wikimedia projects.
  • Proposed solution: Add Special:GlobalRecentChanges, a page in which there are displayed all recent changes from all Wikimedia projects.
  • More comments: I don't know if this is technically possible.
  • Phabricator tickets:
  • Proposer: --NGC 54 (talk / contribs) 12:35, 25 November 2020 (UTC)[reply]

Discussion

  • @NGC 54: I doubt we could build a Special:GlobalRecentChanges that works just like Special:RecentChanges, with a dedicated database table, etc., but there are some existing external solutions like toolforge:event-streams that can be used for monitoring activity across all wikis. We could certainly improve these tools. Would that satisfy the wish? MusikAnimal (WMF) (talk) 16:27, 25 November 2020 (UTC)[reply]
  • @NGC 54: I also wonder if you have considered the sheer scale of 'everything on every wiki'... It would be immensely overwhelming for any person to look at that, with all the different languages, multiple scripts like latin, hebrew, korean, japanese etc all mixed together and also different directional alignment... It doesn't seem to me like anything that anyone would ever want to look at unless heavily filtered towards a specific subset. —TheDJ (talk • contribs) 22:31, 25 November 2020 (UTC)[reply]

Allow page creators to block other editors to the page

NoN Proposes a social/policy change, needs consensus

  • Problem: Certain times, some Wikipedia users misuse the edit option and write negative things on the Wikipedia page created for a celebrity or famous person. It'll be also very okay if Wiki can ban a user or give an option to ban a user if he/she writes any hateful speech on a wiki page.
  • Who would benefit: Those celebrity personalities who recently spoke on a controversial topic or are hated by some Wiki users.
  • Proposed solution: The edit option should be valid but the creator of the wiki page should be able to block the editor of the page.
  • More comments:
  • Phabricator tickets:
  • Proposer: Pratishtha Karkee (talk) 06:26, 18 November 2020 (UTC)[reply]

Discussion

Two-factor authentication (2FA) for all users

Deutsch: Zwei-Faktor-Authentifizierung (2FA)

NoN Declined in a previous survey

  • Problem: As far as I know, two-factor authentication is currently still in the field test for certain user groups. It would be desirable if the development could be pushed forward so that this function could be rolled out globally for all users and wikis. Many thanks
Deutsch: Soweit mir bekannt ist, befindet sich die Zwei-Faktor-Authentifizierung derzeit noch im Feldtest für bestimmte Benutzergruppen. Es wäre wünschenswert, wenn die Entwicklung voran getrieben werden könnte, so das diese Funktion global für alle Benutzer und Wikis ausgerollt werden könnte. Vielen Dank

Discussion

Dark Mode (2)

NoN Declined in a previous survey

  • Problem:
  • Leuten die ehr im dunkeln erbeiten oder einfach den Darkmode bevorzugen:
  • Darkmode programmieren (css):
  • Weitere Kommentare:
  • Phabricator-Tickets:
  • Antragsteller: MR776 (talk) 14:48, 20 November 2020 (UTC)[reply]

Diskussion

  • This was the #2 wish in the 2019 survey. We investigated and even began work, and as much as we wanted to finish it we unfortunately had to stop due to some technical challenges and conflicts with the Desktop Improvements project. You can learn more by reading our status report. This is not to say dark mode won't happen some day; I think it definitely will, but I'm afraid it won't be from Community Tech. As such I'm going to decline this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 00:50, 22 November 2020 (UTC)[reply]
    Deutsch: Dies war der Wunsch der #2 Wunsch in der Umfrage 2019. Wir haben nachgeforscht und sogar mit der Arbeit begonnen, und so sehr wir sie auch beenden wollten, mussten wir leider aufgrund einiger technischer Herausforderungen und Konflikte mit dem Projekt Desktop Improvements aufhören. Weitere Informationen finden Sie in unserem Statusbericht. Dies bedeutet nicht, dass der dunkle Modus eines Tages nicht mehr auftreten wird. Ich denke, das wird es definitiv, aber ich fürchte, es wird nicht von Community Tech sein. Als solches werde ich diesen Vorschlag ablehnen. Vielen Dank für Ihre Teilnahme an der Umfrage. MusikAnimal (WMF) (talk) 00:50, 22 November 2020 (UTC)[reply]

Watchlisting category would show pages added/deleted to the category

NoN Withdrawn by proposer; proposes an existing feature

  • Problem: Currently, monitoring categories is not an easy task. Putting a category in your watchlist only shows changes to the category page but does not show if any pages are added or removed from said category. That creates issues for maintaining well defined categories (e.g. that no random person is categorized as an office holder) or controversial categories (e.g. sexual orientation categories).
  • Who would benefit: All category maintainers on all projects
  • Proposed solution: If a category is in your watchlist, then any edits that place or remove pages from that category would show up on your watchlist. To be clear, not looking for a feature that would display all edits to all pages in the category (that's the function of "related changes" tool), just edits that place/remove pages from the category.
  • More comments:
  • Phabricator tickets:
  • Proposer: Renata3 (talk) 02:28, 17 November 2020 (UTC)[reply]

Discussion

Doesn't this already work? * Pppery * it has begun 03:00, 17 November 2020 (UTC)[reply]

It certainly should. @Renata3: In your watchlist filters there should be a "Category changes" option under the "Type of change" heading. Is not that working for you? You can also save this to your default watchlist settings, either using the save button in the watchlist interface or by ensuring "Hide categorization of pages" is unchecked at Special:Preferences#mw-prefsection-watchlist. MusikAnimal (WMF) (talk) 03:19, 17 November 2020 (UTC)[reply]
Haha, bloody hell, it does work. Nevermind then. Please close/withdraw this. Renata3 (talk) 03:34, 17 November 2020 (UTC)[reply]
Glad it's working! I suppose it's easy to miss because it's not in the default filters. Per your request I will archive this proposal. Best, MusikAnimal (WMF) (talk) 03:44, 17 November 2020 (UTC)[reply]

The Special:ContentTranslation sometimes a bug occurs

  • Problem: When I prepare an article in Special:ContentTranslation (I don't know what happens), I hope to save it automatically; and when opening the draft again, it shows the previous version of the saved one.
  • Who would benefit: When I prepare an article on Special:ContentTranslation, I don't know what happens or if it happens to several users, that when I hope to save; and open the draft again, it shows the previous version of salvo
  • Proposed solution: The gadget needs to be reconfigured in the automatic saving part, forcing the user to wait (Clearly, the user will be able to refuse the save at that time) to completely save the draft of the translated article.
  • More comments: I don't know if that could be my mistake; plus the solution could be useful for gadget, in my opinion.
  • Phabricator tickets:
  • Proposer: Juan90264 (talk) 04:33, 17 November 2020 (UTC)[reply]

Discussion

@Matěj Suchánek: I will create a task in Phabricator, to discuss this "bug". I appreciate the answer! But, what do I do with this discussion? Juan90264 (talk) 19:49, 17 November 2020 (UTC)[reply]
Looks like this became phab:T268070 (though that one needs clarification by following mw:How to report a bug). --AKlapper (WMF) (talk) 11:05, 18 November 2020 (UTC)[reply]
I think you don't have to do anything. It will definitely get proper care by the survey organizers at some point. --Matěj Suchánek (talk) 11:07, 18 November 2020 (UTC)[reply]

Create Commons iOS app

NoN Outside the scope of Community Tech

Commons Upload Wizard on Safari iOS
Commons Upload Wizard on Safari iOS
  • Problem: Year after year, the proportion of contributions made by cell phones to Wikimedia projects and the quality of the cameras in smartphones are constantly increasing. Significant efforts have been made to improve the Wikipedia editing interface and develop Android and iOS applications. But the Upload Wizard on Commons remains completely unusable on Mobile, forcing contributors to go through a computer to upload photos.
  • Who would benefit: All users using an iOS device
  • Proposed solution: Create a Commons iOS app similar to the Android one.
  • More comments:
  • Phabricator tickets:
  • Proposer: Ayack (talk) 16:37, 19 November 2020 (UTC)[reply]

Discussion

Instead of creating a new iOS app, it would make sense to generally develop functionality like that with a crossplatform framework like Flutter. ChristianKl ❪✉❫ 14:12, 24 November 2020 (UTC)[reply]
  • Building a new iOS app from scratch (as the Android one can't simply be ported) I'm afraid is too out of scope for our team. However we have accepted the Friendly mobile browser version for OS devices to upload photos proposal which aims to make the Upload Wizard more mobile-friendly, so be sure to vote for that when the voting phase starts on December 8. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 02:05, 2 December 2020 (UTC)[reply]
    @MusikAnimal (WMF): I don't find it respectful at all to withdraw my proposal by telling me that it duplicates another one, and to withdraw this other one two days before the opening of the votes. If I had been warned, I would have modified mine so that it would fit into the survey... Now it is too late! Ayack (talk) 17:22, 9 December 2020 (UTC)[reply]
    @Ayack I am truly sorry! Your proposal seemed to be clearly about an iOS app which we knew we couldn't do. The other proposal left room for working on mobile web, but unfortunately the proposer didn't get back to us in time to clarify :( I would have pinged you had I thought of it. We went through many hundreds of proposals, so you can imagine how easy it is to forget about some of them. Apologies again and kind regards, MusikAnimal (WMF) (talk) 22:40, 9 December 2020 (UTC)[reply]

Disable the "legacy" method of deleting a file version

NoN Proposes social/policy change rather than technical feature

  • Problem: Currently, there are two ways of deleting a file version. The first way is the "old-fashioned" or "legacy" way of do it, which moves the file version into the "filearchive" table and creates a deletion log entry that says "Deleted old revision" in its comment. The second way, and the preferred way, is to "RevDel" the file.
  • Who would benefit: Administrators
  • Proposed solution: On wikis where RevisionDelete is enabled (including Wikimedia ones), do not allow administrators to use the "legacy" method, but only the "preferred" one. On (third-party) wikis where RevisionDelete is disabled, continue allowing the use of the "legacy" method. A bot should then convert all files that were deleted the "old-fashioned" way to RevisionDeleted files.
  • More comments:
  • Phabricator tickets:
  • Proposer: GeoffreyT2000 (talk) 19:53, 22 November 2020 (UTC)[reply]

Discussion

IIRC the "legacy deletion" you speak of is just the normal way MediaWiki handles deleted revisions. Should not be disabled, as this would fundamentally break history splits/merges. -FASTILY 11:03, 23 November 2020 (UTC)[reply]

  • After discussing with the team, we don't believe deletion is a "legacy" method and in some cases may be favourable. We do realize some wikis discourage it, so you could for instance use sitewide CSS to hide the delete links, if you wanted, but that is up to each respective community. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 02:15, 2 December 2020 (UTC)[reply]

Ref-Tags

Discussion

I would appreciate a simplification of the way to do ref-tags. To type <ref> and </ref> forces me to look at the keyboard and use the shift key every time.

Is there any possibility to create a more simple code for this?

Sciencia58 (talk) 08:04, 17 November 2020 (UTC)[reply]

There's a plenty of tools for this. For example, you can make a button to insert "<ref></ref>" at the place you are writing to. Many wikis also have clickable buttons beneath the wikitext editor (including this wiki). And finally, there are citation tools in the visual editor which do not require the user to know there is something like <ref>. --Matěj Suchánek (talk) 09:35, 17 November 2020 (UTC)[reply]
Exactly. edit toolbars already provide all of this. —TheDJ (talk • contribs) 11:47, 17 November 2020 (UTC)[reply]
@Sciencia58: Try this tool (others are also available). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:01, 17 November 2020 (UTC)[reply]
Not sure why I can't just reply to this, but that looks interesting, I too would want to use it for citing (clicking in the toolbar makes the entire page shift, and getting it back means I lose any time savings) Nosebagbear (talk) 15:07, 18 November 2020 (UTC)[reply]

Category management for one or multiple images at once

NoN Proposes existing feature

  • Problem: currently, pictures can be dedicated to certain category only through text interface or HotCat. What we probably miss (and this applies maybe to articles as well) that on the top toggle button "Category management" (on/off) would be shown. By pressing this in any of multiple pictures view (search results, category view,...) small square checkmark field would appear next to each picture (or article). You could then select one by one multiple pictures. Also after pressing "Category management" second button would appear "Add/remove Category". After pressing on it, list of all categories asociated to these pictures would appear. If all fit to one category, square with checkmark and white background next to category name will appear. If they not fit all to the category, grey background to this checkmark square would appear. And below the list of categories, "Add category" would appear. Applying checkmark to grey would add category to all selected pictures, erasing checkmark would remove category to all selected pictures.
  • Who would benefit: all Commons editors and users
  • More comments:
  • Phabricator tickets:
  • Proposer: ModriDirkac (talk) 13:45, 24 November 2020 (UTC)[reply]

Discussion

Pronunciations in the English

  • Problem: Many terms have wiki articles, but no pronunciation. Non-native speakers may have no idea how to pronounce the terms.
  • Who would benefit: Language learners.
  • Proposed solution: (auto-generating soundfiles from IPA spelling?)
  • More comments: (I've filled this proposal in, on the basis of his edit comment, as the original poster did not; I hope the original poster will correct me and remove this sentence. Si vous écrivez en Français, nous pouvons le traduire. HLHJ (talk) 01:42, 24 November 2020 (UTC))[reply]
  • Phabricator tickets:
  • Proposer: JulesMarner (talk) 16:07, 22 November 2020 (UTC)[reply]

Discussion

  • @JulesMarner: Thanks for your proposal, but it's currently lacking some information. Could you please fill in the above bullet points ('Problem', 'Who would benefit', etc.)? Thanks! (If you want to write in a language other than English, that's fine too.) —Sam Wilson 07:27, 23 November 2020 (UTC)[reply]
  • It seems like the space for pronunciations and IPA is Wiktionary and Wikidata lexemes and not Wikipedia. There are already some audio files. I believe it's better to have the community produce more pronunciation recordings then centrally create automated IPA recordings (which would naturally be of lower quality given that the IPA doesn't cover everything). ChristianKl ❪✉❫ 14:11, 24 November 2020 (UTC)[reply]
  • Auto-generating soundfiles is a bad idea for plenty languages and mostly for names of places that could have weird old and regional habits. For French, dead letters are everywhere. Human-made audio recording could be hosted in Wikimedia Commons and there is a wonderful tool name Lingua Libre built by Wikimedia France chapter to help record lists of words. Including lists of surrounding places, very useful to record the pronunciation of places with odd names. Sounds are automatically added to Commons and a bot add them to some Wiktionary pages already. Those can be added to Wikipedia Noé (talk) 11:59, 29 November 2020 (UTC)[reply]

La "Consultation des souhaits de la communauté" NE PEUT PAS ÊTRE FAITE QUE DANS UNE SEULE LANGUE ! (anglais ici)

  • Problème: voir le titre !
  • Qui en bénéficierait:
  • Solution proposée:
  • Autres commentaires: Il n'y a rien à ajouter à ce qui est dit en titre. Je ne ferai strictement aucune autre intervention. Salutations. pat
  • Tâches sur Phabricator:
  • Proposant: Tifroumi (talk) 14:34, 20 November 2020 (UTC)[reply]

Discussion

  • Translation: "The community survey shouldn't be exclusively done in one language (English here)"--Vera (talk) 11:45, 21 November 2020 (UTC)[reply]
  • @Tifroumi: We agree! This is one of many problems we have with the survey. This particular problem, though, is mostly due to technical challenges. Unfortunately the translate extension doesn't play nicely with the way the survey is structured. It sounds like next year will be radically different, so we'll make sure to make localization a priority in the new system. Apologies for the inconvenience. We definitely recognize the importance of including non-English speakers. Kind regards, MusikAnimal (WMF) (talk) 01:16, 24 November 2020 (UTC)[reply]
Français: Nous sommes d'accord! C'est l'un des nombreux problèmes que nous avons avec l'enquête. Ce problème particulier, cependant, est principalement dû à des défis techniques. Malheureusement, traduire l'extension ne joue pas bien avec la façon dont l'enquête est structurée. Il semble que l'année prochaine sera radicalement différente, nous nous assurerons donc de faire de la localisation une priorité dans le nouveau système. Mes excuses pour le derangement. Nous reconnaissons définitivement l’importance d’inclure les non-anglophones. Sincères amitiés, MusikAnimal (WMF) (talk) 01:16, 24 November 2020 (UTC)[reply]

Allow footnotes to be added in the visual editor

Request withdrawn Withdrawn by proposer

  • Problem: The visual editor does not allow footnotes to be added.
  • Who would benefit: Visual editors.
  • Proposed solution: Add a function on the visual editor to add a footnote.
  • More comments: Adding footnotes should be as easy as adding references, but on the visual editor one is easy and the other impossible.
  • Phabricator tickets:
  • Proposer: Keepcalmandchill (talk) 04:22, 17 November 2020 (UTC)[reply]

Discussion

Visual Editor for mobile

NoN Outside the scope of Community Tech

  • Problem: No visual editor for the mobile app
  • Who would benefit: People who want to contribute but struggle with source editing or find it much easier to use the virtual editor
  • Proposed solution: Add the ability to use visual editor when editing in the mobile app
  • More comments: This would make editing/adding/contributing available to a bigger group of people on mobile as not everyone likes using the source editor.
  • Phabricator tickets:
  • Proposer: Loganscott74 (talk) 15:19, 19 November 2020 (UTC)[reply]

Discussion

Many people would love and benefit from having a visual editor on mobile. Not everyone understands how to use the source editor which may prevent them from contributing to posts about the information they may know just because they cant use a visual editor on their mobile device. Even for people who can use both, it will likely be easier to use the visual editor on the smaller mobile displays. — The preceding unsigned comment was added by Loganscott74 (talk)

I support it. Visual editor partially works on mobile but it doesn't has all the features. Please add the visual editor features in mobile also. It would be helpful to all the mobile editors --Huzaifa abedeen (talk) 05:55, 25 November 2020 (UTC)[reply]
同意，移动设备端的维基百科APP应该加入可视编辑器，现有的编辑器的确对新手不太友好。Cod9 (talk) 17:45, 25 November 2020 (UTC)[reply]
I support it. --El Pantera (talk) 11:31, 25 November 2020 (UTC)[reply]
  • As much as we'd like to help with this, it is beyond the scope of what Community Tech can do. There are also two mobile apps (iOS and Android) with a completely different code base, doubling the effort. They are written in a different programming language than the web-based VisualEditor, so you can imagine how big of a project this would be. Sorry we can't help, but thank you for participating in the survey! MusikAnimal (WMF) (talk) 17:53, 3 December 2020 (UTC)[reply]

Back button of the browser to bring you precisely where you were

NoN Unclear proposal / proposer has not replied

Discussion

@Gfombell: Cannot reproduce. Have you discussed this before on a Village Pump to make sure that this is a common problem also faced by other community members across different browsers and operating systems? For me, Firefox 82 does go back to the position of a page after going to another page and then going back. Plus I'm afraid defining this behavior is up to web browsers, not to web sites... --AKlapper (WMF) (talk) 13:45, 17 November 2020 (UTC)[reply]

I agree with AKlapper (WMF); I don't seem to have this problem. I use Chrome v85, and it indeed goes back to where I was when I go back at least 90% of the time. Thanks, EDG 543 (message me) 15:34, 17 November 2020 (UTC)[reply]

Automatic visual editing of spanned templates

NoN Outside the scope of Community Tech

  • Problem: en:Template:Citation needed span and alike needs to be editable in visual mode in the same manner one inserts references. When reference is inserted, text should turn normal automatically.
  • Who would benefit:
  • Proposed solution:
  • More comments: If one finds a reference, it is natural to copy it, then insert as is done with ⌘⇧K. However, if one opens Template:Citation needed span one need to copy the text to delete template, and there is no way to insert the requested reference.
  • Phabricator tickets: phab:T52182
  • Proposer: Macuser (talk) 11:52, 30 November 2020 (UTC)[reply]

Discussion

ETL Tool

  • Problem: There is a lack of knowledge about all jobs done in Wikidata. Every day a large number of them are run, but there is no easy way to monitor them, keep track of sources, stop them when they don't work properly or even spread awareness about them among developers. Related to this, there is a huge amount of data imported from Open Data Collections to Wikidata through a code executed once, but not run again when those collections are updated. There is not an easy way to discover when a collection was imported last. We should devote more efforts to facilitating the creation of ETLs and running them periodically.
  • Who would benefit: Wikidata would have a much more up-to-date corpus and code executions would be more transparent to the community (heavy, light developers and maintenance users).
  • Proposed solution: I'm not sure about the solution, maybe install an ETL Tool or something like Jenkins is enough.
  • More comments:
  • Phabricator tickets:
  • Proposer: KRLS (talk) 17:27, 22 November 2020 (UTC)[reply]

Discussion

Editing templates recursively

NoN Outside the scope of Community Tech

  • Problem: Editing using the VisualEditor cannot edit templates that exist inside of other templates, and editors frequently have to switch modes (or preview the edit) from the source mode to check that the nested template works properly.
  • Who would benefit: Editors using the VisualEditor
  • Proposed solution: Like the current implementation of editing templates, there would be a popup, but much larger. Alternatively, it would be a tab much like the tabs above the editing area, but distinguished in its own horizontal row. In these context menus, there would exist an editable template that would look identical to the final result. Users could view and edit formatted text, as well as adding templates, which would appear as finalized, too. In these menus, if the editor wishes to edit a second template inside another, a popup or tab would appear with the new editing workspace. Such templates that would benefit from this include Episode list, any date formatting template, navigation templates, etc.
  • More comments:
  • Phabricator tickets: phab:T52355
  • Proposer: SWinxy (talk) 04:35, 17 November 2020 (UTC)[reply]

Discussion

  • Editing templates within templates I think is phab:T52355? I think it might be too much scope for the CommTech team to take on. --Izno (talk) 19:53, 17 November 2020 (UTC)[reply]
    That bug is for visual editing of the template. The 'complex transclusion' mode already exists, and lets you change the template contents within the visual editing mode. Click on the "outside" template, and open the template editor. Then click "Show options" in the bottom corner. When you "Apply changes" (to the "outside" template), you'll see the result. Whatamidoing (WMF) (talk) 06:30, 18 November 2020 (UTC)[reply]
I think I get what you mean, but that appears to only append a template onto another one, rather than edit a template from inside another template. SWinxy (talk) 03:57, 24 November 2020 (UTC)[reply]
You can make full changes to the items already in it. Whatamidoing (WMF) (talk) 21:05, 4 January 2021 (UTC)[reply]

Arrow that denotes majority control in linear election bars

NoN Out of scope / does not require engineering resources

  • Problem: On linear bars showing the makeup of legislatures by party or bloc, the arrow that denotes the halfway point does not show up halfway in the mobile view; unlike as intended on desktop. This image shows the desktop page as viewed on a mobile device. When viewed on the mobile website, the arrow is pushed to the left, regardless of orientation [2][3]
  • Who would this benefit? Mobile viewers, particularly casual users who may not think changing back to desktop mode would “fix” it
  • Proposed solution: I do not know how to fix this. A bodge may be to split the majority faction into two parts, with one part showing how big their majority is. A bolded line in the table could then be used to denote the halfway or majority point of the chamber.

    So if a party had 56 seats out of a 100 seat legislature, that party would have a 50 seat section and a 6 seat section. It could be something along the lines of the thin grey box in the Hong Kong 2019 local election page https://media.discordapp.net/attachments/293289531396849664/779478006129360916/image2.png but the thin grey box denoting the halfway point in the legislature, rather than separating two factions

  • Phabricator tickets:
  • Proposer: Iamthinking2202 (talk) 22:52, 20 November 2020 (UTC)[reply]

Discussion

  • @Iamthinking2202: I think this proposal is too narrow and possibly out of scope. There are many other templates with similar issues in the mobile view, and they can usually be fixed by modifying their CSS. Potentially, you could broaden this to cover all templates with usability issues on mobile, but this would still not involve any changes to the underlying software, so it's not clear if this would be a good use of Community Tech's time (this could be accomplished entirely by normal volunteer editors). Jc86035 (talk) 18:03, 21 November 2020 (UTC)[reply]
    • Alright, thank you for replying and reading.
  • From what we gather, this can be resolved locally without the help of WMF engineers, so I'm going to archive this as out of scope. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 22:23, 1 December 2020 (UTC)[reply]

Multiblocks

  • Problem: (citing from the Phabricator task) After partial blocks were introduced there may be reason for a user to have several blocks with different expiration dates. For example: User:Apples has been indefinitely blocked from editing `Neptune`. They then receive a 24 hour full-site block. When the full site block expires, they should continue to be blocked from `Neptune`. or User:Bananas is indefinitely blocked from editing `Mars` and from editing `Venus` until 2025. An admin wants to block them from `Saturn` for one month.
  • Who would benefit: Administrators, anti-vandalism fighters and harassed users. With the introduction of partial blocks the maintenance of the blocks became significantly more demanding. Some examples of the emerging problems are listed above.
  • Proposed solution: phabT194697#4490345 is a proposal, how it could work.
  • More comments: The work on the phabricator task was esentially stopped in the early 2019 after WMF anti-harassment team declined to commit resources on it with the reason: The development of this project would be a massive time and resource investment for minimal impact. Perhaps Community Tech team would be willing to work on it?
  • Phabricator tickets: T194697, T202673
  • Proposer: Vachovec1 (talk) 18:35, 25 November 2020 (UTC)[reply]

Discussion

@Zblace: I take it that UCoC means Universal Code of Conduct? -- Luk talk 12:28, 1 December 2020 (UTC)[reply]
Correct! Zblace (talk) 20:26, 1 December 2020 (UTC)[reply]
  • Hi Vachovec1. Thanks for making this proposal. As you've noted, the Anti-Harassment Tools team declined this in favor of working on the Partial Blocks feature. That was primarily due to the very large undertaking this work would be. This Multiblocks wish is also out of scope for the Community Tech team to take on as part of the wishlist. For that reason, I'm archiving this wish as part of my role with Community Tech. In my role with the Anti-Harassment Tools team, I'm curious what block management issues you're having with Partial Blocks. Would you be open to starting a Phab task detailing your issues around Partial Blocks? I can't guarantee we will change/fix them but I'd be very happy to have the feedback. --AEzell (WMF) (talk) 20:45, 2 December 2020 (UTC)[reply]
    The "block management issue" is described in this proposal's motivation, as well as Community health initiative/Partial blocks/Multi-blocks (the Phabricator tasks are linked above). It is the inability to impose several partial blocks with different expiration on one user. --Matěj Suchánek (talk) 11:37, 5 December 2020 (UTC)[reply]

Add an option in the API to request images in recursive categories

Request withdrawn

  • Problem: Currently it is not possible to request images through the API and get also images from the subcategories. As images are generally intensively categorized, the query often produces a result set of leftovers when requesting the related Commons category of a Wikidata item, for example. The other option is to wait for the structured data to be completely added to images.
  • Who would benefit: Reusers of Commons images via the API
  • Proposed solution: Add an option to the API for retrieving images recursively.
  • More comments:
  • Phabricator tickets:
  • Proposer: Susanna Ånäs (Susannaanas) (talk) 09:25, 21 November 2020 (UTC)[reply]

Discussion

Is an API endpoint a specific requirement for you (i.e. you're building a service/bot that would consume this endpoint) or do you just care about the data itself (e.g. a plaintext list of files)? -FASTILY 11:17, 21 November 2020 (UTC)[reply]

I am building an application (Wikidocumentaries) that displays all images related to the current topic and it will be developed to allow enriching the Commons data from the application. With the current API it is not possible to get the images from the subfolders. – Susanna Ånäs (Susannaanas) (talk) 15:06, 26 November 2020 (UTC)[reply]
Then why not use mw:API:Categorymembers to query the parent category for categories, and recursively iterate through the returned categories? If you don't want to do this recursively, then you do it iteratively with a Queue data structure. Anyways, here's a recursive implementation in Java which uses Sets to avoid duplicates: [4] -FASTILY 03:08, 27 November 2020 (UTC)[reply]
Thank you, it is possible that this will solve it and I can withdraw the proposal. – Susanna Ånäs (Susannaanas) (talk) 10:59, 27 November 2020 (UTC)[reply]

Global generalisation of infobox parameters

NoN Outside the scope of Community Tech

  • Problem: I don't kow if this problem also appears in the English Wikipedia, because I come from the Spanish one, but the thing is, I always had a continuous confusion on how a parameter was written in an infobox template, to show the data that I wanted. This is, for example, when I wanted to make visible an image on an infobox, I had to know if the infobox's parameter was "image", "photo"... Or even the captions; I had to know if it was "image_2", "image caption", "image_caption"... And thus with many other parameters.
  • Who would benefit: Everyone who edit infoboxes. It would be much easier and faster to make or edit articles.
  • Proposed solution: If it's possible, I propose all the infobox codes have to be edited to have a general name of a common parameter. Therefore, an image input in an infobox should be made by writing "image", and in another one, "image" too.
  • More comments:
  • Phabricator tickets:
  • Proposer: De un millón (talk) 22:15, 20 November 2020 (UTC)[reply]

Discussion

  • @De un millón: There unfortunately is no solution here without global templates, which is an extremely daunting task that's outside the scope of this survey. There is a similar but smaller wish at Templates translation that proposes a solution that might work for you too; perhaps you'll want to vote on it when the voting phase starts on December 8.

    In the meantime, maintainers of templates are encouraged to make use of TemplateData. This offers a means to define the names and types of all the template parameters in a structured format. Once that's defined, whenever you add an infobox or other template, you can use TemplateWizard or VisualEditor and it will be much easier to figure out how to add an image. You won't even need to know what the parameter is actually called (be it image, image_2 or cover, etc.). This is the best solution we can offer for the time being.

    I think your proposal is well written, but unfortunately it is essentially asking for global templates which we cannot feasibly accomplish. So, I'm going to archive this proposal, but thank you very much for participating! If you have any other ideas, please don't hesitate to propose them :) MusikAnimal (WMF) (talk) 22:36, 20 November 2020 (UTC)[reply]

User contributions watchlist

NoN Declined in a previous survey

  • Problem: Many users would like to be able to see what a friend of theirs or adoptee has been editing recently. Or maybe a vandal hunter would like to be alerted whenever a certain vandal edits again so they can revert them or report them to aiv.
  • Who would benefit: Vandal hunters and friends who want to casually check up on each other from time to time without having to go to their contributions page.
  • Proposed solution: A way to watchlist a user's contributions; either a separate watchlist from the one we already have or an option to be put into the existing watchlist.
  • More comments: This may make it easier for someone to stalk another's edits, but it also greatly decreases between reporting times of vandals.
  • Phabricator tickets:
  • Proposer: Ghinga7 (talk) 03:18, 17 November 2020 (UTC)[reply]

Discussion

  • Ah, ok then. I think that the argument that the harassment argument is like saying we shouldn't have watchlists because it facilitates ownership, but whatever. Thanks for informing me of the past discussion. As a quick question, @User:MusikAnimal (WMF), would I still be allowed to bring this up at, say, the english wikipedia village pump? I understand that the foundation won't back it, but what about a specific language wikipedia? Best regards, Ghinga7 (talk) 03:52, 17 November 2020 (UTC)[reply]

NoN Does not require engineering resources

  • Problem: Links on wikipedia can be difficult to understand if you are new to tech and such. I feel like the names should be easier to understand. People of foreign languages should also be able to have a "wiki" for that language.
  • Who would benefit: Editors
  • Proposed solution: Create easier link options and names
  • More comments: None
  • Phabricator tickets:
  • Proposer: MemeGod27 (talk) 17:36, 17 November 2020 (UTC)[reply]

Discussion

  • @MemeGod27: Could you give some specific examples? Are you talking about linking to pages on other wikis, or links to external websites? Is it the syntax that you find confusing, or something else? MusikAnimal (WMF) (talk) 17:49, 17 November 2020 (UTC)[reply]
    @MusikAnimal: What I meant was renaming links for the "sidebar". Sorry. User:MemeGod27 17:52, 17 November 2020 (UTC)[reply]
    @MemeGod27: No need to apologize! :) Administrators on any wiki can customize the sidebar links. Can you give an example of some links you find confusing? Administrators on your wiki may be able to fix it. MusikAnimal (WMF) (talk) 05:02, 18 November 2020 (UTC)[reply]
    @MusikAnimal: Thanks! I'm "kind of" new to wiki things but i've been coding and "teching" for a while now. I think it would just be easier for people who are newer to tech to be able to understand the terms on the sidebar. Also, I feel like a few people are going to have no idea what "movement affiliates" means. :) Stay Safe! User:MemeGod27 9:46, 18 November 2020 (UTC)
    When it comes to a term like "movement affiliates" that's a complex concept which needs to be learned to understand it. You can access the Wikidata description by clicking on the link and then on Wikidata item. The Wikidata description of the term is 'organization registered as a part of the Wikimedia community'. Does that help you with understanding it?
Wikidata also has some descriptions in a few other languages. ChristianKl ❪✉❫ 12:03, 20 November 2020 (UTC)[reply]
  • Okay! Thanks! MemeGod27 9:52, 23 November, 2020 (EST)
  • Per above, the sidebar is configurable by wiki administrators. If there is confusion with what these links mean, it should be brought to the attention of the local community since they have control over it. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 17:18, 3 December 2020 (UTC)[reply]

Automatic nomination of images as quality images if they are used very often (Nominate this image for QI)

Deutsch: Automatische Nominierung von Bildern als Qualitätsbild, wenn diese sehr häufiger verwendet werden (Nominate this image for QI)

NoN Requires community consensus

  • Problem: Frequently used images are usually valuable / high quality, but are not always marked as quality images.
(Deutsch): Häufig verwendet Bilder sind meist wertvoll/hochwertig, sind aber nicht immer als Qualitätsbilder gekennzeichnet.
  • Who would benefit: Everyone who is looking for high quality pictures
(Deutsch) Wem würde dieser Wunsch helfen: Allen die hochwertige Bilder suchen
  • Proposed solution: I would like to suggest automatically nominating images as quality images if they are used very often. In my opinion, a frequent use is an indication that the picture is "valuable".
(Deutsch) Lösungsvorschlag: Ich möchte vorschlagen, Bilder automatisch als Qualitätsbild zu nominieren, wenn diese sehr häufig verwendet werden. (Eine häufige Verwendung ist aus meiner Sicht ein Hinweis darauf, dass das Bild „wertvoll“ ist.
  • More comments: Perhaps a threshold of around 20 uses would make sense?
(Deutsch) Weitere Kommentare: Vielleicht wäre eine schwelle von ca. 20 Verwendungen sinnvoll?

Discussion

  • I don't like this award system. My pictures shouldn't be rated there. So I am clearly and vehemently against automatism. -- Marcus Cyron (talk) 19:49, 16 November 2020 (UTC)[reply]
  • Currently according to c:Commons:Quality images and c:Commons:Image guidelines, Quality Images are mostly about technical merit and less about how often they are used. I think it would be very challenging to write automation to detect what humans consider "quality", but even if we could, we first need widespread support from the Commons community. As such, I'm declining this proposal. Thank you for participating in the survey! MusikAnimal (WMF) (talk) 20:33, 16 November 2020 (UTC)[reply]
  • My wish is not the automatic decision. My wish is only the automatic suggestion. (I do not assume that the decision about quality images is made by humans and not by algorithms!?). (Deutsch: Mein Wunsch ist nicht die automatische Entscheidung. Mein Wunsch ist nur das automatische Vorschlagen. (Ich gehe nicht davon aus, dass die Entscheidung über Qualitätsbilder von Menschen getroffen wird und nicht von Algorithmen!?)) --Molgreen (talk) 18:00, 17 November 2020 (UTC)[reply]

Presentation template

  • Problem: There is no up to date, nicely formatted shared presentation template in our movement that I'm aware of (at least not in English). Instead, everyone, including people making presentations on behalf of affiliates, has to come up with their own. While there are many, many approaches to presenting and teaching Wikipedia and there is no one "correct" way to do it, trainers and advocates would save time by having a baseline reusable presentation that they could adapt for their own individual talks on. The WMF has a communications team - but none of the rest of us who are not affiliated with WMF get the benefit of their professional design and communication skills, and the vast majority of outreach in our movement is done by volunteers, who have varying levels of skill with design.
  • Who would benefit: Everyone who does outreach for Wikimedia projects, including trainers, educators, and affiliate members, including people who are newer to the Wikimedia movement but find themselves giving trainings (like librarians and educators).
  • Proposed solution: A kit that could consist of some accessible slide templates and guidance on where to find information, in several parts: background on Wikimedia, Wikipedia editing, Wikidata editing, etc., with text fields clearly delineated and a textual script for ease of translation. Information guidance could include for instance where to draw updated statistics from -- this would be so the slides would not go out of date as quickly. Other slides could be practical - well-formatted screenshots of inserting a reference, for instance. All of this could be part of my other proposal, the events kit, as well, or a stand-alone project. Putting in the effort once to make a nicely designed, well-formatted, accessible and multi-lingual friendly template would save hundreds of hours of effort for outreach volunteers.
  • More comments:
  • Phabricator tickets:
  • Proposer: phoebe | talk 17:05, 29 November 2020 (UTC)[reply]

Discussion

Hello, phoebe! Thank you for submitting this wish. Unfortunately, we will be archiving this wish, since it is out of scope and more content-related (rather than a technically-focused problem for us to solve through software solutions). However, if you do want help in creating presentation templates, there are some resources and slides on Commons that may be useful to you (such as Category:Wikimedia_presentations). You may also find some help or resources provided by the Community Programs team. Thank you again for proposing this wish! IFried (WMF) (talk) 23:29, 2 December 2020 (UTC) [reply]

To see how many people are reading the article

NoN Outside the scope of Community Tech / needs legal approval

  • Problem: A number to see how many people are reading the current article
  • Who would benefit: An individual that wants to see the popularity of a certain article
  • Proposed solution: A little number that is updated - say once every 5 seconds or so.
  • More comments: The number can be on the top of the page in a corner
  • Phabricator tickets:
  • Proposer: PittsburghPlays (talk) 00:35, 18 November 2020 (UTC)[reply]

Discussion

  • [User: PittsburghPlays] Thanks for your reply EDG 543... Yes I am aware of this setting. I also acknowledge that we don't really need it but it would be cool in a way to see the number of people on the article.
  • I believe a live update of the number of people reading the article might not be the best way to indicate it's popularity. Instead, when the web page is loaded, it should show the total number of times the article has been read. James Goner (talk) 04:58, 18 November 2020 (UTC)[reply]
  • Perhaps showing the popularity of an article might not be a conventionally popular feature for an encyclopedia. James Goner (talk) 04:58, 18 November 2020 (UTC)[reply]
  • No offense, but this sounds like “gamification” of a serious business. And I’d really not like to see such a feature (enableable) on certain articles, like en:Suicide or the most-recent terror attack, you know what I mean? The viewing statistics EDG 543 mentioned above are OK, but a “right now” metric is really unnecessary. Kays (talk) 23:25, 20 November 2020 (UTC)[reply]
  • I'm fairly certain this would need legal sign-off and community consensus before we could ever implement it. Regardless, the scope is far too large for our team. We don't have the infrastructure to support this sort of real-time analytics. As such I'm archiving this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 04:32, 3 December 2020 (UTC)[reply]

Dictation tool

NoN Outside the scope of Community Tech

  • Problem: sometimes you have to type a lot, when you could dictate it.
  • Who would benefit: every editor
  • Proposed solution: similar to WhatsApp dictation and other tools
  • More comments:
  • Phabricator tickets:
  • Proposer: BoldLuis (talk) 10:15, 19 November 2020 (UTC)[reply]

Discussion

  • I'm curious, but aren't there any dictation tool (that isn't run by the foundation) already available in source code? Or it you mean to provide some sort of dictation tool in the Visual Editor? Also, as far as I know, some languages cannot have dictation tool (read: Chinese and its derivative languages)--1233 （T / C） 18:02, 19 November 2020 (UTC)[reply]
  • I don't see this as a priority. The major computer platforms have a free dictation tool which works quite well, there are also other proprietary free and pay-for solutions. What I do is work off-Wiki and copy and paste the result. Kudpung (talk) 02:14, 21 November 2020 (UTC)[reply]
  • I agree that this is not a priority. You can use third-party's tools. Otherwise, probably only English speakers would benefit this tool, as the deployment for other languages would be very time consuming. — Draceane talkcontrib. 17:39, 24 November 2020 (UTC)[reply]
  • I would guess most device software supports this. Is there a particular device you are thinking about that doesn't support this? --Izno (talk) 05:18, 18 November 2020 (UTC)[reply]
  • Not the proposer, but I know my desktop PC doesn't have native voice typing options. However, I don't like this idea, due to the fact you cannot add wikitext options and voice typing is fairly unreliable. In my opinion, if you are going to editing a wiki, you should atleast dedicate enough time to look text over a few times to make sure there isn't any errors/etc. --JackFromReedsburg (talk) 16:00, 24 November 2020 (UTC)[reply]
  • We talked about this as a team, and decided it's too out of scope for us. Other companies (such as your phone/computer manufacturer) have poured millions of dollars into perfecting dictation tools. They are much better than anything we could ever build. We'd have to support as many languages as possible, with extensive training of the algorithms, etc. This would take many years for us to accomplish and again is redundant for (most?) many users as the hardware they use already supports it. For this reason we're going to archive this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 21:54, 30 November 2020 (UTC)[reply]

End of Year Sweepstakes for Those who Make Donations to Wikipedia

NoN Outside the scope of Community Tech

  • Problem: Not enough people are making donations to Wikipedia.
  • Who would benefit: Wikipedia would have more funds, and the sweepstakes winners would also benefit.
  • Proposed solution: Wikipedia should automatically enter anyone who donates to it into a sweepstakes that will be drawn at the end of the year. Cost, size, and quantity of prize(s) is entirely up to Wikipedia.
  • More comments:
  • Phabricator tickets:
  • Proposer: PyramidFan (talk) 15:24, 18 November 2020 (UTC)[reply]

Discussion

  • The sweepstakes would be entirely free to enter for people who donate to Wikipedia. It is similar to how nature preservation organizations will give you a free stuffed animal or tote bag if you donate to their cause. Note: Only those who make monetary donations would be eligible. PyramidFan (talk) 14:48, 20 November 2020 (UTC)[reply]
  • I do not have any sources that prove that Wikipedia is not getting enough donations. However, sometimes when I view a Wikipedia page, there is an ad at the top of the page asking for me to make a donation to Wikipedia. Besides, is it possible for Wikipedia to be receiving too many donations? The more donations that Wikipedia receives, the more events and projects it can fund. Maybe Wikipedia is only receiving enough donations for a couple events a year. But, with more donations, there can be more Edit-a-thons, and more events in general. PyramidFan (talk) 15:10, 20 November 2020 (UTC)[reply]
  • I'm afraid I'll have to archive this proposal as out of scope. This survey is about requesting technical changes the software you use, while what's being proposed here is more of a strategy decision for the Fundraising team. Indeed, as far as I know, we meet our fundraising goal every year, so I'm not sure problem statement is accurate. The banners you see soliciting for donations is the strategy the Fundraising team currently employs to get donations. It is not by itself an indicator that we are failing to meet the fundraising goals. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 19:49, 25 November 2020 (UTC)[reply]

Positive check on verified diffs

NoN Proposes existing feature

  • Problem: Today, when I check the diff of an edit on an article I watch, I can only undo it or thank the editor but, if the edit is valid, I have no way to indicate it to other patrollers. So, another user watching the same article will probably check the same diff later and waste his/her time to reach the same conclusion.
  • Who would benefit: Patrollers and in general any user who keeps articles on a watchlist.
  • Proposed solution: Add a button in the diff interface that "validates" or "endorses" the edit, only for users who meet certain criteria. Clicking the button would trigger several actions: 1) notify the user who made the edit; 2) add a tag to the edit in the article history saying "validated by User:..." and later on "validated by N users" (this can be tailored to show only your own validations); 3) for patrollers who enable the option, this would remove that particular diff from their to-do list.
  • More comments: A user should be held answerable for the edits he/she validates, so that the function is used with parsimony, only to flag unambiguously valid edits.
  • Phabricator tickets:
  • Proposer: Hispalois (talk) 23:12, 23 November 2020 (UTC)[reply]

Discussion

Automatic notification when there is a response on a talk page

NoN Outside the scope of Community Tech

  • Problem: One has to manually check whether talk page discussion have received responses, which can sometimes take weeks or longer.
  • Who would benefit: Editors engaging in talk page discussions.
  • Proposed solution: An option for a notification when a talk page on your watchlist gets edited.
  • More comments: It can be either an option for certain watchlist pages like noted above, or a special kind of watchlist (a 'follow discussion' option or something like that) which sends notifications. If it's the latter, then it could actually be extended to the articles themselves, as well.
  • Phabricator tickets:
  • Proposer: Keepcalmandchill (talk) 04:35, 17 November 2020 (UTC)[reply]

Discussion

NoN Outside the scope of Community Tech I want a tool that can find the shortest way between two articles. --Villy Fink Isaksen (talk) 14:23, 24 November 2020 (UTC)[reply]

Discussion

  • (På dansk) Hej Villy. Vil du være rar at uddybe forslaget. Hvilket problem skal det løse? Hvem vil det gavne? Hvad mener du med den korteste vej mellem to artikler? Du må gerne bruge dansk hvis du ikke er fortrolig med engelsk, så vil andre oversætte for dig. --Dipsacus fullonum (talk) 16:53, 24 November 2020 (UTC)[reply]
  • (In English) Hi Villy, please elaborate on the proposal. What problem will it solve? Who will benefit? What do you mean by the shortest path between two articles? You are welcome to use Danish if you are not familiar with English, then others will translate for you. --Dipsacus fullonum (talk) 16:53, 24 November 2020 (UTC)[reply]
  • (På dansk) Det kan være et værktøj til at undersøge forbindelser (links) mellem artikler. Dette vil sikkert blive betraget som unødvendigt og for teoretisk. Men jeg mener det kan bruges til at forbedre sammenhængen mellem artikler på Wikipedia.

Med den kortest vej mener jeg via link mellem de færreste artikler.

Outputtet skulle gerne være en række artikler der link til hinanden. --Villy Fink Isaksen (talk) 21:14, 24 November 2020 (UTC)[reply]

  • Translation of Villy Fink Isaksen's reply above made by Dipsacus fullonum (talk) 12:43, 25 November 2020 (UTC):[reply]
    It can be a tool to explore connections (links) between articles. This will presumably be considered unnecessary and too theoretical. But I think it can be used to improve the coherence between articles on Wikipedia.
    By the shortest path I mean via link between the fewest articles.
    The output should be a series of articles that link to each other.
@Villy Fink Isaksen: There's an external website that I believe does this at https://www.sixdegreesofwikipedia.com. Vahurzpu (talk) 03:51, 26 November 2020 (UTC)[reply]
Thanks Vahurzpu - but this is probably only in the english Wikipedia it works. --Villy Fink Isaksen (talk) 07:49, 26 November 2020 (UTC)[reply]

Make article browsing more visual

Withdrawn by proposer

  • Problem: Most of us are contributing to the Wikimedia movement to share factual information, which we do most effectively by written text and a lot of references. However, our readers now expect something different: they want to visit a visual-rich website that shows them the topic as well as describing it. In the past we had the problem that we didn't have many photos to illustrate our articles, but that has now changed thanks to contests like Wiki Loves Monuments. We could now have articles that are much more visual than they currently are: do we want to do that?
  • Who would benefit: Readers of articles
  • Proposed solution: Rework the default article display to be more media rich
  • More comments: Technical changes can be implemented by WMF, but this would need community consensus before releasing.
  • Phabricator tickets:
  • Proposer: Mike Peel (talk) 20:24, 27 November 2020 (UTC)[reply]

Discussion

Add a visual editor to the talk page

NoN Proposes existing feature / out of scope

  • Problem: There isn't a visual editor for the talk page
  • Who would benefit: Everyone who uses talk pages and the visual editor
  • Proposed solution: Add a visual editor
  • More comments:
  • Phabricator tickets:
  • Proposer: Tokerjoker5000 (talk) 17:21, 17 November 2020 (UTC)[reply]

Discussion

  • @Tokerjoker5000: Have you seen the new Discussion Tools feature? It's not on English Wikipedia yet but it should before too long, I believe. You can try it out here on Meta at Special:Preferences#mw-prefsection-betafeatures. After enabling, you should see a [reply] link to every comment which allows you to use the VisualEditor. MusikAnimal (WMF) (talk) 17:34, 17 November 2020 (UTC)[reply]
    • The question is, how long it'll survive. There have been several attempts to deploy special software to discussion pages, but most of them have failed or haven't survived. The question also is, whether it's not confusing to have a different editor for the main page and a different editor for talk pages for newbies. Juandev (talk) 20:05, 21 November 2020 (UTC)[reply]
      I assume Discussion Tools will have some longevity given the heavy involvement with the community during the planning process, and the multi-year, incremental improvements which are still underway. I personally think it's a major step forward for newbies; VE on content pages shouldn't act the same as interacting in discussions. Discussion Tools tries to answer that need without overdoing it. My opinion, of course :) At any rate, I'm fairly certain VE as you know it will not be enabled on talk pages. This is based on mw:Help:VisualEditor/FAQ and phab:T151854 (there are other tasks too, I'm sure). MusikAnimal (WMF) (talk) 22:20, 21 November 2020 (UTC)[reply]
  • @Tokerjoker5000: This is kind of implemented with the reply-link.js script that Enterprisey wrote. It doesn't have keyboard shortcut support that Discussion Tools has, but it (for the most part) works well on talk pages and usually avoids edit conflicts. It's not an immediate WYSIWYG editor, but it comes with a preview button so that editors can see what their comments look like when properly rendered. Tenryuu (talk) 04:13, 24 November 2020 (UTC)[reply]
  • @Tokerjoker5000: Since we haven't heard back from you, I'm going to archive this proposal for the time being. See above comments for more; VE will not be enabled on talk pages, unfortunately. However Discussion Tools will be coming to all wikis (I'm not sure when), and it allows you to use VisualEditor when replying to comments. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 20:41, 24 November 2020 (UTC)[reply]

Permit Embedding of Images

NoN Needs consensus and/or proposes a legal change rather than a technical feature

  • Problem: Thousands of pages on Wikipedia contain old images, few images, or no images at all. For many, visuals are an important part of understanding a subject, due to the unfortunate dilemma that Creative Commons-licensed photographs of many subjects are hard to come by.
  • Who would benefit: Anyone who reads articles on Wikipedia.
  • Proposed solution: Allow users to HTML embed external images in articles on Wikipedia. Though this would not add to the Wikimedia Commons library of CC-licensed images, it would significantly improve the average user's experience on Wikipedia. Getty Images allows for over 66 million images in its library to be embedded onto non-commercial websites - that alone would more than double the number of images able to be used in articles (at the time of writing this, ~62 million images are in the Wikimedia Commons library).
  • More comments: Information about Getty's embed program: https://www.gettyimages.com/resources/embed
  • Phabricator tickets:
  • Proposer: Boomerthebobcat (talk) 04:41, 17 November 2020 (UTC)[reply]

Discussion

Oppose because abuse are possible. --ComputerHotline (talk) 07:44, 17 November 2020 (UTC)[reply]

@ComputerHotline: Small note that we are not in voting phase... Suggest just listing this as a comment. —TheDJ (talk • contribs) 11:52, 17 November 2020 (UTC)[reply]
@Boomerthebobcat:In my understanding, implementing this proposal would violate the privacy of everybody opening a page with such an external image, as your personal identifiable information will be sent to the server on which that external image is hosted. Furthermore, content must be either under a free license, or their must be an Exemption Doctrine Policy in place, because Getty Images content is not free by definition. --AKlapper (WMF) (talk) 13:55, 17 November 2020 (UTC)[reply]
@Boomerthebobcat:This would be very dangerous. Imagine this: I link to a very benign image on my server, but after a while I change the image (there) to something else - extremist propaganda, offensive image, a virus - you name it. This should never happen!

Global bots userright

NoN Proposes an existing feature / requires community consensus

  • Problem (minor): Not all wikis have a bot for fighting vandalism, some wikis like enwikipedia do, (ClueBot NG), but we don't have to assign bots to every wiki registered, which is why we can program the bot on Meta so it can work for all wikis. ClueBot NG isn't the only way we can use GB for, we can use a bot to use Checkuser for spam-only accounts, vandals, or other suspicious activity. I think this can be useful to cut time. It isn't a really bad problem, but it would be nice to have that idea implemented.
  • Who would benefit: Every wiki in WMF
  • Proposed solution: To add the userright
  • More comments: I bet this will get rejected GeometryDashFan12 (talk) 19:10, 17 November 2020 (UTC)[reply]
  • Phabricator tickets:
  • Proposer: GeometryDashFan12 (talk) 19:10, 17 November 2020 (UTC)[reply]

Discussion

Dark mode on desktop

NoN Declined in a previous survey

  • Problem: Reading the actual mode (bright) in the night or in a dark place is uncomfortable.
  • Who would benefit: Desktop users
  • Proposed solution : Switching (automatically or manually) to a "dark" mode

Discussion

Implement a checkbox saying "I need my plaintext code editor"

NoN Outside the scope of Community Tech

  • Problem: Once every few years well-meaning improvement teams take steps to reduce or remove the ability to edit a Wikipedia article or talk page using nothing but plain text, where wiki markup is fully visible and editable.
  • Who would benefit: Everyone who would feel a WYSIWYG editor would only get in the way; everyone who prefers full control over "user friendly" interfaces
  • Proposed solution: In Preferences, create a checkbox (initially unchecked is fine), that if checked, ensures that no amount of "improvements" to the WikiVisuals or editors are ever enabled. The user retains full and immediate access to the fast and efficient plaintext wiki markup editor with no hoops to jump through, no welcome messages to "easy" editing, and every opt-out immediately done on a permanent basis
  • More comments: You might wonder why a checkbox is needed and this is because the last time I suggested the plaintext editor was retained, my suggestion was immediately archived on the technicality "Does not propose a technical change". So I am proposing a technical change.
  • Phabricator tickets:
  • Proposer: CapnZapp (talk) 11:29, 18 November 2020 (UTC)[reply]

Discussion

  • I think you can immediately archived this request on the technicality "Does not propose a technical change" or because the request isn't serious in lot of way... Nouill (talk) 02:09, 19 November 2020 (UTC)[reply]
  • I fully understand the sentiment and sympathize with your frustration. But as I said in the other proposal, the focus here is to find things for Community Tech to work on in the upcoming calendar year, as explained in our documentation. We cannot implement a "freeze software development on this part of the codebase" checkbox. We (Community Tech) cannot guarantee this because software is always evolving, and we don't control the direction of MediaWiki. Community Tech is happy to make improvements to the existing plaintext editor, however (though I think the desire is to have no "improvements", which is okay :). There were definitely some controversial changes to the old wikitext editor that were deployed in late 2018. I can say on behalf of the responsible teams that lessons were learned. Like you, some people came to the Wishlist Survey looking for immediate fix, overlooking the scope was for a single product team who expressly does not undo or stomp on the work of other teams. This is not to put them down, or you down. I hope it's understandable why there's little reason to let this proposal sit here, as it seems more political in nature than an actionable proposal, and likely to attract unwanted drama. In your proposals, please try to focus on ways Community Tech can improve or build upon the software you use – that's what the survey is for. Kind regards, MusikAnimal (WMF) (talk) 23:59, 19 November 2020 (UTC)[reply]

Re-enable machine translation to English for experienced users

NoN Requires community consensus

  • Problem: Machine translations are not enabled when translating to English.
  • Who would benefit: Editors who wish to translate content to English.
  • Proposed solution: Allow machine translations for editors with a certain level of experience.
  • More comments: I understand why the machine translations were disabled, as there was just too much junk being passed on without any critical judgement. But a blanket ban goes too far in the other extreme. Instead, just set a reasonable level of experience needed to employ this tool responsibly.
  • Phabricator tickets:
  • Proposer: Keepcalmandchill (talk) 03:58, 17 November 2020 (UTC)[reply]

Discussion

User:MusikAnimal (WMF), a translation admin, said it was appropriate. Keepcalmandchill (talk) 05:25, 18 November 2020 (UTC)[reply]
This is interesting, as afaik, it was an en-wiki decision to disable it, rather than an inherent tool decision (that is, were en-wiki convinced to change its mind, it could just be set at that level), which would indeed make it out of scope. Nosebagbear (talk) 14:51, 18 November 2020 (UTC)[reply]
My apologies. I obviously didn't read this closely enough! Indeed this is entirely up to the English Wikipedia. As I understand it, it doesn't actually require engineering resources, anyway. You just needs consensus. As such, I'm going to archive this proposal. Keepcalmandchill, your allow footnotes in VE proposal has not been archived yet (along with the other two), so you've still got three proposals :) Hope this is okay, MusikAnimal (WMF) (talk) 01:14, 20 November 2020 (UTC)[reply]
MusikAnimal (WMF) No worries! I actually submitted another proposal with the expectation that the footnotes one would be withdrawn, so you can go ahead and archive that too. Cheers, Keepcalmandchill (talk) 08:38, 20 November 2020 (UTC)[reply]

Text layout on desktop that is not like www of 1990s

  • Problem: Default text layout on wide screens looks like www of the 1990s. Long line lengths (should never be more than ~120 chars) Images of all sizes, on all sides, text squeezed in between. Desktop desperately needs a makeover.
  • Who would benefit: Modern readers
  • Proposed solution: Majority of readers are anonymous, make Vector skin default for all. WP:BEBOLD. Limit en:line length. Put images in the right margin, if too big allow part of them left of the margin; allow few predefined image widths, or any width but with some additional effort.
  • More comments: Some good ideas here: https://en.wikipedia.org/wiki/User:TheDJ/responsiveContent. Wiki pages look better on wikiwand too.
    Update 2020/11/21: I've received a message from Web team, some changes are underway. Hopefully all wikis will get them soon, I think it's high time. I would be happy to see support here for the changes they have planned.
  • Phabricator tickets:
  • Proposer: Ponor (talk) 06:45, 17 November 2020 (UTC)[reply]

Discussion

This is already being worked. Go to Special:Preferences#mw-prefsection-rendering and uncheck "Use Legacy Vector". In some wikis is already default. -Geraki TL 09:52, 17 November 2020 (UTC)[reply]

@Ponor: As per guidelines, "Proposals should be discrete, well-defined tasks". I personally don't think that this one classifies in its current state. --AKlapper (WMF) (talk) 13:47, 17 November 2020 (UTC)[reply]
@AKlapper (WMF) and Geraki:"Good design sells product", that's why I think this is very important. Most readers on WP are, I believe, guest/anonymous users, so it doesn't really matter for them if there are options to change this or that, somewhere. Yes, Vector skin is a step in the right direction, but en:line length should still be shorter. And I'm proposing the images be put in the margin, scaled to a predefined width (or one from a set of predefined widths). Please log out and tell me if this looks like a decent, modern encyclopedia article or a scrapbook: STM (old rev). As to the actions: limit line width, put images in the margin, make articles on desktop look as good as articles on mobile or in the app. Ponor (talk) 14:58, 17 November 2020 (UTC)[reply]
@Ponor: I did not argue whether things could look better or not. I argued about the scope of this very Community Wishlist proposal. It seems that your reply misses my point. :) --AKlapper (WMF) (talk) 19:38, 17 November 2020 (UTC)[reply]

Implement Artificial intelligence.

NoN Outside the scope of Community Tech

Discussion

  • Hello VasilijB! Could you elaborate on what you're proposing? What is the problem you're trying to solve, in what way do you feel artificial intelligence could help? Вы можете ответить на русском, если хотите. MusikAnimal (WMF) (talk) 21:21, 18 November 2020 (UTC)[reply]
    Как известно, Искусственный интеллект может самостоятельно разыскивать нужную информацию в интернете. Если информация, взятая из разных источников (сайтов), окажется противоречивой или не полной, Искусственный интеллект может самостоятельно из других источников уточнить неполную информацию и объяснить причины её искажения в некоторых источниках. Надо позволить Искусственному интеллекту править статьи в Википедии, наравне со всеми редакторами.
    (English): As you know, Artificial Intelligence can independently search for the necessary information on the Internet. If the information taken from different sources (websites) turns out to be contradictory or incomplete, Artificial Intelligence can independently clarify the incomplete information from other sources and explain the reasons for its distortion in some sources. We need to let Artificial Intelligence edit Wikipedia articles as well as all editors. — The preceding unsigned comment was added by VasilijB (talk)
    I think the idea is great, but I can say with confidence that this proposal is too broad for the Wishlist Survey. The free-form style of wikitext would make it incredibly difficult to automate fact-checking. Furthermore, we'd need consensus to ever allow machines to decide what is factual. For these reasons, I'm going to archive this proposal as out of scope. Thanks for participating in the survey!
    (русский): Я думаю, что идея отличная, но могу с уверенностью сказать, что это предложение слишком широкое для обзора списков желаний. Свободный стиль викитекста сделал бы невероятно сложным автоматизацию проверки фактов. Более того, нам потребуется консенсус, чтобы когда-либо позволить машинам решать, что является фактом. По этим причинам я собираюсь заархивировать это предложение как выходящее за рамки. Спасибо за участие в опросе! MusikAnimal (WMF) (talk) 23:19, 19 November 2020 (UTC)[reply]

Organize some years the Community Wishlist Survey by language

  • Problem: This year is the 6e edition of the Community Wishlist Survey. The 4 first edition have the same format. The fifth edition (Community Wishlist Survey 2020) focus on others projects than Wikipedia. I think it's a good idea to diversified the edition of the Community Wishlist Survey and to propose a edition that have category by language, where contributors can propose wish and speak with their own language.
Community Wishlist Survey permit to use others languages that English but the vast majority use English because if you want to have your proposition win, you need to be understand to all the voters, and for that you have to use English. Moreover it's permit to show problematic which don't be report in others medium like fabricator, which are also in the vast majority in english, and which have the same problematics.
Organize the Community Wishlist Survey by language for one or few editions, permit also to show strong problems specific to some wiki which can't be see on a global survey. In the present, all the wiki, and the wikipedia don't have the same editor (some use the visual editor with the wikicode editor, others use only the wikicode editor), don't use wikidata in the same way (some permit the use of wikidata in the infobox, some don't), don't use the maps on the same way, etc. For example : wp:fr have by default (for all the readers) a beta skin since few month, but it's useless to propose something on it, when the majority of wiki don't know this skin.
  • Who would benefit: All contributors who can't contribuate or read English.
  • Proposed solution: Organize the Community Wishlist Survey by language for one edition.
  • More comments:
  • Phabricator tickets:
  • Proposer: Nouill (talk) 14:52, 21 November 2020 (UTC)[reply]

Discussion

Сталкивался с языковой проблемой неоднократно.После фотоконкурсов WLM и WLE приходят предложения пройти опрос.Переходишь по ссылке и что видишь? Четыре международных языка:Английиский,Украинский(?),Французкий и Итальянский.Неужели русскоязычных так мало или их мнение не интересует?--Yan.gorev (talk) 06:34, 22 November 2020 (UTC)[reply]

To zní zajímavě, ale když nebude TechTeam rozumět návrhům, jak na nich může pracovat -) ? JAn Dudík (talk) 11:44, 25 November 2020 (UTC)[reply]

  • We agree more work needs to be done to make the Survey more accessible to non-English speakers. In addition, we can introduce means to give focus to proposals that are from non-English communities that otherwise wouldn't have the "voting power" to perform well with global wishes. This is something we already do, actually. So please, propose any technical wish you'd like, in any language :) Having few votes doesn't mean it won't happen. Since this proposal does not propose a technical change, I'm going to archive it. But thank you for participating in the survey and highlighting the need to assist non-English users :) We hear you! Kind regards, MusikAnimal (WMF) (talk) 22:24, 2 December 2020 (UTC)[reply]

Inadequate knowledge and grudges should be evaluated before an action

NoN Proposes a social/policy change rather than a technical feature

  • Problem: Personal grudges and inadequate knowledge and playing politics in organization
  • Who would benefit: Everyone of WMF family
  • Proposed solution: Not all editors or admins/patrollers are alike. Some of us are as real as we are, so shouldn't judge it from personal enmity, grudges. Our motive should be limited to abide by the protocols not to use these as weapons. To create a page with all references for an ECU like me may take 10 to 15 days or may be more but it can easily move in 1 minute by an admin. What kind of evaluation can be done in 1 minute? So it's absolutely important to recheck our strategies.
  • More comments:
  • Phabricator tickets:
  • Proposer: Raavimohantydelhi (talk) 08:00, 21 November 2020 (UTC)[reply]

Discussion

How can a person delete or move a page within 1 minute of publishing it? Is it evaluated in a proper way? No, one should need at least 6 to 10 min to read it and understand the topic and may ask the editor to rework it. How to stop admins/editors/others to delete pages without nomination. How can one play politics when comes to power? How to figure out such people and ban these activities. I am delighted and grateful to many admins who supported me throughout my Wikimedia journey but still, I have experienced a lot of meaningless issues created by some powered admins or patrollers.

This doesn't seem to be a request for a technical software change —TheDJ (talk • contribs) 12:24, 21 November 2020 (UTC)[reply]
Seems to me to be part of a general reputational problem, but TheDJ is correct to say that it lacks a "technical software" change. In more general terms, I would describe the problem as Wikipedia having a high and well-earned reputation, but people with little or no reputation can exploit Wikipedia's reputation for various purposes, some of which are nefarious. I have written (within WikiMedia and elsewhere) at some length about a general solution approach that I called MEPR (Multidimensional Earned Public Reputation), but as far as I can recall there wasn't much evidence of interest or comprehension. The short summary is that we tend to be polite and trusting of strangers, but some people exploit that tendency. Because there are too many sources of information, I would prefer to favor the information that is coming from people who have earned positive reputations. In the Wikipedia context, that would suggest a (complicated) mechanism for multiple versions of articles, which is probably impractical, but which actually reflects the reality that different readers do have different objectives and actually would prefer to see different articles. Too much already said and we live in a TL;DR world these days, so... Shanen (talk) 03:45, 25 November 2020 (UTC)[reply]

As described above, this proposal does not invite any technical changes, which is what this survey is about (we realize this isn't very clear to everyone, and we'll improve the documentation for next year!). As such I'm going to archive this proposal. Kind regards, MusikAnimal (WMF) (talk) 16:31, 28 November 2020 (UTC) [reply]

Codigo de citas mismo lenguaje

NoN Outside the scope of Community Tech

  • Problema: Los códigos de citas son de distintos lenguajes a la hora de traducir es díficil insertar las citas.
  • A quiénes beneficiaría: A los traductores
  • Solución propuesta: Que el código de citas sea el mismo en todas las wikis así cuando se va a colocar la misma referencia del artículo que se está traduciendo sea más fácil y se pueda copiar y pegar, así también con las fichas, tablas, etc....
  • Más comentarios:
  • Informes de Phabricator:
  • Proponente: JesúsPeña074 (talk) 15:49, 17 November 2020 (UTC)[reply]

English

  • Problem: Citation template code varies across different languages, and it's difficult to insert citations when translating articles.
  • Who would benefit: Translators
  • Proposed solution: Make it so that citation template code is the same across all wikis, so that its easy to just copy and paste citations directly into articles being translated. This should also be done with infoboxes, tables, etc...
  • Phabricator tickets:
  • Proposer: JesúsPeña074 (talk) 15:49, 17 November 2020 (UTC)[reply]

Discusión

Correct wrong tenure lengths

NoN Outside the scope of Community Tech

  • Problem: Whenever an Age module template is used to find the length of time that someone currently in post has been in that post, the length of time stated in the article quickly becomes incorrect. This error happens a lot. For example, on the page wikipedia:First Minister of Wales, right now the term of office (in the table) for the incumbent Drakeford is given as '1 year, 337 days', even though the time between his appointment (13 Dec 18) and today (21 Nov 20) is actually 1 year, 344 days. Second example: wikipedia:List of justices of the Supreme Court of the United States. The tenure length for incumbent Coney Barrett is currently showing as 7 days, even though it's now 25 days. (Though there is a note stating the 7 days is 'As of 3 Nov', but I'm guessing most people won't read that, and anyway most articles with this problem don't have any such warning.)
  • Why the problem occurs: My understanding of the way Wikipedia works is that whenever any editor saves any change to the wikitext for an article, Wikipedia converts the whole article into HTML, and caches this HTML. Whenever any reader requests that article, this cached HTML is sent to them. The tenure length is therefore fixed until the next re-caching of the article, which is either at the next edit, or at the refreshing of cached copies which Wikipedia does randomly.
  • Who would benefit: Every reader of any article that uses any of the Age module templates for an incumbent.
  • Proposed solution: Every midnight, Wikipedia automatically re-caches into HTML any article that uses any of the Age module templates with only one date in the arguments. Alternative solution: Someone writes a bot to force those articles to re-cache (by saving those articles without making any changes or leaving any edit summary).
  • More comments:
  • Phabricator tickets:
  • Proposer: Mmitchell10 (talk) 20:51, 21 November 2020 (UTC)[reply]

Discussion

This is related to Community Wishlist Survey 2021/Categories/Set maximum delay in updating category membership. Jonesey95 (talk) 19:13, 22 November 2020 (UTC)[reply]

To illustrate how wide-spread this problem is, here's a few more examples of completely different types of article that also suffer this problem: wikipedia:List of popes, wikipedia:National parks of the United Kingdom, wikipedia:Ministry of Defense (Turkmenistan), wikipedia:List of prime ministers of the United Kingdom by length of tenure, wikipedia:Spouse of the prime minister of New Zealand, wikipedia:List of judges of the Supreme Court of the United Kingdom, wikipedia:List of presidents of France by tenure. Mmitchell10 (talk) 21:25, 26 November 2020 (UTC)[reply]
  • We agree this is a major issue that needs to be addressed, however the engineering challenges unfortunately are beyond the scope of our team. The short-term solution might be to create a bot to purge effected articles (there are several similar bots on English Wikipedia already, I think), but you can really only go so far before running into the same performance issues. The age module is used on over a million articles, and it's not the only module/template that suffers from this same issue. So as much as we'd like to, I don't think our team can help here :( Sorry! Thanks for participating in the survey, MusikAnimal (WMF) (talk) 00:55, 3 December 2020 (UTC)[reply]

Make sure the plain wikimarkup editor remains for use by "advanced" editors

NoN Does not propose a technical change

  • Problem: Once every few years well-meaning improvement teams take steps to reduce or remove the ability to edit a Wikipedia article or talk page using nothing but plain text, where wiki markup is fully visible and editable.
  • Who would benefit: Everyone who would feel a WYSIWYG editor would only get in the way; everyone who prefers full control over "user friendly" interfaces
  • Proposed solution: Make sure the plain wikimarkup editor remains for use by editors, and fully supported by the Wikipedia sites. Both for articles and talk pages. I don't mind if I have to go into Preferences and actively flip a switch, just as long as I can make a permanent one-time choice to have the current editor available and default. While I fully understand the benefits in attracting and retaining editors by more "user friendly" editing tools, let us agree that any type of such "friendly" editor also removes control, and makes Wikipedia life much much harder for those already used to "coding" rather than "writing" Wikipedia content (articles and talk pages).
  • More comments:
  • Phabricator tickets:
  • Proposer: CapnZapp (talk) 08:47, 17 November 2020 (UTC)[reply]

Discussion

  • It feels like to me that the WMF, developers, etc. cripple the wikitext editor in various ways inadvertently, or on purpose. Killing it by degrees. And then refuse to fix the problems they created. For example; removing, changing, restricting what goes in the various editing toolbars over time. Rather than give us wikitext editors more toolbar options, "they" impose whatever the developer consensus of the week decides to offer in the way of choices. So it is gradual destruction of the wikitext editor. I would like to be able to pick what tools I want in my wikitext editing toolbar. All of us are different. Other software allows such choices. Why not Wikimedia? In my Firefox browser I can choose the tools, addons, placement, locations, etc.. --Timeshifter (talk) 01:02, 18 November 2020 (UTC)[reply]
I support @CapnZapp:'s proposal for full control to opt out of the visual editor. Since I first started editing on Wikipedia, I have used plain wikimarkup. I've always wanted to be able to code but got put off trying to learn machine code for the ZX Spectrum, but now I appreciate how it stretched my mind. I never got to grips with the WYSIWYG visual editor, and have since become accustomed to the wiki-language. SpookiePuppy (talk) 01:11, 18 November 2020 (UTC)[reply]
  • It's my understanding that the plain wikitext editor (or a plain wikitext editor) will never go away, because VisualEditor doesn't support everything that can be done in wikitext, and also editing must be supported for users who don't have JavaScript. So I wouldn't worry about that. As for unwanted changes to the plain wikitext editor, that's not something we (Community Tech) can guarantee and I do not think the wishlist is the right place for this. A proposal in the survey should result in us doing technical work. This sounds more like the wish is that work should not be done (which is easy for our team, but impossible to promise indefinitely on behalf of the Foundation because we can't predict the future). For this reason I'm going to archive this proposal. However if there are problems with the plain wikitext editor that you would like to get fixed, we'll happily accept a proposal for it. Thanks for your understanding and participation, MusikAnimal (WMF) (talk) 01:46, 18 November 2020 (UTC)[reply]

Add month and year for quality score

NoN Proposes existing feature / out of scope

  • Problem: Quality scores in the talk page of articles in science may be very out-dated, but it is now not possible to easily see when the article was assessed. Now one has to go to the View history of the talk page to find out.
  • Who would benefit: anyone who reads the talk page and all those who would like to give the article a score
  • Proposed solution: add month and year to the Quality score box, just as the boxes/tags on the article page concerning e.g. "more references needed" or "this article is written as an essay".
  • More comments:
  • Phabricator tickets:
  • Proposer: Olle Terenius (UU) (talk) 16:15, 19 November 2020 (UTC)[reply]

Discussion

Yes, I talk about English Wikipedia. Not sure I understand your comments. When I look at the page https://en.wikipedia.org/wiki/Talk:French_battleship_I%C3%A9na as you referred to, there is only a date mentioned when the article appeared on the Wikipedia Main page, not when it became a FA. I also don't know how to "request these parameters be added to the template". --Olle Terenius (UU) (talk) 09:28, 24 November 2020 (UTC)[reply]
@Olle Terenius (UU): If you click "Show" next to "Article milestones" in that template, it will show important dates including when the article was promoted to Good and Featured status. I don't believe we currently track the dates of other Class ratings, but that would still be an on-wiki matter, not something that needs software development. the wub "?!" 15:38, 30 November 2020 (UTC)[reply]
Thank you. Since I still want this to happen for lower ranked articles, where should I request such a change? --Olle Terenius (UU) (talk) 11:08, 1 December 2020 (UTC)[reply]
  • A while back I updated a featured article which had gotten badly out-of-date with the research literature. There are many other languages that also have a featured article on the same topic, and they are similarly out-of-date (guessing from the sources), but I can't fix or even flag them outdated, as I don't know the languages and there are lots of them. I'd like to be able to tag all articles on topic X with no sources later than [date y] as outdated, cross-language. HLHJ (talk) 02:17, 24 November 2020 (UTC)[reply]
  • Per above, there are existing solutions for some of what's being requested, and the template changes should be made through community processes. As such I'm going to archive this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 22:02, 1 December 2020 (UTC)[reply]

Mobile format preview tool

NoN As pointed out below, this is already an experimental gadget

  • Problem: Most editing is done in Desktop view, but most readers are using either Mobile View or the mobile app, where elements are displayed differently.
  • Who would benefit: Most editors (particularly those working with large articles and or pages involving multiple images or tables) and all readers using mobile devices.
  • Proposed solution: An option to view how a page will appear on mobile devices. Selecting "mobile view" on a desktop browser is misleading as pages still display differently on desktop browsers to the way in which they appear on smartphones and tablets; this in turn misleads editors (whether using the wikitext editor or VisualEditor) who are unaware that elements such as large images, tables, or complex templates such as infoboxes are disrupting the display for readers or that images are being displayed in unexpected locations on mobile devices, and that on mobile devices much of the text is often hidden within auto-collapsed sections. On wikis with the RelatedArticles extension enabled it would also allow editors to confirm at a glance that the RelatedArticles suggestions being displayed to readers are appropriate, as at present there is no easy way to monitor this.
  • More comments:
  • Phabricator tickets:
  • Proposer: Iridescent (talk) 15:41, 19 November 2020 (UTC)[reply]

Discussion

Required Cleanup of Backlog

NoN Proposes social/policy change rather than technical feature

  • Problem: The oldest "citation needed" I've stumbled across in the wild dated back to 2006...for fourteen years it sat unfixed. Then I discovered w:Category:Clean-up categories from February 2001 is only almost empty, and w:Category:Clean-up categories from November 2010 has thousands backlogged. Our backlog of cleanup tasks is embarrassing
  • Who would benefit: Readers, academics that use WP as a resource
  • Proposed solution: Two possible solutions, (a) Require all Admin self-nominations to include 50 clean-ups that are more than a decade old, non-self nominations and renewals need to demonstrate 20 this year. The math should work out. (b) Require anyone banned even for 24 hours to perform 10-50 such cleanups based on the severity of the ban, to be unbanned.
  • More comments: How is this "Community Tech", you ask? Because you'll ideally want a bot-counter that tracks how many {{fact}} templates, etc a user has removed so they aren't left copy/pasting 50 diffs to each nomination, etc. Possibly like auto-mod it could even just be a switch that flips once they've done it (ensuring it only counts on unique articles not created by the user, etc)
  • Phabricator tickets:
  • Proposer: HaltlosePersonalityDisorder (talk) 03:43, 17 November 2020 (UTC)[reply]

Discussion

  • Yeah, this doesn't seem like comm tech at all. Counting contributions to backlogs is easy enough. Even were that not the case, forcing volunteers to do something still requires the community agreement a priori; Comm Tech's role is mostly to do good ideas that we've known about but haven't gotten around to. --Izno (talk) 18:11, 17 November 2020 (UTC)[reply]
  • I believe this would be better as an English Wikipedia proposal (on Village pump) and Comm Tech shouldn't be working on something that would not get community consensus once created. — Bilorv (talk) 18:13, 17 November 2020 (UTC)[reply]
  • @HaltlosePersonalityDisorder: Tackling backlogs is strictly a volunteer task, and imposing a requirement to work on backlogs is a social/policy change. Neither are appropriate for the wishlist. We can however help with tooling to assist in tackling backlogs. Would you like to reword your proposal to be just about the counting? As written we cannot accept this wish. We'll need some clarification on what technical issue you hope to see solved, or how you envision the process to work (however you still would need to convince English Wikipedia to adopt it). For example, we could expand the Citation Hunt tool to allow editing from within the tool and count your progress that way, or at least have a link to edit on Wikipedia and pre-supply an identifiable edit summary so that they can be counted via edit summary search. Best, MusikAnimal (WMF) (talk) 21:47, 17 November 2020 (UTC)[reply]
  • I also have to question how your math works out - on en-wiki you'd get perhaps 500 done a year through your admin route, which would be but a tiny fraction of the needed. I also question how positive a quality you'd get by turning it into a community service operation as part of unblocking. Nosebagbear (talk) 15:17, 18 November 2020 (UTC)[reply]
  • As we still haven't heard back from the proposer, I'm going to archive this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 17:28, 3 December 2020 (UTC)[reply]

Page create - competition

NoN Not a technical proposal

  • Problem: It´s not a problem, it´s that I would like Wikipedia to have a article-creating competition, like every year or month. It would encourage more people to contribute, to make Wikipedia bigger and better, and with more information. It would be in all the languages, so everyone can contribute, and make their language Wiki better (some languages only have, like, 300 articles)
  • Who would benefit: Everyone.
  • Proposed solution: To have a article-creating competition every six months or so, that accepts anybody who wants to. The contestants will, in their workshop, write a Wikipedia article that A) follows rules, B) is more than 500 words (or so), and C) is not already made. It can also be an article that was marked as a stub, but expanded to 600 words more (or so) by the contestants. The contestants would have a month to complete their page, and present it to the judges. How? Please comment, I am not at all sure. Anybody who wants to add to this idea, feel welcome!
  • More comments:
  • Proposer: G.L.Sirius (talk) 15:14, 18 November 2020 (UTC)[reply]

Discussion

G.L.Sirius, I think this would be a pretty good idea. By having them present their article to judges, it would keep people from just rushing and making a poor quality article just to "win" this competition. One thing that I would suggest would be that each new competition should have a different theme. For instance, one competition would have the participants create articles about Africa, and the next time they make an article about Women's rights, and the next time about Penguins, I don't know. But this would be a good way to have many editors focus on creating articles in an overlooked category that needs help. Thanks, EDG 543 (message me) 15:59, 18 November 2020 (UTC)[reply]

Thanks for your support, EDG 543!
I also think the theme stuff is a good idea.
I have also been thinking about what the "prize" should be, and I think one of the following would be good?
Barnstar
Some kind of "upgrade" in status
Just the nice feeling of having contributed and/or having won
Cash (I don't think so)
A present, like, a new camera, or Free Minecraft?
I really don´t know! G.L.Sirius (talk) 10:05, 20 November 2020 (UTC)[reply]
In fact, these "competitions" already take place (at the moment, it's "Wikipedia Asian Month" for example). What is the problem you would like to solve? Unless you point at them now, you can hardly get any help. --Matěj Suchánek (talk) 16:05, 20 November 2020 (UTC)[reply]
Already solved? There are dozens such competitions happening, some even have valuable prizes (if the corresponding Wiki chapter finds a sponsor). Some are aimed at a specific topic/subjects, some are focused on cleaning up and expanding stubs, some are meant for newbies etc etc etc. SSneg (talk) 21:35, 20 November 2020 (UTC)[reply]
I was coming here to say something similar @SSneg:-- I think the more central problem is the event calendar issue described by Ainali above, Sadads (talk) 22:40, 23 November 2020 (UTC)[reply]
You may want to link the event calendar issue because the bot shuffles the order and its relative position (above) can change. Matěj Suchánek (talk) 08:20, 24 November 2020 (UTC)[reply]

Create an open domain question answering interface

NoN Outside the scope of Community Tech

  • Problem: Many people look at Wikipedia to find the answer to one question (ie Who is the Queen of England? How many people live in Berlin? etc). Yet, Wikipedia has a very standard search engine to find documents.
  • Who would benefit: Readers
  • Proposed solution: It would be interesting to develop an open domain question answering engine to let users ask questions about Wikidata and find not only the good article but also the good answer.
  • More comments: Open domain question answering has now done lots of progress (See DRQA system or algo ranking at Squad)
  • Phabricator tickets:
  • Proposer: PAC2 (talk) 06:00, 17 November 2020 (UTC)[reply]

Discussion

Isn't that kind of what Abstract Wikipedia is trying to achieve? NMaia (talk) 10:16, 17 November 2020 (UTC)[reply]

Abstract Wikipedia is trying to generate comprehensive content using structured data. It's different from developing a natural language question answering engine. PAC2 (talk) 12:38, 17 November 2020 (UTC)[reply]

That sounds like it would be a very helpful feature, and would help eliminate cluttered chat through multiple different pages. NMaia and PAC2, you are right Wikipedia is always an encyclopedia at the core, but adding a community Q&A would help modernize it and bit and definitely help provide more information. A talk page is really created for this purpose, but it is more for editors and writers, vs a community asks questions are receive other answers as well as articles. KyGuy2002 (talk) 16:51, 17 November 2020 (UTC)[reply]

  • I think websites like StackExchange, Quora and Yahoo! Answers (outdated as some of them are) serve the Q&A purpose better and it's a bit out of scope for Wikipedia to add a Q&A feature. As for the original open domain suggestion, I fear this is far too difficult for the Wishlist scope - the issue is we have to come up with a very, very good search engine or none at all if we don't want to suffer reputational damage. — Bilorv (talk) 20:05, 17 November 2020 (UTC)[reply]
  • This is a good idea! I’m sure it’ll be very useful. +1. - Eric0892 (talk) 05:22, 18 November 2020 (UTC)[reply]
  • Moving from just providing search results to directly answering questions is what Google did with w:Knowledge Graph. I'm not sure we really want to compete with them on that, and it comes with a lot of thorny issues when you start needing to make judgement calls about questions like "which country is w:Crimea in?" {{u|Sdkb}} talk 03:20, 19 November 2020 (UTC)[reply]
  • These are very deep and complex products to build and will also require sustained maintenance after having build. This is very unlikely to be picked up by the team that will work on the wishlist projects.. —TheDJ (talk • contribs) 13:15, 21 November 2020 (UTC)[reply]
  • Indeed, this is a very fun idea but a mammoth project that could not feasibly be tackled by Community Tech. I think it would be a multi-year project for any team and would require a lot of community involvement. We appreciate the thought put into this proposal, but I'm afraid we'll have to archive it as being out of scope. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 02:22, 25 November 2020 (UTC)[reply]

Enable upload of web fonts for use on specific pages

  • Problem: Fonts for rare and historic scripts are not found by default on computers. As such, content in these scripts, including wikiquotes, articles on writing systems, etc. end up having content either inaccessible to the vast majority of readers or dependent on image files that obscure the textual nature of content.
  • Who would benefit: Readers of any articles with content in inadequately supported writing systems. Researchers running corpus studies on language use on Wikimedia projects.
  • Proposed solution: Enable the hosting of webfonts in file/media namespaces, and enable their use on content pages. Some features that would be necessary include:
    • Full glyph repertoire would need to be visible on file page to prevent trojan horse addition of bad faith glyphs through unrelated plain text rendered in the font.
    • Ideally the font page would enable a user to select glyphs and produce the plain text for a sequence of glyphs when rendered with that font.
    • For security and keeping page download sizes manageable, one webfont per page can be specified, and must be enabled by an admin or other limited access permission as decided by project.
    • Because of limited connectivity of some users, create a user preference to disable webfonts or require permission on page visit.
    • Creation of a custom XML tag, e.g. <webfont>... </webfont> for specifying blocks of text in a page to be rendered in the webfont.
    • Edit dialogue would need to display the name of the enabled webfont and ideally link to the file page for character selection; possible access via pop-up dialogue that inserts plain text in edit window.
  • Proposer: Vanisaac (talk) 02:49, 29 November 2020 (UTC)[reply]

Discussion

  • @SWilson (WMF): I am active on the writing systems wikiproject at en-wp and have contributed or maintained content on nearly every script in the Unicode standard / ISO 15924 from Armenian to Yi, and some writing systems with allocation in Private Use Area agreements (Braille Extensions, Klingon). I even work on scripts (Tocharian, Pitman Shorthand) that are not yet encoded either formally in Unicode or informally with a PUA agreement, although obviously plain text won't be possible until their encoding has been allocated. But I've never heard of the Universal Language Selector, and will take a look and see what's going on there. Vanisaac (talk) 02:43, 2 December 2020 (UTC)[reply]
  • @SWilson (WMF): I'm less concerned with proposing fonts than enabling them. From what I can tell, the ULS seems to be a defunct project only halfway complete - they created the system for editing, but then didn't make it available so that readers can see the result. Vanisaac (talk) 15:21, 2 December 2020 (UTC)[reply]
  • Now that I'm looking at it, it doesn't appear to have anything to do with content at all. It's just an interface tool. I'm looking to enable content to be displayed with webfonts. Vanisaac (talk) 15:43, 2 December 2020 (UTC)[reply]

Editathon events kit

  • Problem: New organizers of edit-a-thons have scattered and incomplete documentation to draw from; there is an ecosystem of events that copy one another's on-wiki formatting and style, but there are no up-to-date and complete guides that also have specific information on tool suggestions for different kinds of events (virtual, in person, single day vs multi day, first-time-editors, GLAM-affiliated, etc) and information on how to set up the logistics of each kind of events. For examples of guidance that does exist, look at Art+Feminism's project kits, which have successfully enabled many new organizers to run great edit-a-thons, reaching thousands of new editors. However, Art+Feminism's guides are topic-specific. For a new librarian, museum professional, or Wikipedian of any profession who wants to run an edit-a-thon, the directions they find on-wiki are unclear, tools are scattered across our projects, and training materials are out of date or non-existent (particularly in non-English languages). This is an issue of both an embarrassment of riches (everyone has made their own presentation) and not enough resources (things are out of date and hard to find). While approaches legitimately vary in how to teach people to edit, with different pedagogical goals and approaches (some trainers prefer to give more information, some prefer to take a hands-on approach) the mechanics of actually designing the editathon tend to be similar across events, but difficult to figure out the first time.
  • Who would benefit: Every organizer doing outreach and events would benefit; the attendees of events, particularly first time or newer editors who join edit-a-thons, would also benefit from getting better and more clear training. Experienced organizers and Wikipedians would also benefit, as many of us take on mentoring new organizers, and a good deal of this time could be saved by having a specific kit to point people to.
  • Proposed solution: I propose that the WMF create a translatable events kit, focused on the mechanics of running an editathon and geared towards organizers that would explain: how to plan an editathon, how to use available tools, and some possible approaches to running an editathon. Tools range from creating on-wiki pages, to the availability of grant funds (and how to apply), to the outreach dashboard. This basic framework could then be connected to different training approaches, presentations, and community-developed guides on how to actually conduct training in editing techniques. Community members could contribute to the events kit by suggesting topics, updates and adding additional documentation and resources, but the core materials would be well designed by professionals, tested for usability, accessibility and bias, and translatable and usable in many contexts.
  • More comments: Nothing like this has ever been created in my knowledge, even when we were building outreach wiki (a decade or so ago); the closest materials to what I'm thinking of were made several years ago by the Wiki Education foundation, which were focused on classroom education (but are still in hot demand by educators).
  • Phabricator tickets:
  • Proposer: phoebe | talk 14:59, 27 November 2020 (UTC)[reply]

Discussion

  • Hi phoebe, thanks for suggesting this wish. As the team that has worked on EventMetrics, we know how challenging it can be for organizers to put together high-impact edit events with the latest know-how around editing and contributing. So, we agree that having a set of best practices would be very valuable. However, the Community Tech wishlist is specifically a technical wishlist. This means that our team is looking for wishes that mean software changes to MediaWiki or other tools that are impossible or difficult for the community to do on its own. We don't feel this wish represents a technical wish even though it would clearly be helpful for the community. For that reason, I am archiving this wish. I notice you have other wishes and I appreciate your contribution. --AEzell (WMF) (talk) 23:02, 1 December 2020 (UTC)[reply]
  • Hi phoebe, I'm excited to provide an update that may interest you! The WMF now has a campaigns team, which will focus on building and improving tools for campaign organizers and participants. We will be a software development team, so we will be building out better support for events like edit-a-thons. We invite you to visit the project page for our first focus area (building a registration tool) and to provide your feedback on the project talk page. Thank you! --IFried (WMF) (talk) 14:52, 10 August 2021 (UTC)[reply]

Pageviews also in all languages

NoN Out of scope / does not require engineers

  • Problem: Only all English articles have a Pageviews link. Make a Pageviews link available for all pages in all languages.
  • Who would benefit: Everyone in all languages can then see the 'popularity' of any article.
  • Proposed solution: Technically Pageviews already works in all languages. The statistics in all languages are already collected and are available. Only the Pageview link has to be shown on all pages. It seems fairly easy to program.
  • More comments: For example this English page has a pageviews link under View history. But like the corresponing Nederlands/nl, Español/es, Català/ca and Deutsch/de do not have a Pageviews link. By simply changing en.wikipedia to nl.wikipedia in this hyperlink it simply works in any language like Català/ca, Deutsch/de, Nederlands/nl and Español/es.
  • Phabricator tickets:
  • Proposer: FlippyFlink (talk) 15:04, 18 November 2020 (UTC)[reply]

Discussion

The link is in fact added through modification of local wikis’ MediaWiki:Histlegend. You may ask interface admins on each Wikipedia to add the link in it. H78c67c (talk) 15:46, 18 November 2020 (UTC)[reply]

Thank you for your comment H78c67c. I asked the Dutch interface administrators just now. But I think it could/should also be a central coördinated effort to improve all Wikipedia languages with this feature. --FlippyFlink (talk) 16:16, 18 November 2020 (UTC)[reply]
I got a reply on how to manually enable it for only myself. I added #history-toolbox { display: block !important; } to my global.css. You can see the result here:before and after. --FlippyFlink (talk) 21:00, 18 November 2020 (UTC)[reply]
Great. But please refrain from editing others' comments in the future. Thank you. H78c67c (talk) 05:26, 19 November 2020 (UTC)[reply]
Sorry I added a hyperlink in your text. Won't do it again :-) --FlippyFlink (talk) 07:38, 19 November 2020 (UTC)[reply]

Support for the Commons App

NoN Outside the scope of Community Tech

  • Problem: There is no "offical" app for viewing and uploading material on Commons with your phone/tablet. The present Commons App (for Android) appears to be a private initiative and it could benefit from the collaboration of the Community. Read somewhere that the developer had given up on the IOS version because of costs demanded by Apple.
  • Who would benefit: Everybody who takes photos and wish to upload them to Commons. Everybody who wish to view illustrations on their mobile/tablet from Commons vast (and categorized) stock.
  • Proposed solution: The Community join forces with the current developer - if that is possible.
  • More comments: The app could benefit from extra hands. It breaks down sometimes and it does not act as advertized when you are not logged in as a Commons user. There would be a further enhancement to its value if the names of the categories were automatically translated - as suggested in another proposal for this year.
  • Phabricator tickets:
  • Proposer: Rsteen (talk) 09:20, 21 November 2020 (UTC)[reply]

Discussion

  • I second the need of an official app. What we have now is the one mentioned and also this other one, both made by the community but lacking of any support. EasyKL (talk) 19:10, 25 November 2020 (UTC)[reply]
  • The one at commons:Commons:Mobile app does seem to be actively maintained. I don't know that foundation-maintained apps are going to necessarily be more collaborative exercises than volunteer-maintained projects like this one. I'd hope the foundation could help with things like Apple Store fees via a grant application but it would probably be good to outline what specific kinds of features could be added with foundation support (or other benefits beyond just being developed by a larger entity/being "official"). — Rhododendrites talk \\ 16:57, 29 November 2020 (UTC)[reply]
  • As the Commons Android app's project lead, I think it would be wonderful to have more hands and "official" support for the app. The app is currently actively maintained by a small group of volunteers and part-time grantees, and has been since 2015. Every 1-2 years, we apply for a project grant to give our core developers a bit of support, but grants are by nature sporadic and limited, and thus the gaps are still filled in largely by volunteer effort.
However, it may be worth noting that ongoing maintenance is our biggest burden (and the one that you are likely noticing cracks in). Android is a relatively difficult platform to target - new versions of Android are released frequently and cause issues with old code, there are many different device manufacturers and most of them don't use stock Android but rather their own customization of Android, some users use very old versions of Android, etc. For all of these, bugs need to be ferreted out and fixed, alongside other maintenance burdens involved with an active app, e.g. triaging reports, communicating with users, project and repository management, publicity, testing, etc. This is all in addition to developing the new features that are proposed for our grants.
So from my perspective, ongoing and stable/long-term support from the Foundation for the existing team is the best way to solve this problem. On the other hand, a one-time technical contribution (which seems to be the main scope of community wishlist, but please correct me if I'm wrong) is unlikely to help long-term. Misaochan (talk) 09:45, 30 November 2020 (UTC)[reply]
  • We agree the Commons app needs WMF support, but I'm afraid Community Tech isn't the right team for it :( Indeed, as Misaochan suspected, the survey is focused on what we can accomplish in just a few months' time. We're sorry we cannot be of more help. Thanks for participating in the survey, nonetheless! MusikAnimal (WMF) (talk) 04:37, 2 December 2020 (UTC)[reply]
  • @MusikAnimal (WMF): So you agree that support of the Commons app would be a good thing - but you can not help. Next question would be: Then who can? Where is the right forum for this idea? Cheers Rsteen (talk) 16:24, 29 December 2020 (UTC)[reply]
    @Rsteen I would think Phabricator is an okay place to propose Foundation support for the Commons app. There's at least one team experienced with the Android platform; I doubt with the current staffing they could take on ownership of a whole new product, but you could also reach out to them to see if they have any ideas on best way forward.
    As a side note, I think next year's Wishlist Survey will allow bigger wishes that are outside of Community Tech's scope, simply as a means to show what the community wants (even though there's no guarantee WMF will be able deliver). So if this is still a problem come next year, we can utilize the Survey to show widespread community interest and maybe attract support from the Board or some other authority that could help allocate resources to the app.
    Hope this helps! MusikAnimal (WMF) (talk) 22:59, 1 January 2021 (UTC)[reply]
    @MusikAnimal (WMF): Thanks for taking the time to answer this. As somebody who is just a dayly user of Wikipedia/Commons, the inner workings of WMF are rather a "black-box" to me. Cheers Rsteen (talk) 04:10, 2 January 2021 (UTC)[reply]

Explicit protection for young people — policy and tooling

NoN Proposes a legal/social/policy change rather than a technical feature

  • Problem: young people (and particularly those with dedicated articles) are currently treated as adults and may be subject to inappropriate editing and discussion
  • Who would benefit: young people (and indirectly the entire Wikipedia community)
  • Proposed solution: that Wikimedia Legal develops policy to protect young people and then develops suitable structures and tooling to monitor and enforce that policy
  • More comments: within Europe, Wikimedia has additional responsibilities under the Charter of Fundamental Rights of the European Union[1]
  • Phabricator tickets:
  • Proposer: RobbieIanMorrison (talk) 17:37, 30 November 2020 (UTC)[reply]

Discussion

The background to my proposal involved watching and occasionally contributing to the page for Greta Thunberg in its early days. Greta was 15 years old when she first went on strike. At around that time, Greta was peripherally involved in a some kind of scandal with a Swedish social media startup — the details of which are not material here.

What is relevant is that Greta should have been subject to additional editing protections because of her age and provisions under article 24.2 of the Charter of Fundamental Rights of the European Union — 2000/C 364/01.[1] And she was not. I watched contributors argue that Greta's judgment was deficient and it was necessary for this material to go live.

I argue that the Wikimedia Foundation (WMF) failed in its duties to Greta such that "In all actions relating to children, whether taken by public authorities or private institutions, the child's best interests must be a primary consideration."

The appearance of children on Wikipedia is likely to grow. Another candidate would be 14-year old Anika Chebrolu who recently won a science prize.[2] Or the six children and young adults currently plaintiffs before the European Court of Human Rights in relation to climate breakdown.[3] Their ages ranged from five to 14 years when their case was first filed in 2017.

I am not a lawyer or a child advocate, so I don't know what policy would be necessary. But I do know that in the absence of such policy, WMF is running a legal risk, and worse, likely to be an unwitting facilitator in undermining the rights of children.

I have tried to raise this matter with WMF Legal in the past, but to no apparent avail.

The policy should also cover the use of images of children, particularly for those individuals of public interest.

I sincerely hope this matter can be conceded, tackled and resolved. We would all benefit, primarily the young people in need of protection and the Wikimedia community not having to watch events deteriorate as editors debate their interpretations of the facts and then publish actionable material.

References

  1. ↑ a b European Commission (18 December 2000). "Charter of fundamental rights of the European Union — 2000/C 364/01" (PDF). Official Journal of the European Communities (C 364): 1–22. Retrieved 2017-11-09.  Article 24 on the rights of the child.
  2. ↑ Lanese, Nicoletta (21 October 2020). "14-year-old from Texas wins top science prize for coronavirus molecule discovery". ScienceAlert. Retrieved 2020-11-21.  Article on Anika Chebrolu.
  3. ↑ Watts, Jonathan (30 November 2020). "European states ordered to respond to youth activists' climate lawsuit". The Guardian (London, United Kingdom). ISSN 0261-3077. Retrieved 2020-11-30. 

Ability to use gadgets crosswiki

NoN Outside the scope of Community Tech / declined in a previous survey

  • Problem: I've gone from Wikipedia to other sites part of the Wikimedia foundation, such as German Wikipedia, Wikicommons, etc. and tried to use the gadget's funcionality, but found it never crossed over. I'd gone to the gadgets page, wondering if the gadget just got turned off for some reason, only to find it isn't in the gadgets page. This has/would create some problems that, although some might be small, it's may be enough to push users away from using that specific site.
  • Who would benefit: Users of any gadget that have tried to use it crosswiki, but found it couldn't
  • Proposed solution: Sites of the Wikimedia foundation are largely similar, and gadgets probably would act similar now to if they became crosswiki. All that'd need to happen is allow the use of gadgets anywhere on the Wikimedia foundation's sites, since the "Global prefs" option should allow them on all Wikimedia's sites (EDIT: It doesn't. I've enabled HotCat, and a variety of other things on Wikipedia, but it isn't enabled here. The global preferences thing doesn't even seem to affect the section)
  • More comments: If some sites either are largely different, or if it's in a completely different language, I'd get that. It'd be up to the gadget's developer(s) to do that. However, some sites are basically the same, and gadgets should function the same on each site, but the gadget isn't there. Also, if you can't implement this, at least allow editing tools' gadgets, as the editing is the same on every Wikimedia foundation site.
  • Phabricator tickets:
  • Proposer: JMVR1 (talk) 20:57, 17 November 2020 (UTC)[reply]

Discussion

  • We couldn't agree more! This was the #1 wish from the 2016 survey. Gadgets are currently defined on a per-wiki basis. Unfortunately globalizing them into Special:GlobalPreferences is a massive project that is too out of scope for our team. For this reason I must archive this proposal. As an alternative, you can instead propose that your favourite gadget(s) be turned into extensions (HotCat, for example). That is much more feasible. Sorry my message could not be more favorable, but nonetheless thank you for participating in the survey! MusikAnimal (WMF) (talk) 21:52, 21 November 2020 (UTC)[reply]
@MusikAnimal (WMF): This is the community wishlist, whether your or any other team should work on this has to be decided after the community can make its preferences, do not accept it, because some random small team doesn't want is is not reason to reject ist. Grüße vom Sänger ♫(Reden) 08:32, 22 November 2020 (UTC)[reply]
We'll reply to the thread on the talk page soon. But short answer – this is all explained in the documentation and is no different than how we conducted the survey in previous years. Thanks for your understanding and cooperation, MusikAnimal (WMF) (talk) 20:50, 22 November 2020 (UTC)[reply]
@MusikAnimal (WMF): 'no different than how we conducted the survey in previous years' does not make it the right way, and that is what Sanger, several others and I are arguing. We've seen these comments/arguments over and over, but basically you can utterly ignore what the community wants and just work on whatever you like and define that all the rest is 'out of scope'. Not much of a community wishlist then. --Dirk Beetstra T C (en: U, T) 06:04, 23 November 2020 (UTC)[reply]
I've started another thread over there, as this survey is either completely misnamed or the restrictive handling is wrong. A Community Wishlist is the wishlist of the community for all the devs, I could not care less, how the internal organisation of WMF/WMDE, i.e. the software service orgs, is done, but this survey is, from the name of it, the wishlist of the community. If it should just be the wishlist for a tiny team, that is very busy and constructive, but not able to accomodate the community wishlist, this should be made clear with a better naming. I would prefer to keep the title and make it a real community wishlist, as that's what's really missing, tons of wishes rot somewhere in Phabricator and nobody cares about them. As the community isd the highest Entity in the Wikiverse, they should be far more accomodated, they are the ones, that matter, not shiny new projects like the unwanted FLOW or such. Maintenance matters, bling is not relevant. Grüße vom Sänger ♫(Reden) 06:56, 23 November 2020 (UTC)[reply]

Move citations to Wikidata

NoN Needs consensus / no engineering necessary

  • Problem: Many citations are incomplete, tend to be outdated and/or have invalid URLs etc. They must be maintained in each and every language version redundantly. Actually, citations are metadata which can be maintained at Wikidata much more easily than in different language versions and used universally by recognising key strings like URL, ISBN, ISSN etc.
  • Who would benefit: Each and every editor in each and every Wikimedia project. InternetArchiveBot would have to work only on Wikidata.
  • Proposed solution: Move citations to Wikidata, ensure by means of software that users edit their citations on Wikidata and that those diminish from articles' source text.
  • More comments: (Feel free to translate my proposal into better English.)
  • Phabricator tickets:
  • Proposer: Matthiasb (talk) 21:05, 22 November 2020 (UTC)[reply]

Discussion

  • @Matthiasb: Thanks for your proposal! The big part of this is to get community acceptance for having citation data not in the wikitext. On English Wikipedia I think this is a contentious topic (there does exist the {{CiteQ}} template, which does what you want), although on other wikis it might be more acceptable. The second part of this is about the actual form of these citations, and that feels like a wiki's responsibility (there are existing templates that can be copied). So I think the only part of this that would require input from developers is some way of making it easier to edit the citations in a wiki and Wikidata at the same time; maybe you could focus on that aspect of it for this proposal? —Sam Wilson 01:10, 23 November 2020 (UTC)[reply]
  • @Matthiasb: Thanks also for this nice proposal! I see two main merits in your proposal:
  1. It allows to separate the references from the body of the page text where references often clutter the text and make very difficult to read and to understand the text code for locating easily where to make some modifications. It is an old problem of Wikipedia: clearly separating the references from the text!
  2. It allows to share references between different languages and to centralise all the references in one unique common place where their maintenance and corrections would be much more easy to do. Supplementary advantage: contributors from one language could more easily discover references used in another language.
The references, if correctly formatted in English could serve as international master reference commonly shared between all the Wikipedia sites. In case of need, the master reference could be translated in each language as a function of the needs of each page. I hope this proposal will receive a large support, but I understand that it could also represent a big technical challenge. Shinkolobwe (talk) 17:37, 24 November 2020 (UTC)[reply]
  • Given the major issues with WikiData and there incapability of dealing with vandalism effectively (or at all!) I fully oppose this proposal and I oppose any idea that we should host citations elsewhere (I'd only support if vandalism detection there was as good as EN which is a very big wish I know!). –Davey2010Talk 19:39, 27 November 2020 (UTC)[reply]
    Protecting against vandalism is very important, I agree. I think the focus should be on that, with an eye toward implementing this proposal when vandalism is under control. Silver hr (talk) 19:22, 30 November 2020 (UTC)[reply]
  • This is an excellent idea that would make dealing with references and citations much easier and thus enable more and better contributions to Wikipedia. Silver hr (talk) 19:22, 30 November 2020 (UTC)[reply]
  • We discussed this as a team and it sounds like this needs broader consensus. There isn't much engineering for us to do anyway, given sourcing from Wikidata is possible now (such as with {{CiteQ}}). As such I'm going to archive this. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 03:59, 3 December 2020 (UTC)[reply]

pre-check for plagiarism

NoN Proposes existing solution

  • Problem: sometimes a good faith edit turns out to plagiarism (e.g. not properly cited); it would be nice to know this before publishing...
  • Who would benefit: good faith editors
  • Proposed solution: a tool that allows for this check (possibly even automatic)
  • More comments:
  • Phabricator tickets:
  • Proposer: Fintor (talk) 07:14, 17 November 2020 (UTC)[reply]

Discussion

  • This would be great but I am pretty sure it is pretty hard to do (and may not be technically viable for many reasons). We do have a post-edit mechanism available today though maybe it's not well advertised in CopyPatrol? (See also phab:T141379 and CopyPatrol project.) --Izno (talk) 04:57, 18 November 2020 (UTC)[reply]
  • @Fintor: Try the Copyvios tool. This has to be used after publishing, but seemingly any solution would (also I imagine you as the editor would know ahead of time if you're plagiarizing?). As Izno points out there is also CopyPatrol for patrollers to review. Do any of these solutions work for you? MusikAnimal (WMF) (talk) 22:45, 19 November 2020 (UTC)[reply]
    I think we could probably investigate deeper into the en.wiki proposal of natively supporting TurnItIn in Wikipedia by adding a report to talk pages that spot plagiarism instead of using the Copyvio tool, or maybe even let users run the page through the TurnItIn software before publishing. See w:en:WP:Turnitin, it is a proposal in en.wiki back in 2012. WikiAviator (talk) 13:21, 20 November 2020 (UTC)[reply]
  • Wouldn't an editor already know if their edit is plagiarized or not? And how would you expect this to function? Would it be an optional check that the editor opts into, or a check that is run every time an edit is submitted? Unfortunately, doing a check for plagiarism isn't very fast, so I don't imagine we would want to make every editor wait for it to complete before saving the edit. Kaldari (talk) 18:02, 20 November 2020 (UTC)[reply]
    The problem is not so much for the editor oneself, but for the next one. Recently I translated a page into another language; only later I detected by accident that the previous' editor had indeed committed plagiarism, so I implicitly inherited the previous editor's problem. Copyright checking is indeed CPU and I/O + network intensive. Couldn't this be done offline by a bot that places a warning? Geert Van Pamel (WMBE) (talk) 18:43, 23 November 2020 (UTC)[reply]
    • Agree with Geert Van Pamel; undetected plagiarism in articles is a problem. Second-order, there's also plagiarisms in sources. I once accidentally cited a source which turned out to be plagiarized from another publication, and the resulting bad-faith editing, apparently by the plagiarist, lead to several domains being placed on the global blocklist (details). This faff wasted the time of half-a-dozen editors over the course of a couple of years. And a new editor might not know that copying text from another website is not OK; an automated message warning them and explaining how to insert the information without copyvio would be useful. I agree that this is likely to be to time-consuming as an edit filter, but perhaps it could be implemented as a bot targeting inexperienced editors making long edits? (suggestion independent of Geert Van Pamel, due to edit conflict) HLHJ (talk) 20:13, 23 November 2020 (UTC)[reply]
  • If we are talking about uncited text, not copyvio, then the appropriate response is a citation-needed tag; see Community Wishlist Survey 2021/Editing/Easier flagging. With the sole exception of BLP (biographies-of-living-people) material, uncited content is in fact allowed on Wikipedia; only if anyone challenges it does it needs to be cited or removed. And frivolous challenges (challenging things you know to be accurate) is heavily discouraged. There are good reasons for this policy; on non-controversial subjects, new-editor subject experts may be able to write reams of useful, encyclopedic content on a subject, but have no clue about citations or even sources at first. This can be a symbiotic relationship if experienced editors tag and gradually cite the text rather than just reverting the lot. The common misconception that anything uncited must be reverted is contributing to falling numbers of active editors; inline-tagging an edit engages the new editor and makes them more likely to stay, while reverting them makes them give up (my citations are here). HLHJ (talk) 20:13, 23 November 2020 (UTC)[reply]
  • @Fintor: We still haven't heard back from you. Do the existing solutions (Copyvios and CopyPatrol) work for you? I know you say "it would be nice to know this before publishing", but I'm afraid this isn't going to happen. Copyvio checks are very slow. My guess is the next best step is to write a bot to flag copyvios on-wiki after the fact. That's already on the CopyPatrol board at phab:T165951. Would you like to revise your proposal to be about this? MusikAnimal (WMF) (talk) 19:22, 24 November 2020 (UTC)[reply]

Set maximum delay in updating category membership

NoN Outside the scope of Community Tech

  • Problem: When a change is made to a template or module that involves category membership, pages that transclude that template or module require a null edit in order to update their category membership. Because of delays in the job queue, such category membership changes can take weeks, or even months.
Changes to the underlying MediaWiki software that apply categories (e.g. those in Special:TrackingCategories) do not force pages into the job queue, which means that category membership for affected pages can take months, years, or forever.
These delays cause outdated information, missing information, and outright errors to be rendered for readers, and cause editors who are working on fixing problems identified by maintenance categories to be delayed in applying those fixes. When a maintenance category should be populated but is empty, it gives editors the false impression that all affected articles are working properly.
  • Who would benefit: This change can be applied to all WMF wikis. Readers would benefit from seeing up-to-date renderings of articles and fully populated categories. Editors would benefit from knowing that maintenance categories reflect the true state of affected pages, at least after a known period of time. Editors who run null edit bots and similar workarounds could spend their time doing more productive work.
  • Proposed solution: Set up a background process that tracks all pages based on their last edit time stamp, including null edits. Use that tracking to make a list of needed null edits for "stale" pages.
  • More comments: The "stale" age tolerance may have to be adjusted based on the size of a given wiki. A small wiki might be able to keep pages refreshed to no older than one week, but a larger wiki might need to have a limit of one month. There could be a different limit for pages in different namespaces; articles could have a shorter "maximum stale time" than user pages, for example.
There are secondary benefits to applying null edits to all stale pages periodically, including updated rendering of templates, refreshing of ages when a template calculates an age based on a birth date, and more.

Discussion

Corrections to my technical description of the problem are welcome. I may not have the exact mechanisms right. There are detailed discussions in the linked phabricator tickets. Jonesey95 (talk) 21:37, 16 November 2020 (UTC)[reply]

  • I totally agree with this issue. Category update is sometime still not done after months and require a null-edit for being applied. An example of this behavior on WP:FR is templates categories included from the documentation sub-page: some templates (but not all... couldn't find the common element) which are categorized by their doc page do not appear in their category, leading bot maintenance to constantly report false positives for uncategorized templates. This categorization issue is very bad as when viewing the affected page, the category does appear at the bottom of the page, but actually, when looking at the category, the page is missing, which is a very misleading behavior that renders identification of the error very hard to find. Epok (talk) 07:12, 17 November 2020 (UTC)[reply]
  • There's no evil setting that delays updating, the problem is in job queue that always has lots of work to do, category membership or not. Several WMF teams have been working on improving the queue for years, so I'm not sure this is a good candidate for a wish that is supposed to take about a month worth of team's time. Max Semenik (talk) 10:34, 17 November 2020 (UTC)[reply]
    • I added a couple more related phab tickets. As I wrote above, even if the job queue were instant, I don't think this problem would be solved for updates to MediaWiki code. See the 17 Feb 2017 comment in task T157670 for details; millions of pages had gone unrefreshed for years. I am sure that I oversimplify, but it doesn't seem like a full-month task to set up a system that (1) maintains a list of stale pages, and (2) automatically null-edits pages that are stale beyond a specified age. Failing that, or if the problem really is too complex for a team of smart developers to resolve, there is a proposed workaround that would allow local bot operators to run null edits. That workaround probably would not take a month to implement. Jonesey95 (talk) 14:53, 17 November 2020 (UTC) (updated 20:05, 19 November 2020 (UTC))[reply]
  • This annoying problem exists for years now. I ran many thousands of touches on Commons using Pywikibot for to fix that partially. That's not a cosmetical problem: Cats like c:Category:Broken category redirects or c:Category:Non-empty disambiguation categories (for example, there are more) become unusable if new entries are not added automatically as they should. --Achim (talk) 18:53, 19 November 2020 (UTC)[reply]
  • We agree this is a major issue that needs to be addressed, however the engineering challenges unfortunately are beyond the scope of our team. The short-term solution might be to create a bot to make null edits to effected categories (there are several similar bots on English Wikipedia already, I think), but you can really only go so far before running into the same performance issues. As much as we'd like to, I don't think our team can help here :( Sorry! Thanks for participating in the survey, MusikAnimal (WMF) (talk) 00:57, 3 December 2020 (UTC)[reply]

Search history contents

NoN Proposes existing feature

  • Problem: Searching for a particular diff is time consuming
  • Who would benefit: Admins dealing with for example possible vandalism and anyone investigating for example orphaned images
  • Proposed solution: It should be possible for confirmed users to search for a text string in the contents of an article history (and no reason not to enable it for other pages such as project and talk as well). This should allow searching in either the content as presented or in the source. It's obviously a processor and storage access intensive task so should be low priority or background, but would still save the searcher time.
  • More comments: I am often looking to see when a particular change took place, either as an admin or as a contributor. For example I recently wanted to know when a subsequently orphaned image had been removed from en:Luo Bao Bei in order to see what edit summary had been given, and who had done it so as to discuss this with them. Similarly, when I stumble upon what seems to be undetected rubbish that has been added to an article... sometimes vandalism, sometimes good faith... the first thing I want to know is when it was added and by whom. I simply want to find the diff that did the damage! But sometimes this can be years and hundreds of edits in the past. Manually searching the page history is time consuming.
  • Phabricator tickets:
  • Proposer: Andrewa (talk) 16:57, 18 November 2020 (UTC)[reply]

Discussion

  • Hi Andrewa! There are several existing solutions for this. For your first example it sounds your trying to find when someone removed something from a page. For that, you could use WikiBlame tool, checking the "Look for removal of text" option. Your second example (where you want to see who added certain content that is still visible), was a top 10 wish in the 2017 survey. Community Tech has already built a visual tool that I think you would assist you. See Who Wrote That? for documentation. It is available as a browser extension. If that doesn't work for you, you can still use the WikiBlame or XTools Blame. Finally, there is a built-in feature called RevisionSlider that makes it much easier to identify where content was changed. To use it, open up any diff (example) and click on the "Browse history interactively" dropdown at the top. As a first-time user, you should be prompted for a tutorial, if that helps.

    Do any of these solutions work for you? MusikAnimal (WMF) (talk) 21:05, 18 November 2020 (UTC)[reply]

    • Thank you! I'm sure they will all prove useful. But I would not call any of them solutions. They are workarounds.
    • I am installing the RevisionSlider extension. Here is how far I got so far. I downloaded the compressed file, which was in a .gz format I'd never heard of and which my system did not recognise. I installed 7z to extract this file, which extracted to a .TAR format which I had heard of but which my system doesn't recognise either. 7z is supposed to support this format but I am still trying to extract the files. Now I used to be a geek but am long retired and out of my depth here obviously. I will get there I'm sure.
    • But do we really expect everyone wanting the feature I'm looking for to go to this much trouble? Wikipedia has a systematic bias towards people with a technical background. This sort of "solution" is one of the reasons.
    • WikiBlame appears to run on a third party website. OK, we have many such tools and I already use some of them. But we should not depend on them any more than we need to.
    • I'll have a look at WhoWroteThat. It again requires me to install something, is that right? If so I will have no access to it from the library computers I have used in the past and on which some of our contributors depend.
    • But all good suggestions, and thank you again. Andrewa (talk) 15:35, 22 November 2020 (UTC)[reply]
      • Trying to help: I think Andrewa is misunderstanding. The RevisionSlider extension is an extension for the MediaWiki server software. You are not running a MediaWiki server. You want to use the extension in the English (or German or whatever you use) Wikipedia. The server administrators have to have installed the extension. The English Wikipedia has it. To test it, open a diff, such as the one provided by MusikAnimal and look for the "Browse history interactively" dropdown at the top. I don't know if it does what you want. --Error (talk) 13:22, 25 November 2020 (UTC)[reply]
        • Thank you, that's very helpful! You are of course correct. I'm feeling quite stupid not to have realised that it was a MediaWiki extension not a browser extension. But you say it's installed on en:Wikpedia? I don't see it. Why would that be? Something to do with my personal settings? Andrewa (talk) 19:42, 25 November 2020 (UTC)[reply]
          If you do not see a button "Browse history visually" on this page then it might be that you have disabled either the feature in your Preferences in the section Appearance is an option "Don't show the revision slider". Perhaps you have checked that at some point. Alternatively it is always possible that you have disabled all Javascript in your browser, which would be another reason for it not to be present there. —TheDJ (talk • contribs) 22:27, 25 November 2020 (UTC)[reply]
  • Since there are several solutions to this, I'm going to archive this proposal. Do give Who Wrote That a try; I think you'll like it! Thanks for participating in the survey, MusikAnimal (WMF) (talk) 04:29, 3 December 2020 (UTC)[reply]

Modernize talk page format

NoN Outside the scope of Community Tech; currently being working on as part of the Talk pages project

  • Problem: Talk page discussions are often fragmented with unsigned comments, over-indenting and format problems, especially on mobile.
  • Who would benefit: Everyone.
  • Proposed solution: Change the talk page format to a thread format (like Reddit) so no indentation is needed and restrict the use of Wiki Markup in talk pages so it would not be burdened by problematic formatting.
  • More comments:
  • Phabricator tickets:
  • Proposer: WikiAviator (talk) 06:19, 17 November 2020 (UTC)[reply]

Discussion

This is probably too big a problem to be tackled by the team. Structured Discussions (ex-Flow) is trying to achieve this, but meets resistance in certain communities. NMaia (talk) 10:36, 17 November 2020 (UTC)[reply]

Thanks for letting me know. After reading WP:FLOW, I can forsee great hurdles of introducing Flow Wiki-wide since en-wiki even uninstalled Flow back in 2016. However, I think that it would serve as a more efficient tool in the future and Wikimedia should provide more features in flow and facilitate a smoother transition (archiving old discussions etc.) to Flow for different wikis. This topic is worth discussing but we'll have to observe longer to see what the consensus in Meta is. WikiAviator (talk) 13:29, 17 November 2020 (UTC)[reply]
Honestly, a quick fix would just be to add a link that generates at the end of each signature/edit that generates a reply button. This then brings the person wishing to reply into the editor with a comment indented one more than the previous user and an auto generated tilde signature. Shouldn't be too hard, but I'm not familiar at all with the Wikipedia Backend Regicide1 (talk) 00:21, 18 November 2020 (UTC)[reply]
I'm gonna phrase this as a proposal actually Regicide1 (talk) 15:52, 18 November 2020 (UTC)[reply]

Proposal: install the Discussion Tools or MediaWiki's Support Desk. Scarecroe (talk) 21:27, 17 November 2020 (UTC)[reply]

Neither allow full use of all wikitext editing functions. This is too great of a sacrifice just to get indentation and signatures. Talk pages are used to illustrate exactly what people would like to see in articles. Tables for example. Templates. All wikitext functions. Crippling functionality of talk pages also cripples articles. Adding a reply link to all signatures by default would be a lot simpler solution.
A warning (before a talk page post can be saved) about a missing signature would solve that problem. It wouldn't automatically add a signature since many edits do not require a signature on talk pages. Formatting, minor typos, etc..
It would be nice if the Visual Editor could edit sections by themselves. Then the Visual Editor could be allowed on talk pages. As long as the Visual Editor is restricted to section editing only then I would support it as an addition to the wikitext editor on talk pages. Otherwise the Visual Editor tries to change stuff in other talk sections without asking. Tables for example. Newbs wouldn't notice it. Experienced editors may not catch it either since we don't regularly use "show changes". --Timeshifter (talk) 01:22, 18 November 2020 (UTC)[reply]
  • As well as disagreeing with this specific proposal for the reasons above, it's also going to be running directly counter to a current major project. There's no way that's in scope. I'd also note that the Wishlist could not be viewed as consultation equivalent to the Talk Page Discussions consultation that is viewed as the gold standard of WMF consultations (would that they always did it that way!) Nosebagbear (talk) 14:55, 18 November 2020 (UTC)[reply]
  • mw:Talk pages project (mentioned here as Discussion Tools) is a direct result of last year's global consultation. The community did not want to resurrect Flow, they wanted to keep talk pages with wikitext and all the magic stuff. --Matěj Suchánek (talk) 15:24, 18 November 2020 (UTC)[reply]

Proposal: Add a functionality that allows for automatic formatting of response, with autosigning and indentation. This would add a response link to all signatures, that when clicked takes the user into the editor and both indents them one more than the comment to which they are replying and adds their signature. This should help at least address the messiness of talk pages, but other than that I actually like the current talk page.

I think a solution that both improves the talk page flow and supports Wikitext is to let editors use Wikitext in their own comments, while comments from other users are only allowed to be altered by administrators. That would let people who want the talk page to be simple to use normal text while preserving Wikitext elements (tables, templates etc). It may be a good idea to introduce the ability for admins to lock old topics instead of archiving them (like those technical support forums). WikiAviator (talk) 08:06, 19 November 2020 (UTC)[reply]

Whoa! Isn't this page getting off-track or messy or something? We're having two or three proposals in one page. Furthermore, the term "modernize" looks too broad to me. George Ho (talk) 21:28, 19 November 2020 (UTC)[reply]

┌─────────────────────────────────┘

It's nice to see this lively discussion! Issues with talk pages are well-known. Repeating what others have said: That's why the Talk pages project was started. They spent roughly a year consulting with the community. Some of the ideas pointed out here are already in development, such as DiscussionTools (which adds a [reply] link, auto-indents and auto-signs). When this is all completed, I think you will see something much closer to modern chat systems such as seen on Reddit. So hang tight :)

As written, this proposal is too broad and not actionable by our team so I am going to archive it. We might be able to accept some ideas for the Talk pages project, but we'll have to make sure it doesn't conflict with any of their existing plans. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 00:22, 20 November 2020 (UTC) [reply]

Explore how MediaWiki could reach the goal of making a collaborative dictionary

  • Problem: MediaWiki was made to be collaborative and it evolved during the last twenty years to fulfill the needs of Wikipedia, i.e. to make a collaborative encyclopedia. The same tool is also used for others projects such as Wiktionary and other peer projects, but we can't say it evolved so much for Wiktionary. The only dedicated evolution was the Cognate extension made by WMDE. It is raw but useful, thanks to the team that made that. All other features were made by the community, without any funding to make them scalable to all wiktionaries. The design and content management is not oriented to the creation of a dictionary, and there are several major issues identified for years.
  • Who would benefit: All Wiktionary projects, editors and readers
  • Proposed solution: In order to identify the needs for the building of a collaborative dictionary, we may need to consider a large consultation of the communities with surveys, workshops and UX tests. This large problem could not be solved by a single feature but by an exploratory work. Then this first step may help to write new proposals next year for the Community Wishlist Survey, with more specific concerns.
  • More comments: This proposal may seems a little bit out of the scope, but I can't think of another dev team which could take this in charge. From a project management perspective, it is not that odd to look for a phase of conception prior to any development and I think the Community Tech team is the most qualified to do so.
  • Phabricator tickets:
  • Proposer: Noé (talk) 00:43, 29 November 2020 (UTC)[reply]

Discussion

  • Hi, Noé. We agree that there's more work to be done to make Wiktionary the best it can be. There do appear to be some efforts to increase the amount of structured data that is used on Wiktionary. Those efforts seem like the best chance for progress. As for this wish as part of the wishlist, the Community Tech team is limited to working on specific, in-scope, technical wishes and this wish does not meet this criteria. For this reason, I'm archiving the wish. --AEzell (WMF) (talk) 23:26, 1 December 2020 (UTC)[reply]
    Structured data will not improve the user experience in reading. I am confuse about the "efforts to increase the amount of structured data that is used on Wiktionary you mentioned". There is nothing alike. There is zero structured data used on Wiktionaries. Maybe you were thinking of Wikidata Lexeme, a project for lexicographical structured data but it is not made for Wiktionaries, it is made for Wikidata and there is nothing planed to support Wiktionaries. Nowadays, you can't display Lexeme data in another Wikimedia project and there is not standardized way to indicate that a L-item is described in a Wiktionary project. I made an attempt to create such a connection and started a conversation about it, but it went out dry.
    About the exclusion of the wishlist, I understand this issue is too large. We may consider a solicitation to a chapter or some chapters to fund a UX expert. Then we should be able to get back to the wishlist with a more specific query Noé (talk) 23:49, 1 December 2020 (UTC)[reply]
    I appreciate what you are saying about reading. That is certainly a different issue. As for structured data, I could be wrong, but I thought there were efforts underway to structure more of the data about different "versions" of words across languages so that the wiktionary could understand these connections but a French reader wouldn't have to wade through 17 other languages to find the French definition of a given word. I'm very inexperienced with Wiktionary so I apologize if this is more confusing. As you say, this wish is out of scope but, in your opinion, what is the number one issue for readers of Wiktionary? Maybe thinking in that way and trying to do small, incremental change is the way to see some progress? AEzell (WMF) (talk) 00:25, 2 December 2020 (UTC)[reply]
    Hi AEzell,
    There are some efforts to have a better structure but it is not structured data per se. Ok, I may explain this with a short story. During the past months, in French Wiktionary, we worked with a team of four people including a WiR, a Lua-skilled contributor, an internship trained in lexicography and myself to structure the labels for technical domains used to characterize a definition (i.e. botanic, linguistics, computer sciences, and so on). We built a very nice module with definitions and a hierarchy to structure the whole thing. English Wiktionary have a similar inventory since 2016. To my knowledge, those two are the only attempts of structure for domains. Half a dozen editions have imported the English Wiktionary list with a partial to no translation. The others Wiktioanry editions have one template for each domains, with a loose structure behind. So, on this part of the data, it is more structured for some project but not globally and it is a though job to build this structure.
    My reading of this situation is that wiktionarians have a scarce knowledge of lexicography and are creating an new object, a multilingual collaborative dictionary. This lead to improve the inventory of possible labels in a rather chaotic way, sometimes with a loose understanding of lexicographical concepts such as obsolete, by extension or transitivity. It makes it very difficult to share our structures between languages, it is almost as building towers without any architect able to read the other's blueprints.
    Building a multilingual structure for all languages and cultures with a multilingual community is very complex, with modules in Lua, templates in wikicode or in Wikidata Lexeme (or a similar RDF base) is similarly difficult. We may need another way to structure our data, with a better handling of multilinguism in each projects. Nowadays we describe chat in English and chat in French in the same page (same url). Splicing in subpages or sections could help to have a better managment of the content. Also, we can't reuse an information, or link a definition to the picture that illustrate it. Beside picture reference, an example of this issue is for the pronunciation of inflexions, indicated in both pages, mouse and mice. Well, there is a lot that can be improve for the structure.
    I think I am the wrong person to pick the number one issue for readers, as I contribute for too much time, on so many aspects of the project, including by writing Help pages and tutorials. That's why I am convince some UX tests should be a better method to frame readers' issues. Well, UX tests should still be guided to specific scenarios in the reading. One problem I can think of is the way Wiktionaries display lists of audio recordings. It is quite a mess, sometimes with 20+ files in a random order. An integrated playlist with files order based on readers location could be a better way, in my opinion, but again, some UX tests may help to consider a different need or another way to fix this one.
    I am happy that you asked to continue this conversation, but I understand if you are not able to answer soon. There is so many good proposals to evaluate this year! Have a good day! Noé (talk) 10:08, 2 December 2020 (UTC)[reply]

Add more gadgets to Preferences/Gadgets

NoN Outside the scope of Community Tech / does not require engineers

  • Problem: There are many "gadgets" (user scripts and like) that are useful but very hard to find.
  • Who would benefit: Everyone.
  • Proposed solution: There are many gems that most people are not aware of because few even realize there is stuff besides the Preferences/Gagets menu. My best idea right is from the end-user perspective. The easiest way for most end-users to find gadgets is to go to Preferences/Gadgets and read through it or CTRL+F for specific keywords. Yet that list has only a small fraction of user scripts and like, plus it does not explain how gadgets can be added there (also please note that right now, clicking the help button on English Wikipedia in the Preferences/Gadgets takes one to https://www.mediawiki.org/wiki/Help:Preferences#Gadgets but that section is empty). This needs to be streamlined, and here my solution is the creation of project-specific as well as meta noticeboards for adding gadgets to Preferences/Gadgets (and linking said noticeboard from Preferences/Gadgets). Local noticeboard for different projects would make the final call, while the meta would be a way to highlight useful gadgets to people who otherwise wouldn't know it. For example, if I create a cool gadget on pl wiki, I probably don't feel like mentioning it on dozens of other wikis. But I could submit it to the pl wiki gadget noticeboard, and the meta (that process could be automated too, through some bot...). Even if the meta idea is too complex, this proposed process should help to populate the Preferences/Gadgets with useful stuff. Right now an average user, like myself, has no idea why a useful gadget X is not included in preferences, or how to ask for it to be included in it. Finally, each gadget description page should contain a template with information on whether that gadget has been reviewed for inclusion in the Preferences/Gadget or not yet, with a corresponding category for approved, rejected, and pending gadgets. Within a few months, this would allow the community to review each and every user script and like for inclusion.
  • More comments:
  • Phabricator tickets:
  • Proposer: Piotrus (talk) 04:26, 17 November 2020 (UTC)[reply]

Discussion

  • A single searchable and categorized library of gadgets and scripts would also be incredibly useful (like an app store, but for Wikimedia tools). Ɱ (talk) 05:48, 17 November 2020 (UTC)[reply]
  • @Piotrus: In my personal opinion, the proposal summary is unrelated to the problem description here? Adding more and more usually does not solve problems; instead it will create more maintenance issues and rotten code that someone needs to maintain (and often nobody volunteers). If your proposal has to do with discoverability of existing gadgets that sounds personally very valid to me, but the proposal summary doesn't express that. :) --AKlapper (WMF) (talk) 13:50, 17 November 2020 (UTC)[reply]
    It is not so much an issue of lack of maintainers for gadgets (well, kind of, but not the issue Piotrus is talking about here) as it is that the gadget experience is really bad for casual gadgeters. Once you have a script as a gadget, then you have to go through the rigmarole of getting interface administrator or you have to have someone update the script for you. That's not really great. (I know there are technical issues related to that like the perennial sane code review Phab issue that was supposed to be solved At Some Point by Gadgets X.0, but Gadgets X.0 is on hold right now and Gadgets 2.0 moreover seems to have gotten a bad case of requirements creep.) Also you have to sell a community on adding it as a gadget through pre-use as a script most-usually, which is itself a pain because now we're advocating for people to use a script that way. (I assume this is partially due to discoverability at least but also concern about maintenance also I suppose.) In general, I do agree that this issue is mostly social in nature.
    The one idea I've add regarding gadgets that I think would make them easier to find is to deprecate or change the scope of the Gadgets tab to "Miscellaneous" and to integrate the other gadgets into the other preference panes. This would be one tweak to discoverability that might be considered in the context of this request.
    Basic changes like "change the help link to a local link where we can point to other scripts collections" might be a good one too, as below with 1234. --Izno (talk) 18:28, 17 November 2020 (UTC)[reply]
    I read "you have to go through the rigmarole of getting interface administrator or you have to have someone update the script for you" and audibly sighed. I should really apply for that user right one of these days. {{Nihiltres |talk |edits}} 06:48, 18 November 2020 (UTC)[reply]
  • Would a link to en:Wikipedia:User scripts/List from the preferences be good enough to fulfill this proposal? Script developers are quite often not administrators, and moving their code to MediaWiki namespace is not optimal if they work on their code a lot. 𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰 (𝗍𝗮𝘭𝙠) 17:20, 17 November 2020 (UTC)[reply]
    Most editors who manage a gadget maintain a separate beta script for testing anyway, so whether they work on the gadget a lot is kind of immaterial. --Izno (talk) 18:29, 17 November 2020 (UTC)[reply]
    This is enwiki sloution only. And other 200+ projects will have no benefit.
    See also quite similar last year proposal. JAn Dudík (talk) 19:48, 17 November 2020 (UTC)[reply]
    Which? Changing the help link to point to a local page? I guess it is, but making that an editable message (is it maybe already?) means any wiki can change it. --Izno (talk) 19:56, 17 November 2020 (UTC)[reply]
    Link to local page shoul be fine, if this page have some content. User scripts/List (Q96781348) exists only on two wikis, some page about user scripts is on ~25 wikis. Maybe 30 biggest projects have some experenced users. And many of these scripts are wiki specific and does not works on other versions. Some works, but when imported from other wiki, cannot be localised. JAn Dudík (talk) 13:09, 18 November 2020 (UTC)[reply]
    @1234qwer1234qwer4: While this does not address all the issues, it would help. Overall, I think the gadget page should be integrated with that list since they serve similar purpose for most end users (i.e. they are a list of helpful tools). --Piotrus (talk) 09:12, 18 November 2020 (UTC)[reply]
  • After discussing this proposal with the team, we feel there's not much Community Tech can do here. Longer-term, it seems Toolhub will be the formal answer to tool/gadget discoverability, which appears to be in development. In the meantime, nothing is stopping the community from making a centralized venue to share user scripts and gadgets. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 01:07, 3 December 2020 (UTC)[reply]

Eliminate Root Cause of Harassment

NoN Proposes a social/policy change rather than a technical feature

  • Problem: The root cause of harassment is edit wars and censoring, especially problematic for minority opinions. By definition, revolutions start with the first minority person to recognize a problem with the status quo. Wikipedia resists revolutionary progress and minority opinions.
  • Who would benefit: Anyone facing an edit war, losing work done from such, especially people holding a minority opinion. By definition, all new revolutions start with a minority or disrupting first person.
  • Proposed solution: The reason we need censoring is because we can’t listen to everyone. But if we could find a way to organize everyone into the fewest possible camps in a bottom-up way, each camp with concise statements and counts of how many people are currently in them, we could listen to everyone. If a revolutionary person could create a new camp, instead of being censored, then if the camp can show exponential growth in consensus as more people join (abandoning camps they now consider falsified), this would enable that camp to stand out from the crowd. Revolutionary progress could be tracked and accelerated. Minority opinions would not need to be censored. In the consensus/encyclopedia case, Wikipedia is the simplest tool, since there are no edit wars. When lack of consensus shows up, people could be pointed to a more complex wiki with camps, like Canonizer, where nobody is censored. Disarming any win/lose censor wars with a win/win this is what I believe, what do you believe? The root cause of harassment would be eliminated.
  • More comments: This proposal is simply recommending something like the below description be added to the Biased or opinionated sources section of the Wikipedia:Reliable sources page. Approving references to Canonizer topics as primary sources of information about the opinion of participants of any topic referenced, and encouraging people to take edit wars that show up to a system better capable of handling them.

Wikipedia is the best crowd sourcing tool when there is consensus. But when people’s opinions differ, there is a lack of consensus. The polarization of society and many of Wikipedia’s problems, including edit wars, are symptoms of Wikipedia’s inability to deal with lack of consensus information. No matter where you go on the internet, including all the “trusted sources” listed here, someone can call it fake news. We simply do not have a rigorous way trusted by all to measure the quality of information.

All these problems can be resolved by simply adding camps to a wiki system as has been done with Canonizer. Whenever a lack of consensus system, such as an edit war emerges, people can move the disagreement to [https://canonizer.com Canonizer, where they can create, join, build and track consensus around their preferred opinions. Comps convert win/lose edit wars into a win/win “This is what I believe, what do you believe?”

The crowd’s goal with such a system isn’t to determine truth via biased, limited, or popular consensus. It is to enable the experts to find out who isn’t yet on board with important scientific consensus and why. We need to be able to compare the popular consensus to the expert consensus to see how well it is keeping up. That which you measure, improves.

Normally, people polarize around issues as they collect all possible arguments that support their position, no matter how poor, to repeatedly throw at competing camps. Instead, experts need the ability to track the quality of evidence and arguments by how many people they convert. Good camps should be able to describe how their camp could be falsified. Once each camp has described this, it is then up to the experimentalists to force consensus with falsifying experimental results. Once consensus is achieved, it can be returned to Wikipedia, knowing there will no longer be edit wars.

The issues people polarize around are almost always less important than what everyone agrees on. Canonizer’s tree structure resolves this problem. The focus can remain in a super camp where the consensus is being built. Any disagreeable stuff can be pushed down to supporting sub camps, out of the way of consensus, where they can still be tracked and valued. There is no censoring in Canonizer. If you support a camp, you have editorial control and can object to any proposed camp change you don’t agree with.

Another problem is one person’s expert is another’s devil worshipper. This is resolved by having multiple selectable ‘Canonizer algorithms’. In this way people can use an algorithm that only counts the votes of people they trust. In this way experts can address not yet on board camps using their frame of reference, their terminology, and experts that camp trusts. If a camp is falsifiable, consensus should still be possible. If you are using a canonizer algorithm that camp trusts, they can’t call their canonized score, fake news.

Canonizer does not determine truth. All it is is a rigorous concise and quantitative, real time representation of the opinions of the participants. It is a definitive primary source of what the participants believe. In reality, the closest we can get to “truth” is scientific consensus. Everyone knows there can always be a new first revolutionary to notice a problem in established consensus. Where Wikipedia resists such minority opinions and revolutions, Canonizer is designed to accelerate such revolutions as much as possible. All this amplifies the moral wisdom of the crowd.

Discussion

Compare the polarizing edit war stuff in the wikipedia article on Qualia leading everyone to believe nobody agrees on anything to what is contained in the Representational Qualia Theory camp where more definitive consensus has been built in this field (including the support of Dennett’s current Predictive Bayesian Coding Theory camp than has ever been possible before. All competing theories are also included and tracked, so you can see the state of the art of what all participators, at least, currently believe in, in a definitive dendrogram. Even though this is nothing more than a real time, concise and quantitative representation of only the participants, this much consensus has never been demonstrated in this field before, and this can continue to scale to include as many experts as care to include their possibly revolutionary view. May the best theory achieve the most consensus, the soonest. For more info on this consensus, see this short video.

  • Hello! The Community Wishlist Survey is where you propose technical changes or improvements to the software used on Wikimedia sites. While this is a wonderfully elaborate proposal, it is not technical in nature and seems to be more about changing the local policy of one wiki, and proposing the use of an external tool (which you apparently are associated with). This is not appropriate for the survey, as such I'm going to archive this proposal. Please consider bringing your proposal to the attention of your local community instead. Thanks, MusikAnimal (WMF) (talk) 17:43, 30 November 2020 (UTC)[reply]
  • Hi MusikAnimal (WMF), just wondering why our policy change proposal was rejected, while the one on Contributions from under-resourced countries was not?

Mirror contents of previous IPv6 talk page when a new address is assigned

NoN Conflicts with IP Editing: Privacy Enhancement and Abuse Mitigation project

  • Problem: A single IP editor using an IPv6 connection can have multiple IP addresses on the /64 range, which can change daily, usually without them knowing (as explained in this closely-related proposal). Warnings and messages left for one IPv6 address on the /64 range are not readily visible, either to the IP user themselves, or to other editors once a new IP address gets automatically reassigned. Without looking at the entire contributions made by one person on the /64 range, and then accessing individual talk pages to check for past warnings on each page, it is not possible to determine the level of good or bad faith editing by that user.
  • Who would benefit: All admins, anti-vandalism patrollers and any editor interested in understanding the range of editing contributions and warnings left for IPv6 users operating on one /64 range, but who have innumerable (and frequently shifting) IPv6 addresses within that range. The IP editor themselves would also benefit from better communication from other editors should they look at their currently assigned IPv6 talk page and see messages left for them at the talk page of the previously active address.
  • Proposed solution: The contents of the most recently-assigned IPv6 talk page should be automatically mirrored (copied) to the talk page of the next, newly assigned IPv6 address operated by that same user within the single /64 range. This mirroring process would be repeated with the next, newly assigned IPv6 addresses used by that single user, so that warnings and notices (unless intentionally deleted) would be carried forward, just one step at a time, to the next active address. :
(If technically possible, the editing histories of each of the previously allocated IP addresses within that range would be made to accumulate, so that the current IPv6 address contains the edit histories of all the past addresses operated by that user within the single /64 range. But this inability to easily view all edits made across a user's /64 range has been partly addressed by this closely-related proposal to add a clearly visible 'Display full range of IP edits by this user button at Special:Contributions. In this way, each new IPv6 address, operated on a single user's /64 range, would contain an accumulation of any warnings and messages on its talk page, built up from carrying forward past messages from the previously active address, plus an accumulation of all that range's IP contributions)

Discussion

I would only comment that one does not need to know the specific address of an editor, but one does need to be able to readily see all the warnings and messages left for one user across their multiple, changing IPv6 addresses, whether anonymised or not. Nick Moyes (talk) 15:33, 17 November 2020 (UTC)[reply]
  • I am adding phab:T112325 as I believe that's basically what you're asking for. However I echo Matěj Suchánek's concerns about conflicts with the Privacy Enhancement project. Following the aforementioned task, you end up at the TechCom-RFC for IPv6 talk pages which got merged into RFC: Create temporary accounts for anonymous editors. Considering the whole concept of IPs is in question, so are the talk pages, hence this proposal may not be appropriate for this year's survey. MusikAnimal (WMF) (talk) 22:56, 17 November 2020 (UTC)[reply]
  • Perhaps what we really need is a single User_talk: page for each /64, just as every logged-out device in my home will see the same page for our shared IPv4 address. That can still work with anonymity if a prefix-preserving IP mangler such as en:Crypto-PAn is deployed. Certes (talk) 00:09, 23 November 2020 (UTC)[reply]
  • Note that there are also hosters assigning IPv6 addresses within the same net to different customers. --Shoeper (talk) 14:50, 23 November 2020 (UTC)[reply]
  • Even if just visible to admins, knowing that IPs in a certain range (especially on /64 blocks of IPv6) would be immensely helpful. Or a link we could click (similar to the notification of previous blocks) that alert is to warnings in that range. I've encountered IPv6 users who've received nearly a dozen level-1 warnings across as many IPs. A similar feature for previous individual IP blocks within the range would be helpful too. EvergreenFir (talk) 06:06, 27 November 2020 (UTC)[reply]
  • I support this wholly. As an English Wikipedia checkuser and admin, I am consistently shocked by the behavior of MediaWiki when it comes to IPv6 editing, especially within the same /64 block. In my opinion, /64 ranges should be treated by default for most purposes as a single IP address with a single talk page and a single block setting by default; dealing with /64 ranges within poor technical infrastructure wastes a lot of valuable volunteer administrator time that could be spent elsewhere. Best, KevinL (aka L235 · t) 06:48, 1 December 2020 (UTC)[reply]
  • After discussing with the team, we believe the level of effort involved to solve this won't be worth the while given the future of IPs is uncertain. As we understand it, the plan for privacy enhancement will basically solve this wish through session-based temporary accounts. Don't quote me on that, though! All we know is we can't devote significant time to IP-related things right now. Improve display of multiple IPv6 contributions by a single editor on the other hand is a very simple wish to solve and we are happy to work on that. Sorry we can't help, and thanks for participating in the survey, MusikAnimal (WMF) (talk) 01:13, 3 December 2020 (UTC)[reply]
    • @MusikAnimal (WMF): "we believe the level of effort involved to solve this won't be worth the while given the future of IPs is uncertain": However, having a community opinion on whether this should be taken into consideration by the developers of the current effort. I again urge you to quickly consider the option of having a full wishlist where afterwards you make a top ## for problems for the wishlist team to work on, and a top ## that developers/WMF should prioritize (and there is then nothing wrong with pre-sorting these as 'this should be thrown in the general direction of WMF/developers', and 'this can be done by this team'). --Dirk Beetstra T C (en: U, T) 06:02, 3 December 2020 (UTC)[reply]
      They are aware :) The manager of the Anti-Harassment Tools team and the director of engineering was present in our meeting and they recommended archiving this as it would basically have to be done anyway as part of the privacy enhancement project. There's no need to keep reiterating the concept of a "full wishlist"; we agree and plan to broaden the scope next year, as I've said repeatedly. It has been a pretty stressful survey this year, so I really appreciate your cooperation. Thank you! MusikAnimal (WMF) (talk) 16:59, 3 December 2020 (UTC)[reply]

Harrassment and micro agression notification

  • Problem: continuing and recurrent micro agrression towards editors happen daily on all projects.
  • Who would benefit: all editors would beneficiate from a more friendly atmosphere, especially underrepresented communitie. People might start to pay more attention to the way they formulate their ideas and advices, if they knew that a simple procedure to track and notify these was present.
  • Proposed solution : a notification. procedure present on all lateleral boxes on all projects in all languages with which editors affected by rude language, derogatory terms and microagressions could generate a notification. Possibly by mailing them directly to an OTRS procedure, with copy to Trust and Safety and generating a non public data base which could be consulted by selected members of each community.
  • More comments:
  • Phabricator tickets : https://phabricator.wikimedia.org/T268366 and https://phabricator.wikimedia.org/T268366
  • Proposer: Nattes à chat (talk) 19:36, 20 November 2020 (UTC)[reply]

Discussion

  • I support this, or a mechanism like this, to make harassment / abuse / discrimination reporting much more accessible and to make sure that the reports are documented and go through the proper channels. RachelWex (talk) 21:18, 20 November 2020 (UTC)[reply]
  • I support this as a generic 'report' button next to every comment (maybe as part of Discussion Tools) that allows for quick reporting of offensive language to admins/other users. HappyMihilist (talk) 05:55, 21 November 2020 (UTC)[reply]
  • I'd expect the signal-to-noise ratio would be a problem. Probably the most common source of complaints are people upset that their edit was (correctly) reverted and/or someone tries to explain what was wrong with their editing. Users who are on the road to being blocked often complain everyone and every comment is somehow abusive against them. Alsee (talk) 06:24, 21 November 2020 (UTC)[reply]
    • Yup, which is why I propose that the complaints would not be put in a public database. However, the general feeling is that although this might be distorted and used against people who complain in the first place. the problem is that there is no procedure to moderate efficiently micro agrresions in our communities, and this is driving people away by creating a toxic climate. There is a contradiction between affirming that everybody is welcome and can edit, and allowing such toxic behaviors to thrive. Nattes à chat (talk) 10:38, 21 November 2020 (UTC)[reply]
  • I strongly support such a mechanism, which not only needs a technical solution but alos better professional and volunteer resources (including formation). Kvardek du (talk) 11:58, 21 November 2020 (UTC)[reply]
  • Strong support. It needs more details (to be discussed I guess). I think a OTRS system would be good, and a team of some trustworthy volunteers should handle notifications in their native language(s) - maybe through a T&S team and volunteers team cooperation on OTRS. Also, we need to find a way to avoid the "background noise", such as Alsee explained above. - .Anja. (talk) 16:33, 21 November 2020 (UTC)[reply]
  • +1. Thank you for this proposal--JMGuyon (talk) 17:58, 21 November 2020 (UTC)[reply]
  • +1, one of the hardest unsolved problems on this platform without satisfactory resolution. Micro aggression rarely warrant/result in warnings/punitive measures but they have an obvious negative impact on community editing. — Shushugah (talk) 21:25, 21 November 2020 (UTC)[reply]
  • I think such a system will clash with existing reporting places on each wiki (i.e you'll see complaints about an user ending up both on OTRS and en:WP:ANI and equivalents) unless it can be configured to redirect complaints to a configurable venue. Jo-Jo Eumerus (talk, contributions) 08:55, 23 November 2020 (UTC)[reply]
  • Strongly against. There's no scientific validation for the concept of micro aggression and no way of establishing standards, it's a tool to further politicize and corrode WP. We need less administrative overhead and minder control, be it self-appointed or community-led, not more. --Tickle me (talk) 21:47, 24 November 2020 (UTC)[reply]
  • Strongly oppose this Orwellian proposal. Wikipedia does not need to become even more bureaucratic and, as an open project, should not have a secret database of user behavior. What's next? Mandatory behavior modification and reeducation camps for editors? Disagreements between contributors, including their behavior, can and should be resolved in public on talk pages. --Ehn (talk) 03:26, 25 November 2020 (UTC)[reply]
  • Procedurally - I don't see how this can happen without a discussion with the community. I think this is basically a policy proposal and should be disqualified on those grounds. I am also concerned about having another shadow system of "governance" that would result in w:en:WP:FRAM all over again - where the evidence received cannot be reviewed or responded to by the alleged perpetrator. --Rschen7754 06:26, 25 November 2020 (UTC)[reply]
  • +1 --El Pantera (talk) 11:32, 25 November 2020 (UTC)[reply]
  • +1 we need some action about the continuous low grade harassment, that passes for discussion, and provides cover for the incivility. we need a trained response team to deal with anti-social annoying users that harm the project, i.e. Fram, and his enablers. Slowking4 (talk) 02:20, 27 November 2020 (UTC)[reply]
Hello Slowking4 May I respectfully request that you review your comment and revise it so that it focus on questions and possibly concerns about the proposal? Tagging other users as "anti-social" is inappropriate. I am requesting this revision so that current and future participants feel that they can participate in the discussion without having to make or receive unfriendly remarks or personal attacks such as this. Happy new year in advance. T CellsTalk 19:27, 3 December 2020 (UTC)[reply]
"anti-social" is appropriate. that was not a personal attack, that was an accurate description of that banned admin's behavior. it is important to give examples of which behavior is uncivil yet tolerated by a clique of admins. see also [5] Slowking4 (talk) 20:57, 7 December 2020 (UTC)[reply]
  • Oppose. I think the cost would out way the benefit. There would be massive number of meaningless complaints that would effectively stifle any actual action against more major problems. People are imperfect, and generally, pointing fingers doesn't make things much better. Mulstev (talk) 07:00, 28 November 2020 (UTC)[reply]
  • I am against it. At the limit, if the reports are public and referred to arbitration committees, why not. To make the reports private would prevent an important step back from the dispute, in my opinion. --TechAcquisitor (talk) 22:24, 28 November 2020 (UTC)[reply]

I totally and utterly oppose this proposal. I think if people actually properly understood what it meant it would have been deleted. We would not tolerate a proposal which discriminated against wikipedians for being gay or black. We wouldn't even allow such a proposal. Yet, the scientific and medical evidence shows unequivocally that this proposal is functionally identical. It discriminates against people for states of being, in exactly the same way as homophobia and racism discriminates. I am one of those discriminated against. This is scientist-phobic behaviour. It discriminates against me for being a scientist. It it discriminates against people for being scientific as a personal characteristic like sexuality or skin colour. Scientific people tend to be blunt and logical. This sometimes upsets people who aren't like that. As you can see from the way I am saying this I am outspoken, I don't make personal attacks on Wikipedia, but sometimes it is necessary to tell someone they are wrong quite directly. An example would be where I edited the Astrid Peth article and told a Dutchman that I didn't think he should be debating the meaning of words in the Welsh language. He clearly didn't speak it and I am fluent. It is the native language of my homeland. If you want good articles you need competent writers. This will really damage scientific editing. It is also a very American centric view. There seems to be a rise in "offence culture" in the USA. Incidentally, I should say that there is a political divide on this. I don't match that. I am not right wing at all. If I lived in the USA I would be a Bernie Sanders man. I wouldn't describe some people as "snowflakes" as some in the USA do. The evidence on the effect of microaggressions is very charitably expressed as poor at best. This is like creationism versus evolution or flat vs round earth. The evidence clearly shows what is true. Get an expert. This is a subtle medical matter and you don't decide these by a vote. Reject this proposal. It is bad. Here is an article on the science from one of the websites run by the journal Nature, one of the leading science journals in the world. https://www.natureindex.com/news-blog/scientists-are-curious-and-idealistic-but-not-very-agreeable-compared-to-other-professions I don't think secret, Spanish Inquisition type lists are a good idea either. ( USER Neilj) Neilj (talk) 12:43, 29 November 2020 (UTC)[reply]

  • "Microagression" is a neologism for rudeness. Rudeness is unfortunate and I certainly don't support or practice it, but it is also entirely subjective and frequently boils down to a clash between styles of communication, such as factual vs. non-factual. Trying to politicize and legislate rudeness would be a very slippery slope toward censorship, which is why it should not be done. Instead, what we should do is deal with instances of rudeness the way people have always done: through communication. If a particular user's behavior becomes disruptive, there are already mechanisms to address that. Silver hr (talk) 17:58, 30 November 2020 (UTC)[reply]
  • This is a good proposal. Any emails to this system that aren't legitimate could be sent a templated message back -- it isn't that time consuming. Meanwhile, legitimate emails could be dealt with. I specifically like the idea a system where people could just ask opinions on what to do/say (OTRS does this already to a certain extent but it isn't exactly what it's meant for). Sam-2727 (talk) 03:10, 1 December 2020 (UTC)[reply]
  • Opposed. In contested areas of the project, this will become just another way that editor warriors try to get their opponents. Since each and every report will have to be accessed by a human, "success" of the proposal will mean that there is a permanent long backlog. There are already mechanisms for reporting editors whose behavior is unacceptable, and I think it is a good thing that making such a report takes some effort and allows some time to cool down. Zero0000 (talk) 09:01, 1 December 2020 (UTC)[reply]

Hi all. Thanks for the proposal and the discussion. I work with the Community Tech team and the Anti-Harassment Tools team so I'm in a position to speak to this. Specifically, I will archive this wish as out of scope for Community Tech. However, I can report that the Anti-Harassment Tools team has been researching how to build a per-wiki configurable system of reporting, managing reports, and sharing results of those reports of harassment issues of various degrees. We (the Anti-Harassment Tools team) hope to work on this in 2021. To that end, there will be a lot of community consultation, research reports, UX testing, and other ways to get involved in that conversation. I can't address some of the opposition here because it appears to be directed specifically at the notion of "microaggression." Our goal on the team is to build a tool that allows each community to manage harassment in the way they see fit with strong support for best practices. Again, this wish is out of scope for the Community Tech Wishlist but what I see as its spirit will be worked on by the Anti-Harassment Tools team hopefully in 2021. --AEzell (WMF) (talk) 00:38, 2 December 2020 (UTC) [reply]

Reference tools in the source editor

NoN Proposes existing solution

  • Problem: In the French source editor (I don't know others), we can't make references automatically (with an ISBN or a Doi for example). We have to make it manually or use the visual editor. However, making it manually is time-consuming and the visual editor is too greedy on computer resources as CPU and internet speed for old computers and bad connexions.
  • Who would benefit: Contributors with old computers and bad internet connexions, as well as contributors who don't like writing with the visual editor.
  • Proposed solution: Make a lightweight reference tool in the source editor. Before the creation of the visual editor reference tool, I used to write references with this external tool : Refswikipedia by Lebronj23 (fr). But it doesn't work anymore.
  • More comments: Thank you for your work and have a good day.
  • Phabricator tickets:
  • Proposer: Abalg (talk) 09:54, 17 November 2020 (UTC) (fr:utilisateur:Abalg)[reply]

Discussion

Hello. I cannot say anything about the difficulty of implementing such a tool in the source editor. I also do not know how many people have problems using the visual editor. I stopped maintaining the tool mentioned above for ISBN and DOI notably because the visual editor is already doing a good job there. I preferred to focus on web links, where the tool really has an added value compared to the visual editor. If many people are interested, I could implement some patches to get the DOI and ISBN working again when I find some time for that. It should not be too complicated. It will not solve the problem on the long run however. Regards, --Lebronj23 (talk) 21:41, 17 November 2020 (UTC)[reply]

Can we generalize this beyond the French wikis, Abalg? Many other wikis (including English Wikiversity) do not have Citoid facilities either, which is a bit discouraging and reduces their appeal. Anywhere that Visual Editor has the tools the source editor should too. HLHJ (talk) 01:13, 24 November 2020 (UTC)[reply]
Hello HLHJ, I'm agree with you. --Abalg (talk) 01:45, 24 November 2020 (UTC)[reply]

Note that Citoid is available in the mw:2017 wikitext editor. ESanders (WMF) (talk) 13:25, 26 November 2020 (UTC)[reply]

The wikitext editor is what I name the visual editor. The problem concern only the source editor. Regards. --Abalg (talk) 13:34, 26 November 2020 (UTC)[reply]

There is en:Wikipedia:ProveIt and en:Wikipedia:RefToolbar in enwiki for old wikieditor which sounds same --Zache (talk) 16:07, 27 November 2020 (UTC)[reply]

Hello Zache, ProveIt seems to work good (I just install it and taste it). But it's not a native solution. The reftoolbar seems to be a great solution too. And a native one. Except in the French wikipedia. Do you know how can we transfer it on the French wikipedia and other languages? Regards. --Abalg (talk) 14:31, 30 November 2020 (UTC)[reply]
Technically yes, in fiwiki it is gadgets (under label testing and not supported) and it more or less works. However, there is currently some case sensitivy issues with template parameter names which would require checking why they dont work. We had some users who used this couple years ago and now i just updated the code and copied it to gadgets to see if it would still work. However, there are our fiwiki files and configs as for an example if you want to try it out in frwiki.
--Zache (talk) 19:23, 30 November 2020 (UTC)[reply]
To load the gadget from enwiki (mw.loader.load( '//en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-MediaWiki:RefToolbar.js&action=raw&ctype=text/javascript' );) it would require changes to enwikis version. This is how the most of the smaller wikis would like to do it so the upkeep would be centralized. --Zache (talk) 20:42, 30 November 2020 (UTC)[reply]
  • I'm merging a similar wish:
  • Problem: Fully completing all the information for a good citation referencing a URL can be daunting for new or inexperienced users
  • Who would benefit: Pretty much all editors, I think.
  • Proposed solution: When someone adds a citation using the shortcut (ref/ref insertable markup), either:
    1) automatically recognize when a URL has been cited, format it properly (perhaps even test it), add a retrieval date and take care of other housekeeping, or
    2) bring up a dialog box to allow the editor to (optionally) complete the citation

Ping the proposer: @Patrickwooldridge: SGrabarczuk (WMF) (talk) 14:52, 4 December 2020 (UTC)[reply]

Option to Switch between Metric and Imperial Units Site-wide

NoN Does not require engineers

  • Problem: Current implementations of unit measures in Wikipedia are inconsistent at best and confusing at worst.
  • Who would benefit: Any users trying to get consistent units for things such as climate data, distance information, etc. One would not see imperial units preferred for articles in the United States or targeted at Americans or metric units preferred for non-American articles.
  • Proposed solution: Offering a site-wide option to switch between metric and imperial units in settings or in articles themselves.
  • More comments:
  • Phabricator tickets:
  • Proposer: Benjamin (talk) 14:48, 19 November 2020 (UTC)[reply]

Discussion

I wonder how this would be implemented: currently someone may simply type 'this stuff has a length of 200m' ... How to identify for sure that the notation 200m is a length unit, or if the editor want to say something else? Maybe add some sort of tag, mentioning an amount and an unit ? Something like 'this stuff has a length of \[\[unit amount:100 unit:meters\]\]'? AlexanderPicoli (talk) 16:31, 19 November 2020 (UTC)[reply]

A lot of instance go through en:Template:Convert which could add metadata to help with this.
This is really only relevant to en.wikipedia.org, which unfortunately is the largest site. Maybe there should be an autogenerated variant at en-us.wikpedia.org for non-metric use. Crissov (talk) 10:54, 20 November 2020 (UTC)[reply]
My thoughts on utilizing an en-us vs an en-uk, etc to denote unitary measurements wouldn't be very helpful for someone like me, who is an American who uses metric over imperial, although I like the idea of splitting the Wikis up by dialect. For a feature like this it might just need to be slowly implemented over time as people update articles with a new formatted text like AlexanderPicoli mentions above. Benjamin (talk) 16:10, 22 November 2020 (UTC)[reply]
There are also UK people who use imperial units: our road signs show miles rather than km. One implementation might be for Convert, when showing the same value in both metric and other units, to wrap them in different classes, and to create a gadget allowing a reader to hide either of them easily with CSS. Certes (talk) 01:53, 23 November 2020 (UTC)[reply]
I considered this in the past. It will be helpful to be able to define certain user preferences (currency, unit system, etc) so a template like that will be better targeted (i.e. I may want to only use kilometers whilst an american may want miles. Default users may be shown both). I see no need to integrate the conversion in text parsing. It may only provide a variable to templates. It will be human work (or bot work) to put the {{Convert}} when needed.--FAR (talk) 09:54, 29 November 2020 (UTC)[reply]
  • This is a good idea, although it would require semantically tagging all instances of quantities in article text. However, it would be immediately useful for data that's pulled from Wikidata. Silver hr (talk) 02:02, 1 December 2020 (UTC)[reply]
  • We discussed this as a team and feel that while the problem statement is valid, the solution is to use templates like en:Template:Convert. A one-size-fits-all solution as proposed is very unlikely since there are situations where showing a certain format is intentional. There could also be false positives in detecting what is a unit of measurement and not just something that looks like one. The easiest solution is to use the template, and usage of it should be left to editorial discretion. As such we're going to archive this. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 18:06, 4 December 2020 (UTC)[reply]

Requests or Suggestions

NoN Overlaps with talk pages project

  • Problem: It's very important to get updates after you make a request or suggestion. This is especially true in cases where editors are obligated to announce their intention in the discussion page and wait a certain amount of time before taking action. It's too easy to see a problem, leave a message with a proposed course of action, and then forget all about it - because there were no comments by other editors.
  • Who would benefit: Editors
  • Proposed solution: Allow editors to mark themselves as "authors" of a specific section in a talk page, which means they should be notified of any new edit in that section. Also, allow creation of reminders to revisit a certain talk page in X amount of time.
  • More comments:
  • Phabricator tickets:
  • Proposer: Joalbertine (talk) 19:52, 17 November 2020 (UTC)[reply]

Discussion

  • In effect this is section-watchlisting, which was part of the discussion had with Discussion Tools - it's particularly difficult in order to make it handle reformatting of section headers, merging, and so on. At the time when they asked which we're rather have, page or section-watchlisting, the consensus was the former was the critical, the latter a nice to have. Nosebagbear (talk) 15:24, 18 November 2020 (UTC)[reply]
It sounds similar, but in this context I brought it up for a specific purpose - following comments (or lack thereof) on a discussion that I initiated. This discussion is actually a perfect examle: I'd like to be notified whenever a new comment is added in reply to my proposal above. In this particular case, "section-watchlisting" won't be necessary because each proposal is automatically divided to a separate page. There needs to be some way for me to define this discussion as a special interest. As I explained above, the same goes for proposals made in the form of templates. Notifications are needed for new comments or the complete lack of comments after a certain period of time. --Joalbertine (talk) 19:36, 21 November 2020 (UTC)[reply]
  • @Joalbertine: That makes sense, but still kind of confusing. User:MemeGod27 3:20, 18 November 2020 (EST)
  • Section watchlisting would be great, but the other part of this is just reminding yourself to check back in on proposals you've made where w:WP:SILENCE would be sufficient to take action. I know there are some gadgets that help you manage a to-do list, and improvements to those to implement functionality like timed reminders would be fantastic. Right now, the old-fashioned method of just keeping a list of links in one's sandbox works but isn't very efficient. {{u|Sdkb}} talk 03:04, 19 November 2020 (UTC)[reply]
  • Section watchlisting will be part of the talk pages project, so look forward to updates on that in the coming year. Page reminders on the other hand is something that we investigated following the 2019 survey and unfortunately had to decline. You can read more about that in the status report. That said there's not anything Community Tech can do help with this proposal. Sorry! Thanks for participating in the survey, MusikAnimal (WMF) (talk) 18:39, 4 December 2020 (UTC)[reply]

Most między serwerem Discord i kanałami IRC

NoN out of the scope and mandate of the Product department

  • Problem: Społeczność wikipedystów na platformach Discord i IRC jest rozdzielona.
  • Kto zyska: użytkownicy IRC oraz Discord
  • Proponowane rozwiązanie: Wykorzystanie bota do stworzenia połączeń między platformami komunikacji.
  • Dalsze informacje: Komunikowanie się z osobami na serwerze Discord bez zakładania konta na tej platformie jest niemożliwe, nie ma też oficjalnej możliwości na użycie innej aplikacji klienckiej. Korzystanie z IRC nie jest tak przyjazne dla nowych użytkowników, lecz jest otwartym standardem, dzięki czemu każdy może korzystać z wybranej przez siebie, dowolnej aplikacji klienckiej, na dowolnej platformie i urządzeniu. Połączenie platform sprzyja współpracy między użytkownikami z różnymi możliwościami i preferencjami, co przekłada się na zwiększenie dostępności. Rozwiązania stosujące boty do połączenia społeczności między różnymi platformami komunikacji są już stosowane na serwerach niektórych projektów FOSS takich jak np. https://www.lineageos.org, https://lutris.net

Dyskusja

  • @Acetylen: dzięki za zgłoszenie pomysłu.
    1. Niestety, nie może on zostać dopuszczony do głosowania społeczności z powodów formalnych - tymi sprawami zajmują się zupełnie inni ludzie w Fundacji, którzy mają inne możliwości, ale też mogą mieć inne plany. Nie znaczy to, że nic nie da się zrobić. Przekażę im Twój pomysł.
    2. Fundacja pracuje nad zmostkowaniem różnych programów czatowych (patrz: Matrix.org, który obsługuje Slacka i IRC). Nie wiem jednak, czy w grę wchodzi para Discord - IRC. Różne społeczności Wikimedia korzystają ze Slacka, Telegrama, WhatsApp i pewnie jeszcze kilku innych. Technicznie zmostkowanie bywa łatwe, ale Fundacja musi analizować każdą parę czatów pod kątem licencyjnym i bezpieczeństwa (prywatności). Dlatego, chociażby z powodów prawnych, część połączeń być może nigdy nie będzie zbudowana albo nie będzie dostępna dla każdego wikimedianina.
    3. Technikaliami polskojęzycznego Discorda zajmuje się @Yarl:. Jeśli interesuje Cię połączenie czatów dla społeczności polskojęzycznej Wikipedii, Yarl (czy inni technicy Kawiarenki technicznej) wydają się właściwymi adresatami.
SGrabarczuk (WMF) (talk) 18:42, 4 December 2020 (UTC)[reply]

Template

NoN Outside the scope of Community Tech

  • Problem: In mobile it's very difficul watch Navigation template on mobile
  • Who would benefit: It'll be more simple go to other pages
  • Proposed solution: Do something to could see Navigation template on mobile
  • More comments:
  • Phabricator tickets:
  • Proposer: --Esc0fans (talk) 07:04, 17 November 2020 (UTC)[reply]

Discussion

User page and User Talk looks terrible on mobile wikipedia app

NoN Not an engineering issue

  • Problem: User page and User Talk looks terrible on mobile wikipedia app.
  • Who would benefit: Everyone.
  • Proposed solution: Make them seen as seen in any computer.
  • More comments:
  • Phabricator tickets:
  • Proposer: #Safuan 14:56, 17 November 2020 (UTC)[reply]

Discussion

উইকিঅভিধান

NoN community editing practice

  • Problem: If I have time, I work on Wiktionary. We add some of the words, phrases, proverbs, etc. that come to our notice to the Wiktionary. But sometimes it is said - 'It's not on the wiki, ...'! Yeah Al that sounds pretty crap to me, Looks like BT aint for me either. My guess is that there are a lot of Bengali language researchers among the development volunteers of the wiki, who will research and edit all the new Bengali words, phrases, proverbs, etc. for adders like us.
  • Who would benefit:
  • Proposed solution: In addition to Bengali phrases and proverbs, at least one example needs to be given, [such as: "Raghab Boal" - many "Raghab Boals" will be caught if investigated.] So that the matter becomes clear to the reader / viewer. In this case, the wiki page design should be done in the same way. I can write examples if necessary.
  • Other comments:
  • Phabricator tickets:
  • Proposer: Sumasa (talk) 06:15, 17 November 2020 (UTC)[reply]

আলোচনা/Discussion

  • Hello @Sumasa: thank you for your proposal. Correct me if I'm wrong, but it seems to me as if you were putting forward an idea for the community (how they should edit Wiktionary). On the other hand, The Community Wishlist Survey is dedicated for proposals which require engineers' contribution. Here, we are collecting wishes for tools like Watchlist Expiry or Global preferences. This is why I'm archiving your proposal. You are free to discuss with your community how the content of Wiktionary should be shaped. SGrabarczuk (WMF) (talk) 19:40, 4 December 2020 (UTC)[reply]

Bien définir les noms et les prénoms pour ne pas faire d'erreur dans les éphémérides

Discussion

WikiMaps - a proprietary tool for map editing

  • Problem:

For the presentation of maps we use static, ready composed images. Editing and uploading vector graphics, variants, language versions, generates a lot of data rubbish. We do not understand maps like articles that can be edited in detail and where even small edits have to be justified. There is no intelligent discourse about boundaries and there is no database of information from which aspects can be added or hidden depending on the article area. The huge amount of work that is put into the maps could be used in a much more meaningful and sustainable way. But for this we need a completely new tool that helps us to understand maps like Wiki articles. This would lead to maps that also have a recognizable global style.

  • Who would benefit:

Simply put: everyone, except those who would have to implement the whole thing.

  • Proposed solution:

Objective: I would like to select maps for an article from a special map archive. Enter a period of time in this archive, select a section on a world map with the mouse. In the search mask I can search for information available for this temporal and spatial section and add it. For example, I can also select country and district boundaries, places with 100,000 inhabitants or more and the distribution of forests and finaly the information of a certain battle. The archive gives me a code which I simply insert into my article in Wikipedia. Summarised: I would like to be able to compose a map from layers of information.

Implementation: Every piece of information such as area or points of a border would have to be stored in a geo-referenced form. These would be assigned a period of time for which this boundary applies. In addition, further parameters would be added, such as the type of boundary or the subject area to which the information belongs. Each entry (like a boundary) is to be understood as a Wiki article in its own right. The exact course of the border can be debated on discussion pages, and sources can or must also be cited.

  • More comments:

Disadvantage: Such a project is a huge amount of work for some people. And that is a strong trivialisation.

Some Advantages:

  1. The work of the users would have a much much greater value. No entry would be wasted, nothing would be lost.
  2. Users could work together on geo-referencing.
  3. With Wikidata we already have the perfect tool to implement the project.
  4. With OSM we have map material that we can use as a resource.
  5. With georeferenced maps, you also have all the freedom you need. Not only two-dimensional maps can be output, but also three-dimensional ones.
  6. Furthermore, gifs or videos can be used to show the historical changes.
  7. Even tectonic and climatic changes could easily be depicted and displayed as gif.
  8. All linguistic aspects would be solved.

Objections: It is always said that there are other projects like OSM who are responsible for such endeavour. However, OSM has a completely different approach than my proposal, has no historical component and is far less effective in daily use. The reality is that we create our own maps and they are static, uncheckable and uncollaborative. There are projects here and there on the internet to georeference historical maps. But these projects regularly fail or cannot provide a tool to edit and debate borderlines in detail. Furthermore, the source of these maps is, politely put, critical.

Discussion

I think this is done, N3MO, using OSM's database. See, for instance, the source of en:Ōnawe Peninsula. My understanding is that OSM is developing historical dimensions. I'd certainly support more collaboration there; I think we have a lot to learn from OSM when it comes to collaborative databases. Since OSM's data is copyleft, and Wikidata still can't take any license but CC0, we can't use OSM data on Wikidata, and I do not think that duplicating that datagathering effort would be good. Duplicating the effort of making map-editing interfaces would also not be good. HLHJ (talk) 02:01, 24 November 2020 (UTC)[reply]

  • @N3MO: As JLJH points out, we already use dynamic, collaboratively-editable maps in wiki pages (which have a standard cartographic style). These use data from OpenStreetMap, and in many cases avoid the need to create individual SVG files. Of course, as you point out, there are many situations in which other sorts of maps are required: historical geography, or varying cartography for different information display. For the former, the OpenHistoricalMap project is aiming to build a database of historical maps, and the latter is usually done most effectively with a purpose-made tool such as en:QGIS (which is open source). Regarding sourcing, Commons of course accepts scans of old maps, and the warper tool can be used to vectorize these. There are certainly improvements to be made, but starting from scratch with a new system isn't the best way forward. —SWilson (WMF) (talk) 02:12, 7 December 2020 (UTC)[reply]

Search Wikidata items from Lua

  • Problem: There is impossible to look for Wikidata item if no article is associated with the item. However many of the items are filled with properties of type 'external identifier'. The identifiers are mostly (I hope) unique by design. I wish to use them for searching.
  • Who would benefit: Template designers.
  • Proposed solution: Provide new API function in Lua interface: mw.wikibase.getEntityIdForExternalId( propertyId, externalIdValue )
  • More comments: The ability for searching gives us opportunity to create generic citation template, which might be easier to use.
  • Phabricator tickets:
  • Proposer: Paweł Ziemian (talk) 23:09, 27 November 2020 (UTC)[reply]

Discussion

  • @Paweł Ziemian: I'm not sure I quite understand. Do you mean for when you want to use Wikidata in a page with no sitelink, but you do have an external identifier? In that situation, why wouldn't you be able to use a Wikidata ID instead? That could then be used to retrieve the external ID as well as anything else. You mention a generic citation template — is something like {{Cite Q}} what you have in mind? —Sam Wilson 00:17, 4 December 2020 (UTC)[reply]
    • Some external identifier are much easier to find. Let compare Qid to RFC or DOI number. The Q is magic and not easy available. In contrast, DOI or RFC are printed in the document. Paweł Ziemian (talk) 19:57, 4 December 2020 (UTC)[reply]
      • That's true, but even if you already know the DOI, the Wikidata item needs to have been created, and then searching Wikidata with the relevant identifier works perfectly well. For example, if you want to cite the DOI Handbook but only know it's DOI of 10.1000/182, then searching Wikidata for that finds it, at which point you can cite Q69415441 instead. —Sam Wilson 02:23, 7 December 2020 (UTC)[reply]
        • But this method is very inconvinient for Wikipedia editors. Needs some additional work. More effective solution is to write article related content and put dot and reference to cited document as easy as possible. As far as RFC is concerned, I was able to manage it via private map from RFC id to Qid. But this solution is possible only for cases when the whole set of identifiers is relatively small. Paweł Ziemian (talk) 20:37, 8 December 2020 (UTC)[reply]

Function to display all images of a category together with its sub-categories

NoN Proposes existing solution

  • Problem: In Commons there are many categories with sub-categories; I would like to see all images of a certain category together with the ones of its sub-categories and sub-sub-categories and so on (at least to a certain level).
  • Who would benefit: Anyone who looks for an image which is hidden in a sub- or sub-sub-category.
  • Proposed solution: Provide such a missing option (in principle similar as it is provided for coordinates by WikiMap in the German Wikipedia)
  • More comments:
  • Phabricator tickets:
  • Proposer: Slimguy (talk) 20:08, 19 November 2020 (UTC)[reply]

Discussion

There are several gadget to do intersections and combinations of categories. Maybe the task should be adapted to integrate in the default mediawiki approach for all wikis? I'm afraid many users just don't know them.--FAR (talk) 10:59, 29 November 2020 (UTC)[reply]

Open linked article preview within page

NoN Proposes an existing solution

  • Problem: Reading an article is made difficult if you need (or want) to read articles in link, for example to understand where the action takes place, etc. You keep opening and closing new tab,s or clicking the "back" arrow of the browser, which by the way seldom bring you back where you were.
  • Who would benefit: any one reading
  • Proposed solution: give an (optional) possibility to open article preview integrated as insert in the article. How needs to be clarified (right click?)
  • More comments:
  • Phabricator tickets:
  • Proposer: Gfombell (talk) 05:44, 17 November 2020 (UTC)[reply]

Discussion

  • Are you describing mw:Page Previews? Logged out users see these by default, and logged in users can enable them, at least on the English Wikipedia, in their Preferences (under Appearances there is a "Reading preferences" section). — Bilorv (talk) 19:52, 17 November 2020 (UTC)[reply]
  • I think mw:Page Previews could be expanded. For example, you could control how big the popup is, and thus how much content appears. The way I understand this proposal, an insert of the linked page would appear directly in the page. This would be helpful to compare information between two pages, as well as in sections, as you could still scroll. Other ideas include a popup pane that remains open and follows as you scroll, a scrollable insert page, a popup with clickable index, and a side-by-side or multipage view. — Dr.Wiki0 (talk) 13:01, 20 November 2020 (UTC)[reply]
  • @Gfombell: Does mw:Page Previews do what you want, or would you like to see improvements to this feature? MusikAnimal (WMF) (talk) 21:24, 2 December 2020 (UTC)[reply]
  • Since we have not heard back from you, I'm going to archive this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 15:22, 7 December 2020 (UTC)[reply]
  • Hi and sorry not to have followed-up. I think the pop-up is a good thing but an insert in the page would make the reading easier. One could imagine a possibility to open it (For example righ-click and selecting "open as insert" on the page"), move it, resize it (showing more or less content) scroll within, and close it. Gfombell (talk) 19:20, 3 May 2021 (UTC)[reply]

NoN Proposes existing solution

  • Problem: when I am searching for things sometimes it gives me multiple results and it's confusing.
  • Who would benefit:anyone who wants a more accurate search.
  • Proposed solution: when you click on the search bar a dropdown menu for categories will pop up, you can search within a category to get better results you can select a category from the dropdown menu or just search without a selected category.
  • More comments:
  • Phabricator tickets:
  • Proposer: Keelanscanlan (talk) 16:18, 20 November 2020 (UTC)[reply]

Discussion

  • @Keelanscanlan: You can search by category now. Go to Special:Search, and under "Advanced search options" look for the "Categories" section. There are also many other options that can help you find what you're looking for. Does this satisfy your wish? MusikAnimal (WMF) (talk) 20:12, 20 November 2020 (UTC)[reply]
  • When I am searching for pictures in Commons sometimes and I want to work with these (categorizing images etc.), I first get a long list of proposals, eg. re. "Iceland " + 2020 and categorize one image in the middle of the search list/page, afterwards I have to start searching the list of possible images again to know where I was last because the courser goes up on the page; it would be better to get back to the last picture I was working with. Hornstrandir1 (talk) 16:18, 20 November 2020 (UTC)[reply]
  • Since we have not heard back from you, I'm going to archive this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 15:24, 7 December 2020 (UTC)[reply]

Interactive article editing view tool

NoN Proposes existing solution

  • Problem: Sometimes I look up at an article with improvement intention, and see parts of it which are very specific, so I wouldn't need to look all the page's history to find who made that line or fragment.
  • Who would benefit: Everyone who wants to check article edits quickly, and then to edit on them, instead of seeing all the history comparisons.
  • Proposed solution: I propose a new tool, that as the Visual Editing does, has an interface which leads to the editor a direct interaction with the normal article view screen. The thing goes like this:
    • The editor presses the button to open the tool interface.
    • In that interface, the editor is able to click or simply pass by the cursor around the text shown in the article, and then suddenly bringing information about the date a line or related has been last changed, edited, or written. This is basically the history data.
  • More comments: There is no need to go deep into the design part. But a easy way to represent this is by selecting the part of the article you want, and maintaining it in a box, of which the data appears.
  • Phabricator tickets:
  • Proposer: De un millón (talk) 22:50, 20 November 2020 (UTC)[reply]

Discussion

  • @De un millón: This exists! Allow me to present to you... Who Wrote That?. This was built by Community Tech in response to the #4 wish on the 2017 survey. It is available as a browser extension. Only a handful of wikis are supported, but I see Spanish Wikipedia is your home wiki, which is supported. Does this work for you? If the browser extension is not satisfactory, you could revise your proposal to turn it into a gadget. I think that would be fine. Or, if there are other Wikipedias you would like to be added, that might make for a good proposal too. Unfortunately we can't add every wiki/language, at least not in the short-term. Let me know what you think! Regards, MusikAnimal (WMF) (talk) 23:06, 20 November 2020 (UTC)[reply]
@MusikAnimal (WMF):I have read the tool overview, but I don't understand why it isn't allowed in mobile devices, wondering it in a general sense; maybe it's due to a format trouble or a storage saturation (perhaps, because the computer/desktop view is faster and more confident).
If there aren't any problems at all, then why not? (At least it should be made to the APP) Regards, --De un millón (talk) 01:04, 21 November 2020 (UTC)[reply]
@De un millón Extensions for mobile browsers aren't a thing (yet). I can't seem to find a Phabricator task, but I do recall the one of the mobile teams talking about adding Who Wrote That? functionality into the app, so that might be in our future. At any rate, as written this proposal is for something we already built. Would you like to reword it to be about making Who Wrote That? work on mobile, and/or a gadget (if it's a gadget, you can load it in your own Minerva.js)? MusikAnimal (WMF) (talk) 21:18, 23 November 2020 (UTC)[reply]
On open-source mobile phones, extensions to mobile browsers are in beta last I heard. I would like a non-browser-dependent version of this, tho. HLHJ (talk) 02:33, 24 November 2020 (UTC)[reply]
Actually extensions are a thing for mobile browsers. Firefox v78+ supports only a handful of manually picked extensions, but v68 and before had quite well WebExtensions support; Samsung Internet allows installing browser extensions from Galaxy Store (developers need to join a closed beta); Kiwi Browser allows installing directly from Chrome Web Store; and so on. When Who Wrote That? was developed, Firefox still supported WebExtensions, so it would have been a question of ticking a checkbox to release it on mobile; it was not because of no extension support that it wasn’t released for mobile. It was rather because the current design of the tool simply doesn’t work on touchscreen devices—it shows data on hover, which is not really a thing with touchscreen, and the developers were not willing (so far) to redesign the whole thing. Maybe convert this wish to ask WWT specifically for mobile, and see how it goes? —Tacsipacsi (talk) 23:34, 25 November 2020 (UTC)[reply]
@De un millón: If you are able to reword the proposal to be about making Who Wrote That? work on mobile, we can accept it. We have until December 8 at 18:00 UTC to fix this (when voting starts). For now, since we haven't heard back from you, I'm going to archive this proposal. We can move it back if the proposal is reworded in time for voting. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 16:07, 7 December 2020 (UTC)[reply]

Let Visual Editor to edit references in notes

NoN Unclear proposal / proposes existing solution

  • Problem: Visual Editor cannot handle references in notes.
  • Who would benefit: every editor, new editors
  • Proposed solution: Let Visual Editor to handle references in notes the same way as every other reference on the page.
  • More comments:
  • Phabricator tickets:
  • Proposer: Juandev (talk) 20:01, 21 November 2020 (UTC)[reply]

Discussion

More Video on Commons

NoN Proposes existing solution

  • Problem: Wikipedia is relaying too much on text whilst video is becoming more important as information source for new generation. To upload a video to commons you have to be a real techies to have the right format which is not obvious for anyone.
  • Who would benefit: all users: new generation and people who has reading difficulties
  • Proposed solution: provide a way to import open licence video from video platforms e.g. vimeo or provide a simple way to convert video to the acceptable commons format.
  • More comments:
  • Phabricator tickets:
  • Proposer: Yamen (talk) 13:18, 21 November 2020 (UTC)[reply]

Discussion

Hi @MusikAnimal (WMF):, apologies for not coming back to your question earlier. Yes the Video2commons tool works but it's producing very simple and not attractive videos. I was hoping that it could be improved in order to add some Ken Burns effects for example. besides that I was hoping to simplify the process of uploading a videos in commons (which is now very complicated as you need to convert the file beofre or uplaod it to a third party plateform like youtube and then import it back to common).Yamen (talk) 15:54, 21 December 2020 (UTC)[reply]

Better display of videos on mobile browsers

NoN Unclear proposal

  • Problem: Currently it's not possible to play directly a video on a wikipedia page using a mobile browser. Another page will be opened.
  • Who would benefit: all the users viewing wikipedia pages using mobile browsers
  • Proposed solution: video shoud be played smoothly in the same page.
  • More comments: Video is becoming the main source of information for many peoples (especially the new generation) and currently Wikipedia is relying too much on text and photos but in the same time even if we add video content it's not very well managed and displayed.
  • Phabricator tickets:
  • Proposer: Yamen (talk) 13:14, 21 November 2020 (UTC)[reply]

Discussion

Bulk upload program

NoN Proposes existing solution Deutsche: Programm zum Massenupload

  • Problem: There are programs like Commonist or Vicuña, but they have not been maintained for a long time. For uploading larger amounts of images you need something like that, only in an improved form.
Deutsche: Es gibt Programme wie Commonist oder Vicuña, die werden aber schon lange nicht mehr gepflegt. Für das Hochladen größerer Bildermengen braucht man so etwas, nur in verbesserter Form.

Discussion

Das ist keine Alternative. --Ralf Roletschek (talk) 20:29, 1 December 2020 (UTC)[reply]
@Ralf Roletschek: warum? Would it be possible for you to write more what would you expect from a proper alternative? SGrabarczuk (WMF) (talk) 15:05, 4 December 2020 (UTC)[reply]
Since we have not heard back from you, I'm going to archive this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 17:13, 7 December 2020 (UTC)[reply]

Create the Legislative Branch section in the country templates

NoN Unclear proposal

español: Crear el apartado de Órgano Legislativo en las plantillas de países

  • Problem: This proposal arises from the advantage of having a section for the legislative body in the Country File, since currently to indicate it it is mandatory to access WikiData.
español: Esta propuesta surge de la ventaja que es tener un apartado para el órgano legislativo en Ficha de País, ya que actualmente para indicarlo es obligatorio acceder a WikiData.
  • Who would benefit:
  • Proposed solution: In the way that I propose it, it would be as simple as accessing the Country File template and adding the code / section of the legislative body (org_leg).
español: De la manera que lo propongo sería tan sencillo como acceder a la plantilla de Ficha de País y añadir el código/sección de órgano legislativo (org_leg).

Discussion

Friendly mobile browser version for OS devices to upload photos

NoN Outside the scope of Community Tech

Commons Upload Wizard on Safari iOS
Commons Upload Wizard on Safari iOS
  • Problem: The commons mobile app can be used only on android devices and it's not easy at all to upload photos using a OS device via the current mobile browser version.
  • Who would benefit: all Iphones/Ipads users
  • Proposed solution: if a mobile app is not possible at least imporve the mobile browser version.
  • More comments:
  • Phabricator tickets:
  • Proposer: Yamen (talk) 13:27, 21 November 2020 (UTC)[reply]

Discussion

Syncing watchlists

NoN See Simple import and export of Watchlists

  • Problem:
  • Who would benefit: People with multiple accounts
  • Proposed solution: Create an interface in where you can ask a person to sync their watchlist, and if they accept, your watchlist will be synced. If a page does not wish to be synced, you can opt out of that page only by selecting a box or something.
  • More comments:
  • Phabricator tickets:
  • Proposer: HeartGlow30797 (talk) 14:41, 22 November 2020 (UTC)[reply]

Discussion

Tags (ala evernote, searchable, catagorizing)

NoN Unclear/incomplete proposal

Discussion

automatic tag-suggestions (already made tags pop up) tag search section combine search with compatible tags (tags associated togheter with a topic Egypt; Pharaohs; New Kingdom) — The preceding unsigned comment was added by Raven rs (talk)

@Raven rs: Could you fill out the problem statement above? That will give context as to what you're trying to solve. Thanks! MusikAnimal (WMF) (talk) 02:30, 3 December 2020 (UTC)[reply]
Since we have not heard back from you, I'm going to archive this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 17:25, 7 December 2020 (UTC)[reply]

Nachschlagung während des Editierens

Diskussion

Oft genug kommt es vor, dass man während des Editierens (innerhalb von Wp!) etwas nachschauen will. Bis jetzt muss man immer:

  • abspeichern und rausgehen,
  • das gesuchte weitere Lemma nachschaun, auch sehen, ob überhaupt vorhanden,
  • zum vorigen Editieren zurückkehren und das gefundene mit einsetzen (falls vorhanden), oder sich hier ggf. mit einem künftigen Rot-Link begnügen.

Ich würde mir sehr wünschen, dass derartiges einfacher und schneller möglich wäre, also ohne das laufende Editieren zu verlassen. Prinzipiell ging das auch heute schon - aber nur, wenn man 2 Computer und 2 Internetanschlüsse besitzt. Wer hat das schon? --Wilhelmus Legrant (talk) 09:21, 23 November 2020 (UTC)[reply]

  • 問題点: ぺディアにおいて現在のnavboxは、「モバイルモード」からの閲覧が全く出来ず、ぺディア記事内で画像を多用して補足する必要がある記事では（例えば特殊な車両や、鉄道系）記事内のギャラリーに画像を投入した場合、「たびたび画像が多すぎる」または「いやむしろ少ないくらいだ」などと、見解の相違によるトラブルや編集合戦も起こります。この妥協点として、navboxは非常に有効な手段ですが、残念ながら現在の仕様では、「モバイルモード」では全く見ることが出来ず、むしろ中途半端なnavboxは要らない論に発展しています。ぜひ、「モバイルモード」でも見られるように改善を。是非お願い致します。
  • 誰の役に立つか: 不特定多数の多くの閲覧者と、意見対立によるトラブル防止。
  • 提案された決議:
  • その他のコメント:
  • Phabricator チケット:
  • 提案者: 佐渡桶 (talk) 17:42, 22 November 2020 (UTC)[reply]

議論

  • @佐渡桶: Making NavBoxes work on mobile is a style and content issue that individual wikis can work on, and there's not much that the Community Tech team can do about this (we don't generally work on wiki content). That said, if your proposal is to create some sort of responsive and wiki-agnostic navbox system, then that would be within our scope; would that fulfill your wish? —SWilson (WMF) (talk) 07:33, 4 December 2020 (UTC)[reply]
    Since we have not heard back from you, I'm going to archive this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 17:34, 7 December 2020 (UTC)[reply]

Lightroom gadget

Withdrawn by proposer

  • Problem: Simplify image contributions, by being able to directly upload to Wikimedia Commons from Adobe Lightroom,
  • Who would benefit: All photographers
  • Proposed solution: create a plugin that lets us directly upload to Commons from Adobe Lightroom (as is available for Flickr and other sites)
  • More comments:
  • Phabricator tickets:
  • Proposer: Gnangarra (talk) 04:42, 29 November 2020 (UTC)[reply]

Discussion

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2021/Archive&oldid=24159751"