Jump to content

Wikipedia:Village pump (idea lab)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Maile66 (talk | contribs) at 00:25, 30 October 2021 (→‎Spoken wikipedia on the main page: TFA would be an excellent place to start). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
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:

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, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60

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

I think I'd want to know exactly how upload_by_url works. Jo-Jo Eumerus (talk) 07:35, 4 October 2021 (UTC)[reply]
@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)[reply]
@Xaosflux: What do you mean? — Alexis Jazz (talk or ping me) 11:11, 4 October 2021 (UTC)[reply]
@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)[reply]
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)[reply]
  • 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)[reply]
    @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)[reply]
    @Xaosflux: Here's an example I just ran into: Wikipedia:Files for discussion/2021 October 11#File:SKY-Q-Logo.png. It happens. — Alexis Jazz (talk or ping me) 13:48, 12 October 2021 (UTC)[reply]
    @Alexis Jazz: what am I missing there? Wikipedia:Files_for_discussion/2021_October_11#File:SKY-Q-Logo.png doesn't seem to say anything about needing to rescue a file from commons, it is about a file that is already here. — xaosflux Talk 13:55, 12 October 2021 (UTC)[reply]
    @Xaosflux: The nominator says that File:SKY-Q-Logo.png should be deleted as File:Sky Q - Logo 2020.svg is a "free alternative" when in fact it's clearly eligible for copyright protection in the UK. Would be handy if we had a tool to import the thing here, no? — Alexis Jazz (talk or ping me) 14:22, 12 October 2021 (UTC)[reply]
    @Alexis Jazz: sorry if I'm completely misunderstanding you - but File:SKY-Q-Logo.png appears to already be a local file, commons:File:SKY-Q-Logo.png does not seem to exist. Can you further explain that if we had a commons-->enwiki import tool, what is the file that is on commons that would apply in this scenario? It doesn't appear that anyone on commonswiki is discussing deleting the second file you mentioned? — xaosflux Talk 14:28, 12 October 2021 (UTC)[reply]
    @Xaosflux: Exactly, the second file could be copied to enwiki. It easily exceeds c:COM:TOO UK, just because nobody has tagged it yet doesn't mean it acceptable to use. It's not correctly licensed so we should create a local copy with the correct licensing. — Alexis Jazz (talk or ping me) 06:47, 13 October 2021 (UTC)[reply]
    Ah OK, so it this specific example it isn't something anyone has do worry about (yet) - but yes it seems fine, but getting over more then just the file contents is still important - think this sounds more like using filexporter in reverse than just using uploadbyurl, else everything else is going to get lost or still have to be dealt with by hand. — xaosflux Talk 09:58, 13 October 2021 (UTC)[reply]
    @Xaosflux: NOW it is something to worry about! I think in most cases it would be no big loss to miss out on metadata. Keeping metadata (like uploader username) is more important for own work. For logos or fair use this is less of an issue. And even for own work (which may happen in case of FoP issues), there are still "own work" files being exported from enwiki to Commons using tools other than FileImporter, do we really have to be holier than the pope? — Alexis Jazz (talk or ping me) 12:43, 21 October 2021 (UTC)[reply]
    I'm not saying it is a hard blocker, just that if we bother to write a tool for this, might as well make it as useful as possible. — xaosflux Talk 13:20, 21 October 2021 (UTC)[reply]
    @Xaosflux: I get your point, but I'm not sure FileImporter could be adapted for this. FileImporter can't be accessed with the API afaik so everything becomes more complicated. — Alexis Jazz (talk or ping me) 16:59, 21 October 2021 (UTC)[reply]
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)[reply]

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

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 WolfTalkBlaze Wolf#6545 18:39, 7 October 2021 (UTC)[reply]
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)[reply]
@UOzurumba (WMF), this discussion reminds me of the 'Stories' project. What do you think? Whatamidoing (WMF) (talk) 19:08, 8 October 2021 (UTC)[reply]
@Whatamidoing Yes, Ikonact's thoughts about visual stories is in line with the Wikistories pilot project. This is a validation if you ask me. So, @Ikonact and anyone interested in this, please follow up on the project here and then you can also look at the early design exploration presentation. Thanks Whatamidoing, for pinging me about this. :)
UOzurumba (WMF) (talk) 10:26, 13 October 2021 (UTC)[reply]
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)[reply]
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)[reply]
Well, I disagree that this is for Simple English Wikipedia for two reasons. First, the idea is not to make a simple text but to present an article differently. This can be complex text too but with some visual support. It may allow readers that are not familiar with details to learn about a subject without digging in a bunch of paragraphs (one can refer to the subject "Some option to make articles easier to read" above). Second, this can be applicable to other Wikipedias, not only for English. --Ikonact (talk) 09:17, 12 October 2021 (UTC)[reply]
I'm not sure that this would necessarily be at any Wikipedia. It might be a separate project entirely. mw:Wikistories has more information (but doesn't specify whether it would be part of Wikipedia or a separate project). Whatamidoing (WMF) (talk) 02:22, 20 October 2021 (UTC)[reply]
BTW, if you click through to mw: Wikistories and put the page on your watchlist, you'll get a notification whenever anyone starts a new discussion on its talk page. I encourage interested editors to watch that page. Whatamidoing (WMF) (talk) 02:23, 20 October 2021 (UTC)[reply]
I love this idea!
I actually think this could work on all Wikipedias, Simple and EN. Captions can be both simple and complex English, so we shouldn't just limit it to Simple.
How we could implement this is maybe creating a system for different viewing modes of Wikipedia articles. For example, users could choose from the standard text, your slideshow version, or maybe others such as a "fact sheet" (list of bullet points), or anything else the community could come up with! Users could select the mode at the top of the article. Lectrician1 (talk) 14:28, 12 October 2021 (UTC)[reply]
That argument violates the WP:ILIKEIT policy. 🐔 Chicdat  Bawk to me! 10:40, 13 October 2021 (UTC)[reply]
Perhaps I'm just being dense and this is a joke but WP:ILIKEIT is not a policy (see the top of the page) and applies to deletion discussions, not discussions in general or VPI. 15 (talk) 23:18, 13 October 2021 (UTC)[reply]
You're right. 🐔 Chicdat  Bawk to me! 10:18, 14 October 2021 (UTC)[reply]

Create tracking template for Wikidata items in text

After reaching the conclusion that users do not want visible links for Wikidata items on Wikipedia articles in the Create template/link for things that have Wikidata items, but not articles discussion, I want to propose another solution.

I still think it's extremely important that Wikidata items that are tracked in articles in some way. There are so many items in Wikidata that do not have articles but describe something that is present in an article. Establishing a "link" between them is useful for tracking and notability purposes.

So instead of creating a visible link using something like Template:Interlanguage link, my proposed solution is to make a template called "Associated wikidata" that shows normal text for all users and the associated item ID is only present in the source code. This is better than the current suggestion of putting a comment like <!--Q108291790--> because it is actually computer readable, therefore creating an actual association.

Example:

{{Associated wikidata|item=Q108291790|text=Changer : Dear Eris}} will just show "Changer : Dear Eris" on the section that mentions it with no link.

Thoughts? Lectrician1 (talk) 14:11, 12 October 2021 (UTC)[reply]

Not really. You explain that you think it is important to create digital links, but not why it is important to do so. I see no benefit to even hidden “digital” links Blueboar (talk) 14:45, 12 October 2021 (UTC)[reply]
@Blueboar I explain why above: "Establishing a "link" between them is useful for tracking and notability purposes."
To add, Wikidata in the future could establish a native tool that shows on the item page where an item is linked on Wikis.
Creating a tracking category for the template would be nice for statistics as well. We could see where items are linked across wikis and on what types of articles. Lectrician1 (talk) 15:31, 12 October 2021 (UTC)[reply]
Okay, so it might be useful for Wikidata. How is it useful for enwiki? Making our code more complicated to edit for the benefit of Wikidata seems like a poor tradeoff. Fram (talk) 15:50, 12 October 2021 (UTC)[reply]
@Fram Does it matter if it's "one-sided"? We're all part of one movement trying to document information. More linked data means better data for all of us in the end.
It could be useful to enwiki editors, say they found it when editing and they could contribute or use data from it. And it could be more useful if an actual link was displayed for at least logged-in users. But, EN Wikipedians seem to hate Wikidata and stay away from it at all costs, which in the end is hindering Wikidata from actually being of use any use on our wiki (which it can be of significant use if people were inspired enough to create tools for it), and leaving enwiki in the dust compared to, say the Catalan.
I don't see this simple template as an obstruction to editing. My template is of little complication compared to something like an infobox and will barely add any clutter. It's 2 simple parameters. Lectrician1 (talk) 17:34, 12 October 2021 (UTC)[reply]
As I disagree with most of your premises (e.g. "More linked data means better data for all of us in the end."), I disagree with your conclusions as well. I don't think it is advisable to use anything from a website that brings us the article "lost to fury" for nearly a day now, when the enwiki article linked to it has received more than 1 million views over the last 20 days. If even the most high profile pages can't be protected from such extremely obvious vandalism, then we have no business at all linking to it. If Wikidata wants to be useful, they need to improve dramatically (in vandalism protection, in sourcing, and so on). As they haven't done this in the past, what, 8 years, I doubt it will happen anytime soon. For crying out loud, their entry for West Africa was called "Mexico" for two whole weeks[1]. Fram (talk) 07:59, 13 October 2021 (UTC)[reply]
Absolutely right. Peter coxhead (talk) 09:59, 13 October 2021 (UTC)[reply]
@Fram @Peter coxhead
So you're concerned that people will see the item in the source text and then proceed to vandalize it?
I think that the chances of that are extremely low. People who are likely to vandalize a Wikipedia article are very unlikely to know or research what Wikidata, figure out how to get to the item, and then proceed to know how to vandalize it. That is a lot of steps required compared to just vandalizing the Wikipedia article instead. In this instance, Wikipedia is much more likely to get vandalized then Wikidata.
Therefore, I think the potential benefits of adding the template "link" outweigh the potential downside that the Wikidata item is vandalized.
Nothing on Wikipedia is impacted by the presence of this template. It is not used as a source or link. It's just a template as simple as something like Template:Use mdy dates. Lectrician1 (talk) 19:24, 13 October 2021 (UTC)[reply]
No, I think that you will be leading people to a site which is unreliable, poorly patrolled, and of little use. I see no benefit to enwiki at all. Fram (talk) 07:01, 14 October 2021 (UTC)[reply]
Wikidata is crowd-sourced just as Wikipedia is, and we don't allow the use of Wikipedia as a source because it is crowd-sourced. - Donald Albury 17:17, 12 October 2021 (UTC)[reply]
@Malcolmxl5 @Donald Albury It's NOT a link. Nor is it a source. It is simply a "correlation" stored in the source text for "existence" and tracking usage. Please see the example.
Malcomxl5, I'm not sure if you recognize the usage case here. Lectrician1 (talk) 17:39, 12 October 2021 (UTC)[reply]
@Lectrician1: but the use of such a template appears, to me at least, and I'm sure it will to other editors, to endorse links to Wikidata, which I agree entirely with Donald Albury is not and should not be allowed as a source. Peter coxhead (talk) 10:03, 13 October 2021 (UTC)[reply]
Lectrician, if it does not actually link to WD, then there is even LESS reason to clutter up the editing page with it. Still a no for me. Blueboar (talk) 11:26, 13 October 2021 (UTC)[reply]
I'm not sure I'll be able to convince you if you find this template "cluttering" when comparing it to the other average 50+ templates, references, and links on an average article that are much more cluttering. Lectrician1 (talk) 19:42, 13 October 2021 (UTC)[reply]
Those templates either have a clear purpose (adding a reference, indicating unsourced statements) or are out of the way (use dmy dates, shortdesc). Adding a template in the middle of the text which only benefit is that Wikidata might perhaps track some usage is, yes, cluttering. Fram (talk) 07:01, 14 October 2021 (UTC)[reply]
@Peter coxhead
If there's anything that endorses Wikidata on Wikipedia it's the "Wikidata link" on the sidebar...
This template is harmless compared to that.
I also struggle to understand how you see this as a "source" and "endorsement". It's just a relationship. When we add the link to a person or organization's official website to their article, are we "endorsing it"? That is also just a relationship.
And not even the official website link compares to this template. The website link actually appears on the article whereas this template just shows the normal text...
And gosh, we are linking to another Wikimedia project site. This link is part of the Wikimedia ecosystem! Why would we reject it? And if you're concerned about quality differences, who ever said that Wikipedia articles were of any better quality than any other Wikimedia Project...
As I stated above, this is harmless and will not cause vandalism or any other concern. Lectrician1 (talk) 19:40, 13 October 2021 (UTC)[reply]
The sidebar link appears once in each article where editors can find it helpful, or just as easily ignore it. The template could appear every time there is a Wikidata item that does not have its own article, and for the tracking data to have any meaning it would presumably need to be used extensively in order to create a full picture. The interlanguage template should be (but often is not) used sparingly to supplement certain redlinks, for the benefit of other editors, unlike the intention of this template which is to enable machine reading of the source code, but in doing so it would make it almost impossible for humans to edit it. Perhaps there could be a way of tracking this type of information using tools and templates placed somewhere within Wikidata rather than here. EdwardUK (talk) 21:48, 13 October 2021 (UTC)[reply]
I agree with EdwardUK re a one-off link in the sidebar, which can be ignored. Re who ever said that Wikipedia articles were of any better quality than any other Wikimedia Project – I say that some aspects, e.g. classification and taxonomy, are much better covered in the main language wikipedias (English, French, Spanish, German, ...) than in Wikispecies or Wikidata, which is a reflection of the number of editors working on them. Active collaboration by multiple editors in wikiprojects produce better quality articles. Peter coxhead (talk) 06:22, 14 October 2021 (UTC)[reply]
Wikidata is an unstable knowledge base in which any value may change at any time. Well, so is Wikipedia, and the Commons, which we use to link to or take images from all the time, although they may change without warning. There is also general consensus to accept that Wikidata should be used extensively as our central storage for interwikilinks (this is much better than the previous bot-maintained monstrosity of changing corresponding pages on every language edition every time a page is moved on any Wikipedia). We just don't trust Wikidata's other content, because we don't trust their editing processes, which seem less robust that Wikipedia's. In an ideal world, we should have a trustworthy repository of data that can be shared by different Wikimedia projects, but Wikidata is currently far better at collecting and collating unverified data than at verifying it. I do hope that changes, but that's where we're at. —Kusma (talk) 08:07, 14 October 2021 (UTC)[reply]
This is no different from the existing (and already allowed) solution of putting the Q number as a wikitext comment, except for the fact that it adds a template whose wikitext would be literally {{{text}}}. There's no point in creating a template that does so little, and comments are computer readable, in the sense that a computer is capable of parsing the wikitext to find them. * Pppery * it has begun... 03:03, 15 October 2021 (UTC)[reply]

Random Article Feature

Moved from WP:VPR

I really like the random article feature, but it can be improved. I would love to see a way to search for random articles within certain categories.

e.g. search for a random article in science, astronomy, literature, music, etc.

I'm not sure if all articles are categorized by default, but I'm sure a select group of people including myself would help categorize articles so a feature such as this could be implemented.

Thanks. Senor hams (talk) 18:25, 13 October 2021 (UTC)[reply]

WikiFiction

I would like to propose creating a multiauthor space for creative writing: WikiFiction (or WikiNovelist).

Wikinovelists should contribute with donations to be able to participate in multiauthor books and everyone should previously register in order to contribute. This process will hopefully keep bored haters/destroyers away from busy creators -or modern serial witch burners from potential intelligent life out there.

WikiFiction could be a way to get funds for this or other wikimedia projects.

This new platform could recycle the current Wikipedia platform, with the added registration requirement, perhaps with a valid cellphone. A maximum of authors per book should be set for a given time, to avoid some books getting too crowded and the content confusing and neverending changing.

There should be authors and editors, who could review the final book for coherence. All versions should be stored until the final version is agreed. Authors and editors could go by name or nick, but all should be registered with a way to prove identity.

Any profits from any WikiFiction book should ideally be offered to non-profit charity organisations, chosen by votation of main authors, with a percentage dedicated to maintain WikiFiction.

Part of the donations for wikinovelists could be saved in a fund, which will offer free passes for those who could not contribute otherwise. So a young Leonardo da Vinci from a remote village somewhere in this planet, could still contribute to a book with perhaps unique ideas, even if her income is zero.

Creative writing or imagination in general is urgently needed to find solutions for the future we are facing. Encyclopedias and history are giving us great (or terrible) ideas from the past. Some novels (a bit as science) can be a valuable means to predict or create the future.

I will contribute with a first novel first chapter idea as a test. It is aimed to be a multiauthor book that would focus on a paradigm change related to Climate, from looking at plastic or recycling as the big problem here, to admitting we human overpopulation are the real issue on this planet. The book will revolve around that.

This creative piece of work requires the input of scientists, modern philosophers, social anthropologists... And needs to start rolling asap...

Caro — Preceding unsigned comment added by 94.252.121.207 (talk) 13:45, 16 October 2021 (UTC)[reply]

Please see WP:MULTI and my reply at Wikipedia:Village pump (proposals)#WikiFiction. --Redrose64 🌹 (talk) 14:50, 16 October 2021 (UTC)[reply]

Help on Foreign Wikipedias

There are frequently questions asked at various forums on the English Wikipedia about dealing with foreign Wikipedias, typically about block appeals. (Of course, the user may or may not be blocked. Questions about blocks from editors who are editing from their own account and are not blocked do happen. That is a detail.) They have also asked about blocks on Commons, or about problems on Meta. They are always told, of course, that each Wikipedia is a separate project. However, what I am suggesting is a global Help page giving information about seeking various sorts of help on other Wikipedias, and on Commons, and on Meta, and on Wiktionary, and so on. The page, possibly with subpages, should be one that we invite cross-wiki editors to maintain as a service to other cross-wiki editors. It should have a disclaimer that the information is the best that we have here but may not be accurate, and to go to the page on the foreign Wikipedia and ask further, and please come back and update the help here if it needs updating. Robert McClenon (talk) 18:18, 16 October 2021 (UTC)[reply]

Why would this be better than just telling people to go ask on the appropriate project? (Genuine question!) Calliopejen1 (talk) 19:44, 20 October 2021 (UTC)[reply]
User:Calliopejen1 - It is not always obvious on a given project where or how to ask for help. I recently encountered a page on Meta that I thought was a very bad attempt at humor that had no real purpose, and so should be deleted, but it was not obvious on Meta either how to ask for help or how to nominate a page for deletion. I did answer my own question, and the page was deleted. A less experienced user might have been baffled. How to look for help is different on different projects, and the differences can be confusing to a user, especially to a user who lacks experience with online systems. Some of the questions that we see about foreign Wikipedias, or about other projects (e.g., Commons, Wiktionary), seem to indicate that the user either has tried and failed to find help, or is exasperated and has stopped looking on the other system. Robert McClenon (talk) 17:00, 23 October 2021 (UTC)[reply]
I don't see anything wrong with maintaining a page that tells an editor how to do that. That would give people something to link to if editors ask here, which many people seem to do in the mistaken belief that the English Wikipedia has some sort of primacy over the other languages. Phil Bridger (talk) 19:57, 20 October 2021 (UTC)[reply]
An example of where this could be useful can be seen here. I see a few of these every month, and it would be good to be able to direct the editors to the correct place to ask for help on the other project. Phil Bridger (talk) 09:27, 24 October 2021 (UTC)[reply]

Backups for Bot Operators

This is based on a report at WP:ANI. Bots that stop working for various reasons are a common problem. Bot operators who stop editing are a common situation, because editing Wikipedia is voluntary (and often stressful). Some tasks performed by bots are of a relatively high priority. Something would be done in the ideal world that we do not live in. It occurs to me that three of the subtasks are to identify the priorities of bot tasks, and to identify possible backup bot operators (based on programming language and other matters), and then to identify high-priority bots that do not have backup bot operators. Robert McClenon (talk) 18:18, 16 October 2021 (UTC)[reply]

One thing I think might be prudent is to (require/encourage/mention) having bots' userpages link to the codebase that they're running; usually, when software I've written stops working, it's because of some minor bug (or API deprecation, etc) that isn't particularly hard to fix. If everyone were able to take a look at the code (and debug it on their own machine, etc) it'd be a much simpler problem for absent operators to accept a pull request than to personally rewrite code which in all likelihood they haven't looked at in years. jp×g 01:17, 19 October 2021 (UTC)[reply]
Or require a simple startup procedure to be submitted as part of the BRFA. Enterprisey (talk!) 02:47, 19 October 2021 (UTC)[reply]
The problem is that we have some high-priority bots, such as SineBot, that are closed-source. Whether we should be approving BFRAs for closed-source bots is another matter. --Ahecht (TALK
PAGE) 20:58, 21 October 2021 (UTC)[reply]

Preparation for IP masking

I read few weeks ago here and on meta wiki that IPs are going to be masked. Then some editors proposed that IP editing be banned but many opposed it. So banning will be controversial. But, are there some other ideas which can be implemented to counter vandalism? I am relatively new at wikipedia so I don't know what will that be exactly. I propose that now a userscript be made which mimics IP masking. Interested vandal fighters can add in there js file so as to get a feel on how it will look after update, so that community will get better idea about it and vandal fighters will be more prepared for actual masking. I have no idea how to make such script but just thought came in mind so shared it. -- Parnaval (talk) 11:27, 22 October 2021 (UTC)[reply]

@Parnaval: while an interesting preparation idea, I would think one of the bigger issues here is that it's not the regular vandal fighting workflow that is impaired by masking but the socking and range-hunting. A lot of that is done by cross-editor efforts (rather than one person handling everything themselves), so you'd have to make sure everyone was on it. Otherwise you'd be getting "can you block 5%£u343ur/64" and others would be "who is 5%£u343ur/64 - I'm seeing 4.343.121.12/64" etc Nosebagbear (talk) 16:06, 22 October 2021 (UTC)[reply]
@Nosebagbear: Then just aggressively add this to every editor who is rollbacker/admin/checkuser. And post a message to talkpage of everyone in these usergroups. And if this is not feasible, there should be something else which enwiki should do before masking goes live. Some sort of brainstorming needs to be done like one going on for RfA review. -- Parnaval (talk) 06:45, 23 October 2021 (UTC)[reply]
Parnaval, those of us who have been around a long time and have been instrumental in getting important policies brought into line with today's reality know that change on Wikipedia happens slowly. One medium sized Wikipedia has recently banned IP editing with resounding success, while the WMF is currently supporting a 6-month trial on another. That said, consensus can change, and sometimes dramatically so, hence banning IP editing might not be quite so controversial after all. These issues are discussed in depth on Meta. Kudpung กุดผึ้ง (talk) 05:59, 24 October 2021 (UTC)[reply]
Oh. . . OK. I was just suggesting that enwp community should do some trials themselves, so as to show some results to WMF on what worked here. -- Parnaval (talk) 12:49, 24 October 2021 (UTC)[reply]
Why are you even doing IP masking. I ask: why? I see no benefits and many disadvantages of hiding IP numbers from all but the privileged few. 🐔 Chicdat  Bawk to me! 12:11, 25 October 2021 (UTC)[reply]
@Chicdat: -- Well, we aren't doing it. The WMF is. We don't want it, but alas -- Rockstone[Send me a message!] 00:22, 28 October 2021 (UTC)[reply]

Roud Folk Song Index and Child Ballads nr in the WP:LEAD of articles about songs

It's common [2] that a WP-article on a folk song (?) will mention something called a Roud Folk Song Index number in the WP:LEAD, sometimes also a Child Ballads number. See also List of folk songs by Roud number. Sometimes in the first sentence:

Sometimes a little further down:

IMO, this looks like strange WP-writing, like having "The imdb number is tt0068646" in the lead of The Godfather, and not "a summary of [the article's] most important contents". I'm guessing Roud and Child are more academic, though. A previous discussion Wikipedia:Village_pump_(policy)/Archive_156#Stop_putting_Roud_index_numbers_in_the_lead_of_folk_songs mentioned external links, infobox and wikidata (it can be added there apparently [3]) as alternatives to lead, but nothing really happened afaik.

So, is there some sort of consensus that having these in the lead should be dealt with somehow (how?), or is it ok to have them there? At the time of the previous discussion I edited Cotton-Eyed Joe like so [4], noone has changed it. Gråbergs Gråa Sång (talk) 20:08, 22 October 2021 (UTC)[reply]

I know they're an important identifier for those songs. It would be useful to have some standard method of incorporating them in those articles, so readers and researchers can rely on where to find them. Maybe as fields added to Template:Infobox song? Ah, I see that was generally the consensus in that discussion (minus the lead/lede/introduction tangent). But that would also imply an expectation that all of those types of articles include an infobox. It could be a standard section after the lead? Schazjmd (talk) 20:45, 22 October 2021 (UTC)[reply]
How about a "Folk Song Index" section above See also/References? Gråbergs Gråa Sång (talk) 21:11, 22 October 2021 (UTC)[reply]
I like that idea! (Properly sentence-cased, of course) Schazjmd (talk) 21:11, 22 October 2021 (UTC)[reply]
But of course. Gråbergs Gråa Sång (talk) 21:37, 22 October 2021 (UTC)[reply]
Roud numbers at least (not sure about the Childs nos.) are akin to the opus numbers (or other recognized cataloging numbers like BMV or Köchel numbers) we see in the lede -- usually the introductory phrase -- of most classical music articles, e.g. The Symphony No. 6 in B minor, Op. 74...; or The Requiem in D minor, K. 626... or Fugue in G minor, BWV 578.... They have recognized academic status as identifiers to unambiguously identify a particular work. They ought to be in the lede.
This is nothing like IMDB numbers, which are just the database numbers used by a particular vendor to navigate its database, and whose stability Wikipedia takes advantage of for linking. Roud numbers, like opus, BMV and Köchel numbers, are stable, academically recognized and not tied to a vendor who might arbitrarily change them in the future (as Turner Classic Movies did some time ago, breaking Wikipedia templating in the process). TJRC (talk) 23:44, 22 October 2021 (UTC)[reply]
Interesting. Opus numbers has been around longer though, and Bach-Werke-Verzeichnis/Köchel catalogue is more limited in scope, like opus numbers for one musician at a time. Roud seems more like a limited ISBN or ASIN, catching them all, or trying to. Gråbergs Gråa Sång (talk) 08:02, 23 October 2021 (UTC)[reply]
Identifying Roud and similar catalogue numbers is important, but the way they are presented in many WP articles is awkward and not encyclopedic. A while back, I remember several articles that were little more than "'Ballad X'" is Roud 12345" followed by lyrics that were italicized and formatted with a series of <br /> and : (rather than something like {{Poemquote}}), with a link to the Roud index as the sole ref. It reminded me of the mass creations of superstubs in the early days that seemed to ignore WP:NSONGS "Notability aside, a standalone article is appropriate only when there is enough material to warrant a reasonably detailed article; articles unlikely ever to grow beyond stubs should be merged to articles about an artist or album."
The catalogue number should be worked in to articles with some explanation or context; a reader who is only interested in one song may not know what a Roud number is or why it is significant. Also, Roud and other ID numbers can be added to Template:Infobox musical composition using the |catalogue= parameter. This template also has several other useful fields more applicable to traditional songs than Template:Infobox song, which is more geared towards commericial recordings. An example follows.
—Ojorojo (talk) 14:43, 23 October 2021 (UTC)[reply]
Extended content
"Tre pepparkaksgubbar"
Swedish folk song by Alice Tegnér
Sheet music cover (1920)
English"Three Gingerbread Men"
Other name"Vi komma, vi komma från Pepparkakeland"
CatalogueRoud 99
Genre
Written1900–1913: Sweden
Textby Astrid Forsell-Gullstrand
LanguageSwedish
Published1913: Sweden
Publisher
  • Bärina Hallonhätta och andra visor
  • Sjung med oss, Mamma! Vol. 6
RecordedGirls' choir, Solna, Sweden (1931)
Audio sample
Nils Lund version (1950)
{{Infobox musical composition
| name                = 
| type                = 
| composer            = 
| image               = 
| image_size          = 
| alt                 = 
| border              = 
| caption             = 
| translation         = 
| native_name         = 
| native_name_lang    = 
| other_name          = 
| catalogue           = 
| genre               = 
| written             = 
| text                = 
| language            = 
| composed            = 
| published           = 
| publisher           = 
| first_recording     = 
| misc                = 
}}

Subset parameters

  • |name= title of the composition, using the common name
  • |type= appears with the composer above an image, such as Folk song
  • |composer= composer of the piece
  • |image= a suitable free image
  • |image_size=
  • |border= set to yes for a border
  • |alt= an alternative description of the image for readers who don't see it
  • |caption= description of the image
  • |translation= title in English, if the common name is in different language
  • |native_name= native title, if the common name is English
  • |native_name_lang= language of the native title/common title not in English
  • |other_name= other name(s) the work may be known by
  • |catalogue= list the catalogue with a link, such as Roud 99
  • |genre= genre of the piece, such as Christmas music
  • |written= more general if "composed" can't be said or is not known
  • |text= text source, such as a poem or "by A. Smith"
  • |language= language of the text
  • |composed= time and location of composition if known
  • |published= date(s) and location(s) of publishing
  • |publisher= company (or companies) which published the piece
  • |first_recording= artist and date of the first recording
  • |misc= for the use of {{Audio sample}}
One of the problems with folk songs and ballads is that they often exist in many variant versions, no one of which is definitive. Even the titles may vary; or, conversely, two or more songs may have identical titles, but entirely different content. The purpose and great strength of the Child and Roud lists is that they bring together all variants under a single authoritative identifier, and perhaps save the student a lot of wasted time and effort in chasing "ghosts". So to my mind this is important information that should be included both in the lead, and in the infobox if there is one. On the other hand, it's a technical reference which won't immediately mean much to many general readers, so shouldn't be given undue prominence, or made the basis of the definition. Putting the reference in brackets after the title (e.g. Whiskey in the Jar), or briefly stating it at the end of either the lead paragraph or lead section (e.g. Ring a Ring o' Roses, Holmfirth Anthem), are all entirely acceptable ways of achieving what we want – getting core information out there, succinctly, without overcomplicating the issue. But making it the sole content of the definition (e.g. Robin Hood and the Bishop of Hereford, admittedly a stub) is bad practice, and to be deprecated. GrindtXX (talk) 13:13, 24 October 2021 (UTC)[reply]
It seems to me that Roud/Child nr is not "core information," that's stuff like year/country of origin, composer and what Donald Trump tweeted about it. If "Whiskey in the Jar" was a chemical element like lead, Roud is not atomic number, it's electron configuration. However, I think it would be helpful that included Roud numbers has a cite with link included, like.[1] Not necessary if this is under External links, of course. I'm not pushing infoboxes beacause I don't want to "force" an article to have an infobox just to have a place to put the Roud nr. Gråbergs Gråa Sång (talk) 08:41, 25 October 2021 (UTC)[reply]

References

  1. ^ "Whiskey in the Jar, Roud No 533". Roud Folk Song Index. Retrieved 25 October 2021.

Refining the rollback right

At present, the rollback user right is predominantly given by administrators to trusted editors (typically counter vandalism patrollers) and allows access to more complex and powerful tools, the most notable tools being rollback links (the namesake of the right), Huggle, and some features in RedWarn.

As time has progressed, the rollback feature and right has been used for more than just rollback links (i.e. a link that's clicked and immediately reverts an edit without summary) and as such the current rollback policy is outdated, confusing and conflicts with what many people use it for (i.e. through Huggle or other tools with edit summaries). Because of the lack of clarity, many times WP:ROLLBACKUSE has been brought up in discussions, even when it's usually not applicable to use of rollback with edit summaries (i.e. by using the rollback link).

We should clarify this - as such I think renaming the right on the English Wikipedia to "Tool Confirmed" or similar (thinking along the lines of auto-confirmed, extended-confirmed, tool confirmed, but I welcome proposals for any better name) that clearly describes what the role does, why the person has it and how they can be held accountable for their use.

The rollback link policy should then be merged into the wider reversion policy as no matter where, tool use without edit summaries should only be appropriate in certain situations and autoconfirmed users can replicate the use of rollback links by using a tool such as Twinkle or RedWarn. This means there won't be fragmentation between what essentially in both cases is just reverting an edit.

A sample of what my idea of a summary would look like:
Tool confirmed editors are editors approved by an administrator to have access to more powerful semi-automated tools. A tool confirmed user has access to features in tools such as X, Y and Z, also access to rollback links.

This could also supersede the AutoWikiBrowser request page, if technically possible.

We should also consider creating a tag named something along the lines of "Tool edit" that's required for all automated tools, userscripts etc on the English Wikipedia where appropriate and possible to increase accountability and other benefits such as analytics.

What do people think? ✨ Ed talk! ✨ 23:49, 24 October 2021 (UTC)[reply]

It makes sense to me. I requested Rollback because I'd heard intriguing stuff about Huggle, then had Rollback removed when I discovered that I didn't like using Huggle. I couldn't see any other use for having Rollback, because Twinkle provides rollback/vandalism links in both article history view and diff view, and enables rollback of multiple edits (sequential by a single editor) in one click. So the Rollback permission isn't really associated to rollback functionality. Schazjmd (talk) 00:07, 25 October 2021 (UTC)[reply]
I do not think of the rollback permission as mainly functional or technical—giving access to tools—rather as a matter of trust, in effect a licence to revert vandalism without an edit summary. IMO it doesn’t really matter how the revert is done, be it with a helper script, the rollback button, or simply null-editing an old version of the page (which last any user can do).—Odysseus1479 01:45, 25 October 2021 (UTC)[reply]
What does the rollback right grant, other than the "[rollback]" link? --Redrose64 🌹 (talk) 07:01, 25 October 2021 (UTC)[reply]
Permission to use Huggle, and nothing else. 🐔 Chicdat  Bawk to me! 10:22, 25 October 2021 (UTC)[reply]
That's incorrect. In fact the rollback right is required by quite a few tools for both technical and other reasons. "Tool confirmed" could also extend to providing trusted users with more powerful features and merge already complex permission systems together. ✨ Ed talk! ✨ 17:47, 25 October 2021 (UTC)[reply]
  • Literally the only thing that membership in the rollbackers group does is confer access to the rollback permission. The rollback permission allows an user to request a server-side reversion. None of these other scripts or clients are official and are subject to change on the whims of their maintainers, or in some cases by any user that wants to fork or recompile them. — xaosflux Talk 17:56, 25 October 2021 (UTC)[reply]
    Yes, that is technically what it does, but what I'm proposing is an expansion and restructuring of this policy, especially how a lot of people only apply for rollback for access to tools such as Huggle. ✨ Ed talk! ✨ 00:40, 28 October 2021 (UTC)[reply]

Mod Rank

What if there was a rank called Moderator? There would be a moderately protected page, meaning it can only be edited by moderators and above. It would give you more user rights then somebody extended confirmed, but less than somebody who's admin. Pikiwedia98461 (talk) 20:06, 26 October 2021 (UTC)[reply]

I don't think that's a good idea. The point of page protection is to stop disruption, not to privilege one class of editors over another. Vexations (talk) 20:52, 26 October 2021 (UTC)[reply]
@Pikiwedia98461: I don't see any need for it, do you have anywhere in mind where it would be useful? Looking at Special:ProtectedPages shows that basically every fully protected page in the article space are redirects that might need editing once a decade? Filtering by a minimum size of 700 bytes to remove all the redirects (because the "hide redirects" option doesn't hide soft redirects) shows that the only actual page in article space that is permanently fully protected is the main page [5]. 163.1.15.238 (talk) 09:41, 27 October 2021 (UTC)[reply]

Yeah, thinking back on that, it was a dumb idea. Pikiwedia98461 (talk) 16:59, 27 October 2021 (UTC)[reply]

Spoken wikipedia on the main page

This is probably more likely to apply to Today's featured article, Today's featured list, Today's featured picture, and possibly Did you know than it is to apply to In the news and On this day, but I think there should be a way for people to volunteer to add a narration to the blurbs that appear on the main page. This probably wouldn't work for ITN and OTD, because those are dynamically updated lists, but it might work for DYK, because the entire list is updated at the same time, and it could really work for TFA, TFP, and TFL, which have thousand-word blurbs. Maybe it's just the icon, instead of the whole playback box, but I think there should be a way to add spoken tracks to the main page. They'd have to be reviewed, of course, but I think it could be done. theleekycauldron (talk • contribs) (they/them) 01:44, 29 October 2021 (UTC)[reply]

Is a spoken-word reading of material which, like a mayfly, lives only one day (or even less) really a good investment of editor time and effort? And think of the pronunciation disputes! EEng 18:31, 29 October 2021 (UTC)[reply]
For sure. I don't think it'd be a requirement for every appearance, but if someone wants to make a recording, there should be a way to display it—and we have MOS:VAR for pronunciation disputes. The main page is seen by millions of people every day—it does seem worth the investment if someone wants to make it. theleekycauldron (talk • contribs) (they/them) 18:32, 29 October 2021 (UTC)[reply]
MOS:VAR for pronunciation disputes – Entire vistas of deadline-driven main page battles to the death open before us! You'll be a bust in the Hall of Fame! [6] EEng 19:19, 29 October 2021 (UTC)[reply]
Where will you find readers who can pronounce all those foreign names? —Kusma (talk) 18:44, 29 October 2021 (UTC)[reply]
The IPA can help there, no? If not, it'll probably be weaker on that side, but again, we don't need to have one for every blurb. There should be the option, though. theleekycauldron (talk • contribs) (they/them) 18:46, 29 October 2021 (UTC)[reply]
Personally I find IPA an eh-NIG-muh (or eh-nig-MUH if you're over 35 or went to private school) [7]. EEng 19:23, 29 October 2021 (UTC)[reply]
I have a PhD in Linguistics and don't speak or read IPA. - Donald Albury 21:32, 29 October 2021 (UTC)[reply]
I speak fluent IPA … if I drink enough of them. Blueboar (talk) 22:21, 29 October 2021 (UTC)[reply]

@Theleekycauldron: it's a good idea, if the main page projects start with a few to test the waters, and see how it goes. It doesn't have to be an everyday thing, but selected by the individual projects. Let them decide on some trial runs. — Maile (talk) 23:52, 29 October 2021 (UTC)[reply]

Maybe we start with TFA, then—see how it goes. I'll ping some of the coordinators over there. theleekycauldron (talk • contribs) (they/them) 23:55, 29 October 2021 (UTC)[reply]
TFA would be an excellent place to start. They plan well in advance, and are probably the best project to determine how workable this idea is. — Maile (talk) 00:25, 30 October 2021 (UTC)[reply]

Truth seeking team

There's a lot of cloudy information in the news that can make its way onto Wikipedia. Perhaps someone is pronounced dead in absentia on CNN, but people in the real world see the man walking around and get clear tape and pictures of him. Maybe there are little white lies, unverified claims, and other such commodities on a page. Enter the "Truth Team."

Much like the Typo Team (who seek to find Typos and correct them), the Truth Team looks to find lies and false info in Wikipedia pages and correct them or even remove them. For instance, someone may say that "John Doe was assassinated at 3:30 AM" but in reality, John Doe was assassinated at 4:30 AM, as found by eyewitness testimony. If the exact time can't be found, say at "approximately 3:30 AM." Stuff like that.

It would clear up a lot of false evidence, unite Wikipedia users to find the truth and to make Wikipedia a better source of information in general. xdude (talk) 16:54, 29 October 2021 (UTC)[reply]

Listen, Xdude gamer, I made a little joke above, but I want you to know that I (and everyone else) recognize that you're trying to improve things. But if you read the links above you'll see that actually, trying to fix articles by direct evidence isn't a good idea. EEng 22:02, 29 October 2021 (UTC)[reply]

Ah, I see. Reading these articles, I realize the error. xdude (talk) 23:58, 29 October 2021 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(idea_lab)&oldid=1052581174"