Jump to content

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

  • 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

  • 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

  • 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