Community Wishlist Survey/Sandbox

Add topic
From Meta, a Wikimedia project coordination wiki

Welcome to the sandbox

On this page, you can note your early ideas for wishes. This way, you will not forget about these before the next Community Wishlist Survey begins. You can come back and refine your ideas any time.

  • Ideas added here do NOT count as wishes for the Survey.
  • We discourage from adding such templates as support or oppose. These do NOT count as votes.
  • The Community Tech team will NOT approve or decline any ideas added here.

Ideas for wishes

User list(s) of Community Wishlist Survey[edit]

Refine "What links here" to distinguish links from templates[edit]

If I'm considering moving a page to a better title, I look at "What links here" to see the implications of the move. Sometimes there are vast numbers of links, but almost all are from one or few navbox templates which appear on many pages, so that the number of changes needed will really be very small. It would be helpful if that listing could distinguish links which are from templates. I wonder if this would be possible, or whether technical issues make it impractical? PamD (talk) 07:10, 7 September 2021 (UTC)Reply

This would be great for many use cases, if technically feasible. Even when looking at transclusions, it would be nice to be able to find direct transclusions only. Maybe there's even some toolforge service for this kind of advanced filtering? MarioGom (talk) 19:59, 8 September 2021 (UTC)Reply
YES - point in not distinguishing links per namespace. Also does not seem too complex. --Zblace (talk) 04:19, 11 December 2021 (UTC)Reply
Similar propositions:
-- Pols12 (talk) 15:35, 5 January 2022 (UTC)Reply
This idea came 6th in 2022 and was raised as phab:T301648 but doesn't seem to be moving quickly yet. Certes (talk) 13:47, 13 December 2022 (UTC)Reply
Not yet a vote, but I would support marking links from templates differently from direct transclusions.ShakespeareFan00 (talk) 12:22, 20 January 2023 (UTC)Reply

Not just 1-to-1 link on Wikidata[edit]

Currently, each wikidata entry, representing a concept, are only allowed to link 1 article per each wikipedia, and each wikipedia article can only be allowed to correspond to 1 wikidata entry

But due to various reasons, including variation between different languages, 1 concept might be represented with multiple articles in some language Wikipedia, while in other cases 1 article might be representing multiple concepts.

And then there are also Wikipedia written in languages in multiple scripts, that are unable to convert mechanically and thus require individual articles for each concepts.

They currently cannot be linked to wikidata normally, and require-pre-wikidata-era interwiki links to provide inter-language linking, and creating wikidata items that are completely duplicate of other existing items.

This should not be the way it work and thus should be modified. C933103 (talk) 04:10, 8 September 2021 (UTC)Reply

Wikipedia redirects can now be linked to Wikidata items, if you know how, which addresses some but not all of this request. Certes (talk) 13:50, 13 December 2022 (UTC)Reply

Enable Wikiprojects renaming[edit]

From at least year 2006, a number of wikipedia and other wikiprojects have been trying to change their language code. However, even after more than 1.5 decades, due to a number of technical roadblocks, this is not currently possible, and the only site that have gone through such process, from be-x-old to be-tarask, is under a perpetual state of technical issues, for example Content Translation tool still fail to function properly for the wiki due to the change in code.

In order to fix the editing environment and to correct the name and language codes of all the wikis being affected, it is necessary to clear all technical roadblock, which have existed for more than a decade already.

Examples of affected site (While most of the following used Wikipedia URL as example, other non-wikipedia sites for these languages are also being affected, and in some cases are also blocking the creation of new projects for these languages due to intention to avoid related technical troubles)

  1. was renamed
  2. There are petition to rename into , so as to reflect the site's language being Norwegian Bokmål
  3. should be changed to, in order to reflect it is a Wikipedia for Simple English, and comply with the language tagging standard
  4. Serbo-Croatian Wikipedia currently use a language code sh. But the language code have been invalid since year 2000. The language code for the language is now hbs and proposal have been made to move the wiki to accordingly.
  5. Classical Chinese Wikipedia, currently located at, have its own language code lzh, so it have been suggested to move to
  6. Cantonese Wikipedia,, being described as Wikipedia for a variant of Chinese speaking in Guangdong, Guangxi, Hong Kong, Macau, and in diaspora around the world, is usually considered a language, and have its ISO language code "yue" Thus proposal have been made to remove the "zh-" and just use the standard language code for the wikipedia's URL, turning it into
  7. Min Nan Wikipedia, aka the Wikipedia for Minnanese and Taiwanese, is now located at, due to the way tsome classify the language. However, the language have an official language code "nan", and proposal have been made to move the site to, accordingly.
  8. Swiss German Wikipedia, which have been placed under, have since year 2005 received official language code "gsw", and is thus desirable to change the wiki's link to
  9. Syriac Wikipedia, is now currently working under another name of Aramaic Wikipedia, at, which is an historical language which have disappeared long ago, and is not the language of the project. It would be favorable to change its name to Syriac Wikipedia and change its link to, to properly reflect the language used in the Wikipedia.
  10. Norman language from Normandy is now having a wikipedia at Yet "nrm" is actually a language code for Narom language from Malaysia. Hence it have been proposed to change the wiki's URL from to to reflect the correct language code for the Norman language.
  11. The Wikipedia for Emilian language from Italy, currently located at, is actually using the old language code for the combined "Emilian-Romagnol language". As the language code have been separated and Emilian language is encoded as "egl", it have been proposed to change the link to, although there are also opinion against such change
  12. Võro language from Estonia, as part of the Finno-Ugrian languages, now have their Wikipedia at Since the language received its own language code in 2009 as "vro", it have been desired tom move the site to
  13. Currently, is used by Wikipedia of Bhojpuri language in the Bihari languages group from India. Yet the language code "bh" have been deprecated, separating into individual language codes for each language, with Bhojpuri having the code "bho", and thus proposal have been made to move the wiki to, to avoid confusion with other Bihari languages.
  14. is the URL for Wikipedia in Zamboangueño dialect of Chavacano language. As the dialect have been said as the only living version of the language from the Philippines, proposal have been made to move it directly to representing the language.
  15. The Wikipedia for the Eastern Baltic language of Samogitian, have received its own language code "sgs", and thus proposal have been made to move the wiki's location from the current location of to
  16. Aromanian Wikipedia, is currently located at, with rup representing Aromanian language roa supposedly mean "Other romance languages", which is meaningless, and thus should be moved to simply
  17. Currently, there is an "Old Wikisource" located at It have been proposed to rename it as Multilingual Wikisource and be moved to, to better reflect its nature of collecting text in multiple languages that don't have their own wikisource projects.

All of the above moving/renaming have been blocked for up to 16 years as of 2022 due to various bugs in the MediaWiki software. Fixing them would have helped users of all these wikis by able to associate their language and their language code to the wiki sites they use appropriately.C933103 (talk) 06:35, 8 September 2021 (UTC)Reply

Asking here would be more nonsense than useful, since this is already mentioned via Limits_to_configuration_changes#Changes_that_are_likely_to_be_stalled,_though_not_declined, also as Krenair mentioned elsewhere, renaming of a database name would not be possible due to the MediaWiki compatible requirements. --Liuxinyu970226 (talk) 04:18, 10 September 2021 (UTC)Reply
It is not the first time a similar proposal was submitted to community wishlist, and last time I get a response that there are some technical roadblock that can indeed be helped by community tech team.C933103 (talk) 20:24, 10 September 2021 (UTC)Reply
Pardon my limited knowledge on the issue. But isn't there a much easier way to do this? Let's say foo.wikipedia has to be changed to bar.wikipedia . Instead of changing the code from one to another, we make foo.wikipedia read-only for a day or two. foo.wikipedia's entire database is extracted which contains all pages and page history. A separate wiki (fork) is created at bar.wikipedia with that database dump. Forks don't have any specific technical issues afaik. Now, the foo.wikipedia domain is permanently redirected to bar.wikipedia and all old data erased. Editing is resumed at bar.wikipedia. How is this not feasible? Why use the hard way when this easier alternative is available? —‍CX Zoom (A/अ/অ) (let's talk|contribs) 08:22, 18 December 2022 (UTC)Reply
@CX Zoom: You might want to take a look at the pontential issues with the approach you described here: phab:T30441#6213240, phab:T30441#6214672 H78c67c (talk) 06:52, 16 January 2023 (UTC)Reply

Wikibase for Wikiquote[edit]

The wikiquote project would gain in simplicity if the citations were stored in a wikibase. A translation of the quotation in each language would be easier, and the feeding of this database would be simpler.

There would be no need for a lot of properties to describe the quotations, author, language of the quotation, text of the quotation, language of the translation text of the translation, source, context of the quotation, date of the quotation. The difficulty will surely be to create the contribution interface and to succeed in describing the source of the citation.

Koreller (talk) 19:44, 8 September 2021 (UTC)Reply

Smart idea! Worth the effort for sure. --Zblace (talk) 04:24, 11 December 2021 (UTC)Reply

SEO Optimization.[edit]

Sites like WIkiwands which aggregate WIkipedia content and then represent them to readers are frequently spotted on search engine result at about as high or sometime higher place than Wikipedia itself. While it's nothing og fault to have Wikipedia content rehosted and represent in different style as long as copyright and content origin are properly represented, increased readership on third party sites instead of Wikipedia itself could have a potential of leading to less chance of attracting readers into contributing to Wikipedia since those third party sites usually don't have as obvious direct link to let readers contribute to Wikipedia when they see something isn't properly written, and in the long term it could lead to a reduction in number of new Wikipedia editors and could be bad to the long term suvival of the project. Wikipedia the site itself, together with other wikiproject sites, can probably use better SEO, so that readers are attracted to read Wiki content on sites directly managed under WMF which also provide clear guidance toward new user on how to help and contribute to the project and have the potential to attract more editors in the long run.C933103 (talk) 10:46, 15 September 2021 (UTC)Reply

Looking at the interest group and the website itself(, I think the wikipedia mobile UI is at fault. Better UI longer retention time+less bounce --> higher SEO rank. Wikipedia seriously needs to upgrade it's mobile experience, mobile should be the main focus. Greatder (talk) 16:20, 10 November 2021 (UTC)Reply
The site you linked currently claim Wikipedia have a bit higher retention time than wikiwand. But one interesting thing is that the site also claim most traffic from another site to wikiwand are from wikipedia? C933103 (talk) 12:25, 16 January 2022 (UTC)Reply

Fix ListeriaBot memory issues[edit]

ListeriaBot is used to automatically maintain lists of Wikidata items in various Wikipedias. It is used intensively by Women in Red in various languages, as well as other projects (3,204 lists in English, 1,152 in French).

Since the release of ListeriaBot v2, there is a problem with lists with many links to big entities (for example, links to countries), which make the list generation fail. See some previous discussions: 1, 2.

The issue is reported in the official repository: magnusmanske/listeria_rs#66. --MarioGom (talk) 17:49, 15 September 2021 (UTC)Reply

Add Thank Button by Default to Watchlists and Recent Changes[edit]

We have a lot of scholarly evidence that the Thank feature improves the general social dynamic on our Wikis, for example, this recent paper, summarized here. However, the thanks button right now in the default interface is living only in the history page of articles, not in many of the places where experienced editors interact with diffs (watchlists, recent changes feeds, etc). There is a user script on English Wikipedia that implements a thanks feature in other feeds ( see ) but this is a super hidden feature -- and for most wikis, having to configure a script is too high of a technical threshold for most users, especially the ones we want to interact with other users: newbies. The number of newbies looking at individual history pages, is miniscule.Sadads (talk) 23:09, 7 October 2021 (UTC)Reply

Good idea. --Zblace (talk) 04:28, 11 December 2021 (UTC)Reply
It could be enabled locally as a Gadget (maybe by default?). Qwerfjkl (talk) 19:04, 29 December 2021 (UTC)Reply
This does not seem like an issue concerning only a local wiki. ~~~~
User:1234qwer1234qwer4 (talk)
20:56, 29 January 2022 (UTC)Reply
Good idea. I've implemented this locally using TamperMonkey but official support would be better. More controversially, add an undo link too, perhaps disabled by default to deter abuse but selectable in preferences. An argument against is one should view the edit before thanking (or undoing); the refutation is that I use Popups. Certes (talk) 13:54, 13 December 2022 (UTC)Reply

Add a single template with dropdowns to easily add words in Wiktionary[edit]

When adding a word on bn.wiktionary I just add meaning, parts of speech, language. I would like a straightforward way to do this, without remembering all the templates, special structures. This will also encourage new contributors to add words easily. Greatder (talk) 16:24, 10 November 2021 (UTC)Reply

new home page for Chinese Wikinews[edit]

Design and provide a new home page for Chinese Wikinews that is beautiful and modern.--Kitabc12345 (talk) 14:01, 20 November 2021 (UTC)Reply

@Kitabc12345: Main pages are maintained by that site's editing community. Community wishlist team can't help with that. If you want to design a beautiful and modern home page, you need to create appropriate css/html code. You can look at other wiki's main pages for inspiration. —‍CX Zoom (A/अ/অ) (let's talk|contribs) 08:26, 18 December 2022 (UTC)Reply

Centralized incident/problem management and tracking for WMF production[edit]

We currently use phabricator for bug tracking, feature requests, and other items. A common scenario is that contributors from a WMF project finds something malfunctioning - this may be occurring simultaneously on multiple WMF projects. What happens next: one or more phabricator tasks get opened, reporting instances - this works OK, and bug wranglers will merge duplicate reports. Next, if confirmed someone may decide to work on the problem. A common scenario is that the problem is code in need of improvement, and someone working on it may create some new code, and the new code may be released. At this point all of the tracking comes to an end - however notably this does not mean that from the point of view of the original reporters that their actual production problem is resolved. Why - because that doesn't mean that WMF servers are actually running the new code, and it certainly doesn't mean that resolution acceptance in production has occurred. What is lacking here? Tracking of the actual incident and/or problem from report to resolution. Additionally, no information about the priority (the impact and urgency) of the incident or problem is gathered (a priority field that can be misleading is tracked, but this is the priority that software developers are declaring). The primary place that incident tracking may be occurring is on disparate wiki pages across all projects. So what is lacking: A process and system to manage and track actual incident reports. This could be phabricator, however this is going to require more of a human element and mindset improvement than just technology. Should this be a call to help to the volunteer community - a call to help to ask WMF to assign some of this "service desk" functions to staff - not sure right now (still sandboxing) - any idea welcome below! — xaosflux Talk 12:03, 23 November 2021 (UTC)Reply

I think phabricator needs a bot that makes an edit to tasks that have an merged change (that is not an cherry-pick) and where the task has been closed, mentioning when the change will be deployed. There can be multiple patches per task, so submitting for each one of them would not be helpful. Cherry-picks are changes that have been picked for deployment, and are often deployed ahead of the train of deployments, they often also specify when the deployment has been made. Snævar (talk) 20:22, 21 January 2023 (UTC)Reply
What about modifying gerritbot to include the estimated deployment date in the message about merging the patch? While this is not 100% reliable (the train can be cancelled, blocked etc.), it should be correct in most cases. Additional messages after the change has actually been deployed spam Phabricator, even in cases where everyone interested perfectly knows the timeline (which I think means the majority of tickets). Or enhance the Gerrit changes table to include the first train branch it was included in (if there’s any), linking to a page (e.g. on Toolforge) that explains when that particular patch was installed on which wiki – this wouldn’t predict anything before the branch cut, nor would it be sent out in notification emails, but it would be 100% reliable without spamming users. —Tacsipacsi (talk) 17:32, 22 January 2023 (UTC)Reply

Improve move logs[edit]

phab:T66184 / phab:T152829 -- in short, make the move log better, including indexing it by the target page(s). — xaosflux Talk 16:42, 29 December 2021 (UTC)Reply

This would be immensely useful, especially for people like myself who often cleanup spam – lots of spammers will recreate deleted pages by moving an account's sandbox to the (deleted) article's location, and should that article get deleted again, it's basically impossible to find out who made it (since page creation logs don't move with the page, and the move log doesn't show the origin). This would be great to see happen. Giraffer (talk) 17:57, 6 January 2022 (UTC)Reply
+1 to Giraffer and Xaosflux. —‍CX Zoom (A/अ/অ) (let's talk|contribs) 08:30, 18 December 2022 (UTC)Reply
Comment Code review appreciated at 762102: Allow searching the move log by destination title! A PatchDemo instance for this patch exists at to assist — TheresNoTime (talk • they/them) 03:38, 25 January 2023 (UTC)Reply

Computer-aided document authoring[edit]

MediaWiki software could support and interoperate with an extensible set of server-side document-processing tools. The outputs of these tools can be represented as annotations. These output annotations can be merged, aggregated, and presented to end-users as they edit, view, or view more information about wiki documents.

As envisioned, there are two flavors of server-side document-processing tools.

Firstly, server-side document-processing tools can be of use for computer programming languages. Tools, in these regards, include parsers and compilers which can output annotations such as informational, warning, and error messages about portions of source code.

Secondly, server-side document-processing tools can be of use for natural languages. Tools, in these regards, include: spellchecking, grammar checking, readability analysis, sentiment analysis, analysis of subjectivity and objectivity, fact-checking, reasoning checking, and argument verification and validation.

Were MediaWiki to support an extensible set of server-side document processing tools, this could result in a new type of extension.

Some benefits of enhancing computer-aided document authoring are indicated:

Wikifunctions. This project could be enhanced with the first flavor of server-side document-processing tools, wrappers for various server-side parsers and compilers, e.g., Python.

Wikipedia and Wikinews. These projects could be enhanced with the second flavor of server-side document-processing tools, natural-language processing tools.

Downstream projects. Users of MediaWiki software would be able to create new solutions with MediaWiki and related extensions should MediaWiki come to support enhanced computer-aided document authoring.

More discussion about computer-aided document authoring is available here: Wikianswers/Technical_discussion/Computer-aided_document_authoring. AdamSobieski (talk) 02:58, 30 December 2021 (UTC)Reply

Spoken articles[edit]

Attempts to make Wikimedia articles spoken have failed or the number of audios compared to the number of articles is negligible.

Therefore, one of the possible ways to expand and improve this idea is to make software that reads (with pre-established rulesª) the text of articles in all Wikimedia projects in all languages, thus making it possible for people to choose to listen or read, notice misspellings more easily to fix them and the visually impaired can benefit from this.

ª - Rules such as: "Read: '{{Article name}}, in Wikipedia, the free encyclopedia at'" / "ignore sections 'See also', 'Notes' 'References', ' Futher reading', etc. "... --N4CH77 (talk) 01:32, 9 January 2022 (UTC)Reply

You might find interesting pronunciation lexicons for XHTML and SSML attributes in XHTML. There could be wiki syntax, possibly templates, for listing pronunciations which could be aggregated into pronunciation lexicon resources referenced with document metadata. There could also be one or more wiki templates for rendering XHTML spans with SSML attributes. As for which document content to synthesize, this could also be done using cascading stylesheets using the CSS Speech Module, specifically the speak property. AdamSobieski (talk) 11:09, 10 January 2022 (UTC)Reply
Bluerasberry (talk) 18:46, 5 January 2023 (UTC)Reply

Improve the talk pages to be more in line with the article pages[edit]

Problem: Wikipedia talk pages are pretty painful to use when there is a large discussion going on. While novel to use at first, getting anything done while using these pages is a bit of an issue.

Solution: Personally, I would prefer if there was a small editable space at the top of the page for applying tags and the rest of the page was like the app. At the very least, there needs to be a better system than indenting with mark-up. I think it would help newbies navigate the site a lot easier, and might make archives redundant. Also, I think new topics should be at the top.

Suggestion by --TiggyTheTerrible (talk) 19:13, 10 January 2022 (UTC)Reply

@TiggyTheTerrible This is the sandbox page, not the actual survey. But no need to create a proposal, because the problems you're describing are/have already been worked on. See mw:Talk pages project. Thanks for the suggestions, anyway! MusikAnimal (WMF) (talk) 19:38, 10 January 2022 (UTC)Reply
Ah okay! Thank you! TiggyTheTerrible (talk) 10:18, 12 January 2022 (UTC)Reply

Limit Special Prefix subpage level[edit]

I would like to add a parameter "level=1" to the Special:PrefixIndex to e.g. limit the list to the first level (main subpages); level=2 would also show the sub-subpages, etc. When there are too many sublevels an unrestricted subpage list confuses the users. Then we could have the same list generating statement on the next sublevel, etc. making it more easy to easily navigate through subpages.

Example: {{Special:PrefixIndex/{{FULLPAGENAME}}/|stripprefix=1|level=1}} Geert Van Pamel (WMBE) (talk) 15:38, 27 January 2022 (UTC)Reply

This proposal is mentioned in task T9184 (dates from 2006!) but it is totally unclear to me if this was ever implemented? Geert Van Pamel (WMBE) (talk) 16:20, 16 February 2022 (UTC)Reply

Wikimedia Commons Upload wizard default languages[edit]

When uploading a media file, the Wikimedia Commons Upload wizard should propose all languages as per the user's #Babel box, so that entering the labels and the short description is just clicking and typing instead of adding each of the other user languages. Geert Van Pamel (WMBE) (talk) 09:19, 15 February 2022 (UTC)Reply

@Geertivp: This looks like a minor and unlikely-to-be-controversial change. You might propose it on Phabricator and have it implemented in way less than a year, when the next survey will be conducted. —Tacsipacsi (talk) 11:52, 16 February 2022 (UTC)Reply
Actually I already created task task T223111 (myself) 3 years ago... clearly not implemented yet - even when this request obviously requires few coding effort? Geert Van Pamel (WMBE) (talk) 16:26, 16 February 2022 (UTC)Reply

Inline cite references[edit]

Create instant Cite references with the Visual editor omitting the ref-tag, see task T302355 Geert Van Pamel (WMBE) (talk) 23:53, 22 February 2022 (UTC)Reply

Was already requested as task T95702... Geert Van Pamel (WMBE) (talk) 14:34, 25 February 2022 (UTC)Reply

2023 - Warn on moves to sensitive titles[edit]

Follow up from old phab:T85393. — xaosflux Talk 11:56, 26 February 2022 (UTC)Reply

Vote counting only counts (+) "support" voting — it should also consider (-) votes[edit]

The 2022 wishlist survey report vote "counting" reporting only adds those votes which support an idea.

All (-) «do not support» votes are discarded. The time of those who endeavoured to explain why a proposal might not be productive is considered meaningless.

Kinda makes pointless voting on these things; I shall not be wasting my time on these surveys anymore unless fixed. Thanks anyway, XavierItzm (talk) 14:56, 8 April 2022 (UTC)Reply

Better tables[edit]

Currently table wikitext is clunky and very hard to use. Tables are generally hard to edit, esthetically bland and usually even VE isn't enough to make them feel flexible.

The overall source and visual editing experience with them should be improved. - Klein Muçi (talk) 02:05, 29 April 2022 (UTC)Reply

Change this page name?[edit]

Sandboxes are generally disposable test pages. Rename this page to "Early suggestions", "Early ideas for wishes", "Possible 2023 suggestions" or "Pending 2023 suggestions". Also, add a more prominent link to this page to the top of the parent page — GhostInTheMachine talk to me 12:13, 29 April 2022 (UTC)Reply

Google and Facebook etc. login[edit]

To make possible to login with other sites' accounts, such as with Google or Facebook. --40bus (talk) 09:09, 25 May 2022 (UTC)Reply

c.f. phab:T138695. — xaosflux Talk 20:23, 24 December 2022 (UTC)Reply

notify watchers[edit]

Wikibreak/OoO autoresponder[edit]

IDK if that'd even be possible; it would be just so useful if I could set up a "wikibreak/OoO" status which would make anyone pinging me/writing on my user talk page get an Echo message informing that the ping worked/edit was saved but wasn't really effective. Tar Lócesilion (talk) 23:05, 3 August 2022 (UTC)Reply

On your user talk page, you can use edit notices if your wiki is set up to allow non-admins to create edit notices on user talk pages. As an example, see my Commons talk page—if you create a new topic, a notice appears about how I like to have conversations. (Pay attention, though, that edit notices currently don’t appear in the reply tool, only the new topic tool and the legacy full page editor.) —Tacsipacsi (talk) 18:42, 4 August 2022 (UTC)Reply
Thanks @Tacsipacsi. I'm familiar with edit notices. That would be a poor ersatz, though. I mostly mean notifications and pings outside of the user talk page namespace. It's more about Admins' noticeboards, WikiProject talk pages, Village Pumps, anywhere where template/gadget maintainers get chased - spaces where someone may ping you specifically and never ask themselves if you're active at a given moment. Tar Lócesilion (talk) 18:31, 1 January 2023 (UTC)Reply

Edit WikiData easily[edit]

w:en:Template:EditAtWikidata gives a link to WikiData. Users then have to edit on that website. It would be nicer, and would help Wikidata integration, if a pop-up box or similar appeared instead, allowing users (and readers) to edit Wikidata from Wikipedia. Qwerfjkl (talk) 20:17, 8 November 2022 (UTC)Reply

See mw:Wikidata Bridge. However, its development halted a while ago (without being explicitly declined), so making it a wish could help it get continued. —Tacsipacsi (talk) 22:19, 10 November 2022 (UTC)Reply

Global templates[edit]

It would be useful if a template could be created in meta, and able to use on all (language) wikis, similarly to global userpages. Qwerfjkl (talk) 20:17, 8 November 2022 (UTC)Reply

c.f. phab:T121470. — xaosflux Talk 21:33, 13 December 2022 (UTC)Reply
Not in meta perhaps, because meta templates are managed according to local usage. I'd appreciate a that contains everything for centralised usage. Can be invoked by something like {{#repo:ping}} (similar to {{#invoke:) to use Template:Ping at the repository locally. —‍CX Zoom (A/अ/অ) (let's talk|contribs) 08:38, 18 December 2022 (UTC)Reply
This would soon be obsolete, replaced by Wikifunctions, when #wikifunctions magic word becomes available on all wikis to call out to Wikifunctions. Midleading (talk) 08:01, 25 November 2023 (UTC)Reply

Add support for user login with Passkeys[edit]

I will propose to add support for user login with Passkeys, a passwordless authentication system. --Agusbou2015 (talk) 16:16, 14 December 2022 (UTC)Reply

c.f. phab:T321708. — xaosflux Talk 21:01, 14 December 2022 (UTC)Reply

A warning popup when adding a DAB cat while using HotCat[edit]

See MediaWiki talk:Gadget-HotCat.js#Could a warning popup appear when adding a DAB cat while using HotCat?.

  • Problem: If you try to add a Disambiguation category (DAB category) to a file or category using HotCat, you cannot see that it is a DAB category. So a lot of DAB categories have files and/or subcategories, see c:Category:Non-empty disambiguation categories (not only due to HotCat). But it is undesirable to have files or categories in DAB categories.
  • Possible solution: A warning pop-up appears when you try to add a DAB cat via HotCat. That happens already when you try to add a DAB cat via the edit tab. Could such a warning pop-up also appear when you try to add a DAB cat via HotCat?

JopkeB (talk) 05:42, 16 December 2022 (UTC)Reply
I just made a proposal on the Wishlist 2023, see Community Wishlist Survey 2023/Multimedia and Commons#A warning popup when adding a DAB cat while using HotCat. --JopkeB (talk) 05:34, 25 January 2023 (UTC)Reply

Provide example code for SDC[edit]

Media on commons are expected to contain depicts vid SDC. There are tools like QuickStatements and ACDC but no code examples (in python, php, java, whatever) on how to add/edit SDC programmatically. I would love to add depicts to all my uploads, if I could integrate it in my upload process. But without a tutorial or code examples it simply is to much of an effort. C.Suthorn (talk) 18:59, 20 December 2022 (UTC)Reply

This wish is too vague. If you want submit data programmatically, you have two options:
  1. choose a language and use it to send some data to the site (its API),
  2. choose a framework that does the above for you and can work with SDC.
For (1), you need to know the language, how to make web requests and what data API will accept. In this case, there is not much to be done. Tutorials are all over the internet, Wikibase API is documented at mw:Wikibase/API.
For (2), it all depends on the chosen framework, but you don't mention any. Pywikibot (Python) already supports SDC (and most Wikibase API): phab:T173195#6165308. For Java, there is Wikidata Toolkit.
--Matěj Suchánek (talk) 12:35, 14 January 2023 (UTC)Reply

Improve status messages in upload process[edit]

Media uploads to Wikimedia consist of the steps: Uploading, assembling, publishing. In the assembling and publishing steps an upload tool can poll the server for status info. But it is only "assembling" or "publishing". If the server responded with something like "assembling 41%" or "assembling - checking EXIF for malware links" upload tools like UploadWizard, Commopnist, pattypan, Rillke upload tool and every other upload tool could return much more useful info to the user uploading a file. There is a phab task for this. C.Suthorn (talk) 19:04, 20 December 2022 (UTC)Reply

Think this is phab:T309094. — xaosflux Talk 11:20, 4 January 2023 (UTC)Reply

Fix the upload wizard[edit]

The upload wizard is broken since 2016 and gets brokener every year. It needs to be fixed or reset to pre 2016 software version. C.Suthorn (talk) 19:05, 20 December 2022 (UTC)Reply

@C.Suthorn I know this is a placeholder, but this is going to need a lot more details - you should start getting those together. If there is an existing task (see all here about it, note the task number. If there isn't please also open a task in phab with the technical details. — xaosflux Talk 20:17, 24 December 2022 (UTC)Reply
Over the years I opened a number of tasks at phab. - They got closed as not reproducable. The only thinkable solution would be if developers uploaded themselves large numbers of files or large files or both. I have even offered such files for them to try. But there is no interest. I will not again provide details - I have done so too many times.
But take a look at c:Commons:Think big - open letter about Wikimedia Commons: "On the one hand, we strongly welcome quick solutions for the most urgent problems such as the upload of content." or at as a tool that can upload large files and large numbers of files. C.Suthorn (talk) 09:05, 4 January 2023 (UTC)Reply
Sorry you are frustrated, as this will go to the larger community if you list it - being able to tell people what they are voting for may help you get more support. — xaosflux Talk 11:18, 4 January 2023 (UTC)Reply

Better tracking of template dependencies[edit]

Very often, one template invokes another template, only when some condition is met. When we look into the "WhatLinksHere" of this conditional template, it does not show which template invokes it. As such, it may be modified in a way that breaks its dependency template. Further, if we do find it being used at some articles, it becomes very difficult to track down exactly which template invokes it. It also makes debugging difficult. —‍CX Zoom (A/अ/অ) (let's talk|contribs) 17:51, 21 December 2022 (UTC)Reply

Categorisation logs[edit]

Categorisation logs which are currently only seen at watchlists and recent changes, related changes, should be made into a separate log page that tracks all input and output to the category ever made by anyone. And preserve the history of a category just as we preserve the history of articles. —‍CX Zoom (A/अ/অ) (let's talk|contribs) 07:46, 24 December 2022 (UTC)Reply

Please note that showing categorization changes in watchlists and recent changes is done on a best-effort basis; it doesn’t log pages whose categorization changes due to an edit to an embedded template or based on some condition (e.g. “categorize pages with red links” or “categorize pages that have been marked for deletion for more than a week”). I’d be wary of creating persistent logs with such incomplete data, and I’m not sure if the data could be made more complete (changes to embedded templates could probably be tracked, but this may have performance issues; condition-based categorization may not even be possible to track). —Tacsipacsi (talk) 14:45, 25 December 2022 (UTC)Reply
@Tacsipacsi: In my opinion, we don't need to attribute every categorisation to the editor of embedded template. [We don't do it currently either, so nothing of value is lost.] All we do is track what enters a category and what exits it, and at what time. Nothing more. —‍CX Zoom (A/अ/অ) (let's talk|contribs) 15:40, 1 January 2023 (UTC)Reply
But what if it enters the category due to a manual edit and exits it due to an edit to a template? Based on the logs, it’d look like as if it was still member of the category, since it was never removed from it. Or vice versa, pages removed from categories that were never added to them in the first place. —Tacsipacsi (talk) 22:15, 1 January 2023 (UTC)Reply
Yeah, I said All we do is track what enters a category and what exits it, and at what time. Nothing more. Category logs will maintain a log of entry/exits with time, irrespective of how/why the entry/exit happened. Whenever something enters a category, due to manual edit or edit to a template, it triggers the catlog and is logged, same for exiting members. —‍CX Zoom (A/अ/অ) (let's talk|contribs) 12:03, 2 January 2023 (UTC)Reply
Unless it doesn’t trigger it. Category changes caused by template edits are usually processed sooner or later, but category changes caused by changes to MediaWiki messages (tracking categories), magic words/parser functions or external data (Wikidata, tabular data from Commons) sometimes get stuck for months or even years. And if we ask the sysadmins to solve this caching issue, they’ll probably say “no, we don’t want to blow up the wiki”. So this cannot be better than best-effort. —Tacsipacsi (talk) 18:32, 2 January 2023 (UTC)Reply
Support Support -- @CX Zoom, This would be helpful. Ooligan (talk) 03:05, 25 January 2023 (UTC)Reply
For 2021 and 2022, I proposed Community Wishlist Survey 2022/Categories/Improve tracking of categorization changes. I might give it one more try. --Matěj Suchánek (talk) 12:38, 14 January 2023 (UTC)Reply
+1 Nardog (talk) 09:06, 23 January 2023 (UTC)Reply
@Matěj Suchánek, Please, try again. Thanks, -- Ooligan (talk) 03:06, 25 January 2023 (UTC)Reply
It's already done: Community Wishlist Survey 2023/Search and Categories/Improve tracking of categorization changes. --Matěj Suchánek (talk) 07:11, 25 January 2023 (UTC)Reply

Add save to personal draft button[edit]

When writing new articles, I often can't finish them in one go, and end up having to save my incomplete work in my Google Docs. Why not have a "save to draft" button, so that the last version would automatically be added to User:username/Drafts/title. Meanwhile User:username/Drafts can have a list of all drafts created by the user. Inversely, the draft page can have a button "resume article creation" to return to the article creation page, and "delete draft" if the user doesn't need the draft anymore.--Ideophagous (talk) 19:31, 26 December 2022 (UTC)Reply

Possible overlap with phab:T229115. — xaosflux Talk 21:26, 27 December 2022 (UTC)Reply

local securepoll - try this again[edit]

Follow on from phab:T301180. — xaosflux Talk 17:42, 1 January 2023 (UTC)Reply

Was relegated to Community Wishlist Survey 2022/Larger suggestions/Make SecurePoll accessible through local wikis last year. — xaosflux Talk 15:18, 13 January 2023 (UTC)Reply

PagePile / GULP / lists for automated reports[edit]

Tracked in Phabricator:
Task T231891

Develop a tool which saves a list of Wikipedia articles, then makes that list available as input into other tools which run analytics reports on all articles in the list.

Magnus made years ago and proposed Gulp in 2019. This is a tool which creates lists of Wikipedia articles which a user can input into other tools to output metrics. The most popular application for this is, where a user can input a Pagepile of Wikipedia articles to output a traffic report.

Having traffic reports for each of hundreds of Wikipedia articles in a user-curated list is critical for institutional partners. For example, a health organization may want to consider all the Wikipedia articles related to a medical condition to identify the most popular articles as targets for editing. Wikimedia categories do not work for this because they include unwanted topics and exclude wanted topics; organizations simply must make their own lists.

For lots of reasons, mostly lack of development, PagePile needs improvement and fixes. The Gulp proposal on the table which is a specification for the ideal product.

When such a list generation tool works and is reliable, then I expect there will be demand for many other kinds of analytics tools, like aspects of the XTools editing reports for arbitrary lists of Wikipedia articles, or future applications like identifying which articles have translated versions, multimedia from Commons, references, and all the other metrics which Wikimedians check and encourage as part of content development and quality control.

Another desired feature is new ways of list generation. PagePile methods include manually inputting Wikipedia article titles or Wikidata identifiers. Running Wikidata queries is possible too. I also want to be able to input a Wikimedia URL and get a list with all the articles linked or Q ids linked on that page. Bluerasberry (talk) 22:15, 1 January 2023 (UTC)Reply

On English Wikipedia, add the automatic citation generator from visual editor to source editor[edit]

That way, we don't have to switch between visual and source editor for formatting and citations. Di (they-them) (talk) 03:45, 17 January 2023 (UTC)Reply

@Di (they-them) are you familiar with the w:en:Wikipedia:RefToolbar tool there? — xaosflux Talk 19:45, 17 January 2023 (UTC)Reply
I was not, thank you. Di (they-them) (talk) 19:49, 17 January 2023 (UTC)Reply

Reminder notification[edit]

Many times we miss notifications or don't have time to deal with them right when we receive them, so we need reminders. See Reminder software Aram (talk) 17:50, 17 January 2023 (UTC)Reply

URI rot[edit]

- URls are rotting all over WP. Instead, whenever a ref with an URL is added, automatically archive it and add an archive link to the ref. Lfstevens (talk) 18:57, 11 April 2023 (UTC)Reply

Add external link cites in VE[edit]

- In VE, add a way to add a cite to the external links section using the same mechanism used to add a ref. (Possibly by adding a checkbox to the ref page that says something like include ref wraper. Currently, you have to switch to source to get rid of the ref wrapper. Lfstevens (talk) 18:58, 11 April 2023 (UTC)Reply

Error check refs before completing a save[edit]

- In source editing, if you save a change that has a damaged ref in it, display the error without finishing the save. Once the errors are gone, then accept the change. Lfstevens (talk) 06:02, 13 February 2023 (UTC)Reply


Allow this to be set in VE Lfstevens (talk) 19:00, 11 April 2023 (UTC)Reply

Short description[edit]

Allow this to be set in the Properties page, without requiring knowledge of the template. Lfstevens (talk) 19:01, 11 April 2023 (UTC)Reply

Italicize title[edit]

Make this a checkbox on the Properties page. Lfstevens (talk) 19:02, 11 April 2023 (UTC)Reply

Add/remove various templates from property page[edit]

Things like:




infobox settlement

, etc. Use MI accordingly. Lfstevens (talk) 19:05, 11 April 2023 (UTC)Reply

search messages[edit]

signature colour[edit]

Make a setting for all links to userpages and talk/contribs able to be highlighted in a bright colour (of our choosing). Really annoying to see what is signature and what is actual text in discussions, especially when people use the default sig.--Roundish (talk) 23:14, 25 June 2023 (UTC)Reply

Wikidata: Enable the "class" and "relation" parameters on more constraint types[edit]

  • Problem: Some useful constraints cannot be created with existing constraint types as currently implemented. The current workaround is often not feasible, and where it is, it results in large, difficult-to-maintain, and often incomplete constraints (examples below).
  • Proposed solution: Add support for the parameters P2308 (class) and P2309 (relation) (already supported by subject-type and value-type constraints) to the none-of, item-requires-statement, and conflicts-with constraint types, to specify classes that property values may or may not belong to. This will allow some constraints to be made much smaller, more maintainable, and more complete, and enable the creation of powerful new constraints.
  • Who would benefit: Wikidata users and editors
  • More comments: The three specified constraint types support allowing or disallowing specific property values (using P2305 (item of property constraint)), but they do not support allowing or disallowing classes of values. This leads to 1) the creation of large, difficult-to-maintain, and often incomplete constraints (examples 1-3 below) that attempt to list every applicable property value, and 2) the absence of useful constraints when the values are just too numerous to list (example 4). In contrast, subject-type and value-type constraints use the qualifiers P2308 (class) and P2309 (relation) for this purpose (the latter indicating whether values must be instances, subclasses, or either with respect to the specified class).
The effect will be to natively enable the three forms of constraint in green in the lower right of this table: of these items, use: ...a member or subclass of these classes, use:
If the value of the statement... should be... one-of value-type
should not be... none-of none-of w/class+relation
If the value of another statement on the item... should be... item-requires-statement item-requires-statement w/class+relation
should not be... conflicts-with conflicts-with w/class+relation
1. This none-of constraint has 33 values of "item of property constraint", which are meant to include all recurring events, but are certainly not exhaustive. Instead, these could all be replaced with class = recurring event (Q15275719), relation = instance or subclass of, which would be exhaustive. This query gives more constraints that may be candidates for this sort of simplification.
2. This item-requires-statement constraint has 39 values of "item of property constraint", which are meant to include all filmmaking occupations, but are likely not exhaustive. Instead, these entries could be replaced with class = filmmaking occupation (Q4220920), relation = instance of, which would be exhaustive. This query gives more such constraints.
3. This conflicts-with constraint has 27 values of "item of property constraint", which are meant to include all types of crime, but are likely not exhaustive. Instead, these could all be replaced with class = crime (Q83267), relation = subclass of, which would be exhaustive. This query gives more such constraints.
4. (new constraint): The value of instance of (P31) should not be a taxon (Q16521). (If the item is an individual organism (Q110224119), it should use individual of taxon (P10241); if the item is a taxon, it should use parent taxon (P171).) As of writing, 18,080 items violated this rule: (query). Obviously, we can't list all taxons in a constraint. Under the proposal, this rule could be expressed with a none-of constraint on instance of (P31), with class = taxon (Q16521) and relation = instance of.

I wholeheartedly support this kind of extension for constraints. Peter F. Patel-Schneider (talk) 16:00, 6 December 2023 (UTC)Reply

Wikidata Recent changes filter by language[edit]

One should be able to filter the Recent changes page of Wikidata by language; that is, you should be able to set the Recent changes to show only edits that affect a specific language. --NGC 54 (talkcontribs) 19:02, 31 December 2023 (UTC)Reply

Updates for translations[edit]

Let's say that you translate a Wikipedia article. The Wikipedia article in the source language gets updated, but you do not translate the update, as you do not know about it. There should be a notification system that notifies you about the last changes in the articles that you have translated. --NGC 54 (talkcontribs) 19:06, 31 December 2023 (UTC)Reply