Wikipedia:Village pump (idea lab)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas. Before creating a new section, please note: Discussions of technical issues belong at Village pump (technical). Discussions of policy belong at Village pump (policy). If you're ready to make a concrete proposal and determine whether it has consensus, go to the Village pump (proposals). Proposals worked out here can be brought there. Before commenting, note: This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them. Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals. Discussions are automatically archived after remaining inactive for two weeks.

« Archives, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37

Ability to mark notifications from other wikis as read

Hello! So I'm not sure if this is at all possible but when I go to another Wiki I haven't been on before, I always get a notification when I come back to English Wikipedia saying I have notifications from other wikis, while being forced to go to that wiki (or at least click on the notification which takes me to the other Wiki) in order to mark the notification as read. I propose that we give users the ability to mark notifications from other Wikis as read from English Wikipedia (or whatever Wikipedia they mainly use) just like notifications from the Wiki they are currently on. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) (Stupidity by me) 20:15, 7 September 2021 (UTC)

• Support, it is so annoying when that happens. Sometimes I get notices from Wikis I have never edited because a change I made like a file rename in Commons was ported there. BD2412 T 20:28, 7 September 2021 (UTC)

It took me awhile to figure out, but there is a way to mark notifications from other wikis as read without going there. In the notification dropdown, there's a blue dot to the right of the notification. Click it to clear it and that will do it. Schazjmd (talk) 20:29, 7 September 2021 (UTC)

• I think that's a "problem solved", then. BD2412 T 20:34, 7 September 2021 (UTC)

I kinda wish it were a bit more obvious than that. Also @BD2412: you're not supposed to vote here. This is just for formulating ideas before you vote on them. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) (Stupidity by me) 18:54, 8 September 2021 (UTC)

• I'm aware of that, but I did it anyway, per WP:IAR. BD2412 T 19:29, 8 September 2021 (UTC)

  Fair enough. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) (Stupidity by me) 19:10, 9 September 2021 (UTC)

You can also do this at Special:Notifications, which is easily reached by choosing "All notifications" at the bottom of the dropdown menu. Whatamidoing (WMF) (talk) 16:35, 9 September 2021 (UTC)

I mean, that's functionally as awkward as having to go to that project to resolve it, but I was not aware of that blue dot method noted above, so will try that out next time. And I've just tested with 10 editors, and only a few knew about that working. Nosebagbear (talk) 15:41, 11 September 2021 (UTC)

Can confirm blue dot method works (though it looks like it wipes the notification rather than marking it was read) Nosebagbear (talk) 21:40, 13 September 2021 (UTC)

Hitting the blue dot does not wipe the notification on my Chromebook using MonoBook. - Donald Albury 23:00, 13 September 2021 (UTC)

Clicking the blue dot moves the notification between "Read" and "Unread". If you have a lot of notifications (I have 62 waiting for me this morning), then that will move it out of the visible list. Whatamidoing (WMF) (talk) 16:15, 14 September 2021 (UTC)

It removes the notification only while you are browsing a wiki other than the one where it originated. If you go to the originating wiki, you will see the notification of interest. IznoPublic (talk) 16:19, 22 September 2021 (UTC)

I'd like the ability to figure out what other wiki a notification is from when I am on my phone. In the responsive monobook skin, crosswiki notifications show the red/blue numbers, but the actual text notifications are hidden, and there is no obvious way to find out they even exist. I've previously used

.mw-echo-ui-notificationsInboxWidget-sidebar {display:block;}

in my monobook.css to turn the wiki selector on, but that messes up the formatting. Currently I'm just hoping I don't get crosswiki pings while on my phone. Any ideas? @Whatamidoing (WMF)? —Kusma (talk) 20:10, 14 September 2021 (UTC)

@Kusma, my advice is that you post that question at Wikipedia:Village pump (technical). Whatamidoing (WMF) (talk) 18:46, 15 September 2021 (UTC)

Been there, done that: Wikipedia:Village_pump_(technical)/Archive_190#Crosswiki_notifications_and_the_responsive_monobook_skin. —Kusma (talk) 21:23, 15 September 2021 (UTC)

Real-time reporting of election results

• Should live election results be reported on Wikipedia articles?

Live election results may contradict one another. The references to support the results soon become unverifiable because updated results erase any prior results. There is no protocol for determining which how often the live results should be updated, or if the reference needs to be static (like a webpage archived with the Wayback Machine).

See 2020 United States presidential election on November 5, 2020, for example. The references for the election results are live election results from ABC News and The New York Times, whose previous versions have been lost.

I have no objections to declaring winners based on election calls of reputable media organizations, or the reporting of final but unofficial results provided that our sources concur. wikinights _talk 20:07, 14 September 2021 (UTC)

• Yes, as long as it's made clear what the sources are and what the reporting figure is (e.g. as used in this infobox). This is pretty standard practice and is usually done quite reasonably. Number 57 20:17, 14 September 2021 (UTC)
• This is the idea lab, so what is your idea for dealing with this problem? Yes, on election nights in Western Anglophone countries we get a lot of such edits, but they seem to be fixed quickly enough for nobody who realises that this is an encyclopedia, not a breaking news service, to be inconvenienced. Phil Bridger (talk) 20:32, 14 September 2021 (UTC)
• Experience says it's basically impossible to stop people from adding such information in near real time. I don't think any "protocol" or special rules are likely to work. What would you do if people update "too quickly"? Fortunately counts usually finish at some point, and then we can use the final results and find stable references for those. Hyperlink references on old revisions are very often broken. That's just a fact of life. As long as current versions are working, I'm not bothered. —Kusma (talk) 21:11, 14 September 2021 (UTC)
• On election day & for a month after ward, an article should be semi-protected, due to oncoming mostly well-meaning but scarcely informed editing. GoodDay (talk) 23:50, 14 September 2021 (UTC)
• We basically already report election results in near-real-time. Overly excited editors tend to forget to add/update the refs, but that's why we have {{Current election}} enabled on election pages. I would be in favor of discouraging such reporting altogether (in the spirit of WP:RSBREAKING) but that's probably something that won't happen anytime soon. Dr. Swag Lord (talk) 06:56, 15 September 2021 (UTC)
• Yes. 🐔 Chicdat  ^{Bawk to me!} 10:25, 15 September 2021 (UTC)
• This is an encyclopedia, not a breaking news service. No. SQL^{Query Me!} 10:55, 15 September 2021 (UTC)
  • We update the stats for the players, are we not? Those are live. Elections should be treated the same. My only worry is that it might generate edit warring like crazy.--MollyPollyRolly (talk) 03:02, 23 September 2021 (UTC)
    • @MollyPollyRolly: "We" don't. A certain cadre of editors do — to the overall encyclopedia's detriment, IMHO. Enough of their frequent-flyer articles have ended up under Pending Changes protection that I'd love to ban the lot of them. WP:NOTSTATSBOOK anyway, but not one of their stats edits ever includes a single citation. How is any of that even supposed to be reviewed? (It doesn't help that the side-by-side diff view removes enough context that edits to table content are rendered near-indecipherable most of the time, and the visual diff more likely than not craps out because of the article length / coding complexity.) Thank you for the opportunity to rant about one of my pet peeves! 😁 -- FeRDNYC (talk) 15:55, 27 September 2021 (UTC)
• I see no issue with the status quo I see with most ongoing elections. Broad stroke reporting (number of seats, which may be subject to change but will largely remain static) should be added, but not full reports such as developing vote totals. JackWilfred (talk) 13:02, 15 September 2021 (UTC)
• This came up at WT:CANADA just a few days ago, Mathew5000 observed that while editors had rushed to update preliminary results in the template series for the 2015 and 2019 Canadian federal elections, the vast majority of those templates were never subsequently updated with official results nor verified, and have been hosting incorrect data for several years now. Wikipedia shouldn't do anything in real time, but if we're not going to actively prevent this behaviour then we need a concerted effort to go around and clean it up once official results are available. Some editors have also suggested adding a disclaimer to results templates indicating that results are preliminary, and maybe that banner could populate a maintenance category? Category:2021 Canadian federal election results by riding with unofficial results, as a subcat of Category:2021 Canadian federal election results by riding? That would be a big help. Ivanvector's squirrel (^trees/_nuts) 15:54, 15 September 2021 (UTC)

Undo Editor update

So whenever I undo an edit and add something to the edit I undid, I'm forced to use what I'm going to call the undo editor. It appears to be a version of the source editor, however I find it a bit hard to use, mainly when adding a reference or adding more than a few things, as there are some tools in the top bar of the source editor that I like to use when normally using the source editor that either appear to be missing from the undo editor or aren't as good in the undo editor. For example, on the page for Sonic Colors, I undid an edit and added a reference in that same edit, however the ref tool in the undo editor simply just adds <ref> </ref> instead of adding {{Citeweb}} as well as ref tags. So I have to publish the editor and remove the reference and then click the reference tool in the top toolbar of the source editor which allows me to simply put in the link of the reference and it will add the correct information (Such as the Citeweb template and ref tags) for me. I propose that we update the undo editor to be on par with the current source editor (maybe something similar to the reply tool that's being added). Blaze The Wolf | Proud Furry | Discord: Blaze Wolf#0001 (talk) 14:49, 16 September 2021 (UTC)

 Works for me @Blaze The Wolf: are you using mobile or the visual editor? Can you tell which editor you are using from this list: mw:Editor? When I'm on the undo screen, I get the same tools as if I'm in the normal source editor. Is perhaps your citation tool bar just collapsed? — xaosflux ^Talk 13:07, 17 September 2021 (UTC)

@Xaosflux: It appears it's because I"m using WikiEd which I didn't realize did that until just now. ― Blaze The Wolf^Talk_{Blaze Wolf#0001} 13:14, 17 September 2021 (UTC)

@Blaze The Wolf: thanks for the update, for bug reports on that personal user script, please follow up at: User_talk:Cacycle/wikEd. — xaosflux ^Talk 13:21, 17 September 2021 (UTC)

@Xaosflux: Nah I don't really think it's a bug. It's just a bit to complex for me to understand. ― Blaze The Wolf^Talk_{Blaze Wolf#0001} 13:23, 17 September 2021 (UTC)

mw:Editor has screenshots of all the editing environments I'm aware of. The "Undo" button always uses your default editor, which is always an old wikitext editor (either 2010 or 2003 versions). Whatamidoing (WMF) (talk) 19:17, 17 September 2021 (UTC)

@Whatamidoing (WMF): Why using an old version? Isn't there a new one? The updates should come out every week, if I am not mistaken.--MollyPollyRolly (talk) 02:59, 23 September 2021 (UTC)

If you haven't change your prefs, then you are the 2010 wikitext editor. It is rarely updated, because there usually isn't any need to change it. The date is the year that it was widely released. Whatamidoing (WMF) (talk) 16:46, 24 September 2021 (UTC)

Replacement for Interlanguage link template

This is a proposal to deprecate {{interlanguage link}} and define a new type of disambiguation/redirect page that includes one or more links to the appropriate page on one or more other wikis.

The primary issue that I raise with the existing solution is that multiple articles may have links for the same article which exists on other wikis but not on enwiki. Whenever there is any change to the set of wikis that should be linked to (perhaps the article has become available in another language, or perhaps an English-language version has become available), then all the pages referencing that article need to be modified ... we even have a bot which automatically replaces the {{Ill}} with a direct link when an English-language version becomes available.

The proposed solution is a form of disambiguation or "manual redirect" page that has whatever name that would presumably be used on enwiki. The pre-existing discussion is at Template talk:Interlanguage link § Proposed alternative to Template:Ill. Fabrickator (talk) 18:47, 19 September 2021 (UTC)

Note that this can be used in a citation, a meaningful advantage over {{Ill}}. Fabrickator (talk) 19:13, 19 September 2021 (UTC)

I think you misunderstand how {{ill}} works when that red-linked article gets created here – no manual change is required, the red link will turn blue and interlanguage links should appear in the left side bar. A bot may come along and remove the template. As for citations: several components of a citation can already be linked via {{ill}}. Author links are of course possible in free-text citations, and can be hacked into citation templates as well. -- Michael Bednarek (talk) 02:49, 20 September 2021 (UTC)

Sorry, I "mis-spoke" about how the template handles the case when an enwiki version of the page becomes available.... as that's the single situation which is handled okay, more or less. Every other case is handled poorly, in that it's necessary to edit each page which references the affected article when there's any other change to availability of interlanguage versions of the article. Fabrickator (talk) 06:44, 20 September 2021 (UTC)

I would be happy to see the templates and their redlinks being replaced with links to articles that provide at least a basic stub level of content, and with sufficient referencing to show the subject is notable. However, this proposal would see approximately 110,000 redlinks being replaced with links of a different color, and the creation of many new pages to which these recolored links would go. They would be each contain a list of external links to other wikis, but be lacking the level of content or citations required in standard articles. The idea that redlinks are ugly as they are highly visible and a clear indication of something being wrong (i.e. missing content) is not a major concern to me compared to the actual lack of content, something which I feel the proposal does not fix, but attempts to mask by using placeholder pages. There are numerous issues with the usage of this template, from inconsistency in the naming of the redlink to the order, number and selection of language links used with it. It may be possible to make adjustments to the template or create tools that can help to sort some of this, however, these issues are mainly the result of editing rather than the template itself. Changes to the documentation could help inform editors of some potential issues and how to avoid or work around them. EdwardUK (talk) 04:53, 20 September 2021 (UTC)

EdwardUK wrote:

I would be happy to see the templates and their redlinks being replaced with links to articles that provide at least a basic stub level of content, and with sufficient referencing to show the subject is notable

It seems like you are trying to apply some sort of technical rule that would have the effect of complicating or otherwise deterring the implementation of a presumably useful feature. I'm a little perplexed at this approach, given what seems to be a general consensus that these interwiki redlinks are expected to encourage the creation of new articles. Anyway, notability applies to articles, and I think we can distnguish between a redirect page and an article. Fabrickator (talk) 09:45, 20 September 2021 (UTC)

The technical rule is simply meeting the standard expectations of any standard article without which the article is liable to be deleted or draftified. Here it seems the intention is to circumvent these requirements by classing these as a different type of main space page for topics where there is another language version and I would be very surprised if these pages were not challenged either as a concept or on an individual level. I would expect the issue of notability to apply on the basis that wikipedia is not an indiscriminate collection of information, so inclusion here should not be based solely on the content existing on other wikis.

I understand these pages could be seen as starting points which could be expanded into full articles, but it is not clear at what point they would make the transition and the standard rules would apply. This would be a particular problem where content creeps in and it goes from "this article is not available" to "there is no article about topic X…" followed by a brief description for the benefit of the disambiguation and then to further details being added. With the redlinks there is a clear dividing line over there being an article or not, the proposed pages would make this line unclear. EdwardUK (talk) 16:40, 20 September 2021 (UTC)

I am not sure what the source is of your contention that these redirect pages could be expanded into full articles, but of course there's nothing preventing existing disambiguation pages from being expanded in this manner, and there are certainly some cases where a disambiguation page actually describes a term when there is no appropriate article to link to. Just take a look at the red herring disambiguation page. Fabrickator (talk) 18:43, 20 September 2021 (UTC)

There are certainly examples of disambiguation pages that deviate from the guidelines and have content that should not be there, but these pages are never intended to become articles, only to list topics for which there are already related articles on the English language wiki. What the language link pages would need is something more like a disambiguation/hatnote so that users could know exactly which topic there is no article for without having to open any of the links (or translate the contents).

It may be possible to use templates or bots to assist in creating both the redirect and language link pages if the text was kept simple and generic. (If I am correct in thinking that the proposal would create two pages for each topic, a redirect/article page and a links page, one being a page where the article will eventually be but is initially blank except for a redirect to the second page, which has the language links) However, adding the language links may be more difficult, and based on the size of the task I do not know how complicated or time consuming it would be to add the individual disambiguation for each page, and as it has been noted, the template has numerous cases of name and language variations for a single topic, which could result in many errors and page duplications which would have to be corrected too.

Once an article has been created (replacing the redirect) it would orphan the language links page. If these link pages were kept there could be a build-up of these redundant pages, and if deleted there is the same issue as happens with the template, that if the article is deleted or removed the links to it would turn red but the redirect and language links would not be restored. (This is one of the reasons I would prefer to have citations from the start, so that the articles are more likely to be retained.) When it comes to the creation of the articles I can see two ways in which this is likely to happen, either overwriting the redirect page with a full article, or as a result of additions of text on the links page until an editor decides at some point that it should be moved to the article page. EdwardUK (talk) 07:38, 21 September 2021 (UTC)

We've got to start off with some common ground about our attitude towards interlanguage links. On the one hand, the fact that we can use interlanguage links greatly increases the number of distinct topics that are potentially available to enwiki users, notwithstanding the fact that these articles are not in English. On the other hand, some of these articles might not meet the standards of what would be considered acceptable as an article on enwiki, notwithstanding the fact that these articles aren't in English.

So supporting this notion that we might be concerned about this is that some of these other wikis might not have similar attitudes about reliable sources, NPOV, or certain other policies we consider to be fundamental, and thus, such links could be harmful to the reputation of enwiki. If this is a substantial concern, we might restrict links to certain wikis which we consider to have a "like-minded" attitude compared to enwiki.

Now let's take a more positive stance. Given that there are at least some non-English wikis that do have similar standards, we will still have disagreements, certainly as to notability, for instance. And I'll raise the question that has been brought up in a sideways sort of manner: Are we inviting some kind of trouble if we allow a link to an article that would not be considered notable on enwiki, but which is considered notable on one of these "like-minded" wikis? Phrasing the question another way, if the folks running the Russian-language wiki allow there to be an article for some obscure Russian philosopher (yet this article does not exist on enwiki because the philosopher is not notable in the English-speaking world), and enwiki has an article mentioning that obscure Russian philosopher, should it be okay to have an interlanguage link to the article on the Russian wiki? Answer me that, and I think that would help us to move forward. Fabrickator (talk) 09:40, 22 September 2021 (UTC)

Yes. -- Michael Bednarek (talk) 10:52, 22 September 2021 (UTC)

See H:FOREIGNLINK. - Donald Albury 16:26, 22 September 2021 (UTC)

@Donald Albury: The whole point of this discussion is actually the deficiencies of the existing solutions such as {{interlanguage link}}. Some of the discussion has been to the effect that a proposed solution would create "disambiguation" pages (using the appropriate English name of the article) which would offer one or more interlanguage links to choose from, but one of the objections has been that those might not meet the "notability" requirement on enwiki. We now have one person agreeing that this should not be considered to raise a notability issue. Fabrickator (talk) 21:55, 22 September 2021 (UTC)

One solution to all this, will be to wait until a good translator will arrive and will translate this "obscure philosopher" article with attributed reliable sources.--Filmomusico (talk) 22:01, 22 September 2021 (UTC)

Unless the content of a page is terrible (in which case I would not bother) then linking to it would be fine, but that is not the same as creating an English language page for it. On the English wiki the quality expectations are higher than they once were, so there are plenty of older sub-standard and non-notable articles, (some which could be deleted or draftified but have not, either because they have not been noticed, they have been ignored, or the issues have been tagged but not resolved), and the situation is the same in other languages including "like-minded" wikis. The German article de:Arthur Kaan for example, (this being found on Achilles, the first article listed on the "What links here" page for the template) is of a quality which would be okay to have or to link to, but not necessarily to create. If the article already existed in English I think it would be kept, it seems notable and has sources but it would be tagged for lacking inline citations, however, as a new article it may be seen as inadequate until these citations are added, which would be difficult to do as of the three sources on the German wiki, one is not online and a version of another (Thieme-Becker) is behind a registration/pay wall.

If the proposed pages were implemented, then when information on the links page is added, (specifically the introductory disambiguation), it would be necessary if this is drawn from the other language versions to ensure that it has the correct copyright attribution, and that it is accurate, which may be unclear if the other version lacks citations. If it was on the English wiki the editor would be taking on responsibility for the accuracy of the information/content, whereas using the template they only have to ensure the accuracy of the link(s). It would also be necessary when attempting to fully create this article in English to not just use a direct translation but also make additional improvements, without which it could be draftified or deleted, with the redirect and link pages being lost. Unless there is a better alternative, then for this proposal to succeed, there would need to be a way to counter any pages being removed, this would require the creation of another type of template added to the redirect page, which would be retained when it becomes the article page (unlike the removable template used for changing the color of incoming links). These would inform admin editors of the option to restore the redirect page, not just move or delete the article, and could link to any tools that may have to be created to provide a method for un-deleting the links page and adding to it any messages regarding removed versions or drafts of the article. After the first set of proposed pages have been created to replace the existing templates I do not think any more pages of this type would be made because the combination of pages and templates needed would be very off-putting to editors trying to add it, instead they would opt for ordinary redlinks and argue for the restoration of the template which is much easier to use. EdwardUK (talk) 23:39, 22 September 2021 (UTC)

Not to make too fine a point of it, but I do not propose having separate redirect and link pages. I don't know if it helps any, perhaps we should drop the term "redirect", it's just a disambiguation page that may have links to one or more pages, pages which happen to be on other wikis. If it's decided to replace this disambiguation page with an article, some consideration could be given to how we "transition" it back to the way it was if it's decided to delete the article. This is worthy of giving some thought to, but building up some complex set of conventions may be overkill. I see this as a way of increasing the use of wikilinks to non-English wikis, so that there's only one place where the interwiki links (for a given article) need to be recorded, instead of repeating them on each page containing the term to be wikilinked. Fabrickator (talk) 00:09, 23 September 2021 (UTC)

The reason why interwikis exist is so that one can translate an article from one language to another. On the other hand, the articles that we write are translated more (because we have more) then in other languages.--Filmomusico (talk) 02:55, 23 September 2021 (UTC)

The only place the language links need to be recorded is on wikidata, the problem is that this is easily accessible from an article, where it is displayed on the left sidebar, but not from a redlink, and although the template allows a link to wikidata to be added, many of the editors that use the template probably think that it may be more helpful to link directly to another language instead of having to go through wikidata. If there was just a link to a single page, tagged with a "this is not an article" type template, then it would not need to have a list of language links as users could access the wikidata item and find the list of language links there.

Suppose though, instead of this disambiguation page, we were to have a modified "Creating…" page. This would require an addition to be made to the standard blank "Creating…" page (reached from clicking a redlink) of a feature (maybe a sidebar tool option) allowing the editor to pre-associate that name with an existing wikidata item before the article has been created. This could be used to generate a modified "Creating…" page for which all the matching redlinks could display in another color, for example orange. Then when another editor sees it they would be aware that when they clicked on this orange link it would take them to the modified "Creating…" page (something like https://en.wikipedia.org/w/index.php?title=____&action=edit&orangelink=1) from which they could either access the wikidata item, or create the article. This would remove the need for the template (and the language links it displays), without the need for the creation of disambiguation pages or having to create the list of language links that goes on it. Some editors with technical knowledge may have to assess the practicalities/possibilities of this concept, and there may still be some uses of the template that are tricky to convert, but it would very be simple for editors to add new links. EdwardUK (talk) 03:16, 23 September 2021 (UTC)

In principle, this might be an optimum approach, i.e. a single source mapping "equivalent" articles across all different language wikis. As a practical solution, I would be really skeptical. This means that existing editors (and perhaps non-editors) need to somehow be interacting with Wikidata. I looked at the Wikidata docs, trying to access info using the QID, couldn't make out heads or tails. I guess there's great stuff in there that I'm missing out on. (I tried finding the stuff mentioned in the left sidebar, I couldn't find that either.) So I am a totally clueless editor it seems. This would seem to be a huge barrier, maybe I'm the only one with such a blind spot, but I doubt it. My prediction would be that if we go this route, then only a small group of particularly technical editors will participate, it will become a feature regular editors can't effectively contribute to, they'll see that interlanguage articles exist but have no way to contribute. The ability to contribute is obviously a big part of the appeal of being an editor, adding interlanguage links look like a meaningful way to contribute (just as many editors feel they are encouraged to improve articles by adding wikilinks), but this will be beyond them. I am highly skeptical that the barriers this seems to create would be overcome. Fabrickator (talk) 15:37, 23 September 2021 (UTC)

The level of interaction would be little different than it currently is with the existing template, or would be with the proposed disambiguation page. Here the requirement is also for the initial editor adding the links to visit the external pages in order to verify their links are accurate. On most articles the link to wikidata is found in the left sidebar near the bottom of the tools section. (unless using the mobile website, or there is no item, or other display settings have moved/removed it) Adding links to wikidata would be much like when adding other languages, after opening a page on the relevant language site/wikidata an editor could use the search bar at the top right to look for the name and confirm if there is already a page for their topic, with wikidata the QID would appear next to the page title, which the editor could copy without having to take any editing action within wikidata. Then on the standard/redlink "Creating…" page, using a feature (which is not currently there and would need to be created) the editor could type/paste in the QID just as they currently do when adding it to the template. Note that until the article has been created this link would only be one-way, so that it would link to wikidata, but wikidata would not link back to the non-existent English article. When subsequent editors click on the orangelink, the sidebar of this "Creating…" page would not only have a wikidata item, but also the other features generated as a result of this, notable the language list, and also the commons link. These could be accessed directly from that page without having to go via the wikidata site. It could also see more consistency in the naming of links if, when an editor tries to turn a redlink orange by adding the wikidata ID, a message appeared if that QID had already been linked to a different name, so that they could then go back and adjust their redlink as needed. EdwardUK (talk) 19:12, 23 September 2021 (UTC)

@EdwardUK: WP:Wikidata § New articles seems to claim that the capability to create links based on Wikidata is already present. I tried following their instructions with Evgenia Zabolotskaya, adding ru:Институт общей физики имени А. М. Прохорова РАН via Wikidata. But that only updates the Wikidata. There are instructions shown for semi-automated migration and manual migration, but they do not seem clear enough to follow. Can you tell whether these instructions should actually work if I were able to figure out how to follow them? Fabrickator (talk) 21:30, 23 September 2021 (UTC)

Arbitrary section break

Fabrickator: Your merge of Evgenia Zabolotskaya (D:Q67166568) and ru:Институт общей физики имени А. М. Прохорова РАН [A.M. Prokhorov General Physics Institute of RAS] (D:Q16655721) at Wikidata was ill advised. Those articles do not cover the same subject and the merge ought to be reverted. -- Michael Bednarek (talk) 02:15, 24 September 2021 (UTC)

The wikidata instructions seem hard to follow, I get lost near the start as soon as it says to locate "Item by title", rather than just using the "Search Wikidata" box at the top right, but after that it looks like it should work. I have only tried some of more basic things on wikidata, (correcting info and adding links rather than merging and migrating) though I think some of this might be suited to editors more experienced than me. Also these instructions are designed for working with links and pages that already exist. Because, initially there would be no article in English for them to create a link for, editors would not need to know how to do this or any other editing within wikidata. If editors are aware of other language articles that are missing from wikidata they can add them, but it is not required as all they would be doing at this stage is looking for the QID. Entering this into the English wikipedia using a tool/option on the article creation page would extract and display the information from wikidata, without the page itself being added to wikidata. Effectively it is a tool that can be used to show a preview of the links that would normally only appear after the article has been created. Only when the English article had been created would there be the need to add it as an entry on wikidata, and the fact that an editor has already identified its matching QID should make this more manageable. EdwardUK (talk) 02:31, 24 September 2021 (UTC)

@Michael Bednarek: @EdwardUK: I'm not sure I see eye-to-eye with regard to the need for the English-language article to already exist. I think of the QID as a concept, in this case I was trying to apply this to the concept of a specific institute of the Russian Academy of Sciences. The concept exists independent of the existence of an English-language article providing information about that concept. Wikidata is proffered as a specific mechanism that substitutes for {{Interlanguage link}}, it doesn't make sense that the English-language article must first exist. I'm guessing that somebody knows how to do this, or else knows that there's some piece that's missing and it can't really do this, but that person is neither you (EdwardUK) nor me. Michael, is there any chance you can set us straight on this? Fabrickator (talk) 03:10, 24 September 2021 (UTC)

I think of Q-numbers at Wikidata as ISBN numbers or barcodes (note the stylized barcode used as Wikidata's logo) which identify a well defined entity; see Help:Wikidata. The Wikipedia entries at Wikidata then provide links to exactly that subject in various language editions of Wikipedia. -- Michael Bednarek (talk) 03:27, 24 September 2021 (UTC)

If the article did not exist, then in theory it would be possible to create what would be a redlink for it on wikidata, yet trying to do so would result in an error because the list of languages on wikidata is intended to aid navigation, for this reason it would not be desirable to have redlinks here as is the case with them being discouraged in our internal navboxes. I think consensus would probably also be against adding a redlink outside of the English wiki as I have seen a past discussion opposing the linking of our draft versions to wikidata in case this was to suggest to other wikis that something here was sub-standard or deficient, and I think adding redlinks would be viewed in the same manner.

With regards to the language template I have just spotted something interesting on the Chinese language version. An example can be found here: zh: 巴克斯特公園 (Baxter Park), linking to Sir David Baxter. This link appears to be their version of the language template, but the redlink and language links have been replaced with a green link. When the link is hovered over it changes to red and displays a navigation popup which roughly translates as: "Entry X has not yet been created, and can be found on the corresponding page of English Wikipedia:X". EdwardUK (talk) 06:51, 24 September 2021 (UTC)

I came across some other Wikipedia (can't figure out which it was) that provides a solution. See the link labeled "General Physics Institute" on User:Fabrickator/Evgenia_Zabolotskaya. Fabrickator (talk) 19:53, 24 September 2021 (UTC)

Aha! This is already supported {{Interlanguage link}} using the WD (QID) parameter... but of something like 50,000 instances of {{Ill}}, only about 2,000 use this feature, quite rare. I would suggest that using {{Ill}} without QID ought to have been deprecated (or at least discouraged), but Wikipedia editors are no different from other people, they repeat what they see and what they are familiar with. So we continue to propagate a use of {{tlc|Ill}] that doesn't really do the job very well. Fabrickator (talk) 04:00, 25 September 2021 (UTC)

The option to use the template to provide a separate link to wikidata next to a redlink avoids the problem of WP:SURPRISE caused by using a piped link. With the template I think that linking to wikidata should be encouraged in certain situations, mainly as an alternative to adding too many language links. But even with a wikidata link I think editors would continue in wanting to select the best ones and have direct links to these languages too, as they think readers would find this more helpful than just the link to the list of languages, and when there are only one or two languages then linking directly to them and leaving out the wikidata link could be seen as reducing unwanted clutter.

The maximum number of language links was increased from 5 to 12 in 2017, when one editor requested it to enable linking to all the language pages for a particular topic even though at the time only about 3 of these were anything more than a stub. I cannot see a significant benefit in this, the links to stubs did not add anything helpful, one or two links to the good pages were all that was needed, and even if they had all been good that would still have been sufficient. If the issue were to be raised again on the talk page again the number may be reduced. There is a certain amount of reluctance/hostility among some editors towards wikidata, but if asked to consider whether with this template it is more helpful to have a) numerous links to stubs, b) a link to one (or two) good article(s) and wikidata, or c) just to wikidata, my thought is that many would opt for b). When those options are presented with arguments towards greater consistency and neater appearance, I think that it would be possible to gain consensus to adjust the template, or at least to establish clearer guidance on how to use the template to best effect. EdwardUK (talk) 18:31, 25 September 2021 (UTC)

@EdwardUK: You wrote:

linking to wikidata should be encouraged in certain situations, mainly as an alternative to adding too many language links.

I consider it objectionable that, when you link using the QID, the Wikidata link doesn't appear if the enwiki article has come into existence (which is particularly problematic if the enwiki article is a stub). But the original concern I had, being the need to update the {{Ill}} template when the article becomes available in a new language, that's only resolved if the QID is specified. As for users being annoyed by being presented with a bunch of irrelevant choices, this problem is solvable by providing some sort of user-customizable language preferences... but WP editors can't be making the call about which interlanguage version is best (for how many reasons? ... even if the editor feels one language is preferable to another when linking from a specific article, that may change over time, it requires the ability to read the mind of the user, and it goes against the principle of having a single set of interlanguage article equivalences per source article).

Should I try to make this clear? We now have a way to record all the instances in which articles on "Prokhorov General Physics Institute" may be available in various languages. Assuming this article existed in several languages, and you would let the editor who's inserting the link in an article specify which language is best, based on the context in which it is linked? So now, the preferred link depends on the where it's linked from? Never mind that those articles change over time, and the best language to link to would also be subject to change, you're doing completely the opposite of what the QIDs do for us. The QID is suitably close to the right solution, and the only logical reason to avoid using it is a belief that nothing pertinent to the choice of link is ever going to change. Fabrickator (talk) 22:21, 25 September 2021 (UTC)

Here's an article where I resolved several links by QID. The one issue I had was where there was an existing article on enwiki for a different topic.... because that makes the Wikidata link disappear ... adding a qualifier solves the problem, also a couple of items had disambiguation pages in other languages, including a qualifier can reduce the risk of future collisions. All in all, this is a much better solution than using {{ill}} without a QID, IMO. Fabrickator (talk) 03:56, 26 September 2021 (UTC).

Something that would assist in creating versions of the template containing a wikidata link could be useful. There is a user script here: User:Cobaltcigs/IllWill, the description for which says it can be used with redlinks to search wikidata for the matching topic and then add the template with language links. (I have not installed it so am not entirely sure of how it works) It may already have an option for, or could be modified for, adding a wikidata link rather than languages. If not then it may be possible to create a similar user script that could be used for this. EdwardUK (talk) 03:47, 27 September 2021 (UTC)

My attention has been directed to WP:Wikidata § Appropriate usage in articles. I am not sure I fully grasp the rationale. The objection seems to focus on the reliability of Wikidata content, but (given my narrow view of WD as nothing more than a table of "equivalent" non-English language articles) this just strikes me as bizarre. This is how decisions are made here in WP-land, one more piece of evidence (IMO) giving credence to the hypothesis that WP is dysfunctional. Fabrickator (talk) 10:05, 27 September 2021 (UTC)

I was aware that opinion was generally against the use of wikidata and in particular the use of it to automatically add content to wikpedia articles (in case this content may be inaccurate), but the summary for the New RFC (June 2018) suggests no consensus over its use in the language template. Had the RFC banned this then the ability to use this parameter of the template should surely have been disabled and deprecated at that time, which did not happen, and since then another feature, the short= parameter has been added for use with the wikidata link. This would seem an illogical thing to add if the link itself had been prohibited. EdwardUK (talk) 15:44, 27 September 2021 (UTC)

One of the main objections to Wikidata was the fact that the Wikidata "reliable source" requirement might not be up to the standards of the enwiki reliable source requirements. In this instance, the QID is used to obtain a set of interlanguage links on other Wikipedia sites. The query as currently set up by {{interlanguage link}} uses an anchor to go to the Wipkipedia links section of the Wikidata page for that QID. It would be helpful if this could be chaned to display only the Wikipedia links, I presume that this is not too difficult to do. It might be desirable to have certain constraints on these links (e.g. disallow revision ids), but that concern is not a good reason to reject the concept... and to reject on this basis would result in a case of catch-22, nobody is going to fix this problem as long as such Wikilinks are disallowed.

With regard to the closure New RFC on linking to Wikidata (WP:Manual of Style), the statement :

As to the other proposed exception of linking to WD, by inline inter-language link, given that there is roughly a numerical tie and there's no clear-cut refutable argument(s) from either side, I am unable to see any consensus.

. But I think I am properly perplexed when this becomes:

Wikidata should not be linked to within the body of the article except in the manner of hidden comment(s) as to mentioning the Q-number.

It seems to me that you get to this depending on how the proposition is structured. For instance, if this had been interpreted as the following independent propositions:

* prohibit Wikidata links in hidden comments

* prohibit Wikidata links in interlanguage links

* prohibit Wikidata links in ordinary text

Then we'd have no consensus on the use of Wikidata links in interlanguage links, and given that the current state had been to allow them, these links would continue to be allowed. Fabrickator (talk) 01:17, 30 September 2021 (UTC)

@Fram: At User talk:Winged Blades of Godric § June 2018 RfC on Wikidata links, User:Fram responded to this, stating

No: there is consensus that Wikidata links are not allowed in text, and there is no consensus to make an exception for interlanguage links. Which means that the first rule also applies to the second case

.My response to Fram is "Thanks for providing the opportunity to elaborate on my point."

Of 31 votes cast, I interpreted 25 as having a statement that I could assign to one of 3 categories:

* 12 support the proposal (prohibit WD links in interlanguage links and ordinary text)

* 9 oppose the proposal (allow WD links in interlanguage links and ordinary text)

* 4 support the proposal with exception (allow WD links in interlanguage links, prohibit them in ordinary text)

So is this 16 to 9 in support of the proposal, while 13 to 12 (no consensus) to exempt the rule for interlanguage links? Or is it 16 to 9 to prohibit links in ordinary text, and 13 to 12 (no consensus) to allow them in interlanguage links (thus they would continue to be allowed). So with the identical facts, being presented two different ways yet reaching contradictory results, this demonstrates that the determination made in the closure of this RfC was arbitrary." Fabrickator (talk) 02:07, 3 October 2021 (UTC)

Why do we customize appearance of stub tags by topic?

I was recently questioning the utility for readers of having stubs display their category. For instance, at Lukas Lämmel (to choose the first Special:Random hit), why does it help readers to say This biographical article related to association football in Germany, about a midfielder born in the 1990s, is a stub. rather than just the standard This article is a stub.? Lämmel's page already establishes the basic information about him, so it doesn't help to repeat it at the bottom. It'd be better to be concise (or, if we're allowing ourselves some wordiness, to use it to provide better instruction on how to de-stubify an article). The icon is purely decorative. For editors, the stub category (Category:German football midfielder, 1990s birth stubs) already appears in the visible category list, and most stub sorting happens via sorters clearing out the maintenance category rather than stumbling on an unsorted stub anyways.

Given all this, I'm inclined to suggest (in a more formal proposal in a highly visible setting) that we stop using custom displays for stub tags and have them all adopt the standard {{Stub}} appearance. To be clear, I'm not considering proposing that we stop using sorted stub tags, which would be very different. Are there considerations I should have in mind for making such a proposal?

Note: I'm posting here rather than WT:WikiProject Stub sorting since I'm interested in feeling out what the likely response will be among a broad group of editors, not stub specialists. I'm putting an invite there, though, as I do want to hear from those more heavily involved with stubs. I'd appreciate if those coming here from that invite could note so in their comments. {{u|Sdkb}} ^talk 00:16, 21 September 2021 (UTC)

I don't claim to understand all of this metadata stuff that gets incorporated into WP, but it seems to me that having these somewhat vague characteristics be called out in a specific place (i.e. at the bottom of the page) serves multiple purposes:

1. This is content that should be populated at the initiation of the article.

2. This should avoid random editing later on..

3. It saves us from having to dig this out from the article as it develops over time.

Maybe I'm missing something, but it seems like this may be quite useful. Fabrickator (talk) 07:13, 21 September 2021 (UTC)

The text "related to association football in Germany, about a midfielder born in the 1990s," explains how the article gets into Category:German football midfielder, 1990s birth stubs. The rest of the text is boilerplate, it is generated by {{asbox}}. --Redrose64 🌹 (talk) 08:59, 21 September 2021 (UTC)

I have never been convinced by the theoretical basis for stub sorting, but I am happy it exists in practice. Let's talk about the history here: stub tags and stub sorting are old and predate both talk page assessment tags and the category namespace's transformation from a chaotic mess of tags into something resembling a system. Stub tags were always centrally controlled and provided a parallel and working system both for basic assessment and for categorisation. Sometimes this results in oddly fine categories like the one you mention above, a bit different from those used a long time ago on Ambrosius Stub, the best stub we've ever had. While we might not strictly still need this (if we assume that talk page assessments work perfectly, which isn't true either), it isn't terrible to have a redundant system in place. However, the really good thing about stub sorting in my view is not that it is all that useful by itself, but that most stub sorters perform a lot of cleanup tagging, page triage and categorisation while stub sorting. I'd be sad to lose that.

As for having different stub tags display differently: I kind of agree that it is more important that the article is a stub and that it should be expanded than what type of stub it is. For better visuals, all stubs should have a "stub" icon, not a distracting German football for the football related ones. (Similarly, Portals should use a "Portal" icon, not a decorative picture related to the portal topic). —Kusma (talk) 09:21, 21 September 2021 (UTC)

@Kusma: Thanks for that history! The broader thought about stub sorting being redundant to talk page banners and categorization did occur to me. It's hard to know whether getting rid of it would push stub sorters to add talk page banners instead or just make them give up. That would be an even huger change than what I'm considering here, though, and Wikipedians aren't exactly known for embracing bold changes to the way we operate, so I doubt it would pass. {{u|Sdkb}} ^talk 13:14, 21 September 2021 (UTC)

I like the idea, although Redrose does make a good point so maybe instead it could include what the subject is related to as part of the stub template since some stubs are literally 1 sentence, not really establishing what they are known for. ― Blaze The Wolf^Talk_{Blaze Wolf#0001} 15:07, 21 September 2021 (UTC)

I'm sure that somewhere there's an article that has a stub template that includes information that the article itself does not, but my sense is that it's very rare. If an article is so bad it doesn't establish the basic thing it's about, that's a problem beyond anything a stub tag can fix. {{u|Sdkb}} ^talk 15:16, 21 September 2021 (UTC)

Stub sorting and WikiProject banners serve separate purposes and are not interchangeable. Stub sorting is an article categorization task. The meaning is "This is a short article about Subject _____." WikiProject banners are associating the article with a semi-formal group of editors. It happens that most (but not all!) WikiProjects care about articles mostly (but not entirely!) within a given subject area, but others don't follow subject areas at all, and many articles are interesting to a wide variety of WikiProjects. Talk:Leonardo da Vinci includes 17 WikiProjects. WhatamIdoing (talk) 16:40, 21 September 2021 (UTC)

They're definitely not interchangeable, but if I were constructing Wikipedia's systems from scratch, I would make one system for categorizing things, not multiple partially redundant ones (categories, talk page banners, structured data at Wikidata, stub tags, even lists and navboxes). Anyways, this is all a tangent; if editors want to consider changing stub categorization more fundamentally, we should open a separate thread for that. {{u|Sdkb}} ^talk 17:22, 21 September 2021 (UTC)

If I were constructing Wikipedia's systems from scratch, I wouldn't put metadata in a free-form text file. WhatamIdoing (talk) 02:14, 22 September 2021 (UTC)

The images attached to stub templates draw attention to the stub tag; I hope that doing so might suggest an editor/reader edit the article, and images are more compelling than text. Also, I'm not fussy about what the text of the stub tag says, as long as it deposits the article in an appropriate stub category, for the use of editors who browse the categories rather than noticing the individual tag. (Also also, WhatamIdoing's point is spot on and not germane to this discussion, though I understand why folks think "Stub-Class article" and "stub" are related.) Her Pegship (?) 16:50, 21 September 2021 (UTC)

• One reason for thematic stub tags is that a stub article, by its nature, is incomplete and so lacks information. The thematic stub tags therefore help both readers and editors understand the topic and take it forward. The graphical icon is also useful in drawing the reader's attention and encouraging them to develop the article. They are also reasonably attractive and inoffensive. They thus compare very favourably with the obnoxious banner tags at the head of articles which are far more unpleasant and unhelpful. It is those which should be done away with. Andrew🐉(talk) 18:48, 21 September 2021 (UTC)

  Per my reply to Blaze the Wolf, I don't think stub tags actually tend to bolster understanding of a topic in the vast majority of cases. But even for the cases where we do, a stub tag isn't where we want to be doing it for a multitude of reasons: it doesn't fit with their essential message (designating an article as a stub), they're at the bottom of a page (whereas we want essential info at the top), and they're going to be removed once the article is improved. {{u|Sdkb}} ^talk 19:00, 21 September 2021 (UTC)

  they're going to be removed once the article is improved - that's kinda the point, we want people to expand the article and when they do so, that will justify the removal of the stub tag. --Redrose64 🌹 (talk) 23:40, 21 September 2021 (UTC)

I'm sure this sounds/is stupid, but I find that the stub tag categorization line encourages improvement of the article because, by indicating in the voice of the tag itself that the tag knows what the article is about, it makes it feel like someone has thought about how this article fits into the broader encyclopedia. If I read "This food-related article is a stub" I feel that Wikipedia's coverage of food in general is lacking because of this article's stubbiness, not just that this particular niche article is too short. This increases the urgency in a way that I find maybe helpful or at least charming. CapitalSasha ~ talk 19:40, 21 September 2021 (UTC)

I agree that the icons should be removed. They serve at best a decorative purpose. Some people here are arguing they should be kept because they "draw attention to the stub tag", but I think this is precisely the reason they should be removed. If drawing the reader's attention away from the content of the article and toward the invitation to improve it is a valid goal, then why not make them flashing animated gifs to achieve that goal even more effectively? Colin M (talk) 23:46, 21 September 2021 (UTC)

As the stub tag and its image are located at the bottom of the page, I don't see the (very small) icons as drawing attention away from the article itself; they're discreet enough to catch the eye but not so intrusive as to demand the reader's attention. In a related aspect of the appearance of tags, if the icon is a problem I would at least propose that a generic stub icon such as be applied to all stub tags (though it would be too bad to waste the effort we've put into creating appropriate icons!). Her Pegship (?) 00:09, 22 September 2021 (UTC)

I have a pretty significant case of Banner blindness where stub tags (and much of the English Wikipedia's other infrastructure) is concerned. Could any of the editors here comment on whether they personally have expanded an article because the image in the stub tag caught their attention? WhatamIdoing (talk) 02:18, 22 September 2021 (UTC)

I chronically forget to remove the stub tags AFTER I'm done improving the articles. It's a curse. I've probably annoyed other editors over it. I've never paid it much mind otherwise, as a reader or editor. Estheim (talk) 06:37, 23 September 2021 (UTC)

I doubt that anyone is annoyed by that. They're probably just grateful that you expanded the article. WhatamIdoing (talk) 18:27, 23 September 2021 (UTC)

Lol, hope so! Trying to psychoanalyze how I feel about decorated vs non-decorated tags, the ones that are decorated make me think the article is a part of a highly active and enthusiastic Wikiproject. Like, I wouldn't be surprised if Hurricanes and Military articles had more decorative stub tags, but it can create that impression even if the actual Project is actually moribund. This is speaking as an editor, not as a reader. Estheim (talk) 19:45, 23 September 2021 (UTC)

@WhatamIdoing: I think the Wikiproject assessment is more likely to lead to improvements. At least in the Wikiprojects to which I belong, the tables of importance by quality are used to try to ensure that if possible Top or High importance articles aren't stubs. I can't recall having responded to a stub template or the categories created by stub templates. Peter coxhead (talk) 08:02, 23 September 2021 (UTC)

Using TV/radio call letters/signs instead of station branding for News articles citations (US and Canada)

I am aware that any station in the US and Canada would use a generic brand of a newscast with the name of the network and it can happen to most stations. Others use different names. Here's an example of what I mean:

• If you refer to ABC 7 (Or in other cases, ABC 7 [Eyewitness/Action] News) for source, it's either KGO-TV, KABC-TV, WLS-TV, WABC-TV, or any other TV station that is in that channel affiliated to the network.
• If you refer to Fox 5 (or Fox 5 News) for a source of the article, you refer to KTTV, WTTG, WNYW, or other stations with the name Fox [Channel number] News.

Replacing the station's name for their newscasts and using just the station's call letters (for an example: ABC 7 in New York as WABC-TV]]) is in my view the best solution so it can not only become clarified, but it makes it easier for people to know which station it is directly coming from. I must mention, this should apply to local newscasts in the US and Canada. I really feel that its much better this way so people don't have to figure out which station this source it goes to and eases up the need to search which source it is coming from. 20chances (talk) 00:33, 21 September 2021 (UTC)

Why does it matter which station it's coming from, if they're all showing the same newscast? WhatamIdoing (talk) 16:42, 21 September 2021 (UTC)

The proposal is for local newscasts, which rarely get picked up by the national networks. - Donald Albury 18:14, 21 September 2021 (UTC)

Are the USA and Canada the only ones where two different stations far enough to each have the same place in the over the air spectrum that would be designated the same way? Could this also apply to the different broadcasters that are part of ABC (Australia)?Naraht (talk) 18:45, 21 September 2021 (UTC)

All TV stations in the US and Canada broadcast regionally. However, they're affiliated to the network that they broadcast. For an example. WABC-TV only broadcasts in the NYC Area and airs ABC Programming. CBLT-DT in Toronto only airs in the Greater Toronto Area, and is part of the CBC Network. Australia has regional stations just like in the U.S. but it is different. 20chances (talk) 23:47, 21 September 2021 (UTC)

We normally refer to works by their titles, in this case that is part of the title of the source - the government license number could be useful, but in general is less informative. — xaosflux ^Talk 18:59, 21 September 2021 (UTC)

I will agree that using the station call letters (Like using KABC-TV (which uses abc7.com) for the use of any articles for its newscasts if using the article from the station.) My problem is that not mentioning the call letters and just using the name of the website from the station (ex: abc7.com for KABC-TV) or using ABC 10 to refer to a station in Sacramento or San Diego in California or other similar ones can not only be vague, but also confusing if not directed to the right source. 20chances (talk) 23:47, 21 September 2021 (UTC)

You certainly can do both. Here is an example citation:

{{Cite episode
|series=NBC 6 South Florida News at 12pm
|author=NBC 6 South Florida
|network=NBC
|station=WTVJ
|minutes=14|quote=This experiment concludes that water is wet
|date=2021-09-22}}

Which produces:NBC 6 South Florida (2021-09-22). NBC 6 South Florida News at 12pm. 14 minutes in. NBC. WTVJ. This experiment concludes that water is wet

— xaosflux ^Talk 13:53, 23 September 2021 (UTC)

My only if is what if there's a link to that segment that is posted online? 20chances (talk) 16:54, 23 September 2021 (UTC)

@20chances: we have lots of citation templates, that one is in Template:cite episode. — xaosflux ^Talk 16:57, 23 September 2021 (UTC)

@Xaosflux:I agree on the use of citations, but the problem is that some stations don't mention where the article and/or the news segment is uploaded. Sometimes, many articles do link a segment from a newscast (some don't mention the times on which it was actually aired) 20chances (talk) 01:39, 24 September 2021 (UTC)

@20chances: If you're citing a web upload of a video, probably best to use {{Cite web}} even if the video was aired on TV at some point. If you're looking to add a link to an existing {{Cite episode}} citation, it does accept the standard |url= parameter, though interestingly that parameter is documented as (emphasis mine) URL of an online location where the text of the publication can be found. (But then there's also a separate |transcript-url=, which makes me think |url= doesn't have to link exclusively to text.) -- FeRDNYC (talk) 18:00, 29 September 2021 (UTC)

{{Re|FeRDNYC]] Right. The only problem is that people will use the name of the website instead of the station's call letters as the source for the website parameter like the examples I mentioned above. So instead of using the URL abc7ny.com for the website parameter for the ABC station in New York, since there's 2 TV Stations on channel 7 that are affiliated to the ABC Network, it would be WABC-TV instead. Hopefully I'm trying to get it right.

Notified of Manual Reverts

Hello! So I discovered that you get a notification when someone reverts your edit in any way BESIDES a manual revert which I find rather interesting. So I propose that people are also notified when their edit is reverted manually. ― Blaze The Wolf^Talk_{Blaze Wolf#0001} 19:41, 22 September 2021 (UTC)

Just add the page to your watch list… then you can track all edits not just reverts. Blueboar (talk) 19:50, 22 September 2021 (UTC)

Won't this just create talkpage bombardment?--MollyPollyRolly (talk) 22:05, 22 September 2021 (UTC)

@MollyPollyRolly: The notifications never go to your talkpage though. ― Blaze The Wolf^Talk_{Blaze Wolf#0001} 22:21, 22 September 2021 (UTC)

@Blaze The Wolf: Where does it go then? I thought that notifications are linked to talkpages, like we see with ClueBot.--MollyPollyRolly (talk) 01:20, 23 September 2021 (UTC)

@MollyPollyRolly: ClueBot uses warnings which go to talk pages. Notifications go to the bell icon. ― Blaze The Wolf^Talk_{Blaze Wolf#0001} 01:21, 23 September 2021 (UTC)

@Blaze The Wolf: Still, even it does go to a bell icon, it will still be a bombardment of some kind. For example, a new editor edits an article which you revert by using manual revert. First, majority of new editors don't even pay attention to what is on top. Second, if the editor edits multiple articles at the same time, it might be considered as notification spamming.--MollyPollyRolly (talk) 02:31, 23 September 2021 (UTC)

@MollyPollyRolly: That is true. And the reason ClueBot's warnings go to the bell icon is because you are automatically notified about things on your talk page. ― Blaze The Wolf^Talk_{Blaze Wolf#0001} 12:16, 23 September 2021 (UTC)

They still require attention. I think it's a bad idea. Doug Weller talk 15:42, 23 September 2021 (UTC)

@Doug Weller: The idea itself is not bad, the outcome of it might spill a disaster to an already fragile project. :(--MollyPollyRolly (talk) 20:12, 23 September 2021 (UTC)

Ya, I realized that if someone makes an edit that is a manual revert of an older edit, if you got notified about manual reverts then it could spam multiple people's notifs. ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 16:41, 24 September 2021 (UTC)

If memory serves, brand-new accounts aren't notified about being reverted. Whatamidoing (WMF) (talk) 16:59, 24 September 2021 (UTC)

That seems rather interesting. It can technically do both harm and good, depending on what the person behind the account is wanting to do. ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 18:32, 24 September 2021 (UTC)

@Blaze The Wolf: I suspect the thinking there is that new users being reverted would be helped more by a talk page message (even if it comes in the form of a warning) giving some guidance about why they were reverted, vs. just a notification with no explanation behind it. And we are all encouraged to template the n00bs when we revert them, so they know what they did wrong.

Regarding the idea in general, I feel like it would have to be opt-in, if it were implemented. But would that be an all-or-nothing, sitewide opt-in, so you get notified every time there's a revert of some edit you made months and months ago and have already forgotten about? Or would it be on a per-page basis, in which case... yeah that really just sounds like the watchlist, huh? -- FeRDNYC (talk) 16:06, 27 September 2021 (UTC)

@Blaze The Wolf: The removal of request templates after fulfilling the request (like a file move or non-free reduce) is also a manual revert. Archiving of discussions can also result in manual reverts. — Alexis Jazz (talk or ping me) 21:12, 3 October 2021 (UTC)

What to do about infoboxes for soundtracks in film articles?

Wikipedia:WikiProject Albums/Backlog elimination drive: Album covers is an effort to reduce the Category:Album infoboxes lacking a cover backlog, which has approximately 24,000 entries. Over at WikiProject Film, editors are discussing how there are many film articles with infoboxes for soundtracks lacking cover art. The lack of images in these infoboxes is a major source of the backlog, but we're not sure how this can be resolved. Sometimes, soundtracks have unique covers, other times they are similar to film posters (fair use images).

If you have ideas, please contribute to the discussion at WikiProject Film. And, of course, editors are invited to join the campaign to reduce the missing album covers backlog. Thanks and happy editing! ---Another Believer _(Talk) 16:00, 23 September 2021 (UTC)

My only solution to this would be to add a cover (if available).--Filmomusico (talk) 20:15, 23 September 2021 (UTC)

Some option to make articles easier to read

Hello! So I had an idea of an option in the settings that would make articles a bit easier to read. My reasoning behind this is people like me (I'm autistic) have a hard time reading some longer sections of articles. This is mainly due to having sort of a short attention span, making it hard to read long sections of articles in one sitting. I propose some way to break up article sections in a way that makes it easier to read. I'm not exactly sure how we would do this which is why I put this in idea lab. Some of the ideas I have are making the text slightly larger, making different parts of the article highlighted in different colors, or making the space between different parts of the article/section larger. Let me know what you guys think and if you guys have any other ideas as to how we would make larger articles easier to read. ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 16:40, 24 September 2021 (UTC)

I should probably specify that not everyone who has this issue is autistic. Dyslexia can also make reading articles an issue. ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 16:44, 24 September 2021 (UTC)

@Blaze The Wolf, have you tried "new" Vector? @AHollender (WMF) designed it to have a narrower width (on most people's font/screen-size combinations) because shorter lines are easier for many people to read. If you want to try it out, then go to Special:Preferences#mw-prefsection-rendering-skin and un-check the "Legacy vector" item.

Remember: It often takes people two weeks of regular use to get used to a change in the appearance of a website. A few things (e.g., the search bar and links to non-English Wikipedias) are in different places, and you'll have to re-train your habits. But if you stick with it through that adjustment period, you might find it easier to read articles. Whatamidoing (WMF) (talk) 17:06, 24 September 2021 (UTC)

At the same time, many of our articles do have over-long sections, which I'm sure puts a high % of readers off. Editors should get in the habit of breaking them up. It might be an idea if MOS:PARA actually specified a figure for a length that is likely to be too long - at the moment it just says cryptically "paragraphs that exceed a certain length become hard to read" - yes, but what length? Johnbod (talk) 17:15, 24 September 2021 (UTC)

I wonder how it would work to have some kind cursor which highlights one paragraph at a time (or perhaps one line, or a contiguous span of N lines). As you finish reading each paragraph, you could use the up or down arrow keys to move to the next paragraph. A nice side-effect of this could be that the software keeps track of the last paragraph you read and when you revisit the page, gets you back to the same place. That might make it easier to read a bit, go away, and come back to read some more. -- RoySmith (talk) 18:04, 24 September 2021 (UTC)

I highlight (select) text as I read all the time. I suspect many people do. It drives me nuts when a website overrides the selection behavior (Medium, Feedly, etc.). Nardog (talk) 05:28, 25 September 2021 (UTC)

@Nardog: That is a close second, in my list of egregious web-design offenses that should be capital crimes, behind setting the visited link color the same as the normal link color. That I absolutely loathe, and (to all site designers guilty of this crime:) if I visit your site a lot, I will add a userstyle to undo your bullshit, you bunch of heathen, poo-flinging webmonkeys! -- FeRDNYC (talk) 16:11, 27 September 2021 (UTC)

Infinite scroll isn't the first, FeRDNYC? For shame. IznoPublic (talk) 20:17, 29 September 2021 (UTC)

@Izno: Heh. I have nothing against infinite scroll per se — like too many things, it's neither inherently good nor bad, but its power can be difficult to wield correctly, and it's all too easily abused. Infinite scroll as a replacement for pagination is fine as long as (a) there's still a well-defined structure and ordering to the contents; (b) you can reach individual items directly, and (c) you can skip to a point within the infinite scroll, so you don't have to work down from all the way back at the start. (Granted, almost nobody does all of that correctly.)

Tumblr's archive pages for blogs are an example of "pretty good". They scroll "infinitely" into the past (until you hit the first post), and posts are grouped by month. You can start from the "top" (end/latest post) of any given month by selecting it from a dropdown menu, and the infinite scroll will work backwards from that point instead of from "now". You can also filter the contents of the list by things like post type or tag matches. It's mostly OK, really.

The sadly-more-typical "infinitely accumulating progression of barely-related content with no rhyme, reason, or (most importantly) navigation/control", though... well, I guess I figure that's more than a "bad web design" issue. Those sites are fundamentally engineered to convert users' wasted time into site revenue. -- FeRDNYC (talk) 22:52, 29 September 2021 (UTC)

@Nardog Yup, I do that too (selecting text to make it easier to read). Not as a regular thing, but it's an option I have in my toolkit when I'm faced with a website that's made just plain bad design decisions. There's lots of good human-factors research on how to make text easier to read. Font selection, line length and spacing, paragraph formatting, contrast, kerning, etc, etc. And then there's the legions of web designers who do things "because it looks good". -- RoySmith (talk) 20:42, 29 September 2021 (UTC)

@Whatamidoing (WMF): I've tried new Vector and I haven't really liked it. It seems really weird to all of the sudden have the article and sidebar be on the same "level". Overall it just feels weird to me and I haven't liked it so I've switched back to legacy Vector. Also, the narrower width isn't noticeable at all and to me it would just make sections seem longer. I do honestly wonder if it's because when I'm staring at black text on a computer screen, it all sort of starts to blur and black highlights form around the words and in between lines (which aren't really there, it's an illusion). I would honestly love for WIkipedia to have a dark mode but at the moment, Wikipedia's dark mode just feels like "high contrast" mode where the colors are reversed, therefore making a pseudo-dark mode. ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 18:31, 24 September 2021 (UTC)

For RoySmith's idea, what we need is an accessibility expert who is also a JavaScript expert. Like RexxS (talk · contribs). --Redrose64 🌹 (talk) 19:22, 24 September 2021 (UTC)

• The Encyclopaedia Brittanica, in those far-off days when it was a paper encyclopaedia, used to be in two sections - the Micropeaida (Index and Ready Reference) and the Macropaedia (knowledge in depth). For example, when articles of famous people were in the Macropaedia, the Micropaedia would have a corresponding article for that person saying "Abstract of text biography." Would it help if all articles in Wikipedia were headed by an "Abstract" section, similar to the Micropedia articles in the Encyclopaedia Brttanica? YTKJ (talk) 21:38, 24 September 2021 (UTC)

That's what MOS:LEAD is supposed to be. Unfortunately, few articles are written that way RoySmith-Mobile (talk) 09:31, 25 September 2021 (UTC)

• There was an article a bunch of years ago, I think it was posted at Engadget but even knowing that I can't seem to find it anymore, it's been around 10 years so hardly surprising. But in the context of some speculation about the future of human-computer interfaces, one of the advances suggested was that eye-tracking software could observe your progress through an article as you read it, and effectively "mark your place" on the page as you go. Get halfway through a long-form Sunday NY Times thinkpiece and have to run out the door to catch a train? Pull the article up on your mobile device once you're on board, and the browser scrolls right to the last word you read so you can pick up exactly where you left off.

I mean, we all know the most likely use of such technology is to force people to actually watch ads in their content, or other evil manipulations of that sort. But, still, there are some potentially beneficial aspects to that kind of thing, deep down there under all the obvious perversions of it. -- FeRDNYC (talk) 16:27, 27 September 2021 (UTC)

Alright so I haven't really seen many ideas about this. I understand that New Vector might help, however some users don't want to use New Vector, so any ideas that might work with both New and Legacy Vector? ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 19:07, 5 October 2021 (UTC)

Mnemonic for evaulating potential vandalism

Last night, I thought of a mnemonic for evaluating potential vandalism, and I wrote it on a user subpage (User:Plutonical/MOUSE). I'm posting it here to see what you guys think.

M - Maliciousness – Is the edit seemingly malicious?

O – Overtness – Is the edit openly and blatantly disruptive?

U – User – Does the responsible user have a history of vandalizing Wikipedia?

S – Source – Is the edit based on a reliable source?

E – Experience – Is the responsible user new?

Is this in line with current wikipedia policies in your opinion? Plutonical (talk) 12:08, 30 September 2021 (UTC)

This is a good idea for a mnemonic, but there is a change that I think can improve it. The experience of the user does not greatly influence if the user is prone to vandalising, for example: A user that has been on Wikipedia for 3 months can still vandalise, regardless of the time she/he has been on the site. Perhaps change the E to something more constitutional? I don't know, but I think this can be a potential improvement, regardless it is a good, nice, and rememberable mnemonic that can be extremely useful. --Pink Saffron (talk) 14:33, 1 October 2021 (UTC)

Point E being true does not mean the edit is more likely to be vandalism. It's meant to help check if it's a new user who really doesn't know much about the site and is using an article as a sandbox or damaging them accidentally. That way we avoid biting as per Wikipedia:DONTBITE Plutonical (talk) 14:26, 2 October 2021 (UTC)

• Points 3 and 5 seems slightly redundant to me, they both seem to be variants on "does the user have any productive contributions". It's also not the case that a user with experience is immune from vandalising, there's been quite a few cases of experienced editors making sock puppets to vandalise. I also think the "source" point misses the mark - if a user adding sourced content then it's probably more a case of WP:NOCLUE than vandalism - they're probably trying to improve the encyclopaedia, they just don't know the details of WP:RS. It wouldn't be obvious to a lot of newcomers that the daily mail of facebook are not suitable for adding content to articles for example, that doesn't make their edits vandalism. 192.76.8.74 (talk) 05:50, 2 October 2021 (UTC)

point 5 (E) is there to check if the user might be using random articles as a sandbox or damaging them for other reasons.. It's a measure against putting harsh punishments on newcomers. Plutonical (talk) 14:24, 2 October 2021 (UTC)

Really not sure you need an acronym to evaluate anything. 99%+ of vandalism is obvious to everyone, with the other 1% obvious to everyone who's familiar with the subject. Headbomb {t · c · p · b} 13:31, 2 October 2021 (UTC)

Default Protection of Closed RFAs

I was thinking and wondering, given how some RFAs experience vandalism, and it's very unlikely they'll be edited after closure, why RFAs aren't automatically fully protected by the closer as a standard practice? Could this be a viable practice? Would it make sense? ~Gwennie🐈｟💬 📋｠ 21:09, 3 October 2021 (UTC)

Full protection is a bit much as that would impede template maintenance, fixing lint errors and other such legitimate edits. But extended-confirmed protection would probably be a good idea. – SD0001 (talk) 08:50, 4 October 2021 (UTC)

Could you show me some statistics on how much of a problem this is first? — xaosflux ^Talk 10:27, 4 October 2021 (UTC)

I wish I could come up with some, however that feels like OR. ;) (How would I gather the requisite data?) ~Gwennie🐈｟💬 📋｠ 01:06, 5 October 2021 (UTC)

@Gwennie-nyan: in general, we only protect things when necessary to prevent disruption to the project. Over time we have had to extend certain preemptive protections (such as to templates that are widely used) because as a class they have been disruptively edited previously. We generally don't see a lot of disruption at closed discussions such as RfA (or the immensely larger number of AFD pages) - so to consider preemptive protection on them we should have a showing of a pattern of disruption first. I agree it seems reasonable that those pages don't have a need to be edited - and from a "content" perspective - they shouldn't be. From a technical perspective, sometimes they need to be - and currently can be by anyone doing such technical updates. — xaosflux ^Talk 01:16, 5 October 2021 (UTC)

My impression is that this issue isn't serious enough to warrant preemptive protection. If a particular RfA page is being persistently targeted for vandalism or harassment, then we could protect them individually, but we shouldn't protect all RfA pages preemptively, especially if, as SD0001 mentions, there are legitimate reasons for editing them after closure. See also WP:PREEMPTIVE. Mz7 (talk) 06:18, 5 October 2021 (UTC)

Import from Commons

On occasion we lose Commons-hosted images that we could have hosted as fair use had there been a simpler way to import the file from Commons (similar to how we can export to Commons). On another talk page @Alexis Jazz said this is possible by creating an upload_by_url user right that a gadget would then use to preserve/import the file's edit history. This would require community consensus for a configuration change, so wanted to open for discussion. If you're wondering what we'd be looking to import, offhand: (1) Any file that would sufficiently meet WP:NFCC fair use criteria but happens to be uploaded to the wrong place, (2) Images that meet our free use criteria (US-based copyright) but not Commons' (US-based and country of origin's copyright), such as freedom of panorama violations. Related: T214280. czar 04:55, 4 October 2021 (UTC)

I think I'd want to know exactly how upload_by_url works. Jo-Jo Eumerus (talk) 07:35, 4 October 2021 (UTC)

@Czar: is the workflow for this, with examples, available somewhere? I did a very quick direct test (resulting in testwiki:File:Лежка_моржей_на_острове_Нортбрук-test.jpg) which did get the file over, but did not get the "file's edit history". — xaosflux ^Talk 10:36, 4 October 2021 (UTC)

@Xaosflux: What do you mean? — Alexis Jazz (talk or ping me) 11:11, 4 October 2021 (UTC)

@Alexis Jazz: testwiki:File:Лежка моржей на острове Нортбрук-test.jpg was an upload_by_url from commons:File:Лежка моржей на острове Нортбрук.jpg. The upload part, and not having to mess with downloading and reuploading the file, itself seemed to go fine - but it did not do anything about preserving the attributions such as the original uploader information from commonswiki, or even mention the upload_by_url source in a log or in the file description. — xaosflux ^Talk 12:01, 4 October 2021 (UTC)

I think I confused Czar. I said It would perhaps be feasible to create a gadget if we granted users the upload_by_url right and added upload.wikimedia.org to the whitelist for that. I'm not saying it would be impossible otherwise, but it would be a whole lot less messy. Either way page/upload history wouldn't be preserved this way, only mw:Extension:FileImporter can do that. The either way here means that a gadget, whether it uses upload_by_url or not, will not preserve page/upload history like fileimporter does when exporting to Commons and this way refers to gadgets in general. It's just that a gadget with upload_by_url would be easier to create and less prone to errors. Such a gadget would (oversimplified):

• Generate the link to the full image for use with upload_by_url
• Obtain wikitext of the filepage on Commons
• (optional) obtain username of the original uploader
• (optional) do some replacements for Commons-specific templates, remove DR templates, etc
• (optional) do some replacements based on user input (I'm thinking a little form where you select PD-USonly, non-free logo, non-free biog-pic, etc)
• (optional) check if the image is >0.1 megapixel and claimed as fair use, if so tag for non-free reduce
• Upload file here with the updated wikitext

Hope this clears things up. Without upload_by_url the image would have to be downloaded to the computer of the user and uploaded to enwiki. That would be more complicated and more likely to fail so I'm not particularly interested in trying to walk that path. — Alexis Jazz (talk or ping me) 11:11, 4 October 2021 (UTC)

• Without solving for the how to ensure proper licensing and attribution components, working on the how to change the download/upload workflow to link-for-upload doesn't seem extremely useful (nor is yet figuring out who should be allowed to do this, and how/if to manage such group). How prevalent is this situation, and is there someone that wants to work on building the mechanics for such a process? — xaosflux ^Talk 15:12, 4 October 2021 (UTC)

  @Xaosflux, I don't have the means to assess prevalence but one way could be to see which image-less articles have a talk page notice that a Commons image is (was) up for deletion. I know it's affected me perhaps a dozen times. I also know sometimes images are uploaded to Commons by accident. I imagine the technical work needed for the transfer is a major deterrent for preserving the image on ENWP. I was surprised there was no easy way to transfer images back to ENWP. czar 18:35, 9 October 2021 (UTC)

We once had Wikipedia:Bots/Requests for approval/Commons fair use upload bot 2, but then its operator was globally banned in 2014, and no one restarted it. I believe Fae expressed interest in doing so at one point, bur the plan fell through, and in any case they have now been banned. * Pppery * _{it has begun...} 18:04, 10 October 2021 (UTC)

Adding several namespace shortcuts

Moved from WP:VPP

While contributing to English Wikipedia, I found that some namespace shortcuts are missing. For example:

• H: pointing to Help:
  • HT: pointing to Help_talk:
• T: pointing to Template:
  • TT: pointing to Template_talk:

if we add these shortcuts to English Wikipedia, this will makes links shorter and easier to access, esp. with shortcut services. Wiki Emoji | Emojiwiki _Talk~~ 12:27, 5 October 2021 (UTC)

HT: and TT: are interwiki prefixes, so they can't be used. WT: isn't a namespace shortcut either, but there are many redirects substituting for that. See Special:PrefixIndex/H: and Special:PrefixIndex/T: for existing shortcuts. Making more shortcuts just means we'll have more strange cross-namespace redirects such as Wikipedia:Kill (the page should properly be called Project:Kill). —Kusma (talk) 12:38, 5 October 2021 (UTC)

• Administrator note @Emojiwiki and Kusma: I moved this to VPI, it is certainly not a ready-to-go policy proposal (and I really don't think it ever will require a policy update even if it was to go forward). — xaosflux ^Talk 14:32, 5 October 2021 (UTC)
• Please see Wikipedia:Perennial_proposals#Create_shortcut_namespace_aliases_for_various_namespaces for some background on this topic. — xaosflux ^Talk 14:32, 5 October 2021 (UTC)
• @Emojiwiki: ht:Paj Prensipal, tt:Баш бит — Alexis Jazz (talk or ping me) 15:44, 5 October 2021 (UTC)
• Digression: Note enwp dot org is not owned by the Wikimedia Foundation. Reader beware if you make use of it. isaacl (talk) 22:32, 5 October 2021 (UTC)
  • Indeed. If you want to generate short URL's use Special:UrlShortener, there's no need for external services. 192.76.8.82 (talk) 01:11, 6 October 2021 (UTC)

Picturepedia

Reading long text sometimes may be annoying, especially when the subject is not of our main interest. But the text may become interesting if accompanied with images... and even better if it is a slideshow with short text. I personally like looking at articles via the pictures and I believe it may be an interesting idea if there is a way to present an article as a slideshow. It will be more appealing for people with less interest to go into the details. I suggest to create an image mode for the articles. The pictures in the article can have a longer alternative text in a way that if viewed via the Image viewer they tell a story. I made a try here to see what this can look like.There is nothing new. We have already the possibility to create such stories but it may require slight adaptation of the ImageViewer in order to display the text better - for example show the text near the image and the caption below. It may need also an alternative text for the images that is not visible in the article but only visible in the ImageViewer in order to avoid overcharging the text in the article. Finally, a "View this article as slideshow" button may be also nice.--Ikonact (talk) 18:28, 7 October 2021 (UTC)

The only issue I can see with this is articles that have little or no images on them. And even then the pictures don't always talk about everything in the article. ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 18:39, 7 October 2021 (UTC)

If there are articles with little or no images they will not have a slideshow. Not all of the articles need to have it. On the other hand, presenting with pictures gives the freedom to select images less related to the article. It is enough to have a nice picture that tells a story. And that's correct that pictures don't always talk about everything in the article. But that's the point - the slideshow will be a short version, a summary presented in pictures. --Ikonact (talk) 19:32, 7 October 2021 (UTC)

@UOzurumba (WMF), this discussion reminds me of the 'Stories' project. What do you think? Whatamidoing (WMF) (talk) 19:08, 8 October 2021 (UTC)

This sounds like something that should be more a Simple English Wikipedia project, less on en.wiki. Not that this is a bad idea, just maybe beyond our scope. --Masem (t) 19:17, 8 October 2021 (UTC)

I agree with Masem. This would work great on Simple, but here? Here text is the most efficient way of communicating messages to our readers. 🐔 Chicdat  ^{Bawk to me!} 10:07, 11 October 2021 (UTC)

Expand "what links here" for Draftspace articles to include "what links to" the topic if it were in mainspace

For example, I started Draft:Simpson's Rest and want to see relevant links at "what links here". Of course nothing, or hardly anything, links to "Draft:Simpson's Rest"; what I want to see is what links to "Simpson's Rest" (currently a redlink). Could "What links here" be modified to automatically provide those relevant results, for articles in Draftspace? This would be useful for article developers and AFC reviewers and other reviewers. --Doncram (talk) 17:07, 9 October 2021 (UTC)

You could simply go to the mainspace redlink and look at its "what links here" - Special:WhatLinksHere/Simpson's Rest. I just checked and it does work. Roger (Dodger67) (talk) 17:15, 9 October 2021 (UTC)

There is no "mainspace redlink" within a Draft article that can be clicked upon, unless one deliberately adds it as a temporary thing, just to facilitate performing that "what links here" search (by just two clicks). And it is confusing for AFC reviewers and others when they see you have put such a temporary thing into the article. Again, a one-click service would be helpful for draft article developers and reviewers. Note, a somewhat related recent change was the introduction of messaging to persons creating a new article, if there already exists a Draft article on the topic. E.g., clicking on redlink Simpson's Rest right now yields message "There is a draft for this article at Draft:Simpson's Rest." --Doncram (talk) 17:34, 9 October 2021 (UTC)

This is just one more thing that is wrong with the concept of draft space. The whole idea of a Wiki is that articles are edited in main space where people can see them, and deleted if it is found after proper examination (which seems to happen less and less at WP:AFD) that their subject fails policy or guidelines. Why can't we just acknowledge that the experiment of using draft space has failed, rather than add more and more bells and whistles to it? The only answer that I can see is that people are addicted to the fallacious concept that sunk costs should be taken into account. Phil Bridger (talk) 19:37, 9 October 2021 (UTC)

@Phil Bridger: I strongly disagree with your view of draftspace. I have over a thousand drafts there now, and at this point have completed and moved over a thousand previous drafts to mainspace. I use the space as I believe it is best used, as a place to gather sources while preparing an article (see, e.g., Draft:William Lawrence Foster). BD2412 T 20:51, 10 October 2021 (UTC)

Exactly. Sunk costs. You are probably the the only editor who makes such extensive use of draft space, rather than, as we are told it is not, treating it as as a backdoor route to deletion by non-admins, and you could do exactly the same in user space, as has happened ever since Wikipedia started. If you want to give an example of how draft space is any better then show me an article that shouldn't be in main space but where collaboration has happened. Phil Bridger (talk) 21:13, 10 October 2021 (UTC)

Would adding [[Special:Whatlinkshere/{{PAGENAME}}]] to somewhere in {{AfC submission}} solve/work around your problem? It automagically removes the "draft" and shows links to the same name in mainspace. —Kusma (talk) 22:23, 9 October 2021 (UTC)

{{AfC submission/tools}} already says [[Special:WhatLinksHere/{{SUBPAGENAME}}|⋈]]. It's linked on "⋈" after clicking "show" at "Reviewer tools" at Draft:Simpson's Rest. Few draft authors will problably find that. PrimeHunter (talk) 22:49, 9 October 2021 (UTC)

Unicode Character 'BOWTIE' (U+22C8). What a curious selection. --Redrose64 🌹 (talk) 08:07, 10 October 2021 (UTC)

Perhaps we could change it to "links" or something else that I wouldn't overlook and that would make sense also for screen readers? —Kusma (talk) 08:12, 10 October 2021 (UTC)