Wikipedia talk:WikiProject Portals

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
WikiProject Portals Talk Pages

Tasks and

New Post | Watch Page
To discuss work on the portals, and project administration, including policy issues.

Dialog-information on.svg
Portal Design
and Ideas

New Post | Watch Page
Existing and potential portal design features and support tools. Technical stuff.


New Post | Watch Page
General portal topics and announcements that don't fit elsewhere

Shortcut: WT:WPPORT/T

Shortcut: WT:WPPORT/D

Shortcut: WT:WPPORT


Main Discussion Page

Shortcut: WT:WPPORT

All Discussion Sections

Archives: Index1, 2, 3, 4, 5, 6, 7, 8, 9
WikiProject Portals (Rated Project-class)
WikiProject iconThis page is within the scope of WikiProject Portals, a collaborative effort to improve portals on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 Project  This page does not require a rating on the project's quality scale.
Note icon
See also: Instructions • Guidelines • List of Portals

General discussion threads[edit]

Concerning portal guidelines and topic minimums (eom)[edit]

Portal linkage problems[edit]

A major problem is that a lot of the new portals that have been recently mass-produced are entirely orphaned, lacking even a portal link on their main pages in the See also sections. They also often lack a portal link on the template pages.

Without links to the portals, nobody is going to visit them, because nobody will know about them, defeating their purpose entirely.
I have been adding links, but it takes time, and I don't foresee being able to add links for all of the new portals that have been created by myself. Below is a basic list of what should be done when a new portal is created, at the very least.
Portal Linkage
  • Add a portal link to the portal's main topic page. This is typically done using the {{Portal}} template, and when content spills into the See also or other sections, then {{portal-inline}} or {{portalbar}} can be used.
  • Add a portal link to the article's template (e.g. Template:Cajun cuisine). I typically also add the category if one is not present. This works well using: {{portal-inline|size=tiny|TOPIC NAME}}{{•}} {{category-inline|CATEGORY NAME}}
  • Bottom line, with no links leading to the new portals, they just won't be used. North America1000 22:14, 2 November 2018 (UTC)
I agree that orphan portals are not very useful. I started adding portal links to article templates (e.g. making {{Burger King}} link to Portal:Burger King) but the edits were undone and I was warned to stop. Please beware that such changes may meet opposition. Certes (talk) 22:38, 2 November 2018 (UTC)
Certes: Thanks for replying. Well, the warning was for adding a link to Commons, it being an external website (see WP:NAV-WITHIN, "Navigation templates do not provide external links to other websites"), but the user just removed everything. I restored all except the Commons link. So, as long as we omit links to external websites, all should be fine, hopefully. North America1000 22:54, 2 November 2018 (UTC)
I've been working on these in batches, except for related portal links, which simply are not automatable/scalable. So far, I've placed links on the corresponding category pages to almost all of the new portals. And I have processed several hundred see also sections. Both using WP:AWB. I've also been placing more links at the time of creation.
I'm in the process of working on a script to place links leading to a portal at the time the portal is created. But it is a very tricky process to automate, requiring tracking via localstorage items, and may take me some time to figure out.
But, for existing portals...
(see next section).    — The Transhumanist   21:13, 3 November 2018 (UTC)
I think that linking to portals should be considered an integral part of creating them, ie. A portal is not finished until it has links from at least some, possibly all of the articles that it features and the category. Not sure how that would be done, so this would depend on if and how it can be done. Perhaps a job for a bot?· · · Peter (Southwood) (talk): 15:19, 7 November 2018 (UTC)
@Pbsouthwood: Considering the articles that it features, those are all usually listed on the same navigation template, the usual place upon which to place a portal link is at the bottom of the template. The navigation template is usually placed at the bottom of all the articles listed upon it, and so, a template link can be located on all those pages by virtue of being on the template.
The main places to list portals are eponymous with their titles. A portal should have a link placed on the corresponding template, on the corresponding category page, and on the corresponding article (in the See also section).    — The Transhumanist   11:40, 9 November 2018 (UTC)

Mass linking to portals[edit]

To coincide with producing lots of portals, there are techniques for linking to lots of portals.

The main one is WP:AWB. The easiest portal links to place with AWB are on the corresponding category pages, as you can generally get them all in one pass. The others take multiple passes to get them all (due to missing see alsos, etc.).

Another method that works fairly well is multi-tab. First, make a list of portals that need links to them, then edit the list to be root articles or template names or category page title (don't forget the preceding colon). Then ctrl-click on them to make a tab for each. Then process each tab.

A quick way to place the links to a particular portal is, with the portal displayed, Ctrl-click on the article link, the template edit link, and the category link to open in tabs the 3 main pages that need links to the portal. Edit each page as needed. After links are placed on those, go to Portal:Contents/Portals to list it there too.

I hope these tips help speed up the process.

Keep up the great work!    — The Transhumanist   21:13, 3 November 2018 (UTC)

Excluding links to broken portals[edit]

A question at Wikipedia:Village_pump_(technical)#Making_links_conditional_on_target_status has established that it would be possible to add code into Module:Portal so that {{Portal}} would omit links to broken portals, e.g. if tagged with {{Portal maintenance status|broken=major}} (or =serious or =yes).

There are currently between 70 and 80 portals with that assessment, which places them in Category:Portals with errors in need of immediate attention.

Is there consensus here that it would be desirable to add that code? – Fayenatic London 09:19, 7 November 2018 (UTC)

I would support this. Majorly broken portals need to be fixed first before they are to be widely seen. Dreamy Jazz 🎷 talk to me | my contributions 10:45, 7 November 2018 (UTC)
I would go along with that too. If easy to fix they should be fixed. If not, hide, or if sufficiently broken, rebuild from scratch, sometimes the easier option. Linking to broken portals does not do portals any good.· · · Peter (Southwood) (talk): 15:07, 7 November 2018 (UTC)
  • Query: I assume that if there is more than one portal in the template, the not-broken ones would display normal links, and if there are only broken portals the template would not display anything? · · · Peter (Southwood) (talk): 15:07, 7 November 2018 (UTC)
    • Yes to the first point. If there are only broken portals, the template would display an error message, "No portals specified: please specify at least one portal". However. IMHO this (i) is highly unlikely, and (ii) would draw attention to get the problem fixed fairly quickly. – Fayenatic London 12:06, 8 November 2018 (UTC)
      • The quickest solution being to remove the portal button displaying the error message, which would be another example of disappearing links.    — The Transhumanist   02:07, 9 November 2018 (UTC)
  • Politely oppose – Portals have features that may acquire regular readers who return to portals or regularly click on portal links for their news, DYKs, automatically updating content, and automatically added content. Having links disappear could be disruptive to those readers. If a portal becomes broken and its link disappears, regular readers may not know how to contact the right people to fix it. With a link to a broken portal in place, they would see the problem, and would have the opportunity to go to the portal's talk page to report it, or even collaborate with others to fix it. On the portal's talk page, they would see our link to the WikiProject, and could go there to report the problem as well. With no link, they lose those options. For veterans like us, that's no big deal. But for new Wikipedians, or readers who have limited editing experience, that could leave them almost helpless, scratching their heads. Having links disappear may also have other ramifications that we are not yet aware of. We don't want to hide the problems, we want to fix them, and we want anybody on the scene to be able to do it. A link to a broken portal should also be a route to the instructions on how to fix it, such as having a link to the portal instruction page on every portal's talk page. We need to enable people who use portals to be able to help maintain them, rather than remove the option to do so.    — The Transhumanist   01:06, 8 November 2018 (UTC)
    • Comment – a portal that becomes slightly broken, may still be helpful to readers, such as if its news feature is still working. Why remove access to that news if the image slideshow all of a sudden becomes empty because images were removed from the root article from where they were displayed? This creates a domino effect. We need to be careful not to fall into an all-or-nothing mindset. A partially functioning portal is still useful, especially to regular visitors of the portal system.    — The Transhumanist   01:15, 8 November 2018 (UTC)
      • The suggestion is to exclude links to portals assessed as broken=yes, major or serious. The proposal would not remove links for portals with broken=minor etc. – Fayenatic London 12:15, 8 November 2018 (UTC)
        • My concern is about portals that become broken, rather than start out that way. If a perfectly fine portal all of a sudden gets an error, then its link disappears. That is not a good scenario, for reasons I explained above. Once a portal link is in place, it should not disappear unless the portal is deleted.    — The Transhumanist   01:59, 9 November 2018 (UTC)
    • Comment – I checked 3 portals at random listed at Category:Portals with errors in need of immediate attention, and they had no problems. We wouldn't want to hide those. Somebody needs to go trough that list. It is making the problem look bigger than it really is. ;)    — The Transhumanist   01:28, 8 November 2018 (UTC)
      • If you disagree with the assessments by user:Dreamy Jazz or other editors that placed the codes, please take it up with them. Meanwhile I noticed that you have edited other portals within the category and have not replaced the assessments, so presumably you accept that there are significant problems there. – Fayenatic London 12:15, 8 November 2018 (UTC)
        • It is not that I disagree with anyone's assessments, but there is a problem with reports that no longer apply because someone else came along and fixed them (like me). It didn't dawn on me that the assessments were even there to be updated. On the vast majority of portals, those parameters are blank, and so I stopped looking at them. It was not a feature I paid much attention to in the first place, as I have been focusing on automated features and semi-automated processing of the portals, and have been using other ways to find errors. Going over 4,100+ portals manually looking for errors, and then manually reporting them, is a monumental investment of time. We need methods for automatic reporting, to reduce this tremendous labor cost, and so that stale manual alerts don't misreport errors (that are no longer there). Here are a couple tools for scanning portals for problems:
We need more tools like this to find the rest of the error types that come up from time to time. But we don't need disappearing links. That just makes a portal's problems worse. By the way, reporting errors manually on the portals themselves seems a lot like tag placement, my attitude toward which is that many errors can be fixed in almost as little time as it takes to report them (manually), so why not just fix them instead? Just my two cents' worth.    — The Transhumanist   01:59, 9 November 2018 (UTC)
P.S.: @Fayenatic london: (ping)
@The Transhumanist: Just like any other Wikipedia assessment, e.g. the {{unreferenced}} banner on an article, it's acceptable (and desirable) to remove or update the assessment yourself when you fix a problem. Now that they have been drawn to your attention, it should not take long to review those among the remaining 74 Portals with errors in need of immediate attention that you have fixed. – Fayenatic London 10:10, 20 November 2018 (UTC)
@Fayenatic london: They were not as quick as you suggested. It appears a few of them were fixed inadvertently during an AWB conversion pass. I however, don't know which ones. Therefore, I just fixed a bunch arbitrarily, regardless of their problems. Got it down to 47.    — The Transhumanist   11:33, 20 November 2018 (UTC)
@The Transhumanist: OK. I did some minor fixes on Portal:1930s & Portal:1940s, and downgraded their assessments to broken=minor. I used #ifexist, so please review these in case you have a neater templated way to achieve the same result.
In contrast, Portal:1910s is markedly not ready for use. Over 3,000 categories have links to it, and if readers click them they only find a page under construction. Do you still oppose removing links to portals like that? – Fayenatic London 10:28, 21 November 2018 (UTC)
Yes. While they probably shouldn't have been put in place to begin with, those links would be difficult and time consuming to restore once removed (like, who would keep track of them so they could be put back?). It's far better to fix the portal than remove the links to it. One of those links might bring an editor willing to fix the portal, or willing to report it (like you). Portals are very easy to work on these days. They used to take hours to build, and now they take minutes. For most of the portals I've created recently, I've found that it takes more time to place the links to a portal than it took to build the portal. I'll take a look at the 1910s portal, to see what I can do.    — The Transhumanist   13:52, 21 November 2018 (UTC)
Portal:1910s Fixed    — The Transhumanist   15:09, 21 November 2018 (UTC)

Guideline discussions announcement[edit]

Suggestion - Portals browsebar[edit]

Standardize {{Portals browsebar}} as the only navigation template at the top of portals, excluding others such as Template: Religion portals browsebar, Template: Sports portals browsebar, Template: Politics browsebar etc. These templates that can be expanded to infinity, cluttering the header of the portals. What do you think?Guilherme Burn (talk) 12:35, 14 November 2018 (UTC)

Disagree in the case of Portal:Basketball/Basketball portal browsebar, which is a tight set and relevant to each other.—Bagumba (talk) 17:22, 14 November 2018 (UTC)
I agree with the proposal, because most of the links are off-topic, leading to parent or sibling topics. In the case where they are subtopics, they are normally provided in the the Topics section, while subportals would normally be placed in a subportals section.    — The Transhumanist   06:43, 16 November 2018 (UTC)
We can discuss individually:

The inclusion of subcategories on the {{Portals browsebar}} could also be discussed. Guilherme Burn (talk) 12:35, 21 November 2018 (UTC)

Non-free images in portals[edit]

Is there a way to stop non-free files from being transcluded into portals. I've been noticing this happening more than usual lately when checking on files flag for WP:NFCC#9 violations and it seems to have something to do with the syntax being used for portals. The latest example I've come across is Portal:University of New Hampshire and File:UNewHampshire seal.png. The portal is calling up the infobox to University of New Hampshire and was transcluding the infobox image. I think I fixed things by adding "noinclude" syntax for the image, but that might just be a work-around for the time being.

Was there some recent change to the general syntax generally used for portal pages which now makes transcluding non-free content more common? There is a single mention about non-free images and portals in Wikipedia:Portal guidelines, but it's buried in the middle and most likely not many people bother to read that far anyway; some may even think that transcluding the file is OK because technically they haven't added any files directly to the portal. I guess it's also possible that there's something about the wikidata of these files which is telling the system that they are not non-free, so the system treats them as a free image. Anyway, I'm just curious about this. -- Marchjuly (talk) 05:16, 5 December 2018 (UTC)

@Marchjuly: Portal:University of New Hampshire uses Module:Excerpt, which prevents non-free files from appearing in other, similar portals. It checks for the Lua pattern "[Nn]on%-free" in the file description, which should match this file's use of {{Non-free school logo}}. I can't test this particular case now that University of New Hampshire has changed (and I know that reinstating the logo temporarily would upset some editors). Do you know of an unfixed example where a non-free image actually appears? Certes (talk) 11:57, 5 December 2018 (UTC)
Hi Certes. I think if you wanted to go back and test that particular file by removing the "noinclude" tags for just a really short time, it would probably OK as long as you didn't lave things so that the file stays transcluded into that particular portal. However, File:Flag of Winnipeg fair.svg, File:Tehran Logo.png and File:Mississauga coat arms.png seem to be being transcluded into Template:Portal/doc/all, so maybe you can figure things out looking at that page. -- Marchjuly (talk) 01:09, 6 December 2018 (UTC)
@Marchjuly:I've removed the noinclude tags from University of New Hampshire and I still don't see the non-free seal after purging and null-editing Portal:University of New Hampshire. Do you?
The flag of Winnipeg is listed in Module:Portal/images/w as the image to be shown with links to that portal. We probably shouldn't be using non-free images for that purpose, and someone should check the licensing of the images listed there. Certes (talk) 01:19, 6 December 2018 (UTC)
I don't see it now, but yesterday the entire infobox (image included) for the university's article was being transcluded; so, maybe it has sorted itself out. If it pops up again, I'll ping you.
As for the Winnipeg file in Module:Portal/images/w, I can't directly edit that page, but it looks like it was added here by WOSlinker. I'm not sure why that was done, but it shouldn't be being done for non-free files. -- Marchjuly (talk) 01:45, 6 December 2018 (UTC)
I usually check this but missed them when adding a few at the sametime. I've now removed it. -- WOSlinker (talk) 08:17, 6 December 2018 (UTC)
Thanks for doing that. Can you also remove File:Mississauga coat arms.png from Module:Portal/images/m. -- Marchjuly (talk) 08:22, 6 December 2018 (UTC)