Jump to content

Community Wishlist Survey 2022/Archive

Add links
From Meta, a Wikimedia project coordination wiki

This page is an archive for Community Wishlist Survey 2022 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 January 28, we can't move any proposals out of the Archive.

Adopt the new design faster

NoN Incomplete proposal / On roadmap of another team

Discussion

  • @Betseg: There are two issues here. First, you didn't fill out the "Problem" statement. I think from the title your concern is the Desktop Improvements project is taking too long to deploy to wikis? The team responsible for this is deliberately taking it slow in coordination with each of the communities. The second problem here is that you're asking us to work on something that is already being planned by another team, which is something we strictly do not do. For this reason I'm going to archive this proposal. You can learn more the survey and how to create a good proposal by reading our FAQ. Thanks for participating! MusikAnimal (WMF) (talk) 19:06, 10 January 2022 (UTC)[reply]

Non-admin user group that can block users

NoN Proposes a social/policy change, does not requiring engineering resources

  • Problem: Some users vandalize and it takes time before actions occurs.
  • Who would benefit: All users in Wikipedia, page creators, admins, and generally all people.
  • Proposed solution: A new role named Blockers. They temporally block vandals and wait for an admin to come to take action.
  • More comments: The role just doesn't allow an editor or vandal to edit until an admin reviews it. And the requirments for the role is to have more than 700 edits, to be in Wikipedia for more than 60 days, and a non-questionable background.
  • Phabricator tickets:
  • Proposer: Yodas henchman (talk) 19:55, 10 January 2022 (UTC)[reply]

Discussion

  • This is basically asking for a new user group with the block permission. This can be set up now with a simple configuration change. On English Wikipedia, for instance, the idea has intensely and repeatedly been rejected. However if your community has consensus to introduce such a user group, simply request it on Phabricator, tagging with #Wikimedia-Site-requests. I'm going to archive this proposal since there's no engineering work required. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 20:03, 10 January 2022 (UTC)[reply]
@Yodas henchman and MusikAnimal (WMF): this sounds like a possible request that would require engineering work, along the lines of phab:T128328 - while it is true that projects can already make a new group that has the "(block)" permission - that task and a recurring discussion has been to make a new permission that can only block IP's , or can only place time-limited blocks. If so, development of that workflow would be needed. Yodas henchman, is that functionality something you are looking at needing here? — xaosflux Talk 22:07, 10 January 2022 (UTC)[reply]
Not really just proposed the user rights group Yodas henchman (talk) 22:08, 10 January 2022 (UTC)[reply]
@Yodas henchman: ok then, this is something that can already be done, even on WMF wikis - just start a community discussion to create a new group that contains the "block" permission, be sure the community discussion is well attended and result in a strong support - then drop a configuration request to enable it. Non WMF-wiki's sysadmins can just enable this in the configuration already. — xaosflux Talk 22:29, 10 January 2022 (UTC)[reply]
I don't understand well Yodas henchman (talk) 17:32, 11 January 2022 (UTC)[reply]

Hungarian language Wikipedia

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

  • Problem: Some users with "privileges" on the Hungarian Wikipedia think they own the whole Wikipedia. They hardly provide any real help, and if they do, it is only in their own interests. If anyone has any suggestions, they are ignored. Some of the patrollers do not even do their job because they think that if they are not obliged to do it, they don't have to. Unfortunately, the Hungarian Wikipedia has a high rate of bias and discrimination. Both against foreigners and Hungarians.
  • Who would benefit: The Hungarian Wikipedia as a whole, because in addition to the shortage of editors, some members sometimes seem to be intentionally generating fluctuation. And several former members can testify to this.
  • Proposed solution: Withdrawing the rights of certain members, And appointing new members to the post. Also, requiring patrollers members to use their privileges. In a word: Re-election of certain administrators would be the best way forward. Because that way, they will only bring shame to the Hungarian Wikipedia. The numbers are just numbers, that's not all, and anyone who hasn't been an editor there doesn't really know what kind of wolves in sheep's clothing are in charge.
  • More comments: Unnecessary votes are taken on things to leave 8-10 word stub articles, all just to make the "counter" show a more core value. But all this stub is worthless, because no one knows anything about them.
  • Phabricator tickets:
  • Proposer: ᕵᗩᑘᒪ_ᖶᕼᘿ_ᑢᖻᑢᒪᓰSᖶ from Hungarian Wiki Post 20:36, 10 January 2022 (UTC)[reply]

Discussion

Adding of a needed line in river templates and/or infoboxes, Añadidura de una línea necesaria en plantillas de ríos.

NoN Does not require engineering resources

  • Problem: Lack of information about river mouths.
  • Who would benefit: Users, readers of the Wikipedia.
  • Proposed solution: Please, in river templates and/or infoboxes, add another line in the format so any collaborator / user / editor can specify / type / add the geographic COORDINATES of the mouth of any and all of the rivers featured in the Wikipedia –not only those ones corresponding to the river source–. This lacking of geographic coordinates may affect some readers. 20220110 (Monday).
  • More comments:
  • Phabricator tickets:
  • Proposer: Heterotrofo (talk) 21:15, 10 January 2022 (UTC)[reply]
  • Problema: Falta de información acerca de los respectivos nacimientos de ríos.
  • Quiénes se beneficiarían: Usuarios, lectores de la Wikipedia.
  • Solución propuesta: Por favor, en las plantillas de ríos, añadid otra línea en el formato para que cualquier colaborador / usuario / editor pueda especificar / escribir / agregar las COORDENADAS geográficas de la desembocadura de cualesquiera y todos los ríos que aparecen en la Wikipedia, no solo aquellas correspondientes al nacimiento del río. Esta falta de coordenadas geográficas puede afectar a algunos lectores. 20220110 (lunes).
  • Más comentarios:
  • Boletos Phabricator:
  • Proponente: Heterotrofo (talk) 21:15, 10 January 2022 (UTC)[reply]

Discussion

  • You can do this now. Just have your community make the necessary changes to the relevant templates. You may need to seek broader input from your community and/or have someone with the appropriate editing rights implement it, however. Either way unless I'm missing something, this doesn't require any engineering help from the WMF, so I'm going to archive this proposal. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 21:42, 10 January 2022 (UTC)[reply]

Change NHL player infobox to make it similar to NFL,MLB,NBA player formats

NoN Does not require engineering resources

Discussion

Pageviews

NoN Proposes an existing solution

  • Problem: There is to my knowledge no manner to know the number of times an article has been read.
  • Who would benefit: Creators of new articles; editors who have significantly contributed to an article
  • Proposed solution: There could be a number in the footer of the page indicating the number of times that article has been visited since its creation.
  • More comments: I know this is a problem of very minimal importance, if it can even be considered a "problem;" however, following the creation of an article, I am always curious to know at least an approximate number of visits made to it. Furthermore, I have no idea how this could be done, but it is just an idea I wanted to "put out there."
  • Phabricator tickets:
  • Proposer: Meduer (talk) 01:22, 11 January 2022 (UTC)[reply]

Discussion

  • We already have Pageviews and XTools that can be used to see not only the number of views but also more detailed statistics. And article history pages in many projects have links to this tools. — putnik 02:27, 11 January 2022 (UTC)[reply]
  • Per above, there are multiple ways to get this data already. I see your home wiki is English Wikipedia. There, and on most other large wikis, you will probably find a "Pageviews" link on the revision history page (example). On all wikis, you can click on the "Page information" link in the left sidebar under "Tools" (example for Community Wishlist Survey), then look for "Page views in the past 30 days" which has a link to a graph. We can make these links more prominent, such as how is done on German Wikipedia (they show the links at the bottom of the article), but it is up to your local community to decide that. For English Wikipedia, you could propose the idea at w:Wikipedia:Village pump (idea lab) for instance. As there is an existing solution, I'm going to archive this proposal. Thanks for participating! MusikAnimal (WMF) (talk) 04:51, 11 January 2022 (UTC)[reply]

Unbiased admins

NoN Describes a social/policy change and not a technical feature

  • Problem: Many admins are clearly radicals (leftist extremists). They often allow no debate on what can be published and their word is last, regardless of whether they are right or wrong. I have experienced this dozens of times over the last two years. Sometimes, they are not ideological radicals, but are so high on their admin horse that they can't find it in them to admit they've made a mistake and they simply disregard others' opinions with the stance, 'I'm an admin and anything you 'plebs' say doesn't really matter'. This is the main reason I have stopped donating to Wikipedia. If you let any group (regardless of which side of the political spectrum they may be standing on) hijack a website, especially an encyclopedia, then its objectivity is questionable at best and, in this case, that is slowly opening the doors to Wikipedia's demise. That door needs to be shut proper and any biased and prejudicial admin (left, center, or right) should never be allowed to become an admin again.
  • Who would benefit: All users and especially Wikipedia itself (if Jimmy still cares about this being a reputable site).
  • Proposed solution: There needs to be a better system of supervision and an easy way to report such cases, so that such admins are scrutinized and have their admin privileges taken away from them if appropriate.
  • More comments:
  • Phabricator tickets:
  • Proposer: NoWikiNoLife (talk) 11:05, 11 January 2022 (UTC)[reply]

Discussion

  • I share the description of the situation. However, only a small part of Wikipedia is influenced by activists with administrator rights. It could be that there is no better system than the existing one. A perceived 99 percent of the pages are unaffected in my view. The remaining percent is the honeypot I stay away from. The type of administrators is determined by democratic election. What might increase the turnout of voters? — Aktenstapel (talk) 13:31, 11 January 2022 (UTC) (in Wikipedia a non-voter).[reply]
  • Unfortunately Community Tech can't help with this. I think the best course of action would be to get a conversation going here, such as at Stewards' noticeboard. I'm going archive this proposal since it doesn't ask for any explicit technical changes (reporting systems like SR already exist). Even if you wanted a new reporting system built from the ground up, it needs a lot of community discussion first. Community Tech can't set goals like "fewer biased admins" and we certainly can't be responsible for monitoring admin activity. You can learn more about what this survey is for by reading our FAQ. Thanks for participating, MusikAnimal (WMF) (talk) 14:39, 11 January 2022 (UTC)[reply]
  • Yeah, as expected. First, one of the comments (of another Wikipedia user) has been deleted. Then, the discussion is immediately shut down using an excuse (that it's not a tech issue). I expected as much. Wikipedia is becoming more and more user unfriendly. The attitude we get from those of you who are in charge is that we should all butt out and leave you to run Wikipedia the way you want. Fine. But you are losing loads of people in the process. I used to be a huge proponent of Wikipedia and promoted it whenever I could. No more. For the last two years, I have been telling everyone about my experiences here and I will continue to do so. NoWikiNoLife (talk) 23:23, 11 January 2022 (UTC)[reply]

Commons specific: editor permission to undelete categories

NoN Describes a social problem rather than a technical feature

  • Problem: Some time ago I created a veritable cathedral of categories for an artist for whom I had written a en.WP article, and for whom I had uploaded a large number of images to Commons. In order for myself to find anything in all those pictures, I had to create multiple categories, including the countries featured in the pictures (China, UK, etc.), which important national collections had which pictures (UK Royal Collection, British Museum etc.), the subject of the pictures (ships, buildings, views etc.), and more, with all the categories mentioning the artist's name, to keep the whole pattern together. It took a long time do do this carefully and in a logical manner, so that anyone could find anything. Then along came an eager editor who had not read the article and did not know the artist, and they rearranged the whole thing, deleting all my categories, and possibly losing some images from the set in the process, who knows. That editor did not stop when I asked them, and did not respond to my messages. I could not repair the mess because as a non-admin I cannot undelete all those categories. Explaining all this to an admin and getting them to undelete them one by one as I worked through it would waste their time and mine, so I have hesitated to repair this mess. I did alert an admin, but the eager editor was working so fast that they had done most of it by the time a couple of categories were saved from deletion. Those saved categories still stand there, empty, waiting for me to do the mass repair.
  • Who would benefit: Anyone who needed to sort out the same sort of time-consuming category deletion mess. A good way to start to undo the very complicated mess that I am faced with, would be to go through the history of each image filepage, and undo the category deletion history as shown there. That way, every image filepage would be dealt with, if you dealt with them all in careful order. (I still don't know how I would track down any images which were accidentally lost from the set by the rampaging editor, though).
  • Proposed solution: So what we need is a system where an ordinary non-admin editor like me can get permission (if only temporary for a specific task) to undelete categories (complete with also-deleted parent categories if possible?) where that job is needed.
  • More comments:
  • Phabricator tickets:
  • Proposer: Storye book (talk) 12:20, 11 January 2022 (UTC)[reply]

Discussion

  • There isn't really such a thing as "category deletion". All that involves is removing all pages from a category, then deleting the category page itself. You can always re-add the categories to the pages, and re-create the category page (unless the admins create-protected the category page). That's the only technical way to undo the "category deletion". Either way there's no concept of undeleting a category. Admins don't have this "permission", either. They likely de-categorized the pages en masse using c:Help:Gadget-Cat-a-lot, which you should have access to as well (though I'm not encouraging you to start and edit war). I'm sorry you experienced what you did, but the best solution I would think is communication with editors and reaching out to the broader community for assistance. Since I don't see any technical way we could help you, I'm going to decline this proposal. Thanks for participating in the survey, nonetheless! MusikAnimal (WMF) (talk) 14:58, 11 January 2022 (UTC)[reply]

Preview tab

NoN Overlaps with existing Real Time Preview project

  • Problem: Editors cannot switch between source editing and preview promptly. Also, some shortcut keys such as Ctrl/Command-Z do not work to undo/redo an edit after entering the preview mode.
  • Who would benefit: All editors who use source editor of MediaWiki software.
  • Proposed solution: Implement the "Edit" tab and "Preview" tab in the source editing mode. You can refer to or try testing en:User:Ykhwong/Gadget-tabPreview.js that I created in JavaScript to demonstrate the idea. (For testing, turn off New wikitext mode in Beta features)
  • More comments:
  • Phabricator tickets:
  • Proposer: Ykhwong (talk) 04:03, 11 January 2022 (UTC)[reply]

Discussion

  • @Ykhwong: It's hard to tell what your script does by just looking at the code, but two things you may not be aware of: There is an existing preference called "Show previews without reloading the page" available in your preferences. This will show a preview and your undo commands will still work. Secondly, you'll be pleased to know Community Tech is already working on a Real Time Preview feature for source editing. We're somewhat far into that project, so we should have more updates to share on that soon. Stay tuned! :) That said, do these upcoming/existing features satisfy your wish, or is there something else you're looking for? MusikAnimal (WMF) (talk) 04:13, 11 January 2022 (UTC)[reply]
Thanks for the info. I have been using the preference "Show previews without reloading the page" for months, but I forgot that I can still use the undo/redo shortcut keys while keeping the option turned on. My suggestion is to implement a new tab that is somewhat different from the real-time preview feature to preview the page in real-time when editing (simultaneously). However, if you consider the wish a duplicate, you may archive it. :) Ykhwong (talk) 04:40, 11 January 2022 (UTC)[reply]
preview the page in real-time when editing (simultaneously) is exactly what we're going to offer. The UI I think may differ from your script, but something tells me you'll enjoy what's coming. With your word, I'll go ahead and archive this wish as it overlaps with existing work. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 15:27, 11 January 2022 (UTC)[reply]

Allow ancient languages' wikis

NoN Does not request a technical feature

  • Problem: Many active ancient languages' test wikis are blocked for creating new articles at the Wikimedia Incubator in 2021, though editing already created pages is allowed.
  • Who would benefit: All the participating editors as well as all the readers.
  • Proposed solution: The solution to the problem is allowing the creation of ancient languages' wikis if they have the same potential like those of succeeding modern languages' test wikis. For this, please allow the creation of new articles in their test wikis.
  • More comments: There are many ancient languages' test wikis at Wikimedia Incubator in which creation of new articles is blocked but editing already created articles is allowed. This issue started in the year 2021.

    These test wikis do not have little quantity of contributions like 1 or 2 pages, but with a relatively large number of articles just like those of living/spoken languages' test wikis at Wikimedia Incubator, the same platform. The ancient languages' test wikis' contributors are interested in expanding articles as well as creating new articles. If a test wiki has a potential (actively participating editors with significant contributions) to become a wiki, please allow them, without specifying if they are ancient or modern. When we just have a look at the already created ancient languages' wikis like Latin Wikipedia or Sanskrit Wikipedia or Old English Wikipedia, they work normally like every living languages' test wikis, without any shortage of active contributors. Same potential, same volume of contributors and contributions are explicitly seen in many ancient languages' test wikis at Wikimedia Incubator. So, please allow them to be approved for independent wiki status if their test wikis fulfill all the criteria for approval like their succeeding modern languages' test wikis at the incubator. For this, please allow the creation of new articles in their test wikis.

  • Phabricator tickets:
  • Proposer: Haoreima (talk) 14:47, 11 January 2022 (UTC)[reply]

Discussion

@MusikAnimal (WMF): Do you mean it can't be ammended from here? What if I change the category from "Editing" to "Miscellaneous"? Haoreima (talk) 17:21, 11 January 2022 (UTC)[reply]
@Haoreima I mean the decision on whether or not to approve a new language or project rests solely on the governing body (Language committee it seems?). You will need to consult them and/or go through the established processes to get the new wikis created. The Community Wishlist Survey is about making technical software improvements. It sounds like the wikis you attempted to have created in the past were rejected for some reason or another, which is not something we can change. Is that correct? Could you provide links to the prior discussions? MusikAnimal (WMF) (talk) 17:37, 11 January 2022 (UTC)[reply]
@MusikAnimal (WMF): If you mean links, it is Requests for comment/Start allowing ancient languages. It's not proposed by me, though I supported it. Well, I misunderstood the wishlist curriculum. Well, I have to search for other ways but I don't know how and what to do now! Haoreima (talk) 17:44, 11 January 2022 (UTC)[reply]
So it seems the RfC is still in process. We will have to let that run its course, and if the consensus is no, there's nothing we (Community Tech) can do to change that. Sorry! You could solicit broader input by reaching out through the Languages mailing list, or even Wikimedia-l if you have the appetite for very far reach. Best of luck and apologies we cannot help you further, MusikAnimal (WMF) (talk) 17:57, 11 January 2022 (UTC)[reply]

Surtout, ne rien changer !

NoN Does not request a technical feature

Discussion

  • Tu trolles, Paul.schrepfer ? En quoi les améliorations faites les années précédentes grâce à cette consultation annuelle t’ont-elles gênées ? --Pols12 (talk) 20:28, 11 January 2022 (UTC)[reply]
    Seems like trolling. We'll of course archive it. MusikAnimal (WMF) (talk) 01:31, 12 January 2022 (UTC)[reply]
  • Pols12, je suis gêné par le fait que je doit, à chaque connexion, faire un clic de trop depuis que, en haut à droite de l'écran le menu a été modifié. Je suis gêné dans les discussions des pages à supprimer quand les utilisateurs utilisent le bouton répondre au bout de mon avis au lieu de discuter dans le chapitre discussion....... Et là je suis gêné quand, à priori et donc sans échange préalable, on évoque un possible trollage de ma part. On m'a demandé mon avis, j'ai donné mon avis, et je pense qu'il est aussi respectable qu'un autre. Je n'aime pas qu'on change mes habitudes, et je ne dois pas être le seul, alors une année sans changement serait une juste prise en compte de cette tendance, à mon avis. Amicalement. - Paul.schrepfer (talk) 06:16, 12 January 2022 (UTC)[reply]
    Bonjour MusikAnimal (WMF), vous pouvez archiver mon avis, il n'y a aucun problème. Le fait que mon avis soit différent de ce que j'imagine être généralement attendu dans le cadre d'une telle consultation, sinon pourquoi avoir écrit ce que vous avez écrit, est-il en problème en soi ? Nous sommes dans la phase de proposition, je propose ! Si mon avis est retenu, j'en serai satisfait, si ça n'est pas le cas, j'aurai fait entendre une voix dont je ne suis certainement pas le seul tenant. Comme je l'ai précisé ci-dessus à Pols12 : "Je n'aime pas qu'on change mes habitudes, et je ne dois pas être le seul, alors une année sans changement serait une juste prise en compte de cette tendance, à mon avis". Cet avis n'est pas nouveau et je l'ai déjà exprimé à plusieurs reprises sur le bistro de la Wikipédia francophone, et il n'a rien de provoquant ou de trollesque, puisque c'est de cela que je suis soupçonné. J'avoue être surpris du ton des remarques qui me sont faites. Amicalement. - Paul.schrepfer (talk) 07:41, 12 January 2022 (UTC)[reply]
    Ma question était sincère, parce que ton message « ça change tout le temps », sans expliciter quels changements posent problème me semblait trollesque ; alors que je te sais contributeur pertinent dans la discussion.
    Cette consultation permet de créer ou corriger de nouveaux outils facultatifs, elle ne vise pas à changer l’interface. Le fait que le bouton Répondre apparait au mauvais endroit sur les PàS est par exemple un problème que l’équipe pourrait corriger si quelqu’un en faisait le souhait. Tu vois donc bien qu’il y a des changements que tu souhaites. (Ceci dit, les gens répondaient aux avis bien avant l’apparition du bouton Répondre…)
    Estimer que « tout le monde » gagnerait à ce qu’il n’y ait aucun changement me parait naïf, de mauvaise foi ou égocentré. Cette consultation n’est pas faite que pour les contributeurs de Wikipédia en français, mais aussi pour ceux de Wiktionary en malayalam, par exemple. -- Pols12 (talk) 12:36, 12 January 2022 (UTC)[reply]
    Pols12, désolé si mon message un peu télégraphique a pu être mal interprété. Pour les PàS j'ai déjà échangé là dessus avec Whatamidoing, pour le menu de connexion, avec Patafisik, (sans certitude), ....... quand j'ai un problème, je l'évoque sur le bistro, je n'ai donc pas vu l'intérêt de revenir dessus ici. Le bouton répondre n'apparait pas au mauvais endroit pour certains (dont moi qui ne le voit pas, j'ai été informé de son existence quand j'ai fait remarquer à un utilisateur que j'avais exprimé le souhait qu'il réponde ailleurs que sur mon avis et qui m'a répondu qu'il ne faisait que cliquer sur le bouton répondre qui se trouvait au bout de mon avis), mais pour d'autres, il apparait et ils l'utilisent, nous avons donc des versions différentes en terme de fonctionnalité qui coexistent simultanément et qui créent, à mon avis, des problèmes. Si j'ai écrit que tout le monde y gagnerait, c'est en terme de stabilité. Le menu de connexion a été modifié il y a plusieurs mois, et je ne suis pas encore habitué. Nous ne sommes pas tous doués de la même manière. Une année de calme me semblerait de nature à pouvoir digérer les modifications récentes. Et désolé si je ne suis pas adressé au bon service, je ne sais pas qui fait quoi. J'espère que nous avons purgé le sujet !? Amicalement. - Paul.schrepfer (talk) 13:28, 12 January 2022 (UTC)[reply]

Levels of Relevance

NoN Outside the scope of Community Tech

  • Problem: Articles which are incomplete, in development or of claimed irrelevance are often unceremoniously deleted (esp. in the de.wikipedia). This has already caused lesser acceptance among editors and fewer contributions.
  • Who would benefit: some Readers (as there is more content about more topics available), many editors (as they won't write into the bin that often), all exclusionists (as they don't have to bother debating relevance), everyone (as stub articles are accessible to anybody, so more people can contribute to completion which will lead to generally more valuable content).
  • Proposed solution: Articles get a publishing rating of three or more degrees, so whoever feels uncomfortable with the lower levels will simply not activate them, as they are hidden per default. Levels could be:
    L1: Articles of undisputed relevance and with no major information missing; are shown to everyone (as it is now)
    L2: Articles of a formerly disapproved but generally significant lemma or of relevance lesser than L1 but still considered high; incomplete articles. L2 articles must not cover in more detail any existing section of a corresponding L1 article (to avoid content interferences).
    L3: Articles of relevance like L2 but with content extending an existing article section. As interference with a corresponding main article is tolerated the L3 content is supposed to be frequently reviewed for integration in an upper level.
    L2 and L3 is shown only to logged in users who set them to unhide.
  • More comments: The technical implementation shouldn't be too hard and the logical integration of the current structure isn't touched. Yet it would meet the demands of the inclusionists without change the wikipedia for the others.
  • Phabricator tickets:
  • Proposer: Robbit (talk) 22:33, 11 January 2022 (UTC)[reply]

Discussion

This is primarily a social issue rather than a technical one, as it is primarily asking for a fundamental restructure of how Wikipedia is structured. * Pppery * it has begun 04:59, 12 January 2022 (UTC)[reply]

Isn't that just semantics. Organizations are constantly restructuring themselves. The question is, is the stated issue real, and does this proposal help. — The preceding unsigned comment was added by Herostratus (talk) 05:18, 12 January 2022 (UTC)[reply]

I might have been not specific enough. 😊 I really do propose a technical solution to the problem: it demands an additional flag of the article pages. It demands not only approval for the method of separating contents but also a technical logical way allowing to distinguish the types/levels of articles. --Robbit (talk) 09:30, 13 January 2022 (UTC) [reply]

Add ability to search by user agent from CheckUser interface

NoN This proposal would overlap with the effort needed in the transition to Client Hints

  • Problem: CheckUsers cannot search for users based on their user-agent; they can only search by IP. In some cases, the user-agent is quite distinctive and searching by it can more quickly reveal socks (specially when the user is IP-hopping using proxies).
  • Who would benefit: CheckUsers on every project with local CUs, stewards on all projects.
  • Proposed solution: User:Kaldari has made a detailed proposal including mock-ups in phab:T146837.
  • More comments: One major hold-up has been phab:T147894 and the decision on which index to create. This will require contribution from someone with DBA access so they can run a bunch of test queries on various projects.
  • Phabricator tickets: phab:T146837
  • Proposer: Huji (talk) 01:11, 11 January 2022 (UTC)[reply]

Discussion

  • @Huji: Thank you for proposing this. Unfortunately, this work conflicts with the future deprecation by Chrome and other browsers of the UA string in favor of Client Hints. There are already a few tasks to figure out how to deal with it, and CheckUser is a known affected extension by this change. I can see you've already participated in T242825. Here are these other tasks relevant to Client Hints T258592, T258591. Sorry to have to archive this proposal. DMaza (WMF) (talk) 14:43, 12 January 2022 (UTC)[reply]
    @DMaza (WMF): I am well aware of that. However, we are still months (if not years) away from Client Hints impacting us widely, the proposal here has been waiting for several years, and when Client Hints ultimately take over we would need similar functionality for them too so I am hoping that some of the work here (i.e., simply determining what queries need to be run to convince DBAs to create a new index per phab:T147894) would similarly apply then. Time spent on this proposal will not be wasted time. It will add a feature that we use now, and pave the way for a similar feature we would be using later for Client Hints. Huji (talk) 15:02, 12 January 2022 (UTC)[reply]
    @Huji There is a team already looking into Client Hints adoption and UA strings deprecation. Unfortunately, any work related to UA strings will likely overlap with what they are doing or be considered tech debt since it will need to be reverted or reworked at some point.
    Your other proposal on the other hand is totally valid and ready for voting. Let me know if you have any other concerns. Thank you again! DMaza (WMF) (talk) 18:18, 25 January 2022 (UTC)[reply]
    @DMaza (WMF): what if we rewrite this proposal to be inclusive of Client HInts, or specifically about Client Hints? Huji (talk) 18:41, 25 January 2022 (UTC)[reply]
    I'm afraid that until T295073 is completed our team can't really do anything about it unfortunately. DMaza (WMF) (talk) 14:12, 26 January 2022 (UTC)[reply]

Add 'Open Access' tickbox to RefToolbar

NoN Does not require engineering resources

Add a tick box to this?
  • Problem: When adding references there is no option to flag them as open access.
  • Who would benefit: Primarily the readers and editors of scientific articles and anyone else committed to 'open access'
  • Proposed solution: Add a tickbox to RefToolbar (or just it's 'journal citation' section). When ticked |doi-access=free is added to the string produced
  • More comments: Scientific articles mostly use academic journals as references and >90% of these are pay-walled, however many editors focus on finding the 10% which are Open Access. Journal which are open access are clearly shown as such on the publisher website - we know what we're adding. Currently OA tags mostly end up getting added by 'Citation bot' but this is resource heavy.
  • Phabricator tickets:
  • Proposer: Project Osprey (talk) 21:29, 10 January 2022 (UTC)[reply]

Discussion

Intermediary Editor Dispute Board

NoN Withdrawn by proposer

  • Problem: Editors -- even experienced ones, will clash with another editor at least once during their time on Wikipedia. Most editors can come to agreements on talk pages if disagreements or problems persist/occur (for example, taking issues with editing styles, mass deletions, etc.). However, there are some instances where some editors can get so entrenched into their positions, that editing wars occur, problems may get escalated to noticeboards and so on. Usually when things get escalated to noticeboards, punishments can be handed down in one form or another, which is not ideal. What is missing is an intermediary board before it gets to this point: A non-binding problem/issue discussion board or forum, where some disagreements can be worked out with a larger group of editors -- almost like a mentoring session or group therapy. Such a board may dissuade any further escalation between hot-headed editors via a spread out with cooler heads (editors) -- and perhaps reaching non-binding consensus, which is always the best outcome in the long run, before things get any worse. If such disagreements can be headed off before having to go to admin boards, this may help the admins in avoiding petty disagreements, saving their time for real issues that need addressing.
  • Who would benefit: Editors who find themselves in perpetual disagreement with another editor or editors. It would also help admins avoid such disagreements.
  • Proposed solution: Creating a non-binding board/forum where editors can work out differences with the help of other editors - when most admin boards do not fit the bill and just before taking the issue to official admin noticeboard action.
  • More comments: Since we all edit Wikipedia virtually and never really see anyone face-to-face, this forum might be a good place where editors can come together to work out differences before things get heated -- just like in real life. This board would be situated right below the dispute boards, admin boards, etc... but above talk pages and any other lower boards (if applicable).
  • Phabricator tickets:
  • Proposer: Hanyou23 (talk) 20:36, 11 January 2022 (UTC)[reply]

Discussion

See mw:Anti-Harassment Tools. That project even goes farther than your proposal with an global editquette.--Snævar (talk) 11:31, 12 January 2022 (UTC)[reply]

Accept more credible references from YouTube

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

  • Problem: YouTube is currently not accepted as a credible source, blanket ban
  • Who would benefit: Wikipedia quality and all its readers
  • Proposed solution: Accept YouTube videos on a case-by-case basis, to include credible ones
  • More comments:
  • Phabricator tickets:
  • Proposer: Fredericknoronha (talk) 22:39, 12 January 2022 (UTC)[reply]

Discussion

More Admin from the Global South

NoN Proposes financial/cultural change rather than a technical feature

  • Problem: Blind spot currently towards large areas of the world.
  • Who would benefit: Everyone accessing the Wikipedia, Wikipedians who get more incentives to participate from the Two-Thirds World, and the Wikipedia itself.
  • Proposed solution: Get more participation from the Global South. Make sure all Admin are sensitive to issues from here.
  • More comments:
  • Phabricator tickets:
  • Proposer: Fredericknoronha (talk) 22:37, 12 January 2022 (UTC)[reply]

Discussion

  • As much as we'd like to help with this, Community Tech develops software. What you need is a good outreach program. Perhaps some new software could be built to assist with that, and if you're able to come up with a concrete proposal for such a tool, please do :) Unfortunately as written this is not something we can allow to go into voting, since there's no actionable from a technical standpoint. You can learn more about what this survey is for by reviewing our FAQ. Thanks for participating in the survey, nonetheless! MusikAnimal (WMF) (talk) 23:56, 12 January 2022 (UTC)[reply]

Dyslexic font

NoN Feature already exists

  • Problem: Dyslexic users can't read articles
  • Who would benefit: Dyslexic users
  • Proposed solution: When creating an account and in account settings, you can change the font of the Wikipedia text to a dyslexic font for dyslexic users.
  • More comments: If there already is an optional dyslexic font, ignore this
  • Phabricator tickets:
  • Proposer: Rzzor (talk) 21:08, 11 January 2022 (UTC)[reply]

Discussion

At the location where the interlanguage links are located is an gear icon. Underneath it is an option to enable fetching fonts and then you can choose the "OpenDyslexic" font. This tool is called mw:Universal Language Selector So, invalid proposal, I guess.--Snævar (talk) 11:35, 12 January 2022 (UTC)[reply]

@Snævar Yeah, you're right. I think it was a good idea though. Rzzor (talk) 17:54, 12 January 2022 (UTC)[reply]

Commonist update

NoN Duplicate of Community Wishlist Survey 2022/Multimedia and Commons/Mass uploader

  • Problem: Commonist and all other similar upload tools have been non-functional for months now after some software change at the Commons, with no remedy in sight.
  • Who would benefit: All power uploaders to Commons.
  • Proposed solution: Write a small program that can do what Commonist can. Probably not rocket science, but someone needs to do this ASAP.
  • More comments:
  • Phabricator tickets: phab:T293543
  • Proposer: Anvilaquarius (talk) 08:10, 11 January 2022 (UTC)[reply]

Discussion

This is a duplicate of Community Wishlist Survey 2022/Multimedia and Commons/Mass uploader * Pppery * it has begun 05:02, 12 January 2022 (UTC)[reply]

Thanks for marking my original wish as a duplicate for another one that came later... *sigh* --Anvilaquarius (talk) 08:58, 13 January 2022 (UTC)[reply]

@Anvilaquarius: I'm sorry! :-( I just figure that that one is more general but still covers the same ground. I didn't look at creation times. SWilson (WMF) (talk) 06:29, 14 January 2022 (UTC)[reply]
Neither did I. I happened to see the "Mass Uploader" proposal first. * Pppery * it has begun 22:23, 14 January 2022 (UTC)[reply]

Automatically mark stupid admins

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

  • Problem: Often, precious time and efforts could be saved if admins which have previously behaved in a problematic way (e.g. not wanting to understand an issue, not following procedures, or being plain stupid and/or drunk) could be marked in some way. Then, according to the user's preferences, Mediawiki would either display their user name with yellow highlighting, not display their contributions at all.
  • Wem würde dieser Wunsch helfen: All Wikipedians, but especially non-admins.
  • Lösungsvorschlag: See above. Additionally, Mediawiki could highlight admin's user names in red if they have previously issued bans during stupid and/or drunk phases.
  • Weitere Kommentare: Not really necessary, but this proposal is both a worthy and useful one.
  • Phabricator-Tickets:
  • Antragsteller: Keimzelle (talk) 16:53, 13 January 2022 (UTC)[reply]

Discussion

@Keimzelle, please don't revert MusikAnimal's edits. He's a member of the Community Tech team and he can decide to archive proposals.

In the case of this one, we think you're pointing at a social problem and suggesting a technical solution. MusikAnimal has archived your wish because this social problem doesn't necessarily require technical solutions, so it doesn't need the CommTech's work. It may begin with you changing how you think about and address to others. This proposal will stay archived. Take a look at how to make a good proposal and maybe look for problems that are technical in nature? Thanks for your understanding and participation in the Survey. SGrabarczuk (WMF) (talk) 18:48, 13 January 2022 (UTC)[reply]

@SGrabarczuk (WMF): I invest a lot of my free time, my language abilities and also my scientific expertise into Wikipedia. I have also spent countless hours fruitlessly discussing issues with administrators so that I grew extremely frustrated with them. Since more than a year I have not seen any administrator that I can entrust with making a justified, somewhat conscious and, err... sober decision. I guess I will have to discuss this issue with @MusikAnimal:, as he is the person in charge. Thankyouverylittle, --Keimzelle (talk) 19:22, 13 January 2022 (UTC)[reply]
@Keimzelle, both MusikAnimal and I are members of Community Tech. This issue is something neither of us can work on, sorry. We welcome issues that are technical in nature, though. SGrabarczuk (WMF) (talk) 19:57, 13 January 2022 (UTC)[reply]
@SGrabarczuk (WMF):, I proposed a technical solution. Username highlighting helps Wikipedia contributors to avoid interactions with problematic administrators, and thus it improves the usability of Wikipedia as a whole. We can steer clear of problematic individuals and invest much more time in fruitful collaboration. If you have any criticism regarding my proposal, I'm very happy to improve it. But if you cannot see that my proposal proposes a useful technical solution then I'm sorry for Wikipedia. It's the best social project there is, but yet dealing with Wikipedia admins is the most soul-sucking and nerve-wrecking thing I've ever experienced.--Keimzelle (talk) 21:26, 13 January 2022 (UTC)[reply]
A glance at Keimzelle's block-log will show you, he's a very problematic user, usually because of massive violations of de:WP:KPA.
Of course this is a solely social problem, and I don't think there will ever be any consensus about who to flag that way, especially as admins can be voted out of adminship if a small amount of users wants it this way. Keimzelle is currently on a destructive mission against the deWP, this is part of it. Grüße vom Sänger ♫(Reden) 05:17, 14 January 2022 (UTC)[reply]
He's just be infinited for his massive antisocial behaviour in deWP, it was overdue. Grüße vom Sänger ♫(Reden) 09:51, 14 January 2022 (UTC)[reply]

Uniformisation des commandes de base

NoN Outside the scope of Community Tech

  • Problème: Difficile de contribuer sur les différentes applications de Wikimédia car les commandes wikicode ne sont pas les mêmes. Par exemple la procédure de saisie d'un ouvrage dans WP, wiktionnaire, ou wikiquote, ou wikiversité, est très différente. Cela peut rebuter les contributeurs non réguliers qui doivent "repasser le permis de conduire" pour ajouter ou modifier...
  • Qui en bénéficierait: les contributeurs en général et les non réguliers en particulier...
  • Solution proposée: Standardiser les commandes pour toutes les applications : ici dans mon exemple {Ouvrage}} et {harvsp}}
  • Autres commentaires:
  • Tâches sur Phabricator:
  • Proposant: Guy6631 (talk) 08:58, 11 January 2022 (UTC)[reply]

Discussion

  • @Guy6631: Si je vous comprends bien, ce que vous demandez, ce sont des "modèles globaux". Malheureusement, nous (Community Tech) ne pouvons pas vous aider. C'est un énorme projet qui prendra des années à résoudre. La bonne nouvelle, cependant, est que WMF pourrait former une équipe pour aider à résoudre ce problème. Il faudra encore beaucoup de temps avant que cela ne soit corrigé, mais il y a de l'espoir :) Étant donné que cela n'est pas à la portée de notre équipe, je vais archiver cette proposition. Merci d'avoir participé à l'enquête ! MusikAnimal (WMF) (talk) 00:17, 14 January 2022 (UTC)[reply]

Allow option to see all dates and times as user's own time

NoN Withdrawn by proposer

  • Problem: It is quite frustrating to edit from my home in the U.S. Eastern Time Zone after 7:00 pm/1900 hours (8:00 pm/2000 hours during Daylight Savings Time) and see my edits get stamped with the next day's date. It would be good to add an option in which users see all dates and times in their own time zones. Internally, all dates and times would be UTC/Greenwich Mean Time/Z Time.
  • Who would benefit: Anyone not in the same time zone as UTC/Greenwich Mean Time/Z Time.
  • Proposed solution: For logged-in users, set a preference to see all dates and times in their own time zone. Nice to have but not necessary - Choose 12-hour or 24-hour clock.
  • More comments: I have wished for this since I first discovered Wikipedia in 2006!
  • Phabricator tickets:
  • Proposer: RSLitman (talk) 20:12, 11 January 2022 (UTC)[reply]

Discussion

We already have such setting for system dates in Preferences. — putnik 20:52, 11 January 2022 (UTC)[reply]
Thanks. I just found this and set it to Americas/New York. It did not affect what I am seeing on this page. I am still seeing 20:12 (8:12 pm) for the time I proposed this, which was actually at 3:12 pm. I am also seeing 23:22 (11:22 pm) for the time I am posting this reply, while it is actually 6:22 pm. (It may be a minute or so later by the time I finish and save this reply.) Would I need to exit, perhaps even log out of, Wikimedia for this to take effect. And by the way, I do want that 12-hour clock, but it's not shown as an option for me.
It turns out that I did already set this to Americas/New York on Wikipedia. Back in twenty-oh-six, this was not an option, but somewhere along the line, I learned about setting it in Preferences. I just forgot that I did so. Now I'll have to test to see if it works for me there. RSLitman (talk) 23:27, 11 January 2022 (UTC)[reply]

Pattypan fixing

NoN Merged with Mass uploader

  • Problem: Pattypan is a very useful tool to upload images to Wikimedia Commons. It stopped working for months, returning error message login failed
  • Who would benefit: It is beneficial to anybody wishing to upload a lot of files to Wikimedia Commons. Many users depend on this tool.
  • Proposed solution: Login failed error need be fixed, a discussion to that effect is happening at github for long, but no solution arrived. Wikimedia may have to fund the process.
  • More comments: Please make a fix at the earliest, there seems no working bulk uploaders at Wikimedia Commons.
  • Phabricator tickets: phab:T293543
  • Proposer: Vinayaraj (talk) 13:47, 11 January 2022 (UTC)[reply]

Discussion

From commons:Commons:Pattypan: "Pattypan has been used to upload 1,186,912 images to Wikimedia Commons which are viewed over 80 million times a month across Wikimedia projects." This tool has proven to be powerful and successful. If it is a matter of just updating software to turn it back on, then doing so would bring back the success this tool already is demonstrated to have. Blue Rasberry (talk) 01:34, 12 January 2022 (UTC)[reply]

  • Underlining the importance, there are Wikimedians In Residence, employed in museums, libraries and other partner organisations, for whom bulk-uploading images to Commons is part of their job; one which they can not do while the most appropriate tool is not working. Having this tool down for one month is bad; having it down for several months, and no suitable replacement, is actually undermining Wikimedia's relationships with partners. MartinPoulter (talk) 11:22, 12 January 2022 (UTC)[reply]
  • +1 to this, mine and everyone I know's upload projects are stopped until this is fixed. John Cummings (talk) 12:47, 12 January 2022 (UTC)[reply]
  • @Vinayaraj: You mention Please revive or patch or repair the issue with Pattypan in your Mass uploader wish as well. Does "Pattypan fixing" need to be a separate wish, then? The "Mass uploader" wish seems to be more encompassing, and is getting more input from the community, so preferably we'd redirect this page there. Is that alright with you? MusikAnimal (WMF) (talk) 23:13, 13 January 2022 (UTC)[reply]
Yes, I would like this to be redirected to the Mass uploader section, thank you.--Vinayaraj (talk) 13:53, 15 January 2022 (UTC)[reply]
I've archived this one, so please make sure Mass uploader reflects all concerns. Thanks! SWilson (WMF) (talk) 06:25, 17 January 2022 (UTC)[reply]
  • Since Pattynan no longer works (early October 2021), with a group of WP-fr users we have still continued to generate thousands of additional geographical maps with a GIS software (Geographic information system) feeded by many Open Data. These maps make it possible to illustrate several hundred Wikipedia articles for French towns. Pattypan is our best tool to easily upload all these maps into Commons. We have been stuck for more than 3 months, our project is stopped. We hope that a solution will be found soon. --Poudou99 (talk) 06:31, 15 January 2022 (UTC)[reply]

Every user on Wikimedia commons should be able to remove files, not just admins

NoN Proposes a social/policy change, does not requiring engineering resources

Discussion

If commonswiki wanted to do this, they could already - they would just need to request that the "delete" permission be added to the all users group, no technical development is required. Feel free to bring this up at commons:Commons:Village pump, but there is 0% chance that commonswiki is going to approve that any user can delete every file. — xaosflux Talk 00:44, 16 January 2022 (UTC)[reply]

Yes, delete should only be done for admins, because of so many abuse potential and a lot of users can abuse this tool. I think if delete, it would need to not be used in "many" projects, you are the only contributor, or in your userspace. Thingofme (talk) 01:38, 16 January 2022 (UTC)[reply]

This request seems fairly similar to Community_Wishlist_Survey_2022/Admins_and_patrollers/Add_ability_to_delete_your_own_files_without_needing_an_admin, but obviously has worse outcomes. --Izno (talk) 00:16, 17 January 2022 (UTC)[reply]

@PopperPeachesCoconut2022: This is something that can be done with a configuration change on the wiki. It does not require any engineering work. Therefore, I will archive. As mentioned, you can request configuration change on commons:Commons:Village pump. Thanks for taking part in the survey. DWalden (WMF) (talk) 13:36, 17 January 2022 (UTC) [reply]

Making Cat-a-lot available for other changes in files

NoN Withdrawn by proposer as there is an existing solution

  • Problem: If you want to make the same changes in a lot of files, now you have to make these changes file by file. It may be about a mistake in the description, a licence, or a template (for the Netherlands thousands of photos of RCE are categorized with a template instead of a real category, see Category:RCE suggested categories; when I want to remove the template and change it to a real category, I have to do it file by file; I would like to get rid of all these RCE suggested categories in a two-step action per category: 1) add the right category to all the files in a RCE suggested category (already possible with Cat-a-lot) and 2) remove the template from the same files). It may, for instance, also apply to changing files with Category:County X photographs taken on yyyy-mm-dd to Date={{Taken on|jjjj-mm-dd|location=Country X}}.
  • Who would benefit: Editors
  • Proposed solution: Make a tool like Cat-a-lot, or make Cat-a-lot also available for other changes than categories. I understand that administrators of the Volunteer Response Team has a possibility to add a VRT tiket to all the files in a category, so perhaps that tool may be a base as well.
  • More comments:
  • Phabricator tickets:
  • Proposer: JopkeB (talk) 06:31, 14 January 2022 (UTC)[reply]

Discussion

This sounds a lot like c:Help:VisualFileChange.js -FASTILY 07:02, 14 January 2022 (UTC)[reply]

FASTILY, Thanks a lot! Visual File Change indeed does the trick. Uptill now I only used it for deletion requests. Now I found out it can also be used for this kind of changes.
I withdrawn this proposal. JopkeB (talk) 14:01, 14 January 2022 (UTC)[reply]
I've archived it. SWilson (WMF) (talk) 14:12, 17 January 2022 (UTC)[reply]

Adding a Deletion Administrator on Commons WikiProject

NoN Proposes a social/policy change, does not requiring engineering resources

  • Problem: The deletion backlog on Commons WikiProject is endless, and very less administrators compared to the backlog.
  • Who would benefit: The deletion backlog being less.
  • Proposed solution: To make a user group naming Deletion Administrator
  • More comments: There is so much deletion requests on Wikimedia Commons. Many requests go unattended for months or even years. As there are only 250 admins available and atleast 100 requests flooding everyday, it is physically impossible for admins to attend every request.

If a user group named "Deletion Administrator" is made, they will be focused on one thing and thus will reduce the backlog by a lot.

Discussion

"Literals" in Citations

NoN Proposes an existing solution

  • Problem: Lots of websites contain things like "|", "{", "<" or other characters in their titles or website names, but Wikipedia can't count them as an actual part of the title. This can mess up links or cause errors to appear in the syntax.

    For example, adding a vertical bar in a citation doesn't work because a vertical bar counts as Wiki syntax, so the webpage can't be shown because the link doesn't work.

  • Who would benefit: All editors of Wikipedia.
  • Proposed solution: Add "literal" indicators(There's a name for this that I forgot). For example, use something like "&137%#" to indicate a vertical bar in the title, or use "&{]5990" for a closing curly bracket as a couple of examples.
  • More comments: No point of this because {{!}} already does this.
  • Phabricator tickets:
  • Proposer: MrMeAndMrMeContributions 21:56, 11 January 2022 (UTC)[reply]

Discussion

Add admin-ability to salt article titles allowing page mover creation

NoN Withdrawn by proposer

  • Problem: Currently, when article titles are create protected, they are overwhelmingly fully protected. This unnecessarily hampers the forward momentum of Wikipedia growth when lessor protection levels (while being higher than semi protection) could satisfy the need for the protection if they were available for admins to use (this applies to move protection as well). Ostensibly, the extended confirmed user group was created for similar reasons regarding edit protection just as template editor was for template protection (and they have had a positive effect). In my opinion, page movers should be available protection levels for create and move protected pages.
  • Who would benefit: Admins, by not having to perform these, often trivial, tasks, page movers by being further empowered to fulfill the task of moving pages which they are trusted to do, and the editing community at large by having more opportunities to overcome these technical restrictions.
  • Proposed solution: Allow admins the ability to choose page mover protection as a protection level when create/move protecting a page.
  • More comments: As a page mover, I, too often, see legitimate requests where the pages are create/move protected with full protection. This hampers my ability to perform the page moves I have been entrusted to perform. While some pages should clearly be fully create/move protected, many others could as easily be satisfactorily protected by page movers if it was an optional protection level for admins to choose.
  • Phabricator tickets:
  • Proposer: --John Cline (talk) 15:59, 15 January 2022 (UTC)[reply]

Discussion

  • Custom protection levels can already be implemented via the Requesting wiki configuration changes process, if there is community consensus to do so. Majavah (talk!) 16:59, 15 January 2022 (UTC)[reply]
    Yes, I think this is probably something that could be done today with a simple-enough phab request and community consensus. Izno (talk) 23:31, 16 January 2022 (UTC)[reply]
  • @John Cline: additionally, as to your request, Allow admins the ability to salt titles that requires lessor user groups than admin to create - this is already possible, create protection can be set to any of the protection levels. For example see this list. — xaosflux Talk 00:59, 17 January 2022 (UTC)[reply]
    To any tech people reading this, that isn't the exact tech reasoning - just using the same terms that the requester did. — xaosflux Talk 01:00, 17 January 2022 (UTC)[reply]
    Thank you Xaosflux, for your reply and the additional information given. If not disallowed, I have modified my technical wish to align with the new information (new to me) that you provided and expanded it to include move protection as well. If the modifications are not proper, someone can close this request and I'll submit another request anew. Also, if my comments in this section are disallowed, remove them with my apologies. If my comments are allowed in this section, the internal comment in the document source that says: <!-- DO NOT EDIT BELOW THIS LINE -- DO NOT EDIT BELOW THIS LINE --> should be removed. I can imagine that others could be confused by such an internal comment as well. kind regards. --John Cline (talk) 03:37, 17 January 2022 (UTC)[reply]
    @John Cline: so yes, basically this is something that can already happen technically - I would think it is extremely unlikely that it will be done for "every WMF project" or for mediawiki core, as "page mover" (extendedmover) is a bespoke usergroup that only exists on a few WMF wikis (enwiki, enwiktionary, fawiki, urwiki). Of those, you only seem to be involved with enwiki. This will pretty much never happen as-is, so you have a couple of options:
    1. Continue discussion at w:en:Wikipedia:Village pump (proposals) along the path of "Create a new protection level on the English Wikipedia that can be used when create-protecting pages, and allow extendedmovers to edit in that level".
    2. Here, you could propose a new permission model, something along the lines of change the create-page workflow to split the permission checking to allow a new permission for overriding edit-create protection if the page does not exist and the user has access to a new permission. Once all that was done, a project could assign said new permission to a usergroup.
    Cheers, — xaosflux Talk 11:07, 17 January 2022 (UTC)[reply]
    Thanks again @Xaosflux:. Based on the things I now know, I think it would be best for the entire "wish" process for me to withdraw this request and for it to be either removed or wrapped in an appropriate manner that indicates finality and closure. I'm not familiar with the wishlist protocols so if you, or someone else could proxy that on my behalf, I'd be grateful and the process here: better served. My thanks, to all, again.--John Cline (talk) 15:33, 17 January 2022 (UTC)[reply]
    @John Cline: sure, it will get moved to "Archives" before the voting stage opens - thank you for your idea! — xaosflux Talk 15:37, 17 January 2022 (UTC)[reply]

Add a way to tell the user if he is copywrite infringing before submitting the edit

NoN Technically infeasible

  • Problem: Add a way to tell the user if he is copywrite infringing before submitting the edit
  • Who would benefit: All editors of wikipedia
  • Proposed solution:
  • More comments:
  • Phabricator tickets:
  • Proposer: Omar102 (talk) 11:40, 17 January 2022 (UTC)[reply]

Discussion

  • @Omar102: This is a great idea! Unfortunately, we've looked into this before and it's just not feasible to run the copyright-detecting system at the time when a page is saved. It's too time-consuming. However, we do have the CopyPatrol tool, which ensures that all edits are (after saving) checked for plagiarism. — SWilson (WMF) (talk) 02:37, 18 January 2022 (UTC)[reply]

Extend the template "Infobox data structure" to 3 columns

NoN Does not requiring engineering resources

  • Problem: The template "Infobox data structure" offers the 2 columns "Average" (induced by _avg) and "Worst-case" (induced by _worst), but for some algorithms there are known 3 columns, namely also "Amortized".
  • Who would benefit: Mainly the WP-reader, because s/he would read information which is closer to the relevant literature.
  • Proposed solution: Currently available are the columns _avg and _worst, so _amort should be added. And this for all the keywords space_, search_, insert_, delete_, update_ etc. Maybe, if there are only 2 columns mentioned, e.g. _amort and _worst, it suffices to show only "Amortized" and "Worst-case". If all 3 are used, it is proposed to show "Amortized" between the other two.
  • More comments:
  • Phabricator tickets:
  • Proposer: Nomen4Omen (talk) 16:17, 12 January 2022 (UTC)[reply]

Discussion

@Nomen4Omen: This does not seem like something that requires the assistance of developers, but can instead easily be implemented by anyone with some template skills on the wiki in question. Please reach out to the commnity via a talk page or via their community fora. —TheDJ (talk • contribs) 16:41, 12 January 2022 (UTC)[reply]

Category history

NoN Merged with Community Wishlist Survey 2022/Categories/Improve tracking of categorization changes.

  • Problem: There is no way to see what pages were previously in a category, nor when the pages currently there were placed there.
  • Who would benefit: Anyone monitoring specific categories.
  • Proposed solution: Create a "category history", which will allow users to see the history of what entered and exited the category. This won't be perfect (changes to categorization via template, lack of history before implementation), but would help in most situations.
  • More comments:
  • Phabricator tickets:
  • Proposer: Animal lover 666 (talk) 20:59, 13 January 2022 (UTC)[reply]

Discussion

Visual Editing for talk pages and other non-mainspace pages

NoN Does not require engineering resources / proposes existing feature

  • Problem: Talk pages and a lot of other namespaces only allow editing in source mode.
  • Who would benefit: People who prefer to use the Visual Editor, who can therefore use it on most non-mainspace pages.
  • Proposed solution: Allow Visual Editing on these pages.
  • More comments:
  • Phabricator tickets:
  • Proposer: Skarmory (talk) 14:15, 11 January 2022 (UTC)[reply]

Discussion

Hello @Skarmory,

  1. Have you used the Discussion tools? Maybe this is a solution to the talk page part of the issue?
  2. What other namespaces do you mean? If I'm correct, it's up to the local community to decide and then request for the VE in specific namespaces.

SGrabarczuk (WMF) (talk) 14:37, 11 January 2022 (UTC)[reply]

There is also exists the Convenient Discussions (CD) gadget with the same purpose. — putnik 18:32, 11 January 2022 (UTC)[reply]
See phab:T151854 for context. As I understand it, VisualEditor simply doesn't work well on talk pages, and there's not much hope that it will. Fortunately Discussion Tools fills the need very well for many people, so do give it a try if you haven't already! These days I almost never see wikitext on talk pages thanks to Discussion Tools :)
As for enabling on specific namespaces, I believe that is up to the community to decide, provided that namespace is free of discussions. For example, VE can't (or won't) be enabled for the Wikipedia namespace on English Wikipedia because w:Wikipedia:Village Pumps and many other venues are basically talk pages. Pinging @Jdforrester (WMF): in case they have input or corrections to make to what I've said. MusikAnimal (WMF) (talk) 19:54, 11 January 2022 (UTC)[reply]
Obviously this is a call for the Editing team and not me personally. :-) Jdforrester (WMF) (talk) 00:17, 12 January 2022 (UTC)[reply]
I think VE should be used for all the content namespaces except for Template, Module, MediaWiki. And in talk namespaces, VE shouldn't be enabled, instead is the Discussion tools and the CD gadget by JWBTH. Thingofme (talk) 11:51, 13 January 2022 (UTC)[reply]
I'm going to be bold and go ahead and archive this for reasons stated above. @Skarmory If you disagree with this, please give a timely response so we can refine your proposal into something workable before the voting phase starts on January 28. Thanks! MusikAnimal (WMF) (talk) 21:28, 18 January 2022 (UTC)[reply]
I'm fine with this being archived. Sorry for the late response. Skarmory (talk) 21:44, 18 January 2022 (UTC)[reply]

RedWarn to become a gadget

NoN Requires community consensus / does not require engineering resources

  • Problem: Twinkle as a helpful tool is a gadget, RedWarn is a helpful tool also but it is not a gadget.
  • Who would benefit: all editors
  • Proposed solution: making RedWarn as a gadget
  • More comments:
  • Phabricator tickets:
  • Proposer: Ctrlwiki (talk) 08:30, 15 January 2022 (UTC)[reply]

Discussion

  • Yes, I agree, and Ed6767 has resigned on developing the RedWarn. Also, this is made in user scripts as Ed6767 is not an interface-admin; but hopefully some interface administrators to get this to a gadget, similar to Twinkle. Thingofme (talk) 10:23, 15 January 2022 (UTC)[reply]
  • This kind of request is one that needs community consensus but could be done today, meaning it's not in CommTech scope. --Izno (talk) 00:41, 17 January 2022 (UTC)[reply]
  • This isn't a community watchlist thing as it can be done on enwiki by opening a RFC at the appropriate village pump, nor do I speak for the current RedWarn team, however, for some background:
    We did open a proposal, but we decided against making RedWarn a gadget as we don't think the format is appropriate for something like RedWarn and would give us far less flexibility, especially in updating. One of the last things I did as part of the RedWarn team was add a one-click installer to the enwiki page, which I could argue makes it even easier to install than scrolling through a list of gadgets. Ed6767 (talk) 01:47, 17 January 2022 (UTC)[reply]
  • Moving to the archives per above. Gadgets can be added without WMF assistance, and the developers of RedWarn apparently are against the idea anyway. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 22:52, 18 January 2022 (UTC)[reply]

NoN Does not require engineering resources

Editing Mode that shows a wiki external link for to a page that requires a subscription
An Inaccessible Website to those who don't have a subscription
  • Problem: Citations that are only accessible through paid subscriptions or login are marked through the usage of "url-access=". This is useful as members of the community can go through and find these, subsequently fixing the problem so that members can find a more accessible source. Exernal links, however, do not have this option.
  • Who would benefit: Members of Wikipedia who will be able to find certain links more easily.
  • Proposed solution: Add syntax to Wikipedia External Links, similar to citations. An example would be this: url=example.org|access=subscription
  • More comments:
  • Phabricator tickets:
  • Proposer: MrMeAndMrMeContributions 18:06, 12 January 2022 (UTC)[reply]

Discussion

Concept of Bi-head-ral, bipolar wikitable

NoN Duplicate of Community Wishlist Survey 2022/Reading/floating table headers

  • Problem: Long list needs a header repeated at less than page interval or better still a header in place (floating header with scrolling ) and the list scrolls below- a concept of bi or multiheadral table would suffice meanwhile. The printout on paper electronic pages can have a header on each page.
  • Who would benefit:
  • Proposed solution:
  • More comments: Though this is best taken up at the w:Village pump, it is listed herewith for info and the advanced Wikipedian can work on a solution Bi and Multi headral use is demonstrated in:[1]. Long list needs a header repeated at less than page interval or better still a header in place (floating header with scrolling) and the list scrolls below- a concept of bi or multi-headral table would suffice meanwhile. The printout on paper electronic pages can have a header on each page. Let the engineers work on floating header is only for viewing; for printing page length and header lines to be accommodated at each page breaks.
  • More comments:
  • Phabricator tickets: T42763
  • Proposer: Patelurology2 (talk) 20:30, 11 January 2022 (UTC)[reply]

Discussion

@Patelurology2: - main English Wikipedia

Add more types of citations

NoN Does not require engineering resources

  • Problem: Universities often release studies and thesis essays that are not published in journals, or which don't mention that they are also published in journals. This can make citing things fiddly using the manual citations templates - with the Journal template being the closest approximation. There are often valid sources that do not fit neatly into the allowed categories, making them difficult to cite using the form.
  • Who would benefit: Everyone
  • Proposed solution: Add a generic citations template, a university or organisation template, or allow us to edit the titles when posting. For example, changing "Journal" to "University". Also, if a field (such as archive URL) has a required second component (archive date) it would be good if both were added at once (though I think those should be on there by default tbh).
  • More comments:
  • Phabricator tickets:
  • Proposer: TiggyTheTerrible (talk) 11:42, 12 January 2022 (UTC)[reply]

Discussion

I was saying to add these to the 'Manual' part of the citations button. Are you saying there's a way for me to do that myself? TiggyTheTerrible (talk) 15:55, 12 January 2022 (UTC)[reply]
Yes and no. Yes this is configurable, but not per user, it is defined per wiki by each individual wiki (because the templates used for these citations differ on each wiki). For configuration steps see mw:VisualEditor/Citation_tool#Citation_tool_definition (add templates to VE) and mw:Citoid/Enabling_Citoid_on_your_wiki#Step_2:_Configure_Citoid (Map citoid information retrieval to template fields). —TheDJ (talk • contribs) 16:09, 12 January 2022 (UTC)[reply]

Make Discussion pages more like proper forums

NoN Proposes existing solution

  • Problem: Discussion pages, AKA talk pages, use the same Mediawiki software as articles. But discussions are not articles. Discussions do not have beginnings, middles and ends. Discussions are not documents to be perfected over time. A tool should be appropriate to the job.
  • Who would benefit: Editors.
  • Proposed solution: Adapt the wiki software used on talk pages to suit their real-life usage as discussion forums, by any means necessary. Integrate the Discussion Tools beta feature as standard. Revive the LiquidThreads project. Anything would be progress.
  • More comments: This is obviously a big wish, and unfathomably controversial among the many reflexive conservatives here. I personally believe it to be Wikipedia's original sin. A discussion is not a document, it is a discussion. To newcomers, to go to a talk page is very often to confront a mass of jumbled undifferentiated text. The indenting convention sprang up to fix the problem, but on most pages it is difficult to see the boundaries between comments - and therefore to be certain who is even talking, on a supposed "talk" page. There is no way to vote up useful comments, or get replies in one's inbox. Just an opaque wall of text and impenetrable code, accompanied by diffs - entirely appropriate to articles and inappropriate to discussions. Incidentally, this "paradigm capture" of wiki software on Wikipedia has a parallel on the Stack Exchange network, where they abuse their signature Q&A software for their own "meta" discussion pages! Talk pages are, de-facto, forums. The software used for them on Wikipedia is all but completely inappropriate. It is too late to junk and replace it, but I personally would welcome all and any improvements offered.
  • Phabricator tickets:
  • Proposer: Rollo (talk) 20:21, 16 January 2022 (UTC)[reply]

Discussion

Somekind of linking of referred books to the Worldcat.org

NoN Outside the scope of Community Tech

  • Problem: to made easier to readers to find info about the books referred in the articles, as could be the lybraries where to find it.
  • Who would benefit: readers who want more info about sources
  • Proposed solution: to made somekind of link to services/databases as could be worldcat.org or others
  • More comments:
  • Phabricator tickets:
  • Proposer: Carmallola (talk) 15:22, 12 January 2022 (UTC)[reply]

Discussion

Show a floating Search box on all pages

NoN Withdrawn by proposer

  • Problem: Having to scroll to the top of the page to get at the Search window takes too much time.
  • Who would benefit: All users.
  • Proposed solution: Create a 'floating' "Search Window" that would follow the user up or down the page.' See also "Back to Top" suggestion above.
  • More comments:
  • Phabricator tickets:
  • Proposer: Shir-El too 13:28, 12 January 2022 (UTC)[reply]

Discussion

  • @Shir-El too: I'm assuming you're proposing this for the default Vector skin? If so, are you aware of the Desktop Improvements project? It is a redesign of Vector that is slated to feature a sticky header with a search bar, among many other visual improvements. It's a project that you can enable into now in your Special:Preferences (uncheck "Use Legacy Vector"). Does this suit your needs?

    You might also be interested in trying out mw:Skin:Timeless, which already has a floating search bar. See here for a live example.

    If you just want to improve the old Vector, let's make that clear in the proposal. I can help if you need any. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 04:31, 13 January 2022 (UTC)[reply]

  • @MusikAnimal (WMF): Thank you for your suggestions - although I have no idea what most of them mean; I am not into programming. My thought was for something that would be usable across all Wikis by any Wiki user, a universal tool applicable to any Wiki page, with a minimum of fuss. How it would be implemented I honestly don't know. Stay Safe and Well! Cheers! Shir-El too 14:20, 13 January 2022 (UTC)[reply]
    @Shir-El too What I am trying to do is find out if the existing solutions work for you. These are already available to all wiki users, you just have to enable it. I will ask again: Does the Timeless skin work for you? Notice it has a floating search bar. You can change your skin permanently in your preferences, and for all wikis in your global preferences. If you don't like Timeless, try the new Vector (uncheck "Use Legacy Vector" in your preferences). This does not have a floating search bar yet, but it will eventually.
    If any of these solutions work for you, then there's no need for this proposal to go into voting. If you want to continue to use Legacy Vector, I'm afraid we can't offer a floating search bar for all users that is enabled by default (many people will not like this). But we could write a user script or gadget. We will need to reword the proposal to say this, which I can help you with.
    Let us know how you'd like to proceed, or if you're okay withdrawing the proposal now that you know about the existing/upcoming solutions. Best, MusikAnimal (WMF) (talk) 16:33, 13 January 2022 (UTC)[reply]
    * @MusikAnimal (WMF): I thank you for your ideas - it's just that your suggestions are almost complete 'Double Dutch' to me. Seriously. I'm guessing that you are writing about alternate versions of WP, but after trying one I decided to stick with the original. Meanwhile the community discussion here "Community Wishlist Survey 2022/Reading/Button to scroll to top of page" has come up with some simpler ideas that I'll try first. Again, Thank You for your time and effort. Stay Safe and Well!!! Shir-El too 19:36, 19 January 2022 (UTC)[reply]
    * @MusikAnimal (WMF):PS Yes, I'm OK with withdrawing the proposal. Thank You, Shir-El too 19:54, 19 January 2022 (UTC)[reply]
    Alright, with your word I will archive this as withdrawn by proposer. I'm sorry we couldn't help here. In my opinion getting used to Desktop Improvements may be worth the while. It will have many nice new features that won't be available in Legacy Vector. Anyways, thanks for participating in the survey! MusikAnimal (WMF) (talk) 19:59, 19 January 2022 (UTC)[reply]

Carry Wikipedia logon over to this Wishlist survey

NoN Duplicate of Community Wishlist Survey 2022/Miscellaneous/Automatically log in to all projects if you are logged in to one

  • Problem: When I clicked on the invitation to the Wishlist Survey from a logged-in Wikipedia page, my logged-in status didn't transfer over with me. I had to do password recovery before I could log in here, by the way. Once I was in, I did check the box to remember me here.
  • Who would benefit: People who appreciate staying logged in.
  • Proposed solution: Carry the logged-in information to this section.
  • More comments:
  • Phabricator tickets:
  • Proposer: RSLitman (talk) 16:39, 11 January 2022 (UTC)[reply]

Discussion

Improve visibility of proposed solutions in this survey

NoN Not a technical proposal

  • Problem: Proposals in this survey have a "Who would benefit" field which interferes with the natural flow of reading the proposals.
  • Who would benefit: All users of this survey.
  • Proposed solution: Move the "Who would benefit" field below "Proposed solution".
  • More comments: Discourse has a natural issue/response (or Q and A) flow. In this survey, reading of the proposed solution, the response to the problem, is interrupted by a less significant "who would benefit" field before it. Enjoyability and ease of reading would be improved by moving this field elsewhere.
  • Phabricator tickets:
  • Proposer: Danbloch (talk) 23:33, 17 January 2022 (UTC)[reply]

Discussion

Time Machine mode

NoN Technically infeasible

  • Problem: Wikipedia doesn't allow someone to easily go back and view the entirety of Wikipedia as it existed in the past
  • Who would benefit: The community, researchers
  • Proposed solution: Implement a Time Machine mode where you can choose any date in Wikipedia's existence, and any wikified link you click within articles will take you to a revision that existed on that day (if there's multiple revisions for that given day, the algorithm could just choose a random one) - archive.org integration could be made available for external links that are no longer live
  • More comments:
  • Phabricator tickets:
  • Proposer: TheNewMinistry (talk) 22:34, 11 January 2022 (UTC)[reply]

Discussion

  • I don't really see the point of this and this can be fixed with the "view history" tab. There is no reason for this edition, along with the fact that Wikipedia has "nostalgia" pages for a couple of decades ago. --MrMeAndMrMeContributions 05:29, 12 January 2022 (UTC)[reply]
    @MrMeAndMrMe: not really - view history is fine for viewing the wikitext of a page at any point in time, but if the page uses anything at all external to the wikisource (images, tempaltes, wikidata integrations, etc) - you will not see what that page looked like as of a timestamp. This proposal would likely require maintaining prior rendered versions of a page (such as what can be seen in a cache). This would also require a method to delete and suppress such cached versions. — xaosflux Talk 15:39, 12 January 2022 (UTC)[reply]
    Some Common files are removed for legal reasons (copyvio, etc). These cannot be shown, so there will be holes. Links to wikipedia articles can also be problematic, as the old content can be moved or reorganized to other parts of articles. The whole environment of related articles can be different and not reproduceable.Smiley.toerist (talk) 14:45, 13 January 2022 (UTC)[reply]
    @Xaosflux I suppose that is true, but I still don't see a particular reason for this. MrMeAndMrMeContributions 18:07, 15 January 2022 (UTC)[reply]
  • Per above, I'm going to archive this proposal as it proposes an idea that is technically infeasible. Yes, with significant effort we may be able to simulate what a page looked like given a timestamp, but there are so many ways this could break or otherwise not accurately reflect what the page looked like at that time. For instance, if templates used on the page have changed since the timestamp, the software would have to know to render those older versions of the templates. Also, what if the older version of the article used a template that is now deleted? Then we'd have to surface deleted content, which is a no-no. Finally, the MediaWiki software itself and how things are rendered has changed over time, so that would somehow need to be accounted for as well. The solution? The Wayback Machine. This will accurately bring you back in time to how things look and behaved then. Of course not every version of every page has been archived, but it's as good as we'll get for this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 21:00, 19 January 2022 (UTC)[reply]

References to existing page in other language, instead of just showing missing page in current language

NoN Withdrawn by proposer

  • Problem: Articles sometime exist in a large language (e.g. English), but are missing in a small language (e.g. Danish). When such a missing article is referenced in a small language, then the link just leads to a page for creation of the missing article This is rather useless when wanting to read about the subject. Many users can read article in multiple languages, and even seeing the images and article contents in an unknown language is often more useful than getting a page for creating an article about a subject that the reader would rather learn something about. An example is the Danish page about Apollo 11 (DA), where the article about "National Air and Space Museum" is not written yet, in which case a link to the English article at National Air and Space Museum (EN) would be useful.
  • Who would benefit: In particular readers in smaller languages, where some articles are not created yet.
  • Proposed solution: Allow creation of link to an article in another language. The Wiki system could then present a link to the top article in any language, a link to an article in a language preferred by the user.
  • More comments:
  • Phabricator tickets:
  • Proposer: MortenZdk (talk) 13:05, 17 January 2022 (UTC)[reply]

Discussion

Are you aware of the interlanguage link template? en:Template:Interlanguage link? This displays both a red link (invitation to create), and a link to an article in the language specified. The foreign-language link disappeared when the article is created. The template exists in 85 languages, including in Danish. Femke (talk) 18:22, 17 January 2022 (UTC)[reply]

Thanks a lot; I was not aware of that template. I have applied it to the Danish article, and it already looks much better. That template is actually an answer to my suggestion, so I guess that I should delete my suggestion. However, I don't know how to do that, since simply deleting the text does not work (gives an warning about wrong behaviour). MortenZdk (talk) 19:22, 17 January 2022 (UTC)[reply]
It will be archived by the team sometime in the next couple weeks before voting starts. Izno (talk) 22:42, 18 January 2022 (UTC)[reply]

Stop allowing site bans to render editors ineligible to vote in WMF board elections

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

  • Problem: Currently site bans render an editor ineligible to vote in WMF board elections. This is despite the growing realisation by the WMF that on some of its site – particularly smaller and outlying sites – indeffs are handed out to users who might, for example, have a disagreement with an admin, or might criticise attitudes of other editors, might be wrongly suspected of being a sockpuppet (surprisingly difficult to disprove), or take sides in political ructions such as the China–Hong Kong imbroglio and the Croation WP issue. There must be quite a few other examples.
  • Who would benefit: The whole community benefits if the WMF stops outsourcing voter eligibility to single admins on any site. Some blocks might well target vandals and others who probably are not going to make positive contributions to the movement; but we all know that blocks are multi-faceted and sometimes unjust – and typically resistant to appeal, without representation but in full public view in the manner of a show trial. It's difficult to see why editors who are blocked on one or even more than one site while having contributed and continuing to contribute positively on others for many years should be caught up in this one-size-fits-all net.
  • Proposed solution: End the criterion that denies suffrage in this way.
  • More comments:
  • Phabricator tickets:
  • Proposer: Tony (talk) 09:03, 19 January 2022 (UTC)[reply]

Discussion

DIRTZ

NoN Proposer did not respond

  • Problema:
  • A quiénes beneficiaría:
  • Solución propuesta: Ayudar a los usuarios tener una mejor experiencia respecto a la ortografía y evitar las ediciones arbitrarias.
  • Más comentarios:
  • Informes de Phabricator:
  • Proponente: IDRR12345 (talk) 04:58, 11 January 2022

Discussion

.CSV data upload

  • Problem: Many graphs are uploaded to Wikimedia and not updated because of lack of data
  • Proposed solution: Be able to upload a .CSV file to the Wikimedia summery section
  • Who would benefit: Everyone
  • More comments:
  • Phabricator tickets:
  • Proposer: Wikideas1 (talk) 06:47, 11 January 2022 (UTC)[reply]

NoN Does not require engineering resources

Discussion

mw:Extension:Graph's Vega does understand CSV, even in the version installed on WMF wikis. Whether it has access to the file system, I do not know. So, at least, that way a CSV based graph could be made.

Currently, you can make an graph from json data.--Snævar (talk) 09:53, 11 January 2022 (UTC)[reply]

I guess I’m just not smart enough to figure that out. I just wish there was a way to add data to a Wikimedia Commons document.--Wikideas1 (talk) 21:47, 19 January 2022 (UTC)[reply]
Thanks for this proposal! Let us know if you run into any trouble trying out the CSV import gadget. If it there are any difficulties while using it, those themselves could be a wish. For now, we will archive this wish since the functionality is available via that tool. Regards, NRodriguez (WMF) (talk) 12:52, 20 January 2022 (UTC)[reply]

Built - In Graphic Tools

NoN Too generic proposal

  • Problem: To create diagrams such as maps like this one, parliament diagrams like this one, or chronological scales like the one in the infobox of Ordivician, you have to use 3rd party and often difficult to use sites that often require downloads or payment.
  • Who would benefit: More casual editors without sophisticated technical skills.
  • Proposed solution: Make built - in, simpler, more limited alternatives for sites such as Adobe Illustrator or Toolforge.
  • More comments:
  • Phabricator tickets:
  • Proposer: PtolemyXV (talk) 00:58, 11 January 2022 (UTC)[reply]

Discussion

  • @PtolemyXV: As it stands, this proposal is a bit broad; would you be able to add some specific graphics tools that you feel are missing or inadequate? For example, what problems do you find with the Parliament Diagram tool (it seems to be reasonably frequently used but does have some open issues), or you could propose extending the SVG Map Maker tool to support more than just the USA. Also, I'd just note that Toolforge is not usually considered "3rd party", despite being outside the main wiki interface: it's the usual home for features that are ancillary to wiki-editing but which support that editing (perfect for things like graphics tools). Thanks! SWilson (WMF) (talk) 02:31, 11 January 2022 (UTC)[reply]
    • @SWilson (WMF): I didn't know that toolforge was associated with Wikimedia; thanks for letting me know. In that case, I would both propose that some commonly used toolforge features be integrated into the standard editing interface, and that the mapmaking and parliament tools be expanded so that they can be used in more contexts than just the US. What I'm specifically talking about, also, is that it took me quite a while to find the toolforge tools, and even longer to figure out how to connect them to Wikipedia. PtolemyXV (talk) 23:54, 11 January 2022 (UTC)[reply]
      • @PtolemyXV: Okay, great, sounds good! The Parliament Diagram tool isn't really US-centric, but perhaps there are diagram types that you wish it supported — could you list them? Or would you rather focus on the SVG Map Maker? And which specific tools need more exposure on-wiki? I guess what I'm saying is that it's best if proposals can focus on one well-defined thing (and don't forget that you can create up to five proposals!). Note also that the Toolhub now exists, as the primary catalogue of all tools. — SWilson (WMF) (talk) 06:37, 17 January 2022 (UTC)[reply]
        I'll archive this, but please feel free to create separate proposals with smaller scopes for any particular graphics tools that you think should be worked on. Thanks! SWilson (WMF) (talk) 13:00, 20 January 2022 (UTC)[reply]
  • I agree of that information; however, if we want to create maps or graphics without uploading to Commons, we need to have a template/module containing the content of the graph, and codes are very hard to write and store in articles. Thingofme (talk) 13:04, 12 January 2022 (UTC)[reply]

Improve integration with YouTube

NoN Does not require engineering resources

  • Problem: YouTube enforces a limit regarding the number of requests a single IP adresses makes in a given time frame. When this limit is reached, all requests fail with an HTTP 429 error (too many requests). This causes problems for tools being hosted on toolforge as they all share a single IP address. In particular, users who try to import YouTube videos using video2commons regularly face this error, forcing them to download the video from their computer before uploading it to video2commons. It affects citoid too, preventing it to get metadata from the page to cite youtube videos in references. A phabricator ticket is stalled since May 2020 despite WMF discussions with Google.
  • Who would benefit: Anyone who wants to retrieve from YouTube a video (for Wikimedia Commons) or metadata (for Wikipedia).
  • Proposed solution: I don't have the whole picture but I can think of two solutions:
    • Sign an agreement with Google to that Wikimedia IP addresses are allowed to bypass this limit
    • Change Toolforge infrastructure to get a pool of public IP addresses, with enough of them to no longer reach the limit
  • More comments:
  • Phabricator tickets: phab:T236446, phab:T254700.
  • Proposer: Don-vip (TALK
    PAGE    ) 22:15, 10 January 2022 (UTC)[reply]

Discussion

  • According to phab:T236446#7363298, YouTube won't make an exception for the WMF, which is unsurprising at best, given that it's explicitly against YouTube's terms of service to rip videos from the site. Now assuming you don't care about the TOS, there are open source programs such as youtube-dl-gui and yt-dlp which make downloading videos from the site easy. -FASTILY 02:36, 12 January 2022 (UTC)[reply]
    But I think sometimes for the computers, storing a large number of videos can take up a lot of computer spaces. Thingofme (talk) 15:50, 18 January 2022 (UTC)[reply]
  • Well, phab:T236446#7363298 as Fastily points out pretty much says it all. This entirely depends on YouTube cooperating with us, which they are not. Change Toolforge infrastructure to get a pool of public IP addresses, with enough of them to no longer reach the limit There is a pool of public IP addresses (I don't have them off-hand but it is a decently sized range). I'm not sure about video2commons, but in the case of production Citoid, we gave YouTube the range and they said it was too big (phab:T254700#6359644). That suggests doing the same for Cloud Services would be futile. We can leave this proposal here for now for further input, but I don't think this should go into voting because sadly, no amount of community support will change the situation :( MusikAnimal (WMF) (talk) 23:25, 13 January 2022 (UTC)[reply]
  • @Don-vip: There is nothing the Community Tech team can do about this at this time. Therefore, I am archiving. Thank you for taking part in the survey. DWalden (WMF) (talk) 13:39, 20 January 2022 (UTC)[reply]

UploadWizard improvement

NoN Functionality already exists.

  • Problem: There's no ability to set same summaries, descriptions, categories, and/or dates for files in UploadWizard. For example, I'd like to upload 30 files that are simply variants of one file and I'd like them to have the same summary, description, category, and date. I would need to go through and put in the summary, description, category, and date for each file which takes way too long! Well yes, many other file uploading tools exist, but Special:UploadWizard is official.
  • Who would benefit: People who upload lots of similar files
  • Proposed solution: On the "is this self work then select license" step in UploadWizard, add 4 checkboxes: "Give same summaries for each file", "Give same descriptions for each file", "Give same categories for each file", and "Give same dates for each file". For example, checking "Give same descriptions for each file" then going to the next step (label the files step) will only cause 1 description textbox to appear instead of one for each file. The description put in the description textbox will apply to all files.
  • More comments: Nothing
  • Phabricator tickets: No tickets
  • Proposer: Anpang01 (talk) 02:10, 11 January 2022 (UTC)[reply]

Discussion

It is already possible to copy summaries, descriptions, categories, and/or dates (and more, even titles with automatic numbering) to other files in the UploadWizard. Simply click on "Apply data to all uploads below" (might be slightly different text, translation from Dutch) just under the first upload, tick the appropriate boxes and click on the button <Copy>. That is all. --JopkeB (talk) 06:19, 11 January 2022 (UTC)[reply]

  • @Anpang01: Thanks for your proposal! As JopkeB mentions, the copy-metadata feature already exists in UploadWizard. It might be that this feature isn't readily discoverable, so feel free to make a new proposal about how to make it better. Thanks. SWilson (WMF) (talk) 13:57, 20 January 2022 (UTC)[reply]

Ability to mass revert article deletion through AfC/AfD process by specific editors/administrators

NoN Requires community consensus / rudimentary scripting

  • Problem: According to my memory, about 10-15 years ago, a large number of Japan-related articles on Chinese Wikipedia were deleted through Article for Deletion process, with editors/administrators involved in relevant procedures stated that their reason for proposing deletion of those articles being anti-Japan nationalism, although the official reason of those articles being submitted to AfD was their lack of notability and/or lack of sources and/or lack of third party reference. The amount of articles was too large at the time for concerned editors to pick up those articles and refurbish them according to guidelines at the time. Chinese Wikipedia guidelines have subsequently improved and adminsitrator position as well as users involved in actively editing Chinese Wikipedia have also changed as time goes, however many of the articles being deleted back then especially some of the more niche ones were still not being rewritten and they still only exists in the deletion log of the site.
  • Who would benefit: Any one who consume information from Wikipedia
  • Proposed solution: Provide a tool, to allow bureaucrat after gathering community consensus, to mass revert deletion depending on an array of conditions, for example identity of AfD proposer, the reason behind such proposal, the identity of administrator closing AfD discussion, and the stated reason behind such decision by them.
  • More comments: As I don't want to turn this into a debate of what should or should not stay in Wikipedia, the focus of this wish is to provide a tool for Bureaucrat to use it, after gathering community consensus and after definition of new rules, or after learning about factors that have influenced pass AfD processes, instead of trying to accuse anyone from actually conducting any of such events, and the intention of this wish is not to directly ask for re-installation of those deleted articles directly either, but rather the goal is to provide a tool where such option can be utilized when such situation surface.
  • Phabricator tickets:
  • Proposer: C933103 (talk) 14:15, 18 January 2022 (UTC)[reply]

Discussion

This sounds like a one-time script to run, that can likely be done via the undelete API already? — xaosflux Talk 16:19, 18 January 2022 (UTC)[reply]

If this is true then I would like to withdraw this wish? Since I am not an administrator who have access to such tool to tell how they perform C933103 (talk) 13:29, 19 January 2022 (UTC)[reply]
Yes, if you create a list of pages it should be rather straightforward to mass undelete them with a rudimentary user script. This does require some engineering skills but it's so small I don't think there's a point in it going through the survey, so with your word I will archive this wish. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 16:17, 20 January 2022 (UTC)[reply]
Wait, it seems like creating a list of page, especially by proposed deletor and by the deletion reason, would be the difficult part of the task, when we are talking about multi-year worth list of AfC from decade ago. And there doesn't seems to have a clear technical way to make a list out of this other than manual sorting each items one by one. C933103 (talk) 13:22, 21 January 2022 (UTC)[reply]

Require new user to disclose their affiliation at registration/first edits

NoN Requires community consensus

  • Problem: A number of users in Wikipedia are paid/affiliated contributors for some organization/companies/nations, and it would be desirable if they can disclose it themselves if those users are in such position, to reduce the chance of conflict of interest in editing went under radar
  • Who would benefit: Everyone who consume Wikipedia content.
  • Proposed solution: Add an option that ask user to state their affiliation at account creation and/or at their first editing, as well as related option in user preference, and automatically display such information at the account's user page, to indicate the nature of such account clearly.
  • More comments: It might be desirable to automatically link the claim to relevant categories in Wikipedia, and when users try to edit a page in the relevant categories, they should be presented with an additional warning, as well as have their edits be tagged by additional abuse filter. The setting should be in Global Preference by default.
  • Phabricator tickets:
  • Proposer: C933103 (talk) 04:03, 17 January 2022 (UTC)[reply]

Discussion

  • This seems like a community consensus needed request. --Izno (talk) 18:58, 17 January 2022 (UTC)[reply]
    At least in English Wikipedia, w:en:Wikipedia:Paid-contribution_disclosure is a policy that must be followed by those who conduct such behavior. And the wish would merely be a way to better enable the implementation and declaration by editors falling under the category specified in such policy as required by the policy. But I guess English Wikipedia isn't representative of all wikis? Then I guess this is not appropriate for global implementation into the MediaWiki software? Although it can also be made into an optional function I guess? C933103 (talk) 13:38, 19 January 2022 (UTC)[reply]
    Telling new users to disclose their affiliation if they have such is something we could say on the login page today. That we don't should indicate there is either not a local need or want to do this, or we believe (as a community) that this will scare off editors, and so on and so forth, extrapolated to 900 some odd wikis, most of which don't have the same policy as English Wikipedia.
    Ideally, changes that come from this survey benefit every one of those. Some do and some don't, but either way, a change like this would require significantly more study and community outreach than I would prefer for this team to perform, even if I thought the change was needed (which I also don't think it is needed). Izno (talk) 22:52, 19 January 2022 (UTC)[reply]
    Then I guess I should start a RFC on this instead? But while I have previously tried to start RFC on meta, none of them gained significant discussion nor major follow up by any official actions. How to improve chance of a successful RFC? (This question is maybe a bit off topic) C933103 (talk) 13:06, 20 January 2022 (UTC)[reply]
    Indeed, this would need broader input before any engineering work could go into it. For this reason I'm going to archive this proposal as needing community consensus. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 17:45, 20 January 2022 (UTC)[reply]
    You can try picking a wiki that you are specifically interested in to see if they want to add something like this. I expect that on English Wikipedia, you would not have consensus to change the login page, so you might try somewhere else instead. Izno (talk) 05:57, 21 January 2022 (UTC)[reply]

Auto-correct

NoN Duplicate of Community Wishlist Survey 2022/Editing/Grammar editor

  • Problem: Grammatical errors and issues
  • Who would benefit: Page creators
  • Proposed solution: Make an auto correct function to correct spelling issues or punctuation
  • More comments: Not sure if it should be a bot or a new function in the editor
  • Phabricator tickets:
  • Proposer: Rzzor (talk) 22:02, 11 January 2022 (UTC)[reply]

Discussion

Actually you can do it as a gadget or just for yourself. Kind of. See: https://github.com/Eccenux/veAutocorrect. We have this on plwiki as a gadget. You can add custom sequences see: #example-sequences. Obviously if want to use that for grammar or spelling then it would be very specific to a language you write in. Also not sure how would this work if you have something like 100 sequences. --Nux (talk) 23:22, 11 January 2022 (UTC)[reply]

What are sequences? Rzzor (talk) 00:34, 12 January 2022 (UTC)[reply]

My problem in RedWarn

NoN A small bug

  • Problem: Adding editors talk page to my watchlist after I warned them, which I do not like. No rollback links in page history.
  • Who would benefit: Editors of course
  • Proposed solution: I hope there is a option that disabling userpages to watch after warning them. And there is rollback links at the page history like Twinkle
  • More comments:
  • Phabricator tickets:
  • Proposer: Ctrlwiki (talk) 08:37, 15 January 2022 (UTC)[reply]

Discussion

I see you've already made these suggestions on the RedWarn talk page. Not sure what you expect Community Tech to do about it :) -FASTILY 00:25, 16 January 2022 (UTC)[reply]

Thanks for this proposal and for reporting the bugs, we are declining it since it is a smaller bug request. Thanks for understanding, NRodriguez (WMF) (talk) 18:46, 20 January 2022 (UTC) [reply]

Bot cataloger of images

NoN Functionality exists

  • Problem: it is often not easy to find well-cataloged images
  • Who would benefit: anyone who wants to use them to enrich the voice with images
  • Proposed solution: It is a bot that automatically searches for images on Commons and groups and signals them to simplify their consultation and use. I know that it is not easy due to the difficulties inherent in the versions of the various languages, but in my opinion it would enhance the opportunity to decorate the page more with a graphic support.
  • More comments:
  • Phabricator tickets:
  • Proposer: ImPERtinente (talk) 23:53, 11 January 2022 (UTC)ImPERtinente[reply]

Discussion

Reference importation tool, as in French Wikipedia

NoN Withdrawn by proposer

  • Problem: Inserting references is too time-consuming
  • Who would benefit: All Wikipedia editors on the English site (French site already has this tool)
  • Proposed solution: Develop a tool based on the French Wikipedia site tool
  • More comments: I am very surprised to see that the English Wikipedia site is far behind the French site, technologically speaking. Not only is the French interface to edit in general more user-friendly, but most importantly, it includes a great tool to generate the reference from a publication's DOI, URL, or title (among others). I highly recommend that you take a look and develop a similar tool (conceivably, the code from the French Wikipedia site could be re-used). This is now standard in other web sites. For instance, HAL, the French "Archives ouvertes" of the CNRS, also has a similar tool. This is where French scientists are supposed to reference their publications and whenever possible, enter the unformatted drafts of their papers. See: https://hal.archives-ouvertes.fr/ But my point is that at least two web sites (and possibly many more) have great tools to generate references from identifying information, and the main (English) Wikipedia web site lacks this. The difference in user (editorial) experience is such that I am now reluctant to work on the English pages and prefer to concentrate on the French pages, where I don't waste my time typing or pasting information that a code could do far more efficiently than me. Please consider this request seriously!
  • Phabricator tickets:
  • Proposer: Michel Laurin (talk) 09:39, 16 January 2022 (UTC)[reply]

Discussion

Example of reference insertion (Cite) toolbar of WikiEditor
Example of reference insertion (Cite) toolbar of Visual Editor
  • Response: Thanks DJ; I had not edited much in the English Wikipedia site for a while. I tried this tool and it works reasonably well. This item can be removed from the wish list.
    Per above, I'm archiving this proposal as withdrawn. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 22:18, 20 January 2022 (UTC)[reply]

Templates with editorial warning support

NoN Duplicate of Better warning display for mobile users and/or Alert View

  • Problem: When displaying Wikipedia articles, service templates such as "sources are needed", "contents appear not to be neutral" and so on do not display on mobile devices
  • Who would benefit: All users who could improve the contents
  • Proposed solution: Add an option to enable the visibility of such service templates when reading an article on a mobile device
  • More comments:
  • Phabricator tickets:
  • Proposer: L736Etell me 17:49, 12 January 2022 (UTC)[reply]

Discussion

希望可以把請求校對的條目按照其知識領域分類

NoN Does not require engineering resources (machine translation: 不需要工程资源)

Discussion

  • Thanks for your proposal. It sounds like the required categorization can be done by editing the relevant template on-wiki, and as such it isn't necessary for this to be voted on in the wishlist survey. If you don't know about editing templates, please ask on your wiki's Village Pump. (Machine translation: 谢谢你的提议。 听起来所需的分类可以通过编辑维基上的相关模板来完成，因此没有必要在愿望清单调查中对此进行投票。 如果您不知道如何编辑模板，请在您的 wiki 的 zh:维基百科:互助客栈 上提问。) — SWilson (WMF) (talk) 03:11, 21 January 2022 (UTC)[reply]

Pings for e-mail notifications

NoN Proposes existing feature

  • Problem: When someone emails a user using wikipedia they often have to leave a message on their talk page saying "You've got mail!"
  • Who would benefit: Wikipedians who use emails on their page
  • Proposed solution: A solution to this could be a ping in their notifications saying "You've got mail" instead of the person sending the notification to write that on their talk page that might not be checked often but there also needs to be a captcha check so it isn't spammed by bots and to stop spamming from others it should be limited to one email every 15-30 minutes
  • More comments: No extra comments
  • Phabricator tickets:
  • Proposer: The furret lover (talk) 20:48, 19 January 2022 (UTC)The furret lover ( aka Akari)[reply]

Discussion

Disruptive edit notification watchdog

NoN Withdrawn, as it was agreed that there is no longer a need to pursue this proposal

  • Problem: Some disruptive edits may go unnoticed for months or years, simply because there is no convenient means of detecting them as they occur.
  • Who would benefit: Admins and editors engaged in protecting the content of large wikis.
  • Proposed solution: Introduce a generic, user-configurable watchdog feature to obtain notification of certain types of rare edits to any page or object. This is similar to the watchlist feature, but while the watchlist feature is selective as to which pages it tracks, this watchdog is meant to be selective with respect to the types and characteristics of the edits it tracks.
  • More comments: Please see a longer write-up for more details of this proposal.
  • Phabricator tickets:
  • Proposer: SM5POR (talk) 07:49, 18 January 2022 (UTC)[reply]

Discussion

  • I just found mw:Help:New filters for edit review which may help tracking changes like the one that inspired this proposal. However, I haven't had the time to find out whether it makes the entire proposal redundant, wherefore I'm not withdrawing it, but I'm leaving it in place just in case it may help improve the functionality of the filtering mechanism. --SM5POR (talk) 06:02, 19 January 2022 (UTC)[reply]
  • @SM5POR: communities can already configure many filters that check targeted, or even every, edit(s) via the Special:AbuseFilter - which produces a public log: Special:AbuseLog that editors can review. I think that takes care of most of your request? As far as getting a "notification" for such hits - that seems quite cumbersome - where would it "send" these? To all users, to all opt-in users? If a notification went to say 1000 editors, would you expect that they all spend time reviewing it? — xaosflux Talk 15:30, 20 January 2022 (UTC)[reply]
    @Xaosflux: Thank you for pointing me to the alternative solution. The AbuseFilter mechanism however appears targeted at willful abuse of a fairly frequent kind, and I haven't found out how to create such a filter yet. While my proposed watchdog might catch those cases of abuse as well, it's not them I'm looking for, but supposedly quite rare changes, more likely done by mistake than by intent.
    Take the case I wanted to report as an example. A restore is typically used to revert a recent series of bad edits in bulk I believe. It should be done swiftly in order not to destroy good edits as well. Yet there is a restore link next to the undo link on every line in the revision history. The restore I found was far from swift; for no apparent reason it hit a revision that was already eight months old, destroyed 15 good intermediate edits, and remained unnoticed for another 15 months while editors gradually cancelled out some of the effects of the restore, probably unaware that they were redoing edits already done but lost, like ants repairing an anthill for the Nth time without knowing the value of N.
    As to the notifications, they should be sent to users requesting them only. If you are looking for events happening maybe once a month in the entire wiki, you will hardly check a log file on an hourly basis (which you would have to do to attend to those cases in due time). It's just like the page-specific watchlists in that regard. If two users happen to watch the same page, then I would expect both to review the notifications they get as well. -- SM5POR (talk) 08:52, 21 January 2022 (UTC)[reply]
  • My bad -- The restore feature appears limited to Wikidata only! Then I understand why this proposal makes little sense elsewhere, and I should probably withdraw it as the remaining functionality may well be served by the AbuseFilter mechanism as suggested by @Xaosflux: (thanks for making me find out). Now, where is the "cancel" button..? --SM5POR (talk) 09:40, 21 January 2022 (UTC)[reply]
    @SM5POR: there is a category of wikidata-specific wishes, so you can just tweak it with more details and it can be moved to that category if you could still find it useful there. — xaosflux Talk 11:05, 21 January 2022 (UTC)[reply]
    That could be an option, thanks, but since the cross-platform usefulness was a significant part of my motivation for writing that proposal in the first place, it would require a major rewrite to fit the more limited Wikidata context, and I simply don't have the time to do that. Another option would be to repurpose it to add some notification feature to the Abuse filter processing, if that doesn't exist today, but same thing there, I don't have the time this weekend, and I'm not familiar enough with the filter system to do it anyway. If anybody else sees some potential use for this entry, I will gladly offer it for them to work on (if that's permissible). -- SM5POR (talk) 11:50, 21 January 2022 (UTC)[reply]
    Hello there, thanks for taking the time to write the proposal and engage in conversation! I do agree it makes sense to cancel given what you learned. Will archive this! Regards, NRodriguez (WMF) (talk) 13:23, 21 January 2022 (UTC)[reply]

Фотовики

NoN Functionality exists

  • Проблемы: Нет качественного сервиса по визуализации исторического развития Земли
  • Кто выиграет: Люди
  • Предлагаемое решение: Создать сервис, наподобие pastvu.com, но на движке Вики и с меньшими ограничениями на публикацию фото
  • Дополнительные комментарии: Очень важно, чтобы ограничения были минимальными — не только архитектуры и городских пространств, как на pastvu.com, но и пейзажей, примечательных мест, интерьеров помещений, праздников, национальных атрибутов и т.д. И чтобы все это было привязано к карте и страницам Википедии. Возможно создание такого сервиса на базе Викимедиа.
  • Ссылка на задачу в Фабрикаторе:
  • Предложил(а): Pavljenko (talk) 12:08, 11 January 2022 (UTC)[reply]

Discussion

Hello there, and thanks for taking the time to write this proposal! This request sounds a lot like the existing platform, Commons We will be archiving this wish for that reason! Thanks and regards,

Здравствуйте, и спасибо, что нашли время, чтобы написать это предложение! Этот запрос очень похож на существующую платформу Commons. По этой причине мы заархивируем это желание! спасибо и привет, NRodriguez (WMF) (talk) 13:50, 21 January 2022 (UTC) [reply]

Embeding images rather than uploading them

NoN This proposal contradicts an established policy

  • Problem: Lack of creative commons images
  • Who would benefit: Readers
  • Proposed solution: Since there is a constraint on the upload of images to Wikipedia, why not simply embed the images via a link. For example, Google doesn't host images on its servers, yet when searching for a certain topic it presents images (I'm not talking about Google images) and when clicking on an image it takes you to the host website. I think Wikipedia should allow for such a feature because there is a lack of quality images with proper licensing and it will significantly improve the reading experience.
  • More comments: And maybe create a bot that deletes dead links to images or provide links.
  • Phabricator tickets:
  • Proposer: Omar.idma (talk) 10:09, 20 January 2022 (UTC)[reply]

Discussion

Purely adding keywards on Abusefilter

NoN Duplicate of Community Wishlist Survey 2022/Anti-harassment/Expose more detailed diff information to the AbuseFilter

  • Problem: For anti-vandalism, we want to create an abusefilter to check purely adding keywords on the article, which means that the keywardA is being added by the user. Currently we need to check both of added_lines and removed_lines with contains_any() (e.g. contains_any(added_lines, "keywordA", "keywordB", "keywordC") & !contains_any(removed_lines, "keywordA", "keywordB", "keywordC") or rewrite it with regex (e.g. keywords := (keywordA|keywordB|keywordC); (added_lines regex keywords) & !(removed_lines regex keywords)) to avoid false-positive because added_lines by editing "This keywardA is good" to "This keywardA is good, I am added" contains "keywardA" even though the edit does not add "keywardA". Such workarounds make our maintainance difficult, especially by not-so-technically-skilled users. Since it is very efficient and widely used for anti-vandalism, supporting easy-to-use function to check purely adding (and also removing) a keyward by abusefilter would be helpful.
  • Who would benefit: Users trying anti-vandalism
  • Proposed solution: I have two ideas. Other solution idea is also welcome.
    • The lighter one is that contains_any() supports array of keywords as its arguments (i.e. keywords := ["keywordA", "keywordB", "keywordC"]; contains_any(added_lines, keywords), which currently supports only variadic arguments contains_any(added_lines, "keywordA", "keywordB", "keywordC").
    • The other one is to implement a new variable including only purely added/removed words. Note that extracting words is a little difficult on the language which does not leave space between words (e.g. CJK). This sample is one of the simplest.
  • More comments:
  • Phabricator tickets:
  • Proposer: aokomoriuta (talk) 02:58, 12 January 2022 (UTC)[reply]

Discussion

Easy switching among Wikipedia language versions of each article

NoN Proposes existing feature

  • Problem: When reading an article in en.wikipedia.org I often want to read the corresponding article in es.wikipedia.org, which may have more complete information - as it often does when the subject is specific to that country. A direct link would be faster than redoing the search in es.wikipedia.org, de.wikipedia.org, etc., currently the only option.
  • Who would benefit: All Wikipedia users, especially those who are multilingual.
  • Proposed solution: Add an options drop-down at the head of each article with links to the corresponding article in other languages' Wikipedias. Ideally this should be automated so authors do not have to manually populate the drop-down for each article.
  • More comments: This is NOT a request to translate the article to another language but to link to an existing article in that language's Wikipedia, which may have different or more thorough information.
  • Phabricator tickets:
  • Proposer: Billfalls (talk) 23:02, 19 January 2022 (UTC)[reply]

Discussion

  • This already exists as a list of interwiki links. You should have it in the left hand column, in new Vector at the top of the page, and in mobile a little language button. --Izno (talk) 23:23, 19 January 2022 (UTC)[reply]
    Yes @Billfalls, I also am aware of many wikis where this already works well, are you referring to any specific wiki where this isn't the case? KSiebert (WMF) (talk) 09:52, 21 January 2022 (UTC)[reply]
  • @Billfalls: If you haven't already, try unchecking "Use Legacy Vector" in your preferences (or global preferences). This will give you the new Desktop Improvements, which includes a language switcher at the top of every article just as you describe. If you prefer Legacy Vector, look towards the bottom on the sidebar on the left, and you should see a list of other Wikipedias for which the article exist. If you don't see any, then it may only be available in English. Because what you're proposing already exist, I'm going to archive this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 18:16, 21 January 2022 (UTC)[reply]

Improved math and chemistry formula insertion

NoN Outside the scope of Community Tech

  • Problem: There are problems with inserting a math or chemistry formula into Wikipedia, such as the length of time it takes to write a formula or the difficulty of writing a formula with existing tools; Computing websites like Microsoft Math Solver, wolframalpha, and symbolab use several different models for inserting formulas and do not have the current problems with Wikipedia. If other modes on these sites are added to Wikipedia or Wikimedia software, the speed of writing and text correction will be very high.
  • Who would benefit: All Wikipedia users, especially editors, will benefit
  • Proposed solution:
  • More comments: It is now possible to add a formula in the Insert tab, but the simplicity and speed of working with it does not reach the level of the mentioned websites and needs to be improved.
  • Phabricator tickets:
  • Proposer: Mohammad ebz (talk) 15:35, 11 January 2022 (UTC)[reply]

Discussion

  • Hello and thanks for this proposal, we are moving this to the Archive because we are unable to integrate with proprietary software when building solutions. The LaTex syntax is more common than other open source alternatives. Thanks for your time! Regards, NRodriguez (WMF) (talk) 01:43, 18 January 2022 (UTC)[reply]

"cite book" ISBN database

NoN Functionality exists

  • Problem: Frequently in editing one article and having to enter all the details for a "cite book", one finds that related articles already have a "cite book" for the same book. Not only does this seem unnecessary duplication of detail, but it introduces the possibility of errors, either new or cloned.
  • Who would benefit: Anyone creating, using or maintaining a "cite book" type of entry in an article
  • Proposed solution: (Note: I'm considering this from a top-down perspective.) User interface could be, for instance, an enhanced "cite book" template or perhaps a "cite isbn" template or similar. Implementation would involve some sort of database, or perhaps an API to an external ISBN database.
  • More comments: This proposal is something like a database of books, so that the extended book information can be in a single place, referenced by multiple articles.
Instead of a user interface of:
  • "{{cite book |isbn=<ISBN> |lots... |of... |these}}" with lots of long details of authors (potentially many), authorlinks, title, publisher, year, place, etc.
one would imagine using:
  • "{{cite isbn |isbn=<ISBN> |...}}", supplemented only with this-instance details
as a higher-level version that fills in most of the details from that database-like entity.
It would, of course, still need some flexibility for details such as page numbers in particular usage-instance. For example, imagine two articles referencing the same simple book. One article might reference page 'p', another page 'q'. The first article would reference "{{cite isbn |isbn=<ISBN> |page=p}}"; the second "{{cite isbn |isbn=<ISBN> |page=q}}". Note how simple this is compared to each instance having to flesh out lots of additional detail.

Discussion