This page contains discussions that have been archived from Village pump (idea lab). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
< Older discussions · Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57
When you paste text into messaging apps and some word processors, the footnote markers stop being superscripts and show up with a normal baseline, which "makes the[1] text somewhat[2] illegible[3]".
It's good for pasted passages to refer to their sources, but more often than not, the medium that the Wikipedia passage is being pasted to omits the link (e.g. text messages where hyperlinks become normal text, or printed paper where hyperlinks are useless).
Footnote markers being copied is more often a nuisance than a useful thing, so I propose that they not be copiable under regular circumstances (maybe a keyboard shortcut or a toggle could make them copiable). — Preceding unsigned comment added by 207.172.131.14 ( talk) 03:05, 2 July 2021 (UTC)
sup.reference { user-select: none; }
. However I doubt it's actually desirable: as Nosebagbear says we don't want to make it too easy for plagiarists.
the wub
"?!" 14:16, 2 July 2021 (UTC)
The Wikipedia Library has a horrendous backlog of suggested sources. So I'm curious about the idea of fundraising (via some external platform) so the wiki/editors can purchase institutional-type access to various scientific journals and databases for the Library. Access to academic publications and resources is absolutely critical to developed well-sourced content in a significant amount of subject matter that isn't covered in the news media but is covered in those publications. Additionally certain high-quality news cites are also now under paywall and if the funds can be raised, the Library could also potentially offer access to these very important sources.
I'm curious about implementing this in a couple ways:
If anyone has input on this, please do. ~Gwennie🐈⦅ 💬 📋⦆ 23:46, 4 July 2021 (UTC)
i noticed wikidata has property for relationships, is it better to show them in a nav bar template like baike https://baike.baidu.com/item/%E5%94%90%E7%BA%B3%E5%BE%B7%C2%B7%E7%89%B9%E6%9C%97%E6%99%AE?fromtitle=Donald+Trump&fromid=7895491 bi ( talk) 05:49, 30 June 2021 (UTC)
Page hits some number of hundreds of thousands of views, or hits 1 million views, add a banner for the day that "This page has hit 1 million views"? And similar increments, 2 million, 5 million, 10, 20, 50, and so on. Is that something we'd do, or could do? Hyperbolick ( talk) 09:02, 29 June 2021 (UTC)
Pending changes has been discussed recently in this RfC and this RfC. Specifically, there are a few issues I think may be worth discussion:
Thoughts appreciated to refine the above ideas and decide whether there is a problem here, before taking it to RfC. ProcrastinatingReader ( talk) 19:46, 3 July 2021 (UTC)
Should the PC user-right be removed and its permission bundled into either autoconfirmed or extendedconfirmed?makes me confused. Some vandals and many disruptive editors make it to autoconfirmed before being blocked. This would make many hours of discussion at ANI; threads with titles like "User accepting vandalism in pending changes protected articles. I would support the bar being a little higher, like 365/5000 rather than 30/500 or 4/10, though. Most purposely disruptive editors don't make it that far. 🐔 Chicdat Bawk to me! 10:30, 4 July 2021 (UTC)
The extension has no maintainer; it is ancient and technically complex. There are few people still around that are familiar with the codebase, and most devs don't want to touch it.As a software engineer, that's a big red flag. You really don't want a system as big and widely used as wikipedia to depend on something like that. The scary scenario is not that it stops working and nobody can figure out how to fix it. The scary scenario is that it breaks in some way that impacts the running of the site (perhaps a security exposure) and nobody can figure out how to disable it cleanly because there's some dependency that nobody knew existed. You really want to discover things like that during a planned phase-out, not when you're putting out a fire.
Level 1
Level 2
Level 3
its use case is "any article that would be semiprotected but has a low enough rate of edits for PCR to not get clogged by stacked edits". It's significantly less work to review a single pending edit than evaluate and then actually add-in a single edit request. Reading through that sentence above, it seemed like a no-brainer to me to merge the two protection levels and make semi-protected pages have easier review tools for edit requests (through an UI instead of a template). I imagine that if there were to be a new system for PC that essentially merges PC and semiprot, the visibility (do unregistered editors see pending changes?) mechanics would be the same as "regular" PC, which is the system currently. As for how something like this could be written, and by who, I'm not entirely sure. If a community member wants to ask for a WMF grant in exchange for building a new extension, that could work. This could be brought up at the next Community Wishlist Survey, or the m:WMDE Technical Wishes. I'm not sure if this is appropriate for a Phab task, but if all other methods are exhausted, a Phabricator feature request task could be filed as a last resort. I refer to this as a last resort, as in my experience Phab is rather slow for feature requests, especially fairly large ones (which is completely fair).
Sorry, I just realised that this is a gigantic jumble of words. I'll try to clean it up later, but I'm publishing this now to save it. 🐶 EpicPupper (he/him | talk, FAQ, contribs | please use {{ ping}} on reply) 04:40, 7 July 2021 (UTC)
As a good-faith new user, ideally I shouldn't have to learn about edit requests or any internal processes in order to contribute. I should just be bold and edit. That’s exactly what I meant, Pending Changes is much less of a barrier for new users to go through (just click edit) than edit requests, and if semi prot is replaced by PC, PC would be the replacement of our current edit requests system. Phil Bridger, I meant “editing articles directly” as in having an easier UI for new editors to edit exactly what is inside the article instead of having to fiddle around with using a template, going to the talk page, describing the changes, etc, with edit requests. 🐶 EpicPupper (he/him | talk, FAQ, contribs | please use {{ ping}} on reply) 18:21, 7 July 2021 (UTC)
flaggedrevs
extension is an unholy mess that is technically incongruous with how MediaWiki otherwise works. Forking like Git or suggested edits/'track changes' as in MS Word would be a massive improvement, and yet also a massive task to implement as you say. In the interim I stand by my comments above that the extension should be phased out of use here on enwiki.
firefly (
t ·
c ) 08:44, 8 July 2021 (UTC)
Relevant guideline (I think): Wikipedia:Disambiguation § Dictionary definitions: A short description of the common general meaning of a word can be appropriate for helping the reader determine context.
My impression is that this is generally sufficient guidance when it comes to content words, and ditto when it comes to the minority of function words that have their own articles - i, we, you, he, she, it, they, for example. With the predictable exception of single-letter "I", each of these leads either to the article about the pronoun, or to a disambiguation page, either directly or via a redirect. And if a disambiguation page, the pronoun is either treated as the primary topic and placed above the "may also refer to" introduction, or else the very first entry below it. Additionally, of course, there's always a link to the corresponding wiktionary entry via the interwiki template. So, clearly no consistency issues here.
It's quite different for the majority of function words that don't have separate articles, though - am, are, is, for example. In each case, the path relevant to the function-word usage ultimtely leads to the same place, Copula (linguistics) § English, which is good, but which is also where the consistency ends. "Am" and "are" redirect to disambiguation pages. The former puts it at the bottom of § Other uses, making it, by accident or design, the very last regular disambiguation entry on the page. The latter puts it at the very top of the page, just as in the case of the pronouns. And "is" redirects straight to the target section, which has the requisite "For other uses" hatnote link to the disambiguation page... which in turn includes a link to the target section mid-page, under § Language. Doesn't get much more inconsistent than that, does it.
My guess is that this comes about because both of these factors - not lexical, not "worthy" of an article - make it more likely that people will have widely differing ideas as to whether and how such a usage is "appropriate for helping the reader determine context", in the words of the guideline. So maybe this constitutes a special case, and should be treated as such.
On the other hand, maybe this is a non-issue - " foolish consistency [being] the hobgoblin of little minds", and all that. ·· 2A02: talk ·· 13:56, 17 July 2021 (UTC)
Many times when I have doubts about info in an article and there is a citation nearby, I ponder if the reference covers the part of the info I have doubts about. When the ref is easily searchable online, I can verify, which takes time, some times a little sometimes more. And when the ref is a book that is not searchable online, then the doubt persists and I wonder, what info covers the reference? Is it just one word? Is it a phrase, is it a sentence? A paragraph? For example, in the article Jacobo Árbenz, you can find the following: "On one of his visits to Mexico, Árbenz contracted a serious illness, and by the end of 1970 he was very ill. He died soon after. Historians disagree as to the manner of his death: Roberto Garcia Ferreira stated that he died of a heart attack while taking a bath,[140]". What info does the citation 140 covers? That he died of a heart attack while taking a bath? Or does it include the disagreement claim? Or does it include that he died soon after? You may think it is evident that it just covers the heart attack or not, but this is just to illustrate my point.
I think in order to save time for editors and to have more certainty about the info in a page, there should be a system to mark the extent of the coverage of any given specific reference. There could be a tab next to the "view history" tab, where one could see the page with the text of the info within in different colors, marking the extent of the coverage of each reference. The info that is not backed by any reference would just remain without color. Thinker78 ( talk) 18:06, 13 July 2021 (UTC)
One thing that Wikipedia falls short of on commercial encyclopedias such as Encyclopædia Britannica are its illustrations. Almost everyone can write an article, use citations and understand sources, but often illustrations, especially in more niche and complex topic areas require skill to create. Let's look at Encyclopædia Britannica's map of London's West End; vs the only map we have. The dedicated forum for requesting maps is really a hit and miss, a lot of requests go unanswered. It's not just maps, especially in topics such as geography and the sciences, we get poor illustrations. Our diagram for the water cycle (which wasn't even made by a Wikimedian), and Britannica's. Especially at smaller scales the former diagram is too detailed, and contains too much text to read.
Another problem is consistency. On Wikipedia, maps are relatively standardised (by no means 100%) but there are basically no guidelines on other illustrations. No guidelines on the fonts that should be used, the colours, the keys, meaning almost every illustration on Wikipedia shares no conventions, meaning a reader has to repeatedly adapt from style to style.
I don't really know a solid solution to this, I think probably the best would be for WMF to hire professional illustrators, meaning illustrations could be requested, similar to the Art Team on WikiHow. However, whether this is financially viable I do not know. I think a good starting step however would be to set out conventions on Illustrations, and the general style they should follow (even then this doesn't guarantee people will actually follow these guidelines). Standardising fonts, colours, and levels of detail would certainly benefit the project as a whole.
I might be speaking rubbish, or maybe there isn't a problem at all. I just thought it would be useful to get other's opinions on this matter. — Berrely • Talk∕ Contribs 14:40, 17 July 2021 (UTC)
<mapframe>
, which gives interactive maps that are not terrible overall. See {{
OSM Location map}}. For other diagrams, it is super difficult to get the size and level of detail right for all resolutions and screen sizes, especially if you want to use the same image on desktop and mobile. Generally, if you want to try to standardise the font and colour conventions for diagrams, your best shot is to lead by example and create (with a dedicated Wikiproject) a few thousand diagrams using these conventions that are clearly superior to what is currently used, and then people will want to use these and might follow your conventions. Or they might not, if these conventions are at odds with subject-specific ones. —
Kusma (
talk) 20:43, 19 July 2021 (UTC)
<switch>
element. We even have a dedicated tool made by Community Tech,
SVG Translate. It's actually rather good, and much better than manually editing code with a text editor. Sadly, as you noted, even if we have the tools to translate illustrations, it doesn't mean all illustrations are translated, and we have a lot of illustrations that are either only in English, yet used for other projects, or only in another language, and no one has the time to translate them. Not to mention that if a diagram is in a bitmap format such as PNG or JPEG translating it also requires image manipulation knowledge, which many don't have. —
Berrely •
Talk∕
Contribs 08:49, 22 July 2021 (UTC)I hesitate ti say this for fear of being guilty of unleashing a monster when this interacts with other poorly written policies, but illustrations often contain information and statements. In essence creating unsourced OR. North8000 ( talk) 23:32, 19 July 2021 (UTC)
I personally have accepted it as a characteristic of Wikipedia, that because it is free and the contributions are free, and that we can't use copyrighted works (except sometimes with Fair Use), we often don't have the beautiful illustrations that paid/professional media has (we do have one partial work-around, though: Template:External media). On the other hand I am still amazed at the many times we do have good illustrations. I praise your desire to do better and think of ways.
I see only two options: we either go through another phase of expansion (I wish!) in the number of wikipedians (and a small subset of them coming with graphic skills), or we accept the fact that to get good graphic design you have to pay for it at times. A system could be set up where editors propose and upvote on the graphics that need creation, and then the WMF offers some modest funding for someone to create them (either in-house, or gig-economy style). It may not be the most "pure" way of expanding wikipedia, but it may be the more pragmatic one. Just a thought. Al83tito ( talk) 04:24, 24 July 2021 (UTC)
I've noticed a lot of editors forget to use edit summaries. Perhaps we should require edit summaries for edits to the mainspace? -- Firestar464 ( talk) 11:35, 21 July 2021 (UTC)
Not sure where else to post this, but at a recent FAC [14] it was brought up that multiple image templates, which I've used a lot recently, should be avoided because they require that you force a certain pixel size, which is problematic. Is it technically possible to add something like the "upright" parameter that are already used on single images, which scales images relative to particular screens instead? Otherwise it will be hard to use the multiple image templates for articles meant for promotion. FunkMonk ( talk) 11:22, 10 July 2021 (UTC)
Generally, a gallery or cluster of images should not be added so long as there is space for images to be effectively presented adjacent to textsee WP:GALLERY — GhostInTheMachine talk to me 19:02, 10 July 2021 (UTC)
We encourage people to use {{ convert}} so readers can see numerical values in terms that are familiar to them. A laudable goal, but IMHO, poorly implemented. For example, in Mercury-Redstone 3, we've got "His spacecraft reached an altitude of 101.2 nautical miles (116.5 statute miles, 187.5 km) and traveled a downrange distance of 263.1 nautical miles (302.8 statute miles, 487.3 km)" That's not very reader-friendly. It seems to me a better way to do this would be to have a preference people could set "I want metric units" or "I want that bat shit crazy stuff they use in the US". Then, somebody could see "His spacecraft reached an altitude of 187.5 km and traveled a downrange distance of 487.3 km". Or, "His spacecraft reached an altitude of 116.5 miles and traveled a downrange distance of 302.8 miles" for those of use who grew up in an awkward backwater corner of the universe. -- RoySmith (talk) 00:39, 27 July 2021 (UTC)
We have received complaints from readers that Category:Linux distributions is an non-navigable mess and I agree, it is. It has obviously grown up "organically", with people adding random cats over time without rhyme or reason, making it almost impossible penetrate it and actually find comprehensible lists of Linux distros.
There have been several attempts fix this, including:
So, as mentioned, at User:Huggums537's suggestion I am bringing this here for ideas, thoughts and suggestions as to what to do about the remaining sub-categories in this category. Should they be retained, changed, or just left alone?
I duplicate here the category tree that I also posted in the CfD discussion, which diagrams the situation under discussion:
- Ahunt ( talk) 00:34, 28 July 2021 (UTC)
Wikipedia:Manual_of_Style/Biography#Opening_paragraph says the first sentence should include "Context (location, nationality, etc.) for the activities that made the person notable." If the subject was a slave owner should this context be included in the first sentence? ♥ L'Origine du monde ♥ ♥ Talk ♥ 02:07, 13 July 2021 (UTC)
Slave ownership is often mentioned in the lead sentence. See e.g. John Taylor (Baptist preacher) and Robert Ward Johnson. However, the mention is usually "was a planter....". "Planter" strikes me as a euphemism and I think most people won't know what it means. On the other hand, is suppose there is a difference between somebody whose income/livelihood was largely derived from slave labor (a "planter"), and somebody who owned a small number of slaves but earned most of their money through other ventures. Plantdrew ( talk) 19:19, 20 July 2021 (UTC)
Above and other reports from Wikipedia Co founder raise questions over article bias, foreign government fake news etc. How can that be countered?
Is possible to have a pro and con page tab per subject?
With links to each disputed 'fact' so that both the pro and con view can be read by reader?
How can Wikipedia measure or show the validity or support for each point of view?
Can links to alternate points of view be included in a semi permanent way? So that biased editors are forced to acknowledge alternative narratives?
At least it might at least show on Wikipedia that entry views are 1) indispute Or 2) minority views — Preceding unsigned comment added by Ro mona lisa ( talk • contribs) 14:55, 1 August 2021 (UTC)
I really don't understand the A-Class article ranking. I can't remember the last time I came across one. Does it even really serve a purpose? ~ HAL 333 20:41, 3 August 2021 (UTC)
I feel like this is something uncontentious as flat icons are being used all across the modern web. But still I want to build this proposal so that it is something that can reasonably be implemented.
I built a list at User:Awesome Aasim/Flat design idea - Wikipedia and @ Arsonxists continued expanding that list at User:Arsonxists/Flat Icons - Wikipedia. I feel like it would be a waste of time to get community input on something uncontentious, but I still want to figure out if there is a way that we can transition to flat icons and if there is someone willing to implement this idea. Aasim ( talk) 21:45, 3 August 2021 (UTC)
I do not think this question is ripe for an RFC. I see no recent discussion and I certainly see no major significant dispute needing resolution. I see a lot of "we should do this" but not a lot of "here's my solution".This is the drawing board, this is the place to figure out how the proposal should be done before it is proposed again via RFC. Aasim ( talk) 09:00, 4 August 2021 (UTC)
Maybe we should take a different approach. What happened to readers' input? After all, readers are the ones who are using Wikipedia, we are modifying it: WP:CREEP strikes again. User:Berrely made a good point: We don't know much about our readers. Maybe our readers are Gen Z teenagers. Maybe our readers are scientists who understand jargon. What do we know?
Is there some way we can poll our readers to see what they want? If this has been tried before, don't heckle me, come up with a better solution. Sungodtemple ( talk) 14:30, 5 August 2021 (UTC)
If you use Wikipedia to stay informed about current politics and elections, you will be used to articles of politicians being filled with sections about their political positions. Such sections are often divided into sub-sections about specific issues and may become very long. It seems that editors will indiscriminately add a politician's statement about their political position as long as there is RS (usually news) to substantiate it. I have noticed this problem in the English-speaking countries of the US, the UK, Canada, and Australia, and it may extend to virtually every democratic country. It also extends beyond government officials, elected or unelected, to political commentators and others who are involved in politics.
Political positions bloat is unencyclopedic, excessive detail, recentism, and cruft. Remember that Wikipedia articles are summaries of their topics, not treatises, not essays, not voter guides. While politicians generate a lot of media coverage (which would be considered routine coverage in the terms of our notability guides), we do not consider every detail mention-worthy, unless it happens to be a political position. Why would we include a low-profile comment someone says about, say, marijuana, but not if they own a dog? Both will not be remembered in the long term.
The salience of political issues constantly changes, and politicians will become known for a few accomplishments or ideological opinions. Lists of political positions will not pass the 10-year test, but summaries and generalizations will. We should not include such lists for pre-21st century politicians because we are aware of what they are notable for and what is a side detail. Indeed, we find sections discussing the political positions of dead politicians, though they are not bloated with details of minor political issues. In reality, that is because the Internet and the existence of Wikipedia have enabled the expansion of lists in gradual steps. One may object that we do not know which political positions are relevant. But even without the certainty of scholarship, we should recognize what is noteworthy based on how much attention some position has garnered in RS, just as we recognize which details of personal life are notable and which are not. It is especially useful when a source explicitly states that someone is known for something.
I propose a link-able essay written on this issue ( Wikipedia:Political positions, WP:POLPOS as a link?) and hope that we can soon cut down on political views sections. WIKINIGHTS talk 13:19, 9 August 2021 (UTC)
There are people who find certain images on Wikipedia offensive or disturbing. It should be possible for those viewers to access the text of an article without being forced to view the images. There is community consensus that offensive or disturbing images shouldn't be censored. At the same time one fundamental goal of Wikipedia is to make information accessible for everyone. If the graphic nature of certain (e.g. medical) images shocks some users, the information on that page is in effect no accessible to those persons. In those cases, those images work against one of the fundamental goals of Wikipedia. I therefore propose that sensitive images are hidden by default, and can be displayed with a single click. If no consensus can be reached which images should be considered offensive or disturbing, I propose that all images are hidden – and not loaded – be default. This will have the additional effect of making both mobile browsing for users and hosting of Wikipedia cheaper.— Preceding unsigned comment added by 2003:df:972b:fc52:bc41:2309:e4d1:9069 ( talk • contribs) 07:40, 3 August 2021 (UTC)
Idle thought: {{ uw-van1}} etc really ought to link to a specific diff when they can. Enterprisey ( talk!) 07:46, 10 August 2021 (UTC)
Are there any tools that can automatically find and display sections that used to be in an article but have since been deleted?
I think this might unfortunately be the most insidious form of vandalism. Disinformation isn't terribly hard to spot, verify, and remove, but sourced material that has been removed can't be seen again unless you go digging through the page's history for some reason. Intralexical ( talk) 15:42, 11 August 2021 (UTC)
Hello,
I have been spending some time in the sandbox of Template:AFD help, trying to fix some problems I perceive with it:
Below are some possible redesigns, transcluded from Template:AFD help/testcases:
Possible redesigns of Template:AFD help
|
---|
Current live code [Hide this box] New to Articles for deletion (AfD)? Read these primers! Sandbox code |
Any feedback is appreciated. Also, please feel free to suggest other possible designs. Regards, DesertPipeline ( talk) 05:38, 15 August 2021 (UTC)
Please add a subsection with four equal signs below all other subsections in this section with your comments. |
This idea/proposal is fundamentally flawed and is based on several misconceptions.
Example 1 (
Live sandbox, since it changes all the time); Original
Wikipedia:Articles for deletion/Daniel Carver (3rd nomination)
|
---|
The following discussion is an archived debate of the proposed deletion of the article below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page. The result was no consensus. Sandstein 06:33, 1 July 2018 (UTC) [Hide this box] New to Articles for Deletion (AfD)? Read these primers! AfDs for this article:
Daniel Carver ( | talk | history | protect | delete | links | watch | logs | views) – ( View log · Stats) (Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL) Doesn't seem to satisfy WP:GNG. Ambrosiaster ( talk) 17:56, 1 June 2018 (UTC)
Note: This discussion has been included in the list of People-related deletion discussions. MT Train Talk 07:58, 2 June 2018 (UTC)
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, North America 1000 07:13, 9 June 2018 (UTC)
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Sandstein 18:28, 16 June 2018 (UTC)
Relisted to generate a more thorough discussion and clearer consensus.
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's
talk page or in a
deletion review). No further edits should be made to this page.Please add new comments below this notice. Thanks, Enigma msg 05:09, 24 June 2018 (UTC) |
Example 2; Original
Wikipedia:Articles for deletion/Daniel Carver (3rd nomination)
| ||
---|---|---|
The following discussion is an archived debate of the proposed deletion of the article below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page. The result was no consensus. Sandstein 06:33, 1 July 2018 (UTC) AfDs for this article:
Daniel Carver ( | talk | history | protect | delete | links | watch | logs | views) – ( View log · Stats) (Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL) Doesn't seem to satisfy WP:GNG. Ambrosiaster ( talk) 17:56, 1 June 2018 (UTC)
Note: This discussion has been included in the list of People-related deletion discussions. MT Train Talk 07:58, 2 June 2018 (UTC)
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, North America 1000 07:13, 9 June 2018 (UTC)
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Sandstein 18:28, 16 June 2018 (UTC)
Relisted to generate a more thorough discussion and clearer consensus.
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's
talk page or in a
deletion review). No further edits should be made to this page.Please add new comments below this notice. Thanks, Enigma msg 05:09, 24 June 2018 (UTC) |
This is bike-shedding at its finest. Headbomb { t · c · p · b} 06:42, 15 August 2021 (UTC)
explicitly cause a mismatch between the two boxes. That is the intent; they aren't related boxes. Putting the help links elsewhere allows us to make the previous AfDs box a dynamic size, avoiding a load of whitespace which would occur if the links inside that box aren't as long as the box itself. DesertPipeline ( talk) 07:04, 15 August 2021 (UTC)
Changing the width of one box without changing the width of the other box will cause a mismatch in width between the box, and that's also bad design.
Here are the same screenshots:
Headbomb { t · c · p · b} 07:42, 15 August 2021 (UTC)
You could in theory design something that's used on a go forward basis, but you'd need to redesign the AFD link box, the AFD help box, both should line up and be of equal width, then redesign the AFD workflows to make use of them. And then you'd need an RFC to roll out the changes. You cannot do so simply by editing {{ AFD help}}, you need new templates entirely, and then redesign AFD around those new templates.
Apologies if this is the wrong place, willing to move this question if this is the case. Is there any bot currently on the English Wikipedia which creates articles unassisted? And would such a bot be allowed in the future if this isn't the case? By articles I don't mean redirects, or disambiguations. Note that this is not me making a bot request but instead just asking out of curiosity. Cheers, Rubbish computer Ping me or leave a message on my talk page 18:21, 16 August 2021 (UTC)
Thank you both, will read more about it at the links provided. Rubbish computer Ping me or leave a message on my talk page 18:34, 16 August 2021 (UTC)
Xaosflux I didn't realise ruwikinews did that, sounds like a mess. Rubbish computer Ping me or leave a message on my talk page 18:36, 16 August 2021 (UTC)
They are copying verbatim professionally written news articles that were placed into Creative Commons after the Putin regime forced the closure of this newspaper as it was critical of the regime. This might have unintended results since anyone including pro-Putin elements can now edit those articles requiring constant vigilance to monitor millions of articles. A read-only archive might have been better. -- Green C 19:35, 16 August 2021 (UTC)
Earlier today I stumbled upon a help request from a user asking for suppression of the IP associated with an edit they made while accidentally logged out. The request didn't include a diff of the problematic edit ( duh), but since such requests are routinely granted, I thought someone at #revdel would be able to CU the user and find the edit in question. To my surprise, this couldn't be done because our current CU policy precludes such checks.
I believe that adding an exception to our CU policy that would allow Oversighters who are also CUs to use the CU tool to expedite the handling of incomplete suppression requests would be an improvement on the current situation in which the requester is needlessly required to supply the missing information before their request can be actioned.
The global CU policy allows individual wikis a degree of latitude in handling self-requested checks; I believe that filing an OS request (regardless of its form) such that it requires user IP information to handle can be regarded as such a request and so the exception would be in keeping with the global policy. An argument could be made that such a check might reveal more than the user wanted us to know but this is always the case with self-requested checks and doesn't clash with the long-standing practice of allowing such, globally speaking (enwiki currently disallows self-requested IP checks wholesale).
I'd imagine that the typical profile of a person that inadvertently reveals their IP while logged out is that of a careless new editor. Such are notorious for being difficult to reach when a follow-up is needed which means their perfectly valid OS requests may end up rejected, or significantly delayed, due to purely bureaucratic hurdles. That sounds to me like a situation that could and should be improved upon regardless of how often this actually happens.
My proposed policy amendment would roughly look something like this:
As oversight requests are often time-sensitive, oversighters who are also checkusers are permitted to perform CU checks to expedite the processing of incomplete suppression requests. Information obtained through such checks may be used only for that specific purpose, and must not be shared; it also must not be retained, or even accessed, by the oversighter any longer than absolutely necessary for the handling of the request.
Is this something worth proposing at VPP? I'd appreciate some feedback. 78.28.44.31 ( talk) 05:57, 26 July 2021 (UTC)
I use a gadget in my preferences that shows blocked users with a strike through their username on talk pages and page histories. However, anything from a decade ago, for example, has quite a lot of strikethroughs. Some of the users are LTAs, trolls, and whatnot, but a lot are either deceased or retired or just abandoned. I was wondering if there could be some kind of difference in a perma-ban block & a deceased block, etc. Also, at ANI a 24-hr block appears the same as an indef. Maybe a perma-ban could have double strike throughs, a deceased block could be a different color, etc. Thoughts? Rgrds. -- Bison X ( talk) 15:55, 15 August 2021 (UTC)
Sometimes when an image becomes the subject of discussion, discussion takes place both on en-Wikipedia and on Commons. However, most images are hosted on Commons, you can't directly edit or replace the image on en-Wikipedia etc. so image talk page on en-Wikipedia probably shouldn't be used unless any discussion relates only and specifically to en-Wikipedia.
I propose that soft redirects to Commons talk pages on all pictures be added automatically.
An alternative is to add tags like Discussed on sister project
or talk at enwp
to en-Wikipedia file discussion pages, like is used here:
https://commons.wikimedia.org/wiki/File_talk:RGB_3bits_palette_sample_image.png but I think that tag is specific to Commons.
(Why am I proposing this? I recently updated in the seating diagram of the US Senate, and found it cumbersome getting consensus both at Talk:United States Senate and c:File Talk:117th United States Senate.svg. I ended up adding a soft redirect at File Talk:117th United States Senate.svg lest discussion began in a 3rd location.)
Egroeg5 ( talk) 02:50, 22 August 2021 (UTC)
Was there a previous discussion on whether categories should or should not be transcluded from templates? For example, {{
Kerala State Award for Best Actress}}
could potentially transclude
Category:Kerala State Film Award winners onto the articles. That would make categorization of the articles a little easy, by removing the manual need of adding cats to articles. Surely, it would also put the
Kerala State Film Award for Best Actress article into the category. To counter these unwanted, a |cat=no
parameter could be introduced to templates to not allow not transcluding the cats. I updated {{
NSE}}
and {{
BSE}}
to include the respective cats, and wondering if I acted too quickly. Thoughts around these?
-- DaxServer (
talk) 13:00, 22 August 2021 (UTC)
{{
Infobox film}}
-- DaxServer (
talk) 13:09, 22 August 2021 (UTC)
There are about ~88,000 files under the
Category:Non-free posters which will benefit from moving to sub-categories. Depending upon the article where the file is used, it could be moved. This way the huge cat could be diffused. The category can be set in the {{
Non-free poster}}
as the first unnamed parameter. This ideally could be done by a bot.
One straight forward action is for movie posters which are used only once on the respective movie articles. The {{
Infobox film}}
transcludes appropriate language category from
Category:Films by language. There are not that many sub-categories by language in the Non-free posters category. My proposal is to create those categories under
Category:Fair use images of film posters (under appropriate country), and assign the posters based on the Infobox transcluded category intersecting
Category:Films by country on the article. In case of multi-lingual films, [I'm not sure if it transcludes all categories for multi-lingual films], the first category that one encounters would be put in the {{
Non-free poster}}
template and the second category would be added as a normal category.
Categories other than films could also be handled accordingly, or be left out for a follow-up work. Surely, a con that I see is the mis-categorization of the main article, (either due to unchecked vandalism, or some other reason,) resulting in the mis-categorization of the poster. The bot could also regularly check and re-categorize, or post a message for a manual check. Opinions and thoughts around this? -- DaxServer ( talk) 12:09, 23 August 2021 (UTC)
Imagine you’ve just spent 27 minutes working on what you earnestly thought would be a helpful edit to your favorite article. You click that bright blue “Publish changes” button for the very first time, and you see your edit go live! Weeee! But 52 seconds later, you refresh the page and discover that your edit has been reverted and wiped off the planet.
An AI system - called ORES - has been contributing to this rapid judgement of hundreds of thousands of editors’ work on Wikipedia. ORES is a Machine Learning (ML) system that automatically predicts edit and article quality to support content moderation and vandalism fighting on Wikipedia. For example, when you go to RecentChanges, you can see whether an edit is flagged as damaging and should be reviewed. This is based on the ORES predictions. RecentChanges even allows you to change the sensitivity of the algorithm to "Very Likely Have Problems (flags fewer edits)" or "May Have Problems (flags more edits)”.
In this discussion post, we want to invite you to discuss the following *THREE potential ORES models* -- Among those three models, which one do you think presents the best outcomes and would recommend for the English Wikipedia community to use? Why?
ABOUT US: We are a group of Human–computer interaction researchers at Carnegie Mellon University and we are inviting editors to discuss the trade-offs in AI-supported content moderation systems like ORES; your input here has the potential to enhance the transparency and community agency of the design and deployment of AI-based systems on Wikipedia. We will share the results of the discussion with the ML platform team which is responsible for maintaining the ORES infrastructure. However, the decisions of the discussion are not promised to be implemented. More details are available at our research meta-pages: Facilitating Public Deliberation of Algorithmic Decisions and Applying Value-Sensitive Algorithm Design to ORES.
Group / Metrics | Accuracy Percentage of edits that are correctly predicted
|
Damaging Rate Percentage of edits that are identified as damaging
|
False Positive Rate Percentage of good edits that are falsely
identified as damaging |
False Negative Rate Percentage of damaging edits that are
falsely identified as good |
---|---|---|---|---|
Overall | 98.5% | 3.4% | 0.5% | 26.3% |
Experienced | 99.7% | 0.2% | 0.0% | 61.2% |
Newcomer | 95.7% | 10.7% | 1.8% | 23.0% |
Anonymous | 94.8% | 12.7% | 2.4% | 22.8% |
Group / Metrics | Accuracy Percentage of edits that are correctly predicted
|
Damaging Rate Percentage of edits that are identified as damaging
|
False Positive Rate Percentage of good edits that are falsely
identified as damaging |
False Negative Rate Percentage of damaging edits that are
falsely identified as good |
---|---|---|---|---|
Overall | 97.2% | 1.2% | 0.1% | 69.9% |
Experienced | 99.6% | 0.0% | 0.0% | 94.0% |
Newcomer | 91.2% | 4.4% | 0.8% | 68.5% |
Anonymous | 90.7% | 4.5% | 0.0% | 67.2% |
Group / Metrics | Accuracy Percentage of edits that are correctly predicted
|
Damaging Rate Percentage of edits that are identified as damaging
|
False Positive Rate Percentage of good edits that are falsely
identified as damaging |
False Negative Rate Percentage of damaging edits that are
falsely identified as good |
---|---|---|---|---|
Overall | 96.1% | 7.6% | 4.0% | 2.4% |
Experienced | 99.9% | 0.4% | 0.0% | 17.9% |
Newcomer | 91.8% | 19.8% | 9.1% | 1.0% |
Anonymous | 82.7% | 30.8% | 19.9% | 0.8% |
If you are not satisfied with any of the models described above, you can try out this interface, pick a model on your own, and share your chosen model card in the discussion by copying and pasting the wikitext offered in the interface.
Bobo.03 ( talk) 15:32, 20 August 2021 (UTC)
Hi @ Bobo.03: I'm sure this has come along since my very early engagement with it. I know you are well-aware of CluebotNG, but I'd like to draw a highlight that although it once accepted a false positive rate of 0.25%, it has been changed to use 0.1% as its threshold. That hit 55% and 40% of vandalism (thus 45% and 60% false negative). That, I think, gives a pretty clear marker that Wikipedians are way more willing to accept it missing something than an unwarranted hit. Unwarranted hits kill off new users, and irk experienced users, while many issues missed can be caught by alternate means. I tried to have a fiddle with the interface but couldn't figure out how to make it apply different tolerable false positive rates to different groups. Nosebagbear ( talk) 20:43, 20 August 2021 (UTC)
Hello! So I have an idea of being able to add pages to your watchlist by simply putting the name of the article/page into a text box and it will add that article/page into your watchlist instead of having to go to individual pages and clicking on the star to add it on to the watch list. Not sure if this is already something that's been mentioned or if it's even possible because I don't know how to write code that makes Wikipedia work. Blaze The Wolf | Proud Furry and Wikipedia Editor ( talk) 13:53, 20 August 2021 (UTC)
Hi guys! Please consider my Idea. The mobile view doesn't have easy access to the preferences, so I was just thinking if there was a way to change that? Twilight Sparkle 222 ( talk) 22:12, 16 August 2021 (UTC)
Hello! I have a feeling I already proposed this idea but i can't remember. Anyways, my idea is the ability to add a short message to your thanks. Yes WikiLove exists, however if someone does something small and you'd like to show your appreciation, I'd find that WikiLove would be a bit overkill. For example, on my talk page, ferret fixed a WikiLove another editor gave me as when I replied to the WikiLove, it was part of the WikiLove and I attempted to fix it myself but couldn't and ferret fixed it for me. I thanked them and would've liked to leave a short little message saying something like, "Thanks for fixing the WikiLove" however I don't necessarily think something like that would be fit for a WikiLove message. Blaze The Wolf | Proud Furry and Wikipedia Editor ( talk) 16:23, 23 August 2021 (UTC)
I propose making a space for editors to openly discuss and recommend candidates in Wikimedia elections. Wikimedia is the parent organization of Wikipedia and as such takes important decisions that affect Wikipedia, therefore it is my belief that it is important for editors to discuss Wikimedia elections, candidates, make recommendations of candidates to vote for and have a space in Wikipedia for such discussions, without running afoul of rules like WP:CANVASS. Thinker78 ( talk) 01:03, 26 August 2021 (UTC)
I'm interested in getting feedback for a feature I've been working on as a hobby. I have working code but it is alpha-quality.
Many people do not trust quotations in the media because they are suspicious that the quote may be taken out of context or fabricated.
I've been developing an open-source app that:
* given a quotation which is attributed with a URL, * looks up the quote context using a Python Webservice and saves the contextual data to a JSON file * displays the context to the reader using javascript to render contextual popups or expanding blockquotes
* I propose that Wikipedia explore "upgrading" those quotations that are attributed to a web source to CiteIt-style contextual citations.
The Benefit of using Contextual Citations is that readers:
* learn more about the context of quotes * gain trust in the integrity of the citation and verify that a quote wasn't fabricated or cherry-picked.
You can view a video and demo on my project website:
* View Demo
I've outlined some of the steps to implementing this on my Wikipedia User page:
* https://meta.wikimedia.org/wiki/User:Timlangeman/sandbox
* All code is published on GitHub and licensed under the open-source MIT License
P.S. I'm new to the Wikipedia culture, so feel free to point out the correct Wikipedia way.
Timlangeman ( talk) 03:05, 24 July 2021 (UTC)
Hi Timlangeman, thank you for your neat idea and having the tech chops to develop the code! From seeing how it works in the demonstration video, I can see this implemented in one of two ways: just as you show it, by making the quote itself clickable to bring up the contextual pop-up box, or, have this feature imbedded in the corresponding in-line citation. The question is: would this feature be used so often by readers to be it worth to make the main text clickable? Or should we minimize the "noise" in the text by having this feature a bit more discretely included within the reference? Food for thought. Thanks! Al83tito ( talk) 05:35, 24 July 2021 (UTC)
Hi Al83tito, I'm open to UI suggestions and I'd be happy for others to experiment with UI ideas too.
As far as the amount of link "noise", this can be handled in different ways:
I don't know if you saw the 8 sample articles that I mocked up?
* 8 Sample Wikipedia Articles
These should provide good samples for programmers and designers to experiment with.
I packaged these files up into a Git repository for anyone that has UI skills and wants to experiment with different UI options.
* https://github.com/CiteIt/wikipedia-samples
If you don't have programming skills, I can create mockups based on your suggestions.
Timlangeman ( talk) 14:48, 24 July 2021 (UTC)
I like the general idea. I do have one issue however... Wikipedia generally doesn't have many direction citations. This is because of the copyright nature of Wikipedia and because it is a tertiary source. We intentionally 'transform' and 'rewrite' points from 1st and 2ndary sources most of the time and then use references. I see that as a bit of a problem for the success of this particular tool. Do you have thoughts on that ? — TheDJ ( talk • contribs) 09:05, 3 August 2021 (UTC)
This is a copyright nightmare. Even the image used to demonstrate this ( [22]) is probably not acceptable, as it has a way too long quote of copyrighted text. We instruct editors to make their quotes as short as possible (if the text is copyrighted, and if they can't avoid using quotes altogether): to then add a tool that shows much longer quotes simply contradicts this. For public domain sources, fine, but for copyrighted texts, I don't think this will be acceptable. Fram ( talk) 09:24, 3 August 2021 (UTC)
@ Fram and @ TheDJ, I did a little bit more research and consulted with @ LWyatt, who has a Master's degree in Intellectual Property law.
Fram is correct that copyright can be a nightmare in many countries.
I asked LWyatt why the Internet Archive is able to publish complete archived documents. He said that this is due to the US's fair use laws. LWyatt said that just as fair use laws in the US allow the Internet Archive to host archives of complete documents, fair use would allow the US Wikipedia to publish CiteIt's contextual snippets, but only for the US version hosted in the US.
This means that to start with at least, CiteIt's Contextual Citations would have to be restricted to the US English site.
Do people have additional feedback on other isssues, such as the user interface or the general idea? Timlangeman ( talk) 13:31, 27 August 2021 (UTC)
If copyright issues are a barrier to contextual citations, I'm wondering what people think about using Google Text Fragments in linking to citations to help the reader more easily inspect the context of the quote. I've written up a summary aggregating some information about them:
* Using Google Text Fragments to Link to Specific Text
I know that there are issues with browser support and privacy. At this point, I'm mainly trying to seek what people think about them in principle. Timlangeman ( talk) 21:47, 5 August 2021 (UTC)
Greetings
Requesting (brainstorming) inputs regarding Manual of Style proposal @ Chronological listing of coastal townships
Thanks and warm regards
Bookku, 'Encyclopedias = expanding information & knowledge' ( talk) 06:38, 29 August 2021 (UTC)
There is a longstanding problem with transcluded refs and notes -- their name and group parameters sometimes collide with names/groups in the transcluding article or names/groups from other transclusions. I've made suggestions about this elsewhere in the past (some good and some hare-brained), but none of those have gone anywhere. Another approach occurred to me this morning. I'm wondering whether en editor-discoverable short unique article identifier (effectively an article-ID) which remains stable through article renamings/page-moves. If there is such a thing, or if it is easily implementable within WP,, that identifier could be incorporated by editorial convention into the name and group parameters of refs and notes subject to transclusion. This was prompted by what appears to be an instance of this problem which I fixed with a workaround in this edit. Wtmitchell (talk) (earlier Boracay Bill) 12:35, 29 August 2021 (UTC)
There are 2 problems that creating Wikidata items for Files on Wikipedias could solve:
Example of benefits:
To implement this, all we would need to do is:
Wikidata already supports Files as sitelinks, so no new development is needed to implement this (unless allowing 2 datatypes for a property might be an issue).
Thoughts? Lectrician1 ( talk) 22:57, 28 August 2021 (UTC)
In scientific works quotations are used to directly quote another piece of literature; a source citation is usually provided directly after the quote. On Wikipedia, citations are required, but I find that text taken from a source can be broken through editing quite easily. For example, if someone provides "including the sum of all virtual worlds, augmented reality, and the Internet" and a source, someone can just delete "augmented reality", leaving a perhaps incorrect statement "including the sum of all virtual worlds and the Internet".
I understand that Wikipedia does not want lots of quoted pieces of text. I would like to suggest a markup tag that provides similar functionality internally, but with no visible changes on the rendered page. If I'm not mistaken the <ref/> tag is always used without text, except the citation e.g., <ref>{{citation}}</ref>.
Instead of providing something like:
I would suggest:
or a new nested tag:
To the person editing it immediately provides a visual cue of which text comes from a particular reference. On the "Related changes" and history page a visible symbol could warn when an edit happens within a quote of text without the source being updated or when a quote is deleted entirely. Editors can then know when the source needs to be checked to verify the edit was correct.-- K.Nevelsteen ( talk) 07:14, 27 August 2021 (UTC)
Inspiration:
I commonly create music release items on Wikidata for artists who may not be popular enough to have an article for every release or song they release. These releases are mentioned on their artist or discography pages, however they have no link to the Wikidata item that exists for release.
This clearly has some disadvantages:
Proposal:
Create a template called "Existing Wikidata link" that displays an orange (or another color) link to the Wikidata item of a term for logged-in users (editors). No link displays for non-logged-in users and the text looks normal. This functions similarly to how the Wikidata edit button on templates that support Wikidata shows up only for editors.
This link will be used exactly as blue links currently are. The first mention of a relevant term on an article deserves a link.
Example:
A.C.E (South_Korean_band)#2021–present: New_agency, Siren: Dawn and Changer: Dear Eris mentions the album "Changer : Dear Eris". This release does not have an article, so it is not linked.
I created an item for this release: Changer : Dear Eris (Q108291790)
I replace the text on the article with: {{Existing Wikidata link|Q108291790}}
The text then turns orange and becomes a link to the item.
The text for the link can be automatically drawn from the label of the item or be specified as the second argument for the template.
Going further:
A link could be created for every repeated thing mentioned on a Wikipedia article.
This clearly would make source-editing articles a nightmare, however it could serve an important purpose.
Wikidata is a subset of the Semantic Web movement. One of the goals of the semantic web is to link all things on all webpages. By linking everything on an article, Wikipedia could help this movement and provide computer-interpretable contextualization for all content on all Wikpedia articles.
I'm mentioning this because it's something to think about.
When the Visual Editor eventually becomes usable for all editing actions, specific links could be implemented for all things mentioned in an article. The source text could become a convoluted system of links for all things mentioned, but not disrupt the editing of the user utilizing the Visual Editor which would provide a usable user interface to work with the links.
Additionally, AI in the future could assist in the linking of text in articles.
Feedback:
Let me know what you think of both the main proposal (which is intended to be implemented) and the future-thinking ideas of linking everything (which is not intended to be implemented at the moment). Lectrician1 ( talk) 00:47, 29 August 2021 (UTC)
Wikipedia has a lot of queues. Two disparate examples: WP:AFC/R and WP:PERM. What if we made them all use the same technology? I have a vision. If you write a JSON page that has the following information:
You should get:
Problems this solves:
Queues this could apply to, off the top of my head: DRN, BRFA, PERM, AFC/R (probably more)
Anyway, if anyone wants to help out, let me know here. This might be a bit of a heavy lift, but I'm sure it's worth it, and I know a thing or two about graceful and peaceful transitions of Wikipedia processes to newer technology.
Enterprisey (
talk!) 07:10, 11 August 2021 (UTC)
Enterprisey, part of User:Alexis Jazz/LuckyRename is more or less a library. (getToken() gets an edit token, getArticletext('Main Page') gets raw page text, that sort of thing) Editing ( doAPICall() ) isn't a proper separate function atm, though I plan to change that. Not sure you could use any of it in its current state, but I hope creating a user script can eventually be made as simple as, say:
userscriptID = 'myVoteScript'; $( '.mw-content-text' ).append('<div id="userscriptID"></div>'); // would attach to the bottom of the page addvote = function(yourvote) { pagename=mw.config.get('wgPageName'); voted = editpage(pagename, yourvote, 'append'); if ( voted.edit.result == 'Success' ) { $( userscriptID ).append('<br \>You voted!'); location.reload() } else { $( userscriptID ).append('<br \>Squirrels intercepted your vote. Whatcha gonna do?') } } $( userscriptID ).append('Vote something?<br \>'); addButton(userscriptID, 'supportButton', 'Yay support!'); addButton(userscriptID, 'opposeButton', 'Boo! Boo!'); buttons.supportButton.on( 'click', function() { addvote('* \'\'\'Support\'\'\' ~~~~') }); buttons.opposeButton.on( 'click', function() { addvote('* \'\'\'NO NEVER\'\'\' ~~~~') });
But this is largely a rough idea at this point. Not sure it'll even help here, but perhaps it could attract more coders if creating a user script was simpler. Edit: Now that I think about it, this is simplifying on a lower level. The gadget you envision could partially be made using something like this, but wouldn't have to be. Your idea is pretty clever. Shouldn't even be that hard to create. (though the 80/20 rule applies, 80% can be written in 20% of the time) — Alexis Jazz ( talk or ping me) 22:36, 31 August 2021 (UTC)
A VPR discussion closed about three months ago eeked out a consensus to experiment with a new look for Template:Authority control, but it wasn't super clear even at the time what exactly the community wanted that look to be. The new design has resulted in effectively the authority control turning from a one-line bar into a navbox, which is a major expansion, and the general sense I have is that this isn't what the community signed up for. How long do we have to live with this version of authority control before it's either improved to something tolerable or rolled back? I'd encourage a little bit of discussion here, but if improvements are not forthcoming, I'd like to soon see a more formal referendum at VPR that'll carry the possibility of action. {{u| Sdkb}} talk 00:19, 4 September 2021 (UTC)
I have come across a situation when I am checking edits in my watchlist. I for example see the last minor edit of someone and then I don't bother and keep going through the list. But behind that edit in the article's history may be a number of consecutive edits that I would like to take a look, but I didn't because I thought it was a single minor edit the editor made. As a solution, an idea is to add the number of consecutive edits next to the number indicating the size of the edit in bytes. I think this would help editors be more engaged in their patrolling by not missing consecutive edits that may be of interest to them, which oftentimes are overlooked because in the watchlist one assumes there was only one little edit made. It would also help save time by giving the editor some info that currently is obtained by clicking on the page history to see namely the number of consecutive edits by an editor. Thinker78 ( talk) 00:08, 22 August 2021 (UTC)
(3 changes | history)
. No doubt the WMF code for watchlists is incredibly convoluted and any change will be a pain, but the proof of concept is there. This would make no difference to me personally, but I see the use case for others (I aim to review every edit that pops up in my watchlist, and try to keep my watchlist as small as possible for that reason). —
Bilorv (
talk) 21:49, 28 August 2021 (UTC)
When an individual edit is made to an individual article, it's trivial at that point to determine if that edit is the first, second, fifth, or seventeenth consecutive edit from that user.Actually, that's an assumption on my part. It's certainly much more likely to be doable in the context of performing the edit, than trying to assemble the info after-the-fact during watchlist processing, but even at edit time it would still require examining the nearby edit history for the article. But without knowing far more about the inner workings of the system, the only statements I can make about its difficulty are ignorant ones. That being said, tags already exist for things like "Non-autoconfirmed user rapidly reverting edits" and "repeated addition of external links by non-autoconfirmed user", and that fact alone tells me that taking surrounding context into account when tagging edits is far from impossible. -- 21:56, 5 September 2021 (UTC)
We've got IP range blocks, but when the ranges get wide, the collateral cost becomes prohibitive. So, how about browser-specific range blocks? You could block a wide (/18 or more) range, and specify that it only applies to a specific client string. I could see two ways to implement this. One for use by CUs, where you explicitly specify the client string (or perhaps, a pattern). The other would be a "block by example" version that any non-CU admin could use by supplying a specific edit and it would block whatever client was used to perform that edit without revealing the actual client to the blocking admin.
I'm working on a WP:Sockpuppet investigations/Rgalo10 where we'd need to block three different /18s to be effective. That's unlikely to happen, but blocking those 3x/18 in combination with a client string would be much more attractive.
Yeah, I know, people upgrade their browser. People switch browsers. People use browser-obscuring proxies. It's not perfect, but it would still be a good tool. -- RoySmith (talk) 22:13, 2 September 2021 (UTC)
People use browser-obscuring proxies.Well, you don't even need a proxy. You just need to modify the
user-agent
header, which is trivial.
ProcrastinatingReader (
talk) 22:16, 2 September 2021 (UTC)
:-p
When the blocking admin has no idea what they are blocking in the first place, they may block something very commonthis happens now on almost every user block. If the "Autoblock any IP addresses used" option is selected (which it is by default), you block IP addresses without even knowing what they are. -- RoySmith (talk) 23:03, 15 September 2021 (UTC)
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)
.mw-echo-ui-notificationsInboxWidget-sidebar {display:block;}
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)
{{
asbox}}
. --
Redrose64 🌹 (
talk) 08:59, 21 September 2021 (UTC)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)
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)
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)
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:
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)
{{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}}
This experiment concludes that water is wet
{{
cite episode}}
: CS1 maint: numeric names: authors list (
link)
{{
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)
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)
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 TalkBlaze Wolf#0001 19:41, 22 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)
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)
This page contains discussions that have been archived from Village pump (idea lab). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
< Older discussions · Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57
When you paste text into messaging apps and some word processors, the footnote markers stop being superscripts and show up with a normal baseline, which "makes the[1] text somewhat[2] illegible[3]".
It's good for pasted passages to refer to their sources, but more often than not, the medium that the Wikipedia passage is being pasted to omits the link (e.g. text messages where hyperlinks become normal text, or printed paper where hyperlinks are useless).
Footnote markers being copied is more often a nuisance than a useful thing, so I propose that they not be copiable under regular circumstances (maybe a keyboard shortcut or a toggle could make them copiable). — Preceding unsigned comment added by 207.172.131.14 ( talk) 03:05, 2 July 2021 (UTC)
sup.reference { user-select: none; }
. However I doubt it's actually desirable: as Nosebagbear says we don't want to make it too easy for plagiarists.
the wub
"?!" 14:16, 2 July 2021 (UTC)
The Wikipedia Library has a horrendous backlog of suggested sources. So I'm curious about the idea of fundraising (via some external platform) so the wiki/editors can purchase institutional-type access to various scientific journals and databases for the Library. Access to academic publications and resources is absolutely critical to developed well-sourced content in a significant amount of subject matter that isn't covered in the news media but is covered in those publications. Additionally certain high-quality news cites are also now under paywall and if the funds can be raised, the Library could also potentially offer access to these very important sources.
I'm curious about implementing this in a couple ways:
If anyone has input on this, please do. ~Gwennie🐈⦅ 💬 📋⦆ 23:46, 4 July 2021 (UTC)
i noticed wikidata has property for relationships, is it better to show them in a nav bar template like baike https://baike.baidu.com/item/%E5%94%90%E7%BA%B3%E5%BE%B7%C2%B7%E7%89%B9%E6%9C%97%E6%99%AE?fromtitle=Donald+Trump&fromid=7895491 bi ( talk) 05:49, 30 June 2021 (UTC)
Page hits some number of hundreds of thousands of views, or hits 1 million views, add a banner for the day that "This page has hit 1 million views"? And similar increments, 2 million, 5 million, 10, 20, 50, and so on. Is that something we'd do, or could do? Hyperbolick ( talk) 09:02, 29 June 2021 (UTC)
Pending changes has been discussed recently in this RfC and this RfC. Specifically, there are a few issues I think may be worth discussion:
Thoughts appreciated to refine the above ideas and decide whether there is a problem here, before taking it to RfC. ProcrastinatingReader ( talk) 19:46, 3 July 2021 (UTC)
Should the PC user-right be removed and its permission bundled into either autoconfirmed or extendedconfirmed?makes me confused. Some vandals and many disruptive editors make it to autoconfirmed before being blocked. This would make many hours of discussion at ANI; threads with titles like "User accepting vandalism in pending changes protected articles. I would support the bar being a little higher, like 365/5000 rather than 30/500 or 4/10, though. Most purposely disruptive editors don't make it that far. 🐔 Chicdat Bawk to me! 10:30, 4 July 2021 (UTC)
The extension has no maintainer; it is ancient and technically complex. There are few people still around that are familiar with the codebase, and most devs don't want to touch it.As a software engineer, that's a big red flag. You really don't want a system as big and widely used as wikipedia to depend on something like that. The scary scenario is not that it stops working and nobody can figure out how to fix it. The scary scenario is that it breaks in some way that impacts the running of the site (perhaps a security exposure) and nobody can figure out how to disable it cleanly because there's some dependency that nobody knew existed. You really want to discover things like that during a planned phase-out, not when you're putting out a fire.
Level 1
Level 2
Level 3
its use case is "any article that would be semiprotected but has a low enough rate of edits for PCR to not get clogged by stacked edits". It's significantly less work to review a single pending edit than evaluate and then actually add-in a single edit request. Reading through that sentence above, it seemed like a no-brainer to me to merge the two protection levels and make semi-protected pages have easier review tools for edit requests (through an UI instead of a template). I imagine that if there were to be a new system for PC that essentially merges PC and semiprot, the visibility (do unregistered editors see pending changes?) mechanics would be the same as "regular" PC, which is the system currently. As for how something like this could be written, and by who, I'm not entirely sure. If a community member wants to ask for a WMF grant in exchange for building a new extension, that could work. This could be brought up at the next Community Wishlist Survey, or the m:WMDE Technical Wishes. I'm not sure if this is appropriate for a Phab task, but if all other methods are exhausted, a Phabricator feature request task could be filed as a last resort. I refer to this as a last resort, as in my experience Phab is rather slow for feature requests, especially fairly large ones (which is completely fair).
Sorry, I just realised that this is a gigantic jumble of words. I'll try to clean it up later, but I'm publishing this now to save it. 🐶 EpicPupper (he/him | talk, FAQ, contribs | please use {{ ping}} on reply) 04:40, 7 July 2021 (UTC)
As a good-faith new user, ideally I shouldn't have to learn about edit requests or any internal processes in order to contribute. I should just be bold and edit. That’s exactly what I meant, Pending Changes is much less of a barrier for new users to go through (just click edit) than edit requests, and if semi prot is replaced by PC, PC would be the replacement of our current edit requests system. Phil Bridger, I meant “editing articles directly” as in having an easier UI for new editors to edit exactly what is inside the article instead of having to fiddle around with using a template, going to the talk page, describing the changes, etc, with edit requests. 🐶 EpicPupper (he/him | talk, FAQ, contribs | please use {{ ping}} on reply) 18:21, 7 July 2021 (UTC)
flaggedrevs
extension is an unholy mess that is technically incongruous with how MediaWiki otherwise works. Forking like Git or suggested edits/'track changes' as in MS Word would be a massive improvement, and yet also a massive task to implement as you say. In the interim I stand by my comments above that the extension should be phased out of use here on enwiki.
firefly (
t ·
c ) 08:44, 8 July 2021 (UTC)
Relevant guideline (I think): Wikipedia:Disambiguation § Dictionary definitions: A short description of the common general meaning of a word can be appropriate for helping the reader determine context.
My impression is that this is generally sufficient guidance when it comes to content words, and ditto when it comes to the minority of function words that have their own articles - i, we, you, he, she, it, they, for example. With the predictable exception of single-letter "I", each of these leads either to the article about the pronoun, or to a disambiguation page, either directly or via a redirect. And if a disambiguation page, the pronoun is either treated as the primary topic and placed above the "may also refer to" introduction, or else the very first entry below it. Additionally, of course, there's always a link to the corresponding wiktionary entry via the interwiki template. So, clearly no consistency issues here.
It's quite different for the majority of function words that don't have separate articles, though - am, are, is, for example. In each case, the path relevant to the function-word usage ultimtely leads to the same place, Copula (linguistics) § English, which is good, but which is also where the consistency ends. "Am" and "are" redirect to disambiguation pages. The former puts it at the bottom of § Other uses, making it, by accident or design, the very last regular disambiguation entry on the page. The latter puts it at the very top of the page, just as in the case of the pronouns. And "is" redirects straight to the target section, which has the requisite "For other uses" hatnote link to the disambiguation page... which in turn includes a link to the target section mid-page, under § Language. Doesn't get much more inconsistent than that, does it.
My guess is that this comes about because both of these factors - not lexical, not "worthy" of an article - make it more likely that people will have widely differing ideas as to whether and how such a usage is "appropriate for helping the reader determine context", in the words of the guideline. So maybe this constitutes a special case, and should be treated as such.
On the other hand, maybe this is a non-issue - " foolish consistency [being] the hobgoblin of little minds", and all that. ·· 2A02: talk ·· 13:56, 17 July 2021 (UTC)
Many times when I have doubts about info in an article and there is a citation nearby, I ponder if the reference covers the part of the info I have doubts about. When the ref is easily searchable online, I can verify, which takes time, some times a little sometimes more. And when the ref is a book that is not searchable online, then the doubt persists and I wonder, what info covers the reference? Is it just one word? Is it a phrase, is it a sentence? A paragraph? For example, in the article Jacobo Árbenz, you can find the following: "On one of his visits to Mexico, Árbenz contracted a serious illness, and by the end of 1970 he was very ill. He died soon after. Historians disagree as to the manner of his death: Roberto Garcia Ferreira stated that he died of a heart attack while taking a bath,[140]". What info does the citation 140 covers? That he died of a heart attack while taking a bath? Or does it include the disagreement claim? Or does it include that he died soon after? You may think it is evident that it just covers the heart attack or not, but this is just to illustrate my point.
I think in order to save time for editors and to have more certainty about the info in a page, there should be a system to mark the extent of the coverage of any given specific reference. There could be a tab next to the "view history" tab, where one could see the page with the text of the info within in different colors, marking the extent of the coverage of each reference. The info that is not backed by any reference would just remain without color. Thinker78 ( talk) 18:06, 13 July 2021 (UTC)
One thing that Wikipedia falls short of on commercial encyclopedias such as Encyclopædia Britannica are its illustrations. Almost everyone can write an article, use citations and understand sources, but often illustrations, especially in more niche and complex topic areas require skill to create. Let's look at Encyclopædia Britannica's map of London's West End; vs the only map we have. The dedicated forum for requesting maps is really a hit and miss, a lot of requests go unanswered. It's not just maps, especially in topics such as geography and the sciences, we get poor illustrations. Our diagram for the water cycle (which wasn't even made by a Wikimedian), and Britannica's. Especially at smaller scales the former diagram is too detailed, and contains too much text to read.
Another problem is consistency. On Wikipedia, maps are relatively standardised (by no means 100%) but there are basically no guidelines on other illustrations. No guidelines on the fonts that should be used, the colours, the keys, meaning almost every illustration on Wikipedia shares no conventions, meaning a reader has to repeatedly adapt from style to style.
I don't really know a solid solution to this, I think probably the best would be for WMF to hire professional illustrators, meaning illustrations could be requested, similar to the Art Team on WikiHow. However, whether this is financially viable I do not know. I think a good starting step however would be to set out conventions on Illustrations, and the general style they should follow (even then this doesn't guarantee people will actually follow these guidelines). Standardising fonts, colours, and levels of detail would certainly benefit the project as a whole.
I might be speaking rubbish, or maybe there isn't a problem at all. I just thought it would be useful to get other's opinions on this matter. — Berrely • Talk∕ Contribs 14:40, 17 July 2021 (UTC)
<mapframe>
, which gives interactive maps that are not terrible overall. See {{
OSM Location map}}. For other diagrams, it is super difficult to get the size and level of detail right for all resolutions and screen sizes, especially if you want to use the same image on desktop and mobile. Generally, if you want to try to standardise the font and colour conventions for diagrams, your best shot is to lead by example and create (with a dedicated Wikiproject) a few thousand diagrams using these conventions that are clearly superior to what is currently used, and then people will want to use these and might follow your conventions. Or they might not, if these conventions are at odds with subject-specific ones. —
Kusma (
talk) 20:43, 19 July 2021 (UTC)
<switch>
element. We even have a dedicated tool made by Community Tech,
SVG Translate. It's actually rather good, and much better than manually editing code with a text editor. Sadly, as you noted, even if we have the tools to translate illustrations, it doesn't mean all illustrations are translated, and we have a lot of illustrations that are either only in English, yet used for other projects, or only in another language, and no one has the time to translate them. Not to mention that if a diagram is in a bitmap format such as PNG or JPEG translating it also requires image manipulation knowledge, which many don't have. —
Berrely •
Talk∕
Contribs 08:49, 22 July 2021 (UTC)I hesitate ti say this for fear of being guilty of unleashing a monster when this interacts with other poorly written policies, but illustrations often contain information and statements. In essence creating unsourced OR. North8000 ( talk) 23:32, 19 July 2021 (UTC)
I personally have accepted it as a characteristic of Wikipedia, that because it is free and the contributions are free, and that we can't use copyrighted works (except sometimes with Fair Use), we often don't have the beautiful illustrations that paid/professional media has (we do have one partial work-around, though: Template:External media). On the other hand I am still amazed at the many times we do have good illustrations. I praise your desire to do better and think of ways.
I see only two options: we either go through another phase of expansion (I wish!) in the number of wikipedians (and a small subset of them coming with graphic skills), or we accept the fact that to get good graphic design you have to pay for it at times. A system could be set up where editors propose and upvote on the graphics that need creation, and then the WMF offers some modest funding for someone to create them (either in-house, or gig-economy style). It may not be the most "pure" way of expanding wikipedia, but it may be the more pragmatic one. Just a thought. Al83tito ( talk) 04:24, 24 July 2021 (UTC)
I've noticed a lot of editors forget to use edit summaries. Perhaps we should require edit summaries for edits to the mainspace? -- Firestar464 ( talk) 11:35, 21 July 2021 (UTC)
Not sure where else to post this, but at a recent FAC [14] it was brought up that multiple image templates, which I've used a lot recently, should be avoided because they require that you force a certain pixel size, which is problematic. Is it technically possible to add something like the "upright" parameter that are already used on single images, which scales images relative to particular screens instead? Otherwise it will be hard to use the multiple image templates for articles meant for promotion. FunkMonk ( talk) 11:22, 10 July 2021 (UTC)
Generally, a gallery or cluster of images should not be added so long as there is space for images to be effectively presented adjacent to textsee WP:GALLERY — GhostInTheMachine talk to me 19:02, 10 July 2021 (UTC)
We encourage people to use {{ convert}} so readers can see numerical values in terms that are familiar to them. A laudable goal, but IMHO, poorly implemented. For example, in Mercury-Redstone 3, we've got "His spacecraft reached an altitude of 101.2 nautical miles (116.5 statute miles, 187.5 km) and traveled a downrange distance of 263.1 nautical miles (302.8 statute miles, 487.3 km)" That's not very reader-friendly. It seems to me a better way to do this would be to have a preference people could set "I want metric units" or "I want that bat shit crazy stuff they use in the US". Then, somebody could see "His spacecraft reached an altitude of 187.5 km and traveled a downrange distance of 487.3 km". Or, "His spacecraft reached an altitude of 116.5 miles and traveled a downrange distance of 302.8 miles" for those of use who grew up in an awkward backwater corner of the universe. -- RoySmith (talk) 00:39, 27 July 2021 (UTC)
We have received complaints from readers that Category:Linux distributions is an non-navigable mess and I agree, it is. It has obviously grown up "organically", with people adding random cats over time without rhyme or reason, making it almost impossible penetrate it and actually find comprehensible lists of Linux distros.
There have been several attempts fix this, including:
So, as mentioned, at User:Huggums537's suggestion I am bringing this here for ideas, thoughts and suggestions as to what to do about the remaining sub-categories in this category. Should they be retained, changed, or just left alone?
I duplicate here the category tree that I also posted in the CfD discussion, which diagrams the situation under discussion:
- Ahunt ( talk) 00:34, 28 July 2021 (UTC)
Wikipedia:Manual_of_Style/Biography#Opening_paragraph says the first sentence should include "Context (location, nationality, etc.) for the activities that made the person notable." If the subject was a slave owner should this context be included in the first sentence? ♥ L'Origine du monde ♥ ♥ Talk ♥ 02:07, 13 July 2021 (UTC)
Slave ownership is often mentioned in the lead sentence. See e.g. John Taylor (Baptist preacher) and Robert Ward Johnson. However, the mention is usually "was a planter....". "Planter" strikes me as a euphemism and I think most people won't know what it means. On the other hand, is suppose there is a difference between somebody whose income/livelihood was largely derived from slave labor (a "planter"), and somebody who owned a small number of slaves but earned most of their money through other ventures. Plantdrew ( talk) 19:19, 20 July 2021 (UTC)
Above and other reports from Wikipedia Co founder raise questions over article bias, foreign government fake news etc. How can that be countered?
Is possible to have a pro and con page tab per subject?
With links to each disputed 'fact' so that both the pro and con view can be read by reader?
How can Wikipedia measure or show the validity or support for each point of view?
Can links to alternate points of view be included in a semi permanent way? So that biased editors are forced to acknowledge alternative narratives?
At least it might at least show on Wikipedia that entry views are 1) indispute Or 2) minority views — Preceding unsigned comment added by Ro mona lisa ( talk • contribs) 14:55, 1 August 2021 (UTC)
I really don't understand the A-Class article ranking. I can't remember the last time I came across one. Does it even really serve a purpose? ~ HAL 333 20:41, 3 August 2021 (UTC)
I feel like this is something uncontentious as flat icons are being used all across the modern web. But still I want to build this proposal so that it is something that can reasonably be implemented.
I built a list at User:Awesome Aasim/Flat design idea - Wikipedia and @ Arsonxists continued expanding that list at User:Arsonxists/Flat Icons - Wikipedia. I feel like it would be a waste of time to get community input on something uncontentious, but I still want to figure out if there is a way that we can transition to flat icons and if there is someone willing to implement this idea. Aasim ( talk) 21:45, 3 August 2021 (UTC)
I do not think this question is ripe for an RFC. I see no recent discussion and I certainly see no major significant dispute needing resolution. I see a lot of "we should do this" but not a lot of "here's my solution".This is the drawing board, this is the place to figure out how the proposal should be done before it is proposed again via RFC. Aasim ( talk) 09:00, 4 August 2021 (UTC)
Maybe we should take a different approach. What happened to readers' input? After all, readers are the ones who are using Wikipedia, we are modifying it: WP:CREEP strikes again. User:Berrely made a good point: We don't know much about our readers. Maybe our readers are Gen Z teenagers. Maybe our readers are scientists who understand jargon. What do we know?
Is there some way we can poll our readers to see what they want? If this has been tried before, don't heckle me, come up with a better solution. Sungodtemple ( talk) 14:30, 5 August 2021 (UTC)
If you use Wikipedia to stay informed about current politics and elections, you will be used to articles of politicians being filled with sections about their political positions. Such sections are often divided into sub-sections about specific issues and may become very long. It seems that editors will indiscriminately add a politician's statement about their political position as long as there is RS (usually news) to substantiate it. I have noticed this problem in the English-speaking countries of the US, the UK, Canada, and Australia, and it may extend to virtually every democratic country. It also extends beyond government officials, elected or unelected, to political commentators and others who are involved in politics.
Political positions bloat is unencyclopedic, excessive detail, recentism, and cruft. Remember that Wikipedia articles are summaries of their topics, not treatises, not essays, not voter guides. While politicians generate a lot of media coverage (which would be considered routine coverage in the terms of our notability guides), we do not consider every detail mention-worthy, unless it happens to be a political position. Why would we include a low-profile comment someone says about, say, marijuana, but not if they own a dog? Both will not be remembered in the long term.
The salience of political issues constantly changes, and politicians will become known for a few accomplishments or ideological opinions. Lists of political positions will not pass the 10-year test, but summaries and generalizations will. We should not include such lists for pre-21st century politicians because we are aware of what they are notable for and what is a side detail. Indeed, we find sections discussing the political positions of dead politicians, though they are not bloated with details of minor political issues. In reality, that is because the Internet and the existence of Wikipedia have enabled the expansion of lists in gradual steps. One may object that we do not know which political positions are relevant. But even without the certainty of scholarship, we should recognize what is noteworthy based on how much attention some position has garnered in RS, just as we recognize which details of personal life are notable and which are not. It is especially useful when a source explicitly states that someone is known for something.
I propose a link-able essay written on this issue ( Wikipedia:Political positions, WP:POLPOS as a link?) and hope that we can soon cut down on political views sections. WIKINIGHTS talk 13:19, 9 August 2021 (UTC)
There are people who find certain images on Wikipedia offensive or disturbing. It should be possible for those viewers to access the text of an article without being forced to view the images. There is community consensus that offensive or disturbing images shouldn't be censored. At the same time one fundamental goal of Wikipedia is to make information accessible for everyone. If the graphic nature of certain (e.g. medical) images shocks some users, the information on that page is in effect no accessible to those persons. In those cases, those images work against one of the fundamental goals of Wikipedia. I therefore propose that sensitive images are hidden by default, and can be displayed with a single click. If no consensus can be reached which images should be considered offensive or disturbing, I propose that all images are hidden – and not loaded – be default. This will have the additional effect of making both mobile browsing for users and hosting of Wikipedia cheaper.— Preceding unsigned comment added by 2003:df:972b:fc52:bc41:2309:e4d1:9069 ( talk • contribs) 07:40, 3 August 2021 (UTC)
Idle thought: {{ uw-van1}} etc really ought to link to a specific diff when they can. Enterprisey ( talk!) 07:46, 10 August 2021 (UTC)
Are there any tools that can automatically find and display sections that used to be in an article but have since been deleted?
I think this might unfortunately be the most insidious form of vandalism. Disinformation isn't terribly hard to spot, verify, and remove, but sourced material that has been removed can't be seen again unless you go digging through the page's history for some reason. Intralexical ( talk) 15:42, 11 August 2021 (UTC)
Hello,
I have been spending some time in the sandbox of Template:AFD help, trying to fix some problems I perceive with it:
Below are some possible redesigns, transcluded from Template:AFD help/testcases:
Possible redesigns of Template:AFD help
|
---|
Current live code [Hide this box] New to Articles for deletion (AfD)? Read these primers! Sandbox code |
Any feedback is appreciated. Also, please feel free to suggest other possible designs. Regards, DesertPipeline ( talk) 05:38, 15 August 2021 (UTC)
Please add a subsection with four equal signs below all other subsections in this section with your comments. |
This idea/proposal is fundamentally flawed and is based on several misconceptions.
Example 1 (
Live sandbox, since it changes all the time); Original
Wikipedia:Articles for deletion/Daniel Carver (3rd nomination)
|
---|
The following discussion is an archived debate of the proposed deletion of the article below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page. The result was no consensus. Sandstein 06:33, 1 July 2018 (UTC) [Hide this box] New to Articles for Deletion (AfD)? Read these primers! AfDs for this article:
Daniel Carver ( | talk | history | protect | delete | links | watch | logs | views) – ( View log · Stats) (Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL) Doesn't seem to satisfy WP:GNG. Ambrosiaster ( talk) 17:56, 1 June 2018 (UTC)
Note: This discussion has been included in the list of People-related deletion discussions. MT Train Talk 07:58, 2 June 2018 (UTC)
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, North America 1000 07:13, 9 June 2018 (UTC)
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Sandstein 18:28, 16 June 2018 (UTC)
Relisted to generate a more thorough discussion and clearer consensus.
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's
talk page or in a
deletion review). No further edits should be made to this page.Please add new comments below this notice. Thanks, Enigma msg 05:09, 24 June 2018 (UTC) |
Example 2; Original
Wikipedia:Articles for deletion/Daniel Carver (3rd nomination)
| ||
---|---|---|
The following discussion is an archived debate of the proposed deletion of the article below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page. The result was no consensus. Sandstein 06:33, 1 July 2018 (UTC) AfDs for this article:
Daniel Carver ( | talk | history | protect | delete | links | watch | logs | views) – ( View log · Stats) (Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL) Doesn't seem to satisfy WP:GNG. Ambrosiaster ( talk) 17:56, 1 June 2018 (UTC)
Note: This discussion has been included in the list of People-related deletion discussions. MT Train Talk 07:58, 2 June 2018 (UTC)
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, North America 1000 07:13, 9 June 2018 (UTC)
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Sandstein 18:28, 16 June 2018 (UTC)
Relisted to generate a more thorough discussion and clearer consensus.
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's
talk page or in a
deletion review). No further edits should be made to this page.Please add new comments below this notice. Thanks, Enigma msg 05:09, 24 June 2018 (UTC) |
This is bike-shedding at its finest. Headbomb { t · c · p · b} 06:42, 15 August 2021 (UTC)
explicitly cause a mismatch between the two boxes. That is the intent; they aren't related boxes. Putting the help links elsewhere allows us to make the previous AfDs box a dynamic size, avoiding a load of whitespace which would occur if the links inside that box aren't as long as the box itself. DesertPipeline ( talk) 07:04, 15 August 2021 (UTC)
Changing the width of one box without changing the width of the other box will cause a mismatch in width between the box, and that's also bad design.
Here are the same screenshots:
Headbomb { t · c · p · b} 07:42, 15 August 2021 (UTC)
You could in theory design something that's used on a go forward basis, but you'd need to redesign the AFD link box, the AFD help box, both should line up and be of equal width, then redesign the AFD workflows to make use of them. And then you'd need an RFC to roll out the changes. You cannot do so simply by editing {{ AFD help}}, you need new templates entirely, and then redesign AFD around those new templates.
Apologies if this is the wrong place, willing to move this question if this is the case. Is there any bot currently on the English Wikipedia which creates articles unassisted? And would such a bot be allowed in the future if this isn't the case? By articles I don't mean redirects, or disambiguations. Note that this is not me making a bot request but instead just asking out of curiosity. Cheers, Rubbish computer Ping me or leave a message on my talk page 18:21, 16 August 2021 (UTC)
Thank you both, will read more about it at the links provided. Rubbish computer Ping me or leave a message on my talk page 18:34, 16 August 2021 (UTC)
Xaosflux I didn't realise ruwikinews did that, sounds like a mess. Rubbish computer Ping me or leave a message on my talk page 18:36, 16 August 2021 (UTC)
They are copying verbatim professionally written news articles that were placed into Creative Commons after the Putin regime forced the closure of this newspaper as it was critical of the regime. This might have unintended results since anyone including pro-Putin elements can now edit those articles requiring constant vigilance to monitor millions of articles. A read-only archive might have been better. -- Green C 19:35, 16 August 2021 (UTC)
Earlier today I stumbled upon a help request from a user asking for suppression of the IP associated with an edit they made while accidentally logged out. The request didn't include a diff of the problematic edit ( duh), but since such requests are routinely granted, I thought someone at #revdel would be able to CU the user and find the edit in question. To my surprise, this couldn't be done because our current CU policy precludes such checks.
I believe that adding an exception to our CU policy that would allow Oversighters who are also CUs to use the CU tool to expedite the handling of incomplete suppression requests would be an improvement on the current situation in which the requester is needlessly required to supply the missing information before their request can be actioned.
The global CU policy allows individual wikis a degree of latitude in handling self-requested checks; I believe that filing an OS request (regardless of its form) such that it requires user IP information to handle can be regarded as such a request and so the exception would be in keeping with the global policy. An argument could be made that such a check might reveal more than the user wanted us to know but this is always the case with self-requested checks and doesn't clash with the long-standing practice of allowing such, globally speaking (enwiki currently disallows self-requested IP checks wholesale).
I'd imagine that the typical profile of a person that inadvertently reveals their IP while logged out is that of a careless new editor. Such are notorious for being difficult to reach when a follow-up is needed which means their perfectly valid OS requests may end up rejected, or significantly delayed, due to purely bureaucratic hurdles. That sounds to me like a situation that could and should be improved upon regardless of how often this actually happens.
My proposed policy amendment would roughly look something like this:
As oversight requests are often time-sensitive, oversighters who are also checkusers are permitted to perform CU checks to expedite the processing of incomplete suppression requests. Information obtained through such checks may be used only for that specific purpose, and must not be shared; it also must not be retained, or even accessed, by the oversighter any longer than absolutely necessary for the handling of the request.
Is this something worth proposing at VPP? I'd appreciate some feedback. 78.28.44.31 ( talk) 05:57, 26 July 2021 (UTC)
I use a gadget in my preferences that shows blocked users with a strike through their username on talk pages and page histories. However, anything from a decade ago, for example, has quite a lot of strikethroughs. Some of the users are LTAs, trolls, and whatnot, but a lot are either deceased or retired or just abandoned. I was wondering if there could be some kind of difference in a perma-ban block & a deceased block, etc. Also, at ANI a 24-hr block appears the same as an indef. Maybe a perma-ban could have double strike throughs, a deceased block could be a different color, etc. Thoughts? Rgrds. -- Bison X ( talk) 15:55, 15 August 2021 (UTC)
Sometimes when an image becomes the subject of discussion, discussion takes place both on en-Wikipedia and on Commons. However, most images are hosted on Commons, you can't directly edit or replace the image on en-Wikipedia etc. so image talk page on en-Wikipedia probably shouldn't be used unless any discussion relates only and specifically to en-Wikipedia.
I propose that soft redirects to Commons talk pages on all pictures be added automatically.
An alternative is to add tags like Discussed on sister project
or talk at enwp
to en-Wikipedia file discussion pages, like is used here:
https://commons.wikimedia.org/wiki/File_talk:RGB_3bits_palette_sample_image.png but I think that tag is specific to Commons.
(Why am I proposing this? I recently updated in the seating diagram of the US Senate, and found it cumbersome getting consensus both at Talk:United States Senate and c:File Talk:117th United States Senate.svg. I ended up adding a soft redirect at File Talk:117th United States Senate.svg lest discussion began in a 3rd location.)
Egroeg5 ( talk) 02:50, 22 August 2021 (UTC)
Was there a previous discussion on whether categories should or should not be transcluded from templates? For example, {{
Kerala State Award for Best Actress}}
could potentially transclude
Category:Kerala State Film Award winners onto the articles. That would make categorization of the articles a little easy, by removing the manual need of adding cats to articles. Surely, it would also put the
Kerala State Film Award for Best Actress article into the category. To counter these unwanted, a |cat=no
parameter could be introduced to templates to not allow not transcluding the cats. I updated {{
NSE}}
and {{
BSE}}
to include the respective cats, and wondering if I acted too quickly. Thoughts around these?
-- DaxServer (
talk) 13:00, 22 August 2021 (UTC)
{{
Infobox film}}
-- DaxServer (
talk) 13:09, 22 August 2021 (UTC)
There are about ~88,000 files under the
Category:Non-free posters which will benefit from moving to sub-categories. Depending upon the article where the file is used, it could be moved. This way the huge cat could be diffused. The category can be set in the {{
Non-free poster}}
as the first unnamed parameter. This ideally could be done by a bot.
One straight forward action is for movie posters which are used only once on the respective movie articles. The {{
Infobox film}}
transcludes appropriate language category from
Category:Films by language. There are not that many sub-categories by language in the Non-free posters category. My proposal is to create those categories under
Category:Fair use images of film posters (under appropriate country), and assign the posters based on the Infobox transcluded category intersecting
Category:Films by country on the article. In case of multi-lingual films, [I'm not sure if it transcludes all categories for multi-lingual films], the first category that one encounters would be put in the {{
Non-free poster}}
template and the second category would be added as a normal category.
Categories other than films could also be handled accordingly, or be left out for a follow-up work. Surely, a con that I see is the mis-categorization of the main article, (either due to unchecked vandalism, or some other reason,) resulting in the mis-categorization of the poster. The bot could also regularly check and re-categorize, or post a message for a manual check. Opinions and thoughts around this? -- DaxServer ( talk) 12:09, 23 August 2021 (UTC)
Imagine you’ve just spent 27 minutes working on what you earnestly thought would be a helpful edit to your favorite article. You click that bright blue “Publish changes” button for the very first time, and you see your edit go live! Weeee! But 52 seconds later, you refresh the page and discover that your edit has been reverted and wiped off the planet.
An AI system - called ORES - has been contributing to this rapid judgement of hundreds of thousands of editors’ work on Wikipedia. ORES is a Machine Learning (ML) system that automatically predicts edit and article quality to support content moderation and vandalism fighting on Wikipedia. For example, when you go to RecentChanges, you can see whether an edit is flagged as damaging and should be reviewed. This is based on the ORES predictions. RecentChanges even allows you to change the sensitivity of the algorithm to "Very Likely Have Problems (flags fewer edits)" or "May Have Problems (flags more edits)”.
In this discussion post, we want to invite you to discuss the following *THREE potential ORES models* -- Among those three models, which one do you think presents the best outcomes and would recommend for the English Wikipedia community to use? Why?
ABOUT US: We are a group of Human–computer interaction researchers at Carnegie Mellon University and we are inviting editors to discuss the trade-offs in AI-supported content moderation systems like ORES; your input here has the potential to enhance the transparency and community agency of the design and deployment of AI-based systems on Wikipedia. We will share the results of the discussion with the ML platform team which is responsible for maintaining the ORES infrastructure. However, the decisions of the discussion are not promised to be implemented. More details are available at our research meta-pages: Facilitating Public Deliberation of Algorithmic Decisions and Applying Value-Sensitive Algorithm Design to ORES.
Group / Metrics | Accuracy Percentage of edits that are correctly predicted
|
Damaging Rate Percentage of edits that are identified as damaging
|
False Positive Rate Percentage of good edits that are falsely
identified as damaging |
False Negative Rate Percentage of damaging edits that are
falsely identified as good |
---|---|---|---|---|
Overall | 98.5% | 3.4% | 0.5% | 26.3% |
Experienced | 99.7% | 0.2% | 0.0% | 61.2% |
Newcomer | 95.7% | 10.7% | 1.8% | 23.0% |
Anonymous | 94.8% | 12.7% | 2.4% | 22.8% |
Group / Metrics | Accuracy Percentage of edits that are correctly predicted
|
Damaging Rate Percentage of edits that are identified as damaging
|
False Positive Rate Percentage of good edits that are falsely
identified as damaging |
False Negative Rate Percentage of damaging edits that are
falsely identified as good |
---|---|---|---|---|
Overall | 97.2% | 1.2% | 0.1% | 69.9% |
Experienced | 99.6% | 0.0% | 0.0% | 94.0% |
Newcomer | 91.2% | 4.4% | 0.8% | 68.5% |
Anonymous | 90.7% | 4.5% | 0.0% | 67.2% |
Group / Metrics | Accuracy Percentage of edits that are correctly predicted
|
Damaging Rate Percentage of edits that are identified as damaging
|
False Positive Rate Percentage of good edits that are falsely
identified as damaging |
False Negative Rate Percentage of damaging edits that are
falsely identified as good |
---|---|---|---|---|
Overall | 96.1% | 7.6% | 4.0% | 2.4% |
Experienced | 99.9% | 0.4% | 0.0% | 17.9% |
Newcomer | 91.8% | 19.8% | 9.1% | 1.0% |
Anonymous | 82.7% | 30.8% | 19.9% | 0.8% |
If you are not satisfied with any of the models described above, you can try out this interface, pick a model on your own, and share your chosen model card in the discussion by copying and pasting the wikitext offered in the interface.
Bobo.03 ( talk) 15:32, 20 August 2021 (UTC)
Hi @ Bobo.03: I'm sure this has come along since my very early engagement with it. I know you are well-aware of CluebotNG, but I'd like to draw a highlight that although it once accepted a false positive rate of 0.25%, it has been changed to use 0.1% as its threshold. That hit 55% and 40% of vandalism (thus 45% and 60% false negative). That, I think, gives a pretty clear marker that Wikipedians are way more willing to accept it missing something than an unwarranted hit. Unwarranted hits kill off new users, and irk experienced users, while many issues missed can be caught by alternate means. I tried to have a fiddle with the interface but couldn't figure out how to make it apply different tolerable false positive rates to different groups. Nosebagbear ( talk) 20:43, 20 August 2021 (UTC)
Hello! So I have an idea of being able to add pages to your watchlist by simply putting the name of the article/page into a text box and it will add that article/page into your watchlist instead of having to go to individual pages and clicking on the star to add it on to the watch list. Not sure if this is already something that's been mentioned or if it's even possible because I don't know how to write code that makes Wikipedia work. Blaze The Wolf | Proud Furry and Wikipedia Editor ( talk) 13:53, 20 August 2021 (UTC)
Hi guys! Please consider my Idea. The mobile view doesn't have easy access to the preferences, so I was just thinking if there was a way to change that? Twilight Sparkle 222 ( talk) 22:12, 16 August 2021 (UTC)
Hello! I have a feeling I already proposed this idea but i can't remember. Anyways, my idea is the ability to add a short message to your thanks. Yes WikiLove exists, however if someone does something small and you'd like to show your appreciation, I'd find that WikiLove would be a bit overkill. For example, on my talk page, ferret fixed a WikiLove another editor gave me as when I replied to the WikiLove, it was part of the WikiLove and I attempted to fix it myself but couldn't and ferret fixed it for me. I thanked them and would've liked to leave a short little message saying something like, "Thanks for fixing the WikiLove" however I don't necessarily think something like that would be fit for a WikiLove message. Blaze The Wolf | Proud Furry and Wikipedia Editor ( talk) 16:23, 23 August 2021 (UTC)
I propose making a space for editors to openly discuss and recommend candidates in Wikimedia elections. Wikimedia is the parent organization of Wikipedia and as such takes important decisions that affect Wikipedia, therefore it is my belief that it is important for editors to discuss Wikimedia elections, candidates, make recommendations of candidates to vote for and have a space in Wikipedia for such discussions, without running afoul of rules like WP:CANVASS. Thinker78 ( talk) 01:03, 26 August 2021 (UTC)
I'm interested in getting feedback for a feature I've been working on as a hobby. I have working code but it is alpha-quality.
Many people do not trust quotations in the media because they are suspicious that the quote may be taken out of context or fabricated.
I've been developing an open-source app that:
* given a quotation which is attributed with a URL, * looks up the quote context using a Python Webservice and saves the contextual data to a JSON file * displays the context to the reader using javascript to render contextual popups or expanding blockquotes
* I propose that Wikipedia explore "upgrading" those quotations that are attributed to a web source to CiteIt-style contextual citations.
The Benefit of using Contextual Citations is that readers:
* learn more about the context of quotes * gain trust in the integrity of the citation and verify that a quote wasn't fabricated or cherry-picked.
You can view a video and demo on my project website:
* View Demo
I've outlined some of the steps to implementing this on my Wikipedia User page:
* https://meta.wikimedia.org/wiki/User:Timlangeman/sandbox
* All code is published on GitHub and licensed under the open-source MIT License
P.S. I'm new to the Wikipedia culture, so feel free to point out the correct Wikipedia way.
Timlangeman ( talk) 03:05, 24 July 2021 (UTC)
Hi Timlangeman, thank you for your neat idea and having the tech chops to develop the code! From seeing how it works in the demonstration video, I can see this implemented in one of two ways: just as you show it, by making the quote itself clickable to bring up the contextual pop-up box, or, have this feature imbedded in the corresponding in-line citation. The question is: would this feature be used so often by readers to be it worth to make the main text clickable? Or should we minimize the "noise" in the text by having this feature a bit more discretely included within the reference? Food for thought. Thanks! Al83tito ( talk) 05:35, 24 July 2021 (UTC)
Hi Al83tito, I'm open to UI suggestions and I'd be happy for others to experiment with UI ideas too.
As far as the amount of link "noise", this can be handled in different ways:
I don't know if you saw the 8 sample articles that I mocked up?
* 8 Sample Wikipedia Articles
These should provide good samples for programmers and designers to experiment with.
I packaged these files up into a Git repository for anyone that has UI skills and wants to experiment with different UI options.
* https://github.com/CiteIt/wikipedia-samples
If you don't have programming skills, I can create mockups based on your suggestions.
Timlangeman ( talk) 14:48, 24 July 2021 (UTC)
I like the general idea. I do have one issue however... Wikipedia generally doesn't have many direction citations. This is because of the copyright nature of Wikipedia and because it is a tertiary source. We intentionally 'transform' and 'rewrite' points from 1st and 2ndary sources most of the time and then use references. I see that as a bit of a problem for the success of this particular tool. Do you have thoughts on that ? — TheDJ ( talk • contribs) 09:05, 3 August 2021 (UTC)
This is a copyright nightmare. Even the image used to demonstrate this ( [22]) is probably not acceptable, as it has a way too long quote of copyrighted text. We instruct editors to make their quotes as short as possible (if the text is copyrighted, and if they can't avoid using quotes altogether): to then add a tool that shows much longer quotes simply contradicts this. For public domain sources, fine, but for copyrighted texts, I don't think this will be acceptable. Fram ( talk) 09:24, 3 August 2021 (UTC)
@ Fram and @ TheDJ, I did a little bit more research and consulted with @ LWyatt, who has a Master's degree in Intellectual Property law.
Fram is correct that copyright can be a nightmare in many countries.
I asked LWyatt why the Internet Archive is able to publish complete archived documents. He said that this is due to the US's fair use laws. LWyatt said that just as fair use laws in the US allow the Internet Archive to host archives of complete documents, fair use would allow the US Wikipedia to publish CiteIt's contextual snippets, but only for the US version hosted in the US.
This means that to start with at least, CiteIt's Contextual Citations would have to be restricted to the US English site.
Do people have additional feedback on other isssues, such as the user interface or the general idea? Timlangeman ( talk) 13:31, 27 August 2021 (UTC)
If copyright issues are a barrier to contextual citations, I'm wondering what people think about using Google Text Fragments in linking to citations to help the reader more easily inspect the context of the quote. I've written up a summary aggregating some information about them:
* Using Google Text Fragments to Link to Specific Text
I know that there are issues with browser support and privacy. At this point, I'm mainly trying to seek what people think about them in principle. Timlangeman ( talk) 21:47, 5 August 2021 (UTC)
Greetings
Requesting (brainstorming) inputs regarding Manual of Style proposal @ Chronological listing of coastal townships
Thanks and warm regards
Bookku, 'Encyclopedias = expanding information & knowledge' ( talk) 06:38, 29 August 2021 (UTC)
There is a longstanding problem with transcluded refs and notes -- their name and group parameters sometimes collide with names/groups in the transcluding article or names/groups from other transclusions. I've made suggestions about this elsewhere in the past (some good and some hare-brained), but none of those have gone anywhere. Another approach occurred to me this morning. I'm wondering whether en editor-discoverable short unique article identifier (effectively an article-ID) which remains stable through article renamings/page-moves. If there is such a thing, or if it is easily implementable within WP,, that identifier could be incorporated by editorial convention into the name and group parameters of refs and notes subject to transclusion. This was prompted by what appears to be an instance of this problem which I fixed with a workaround in this edit. Wtmitchell (talk) (earlier Boracay Bill) 12:35, 29 August 2021 (UTC)
There are 2 problems that creating Wikidata items for Files on Wikipedias could solve:
Example of benefits:
To implement this, all we would need to do is:
Wikidata already supports Files as sitelinks, so no new development is needed to implement this (unless allowing 2 datatypes for a property might be an issue).
Thoughts? Lectrician1 ( talk) 22:57, 28 August 2021 (UTC)
In scientific works quotations are used to directly quote another piece of literature; a source citation is usually provided directly after the quote. On Wikipedia, citations are required, but I find that text taken from a source can be broken through editing quite easily. For example, if someone provides "including the sum of all virtual worlds, augmented reality, and the Internet" and a source, someone can just delete "augmented reality", leaving a perhaps incorrect statement "including the sum of all virtual worlds and the Internet".
I understand that Wikipedia does not want lots of quoted pieces of text. I would like to suggest a markup tag that provides similar functionality internally, but with no visible changes on the rendered page. If I'm not mistaken the <ref/> tag is always used without text, except the citation e.g., <ref>{{citation}}</ref>.
Instead of providing something like:
I would suggest:
or a new nested tag:
To the person editing it immediately provides a visual cue of which text comes from a particular reference. On the "Related changes" and history page a visible symbol could warn when an edit happens within a quote of text without the source being updated or when a quote is deleted entirely. Editors can then know when the source needs to be checked to verify the edit was correct.-- K.Nevelsteen ( talk) 07:14, 27 August 2021 (UTC)
Inspiration:
I commonly create music release items on Wikidata for artists who may not be popular enough to have an article for every release or song they release. These releases are mentioned on their artist or discography pages, however they have no link to the Wikidata item that exists for release.
This clearly has some disadvantages:
Proposal:
Create a template called "Existing Wikidata link" that displays an orange (or another color) link to the Wikidata item of a term for logged-in users (editors). No link displays for non-logged-in users and the text looks normal. This functions similarly to how the Wikidata edit button on templates that support Wikidata shows up only for editors.
This link will be used exactly as blue links currently are. The first mention of a relevant term on an article deserves a link.
Example:
A.C.E (South_Korean_band)#2021–present: New_agency, Siren: Dawn and Changer: Dear Eris mentions the album "Changer : Dear Eris". This release does not have an article, so it is not linked.
I created an item for this release: Changer : Dear Eris (Q108291790)
I replace the text on the article with: {{Existing Wikidata link|Q108291790}}
The text then turns orange and becomes a link to the item.
The text for the link can be automatically drawn from the label of the item or be specified as the second argument for the template.
Going further:
A link could be created for every repeated thing mentioned on a Wikipedia article.
This clearly would make source-editing articles a nightmare, however it could serve an important purpose.
Wikidata is a subset of the Semantic Web movement. One of the goals of the semantic web is to link all things on all webpages. By linking everything on an article, Wikipedia could help this movement and provide computer-interpretable contextualization for all content on all Wikpedia articles.
I'm mentioning this because it's something to think about.
When the Visual Editor eventually becomes usable for all editing actions, specific links could be implemented for all things mentioned in an article. The source text could become a convoluted system of links for all things mentioned, but not disrupt the editing of the user utilizing the Visual Editor which would provide a usable user interface to work with the links.
Additionally, AI in the future could assist in the linking of text in articles.
Feedback:
Let me know what you think of both the main proposal (which is intended to be implemented) and the future-thinking ideas of linking everything (which is not intended to be implemented at the moment). Lectrician1 ( talk) 00:47, 29 August 2021 (UTC)
Wikipedia has a lot of queues. Two disparate examples: WP:AFC/R and WP:PERM. What if we made them all use the same technology? I have a vision. If you write a JSON page that has the following information:
You should get:
Problems this solves:
Queues this could apply to, off the top of my head: DRN, BRFA, PERM, AFC/R (probably more)
Anyway, if anyone wants to help out, let me know here. This might be a bit of a heavy lift, but I'm sure it's worth it, and I know a thing or two about graceful and peaceful transitions of Wikipedia processes to newer technology.
Enterprisey (
talk!) 07:10, 11 August 2021 (UTC)
Enterprisey, part of User:Alexis Jazz/LuckyRename is more or less a library. (getToken() gets an edit token, getArticletext('Main Page') gets raw page text, that sort of thing) Editing ( doAPICall() ) isn't a proper separate function atm, though I plan to change that. Not sure you could use any of it in its current state, but I hope creating a user script can eventually be made as simple as, say:
userscriptID = 'myVoteScript'; $( '.mw-content-text' ).append('<div id="userscriptID"></div>'); // would attach to the bottom of the page addvote = function(yourvote) { pagename=mw.config.get('wgPageName'); voted = editpage(pagename, yourvote, 'append'); if ( voted.edit.result == 'Success' ) { $( userscriptID ).append('<br \>You voted!'); location.reload() } else { $( userscriptID ).append('<br \>Squirrels intercepted your vote. Whatcha gonna do?') } } $( userscriptID ).append('Vote something?<br \>'); addButton(userscriptID, 'supportButton', 'Yay support!'); addButton(userscriptID, 'opposeButton', 'Boo! Boo!'); buttons.supportButton.on( 'click', function() { addvote('* \'\'\'Support\'\'\' ~~~~') }); buttons.opposeButton.on( 'click', function() { addvote('* \'\'\'NO NEVER\'\'\' ~~~~') });
But this is largely a rough idea at this point. Not sure it'll even help here, but perhaps it could attract more coders if creating a user script was simpler. Edit: Now that I think about it, this is simplifying on a lower level. The gadget you envision could partially be made using something like this, but wouldn't have to be. Your idea is pretty clever. Shouldn't even be that hard to create. (though the 80/20 rule applies, 80% can be written in 20% of the time) — Alexis Jazz ( talk or ping me) 22:36, 31 August 2021 (UTC)
A VPR discussion closed about three months ago eeked out a consensus to experiment with a new look for Template:Authority control, but it wasn't super clear even at the time what exactly the community wanted that look to be. The new design has resulted in effectively the authority control turning from a one-line bar into a navbox, which is a major expansion, and the general sense I have is that this isn't what the community signed up for. How long do we have to live with this version of authority control before it's either improved to something tolerable or rolled back? I'd encourage a little bit of discussion here, but if improvements are not forthcoming, I'd like to soon see a more formal referendum at VPR that'll carry the possibility of action. {{u| Sdkb}} talk 00:19, 4 September 2021 (UTC)
I have come across a situation when I am checking edits in my watchlist. I for example see the last minor edit of someone and then I don't bother and keep going through the list. But behind that edit in the article's history may be a number of consecutive edits that I would like to take a look, but I didn't because I thought it was a single minor edit the editor made. As a solution, an idea is to add the number of consecutive edits next to the number indicating the size of the edit in bytes. I think this would help editors be more engaged in their patrolling by not missing consecutive edits that may be of interest to them, which oftentimes are overlooked because in the watchlist one assumes there was only one little edit made. It would also help save time by giving the editor some info that currently is obtained by clicking on the page history to see namely the number of consecutive edits by an editor. Thinker78 ( talk) 00:08, 22 August 2021 (UTC)
(3 changes | history)
. No doubt the WMF code for watchlists is incredibly convoluted and any change will be a pain, but the proof of concept is there. This would make no difference to me personally, but I see the use case for others (I aim to review every edit that pops up in my watchlist, and try to keep my watchlist as small as possible for that reason). —
Bilorv (
talk) 21:49, 28 August 2021 (UTC)
When an individual edit is made to an individual article, it's trivial at that point to determine if that edit is the first, second, fifth, or seventeenth consecutive edit from that user.Actually, that's an assumption on my part. It's certainly much more likely to be doable in the context of performing the edit, than trying to assemble the info after-the-fact during watchlist processing, but even at edit time it would still require examining the nearby edit history for the article. But without knowing far more about the inner workings of the system, the only statements I can make about its difficulty are ignorant ones. That being said, tags already exist for things like "Non-autoconfirmed user rapidly reverting edits" and "repeated addition of external links by non-autoconfirmed user", and that fact alone tells me that taking surrounding context into account when tagging edits is far from impossible. -- 21:56, 5 September 2021 (UTC)
We've got IP range blocks, but when the ranges get wide, the collateral cost becomes prohibitive. So, how about browser-specific range blocks? You could block a wide (/18 or more) range, and specify that it only applies to a specific client string. I could see two ways to implement this. One for use by CUs, where you explicitly specify the client string (or perhaps, a pattern). The other would be a "block by example" version that any non-CU admin could use by supplying a specific edit and it would block whatever client was used to perform that edit without revealing the actual client to the blocking admin.
I'm working on a WP:Sockpuppet investigations/Rgalo10 where we'd need to block three different /18s to be effective. That's unlikely to happen, but blocking those 3x/18 in combination with a client string would be much more attractive.
Yeah, I know, people upgrade their browser. People switch browsers. People use browser-obscuring proxies. It's not perfect, but it would still be a good tool. -- RoySmith (talk) 22:13, 2 September 2021 (UTC)
People use browser-obscuring proxies.Well, you don't even need a proxy. You just need to modify the
user-agent
header, which is trivial.
ProcrastinatingReader (
talk) 22:16, 2 September 2021 (UTC)
:-p
When the blocking admin has no idea what they are blocking in the first place, they may block something very commonthis happens now on almost every user block. If the "Autoblock any IP addresses used" option is selected (which it is by default), you block IP addresses without even knowing what they are. -- RoySmith (talk) 23:03, 15 September 2021 (UTC)
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)
.mw-echo-ui-notificationsInboxWidget-sidebar {display:block;}
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)
{{
asbox}}
. --
Redrose64 🌹 (
talk) 08:59, 21 September 2021 (UTC)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)
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)
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)
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:
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)
{{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}}
This experiment concludes that water is wet
{{
cite episode}}
: CS1 maint: numeric names: authors list (
link)
{{
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)
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)
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 TalkBlaze Wolf#0001 19:41, 22 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)
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)