Wikipedia talk:WikiProject Portals/Archive 14

Archive 10

←

Archive 12

Archive 13

Archive 14

Archive 15

A proposal for portal system overhaul

Proposal

The portals at Wikipedia are expected to serve as gateways for readers interested in specific subject areas for browsing the best Wikipedia has to offer in that area. In other words the portals are supposed to be extensions of the main page, but more focused in a specific topic area. Given the Wikipedia communities agree on the need of such gateways or extensions of main page the main page should not only link, but also prominently feature and promote a few portals which should be selected and organized in meaningful / systematic manner. Currently the main page does link a few portals, but there is room for improvement in the way they are organized.

I would like to propose a system of “Portal Tree” which would help decide which portals should be linked to main page and also serve the purpose of deciding which portals are needed and which are good to have.

The main page should link to portals which would offer to break-down Wikipedia into certain themes. Let’s call these portals linked from the main page as L0 Portals:

• Theme: People and Events: Current Events, History, Biography,
• Theme: Places: Asia, Europe, North America, South America, Africa, Oceania
• Theme: Topics: Mathematics and Logic, Physical Science, Social Science, Arts, Games and Sports
• Theme: Species: Protista, Plantae, Animalia

(of course the above list is an output of my initial brainstorming. Wikipedia community can discuss and decide what should be the ideal structure)

I would also recommend that each L0 Portal within a given theme should have some structural consistency.

Each L0 portal, should lead to sets of sub-portals - let's call them L1 Portals. L1 Portals will be a logical sub-division of an L0 portal. For example a Country Portal can be an L1 Portal to a Continent Portal.

L0 and L1 Portals should be designed in a way that they give a balanced representation of the topic covered. With that goal, they should be allowed to display contents (articles/lists) of up to B-Class and any media of relevance to the topic area. DYK and News items should ideally be sourced from main page. Until a L0/L1 Portal reaches a certain level of acceptance of quality, they may show a Notification message on top saying "This portal is currently undergoing update and may not give a balanced representation of the topic."

L1, and L0 portals will not be deleted on the ground of quality or page views.

In addition, if community wants, there can be additional "Featured Portals" (let's call LF) linked to L0 / L1 portals which would only focus on a narrow subject area where Wikipedia has highly developed content. LF Portals will only be used to feature FA / GA / FL rated contents.

Examples of LF Portals would be portals on Specific Cities, tournaments, specific non human species etc.

LF level portals can and should be deleted if they fail to maintain standard.

Please place your comments under in the comments section below. Arman ^(Talk) 06:15, 3 October 2019 (UTC)

Comments

• Agree. I agree with the proposal above. I have added some comments, further down. --Sm8900 (talk) 15:03, 11 October 2019 (UTC)

I have a couple of comments: firstly, we're probably wasting our time because portals are being deleted so fast they will cease to exist in a few months' time. Secondly, the idea of portals as extensions of main page is the reason they are being deleted. They are so poorly linked (POG only requires one mainspace link) and have such low page views that the deletionists are using that as a major reason to eliminate them. Page views would go up with more links, but they will probably never be 'read' more than high-level categories and that is fine, but only if the community accepts them as navigation aids. My final point is that, if portals survive the current holocaust, it will only be because they are accepted as project tools used by editors to view at a glance the coverage of a topic and then expand and improve the topic area. With one or two exceptions, the only portals that have survived total annihilation so far are those that I have moved to project space. No-one seems to be objecting to that... yet. So, yes, the portal system does need an overhaul, but I think it's now too late. Their almost total destruction is imminent. Bermicourt (talk) 06:26, 3 October 2019 (UTC)

I am aware of the drive against portals and was hoping the above proposal would help give a fresh thought on saving the portals or helping them eveolve into a more structured browsing tool for wikipedia. But of course the above proposal assumes that we need some sort of extension of the main page for readers interested in specific topic areas. This assumption itself needs to be validated by community first. Arman ^(Talk) 07:01, 3 October 2019 (UTC)

• I think that the notion that a portal should be like the main page for a specific subject area is the single biggest flaw in Portals. The main page is not for navigation but for showcasing. It is the glossy foyer. Portals are for navigating and that means function not gloss. —SmokeyJoe (talk) 07:19, 3 October 2019 (UTC)

Just to understand this comment a bit more - what is the problem of using Portals for showcasing, like main page? While we have "Outlines" and "Categories" for navigation, why not designate Portals for showcasing? -- Arman ^(Talk) 08:37, 3 October 2019 (UTC)

Showcasing may be fine, but showcasing is not navigating. Or, showcasing is a highly POV form of guided navigating. The two shouldn’t mix. Link, yes. Mix, no. Someone may want to see Mathematics Featured Articles, but that’s no way to get a sense of all mathematics. —SmokeyJoe (talk) 11:00, 3 October 2019 (UTC)

Hardly any portal claims to be a systematic navigation tool. That's what outlines are for. Portals always were showcasing tools. The POV concern is legitimate and like any other wikipedia content it should be managed with peer review. This is why in my proposal I mentioned that L1 and L0 portals should provide a balanced view of the topic area. Until that is achieved, the portals should display a suitable disclaimer. On the other hand LF portals should make it clear that the portal's goal is to showcase featured components, not to provide a representative coverage. Arman ^(Talk) 11:14, 3 October 2019 (UTC)

“Portals always were showcasing tools”. Portals have been a failure from the start. Clarity of purpose is a good idea. —SmokeyJoe (talk) 21:29, 3 October 2019 (UTC)

@Armanaziz: I agree. Please take a look Wikipedia:WikiProject Portals/Portals tree, Template:Portals tree, Wikipedia talk:Portal/Guidelines/Archive 9#Portal creation and deletion criteria proposal 5 and Talk:Main Page#Add Portal:Law to the list of portals displayed on the homepage.Guilherme Burn (talk) 11:32, 3 October 2019 (UTC)

Portals are redundant. Interested in mathematics? Go to mathematics. There's your L0 portal. Categories and navboxes are all we need. Less is more. — UnladenSwallow (talk) 17:42, 9 October 2019 (UTC)

Is the average Joe willing to read a lengthy article to be recommended the most important/best articles? The portal model sounds like it could have a user for a person not willing to wade through an article but interested in being recommended a few choice articles. It would be best to think about the average person. WhisperToMe (talk) 21:49, 12 October 2019 (UTC)

Smokey Joe makes a good point: "clarity of purpose is a good idea." It's clear from the various comments that we all have different POVs on the purpose of portals and that, naturally, leads to different POVs on their utility. What is also true is that this lack of consensus has been a major factor in the perception that 'portals are redundant' which is another way of saying "I personally don't have a use for them". My practical experience is that portals have real utility, if well constructed and linked, as navigation and project tools, but too many editors have seen them purely as showcases having to compete somehow with articles. Bermicourt (talk) 06:53, 10 October 2019 (UTC)

the perception that 'portals are redundant' which is another way of saying "I personally don't have a use for them" It's not about utility, it's about the consumption model. When people want to learn about something, they google it from the browser's address bar. Then they go to a news article, a YouTube video, the official website, or a Wikipedia article. If they choose to go to a Wikipedia article, they may occasionally dig deeper by following the links (including links in navboxes) until they satisfy their curiosity. No one ever thinks: "Oh, this topic I'm interested in is related to mathematics, so I'd better open the Mathematics portal and try to find it there." 99.9% of Wikipedia users don't even know portals exist.

Perhaps L0 portals have their place, but they have to be updated regularly (every day) and featured on the main page even more prominently than they are now. And they must cover only the most general topics, for example:

• Politics, Governance & Law
• Business & Economy
• Culture & Arts
• Sports
• History
• Technology & Engineering
• Science
  • Mathematics & Computer Science
  • Physics & Chemistry
  • Life Sciences & Medicine
  • Biology
  • Geography & Urban Studies
  • Astronomy & Space Exploration

Also, they should be titled, e.g., Wikipedia:Science_Page (like Wikipedia:Main_Page), not Portal:Science. Only if these L0 portals become very successful (and that's a big if ) should we consider adding L1 portals. — UnladenSwallow (talk) 14:56, 11 October 2019 (UTC)

Re: "Perhaps L0 portals have their place, but they have to be updated regularly (every day)" I think we should make it so the top/most active Wikipedia users don't need to update it, as the portals would be updated by drive-by users - Make it so it's easy for others to do it. I only have so many hours in a day, I have a day job, and I'm not getting paid by the WMF - I'm more active than 99.9% of the public, and I feel that it's not reasonable to expect a core dedicator to "maintain a portal" when instead one should have the user base, the public, do it. But that will mean:

• A. people need to know they exist
• B. they need to be placed at the top of the article/in a prominent place so they know they exist (people on Reddit note that commenters don't read beyond the headline so portals need to be at the start of each article)
• C. Editing needs to be super-super easy from a mobile phone, so that even a person relatively uneducated in technology can do it.

Otherwise I feel portals are being set up for failure as it'll burden people who can otherwise work on articles which don't get deleted even if they aren't maintained.

WhisperToMe (talk) 21:53, 12 October 2019 (UTC)

• Strongly disagree. Sorry to the proposer, but I will be blunt: this proposal is silly. It has made as if the last year of discussions had never happened.

The problems with portals are simple:

• The whole concept of portals is redundant. They were a 1990s technology for navigating the web, which needed high maintenance, and therefore didn't scale as the web grew. So when Google offered powerful search, and content management systems allowed website to offer massive cross-linking, portals faded away.
• Wikipedia portals were started in 2005 when the web portals were all dead. Nobody has ever identified any problem that they were intended to solve, or any reader demand that they were intended to meet. They were, and always have been, driven by the desire of a small number of editors to create pages without having to go through the hard work of identifying and using sources, and building verifiable, referenced NPOV articles.
• As a result, portals have adopted a design and structure which fails every task which they have been set:
  • They don't function as a mini-mainpage, because they don't get remotely near as much editorial attention and is needed to sustain that type of page. (The wikipedia Main Page is sustained by several large teams of hard-working editors. No portal has even a tiny fraction of that much editorial effort)
  • Portals don't assist navigation, because that job is done a million times better by categories (which are largely compete, and have a hierarchical structure) and navboxes (which a massively more usable, because they appear on the same page as the article).
  • Portals are near-useless as showcases, because the list of articles is not drawn up against any objective list of criteria, is almost never discussed, is usually created by editors with little or no demonstrable expertise in the topic area, and is almost never even displayed on the face of the portal. The list of topics is core of any portal, but it receives little attention.
    Additionally, the Rube Goldberg machine structure use for showcasing is a usability nightmare and a maintenance nightmare. For readers it doesn't even display a list of available topics, leaving the poor reader to to the completely counter-intuitive task of purging the page to see another random topic from an undisclosed list or unstated size; for editors it offers a hideously complex, unfamiliar framework.

So before defining a hierarchy, let alone proclaiming that some portals cannot be deleted even if they are unused crap ... start by building a consensus on what portals are actually for, and whether they can actually fulfil that task ... and then test them to see if readers actually find that they add value. The rest is just building cardboard castles on sand, as has been done for the last 15 years. --BrownHairedGirl (talk) • (contribs) 16:18, 12 October 2019 (UTC)

Subsection

• Agree. I appreciate and agree with the initial idea above by @Arman, about possibly designating different levels for portals based on their content.

if anyone wants to start a topic of this nature, then maybe as one good starting point, or maybe as one possible item to include, perhaps we might agree that at least there are some portals which are well-run and which prove the value of portals in general. this might be one possible starting point for establishing and illustrating some good practices for defining portals in general.

here is a HIGHLY incomplete list of some of these. can our group get some consensus that these are some of the portals that are considered valid and worthwhile? Is that one good starting point? By the way, the purpose of this list is just to agree on a few examples; this list is not intended to be complete in any way; i.e., this is not exhaustive, and I am not saying that all portals other than these should be deleted. Thanks!

Useful portals:

• Geographical, political:  United Kingdom portal,  United States portal,  North America portal, Europe portal, England portal,  EU portal
• Science/Technology:  Biology portal,  Chemistry portal,  Environment portal,, Physics portal,  Computer programming portal,  Technology portal, ,  Engineering portal,
• Historical: , ,
• General topical:  Society portal,  Philosophy portal,  Politics portal,  Geography portal
• Arts and culture:  Music portal,  Arts portal,  Opera portal
• Cities, regions:  New York City portal,  London portal,  Tokyo portal

As an alternate approach, here is another format to present sets of portals systematically, i.e. portal bars, to highlight some portals that are of great importance. here is science portalbar, i.e. based on existing template:

some other possible portal bars, i.e. that I simply compiled on my own:

etc etc Sm8900 (talk) 19:51, 10 October 2019 (UTC)

I haven't checked all the portals above, but I do agree that there are some that have interesting content and are reasonably maintained, and therefore should not be considered targets for deletion. Regarding some of the "purpose of portals" comments above, I see portals primarily as showcases of content that is either high quality (FAs, FLs, FPs, maybe GAs) or with an identifiable "hook" to draw interest (DYKs, OTDs, ITNs). This is similar to what the Main Page (which has a portal-style layout) provides, but with a narrower scope so that readers interested in a specific area can see something focused rather than hoping their interest shows up on the Main Page once a month. Showcasing includes allowing users to navigate to the articles and images that are being showcased, but saying that navigation per se is the primary purpose of portals is out of step with what most of our portals do and have done since they were first used on Wikipedia.

With that understanding of purpose, it becomes easier to formulate criteria for what makes a good portal. To have a portal at all, a topic should have a substantial amount of promoted content (FA, etc.) to show, and it should be broad enough in scope generally that there are enough "hook" items. To be a good quality portal, a healthy set of these should be presented on the portal: "healthy" both in number (so return visitors can see something different being showcased) and in quality (for example, showing only "selected articles" that are currently at featured status). Portals that "feature" a handful of C-class articles and show the same three DYKs on every visit are failing. --RL0919 (talk) 21:36, 10 October 2019 (UTC)

Also, "In the news" section should be featured prominently and regularly updated (once a day). And giant boilerplate introductions like the one at Portal:History should go—we all know what history is, and if someone doesn't, he/she will go and read history. If these L0 portals become one of the best places on the Internet to read the latest news & high-quality articles about specific areas of knowledge, then I'll agree they have their place. That means they have to become "magazines" competing with various media outlets and blogs, with dedicated editors putting in a lot of work to make them interesting. — UnladenSwallow (talk) 15:18, 11 October 2019 (UTC)

To date, there hasn't been enough editor support for such frequent updates. We have to work with the reality of what editors are willing to sign up to do on a sustained basis. isaacl (talk) 20:00, 11 October 2019 (UTC)

Exactly. Which is the reason we should remove portals. — UnladenSwallow (talk) 22:37, 11 October 2019 (UTC)

Only if you expect portals to be magazines. Other interested editors may have less lofty goals. isaacl (talk) 17:27, 12 October 2019 (UTC)

For some topics, ITNs can be automated pretty easily. Others may be harder to automate, and some topics don't generate many ITNs. Similarly, some topics will have a lot of biographies to support a "featured biography" box, but others may not have enough featured bios. They important thing is to align to the showcasing concept, not that every specific type of item needs to be included on every portal. Context matters. --RL0919 (talk) 20:52, 12 October 2019 (UTC)

Unless the ITNs (when generated) are tagged with the topic/category, there will always be extraordinarily bad entries. — Arthur Rubin (talk) 00:47, 13 October 2019 (UTC)

Here's what I would do with your list of portals:

• Split North America portal and merge into Canada portal, United States portal, and Mexico portal (not every continent makes sense as a portal).
• Merge EU portal into Europe portal.
• Rename Biochemistry portal to Life Science portal, covering genetics, molecular biology, cytology, immunology, neuroscience (but not zoology, botany, ethology, which should be covered in Biology portal instead).
• Rename Computer programming portal to Software portal, expanding coverage to user interface design and software security & privacy.
• Merge Battleships portal into Engineering portal.
• Merge American Revolutionary War into United States portal.
• Merge Opera portal into Music portal.
• Merge city portals into their respective country portals.
• Split History of science portal and merge into respective science portals.
• Remove Systems science portal.
• Rename South America portal to Latin America portal, expanding coverage to Central American countries and Mexico (not every continent makes sense as a portal).

— UnladenSwallow (talk) 16:11, 11 October 2019 (UTC)

I don't agree with pre-defining a specific set of portals without engaging with the editors interested in those areas to see if they want to create and maintain those portals. I believe those interested in doing the work should define the scope of the work they want to do. isaacl (talk) 20:06, 11 October 2019 (UTC)

FYI

Hello to the members of this project. I noticed that the replacement of the Christmas portal with the Christianity one has led to the latter being a part of articles like Silent Night, Bloody Night, Robert L. May and Steam Railroading Institute which seems inappropriate. I guess the dilemma is that not every article about Christmas has to do with religion. I know portals have different guidelines than categories and I'm guessing it would be a major project to deal with this so whatever the members of this project decide will be fine but I did want to let you know about it. MarnetteD|Talk 05:10, 1 October 2019 (UTC)

@MarnetteD: at Wikipedia:Miscellany for deletion/Portal:Christmas, I proposed Portal:Christianity as the best fit. The only response agreed with that.

I agree that in some cases it was merely the least-worst fit, and in a few cases not a fit at all.

But when I set out to do the replacements, there were only 136 article-space links to replace. The overwhelming majority to me look worth keeping, but obviously editors should review any they consider problematic and WP:BOLDly remove those they consider inappropriate. The small size of the set means that it is not a big job. --BrownHairedGirl (talk) • (contribs) 23:53, 2 October 2019 (UTC)

Thanks for the info BrownHairedGirl. Your thought process sure makes sense and I'm glad to know that checking on this isn't as big a project as I thought. I've removed a few and this thread will alert other editors to be on the look out for any articles that may need looking at. MarnetteD|Talk 00:27, 3 October 2019 (UTC)

Glad that helped, @MarnetteD. I try to do the AWB run for each deleted portal as a single batch, to facilitate review ... but this is the first time that has actually been needed. So I'm kinda pleased that my self-discipline has had a use. --BrownHairedGirl (talk) • (contribs) 01:31, 3 October 2019 (UTC)

Sweet - synchronicity - serendipity BrownHairedGirl. One of these "S" words apply - or maybe all three :-) MarnetteD|Talk 01:35, 3 October 2019 (UTC)

In the 80s and 90s, if someone said "fuck" or "shit" on the TV it was hilarious. And we would cry out, sort of, if you weren't allowed to say these words on the TV at certain times, something must be wrong because it was hilarious and nobody got hurt. Now people can say "shit" all they want on the TV. People rarely want to and when they do, nobody even notices. We got what we wanted, but we can never have that fun time back because you'd have to take the freedom away and wait for so long, that everybody forgot anything ever happened anyway. We'd all be dead. And I am like, that movie is about Christmas, but what has Christmas got to do with that movie? But of course over here in English speaking Europe, Christmas meant movies like Star Wars and Mickey Mouse, Home Alone, Gremlins... I dunno where you get your movies from over in America though... And I suppose if it's different, there's only so many ways we can find out, like when we search up Christmas at Christmas trying to figure out what to do. And stuff. Apparently, in Japan, the tradition is to take your girlfriend to KFC at Christmas. Isn't that romantic? Wonder what they do for halloween. Probably watch Rudolf the Red Nosed Reindeer or something... Yes of course I'm watching it, what do you think I am stupid? I'm the one who says uh stupid! Nevertheless... ~ R.T.G 16:50, 14 October 2019 (UTC)

Duplicate portals for task forces

Is there a system for finding and fixing cases where a WikiProject banner has a portal for the main WikiProject, and the same portal associated with one of its taskforces? For example, this edit by BrownHairedGirl (talk · contribs) which resulted in {{WikiProject Pakistan|Islamabad=yes}} showing Portal:Pakistan twice. I fixed it, but how many other similar cases are there? --Redrose64 🌹 (talk) 18:06, 19 October 2019 (UTC)

@Redrose64: that's probably the only one done like that by me. My usual practice in cleaning up after a portal deletion is simply to remove the portal link from a project banner template; I don't recall what prompted me to try something different there, but AFAICR it was the only one.

In the last few months, the vast majority of such portal link fixes to WPbanners have been done by me, so that's probably a one-off. --BrownHairedGirl (talk) • (contribs) 18:56, 19 October 2019 (UTC)

Nomination for deletion of Template:Basic portal start page

Template:Basic portal start page has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Certes (talk) 16:22, 25 October 2019 (UTC)

Every portal should fall under a single specific WikiProject

I propose that every portal should fall under a single, specific WikiProject. If there is not either a single WikiProject for the topic of the portal, or a single WikiProject under which the portal would fall as a subtopic, then the portal should not exist. There should be no intersectional portals combining topic areas. An example of such a portal would be the recently deleted portal for "Television in Australia" (see Wikipedia:Miscellany for deletion/Portal:Television in Australia (2nd nomination)), or the current Portal:Football in Africa, Portal:Military history of Europe, Portal:Michigan highways, Portal:UK waterways, and Portal:Geography of Kenya. To the extent that these topics are important, they should already be covered in Portal:Association football, Portal:Kenya, Portal:United Kingdom, and the like. Similarly, to the extent that there is no Wikipedia:WikiProject Telephone, there should be no Portal:Telephones. bd2412 T 01:39, 17 October 2019 (UTC)

Oppose as per Wikipedia:WikiProject Council/Guide#WikiProjects do not own articles..plus most projects are dead because portals are not seen or have been deleted - thus no-one knows about projects anymore because portals are the only content namespace that we could recruit in. Looks like a set up for deletion crew over a rule to help portals get better.--Moxy 🍁 01:49, 17 October 2019 (UTC)

Tying portals more closely to projects would definitely help them get better. bd2412 T 02:16, 17 October 2019 (UTC)

Oppose proposal as worded. I have found the most useful aspect of portals is in enabling project editors to have an 'at-a-glance' overview of a topic and to use it to extend and improve coverage and balance of a topic. Portals are not articles so 'ownership' is not a factor; they are not owned by projects any more than the WikiProject pages themselves. So I think it makes huge sense that portals are supported and maintained by a WikiProject, but not to limit this to one portal per project. Why not take this in 2 stages: get portals under projects first. Then look at the support for and against one portal per project. Bermicourt (talk) 12:40, 17 October 2019 (UTC)

@Bermicourt: apart from the mega-navbox-style portals imported by you from de.wp, most portals barely even try to give an overview. They are crude, thin, magazines with a small selection of random highlights, often surrounded by forests of trivia such as fake DYKs and stale "news". Meanwhile, the head articles do give an overview.

I do agree that it makes huge sense that portals are supported and maintained by a WikiProject. However, a crude one-portal-per-project map doesn't work neatly, because some projects have very broad topics, such as WP:WikiProject North America. What we need is each portal to be actively supported by at least one active WikiProject. --BrownHairedGirl (talk) • (contribs) 20:23, 19 October 2019 (UTC)

Bear in mind, I am suggesting this as one step, not as a cure-all solution. bd2412 T 20:37, 19 October 2019 (UTC)

@BD2412: if you refine and simplify that one step to something simple like any portal must be actively supported by at least one active WikiProject, then I think you will have a good proposal to take to RFC. --BrownHairedGirl (talk) • (contribs) 20:49, 19 October 2019 (UTC)

@BrownHairedGirl:@BD2412:. Thanks, BHG, I agree. That makes a lot of sense. Bermicourt (talk) 09:54, 20 October 2019 (UTC)

• Oppose the exact statement but support the principle. The best scope of a portal may be wider or narrower than one wikiproject. Perhaps nominating a lead wikiproject would be a better implementation, even if it just defaults to the first one listed on the portal talk page. Let's encourage wikiprojects to get more involved with portals but not make an inflexible rule. Certes (talk) 13:28, 17 October 2019 (UTC)
• Oppose, completely arbitrary. Nothing wrong with topics like Portal:American Civil War, which is both USA-related and military history-related. Merging such portals into bigger ones risks losing their focus completely. Also, while WikiProject infrastructure is useful when creating and maintaining portals, it is not necessary. —Kusma (t·c) 13:58, 17 October 2019 (UTC)
• Comment - This just isn't feasible because WikiProjects indeed have died. About 15 years ago WikiProjects were booming. Now... they're not. WhisperToMe (talk) 16:30, 17 October 2019 (UTC)
• Support something like this in principle, tho the precise proposal needs some tweaking. I partly agree with WhisperToMe's observation. But the reality is that both portals and projects have mostly died. Even after abiut 7 months of deletions, and ~950 portals deleted, MFD is still looking at long-dead portals … and while checking out projects related to the portals under discussion in the last week or two, I have found that an alarming number of their related Wikiprojects are dead or barely alive.

I don't see any evidence to support Moxy's claim that portals have ever led editors to WikiProjects. Portals had low readership even when projects thrived, and talk page banners seem to me to be a much bigger gateway to WikiProjects (e.g. {{WikiProject Spain}} is on the talkpges of 40334 articles, but only 2686 article pages link to Portal:Spain. It seems to me that the death of WikiProjects is due to a bunch of other, bigger changes in the editor base and in editing practices.

However, portals need Wikiprojects to support them. Without that project engagement, portals either rot, or became the plaything of one lone editor.

The main remedy is to continue the work already done to reduce the number of portals, both by continuing to remove portals which lack active maintenance, and by setting a much higher threshold for the notion of "broad topic". That means for example, removing nearly all portals on cities and sub-national regions, and also adopting BD2412's idea of culling the intersection portals, but a lot more such culling is needed, e.g. of portals for many countries.

I think that BD2412 has chosen the wrong venue for this discussion, because the portals project continues to be dominated by the same small group of editors who have left portalspace to rot for a decade without even assessing the state of the existing portals. Many of them have repeatedly opposed the deletion first of TTH's portalspam, and then of long-neglected portals on narrow topics. Insofar as I can see any strategic vision from the poral enthusiasts, it seems to be a halfway house to TTH's full-automation: using automated excerpt generation to avoid rotting of content forks, but leaving content selection of generally unscrutinised portals in the hands of a small crew of portal fans, rather than as part of wider community processes with more eyes involved.

In Q2+Q3 2019, this page had an average of only 57 views/day, and a median of only 30 views/day, while WP:MFD averaged 215 views/day .. and that 215/day doesn't include the many views of the MFD subpages which are directly linked from MFD notices. That huge gap in viewing figures explains the huge chasm between between MFD outcomes and the opinions expressed on this project page. Basically, the wider community supports the culling which this project's groupthink opposes.

So any discussion here is highly unlikely to be in any way representative of a broad community consensus. It should be at a wider forum, such as the village pump. --BrownHairedGirl (talk) • (contribs) 20:13, 19 October 2019 (UTC)

• Oppose – A project about a topic being existent should not be a prerequisite for a portal about that topic to exist, as this just adds more instruction creep and bureaucracy, preventing the encyclopedia from being improved. Furthermore, Wikiprojects as a whole do not seem to be as popular as they once were, and in many cases, are not being utilized much, such as with talk page discussions about various matters. This would also equate to changing the goalposts for portal qualification in an unfair manner, whereby portals that already exist could immediately qualify for deletion based upon yet another new rule. In my view, requiring underutilized projects to exist for portals to exist doesn't fit in. North America¹⁰⁰⁰ 13:13, 7 November 2019 (UTC)

Perhaps put portals at the top?

Observing the slow decline of portals, I remembered a maxim on Reddit that few people read beyond the headline of a newspaper article before commenting. Despite numerous complaints from other Redditors and critiques of behavior, the trend keeps happening: people just read the headline and comment (without even reading other comments). There is an element of human nature that is sadly unchangeable. I think it goes to show that many humans are either very busy, or very lazy, or a combination of both.

The fact portals are placed at the bottom means that they cannot serve their supposed purpose, as their intended audience (in my view), the casual reader intending to see a short, easy to digest gateway into a topic won't see them; I would be very interested if the WMF is keeping track of how many people even scroll to the end of the article and what percentage do so.

I have read comments saying top-level articles like mathematics are better than portals, but many top-level articles are no longer short and easy to digest, and I don't see casual readers reading the whole thing to get the details of the subject, let alone go to the bottom of the page. I write many articles for scholars/people deeply interested in the subjects, but I think we as Wikipedians need to think with the casual reader, with an average level of education, in mind.

I strongly suspect that this human nature of not going to the bottom (for casual readers) is, in addition to the issues of displaying portals on mobile devices and Google now summarizing Wikipedia articles in its search engine, one factor on why portals with thousands of links are starved of readers. If portals are to survive, they should go to the top where readers first view the article, and if there are MoS restrictions that prevent that, either the restrictions go, or portals will be condemned to a slow decline for more years. WhisperToMe (talk) 11:44, 13 October 2019 (UTC)

If portals were to be given that much prominence, there would need to be a consensus that portals do indeed provide such a fine short, easy to digest gateway into a topic that they be highlighted at the top of the page. But given the generally abysmal state of design, content, construction and maintenance of wiki-portals, that case clearly fails.

Portals remain a solution in search of problem, which is why there are such poor pageviews for even the 8 portals linked from the top-right of the Wikipedia Main Page. That is one of the prime pieces of real estate on the whole of the internet: it's the key place on any internet page, and the main page gets an average of over 16 million views per day. Yet those 8 portals get between 1500 and 2300 daily views … so on average, only about one in 8,000 visitors to the main page follows a link to those portals. There's your measure of how little readers want portals, even when they are waved in the readers' face.

The enthusiasts for wiki-portals retain a faith that wiki-portals have some great inherent value, despite their demonstrable huge failings, and despite the web as a whole having largely abandoned portals for 20 years. They make lots of proposals to promote portals (mostly from a small set), but seem sadly undeterred by the evidence. --BrownHairedGirl (talk) • (contribs) 15:11, 13 October 2019 (UTC)

…so on average, only about one in 8,000 visitors to the main page follows a link to those portals. Wow. Now I'm even more convinced that portals have to go. These statistics show that users aren't using portals not because they're badly maintained—they simply don't want to click on these thematic links at the top. The search box is all they need. I guess most people think that these thematic links are some sort of article catalogs and decide (correctly) that it would be easier and faster to just type in what they need. So there's no need even for "L0" portals. — UnladenSwallow (talk) 04:46, 14 October 2019 (UTC)

Some data we did about the above.--Moxy 🍁 05:14, 14 October 2019 (UTC)

Thanks, Moxy! I really appreciate this confirmation. Yes, it seems to be the case that relatively few people even go that far down. Re: UnladenSwallow's comment, I'm wondering what level of readership would prove that a certain portal "works"? I see the point that a reader would generally just type in what he/she/they want(s), but a person unfamiliar with a technical topic may not be aware what the topic contains and isn't willing to wade through a lengthy, detailed article (the link above explains the issue). How do we serve him/her/them? WhisperToMe (talk) 13:06, 14 October 2019 (UTC)

Am I the only that thinks that one in 8,000 is actually quite a high number? Given how many people use Wikipedia, and how many readers don't ever see even the main page because they just click through article links after googling a certain person/business/thing, I'd say that's a higher than expected number of portal users. To me, that stat suggests a decent number of WP readers actually think there is a value to the portal and click through. It would be a much worse ratio if not, I already expected the 8k to be bigger and am fiercely against deleting portals. I think we are all probablt interpreting the figures to support our arguments, but I can't help see myself that I thought the portals were less used and still saw them as valuable. Kingsif (talk) 14:19, 14 October 2019 (UTC)

I agree the numbers show usage. Organizations that deal with disabilities recommend portal navigation when using Wikipedia as popups, categories and nav templates are not seen by the majority of our readers (over 60%) because of mobile view invitations. If portals were linked in info boxes and visible to even mobile readers - readership would most likely increase.--Moxy 🍁 15:08, 14 October 2019 (UTC)

Having a portal link in the top right would probably look quite good too - as it does on the talk pages that have them. Kingsif (talk) 15:17, 14 October 2019 (UTC)

Oppose The reasoning is specious since it is based on WP:OR. Some to many readers read the whole article - others scroll to the bottom to get to the external links. The precedence could lead to lets move succession boxes - navboxes - external links - and even categories to the top so that they will be seen. IMO a change to Wikipedia:Manual of Style/Layout like this will need a well publicized RFC. MarnetteD|Talk 15:32, 14 October 2019 (UTC)

Original research is allowed on talk pages in regards to article planning and setup, although article content itself shouldn't be OR, and decisions based on published references (and debating the validity of concrete facts) should use published sources. Thanfully one can find references about general/overall internet behavior. WhisperToMe (talk) 00:17, 15 October 2019 (UTC)

I know it is allowed. I also know it is guess work with no proof that it is actually the case for readers of our articles. Policy changes based on it is not the ay to go. MarnetteD|Talk 00:25, 15 October 2019 (UTC)

I feel that the study presented above about overall Wikipedia article reading behavior is helpful as proof as it summarizes overall trends: I am aware some people strategically look at some articles for particular purposes, but the internet has grown to encompass much of humanity now, and it's more helpful to think of the average Joe, not a person well-versed in Wikipedia (or even a person well versed at research at an undergraduate level) who is using it for a strategic purpose. WhisperToMe (talk) 00:34, 15 October 2019 (UTC)

Portals are already place in info boxes all over so no real change in policy would be needed.--Moxy 🍁 15:36, 14 October 2019 (UTC)

A) I've never seen a portal in an infobox. B) Being in an infobox is not the same thing as being placed at the top of the article and C) If you want the whole s**tstorm about portals to resume just start placing them at the top of an article without the RFC. MarnetteD|Talk 18:28, 14 October 2019 (UTC)

I agree that I don't recall seeing portal links from infoboxes (although there's a bit of everything around enwiki, so it has probably been done somewhere). And I also agree that putting links at the top of individual articles is a bit of a slippery slope. However, I do wonder why there is a fixed list of portal links at the top of the Main Page, when most of the other content there is changed out periodically. There were a lot of bad portals, especially after the big expansion of semi-automated portals, but there are even more bad articles, and that's not stopped us from having a rotation of TFAs, etc. --RL0919 (talk) 19:47, 14 October 2019 (UTC)

Sorry wrong wording I mean in Navboxes in the lead normally seen in academic topics like Genetics - Evolution - History of Canada etc..these are not seen in mobile view.--Moxy 🍁 20:34, 14 October 2019 (UTC)

I agree that having portals higher up would dramatically increase readership and spur editors to care about them more, ending most of the deletionists' complaints. Wikipedia is a work in progress, everyone knows that. Nothing bad would come of the portals being higher up in articles. Portals are the first thing on the Main Page, and used to essentially be the Main Page, for a good reason. Encyclopedias should be broken down by subject, with topic overviews, it's a wonder people think the search function is a decent alternative to finding out everything Wikipedia has on a certain topic. ɱ (talk) 15:59, 8 November 2019 (UTC)

Categorizing

Subpage of a failed proposal, Wikipedia:Portal/Guidelines/Categorizing brings a number of outdated information leading to WP: SMALLCAT, there is no need to create categories to include a single portal and its subpages. In a scenario of reduce portals and with the required categories already created I propose blank Wikipedia:Portal/Guidelines/Categorizing and tag with {{Historical}}.Guilherme Burn (talk) 15:23, 8 November 2019 (UTC)

If we tag as Historical then its status will be clarified and we don't need to blank the page. Certes (talk) 16:03, 8 November 2019 (UTC)

Impact of portals exclusions on portal space global pageviews

I regularly consult Wikipedia:WikiProject Portals/Popular portals and realize that even with the exclusions of over one thousand portals (some with over 1,000 monthly views) the global pageviews of the portal space have not decreased.

This may be an argument in favor of those who advocate fewer well-maintained portals.

Is there any tool that can quantify the evolution of pageviews more accurately?

I also realized that after upgrading the portals are more viewed, but still do not attract the attention of editors. Examples: Portal:Computer programming and Portal:Chess.Guilherme Burn (talk) 15:28, 12 November 2019 (UTC)

Request for comment

– North America¹⁰⁰⁰ 03:46, 13 November 2019 (UTC)

Separate portals from Wikipedia

Has it ever been considered, separating portals from English Wikipedia? We've got Wikinews, Wiktionary & other sister 'pedias. Perhaps portals (which are mostly ignored, by a vast majority of the community) should be given there own home. GoodDay (talk) 14:35, 28 November 2019 (UTC)

@GoodDay: It would be an interesting proposal on meta: - I believe the French pioneered portals to begin with, so let fr.wiki know too. WhisperToMe (talk) 00:55, 3 December 2019 (UTC)

No other Wiki is intended to be an entrée into Wikipedia topics. If portals were separated from Wikipedia, would we still have links to portals in several hundred thousand Wikipedia articles? It seems that something new would then be invented in Wikipedia to serve the function that portals are perceived to serve. BD2412 T 04:19, 4 December 2019 (UTC)

I don't think this idea would work well. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 04:49, 4 December 2019 (UTC)

I like the idea of portals showcasing work from all Wikimedia projects - most portals have featured images (from the Commons) and many used to have news feeds from WikiNews for example. I'd certainly support this. WaggersTALK 10:59, 31 December 2019 (UTC)

New main portal space page

I believe that after the divorce of the content pages with the portal space the ideal would be for the portal space to have its own main page. I suggest the example of the page in German language Draft:Portal:Wikipedia by topic.Guilherme Burn (talk) 18:18, 30 December 2019 (UTC)

Where has such a "divorce" been discussed? BD2412 T 22:11, 31 December 2019 (UTC)

@BD2412: here and here.Guilherme Burn (talk) 22:56, 1 January 2020 (UTC)

Okay, I thought you were referencing something on a broader scale than those discussions. BD2412 T 22:59, 1 January 2020 (UTC)

Removal of portal links from project templates without discussion

Has anyone else noticed this? I've now seen it happen twice. Espresso Addict (talk) 05:17, 28 January 2020 (UTC)

I have reverted a few saying "Restored....if there is a problem deletion or better yet fixing over orphaned is best" Best try not to hide if there is a problem.....best fix or seek deletion.--Moxy 🍁 05:33, 28 January 2020 (UTC)

Thanks, Moxy. It's very annoying that portals have been deleted on grounds of lack of hits, when removing links to them has been going on without discussion and in a manner which isn't very noticeable -- I don't watch project templates even in projects I'm intermittently active in! Espresso Addict (talk) 05:46, 28 January 2020 (UTC)

Yup low pages views used for deletion a few 100 times. Hard to get views or editors to improve them when orphaned on purpose ...MOS:BUILD - WP:ORPHANPROBLEM.--Moxy 🍁 06:10, 28 January 2020 (UTC)

• Diffs? DexDor ^(talk) 06:29, 28 January 2020 (UTC)

eg Portal Viruses: [1]. I don't know how many others have been removed. Espresso Addict (talk) 07:04, 28 January 2020 (UTC)

Little has happened in Portal: space during the ArbCom case and editors may have assumed that we've abandoned attempts to improve it. Portal:Viruses was improved this month and is ripe for the sort of transclusion makeover we're considering restoring elsewhere. We should probably involve the editors who've been removing the links. Paging Plantdrew, with whom I've worked well on other projects. Do we know of anyone else we should be discussing this with? Certes (talk) 11:56, 28 January 2020 (UTC)

As the long-term maintainer of Portal Viruses, I would strongly oppose making it over; I'd much prefer it quietly deleted. The medical project's leads are just not compatible with those of other projects (viruses, veterinary medicine) in style, tone and content; they focus principally on symptoms and treatment, not virology and pathogenesis, and are aimed at a somewhat different readership. I'm doing my best to update it fully at the moment, having spent some time trying to improve my other portal. Espresso Addict (talk) 20:04, 28 January 2020 (UTC)

Orphan box-footer subpages of portals

Please comment this MfD on {{box-footer}} remains from the past. Hopefully it's now kosher to discuss technicalities that should not bother anyone. Nemo 08:30, 30 January 2020 (UTC)

The way forward

For the benefit of anyone not watching the subpage, I've jotted down a few thoughts at /Tasks#January 2020. Certes (talk) 14:03, 30 January 2020 (UTC)

@Certes: that's excellent!!!! I have not read your page or your ideas yet. Just in case we disagree, I want to thank you now for taking the time and the effort to write about this, and to let us know about this. editor discussion, essays, and ideas, are the way to find a path forward on this. I seriously thank you for your energy in taking the time to put some ideas together. thanks!! Cheers!! --Sm8900 (talk) 15:39, 30 January 2020 (UTC)

New bug in excerpt transclusions?

Not sure where to place this query, but I notice that the words and link for Dubh Artach have mysteriously been swallowed from the Scottish islands portal transcluded excerpt. There doesn't seem to be any obvious reason for this in the article, and I am sure it was working at one point. Can anyone troubleshoot? Cheers, Espresso Addict (talk) 02:05, 31 January 2020 (UTC)

@Espresso Addict: I can't see the problem at the moment: a different island appears randomly instead. Do you mean that the excerpt begins "is a remote skerry..." without the words "Dubh Artach" and the IPA at the start? If so then this is due to the <onlyinclude> tag in Dubh Artach, which tells any page (such as a portal) transcluding that article to pick up only the section within the matched tags. Nothing appears to transclude it other than Portal:Scottish islands/Island, so I think the tag could be safely removed. Certes (talk) 09:01, 31 January 2020 (UTC)

Paging Knowledgekid87, who added the tag last October. Certes (talk) 09:02, 31 January 2020 (UTC)

Thanks, Certes -- before you pinged me I had just realised this might be the cause and removed the tags, which seems to have fixed the problem. Espresso Addict (talk) 09:06, 31 January 2020 (UTC)

Transclusion module

Module:Excerpt has a new release to handle wikitables better. The change is intended for non-portal use and should have little effect on this project, but please report any problems. Certes (talk) 12:55, 31 January 2020 (UTC)

New portal maintainers intros

Hi everyone. I suggest that any new portal maintainers leave a brief greeting here, or self-introduction, or whatever they may wish. just a suggestion. let us know the portal(s) you are watching. --Sm8900 (talk) 14:19, 31 January 2020 (UTC)

• sm8900 (talk · contribs), Portal: History. Hi everyone. I have signed up to watch Portal:History. Since I am already active on the WikiProject for this topic, it seemed only natural to take on the portal as well. I am still learning the ins and outs of how to run a portal. It will take a little while, but I am getting familiar with the functions and features there. Of course, anyone who wishes to make any edits there is welcome to do so. I appreciate the help and input of everyone here. thanks!! --Sm8900 (talk) 14:19, 31 January 2020 (UTC)

Portal introductions and transclusion

I've been discussing with Nemo bis whether portal intro sections should use Module:Excerpt transclusion from the main topic article. I don't think it is a great idea, for various reasons. I focus on country portals, as these are my main field of expertise (if any). Typical issues/non-issues I see with transclusion:

• Transcluding the entire lead section often results in a "too long" introduction
• Transcluding only parts of the lead section often leaves out entire subtopics (for example only demographics/geography, missing out on history/politics/economy/culture)
• Even if transcluding a certain number of paragraphs results in a good introduction for a portal now, there is no guarantee that this will be true tomorrow if the article's lead section gets restructured (so using Module:Excerpt means the portal will require regular maintenance to check whether the intro is still appropriate)
• Images: Module:Excerpt usually just gives a flag, no maps or other relevant topical images that a bespoke intro can provide.
• The standard advantage of transclusion is that content updates automatically and so does not go out of date (and I advocate use of transclusion for Selected Article teasers for BLPs and similar). However, for something like a country, there is typically very little need to update more than once every few years (unless you wish to include the current population and current government, but those aren't typically in the lead sections of country articles either).

Overall, I think that bespoke portal introductions (for example made by summarising an article's lead section) can be far superior to automated ones, and replacing them by Template:Transclude lead excerpt is only an improvement in certain cases. For an example, here is Portal:Mexico with bespoke intro and Portal:Mexico with transclusion. Can we get to some sort of agreement that transclusion is not a magic bullet and that we shouldn't rely on it for everything? —Kusma (t·c) 21:10, 28 January 2020 (UTC)

• Definitely! Agree with all the above points. It is also possible to summarise two or more articles in one introduction, which doesn't work well in transclusion. Also one can remove the kind of material that traditionally appears early in article leads but that isn't very important, eg a long list of alternative names. Espresso Addict (talk) 21:21, 28 January 2020 (UTC)

Agree ...but all are aware that you can pick which paragraphs out of the lead to transclude....can pick paragraphs 1 and 3 e.g Portal:Canada.--Moxy 🍁 21:54, 28 January 2020 (UTC)

Shit just noticed the edits removed shortcut and read more links to article....and in some cases broke the box format e.g. We need editors to not make mass flyby edits to portals.....as seen in the past year it has caused big problems like a few bans and even a desysopped. Thank god no cleanup of orphaned pages was done....looking over all the edits.--Moxy 🍁 22:14, 28 January 2020 (UTC)

Indeed. I wish everyone would just slow down, take care and discuss before making changes or hauling potentially salvageable portals to MfD. Espresso Addict (talk) 23:34, 28 January 2020 (UTC)

I'll take responsibility for my BHG reversions night before last. Not to call anyone a "liar", but despite her protests, there are many more out there [2], [3], [4], [5], [6], [7], [8], [9], [10], etc. (I stopped clicking at "S" country portals.) These were, IMHO (and at least in hindsight), bad faith reversions, a misuse of Twinkle, and should be undone. I have paused for now, but feel these will need to be reverted, or at the very least a null edit created to explain the misjudgement in BHG's edit summary on each such history. Future portal editors should not be made to feel intimidated by edit summaries like these; an explanation for such conduct is not unreasonable. I have stated my personal position on my talk. If I have made any "portalistas" here uncomfortable, I am truly sorry. BusterD (talk) 00:17, 29 January 2020 (UTC)

I suggest at very least dropping a courtesy note at the talk pages of the relevant Wikiprojects and leaving it for 48 hours or more before doing anything. Espresso Addict (talk) 00:25, 29 January 2020 (UTC)

That's sensible. BusterD (talk) 00:28, 29 January 2020 (UTC)

Still more to be instated.....not sure how anyone can think 10 edits in a 1 min is considered a thoughtful edit. Will look at more later.--Moxy 🍁 00:33, 29 January 2020 (UTC)

Bespoke introductions will normally be better, if they are maintained or the topic is so static that maintenance is rarely necessary. Excerpts have their place, but are better for presenting a random pick from fifty articles rather than the main topic. Excerpts can add a simple "Read more". If we want to use an excerpt but add other decoration, such as a border in a topic-related colour scheme, that decoration needs to be included around the transclusion either on the main portal page or as a subpage.

A few enthusiastic editors are already getting to work making improvements which had been reverted or put on hold. Everyone has good motives and I see no one doing anything that's obviously wrong, but we might benefit from pausing for a quick discussion to agree what should be done and to be clear that it has consensus. Now could be a good time to add any recent features in a standard way. For example, we might want to transclude a subpage with |showall= to show all excerpts on the editor-facing subpage but only one in the reader-facing main portal, as done for Portal:Speculative fiction/Selected biography. Certes (talk) 01:00, 29 January 2020 (UTC)

I checked all the edits before saving them and there's nothing "broken" in Special:Permalink/937866380 (a different box border is not something "broken", merely a stylistic preference; I found the white one better). The link to the lead article is provided by the first bolded occurrence of its title, but if that's not enough one can always suggest changes to the templates at the relevant talk page. Nemo 07:58, 30 January 2020 (UTC)

I think you miss understand Special:Permalink/937866380 removed the portlet for the intro. As for {{Transclude lead excerpt}} it has a |more parameter but it was not used (as it was on the orphaned subpages).--Moxy 🍁 23:37, 31 January 2020 (UTC)

Load times

I may be a bit impatient, but I often find the load times of some lua-heavy portals (say, the otherwise rather nice Portal:Canada and especially Portal:Canada/Indices) rather unbearable (and I sometimes get Wikimedia errors or timeouts). I just wanted to look at the Canada portal and had to use a different browser where I am not logged in and get cached content instead of having the page generated for me (which timed out for the indices page). For a similar reason, I just removed {{portal suggestions}} from Portal talk:Germany: it slows down loading that page by several seconds, and we (the maintainers of Portal:Germany) know how to find that information or actually have special subpages that use lua transclusion. I think it would be useful to try to keep Lua runtime under a second or so (unless good reasons exist to exceed that). —Kusma (t·c) 20:32, 4 February 2020 (UTC)

I could put it all on sub pages....but the pages listed above like Portal:Canada/Indices

(Page length in bytes 13,483) are absolutely tiny compared to some articles. Do you have problems with say.... United States (Page length in bytes -413,442) that is 10x the size and at the transclusion template limit? Does Lua work the same for all? I ask because Portal:Canada loads much much faster then the article Canada does for me. I am eager to solve accessibility problem.... and make sure we put anything we can help come up with in the accessibility guideline.--Moxy 🍁 22:47, 4 February 2020 (UTC)

Some portals load slowly because they run a lot of Lua code. The page size does not always reflect the complexity. For example, a template usage taking 100 bytes might read a list article and generate excerpts from fifty other articles listed there ready for the reader to browse between them. The limit before getting timeout errors is ten seconds, but I agree that we should aim to have portals load much more quickly than that. One technique which we were just starting to try when development paused was having complex portal elements (like that template usage) use two subpages. One subpage contains the template code; the other holds the expansion of the template and is updated by a bot every hour/day/week. The portal can then read in the expanded version without having to run complex Lua code on demand. Certes (talk) 01:01, 5 February 2020 (UTC)

This is Portal:Canada/Indices according to the HTML source:

NewPP limit report
Parsed by mw1332
Cached time: 20200205062224
Cache expiry: 21600
Dynamic content: true
Complications: []
CPU time usage: 8.632 seconds
Real time usage: 9.292 seconds
Preprocessor visited node count: 18291/1000000
Preprocessor generated node count: 0/1500000
Post‐expand include size: 1334998/2097152 bytes
Template argument size: 497045/2097152 bytes
Highest expansion depth: 16/40
Expensive parser function count: 15/500
Unstrip recursion depth: 0/20
Unstrip post‐expand size: 46930/5000000 bytes
Number of Wikibase entities loaded: 0/400
Lua time usage: 7.381/10.000 seconds
Lua memory usage: 22.05 MB/50 MB
Lua Profile:
    Scribunto_LuaSandboxCallback::match                             4700 ms       64.0%
    Scribunto_LuaSandboxCallback::gsub                               880 ms       12.0%
    ?                                                                440 ms        6.0%
    Scribunto_LuaSandboxCallback::getContent                         320 ms        4.4%
    Scribunto_LuaSandboxCallback::find                               180 ms        2.5%
    Scribunto_LuaSandboxCallback::sub                                160 ms        2.2%
    recursiveClone <mwInit.lua:41>                                   140 ms        1.9%
    Scribunto_LuaSandboxCallback::expandTemplate                     100 ms        1.4%
    Scribunto_LuaSandboxCallback::getExpandedArgument                 80 ms        1.1%
    type                                                              60 ms        0.8%
    [others]                                                         280 ms        3.8%

versus Portal:Speculative fiction:

NewPP limit report
Parsed by mw1261
Cached time: 20200205062452
Cache expiry: 2592000
Dynamic content: false
Complications: []
CPU time usage: 1.164 seconds
Real time usage: 1.763 seconds
Preprocessor visited node count: 7418/1000000
Preprocessor generated node count: 0/1500000
Post‐expand include size: 688934/2097152 bytes
Template argument size: 29543/2097152 bytes
Highest expansion depth: 22/40
Expensive parser function count: 80/500
Unstrip recursion depth: 0/20
Unstrip post‐expand size: 1392/5000000 bytes
Number of Wikibase entities loaded: 0/400
Lua time usage: 0.331/10.000 seconds
Lua memory usage: 4.72 MB/50 MB

The "real time usage" is time the server takes to prepare the page. From my request until the page is loaded can easily take a lot longer. In any case, the Speculative fiction portal feels responsive, and the Canada portal feels sluggish. With its tabbed design, clicking on the tabs should give a much faster response. As it is, it works far better if you are not logged in. —Kusma (t·c) 06:34, 5 February 2020 (UTC)

If loading the page takes longer than stated but only when logged in, perhaps user Javascript or gadgets are taking time. For example, I use a tool which colours redirects and links to dabs differently. On an average page it runs too fast to notice but it can take several seconds to colour an enormous list. Bear in mind that scripts also process text which is not visible by default, such as selected articles beyond the one initially displayed. It may be fairer to judge a portal's performance by the time it takes to render for the typical, logged-out reader. That said, 9.292 seconds is too long. We might cut it down by preparing sections in advance with a bot. We discussed this possibility at BOTREQ but progress seems to have stalled. Certes (talk) 12:03, 5 February 2020 (UTC)

OK this is way above my pay grade....what can I do right now to solve the problem at the Canada portal "list of articles page"?--Moxy 🍁 02:23, 6 February 2020 (UTC)

Split it. The main portal shows one FA, one featured bio, etc., which is fine. /Indices shows all FAs plus all featured bios plus other sections, which is too much. One page for all FAs, another page for all bios, etc. would leave us with a reasonable number of sensibly sized pages. Certes (talk) 10:19, 6 February 2020 (UTC)

Convert a main page portal in a single-page layout

I would like to convert Portal:Geography to the single-page layout, to have a single-page model among the most accessed portals. But I fear that like other portals I converted, it will be summarily reversed. How are the discussions on portal automation going? I made some edits to Portal:Religion in that way.Guilherme Burn (talk) 14:07, 18 February 2020 (UTC)

I don't think you will be summarily reverted, although you should probably double check what should be fully automatic and what should be at least semi-manual. I don't like the "popular pages" section at Portal:Religion very much, for example, as it includes pages like Thomas Cruise that maybe aren't too relevant to the portal. The News and DYK choices are also a bit simplistic. For Portal:Geography and other high and top-level portals, I think navigating to the many quality sub-portals should be an important goal (make a box with a random portal?), maybe more important than elaborating on geography as a science. —Kusma (t·c) 14:44, 18 February 2020 (UTC)

Really. I agree with what you said. To be honest in my view, News, quotes and selected pictures are not very useful sections for the portal concept of connecting readers to wikiprojects and delivering a graphical view of contents. For the DYK and "popular pages" the sections are very useful for this purpose, but I cannot refine the search with the current tools.Guilherme Burn (talk) 15:00, 18 February 2020 (UTC)

@Guilherme Burn: I don't think any improvements have been reverted this year. I'm treading very gingerly but it seems safe to resume editing. Would a search like this be useful? (You may want to change the years.) Certes (talk) 17:20, 18 February 2020 (UTC)

List option

Transclusion templates now have a |list= option to add a collapsed list of candidate articles. See Portal:Liquor for an example of its use. There are concerns about its appearance on mobile, so the implementation may change. Certes (talk) 17:36, 1 February 2020 (UTC)

Great update! I had been imagining this for a while. I have a suggestion Would it be possible to include icons like in Portal:Computer programming?Guilherme Burn (talk) 18:35, 1 February 2020 (UTC)

Thanks! Associating a different icon with each list item and keeping them up to date might be difficult, but if anyone has ideas for doing it without overloading an already complex module we could consider it. Certes (talk) 21:12, 1 February 2020 (UTC)

@Certes: How was the display of this template on mobile devices? I think that if the list could be displayed with one item per line it would be more elegant and less confusing.Guilherme Burn (talk) 14:11, 18 February 2020 (UTC)

@Guilherme Burn: Collapse (show/hide) doesn't work on mobile, so the whole list is shown (expanded). That's not ideal but it's probably tolerable when the list is compact. With one item per line, the list might overwhelm the page on mobile. Certes (talk) 15:23, 18 February 2020 (UTC)

Great work by Certes to provide more options for portal pages to be improved. Thanks, North America¹⁰⁰⁰ 19:57, 1 February 2020 (UTC)

• Interesting! Thanks, Certes. Is there any chance of having more customisation in the way it appears? It doesn't mix well with the "More selections" text link I've been using, though I suppose it is meant to replace that? Personally I view the "More selections" archive a lot, and would be sad to lose it; perhaps it could be wrapped in as "view all on one page"? Also, unless the items are placed in some logical order (alphabetical, chronological, by topic...) the result appears a bit messy and is hard to navigate; though that's not the fault of the new development, of course, it does make it more visible to those who don't habitually click the edit tab. Espresso Addict (talk) 04:05, 2 February 2020 (UTC)

@Espresso Addict: I'm sure we could sort something out. A good plan might be to mock up something that looks right manually, either by repeating the list in a real portal or in a sandbox, and we'll see if we can make the module produce similar wikitext automatically. We could have sort options, but perhaps it's better for the editor maintaining the portal to list the articles in the order they prefer. Certes (talk) 11:31, 2 February 2020 (UTC)

Thanks, Certes -- What would be nice as an option would be a discreet link/box that could tuck in at the bottom right/left under the image, but expand to fill the full width if someone clicked or pressed show or something. Ideally that also allowed an optional link to "view all on one page", but that might just be me. the other thing I'd mention as a nice-to-have would be ability to colour the bar to match the portal colour scheme, if desired. By the way, I wasn't trying to suggest that the module should try to sort on the fly, that would presumably be a bit wasteful, but rather that portal maintainers who adopt this useful innovation need to be aware that it exposes their undercarriage. (I noticed my attempt at alphabetisation was out, probably because an article had moved since I last looked.) Cheers, Espresso Addict (talk) 23:51, 2 February 2020 (UTC)

I think we need help from a CSS expert, preferably one who has a clue about mobile presentation. Certes (talk) 00:49, 3 February 2020 (UTC)

• Pls see User talk:Scottywong/Portal guideline workspace#Outstanding technical problems.--Moxy 🍁 00:02, 3 February 2020 (UTC)

It would be interesting to implement a similar gallery for the image templates. I wanted to open a topic about this, but I need to mature the idea, basically today none of the ways to display images on portals is satisfactory.Guilherme Burn (talk) 10:49, 18 March 2020 (UTC)

Portal:COVID-19

As part of the ongoing project, I've created the Portal:COVID-19 to be an overview - help improve it if you're interested! Kingsif (talk) 15:23, 18 March 2020 (UTC)

Thanks, but can we possibly move the new portal to Portal:Coronavirus disease 2019? I think there is broad consensus that Portal titles should match the title of the head article, not the WikiProject. If there are no strong objections, I will move the portal myself. Best, UnitedStatesian (talk) 15:39, 18 March 2020 (UTC)

 Done Kingsif (talk) 15:42, 18 March 2020 (UTC)

Thanks K. UnitedStatesian (talk) 17:08, 18 March 2020 (UTC)

Two more portals (Portal:Coronavirus disease 2019, Portal:Pandemic) that will soon be abandoned and without readers. I believe that after all the discussion about narrow topic in portals, the ideal would be to update the Portal:Viruses to alert about these very important issues now, but which will soon be narrow.Guilherme Burn (talk) 17:27, 19 March 2020 (UTC)

I don't know about Pandemic, but you're wrong about the COVID-19 portal. It's also a different scope to Viruses. So, no. Kingsif (talk) 17:52, 19 March 2020 (UTC)

It appears User:Guilherme Burn was proved prescient; the subject matter could only support one portal. BusterD (talk) 22:48, 20 April 2020 (UTC)

Actually, he said both would be gone, and I said COVID-19 was more use than Pandemic... I think that means I was right, no ;) Kingsif (talk) 23:45, 20 April 2020 (UTC)

Ooops! I misread the date stamps. You are correct. I think this portal is unlikely to be without readers for some time. Great job as I've said below. BusterD (talk) 02:28, 21 April 2020 (UTC)

Portal:Coronavirus disease 2019

I'd like to say nice things here about the editors performing an enormous public service in creating and improving this impressive portal. Good work. I'd like to ask those interested (and those involved) to talk about what works here, what choices were successful and what we can learn from this unique situation. I'd like to see positives at this stage. (we can certainly learn from negative comments at some point, but it seems we've been over-focused on this for some time.) Is anyone else interested is learning how an impressive and enlightening tool is created and maintained? I sense an opportunity to learn something from pragmatic choices. BusterD (talk) 22:48, 20 April 2020 (UTC)

Would you like to hear things about the choices in what was included and the layout? I'm sure Moxy and I could share something on that. Kingsif (talk) 23:47, 20 April 2020 (UTC)

This portal showed how to build a good portal without the need for a forest of subpages. I liked the layout of the Images section. Good job ;).

I would like to suggest replacing Portal:Coronavirus disease 2019/box-header per Template:Box-header color.

I would also like to question the exaggerated protection in the portal space, most of the most visited portals (like this one) do not allow editing by IPs, this can be a factor that keep editors away.Guilherme Burn (talk) 00:10, 21 April 2020 (UTC)

Well my first thought when making it, as the portals in other languages have followed, was to be informative, rather than promotional. A lot of portals are trying to promote articles, but for this it was designed to be like a one-sheet on the most relevant and helpful coverage the wikiproject churned out. The best way to do that was to use transclusions, given the ever-changing nature of the top articles. The actual articles to be highlighted don't need changing, so no subpages are needed. The images section was added by Moxy I believe, and moved to its location to ease readability, creating a visual 'break' so readers don't feel fatigued from so many words on screen.

Protection is to stop vandalism and misinformation that the subject draws, unfortunately. The header color was something else I think Moxy introduced; I think it is nicer than the blue and white of the Medicine headers used before. Kingsif (talk) 00:28, 21 April 2020 (UTC)

Agree best to display top level vital articles of educational value over jamming the portal with every article we have. As for color.....I just used the project colors that have a AAA rating for accessibility and contrast. I've always thought softer colours are more appealing and authoritative. It is what people are use to because it's what our main page uses ( Pastels).PS Template:Box-header colour default fails Color Contrast Accessibility-Moxy 🍁 02:37, 21 April 2020 (UTC)

Well done everyone for getting a portal on such an important topic built professionally and quickly. Just after doing the work is the best time to create a simple "how-to" guide. I don't foresee a significant number of new portals being created, but some older portals which present good content in a clunky way could usefully be rebuilt along these lines. Certes (talk) 12:37, 21 April 2020 (UTC)

What is the purpose of this portal?

When we were discussing portals on the Scottywong subpage we were coming at the subject in the abstract. Now that we are discussing a concrete new creation, I'm wondering, do we think any differently about this portal's purpose? I'm particularly interested in what the creators were thinking. BusterD (talk) 18:44, 22 April 2020 (UTC)

Well, it still shows off quality content, but it has a functional purpose for readers. Overviews of all the high-trafficked pages with recent news and updates. A one-sheet that can also serve as the portal in years to come. It may be a little more tied to current events than other portals, but still a portal IMO. Kingsif (talk) 18:53, 22 April 2020 (UTC)

As someone who was watching in real time, it appeared to me that there was an effort made to make a complex subject matter accessible to a normal reader. There are a number of charts, tables and graphics which command the attention and make the page visually more compelling. These graphic elements are not only stimulating and enlightening, but also have the effect of making the subject matter easier to grasp without dragging the average reader into over complex descriptions using precise wordings and jargon. This is no knock on the contributors to the primary subject matter pagespaces, quite the contrary. BusterD (talk) 04:00, 23 April 2020 (UTC)

Merge portals for better portals?

Wouldn't it be interesting to join themes in portals for broader portals? For example:

• Portal:Myths + Portal:Religion = Portal:Religion and belief systems
• Portal:Energy + Portal:Renewable energy + Portal:Wind power = Portal:Energy industry

I have already opened some individual discussions, but they were immediately seen as deletionism, and some editors prefer the maintenance of moribund and obsolete portals to trying something new.Guilherme Burn (talk) 13:45, 24 April 2020 (UTC)

Oppose both merges as deletionism. These are solutions in search of problems. BusterD (talk) 14:10, 24 April 2020 (UTC)

Just as I said above, there is a group of editores willing to keep their toy portals intact with their particular views on what a portal is. If a page that displays the same single article for fifteen years (Portal:Myths/Selected Myth), or portals that shows the same redundant articles is not a problem. I don't know what it is.Guilherme Burn (talk) 14:46, 24 April 2020 (UTC)

• Oppose – These topics are all rather extensive in depth and coverage, and are worthy of portals devoted to their respective core topics. Merging into broader scope portals would present a watered-down overview for these topics, cramming everything together into one portal unnecessarily. North America¹⁰⁰⁰ 17:05, 24 April 2020 (UTC)
• Oppose - this is just watering down portals to reduce the overall numbers. And your first one is very unlikely to gain consensus. You may consider all religions to be myths - we're all entitled to our own worldview - but there are millions of people who would disagree with that across the world, including, I suspect, many current Wikipedia editors as well as numerous sources lol. Bermicourt (talk) 14:10, 25 April 2020 (UTC)
• Support Portal:Wind power → Portal:Renewable energy. No comment on others. Rehman 03:21, 19 May 2020 (UTC)

Proposal to shut down or reform this WikiProject

The discussion has been closed and archived to Wikipedia:Administrators' noticeboard/Archive307

I know, me proposing shutting down a WikiProject I'm in? What am I thinking? Well, I mainly joined to make sure things would go smoothly after that RfC to delete all portals - clearly it has not. As thus, I think a solution (among the others) would be to shut down the WikiProject responsible for many of the bad portal creations. Right now it appears all its doing is creating new portals, not maintaining or improving them - which is what a WikiProject is supposed to do. However, a less extreme solution would be to reform the project to actually maintain and improve the portals it creates, and creates portals sparingly. I'm fairly certain a task force making sure portals meet standards would be beneficial to the issue, and also making it clear that not everything needs a portal. I'm going for the latter option to reform - however, I'm going to leave the shutdown option up in the air in case people find good reason for it to be considered. Addendum 13:48, 15 March 2019 (UTC) - Since I forgot to clarify ( Self-trout) here's two examples of reforms I could see being useful: A quality scale for portals, like we use for articles - this could help with knowing which portals are good and which ones need improvement Dividing the Project into task forces to make sure necessary tasks for the maintenance of portals are completed, as right now they clearly are not Sub-reform for this would be to make a task force that deletes bad portals that don't meet quality standards and are not needed Hopefully this can help clarify this proposal somewhat - if none of these can be done reasonably (which I doubt they can't) the shutdown option should be considered. Kirbanzo (userpage - talk - contribs) 23:01, 14 March 2019 (UTC) Survey on sub-proposal to shut down WikiProject Portals SNOW No The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion. Neutral as per above. Kirbanzo (userpage - talk - contribs) 23:01, 14 March 2019 (UTC) Strong oppose firstly this is the wrong forum, secondly there is nothing in the nomination that explains why this is needed, or how it will result in an improvement to the encyclopaedia. Thryduulf (talk) 01:04, 15 March 2019 (UTC) Oppose. Abyssal (talk) 01:35, 15 March 2019 (UTC) Support: might as well. --K.e.coffman (talk) 02:23, 15 March 2019 (UTC) Oppose. There is consensus to keep the portal system but it has many faults, so a focus for improving it seems sensible. Certes (talk) 14:36, 15 March 2019 (UTC) Strong oppose. Not necessary and not the best way to fix Wikipedia’s portals. — pythoncoder  (talk | contribs) 19:49, 15 March 2019 (UTC) Oppose – Would amount to throwing the baby out with the bathwater. North America1000 01:19, 16 March 2019 (UTC) Oppose For the same reasons. — AfroThundr (u · t · c) 19:48, 16 March 2019 (UTC) Oppose For the same reasons. Bermicourt (talk) 22:37, 16 March 2019 (UTC) Support Incompetent project that doesn't want to deal with the crud their members create. CoolSkittle (talk) 18:07, 17 March 2019 (UTC) Invalid rationale. See Wikipedia:Arguments to avoid in deletion discussions#Surmountable problems.  — SMcCandlish ☏ ¢ 😼  20:58, 17 March 2019 (UTC) Oppose as ad hominem vindictiveness. The only rationale for deleting such a project would be a proper community-wide decision to eliminate all portals. This is not the venue for that; WP:VPPOL is. And this is not the venue for deletion of a wikiproject; WP:MFD is. WP:Process is important, most especially in deletion discussions and related matters, because damned near zero people are going to look for such discussions in an admins' "house organ" page like this. Hardly any non-admins watchlist this page or pay any attention at all to what is said here. It is not intended to be a venue for community-wide concerns in the first place, and even with belated addition to WP:CENT, discussing such matters here is a special kind of forum shopping, namely an attempt to appeal to a small cadre of specialist editors whose concerns about maintenance (and cop-like role of "going after" people for alleged behavioral flaws, often with little oversight, especially compared to WP:ANI process) will colour everything they do and say about the matter.  — SMcCandlish ☏ ¢ 😼  20:58, 17 March 2019 (UTC) Widely misleading arguments. This is a widely advertised and widely participated discussion. It came from a VPR discussion, linked from the very beginning. There are far more non-Admins than Admins involved here. Try to stick to facts. Legacypac (talk) 23:23, 17 March 2019 (UTC) Support [non-admin comment :] opposed to portals, they harvest legitimate contributions yet the creators expect them to be automatically protected as legitimate contributions and outside of normal guidance on creation. There are cadres of users who think this is what wikipedia is about, or at least it is a way of making a big splash without knowing anything but how to tweak code (and then wikilawyer when challenged). cygnis insignis 06:10, 18 March 2019 (UTC) Oppose Punishing a whole community for the actions of one person is not reasonable. WaggersTALK 16:49, 18 March 2019 (UTC) Oppose per above. It's getting cold out... SemiHypercube 16:52, 18 March 2019 (UTC) Oppose In the grand scheme of things I'd like to see portals deprecated, but doing so is not where the community is at right now. If there is consensus to keep portals, having a wikiproject to maintain them seems like a good idea. I also feel cold... Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 06:47, 19 March 2019 (UTC) The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion. Survey on sub-proposal to reform WikiProject Portals Support as proposer and per above. Kirbanzo (userpage - talk - contribs) 23:01, 14 March 2019 (UTC) Oppose as the proposal is in the wrong forum and contains no details of what reform is being suggested, let alone how these reforms would solve the issues identified. Thryduulf (talk) 01:05, 15 March 2019 (UTC) This is related to the discussion as the WikiProject is headed by the user being discussed here. Kirbanzo (userpage - talk - contribs) 13:48, 15 March 2019 (UTC) Wikprojects are a collection of editors, not just one person. There is no evidence presented that there is any admin action required regarding the WikiProject as a whole collectively (not that I can immediately think of what that action could look like if it were), and there isn't even consensus that admin action regarding the single editor is required. Thryduulf (talk) 13:57, 15 March 2019 (UTC) Fair point, but considering the discussion below it should still be considered. Kirbanzo (userpage - talk - contribs) 14:00, 15 March 2019 (UTC) Support. I’ve been doing some reform work of this type by creating a page to clean up some of the damage done to the older portals. WikiProject Portals has an assessment page but I’m not sure how much it gets used. — pythoncoder  (talk | contribs) 19:49, 15 March 2019 (UTC) It took quite a lot of discussion to form a consensus for those assessment criteria. Any portals would need to be evaluated against them to ensure they meet at least minimal quality standards (not including the other criteria in the portal guidelines). It will take a while to go through all of the portals and rate them on the quality scale, and that is one of our backlog tasks. — AfroThundr (u · t · c) 19:48, 16 March 2019 (UTC) Support in theory. It makes more sense than the above "I disagree with you so I will try to just erase you" bullshit. However, it's not at all clear that the wikiproject, as such, needs any "reform"; rather, some specific decisions and actions taken by its participants have turned out to be controversial, and the community will discuss that (hopefully in a more sensible venue like WP:VPPOL), and the wikiprojects should abide by the result of that process. We don't have any indication this would not happen, so there isn't actually a "reform" to perform, nor is there yet any consensus of what form that should take anyway. Some people here seem to be under the impression that WP is going to come out against portals; others that it'll be against automated portals; others that it'll be against portals on minor topics (and sub-sub-sub-topics) that people aren't likely to seek a portal for; others that nothing is actual broken; others that .... There isn't a single direction of "reform" being proposed.  — SMcCandlish ☏ ¢ 😼  21:03, 17 March 2019 (UTC) Oppose The way to reform a project is to get involved with it. We've already had multiple discussions about how the project should be structured and how it should operate on the project pages themselves, and further suggestions there are always welcome. But proposing "reform" without specifying what particular changes are being suggested isn't exactly helpful. WaggersTALK 16:53, 18 March 2019 (UTC) Exactly right, Waggers, exactly right. You've hit the nail on the head. ~Swarm~ {talk} 18:22, 20 March 2019 (UTC) But is you see little need for portals why get involved? Legacypac (talk) 23:18, 21 March 2019 (UTC) Nominating hundreds of portals for deletion is getting involved. If you see little need for them then fine, live and let live, they're not doing you any harm. The community has decided to keep portals, so either you respect that consensus and ignore them, or you respect that consensus and get involved with resolving whatever problem you have with them. WaggersTALK 12:58, 3 April 2019 (UTC) Qualified support. The current project is far from perfect but it's hard to give unqualified support without a statement of specific reforms. We don't want thousands more portals, but last year's RfC shows that it would be equally inappropriate to "reform" into WikiProject Nuke All Portals From Orbit. I removed my name from the project's roster when portal creation grew rapidly. Since then I have done some maintenance but I see little point in improving pages that other editors are working so hard to delete. I could rejoin a project that combined improved existing portals with the right blend of identifying poor, narrow portals for deletion and creating portals in small numbers where clear gaps exist. Certes (talk) 13:32, 29 March 2019 (UTC) Qualified support per @Certes:. As a participant in the Portal project, I would encourage them to adopt a more rigorous process for creating new portals, including qualifying criteria, and also for the maintenance of portals by the relevant project members. I'm disappointed that, while this discussion is going on, at least one portal that I help with has been nominated for deletion (it's not one of the automated portals created by TTH which is subject of a deletion nom that I support). Bermicourt (talk) 11:45, 13 April 2019 (UTC) Discussion on proposal to reform WikiProject Portals Query @Kirbanzo: - do you have any early thoughts about what some good reforms would be to shift the primary focus of the project towards maintenance/improvement over creation? Nosebagbear (talk) 23:11, 14 March 2019 (UTC) See addendum. Kirbanzo (userpage - talk - contribs) 13:50, 15 March 2019 (UTC) Transcluded to Wikipedia talk:WikiProject Portals. {{3x|p}}ery (talk) 23:36, 14 March 2019 (UTC) No, do not transclude important discussions from AN to the relevant talkpage. Hold the discussion on the relevant talk page. Transclude to here is there is good reason, which there is not. Holding hte discussion here means watchlisting it doesn't work, and it wont be archived in the right place. Shutting down a WikiProject is not in scope for WP:AN. --SmokeyJoe (talk) 02:20, 15 March 2019 (UTC) The Portals Wikiproject members can't even come up with a proper new guideline for what topics get a portal even when faced with a village pump imposed moratorium. The discussion is all over the place with no focus. Heck they did not even follow their old guideline about picking subjects broud enough to gain reader and editor interest. The only thing they appear to agree on is MORE MORE MORE and using WP:VITAL as a to do list. Their newsletter said they are pushing to 10,000 portals (off a base of 1500 old line portals). Now the number of portals will shrink until and unless they get new guidelines passed by an RFC. Legacypac (talk) 09:57, 15 March 2019 (UTC) That old guideline wasn't generally followed, ever. That's because portals (except those on the main page) get about 1 to 3 percent of the amount of traffic that their corresponding root articles get. In other words, "not a lot". That's because almost all their traffic comes via WP internal links. Almost nobody googles "Portal". So, for the vast majority of topics, large numbers of readers and editors will never be forthcoming, and never were. Out of the 1500 portals, about 100 had maintainers (maintained by around 60 editors), and maybe 20% of them regularly edited the portals they maintained. The WikiProject, and the community, need feedback in the form of hard numbers, in order to get a sense of what will even get used. How hard would it be to make a chart listing all the portals in one column, and their page views for the past month in the second column, and then sort the chart by the second column? That might provide some insight.    — The Transhumanist   11:05, 15 March 2019 (UTC) Sigh. :TTH, you had this data already. You know that portal pageviews are miniscule. At the RFC on deleting the portal namespace, stats were posted on pageviews, and not even all the portals linked from the front page had decent viewing rates. Yet despite knowing all that, you personally created thousands of new portals, despite having all the evidence in front of you that they are useless. And when I presented the evidence to you again, and asked you to desist, you were furious. Instead of assessing the issues, you posted multi-screenfull unfocused ramblings replete with shouts of "bias", "personal attack" etc. The problem is not any shortage of information. The problem is that as @Legacypac notes above, the discussions in the WikiProject have no focus, no regard for available evidence, and no respect for community consensus. Legacypac and usually disagree, but in this case we see exactly the same problem: a WikiProject which has a long and sustained track record of being utterly incapable of acting responsibly wrt the page within its purview. This is not solely TTH's doing. TTH bears by far the highest responsibility because TTH has been both the most prolific creator and the most angry objector to calls for restraint, but several other regulars at WikiProject Portals have been equally unfocused and equally bonkers. For example: Only 15 days ago, WT:Portal/Guidelines#Portal_creation_and_deletion_criteria_proposal_5: a proposal to create portals up to VA Lelevl 5, when even VA level 4 would be about 10,000 portals. 17 days ago, WT:Portal/Guidelines#Portal_creation_and_deletion_criteria_proposal_1: a proposal for portals to have minimum of only 20 articles. Precisely the sort of microportal of which the community has had enough. So the community simply cannot rely on this group to set and uphold resposnsible guidelines. --BrownHairedGirl (talk) • (contribs) 11:53, 15 March 2019 (UTC) @BrownHairedGirl: I make the proposal 5. And it was a proposal. I Support a reform in WikiProject Portals. My idea is the existence of approximately 1000(level 3) single page portals layout, directly linked in tree model with the main page. The role of the wikiproject should be to organize this tree and develop tools to transform all portals into single-page layout portals.Guilherme Burn (talk) 12:11, 15 March 2019 (UTC) @Guilherme Burn, no technical diversions. My point is not about how the portals operate; it's about their scope. And 20 pages is insanely narrow. A 20-page portal is just an bloated navbox. --BrownHairedGirl (talk) • (contribs) 12:36, 15 March 2019 (UTC) @BrownHairedGirl: I'm trying to figure out how you've come to the conclusion that WPPORT completely ignores evidence and consensus. The project discussions I've participated in have been rational and reasonable, and far from unfocused. Also, please try not to conflate individual editors' behavior with the project as a whole. I've seen no evidence that the WikiProject has acted irresponsibly regarding the Portal system. If you're referring to the several thousand new portals created by TTH, you should keep in mind that WikiProjects don't have any actual authority to dictate who can and can't create something (even if we were opposed to creating new portals). That's what guidelines are for. We've been working to develop updated criteria for the Portal guidelines since November (rebooted from even earlier discussions in April) - which you already know, since you've participated as well. We're still working on the guidelines so that we have better, more concrete criteria to judge new and existing portals against (and which would make MfD easier for those that fail). Once we've developed consensus on these, they can be applied to the namespace to fix the portals that can be fixed, and remove the ones that can't (new or old). (Side note: Anyone with input or ideas is welcome to participate at WT:PORTG.) Actions in the Portal namespace itself (for most of us, it seems) has mostly been technical fixes and tweaks to our tools. Also, your not agreeing with particular proposals does not make those proposing them irresponsible or incompetent. Talk pages are a place to discuss new ideas so that we can find the benefits and drawbacks of each. If we constantly had to worry about being labeled as irresponsible or incompetent for suggesting something, we'd never have any new ideas or get anything done. I've made plenty of suggestions that didn't pan out later, as I'm sure you have, and everyone else here. That's how we learn what works and what doesn't and build a better encyclopedia. In the end, that's what we're all here for right? — AfroThundr (u · t · c) 19:48, 16 March 2019 (UTC) @AfroThundr3007730: that's not at all how it looks from outside. Last year, the project began developing automated portals, whose advocates claimed need little or no curation. No attempt was made to hold an RFC to determine whether the community found these automated portals to be a worthwhile addition. (I think I see an emerging consensus that they are not useful, or maybe useful only in some curcumstances) Following the WP:ENDPORTALS RFC which decided not to actually delete the whole portal namespace, the project decided to massively expand the number of portals, despite the clear evidence at RFC that many editors wanted fewer portals. At no point did the project initiate an RFC to establish whether there was a community consensus for the project's enthusiasm to bizarrely interpret "don't TNT the lot" as "create thousands more". You are right that a WikiProject has no powers of restraint on an individual editor. However, the project does have an ability to watch what is done, and to act a venue to monitor inappropriate creations, and to initiate cleanup as needed. I see no sign at all that the project has done any of that ... and on the contrary, when outsiders have challenged TTH's sprees of portalspam, other project members have rallied to TTH's defence. Even now, as a cleanup is underway, I see next to no assistance from project members. V few even comment in the MFDs. For example, take the most extreme case so far: MFD Portal:University of Fort Hare, an utterly absurd creation for which there exists precisely zero relevant selected articles ... yet none of the project regulars is visible. In my view, a WikiProject which shows zero interest in removing inappropriate pages within its scope is dysfunctionally irresponsible. The project's efforts to develop guidelines have been exceptionally poor. The discussions have been rambling and unfocused, with a persistent failure to distinguish between factors such as technical ability to create, availability of editors to maintain and monitor, actual usage data, etc. Above all, none of the proposals has been put to an RFC to gauge community consensus, so the guideline discussion have effectively been the work of a small group of editors who are united by a common desire to massively increase the number of automated portals. The result of this failure has been a walled garden of thousands of micro-portals, sustained only by the enthusiasm of the portal project ... and the absolutely inevitable massive shitstorm at the village pump. What this needs now is a structured RFC, which brings together some or all of the proposals made at the project, adds proposals from outside the project, and seeks a community consensus. --BrownHairedGirl (talk) • (contribs) 20:18, 16 March 2019 (UTC)

New features of Template:Transclude random subpage

I've added a couple of new parameters to {{Transclude random subpage}}. Parameter |more=link text allows adding a link to the index, similar to "More featured articles" on the Main Page. Parameter |several=number allows transcluding more than one subpage. Parameter |prefix= prepends it before every transclusion. Usage of these new features can be seen at Portal:Doctor Who. —⁠andrybak (talk) 13:32, 7 June 2020 (UTC)

Need a parameter to hide refs in all of these templates....looking to do so for Portal:COVID-19.--Moxy 🍁 13:37, 7 June 2020 (UTC)

Scotland portal

Portal:Scotland is broken in areas. The Selected article and Selected biography sections are only displaying images, and no text. This is occurring at all of the Selected items pages, which are accessible by using the tabs in the upper area of the portal. North America¹⁰⁰⁰ 15:57, 17 July 2020 (UTC)

@Northamerica1000: It looks OK to me. This is a big portal with an unusually large number of Selected Things. Perhaps it is failing to render if the servers are very busy or the reader has a slow connection or PC. I wonder if we could trim it down; perhaps keep a few of the most important Selected Things and have the rest transcluded from monthly lists on a rotating basis? Pinging Cactus.man who has worked on the portal. Certes (talk) 16:28, 17 July 2020 (UTC)

Northamerica1000, fixed: Special:Diff/929873093/968161640. —⁠andrybak (talk) 16:37, 17 July 2020 (UTC)

@Andrybak and Certes: Content is now transcluding correctly from what I can see. It appears that the consolidation of the articles from the separate pages onto one page solved it. North America¹⁰⁰⁰ 17:03, 17 July 2020 (UTC)

Concerning portal guidelines and topic minimums (eom)

— Preceding unsigned comment added by The Transhumanist (talk • contribs) 2018-10-06T21:18:36 (UTC)

Guideline discussions announcement

• Wikipedia talk:Portal guidelines#Second sentence contradicts WP:NOTCOMPULSORY policy, and should be removed
• Wikipedia talk:Portal guidelines#Concerning the inclusion of "Related portals" section
• Wikipedia talk:Portal guidelines#Concerning the inclusion of "Selected article(s)" section
• Wikipedia talk:Portal guidelines#Concerning section: Recommended
• Wikipedia talk:Portal guidelines#Concerning section: Article selection
• Wikipedia talk:Portal guidelines#Concerning section: Required

— Preceding unsigned comment added by The Transhumanist (talk • contribs) 2018-11-13T15:04:01 (UTC)

Portal:Methodism assistance

Hi, I'm trying to revive/revitalize the Methodism work group. This portal absolutely falls within our Project and I'd like to help maintain it, but I know nothing about portals. If anyone's willing to help me learn I'm willing to help maintain. Jerod Lycett (talk) 22:09, 7 February 2020 (UTC)

@Jerodlycett: Hi, it's great to have someone who knows the topic and is willing to maintain the portal. It looks to be in decent shape but could benefit from having the excerpts updated from the copy-pasted text like Portal:Methodism/Selected article/7. We can replace those pages by transclusions which update automatically when the articles are edited. If you wish, we can add a collapsed list of articles and have a subpage (aimed at editors) with all the current excerpts visible simultaneously. This might also be a good time to review the lists of selected articles and biographies, perhaps with using the quality article listing. Certes (talk) 10:17, 8 February 2020 (UTC)

@Jerodlycett: I recommend soliciting for portal assistance at Wikipedia talk:WikiProject Christianity/Methodism work group, where I notice you have already posted your Revitalization efforts thread. Another idea is to post at the wider Wikipedia talk:WikiProject Christianity/Noticeboard page about wanting to improve Portal:Methodism. As Certes stated above, I agree that the use of transclusion templates would improve the portal. These templates provide readers with current, up-to-date information that is verbatim to that in articles. The eight articles at Portal:Methodism/Selected article could even be migrated directly into the main portal page using the templates. Same goes for the Portal:Methodism/Selected biography content. Regarding the transclusion templates themselves, a consensus approving their usage in portals was formed at this Village Pump discussion. The discussion also provides an overview of the templates that are available.

Some immediate ideas to improve the portal include:

• Expand it with more FA/GA-class articles
• Add an images section
• Enlarge and expand the Categories section to 100% width, which makes it easier to navigate
• Expand the Methodist topics section
• Consider adding a DYK section.

If you're interested in any of these improvement ideas, I can help you to implement them. Feel free to ping me here if I can be of any further assistance. North America¹⁰⁰⁰ 15:47, 8 February 2020 (UTC)

A few ideas for additional articles are in this search. It needs a human to filter out cases like Pithole, Pennsylvania which briefly mentions a Methodist church. If you want to use a subpage which shows all excerpts but only one when transcluded, there is an example here. Note the use of |showall= within a noinclude tag. Certes (talk) 11:07, 9 February 2020 (UTC)

In The News and Did You Know can also be automated but again I'd recommend manual filtering to avoid barely related articles.

Did you know...

... that "The Potato King of Colorado" survived a shipwreck, mined for gold in Australia, and helped establish an alcohol-free Methodist colony? ... that upon being named the head football coach at Central College, C. A. Clingenpeel declared that "we will win one game this year" – and was correct? ... that the Global Methodist Church is part of a proposed divorce over marriage? ... that the Bethel African Methodist Episcopal Church in Springtown, New Jersey, was used by Harriet Tubman to help fugitive slaves escape? ... that the Ohio Conference of the Methodist Episcopal Church admonished pastor John Swanel Inskip for allowing men and women to sit together at church? No recent news

Hope that helps, Certes (talk) 11:07, 9 February 2020 (UTC)

Portal:Black Lives Matter assistance

I'm trying to recreate the Black Lives Matter portal, which was deleted because it was based on a single navbox. The consensus from said MfD explicitly stated "No prejudice against creating properly curated portals that satisfy WP:POG" (note that WP:POG has been deprecated since then). I believe the topic warrants a portal because it is a broad enough topic, and because Portal:Coronavirus disease 2019 was created under similar circumstances (a portal created as part of a WikiProject covering a developing current event). An admin (the user Pharos) provided me with a copy of the deleted portal in my userspace (which I linked to in the section header). The specific advice I would like to ask is: what steps should be taken to move away from the single navbox design and towards a properly curated portal that won't be deleted? DraconicDark (talk) 02:51, 9 August 2020 (UTC)

Border in portals

There are many portals with borders provided by codes like {| width="100%" cellpadding="4" cellspacing="8" style="background:white; border-style:solid; border-width:1px; border-color:black;" I always remove these borders because they displaying the portals incorrectly on smartphones. But some users consider it a good esthetic detail on the portals.(example Portal:Technology @Northamerica1000:) Low visualization of portals on smartphones is a problem, wouldn't it be better to remove these borders from all portals?Guilherme Burn (talk) 14:46, 11 August 2020 (UTC)

Ideally there should be a way to make the border display only if the screen is wider than X pixels, just like many two-column portals become single column on small screens. —Kusma (t·c) 14:59, 11 August 2020 (UTC)

The border in Wikipedia:Contents/Portals is displayed correctly on my smartphone.Guilherme Burn (talk) 15:27, 11 August 2020 (UTC)

@Guilherme Burn: If you don't mind me asking, what phone are you using? I've tested the Portal:Technology page from several different viewports using chromedevtools and i can't see a break in the render. What do you mean by displaying incorrectly?

If i remember right, the two-column layout was made possible by a few lines added into the sitewide CSS; copied over from German Wikipedia. It's unlikely that the issue of these borders would warrant the site CSS being edited however.

That leaves us with local options. It could make a difference if the values are changed to em units. But i can't imagine a 1px border causing issues. If the padding is the problem, we may be able to use margins on the child elements.

There's also JS solutions but i'd rather avoid that. This all depends on how widespread the issue is, it might not be worth doing a fix. Zindor (talk) 01:42, 15 August 2020 (UTC)

@Zindor: a Moto G6, white Firefox. On my phone it "cuts" a part of the screen on the right.Guilherme Burn (talk) 12:29, 20 August 2020 (UTC)

Having to scroll is unfortunately very normal

The question I wanted to discuss is not the problem itself, but ... isn't it better to just remove that border from all portals? It's just an esthetic detail. So, the portals would look more like the Main page, which does not have this border.Guilherme Burn (talk) 12:29, 20 August 2020 (UTC)

It might just be the padding rather than the border itself. If you look at Wikipedia:Contents/Types layout, it has a border but the content doesn't overflow. I have to get back to work now unfortunately but i'll check in on this later. Regards, Zindor (talk) 13:08, 20 August 2020 (UTC)

Module:Excerpt/portals

Portal templates have been changed to use the new Module:Excerpt/portals, which is merged from the existing modules. Module:Excerpt has since received changes to assist its use in other namespaces. These changes should not affect portals. Certes (talk) 13:31, 27 August 2020 (UTC)

Lua errors in portals

I have fixed the few portals which had Lua timeout errors by reducing the size of those large page pools which were taking too long to select from.

The only remaining problem is on Portal:San Francisco Bay Area, which has too many expensive function calls. If there are no objections, I propose to fix this by replacing Module:Random portal component by its sandbox. This will populate categories such as Random portal component with 26–30 available subpages much more efficiently but may give slightly different results. It will also produce a page even when the first page randomly chosen is missing from the pool, and should generally speed up rendering of this style of portal. Certes (talk) 15:26, 1 October 2020 (UTC)

I've boldly changed the module. Please report any problems. Certes (talk) 10:13, 3 October 2020 (UTC)

Portals needing placement of incoming links

I have noticed that many portals are woefully lacking links to them in main namespace articles, such as in article See also sections. Check out Category:Portals needing placement of incoming links for some of them. If articles lack portal links, them many WP:READERS will not know about the portals' existence. Regarding this matter, the egg needs to come before the chicken. Readers need links to see what's available on Wikipedia. Assistance in adding links to portals would be appreciated. North America¹⁰⁰⁰ 13:48, 30 September 2020 (UTC)

This is usually done by placing links in appropriate templates, usually footer templates, which then propagates the links across all of the articles with that template. There are only 68 listings in that category, so it should be fairly quick work to find appropriate templates in which to include the links. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 00:13, 1 October 2020 (UTC)

@Nihonjoe: Yeah, I add links to templates. A perennial problem is that when the nav boxes at the end of articles are collapsed, then the links are not visible to readers. Unless readers expand the nav box, they don't see the links, and then many readers won't know about the portal's existence despite links being there, because they're hidden away. Out of sight, out of mind. That's why I prefer link placement in See also sections, which is also aligned with WP:SEEALSO. However, template placement is a decent way to at least increase the number of pages in main namespace with at least some kind of link. North America¹⁰⁰⁰ 00:35, 1 October 2020 (UTC)

Totally agree. The almost total absence of links is one of the main reasons why many portals get low visit numbers, something that was repeatedly used to denigrate them during the big portal cull. Another factor is that they don't appear in searches. As an experiment, I created the Harz (portal) redirect which would come up in searches. It'll be interesting to see if, over time, the number of visits goes up as a result. Bermicourt (talk) 15:56, 2 October 2020 (UTC)

I prefer the use of template:portal in the "See also" section, it is more elegant and avoids two links to the same portal in the articles. But in both cases the problem is the link in the end of the article, it would be interesting to be at the beginning too.Guilherme Burn (talk) 16:49, 2 October 2020 (UTC)

@Guilherme Burn: yes, I agree. Burying the link at the bottom of the page means that many readers will never get to it, especially as the main portal article is invariably a long one. But where do we place it so it 'fits' neatly with the lede and infobox? It would be good to integrate it with the infobox as long as it doesn't 'disappear' by being in a hidden part of the infobox. I don't think I have a problem with it also being in the navbox as many of the other navbox links may be duplicated in the text. Bermicourt (talk) 10:26, 3 October 2020 (UTC)

Andorra

Something bad is happening with the template at Portal talk:Andorra — Martin (MSGJ · talk) 21:47, 25 October 2020 (UTC)

@MSGJ: The problem goes away when I remove {{WikiProject Portals}}. Could it be connected to recent changes to Template:WikiProject Portals/qualityscale and Template:WikiProject Portals/importancescale? Certes (talk) 22:34, 25 October 2020 (UTC)

Fixed with [11]. The banner transclusion of the maintenance template was matching the outer table (coloured box), since the module that does the transclusion assumes that the maintenance template is at or near the top of the page, not inside other pairs of { } braces - Evad37 [talk] 23:06, 25 October 2020 (UTC)

Thanks, well spotted! That's certainly a gotcha to look out for in future. Certes (talk) 23:09, 25 October 2020 (UTC)

Bot to purge pages

A bot is proposed to purge pages. This may become useful for refreshing portals which have regularly changing content, such as an "on this day" anniversary section, or simply to turn over content selected randomly from lists. Certes (talk) 11:05, 28 October 2020 (UTC)

Merge project's discussion pages

There are three discussion pages at the WikiProject Portals:

1. Wikipedia talk:WikiProject Portals (this page) with a single subsection "General discussion threads"
2. Wikipedia talk:WikiProject Portals/Design with subsections "Bug collection", "Discussions about possible cool new features", "Discussions about technical issues"
3. and Wikipedia talk:WikiProject Portals/Tasks with subsections "Discussions about WikiProject tasks", "Discussions about new portals or specific portals", and "Requests for Admin assistance".

I personally find it difficult to navigate. This separation seems unnecessary. Having to choose between seven different subsections on where to start a discussion is an unnecessary overhead when starting a new discussion. Should we merge these three pages with their seven subsections into a single page with no subsections? If needed, the discussions which require admin attention could get its own template, similar to {{Request edit}} and/or {{Admin help}}. Bugs could be placed on its own subpage Wikipedia talk:WikiProject Portals/Bugs and transcluded to the top of this page, similar to what template {{todo}} does. —⁠andrybak (talk) 14:37, 2 October 2020 (UTC)

• Support – It would simplify matters a great deal to consolidate everything onto this main talk page, in my opinion. Any and all project talk queries and notices would then exist in one centralized area, rather than scattered about, making it easier for project members and others to access information. North America¹⁰⁰⁰ 00:52, 26 October 2020 (UTC)
• Support. My original thought was "don't care" but the revamped Portal: namespace is now more stable and doesn't need multiple pages, so it helps to have everything in once place. We could also revise the headings: new features can be useful without being "cool". Certes (talk) 10:52, 26 October 2020 (UTC)

 Done, discussion pages have been merged. Header of this talk page has been simplified. —⁠andrybak (talk) 13:16, 31 October 2020 (UTC)

Recognised content

Recognised content is currently being systematically removed from portal talk pages. It is unclear what effects this will have on the corresponding portals. Certes (talk) 16:46, 7 November 2020 (UTC)

A bit misleading/alarmist as a description, but not wholly inaccurate. See User talk:Headbomb#Portal recognised content for a bit of background. In a nutshell

• {{User:JL-Bot/Recognized content}} was added en masse to Portal talk pages by The Transhumanist back in 2018 or so.
• This is an abuse of the WP:RECOG system, which traces back to an oversight from early days of design (the Book namespace is technically allowed for instance, even though it makes no sense there either).
• Removal is because the Portal talk: namespace is for discussion, while WP:RECOG is not discussion-related. It should in the #[[Portal:, either directly on the root of the portal, or in a subpage]]
• Keeping it on talk pages clutters the talk page, talk page histories, and archives (and their histories too , e.g. [12])

Headbomb {t · c · p · b} 17:13, 7 November 2020 (UTC)

For the record, the list of affected pages is

I'm still investigating which of the associated portals already have a /Recognized content subpage, and which are displaying recognized content on their mainpage. Headbomb {t · c · p · b} 17:21, 7 November 2020 (UTC)

The list of those without something on the main page, AFAICT, is

And a list of those without some type of recognized content on their main page, but not one maintained by JL-Bot

Headbomb {t · c · p · b} 18:08, 7 November 2020 (UTC)

Note that whatever solution/implementation/messaging regarding recognized content list should likely apply to all portals without recognized content lists, not just the ones I listed above. Headbomb {t · c · p · b} 18:18, 7 November 2020 (UTC)

I found it mildly useful as a quick way of checking when new articles had been (de)recognised (from looking at the history). If it goes somewhere too esoteric, it's easy to forget it exists and miss new content. Many portal talk pages hardly ever get any edits, so in practice it's not very disruptive to histories. Espresso Addict (remote) (talk) 07:37, 8 November 2020 (UTC)

The logical place for this to be is on the portal themselves, not their talk pages Headbomb {t · c · p · b} 16:59, 8 November 2020 (UTC)

Northamerica1000 may be able to advise what lists are needed and how best to store them. I'm concerned that a sudden disappearance may confuse the portal maintainers who use these lists. We should at least add an explanatory message to the affected talk pages, explaining where the content has moved to. Certes (talk) 17:27, 8 November 2020 (UTC)

A mass message to portals explaining (all of them) how to set this up properly or customize their existing listings would likely be the ideal solution. I can craft one. Headbomb {t · c · p · b} 17:55, 8 November 2020 (UTC)

@Certes: How about User:Headbomb/How to setup RECOG for portals? (Replace 'Headbomb' with BASEPAGENAME everywhere, so on say Portal talk:Physics, you would have 'WikiProject Physics', and not 'WikiProject Headbomb'.) Headbomb {t · c · p · b} 18:20, 8 November 2020 (UTC)

Thanks, that looks good. I'd omit the bit about "improperly set-up": it may be true, but they followed the documentation as it stood at the time to the letter. Rather than substing or transcluding this everywhere, perhaps it should just stay on a how-to page somewhere such as WP:WikiProject Portals/Recognized content, with a one-line message pointing to it on each talk page which used to hold recognised content. Also, understand→understanding (typo). Certes (talk) 18:37, 8 November 2020 (UTC)

Tweaked. I'm fairly indifferent about a one time spam run with the above message transcluded/subted:, or one that points to a WikiProject Portals guide. Probably both would be best. Headbomb {t · c · p · b} 21:46, 8 November 2020 (UTC)

Headbomb, one of usages of WP:RECOG, that's not mentioned is with Template:Transclude list item excerpts as random slideshow and similar templates, which can consume the lists, generated by the bot. Example: Portal:The arts. Another example: Portal:Doctor Who, which broke (see the error in the "Selected quality article" box) after removal of the section from the talk page and had to be fixed. —⁠andrybak (talk) 21:57, 8 November 2020 (UTC)

@Andrybak: Those are manually-maintained systems AFIACT, and not part of the automated WP:RECOG system. Headbomb {t · c · p · b} 22:01, 8 November 2020 (UTC)

Hmmm, seems I was wrong about that. There's a way to have a slideshow option it seems. Feel free to add to Wikipedia:WikiProject Portals/How to setup Recognized Content for portals, if not I'll try to write up something in the coming week after I figure out how that slideshow system works. Headbomb {t · c · p · b} 22:03, 8 November 2020 (UTC)

(edit conflict) Headbomb, after such template is set up on the portal page, all the work to keep the list of articles up-to-date is done by the bot. —⁠andrybak (talk) 22:23, 8 November 2020 (UTC)

I think I've tidied up the other links and transclusions except for Portal talk:Germany#Recognized content. It has links within Portal:Germany but I'm struggling to find them. I suspect they're unimportant but Kusma may be able to help. Certes (talk) 22:42, 8 November 2020 (UTC)

It came from Portal:Germany/Selected archive nav and Portal:Germany/Selected articles and pictures, which I've fixed. Headbomb {t · c · p · b} 22:50, 8 November 2020 (UTC)

Thanks! That and a few null edits have got rid of the links I couldn't pin down. Certes (talk) 22:57, 8 November 2020 (UTC)

Thanks all! I am happy this is no longer dominating the main portal talk page. —Kusma (t·c) 23:33, 9 November 2020 (UTC)

• Simply displaying Recognized content on the main portal pages would be functional. Then, readers can see the best articles about the portal's topical focus, right there in a neat list. Several portals already include it on their main pages. North America¹⁰⁰⁰ 00:02, 9 November 2020 (UTC)
• Some of the listings are long (e.g. Wikipedia:WikiProject Michigan/Recognized content), so for those, I recommend only displaying FA-class and GA-class articles and Featured pictures within the portals. Other stuff can also be displayed for shorter lists. North America¹⁰⁰⁰ 00:42, 9 November 2020 (UTC)
  • The bot could be tweaked to only transclude a certain number of items if the full lists aren't desired. Headbomb {t · c · p · b} 01:48, 9 November 2020 (UTC)
    • I don't recommend that, because then the decision on which articles to include and which are excluded would be entirely arbitrary, based on a max number. A number of high quality articles could be unnecessarily omitted using this technique. North America¹⁰⁰⁰ 02:50, 9 November 2020 (UTC)
      • Wouldn't be the default behaviour. I could swear the bot already did this, but I may be thinking about WP:AALERTS, which adds a (6 more...) when transcluded (see Wikipedia:WikiProject Physics#Article Alerts). That's the sort of thing I was thinking of, not just silently dropping the rest. Headbomb {t · c · p · b} 03:49, 9 November 2020 (UTC)
      • These lists should not be used on all portals, just where they make sense. For example, for Portal:Germany, the majority of the FAs and GAs are military history, and displaying pages and pages of lists of battleships kind of obscures all of the good content we have about Germany. I can't see a good way to automate an interesting list that isn't totally unbalanced (grumbles about WP:MILHIST writing too many good articles). —Kusma (t·c) 23:33, 9 November 2020 (UTC)
        • It's really up to each portal to decide what they want for implementation, including not showing full lists on the main portal page. Headbomb {t · c · p · b} 23:52, 9 November 2020 (UTC)

New Template:Portal pictures

New template {{Portal pictures}}, backed by Module:Portal pictures has been created. This template greatly simplifies the process of maintaining a "Selected pictures" box on a portal. Firstly, the main focus of this template is usage of already prepared subpages of Template:POTD. Secondly, the template uses a "single page approach"—only a single page needs to be touched to add a new selected picture to the list, i.e. the template {{Portal pictures}} does not need manual updates of the |max= parameter, which is usually needed for numbered subpages approach.

An example of using this template can be seen on the Portal:Sports. All selected picture subpages from Portal:Sports/Selected picture/1 to Portal:Sports/Selected picture/40 were merged into a single-page list at Portal:Sports/Selected picture. Then the subpage was transcluded on the main page of the portal. Example of adding a new picture after the conversion: Special:Diff/986398178.

Any feedback is welcome. —⁠andrybak (talk) 16:09, 31 October 2020 (UTC)

See transclusions for the list of portals, which were updated to use the new template. —⁠andrybak (talk) 03:08, 22 November 2020 (UTC)

Change default "Read more..." link text

A number of templates used by portals produce a "Read more..." link at the end of an excerpt, for example {{Transclude list item excerpts as random slideshow}}. I suggest switching all these templates to the text "Full article..." to make it similar to the TFA section on the Main Page. Historical side note: the text of the link in the TFA section changed a lot at the end of 2012. In a span of a month in went from the original "more..." to "Read the full article", to Read the full article... (with ellipsis), and finally to Full article...), which was eventually converted into the Template:TFAFULL (first usage). —⁠andrybak (talk) 12:05, 6 November 2020 (UTC)

Sounds good....however "Read more..." is used all over outside the templates. So we would have 2 style all over.--Moxy 🍁 12:14, 6 November 2020 (UTC)

Moxy, regarding "Read more..." is used all over outside the templates—tracking down every usage can be done with an insource query: [13]. These can be updated with WP:AWB or WP:JWB. —⁠andrybak (talk) 19:44, 16 November 2020 (UTC)

I hard-coded "Read more..." into the original Module:Excerpt (now revived as Module:Excerpt/portals) because that phrase was used consistently in existing portals. If we were making a fresh start, "Full article..." might be more informative and less "clickbaity". Most occurrences (about 12,000 pages) are generated by easily changed templates. However, the text "Read more" is also used explicitly on 3,797 Portal: pages, though some may be redundant or for internal use. Certes (talk) 12:30, 6 November 2020 (UTC)

@Moxy and Certes: one kind of such usages is below an excerpt, often inside {{Box-footer}}. Some of such excerpts even end up with two "Read more"s, e.g. at the top of Portal:Architecture. —⁠andrybak (talk) 15:12, 6 November 2020 (UTC)

Yes, we should settle on either |more= in the excerpt template or an explicit "Read more..." in {{Box-footer}} but not both. Certes (talk) 15:27, 6 November 2020 (UTC)

Architecture is the only portal with this exact problem but a few others have similar issues. Portal:Derbyshire has one Read more in its transcluded /Intro and another in the box footer. France has two variants of Read more in its main page. Georgia has two variants, both in its /Intro. Certes (talk) 15:49, 6 November 2020 (UTC)

All fixed, discarding explicit text in favour of |more= except for France which has custom wording. Certes (talk) 15:19, 7 November 2020 (UTC)

More descriptive link text, such as "full article", would better align with best web practices, both for legibility and accessbility purposes. isaacl (talk) 14:32, 6 November 2020 (UTC)

Implementation

• {{Selected article}} – Special:Diff/986437029. —⁠andrybak (talk) 12:00, 21 November 2020 (UTC)
• Templates implemented by Module:Excerpt/portals – Special:Diff/989060122/989967151. —⁠andrybak (talk) 00:49, 22 November 2020 (UTC)
• Templates implemented by Module:Excerpt slideshow – Special:Diff/989963181. —⁠andrybak (talk) 00:57, 22 November 2020 (UTC)
• For some portals, the duplicate link "Read more..." at the bottom of the lede can be replaced with links to outlines, indexes, and related articles. Examples: Portal:Norway, Portal:Technology. I plan to go through some of these with WP:JWB. —⁠andrybak (talk) 20:20, 22 November 2020 (UTC)
• {{Selected biography}} – Special:Diff/990414295. —⁠andrybak (talk) 10:17, 24 November 2020 (UTC)
• {{Selected economy}} – Special:Diff/990416806. —⁠andrybak (talk) 10:35, 24 November 2020 (UTC)

• Comment. One of my portals acquired doubled parentheses around this text since I last looked at it, presumably because of this change. Is there any way of checking that other portals do not have this glitch? Cheers, Espresso Addict (talk) 07:06, 26 November 2020 (UTC)

  I don't see any, but punctuation is hard to search for. Do you have an example of a portal with doubled parentheses? Certes (talk) 12:55, 26 November 2020 (UTC)

  Thanks, Certes. It was in the Portal:Scottish islands intro, but I've now fixed that. Espresso Addict (talk) 13:09, 26 November 2020 (UTC)

  I've fixed the three other cases. One was in Portal:Speculative fiction/Selected works. The others were in redundant subpages of Portal:Herbalism which was "merged" last year, i.e. replaced by a redirect then speedily deleted. Certes (talk) 13:40, 26 November 2020 (UTC)

  Certes, to search for this error in particular insource search with following regex works: insource:/more *= *\(/ [14]. —⁠andrybak (talk) 13:44, 26 November 2020 (UTC)

  Thanks; that's what I used once I had an example to work out what to seek (one parenthesis in wikitext; another from the template). The search comes back empty now. Certes (talk) 13:52, 26 November 2020 (UTC)

Showall option (for archive pages) in Template:Transclude random excerpt broken?

It looks like the update to this has broken the showall option -- See for example Portal:Scottish islands/Biography, which I'm sure used to show all the selections, but now only shows one. Espresso Addict (talk) 17:52, 30 November 2020 (UTC)

Espresso Addict, thanks for the report. This use case has been fixed: Special:Diff/992005614. The issue was caused by the whitespace in the unnamed (also known as positional) parameters passed to the template. See third item at Help:Template § Usage hints and workarounds: Remember that whitespace characters (spaces, tabs, carriage returns, and line feeds) are not automatically stripped from the start and end of unnamed parameters.

The bug has been in the Module:Excerpt/portals since its creation. So the bug was probably introduced to the template in Special:Diff/975223429 or Special:Diff/960161970, when the template was switched from the original Module:Excerpt. —⁠andrybak (talk) 00:08, 3 December 2020 (UTC)

Thanks, Andrybak. Looks to be working fine now. Espresso Addict (talk) 18:55, 3 December 2020 (UTC)