Community Wishlist Survey 2022/Miscellaneous

Add links
From Meta, a Wikimedia project coordination wiki
Community Wishlist Survey 2022
Miscellaneous
39 proposals, 391 contributors, 1169 support votes
The survey has closed. Thanks for your participation :)



Be able to find the largest edits of a user on XTools

  • Problem: I would like to know which of my edits have added the most amount of bytes. I don't mean the pages I have lots of edits on, I mean which single edits have added the most content. However this option is not available in XTools or Wikistats.
  • Proposed solution: Add a new tool to XTools that lists a users edits by their diff size.
  • Who would benefit: People who want to know statistics about their largest edits.
  • More comments:
  • Phabricator tickets:
  • Proposer: Dunutubble (talk) 16:35, 13 January 2022 (UTC)[reply]

Discussion

Voting

Add "yearly" as an optional date type to the Pageviews Analysis

  • Problem: When analysing pageviews with toolforge:pageviews, it is possible to quantize the data by day or by month. As our projects are getting older, a quantization by year becomes increasingly interesting.
  • Proposed solution: Add "yearly" as an optional date type.
  • Who would benefit: People who like to study pageviews.
  • More comments:
  • Phabricator tickets:
  • Proposer: Nachtbold (talk) 20:43, 17 January 2022 (UTC)[reply]

Discussion

Voting

Centralization of interwiki links

  • Problem: The project and language for interwiki links are currently specified separately. If you want to link to a location where both the language and project are different, or if you want to link to somewhere other than Wikipedia from a multilingual project (Meta, Commons, etc.), you need to go through the Wikipedia of that language or the English version of that project. That results in the creation of an unused account for the intermediary project, leaving extra logs and making the unified login information more confusing.

    For example, if you want to link to the Japanese Wikivoyage (ja.wikivoyage), you currently need to write ja:voy: or voy:ja:, which makes you go through the Japanese Wikipedia or the English Wikivoyage.

  • Proposed solution: Simplify interwiki links by removing the redirects so that it is a single link, such as [[ja-voy:]] (or, alternatively, "javoy").
  • Who would benefit: Mainly people whose mother tongue is the language of a different version, and people who often use multilingual projects such as Commons.
  • More comments:
  • Phabricator tickets:
  • Proposer: Mario1257 (talk) 16:16, 17 January 2022 (UTC)[reply]

Discussion

  • @Mario1257:
    en: Are you aware of wikidata:Special:MyLanguage/Help:Sitelinks? The idea is to add all interwiki links on the Wikidata item itself. You only need to go to one page (the item page on Wikidata), then add the links one by one. This avoids the account creation problem you speak of, too. For example, see wikidata:Q60 on New York City. At wikidata:Q60#sitelinks-wikivoyage you can view and edit all the links to the different Wikivoyage projects. Does this work for you? You shouldn't need to write ja:voy: or anything similar on each language edition. Add the sitelinks only on Wikidata.
    日本: ウィキデータ サイトリンク を知っていますか？ アイデアは、ウィキデータアイテム自体にすべてのインターウィキリンクを追加することです。 1つのページ（ウィキデータのアイテムページ）に移動し、リンクを1つずつ追加するだけです。 これにより、あなたが話すアカウント作成の問題も回避されます。 たとえば、ニューヨーク市の Wikidata:Q60 を参照してください。 wikidata:Q60#sitelinks-wikivoyageでは、さまざまなWikivoyageプロジェクトへのすべてのリンクを表示および編集できます。 これはあなたのために働きますか？ 各言語版でja:voy:などを書く必要はありません。 ウィキデータにのみサイトリンクを追加します。 MusikAnimal (WMF) (talk) 19:01, 21 January 2022 (UTC)[reply]
  • Ohh, I'd never noticed that! So the idea is
Where the current situation is
I'm more likely to visit w:lang than say s:lang, so the extra login history doesn't affect me personally.
⁓ Pelagic (talk) 21:05, 28 January 2022 (UTC)[reply]

Voting

add MW messages to content pages

  • Problem: Allow displaying automatic stuff on content pages via MediaWiki messages (notices, user warnings, auto categorization, ...)
  • Proposed solution: Talk pages have specific MediaWiki messages (MediaWiki:Editnotice-NS_number-article_name and MediaWiki:Editnotice-NS_number) that can be modified to show specific content on each talk page. I propose adding a similar option to content namespaces.
  • Who would benefit: all editors
  • More comments: It could be used to show instructions for new Draft pages automatically, to categorize all kinds of content automatically (drafts, documentation subpages, articles whose name begins a certain way), to show protection templates automatically, show messages at the top of user pages, etc.
  • Phabricator tickets: phab:T151682
  • Proposer: —Ivi104 02:42, 11 January 2022 (UTC)[reply]

Discussion

  • I do not understand this proposal. Maybe an example would help. · · · Peter (Southwood) (talk): 07:23, 11 January 2022 (UTC)[reply]
    @Pbsouthwood: When editing an article, there is no way to display a notice to say there is a draft page of the same name outside of manually including a template or module into every single page to check if a draft page exists. Similarly, when editing an existing draft, there is no way to display instructions or categorize the draft outside of adding a template to the top of every draft page. If a new editor makes a draft without a template, the draft is lost in the depths of the project until someone manually notices it and adds the template.
    I propose adding a MediaWiki system message to the top of content pages. Inside, we could check if the current page is in the draft namespace, and if so, show appropriate instructions, categorize the page automatically, and so forth.
    This feature exists when editing pages (MediaWiki:Editnotice-NS_number-article_name and MediaWiki:Editnotice-NS_number) and talk pages have their own system messages (MediaWiki:Talkpageheader and MediaWiki:Talkpagetext). I propose a new system message be added to the top of existing content pages. I hope this explanation conveys my idea. —Ivi104 01:16, 12 January 2022 (UTC)[reply]
    Would this system message just display automatically/bot generated information? · · · Peter (Southwood) (talk): 04:38, 12 January 2022 (UTC)[reply]

This seems to be an en.wp-only implementation which at first glance works for NS 0 (articles) as well. See en:Wikipedia:Editnotice for details. Improvements should probably be requested there.--Strainu (talk) 07:58, 12 January 2022 (UTC)[reply]

If you means edit notice in edit mode, see phab:T201613.--GZWDer (talk) 22:01, 12 January 2022 (UTC)[reply]
  • @Ivi104: are you wanting to have a per namespace site-notice (something that is displayed to readers)? If so, that is phab:T6469. (Though it seams you want a per-page-sitenotice ??) — xaosflux Talk 19:44, 14 January 2022 (UTC)[reply]
    @Xaosflux: Yes, that is what I would like, a sitenotice that is displayed to readers. I was thinking of one notice, and parser functions could be used to display different content in different namespaces, but this idea of a separate notice for each namespace works well too. —Ivi104 22:22, 14 January 2022 (UTC)[reply]
    So you want what we currently have for editnotices, but for all content. I think that is difficult because unlike edit pages, content is cached. So if anything changes about the 'calculation' (say a draft is created or deleted) it will take a LONG time for any notice to update. —TheDJ (talk • contribs) 15:07, 16 January 2022 (UTC)[reply]

Voting

Include section links in WhatLinksHere

  • Problem: When section names are updated in an article, it's difficult to find which articles link there, making it much more difficult to update broken section links.
  • Proposed solution: When caching Special:WhatLinksHere, add which section (if any) they link to. It would also then be possible to automatically generate a list of articles with links to sections that no longer exist.
  • Who would benefit: Editors trying to find broken section links, and so readers who will be redirected to broken sections links less frequently.
  • More comments:
  • Phabricator tickets: phab:T18561
  • Proposer: --YodinT 19:49, 18 January 2022 (UTC)[reply]

Discussion

I usually use insource: search for this task. It lets me find any specific string of interest in the wiki-source. DMacks (talk) 09:51, 19 January 2022 (UTC)[reply]
That works, but only if you know previous section names. I guess there are many thousand links to non existant sections in articles that aren't being watched by an editor. This would let a new editor find all of these with one click (otherwise they would have to go through the page history to find all previous section names, and this wouldn't catch any section name typos in links either). It could also easily compile a list of all the broken sections links that are in the mainspace, in case any editors wanted to work through and fix some of them. --YodinT 11:18, 19 January 2022 (UTC)[reply]
I mis-read the proposal as targetted at the editor who is changing the section-name (to fix the inbound links themself at that time) rather than to catch broken links afterwards. I agree that some tools for finding and fixing inbound links to sections that don't exist would be useful. I think enwiki has some tool or bot, will look... DMacks (talk) 11:26, 19 January 2022 (UTC)[reply]
<page name> (redirect to section "<anchor>")
since perhaps two or three years ago.
However it does this only for redirects. I guess this is down to the fact that there can be only one such link in a redirect, but there could be many links pointing to the same page in an article and they do not necessarily all point to the same target anchor/section. Also, parsing a redirect for such target anchors is quickly done, but searching a whole article for them is an expensive operation (when done on demand and without caching). If there are multiple links from a page to the target page, but to different anchors in that page, WhatLinksHere could (group and) list them in separate lines like:
<page name> (link to section "<anchor>")
Since this is an expensive operation I think there should be a selection box in the header of WhatLinksHere to activate the feature only when it's actually needed.
It would also be great, if WhatLinksHere would actually check if a target anchor/section name exists on the target page, and display modified messages instead:
<page name> (redirect to non-existing section "<anchor>")
<page name> (link to non-existing section "<anchor>")
Given, that parsing the target article is an expensive operation as well, there should be a check box to enable this feature on demand only.
If the target article gets parsed for the anchors/section names already, the messages could actually distinguish between anchors and section names in the resulting messages like:
<page name> (redirect to section "<anchor>")
<page name> (link to section "<anchor>")
<page name> (redirect to anchor "<anchor>")
<page name> (link to anchor "<anchor>")
<page name> (redirect to non-existing section/anchor "<anchor>")
<page name> (link to non-existing section/anchor "<anchor>")
And finally a remark: Fixing broken anchor names is fine by either editing the source or the target, but it should be communicated to over-ambitious editors that blindly removing them is not. A link to a non-existing anchor does no "harm" by itself, it is perfectly valid HTML etc., the browser will just set the focus to the top of the page. There are often groups of links from articles and redirects pointing to the same anchor in a target article, and even if it does not exists, it still carries useful semantic information on which specific content is missing in an article, which of the incoming redirects are synonyms or at least semantically closely related, and which source links need to be updated in other articles and redirects when the missing contents get added/moved somewhere. This semantic infrastructure info is useful for article maintenance and reverse lookup, and by blindly deleting dangling anchor fragments, this information would get lost.
Thinking about it, it might even be useful to have an option in WhatLinksHere to sort the resulting list entries by anchor names (regardless if they exist in the target page or not), so that incoming links pointing to the same anchor can be grouped.
--Matthiaspaul (talk) 21:28, 29 January 2022 (UTC)[reply]
What would be the technical/syntactical difference between a non-existent section and a non-existent anchor? ~~~~
User:1234qwer1234qwer4 (talk) 21:43, 8 February 2022 (UTC)[reply]
Sorry for the late reply, seeing this only now... That's a good point, as they are non-existing, they can't be distinguished. I have updated the suggested list above accordingly.
--Matthiaspaul (talk) 02:53, 28 February 2022 (UTC)[reply]

Voting

Improve plain-text change tag selector

  • Problem: The plain-text tag selector (on Special:Contributions, Special:Log and some other special pages or views) is not very user friendly. You need to remember the internal tag name, which for localized tag is different from the name you are used to seeing (imagine: is it mw-revert or mw-reverted? 🤔). There are more and more supported tags added every month.
  • Proposed solution: Implement the selector as a drop-down menu or add suggestions as you type.
  • Who would benefit: Power users, admins, etc.
  • More comments: The best experience is offered in Special:RecentChanges et co.
  • Phabricator tickets: phab:T27909, phab:T23383
  • Proposer: Matěj Suchánek (talk) 10:42, 17 January 2022 (UTC)[reply]

Discussion

Voting

Add an option to switch between user accounts

  • Problem: If you are working with more accounts, there is no simple way to switch between your accounts without logging out and logging in with other credentials.
  • Proposed solution: Add an option to log in to more than one account at one moment. By clicking on your user name, you should be able to switch to another account. I think that this should be restricted to only few accounts (max. 5 [?]). The security aspects should be taken into concern.
  • Who would benefit: users with multiple accounts (bot accounts, test accounts, WMF/WMXY accounts, employee accounts...)
  • More comments: The actual workaround is to have more instances of the web browser (or more browsers, e.g. one account in G Chrome, other in Mozilla Firefox). I perceive the opportunity of switching the accounts as a standard feature in 2020s.
  • Phabricator tickets:
  • Proposer: — Draceane talkcontrib. 19:55, 15 January 2022 (UTC)[reply]

Discussion

Voting

Automatically log in to all projects if you are logged in to one

  • Problem: Now I have to log in seperately at all projects (like the Wikpedias, Wikibooks, Wikidata), even if I am logged in to Commons, though the inlog codes are the same for all projects. Sometimes I forget it and then my edits are registered on my IP adress. Going from any project where I am logged in to Commons, I am automatically logged in to Commons, so it is possible.
  • Proposed solution: Automatically log in to all projects if you are logged in to one, no matter which one, like now in Commons.
  • Who would benefit: All editors who regulary switch from one project to another to make changes/edits.
  • More comments:
  • Phabricator tickets: phab:T217519, phab:T226797
  • Proposer: JopkeB (talk) 05:57, 11 January 2022 (UTC)[reply]

Discussion

  • Isn't this supposed to be default already? · · · Peter (Southwood) (talk): 08:44, 11 January 2022 (UTC)[reply]
    If it is, it certainly doesn’t work for me? Jcshy (talk) 08:47, 11 January 2022 (UTC)[reply]
    It didn’t work just now for me, logged in to Wikipedia.org but not here. -- TheInternetGnome (talk) 10:19, 11 January 2022 (UTC)[reply]
    Same here, which is why I submitted a different proposal that is apparently a subset of this one. RSLitman (talk) 19:58, 11 January 2022 (UTC)[reply]
    It is, but the CentralAuth extension responsible for the the global account system hasn't been properly maintained in years. I suspect automatic cross-wiki login broke after some browser privacy change (see for example phab:T257853). Majavah (talk!) 06:56, 12 January 2022 (UTC)[reply]
    Yes this stopped working years ago. First on Safari, then on Firefox and since a years or two on Chrome and Edge. —TheDJ (talk • contribs) 12:09, 12 January 2022 (UTC)[reply]
    I think it is like a browser problem; and I don't see any problems with unified login. Some tools to patrol cross-wiki needs to have a global account. Thingofme (talk) 03:24, 16 January 2022 (UTC)[reply]
  • Added an phab ticket.--Snævar (talk) 08:53, 11 January 2022 (UTC)[reply]
  • Agreed. Don't know why this isn't the default already. BetweenCupsOfTea (talk)
  • Comment. Please, make this togglable in the preferences ("Disable/enable the unified login" or something like that), so that you can easily use different usernames on different wikis (for example, the username "EnglishWikipedian321" on en-wiki and the username "ItalianWikipedian123" on it-wiki). Having to log out and in constantly between those two accounts in order to edit both wikis at the same time is a pain in the... 85.76.129.122 11:56, 13 January 2022 (UTC)[reply]
    User accounts are global so there's no reason to have a different account on each wiki. You can use another browser then. Stryn (talk) 15:08, 13 January 2022 (UTC)[reply]
    Thanks but I'm aware. Here are some reasons I can think of why it's important to implement the togglability:
    • 1) Better privacy
      • Maybe you are very open of who you are on your userpage in another wiki, but you would like to stay as anonymous as possible on another wiki you edit for whatever reason. E.g., you can be pretty open about your political views, sexuality or gender etc. on many wikis, but, sadly, that's not the case on every wiki (not going to name any specific wiki here, but there are language editions whose some users are not used to the same level of liberty of any developed country). Thus, you would be prone to harassment either on wiki, social media or maybe even IRL.
    • 2) Better security
      • When you edit any language edition that could possibly lead you to problems with authorities of specific countries (again, not going to name any specific country, but you probably know at least one authoritarian country with very limited freedom of speech). There's always a risk of this happening. Your less-anonymous other wiki identities would only be clear to users that have a cross-wiki IP check tool or something like that, so it wouldn't be 100% risk-free but still.
    • 3) Personal preference and accessibility
      • When you, e.g., want to use a Latin-script username ("User:John Doe") in a Latin-script wiki, and a Chinese-script username ("User:雨果奖等") in the Chinese-language wiki. This would also make others in that wiki feel you're more approachable when, in their eyes, your username is not in a foreign script. It would be easier to remember someone's username in order to find their userpage to contact or ping them. I personally find it very hard to remember and write usernames like "User:بالتاريخ", "User:дюжин листов" or "User:ギリシャ経済危" compared to a username like "User:John Doe".
    • 4) Username means something else in another language
      • Maybe your username happens to be a name of a large company in some other country? Or a profanity in that wiki's language perhaps? And when something like that gets your username banned from editing that wiki due to that wiki's username policies, you would have to register another username there, and then you would have to use different browsers to edit those two wikis at the same time. I'd imagine there already are some cases like this.
    • 5) No more cross-wiki alerts or emails
      • When you visit another wiki for whatever reason while logged in and your account gets automatically registered there, you're prone to get spammy alerts and emails later on when, e.g., bots leave foreign-language messages to your user talk page on wikis that are foreign to you, i.e. those that you never edit. Sometimes they also like to send you foreign-language emails that you don't wish to receive.
    • 6) It wouldn't be against any policy(?)
      • Well, maybe someone else knows better, but I believe it's not. And I don't think implementing this would cause any cross-wiki abuse--at least I can't think of any possibilities this would open to vandals and such.
    I can't think of any good reasons to not implement this for us who want this waterproof togglable option to opt-out from cross-wiki logins easily. "Use different browsers" = you're prone to make a human error all the time. Also, using a different browser that you're used to is very inconvenient. 85.23.82.28 20:02, 5 February 2022 (UTC)[reply]
  • It somehwat works, but there are many bugs. E.g. T257853, T257852, T256525, T257803. --Tgr (talk) 02:33, 30 January 2022 (UTC)[reply]

Voting

Allow Users to Add Their Own Personal Notes to a Page

  • Problem: I will discuss this with respect to Wikipedia, but it applies to most Wikimedia projects.

    If I am logged in and I want to add a comment or a list of notes to an entry, it would be good to be able to. The notes would only be readable to me or anyone logged into my login. Think of this as something like the notes page at the back of a reference book.

    The implementation would be relatively simple and with reasonable limits on what could be placed in the notes, the storage overhead should not be a problem based on 2022 storage standards.

    I made this proposal directly to S. Sastry at Wikimedia a couple of years ago, but I believe it was lost in the noise at that time. This is a better place for it.

  • Proposed solution:
  • Who would benefit: Everyone
  • More comments:
  • Phabricator tickets:
  • Proposer: Bezenek (talk) 22:26, 20 January 2022 (UTC)[reply]

Discussion

Voting

Eye icon when creating an account or logging in

  • Problem: When creating an account or logging in, it is sometimes hard to find out if you entered the correct characters for password.
  • Proposed solution: Add an eye icon in the "Password" field at Special:CreateAccount and Special:UserLogin. Once pressed, it will show you the characters already entered by you in this field.
  • Who would benefit: Registered users
  • More comments: This is very useful if you use a longer password.
  • Phabricator tickets:
  • Proposer: --NGC 54 (talk / contribs) 11:12, 11 January 2022 (UTC)[reply]

Discussion

  • Agree. No explanation needed. Jmaxx37 (talk) 16:44, 11 January 2022 (UTC)[reply]
    One could argue that a) the "Confirm password" field already alleviates the need for such a button, but more importantly, b) this is a client-side thing the browser should provide, not some kind of JavaScript messing with the field type in the form. Making it a non-hidden text could, for example, cause mobile keyboards to remember the typed word and suggest it the next time you're typing a WhatsApp message. It would also prevent the browser from offering you to save the password for you. ToBeFree (talk) 20:26, 11 January 2022 (UTC)[reply]
    I usually remain logged in (no shared devices), but because I had to recover my WikiMedia password and set a new one today, I got logged out on all devices/browsers I use. As I went on to all of my devices and browsers, I noticed while using Edge on my Windows 10 computer, I did get the eye icon. It happened to be the last log in that I did, so I didn't have a chance to glance at this on my other browsers and devices. Maybe this is something that only happens in Edge, which I use a lot less often than Chrome on this computer. RSLitman (talk) 23:08, 11 January 2022 (UTC)[reply]
    I agree with this idea because some strong passwords are hard to remember and to fill the correct one is challenging. Sometimes, I can fill it wrong and don't know why. The eye feature would help you with this, but remember to not click this when at the public. Thingofme (talk) 03:30, 16 January 2022 (UTC)[reply]
  • Agree completely. I've struggled many times while writing my password because of this. BetweenCupsOfTea (talk)
  • For security reasons (to prevent others from unknowingly discovering your password), clicking on the "eye" icon should ask you to enter your Windows or Mac credentials if you are using a laptop or desktop. If you are using an iOS or iPadOS device, then it should ask for your Apple ID credentials. If you are using an Android device, then it should ask for your Google account credentials. GeoffreyT2000 (talk) 04:14, 16 January 2022 (UTC)[reply]
    That's not reasonable at all and not how modern websites work either. Izno (talk) 22:28, 18 January 2022 (UTC)[reply]
  • 'Agree. It is standard behavior. --Frettie (talk) 09:03, 18 January 2022 (UTC)[reply]
  • Although this should be a standard browser feature in an ideal world (so far it is supported as -ms-reveal in MS family of browsers from IE to Edge / EdgeChromium), it is currently not standard. Yet it is very useful e.g. for accessibility purposes (some people have to use very cumbersome input methods). --SSneg (talk) 21:02, 29 January 2022 (UTC)[reply]

Voting

Show edit count at Special:Contributions

  • Problem: Edit counts are hard to determine unless you know about external tools and user scripts that show this information, or if you explicitly state how many edits you have on your userpage. Attempting to paginate through a user's contributions to count their edits can take a very long time if they have a very high edit count.
  • Proposed solution: Show a user's edit count at Special:Contributions, similar to how it is done on mobile web.
  • Who would benefit: An editor's edit count can be an indicator of how experienced they are. If somebody who recently edited the page had only 50 edits, an editor would be sure to review the edit with caution, because newer editors will generally mess up more often than experienced editors with 150,000+ contributions. Edit counts can also helpfully determine what kind of editor a person is (e.g. whether an editor edits to add more information to the site, or is a wiki gnome who fixes spelling errors and formatting).
  • More comments:
  • Phabricator tickets: T324166
  • Proposer: MrMeAndMrMe (talk) 19:13, 10 January 2022 (UTC)[reply]

Discussion

It would be better also if the edit count of a user is visible on diffs, so if the editor edited an article, we may wish to see his edit on diffs and if edit count of that user is there, it's easy to identify if the user has enough experience in editing. Just in the mobile version. Ctrlwiki (talk) 06:33, 11 February 2022 (UTC)[reply]

Voting

Enable wiki URL changes

  • Problem: From no later than year 2006, a number of Wikipedia and other Wikimedia projects 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 failures, for example Content Translation tool still fail to function properly for the wiki due to the change in code from a decade ago.

    In order to fix the editing environment of such the renamed wiki, and to correct the name and language codes of all the wikis that are currently having various problems with their current name/url/language code, it is necessary to clear those long-standing technical roadblocks, and also to prevent new ones from being created.

    It might be a bit too large of a project for the Community Tech team to clear all of the blockers, but there should be a number of those blockers that the Community Tech team should be able to help clear, thus making the goal of changing the name, language code, and URL of different Wikipedia or other Wikimedia projects much easier.

    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 petitions to rename no.wikipedia.org into nb.wikipedia.org, so as to reflect the site's language being Norway's 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 proposals 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 some 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 to 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.
  • Proposed solution: Resolve as much bugs in phab:T172035 as possible, in accordance with the Community Tech team's capability.
  • Who would benefit: All readers and editors of affected wiki, all future developers of tools for the MediaWiki software, and all users of affected languages across the globe (Since Wikipedia language codes are sometimes being taken as de facto standard for languages by others far beyond just the Wikipedia itself, instead of the base BCP-47 standard, fixing these language codes will also promote fixing them everywhere else across the internet or even off the internet)
  • More comments: This is a resubmission of wish from 2019 Community Wishlist and based on a proposal written in the sandbox.
  • Phabricator tickets: phab:T172035
  • Proposer: C933103 (talk) 12:10, 16 January 2022 (UTC)[reply]

Discussion

Voting

Graph showing which articles link to each other for incubator

  • Problem: This isn’t really a problem that necessary harms users, just a suggestion for something that would help.
  • Proposed solution: For every test wiki, it will be possible to choose an article, then get a graph with arrows showing what articles the specified article links to, and what articles the linked articles link to. Probably a maximum of 3-5 jumps.
  • Who would benefit: Editors in test wikis in the incubator.
  • More comments: Will be useful to estimate how much content the test wiki has and if it uses wikilinks correctly.
  • Phabricator tickets:
  • Proposer: Gifnk dlm 2020 Happy New Year 🎄❄️⛄️🎇 (talk) 16:51, 16 January 2022 (UTC)[reply]

Discussion

Voting

Create 'Related changes' tool that extends beyond 30 days

  • Problem: Even though 'Related changes' can show up to 500 changes, it has a short lifespan, just 30 days maximum, so rarely shows more than 20-30 before they time-expire. 'Related changes' uses the recentchanges table, which for performance reasons on Wikimedia cannot be increased from 30 days worth of data.
  • Proposed solution: Create an external tool that works just like Special:RecentChangesLinked, except it extends beyond 30 days.
  • Who would benefit: Editors checking for changes on related pages.
  • More comments: It is very easy to forget to check 'Related changes' monthly. Extending it to a year would allow editors to keep a more relaxed overview of checking changes on related pages without worrying if they've missed anything important.
  • Phabricator tickets:
  • Proposer: MPF (talk) 21:21, 10 January 2022 (UTC)[reply]

Discussion

  • This would be a useful addition in two contexts related to categories, as "related-changes to Category:foo" gets me pages recently edited that are in or added to that cat...a form of watchlist for all articles in the category. One use-case is occasional vandal-pattern of adding incorect categories (one that comes to mind was adding a certain ethnicity to all sorts of inventions by anyone marginally associated with that geo-ethnic region). A second use-case is that I periodically check certain maintenance categories that are very full but non-trivial to fix, and use recent-changes to prioritize fixing based on which ones are popular (also catches recent edits that make mistakes...opportunity to educate/get-assistance-from those editors themselves). DMacks (talk) 21:46, 10 January 2022 (UTC)[reply]
    I think some related changes have a lot of links and some pages have a lot of small links, and some page can have unrelated changes for the article. I think we should only increase to 90 days and 1 year when the edits are low enough to ensure performance. The appliances of the idea is to categories, and other lists. Thingofme (talk) 03:05, 16 January 2022 (UTC)[reply]
  • Related changes uses the recent changes table to get its data, which is bound by $wgRCMaxAge. On the WMF cluster that's set to 30 days. I'm somewhat certain there's little chance of increasing that, or at least not without consulting the DBAs and/or the performance team first. I believe it used be higher but they had to reduce it for performance reasons, hence why I doubt they'd reverse that decision. Pinging ASarabadani (WMF) for input. MusikAnimal (WMF) (talk) 22:43, 10 January 2022 (UTC)[reply]
    @MPF: I have confirmed that making Special:RecentChangesLinked for 100 days is out of the question :( Amir may or may not reply here with more info, but my inclination is that if we want to take on this wish, it would probably have to be an external tool that queries the revision table. This means it won't be built into the interface like a Special page, and it might also be really slow to use. I'm not sure if that would satisfy this wish or not? If it would, could you reword your proposal to be about an external "related changes" tool? I don't want other !voters to be misled into thinking we could do something for Special:RecentChangesLinked. Thanks, MusikAnimal (WMF) (talk) 16:59, 11 January 2022 (UTC)[reply]
    @MusikAnimal (WMF): - thanks! That's a shame. What about a smaller extension? Even 50 or 60 days would still be better than 30 - MPF (talk) 17:22, 11 January 2022 (UTC)[reply]
    I'll let Amir reply to that, but as I understand it on some wikis like Wikidata, we may even have to reduce the RCMaxAge. Overall I'm still leaning towards an external tool if anything, since those are allowed to be slow. MusikAnimal (WMF) (talk) 17:27, 11 January 2022 (UTC)[reply]
    For 500 edits, it's ensure performances, but higher than 500 it is too slow to load. Thingofme (talk) 03:06, 16 January 2022 (UTC)[reply]
    It's not just the query runtime that's the problem, it's the size of the table. When it gets really really big, weird things happen. MusikAnimal (WMF) (talk) 04:00, 19 January 2022 (UTC)[reply]
    I would bet pages with higher numbers of results are loading slowly mostly due the client side (rendering the HTML), not the server side (querying the edits). 500 edits is still nothing compared to the size of the recentchanges table. ~~~~
    User:1234qwer1234qwer4 (talk)     22:04, 8 February 2022 (UTC)[reply]
    @MPF Is an external tool (not Special:RecentChangesLinked, but it would work in the same way), not an acceptable solution? If so, please reword your proposal accordingly. I can help, if you need. If the desire is solely for Special:RecentChangesLinked, then I'm afraid it's at the very least out of scope for our team. We can offer to put it in the Larger suggestions category so we can still gauge the popularity of the idea. You decide. MusikAnimal (WMF) (talk) 04:04, 19 January 2022 (UTC)[reply]
    I recall that, before Special:RecentChanges changed to the current interactive format, it was possible to see up to 91 days of changes? Am I recalling correctly? C933103 (talk) 12:14, 16 January 2022 (UTC)[reply]
    That used to be the default from 2007 till some point yes, but I think it changed quite a while ago, possibly even before wikidata was introduced ? —TheDJ (talk • contribs) 15:13, 16 January 2022 (UTC)[reply]
    Was there any documented reason behind such change? As undoing intentional changes would be out of scope for the community tech team. C933103 (talk) 08:08, 17 January 2022 (UTC)[reply]
  • In addition to the Proposed solution: An other possibility would be be to remove the time-border completely, and instead just keep track of the last say 250 edits.T.vanschaik (talk) 18:37, 18 January 2022 (UTC)[reply]
    @T.vanschaik and MusikAnimal (WMF): That would be a huge improvement - I checked one page I like to keep an eye on, and the current top allowed "Max 1,000 changes, last 30 days" only showed 11 related changes because of the 30 day time limit. So the last 250 related changes would actually cover the last two years or so - MPF (talk) 08:55, 19 January 2022 (UTC)[reply]
    @MPF I'm afraid that's not feasible, either. In order to accommodate the last 250 related changes of every page we'd have to increase the size of the recent changes table several times over. I'll ask one last time – would an external tool suffice? It would basically offer the same functionality as Special:RecentChangesLinked except allow you to go back any arbitrary number of edits or time period, with the caveat that you may need to wait up to say 30 seconds to get a result. If this is acceptable, I'll help you rewrite your proposal. Otherwise it needs to be moved to the Larger suggestions pile. Please advise on what route you'd like to go. Thanks, MusikAnimal (WMF) (talk) 15:48, 19 January 2022 (UTC)[reply]
    The number of 250 was just a proposal. On the other hand, the list could have two limits, one on the number of entries, again say 250, and one one the time elapsed since the edit, say one year. Whichever one is met first springs into action to remove the entry from the list.T.vanschaik (talk) 16:51, 19 January 2022 (UTC)[reply]
    @T.vanschaik and MusikAnimal (WMF): - I'm not sure how an 'external' tool would work? Otherwise, any shift of the current limits from 'high number, short time limit' towards more of a 'low number, long time limit' would help, whatever is feasible (even a max of 50 would be better if it allowed a more open-ended time limit) - MPF (talk) 00:34, 20 January 2022 (UTC)[reply]
    @MPF The external tool would more or less work exactly like Special:RecentChangesLinked does, except it would be external (i.e. hosted on toolforge.org and not usable within the on-wiki interface). Admins on your local wiki could add a link to the external tool so that it is easily accessible. The results this tool give you would match Special:RecentChangesLinked exactly, except it'd be able to give you more results, which I believe is what you want. Does that sound okay? MusikAnimal (WMF) (talk) 22:35, 20 January 2022 (UTC)[reply]
    Thanks! Yep, that sounds OK, if it can be made as easily accessible as the current 'related changes' link - MPF (talk) 22:43, 20 January 2022 (UTC)[reply]
    Okay, done! Thanks again. MusikAnimal (WMF) (talk) 18:40, 26 January 2022 (UTC)[reply]

Voting

Check if a page exists without populating WhatLinksHere

  • Problem: Does a wiki page exist? This should be a simple thing to check in a template or module, and it partly is – you can use the #ifexist parser function. However, due to the way that this has been implemented in MediaWiki, this has unexpected consequences: pages that call the templates/modules that do this check will now appear in Special:WhatLinksHere. These false flags cause significant problems for editors that are working on resolving misplaced wikilinks, such as links to redirects or disambiguation pages. That in turn leads to them objecting to the use of any template/module that checks for the existence of a page to see if they should link to it.
  • Proposed solution: Rework the MediaWiki database structure so that uses of #ifexist do not also appear in Special:WhatLinksHere – although this is not easy.
  • Who would benefit: Template developers who need to check if a page exists. Editors resolving disambiguation links on all wikis who don't want to see false links.
  • More comments: This is a perennial request to fix some long-standing technical debt. It has been proposed in the 2015, 2017, 2019, and 2021 wishlists. There is a work-around that uses page protection information, see en:Template:Linkless exists, but this isn't a long-term solution.
  • Phabricator tickets: phab:T14019 (from 2007), phab:T268526 (the wider database structure issue)
  • Proposer: Mike Peel (talk) 19:04, 14 January 2022 (UTC)[reply]

Discussion

This also causes a quirk at Wikisource. The proofreading statistics (how many pages exist, how many are proofread or validated, etc) for an index can be gathered using Lua. Obviously, this has to check that pages exist, which means registering a template dependency on every page in the index, existing or not so that if pages change status the stats are correct (note: the actual counts of page statuses in an index don't require to access every page). The upshot is that pages like the monthly overviews of things like the s:en:Wikisource:Monthly Challenge appear to transclude very very many pages, though they actually do not transclude a byte of content. There is an idea for a workaround to add an "approximate" mode to the stats function, which would dispense with the template link, but this would rely on pages using approximate stats to purge regularly, as changes to or creations of the pages would not cause an update. It would be better if there could be some concept of non-transcluded, non-linking dependency. Inductiveload (talk) 20:09, 14 January 2022 (UTC)[reply]

Procrastination is the #1 reason why the problem still has not been fixed despite requests from past surveys. People put things off all the time, so the developers put off implementing the required changes (in other words, they procrastinate). Next time, we should set reminders and deadlines so that the developers know to implement the required changes to prevent pages with #ifexist checks from appearing in Special:WhatLinksHere and stop procrastinating. GeoffreyT2000 (talk) 21:26, 14 January 2022 (UTC)[reply]

Why isn't en:Template:Linkless exists a long-term solution? Seems to me it would likely be a lot easier to make the #ifexist parser function use the "linkless exists" technique than to rework the MediaWiki database structure. I tried voting support below, but tired of the edit conflicts and it's not worth the waste my time to try voting again. Wbm1058 (talk) 20:45, 28 January 2022 (UTC)[reply]

@Wbm1058: It seems to work as a work-around, but having to ask 'what is the page protection' if you want to ask 'does this page exists' is fundamentally illogical. It also doesn't seem to be available via Lua (unless I've missed something). Thanks. Mike Peel (talk) 21:03, 28 January 2022 (UTC)[reply]
Because it's a hack. It works because of the peculiar behavior of the {{PROTECTEDEXPIRY:}} magic word, which might change at some point. Also not sure the caches are correctly updated when the page exists. Strainu (talk) 21:12, 28 January 2022 (UTC)[reply]
Well, I say just HACK AWAY! You'll get more satisfaction than waiting for the Cleveland Browns to appear in a Super Bowl. And if the developers are sufficiently annoyed by the hacks then that might just motivate them to fix it right. Wbm1058 (talk) 21:26, 28 January 2022 (UTC)[reply]
@Wbm1058, Strainu, and Mike Peel: Yes, it's a hack, or possibly an exploit of a data leak in MediaWiki. If you can think of a more elegant way to achieve this, please enhance the template! The Lua version was deleted per en:Wikipedia:Templates_for_discussion/Log/2018_October_10#Module:Linkless, but I have my original effort stored locally if anyone would like to use it in another module. Certes (talk) 19:45, 21 February 2022 (UTC)[reply]

Unexplained "oppose" comments such as that below are very unhelpful. There is nothing in them that can be addressed, nor that informs other editors of any problems that might have been identified. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:47, 9 February 2022 (UTC)[reply]

Voting

simple export of SpecialPages

  • Problem: There are special pages like ancient, lonely or what links here. If someone wants use this list for further work he must copy it, in some cases clean (e.g. in Special:AncientPages delete date or add [[]] or both) and then use. It would be useful, if this list can be exported as wikipage, plaintext, csv or json.
  • Proposed solution: Provide possibility to export specified number or all entries in special page.
  • Who would benefit: Maintenancers, experienced users, bot operators
  • More comments: This is possible using Petscan or Quarry, but needs more skills and not everything is possible. Petscan is easier to use, but probably not useful for creating list of lonelypages. query have more possibilities, but only few users know how to use it.
  • Phabricator tickets: phab:T248440
  • Proposer: JAn Dudík (talk) 09:54, 20 January 2022 (UTC)[reply]

Discussion

Voting

Shared talk page section for related articles

  • Problem: Often times, related articles (e.g. for various general elections in the same country) will re-use certain conventions, etc. (e.g. whether to treat a coalition as a single party or multiple parties). It is good to keep those conventions consistent among related pages. However, because it each article has its own talk page, it can be difficult to ensure editors of every page are alerted and able to participate in the discussion; this can result in the inability to gain consensus, or else create a false consensus.
  • Proposed solution: Create a feature which allows multiple articles to share a talk page section. When someone edits/updates the shared talk page section in one of the articles, the corresponding section of the talk page would update for all other articles contained the shared section of the talk page. (Perhaps having a shared talk page section would involve using a common category. Or perhaps it would use a tag hidden from people who read but do not write Wikipedia.)
  • Who would benefit: Editors would be the ones to directly benefit
  • More comments: Here is a real-life example of where I believe this would be beneficial. The infoboxes of articles on Australian elections treat the Liberal Party and the National Party as a single political party. I believe this should be changed so the infoboxes reflect that they are two different parties. Normally, I might propose on the talk page of "2019 Australian federal election" article to make this change. However, people who edit related articles (e.g. "2016 Australian federal election" and "2013 Australian federal election") are unlikely to see my proposal. (It would not be practical to post my proposal on the talk page of every article on an Australian election, and doing so could lead to branched debates/consensuses.)
  • Phabricator tickets:
  • Proposer: ROADKILL (talk) 21:46, 14 January 2022 (UTC)[reply]

Discussion

This can already be achieved via mw:Extension:Labeled Section Transclusion.--GZWDer (talk) 07:09, 16 January 2022 (UTC)[reply]

Voting

Centralized Incident Management

  • Problem: When reports about production issues are opened on WMF projects, it is difficult for those reporting the issue to know when the production issue is purportedly resolved.
  • Proposed solution: Expand the use case for Phabricator to include incidents and problem, instead of only tasks for solutions.
  • Who would benefit: Users
  • More comments: Phabricator states are really only used to indicate that software changes have been created merged, not that they have actually been deployed. People with issues are generally trying to open "incident reports" - not "software requests" - they are telling a user story, but their story doesn't end until the situation is no longer presenting to them.
  • Phabricator tickets:
  • Proposer: — xaosflux Talk 18:22, 10 January 2022 (UTC)[reply]

Discussion

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 the "best" but additional ideas are welcome below! xaosflux Talk 18:22, 10 January 2022 (UTC)[reply]

I think this is often implemented by having two different states, like To Deploy/Done. This way things that are fixed in code can be moved to To Deploy once they are committed, and to Done only when the change is live. It seems a very easy fix in technical terms, but probably big for developer workflows. MarioGom (talk) 08:18, 12 January 2022 (UTC)[reply]
Even a workflow like that may help, a user story or incident isn't "done" until the situation leading to it is actually usable. — xaosflux Talk 14:36, 12 January 2022 (UTC)[reply]
I do note that we have deploy labels on tickets WITH dates of when something starts entering production. It's just that this does not match the expectations of normal users where to look. Then again, closed is special state, which has all kinds of workflow affects that are generally rather important for developers, so splitting that in two in the software is not that easy. But I agree that it is confusing and especially if sometimes some WMF teams even deviate from what happens in most of the rest of the tickets. —TheDJ (talk • contribs) 16:22, 12 January 2022 (UTC)[reply]
I also agree it's awfully confusing. Those deploy labels can be wrong, such as this week when the deployment train was halted. To those who don't know: The most exacting way to tell is to (1) go to the Phab task (2) look at the linked Gerrit patches (3) on the gerrit patch, you'll see an "INCLUDED IN" link on the right above the list of files. That tells you what branches it lives on. (4) Go to toolforge:versions and see if the branch you need is on your wiki. Easy, right? :) Making that process easier is something worthy of a proposal on its own. Maybe a Phabricator extension or something, that talks to whatever it needs to in order to tell us definitively if it's live or not on a given wiki.
@Xaosflux There are a lot of good ideas here. At the very least I ask we expand on the "Problem statement" (i.e. "I have no way of knowing the fix for T12345 has been deployed", and then maybe expand on the proposed solutions. This year proposals get marked for translation, but for obvious reasons the comments do not. So to a non-English reader, they won't be able to infer much with what you have now :) Thanks for starting this conversation, and for participating in the survey! MusikAnimal (WMF) (talk) 05:09, 14 January 2022 (UTC)[reply]
@MusikAnimal (WMF): see above - better? I mostly understand the current phab process - but I'm certain 99%+ of users of our system do not - which is why I know this is a problem :) — xaosflux Talk 11:07, 14 January 2022 (UTC)[reply]
Better, yes! I may make a few tweaks for translatability but this otherwise looks good and is a great proposal. Thanks, MusikAnimal (WMF) (talk) 03:38, 19 January 2022 (UTC)[reply]

T280 and T88136 are somewhat related. --Tgr (talk) 00:02, 30 January 2022 (UTC)[reply]

Voting

The "tag name" on the change line should link directly to "tagged changes"

  • Problem: The tag on the change line currently looks like this:

        14:33 John Callahan's Quads! (diff | hist) .. (−12) .. Rng0286 (talk | contribs) (lorem ipsum) (Tags: Visual edit, Mobile web edit)

    The tag name is either a link to a help page or just plain text. It is not easy to find edits with the same tag.

  • Proposed solution: Change the tag display on the change line. The tag name should link directly to the "tagged changes" at Special:RecentChanges. For example: the tag "VisualEditor" would link to Recent Changes but showing only edits with the #VisualEditor tag (example), tag "Mobile web edit" links to example, etc. Like this:

        14:33 John Callahan's Quads! (diff | hist) .. (−12) .. Rng0286 (talk | contribs) (lorem ipsum) (Tags: VisualEditor, Mobile web edit)

    A new Special redirect could be introduced as well, such as Special:Tags/tag_name page that would redirect to Special:RecentChanges showing only edits with the given tag.

  • Who would benefit: All editors
  • More comments:
  • Phabricator tickets:
  • Proposer: Shizhao (talk) 07:09, 19 January 2022 (UTC)[reply]

Discussion

  • @Shizhao: Did you know you can find "tagged changes" through Special:RecentChanges? Look for the "Tags" button towards the right. See the English Wikipedia results for Visual edit, for example. Is this what you are looking for?

    I think it's sensible to link recent changes from the tag names in revision histories, as you are suggest, but then how would we ever show a link to the documentation for the tag? Special:RecentChanges doesn't have an intuitive way surface this (you can also filter by multiple tags). Also, if it wasn't clear, these links to documentation pages are defined in interface messages. Those could be updated by any admin to link to Special:RecentChanges for that tag, if there's consensus to do so. The "Visual edit" tag for instance is defined at en:MediaWiki:Tag-visualeditor. MusikAnimal (WMF) (talk) 21:28, 19 January 2022 (UTC)[reply]

    For pages which need/have the additional documentation, adding some text "help" or whatever would work. I would be more than happy to see, for example, the VE tag changed today just to demonstrate it's possible to do what is being suggested today. --Izno (talk) 23:04, 19 January 2022 (UTC)[reply]
  • I would love this! I have clicked these too many times and thought "gosh, I wish this actually took me to the list of changes with this tag". --Izno (talk) 23:04, 19 January 2022 (UTC)[reply]
    "find "tagged changes" through Special:RecentChanges" is another way, and it's a lot more troublesome than clicking the link directly. The tags also appears in watchlists, user contributions, and page history. Shizhao (talk) 02:45, 20 January 2022 (UTC)[reply]
    Great points! A link to see changes with the tag seems most intuitive, doesn't it. Well, let's see what people have to say! I also like the idea of serving some help text or what have you through the |title= attribute. I'm going to get this proposal setup for translation. MusikAnimal (WMF) (talk) 06:32, 21 January 2022 (UTC)[reply]
    I also did a little tweaking to the proposal that I hope is okay. Towards the end you were proposing a Special:Tags/tag_name page that shows only edits with this tag. Instead, I wrote it to utilize Special:RecentChanges for this purpose, which gives you many other features while still only showing the tagged edits. I hope this is okay :) Looking forward to seeing what people have to say! MusikAnimal (WMF) (talk) 07:18, 21 January 2022 (UTC)[reply]
  • see phab:T301063--Shizhao (talk) 08:36, 6 February 2022 (UTC)[reply]

Voting

Enhanced Move Logs

  • Problem: When a page is moved, the log entry is associated with the old page, and not the new page. In order to find what the history behind how a page ended up where it is, you may have to dig through the move logs of other pages first. This makes it difficult to determine prior titles for a given page.
  • Proposed solution: Include both the source and destination in move logs, integrate these in to log displays.
  • Who would benefit: Editors
  • More comments: This proposal page is a good example. The move log is empty, however the page was moved from a different title.
  • Phabricator tickets: phab:T66184, phab:T152829
  • Proposer: — xaosflux Talk 18:18, 10 January 2022 (UTC)[reply]

Discussion

Agreed This would be useful to find previous versions 'lost' from a Move action.Kaybeesquared (talk) 19:47, 10 January 2022 (UTC)[reply]
I think the movement of logs should be done, because of protection logs: When a page moved after protected, we only find the move log entry in the protection log; and logs from the old should be moved to the new pages. Thingofme (talk) 03:17, 16 January 2022 (UTC)[reply]
This has unintended consequences for users who undergo a rename... –MJL ‐Talk‐☖ 20:08, 13 January 2022 (UTC)[reply]
@MJL: I'm not seeing anything serious in that - first renames are not private, second this would only have affect if said user had a userpage, which if such userpage was moved by the globalrename job it already logs the userpage move in the history (example). Can you be more specific? If you think this is a security issue you can share by wikimail. — xaosflux Talk 21:04, 13 January 2022 (UTC)[reply]
@Xaosflux: All of what you said is true, but some people don't want it to be that public. You know when names are changed for privacy reasons? I'll email you when I get home about it. –MJL ‐Talk‐☖ 17:39, 15 January 2022 (UTC)[reply]
Someone with "privacy reasons" is best of changing their account to "Renamed user xxxx" and starting a new account. — xaosflux Talk 17:46, 15 January 2022 (UTC)[reply]
This is like an username violates the username policy. In this case, the log of global renaming should be revision-deleted or oversighted, and the new, fresh username would be allowed to function as normal names. Thingofme (talk) 03:18, 16 January 2022 (UTC)\[reply]
@Thingofme: I'm not going to get in to argument about deletion policies here, however if there is an extraordinary case where pages and logs are being suppressed, the move log would already be getting take care of and this proposal wouldn't change that. — xaosflux Talk 10:15, 16 January 2022 (UTC)[reply]
But the edit summary or reasons for the log would not be changed,... so the old page (with old names) are seen, which also may cause confusion. Thingofme (talk) 13:24, 16 January 2022 (UTC)[reply]
Changing the current behavior of the move function is as close to a bug fix as a requested new feature can be. If there is a general privacy problem, unrelated to this proposal, with traces created by user renames on Wikimedia projects, then it can be addressed separately for Wikimedia projects. As pointed out above, the revision history already contains an entry labeled "moved from A to B"; it is just pointlessly missing from the move log. ToBeFree (talk) 19:54, 16 January 2022 (UTC)[reply]
  • @Xaosflux: I tweaked the wording of the proposal a little bit that hopefully makes it more understandable. Please review and if you're okay with it, I'll ready it for translation. Thanks for the fine suggestion! MusikAnimal (WMF) (talk) 05:37, 14 January 2022 (UTC)[reply]
    @MusikAnimal (WMF): think something got lost in the massaging: I want to make it clear that I'm suggesting the log entry is associated with both pages, not to change it from being associated with the old page to the new page. — xaosflux Talk 10:58, 14 January 2022 (UTC)[reply]
    Actually that's ok, the "problem" doesn't need to say that, the solution already does - so go ahead! — xaosflux Talk 10:59, 14 January 2022 (UTC)[reply]
    I think the wordings of the proposal is like unclear, and we need to start by somethings. First of all, we need to move the logs (protection log, revdel log, patrol log, review log, creation log) to the new name, and won't be considered with the old name. Other logs WON'T be moved, and should be stayed in the old place. Thingofme (talk) 03:22, 16 January 2022 (UTC)[reply]
    So, right now the move log contains: timestamp, actor, frompage (target), topage, summary; however the Special:Log page only allows searching by the frompage - as if there is no index on the topage -- that's what I'm asking be added, then that can be integrated with Special:Log, and other places. — xaosflux Talk 17:42, 16 January 2022 (UTC)[reply]
This is an important question. As it turned out, moving is a risky operation and can be used for very strange purposes. Intervention may require administrator rights (double move example: wikt:eo:abio, wikt:eo:abio-PIRATAĴO - only this page is original and contains full revision history, wikt:eo:abio-DENOVA-PIRATAĴO), and in some cases even the administrator will not be able to do anything.
Move operations should have more control and analysis in the logs. For cases of cascading move or circular move with delete operation.
For the move result page, you need to be able to get a list of all sources.
For a move source page, you need to be able to get a list of all move result pages.
In both cases, references to the logged event are needed.
Anticipe pardonu aŭtomatan tradukilon, se ĝia angla lingvo estas ne tre kvalita (translate)
Va (🖋️) 11:30, 14 January 2022 (UTC)[reply]
This wish will not make the eo:wikt:PIRATAĴO mess easier to unravel. And, as I explained there, it is not the case that nothing can be done, even with the codebase as it is today. * Pppery * it has begun 21:21, 14 January 2022 (UTC)[reply]
To unravel and restore this particular example - yes, it will not help. But it will help to identify damage for in similar cases for manual recovery by re-entering data. And it can help identify similar cases, whether intentional or accidental. Va (🖋️) 09:23, 16 January 2022 (UTC)[reply]

Voting

Allow filtering of WhatLinksHere to remove links from templates

  • Problem: When using Special:WhatLinksHere, many of the results aren't in the body of the article, and are just from templates (especially navboxes) - this often makes finding results in the content of an article much more difficult than it needs to be.
  • Proposed solution: Special:WhatLinksHere already has (redirect) and (transclusion): add (template link), with a toggle to hide/show results that only link here from links in templates. Ideally, show the results nested in the same way that (redirect) links are - so if a template links to the article, show all articles beneath that.
  • Who would benefit: Editors (and readers) who use Special:WhatLinksHere.
  • More comments:
  • Phabricator tickets: phab:T301648
  • Proposer: --YodinT 19:46, 18 January 2022 (UTC)[reply]

Discussion

Voting

Automated "Top Viewed Articles" list on main page

  • Problem: "In the news" section on main page is good and curated, but a Top 5 or Top 10 list of most-viewed daily (weekly?) articles might more accurately reflect what people are searching for at any given time
  • Proposed solution: Dedicated section on main page to show either "Top Viewed" or "Hot" articles, either ranked or unranked
  • Who would benefit: The community
  • More comments:
  • Phabricator tickets:
  • Proposer: TheNewMinistry (talk) 21:14, 10 January 2022 (UTC)[reply]

Discussion

Voting

Poll Yes and No (on talk pages)

  • Problem: It is not possible to poll on Wikipedia talk pages for quick approval or disapproval, the purpose of the poll is to remove or add text to the article page or to move the article.
  • Proposed solution:
  • Who would benefit: All users will benefit from it
  • More comments: This feature is available on other social media such as liking or disliking a video on YouTube or a post on Instagram or a message on Telegram. The principle is to provide a quick way to agree or disagree so that the results can be quickly compared and concluded. You can even use this suggested tool and feature to disagree / agree with the latest edit in the article history section.
  • Phabricator tickets:
  • Proposer: Mohammad ebz (talk) 16:22, 11 January 2022 (UTC)[reply]

Discussion

  1. Should it be anonymous?
  2. Should it require authenticated participants? (Can "IP users" poll?)
  3. Should non-repudiation be present?
  4. Should it prevent someone from making multiple entries?
  5. Should someone be allowed to change their entry?
  6. Should the results be reliable?
  • Some existing things you could compare to are the SecurePoll extension, and the POTD voting process. — xaosflux Talk 15:35, 12 January 2022 (UTC)[reply]
    The principles that I follow in this survey model are as follows:
    - Simplicity in the poll (for both the organizer and the commenter)
    - Speed in voting (for both organizer and commentator)
    - Use to agree / disagree with a comment or edit or act or move the article on discussion pages
    - Poll on a public topic on talk pages
    - Put this tool in the wiki editing environment
    Note that this proposal is a prototype and requires more brainstorming (it may even be an improved version of previous tools)
    1. In important cases where an action is to be taken, it must be anonymous, and in cases where it is not of significant importance, it can be anonymous.
    2. Based on what I had in mind, it is better to do the survey only on the basis of registered users, although in cases where it is only a non-action and personal survey, I do not see the need to restrict IP users.
    3. It is not mandatory, but it is better in the form of non-repudiation
    4. The poll I had in mind was two-choice or three-choice and you have to choose one choice, but having a multi-choice poll can be a positive point of this tool (unlike the name of the suggested tool)
    5. Have the right to change the choice in the poll within the specified time (during the discussion on the subject and achieve the results)
    6. In non-private or non-action cases, it is necessary for the results to be accurate and reliable
    Finally, it is important to add a simple yet effective poll tool to the Wikipedia environment or other projects. At present, a tool that has the basic conditions in a simple and accessible way for everyone has not been implemented. (Although there are tools, they do not have good access and simplicity) Mohammad ebz (talk) 17:15, 12 January 2022 (UTC)[reply]
For that to be useful, you should be able to set a condition on who can vote, for example, on the hebrew wikipedia there is a rule that you need to have 100 edits during the last 90 days to vote, so for wikis like this one you need a way to set a limit. Maybe on the mediawiki space that has a code which makes some people unable to vote... Omer abcd (talk) 16:18, 12 January 2022 (UTC)[reply]
  • Oppose. I don't think wikipedia editing decision should be made by simple votes. Reason and rationale behind should be the more important factor.C933103 (talk) 23:56, 15 January 2022 (UTC)[reply]
  • Oppose an extremely bad idea. This is the direction we should be moving away from. The goal of a discussion is to reach consensus, not and voting aligns people on opposite sides, with a losing position and a winning position. This already happens a great deal too much. The only processes that need voting is when there is an actual competition, as in elections to arb com, and a specific decision of some definite sort must be reached. We've ben struggling for years to keep established the principle that AfD discussions, for example, must reach consensus, not count votes, and that's true for most AfCs also. We don't decide content by voting, but consensus. DGG (talk) 06:15, 16 January 2022 (UTC)[reply]
  • Support. Consensus is a laudable goal, a founding principle of Wikipedia, not to be abandoned. In practice things are more complex. Just as polls are subject to abuse by majorities, consensus is subject to abuse by the loud, the persistent, the well-connected. In practice, true consensus here is surely a rare thing. Minorities are overruled and silenced, as well as persuaded. If used properly, a poll is just a tool to gauge temperature - transparently. If consensus is really the objective, then we should not fear transparency. Rollo (talk) 20:45, 16 January 2022 (UTC)[reply]
unfortunately in practice I fear that this will tend to over-ride minoritiesand diminish the chance for a full discussion. DGG (talk) 02:14, 17 January 2022 (UTC)[reply]
  • Oppose - Vote counting instead of reaching consensus is a very bad idea. On hiwiki we have been trying to discourage use of those 'support' and 'oppose' templates in such discussions where consensus is very crucial in discussion-and-decision making process. --SM7--talk-- 14:51, 28 January 2022 (UTC)[reply]

Voting

Users should have the ability to directly report a bug, from the user interface

  • Problem: Bugs occur; some are trivial to fix, others are longer. I think what would be important is to have a menu item, that allowed to directly report a bug. This would cause a wizard to pop up, and the user could enter more infos about the bug; perhaps a screenshot could be added. In any case, the source page, from where the bug was reported, would be stored.
  • Proposed solution: Bug-reporting wizards as described. More bugs reported, more fixed, more stable software
  • Who would benefit: Users, developers.
  • More comments:
  • Phabricator tickets:
  • Proposer: Eptalon (talk) 21:21, 19 January 2022 (UTC)[reply]

Discussion

  • Surfacing "help me, where do I tell someone something broke" does seem like something that could be generally improved about the wiki UI. --Izno (talk) 23:05, 19 January 2022 (UTC)[reply]
  • Absolutely agreeing with this. We cannot expect new users to create a Phabricator account and create/follow a thread. It is quite surprising that there is no button at the bottom of each wiki to alert about interface problems. Xavier Dengra (MESSAGES) 00:10, 22 January 2022 (UTC)[reply]
  • We tried this with MediaViewer and it didn't work well - most bug reports weren't useful. (T111112) It's kind of the equivalent of allowing everyone to upload photos they took with their mobile phones - sounds nice in theory, but lowering barriers is not automatically a good thing. It might be fixable with better UX but certainly not as simple as just putting up a dialog window. --Tgr (talk) 23:54, 29 January 2022 (UTC)[reply]

Voting

Rolviki℟ 16:38, 14 June 2022 (UTC)[reply]

Allow to batch expensive queries

  • Problem: There is a limit of 500 "expensive" functions, most notably "IfExist" and "PagesInCategory". Internally, "IfExist" can be batched and is thus not expensive. The limit causes problems for some wikis, most notably wiktionaries. Raising the limit for a single wiki is technically possible, but reliably getting rejected due to performance and precendent effect. A better solution giving a higher limit without higher consumption of processor performance on the servers is needed.
  • Proposed solution: Add a LUA function providing batched access to at least "IfExist" (and "PagesInCategory" too if possible and useful).
  • Who would benefit: template and module developers, users
  • More comments:
  • Phabricator tickets: phab:T278629
  • Proposer: Taylor 49 (talk) 22:51, 22 January 2022 (UTC)[reply]

Discussion

Voting

A wiki page can have over 500 wikilinks, and they will be blue or red as expected. This is the better way, but it's "internal" for now. I have tested this. Taylor 49 (talk) 23:59, 2 February 2022 (UTC)[reply]

Improve WikiHiero

  • Problem: WikiHiero is an extension which handles the rendering of hieroglyphs. It could be improved in several ways, by order of priority:
    1. Enable the use of WikiHiero inline (currently it displays as a block, triggering line breaks before and after the hieroglyphs).
    2. Replace old rough PNG images by new neat images, either in PNG or (what would be better for future development) in SVG. The new images can consist in the glyphs of a free font (like Noto Sans).
    3. Enable more formatting : especially "font-size".
    4. Fix some mismatches between WikiHiero and Unicode/Manuel de Codage.
  • Proposed solution:
  • Who would benefit: Editors and readers of articles and books on Ancient Egypt.
  • More comments:
  • Phabricator tickets:
  • Proposer: ElioPrrl (talk) 10:10, 20 January 2022 (UTC)[reply]

Discussion

Voting

Allow to see newcomers edits when they ask question

  • Problem: When someone asks a question to a tutor (I don't know how this function is called in English) I often want to see if the question is first thing the user did, or if he has some edits. Sometimes the users ask "I've created a page in my sandbox" (without a link) and i order to see that page, I need to copy his username and click my edits and change the url. It would be nice to see, on the discussion page, a link to his edits.
  • Proposed solution: Not sure, maybe additinal link inside user sign added by ~~~~ when user ask a question using newcomers feature.
  • Who would benefit: Mentors, Tutors for newcomers
  • More comments:
  • Phabricator tickets:
  • Proposer: Jcubic (talk) 11:34, 12 January 2022 (UTC)[reply]

Discussion

  • Why not click his name to go to his userpage and choose "User contributions" from the Tools menu ? —TheDJ (talk • contribs) 11:55, 12 January 2022 (UTC)[reply]
    @TheDJ: most newcomers don't have a user page yet, but it works on the discussion page as well. I didn't know about this feature. I don't use the Tools menu that much. Maybe I should pay more attention to that menu. Jcubic (talk) 18:50, 7 February 2022 (UTC)[reply]
    Sometimes, it can be inconvenience, but the signatures of questions can have direct contributions link. Thingofme (talk) 02:52, 16 January 2022 (UTC)[reply]
    Hello,
    The Growth team identified this issue as one related the Newcomers Homepage. At wikis where the community decided to create a list of mentors who support newcomers' first steps, newcomers can ask questions to their mentors through the homepage. This feature creates a new topic on the mentor talk page, as Jcubic described. An easier access to newcomers' contributions is now tracked on Phabricator (T300630) and we will triage it soon.
    In the meantime, the Navigation popups gadget could be helpful. It available at en, pl and commons, where Jcubic is active. If you haven't yet turned it on, this gadget aims to simplify access to frequently needed features and links, including user contributions.
    Best, Trizek (WMF) (talk) 13:31, 7 February 2022 (UTC)[reply]
    @Trizek (WMF): I've tried Navigation popups gadget, it's interesting. But unfortunately it don't work very good when hoverig on users pages. It seems that it only works on normal pages, since history just return error, when userpage is missing. The only link that is usefull in this gadget is discussion, but that one is in signature.
    Maybe the solution is to create Gadget that will work on usernames or update Navigation popups to work with them.
    I will try few things maybe I will came up with better solution. The problem is stated, maybe somethig can be done to improve working with Newcomers. Jcubic (talk) 18:50, 7 February 2022 (UTC)[reply]
    @Jcubic, have you checked the Phabricator ticket I refer to? DO you think it would be the solution you need to work with your mentors?
    In any case, if you have any question regarding Growth tools and mentoring, please tell us! :) Trizek (WMF) (talk) 19:01, 7 February 2022 (UTC)[reply]
    @Trizek (WMF): Just checked the ticket, if this is implemented it would improve the workflow, but clickig on dicussion and using tools menu is that that hard. But if there was link to contribution it would be much better. I will check Growth discussion, maybe will have some ideas how to imrove. Jcubic (talk) 19:24, 7 February 2022 (UTC)[reply]

Voting

What is really done by the team of the Wikipedia Library with partner suggestions

  • Problem: Users can add and vote for new partners to be added in (the already quite great) Wikipedia Library. But then no info is given to the users about what the Wikipedia Library team is doing about the suggestions! Has the team emailed the suggested partner? Did they call someone at the partner office? Did they receive any answer? etc.
  • Proposed solution: Create a simple table (?) explaining what has been done (+ add dates) by the Wikipedia Library team in the suggest page.
  • Who would benefit: Every user who has taken the time to vote and/or to suggest a new partner for the Wikipedia Library.
  • More comments: note: I am not convinced that all the details of the negotiations need to be publicly known, but at least that something was done.
  • Phabricator tickets:
  • Proposer: Jurbop (talk) 09:09, 23 January 2022 (UTC)[reply]

Discussion

Jurbop: This team, Community Tech, at the most, can only improve the interface. They can not respond for another team, that is phab:T240166--Snævar (talk) 10:26, 23 January 2022 (UTC)[reply]

Hello, Thank you for your answer. Jurbop (talk) 07:01, 24 January 2022 (UTC)[reply]
@Jurbop: Thanks for the suggestion! One approach we started taking for this, which wouldn't require us to make significant changes to the suggestion page, was to have a Phabricator board which tracks the progress and enables us to post updates. We could then (theoretically, we didn't do this yet) link those tickets to the suggestion page. You can see our trial of this at https://phabricator.wikimedia.org/project/view/4808/. It's out of date and doesn't have every suggested resource, but if it was up to date and prominently linked from the library suggestion page, do you think this would help make things clearer? Samwalton9 (WMF) (talk) 09:37, 24 January 2022 (UTC)[reply]
Hello @Samwalton9 (WMF), That would be great! Thank you very much Jurbop (talk) 09:40, 24 January 2022 (UTC)[reply]
OK great, I've filed T299883 to track the more specific solution. Samwalton9 (WMF) (talk) 09:57, 24 January 2022 (UTC)[reply]

Voting

Global signatures

Discussion

  • I think it's a great solution for global patrollers and some cross-wiki; as they can use their custom signatures when talking for other people. Thingofme (talk) 08:40, 14 January 2022 (UTC)[reply]
    • We already have global user pages that autotransclude to local wiki rights ? How much does this really add on top of that ? —TheDJ (talk • contribs) 09:21, 14 January 2022 (UTC)[reply]
      This is a global signature, not a global userpage. We have used a global userpage already, but no global signature (with some language variants) Thingofme (talk) 11:22, 14 January 2022 (UTC)[reply]
      I know, but why do they NEED it ? or do they just like it ? It doesn't seem essential for communication at least. —TheDJ (talk • contribs) 15:44, 16 January 2022 (UTC)[reply]
      @TheDJ: seems like a nice-to-have. Many users customize their signature, and also edit on many projects; having to copy/paste their custom signature to each project can be annoying. For many, they will probably just break things with this - for example by not using the cannoical namesapce names for "User" / "User talk" in such a global signature when updating it from a local project in another language. — xaosflux Talk 20:24, 16 January 2022 (UTC)[reply]

Voting

Structured user pages

  • Problem: Users currently don't have structured user pages/profiles
  • Proposed solution: Allow for the possibility of structured user pages
  • Who would benefit: New users specifically, everyone generally
  • More comments: Currently users start the Wikimedia journey with a blank user page/a red link. This creates confusion among new users which have to learn the differences between the account and the user page, both concepts which can exist independently of each other in MediaWiki. Most new users, coming from the social media era, expect to find "a profile" when they create an account, a premade structured user page that showcases some basic information, maybe their contributions/achievements or even a way to easily reach into their preferences. The idea was entertained a bit in the Growth initiative with the homepage update but was deemed a bit hard to follow through currently. Having the possibility of structured user pages (maybe starting by expanding the functionality of the homepage tab) would not only help in alleviating the confusion the current system creates on new users (witnessed it first hand in many wiki-workshops) and help them actually have a profile other than a page with the text "Hello!" at most, but it would also help in bringing more integrity to the account itself, possibly suppressing the multiple fake account creation process by one user, given that an account would appear to be more than a "random red link" then. More detailed information can be found in this conversation where the idea is discussed more thoroughly in a brainstorming way.
  • Phabricator tickets:
  • Proposer: Klein Muçi (talk) 01:10, 20 January 2022 (UTC)[reply]

Discussion

See phab:T173145.--GZWDer (talk) 21:15, 21 January 2022 (UTC)[reply]
@GZWDer, I did read what you just linked to but I'm not sure if it is really related to what I'm proposing above. Can you elaborate on that please? - Klein Muçi (talk) 22:30, 21 January 2022 (UTC)[reply]

I completely support efforts into this area, there is an urgent need for that! I expect, the disorder and non-existing usability to build social infrastructure might be the main issue that leads to loss of newcomers and especially female authors (gender-gap). Males might suffer under this as well, but maybe they're more able to compensate this in any way than women. I don't know whether situation in DE:wikipedia is the same as in other languages, at least from my perspective there are two central nodes to establish a functional social infrastructure: Perspective 1: Wikipedia:Babel might be a great tool to build your own social profile (not only about languages). However, for newcomers it is hard to understand how to build your own babel/contribute new babel-parts. And, you can't search for user attributes easily that babel data actually provide. I guess it should be possible to overcome this, if somebody really takes work into this. Perspective 2: Category:Wikipedia user space actually provides information as a social network. However, it honestly NOT seems like this. An intensive maintainance/administration of those category-pages could qualify them to a very efficent social infrastucture. Not to talk about funny cats, it is needed to find authors with similar interests to work more efficent together and to avoid the feeling that you're surrounded by cold bots just revoking your edits... should I make a new propose for that or could it become combined with the proposal here?--Max schwalbe (talk) 09:34, 23 January 2022 (UTC)[reply]

Hello @Klein Muçi -- thank you for proposing this! I'm the product manager for the Growth team, and I just wanted to say that we agree that a structured user page would be helpful for newcomers. We think it will allow them to build an identity on wiki that will help others trust them, and make them more likely to stay engaged. I'm going to link this wish to the project page where we considered this project. We still do want to build it one day, but have prioritized other work for newcomers. I'll be sure to contact you to follow along if we return to the idea. MMiller (WMF) (talk) 04:45, 31 January 2022 (UTC)[reply]
@MMiller (WMF), glad to read that. Ever since I've joined Wikimedia (8 years ago), 2 were the things that have baffled me:
  1. I have to somehow sign every comment?!
  2. Where's my profile?!
The first concern has been taken care of lately, so I feel strongly about the 2nd one now. I'd appreciate knowing more about this in the future. :) - Klein Muçi (talk) 11:07, 31 January 2022 (UTC)[reply]

Voting

Enable redirects for Lua modules

  • Problem: Moving a Lua module currently never creates a redirect at the old title, thus breaking links to the old title.
  • Proposed solution: Enable redirects for Lua modules, with return require('Module:Target') making a Lua module redirect to "Module:Target".
  • Who would benefit: Users moving Lua modules
  • More comments:
  • Phabricator tickets: T120794
  • Proposer: GeoffreyT2000 (talk) 02:22, 16 January 2022 (UTC)[reply]

Discussion

Voting

Support more OSM relation types in Extension:Kartographer

  • Problem: The Kartographer extension can only display OSM relations of type multipolygon, route, and boundary on maps. Other relations like waterway, superroute, network etc. can not be displayed. That limits what can be displayed on interactive maps in Wikipedia and other projects. It would be nice to able to display e.g. rivers and long hiking trails automatically in infoboxes.
  • Proposed solution: Add support for more, or ideally all, OSM relation types in Kartographer. Especially waterway relations (typically rivers) and superroute relations (typically international routes) would be nice to display.
  • Who would benefit: Readers of wiki pages in Wikipedia and Wikivoyage which can be improved with interactive maps displaying OSM relations which are now unsupported.
  • More comments: OpenStreetMap (OSM) have free geodata for most geographic features in many parts of the world. It can be a big help for many Wikipedia articles and Wikivoyage to have access to these data to generate interactive maps showing their topics. I made same proposal in 2021.
  • Phabricator tickets: T156433
  • Proposer: Dipsacus fullonum (talk) 15:26, 22 January 2022 (UTC)[reply]

Discussion

Voting

Article ratings

  • Problem: Often an interesting and significant article with scientific, educational and simply informative content is marked as insignificant and its relevance is questioned.
  • Proposed solution: To determine the interest of users, enter a rating similar to the likes of social networks - with positive and negative ratings. Based on them, and not on the personal subjective opinion of some "experts", determine the need for an article. If Wikipedia is for the people, then the people, and not low-contact "gurus" should be able to influence what they want to know.
  • Who would benefit: The implementation of the proposed idea will certainly be useful to Wikipedia users, who will be able to find the information they are interested in, even if it is incorrectly formatted.
  • More comments: It's sad that potentially useful articles can be destroyed, while really uninteresting articles about rock musicians, athletes and show business figures stick out of Wikipedia like overcooked dough from a saucepan.

    It is necessary not to delete the information of informative articles that, for various reasons, were compiled ineptly, but to help improve them.

  • Phabricator tickets:
  • Proposer: Byzeterna (talk) 22:39, 15 January 2022 (UTC)[reply]

Discussion

Voting

Kartographer icon improvements

Icons urgently needed for Wikimedia maps
Some icons currently available, but of little use to Wikimedia maps
Currently, a skyscraper is an office, a capitol building is a town hall, a hotel is a bed, a church is a cross, and banks are credit cards?
  • Problem: There is no one clear set of icons dedicated to Wikimedia maps. Three things need to happen – (1) an established set of icons particular to Wikimedia mapping needs, (2) the rewriting needed in order to add this set of icons, and (3) better support to more easily add and modify icons in the future.
  • Background: Kartographer-based Mapframe maps work wonders to easily show maps in Wikipedia infoboxes and beyond. However the mapping tool really suffers from a lack of identifying icons. Especially for maps that show numerous features, editors are having to be creative to come up with icons that just barely associate with their topics. This is because MediaWiki uses an obsolete version of Maki icons, but even that still wouldn't fix all the problems relevant to Wikimedia spaces. The Maki icon set was designed for maps, though not for Wikimedia. Therefore it has numerous icons useless to Wikimedia spaces, and lacks icons essential to mapping here. There are at least 11 unclear icons, and at least 47 missing icons key to mapping here.
Other problems include, for accessibility, making more options for legibility. Right now, icons only display white. Icons should be able to be at least colored black, if not more colors, for increased contrast when the marker color is set to a lighter color. Markers should also have options for shapes other than the default teardrop shape, to allow for differentiation when using grayscale maps and for people with low color recognition (see task T131618).
  • Who would benefit: Innumerous Wikimedia spaces, primarily Wikipedia and Wikivoyage, but including numerous unique projects like Wiki Loves Monuments and Wiki Loves Earth, which need good mapping.
  • Proposed solution: Developing an additional entirely new set of icons, including many of the below missing or unclear examples:
Part one: coding
  • Code to allow for easy icon additions and improvements. This needs to happen now, and likely as Kartographer becomes more widespread on WMF projects, future changes will be necessary.
Part two: icon/marker formatting
  • Icons, currently only available in white, should be available at least in black as well, for increased contrast when marker-color is set to a light color
  • Markers should have more shape options behind the tear-drop shape.
Part three: fixing unclear icons
Part four: adding missing icons
(tracking for infoboxes here)
  • More comments: The above set of icons proposed are only ones I have found immediately relevant; others in the current Maki set or elsewhere may prove to be as well. Careful care needs to be taken to ensure a non-Western view, as some instances of map icon bias have already been pointed out.
How this should best be solved needs investigation, whether it be adopting later Maki items, WMF or community creating new icons, utilizing existing free Commons files, or a combination of those options. Nevertheless, the technical function of adding and modifying icons needs to take place.

Discussion

This would be a relatively easy service to build (and one I actually have on my very long term todo list), now that Kartotherian is no longer so strictly coupled with everything. The hardest parts are versioning and numbered poi's. My current design looks like: 

/marker/default-icons
/marker/maki/v3/original-icons
/marker/maki/v7/other-icons
/wmf/v1/othericons

Where default icons then maps a name to a more specifc icon of a styleset. Then from the geojson, you can refer to: tenniscourt for the default or "maki/v4/tenniscourt" for instance for another set. And you could refer to pog-red or wmf/v1/pog-red. It also needs a rewrite/update of the makizushi compositing library to put icons and marker images together. It would be relatively easy to do, but does take some time. —TheDJ (talk • contribs) 12:30, 12 January 2022 (UTC)[reply]

Thanks, @TheDJ:. I hope this can move to a more short-term to-do list, because it's definitely been a barrier for many users. I've encountered a good amount of opposition to mapframe because of poor design - this would be a huge plus for many users to switch over. Ɱ (talk) 04:07, 13 January 2022 (UTC)[reply]
Can you link these four icon sets so I can see what is suggested but not in them? And what could be the process to add new icons? I can design new icons, but would need a way to add them in. Ɱ (talk) 04:23, 13 January 2022 (UTC)[reply]
For mapframes, there are OpenStreetMap, which contains different information about the location. I agree with the icon that's not very good. Thingofme (talk) 02:53, 16 January 2022 (UTC)[reply]

Don't forget that Wikivoyage exists with comments like 'these can't be used for Wikimedia' ;). --Izno (talk) 22:34, 18 January 2022 (UTC)[reply]

Is this referencing my image caption? I use and edit Wikivoyage too, and don't see how those highlighted icons could be useful for that project. Ɱ (talk) 03:39, 19 January 2022 (UTC)[reply]
Not sure if any multi-project nominations are divided up that way, have you found any or any rule for it? Ɱ (talk) 03:39, 19 January 2022 (UTC)[reply]
Multimedia does not mean "images and video" and that's the part I think this falls under. Izno (talk) 04:41, 19 January 2022 (UTC)[reply]
What about having POIs that show number above 99? This is one of most annoying thing on those icons. --Andyrom75 (talk) 20:10, 28 January 2022 (UTC)[reply]

Voting

Show nearby or related articles in maps

  • Problem: Mapframe is now used in over 1.5 million categories on Commons to display the area that the category covers through the coordinate on Wikidata and the layout of the corresponding item on OpenStreetMap (via commons:Template:Wikidata Infobox) - as well as being used on many other Wikimedia projects. However, it is not currently possible to automatically display related items in the map. Ideally, it should be possible to show items linked to through has part/P527 in the map and/or nearby items (using the example of commons:Category:Teide Observatory)
  • Proposed solution: Have an option that shows the nearby/"part of" items in the maps.
  • Who would benefit: Readers and editors that see a map on Commons and other wikis who then want to explore nearby items.
  • More comments: This proposal was also posted in the 2019 wishlist. Ideally this functionality could also be used in Special:Nearby to show a map of nearby objects rather than a list (As community-requested in 2017. Wikishootme is a current example where nearby Wikipedia articles and Wikidata items are shown on a map (along with Commons photos), but that is on the toolserver rather than built in to Mediawiki.
  • Phabricator tickets:
  • Proposer: Mike Peel (talk) 20:33, 15 January 2022 (UTC)[reply]

Discussion

Voting

Wikiversity Seminars

  • Problem: Wikiversity lacks interactive features for students. Traditional classroom courses feature instructor questions and answers and topical classroom discussions. This interactive access to instructors, discussion leaders, and other students is missing from Wikiversity and diminishes the utility of the platform.
  • Proposed solution: Provide a mechanism, optionally linked from Wikiversity courses, that allows conscientious students and educators to schedule a video chat session, invite others to participate, or join a scheduled session.
  • Who would benefit: Wikiversity students, content creators, and those wishing to lead discussions based on Wikiversity learning resources.
  • More comments: A structured method to schedule a zoom (or other existing video chat system, preferably one that allows free access) session would be sufficient. There is no need to develop a new video chat service.
  • Phabricator tickets:
  • Proposer: Lbeaumont (talk) 15:15, 12 January 2022 (UTC)[reply]

Discussion

Voting

Create universal routinformationcode for railways, roads, etc in Wikidata

  • Problem: In nearly every language wiki there is a system, to show a route diagram of the line/route. examples: nl:Spoorlijn Amsterdam - Elten (traject in the infobox), de:Bahnstrecke Amsterdam–Arnhem (verlauf) and en:Amsterdam–Arnhem railway (route map). The first problem is that the language wikis dont use the same symbol set, so it is imposible to copy and paste from one langauge to an other. This causes a lot of duplicate work. It would be more efficient to maintain the information in one place for al the languages. Only descriptions and comments differ by langauge. However placenames can be standardized with Wikidata.
  • Proposed solution: *First and prerequisite fase: standardise the symbolset so it can be used in all langauges.
  • Second: Standardize via Wikidata the definitions of the routes. In principle the railway lines should be defined in the main language wiki of the country. For example: Dutch railway lines are defined by NL wiki, the German railway lines by de wiki. Today all wiki's have the freedom to divide up the railway network in line articles as they see fit. There are some conventions: For example read: Commons:Category:Railway lines in Belgium. In the Netherlands this is based on historic lines. example: nl:Spoorlijn Utrecht - Kampen (Kampen - Zwolle in today's rail network is not logicaly connected with Zwolle Utrecht)
  • Third. make a central repository. I dont know where. It could be in Wikidata connecting all the elements of route, but it may be to much 'content' for wikidata. Maybe better as special type of file in the Commons. It has to be defined flexibly. It should be posible to use only part of the route. From point A to B. Some wiki's use a simplified version and not the most complete in the repository. Wiki?s should be able te specify that they dont need certain elements (for example all road and river crossing, or eliminate all references to historic lines, junction etc to show the line as it is today)
  • Who would benefit: Editors of articles, who can copy over the route information from other languages or central repositry in (wikidata?). Updates can then be done centraly.
  • More comments:
  • Phabricator tickets:
  • Proposer: Smiley.toerist (talk) 15:52, 13 January 2022 (UTC)[reply]

Discussion

  • So you want a language syntax to describe railways ? Then parse that language and generate a diagram. Doesn't something like such a language t already exist somewhere ? Might be easier to reuse something than to invent something. —TheDJ (talk • contribs) 15:20, 16 January 2022 (UTC)[reply]
    I guess something that builds on the syntax of e.g. en:Wikipedia:Route diagram template, so not a whole new language. I can see the attraction of centralizing such route diagrams in a MediaWiki extension, but then the task of unifying all wikis' ideas of how the diagrams should work feels like a big task! The issue I see with using Wikidata as the central repository is that it doesn't (as far as I know) model things like every bridge and crossing, every junction, etc. SWilson (WMF) (talk) 02:47, 21 January 2022 (UTC)[reply]
  • This seems doable without any technical work. --Izno (talk) 22:25, 18 January 2022 (UTC)[reply]
  • The <translate></translate> tags are currently not rendered correctly here. I have created Community Wishlist Survey 2022/Translation/Make "translate" tags always render correctly for addressing this issue. GeoffreyT2000 (talk) 15:14, 22 January 2022 (UTC)[reply]
  • The symbols for RDTs are already organised at the WikiProject BSicon on Commons and are the same for every Wiki. The problem is that different Wikis use different styles, the Dutch Wikipedia for example has a very detailed representation almost like a track map while most others only show the railway lines (and still differ in many details). If we tried to create universal template, the first step would be to find a consensus throughout all Wikis on how RDTs are supposed to look like.
    Today all wiki's have the freedom to divide up the railway network in line articles as they see fit. That's not the whole truth. Many operators have defined where their railway lines start and where they end. I know that there are many cases where the articles don't align with the official lines but in theory Wikipedia can't make things up that don't exist and call something a railway line that isn't. In practice different Wikis have very different opinions on how to organise their articles. The idea of letting the local Wiki decide what the "correct" line is on Wikidata is not possible. A Wiki can't decide what another Wiki should do and I'm very certain that this will lead to many conflicts. --PhiH (talk) 08:13, 4 February 2022 (UTC)[reply]

Voting

Fix export at wikibooks to PDF, MOBI, ...

  • Problem: Export of Wikibooks to PDF stopped working and this problem is neglected.
  • Proposed solution: Fixing the broken feature + adding one-click export of the book.
  • Who would benefit: Anyone with intermittent access to Internet for various reasons (expensive connection, privacy etc.) I myself had an idea to start such a project on Wikibooks, where (a) many people could add their two cents, (b) young readers' privacy is advised so they could download the document and read it offline away from their parents or friends but absence of offline export - prevented me from using Wikibooks.
  • More comments:
  • Phabricator tickets:
  • Proposer: Voxhumana (talk) 16:45, 22 January 2022 (UTC)[reply]

Discussion

Voting

Get WhatLinksHere's lists in alphabetical order

  • Problem: In Special:WhatLinksHere, having all the results in an apparent random order is of no help. When orphaning a page in order to correct wikilinks or titles, you can get stacks of articles with similar titles and likely to be related to a specific subject that one can (if need be) keep in or out of user's check: having these stacks well packed would be of great help.
  • Proposed solution: As per title: alphabetical order is an order at least... and the fittest I can think of.
  • Who would benefit: Any editor engaged in Orphanage projects.
  • More comments:
  • Phabricator tickets: phab:T4306
  • Proposer: Pequod76(talk) 21:35, 19 January 2022 (UTC)[reply]

Discussion

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2022/Miscellaneous&oldid=22829015"