Wikimedia Meta-Wiki

Community Wishlist Survey 2022/Miscellaneous

< Community Wishlist Survey 2022
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[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[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[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[reply]
    • @MusikAnimal (WMF): Thank you comment. The explanation was a shortage, so been maked misunderstanding this explanation. I add that when a link in the text (it's not wikilinks of sidebar), this problem is the occurs.--Mario1257 (talk) 17:58, 22 January 2022 (UTC)Reply[reply]
      I understand now! Thanks for the follow-up. I'm going to get this proposal moved into the survey so it can be voted on. Regards, MusikAnimal (WMF) (talk) 22:41, 25 January 2022 (UTC)Reply[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[reply]
  • Comment Comment Can't the function of this idea be replaced by In other projects on the left? --Liuxinyu970226 (talk) 11:27, 29 January 2022 (UTC)Reply[reply]
  • The Interwikimap would need to be expanded massively to achieve this. C933103 (talk) 15:02, 6 February 2022 (UTC)Reply[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[reply]

Discussion

  • I do not understand this proposal. Maybe an example would help. · · · Peter (Southwood) (talk): 07:23, 11 January 2022 (UTC)Reply[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[reply]
    Would this system message just display automatically/bot generated information? · · · Peter (Southwood) (talk): 04:38, 12 January 2022 (UTC)Reply[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[reply]

If you means edit notice in edit mode, see phab:T201613.--GZWDer (talk) 22:01, 12 January 2022 (UTC)Reply[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[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[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[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[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[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[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[reply]
  • I support this, although I think it might be even better if section links were given a section of their own in the list.--YTRK (talk) 12:12, 22 January 2022 (UTC)Reply[reply]
    • Having this, or some way to sort by section/anchor link would definitely help. --YodinT 20:55, 28 January 2022 (UTC)Reply[reply]
  • Ideally this solution would extend to {{anchor}}s, not just section links. Danbloch (talk) 19:42, 28 January 2022 (UTC)Reply[reply]
    They (as well as anchors that do not actually exist in the article) are handled/displayed the same by WhatLinksHere anyway, so I doubt there would be a problem with that. ~~~~
    User:1234qwer1234qwer4 (talk)     21:42, 8 February 2022 (UTC)Reply[reply]
  • I don't know if this holds true for all Wikipedias, but at least in the English Wikipedia, WhatLinksHere shows the target anchor/section of redirects in the list as
<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[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[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[reply]
  • I agree with your points about redirects, and links to more than one anchor/section from one page. Grouping by anchor names would tie well into the suggestion by YTRK above. --YodinT 00:42, 11 February 2022 (UTC)Reply[reply]
  • Let me point you to a discussion in German Wikivoyage where we discussed broken links to anchors. In de-wv we're using excessively a template that as a side effect creates an anchor for the item. The known problems for sections apply here too. A fix would be a big help for the project. --4omni (talk) 13:24, 30 January 2022 (UTC)Reply[reply]
    • Good example! Even if this proposal doesn't make it this year, I'm hoping that there's a chance that it (and sorting alphabetically, etc.) might be still included if WhatLinksHere is overhauled. --YodinT 00:42, 11 February 2022 (UTC)Reply[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[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[reply]

Discussion

  • I personally have 3 accounts: my primary account for the majority of the Wikimedia work, the second one is a bot account – I use AWB for bot edits, but I also use the bots account in the web browser for the category-related tasks (Cat-a-lot); the 3rd account is dedicated to mass imports of files of the third parties to Commons. — Draceane talkcontrib. 19:55, 15 January 2022 (UTC)Reply[reply]
  • See also: phab:T16409--GZWDer (talk) 07:14, 16 January 2022 (UTC)Reply[reply]
  • Yes, please. Whe I have 2FA enabled and use my account on more devices, it is pain to login again. Current workaround is using different browser, but there are some browser specific (eg. Vivaldi tiled tabs) and I sometimes want to use specific browser with specific account. JAn Dudík (talk) 12:29, 17 January 2022 (UTC)Reply[reply]
  • Neutral Neutral I have 2 accounts. Generally I work with 2 browsers open (Windows and Firefox) and I'm logged in with both browsers as different user. No problems. Taivo (talk) 20:09, 28 January 2022 (UTC)Reply[reply]
  • Firefox Containers does exactly this. Just set up a container per account. The tabs are even colour coded, and you can open any link in a specific other container (the effect being to open that link as another account). Inductiveload (talk) 23:32, 28 January 2022 (UTC)Reply[reply]
  • I think this would be nice, but one downside to weigh is that it'd make socking a lot more convenient. {{u|Sdkb}} talk 00:20, 29 January 2022 (UTC)Reply[reply]
    • @Sdkb: I understand this concern; the tool might be restricted to trusted users only, or the user should make the switched accounts public (or the switch could be logged.) — Draceane talkcontrib. 18:03, 29 January 2022 (UTC)Reply[reply]
  • @Wostr, Agus Damanik, and Dreamy Jazz: I'll be glad, if you bring at least some feedback on the proposal... — Draceane talkcontrib. 16:03, 31 January 2022 (UTC)Reply[reply]

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[reply]

Discussion

  • Isn't this supposed to be default already? · · · Peter (Southwood) (talk): 08:44, 11 January 2022 (UTC)Reply[reply]
    If it is, it certainly doesn’t work for me? Jcshy (talk) 08:47, 11 January 2022 (UTC)Reply[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[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[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[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[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[reply]
  • Added an phab ticket.--Snævar (talk) 08:53, 11 January 2022 (UTC)Reply[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[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[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[reply]
  • It somehwat works, but there are many bugs. E.g. T257853, T257852, T256525, T257803. --Tgr (talk) 02:33, 30 January 2022 (UTC)Reply[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[reply]

Discussion

  • There are multiple browser extensions that provide this functionality already (and apparently Edge can do this natively). Why should the tech team spend time on this? --Izno (talk) 05:47, 21 January 2022 (UTC)Reply[reply]
    Because this functionality would not depend on specific browser or computer. Many wikipedians have their comments in their user space, but this is not very comfortable workaround. Riha (talk) 13:33, 30 January 2022 (UTC)Reply[reply]
  • You can use w:en:User:Bradv/Scripts/Notepad.js for this – which stores notes persistently and can be accessed across different computers. Best, KevinL (aka L235 · t) 20:54, 30 January 2022 (UTC)Reply[reply]
  • de:benutzer:Schnark/js/notizen allows for by-page personal notes and alerts, but should be changed to use mw.user.options rather than the browser's localStorage for the suggested cross-browser functionality. ~~~~
    User:1234qwer1234qwer4 (talk)     22:40, 9 February 2022 (UTC)Reply[reply]

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[reply]

Discussion

  • Agree. No explanation needed. Jmaxx37 (talk) 16:44, 11 January 2022 (UTC)Reply[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[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[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[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[reply]
    That's not reasonable at all and not how modern websites work either. Izno (talk) 22:28, 18 January 2022 (UTC)Reply[reply]
  • 'Agree. It is standard behavior. --Frettie (talk) 09:03, 18 January 2022 (UTC)Reply[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[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[reply]

Discussion

  • Just add this to your global.js and have a look at someone's user page afterwards: mw.loader.load('https://en.wikipedia.org/w/index.php?title=User:Amorymeltzer/userinfo.js&action=raw&ctype=text/javascript'); – The currently easiest built-in way involving no custom scripts is to open Special:CentralAuth/Username and to sort the table by "edit count". ToBeFree (talk) 19:17, 10 January 2022 (UTC)Reply[reply]
    Thank you for that link. However, I would think that it would be easier for it to be a built-in function instead of that MrMeAndMrMe (talk) 19:24, 10 January 2022 (UTC)Reply[reply]
    A reasonable wish. And with MusikAnimal (WMF)'s statement below, one I'll support. ToBeFree (talk) 19:37, 10 January 2022 (UTC)Reply[reply]
    This is a reasonable wish, and I think it should be implemented in all installations of MediaWiki. In Wikimedia, we have XTools for viewing the others' edit count, but in wikis with no CentralAuth and XTools like other installations, we can't see others' edit count easily. Thingofme (talk) 02:51, 16 January 2022 (UTC)Reply[reply]
  • FYI phab:T32353, phab:T213110, phab:T278506 (and likely many others) have been repeatedly declined due to claimed problems with caching. — xaosflux Talk 19:25, 10 January 2022 (UTC)Reply[reply]
    Those asked for a magic word to be used in wikitext, which needs to be cacheable. MobileFrontend puts it at Special:Contribs which is not cached in the same way, and we could definitely do the same in native MediaWiki. Showing the system edit count is super cheap too, so I think this proposal is very doable, it would just need minimal design input. MusikAnimal (WMF) (talk) 19:30, 10 January 2022 (UTC)Reply[reply]
    And it is readily available via the API (example for OP). — xaosflux Talk 19:33, 10 January 2022 (UTC)Reply[reply]
  • That's a good suggestion. It does seem to take a long time (and sometimes X-tool can't see it) when looking at records with a large number of posts, such as Bot. Also, on a related note, I would like to suggest that the difference between registered users and IPs be removed for the following points.
    In Special:CentralAuth, you can see the registration and permission status for each project, but IPs cannot see the number of posts made.
    X-tool allows you to see the number of submissions, but there are no links to other projects, so you have to search for each one from the search screen.
    --211.1.70.190 03:18, 20 January 2022 (UTC)Reply[reply]
    Viewing CentralAuth's contribution counter is not restricted to logged-in users. ToBeFree (talk) 22:45, 29 January 2022 (UTC)Reply[reply]
    Why we can't easily view the number of IP edits? We can use a special page like Special:GlobalContributions/(the IP address) to do this. Thingofme (talk) 01:39, 31 January 2022 (UTC)Reply[reply]
    IP edit counts most likely won't happen in production, for performance reasons. XTools counts the actual number of revisions, what you might consider more exacting, and that's why it's slower. MediaWiki's "system" edit count is a running tally that is incremented on every edit, meaning we can query for it very quickly. However it is only applied to registered users (who have a row in the user table), and what constitutes an edit has changed over time, which is why it could be considered approximate. More info at mw:Special:MyLanguage/XTools/Edit Counter#Edit counts. MusikAnimal (WMF) (talk) 00:17, 9 February 2022 (UTC)Reply[reply]
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[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[reply]

Discussion

  • Have you ever read Limits_to_configuration_changes#Changes_that_are_likely_to_be_stalled,_though_not_declined? --Liuxinyu970226 (talk) 01:30, 17 January 2022 (UTC)Reply[reply]
  • Please be noted that I mentioned "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" so I do not expect the Community Tech Team to totally resolve the issue, but rather help resolve as much parts of it as possible, in accordance with their capability. C933103 (talk) 03:12, 17 January 2022 (UTC) Edit: highlight added: 04:30, 17 January 2022 (UTC)Reply[reply]
    @C933103 If so then your proposal is OOS for CWS, move to Community_Wishlist_Survey_2022/Archive or not? Liuxinyu970226 (talk) 04:20, 17 January 2022 (UTC)Reply[reply]
    @MusikAnimal: In the current form, isn't this "On roadmap of another team"? This looks like something that server admins should focus on, instead of Community Wishlist team. Liuxinyu970226 (talk) 05:33, 17 January 2022 (UTC)Reply[reply]
    Is it on the roadmap of another team? If it is, then yes we can archive it as there's no reason to vote on this wish. Otherwise, as the proposer states, we might be able to help with some of the subtasks, but certainly not the whole wish. It is rather odd for our team, though, since we generally build new products or have some sort user-facing deliverable. Here we'd just be assisting with some busy work that may actually result in the wish being resolved at some later time in the future. Peculiar for us, but not necessarily out of scope in my opinion. MusikAnimal (WMF) (talk) 20:46, 17 January 2022 (UTC)Reply[reply]
    So far as I know, this one is not on anyone's roadmap to actually do anything about. Izno (talk) 22:27, 18 January 2022 (UTC)Reply[reply]
    @Izno phab:T30443 told me that @Vladimir Alexiev: is probably handling this one subtask, as they re-triaged the priority of it from Lowest to High. Liuxinyu970226 (talk) 02:23, 19 January 2022 (UTC)Reply[reply]
    I don't think so, there has not been change on that task for some time. Izno (talk) 04:42, 19 January 2022 (UTC)Reply[reply]
  • This is an unacceptable state of affairs that has gone on for far too long. In particular, the situation where a Wikipedia language edition (be-tarask) is experiencing ongoing technical failures, rendering parts of the software unusable, is entirely unacceptable. The Community Tech team could play a valuable role as "shepherds", taking ownership of the issue and making sure that the different WMF teams come together to get it resolved. IThis, that and the other (talk) 13:00, 18 January 2022 (UTC)Reply[reply]
    @This, that and the other: Would you like to take over this wish? As I have exceeded the number of permittable proposal. You can take over the wish by changing the proposer name to your's. C933103 (talk) 13:43, 19 January 2022 (UTC)Reply[reply]
    @C933103 It's alright, we up'd the limit to 10! That rule only ever existed to ensure proposers are responsive. You are being responsive, so there's no problem :) MusikAnimal (WMF) (talk) 20:20, 19 January 2022 (UTC)Reply[reply]

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[reply]

Discussion

  • Comment Comment since Special:WhatLinksHere already exits, it’s possible to use the same algorithm and creating a graph of what pages link to this page, again a maximum of 3-5 jumps. Both would be equally useful so implement the way that will be easiest to implement. -Gifnk dlm 2020 From Middle English Wikipedia 📜📖💻 (talk) 13:57, 18 January 2022 (UTC)Reply[reply]
    • The result will be a png image which can be uploaded to commons. -Gifnk dlm 2020 From Middle English Wikipedia 📜📖💻 (talk) 14:27, 18 January 2022 (UTC)Reply[reply]
  • @Gifnk dlm 2020: Some sort of visual link graph tool exists, I know because I've seen it before... alas I cannot find it! Perhaps someone else reading this proposal will know what I'm talking about; but regardless there's a good chance the tool doesn't support Incubator wikis. As you say Special:WhatLinksHere and the database tables it uses can be queried directly, so this seems perfectly feasible. However this proposal might have better chances if you ask for a link graph tool that works on any wiki, including Incubator wikis. Just a suggestion! MusikAnimal (WMF) (talk) 04:35, 19 January 2022 (UTC)Reply[reply]
    • @MusikAnimal (WMF):, thank you very much! It will probably really be better for all wikis and not just incubator to be helpful for a wider variety of contributors. I feel like it will be useful only for Wikipedia and test Wikipedia projects and suggested it as a tool that will help incubating however if it’s useful also for other purposes I’m all for it. -Gifnk dlm 2020 From Middle English Wikipedia 📜📖💻 (talk) 07:54, 19 January 2022 (UTC)Reply[reply]
      • Yes, it will help us a lot while working in incubator test wikis. :) Haoreima (talk) 07:57, 19 January 2022 (UTC)Reply[reply]
  • Why specifically only incubator?C933103 (talk) 15:00, 6 February 2022 (UTC)Reply[reply]

Voting