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.
@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]
NProposes 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.
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? — xaosfluxTalk22:07, 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. — xaosfluxTalk22:29, 10 January 2022 (UTC)[reply]
NProposes 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.
Out of scope: This is a request for a global (steward) action against a local community. You're probably looking for RFC, which may be a suboptimal idea as well but is at least a possible venue for such requests. ToBeFree (talk) 20:46, 10 January 2022 (UTC)[reply]
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).
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).
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
This can be done now. Simply consult template editors on your wiki to adjust the relevant templates as desired. You can read our FAQ for more information on what this survey is for. Thanks for participating, MusikAnimal (WMF) (talk) 22:25, 10 January 2022 (UTC)[reply]
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."
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. — putnik02: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]
NDescribes 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.
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
NDescribes 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.
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]
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)
@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]
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.
@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]
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]
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]
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.
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
NThis 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.
@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.
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.
This seems like something that should be requested at en:Wikipedia talk:RefToolbar first. If there's consensus, it could be trivially enacted by any interface administrator without the need for WMF intervention or taking up one of the wishlist slots. Ahecht (TALK PAGE) 15:17, 11 January 2022 (UTC)[reply]
Since this requires no engineering resources from WMF and is something only the community can implement, I'm going to archive this proposal. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 15:48, 12 January 2022 (UTC)[reply]
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).
Project can create any pages and processes they want already, what technology do you think is lacking that would need to be developed for this? — xaosfluxTalk00:22, 12 January 2022 (UTC)[reply]
Sorry, only your local community can decide that. This survey is for proposing improvements to software tools. You can learn more in our FAQ. I'm going to have to archive this proposal, but thanks for participating, anyway! MusikAnimal (WMF) (talk) 22:56, 12 January 2022 (UTC)[reply]
NProposes 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.
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]
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
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]
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.
NProposes 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.
@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]
@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]
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}}
@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
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!
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]
@RSLitman: verifying, you are referring to system-generated dates and times only here, not any date or time that happens to be in prose correct? If so, with the notes above, is this already resolved? — xaosfluxTalk14:18, 12 January 2022 (UTC)[reply]
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.
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]
@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]
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
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. — xaosfluxTalk00: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]
NWithdrawn 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.
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.
NProposes 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.
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.
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.
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. — xaosfluxTalk00:59, 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:
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".
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.
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]
@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
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.
@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]
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.
I agree that this is very practical, because there is a situation in our community, that is, "remove all the pages in the category, and then apply for deletion to delete the category page". Although it is possible to monitor the category page immediately, and then view it through "RecentChanges" or "Watchlist", it is not efficient. And if it is found vandalism, it is not easy to restore (don't know which pages were originally in this category). This requires a more convenient way to see what pages have been added or removed from categories. --Cwek (talk) 00:59, 14 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]
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]
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]
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
I don't think changing the MediaWiki Core syntax for external links is the right solution. Instead, your community should simply create a template to serve this purpose. For example, w:Template:URL on English Wikipedia could be changed so you call it like {{URL|example.org|access=subscription}}. MusikAnimal (WMF) (talk) 18:28, 12 January 2022 (UTC)[reply]
Per above, I'm going to archive this as a template-based solution would seem to make the most sense. It would also be much simpler and quicker to implement, while allowing your community to customize how you handle these URLs (for instance, you may want to put any URL with |access=subscription in a tracking category). Thanks for participating in the survey, MusikAnimal (WMF) (talk) 02:44, 19 January 2022 (UTC)[reply]
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.
That gadget link led me to gadget page and that will be explored but when people create these tables there is no freq gadget that may help with the table. The call is to automatically associate a gadget with such tables and function seamlessly in the background without looking for gadget
I think keeping the table header always on top of screen is extra important on mobile web/app with limited screen size, while it is also useful on desktop. C933103 (talk) 23:49, 15 January 2022 (UTC)[reply]
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).
@TiggyTheTerrible: There's nothing stopping you and your community from creating more templates. What software changes are you proposing that you are unable to do yourself? Perhaps you mean exposing those new templates in VisualEditor, or something else? MusikAnimal (WMF) (talk) 15:23, 12 January 2022 (UTC)[reply]
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.
Looks great, just like LiquidThreads. It should be integrated, not abandoned. This wishlist is for Wikipedia and its future, not for my personal needs. The solution of setting up a dev environment and a stack of software is not really a solution, unfortunately. Rollo (talk) 20:52, 16 January 2022 (UTC)[reply]
@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.
@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-Eltoo14: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.
* @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-Eltoo19:36, 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
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.
I saw that one after I entered mine. I am not up on Wiki terminology, but if my proposal is a subset of that one, I will gladly drop mine and support that one instead. RSLitman (talk) 19:57, 11 January 2022 (UTC)[reply]
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.
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
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. --MrMeAndMrMeContributions05: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. — xaosfluxTalk15: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]
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
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.
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]
NProposes 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.
Indeed, there's nothing we can do to help through this survey, which is meant for proposing technical features and improvements. You can learn more by reading our FAQ. Regards, MusikAnimal (WMF) (talk) 21:18, 19 January 2022 (UTC)[reply]
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.
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]
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.
@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]
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
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. -FASTILY02:36, 12 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]
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.
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
NRequires 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.
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
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.
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]
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]
It's like a function, a way like Grammarly or some auto-correct software. However, I think it should be a opt-in gadget for other languages, because Grammarly mostly focus in English. Thingofme (talk) 00:46, 12 January 2022 (UTC)[reply]
Oh, ok. I just thought it would be a good idea to implement this because some users might be skeptical when downloading online, so I thought it would be easier to do it without downloading anything and having it implemented into the editor instead. I can understand that this would be hard to implement, though. Rzzor (talk) 00:50, 12 January 2022 (UTC)[reply]
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
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.
@ImPERtinente Have you tried using categories and the new MediaSearch, as others have suggested? Asking for a bot to catalog images is a huge feat, and is better solved with the existing solutions of categories and structured data. MediaSearch is now the default search engine on Commons and in my experience works quite well. For instance, try search for red car or person holding a sign. MusikAnimal (WMF) (talk) 21:18, 13 January 2022 (UTC)[reply]
Categories is similar, and we also have already got Structured data, which is a bit similar to Wikidata; so we can search contents based on Wikidata property, like MediaSearch. Thingofme (talk) 00:56, 13 January 2022 (UTC)[reply]
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!
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.
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
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]
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
NWithdrawn, 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.
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? — xaosfluxTalk15: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. — xaosfluxTalk11: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]
Проблемы: Нет качественного сервиса по визуализации исторического развития Земли
Кто выиграет: Люди
Предлагаемое решение: Создать сервис, наподобие pastvu.com, но на движке Вики и с меньшими ограничениями на публикацию фото
Дополнительные комментарии: Очень важно, чтобы ограничения были минимальными — не только архитектуры и городских пространств, как на pastvu.com, но и пейзажей, примечательных мест, интерьеров помещений, праздников, национальных атрибутов и т.д. И чтобы все это было привязано к карте и страницам Википедии. Возможно создание такого сервиса на базе Викимедиа.
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]
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.
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.
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.
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]
@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]
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.
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]
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.
I could see this using the Open Library API. That said, I could see a case for a database of on-wiki book citations since we would potentially have info Open Library (or any other API) doesn't track (author/editor wiki links, etc.). = paul2520 (talk) 21:49, 10 January 2022 (UTC)[reply]
This already exists to some degree. Using the source editor and the en:Wikipedia:RefToolbar gadget (which is enabled by default on enwiki), if you go to the Cite tab, choose "cite book" from the "Templates" drop down, fill in the ISBN, and hit the magnifying glass icon, it fills in the rest of the book details automatically. Similarly, with Visual Editor, when you hit the Cite button, you can paste in the ISBN on the "Automatic" tab and hit generate, and it will fill in the rest of the details automatically. Finally, the en:Wikipedia:Citation expander gadget can add a button to expand citations of the format {{cite book |isbn=978-1-23-456789-0}} with automatically generated data from the Google Books API. Ahecht (TALK PAGE) 22:32, 10 January 2022 (UTC)[reply]
Would a template such as {{Cite Q}} help with this? It means that most of the work's metadata can be stored on Wikidata (the "database of books" mentioned above) and still allows individual citations to add their own parameters. For example, rather than using the ISBN as the identifier, the Wikidata ID is used: {{Cite Q|Q15625490|page=42}}. SWilson (WMF) (talk) 01:20, 11 January 2022 (UTC)[reply]
@SWilson (WMF): That {{Cite Q|Q15625490|page=42}} simplicity of style looks great. But most casual editors, however, would come along with an ISBN as the desired database key. I suspect few would come with even a vague notion of a Wikidata "Q". The ready familiarity of ISBN to almost all editors would be a major advantage. Does that database offer some sort of secondary index based on ISBN? Feline Hymnic (talk) 18:02, 14 January 2022 (UTC)[reply]
@Feline Hymnic: I guess it depends on how they'd be inserting the citation. If it were via the Citoid-based automatic process, then perhaps it could find a unique ID (e.g. ISBN) and check to see if there's a matching item on Wikidata, and if there's also an appropriate citation template parameter — so, yeah, maybe there's a bit of complexity there and different options! But I'm sure we could figure out some sort of helpful thing. There are lots of discussions about this topic, of course, and they go back quite a few years. As it stands, I'd say that this proposal should be archived because we do have a database of citable works (Wikidata). Could you rewrite it a bit to focus more on some smaller part of the process? Thanks! SWilson (WMF) (talk) 13:33, 17 January 2022 (UTC)[reply]
@SWilson (WMF): Thanks for the reply. What further rewrite is needed? My proposal is from the top down. The editor-focussed interface would be something like {{cite book |isbn=978-1-23-456789-0}} or {{cite isbn |978-1-23-456789-0}} Behind the scenes it would get the data from a central database. (Perhaps, but not necessarily, this might be Wikidata. That's an implementation decision, admittedly a big one, by those who have captured the vision and are in a position to implement it.) It would probably also allow some additional data, such as page numbers, and perhaps some overrides. I hope my proposed solution and more comments above are sufficient, clear and concise; but if not, could you explain what you would like me to provide, and where, please? Thanks. Feline Hymnic (talk) 17:56, 29 January 2022 (UTC)[reply]
@Feline Hymnic: The reason this was archived this is that it looks like the crux of the problem you describe is already fixed: we do have a database of books, and a means of citing them multiple times without repeating the bulk of the information. The remaining part of this looks to be to have a way to cite via the ISBN rather than Wikidata ID, and that's what I was referring to when I said to focus on a smaller part of this. That said, there is another proposal (Accessing items with particular statements via Lua) which would enable the ISBN-lookup process to work as you describe. SWilson (WMF) (talk) 02:32, 1 February 2022 (UTC)[reply]
Yes, yes, and yes again. Literally the number-1 missing feature for editing Wikipedia. No hyperbole from my perspective. It is unbelievable that editors are still doing all this completely unnecessary work. This missing feature alone has put me off working on articles, again and again. Rollo (talk) 18:50, 16 January 2022 (UTC)[reply]
Problem: Wiktionary does not dominate online the way Wikipedia does, despite its strengths in accurately documenting evolving language and despite numerous translations which cannot be found together at a single other source. (Compare our newest definitions to the random garbage at Urban Dictionary, or open up a translation section in one of our entries, and see for yourself!) This shortcoming is evident from online searches for definitions, synonyms, rhymes, or other such purposes, none of which tend to ever give hits for Wiktionary, whether looking for slang, jargon, archaic terms, or anything else. This lack of renown stems fundamentally from a design that has been pounded into the existing wiki software developed to enable discussions on long articles. These namespaces do not work well for dictionary purposes, so though editors have made do, ultimately it's the user experience that suffers. For example, it's difficult to use Wiktionary and Wiktionnaire together as a strictly French-English dictionary because of the need to jump around amidst all the clutter from other languages. Yet together the two sites are much more complete and reliable than other resources.
Who would benefit: New and existing users in both their native language, most importantly, and in foreign languages, most extensively.
Proposed solution: Re-envision what a wiki dictionary would look like from the ground up, then use that concept to propose extention or branch of the wiki software. Although its completion must combine the unilingual dictionary with translations and a phrasebook, this is not a proposal to re-imagine how dictionaries work, rather to capture the essence of a dictionary in a wiki format. For instance, the fundamental unit stems from a definition line, traditionally grouped by etymology, but there is currently no way to tie images, usage notes, or long lists of synonyms and translations to a definition in a way that's transparent within the wiki software. Consider use cases for definitions of different types of terms like newly attested slang, technical jargon, and acronyms in living languages, for quotations in and derivations from archaic languages, for synonyms, antonyms, hypernyms and such, for rhymes, for anograms and scramble searches, for translation work and language acquisition, and for whatever else falls under the scope of the project. Then consider combining all the Wiktionaries into one service, using the domain name only as a selection of the interface, and the tabs for specifically selected languages (like English and French) plus Other Languages, instead of Entry and Talk. This would in effect create much more than a dictionary, rather a single reference with unilingual dictionaries in every language. Again, the idea is not to redefine the basic tenents of a dictionary, but to establish strong traditional dictionaries first, in such a way that they can then reference each other. As this is intended to update rather than replace the existing Wiktionaries, the re-envisioning needs to occur within the Wiktionary communities themselves, but principally from a user standpoint first. If the Wiktionaries are to be combined into a single reference, then the prototype needs to derive from existing content as evidence of the feasibility of transition.
More comments: TL;DR This is Wiktionary. Let's replant it.
Problem: Many artricles have a refrences section, with the actual works, and notes, wher the works are cited with page number. It would be nice to be able to link the two automatically. So suppose I have a reference: "Foo, Bar: The Foos of Bar (..)", and I want to add a footnote, that the text cites is in that wotk on page 123, the tool should allow me to do that. If I add a second reference to the same work, say, page 234-345, I'd expect the reference to be moved to the references section, and to have two notes, with the work linked. Whether to dispaly the full reference twice, or to have a notes and a references section would then be one of the options the user could set.
Who would benefit: Readers/Editors of larger articles with many references
Proposed solution: Manage page numbers of a referenced work separately, provide logic to split the citation, if the user so desires. At the same time, provide a default setting for users without accounts.
NThis proposal was considered potentially harmful as it is prone to facilitate misconducts and worsens community dynamics
Problem: Users may want to revert others' edits en messe, which will cause notification spam. Unwanted notifications may also caused by other edits, such as mass creation of Wikidata items.
Who would benefit:
Proposed solution: Introduce a parameter to suppress all notifications caused by this edits (including revert, ping, page link, connection with Wikidata, etc.)
This strikes me as potentially open to abuse. It would make malicious edits harder to detect. How would you counteract that danger? ONUnicorn (talk) 14:33, 11 January 2022 (UTC)[reply]
Ah, I misunderstood the proposal then. Letting the editor control the notifications seems indeed like a door for abuse. Of course there are many cases where notification pollution might occur, but it is far more important to have eyes on all changes.
One solution would be to limit the feature to a few trusted users, but on Wikidata that would seriously limit its usability, since any user can do batch edits using automated tooling. Strainu (talk) 23:42, 13 January 2022 (UTC)[reply]
It’s not up to the users to make sure that others don’t receive spam. People decide for themself which notifications they want and which not, and that’s exactly how it should be. And as others already mentioned, there is a very high risk of abuse. Such a feature would make a devastating weapon for edit wars and would lower the inhibition towards treacherous behavior. --Nachtbold (talk) 18:07, 17 January 2022 (UTC)[reply]
@GZWDer: Thank you for your proposal but like others have already mentioned this feature will open a door for abuse. I'm sorry but I'm afraid I have to archive this. DMaza (WMF) (talk) 16:16, 24 January 2022 (UTC)[reply]
Problem: sometimes there may be hundreads of people following a certain page, but there is a risk that none of them is really watching/active on wiki.
Who would benefit: patrollers
Proposed solution: when you look at page information, patrollers would be able to click on the number of page watchers and get a list of people who follow the page and people who looked at the last edits from those people.
More comments: the reason I believe this should be only for patrollers is for the same reason only they can see how many follow a page that has less than 30 followers-To avoid abuse of the watchlist information...
I don't think this is good idea. There might be articles I watch, but I want nobody knows about it. Now I can see Number of page watchers = 13; Number of page watchers who visited recent edits = 5 and this is enough information. But will be useful, when patrollers can see more detailed info - without names; and when inactive watchers are not counted in (also for special:unwatched pages). JAn Dudík (talk) 07:37, 12 January 2022 (UTC)[reply]
@Strainu: E.g. if this page was visited by watcher in last 24 hours or last week. If there was some watcher for admin/patroller usergroup. If they simply visited pages or looked to diff. I don't know how exactly this works and how is it counted, but often ahppens that some vandalism remains in frequently visited page, because nobody seen diff where was this edit made and vandalism is not easily visible. JAn Dudík (talk) 09:36, 12 January 2022 (UTC)[reply]
@Omer abcd: before this very quickly gets voted down - "WHY" do you think this would be useful? What is a usecase? Say you could do this, what positive thing would you do with the information? — xaosfluxTalk15:54, 12 January 2022 (UTC)[reply]
If I knew it, and I saw that the only ones who follow the page are not active at all on wikipedia, I know that the amount of watchers is helpless and I know I should follow the page. Maybe some followers follow a page for fun and not for patrolling it and then the amount of those who looked at the last edits is not telling the truth. There is no way to know why someone follows a page. I get the idea that this violates privacy, so maybe this abillity should work only for checkusers... Omer abcd (talk) 16:07, 12 January 2022 (UTC)[reply]
Problem: Reports to administrative noticeboards often require many diffs of talk page posts or noticeboard comments. Finding diffs for specific content is a time-consuming process involving many clicks, particularly for prolific users and popular venues.
Who would benefit: Any editors initiating reports on administrative noticeboards
Proposed solution: A gadget which creates a "view diff" link at the end of every signed comment.
More comments: In an ideal world, I would be able to read a discussion on an administrative noticeboard, and click on/copy links to diffs in which each comment was added, just as I currently have the option to reply to any individual signed comment. This may not entirely eliminate the problem I describe, but it will lighten the burden considerably.
Without commenting on the usefulness of the tool itself, the logical way to implement it would be using the timestamp on each comment: transforming the timestamp into a diff link for that comment. The timestamp-based link could be used either to shorten the search for the revision (if purely a gadget) or to provide the diff link directly (if implemented as a MediaWiki feature). {{Nihiltres |talk |edits}}06:11, 11 January 2022 (UTC)[reply]
A similar tool which extends the new built-in DiscussionTools was introduced very recently: mw:Topic:Wmredg44lh8v9x9i. The link it generates after comments with signature doesn't redirect to the diff, though, but generates an anchored link within the page. Per phab:T249893, some work has also begun on adding the "thanks" button to comments which by coincidence also requires inferring the revision id from the comment. So this wish might actually be implemented into DiscussionTools (@User:PPelberg (WMF)). --Matěj Suchánek (talk) 12:54, 11 January 2022 (UTC)[reply]
@MusikAnimal (WMF) I was unaware of both of these, thank you for pointing them out. I will try both tools, and report back. TimestampDiffs does seem to be what I'm looking for. It doesn't seem to be very commonly used (based on a what-links-here check); I do wonder if more advertising could be helpful. Vanamonde93 (talk) 17:07, 21 January 2022 (UTC)[reply]
Based on a random sampling of ~20 timestamps so far, TimestanmDiffs has the functionality that I was looking for, so thanks again for alerting me to it. Within this small sample, it has generally performed well, but has troubles with ANI comments on occasion, suggesting there may be room for improvement; nonetheless, the tool clearly exists, so perhaps I should withdraw this? Vanamonde93 (talk) 17:17, 21 January 2022 (UTC)[reply]
@Vanamonde93 The thing is, as you've noticed, inferring the revision ID from a comment is not always possible. Any tool WMF builds will come with the same caveats the existing solutions do. If you want, we can see this proposal through voting, but I don't think we'd be able to offer an "official" 100% foolproof solution. This is simply not possible due to the fragile and unstructured nature of wikitext. MusikAnimal (WMF) (talk) 19:04, 21 January 2022 (UTC)[reply]
@MusikAnimal (WMF) I do understand that, believe me, and I'm neither expecting nor asking for perfection. I suppose the important question to ask is whether WMF resources will make this a better tool, or if it's already good enough that further investment isn't worthwhile. I am not qualified to answer this, as I've neither used this tool very much nor had any coding experience of this sort. So perhaps voting on this will be helpful, and if the community indicates it isn't a priority (either because it's already good enough, or because it's just not that important), that's fine by me. I don't know how you're going to structure these proposals for a vote, but I think if this does go to a vote, the existing tools should be mentioned. Vanamonde93 (talk) 19:12, 21 January 2022 (UTC)[reply]
If you say en:User:Evad37/TimestampDiffs.js works well enough for you (and I suspect it's about as good as it will get, knowing the strength of the engineer who wrote it), then I think it's safe to archive this proposal. What we don't want is community expectation that they will get something better. Discoverability of the script would be nice, though. Pining Evad37 with a suggestion to promote it on Toolhub. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 22:25, 24 January 2022 (UTC)[reply]
Ability to find articles by what categories they are in
Problem: There is no way to search Wikipedia articles by categories
Who would benefit: People who want to find articles based on a certain criteria, without having to cross reference which articles are in what category.
Proposed solution: A way to find articles by what categories (one or more) they are in.
Problema: a veces un usuario (normalmente no registrado) realiza un cambio, e inmediatamente después lo suprime.
A quiénes beneficiaría: a cualquiera que sigue páginas para ver si hay cambios no pertinentes o vandalismo, para ahorrarse tiempo (no tener que ver si realmente uno quitó bien algo que antes puso, normalmente como vandalismo). Ahorro de tiempo.
Solución propuesta: en el caso de que alguien ponga algo e inmediatamente después lo quite, que esas dos acciones no aparezcan como cambios recientes de las páginas que uno vigila (es decir, esas dos acciones no se computen como cambios recientes)
Problem: many recent evolutions are incomptatible with wikisource interface, or broke the "proofreadpage" tools... Problem is that, even on big ws projects, there is generally only 1 technical volunteer admin, part time, with less and less free time (I think of @Tpt (fr) ou @Samwilson (en) or @Alex Brollo (it)) - and it is very difficult to have problems fixed, since the specific wikisource structure is difficult to comprehend.
examples are VisualEditor (still completely breaking Proofreadpage), Zoom recent changes, Syntax colorisation - that completely inhibits scripts that we can't do without..., recent break of Hocr (shared script), etc.
Who would benefit: All wikisource communities.
Proposed solution: Have a specialized dev', devoted (part time) to specific wikisource problems, to avoid the total breakdown of wikisource tools...
Hello and thanks for taking the time to write this proposal. We reviewed this proposal as a team and have determined that this is out of scope for our team because it does not ask for specific tool changes and asks for people resources. While we agree sincerely that wikisource should be better resourced, we have to archive due to the rules of what qualifies as a proposal. Thanks again! Regards, NRodriguez (WMF) (talk) 00:45, 25 January 2022 (UTC)[reply]
This doesn't really express a specific wish of a problem or improvement to make very well/at all. What is most problematic right now? --Izno (talk) 02:41, 17 January 2022 (UTC)[reply]
The most problematic is that, often, the main tools of Wikisource (e.g. Proofreadpage) are modified without warning our interface admins, except via the tech news, which contains very brief and cryptic summaries of the modifications — remind that our interface admins are not coding experts! Moreover, even when these modifications succeed in solving some issue, they also often have "side effects" that developers have not foreseen, but that everyday contributors would have seen. For example, when the OCR tool was implemented on Wikisource (which is a great improvement, asked here in 2020, and I thank the Community Tech for that!), its button partly hid the scan in edition mode; another example, the zoom command have been modified recently, but it triggers bad highlighting in the scan; etc. etc. To avoid that, we would like our interface administrators to be informed with human-readable summaries when important modifications are made, and, before implementing them, our community to be invited to participate to the tests. This could be made by a specialised developer, which has thorough knowledge of Wikisource functioning. This proposal is relevant here, because the biggest modifications are often made to solve a problem raised during a Wishlist Survey (cf. the precited example of OCR tool). — ElioPrrl (talk) 13:40, 17 January 2022 (UTC)[reply]
I guess you’re right but what solution do you propose when a page no more behaved as it used to. There is no revert button to regain the features we’ve lost last december or when something like Code Mirror is deployed and years after each time a newcomer asks for help to solve a sudden problem, the first thing to check is if he activated the Syntax colorisation or when an api like #wpTextbox1 is not adapted to the Page Namespace and breaks an important tool. Protection of the Wikisource environment may be out of scope but, in a user perspective, it will remain a priority. --Denis Gagne52 (talk) 18:31, 23 January 2022 (UTC)[reply]
Problem: Words like 'now', 'recently', 'currently', 'this year', 'last year', etc. are meaningless in an encyclopedia.
Who would benefit: All readers who read an article several years after an edit containing ambiguous time-related words.
Proposed solution: After clicking 'Publish page', a warning should alert editors of ambiguous time-related words, and force return to edit mode.
More comments: An warning should be displayed. Example: "Your edit contains ambiguous time-related word(s), like 'now', 'recently', 'currently', 'this year', 'last year', etc., that are meaningless in an encyclopedia article, which may be read several years after your edit. Please edit the ambiguous time-related word(s) with a specific year or date."
Global templates need translation, and it's like writing the code and adding some translation marks. There can be global templates, in mediawikiwiki to translate, and a bot would update it crosswiki. The documentation should say "This is a template updated from mediawiki.org (or a site like template.wikimedia.org) by a bot. Do not edit this and edits/translations should be made in mediawiki.org." Thingofme (talk) 10:36, 15 January 2022 (UTC)[reply]
This was declined in a previous survey, as it was simply too large of a project for our team. See our FAQ for more information. This is however an ideal candidate for the new Larger suggestions category, where we advertise and allow voting on wishes for other teams and the broader movement's benefit, with the understanding there's no guarantee they will be implemented. I can say with great confidence, tough, that global templates is a very much wanted feature from pretty much everyone and their entire families. There were technical conferences with lots of people wearing "Global Templates" t-shirts :) But nonetheless there's good in showing our support to express it's urgency. I just think the proposal needs some rewording, first. @Nomen4Omen: Do you mind if I reword your proposal to be more technically sound? Also pinging Amire80 in case he wants to help. Thanks, MusikAnimal (WMF) (talk) 05:27, 18 January 2022 (UTC)[reply]
I don't understand computer programming any more, was a whizz at it in the 1980's, so sorry if this is a silly proposal. When I upload a DjVu or PDF file to Commons, it contains every image in the book, is there any way that the images could be extracted /cropped automatically from the pages under the same licence / description as the book upload? 03:44, 23 January 2022 (UTC)
Good proposal. I am not aware of any current auto cropper, croptool does crop pdfs and djvus with help from the user. Full page images can be linked to, like so: [[File:image name|thumb|page=pageno]]. These are the steps: 1. figuring out where the images are, 2. cropping out the empty space/text, 3. uploading the image.
This is how I see it, there are probably different methods. 1. The machine kind of knows where images are due to OCR. 2. Imagemagick, which we use, does allow to auto crop out an empty area, 3. re-uploading with same licence is defiantly possible.--Snævar (talk) 10:10, 23 January 2022 (UTC)[reply]
And oh, AlwynapHuw, please fill in the proposal. This wishlist does get translated into other languages than english, and that translation does not include the discussion.--Snævar (talk) 10:11, 23 January 2022 (UTC)[reply]
@AlwynapHuw: As Snævar says, extracting images from PDFs and DjVus can be done with the CropTool. This makes sure that the resulting files have the correct metadata. It doesn't detect the bounds of the images automatically, but that's usually a manual process that requires some editorial control. — SWilson (WMF) (talk) 05:35, 25 January 2022 (UTC)[reply]
Proposed solution: (Czech) když hledám určité slovo a nevím ve kterém článku slovo je, vyhledávač ho nenajde. To samé je to s obrázky. Když chci vložit obrázek a nevím, pod čím obrázek je (např. ulice.jpg) a zadám ho jen slovem ulice, vyhledávač ho nenajde. (English) when I search some word and I don't know the artice where this word is, searching wouldn't find it. And the same with images. When I want to add image and I don't know the name (ulice.jpg) and write only ulice, searching wouldn't find it.
2) (Czech) Vložení mapy je zbytečně složité, co použít pro vkládání odkaz ze Seznam mapy nebo z Google mapy? (English)Insertinhg of map is too complicated, what about to use for this ling to mapy.cz or maps.google.com ?
More comments:
Phabricator tickets:
Proposer: --08:36, 19 January 2022 (UTC)Mojmir13 (talk)
Dobrý den, mám na mysli tohle: když třeba někdo hledá loď Francisco a zadá to do vyhledávání na české Wiki, vyhledávač to nenajde, přestože tato loď je na stránce Lodě na alternativní pohon. A když chcete vložit obrázek této lodi, nestačí zadat např. ship Francisco, ale nutno zadat název toho obrázku
@Mojmir13: Thank you for participating. Unfortunately your proposal is too broad and for that reason I'm afraid I have to archive it. See the Community_Wishlist_Survey/FAQ for more details on our process and how to ensure your proposal have the best chance at being selected for completion. DMaza (WMF) (talk) 13:24, 25 January 2022 (UTC)[reply]
Problem: Wikimedia's projects' overall interface uses a lot of links instead of buttons
Who would benefit: Everyone
Proposed solution: Convert links to buttons
More comments: This is pretty straightforward: The sidebar and the topbar (?) in all Wikimedia's projects are comprised almost solely of links, at least in the Vector skin. The lack of buttons causes many new users not to use most of the links there until they gain some trust in their "wiki-abilities", which can mean many months, if not years in some cases. In many wiki-workshops I've been present, a lot of users weren't aware of the preferences tab and had never opened it before even after being an editor for quite some time, to give just an example. Buttons give the urge to press them which helps in engagement and site exploration so maybe it would be beneficial in converting many of the links mentioned above in buttons (they don't need to be necessarily icons, words can be retained).
@DWalden (WMF), I had actually forgotten about it. I remember trying it for some days and being really excited for the general upcoming changes. Then I switched back to the old version, promising myself to check it again in the future but eventually I had stopped to see updates about it around and forgot about that. Now that you mentioned it, I navigated the site a bit with that and it is very close to what I had in mind (at least in regard to the "topbar"). But... It has that mobile feel overall view that makes me uncomfortable to use it for long. (I hate to say it but I'm not a fan of the overall mobile view and I always switch to the desktop view.) Starting with the changes in regard to the top of the page and the logo, with many icons being gathered together instead of being collapsed on its own, etc. - Klein Muçi (talk) 10:54, 25 January 2022 (UTC)[reply]
Example of a wordpress page with a floating button in the bottom right corner to enable navigate to top op page
Problem: When reading long articles or specific chapters in the middle or at the bottom of such articles, I often wish to go to the top of the page to use the search field and must then scroll the whole way up.
Who would benefit: Every reader
Proposed solution: A (floating) button to scroll up to the top of the page as it appears in the low right corner of WordPress pages as soon as you scroll down a page.
Christian Ries Hey there, thanks for submitting this proposal! Could you share screenshots of the problem and describe more details about the instances in which you find yourself wanting to navigate to the top? The details about the pain points always make a proposal stronger! NRodriguez (WMF) (talk) 04:57, 13 January 2022 (UTC)[reply]
I was about to propose this too. If you are reading far down in a long article and want to go back to the top (say to revisit the Table of Contents or the tab bar or whatever), not every user device and/or browser has a "Home" key or similar. Where this is lacking you have to scroll, scroll, scroll back up. A "^Top" button fixed in one corner of the screen would go there instantly. A screenshot without such a button would not really illustrate the issue. Steelpillow (talk) 10:23, 14 January 2022 (UTC)[reply]
@Xaosflux: I didn't know about the template and don't know how it works - if it does. The idea is for a tool that would be available everywhere, just as the scroll-bars are, and would save some of the up-and-down schlep. Cheers! Shir-Eltoo21:31, 12 January 2022 (UTC)[reply]
I just looked at the 'Academic Journals' page and it looks like a good solution. Meanwhile I'll try using the Home and End Buttons to see what happens. Thank you and Stay Safe and Well!!! Shir-Eltoo19:46, 19 January 2022 (UTC)[reply]
@MusikAnimal (WMF):, @Xaosflux: and @Thingofme: 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-Eltoo14:24, 13 January 2022 (UTC)[reply]
@Christian Ries: I just re-read that your only problem was wanting a quick way to go to the "top of page" - the Home button on most keyboards should provide this functionality in most browsers. — xaosfluxTalk02:09, 14 January 2022 (UTC)[reply]
Technical implementation: Probably the easiest way to implement this would be to add the button to the boilerplate HTML for the page wrapper. It then needs only a little CSS to position the button. (I have begun to do this on my own web site, and it works well). Steelpillow (talk) 10:23, 14 January 2022 (UTC)[reply]
It would be necessary to make it selectable in the user Preferences, as users who do have a built-in Home function would be irritated by it. One might also consider including positioning options. Steelpillow (talk) 10:23, 14 January 2022 (UTC)[reply]
I will check in with the Web team to see if that's something they have been considering and if not why not? In any case I also feel like this could be implemented quickly with CSS. KSiebert (WMF) (talk) 10:51, 19 January 2022 (UTC)[reply]
Dear everyone who contributed here,
when checking in with the Web team, who would normally work on related tasks, they said it will get less necessary to work on a feature like that since we'll soon have a sticky table of contents (TOC) as a part of the UI which will allow to jump to all sections from all scroll positions. To go back to the top you could click on the first section in the TOC for example. If you are curious how this could work there's a prototype you can access here:
It's great to see that until we can use these new features there's a gadget to this as well. Thanks for all your efforts! To make sure we are not working on a wish that will soon be solved otherwise we will archive this wish and hope this makes sense. KSiebert (WMF) (talk) 16:20, 21 January 2022 (UTC)[reply]
Problem: Some people are dyslexic and can't read unless the text is displayed at a specific font at a specific size.
Who would benefit: Lots of people, especially those with dyslexia and Arabic readers (me included)
Proposed solution: The body text is too small in Arabic and having the option to change font size and style would improve reading experience. I think there are addons for browsers to achieve this goal but an integrated option would be nice, especially if tailored to Wikipedia.
Hello @Omar.idma, we think this is an interesting accessibility feature and wanted to tell you that the Web team has something on their roadmap, but they can not specify when they will be working on this together with a series of features called "reader settings". Since another will be implementing this, we sadly have to archived this wish. KSiebert (WMF) (talk) 12:40, 21 January 2022 (UTC)[reply]
Problem: Current categories were created in local Wikipedia. This uncentralized situation caused lots of redundant categories and confusion in each languages, some articles was categorized into upper category and lower category at the same time, and it is impossible to deal it totally with manual fix.
Who would benefit: Wikidata, and all project which used category.
Proposed solution: There may be two solution.
Create a property in Wikidata and included all categories. The category on other project will show their category with Wikidata support.
Divided each current categories into structured data, and showed categories automatically if the item fulfill the definition.
For Example: Category:1911 births (Q9704085) could be translated as "date of birth" (P569) with value "1911". Thus all item with matched property and value will showed the former category automatically.
Current category on Wikipedia could also translated into structured data and imported to Wikidata either.
The Wikidata community has plenty of tools already that solve this need. I don't see a reason to implement this request. --Izno (talk) 01:49, 17 January 2022 (UTC)[reply]
Maybe I didn't say it clearly enough. I mean that clear all the category tags on Wikipedia, and totally supported by Wikidata. The tools on Wikidata didn't help anything on Wikipedia's categorization. ---Koala0090 (talk) 05:58, 17 January 2022 (UTC)[reply]
The Category tree on different languages doesn't really match. Also, sometimes people on a language choose a different category for a good reason (becaus it better fits their tree). -Eptalon (talk) 22:41, 17 January 2022 (UTC)[reply]
Much of the effort involved here would be gaining support for the idea itself, and we don't think the Survey is the most appropriate place for this. In addition, a large-scale replacement of traditional categories to be auto-populated by Wikidata items (where applicable) is a massive ask that by itself would be outside the scope of our team, I think. I'm happy to put this in our Larger suggestions category if you wish but I feel like this idea, as genuine and sensible as it may seem, needs broader discussion beyond what the Survey can provide. I hope that makes sense... thanks for participating in the survey, MusikAnimal (WMF) (talk) 20:54, 25 January 2022 (UTC)[reply]
Make it easier to push several pages down the category tree at the same time
Problem: Given that many categories are overpopulated (but decent subcategories exist), it would be useful to "select" a number of pages from a category, and then move all of them down the category tree at once.
I have also discovered cat-a-lot and am very satisfied with this as a helper tool to exactly the use-case of the proposer. Check it out, please! --Enyavar (talk) 10:30, 23 January 2022 (UTC)[reply]
@Eptalon: As time is running out and we have not heard from you, I'm going to be bold and archive this as it would seem Cat-a-lot provides the required functionality and then some. Please ping me or someone on the team if you disagree, but we must act fast as we only have three days until voting. MusikAnimal (WMF) (talk) 20:57, 25 January 2022 (UTC)[reply]
Add a way to tell the user if he is copywrite infringing before submitting the edit (duplicate)
Infringement is a legal term, so this may be hard - quotes or media may have fair use exceptions - it would be hard for a tool to tell if "infringement" has occurred. Best change may be "possible infringement", but interrupting the save process may be hard here as any such check will be time consuming to hold up every edit for. There are some copyvio detection bots, perhaps they could trigger some notification to the author of revisions that they tag? — xaosfluxTalk23:51, 19 January 2022 (UTC)[reply]
Problem: Citoid isn't found in many Wikis including Meitei Wikipedia (mni wiki), Assamese Wikipedia (as wiki), Fiji Hindi Wikipedia (hif wiki) and many others. Many wikis, like Simple English Wikipedia, have malfunctioning citation tools also.
Who would benefit: Everyone who use citation tools
Proposed solution: Please allow every wikis to access citation tool. And please fix the malfunction of the citation tools in the already supported wikis.
More comments: In Simple English Wikipedia, though the citation tool is present, it is not working for every reference links. In this Wikipedia, citation tool converter works for book reference links like links of Google Books, archive org, etc. However, the citation tool doesn't work for news links, web links, and others. For frequent citation tool users like me, we have to convert the citations from bare url to well maintained non bare url, all by manual edits. Manual edits take a lot of efforts as well as a lot of time. However, such malfunctioning of the citation tool isn't found in Arabic Wikipedia, Spanish Wikipedia, etc. as I had observed. Their citation tools can convert any links of any kind.
Thanks for clarifying! I'm going to retitle your proposal and reword it to be more clear that we're talking about Citoid. By the way, phab:T294236 may effect the feasibility of this proposal, as it seems currently there is no maintainer of Citoid. Community Tech might still be able to help, though. We'll review this proposal more closely and let you know if we have any concerns. MusikAnimal (WMF) (talk) 17:22, 11 January 2022 (UTC)[reply]
@MusikAnimal (WMF): I've had a lot of truble with the same citaiton tool @Haoreima is mentioning on Simple English Wikipedia. Got to the citation stage with students on a grade-level-wide annual Wikipedia project and discovered that both the auto citation and the webpage citation tool were broken (autocite comes back with inability to formulate citation and web page manual citation cannot offer the form at all). Led to a host of other problems with the project.
To @Haoreima's other point, I am enthusiastic about making it easier for Wikipedians on less-populous-language Wikis to add to our global understanding of the world around us by building up content with notable topics that may be less-recognized or less-honored in en:Wiki or other more populated versions. Citation tools would absolutely help with that process.
Per above I'm going to assume this issue is now resolved as Citoid merely needed to be configured on the wiki. Please ping me if I've misunderstood. Thanks, MusikAnimal (WMF) (talk) 21:20, 25 January 2022 (UTC)[reply]
Problem: While reading the article, sometimes I found wrong information or unconstructive edit. To make any changes I have to go on the page history tool. In page history, I can see the difference between the revision but it takes lot of time in doing, so I either left if I not known or do it manually.
Who would benefit: All editors
Proposed solution: Provide a tool to view history in the section or to separate the history of the page.
Looks like this could be complicated to implement. Some people open the whole page for editing to change one section, sometimes an edit spans several sections. Does VE not open the whole page every time? Are the edits saved by section? What happens when a section is renamed, or merged, or split? Does "Who wrote that" not provide similar functionality? It takes a long time to load but seems to work quite well. · · · Peter (Southwood)(talk): 07:13, 11 January 2022 (UTC)[reply]
@I ame shears: Could you elaborate on the problem statement? Why do you need to go to the revision history to edit? I assume, as Pbsouthwood did, that you are trying to find an edit that added some problematic content. mw:Who Wrote That?, mw:XTools/Blame and WikiBlame all offer this functionality. Additionally, I find RevisionSlider to be helpful for this, too. When viewing any diff, you should see a "Browse history interactive" panel at the top. Do any of these solutions work for you? MusikAnimal (WMF) (talk) 20:54, 11 January 2022 (UTC)[reply]
@I ame shears, Pbsouthwood, and MusikAnimal (WMF): My suggestion for checking edits to an article and finding malicious editing or malicious user, etc. is to add a tool in the history section to video the evolution and expansion of the article (step-by-step animated images with highlighted added text). Show the user or the administrator or ... and can stop it in any part to examine that particular part more. Mohammad ebz (talk) 14:39, 13 January 2022 (UTC)[reply]
I think the edit history of a section is very hard. Just now, we should only see in the diff section, to see the difference between revisions. I agree with @Pbsouthwood, as this is very complicated to implement, and one edit can span cross-sections. Thingofme (talk) 07:43, 14 January 2022 (UTC)[reply]
The way I personally deal with this is with an offline tool, which I called "wikiblame" and can be found at https://gitlab.com/jordibc/wikiblame . It converts the history of the article into a git repository and then one can easily navigate thru it with their favorite tool to view changes (mine is emacs with vc-annotate). Could that, or something like that, be useful here? --Jordi Burguet Castell (talk) 01:04, 23 January 2022 (UTC)[reply]
@I ame shears: Since we have not heard back from you, we're going to archive this proposal since it seems to propose a feature that already has multiple solutions. If you truly wanted a dedicated revision history just for a single section, I'm afraid that's also out of scope and possibly technically infeasible, as others have mentioned above. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 21:53, 25 January 2022 (UTC)[reply]
VisualFileChange should have a possibility for large categories
I assume this refers to the VisualFileChange tool. I think the title should be changed to avoid confusion with the visual editor for articles, but I don't know if I can do that without messing up the wishlist. Matma Rex (talk) 02:10, 17 January 2022 (UTC)[reply]
@Sarangbot: As we have not heard back from you, we're going to go by our assumptions that you are talking about VisualFileChange which apparently already has a means to change the batch size (see above). Please let us know if we're misunderstanding you. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 21:57, 25 January 2022 (UTC)[reply]
Sorry that I forgot to answer! I made good experiences with loadBatchSize. When I tried for a special case to set it to a high number, its maximum seems to be 500. But it works fine, thank you for the hint -- Sarangbot (talk) 16:18, 26 January 2022 (UTC)[reply]
Problem: Divide script templates between languages. Annoyed writing article English first send trying to create article in another language later. Must learn new template or create template for that language.
Who would benefit: All
Proposed solution: Share code between different wiki pages
Who would benefit. For those who do not know Czech cuisine perfectly. And assigns pictures somewhere else. — The preceding unsigned comment was added by Pohled 111 (talk)
Problème: J'ai connu une époque où la saisie de mes données de connexion dans l'une quelconque des applications Wikimédia (Wikiquote par exemple) me permettait d'éviter de me connecter à l'ouverture de Wikipédia ou wiktionnaire... Depuis ce n'est plus le cas et j'enrage à chaque fois...
Qui en bénéficierait: Toustes les contributeurs.trices.
Solution proposée: retrouver la situation d'une connexion unique pour la session en cours
@Guy6631: Thanks for your proposal! This looks like it's a duplicate of an existing proposal to fix the log-in process on multiple projects. (Machine translation: Merci pour votre proposition ! Il semble qu'il s'agisse d'un doublon d'une proposition existante visant à corriger le processus de connexion sur plusieurs projets.)SWilson (WMF) (talk) 01:14, 26 January 2022 (UTC)[reply]
Donner un statut prépondérant à l'ISBN d'un ouvrage
Problème: La saisie des ouvrages est très disparate. Le modèle ouvrage n'est pas systématisé. Le stock saisi est donc non harmonisé et les nouvelles saisies ne sont pas uniformisées. La situation se dégrade et se dégradera encore !!!
Qui en bénéficierait: Toustes les contributeurs.trices qui ont à cœur de bien saisir leurs sources et références.
Solution proposée: Donner à l'ISBN un statut qui permette à un robot de remettre tout en ordre dans les articles déjà saisis et modifier la prodécure de saisie des nouvelles sources et référence pour que la seule saisie de l'ISBN donne le remplissage de tous les champs utiles à partir des données de l'éditeur ou autre base de référence.
Autres commentaires: Former les contributeurs au modèle harvsp qui permet d'alléger le § notes et références !!!
Bonjour Guy6631 et merci d'avoir pris le temps de soumettre. Cette proposition est très similaire à la Community Wishlist Survey 2022/Archive/"cite book" ISBN database, que l'équipe a archivée car, comme indiqué dans la discussion de cette proposition, nous avons déjà une base de données d'œuvres citables (Wikidata). (Ce commentaire a été traduit à l'aide de Google Translate.) English: Hello Guy6631 and thanks for taking the time to submit. This proposal is very similar to Community Wishlist Survey 2022/Archive/"cite book" ISBN database, which the team archived because, as noted in that proposal's discussion, we already do have a database of citable works (Wikidata). (This comment was translated using Google Translate.) LDelench (WMF) (talk) 02:13, 26 January 2022 (UTC)[reply]
1. Wenn man noch nicht über Sicherberechtigung verfügt, müssen andere das Sichten übernehmen. Das kann sehr zeitaufwendig sein. Diesen Sichtern würde ich gerne Danke können. UND 2. IPs kann man nicht danken:
Dem guten Miteinander in der Community:
1. "Sichtungs-Danken"-Schaltfläche in der "Versionsgeschichte" für "Sichtungen" UND 2. in der "Versionsgeschichte" einen Zähler einfügen, wie oft es einen Dank für eine Bearbeitung gab, so dass IPs dies in der Versionsgeschichte sehen können (Sie können ja nicht benachrichtigt werden.):
@Armin Krejsa: Leider ist dies ein mehrjähriger Vorschlag, an dem wir nicht arbeiten können. Es wurde wiederholt abgelehnt, sowohl aus technischen als auch aus sozialen Gründen. Sie können mehr darüber unter phab:T284214 lesen. Aus diesem Grund müssen wir dieses Angebot archivieren. Es tut uns leid! Vielen Dank für Ihre Teilnahme an der Umfrage (und Entschuldigung für die maschinelle Übersetzung), MusikAnimal (WMF) (talk) 02:25, 26 January 2022 (UTC)[reply]
Presencia en redes sociales para reclutar editores e instruirlos en las guías.
Problema: Wikipedia año con año está descendiendo en cantidad de editores.
A quiénes beneficiaría: Lectores y reclutas editores.
Solución propuesta:
Crear un canal en Youtube (En principio uno en inglés y luego más en otros idiomas) donde un personaje o una voz en off lea guías como "Wikipedia NO es" e instruya a su audiencia en neologismos como "Wikificar". Algo similar a los archivos de audio incrustados en un artículo de Wikipedia con una voz que lee el artículo en cuestión.
También leería artículos calificados como "buenos", sirviendo al mismo tiempo para la divulgación de conocimiento en general pidiendo amablemente a su audiencia que aporte sus conocimientos a Wikipedia.org y así tenga nuevos artículos que narrar.
Más comentarios:
Se tendrá que contratar a un actor o actriz de voz para que sea la voz de wikipedia.
Para ser más atractivo el proyecto se podría usar a un personaje como Wikipe-tan, aunque sugeriría cambiar el diseño del personaje para que la actriz de voz no tenga que agudizar tanto la voz y pueda entonar una voz más natural y menos exigente.
@Christian Alexis Arroyo Ortiz: Thanks for your proposal. Creating content is outside the scope of the Wishlist Survey, so I'll archive this. You might be interested in projects such as Spoken Wikipedia and Communications/Sound Logo. (Traducción automática: Gracias por tu propuesta. La creación de contenido está fuera del alcance de la Encuesta de lista de deseos, así que lo archivaré. Puede que le interesen proyectos como la Wikipedia hablada y Communications/Sound Logo.)SWilson (WMF) (talk) 03:16, 26 January 2022 (UTC)[reply]
Problem: Many genealogy websites compete with each other, are chargeable and do not prove filiations.
Who would benefit: All those interested in their genealogy will be able to benefit from the research of amateurs, and they themselves will be able to cross ascending trees and accelerate their work.
Proposed solution: An open database in which proof of parentage must be provided by a scanned document may link all databases. A name, few informations (limited list of information : dates, job and location), links to other names and at least one scanned document for each link.
More comments: Discussions will be about scanned documents interpretations, they will have to be re-written and a discussion page is mandatory. The biggest workload will be in the representation of family trees.
Agreed, therefore instead of asking for a "Genealogical database", I would encourage people to log ideas to implement features that would enable a genealogical database. There's a lot of features that would help, so one step at a time. Supertrinko (talk) 19:22, 11 January 2022 (UTC)[reply]
There is various discussion and information about this topic at Wikimedia genealogy project. As it stands, this doesn't sound like a proposal that is within scope — but it does sound like there might be some particular technical tasks that the Community Tech team could undertake to improve working with genealogical data on Wikimedia sites. @Bertrouf, as the others say above, this could be targetted a bit more specifically to one problem. (For example, something about Gedcom import/export on Wikidata, or family tree diagram generation, or some other small concrete tool or task…) —SWilson (WMF) (talk) 12:44, 12 January 2022 (UTC)[reply]
I don't think importing GEDCOM is good, as they are usually unsourced. However we may research existing functions of other genealogical websites and see what feature is missing. GZWDer (talk) 12:57, 12 January 2022 (UTC)[reply]
Problem: I contribute images through the mobile website (commons.m.wikimedia.org) from a smartphone via the mobile website (I can not download any mobile App for that purpose). When I log in with the smartphone to the mobile website there is no "upload files" button in the menu on the left
Who would benefit: Everybody who contributes to files to Commons with their mobile phone
Proposed solution: Just add a link to the regular upload pages
Upload button on commons mobile@Hangman'sDeath: Can you be more specific, there is a giant "Upload" button on mobile commons as soon you go to the link you mentioned above. See image below, which I uploaded via commons mobile after following that link. — xaosfluxTalk15:18, 20 January 2022 (UTC)[reply]
They mention the "menu on the left" which I assume is the hamburger flyout menu. Links there can't easily be configured there (phab:T65459), but it's still doable with JavaScript with the help of an interface admin in commons:MediaWiki:Minerva.js with something like mw.util.addPortletLink('p-navigation', '/wiki/Special:Upload', 'Upload'). There'll be a slight delay before it gets added but this should be fine because the sidebar menu isn't shown without first tapping the hamburger icon. MusikAnimal (WMF) (talk) 00:26, 21 January 2022 (UTC)[reply]
Gothca, perhaps this user story can be further explained, maybe they want the "upload" button on more pages? If the fix is about adding to "mobile-frontend-*" menu, phab:T65459 seems like the best fix to me, and would fix any similar issues! — xaosfluxTalk15:55, 21 January 2022 (UTC)[reply]
Problema: Cuando se celebran elecciones en España cada uno de los más de 7000 municipios elige a un nuevo alcalde. El Instituto Nacional de Estadística publica un archivo que lo incluye en cada provincia. Se incluye el código de identificación del municipio, también incluido en Wikidata. A simple vista se podría automatizar la tarea. Me parece que para la revisión anual del padrón el dato lo incorpora un bot. Opinión al respecto del usuario Strakhov: Supongo que habrá que usar OpenRefine y/o Quickstatements?
Hola y gracias por tomarte el tiempo de escribir esta propuesta. Estamos archivando este deseo debido a la falta de aclaración. Necesitábamos una aclaración para que pudiéramos aceptar este deseo y marcarlo para su traducción para que pudiera someterse a votación. ¡Gracias de nuevo! Saludos, NRodriguez (WMF) (talk) 18:21, 26 January 2022 (UTC)[reply]
Problem: To avoid having to leave a Wikipedia article to find a source for an article in the chance that you might close the article, lose connection, or it refreshes the page on its own.
Who would benefit: Any editor, especially those who are interested in including lots of citations in articles.
Proposed solution: A search engine built into the wiki editor that lets you find citations by searching.
It's not clear to me how this would work because you'd need more than just search engine results; you'd need to actually read those web pages and make sure they support the claim you're trying to make. How would you view those pages without leaving the article? It would seem simply opening a new tab to do your research is the easiest workflow. @SoyokoAnis: Could you elaborate a little more on what you had in mind? MusikAnimal (WMF) (talk) 14:46, 11 January 2022 (UTC)[reply]
I sort of have an idea of how this would work (I'm not the one who made this proposal) but I think it would be very complicated to implement. I'm thinking it would just bring up an overlay of some kind that is basically a browser you can use to find citations for Wikipedia and also look at the pages to see if they support the claim. There may need to be some kind of limitation to this (Such as a blacklist for websites you can't visit such as ones that are considered deprecated sources) to prevent someone from abusing it if it can be implemented. Overall I don't see how just opening up a new tab to find citations is an issue in the first place (the user said, "In the chance you might close the article, lose connection, or refreshes its page on its own", however this wouldn't really solve any of those issues since if you close the article, then you are still losing the work you did, if you lose connection same thing, if it refreshes, same thing). Blaze Wolf (talk) 18:27, 11 January 2022 (UTC)[reply]
To see whether a website is a reliable source or not, I think we need to open another tab (I agree with Blaze Wolf). Or, most of the people write texts on the Draft, or the page, or saving them to prevent errors. Thingofme (talk) 00:50, 12 January 2022 (UTC)[reply]
Hello @L736E:, thanks for this proposal. Would it be possible for you to elaborate on what would you like to see? What limits have you experienced? What would you like to do that is impossible now? SGrabarczuk (WMF) (talk) 04:16, 13 January 2022 (UTC)[reply]
I think the regex is like the title blacklist regex, but it's hard to understand. Maybe we should create a help page for advanced searches. Thingofme (talk) 11:05, 13 January 2022 (UTC)[reply]
@SGrabarczuk (WMF): A simple example: if I write in the search form say of en.wiki "([2-7]+2)nd Academy Awards" I would expect as most relevant results "22nd Academy Awards", "32nd Academy Awards" and on and the other less relevant not listed afterwards if not listed at all. Today I see that "2nd Academy Awards", that is "not" matching the regex used for searching, is displayed as "most relevant result". That's not correct or at least what an user would expect.--L736Etell me11:13, 13 January 2022 (UTC)[reply]
Thanks! I've instructed by a fellow Wikipedian whom I consider to be a regex expert that the search is a bit different from the regex feature in the editing mode. He says that in the case you've provided as an example, you need to type intitle:/([2-7]+2)nd Academy Awards/ or even intitle:/[2-7]+2nd Academy Awards/. Have you maybe taken a look at Help:CirrusSearch? SGrabarczuk (WMF) (talk) 17:51, 13 January 2022 (UTC)[reply]
@L736E Since we have not heard back from you, and what you're proposing appears to already exist, we're going to archive this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 21:44, 26 January 2022 (UTC)[reply]
Maybe I'm wrong, but that's because plain searches (Full text search in Cirrus help) doesn't support the use of regex at all (it uses its own set of regex-like characters).
Why not ? Please provide accurate descriptions of problems you encounter. Many people have many different experiences, ppl cannot guess what you mean. —TheDJ (talk • contribs) 14:53, 16 January 2022 (UTC)[reply]
@Thingofme I, too, am curious why you say the 2017 wikitext editor "can't use highlight as easily as the normal source code"? Are you sure you have syntax highlighting enabled (settings menu > Syntax highlighting)? This should for the most part appear exactly the same as the older wikitext editor. MusikAnimal (WMF) (talk) 02:40, 18 January 2022 (UTC)[reply]
It sounds like they're talking about loading the editor, not previewing, but indeed they would most certainly appreciate the "Show previews without reloading the page" preference too.
Problem When adding or deleting Wikilinks in a table using the Edit This Page function, it is a cumbersome process. You have to open the template, scroll to the text box and open it, then manually add or delete brackets around the words.:
Who would benefit Any editor who adds or deletes Wikilinks from articles:
Proposed solution Make it possible to add or delete a wikilink from table text without opening the table template:
Hello there and thanks for your proposal! We looked at this wish as a team and we had a couple of questions about what you meant here. Do you mind telling us which editor are you using? Can you link us to an example table that is hard to edit? A screenshot could also be helpful. It's hard for us to see what is meant here. Thanks in advance, NRodriguez (WMF) (talk) 01:10, 18 January 2022 (UTC)[reply]
Pinging @Rogermx so they see this. I think I might understand what you mean; it sounds like you're using a wikitext editor. Removing links from items in a table is a bit easier with VisualEditor, if you haven't tried it yet. You can click directly within the table, move the cursor on the link, then click on the "unlink" icon. Does that work for you? I'm not sure what solution we could devise for wikitext editing. MusikAnimal (WMF) (talk) 22:58, 20 January 2022 (UTC)[reply]
Problem: The second most annoying thing in Wikipedia, after trolls, is that mobile users have to switch to desktop to move (translate, an error in title).
Who would benefit: All mobile users that aren't multiplataform
Proposed solution: Add a sixth button in mobile web interface, which allows to move articles. A simple solution.
@Goodlucksil: The default mobile experience is intentionally stripped down. If you enable "Advanced mode" in your mobile settings, you will get the "Move" function along with most other native functionality you enjoy in your desktop. Since the feature you propose already exists, I'm going to archive this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 22:34, 26 January 2022 (UTC)[reply]
NProposer did not respond / proposes existing solution
Problem: If you are a mobile user, and you want to view your userpage or others, you need to click the three long bar at the top left of the article. There are options there including your userpage, your contribs, your watchlist etc. The problem is, there are no options "preference" and "sandbox" and if I want yo to see them, I need to search special:preference and my user sandbox at the searchbox of Wikipedia.
Who would benefit: all mobile experienced editors
Proposed solution: add "Preference" and "Sandbox" options.
@Ctrlwiki: Are you aware of the advanced mode on mobile? Go to your settings to turn it on. Then you will have an person icon at the top-right, which when tapped reveals all the "personal" links such as the Sandbox. There is no way to get to Special:Preferences but I believe this is intentional since most of the preferences don't apply to mobile anyway. MusikAnimal (WMF) (talk) 17:50, 14 January 2022 (UTC)[reply]
Since we still have not heard back from you, and this appears to propose a feature that already exist, we're going to archive this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 22:36, 26 January 2022 (UTC)[reply]
Supress user talk page notification in case of revert
Problem: At times, someone may vandalize or spam user talk pages. The user may or may not see his/her talk page before some third party reverts the edit. After this revert, the user will get a "you got a new message" which he/she may not want.
Who would benefit: Any user whose user page was vandalized/spammed.
Proposed solution: Allow a user to supress the user talk page notification in case of a revert. This will only apply if reverted to a version which the user had already seen.
Someone edits user_talk:xxx (lets assume it is a vandal)
The "new messages" indicator is set / echo notification triggered
Someone makes any reversion edit on the user talk page
The "new messages" indicator is set / echo notification triggered
Scenario 2
Someone edits user_talk:xxx (lets assume it is a vandal)
The "new messages" indicator is set / echo notification triggered
The user visits their userpage, clearing the indicator/notification
Someone makes any reversion edit on the user talk page
The "new messages" indicator is set / echo notification triggered
So is the use case you want to change to just remove the last step from scenario 2? This seems like a problem to build around the "revert" tagging job - see this reversion for example - if someone did that to my page I certainly would not want the notification to be suppressed. — xaosfluxTalk16:11, 12 January 2022 (UTC)[reply]
Actually, what triggered me requesting this was a scenario #2 from a spammer. He left me a request to edit a specific article; I saw this message; and then it was reverted. I really would have preferred not to be notified about this revert. Animal lover 666 (talk) 20:33, 13 January 2022 (UTC)[reply]
@Xaosflux I think the idea is that we'd only make the first user talk page notification disappear if the edit that caused it is reverted, and the user hasn't seen the notification yet (and if they have email and app notifications disabled, since we can't "undo" those). If the user has already seen the user talk page notification, this special behavior would not happen. Matma Rex (talk) 04:37, 22 January 2022 (UTC)[reply]
We feel like this is changing the way to notifications work a bit so it so it's seems too complex to be implemented by us in a wishlist cycle. Sorry, that therefore we will have to archive this wish. KSiebert (WMF) (talk) 14:28, 26 January 2022 (UTC)[reply]
Problem: Difficulty to read and keep an overview on long articles
Who would benefit: Any reader
Proposed solution: Generate summary in the left pane, for example between "Babel" and Community. Make it always visible with the title of the section currently read in the middle of the screen and highlighted in color
More comments: Somewhat similar to the navigation pane in MS Word, hopefully better
Yes, Sdkb and Strainu! Thanks for these links. If anyone (I'm looking at Gfombell and Ed6767) is intersted in learning more or getting more involved, check the Participate page. Also:
Did you know ...
...that "new Vector" is in fact just (the) Vector, and (the currently default on most wikis) "Vector" is in fact "Legacy Vector"? So instead of "current vs. new" it's "frozen vs. the new basic one". This is because Vector with the new changes is the only currently evolving version, and the version without the changes is "frozen" and only maintained. That's a DYK for geeks. If you'd like to read more, check this FAQ question. SGrabarczuk (WMF) (talk) 04:57, 13 January 2022 (UTC)[reply]
Somehow super glad to see that the wishes contributors have are already in the workings by other foundation teams, will have to archive this for this reason, thanks for proposal in any case! KSiebert (WMF) (talk) 16:24, 21 January 2022 (UTC)[reply]
Problem: It is currently not possible for restoring back to a previous version in the mobile site version. This is especially hard for mobile editors who wants to revert multiple edits and bring back a stable version of an article for stopping vandalism. The editors have to switch to the desktop version in order for doing that.
Who would benefit: Editors who use mobile phones to edit.
Proposed solution: Have a restore this version button on top of the version of the article just like the desktop mode.
AMC is a good choice if the user has the rollback access and want to revert an edit, because AMC has a rollback link, but if the user has no access to the tool, they will still revert it manually, and manual revert on mobile and AMC are the same. Gadgets like Twinkle on mobile devices are very helpful. Ctrlwiki (talk) 05:51, 13 January 2022 (UTC)[reply]
@Ctrlwiki: But Twinkle is accessible only through the desktop site. We have to switch to desktop site again and again, which is difficult. Also using RedWarn is better than Twinkle CrafterNova (talk) 05:54, 13 January 2022 (UTC)[reply]
@CrafterNova: That's what I've said, if the Twinkle gadget can be used in mobile devices, it will be very helpful. Bacause, currently, Twinkle and RedWarn cannot be used on mobile devices, even if we switch from mobile to AMC. Ctrlwiki (talk) 06:53, 13 January 2022 (UTC)[reply]
@SGrabarczuk (WMF): Thank you, we will definitely try that, but hope that desktop functionalities are added to the mobile site as well. One more thing, I'm having problems in enabling Dark Mode from Extension:DarkMode. How to "place the file(s) in a directory called DarkMode in extensions/ folder and add the following code at the bottom of LocalSettings.php: wfLoadExtension( 'DarkMode' );" CrafterNova (talk) 05:56, 13 January 2022 (UTC)[reply]
I have been using AMC for more than a year, but as far as I'm aware, I don't think AMC currently has a button (by default) to let users restore version, even if the user has rollback right. But I can restore version on Wikidata on mobile web interface, which is a default option even without AMC. Sun8908 (talk) 10:26, 13 January 2022 (UTC)[reply]
A user with rollback rights can see rollback link if he will using AMC or Desktop view, you can't restore a revision using rollback of course, but you can do a manual revert using either mobile or advanced mobile. Twinkle and RedWarn has buttons that can revert and restore revisions but you can only do that on Desktop view. Ctrlwiki (talk) 10:38, 13 January 2022 (UTC)[reply]
Problem: Pour sourcer, le contributeur utilise par défaut le modèle proposé : "ouvrage". Celui-ci est à la fois trop compliqué pour une simple référence (ou citation) : plus de 105 champs ou critères, d'où un paragraphe "sources et références" pléthorique), mais incomplet pour établir une vraie fiche bibliographique (description) : un format basique (mise en page type folio, ou centimètres ?), tomaison défectueuse : on peut citer le tome 5 (= t. 5), mais pas décrire "5 tomes", parce que le t. se met automatiquement avant le chiffre), pas d'illustrations prévues.
Le modèle "Ouvrage" de Wikipedia semble inférieur aux modèles utilisés en bibliothèque ou en librairie.
Who would benefit: Tous ceux qui s'intéressent à la bibliographie.
Proposed solution: Arborescence des champs, indiquer ceux qui sont suffisants pour simplement citer [auteur, titre (abrégé), date, tome et page], et ceux nécessaires pour une description bibliographique complète. Ajouter des champs (et des conseils) pour le choix du format, l'illustration (dessin, litho, gravure, photo, etc.).
More comments: Lorsqu'on cite simplement une page d'un ouvrage, on n'a pas besoin d'indiquer tous les auteurs (s'ils sont plusieurs), le lieu de parution, l'éditeur, le nombre complet de pages, etc.
This appears to be a wish to change what is/not acceptable inside citation templates, which does not require work from the team but consensus at the local project instead. --Izno (talk) 21:02, 24 January 2022 (UTC)[reply]
Bonjour @Liberald:, merci pour votre contribution. Cette proposition nécessite de demander a votre communauté de modifier les modèles (templates) que vous utilisez. A ce titre, elle ne rentre malheureusement pas dans le cadre de projets que nous prenons en charge avec notre equipe. Merci encore pour votre participation. NAyoub (WMF) (talk) 03:27, 27 January 2022 (UTC)[reply]
Problem: search and replace box (editing iPad, classic view) is a really big help (as long as safari internal search removes all hits in the edit field - data loss may happen. we cannot wait until they fix that problem)! However the box should consume a minimum of display area!
Who would benefit: Editors
Proposed solution: Minimize distance between fields
More comments: The box seems to be available with IPad editing but not on Windows PC/NB, same user.
A search and replace function is already available when editing from a PC. If using the 2010 wikitext editor, click on Advanced and then click the icon. If you're using Visual Editor, click on and then choose "Find and Replace..." (or just hit Ctrl+F).
Hello, thanks for the answer. I sse the option now as in en as in de ("Erweitert") Version on PC. The obly remaining issue is that the box consumes unneccessary space, esp. on iPad. Hits are behind the box in most cases (however, the box has a see-thru property :-) ). Best wishes! --Ernsts (talk) 17:24, 17 January 2022 (UTC)[reply]
Problem: Error in judgement about translation skills. If I'm volunteering to post from Portuguese-to-English, I get a lot of requests to translate from English-to-Portuguese (which I am unable to do)
Who would benefit: Translators
Proposed solution: Treat both as separate skill-sets and qualifications.
Per above, you can do this now. Just consult with your community and someone should know how to adjust your citation templates if there's consensus for it. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 05:33, 27 January 2022 (UTC)[reply]
Problem:Es gibt bisher nur einen guten Viewer für 360*180-Panoramen. Andere Panoramen, insbesondere 360°-Panoramen mit extremen Seitenverhältnissen können nur schlecht interaktiv betrachtet werden, z.B. hier
Wem würde dieser Wunsch helfen: Panoramabildern mit extremen Seitenverhältnissern, die keine komplette Sphäre abbilden.
Lösungsvorschlag: Präsentationsmöglichkeiten wie etwa hier
@Milseburg: Have you tried ZoomViewer? Does this satisfy your need? Or would you like to bring something like ZoomViewer into Media Viewer so that it is part of the MediaWiki software?
I know these tools. They are getting a bit old and need an update. The controls should be improved so that you can zoom in and out with the mouse wheel. In addition, the image construction is a bit slow when scrolling. It would also be nice to be able to show and hide labels. That matches my other suggestion. Maybe you could merge them together. --Milseburg (talk) 10:57, 27 January 2022 (UTC)[reply]
Hello there, thanks so much for your proposal and for following up with the idea to merge the two ideas together. I found another proposal that references the painpoints around zooming and mouse so I we can count it as merged with that one since they are more similar in nature. Thanks so much! Hallo, vielen Dank für Ihren Vorschlag und dafür, dass Sie die Idee verfolgt haben, die beiden Ideen zusammenzuführen. Ich habe einen anderen Vorschlag gefunden, der sich auf die Painpoints rund um Zoomen und Maus bezieht, sodass wir ihn als mit diesem zusammengeführt zählen können, da sie in ihrer Natur ähnlicher sind. Vielen Dank! NRodriguez (WMF) (talk) 13:30, 27 January 2022 (UTC)[reply]
Allow interwiki links of Special namespace pages without Wikidata items
Problem: Some users are concerning if Wikidata should support Special namespace pages or not, to the best of my knowledge adding such links to any Wikidata items are the most bogus things of the Internet world, since such links are usually less focus and less traffic, except the Watchlist and login/logout-related, for most newbits.
The re-creation of Q105429923 (Q105429923) for Special:RecentChanges gave me one keystone reason to propose this, unlike the potential maintenancers of that item, I don't often visit this special page, as I have less interests on patroll works. However by such allowing links, such items could simply fact-to-face edit wars on the criterias of selections (as there are more and more concerns about links for closed wikis).
By focusing Wiktionary pages, I have a strong idea that if we can stop linking special pages, and stop creating items for em, by using an extension called Cognate to auto-prepare links for special pages on all wikis, not only Wiktionaries.
Who would benefit: No certain answer, though by asking me I would say every Wikidata editors
@Liuxinyu970226: Sorry if I'm missing the obvious here, but it sounds like you're proposing that Special pages be prevented from having Wikidata items, is that right? But also that they will be able to be interwiki-linked. Isn't that latter point already possible? Could you elaborate a bit on how the Cognate extension will help? Thanks — SWilson (WMF) (talk) 13:16, 17 January 2022 (UTC)[reply]
"But also that they will be able to be interwiki-linked." And any other pages are originally able, but how can such links be worked on every wikis? It's unable to see these sitelinks, even compacted, on Special:RecentChanges of every wiki, unable to see it on en:Special:RecentChanges, fr:Special:RecentChanges, tr:Special:RecentChanges, etc. Thus linking such pages are wasting of Wikidata users' times. The existing of Q105429923 looks partly good per d:WD:N (for structured statements purpose), but having links on the right of item interface are weird and bogus as they mostly can't work. Cognate, however, can and should provide such links for same purpose pages automatically to hold up future wasting of times on creating dummy items for special pages. PS: I heard that someone will against me because this will always populate several hundres of links on every special pages, so a configuration to triage such a function is also necessary via Special:Preferences. Liuxinyu970226 (talk) 14:03, 17 January 2022 (UTC)[reply]
@Liuxinyu970226:It's unable to see these sitelinks, even compacted, on Special:RecentChanges of every wiki Do you mean that the sitelinks for Special:RecentChanges are not listed in the sidebar? That's true, and as you say it's probably because every single other language would be listed there. Does your proposal include adding the sidebar list? having links on the right of item interface are weird and bogus as they mostly can't work I'm not sure I understand: the sitelinks on Q105429923 (Q105429923) work fine as far as I can see. I mean, I totally agree that it feels a bit redundant to have to define Wikidata items for special pages when we know for sure what they're called on every wiki and that they exist. SWilson (WMF) (talk) 05:46, 18 January 2022 (UTC)[reply]
Hello and thanks for taking the time to write this proposal. We are archiving this wish due to a lack of clarification. We needed clarification so that we could accept this wish and mark it for translation so that it could go into voting. Thanks again! Regards, LDelench (WMF) (talk) 13:54, 27 January 2022 (UTC)[reply]
Proposed solution: Links from mainspace to draft articles visible only to logged-in users
More comments: This is a difficult thing to explain, but I've noticed a conflict between two different philosophies of Wikipedia users. Users who want a Wikipedia that's analogous to a published encyclopedia, and users who see Wikipedia as a knowledge aggregation platform.
Users of the former group will tend to want to delete or draftify any article that does not meet a certain high standard of quality, while users of the latter group will tend to want articles in the mainspace so they can get more exposure to potential editors interested in the topic.
These two types of users seem to clash with each other a lot, I believe we could have a software solution to this though.
We could have a system where for users who opt in clicking on a red link with a draft article will automatically redirect them to the draft. Perhaps there can be draft links in articles that will only be visible to users who opt into this feature. Maybe links will be a new color like green to stand out to users who want to see them. These articles will serve the purpose of being visible to the knowledge aggregator users, while being hidden from the general public to help maintain the reputation of Wikipedia as a high-quality encyclopedia.
The current system already provides this after a first click. I don't think this would be a productive use of the tech team's time. --Izno (talk) 20:53, 18 January 2022 (UTC)[reply]
From what I can tell, the user is asking for red links to be blue if there is a draft namespace draft (after turning on some preference or another) and subsequently they can jump to the draft page. On English Wikipedia we have an edit notice that displays after you click the red link looking to see if there is a draft and the system finds that there is a redlink. So the user is essentially proposing a) to confuse some editors into thinking a page exists and b) to have a one-click instead of 2-click navigation.
I do not know if other wikis have either a) draft namespace pages and/or b) this editnotice system. Either way, the potential confusion for any editor seems like a clear negative. Izno (talk) 18:37, 19 January 2022 (UTC)[reply]
Dear @MaitreyaVaruna, thank you for your proposal! After talking to the Web team, who worried that the idea might be confusing some editors, we decided not to accept this wish since it's unlikely we will work on it. Also seeing the comments here lead us to the conclusion that we would like to see more community consensus, but we do really appreciate your thoughts and time. KSiebert (WMF) (talk) 14:15, 27 January 2022 (UTC)[reply]
This is a compromise between a fully collapsed TOC and a fully expanded one. As the TOC is important to get a quick first impression of the content and the size of the article. And for a quick navigation, of course. --Wickey (talk) 12:40, 12 January 2022 (UTC)[reply]
For the new Vector skin, the Reading team is/was user-testing a floating-TOC prototype at mw:Reading/Web/Desktop Improvements/Third prototype testing. Some of the feedback there has been a desire for manual collapse–expand buttons in addition to the persistent preference choices. It would be nice to have a consistent, multi-level collapse–expand across non-floating and floating TOCs in all skins. If this wish gets adopted, please don't ignore Minerva, Timeless, etc.! I would like an option to show just one level of headings (==) or two (== and ===). I can picture something like [ collapse all | less | more | expand all ], but it would be subordinate to the existing show/hide. Or instead of more–less, I suspect three fixed steps for [ 1 | 2 | + (all) ] would be better. Pelagic (talk) 02:19, 14 January 2022 (UTC)[reply]
Manual buttons would have the advantage that it always works. With every skin and for every reader who did not login (probably most readers). Wickey (talk) 11:36, 14 January 2022 (UTC)[reply]
that's great wish and I have good news there's a prototype which you can access through a browser extension, where you can try out a related TOC, it's currently being tested. You can find a little chevicon arrow icon on the complexer TOC that allow you to collapse parts of it. Also not the settings icon on some TOC to specify how you would like this to behave. Having these prototypes in mind, we will most likely archive this wish, if thats's ok with you?
NRequires community consensus/Does not require engineering resources
Problem: Design and provide a new home page for Chinese Wikinews that is beautiful and modern. The current appearance of Chinese Wikininews is very ugly. For example, the home page, or even the general news page. However, due to the small number of local community, there is no professional, so there has been no solution, hoping to create a more beautiful appearance in Chinese Wikininews.
Who would benefit: Chinese Wikinews readers, brand image and Chinese Wikinews local community, editors, users.
Proposed solution: Personally, I think the overall appearance of this site is a little ugly. At present, this Vector is a skin on this site. Personally, I think it is not suitable for a news website, and it seems a little ugly to use it as a news report. Suggestions can find some, or create some look more like news sites, and very beautiful appearance. For example, Timeless and use this as the default look for this site. Wikis have a variety of different looks and skins, and we can create a skin and a new homepage design that fits the look of a news site, such as the South China Morning Post. Anyway, I think we can have and create another look, and I personally think the current look is a little ugly. This will make the site look new and better than before.
Two comments. 1) Changing the skin among existing skins, or changing the home page, is a local community consensus needed and requires no technical investment. 2) If you want a whole new skin, I think that is outside CommTech's size/scope. --Izno (talk) 20:55, 18 January 2022 (UTC)[reply]
Hello Kitabc12345. Thank you for your proposal. Unfortunately, the Wikimedia Foundation doesn't build main pages for the communities. But that doesn't mean we don't have any ideas!
Would you be interested in asking the community to have the Desktop Improvements for all (logged in and out) as default? See how this very page looks like with the changes enabled. We are particularly interested in enabling this on large and mid-sized wikis, so mostly Wikipedias. Chinese Wikinews, although small, are an option, too.
Maybe some day (not before June 2022 and perhaps not before June 2023) we could build widgets that could be used on main pages. But that's not a promise. I only mention this to let you know that we are aware of such an idea.
You could check main pages of other wikis and reuse the code. This is not optimal but at least, it's possible right now.
The new skin is actually an interesting extension of my idea to make the site look better overall.
I hope to have a new home page, this is the local community to support the desire, because the original home page is not so modern, people are looking for a new design.
The desire for a new skin can be put on hold or shelved. I think the new skin will make the website look better, the original one was a little ugly, but in fact, it's ok to lose this one, thank you.
We'll see if the local community is willing to use Desktop Improvements.
The problem we ran into with the local homepage design desire was that the new homepage design of the local community users was ugly, so they had to go back to the original.
I tried to copy wikinews' homepage in other languages, but it was a huge project. No one in the busy real world does it anymore, because copying is messy. A lot of pages and code need to be created, which takes a lot of effort and time to translate, review, and copy. Kitabc12345 (talk) 09:56, 21 January 2022 (UTC)[reply]
Problem: On the mobile app, conversely to the web visuals of the page, the different parts of the article are unrolled… This makes the article less clear, because you can’t see at glance every part, and directly go to the one which interests you. It is also, in my opinion very pleasing to roll up a part you’ve finished reading, it feels like a job completed.
@Verturquoisee: Just to make sure: you are aware there is a floating table of contents on the app, right? You can see that by swiping from the right side. That's what I use to navigate. But regardless this wish is still valid, just wanted to clue you in on the TOC feature in case you weren't already aware of it. MusikAnimal (WMF) (talk) 22:49, 10 January 2022 (UTC)[reply]
There is also a button at the bottom right of the article giving access to that.. On iOS its just a button at the bottomleft and there is no swipe. —TheDJ (talk • contribs) 10:37, 13 January 2022 (UTC)[reply]
Oopsie very sorry, I do not go on meta very often, I got here thanks to a mail warning :p… I know this option exists, but I prefer the slide visuals on the web page, it feels way more satisfying. Sorry again for not responding. — The preceding unsigned comment was added by Vertuquoisee (talk) 18:40, 27 January 2022 (UTC)[reply]
Reading progress bars are great for blog posts and news articles, and you see them often on those sort of sites. They're great for the reader to know how much of the article is left, because there is an implicit assumption on those websites that readers will read (or at least skim) the majority of the article's content. With all that said, does that assumption exist on Wikipedia? I don't think it does. I don't think any significant percentage of readers actually reads whole articles. I believe the general user experience is to read the introduction only, maybe the sidebar, and maybe another section of interest. Thus, I don't think a reading progress bar is appropriate on Wikipedia, or any wiki. --//Lollipoplollipoplollipop::talk16:40, 12 January 2022 (UTC)[reply]
Perhaps this could be more relevant to Wikibooks than Wikipedia. I believe books on Wikibooks are supposed to be read through. One book there spans over multiple wiki pages, though. --whym (talk) 13:43, 18 January 2022 (UTC)[reply]
Problem: Site loading speed and visual pollution (velocidade de carregamento do site e poluição visual)
Who would benefit: users of low-cost devices and fast researchers (usuários de aparelhos de baixo custo e pesquisadores rápidos)
Proposed solution: Create an extension for google crhome or widget for windows for quick reading of articles. Containing button to "read full article" and "search". Without the need to access the encyclopedia's website (Criar uma extensão p/ chrome ou widget p/ windows para leitura rápida de artigos. Contendo um butão para "leitura do artigo completo" e "pesquisa". Dispensando a necessidade de acessar o site da enciclopédia)
More comments: Display text only, no presets and images, or just introduction similar to google search (exibir somente texto, sem predefinições e imagens, ou somente introdução semelhante na pesquisa do google)
Dear @Elilopes, we do think that is is an important cause for a proposal and when discussing it we actually realised that there is some tools existing that would help here. There's an offline wiki reader: https://www.kiwix.org/en/ but also there is only text browsers you could try out like http://lynx.invisible-island.net/ There is also a Text-Only Mode Chrome extension? Does that help, since a related functionality already exists, we will have to archive this wish. Thanks a lot for your suggestion! KSiebert (WMF) (talk) 18:28, 26 January 2022 (UTC)[reply]
How a Navbox would look like if tabs are integrated (Top: regular. Other: Navbox when different tabs are selected)
Who would benefit: Readers
Proposed solution: From a personal point of view, those accordion sections in the Navboxes are hideous and frankly, out-of-date. From a UX and UI point of view, tabs are way better when it comes to arranging content whether in Navboxes, tables or even infoboxes. Editors should at least have the option to choose between using accordion or tabs to cram large amounts of information in a tiny space. These tabs can be placed horizontally or vertically depending on the amount of content. EDIT: Not just Navboxes and infoboxes but also the body of an article as shown in the GIF.
Captured from another Wiki that integrates tabs in the article
I'm not sure what you mean. Is it not worth the engineering time or is it? Also, I edited the proposal so that tabs can be included in the articles themselves. This could come in handy when you have medium bits of information that are repetitive but related. For example, multiple teams within a certain contest. Omar.idma (talk) 08:01, 21 January 2022 (UTC)[reply]
There already templates with tabs in most of the wikis. Some more developed and nicer, others less developed and uglier. However, this is not a task for the Tech team, but rather aesthetic changes that can be done by editing the templates with the code editor within your home wiki(s). Xavier Dengra(MESSAGES)23:52, 21 January 2022 (UTC)[reply]
Drag and drop Contents items to re-arrange article
Problem: Re-arranging an article requires a lot of copy/paste which can be confusing
Who would benefit: Editors
Proposed solution: Instead of copy/pasting a sections of the article, a contents dialog window should be available to editors so they can simply drag the items or sections and re-arrange them as they like.
@Omar.idma: Have you tried VisualEditor? I believe this may be your only option. It is surely not worth the engineering effort to come up with a new visual editing system. If you had something else in mind, could you elaborate? I will also add that it should be possible to select a block of wikitext and click and drag it to another part of the wikitext, too, in case you weren't aware of that. MusikAnimal (WMF) (talk) 22:55, 20 January 2022 (UTC)[reply]
Problem: There are categories with many subcategories, like commons:Category:Mandelbrot sets. Sometimes I would like to see all images which are included in all subcategories on one page. I can't do it now.
Problem: Wikisource is an excellent tool for transcribing paper works online. However, a majority of online archives are newspapers and magazines and these media are significantly absent from Wikisource. Current transcription models can prove to be a real headache when it comes to transcribing newspaper or magazine articles, which discourages many from tackling them on Wikisource.
Who would benefit:
All editors on Wikisource
All users of Wikisource
Researchers
Proposed solution:
When a file is registered as a newspaper or magazine on Wikisource, the editing page should offer a different template of transcription.
The new template should allows the editor to have an interface that recreates the organization of chosen newspaper or magazine articles.
The creation of a "calendar" page which allows to locate the newspapers or magazines transcribed according to the year, the month and the day of their publication. To view an example of a calendar page, see this Gallica link.
More comments: Newspapers and magazines represent a wealth of information on thousands of subjects. These could be offered to all Wikisource users if only their transcription was made easier and more efficient.
Problem: When I add an image in an article, I have difficulties understanding where the image will land exactly in the article page in advance. I know I can select in the advanced mode "right, left, etc.". If I do, I often find myself editing the page again in a trial an error mode.
Who would benefit: Everyone adding an image.
Proposed solution: Add a "preview mode" once you add an image in an article. So, you know exactly in advance where the image will be displayed once you edit the page.
On English Wikipedia if you are editing the full page in Wikitext you get a preview of how the whole page will look when you click on preview. I assume your use case differs, so it would help if you could clarify. · · · Peter (Southwood)(talk): 18:49, 23 January 2022 (UTC)[reply]
Hello, My error! Indeed, I can use "review my changes" before publishing. And there is an option to "Report incorrect display for this change".
That just that the image won't be precisely where I want it to be (next to this or that part of the text, not just the whole paragraph). But I believe that it may not be solvable with mediawiki? Jurbop (talk) 07:31, 24 January 2022 (UTC)[reply]
With the new fixed width Vector design, the images will always fall in the place you decide, as the width doesn't change per user. Theklan (talk) 10:44, 24 January 2022 (UTC)[reply]
@Jurbop: You can preview your changes in both the Wikitext editor and VisualEditor. Hopefully the new Vector design will also help when placing images. You may also like to know that CommTech are working on a Real-time preview feature for the Wikitext editor. As there appears to be existing solutions to your problem, I am archiving this. Thanks for taking part in the survey. DWalden (WMF) (talk) 18:16, 27 January 2022 (UTC)[reply]
From the description, it sounds like Jurbop is using VisualEditor, and the problem they're having is when sometimes floated images don't show up in the same place they do after saving. phab:T68228 may be related. In the future, Jurbop, it would help if you gave a more specific example with step-by-step reproduction steps. Anyway, I agree with the decision to archive this proposal because I think your issue may eventually be fixed on its own. I'll explain: First, I do not think we will be able to introduce a "preview" mode into VisualEditor, because VisualEditor itself is supposed to be the preview. I believe the issue you have may be with mw:Parsoid (which is used by VisualEditor) and how it differs from the core parser. Once mw:Parsing/Parser Unification is complete, your issue may magically fix itself, since the rendering of wiki pages when reading will be the same rending used by VisualEditor. In the meantime, however, editing via wikitext and using the full page preview will give you a more accurate preview, so that is the only workaround we can offer at this time. Hope this helps, MusikAnimal (WMF) (talk) 18:28, 27 January 2022 (UTC)[reply]
Problem: I contribute all my images through the web interface of a smartphone. It is so incredibly tedious! See solutions for exact problems.
Who would benefit: Everybody who contributes files via the mobile website
Proposed solution: Per tab/step of upload:
Upload: Images are only cached when you upload them. When you take to long to add descriptions you can start all over again. SOLUTION: Server side cache that allows you to save edit steps
Choose a licence: I can say it's my own work or not. When I say it's my work and select a license I would have to edit the author name for each file. When I choose the other option the entered values are not saved between sessions. SOLUTION: Save values in between sessions or add the option for a template.
Description: A proposal for descriptions is located here. There is no easy way to fix the EXIF for all uploaded files (Example: The sh***y iPhone I have to use at work one was off by 6 days (yes, days) and 52 minutes. The EXIF is still wrong, but I am not able to manipulate every date at once) SOLUTION: An option that changes the timestamp of every image for a certain value (eg. 6 days, 0 hours and 52 minutes)
Wikidata Item: You have to search for the category and then for the Wikidata Item. SOLUTION: Suggest Wikidata Items based on the used categories. You have a tickbox to include them but you are able to search for more. If the file has GPS info, Wikidata items nearby could be suggested.
@Hangman'sDeath: Thanks for your proposal. At it stands, there are too many different proposals in one; would you be able to narrow it down to just one? There are a few things that I can think of that also might help in the workflow you talk about above: firstly, (if you're an Android user) have you tried the Commons app? It makes uploading from mobile very easy (but unfortunately isn't available for iOS). For the UploadWizard (which I'm assuming you're referring to above), note that you can set a default Author name (or template) and license via your preferences, and it'd not be useful to save other values as they change between uploads and should be confirmed in each new upload session. Batch-fixing incorrect times of photos sounds like it'd be a great proposal; maybe this could focus on that? Or as you say, having a stronger connection between the categories chosen on the Describe page and the Depicts statements on the following page would be great (or it could even work the other way around); that'd also be a good proposal on its own. Adding Depicts statements based on coordinates sounds like a brilliant idea too, and it could also be usefully done outside of the upload process. Anyway, sorry to write so much! It'd just be good to rework this to something smaller, so it can be voted on next week. What do you think? What is the most important part of this, to you? SWilson (WMF) (talk) 07:27, 26 January 2022 (UTC)[reply]
Problem: When using the machine translation service, a bug pops up after you try and translate an article that doesn't exist in English. When browsing the search bar for articles that don't exist in English, you might click an article that already has an article in English, and see a little yellow box pop up telling you it has an article. This is perfectly fine, but after you go on to an article that doesn't have an English form, the same little box will pop up again, even though there's no English equivalent. When you go on to try and translate the article, a warning is given that the English article already exists (and it doesn't). If you can translate from French you can try this by searching up Seconde Guerre mondiale and once they give you the box, proceed to visit an untranslated article such as the Régiment des Étrangers de Dunkerque.
Who would benefit: Editors who use the translation feature
Proposed solution: Fix the bug so the box does not work when you click on an untranslated page.
Agreed this just happened to me a few days ago - and I thought it was my mistake as I rarely translate pages, and it put me off doing so. Glad to know it is a bug. Should be easy to fix? Kaybeesquared (talk) 19:52, 10 January 2022 (UTC)[reply]
Problem: A lot of time has to be spent for fixing incompatibilities between templates in different languages (here: en to de, manual translation). Tried to use translation tools several times, never succeeeded, sorry. This consumes about as the same time as the proper translation (using web tools like DeepL, Google, Binf or Yandex depending on the languages).
Who would benefit: Translators
Proposed solution: Updateing templates in target languages to accept the current perameter list of the en template
More comments: esp. for referenceing templates - unwanted parameters in target lang may be ignored instead of generating a error
As a templating maintainer, I don't like the proposed solution, although I understand the problem itself. Probably, here we need a solution for mapping parameters of the same meaning in different languages. @Amire80, maybe you already have some solutions on this topic? — putnik18:03, 11 January 2022 (UTC)[reply]
There have been proposals for making templates working more globally (phab:T121470), this would definitely help in the translation process. Amir can add more to it, since he has been thinking about this area for a while. Pginer-WMF (talk) 09:40, 12 January 2022 (UTC)[reply]
I think we should keep a template globally, and have some local translations; however big changes must be announced to be able to get others to know about this change and to translate it. Thingofme (talk) 02:33, 22 January 2022 (UTC)[reply]
The english wikipedia uses en:Module:Check for unknown parameters to give an error if an template parameter is in use that is no longer supported. Finding those without it is a pain. I do not see this proposal as an proposal for global templates, although that does fix the problem aswell.--Snævar (talk) 19:28, 12 January 2022 (UTC)[reply]
Hi @Ernsts:, the concept of Global templates was declined in a previous survey, as it was simply too large of a project for our team. See our FAQ for more information on the scope of this survey. This proposal seems quite similar to this one: Global templates and modules, and would as such be considered a duplicate. NAyoub (WMF) (talk) 03:17, 27 January 2022 (UTC)[reply]
My idea was not to have global templates but to care for better compatibility between english and for instance — or better: especially — german templates. There are a lot of templates available in most languages but not in german. I ever wondered why. Thanks!--Ernsts (talk) 06:27, 27 January 2022 (UTC)[reply]
Problem: Flagged Suggestion In Wikidata When a potential issue is flagged against a property within an entry (because a property constraint has been set), unless the remedy is "quick and easy" people are less likely to do anything about it
Who would benefit: The whole community as the quality of data gets better
Proposed solution: That the "potential issue" or suggestion box as well as the existing "help" and "discuss" has a link that (using the data set with that problem property) will offer values it can add to remedy the situation or using its "search formatted URL" send them to a page that will supply the required information
After discussing this as a team, we concluded that it isn't feasible for the "potential issues" / suggestion box to recommend actual values. It unfortunately can't be generalized enough to infer what constraint needs fixing. For this reason we're going to archive this proposal. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 21:42, 27 January 2022 (UTC)[reply]
Hello! It is difficult to understand what you mean, but it sounds like you want to know which user groups a user belongs to, and have that displayed on their userpage. This is possible not something we'd want to enable for everyone by default. However there are many user scripts out there you can try. In particular I recommend en:w:User:Anomie/useridentifier.js. I hope this script works for you, and if not, maybe a developer on your wiki can make something for you that better suits your needs. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 21:49, 27 January 2022 (UTC)[reply]
مرحبا! من الصعب فهم ما تقصده ، ولكن يبدو أنك تريد معرفة مجموعات المستخدمين التي ينتمي إليها المستخدم ، وعرضها على صفحة المستخدم الخاصة بهم. هذا ممكن وليس شيئًا نرغب في تمكينه للجميع افتراضيًا. ومع ذلك ، هناك العديد من البرامج النصية للمستخدم التي يمكنك تجربتها. على وجه الخصوص أوصي بـ en:w:User:Anomie/useridentifier.js. آمل أن يعمل هذا البرنامج النصي من أجلك ، وإذا لم يكن الأمر كذلك ، فربما يمكن للمطور في ويكي الخاص بك أن يصنع لك شيئًا يناسب احتياجاتك بشكل أفضل. شكرا للمشاركة في الاستطلاع ، MusikAnimal (WMF) (talk) 21:49, 27 January 2022 (UTC)[reply]
Problem: The most important articles to a particular editor get lost in a big watchlist
Who would benefit: Editors who watch a lot of stuff
Proposed solution: Add the possibility to "favorite this article". A favorite article would be represented by a golden star where the blue star currently is. Favorite articles (or pages in general) would always appear at the top of the watchlist. A favorite page would also include all the other characteristics of a watched page.
Hi @Bageense:, thanks for your proposal. Per my understanding, you're asking to define a hierarchy of watched pages and it seems like the Multiple Watchlists proposal would also satisfy this use case. It might be complex to add another icon to the UI as there are already quite a few icons and that stars and already used as an icon on Minerva Neue pages while other skins say "watch".Would you mind if we merge your proposal with Multiple Watchlists? Please let us know, thanks! NAyoub (WMF) (talk) 03:46, 27 January 2022 (UTC)[reply]
Thank you for submitting this idea, @50829! I'm the product manager for the Growth team, and we'll be discussing your idea on this task. I'm glad to hear you've been trying the suggested edits feature. Please let us know any other feedback or thoughts you have. Do you think it is useful for newcomers? How does your community feel about the features on your wiki?
Problem: When looking for an article that is one out of many with almost the same name like e.g. "Roman Catholic Diocese of.....", it is necessary to write all these words before you get to the fifth word, where the names start to be different. Or, even if the name of the article is unique, it is necessary to write a long part of it to get to it in the search box, e. g. when you are looking for William Makepeace Thackeray you have to write "william mak" to get to his name in all the competing proposals starting with "William Ma-".
Who would benefit: Timesaver for everyone
Proposed solution: Searching by first letters: "r c d o p" instead of "Roman Catholic Diocese of Pittsburg", "w m t" instead of "William Makepeace Thackeray"
Hey Ivannah, this sounds like very a useful proposal, sadly it feels a bit like changing the way the search works will be more complex than we can do in wishlist cycle so we will move it to the bigger suggestions, if that's ok for you. KSiebert (WMF) (talk) 20:17, 22 January 2022 (UTC)[reply]
This is an interesting idea! I wanted to see how plausible it is to get the results you are looking for given only initials. You can do a very very rough approximation on titles using intitle: and regular expressions. I capitalize the first initial to encourage it to be at the beginning of a word, and required the other initials to follow a space. This isn't perfect because it doesn't require the first initial to start the title, it allows additional words after the match, and there will be occasional false hits (s s t would match NASA spinoff technologies). Because these are very expensive regular expression queries, they will always time out, so you don't get a consistent number of results, and ranking is fairly random since it isn't optimized for these kinds of queries. For William Makepeace Thackeray / w m t, my query is intitle:/W[^ ]* [Mm][^ ]* [Tt][^ ]*/ (no link because it is very expensive and I don't want the rest of the search team complaining that I crushed the servers by providing an easy-to-click link), which gets 73+ results. r c d o p gets 21+ results—all Roman Catholic Diocese of P..., though! Ruth Bader Ginsberg / r g b gets 45+ results. System of a Down / s o a d gets 26+ results. Shorter queries are much more ambiguous: George Clooney / g c gets 5300+ results. So, very roughly, for 3–4 initials, there is a 5–50% chance your desired result is in the top 10 results and would make it onto the suggestion list. Unless it is the most popular thing with those initials, it will not be the top item—and there can be a lot of competition—so you still may not notice it easily. From the back-end perspective, adding all of the initials to the suggester's index might be prohibitively expensive; I'm not sure. But it would definitely by a noticeable increase in the size of the index. Trey314159 (talk) 18:29, 24 January 2022 (UTC)[reply]
I'm going to be bold and conclude this is not just out of scope for our team, but a likely not going to be a priority for the Search team, either. Those who face the problem you describe will typically find their desired search result in the dropdown suggestions, or on the subsequent search page after submitting. It would be very challenging and expensive to index results by their initials for what is seemingly a narrow use-case. As mentioned above, Special:PrefixIndex is a workable solution for the "Roman Catholic Diocese of…" example, specifically. I'm sorry our response could not be more favorable, but we nonetheless thank you for taking the time to write this proposal. Regards, MusikAnimal (WMF) (talk) 03:15, 28 January 2022 (UTC)[reply]
Problem: Not able to write good papers/electronic publishing
Who would benefit: Newspaper journalists, students, anyone trying to write about a subject
Proposed solution: create an easy to use E-publishing WIKIPAPER
More comments: WIKIPAPER
It would be nice if Wikipedia made it so people can write an article or paper using the Wiki Markup Language and publish it to the web so people can link to it. I think this would drive more traffic to Wikipedia also. I used my sandbox to write an article for my website the other day and it works good [Sandbox article]. If people had 5 or 10 articles they could make in a document text editor or Source-code editor that would be dope. Maybe have a paid version for people or organizations to have Wikimedia host those articles. It would be a better version of Google Docs or other online publishing software like Medium (website), No one does a very good job of Electronic publishing yet.
Mediawiki is just to hard to even install and get going.
Larry Sanger is trying to get a blogosphere going or Encyclosphere for that reason.
I used my sandbox to write an article for my website the other day and it works good – please install MediaWiki for your website rather than using Wikipedia as a web host. ~~~~ User:1234qwer1234qwer4 (talk)10:35, 14 January 2022 (UTC)[reply]
We originally tossed this here in the Larger suggestions pile, but now that pile has grown to be very large! I'm afraid this one has little hope, and since it is strictly unrelated to Wikimedia – the focus of this Survey – I'm going to do a little bit of cleanup and move this to the Archives. Feel free to continue discussing there. As mentioned above, there are numerous MediaWiki hosting sites available for free. All you need to know is how to edit. Thanks for participating in the survey, nonetheless, MusikAnimal (WMF) (talk) 03:40, 28 January 2022 (UTC)[reply]
@Waren1: your proposed solution is unclear to me. What would you have them do differently to the current Visual Editor? How would this bring on board significant numbers of new editors (or, more likely, retain them) in a way that VE cannot? Nosebagbear (talk) 11:34, 24 January 2022 (UTC)[reply]
I suggest you find a solution. I repeat: VE did not justify itself, as it did not increase the number of authors in the Wikimedia project. Time is working against you. Hurry up. Waren1 (talk) 18:39, 24 January 2022 (UTC)[reply]
The Larger suggestions page is becoming too big to comfortably navigate. Since this proposal doesn't ask for anything concrete, I'm moving it to the archives. VisualEditor is the answer to "writing articles without code". Thanks for participating in the survey, nonetheless MusikAnimal (WMF) (talk) 03:44, 28 January 2022 (UTC)[reply]
More tools of using categories for analysis, diagnostics and target processing of pages
NProposes existing functionality / proposer did not respond
Problem:
1. For category A: ∀X: X is category & (X∈A or (∃Y: Y∈A & X∈Y)) => ∪X. It can be useful to have the ability to set the category nesting option for union.
2. For categories A and B: A∩B (page∈A & page∈B)
3. For categories A and B: A\B (page∈A & page∉B)
4. Add the ability to get not only category members, but all pages that have ever been members (were added). Possible in the form: name, date of inclusion in the category, date of exclusion from the category. It can be useful to have the ability to specify dates for filtering - inclusion after, exclusion befor etc.
5. Export of category list (all names; and for filters 1,2,3,4 too) as text file by single click for offline analise. Formats - plain, csv, json.
6. Change default mode for new categories (not having description page with "hiddencat" command) to hidden and add command like "visiblecat".
Who would benefit:
any wiki project with a large number of objects of the same type, for example *.wiktionary
Covered is not integrated, is not it? I'm talking about tools available right away, not as third party tools. If something has already been implemented, then there is a need, and the implementation method is not complicated. Va(🖋️)09:02, 16 January 2022 (UTC)[reply]
it is strange tool, that propose "Manual list"... of course, to get list of all pages in cat i can by JWB, in example small project it take 53 sec for 15188 copypastable names, intersection for 2 files i can make by command "comm -12 <(sort "file1") <(sort "file2") >file3", and file1-file2 i can make by command "comm -3 <(sort "file1") <file3 >file4", so for manual work i dont need toolforge. but i can work from different systems, so tool for cats directly in project may be very usefool. Va(🖋️)20:21, 16 January 2022 (UTC)[reply]
Hello Va, thank you for submitting the proposal. This is written in a really clear format, thanks for the excellent proposal. We reviewed it as a group, and we decided that while there are many strong ideas in here for independent proposals, what it is currently written like is too large for our team. Do you mind narrowing the focus of this proposal to the problem you think would be most important to focus on? From there, we can accept the proposal and let it go into voting. Regards NRodriguez (WMF) (talk) 00:13, 25 January 2022 (UTC)[reply]
@Vami It sounds like perhaps Petscan does what you need, except A-B (difference) of categories? Perhaps you'd be willing to reword your proposal to add that functionality to Petscan? I understand you would prefer this be integrated right into MediaWiki, but this is of course much easier said than done. Petscan is very popular and works well. It would be orders of magnitude easier to contribute to it than to build something new, and without doing some performance tests, there's no guarantee some of this functionality could feasibly live in MediaWiki anyway since in production database queries should be relatively fast. Let us know how you'd like to proceed. Thanks, MusikAnimal (WMF) (talk) 21:05, 25 January 2022 (UTC)[reply]
In the interest of time I'm going to go ahead and archive this, but we can unarchive before 18:00 UTC if we hear back and can come up with a compromise. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 03:54, 28 January 2022 (UTC)[reply]
@MusikAnimal (WMF) Ŝajnas, ke la propono ne kaŭzis intereson, ĉar la projektojn ne multaj personoj uzas kiel esplora rimedo. Do, jam ne gravas, ĉu mi respondis aŭ ne. Aldone pripensinte mi decidis, ke por miaj personaj bezonoj estos pli simple krei iun JS-aldonon. Ŝajnas, ke por tiu celo taŭgus iu parto de kodo de w:en:User:Joeytje50/JWB. Kaj, kompreneble, tio postulas studi (rememori) JS-on. () Ну, как-нибудь разберусь с божьей помощью. Спасибо за беспокойство! () Va(🖋️)07:26, 2 February 2022 (UTC)[reply]
Refine Search Specifications for Search not in this category - to exclude pdf
Problem: COMMONS Image Search "NOT in this category" delivers too many results, due to missing quotes and scanning texts of PDF and DjVu files
Example current search: Jan van Gool -incategory:"Jan_van_Gool" - delivers over 150 results
Improved search: JPG +"Jan van Gool" -incategory:"Jan_van_Gool" - delivers the right set of 8 results, note the quoted name to get exact results
Improved search trial 2: NOT pdf +"Jan van Gool" -incategory:"Jan_van_Gool" - delivers 10 results
Who would benefit: Categorizing large art collections, like drawings from different museum collections by creator
Proposed solution: Would it be possible to add the quotes by default and create an advanced search button to toggle include/exclude PDF files and DjVu files? Or search by filetype with checkboxes to include PNG, JPG and TIFF only.
@SWilson (WMF): On commons I open the Category:Jan van Gool and under topbar button "More" i click "Search not in category". To get just the right set of images i have to restate the search as :[ JPG "Jan van Gool" -incategory:"Jan_van_Gool" ]. Than I get a comprehensive overview of the few exactly right images and fragments of the text that often also show me the info "by ... / after ... / dedicated to ..." so these images can be added to the proper categories and subcats where they fit best. Thank you for showing me special image search but that seems neither not doing it surgically correct and does not show me any textinfo in the overview, plus it does not pop up my Cat-a-lot tool. It's not about finding plenty of images that are faintly related like Roger+van+Gool but to find exact results like "Jan van Gool"+jpg -incategory:"Jan_van_Gool". I think most important improvement would be to by default add quotes around the searchkey. - I moreover would desire the possibility to exclude all and any subfolders of cat:Jan van Gool. But that might be asking to much, so sometimes I try it with double -incat statements. Note: only for purpose of this experiment the search results are kept "as is" and not further processed, the goal of the effort would be to copy/move each of these nine files to the proper cat and subcat of Jan van Gool. And result of renewed search will be 0 items, to know job is done. (My search prefs in commons are 'exact' and 'standard' enabled.) Peli (talk) 11:15, 26 January 2022 (UTC)[reply]
@Pelikana: Ah! That makes sense — this is about the searchnotincat gadget! Sorry, I didn't have it enabled so didn't recognise the "Search not in category" label. Adding quotes around the search term (page title) should be a simple fix. I've left a note on the technical Village Pump asking about this change. To also remove files in subcategories from the search, does the following search work? "Jan van Gool" -deepcat:"Jan_van_Gool"SWilson (WMF) (talk) 01:18, 27 January 2022 (UTC)[reply]
HEY, ONE WARNINGI am brazilian and I no written in english some times. I´ts easily find sepalling mistakes here.
Propose Idea: News styles of words for highlight, as, but not limited to, calibri light (The normal word style for titles of Microsoft Word)
Who would benefit: Good, the Simple English Wikipedia, given tath ares for students and people learning to read, and articles as Bad Jokes and Other Deleted nosense, than are for fun.
Sorry it took us so long to get back to you. We're about 12 hours away from the voting phase starting, and this proposal is rather unclear, so we're going to have to archive it. Thanks for participating, nonetheless! Reminder that next time, you can propose in your own language :)
Desculpe por termos demorado tanto para lhe retornar. Estamos a cerca de 12 horas do início da fase de votação, e essa proposta não é clara, então teremos que arquivá-la. Obrigado por participar, mesmo assim! Lembre-se de que da próxima vez, você pode propor em seu próprio idioma :) MusikAnimal (WMF) (talk) 04:21, 28 January 2022 (UTC)[reply]
Problem: excepted with the exact target (title or username) as far I now it is not possible to search within the deletion log
Who would benefit: every one
Proposed solution:
to developp Special:Log in order to have the possibility to show all the deleted content using key words
or to developp the current search engine CirrusSearch with a new filter function "search in: deletion log"
More comments: One precise exemple: this simple search [2] with two words (now not displaying anymore any results) allowed me to find several dozen of files within Wikimedia Commons, to delete those files, and to blocks the uploaders (sock puppets). With that querry made by a colleague, showing all the deleted files that contains "Kris_Kourtis" in the titles, showing the deleted administrators, and showing the uploaders, I have been able to find 6 or 7 additional sock puppets and to find additional content to delete. If such a functionality already exist for the Wikimedia projects I would be happy to know it, otherwise I think it should a good thing to have it without to have to go outside the Wikimedia projects to make requests which requires having accounts in the places where it is necessary, ect...
Very great, thanks you... and for the second time...:). I'm glad I learned something. A possibility to see, within the results list, the name of the creator and the name of the administrator (without to have to click on the fike name) would be great, if the technical staff can do it I would not be against. Christian Ferrer (talk) 11:53, 21 January 2022 (UTC)[reply]
I think some deleted contributions and pages should be made viewable to the public, to see what page a vandalized user has created. Thingofme (talk) 08:26, 21 January 2022 (UTC)[reply]
Per above, the primary ask here is already available at Special:Undelete. Showing the original author and deleting admin is something we can add easily with a user script. I think it would be pretty simple to add in MediaWiki, too... but it doesn't seem like enough work to warrant going through the survey. I think making a task on Phabricator would be the best route. Regardless, we thank you for participating in the survey! MusikAnimal (WMF) (talk) 04:38, 28 January 2022 (UTC)[reply]
Let "VE toolbar" request ArchiveBOT save Citation URL at Archive.org, if fail then Archive.is, if fail then GhostArchive
The workflow I am thinking of is: user fills in citation, adds it to the article, later, BOT adds oldest archived instance, or makes new archive and adds it to citation in article. LAZY="automate mindless task to reduce errors by implimenting software tools". By the way, meta.wikimedia.org should have Edit summary pick-lists like en.wikipedia.org. ....0mtwb9gd5wx (talk) 16:06, 12 January 2022 (UTC)[reply]
Most of the Internet Archive is captured by automatic crawling, not manual submission. One of the sources for Internet Archive automatic crawling, is Wikipedia and our external links. IA has a program known as "NoMore404", which monitors Wikipedia edits in real-time, extracts external links, and generally archives those within 24 hours (after a short delay and some filtering, e.g. links that are already archived). There is also InternetArchiveBot, which is another way to ensure links are archived, e.g. if the automatic crawl missed them. And there are also automatic crawls from Wikipedia to Internet Archive based on monthly Wikipedia dumps. For example, see this archive.org entry which shows at least three Wikipedia-related sources were used to automatically capture this URL from the w:Banana article. Refer to Wikipedia:Link rot for more information. --Krinkle (talk) 18:47, 12 January 2022 (UTC)[reply]
@0mtwb9gd5wx: External URLs in wikis are already archived with the Wayback Machine as mentioned above. This doesn't happen immediately when a page is saved, and not all links are necessarily archive-able (some take action to prevent it), but for the most part it's a pretty great system. Would you like to re-scope this proposal to be about adding additional archive sites (Archive.is, GhostArchive.org — or something else), or should we archive this proposal? (Not to overload the term 'archive' or anything!) SWilson (WMF) (talk) 04:10, 19 January 2022 (UTC)[reply]
@SWilson (WMF):@Krinkle:@Thingofme: I have not seen NoMore404 demonstrate such behavior, InternetArchiveBot does a small amount, there are many citations without archive-url. Tagging a citation seems a way to improve efficiency. EXPAND: Archive.is does a better job of archiving pages that depend on javascript and XHR use it if Archive.org fails. GhostArchive.org might archive pages banned by Archive.org use it if Archive.org refuses, or use it if Archive.is fails. It seems Google also monitors Wikipedia edits in real-time also. .... 0mtwb9gd5wx (talk) 13:38, 19 January 2022 (UTC)[reply]
This was proposed in 2016 and we declined it in favor of InternetArchiveBot. Archiving as soon as links are added I don't think is something we can offer. For now I'm going to move this into the Survey's archives because it re-proposes something we declined in the past, but we might be able to move this back. MusikAnimal (WMF) (talk) 16:55, 28 January 2022 (UTC)[reply]
Unregistered users need to complete a CAPTCHA for creating an account, but people with low vision can't do it. Projects have to be accessible to everyone, that's why an alternative is needed. LD (talk) 12:51, 1 February 2022 (UTC)[reply]
Incomplete proposal / On roadmap of another team
_on_the_edge_of_Fairwood_and_Woodmore_in_Prince_George%27s_County,_Maryland.jpg)
Noé (talk) 09:20, 16 January 2022 (UTC)
Support The most important, IMO. --Yann (talk) 13:12, 29 January 2022 (UTC)
Strong support — ElioPrrl (talk) 15:38, 29 January 2022 (UTC)
icon. If you're using Visual Editor, click on 
and then choose "Find and Replace..." (or just hit Ctrl+F).
)
) Ну, как-нибудь разберусь с божьей помощью. Спасибо за беспокойство! (
Neutral But, what's the alternative? How can anyone evaluate a proposal of "something else". -- Kace7 (talk) 20:00, 3 February 2022 (UTC)
Comment This proposal was created after deadline (January 23th), therefore it cannot be part of the survey. --Matěj Suchánek (talk) 12:40, 4 February 2022 (UTC)
.jpg){kind=link}