Community Wishlist Survey/Sandbox

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

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


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[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[reply]
YES - agree...no point in not distinguishing links per namespace. Also does not seem too complex. --Zblace (talk) 04:19, 11 December 2021 (UTC)Reply[reply]
Similar propositions:
-- Pols12 (talk) 15:35, 5 January 2022 (UTC)Reply[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[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. be-x-old.wikipedia.org was renamed be-tarask.wikipedia.org
  2. There are petition to rename no.wikipedia.org into nb.wikipedia.org , so as to reflect the site's language being Norwegian Bokmål
  3. simple.wikipedia.org should be changed to en-simple.wikipedia.org, in order to reflect it is a Wikipedia for Simple English, and comply with the language tagging standard
  4. Serbo-Croatian Wikipedia sh.wikipedia.org 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 hbs.wikipedia.org accordingly.
  5. Classical Chinese Wikipedia, currently located at zh-classical.wikipedia.org, have its own language code lzh, so it have been suggested to move to lzh.wikipedia.org.
  6. Cantonese Wikipedia, zh-yue.wikipedia.org, 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 yue.wikipedia.org.
  7. Min Nan Wikipedia, aka the Wikipedia for Minnanese and Taiwanese, is now located at zh-min-nan.wikipedia.org, 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 nan.wikipedia.org, accordingly.
  8. Swiss German Wikipedia, which have been placed under als.wikipedia.org, have since year 2005 received official language code "gsw", and is thus desirable to change the wiki's link to gsw.wikipedia.org
  9. Syriac Wikipedia, is now currently working under another name of Aramaic Wikipedia, at arc.wikipedia.org, 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 syc.wikipedia.org, to properly reflect the language used in the Wikipedia.
  10. Norman language from Normandy is now having a wikipedia at nrm.wikipedia.org. Yet "nrm" is actually a language code for Narom language from Malaysia. Hence it have been proposed to change the wiki's URL from nrm.wikipedia.org to nrf.wikipedia.org to reflect the correct language code for the Norman language.
  11. The Wikipedia for Emilian language from Italy, currently located at eml.wikipedia.org, 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 egl.wikipedia.org, 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 fiu-vro.wikipedia.org. Since the language received its own language code in 2009 as "vro", it have been desired tom move the site to vro.wikipedia.org
  13. Currently, bh.wikipedia.org 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 bho.wikipedia.org, to avoid confusion with other Bihari languages.
  14. cbk-zam.wikipedia.org 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 cbk.wikipedia.org 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 bat-smg.wikipedia.org to sgs.wikipedia.org.
  16. Aromanian Wikipedia, is currently located at roa-rup.wikipedia.org, with rup representing Aromanian language roa supposedly mean "Other romance languages", which is meaningless, and thus should be moved to simply rup.wikipedia.org.
  17. Currently, there is an "Old Wikisource" located at www.wikisource.org. It have been proposed to rename it as Multilingual Wikisource and be moved to mul.wikisource.org, 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[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[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[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[reply]

Smart idea! Worth the effort for sure. --Zblace (talk) 04:24, 11 December 2021 (UTC)Reply[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[reply]

Looking at the interest group and the website itself(https://www.similarweb.com/website/wikiwand.com/), 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[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[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[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 https://en.wikipedia.org/w/index.php?title=User:Evad37/Thanky.js ) 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[reply]

Good idea. --Zblace (talk) 04:28, 11 December 2021 (UTC)Reply[reply]
It could be enabled locally as a Gadget (maybe by default?). Qwerfjkl (talk) 19:04, 29 December 2021 (UTC)Reply[reply]
This does not seem like an issue concerning only a local wiki. ~~~~
User:1234qwer1234qwer4 (talk)
20:56, 29 January 2022 (UTC)Reply[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[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[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[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[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[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[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 en.wikipedia.org'" / "ignore sections 'See also', 'Notes' 'References', ' Futher reading', etc. "... --N4CH77 (talk) 01:32, 9 January 2022 (UTC)Reply[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[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[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[reply]
Ah okay! Thank you! TiggyTheTerrible (talk) 10:18, 12 January 2022 (UTC)Reply[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[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[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[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[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[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[reply]

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

2023 - Warn on moves to sensitive titles[edit]

Follow up from old phab:T85393. — xaosflux Talk 11:56, 26 February 2022 (UTC)Reply[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[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[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[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[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[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[reply]