Wikipedia talk:Reliable sources/Perennial sources

Sticky header user interface community input

There has been an initiative to change the interface so that the gray header at the top of the table "follows around" as you scroll down. See: {{sticky header}}. Which of the choices below (A-E) do you prefer? What other ideas do you have?

The header is now 2 lines tall. What Timeshifter is now proposing (scroll down this example) is a narrow one-line sticky header with a link from the "Status" column head back to the "Legend" section of the article. And a link from the "Sources" column head back to the "Sources" section of the article. Notes explain this just above the table. He states this allows new users of the table to quickly return to the table TOC, or to quickly find the meaning of the legend icons. There are also improved notes above the table.

An issue in any skin other than the default Vector 2022: When you use the horizontal table TOC, or if you follow ("jump to") an anchored link within the table such as WP:FORBESCON, the top line of the note in the row you jump to would be covered by the narrow sticky header. 2 lines are covered by the 2-line header. Template discussions have not found a way to fix this. Timeshifter does not believe this is a serious problem. Others do. One solution (see E below) is to add a line's worth of blank padding at the top of each row.

• A: No sticky header, same style (2-line) header as before.
• B: Full size (2-line) header with sticky enabled.
• C: Narrow (1-line) header without sticky enabled.
• D: Narrow header with sticky header that follows you around. This has been improved. Please check again.
• E: Same as D, but with padding at the top of each row.

Graywalls (talk) 15:04, 30 October 2024 (UTC). Edited per WP:RFCNEUTRAL by Timeshifter (talk) 11:46, 3 November 2024 (UTC).

Another shortcut (for Forbes.com contributors) with the improved narrow-header version of the sticky table:

https://en.wikipedia.org/w/index.php?title=Wikipedia:Reliable_sources/Perennial_sources&oldid=1260153539#Forbes.com_contributors

The benefits of having the sticky header far outweigh the small inconvenience for the relatively few people using Vector 2010 of having to scroll up a tiny bit to see one line of missing text at the top of the notes column. They can see everything else in the Forbes.com row.

By the way, your history is off. The {{sticky header}} was up without complaints for over 2 months (since Aug 21, 2024) after I changed from {{sticky table start}} and did my final tweak. See Aug 21, 2024 version.

Recently, there were changes by the template editor that messed up the colors, but those have been fixed.

--Timeshifter (talk) 15:38, 30 October 2024 (UTC)

"This template is used on approximately 4,400 pages" sums up the use of the sticky banner. How does it look on mobile? Why reinvent the wheel here when the people shifting through the table know what the columns represent. Also, it's a Wikipedia namespace, not an article. Do whatever you want, I guess. – The Grid (talk) 17:11, 30 October 2024 (UTC)

• A, C, D, B in decreasing order of preference, unless something can be done to prevent the overlapping of the header and the cell content (which might be fixable with a bit of cell padding at the top of the cells, at the cost of making the entire page visually longer; there might also be a JS way to fix this, by forcing a slight scroll-up after page load if a #Section link is in the URL). The overlap interfering with utility for everyone is not surpassed by the sticky header provding some utility to a minority of new editors at the page who aren't sure what the columns are. Especially given that it's pretty obvious what they are, and nearly no one needs most of them anyway, only Source and Summary. If the sticky header were imposed, then use the more concise version; the bigger one isn't actually any more helpful as a sticky. But if sticky is not imposed, maybe keep the more explanatory version, which provides a hint of organizational/thematic clarity as a top-of-table header that appears once. If not sticky, also put the header at the bottom of the table, so someone who doesn't remember what the columns are but is nearer bottom of page can scroll there to find out instead of all the way back to the top.  — SMcCandlish ☏ ¢ 😼  19:06, 30 October 2024 (UTC)

Cell padding at the top of each row would work.

A JS and/or CSS solution would be better. Any ideas how? That's beyond my level of skill.

I set up (and immediately reverted) a sticky narrow header with the "Sources" column head linking to the Sources heading. The "Status" column head links to the Legend heading. I substituted that version link for "D" above. Click it to see the changes.

This makes the sticky header much more useful. It allows one to instantly go to the legend section. New people are going to be confused by the legend symbols, and will want a rapid way to get back to that section. Especially important in Vector 2010 where the TOC doesn't follow you around.

The Sources column head link takes one instantly back to the horizontal table of contents from anywhere in the table without tedious scrolling. So one can choose another letter.

A header at the bottom of a long table is not as useful as a sticky header. It takes a long time to scroll from the middle of this long table to the bottom of the table.

I added a couple notes just above the table. See sticky narrow header with notes here.

--Timeshifter (talk) 14:26, 31 October 2024 (UTC)

It still causes the first line to be missing. Graywalls (talk) 03:39, 3 November 2024 (UTC)

• A if editors want the benefit of a sticky header, they should enable that preference in the gadgets section of their preferences page. On this particular page, the benefit (if any), is minimal at best. When I use RSP, I know what source I am searching for and am basically looking for the color of the source and the discussion. I also use ctrl+f to quickly find what I am looking for sometimes. I was pleased when it was changed back to the status-quo. Isaidnoway (talk) 14:41, 2 November 2024 (UTC)

Non-logged-in editors don't have that gadgets option.

So you have the meaning of the legend icons memorized? Good for you. But non-regular users of this page do not. The "status" column head link takes them to the Legend section. That link is handy because the sticky header follows the reader as they scroll down the table. Is it not useful to users who don't have the legend icon meanings memorized? --Timeshifter (talk) 12:08, 3 November 2024 (UTC)

• A all the way. It simply works. Graywalls (talk) 03:40, 3 November 2024 (UTC)
• D, E, C in decreasing order of preference. Benefits, especially for new or infrequent readers of this page, outweigh the tiny problem of one line of notes being covered in secondary skins. People know how to scroll up to see it. Vector 2022, the default skin, does not have the problem. --Timeshifter (talk) 11:53, 3 November 2024 (UTC)
• A. The narrow benefit does not outweigh the narrow detriment of the scrolling issue, and the narrowed header is simply awful: the new "title" of the table is completely incomprehensible (until explained that it's supposed to be a stand-in for the bigger column headers, which, I'm sorry, what‽ Nobody who doesn't already understand the table will understand that.), and I find the appropriation of columns as navigation links incredibly weird and against how wikilinks usually behave (This point would be solved by turning them into, idk, tiny arrows that are linked instead of the header name, but you still have my other point.).
  Regarding Timeshifter's response to Isaid, I asked a family member of mine what each column meant without giving him the row headers. He identified every column except the year-last-discussed correctly (though he only identified the uses column after hovering over a link). The status icons tell you what they mean when you hover over them; heck, clicking on them already takes you to the appropriate paragraph under the legend section. Aaron Liu (talk) 02:33, 29 November 2024 (UTC)

Thanks Aaron Liu for running the tests. So your family member who was new to the table could not identify what 2 of the 6 columns were about when looking at the table somewhere below the column headers. So the family member had no benefit of seeing the column header. For example, someone following a link like this: WP:FORBESCON. I added {{tooltip}} to the column heads just now. See diff. Maybe someday when the {{sticky header}} template is made to work correctly with the old Wikipedia skins (like Vector 2010), it can be added back. And we could use 2 header rows then for better clarity. And the sticky header will be of more use to someone like your family member now that {{tooltip}} info has been added to the 2 confusing columns. The header, being sticky, will be right there to help out.

By the way, the current header has an internal link in the column head (the "legend" link). I didn't add that. I see internal links regularly in Wikipedia articles and tables.

I made some improvements to the one-line sticky header example. I expanded and clarified the table caption. I also added some notes above the table. See this version of the table section. It's even more improved here:

Note. Click Sources column head to come back here. Click Status column head to go to the Legend section above. Click on any status column icon to go to its explanation above.

Perennial sources. Current status. Discussion links (with latest by year). Uses in Wikipedia articles.

Sources	Status	List	Last	Summary	Use
ABC News (United States)		1 2	2021	There is consensus that ABC News, the news division of the American Broadcasting Company, is generally reliable. It is not to be confused with other publications of the same name.	1   2

--Timeshifter (talk) 05:49, 29 November 2024 (UTC)

I didn't find the "(legend)" link much offbeat because it clearly describes where it targets with its simple appearance. Meanwhile, linking "Sources" and "Status" this way runs against the paradigm/pattern of links going where their contents suggest. Same thing with the misappropriation of the table's name.
Also, just to clarify, my family member realized what the "use" column meant after he hovered over one of its links to see where it goes. I'd also suggest you use your sandbox instead of the RSP page to generate revisions to link to. Aaron Liu (talk) 15:42, 29 November 2024 (UTC)

I tried a sandbox, but many of the links are on the URL blacklist. So that did not work. The "Sources" and "Status" links do go to where their contents suggest. I am sure your family member would have no problem figuring it out. Plus they are explained in a note at the top of the table. The table name is not misappropriated at all. In fact, it is good practice to move info out of the column headers and into the table caption. In order to make column headers less tall. Especially with sticky tables. Helps especially on cell phones. Look it up on the table help pages. And in the sticky header template docs. --Timeshifter (talk) 16:07, 29 November 2024 (UTC)

What I did with my sandbox while experimenting with implementing the tranclusion plan is transclude parts of the RSP list. That worked pretty well as far as I can tell.
"Status" linked suggests going to a page that documents what statuses are, and I can perhaps accept that one; however, "Sources" linked suggests going to a page that documents what sources are. Like I said, using those links in a situation where you link to Wikipedia articles is quite confusing.

Look it up on the table help pages. And in the sticky header template docs.

Well, you only added that to TM:Sticky header/doc in March and to Help:Table in September yourself this year. I see no evidence that the community at large accepts or understands such usage of the table caption, nor that it is accessible to screenreaders. Aaron Liu (talk) 16:19, 29 November 2024 (UTC)

Table captions are required for screen readers. It's a MOS guideline too: WP:HEADERS. For many years now. Many people ignore the requirement. Many are clueless about the need or the requirement. Blind people want more detail in captions, not less. Putting more stuff in table captions is mentioned (for various reasons) in multiple table help pages. One of your links is actually an edit by the other main sticky table editor.

It takes only one use of the "Sources" link to figure out what is going on. People are creatures of habit. --Timeshifter (talk) 17:29, 29 November 2024 (UTC)

Sorry for misinterpreting the first diff link I posted. But 1. I was asking how screenreaders would interpret a table header in a table caption 2. I disagree with your interpretation of @Jroberson108's edit as "describe all the separate parts of the parent table headers". Even if it were correct, this kind of table caption is useless because it does not describe which table headers are associated with which parts of the caption. According to Headers which references its linked ArticleTitles, table captions should describe the table, not the table headers. Aaron Liu (talk) 18:23, 29 November 2024 (UTC)

I am not following some of what you are saying. On your user page I notice that English is not your native language. The table caption in the example above describes what is in the table: "Perennial sources. Current status. Discussion links (with latest by year). Uses in Wikipedia articles." --Timeshifter (talk) 18:56, 29 November 2024 (UTC)

I know that's what it's supposed to describe. I don't see how anyone is supposed to realize that "Uses in Wikipedia articles", the fourth phrase in the caption, is supposed to be a description for the sixth column at first glance. Why do we even need to add those to the caption, whose usual use mandated by ArticleTitles is to describe the entire table and not just duplicate descriptions of column headers that can be accessibly, semantically, and straightforwardly-interpretedly added with {{tooltip}}? Is there any consensus besides just you to use captions to describe table headers? Aaron Liu (talk) 20:20, 29 November 2024 (UTC)

I was pinged. Too much to read, but there seems to be some questions around table caption and screen readers. See w3.org: A caption functions like a heading for a table. Most screen readers announce the content of captions. Captions help users to find a table and understand what it’s about and decide if they want to read it. If the user uses “Tables Mode”, captions are the primary mechanism to identify tables. Also further down: The caption should be a short heading for the table content. A caption of "Perennial sources" or "List of perennial sources" should sufficiently describe the table. If there is another list, then differentiate them further in the caption (ex. Allowed list ... vs. Disallowed list ...). If they opt to read the table's content, then the column and/or row headers will help describe the data further. Jroberson108 (talk) 00:17, 30 November 2024 (UTC)

Thanks @Jroberson108. The question is about the table caption as posted here. Aaron Liu (talk) 00:54, 30 November 2024 (UTC)

Aaron Liu. "Uses in Wikipedia articles" in the caption tells a reader that is in the table. A caption does not tell readers where something is in the table. It just tells them it is in the table. It is in this table caption also because mobile users can't hover and read the {{tooltip}} note for "Uses" in the column headers. Same is true for "Discussion links (with latest by year)" in the caption. Mobile users can't read the {{tooltip}} note for "Last". I added those {{tooltip}} notes because your family member couldn't immediately identify those 2 columns when he/she was placed in them away from the headers. With the sticky header the family member is never away from the header.

The info could have been put in the notes above the table. But it is better in the caption because then it also helps people using screen readers. Serves a dual purpose: Describes the table better, and helps people using screen readers. Then the screen reader users have more info to decide whether to investigate the table further or not. --Timeshifter (talk) 06:30, 30 November 2024 (UTC)

The caption is not just for describing parts or columns that are in the table; it's for describing the entire table as a whole. The answer to mobile devices not being able to view tooltips is to start engineering tooltips to display on mobile, not misuse the table's accessible description: Who wouldn't be confused if their screenreader, asked to describe a table, gives them a seemingly random jumble of phrases? This absolutely does not help. Screenreaders are better served with the tooltips so that screenreaders know that information belongs to a specific column, not the entire table. Aaron Liu (talk) 20:18, 30 November 2024 (UTC)

You need to take the tooltip on mobile problem to Phabricator. They are probably already working on it. They could probably use your help.

As to table captions you are one of the few people I have heard from who has complained about a table caption being too informative. --Timeshifter (talk) 00:06, 1 December 2024 (UTC)

As it's specific to enwiki wikitext, it's something I should prototype in the tm:tooltip/sandbox in the near future, not report to the WMF-wide phab.

You have yet to demonstrate that anyone besides you likes table captions "being too informative" in this manner. Aaron Liu (talk) 03:59, 1 December 2024 (UTC)

It's not too informative.

I see: Template:Tooltip and mw:Extension:SimpleTooltip and mw:Extension:RegularTooltips. And more in the "See also" sections of those MediaWiki pages.

Phabricator search for "tooltip". And "mobile tooltip".

--Timeshifter (talk) 05:53, 1 December 2024 (UTC)

I was using your own words. Please demonstrate that another extended-confirmed editor agrees with your style of captions.
You’ll notice that none of the Phabricator “mobile tooltip” search results deal with what we’re talking about, thus proving my point. And those extensions have nothing to do with the HTML tags we’re talking about. Aaron Liu (talk) 16:17, 1 December 2024 (UTC)

There are many table captions as long as the one in the above example.

I don't claim to have any knowledge about getting tooltips to work on mobile. I just linked to places that might be useful. You might contact some of the people involved in other aspects of tooltips in order to work together on mobile tooltips of whatever flavor you all decide to try. --Timeshifter (talk) 17:02, 1 December 2024 (UTC)

It was never the length I was objecting to. It’s the usage of it to describe column headers instead of the entire table. Aaron Liu (talk) 17:30, 1 December 2024 (UTC)

Well, I am glad you are not objecting to the length of the table caption. And as I said, the more detailed table caption serves multiple purposes: It allows for less-tall headers which is important for sticky headers in cell phones. It describes what is in the table. The info in the columns is part of the table. It helps those on mobile who can't read tooltips to have some inkling of what is covered by the column heads. It helps screen reader users to see more clearly what the table covers without having to dig down into the table. Which they greatly appreciate. Especially when the screen reader is in table mode, which allows them to skip from table caption to table caption. See:

• Caption & Summary, in Tables Tutorial. Web Accessibility Initiative (WAI).

There are multiple methods listed there, but as far as I have seen, only table captions are used on Wikipedia. "Approach 1" in the article looks interesting now that you have said that you do not object to longer captions. It is basically an expanded caption. I have no objection to it. I have been working here lately: User:Timeshifter/Sandbox279. Here is a possibility:

---

---

Note. Click Sources column head to come back here. Click Status column head to go to the Legend section above. Click on any status column icon to go to its explanation above.

Perennial sources. Current reliability status. Links to discussions.
The "List" column links to discussions. "Last" is last year discussed. "Use" shows use in articles.

Sources	Status	List	Last	Summary	Use
ABC News (United States)		1 2	2021	There is consensus that ABC News, the news division of the American Broadcasting Company, is generally reliable. It is not to be confused with other publications of the same name.	1   2

--Timeshifter (talk) 09:01, 2 December 2024 (UTC)

I’m not going to respond further if you don’t show that there is consensus for table captions like this. (And the summary example you linked is inside a longer summary element, not the caption element. I said the problem I had with the caption was far more fundamental than length, not that I don’t object to length per MOS:Caption.) Aaron Liu (talk) 13:18, 2 December 2024 (UTC)

See Help:Table#Captions and summaries. Its summary info is out of date though, and is obsolete in HTML5. That may be why I can't remember ever seeing it used:

{| summary="Summary text here."

The w3.org WAI summary example I linked is part of the caption element. From "Approach 1":

"The element acts as a heading of the table and provides the summary that describes the composition of the table as well. If implemented this way, the summary is available to visual users as well."

I have occasionally seen tables with captions extending to 2 lines.

There is no rule against it. And it appears that w3.org Web Accessibility Initiative (WAI) endorses it for some tables. So that is consensus outside Wikipedia. And Wikipedia tries to meet accessibility standards. WAI is the main accessibility organization. --Timeshifter (talk) 14:24, 2 December 2024 (UTC)

Where does WAI endorse non-summary captions that only describe a table header, or separated by periods?

Also, I think the |summary= parameter is a MediaWiki issue that should be fixed in MediaWiki to be HTML5-compliant, not by modifying wikitext. Aaron Liu (talk) 01:19, 3 December 2024 (UTC)

Mediawiki doesn't decide HTML5 standards. summary= is part of HTLM4, not HTML5.

And as I have repeated several times, the single-line caption I provided describes the content of the table: "Perennial sources. Current status. Discussion links (with latest by year). Uses in Wikipedia articles."

The multi-line expanded caption is a method I did not know about before: "Approach 1" in here:

• Caption & Summary, in Tables Tutorial. Web Accessibility Initiative (WAI).

There are many table captions on Wikipedia with periods within the caption. --Timeshifter (talk) 17:28, 4 December 2024 (UTC)

Tables in Wikitext are part of Wikitext, not HTML. The parser chooses how to render the Wikitext into HTML, and there is discussion about making it render the summary element instead. There’s no reason why the summary parameter can’t be rendered into HTML5.

I have also repeatedly told you that I object to this caption because I object to captions that only describe column headers instead of the entire table as a whole, and you have repeatedly failed to demonstrate that there is consensus for this. Aaron Liu (talk) 21:04, 4 December 2024 (UTC)

phab:T43917 is going nowhere. <summary> </summary> is not part of HTML5 as concerns tables. It is not mentioned here:

Caption & Summary, in Tables Tutorial. Web Accessibility Initiative (WAI).

The single-line caption here describes what is in the table. It does not describe the column headers specifically.

On the other hand, the 2-line caption in the above example (as recommended by the WAI link in Approach 1) explicitly describes some of the column headers.

I edit a lot of tables. It is common in captions to provide, in addition to the general table description, some more specific details. Such as: "Rate is per 100,000 of all ages." That is very specific to the rate columns. This is done to prevent bloated headers. It is common.

You can repeat your preference forever, but it doesn't change the facts about existing table captions. --Timeshifter (talk) 22:53, 4 December 2024 (UTC)

Thanks, I was indeed confused about HTML5. My point still stands though that the Wikitext parser can find ways to make the output HTML5-compliant.

Everything after the first full stop describes individual columns (' headers). If you want a two-line caption, make a two-line caption with the smaller text in prose, and I might be fine with the caption.

The onus is on you to demonstrate that there is consensus for your preference. Aaron Liu (talk) 22:51, 13 December 2024 (UTC)

I can't find the "Rate..." example you mentioned, could you link it? I think it would be better served with a footnote or a parenthetical within the header. Aaron Liu (talk) 22:54, 13 December 2024 (UTC)

• D/B/E: If there were 10-20 entries having static headers would have made sense. But with so many entries, a static header is difficult to follow because it requires several hundred lines of scrolling. I have used RSP shortcuts to revert bad edits, or make arguments at move discussions, in both cases I expect majority of such visitors to not know beforehand what the header contents are. Which means that a visitor would need to scroll all the way to the top, look at what the header contents are, and then come back to understand what exactly the numbers, icons and colours mean. It is unnecessary inconvenience when we now have the ability to show sticky headers. Most regulars to this page and those with this talk page in their watchlists might not need the headers because they are already well-aware of what these columns are for, but it overlooks others' inconvenience. As someone who is not a regular to this page, I found it very convenient and that is the reason behind me adding sticky headers to the table (now reverted) unaware that there is already a discussion going on here. Thanks! —CX Zoom[he/him] ^{(let's talk • {C•X})} 19:17, 6 December 2024 (UTC)

FoxNews

Considering the outcome of the recent election(s), and the previous polling reports, is it encyclopaedic to consider Fox News "not reliable" while other similar outlets like NBC and ABC are considered reliable? Seems quite suspicious how in the 2024 United States presidential election the sites used to report results consistently under-polled the winner of the election, while the one site who did the same thing less, is considered unreliable to be used there. 81.196.30.197 (talk) 14:53, 16 November 2024 (UTC)

A single instance of them being right isn't going to swing against their general unreliability. Even a broken clock is correct twice per day... Captainllama (talk) 00:04, 18 November 2024 (UTC)

How about the Trump-ABC defamation suit that resulted in ABC paying 15 million to the Trump Presidential Library due to their constant, repeated false statements about him? How can they still be considered reliable? 2603:7080:81F0:8F0:0:0:0:10D1 (talk) 23:13, 15 December 2024 (UTC)

Settlements are not legal precedence. And here, we know that this was basically over the issue of saying Trump was convicted of rape, when the court judge and under NY state law, he could only be convicted of sexual misconduct, even though the presiding judge said it was rape in their final opinion. That George S. pushed that point multiple points, he wasn't "wrong" or deliberately lying, compared to how Fox presented its topics. Masem (t) 23:20, 15 December 2024 (UTC)

Single issues have little impact on whether a source is considered reliable, as sources are only ever considered 'generally reliable' (as even the best source can be wrong at times). For a source to be considered unreliable would require a long term lack of fact checking or accuracy. -- LCU ActivelyDisinterested «@» °∆t° 00:19, 16 December 2024 (UTC)

Amendments needed to the transclusion splitting plan

I was implementing Wikipedia talk:Reliable sources/Perennial sources/Archive 10#Tranclusion split partition scheme when I ran into a few issues:

1. Transcluding the final eighth of the sources overruns the mw:Manual:Template limits#Post-expand include size, and even just the first 7/8 plus what's already transcluded on RSP ovverruns the limit.
   • i.e. the list of sources is too large to be trasncluded onto RSP.
2. The page's edit notice needs to be adapted and displayed on the subpages.

Problem #1 may be solved by moving the list of sources onto a separate page and substituting the last two sections there. (As shown in User:Aaron Liu/sandbox, only substituting the last section is not enough.) Problem #2 may be solved by making the source list its own series of subpages by e.g. moving everything else under WP:Reliable sources/Perennial. Alternatively, Problem #1 may be solved by bumping $wgMaxArticleSize (the max post-expand include size), but that may be refused for security reasons. What do we think? Aaron Liu (talk) 23:24, 28 November 2024 (UTC)

Pinging:

• Remsense
• Ivanvector
• CommunityNotesContributor
• Mfko
• ActivelyDisinterested
• Gråbergs Gråa Sång
• Daniel Quinlan
• Apenguinlover

. We really should've seen this coming as the limit was also evident at User:Ivanvector/RSP split proposal. Aaron Liu (talk) 20:00, 30 November 2024 (UTC)

Sorry, I don't have an informed opinion. Gråbergs Gråa Sång (talk) 04:17, 1 December 2024 (UTC)

Since it is useful to sort, what if you cut the table in half horizontally and linked to the other piece? That would be a large change though. Apenguinlover<talk>() 20:19, 30 November 2024 (UTC)

My experience news that this wouldn't help the post expand limit, but I'm not very knowledgeable in such technicalities and so thought I must be wrong. -- LCU ActivelyDisinterested «@» °∆t° 23:12, 30 November 2024 (UTC)

I think it definitely would help but would render the table quite inaccessible/clumsy. I’ve recently been researching maybe substituting all iconless discussion links. Aaron Liu (talk) 01:21, 1 December 2024 (UTC)

idea:

112 Ukraine

data-sort-value=2|

 2019  2020  2020

1

A B

data-sort-value=2020|

2020

112 Ukraine was deprecated following a 2019 RfC, which showed overwhelming consensus for the deprecation of a slew of sources associated with Russian disinformation in Ukraine. It was pointed out later in a 2020 RfC that 112 Ukraine had not been explicitly discussed in that first discussion prior to its blacklisting request. Further discussion established a rough consensus that the source is generally unreliable, but did not form a consensus for deprecation or blacklisting. The prior blacklisting was reversed as out of process. 112 Ukraine closed in 2021.

1  
2  

Special:ExpandTemplates on this row with the tables stuff removed:

[[112 Ukraine]]
:data-sort-value=2|[[File:Argentina - NO symbol.svg|20px|Generally unreliable|link=Wikipedia:Reliable sources/Perennial sources#Generally unreliable]]
:[[File:Treffpunkt.svg|20px|Request for comment|link=]] [[Wikipedia:Reliable sources/Noticeboard/Archive 281#RfC:_Deprecation_of_fake_news_/_disinformation_sites.|2019]] [[File:X-circle.svg|20px|alt=Spam blacklist request|link=]] [[MediaWiki talk:Spam-blacklist/archives/January 2020#State_sponsored_fake_news|2020]] [[File:Treffpunkt.svg|20px|Request for comment|link=]] [[Wikipedia:Reliable sources/Noticeboard/Archive 315#112.ua|2020]]
:[[Wikipedia:Reliable sources/Noticeboard/Archive 281#news-front.info|1]]
:<br />[[Wikipedia:Articles for deletion/Timeline of the war in Donbass (January–March 2016)|A]] [[Wikipedia talk:Reliable sources/Perennial sources/Archive 4#112 Ukraine|B]]
:data-sort-value=2020|
:2020
:112 Ukraine was deprecated following a 2019 RfC, which showed overwhelming consensus for the deprecation of a slew of sources associated with Russian disinformation in Ukraine. It was pointed out later in a 2020 RfC that 112 Ukraine had not been explicitly discussed in that first discussion prior to its blacklisting request. Further discussion established a rough consensus that the source is generally unreliable, but did not form a consensus for deprecation or blacklisting. The prior blacklisting was reversed as out of process. 112 Ukraine closed in 2021.
:[[Special:Search/insource:"112.ua"|1]]&nbsp;[[File:Ic lock outline 48px.svg|16px|HTTPS links|link=Special:Linksearch/https://*.112.ua|class=skin-invert]]&nbsp;[[File:OOjs UI icon link-ltr.svg|16px|HTTP links|link=Special:Linksearch/*.112.ua|class=skin-invert]]<br>[[Special:Search/insource:"112.international"|2]]&nbsp;[[File:Ic lock outline 48px.svg|16px|HTTPS links|link=Special:Linksearch/https://*.112.international|class=skin-invert]]&nbsp;[[File:OOjs UI icon link-ltr.svg|16px|HTTP links|link=Special:Linksearch/*.112.international|class=skin-invert]]

We could nominate some wikitext on WikitextForDeletion, or we could do what Aaron suggested Apenguinlover<talk>() 11:53, 1 December 2024 (UTC)

“Wikitext for deletion”? Aaron Liu (talk) 16:10, 1 December 2024 (UTC)

The Wikitext for deletion part is a joke. I just mean that this can help expose what parts could be trimmed Apenguinlover<talk>() 16:45, 1 December 2024 (UTC)

What happens what you edit WP:RSP, 16 December 2024.

• I am getting "page unresponsive" issues too often. Granted my laptop is not getting any healtheier, but neither is this project page. I also rarely get this problem on other articles, other than those equally oversized. As a point of context here, without wanting to toot my own horn, I am currently one of the top 5 editors of this page and WP:ARTICLESIZE issues has become a predominant reason for my to avoid making updates. The sooner these issues are resolved the better. CNC (talk) 20:31, 16 December 2024 (UTC)

Mostly done

 Mostly done: After a bunch of substituting the RSNL template I trimmed, transclusion split implemented, taking up only 1634531 bytes out of the 2097152-byte post-expand include size−limit.

As mentioned above, now we just have to figure out the group notices. Aaron Liu (talk) 00:23, 17 December 2024 (UTC)

Here's my tentative plan:

1. We turn tm:Editnotices/Page/Wikipedia:Reliable sources/Perennial sources into a group editnotice for all the subpages of Wikipedia:Reliable sources/Perennial sources.
   • This may or may not still display on the templates (see their tentative parentpage specified in the next step). I hope it doesn't, so we'll ask the template editor responding to the editnotice request about this and request that they move/open a move request on the next step after completing this step.
2. We move the non-number subpages (which are all templates) (except /Header) under Wikipedia:Reliable sources/Perennial sources templates.

Aaron Liu (talk) 00:47, 17 December 2024 (UTC)

@ToThAc Lol, I should've tested that. As you can see at the start of this section, I actually did try that at first, but I skipped over it after it exceeded the transclusion character-count limit and broke all the citations (and the 8th part itself). Looks like it works now after I made a bunch of changes to and substituted the RSNLink template and replaced "Wikipedia:" with "WP:". Thanks! Aaron Liu (talk) 02:34, 20 December 2024 (UTC)

That's the change I was curious about. Why is it PS7 doesn't use {{rsnl| template but the other subpages still do? Anyway the change is a vast improvement editing wise, it's a smooth as it gets now. Congrats to those involved. CNC (talk) 10:36, 21 December 2024 (UTC)

As I've said in my updates to RSPI, all bare RSN links (i.e. no RfC, not active) were substituted. PS7 uses RSNL in all the places the other subpages do. Aaron Liu (talk) 14:55, 21 December 2024 (UTC)

Ok understood, thanks for explaining. CNC (talk) 17:03, 21 December 2024 (UTC)

Bild

Why is Bild marked unreliable in the absence of RfCs and with only 3 discussions with only a few contributors? Alaexis_¿question? 15:38, 9 December 2024 (UTC)

It's a very unreliable German tabloid paper. Some sources don't need a full RfC to know they are unreliable.

Though if you do feel like contesting it, you are welcome to start one of course, though the result of it are all but guaranteed, so it might WP:SNOW in it. Raladic (talk) 18:01, 9 December 2024 (UTC)

I don't see any examples of falsehoods that they published in the Wikipedia article about it. Alaexis_¿question? 21:47, 9 December 2024 (UTC)

Maybe try reading the German version then? [1]. It's tabloid trash, exactly like the British red tops or the Daily Mail. Hemiauchenia (talk) 22:18, 9 December 2024 (UTC)

The lead of Bild (the en.wiki article) describes it as "tabloid in style", the journalistic equivalent of The Sun, and quotes the description "notorious for its mix of gossip, inflammatory language, and sensationalism". None of this suggests reliability, whether or not our article discusses specific falsehoods that it has printed. Caeciliusinhorto-public (talk) 11:11, 10 December 2024 (UTC)

@Hemiauchenia, I've just reviewed the German wiki article, specifically post-2015 events in the Verstöße gegen den Pressekodex section and I'm still not convinced it should necessarily be considered unreliable. But I may be missing the local context. In your opinion, what were the worst incidents in the last 5 years? Alaexis_¿question? 20:54, 10 December 2024 (UTC)

According to a Foreign Policy article in 2022 [2] The ubiquitous German tabloid Bild and the online Bild.de are regularly sanctioned by the German Press Council, a body responsible for enforcing the German Press Code, for their violation of standard journalism ethics relating to personal privacy, among other issues. ... The Axel Springer press’s [Bild's owner] obsession with scandals and lurid photos of victims of catastrophes, traffic accidents, or other tragedies earned it recrimination from many corners. The German Press Council has sanctioned it well over 200 times since 1986—more than any other German publication. But these violations of basic journalism ethics obviously don’t faze Axel Springer media house, as these practices haven’t ceased. (In 2021 alone Bild media was reprimanded by the council 26 times.). The piece itself is pretty damning about Bild, including their nomalizing of anti-vaccine rhetoric during the COVID-19 pandemic. How much more evidence do you need that this is an unreliable source? Hemiauchenia (talk) 21:25, 10 December 2024 (UTC)

Thanks, I'll review the article. However, violations relating to personal privacy have no bearing on the reliability. Alaexis_¿question? 21:33, 10 December 2024 (UTC)

I've bitten the bullet and created a RfC to settle the issue. Wikipedia:Reliable_sources/Noticeboard#RfC:_Bild Hemiauchenia (talk) 23:10, 10 December 2024 (UTC)

Imported YouTube videos

@Graywalls: Greetings! Regarding this revert...it sounds like I have failed to dispel the confusion. I'm trying to explain when WP:UGC does not apply to videos imported from YouTube, and it's when the user-generated content is not being used as a reliable source, but merely as a repackaging of a reliable source. For example, imagine someone made a 3D animation of how hurricane winds circulate and uploaded it to Wikipedia to illustrate the article hurricane. This is perfectly fine, and in fact encouraged and celebrated, as long as they cite a reliable source (for example, a series of diagrams published by NOAA) for the data used to create the animation. It is just as acceptable for the same video to be uploaded to YouTube under a suitable Creative Commons license, then re-uploaded onto Wikipedia, and added to the same article. What is not acceptable is to take videos from YouTube that cite no sources and treat them as accurate additions to articles without verification. It's also not acceptable for an editor to make an animation citing no sources and add that to an article by direct upload to Wikipedia, though we are a bit behind on our fact-checking. -- Beland (talk) 07:22, 18 December 2024 (UTC)

I don't see why this note is necessary. UGC also applies even if hosted on Commons, since they also need to cite sources. Aaron Liu (talk) 21:14, 18 December 2024 (UTC)

@Aaron Liu, Beland, and Graywalls: It's a subtle point. Any bozo can upload a freely-licensed Youtube video based on reliable data from a reliable source. But that video would not qualify as being from a reliable source for Wikipedia purposes due to the bozo intermediary. Now let's say another bozo, say me, uploads that video to the Commons. Since the video is based on reliable data from a reliable source, then it qualifies for the Commons. Assuming it is something within Commons:Com:Project scope.

In addition to a clarified, and possibly shorter, note, these 2 links could be added to Wikipedia:RSPYOUTUBE:

Commons:Category:YouTube

Commons:Com:YouTube files

--Timeshifter (talk) 23:02, 18 December 2024 (UTC)

lol, I made my reply below before I saw this. What do you think of it? Do you know of any rules I could link? Aaron Liu (talk) 23:03, 18 December 2024 (UTC)

The use cases have come up in at least one RFC, where a reading of a contemporaneous public domain and verifiable source text was held to be "unreliable" as per this policy, despite the fact that the reading was being used for illustrative purposes. The same case could be used for a music performance, or an extract of a play, or poetry, etc. as well as the examples @Beland makes. However, these are not "unreliable" as they are performances or renderings of verifiable source material, and not being used for citation purposes. Some clarification of the difference between YT as a citation vehicle, and YT as a source of illustrative content, would help avoid future similar situations. Jim Killock (talk) 22:41, 18 December 2024 (UTC)

How about something like All videos uploaded, regardless of source, are treated the same way as images and other media. in a new paragraph? Aaron Liu (talk) 23:02, 18 December 2024 (UTC)

For mine, the necessary condition the user-generated content is not being used as a reliable source makes the usage off-topic for this page; which deals solely with the reliability of sources as references for article content. I do, however, see that the first sentence of the YouTube entry, Most videos on YouTube are anonymous, self-published, and unverifiable, and should not be used at all. (emphasis added), is easily read as prohibiting a broader range of uses. Suggest that this be modified to refer only to use as a (reliable) source; e.g. ... should not be used as a reference or similar. The page would then be silent on the question of illustrative content. Rotary Engine ^talk 23:31, 18 December 2024 (UTC)

Sounds very reasonable. I've implemented this. Aaron Liu (talk) 23:52, 18 December 2024 (UTC)

YouTube is available to everyone and it's widely used by those including official media outlets. So, unless they're official news coverage that happens to use YouTube and it's hosted on their OFFICIAL page, YouTube should be evaluated the same as blogs and home pages.

YouTube channels containing news clippings, or advertisement clippings from channels other than should not be found anywhere within Wikipedia on the ground of WP:COPYVIOEL. Graywalls (talk) 04:57, 19 December 2024 (UTC)

I linked to illustrative, non-referential use. Here is current summary section:

Most videos on YouTube are anonymous, self-published, and unverifiable, and should not be used as a reference. Content uploaded from a verified official account, such as that of a news organization, may be treated as originating from the uploader and therefore inheriting their level of reliability. However, many YouTube videos from unofficial accounts are copyright violations and should not be linked from Wikipedia, according to WP:COPYLINK. See also WP:YOUTUBE and WP:VIDEOLINK. For illustrative, non-referential use see Commons:Category:YouTube.

--Timeshifter (talk) 00:51, 19 December 2024 (UTC)

That's certainly an improvement over the previous text; thanks for the condensation! -- Beland (talk) 03:37, 19 December 2024 (UTC)

While not yet convinced on the need to mention illustrative use on this particular page, I am fairly certain that Commons:Category:YouTube is not the best target for that link. @Timeshifter, could you check and confirm that another page was not the intended target? A Commons policy or guideline page perhaps? Rotary Engine ^talk 06:28, 19 December 2024 (UTC)

Perhaps link to Mos:Images#Audio visual content where there is a line on this, and with an expanded version under consideration, draft 0.3 here. The explanation IMO needs to be on one or the other MOS page; it may make a bit more sense here for reasons of brevity and clarity. Jim Killock (talk) 09:30, 19 December 2024 (UTC)

I've already changed the link to c:Commons:YouTube files. Someone else also added Wikipedia:Image use policy. Aaron Liu (talk) 12:25, 19 December 2024 (UTC)