Community Wishlist Survey 2022/Miscellaneous
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)
Discussion
- I think we should do that, but if it's done, will it be an opt-in feature? Thingofme (talk) 10:51, 15 January 2022 (UTC)
- @Thingofme You mean opting in to restricted statistics like we do for some part of the Edit Counter, etc.? If you feel it needs discussion, we can discuss that. MusikAnimal (WMF) (talk) 04:04, 16 January 2022 (UTC)
- Yes, because other features of Top Edits needs opting in. Thingofme (talk) 06:00, 16 January 2022 (UTC)
- @Thingofme You mean opting in to restricted statistics like we do for some part of the Edit Counter, etc.? If you feel it needs discussion, we can discuss that. MusikAnimal (WMF) (talk) 04:04, 16 January 2022 (UTC)
- I haven't ran any tests but I think it could be done. @User:Dunutubble: When you say "Wikistats" do you mean stats.wikimedia.org or something else? MusikAnimal (WMF) (talk) 04:01, 16 January 2022 (UTC)
Voting
- Support, but it would mean in the opt in to restricted statistics. Thingofme (talk) 01:37, 31 January 2022 (UTC)
- Support --Ciao • Bestoernesto • ✉ 17:25, 6 February 2022 (UTC)
- Support paul2520 (talk) 15:29, 7 February 2022 (UTC)
- Support ~~~~
User:1234qwer1234qwer4 (talk) 21:58, 8 February 2022 (UTC)
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)
Discussion
- Developer note: We should aim to get yearly granularity added to the underlying pageviews API, but if all else fails we can still simulate a yearly date type in Pageviews Analysis. MusikAnimal (WMF) (talk) 03:01, 19 January 2022 (UTC)
Voting
- Support Femke (talk) 19:31, 28 January 2022 (UTC)
- Support This, and other feature development of Pageviews. I love this tool and use it all the time. Very helpful yes! Bluerasberry (talk) 19:47, 28 January 2022 (UTC)
- Support. Thryduulf (talk: meta · en.wp · wikidata) 20:30, 28 January 2022 (UTC)
- Support — Draceane talkcontrib. 21:35, 28 January 2022 (UTC)
- Support Javiermes (talk) 21:54, 28 January 2022 (UTC)
- Support Izno (talk) 23:17, 28 January 2022 (UTC)
- Support ▸ épine talk♬ 02:09, 29 January 2022 (UTC)
- Support Ottawajin (talk) 05:11, 29 January 2022 (UTC)
- Support Lectrician1 (talk) 06:05, 29 January 2022 (UTC)
- Support Jon Harald Søby (talk) 10:52, 29 January 2022 (UTC)
- Support Aca (talk) 13:41, 29 January 2022 (UTC)
- Support BSMIsEditing (talk) 15:12, 29 January 2022 (UTC)
- Support Mbrickn (talk) 16:04, 29 January 2022 (UTC)
- Support //Lollipoplollipoplollipop::talk 18:16, 29 January 2022 (UTC)
- Support Waddles 🗩 🖉 21:35, 29 January 2022 (UTC)
- Support czar 23:50, 29 January 2022 (UTC)
- Support Agus Damanik (talk) 02:19, 30 January 2022 (UTC)
- Support Riha (talk) 14:12, 30 January 2022 (UTC)
- Support BugWarp (talk) 03:01, 31 January 2022 (UTC)
- Support Thingofme (talk) 15:51, 31 January 2022 (UTC)
- Support Havang(nl) (talk) 16:13, 31 January 2022 (UTC)
- Support Labdajiwa (talk) 03:00, 1 February 2022 (UTC)
- Support Daniel Case (talk) 22:44, 1 February 2022 (UTC)
- Support KingAntenor (talk) 06:38, 2 February 2022 (UTC)
- Support Rdrozd (talk) 18:03, 2 February 2022 (UTC)
- Support Krol111 (talk) 21:05, 2 February 2022 (UTC)
- Support Paucabot (talk) 12:39, 3 February 2022 (UTC)
- Support Pi.1415926535 (talk) 21:41, 4 February 2022 (UTC)
- Support —— Eric Liu(Talk) 05:43, 5 February 2022 (UTC)
- Support - Darwin Ahoy! 14:09, 5 February 2022 (UTC)
- Support Ealdgyth (talk) 17:23, 5 February 2022 (UTC)
- Support--Vulp❯❯❯here! 04:34, 6 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 07:26, 6 February 2022 (UTC)
- Support DanCherek (talk) 15:11, 6 February 2022 (UTC)
- Support — DaxServer (t · c) 20:56, 6 February 2022 (UTC)
- Support Mark D Worthen PsyD (talk) [he/his/him] 23:00, 6 February 2022 (UTC)
- Support paul2520 (talk) 15:23, 7 February 2022 (UTC)
- Support t34 (talk) 17:14, 7 February 2022 (UTC)
- Support —TheDJ (talk • contribs) 18:14, 7 February 2022 (UTC)
- Support ~~~~
User:1234qwer1234qwer4 (talk) 22:32, 8 February 2022 (UTC) - Support 4nn1l2 (talk) 01:31, 11 February 2022 (UTC)
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)
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)
- @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)
- 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)
- Ohh, I'd never noticed that! So the idea is
voy:ja:
should directly produce https://ja.wikivoyage.org/wiki/
- Where the current situation is
- voy:ja: parses to https://en.wikivoyage.org/wiki/ja:
- ja:voy: parses to https://ja.wikipedia.org/wiki/voy:
- 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)
- 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)
- The Interwikimap would need to be expanded massively to achieve this. C933103 (talk) 15:02, 6 February 2022 (UTC)
Voting
- Support I faced a related problem. For example, when jumping from the Korean Wikipedia to the Japanese Wikivoyage, if I write ":voy:ja:", it goes to Incubator, because Korean Wikivoyage is still in the test phase. This suggestion will solve that problem. --𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 01:47, 29 January 2022 (UTC)
- This is not in the scope of this page. Thingofme (talk) 01:51, 31 January 2022 (UTC)
- Support Lt2818 (talk) 06:44, 29 January 2022 (UTC)
- Support Less problem with interwiki links and no wrong links. But we have to fix articles which have the interwiki prefix Thingofme (talk) 01:51, 31 January 2022 (UTC)
- Support Glerium (talk) 12:34, 1 February 2022 (UTC)
- Support Yes, but no new prefix styles needed. Wargo (talk) 23:29, 1 February 2022 (UTC)
- Support--Vulp❯❯❯here! 04:23, 6 February 2022 (UTC)
- Support --Dipsacus fullonum (talk) 11:48, 6 February 2022 (UTC)
- Support --Ciao • Bestoernesto • ✉ 17:23, 6 February 2022 (UTC)
- Support Zache (talk) 08:32, 7 February 2022 (UTC)
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)
Discussion
- I do not understand this proposal. Maybe an example would help. · · · Peter (Southwood) (talk): 07:23, 11 January 2022 (UTC)
- @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)
- Would this system message just display automatically/bot generated information? · · · Peter (Southwood) (talk): 04:38, 12 January 2022 (UTC)
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)
- If you means edit notice in edit mode, see phab:T201613.--GZWDer (talk) 22:01, 12 January 2022 (UTC)
- @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)
- @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)
- 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)
- @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)
Voting
- Support Shizhao (talk) 03:51, 29 January 2022 (UTC)
- Support Aca (talk) 13:48, 29 January 2022 (UTC)
- Support We should create editnotices as a template and have it in default. Thingofme (talk) 01:47, 31 January 2022 (UTC)
- Support Novak Watchmen (talk) 17:20, 31 January 2022 (UTC)
- Support Ayumu Ozaki (talk) 07:25, 6 February 2022 (UTC)
- Support --Ciao • Bestoernesto • ✉ 17:34, 6 February 2022 (UTC)
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)
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)- 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)
- 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)
- 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)
- 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)
- Having this, or some way to sort by section/anchor link would definitely help. --YodinT 20:55, 28 January 2022 (UTC)
- Ideally this solution would extend to {{anchor}}s, not just section links. Danbloch (talk) 19:42, 28 January 2022 (UTC)
- Completely agree. --YodinT 20:55, 28 January 2022 (UTC)
- 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)
- 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)
- 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)- 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)
- 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)
- What would be the technical/syntactical difference between a non-existent section and a non-existent anchor? ~~~~
- 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)
- 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)
Voting
- Support * Pppery * it has begun 18:43, 28 January 2022 (UTC)
- Support Danbloch (talk) 19:43, 28 January 2022 (UTC)
- Support for anchors, not only sections --Andyrom75 (talk) 20:19, 28 January 2022 (UTC)
- Support — Draceane talkcontrib. 21:38, 28 January 2022 (UTC)
- Support Izno (talk) 23:27, 28 January 2022 (UTC)
- Support Broken section links are absolutely a problem, since bots fixing them haven't always been operational. This would help. {{u|Sdkb}} talk 00:23, 29 January 2022 (UTC)
- Support Dexxor (talk) 12:47, 29 January 2022 (UTC)
- Support Aca (talk) 13:38, 29 January 2022 (UTC)
- Support —Bruce1eetalk 14:13, 29 January 2022 (UTC)
- Support Good idea. — Jules* Talk 18:29, 29 January 2022 (UTC)
- Support With all the related extensions proposed in the discussion above. --Matthiaspaul (talk) 21:29, 29 January 2022 (UTC)
- Support Including anchors/fragments, not just sections. Nw520 (talk) 23:44, 29 January 2022 (UTC)
- Support czar 23:54, 29 January 2022 (UTC)
- Support SD0001 (talk) 03:47, 30 January 2022 (UTC)
- Support YTRK (talk) 07:46, 30 January 2022 (UTC)
- Support --4omni (talk) 13:24, 30 January 2022 (UTC)
- Support Wotheina (talk) 15:40, 30 January 2022 (UTC)
- Support DerFussi 15:44, 30 January 2022 (UTC)
- Support Libcub (talk) 22:10, 30 January 2022 (UTC)
- Support JPxG (talk) 00:46, 31 January 2022 (UTC)
- Support It's good for archiving talk pages, as we can link section links (however, we can't do that in edit summaries) Thingofme (talk) 01:48, 31 January 2022 (UTC)
- Support Dreamy Jazz talk to me | enwiki 14:42, 31 January 2022 (UTC)
- Support Havang(nl) (talk) 16:11, 31 January 2022 (UTC)
- Support JAn Dudík (talk) 20:44, 31 January 2022 (UTC)
- Support Trey314159 (talk) 22:50, 31 January 2022 (UTC)
- Support -- Ahecht (TALK
PAGE) 21:36, 1 February 2022 (UTC) - Support Daniel Case (talk) 22:42, 1 February 2022 (UTC)
- Support ~ Amory (u • t • c) 20:47, 2 February 2022 (UTC)
- Support Uanfala (talk) 21:53, 2 February 2022 (UTC)
- Support YBG (talk) 07:17, 3 February 2022 (UTC)
- Support WikiAviator (talk) 15:44, 3 February 2022 (UTC)
- Support - Darwin Ahoy! 19:22, 4 February 2022 (UTC)
- Support —— Eric Liu(Talk) 05:49, 5 February 2022 (UTC)
- Support – KPFC 💬 11:35, 5 February 2022 (UTC)
- Support Ealdgyth (talk) 17:27, 5 February 2022 (UTC)
- Support —Thanks for the fish! talk•contrib (he/him) 21:39, 5 February 2022 (UTC)
- Support Waldyrious (talk) 00:10, 6 February 2022 (UTC)
- Support--Vulp❯❯❯here! 04:34, 6 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 07:15, 6 February 2022 (UTC)
- Support Emaus (talk) 08:27, 6 February 2022 (UTC)
- Support Voice of Clam (talk) 10:40, 6 February 2022 (UTC)
- Support C933103 (talk) 15:10, 6 February 2022 (UTC)
- Support — DaxServer (t · c) 21:35, 6 February 2022 (UTC)
- Support --Achim55 (talk) 09:02, 8 February 2022 (UTC)
- Support ~~~~
User:1234qwer1234qwer4 (talk) 21:40, 8 February 2022 (UTC) - Support Rots61 (talk) 22:08, 8 February 2022 (UTC)
- Support Gaurav (talk) 06:38, 11 February 2022 (UTC)
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
ormw-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)
Discussion
Voting
- Support * Pppery * it has begun 18:43, 28 January 2022 (UTC)
- Support Kaganer (talk) 20:26, 28 January 2022 (UTC)
- Support! — Draceane talkcontrib. 21:36, 28 January 2022 (UTC)
- Support Izno (talk) 23:36, 28 January 2022 (UTC)
- Support Shizhao (talk) 03:52, 29 January 2022 (UTC)
- Support Aca (talk) 13:12, 29 January 2022 (UTC)
- Support Hemantha (talk) 14:16, 29 January 2022 (UTC)
- Support JAn Dudík (talk) 09:18, 31 January 2022 (UTC)
- Support the wub "?!" 14:24, 31 January 2022 (UTC)
- Support AWESOMEDUDE0614 (talk) 14:59, 31 January 2022 (UTC)
- Support Hb2007 (talk) 15:54, 31 January 2022 (UTC)
- Support Thingofme (talk) 15:57, 31 January 2022 (UTC)
- Support Liz (talk) 16:29, 31 January 2022 (UTC)
- Support Matma Rex (talk) 16:33, 31 January 2022 (UTC)
- Support stwalkerster (talk) 23:33, 31 January 2022 (UTC)
- Support Wargo (talk) 21:28, 1 February 2022 (UTC)
- Support -- Ahecht (TALK
PAGE) 16:27, 2 February 2022 (UTC) - Support Rzuwig► 12:16, 4 February 2022 (UTC)
- Support —— Eric Liu(Talk) 06:11, 5 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 07:19, 6 February 2022 (UTC)
- Support — DaxServer (t · c) 20:47, 6 February 2022 (UTC)
- Support using the RecentChanges interface. This would also allow for more advanced queries like tag intersections, which can be quite useful sometimes. ~~~~
User:1234qwer1234qwer4 (talk) 22:06, 8 February 2022 (UTC) - Support Quiddity (talk) 08:18, 10 February 2022 (UTC)
- Support Gaurav (talk) 06:32, 11 February 2022 (UTC)
- Thank you very much! Late support. Thank you for this proposal and to who worked on it --Valerio Bozzolan (talk) 08:13, 1 March 2022 (UTC)
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)
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)
- See also: phab:T16409--GZWDer (talk) 07:14, 16 January 2022 (UTC)
- 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)
- 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)
- 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)
- 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)
- @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)
- @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)
Voting
- Support --Matěj Suchánek (talk) 19:48, 28 January 2022 (UTC)
- Support ··· 🌸 Rachmat04 · ☕ 08:20, 29 January 2022 (UTC)
- Neutral – can be abusable and can increase sockpuppetry. – Aca (talk) 13:40, 29 January 2022 (UTC)
- Support — SHEIKH (Talk) 13:54, 29 January 2022 (UTC)
- Oppose Wostr (talk) 19:47, 29 January 2022 (UTC)
- Oppose I think it's just lead to a bigger possibility of sockpuppetry Agus Damanik (talk) 14:43, 9 February 2022 (UTC)
- Oppose https://github.com/mozilla/multi-account-containers#readme --𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 09:45, 30 January 2022 (UTC)
- Support Jmaxx37 (talk) 18:39, 30 January 2022 (UTC)
- Oppose For bot accounts, but there are concerns about sockpuppetry. Many vandals have a lot of accounts, and for Toolforge bots, they don't need to login much. Thingofme (talk) 01:41, 31 January 2022 (UTC)
- Oppose Dreamy Jazz talk to me | enwiki 14:49, 31 January 2022 (UTC)
- Since I was pinged here to provide rationale, I agree with the issues presented around sockpuppetry plus the ways presented for legitimate users to get around this via multiple browsers etc. seems like the easier option than the large amount of developer time that would be spent on making this possible. Dreamy Jazz talk to me | enwiki 02:08, 1 February 2022 (UTC)
- @Dreamy Jazz: OK, thank you for the explanation. — Draceane talkcontrib. 11:06, 1 February 2022 (UTC)
- Since I was pinged here to provide rationale, I agree with the issues presented around sockpuppetry plus the ways presented for legitimate users to get around this via multiple browsers etc. seems like the easier option than the large amount of developer time that would be spent on making this possible. Dreamy Jazz talk to me | enwiki 02:08, 1 February 2022 (UTC)
- Oppose --Havang(nl) (talk) 16:20, 31 January 2022 (UTC)
- Support It might be only for some group of users. It can be granted by admin, it can be only for eg. rollbackers etc.BUt yes, please JAn Dudík (talk) 20:56, 31 January 2022 (UTC)
- Oppose Would seem to be a built in sockpuppetry promotion. IAmChaos (talk) 21:30, 31 January 2022 (UTC)
- Oppose Per others, could support if only available for users of bot accounts, and then only with explicit permission to do this. Daniel Case (talk) 22:53, 1 February 2022 (UTC)
- Oppose Ayumu Ozaki (talk) 07:37, 6 February 2022 (UTC)
- Support --Ciao • Bestoernesto • ✉ 17:40, 6 February 2022 (UTC)
- Oppose Legitimate users already know how to work with this. The feature enhances Sockpuppetry — DaxServer (t · c) 21:00, 6 February 2022 (UTC)
- Oppose It encourages sockpuppetry. It's not a problem to use multiple accounts with Chrome profiles or alternatively using an incognito window or multiple browsers. Grillofrances (talk) 05:51, 7 February 2022 (UTC)
- Neutral --Bikepunk2 (talk) 21:54, 7 February 2022 (UTC)
- Oppose not for everyone. Prawdziwy Mikołajek (talk) 17:55, 9 February 2022 (UTC)
- Support Absolutely. More generally, Mediawiki should store data about linked accounts, to formalize acceptable "alternate accounts" and distinguish between them and prohibited sockpuppets. Yair rand (talk) 00:29, 11 February 2022 (UTC)
- Oppose DSparrow14 (talk) 17:09, 11 February 2022 (UTC)
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)
Discussion
- Isn't this supposed to be default already? · · · Peter (Southwood) (talk): 08:44, 11 January 2022 (UTC)
- If it is, it certainly doesn’t work for me? Jcshy (talk) 08:47, 11 January 2022 (UTC)
- It didn’t work just now for me, logged in to Wikipedia.org but not here. -- TheInternetGnome (talk) 10:19, 11 January 2022 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
- Added an phab ticket.--Snævar (talk) 08:53, 11 January 2022 (UTC)
- 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)
- 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)
- 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.
- 1) Better privacy
- 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)
- Thanks but I'm aware. Here are some reasons I can think of why it's important to implement the togglability:
- 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)
- It somehwat works, but there are many bugs. E.g. T257853, T257852, T256525, T257803. --Tgr (talk) 02:33, 30 January 2022 (UTC)
Voting
- Support --Matěj Suchánek (talk) 19:44, 28 January 2022 (UTC)
- Support Majavah (talk!) 20:13, 28 January 2022 (UTC)
- Support --Kusurija (talk) 21:34, 28 January 2022 (UTC)
- Support Yes, the current behaviour is a pain. — Draceane talkcontrib. 21:35, 28 January 2022 (UTC)
- Support Izno (talk) 23:31, 28 January 2022 (UTC)
- Support GeoffreyT2000 (talk) 23:41, 28 January 2022 (UTC)
- Support It used to work. If browsers have changed, let's fix it to work with the current versions. Certes (talk) 01:20, 29 January 2022 (UTC)
- Support -- ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 07:01, 29 January 2022 (UTC)
- Support Jon Harald Søby (talk) 11:06, 29 January 2022 (UTC)
- Support Šedý (talk) 11:06, 29 January 2022 (UTC)
- Support Aca (talk) 13:21, 29 January 2022 (UTC)
- Support —Bruce1eetalk 14:07, 29 January 2022 (UTC)
- Support Lectrician1 (talk) 20:08, 29 January 2022 (UTC)
- Support Agus Damanik (talk) 02:10, 30 January 2022 (UTC)
- Support Tgr (talk) 02:30, 30 January 2022 (UTC)
- Support TheInternetGnome (talk) 08:02, 30 January 2022 (UTC)
- Support I know this is supposed to be working already, but for many years it actually hasn't well. → «« Man77 »» [de] 13:21, 30 January 2022 (UTC)
- Support Ruthven (msg) 15:08, 30 January 2022 (UTC)
- Support Stryn (talk) 17:12, 30 January 2022 (UTC)
- Support Thingofme (talk) 01:49, 31 January 2022 (UTC)
- Support BugWarp (talk) 02:56, 31 January 2022 (UTC)
- Support daSupremo 04:18, 31 January 2022 (UTC)
- Support Buszmail (talk) 13:32, 31 January 2022 (UTC)
- Support PorkchopGMX (on the go) (talk) 18:38, 31 January 2022 (UTC)
- Support sometimes it wants two or three realoads before login. JAn Dudík (talk) 20:41, 31 January 2022 (UTC)
- Support IOIOI (talk) 20:50, 31 January 2022 (UTC)
- Support Dave Braunschweig (talk) 22:31, 31 January 2022 (UTC)
- Support Trey314159 (talk) 22:48, 31 January 2022 (UTC)
- Support Bencemac (talk) 11:44, 1 February 2022 (UTC)
- Support central and unified login. It works sometimes, but can also sometimes give IP-edits that I do not want to have. Oppose "Disable/enable the unified login". Taylor 49 (talk) 00:07, 3 February 2022 (UTC)
- Support EN-Jungwon 03:33, 3 February 2022 (UTC)
- Support --Nachtbold (talk) 12:01, 3 February 2022 (UTC)
- Support Paucabot (talk) 12:39, 3 February 2022 (UTC)
- Support EpicPupper (talk) 22:34, 3 February 2022 (UTC)
- Support --Ancheta Wis (talk) 23:43, 3 February 2022 (UTC)
- Support Jay8g (talk) 02:37, 4 February 2022 (UTC)
- Support Should already be the case ·addshore· talk to me! 22:55, 4 February 2022 (UTC)
- Support —— Eric Liu(Talk) 05:47, 5 February 2022 (UTC)
- Support RG067 (talk) 11:56, 5 February 2022 (UTC)
- Support —Thanks for the fish! talk•contrib (he/him) 21:38, 5 February 2022 (UTC)
- Support Waldyrious (talk) 00:12, 6 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 06:26, 6 February 2022 (UTC)
- Support SHB2000 (talk | contribs) 08:50, 6 February 2022 (UTC)
- Support--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 09:19, 6 February 2022 (UTC)
- Support: this is a bugfix request, but quite a significant one. The WMF should fix it anyway regardless of the Wishlist. — Bilorv (talk) 10:32, 6 February 2022 (UTC)
- Support — DaxServer (t · c) 20:49, 6 February 2022 (UTC)
- Support Sometimes it simply works, sometimes it works after minutes, sometimes it does not work at all - and I have no idea why it is such a mess. Andreas von Stackelberg (talk) 21:39, 6 February 2022 (UTC)
- Support Nave do Conhecimento (talk) 11:55, 7 February 2022 (UTC)
- Support paul2520 (talk) 14:45, 7 February 2022 (UTC)
- Support —TheDJ (talk • contribs) 18:15, 7 February 2022 (UTC)
- Support ~Cybularny Speak? 20:46, 7 February 2022 (UTC)
- Support EDITHIDEC (talk) 00:19, 8 February 2022 (UTC)
- Support Suonii180 (talk) 19:51, 8 February 2022 (UTC)
- Support ~~~~
User:1234qwer1234qwer4 (talk) 21:40, 8 February 2022 (UTC) - Support of course despite having been caugh by this bug yesterday and posting anonymously before I realised. I still had to login today. Doug Weller (talk) 06:45, 9 February 2022 (UTC)
- Support per Bilorv, Certes, et al. If its broken, fix it. · · · Peter (Southwood) (talk): 11:37, 9 February 2022 (UTC)
- Support ZellmerLP (talk) 19:35, 10 February 2022 (UTC)
- Support Betateschter (talk) 07:22, 11 February 2022 (UTC)
- Support Nehaoua (talk) 15:51, 11 February 2022 (UTC)
- Support --evrifaessa (talk) 16:02, 11 February 2022 (UTC)
- Support Saves me a refresh. -BRAINULATOR9 (TALK) 17:52, 11 February 2022 (UTC)
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)
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)
- 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)
- 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)
- 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)
Voting
- Support Riha (talk) 13:48, 30 January 2022 (UTC)
- Oppose per Community Wishlist Survey 2021/Watchlists/Personal notes on watchlisted items — HELLKNOWZ ∣ TALK ∣ enWiki 11:23, 31 January 2022 (UTC)
- Support ok Thingofme (talk) 15:54, 31 January 2022 (UTC)
- Support Hampcky (talk) 15:37, 2 February 2022 (UTC)
- Support makes sense Ballancier (talk) 20:23, 2 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 07:31, 6 February 2022 (UTC)
- Oppose Wiki is not a storage provider. All notes for article improvements can be stored in their userspace (sub)pages or offline. This could also be useful w:User:BrandonXLF/TodoList — DaxServer (t · c) 13:39, 6 February 2022 (UTC)
- Support --Ciao • Bestoernesto • ✉ 17:21, 6 February 2022 (UTC)
- Oppose Don't really see a purpose. --InterstateFive (talk) 20:42, 6 February 2022 (UTC)
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)
Discussion
- Agree. No explanation needed. Jmaxx37 (talk) 16:44, 11 January 2022 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- That's not reasonable at all and not how modern websites work either. Izno (talk) 22:28, 18 January 2022 (UTC)
- 'Agree. It is standard behavior. --Frettie (talk) 09:03, 18 January 2022 (UTC)
- 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)
Voting
- Support USI2020 (talk) 20:26, 28 January 2022 (UTC)
- Support — Draceane talkcontrib. 21:31, 28 January 2022 (UTC)
- Support Sea Cow (talk) 22:57, 28 January 2022 (UTC)
- Support Izno (talk) 23:33, 28 January 2022 (UTC)
- Support Daud Iffa (talk) 00:16, 29 January 2022 (UTC)
- Support ··· 🌸 Rachmat04 · ☕ 08:18, 29 January 2022 (UTC)
- Support Meiræ 12:35, 29 January 2022 (UTC)
- Support Aca (talk) 13:15, 29 January 2022 (UTC)
- Support Viticulum (talk) 18:16, 29 January 2022 (UTC)
- Support --SSneg (talk) 21:02, 29 January 2022 (UTC)
- Oppose: Use a browser that offers this feature if you need it; request it to be added to a browser if that's not an option. This is not something for a specific website to fix through JavaScript. Any time spent on developing this workaround is lost in the moment it becomes a browser feature. ToBeFree (talk) 22:57, 29 January 2022 (UTC)
- Support Tgr (talk) 00:04, 30 January 2022 (UTC)
- Support Agus Damanik (talk) 02:15, 30 January 2022 (UTC)
- Support --g (talk) 21:33, 30 January 2022 (UTC)
- Oppose as ToBeFree said, implement a specific solution to this problem only for MediaWiki is a workaround. in this case is better wait for browser support of the feature, then change the login page. --valepert (talk) 22:33, 30 January 2022 (UTC)
- Support ok, as sometimes strong passwords are hard to remember. Thingofme (talk) 01:52, 31 January 2022 (UTC)
- Support HugoHelp (talk) 04:03, 31 January 2022 (UTC)
- Support Trizek from FR 12:17, 31 January 2022 (UTC)
- Oppose per ToBeFree; this is (or should be) a browser feature. Silver hr (talk) 21:50, 1 February 2022 (UTC)
- Support Agree that it's better as a browser feature, but it's becoming so common that I don't think we can/should wait until it's ubiquitous that way. But better to make it something users can opt in to, rather than a default option. Daniel Case (talk) 22:56, 1 February 2022 (UTC)
- Support Hampcky (talk) 15:43, 2 February 2022 (UTC)
- Support Rotavdrag (talk) 11:37, 3 February 2022 (UTC)
- Support β16 - (talk) 10:38, 4 February 2022 (UTC)
- Support —Thanks for the fish! talk•contrib (he/him) 21:43, 5 February 2022 (UTC)
- Support--Vulp❯❯❯here! 04:23, 6 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 06:51, 6 February 2022 (UTC)
- Oppose As ToBeFree said — DaxServer (t · c) 21:24, 6 February 2022 (UTC)
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)
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)- 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)
- A reasonable wish. And with MusikAnimal (WMF)'s statement below, one I'll support. ToBeFree (talk) 19:37, 10 January 2022 (UTC)
- 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)
- A reasonable wish. And with MusikAnimal (WMF)'s statement below, one I'll support. ToBeFree (talk) 19:37, 10 January 2022 (UTC)
- 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)
- 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)
- 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)
- And it is readily available via the API (example for OP). — xaosflux Talk 19:33, 10 January 2022 (UTC)
- 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)
- 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)
- Viewing CentralAuth's contribution counter is not restricted to logged-in users. ToBeFree (talk) 22:45, 29 January 2022 (UTC)
- 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)- 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)
- 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
- Why we can't easily view the number of IP edits? We can use a special page like
- Viewing CentralAuth's contribution counter is not restricted to logged-in users. ToBeFree (talk) 22:45, 29 January 2022 (UTC)
- 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)
Voting
- Support -As proposer MrMeAndMrMeLet's talk 19:08, 28 January 2022 (UTC)
- Support I often want to see how many contributions I have made, and going to the Settings tab, despite as easy as going to the Contributions tab, is weird because the reasonable place you would search your number of contributions for is the Contributions tab, not the Settings one. Great proposal. EDITHIDEC (talk) 19:30, 28 January 2022 (UTC)
- Support --Matěj Suchánek (talk) 19:45, 28 January 2022 (UTC)
- Support — Draceane talkcontrib. 21:34, 28 January 2022 (UTC)
- Support Tol (talk | contribs) @ 22:35, 28 January 2022 (UTC)
- Support Huji (talk) 01:50, 29 January 2022 (UTC)
- Support --𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 01:52, 29 January 2022 (UTC)
- Support -- ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 07:03, 29 January 2022 (UTC)
- Support Arado Ar 196 (talk) 11:01, 29 January 2022 (UTC)
- Weak support — ElioPrrl (talk) 11:25, 29 January 2022 (UTC)
- Support Aca (talk) 13:42, 29 January 2022 (UTC)
- Support — SHEIKH (Talk) 13:55, 29 January 2022 (UTC)
- Support BSMIsEditing (talk) 15:16, 29 January 2022 (UTC)
- Support Useful for patrollers, admins, etc. — Jules* Talk 18:27, 29 January 2022 (UTC)
- Support Helen(💬📖) 19:51, 29 January 2022 (UTC)
- Support Waddles 🗩 🖉 21:15, 29 January 2022 (UTC)
- Support ToBeFree (talk) 22:45, 29 January 2022 (UTC)
- Support Also it can be shown on userpage 𝗩𝗶𝗸𝗶𝗽𝗼𝗹𝗶𝗺𝗲𝗿 ℣ 23:47, 29 January 2022 (UTC)
- Support Agus Damanik (talk) 02:25, 30 January 2022 (UTC)
- Support No problem Thingofme (talk) 01:39, 31 January 2022 (UTC)
- Support daSupremo 04:21, 31 January 2022 (UTC)
- Support not necessary, but useful JAn Dudík (talk) 20:43, 31 January 2022 (UTC)
- Support Malarz pl (talk) 21:05, 31 January 2022 (UTC)
- Support Useful. Glerium (talk) 12:39, 1 February 2022 (UTC)
- Support Wargo (talk) 21:48, 1 February 2022 (UTC)
- Support But I think this should be an option, not a default. Daniel Case (talk) 22:41, 1 February 2022 (UTC)
- Support KingAntenor (talk) 06:36, 2 February 2022 (UTC)
- Support Baokhang48812002 (talk) 13:43, 2 February 2022 (UTC)
- Support Hampcky (talk) 15:41, 2 February 2022 (UTC)
- Support Rdrozd (talk) 18:02, 2 February 2022 (UTC)
- Support Paucabot (talk) 12:41, 3 February 2022 (UTC)
- Support WikiAviator (talk) 15:41, 3 February 2022 (UTC)
- Support – Ammarpad (talk) 11:03, 4 February 2022 (UTC)
- Support Rzuwig► 12:13, 4 February 2022 (UTC)
- Support Whisperjanes (talk) 16:55, 4 February 2022 (UTC)
- Support - Darwin Ahoy! 19:58, 4 February 2022 (UTC)
- Support Pi.1415926535 (talk) 21:41, 4 February 2022 (UTC)
- Support — 07 ● 💬 22:07, 4 February 2022 (UTC)
- Support ·addshore· talk to me! 22:52, 4 February 2022 (UTC)
- Support NightWolf1223 (talk) 23:34, 4 February 2022 (UTC)
- Support —— Eric Liu(Talk) 05:51, 5 February 2022 (UTC)
- Oppose: waste of time for the Wishlist team. Low priority task with minor impact. Edit count is not often important information. — Bilorv (talk) 11:19, 5 February 2022 (UTC)
- @Bilorv It generally yes, when the subject is vandalism. - Darwin Ahoy! 14:28, 5 February 2022 (UTC)
- If the subject is vandalism then contribution history will be the main information required to establish the situation, and running XTools will not significantly increase the time spent analysing the user's contributions. — Bilorv (talk) 17:44, 5 February 2022 (UTC)
- @Bilorv It generally yes, when the subject is vandalism. - Darwin Ahoy! 14:28, 5 February 2022 (UTC)
- Support —Thanks for the fish! talk•contrib (he/him) 21:39, 5 February 2022 (UTC)
- Support --Liuxinyu970226 (talk) 04:10, 6 February 2022 (UTC)
- Support--Vulp❯❯❯here! 04:23, 6 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 06:46, 6 February 2022 (UTC)
- Oppose --Ciao • Bestoernesto • ✉ 17:26, 6 February 2022 (UTC)
- Support Mark D Worthen PsyD (talk) [he/his/him] 22:58, 6 February 2022 (UTC)
- Support Brewster239 (T·C·CA) 10:11, 7 February 2022 (UTC)
- Support Nave do Conhecimento (talk) 11:57, 7 February 2022 (UTC)
- Support paul2520 (talk) 14:59, 7 February 2022 (UTC)
- Support ~Cybularny Speak? 20:54, 7 February 2022 (UTC)
- Support Rots61 (talk) 22:14, 8 February 2022 (UTC)
- Support Nehaoua (talk) 15:59, 11 February 2022 (UTC)
- Support --evrifaessa (talk) 16:06, 11 February 2022 (UTC)
- Support -BRAINULATOR9 (TALK) 17:49, 11 February 2022 (UTC)
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):
- be-x-old.wikipedia.org was renamed be-tarask.wikipedia.org
- 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
- 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
- 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.
- 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.
- 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.
- 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.
- 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
- 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.
- 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.
- 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
- 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
- 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.
- 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.
- 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.
- 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.
- 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)
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)
- 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)
- @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)
- @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)
- 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)
- 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)
- @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)
- I don't think so, there has not been change on that task for some time. Izno (talk) 04:42, 19 January 2022 (UTC)
- @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)
- 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)
- 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)
- 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)
- @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)
- @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)
- @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)
Voting
- Support * Pppery * it has begun 18:43, 28 January 2022 (UTC)
- Support Majavah (talk!) 18:51, 28 January 2022 (UTC)
- Support BrandonXLF (talk) 19:36, 28 January 2022 (UTC)
- Strong support --Kusurija (talk) 22:15, 28 January 2022 (UTC)
- Support Izno (talk) 23:27, 28 January 2022 (UTC)
- Support Lt2818 (talk) 06:44, 29 January 2022 (UTC)
- since there are not only something need #operations' focus. --Liuxinyu970226 (talk) 08:06, 29 January 2022 (UTC)
- Support I doubt this will be a popular wish - these wikis are are, after all, small communities that sometimes lack technical capital, and are thus unlikely to vote here in droves - but I do hope it gets some attention from Community Tech nonetheless. This, that and the other (talk) 08:29, 29 January 2022 (UTC)
- Support Jon Harald Søby (talk) 10:56, 29 January 2022 (UTC)
- Support Arado Ar 196 (talk) 11:09, 29 January 2022 (UTC)
- Support — putnik 11:11, 29 January 2022 (UTC)
- Support CptViraj (talk) 11:21, 29 January 2022 (UTC)
- Support Aca (talk) 13:30, 29 January 2022 (UTC)
- Support BSMIsEditing (talk) 15:09, 29 January 2022 (UTC)
- Support //Lollipoplollipoplollipop::talk 18:16, 29 January 2022 (UTC)
- Support Wostr (talk) 19:46, 29 January 2022 (UTC)
- Support OwenBlacker (Talk) 22:59, 29 January 2022 (UTC)
- Support → «« Man77 »» [de] 13:24, 30 January 2022 (UTC)
- Support KevinL (aka L235 · t) 20:56, 30 January 2022 (UTC)
- Support The right language code is important Thingofme (talk) 01:34, 31 January 2022 (UTC)
- Support Sannita - not just another it.wiki sysop 12:12, 31 January 2022 (UTC)
- Support Ruthven (msg) 12:18, 31 January 2022 (UTC)
- Support the wub "?!" 14:24, 31 January 2022 (UTC)
- Support Novak Watchmen (talk) 17:52, 31 January 2022 (UTC)
- Support Xavier Dengra (MESSAGES) 19:00, 31 January 2022 (UTC)
- Support JAn Dudík (talk) 20:48, 31 January 2022 (UTC)
- Support Trey314159 (talk) 00:05, 1 February 2022 (UTC)
- Support Uanfala (talk) 21:52, 2 February 2022 (UTC)
- Support WikiAviator (talk) 15:41, 3 February 2022 (UTC)
- Support Pi.1415926535 (talk) 21:42, 4 February 2022 (UTC)
- Support - Darwin Ahoy! 02:01, 5 February 2022 (UTC)
- Support —— Eric Liu(Talk) 05:41, 5 February 2022 (UTC)
- Support – KPFC 💬 11:30, 5 February 2022 (UTC)
- Support —Thanks for the fish! talk•contrib (he/him) 21:42, 5 February 2022 (UTC)
- Support Waldyrious (talk) 00:17, 6 February 2022 (UTC)
- Support--Vulp❯❯❯here! 04:23, 6 February 2022 (UTC)
- Support (I was alerted to this) Regardless of the merits of individual cases, this should in principle be technically possible. I'm actually surprised it apparently isn't. Seb az86556 (talk) 04:58, 6 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 06:31, 6 February 2022 (UTC)
- Support — DaxServer (t · c) 21:15, 6 February 2022 (UTC)
- Support Lectrician1 (talk) 05:26, 6 February 2022 (UTC)
- Support paul2520 (talk) 15:36, 7 February 2022 (UTC)
- Support lots of technical debt to cleanup —TheDJ (talk • contribs) 18:25, 7 February 2022 (UTC)
- Support ~Cybularny Speak? 20:54, 7 February 2022 (UTC)
- Support ~~~~
User:1234qwer1234qwer4 (talk) 22:07, 8 February 2022 (UTC) - Support ✍️ Dušan Kreheľ (talk) 19:22, 10 February 2022 (UTC)
- Support 4nn1l2 (talk) 01:25, 11 February 2022 (UTC)
- Support Gaurav (talk) 06:36, 11 February 2022 (UTC)
- Support stjn[ru] 16:53, 11 February 2022 (UTC)
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)
Discussion
- 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)
- 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)
- @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)
- @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)
- Yes, it will help us a lot while working in incubator test wikis. :) Haoreima (talk) 07:57, 19 January 2022 (UTC)
- @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)
- Why specifically only incubator?C933103 (talk) 15:00, 6 February 2022 (UTC)
Voting
- Strong support as proposer. This will help test wikis in the incubator but can also be implemented in Wikipedia and Wikivoyage. I imagine incubator is the wiki which will get the most practical uses out of it but there’s no reason not to support other wikis as well if not all wikis. -Gifnk dlm 2020 From Middle English Wikipedia 📜📖💻 (talk) 18:10, 28 January 2022 (UTC)
- Weak support To help Community Wishlist Survey 2022/Larger suggestions/Support more than 1 link to each wikiprojects in each QID. --Liuxinyu970226 (talk) 11:29, 29 January 2022 (UTC)
- Support Aca (talk) 13:14, 29 January 2022 (UTC)
- Support daSupremo 22:35, 30 January 2022 (UTC)
- Support Wikilinks would be useful when cross-wiki linking in test wikis. Thingofme (talk) 15:56, 31 January 2022 (UTC)
- Support - Darwin Ahoy! 14:45, 5 February 2022 (UTC)
- Support Oliveleaf4 (talk) 18:00, 5 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 06:50, 6 February 2022 (UTC)
- Support --Ciao • Bestoernesto • ✉ 17:30, 6 February 2022 (UTC)
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)
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)
- 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)
- 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)
- @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)
- @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)
- 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)
- 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)
- 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)
- 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)
- 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)
- @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)
- 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)
- @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)
- 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)
- 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)
- 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)
- 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)
- @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)
- 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)
- @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)
- @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)
- 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)
- @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)
- @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)
- 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)
- Okay, done! Thanks again. MusikAnimal (WMF) (talk) 18:40, 26 January 2022 (UTC)
- 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)
- @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)
- @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)
- 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)
- @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)
- @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)
Voting
- Support —The Editor's Apprentice (talk) 18:55, 28 January 2022 (UTC)
- Support — SHEIKH (Talk) 13:56, 29 January 2022 (UTC)
- Support JPxG (talk) 00:48, 31 January 2022 (UTC)
- Support Thingofme (talk) 15:52, 31 January 2022 (UTC)
- Support and for watchlist Wargo (talk) 23:26, 1 February 2022 (UTC)
- Support - Darwin Ahoy! 00:57, 5 February 2022 (UTC)
- Support —— Eric Liu(Talk) 05:34, 5 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 07:32, 6 February 2022 (UTC)
- Support --Ciao • Bestoernesto • ✉ 17:39, 6 February 2022 (UTC)
- Support — DaxServer (t · c) 21:16, 6 February 2022 (UTC)
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)
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)
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)
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)
- @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)
- 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)
- 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)
- @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)
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)
Voting
- Support * Pppery * it has begun 18:42, 28 January 2022 (UTC)
- Support Procrastinators, please start working on the required patches this year! GeoffreyT2000 (talk) 18:46, 28 January 2022 (UTC)
- Support It is essentially a bug at the moment — GhostInTheMachine talk to me 18:56, 28 January 2022 (UTC)
- Support. Arlo Barnes (talk) 19:25, 28 January 2022 (UTC)
- Support Wikisaurus (talk) 19:25, 28 January 2022 (UTC)
- Support Kaybeesquared (talk) 19:27, 28 January 2022 (UTC)
- Support. It's an annoying issue, which should have been fixed years ago already. --Matthiaspaul (talk) 19:29, 28 January 2022 (UTC)
- Support Long overdue. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:40, 28 January 2022 (UTC)
- Support again. Debatably a bug. We can afford to fix this. Certes (talk) 19:41, 28 January 2022 (UTC)
- Support yet again. Just fix it. — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ< 19:45, 28 January 2022 (UTC)
- Support The presence of a self-check means that essentially any page tagged for speedy-deletion will warn that there are inbound links when I go to delete it. That makes the inbound-link-check feature useless. DMacks (talk) 19:52, 28 January 2022 (UTC)
- Support He3nry (talk) 20:00, 28 January 2022 (UTC)
- Support I support it, again and again and again ... until it will be implemented :-) --Andyrom75 (talk) 20:04, 28 January 2022 (UTC)
- Support — AfroThundr (u · t · c)