Wikipedia talk:WikiProject Portals/Design/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Discussions about possible cool new features

What about portals that can read themselves out loud?

For accessibility, for example.    — The Transhumanist   03:11, 28 May 2018 (UTC)

• Potentially possible. Services such as Amazon Polly can do this automatically via an API. But I would imagine we would need an open source version for it to be used on Wikipedia. The Wikimedia Foundation is notoriously tight-assed on forbidding external services (notably Google nocaptcha/recaptcha) for various reasons such as data collection and editorial independence. An alternative would be for volunteers to read it out and save them as MP3 files, but there is alot of work required for that. JLJ001 (talk) 18:34, 28 May 2018 (UTC)

Text-to-speech can be handled client-side; I know Google Chromebooks have a keyboard shortcut that enables software that reads text out to the user. I think the best we can do I write clean markup for these engines to parse. On this topic, perhaps we should enable the ALT= parameter in the image syntax of PortalButton (I left it out) and add a default ALT for the button itself? @JLJ001: Cesdeva ^(talk) 19:21, 28 May 2018 (UTC)

Agreed. Purely for accessibility reasons we really should make a point of doing that. In fact doing that with all templates we use would be a good idea. 19:24, 28 May 2018 (UTC)

 Done Cesdeva ^(talk) 19:34, 28 May 2018 (UTC)

@Cesdeva: I'm not sure I follow. What does the ALT= parameter do? What is the name of the software on Chromebooks? (Perhaps it is available in other forms).    — The Transhumanist   21:00, 16 June 2018 (UTC)

Can we bypass the intermediary purge page?

When purging, you get this page, rather than an actual purge: https://en.wikipedia.org/w/index.php?title=Portal:Sacramento,_California&action=purge

Is there any way we can make purge links purge directly, without the confirmation page?    — The Transhumanist   00:41, 6 June 2018 (UTC)

It can be done with javascript, like the UTC clock gadget (which is also a single-click purge link). For it to work with logged out users, it would have to be an on-by-default gadget. - Evad37 [talk] 00:52, 6 June 2018 (UTC)

(ec) A user can make purges they request happen directly: see WP:Purge#Automating the confirmation screen. I don't know of a way to configure a page to bypass confirmation for all users. Certes (talk) 00:55, 6 June 2018 (UTC)

That works great. Thank you.

@Certes and Evad37: I noticed that clicking on the purge item in the More tab, and using the hot key ⇧ Shift+Alt+* bypasses the purge confirmation box. What is the difference between these and the purge buttons on portals?    — The Transhumanist   22:15, 11 June 2018 (UTC)

Yes, something different is happening. More→Purge doesn't require confirmation. The purge link does (though, if you followed the suggestion in my link above, the confirmation screen disappears quickly as the JavaScript clicks Yes for you). Both methods load the same URL, but More→Purge uses POST whilst wikilinks always use GET. The MediaWiki code seems to handle the two differently. Certes (talk) 23:48, 11 June 2018 (UTC)

The way it works is that javascript catches the click on the link and then sends a POST request. We could do this (I would assume) if we add some javascript to catch the click on the link to send the post request. However, we will want to be sure that we could stop annons spamming the purge button (as this is why presumably annons have the purge confirmation screen). Wpgbrown ^{talk | contribs} 07:20, 12 June 2018 (UTC)

@The Transhumanist and Certes: We could make our own purge template that is a HTML form which sends a post request. This is what is done on the purge page. Wpgbrown ^{talk | contribs} 13:40, 12 June 2018 (UTC)

@Wpgbrown: That sounds good. Can you provide an example? I haven't managed to find the source of the purge page, only that of the article I'm pretending to purge. Certes (talk) 13:59, 12 June 2018 (UTC)

@Certes: I just tried to make an example, but the source code of MediaWiki does not allow the use of forms (the only exception being their <inputbox> tag) and that would be unlikely to change (seeing as you can do some pretty nefarious things if you code the form right). See Help:HTML_in_wikitext#Unsupported_elements. The code for purge is built into the source code of wikipedia. The API for purging is at [1], but requires a POST request.

If we really want to not have users click the extra button it may be worth raising it with MediaWiki and whether they can provide another way to make HTML forms that is safe (by that I mean a editor could not make any nefarious code with it). Wpgbrown ^{talk | contribs} 14:07, 12 June 2018 (UTC)

@Certes: It could be possibly done with Lua (see [2]), but I don't know if the libraries that it depends upon are enabled in wikipedia's version of Lua. Wpgbrown ^{talk | contribs} 14:24, 12 June 2018 (UTC)

I don't think so. They're not listed under mw:Extension:Scribunto/Lua_reference_manual#Extension_libraries_(mw.ext). The only way I can think of doing this is to provide an external link (using GET) to an off-wiki site which accepts the GET and fires it back to Wikipedia as a POST. The link could even go within a span class="plainlinks" tag. I suspect that would upset someone, as it is far less secure than doing things the easy way that isn't enabled. Certes (talk) 15:08, 12 June 2018 (UTC)

Enticing buttons

@Cesdeva, Evad37, Certes, AfroThundr3007730, Wpgbrown, Waggers, Nihonjoe, Finnusertop, and Greatedits1:

The {{portal}} template seems dated and unappealing.

Once the revamping of portals is complete, it might be nice to upgrade the links leading to them, as a way to announce the new and improved portal system. True, this is a long ways off, but now is the time to start thinking about the presentation of the system for when the upgrade is complete. Toward this end, here are some questions...

What are the applications of {{PortalButton}}? What can they be used for?

What is the feasibility of implementing {{PortalButton}} for all portals?

Could Module:Portal and Module:Portal/images be expanded/adapted to handle Portalbuttons?

Cesdeva, I'm especially interested in what you envisioned, and what other potential applications you foresee for these.

The idea is to drive traffic to the portals. Thoughts?    — The Transhumanist   21:40, 16 June 2018 (UTC)

I would caution against change purely for change's sake. The current set, while not very flashy, serves its purpose adequately. Not drawing the reader's attention away from the article is actually a positive thing, as I believe many editors would object to their presence otherwise. That said, if we can come up with a more modernized yet sensible design for {{Portal}} I'd be interested to see it get implemented. I feel that {{PortalButton}} needs some work though; it's not there yet, and I certainly wouldn't want to inject it into articles in its current form. It may be suitable for portalspace though, with some tweaks. — AfroThundr ^{(u · t · c)} 00:45, 17 June 2018 (UTC)

The current Mediawiki image syntax works, sure, but the presentational options are limited. PortalButton can work as a gallery, as a colourful wrapper for individual pictures, and several templates together can make a functional portal UI.

Ya there's a couple of rendering issues in specific cases, but that's mainly due to my limited knowledge of CSS, not inherent problems with the idea.

Using buttons would be a modernization in design, and one that could help drive traffic to portals. Far from sakeless, and given that portal links are at the end of articles it wouldn't detract from the actual content.

I'm very busy with work at the moment, and will be for the foreseeable future. So I won't be developing the PortalButton further anytime soon.

Hopefully another editor will see value in the idea and take up the mantle. It has potential to improve certain design aspects greatly; beyond 'adequate'. Cesdeva ^(talk) 01:45, 17 June 2018 (UTC)

(edit conflict) Using images as buttons has multiple problems or challanges:

• Only a very limited set of image can be used, specifically those which are public domain or CC0. Other images are required to link to their description page to provide attribution
• Images containing text aren't generally translatable. There is a way to do it with SVGs, but requires more advanced knowledge.
• accessibility: Needs proper alt text; Looks pretty bad when images are turned off: colour contrast will fail MOS:COLOUR contrast requirements unless a light-coloured background is used
• There are multiple ways portal icons are currently used besides {{portal}}, e.g. {{subject bar}}, {{related portals2}}, wikiproject banners, {{portal bar}}, {{portal-inline}}; a large button-image-containing-text wouldn't be appropriate in all those situation.
• A larger size would create more layout problems, especially for articles linking multiple portals.

I think minor improvements to the existing templates, or some new way of using the existing icons, would be a better way to go. - Evad37 [talk] 01:46, 17 June 2018 (UTC)

The intended use would be limited anyway, so sourcing or creating cc-zero work would be fairly easy. I've released several

photographs myself already and have been working on some SVG's. The standard image alt= already works fine, and no-one said anything about not conforming to policy on contrast. There's always a lot of hot air being blown when new design features appear and it's all fairly weightless naysaying. Perhaps that is why the portal space is in, and will remain in, such a state. I'll leave you guys to keep polishing your turds. Cesdeva ^(talk) 15:13, 17 June 2018 (UTC)

Improved linkage to portals

Evad37 wrote above: "I think minor improvements to the existing templates, or some new way of using the existing icons, would be a better way to go."

Evad37, and everybody, what are your thoughts on ways to improve upon the current system of accessing portals from article space and elsewhere? Related to this, what ways would you suggest for using {{subject bar}}, {{related portals2}}, wikiproject banners, {{portal bar}}, and {{portal-inline}}?    — The Transhumanist   02:09, 17 June 2018 (UTC)

Actually, I would like to see a link in the title bar, or whatever the area is that FA stars are sited is called for the most relevant portal. I predict howls of anguish that the encyclopaedia wil be doomed, much wailing and gnashing of teeth, etc. from the usual group, but I suggest that when this goes to RFC a well argued selection of options is proposed, and that this may include different options depending on portal completeness and navigational functionality, with top spot resrved for complete and fully functional portals, which will also encourage portal builders to get the job done and automate as much as is useful to keep them in good shape.

Another point to consider, is how to deal with multiple portals. In most cases there will be one portal which is most relevant, and which should occupy the prime spot if and only if it is as good as or better quality than the other options. A less relevant portal should only take prime spot if it is significantly better quality than the more relevant option. Relevance can be judged to some extent by the importance given to the article by each WikiProject. Local consensus should deal with the majority of disputes.

Failing the title bar, the link might go in the infobox, or if there is no infobox, where the infobox would normally go.

The link should not be excessively obtrusive, but should be noticeable, or the whole concept becomes futile. Unused portals are wasted, and unless they are visible, and readers find out what they are, they will not be used. They should be a powerful navigation tool as well as an introduction to the topic, and it is up to us to prove that this is feasible, and show how it can be done. · · · Peter (Southwood) ^(talk): 06:58, 25 June 2018 (UTC)

I had not noticed {{subject bar}} previously. Is it used much?

{{Related portals}} does not seem very useful at first sight. Nor does {{portal-inline}}

{{portal bar}} seems usable for portals other than the most relevant to the article. If they have to go at the bottom of the article. · · · Peter (Southwood) ^(talk): 07:21, 25 June 2018 (UTC)

Infobox picture support for excerpts

@Certes, Evad37, Nihonjoe, and Wpgbrown:

During the conversion of portal introduction sections from using static excerpts and subpages, I noticed that picture support of the lead section in articles seems to be migrating to each article's infobox, rendering many leads otherwise pictureless.

The main ramification for portals is that {{Transclude lead excerpt}} and {{Transclude random excerpt}} present bare prose without picture support when used to present excerpts from articles supported by infobox pictures, rendering the files= parameter useless for those articles.

It would be really cool if these templates and their corresponding lua module could be enhanced so that the files= parameter recognizes pictures at the top of the article's infobox. Thoughts?    — The Transhumanist   03:11, 17 June 2018 (UTC)

The templates attempt to extract images from infoboxes. However, there are dozens of different syntaxes for specifying images, and Module:Excerpt may not deal with them all. Do you have an example of a portal where the image fails to appear? Certes (talk) 10:35, 17 June 2018 (UTC)

@Certes and Evad37: I wasn't aware that infoboxes were included. That's good news. Here are some examples of articles for which the infobox pictures do not show up:

Some articles with pictures in the infobox

House mouse (Mus musculus)

A mouse (pl.: mice) is a small rodent. Characteristically, mice are known to have a pointed snout, small rounded ears, a body-length scaly tail, and a high breeding rate. The best known mouse species is the common house mouse (Mus musculus). Mice are also popular as pets. In some places, certain kinds of field mice are locally common. They are known to invade homes for food and shelter.

Mice are typically distinguished from rats by their size. Generally, when a muroid rodent is discovered, its common name includes the term mouse if it is smaller, or rat if it is larger. The common terms rat and mouse are not taxonomically specific. Typical mice are classified in the genus Mus, but the term mouse is not confined to members of Mus and can also apply to species from other genera such as the deer mouse (Peromyscus). (Full article...)

I hope these help.    — The Transhumanist   03:59, 18 June 2018 (UTC)

It looks like the mw:Extension:Popups catches these. Perhaps the method it uses to identify them would be applicable to Lua? Are regexes easily converted to lua search strings?    — The Transhumanist   04:21, 18 June 2018 (UTC)

 Fixed, at least for the cases where the infobox wasn't detected because it didn't have "infobox" in the template name - Evad37 [talk] 06:17, 18 June 2018 (UTC)

Wow, you can see a big difference in Portal:Reptiles and Portal:Amphibians. Lots more pictures show up. Nice.    — The Transhumanist   08:39, 18 June 2018 (UTC)

@Evad37: Found another: the picture in Snake doesn't show up. I'll post more as I find them. Here's what it looks like in a box...    — The Transhumanist   09:06, 18 June 2018 (UTC)

Snakes

Approximate world distribution of snakes, all species

Snakes are elongated, limbless, carnivorous reptiles of the suborder Serpentes (/sɜːrˈpɛntiːz/). Like all other squamates, snakes are ectothermic, amniote vertebrates covered in overlapping scales. Many species of snakes have skulls with several more joints than their lizard ancestors, enabling them to swallow prey much larger than their heads (cranial kinesis). To accommodate their narrow bodies, snakes' paired organs (such as kidneys) appear one in front of the other instead of side by side, and most have only one functional lung. Some species retain a pelvic girdle with a pair of vestigial claws on either side of the cloaca. Lizards have independently evolved elongate bodies without limbs or with greatly reduced limbs at least twenty-five times via convergent evolution, leading to many lineages of legless lizards. These resemble snakes, but several common groups of legless lizards have eyelids and external ears, which snakes lack, although this rule is not universal (see Amphisbaenia, Dibamidae, and Pygopodidae).

Living snakes are found on every continent except Antarctica, and on most smaller land masses; exceptions include some large islands, such as Ireland, Iceland, Greenland, the Hawaiian archipelago, and the islands of New Zealand, as well as many small islands of the Atlantic and central Pacific oceans. Additionally, sea snakes are widespread throughout the Indian and Pacific oceans. Around thirty families are currently recognized, comprising about 520 genera and about 3,900 species. They range in size from the tiny, 10.4 cm-long (4.1 in) Barbados threadsnake to the reticulated python of 6.95 meters (22.8 ft) in length. The fossil species Titanoboa cerrejonensis was 12.8 meters (42 ft) long. Snakes are thought to have evolved from either burrowing or aquatic lizards, perhaps during the Jurassic period, with the earliest known fossils dating to between 143 and 167 Ma ago. The diversity of modern snakes appeared during the Paleocene epoch (c. 66 to 56 Ma ago, after the Cretaceous–Paleogene extinction event). The oldest preserved descriptions of snakes can be found in the Brooklyn Papyrus. (Full article...)

Ok, so this one isn't just a case of |weird_image_parameter_name = imagename.png (I can fix those). With Snake, the image we're after is inside <imagemap>...</imagemap> tags within an infobox template parameter. I'm leaving that one to the experts! WaggersTALK 09:35, 18 June 2018 (UTC)

 Done - Evad37 [talk] 04:40, 19 June 2018 (UTC)

What innovative features do Wikipedia forks have?

I've heard that Wikipedia forks augment WP's content in various ways. Are you aware of any? Perhaps we could implement something similar or better.    — The Transhumanist   08:41, 17 June 2018 (UTC)

Automatic slideshow

Is this possible?    — The Transhumanist   06:14, 20 June 2018 (UTC)

Only with javascript, as far as I am aware (so its unlikely we would be able to have it on for everyone by default). And not at all with the mobile website, which we can't even get to show a regular slideshow. - Evad37 [talk] 03:21, 21 June 2018 (UTC)

If you mean a slideshow that automatically changes images with a fixed interval, I find them generally annoying. Probably heavy on bandwidth too. Why would anyone want one? If it is a slideshow that is static until you click on "run slideshow button" (possibly the standard right pointing arrowhead used for video), then maybe. Manual slideshow is more useful most of the time and we have it already. Getting it to deal with text excerpts is a far more useful goal. · · · Peter (Southwood) ^(talk): 07:30, 25 June 2018 (UTC)

Section editing for portals

See User:Evad37/sandbox/portal for a possible implementation. It doesn't look quite right in some skins, but I think that should be fixable once TemplateStyles is available. - Evad37 [talk] 03:17, 21 June 2018 (UTC)

I like this too. Will use when available. · · · Peter (Southwood) ^(talk): 07:50, 25 June 2018 (UTC)

Mobile view support

Can a section be done in such a way that it is one thing for mobile viewers, and something else for non-mobile viewers?

For example, can Picture slideshow sections be presented as Selected picture sections for mobile viewers? Otherwise, portals with picture slideshows are essentially broken to a majority of our viewers. Thoughts?    — The Transhumanist   01:44,? 30 June 2018 (UTC)

Is there code to exclude display from mobile view and other code that only displays on mobile? Similar idea to noinclude and includeonly. With that we could provide two options until this becomes possible some better way. · · · Peter (Southwood) ^(talk): 14:52, 30 June 2018 (UTC)

Hiding things from mobile is possible by using elements with the class nomobile, but I don't think there's any equivalent for hiding things on desktop only. - Evad37 [talk] 15:35, 9 July 2018 (UTC)

Cesdeva was working on something to make portals view better in mobile devices.    — The Transhumanist   08:01, 11 July 2018 (UTC)

Template:Transclude thumbnail image from page

This would be similar to {{Transclude list item excerpt}}, but instead of gathering list items, it would gather thumbnail pictures (thumbnails, because those have captions). Then it would pick one at random and display it, adjusted to fit the width of the section it is in (like the picture size is adjusted in {{Random slideshow}}. This one, however is not intended to be a slideshow, but is for powering "Selected picture" sections.    — The Transhumanist   09:19, 15 July 2018 (UTC)

Discussions about overall portal design

Concerns regarding the one page portal model

Short on time, so briefly and bluntly: Is it possible to implement the ability to edit each "section" of the portal within the current one page portal model. If not, it may not be a good direction to continue in because I would actually argue that having a subpages for each section makes it easier to edit and manage the portal. Personally, I've never seen a problem with having 10 or so subpages for each portal. If being able to easily discern how many portals there are is the perceived issue, a category (e.g. Category:Main portal page) could be created along with a bot to place it on every portal page that is not a subpage (i.e. titles without a slash). — Godsy ^(TALK_CONT) 05:36, 7 June 2018 (UTC)

I think Portal:Sacramento, California is a bit big for a single page and would benefit from splitting into a handful of subpages with standard names, but it's a matter of opinion and the current arrangement is not wrong. Certes (talk) 10:49, 7 June 2018 (UTC)

Fundamentally this isn't a problem with the one-page idea - instead I think the problem lies with the use of {{box-header}} and {{box-footer}} templates to divide portal pages into "sections" instead of using actual sections. The reason we use the boxes is to control the layout of the page and allow 2 (or more?) columns instead of all the content going down the page in a straight line.

Perhaps we should work on an alternative to {{box-header}} and {{box-footer}}, utilising proper section headings but using css to make them appear as boxes. I'll have a tinker with that idea. WaggersTALK 11:29, 7 June 2018 (UTC)

Hmm, so after some very brief experimenting it seems there's no way to do this currently: While we can assign inline styles to particular elements, and customise our personal css styles, adding <style>...</style> tags to a page to attemt to control the style across the whole page is a no go. WaggersTALK 11:42, 7 June 2018 (UTC)

One subpage per box is certainly worth considering as a compromise. It could make editing a lot easier, while keeping the general concept of massively reducing redundant subpages where they are not really useful. The important thing is that whatever we develop should work and make maintenance easier or unnecessary. The 750 or so box-footers we got rid of were not doing anything useful at all. Using random transclusion templates means a large number of subpages can be reduced to one per box, while still being easier to edit and maintain than the old one-article - one subpage system. I still think that one page portals are a fine ambition though. · · · Peter (Southwood) ^(talk): 17:16, 7 June 2018 (UTC)

Wikipedia:TemplateStyles will be coming soon (in a month or so IIRC) which should fix that problem Galobtter (pingó mió) 17:19, 7 June 2018 (UTC)

I don't believe every portal needs to go to a fully single-page design. In all cases, we should attempt to reduce the number of subpages to only what's necessary, but forcing everything into the single-page format is probably not going to work out too well. I think one-page-per-section is a happy medium for those cases. That said, many portals, if not most, would still benefit from the single-page model. — AfroThundr ^{(u · t · c)} 20:34, 7 June 2018 (UTC)

List of one-page portals

We should track these. By "one-page portal", I mean one that has no subpages of is own, not even header or footer subpages.    — The Transhumanist   19:28, 7 June 2018 (UTC)

See Category:Single-page portals for a list. Add portals to the category by placing {{portal maintenance status|subpages=single}} at the top of the portal. - Evad37 [talk] 00:42, 20 June 2018 (UTC)

What portals are nearly there? (So we can finish them)

• Portal:Amphibians
• Portal:Community of Christ
• Portal:History of the Latter Day Saint movement

Non-portal pages

• Portal:Example
• Portal:Georgia (a disambiguation page)
• Portal:Human (a disambiguation page)

@The Transhumanist: I've tagged the first list with {{portal maintenance status|date=June 2018|subpages=single}} so they're all tracked now. — AfroThundr ^{(u · t · c)} 12:40, 15 June 2018 (UTC)

The other kind of banner

Quite a few portals use a banner image in the introduction or above it. By this I mean a wide panorama style image. Sometimes it includes an image of text, other times it is just for decorative purposes. There are technical problems with most of them.

1. An image of text is not machine-readable, making this an accessibility problem. This should be fixable by using alt text.
2. There does not seem to be a way to make them mobile view compatible. If the page is narrower than the image width, the page stops fitting the screen, and a scroll bar appears at the bottom, which does not look good, and makes reading the text a nightmare. This problem of not having a way to make the image width follow the page width is a general problem, and also manifests with galleries and slideshows. It looks really bad when the image extends beyond the box margin. Wikivoyage has a banner extension which manages this problem well, but I think Wikipedia needs to be able to handle percentage width for images.

If it does already, I have consistently failed to find either an example or an explanation of how to do it.

Is this a thing anyone here knows how to fix? · · · Peter (Southwood) ^(talk): 07:36, 6 July 2018 (UTC)

You'd have to use CSS to target the img element, where you could then set width:100% or whatever you like (see this answer). That would require TemplateStyles though, as it can't currently be done inline. — AfroThundr ^{(u · t · c)} 12:01, 6 July 2018 (UTC)

@Pbsouthwood: Do you still get those problems when {{content-did-you-know-articles}} in its own section on a data page, then use {{Transclude linked excerpt|data page}} on the page where the random article is to appear. If you can link a concrete example of a portal that should do this, then I'm willing to have a go at setting it up as a model. Certes (talk) 10:41, 3 June 2018 (UTC)

Dear Certes, Please feel free to try this for Portal:Bangladesh. In the worst case we can always revert back to the original. Arman ^(Talk) 11:17, 4 June 2018 (UTC)

I've created Portal:Bangladesh/Recognized content. Once the bot populates that page, I can look at changing Portal:Bangladesh itself to use it. This method won't be able to discriminate between DYKs on geography, literature, etc. Certes (talk) 12:13, 4 June 2018 (UTC)

@Armanaziz: The bot has finally run. This won't work as-is, because DYK shows content which isn't in the actual article. I'll keep trying but § Transclude Did you know items from the WP:DYKA archives describes an alternative which may be better . Certes (talk) 09:29, 8 June 2018 (UTC)

Is there any way of using a bot to take the list of DYKs from a project (ie JL-Bot recognized content listing output) and turn it into a wiki-coded text output with the DYKs (recent ones are now stored on the article's talk page). This would be a great help for small/sluggish projects where the new automated template doesn't produce much, if any, recent output, but the project has lots of old DYKs. I've previously done them myself by going to the talk page and cutting & pasting, but it's very time-consuming. Espresso Addict (talk) 13:24, 8 July 2018 (UTC)

Answering my own question, it looks like JL-Bot will do it -- has anyone tried playing around with this option? Espresso Addict (talk) 13:37, 8 July 2018 (UTC)

Discussions about portal-related templates

New Markers

I have created some new flags, which in my view should be added to all portals as a kind of classification system.

• {{Non-standard portal flag}} – use to mark a portal which cannot be easily maintained where there is no known maintainer.

Talk page instead. JLJ001 (talk) 20:41, 29 May 2018 (UTC)

• {{Maintained portal flag}} – use to mark a portal which has maintainers.
• {{Portal flag}} – use to mark a portal where the layout is standard and all new features and updates are wanted.

This will be marked on the talk page instead. JLJ001 (talk) 13:52, 29 May 2018 (UTC)

If the portal has a peculiar layout or is an example of a design incompatible with the latest updates, tag it with {{Non-standard portal flag}}, to avoid introducing errors, project bots and AWB users should skip pages with this flag.

Any portal with one or more active maintainers should be tagged with {{Maintained portal flag}}, those maintainers should be responsible for deploying any updates, therefore project bots and AWB users should skip pages with this flag.

Portals which are not maintained, or where the maintainers want all the latest updates automatically, can be tagged with {{Portal flag}}, project bots and AWB users should make sure to keep these portals up to date and free from errors.

All these flags are optional, but will make things much easier for everyone working on the project. I can add any additional features to these flags if needed. JLJ001 (talk) 10:15, 29 May 2018 (UTC)

Nice Cesdeva ^(talk) 11:35, 29 May 2018 (UTC)

Consolidate Them?

Perhaps it would be better to collapse these into a single template? Something like:

{{Portal flag|maintained=y|standard=y|wpport-autoedit=y|subpages=y|subpage-keep=y}}

Each of these flags should represent a single state/purpose and be set independently, which allows for more situations than mentioned above.

This is also more portable and would simplify management with a single template, that can be extended as needed. (We'll likely need to.) — AfroThundr ^(t•c) 12:17, 29 May 2018 (UTC)

Also, instead of adding them to the portal page, would it be better to tag the talk page instead, like we do with WikiProject Banners? — AfroThundr ^(t•c) 12:19, 29 May 2018 (UTC)

They must be visible while loading the page in JWB, so although the talk pages may be tagged as well, the actual pages must have a visible template on them. The idea of having them all in a single template is good, but note that although they indicate the state, JWB & etc will match a string, so there must be a common string for excluding edits from it. I suggest we tag these additional parameters in another template just for the talk page. (eg {{Portal flag talk}}) but retain the simple solution for bot/auto (in)exclusion. JLJ001 (talk) 12:27, 29 May 2018 (UTC)

If that's the case then we should probably stick with just tagging the portal vice the talk page. No need for excessive duplication of effort. And the wpport-autoedit parameter above was for flagging if auto editing was allowed. — AfroThundr ^(t•c) 13:42, 29 May 2018 (UTC)

Ok taking into account that the majority of portals will be wanting updates, I suggest that is kept on the talk page. This leaves the other two acting more or less like the maintenance tags placed on articles, only less obviously. JLJ001 (talk) 13:52, 29 May 2018 (UTC)

If the merged template suggestion (similar to above) is used, we wouldn't need to add that particular tag to the talk page separately, it would just be an additional (optional) parameter for the (soon to be) already existing tag. — AfroThundr ^(t•c) 15:13, 29 May 2018 (UTC)

I still can't get JWB to read the talk page for the presence of a tag telling it to not edit the page, but if this was possible, then we wouldn't need to tag the portal page itself. JLJ001 (talk) 15:18, 29 May 2018 (UTC)

• @AfroThundr3007730: I made a start, what sort of parameters are you looking for? JLJ001 (talk) 12:35, 29 May 2018 (UTC)
  • At the moment, just collapsing the existing states into the one template. We want to minimize our technical footprint on portals without sprinkling maintenance templates all over. Not sure if a parameter for flagging the existence of subpages would be necessary since we have PrefixSearch. I'll probably have more ideas later. @The Transhumanist: Can you think of any other useful things this project might like to tag portals with? — AfroThundr ^(t•c) 13:42, 29 May 2018 (UTC)

If the subpages are needed for the portal the noting their existence as desired could be useful? JLJ001 (talk) 13:52, 29 May 2018 (UTC)

So subpages=y|subpage-keep=y then. Parameters are cheap. Updated the example above. — AfroThundr ^(t•c) 15:17, 29 May 2018 (UTC)

• The talk page template could be made part of the wikiproject banner? JLJ001 (talk) 14:03, 29 May 2018 (UTC)
  • This would be a good idea, if we start tagging talk pages, just use the banner. This would mean we'd only need a single tag template for the portal page, and any other data could be added to the talk page banner. — AfroThundr ^(t•c) 15:13, 29 May 2018 (UTC)

I suggest we merge this task into the task to assess portal suggested by Evad at the bottom of the page. JLJ001 (talk) 15:18, 29 May 2018 (UTC)

Template Fixes

@JLJ001: what is the flag icon at the top of the page that {{Maintained portal flag}} generates supposed to link to? At present it just links to a non-existent page "The page to link to. This is where you will be taken when clicking the icon" , which obviously takes you to the wiki page inviting you to start the non-existent article. Perhaps you could fix this? I'm reluctant to deploy this template until it's working 100% Cactus.man ✍ 17:19, 29 May 2018 (UTC)

• @Cactus.man: An oversight on my part that. I have fixed this and it now links to Portal talk:{{PAGENAME}}. (the talk page of whatever portal page it's on). JLJ001 (talk) 17:25, 29 May 2018 (UTC)

Ideally whoever clicked on it can then discuss proposed changes on the talk page, but additionally if required, details on the maintenance schedule and layout of the portal could be put on the talk page as well. JLJ001 (talk) 17:27, 29 May 2018 (UTC)

@JLJ001: Yes, I see that now, makes sense. Thanks for your swift action. Cactus.man ✍ 17:32, 29 May 2018 (UTC)

On further thought, I have actually changed this to Portal talk:{{BASEPAGENAME}} so it will automatically link to the main talk page if used on first level subpages. However, this only goes one level down for second or third level supages. For Example: Portal:Opera/Selected audio/20 will link to Portal talk:Opera/Selected audio. There is nothing I can do about this, if talk page consolidation beyond that is needed, redirects could be used. JLJ001 (talk) 17:38, 29 May 2018 (UTC)

@JLJ001: Just use {{ROOTPAGENAME}} instead - Evad37 [talk] 17:43, 29 May 2018 (UTC)

I should have checked the manual, {{ROOTPAGENAME}} is so much better. Thanks. JLJ001 (talk) 17:47, 29 May 2018 (UTC)

New maintenance categories

• New maintenance categories for the flags: Category:Manually maintained portal pages & Category:Non-standard portal pages. JLJ001 (talk) 18:17, 29 May 2018 (UTC)
  • @JLJ001: Tagged and taxonomized. — AfroThundr ^(t•c) 19:26, 29 May 2018 (UTC)
  • Also a question: Would you need a visible template for AWB/JWB tracking or could you use a category instead? I'm wondering if we can just categorize each portal from the project banner on the talk page and just pull a category listing for auto-editing runs. Also, would it be better to merge those two templates into a single one with multiple perameters? Just thinking we could focus on one instead of maintaining a bunch of smaller ones. — AfroThundr ^(t•c) 19:41, 29 May 2018 (UTC)

JWB is a very basic interface with few/no options (it can't check categories or talk pages), and I have yet to see what AWB has (I think it's better), but I feel that a visible warning is the best way to avoid accidental manual and less organized disruption to portals in good faith (the problem at the opera portal was manual editing). Regarding merging them, I don't see the point to be honest, it looks like the Non-standard flag will barely be used, if at all, since any portals that aren't standard probably have a maintainer. And since standard unmaintained portals look like they will tagged as part of the wikiproject banner, that's another template and a new set of categories again. Personally I think there is more future in the talk page template, with these little flags more of a warning notice than anything with advanced usage. It would be good if we could use the talk page banner to arrange the portals by edit yes/no, but also maybe by type, topic, etc. I am not sure exactly what we can do, but it would be good to have categories like you suggest for getting lists to work on. JLJ001 (talk) 19:56, 29 May 2018 (UTC)

• Ok so if I get you, the main uses for those flags are:

1. Unmaintained portals (free game)
2. Unique portals (probably maintained, don't touch)

Any other scenarios I'm missing here? What about the case of unique yet unmaintained? Perhaps another use case for merging those templates and using parameters to record both states, you could have the icon change color if:

1. unique=n && maintained=n (free game for auto-editing)
2. unique=y && maintained=n (edit with care)
3. unique=y && maintained=y (don't touch)
4. unique=n && maintained=y (probably don't touch)

At least as far as auto-editing is concerned. Thoughts? — AfroThundr ^(t•c) 20:25, 29 May 2018 (UTC)

• As for the category tagging via talk page banner, that is certainly possible. See this edit to the Portal banner where Evad37 added the historical flag for me.

Using this method, we could add a flag for subpage retention, and whatever else we might need for portal tagging. — AfroThundr ^(t•c) 20:26, 29 May 2018 (UTC)

• The trouble is that I am seeing any tag on the actual portal as a black and white "don't touch" tag, much like {{in use}} or {{under construction}} to be used only if someone is doing the work themselves. The moment it goes beyond that we need a more visible statement/list detailing the situation, probably best suited for the talk page (like every other such template). If we have multiple parameter tags on the portal pages then updating them could be hard (example, updating a single parameter on Portal:Opera would take 300 edits). Whereas if we have one tag on the talk page then it's easy to find, read and update. Also I think we should scrap the non-standard (orange) flag and stick with the green one. (PS. I think you are about right on the nuance there, lets start with those parameters). JLJ001 (talk) 20:40, 29 May 2018 (UTC)

Portal templates affecting reflist templates

Moved from Wikipedia talk:WikiProject Football § Portal templates affecting reflist templates

I don't know why, but there is some bug were the portal template will affect the reflist template and stop the reflist from splitting into columns. One example is Newcastle United F.C., can someone good with templates have a look thanks. Govvy (talk) 17:15, 31 May 2018 (UTC)

On my screen it splits into three columns. Number 57 17:17, 31 May 2018 (UTC)

I tried it out on the other computer, I think it's bugged to smaller screen sizes, not sure why. Govvy (talk) 17:42, 31 May 2018 (UTC)

@The Transhumanist: Thoughts? Kees08 (Talk) 17:45, 31 May 2018 (UTC)

To help us track this down, please provide the name of the template(s) causing the problem.    — The Transhumanist   19:59, 31 May 2018 (UTC)

Most likely the fact the reflist was using the {{reflist|30em}}, rather than just {{reflist}}</reflist}}, which autocompletes the collumns now. Screensize would change a lot of things about this though. Lee Vilenski ^{(talk • contribs)} 10:57, 1 June 2018 (UTC)

Template:WikiProject Portals incorrectly marks itself as historical

Moved to Template talk:WikiProject Portals § Template marking itself as historical

 – — AfroThundr ^{(u · t · c)} 02:05, 2 June 2018 (UTC)

Can you nest substitution?

Can you subst: a template which in turn has subst: in it? How?    — The Transhumanist   08:45, 5 June 2018 (UTC)

Briefly got some internet. If the parent template has a span tag with nothing inside except a parameter, then sure. So on the page you want to edit, you just fill that parameter with the child templates. See my User:Cesdeva/sandbox.

In in more complex situation, you'd still nest in a parameter, but you'd have to custom write a wrapper around your nested template, to make it compatible with the parent. Cesdeva ^(talk) 09:15, 5 June 2018 (UTC)

(edit conflict) Is there a "template shim" that fully evaluates the templates its placed around into wikitext, before passing it to the template its placed inside? For instance:

{{outer template|{{shim|{{inner template1|param=foo}}{{inner template2|param=bar}}...|shimparam=baz}}|outerparam=quux}}

In the example the shim would evaluate all of its inner templates, then pass the resulting wikitext to the outer template for processing. And maybe shimparam could be used to pass certain values from the inner templates as well (regex maybe?), if that's possible.

If that doesn't exist, I wonder how difficult it would be to make one. Would it require a custom lua module? Is it even possible to do two "eval" passes on templates? — AfroThundr ^{(u · t · c)} 11:38, 5 June 2018 (UTC)

@The Transhumanist: Yes. To prevent the subst: being processed on the template itself, put it within <includeonly>...</includeonly> tags. The only downside is that standard transclusion no longer works correctly (but that limitation can probably be overcome if necessary). See [3], User:Evad37/X1, User:Evad37/X2 for examples. - Evad37 [talk] 11:28, 5 June 2018 (UTC)

See also Help:Substitution - Evad37 [talk] 11:31, 5 June 2018 (UTC)

WP:SAFESUBST may (or may not) help here. Certes (talk) 11:46, 5 June 2018 (UTC)

Rethinking portal flag templates

Two of our maintenance flag templates, {{maintained portal flag}} and {{non-standard portal flag}}, were posted to WP:TFD. Concerns were raised about the validity of maintenance flag templates on Portal pages, specifically the visual flag indicator. These concerns were raised before, and I think we should iron these out before doing much more with these flags.

Previously discussed in #New Markers (which started in #We should use flags), was the need for a visual indicator to users during AWB maintenance runs that signified to the editor that a page met certain criteria that required special care when editing, such as being actively maintained, or using significantly unique markup and design. Currently the use of these flags is a bit inconsistent: They were intended to be placed on the root portal page, not necessarily every subpage in the tree (see Portal:Opera).

It should be noted that these flags add the portals in question to tracking categories. I'll also note that these types of statuses can also be recorded with the {{portal flag talk}} template (still a work in progress), or added as additional parameters to {{WikiProject Portals}}, the same way the |historical= flag is done. Ideally we'd only need one template to record all of these statuses, in whichever namespace they should reside.

We currently track three different statuses for portals, with another planned:

1. Maintained status, via {{maintained portal flag}} or {{portal flag talk}}
2. Non-standard status, via {{non-standard portal flag}} or {{portal flag talk}}
3. Historical status, via {{WikiProject Portals}}
4. Subpage retention status (planned), via {{portal flag talk}}

Portal flags: Questions needing answers

These are the questions I want to start with:

1. Do we need an indicator for these statuses, visual or otherwise, on the portal page itself, or will the talk page suffice?
2. If an indicator is needed on the portal page, should it be visual, and where?
3. If an indicator is only needed on the talk page, should it be merged into the project banner?
4. What effect will this have on our ability to do batch runs while still respecting the flags?
5. Are there any other portal statuses that we should consider tracking?

Please post your thoughts and comments in the discussion section below.

Portal flags: Proposed end state

Barring technical restrictions, the ideal end state would look like this:

• These flags would be provided by {{portal flag}} for the portal page, and {{portal flag talk}} on the talk page.
• The indicator on the portal page would not be visible at the top of the page, if it needs to be visible at all.
• The talk page template would be merged into the project banner, if possible, to minimize our presence.
• These templates would only tag the root page, making subpage tagging unnecessary.

Portal flags: End state update

This is now the current state of affairs:

• These flags are provided by {{portal maintenance status}} for the portal page, and {{WikiProject Portals}} on the talk page.
• The indicator on the portal page will not be visible by default, and will be hidden behind a custom CSS rule.
• The talk page template has been merged into the project banner to minimize our presence.
• These templates will only tag the root page, making subpage tagging unnecessary.
• These flags will populate hidden tracking categories, to facilitate targeted maintenance.

Portal flags: Survey and discussion

FYI

 – Alternate discussion underway at TFD.

@The Transhumanist, Cesdeva, Evad37, Wpgbrown, Pbsouthwood, Certes, and Waggers: Pinging the usual players, input from everyone is welcome and appreciated. — AfroThundr ^{(u · t · c)} 13:43, 6 June 2018 (UTC)

I've added an idea of where I think we should end up. I believe we should consolidate the flags into a single template, or one per namespace if a template is required for both. I think this would provide the best balance between allowing for portal maintenance flags while keeping our footprint in portal space small. That said, there may be things I haven't considered yet, hence the survey. I may need to revise this as the questions get answered. — AfroThundr ^{(u · t · c)} 14:15, 6 June 2018 (UTC)

The talk page template (probably the project banner) should get the status from the template on the portal page (via Lua) to prevent them getting out of sync. Then adding the flag template to the portal page could both put the portal itself into a hidden tracking category, and cause an appropriate message to display on the talk page. Perhaps the flag template could also have some output that is hidden with CSS by default, but could be shown by users doing portal maintenance by adding a line to their personal skin/common css - Evad37 [talk] 15:58, 6 June 2018 (UTC)

I think that could be a good idea, but some editors who may want to change the portal may not see the flag, because they have not found the particular setting. To try to mitigate this it may be worth also adding the maintenance flags to talk pages as well, but not hide them when they are on talk pages (as proposed above). Wpgbrown (talk) 20:10, 6 June 2018 (UTC)

I made a start on the auto-detecting module: Module:Portal flag talk auto. More to come later, including integration with the talkpage project banner. - Evad37 [talk] 17:42, 7 June 2018 (UTC)

 Added to project banner, which effectively makes {{Portal flag talk}} redundant - Evad37 [talk] 02:18, 8 June 2018 (UTC)

Sweet, at that point, we could flag it as obsolete. Now I think we should consolidate the portal flag templates into a single {{portal flag}} that accepts multiple parameters. This shouldn't be difficult, since I'm getting better at editing templates. I can just merge them and add any additional flags we need to track, probably with a switch to toggle visibility too. I wanna iron out our plan for these before I jump too far into this though. Once we have consensus on the desired end state and behavior for these flags, I'll go ahead and implement.

Also a nit: Do you think the module might be better named "Portal flag auto"? I'm just thinking the module's functions aren't limited to the talk page. Also, there wouldn't be two of them for different namespaces, since it'd make the most sense to add any new functionality to the existing one. Or maybe I'm just being picky. — AfroThundr ^{(u · t · c)} 03:50, 8 June 2018 (UTC)

I'm not particularly fussed either way over the module name, but if it is to be changed, we should wait until the new combined template is created, and give the module a similar name.
On that point, maybe the combined template should be named {{portal maintenance status}} rather than "flag" – per the TFD, the "flag" name isn't necessarily obvious enough, and the flag image probably shouldn't be shown to readers.
With regards to parameters, I think they should be named parameters that are present if applicable (i.e. |maintained=yes or any other value to turn on the "is maintained" note). This should make it easier for the module (which looks at the raw unexpanded wikitext of the portal page) to determine which notes apply. - Evad37 [talk] 04:29, 8 June 2018 (UTC)

Back to the rename: Module:Portal maintenance status sounds like a good name. Curious, do modules redirect the same way templates do? It's only called from the two templates, but just wondering. If there are no objections, I'll move it. — AfroThundr ^{(u · t · c)} 05:07, 9 June 2018 (UTC)

Sounds good. Modules do not redirect by default; there is some code that can make them act like redirects, but I don't think that's necessary in this case, as the only direct uses of it are the project banner and the module documentation. - Evad37 [talk] 09:59, 9 June 2018 (UTC)

 Done and all relevant pages updated. — AfroThundr ^{(u · t · c)} 13:12, 9 June 2018 (UTC)

Portal flags: Integration with Template:WikiProject Portals

Moved from Template talk:WikiProject Portals § Portal flag integration

@Evad37: First off, thanks for building that module. I have a couple questions and comments.

• Should the secondary information on this template (historical, flags, future stuff) be folded under a [more] button? I seem to recall there is a threshold you can set for note collapsing. I guess for now we're only recording a couple things, so it doesn't really matter.
• The formatting for the flag information. Do we need that block to be highlighted? The flags are primarily for our batch maintenance editors, who will already know to look for them. Anyone else coming across these will (most likely) be doing manual edits anyway. Perhaps linking to a (to be constructed) page detailing all of the flags and their meaning would be a good idea?
• Another flag to be tracked: subpage retention. This one is for portals who have had their subpages triaged and pruned (not necessarily purged) to the minimum necessary, and should not be culled further. Single-page portals not applicable, of course. Can the module check if subpages exist, and if the flag isn't set, add the portal to another tracking category for triage?

Just a few thoughts I had, I'll probably have more questions later. Thanks again. — AfroThundr ^{(u · t · c)} 04:09, 8 June 2018 (UTC)

The note seems relatively important, and so I thought having them visible would be a good idea – the block highlighting prevents them from getting lost in a sea of talkpage boxes which are present on pages like Portal talk:Opera, since we really don't want them being overlooked. Though perhaps we could go without the bright yellow border. Having an overview page is a good idea, it should perhaps be at the proposed combined flag template's documentation. Checking if there are any subpages probably isn't possible, since the contents of special pages like Special:PrefixIndex isn't available to Lua modules. - Evad37 [talk] 05:40, 8 June 2018 (UTC)

If there isn't a programmatic way of retrieving subpages, then I suppose that one will have to be a manual parameter, like historical is. It shouldn't be a problem since the portals will have to be manually triaged anyway. The editor can just set the flag manually, once they're done. Speaking of which, how much work would it be to make the template also detect {{historical}} on the corresponding main page, and automatically set historical=y for those too? And another thing: the other flags should have a parameter that can be set manually if {{portal flag}} can't be used for some reason. Local values would override detected ones, or absent ones (although, maybe the template should display an error if it has conflicting values). — AfroThundr ^{(u · t · c)} 14:49, 8 June 2018 (UTC)

It should be easy enough to detect {{historical}}, actually – just need to generalise the existing module and provide a different entry point. This would just be pages in Wikipedia: space, right? As for manually setting the flags... doesn't that sort of defeat the purpose of detecting them automatically on the portal page? - Evad37 [talk] 01:09, 9 June 2018 (UTC)

The point of exposing parameters to override the auto detection is for when there is not template on the main portal page, and it cannot be added for whatever reason. You would then be able to specify it directly in the banner parameters. This obviously opens up an avenue for conflicting values from autodetected vs manual values, so manual should take precedence or give an error. — AfroThundr ^{(u · t · c)} 01:37, 9 June 2018 (UTC)

I can't think of when it wouldn't be able to be added to the main portal page though. Even if fully protected, an edit request can be made (and note left here for our friendly admins). - Evad37 [talk] 02:39, 9 June 2018 (UTC)

Not edit-protected so much as potential deletion or clobbering by other editors. WikiProject banners are less likely to be damaged since they reside in a talk page's header, where there is less editing traffic. I'll admit it is an unlikely scenario, but it doesn't hurt to have them. Plus this would make things like demos easier for the documentation. If you think manual overrides are unnecessary, then I'll leave it be until I actually encounter it in the wild. — AfroThundr ^{(u · t · c)} 03:41, 9 June 2018 (UTC)

@Evad37: just curious if you've had time to implement the code to detect {{historical}} yet. With that in place, we wouldn't need to expose it as a parameter, since it would be controlled by the template on the main page. Unless you think the utility of a talk page local override necessitates its retention. I'm indifferent on that at this point. — AfroThundr ^{(u · t · c)} 03:27, 11 June 2018 (UTC)

 Done now. I've removed the parameter; we can always add it back if for some reason we need it again. - Evad37 [talk] 04:14, 11 June 2018 (UTC)

Portal flags: Module and template code consolidation

Another question: right now the module is duplicating the work of the template in generating the messages for the project banner. This means when the maintenance template code gets updated, the module must be updated as well to maintain parity, which could mean them falling out of sync. I don't trust my Lua knowledge enough to add the recent changes (for now). Would it make sense for the module to detect the template on the main page, then embed it into the project banner (with necessary logic added to the template to detect being embedded) with all the same arguments as-is? Or would it be better to consolidate all the logic in the module, with both templates pulling the text content from the module? Just thinking of how we can deduplicate and centralize changes between the set. — AfroThundr ^{(u · t · c)} 03:42, 11 June 2018 (UTC)

Adding an |embed= parameter to the template might make more sense, so as not to use up Lua time on portal pages – some of the other portal automation modules can take up a fair chunk of the allotted Lua processing time. - Evad37 [talk] 07:14, 11 June 2018 (UTC)

Portal flags: Removal of stale maintained status

Issue raised in the TFD:

How is tagging something as maintained is misleading since when it becomes unmaintained, the nonexistent maintainer doesn't remove it addressable by editing? — JJMC89 (T·C) 23:04, 8 June 2018 (UTC)

The template just needs a |date= parameter, automatically filled in by AnomieBOT, and a process for removal, such as a portal_talk page message after some reasonable amount of time (e.g. six months), requesting that the maintainer update the date if they're still active, and automatic removal of the maintained status a short time later (e.g. one month) if not updated. - Evad37 [talk] 00:40, 9 June 2018 (UTC)

Or even skip the talk page message, as long as removal is done without a bot flag, and with a very clear edit summary. - Evad37 [talk] 00:44, 9 June 2018 (UTC)

No point making a bot request till other issues (TFD, merging) get resolved. But does six months sound about right for the timeframe? Can we do without a talk page message? - Evad37 [talk] 00:52, 9 June 2018 (UTC)

I'd maybe even shorten it to 3 months. If a portal doesn't have an edit by then, it falls out of maintained status, or maybe multiple phases? Fresh: sub 30 days, stale: 30 to 60 days, outdated: over 60 days, with each in a tracking category. Perhaps add an optional timespan override parameter to the template to allow for tailoring for portals that don't need regular tweaking. — AfroThundr ^{(u · t · c)} 01:34, 9 June 2018 (UTC)

I also don't think posting on the talk page would be necessary (or desired, if there is a large volume of them) as long as the "flags are outdated" message emitted by the template (and the project banner) link to an adequate help text, probably in the template documentation. And to revise my time estimates eariler: 90 days should be the cutoff for fresh portals, after which they fall into a stale category, then at 180 days they are marked as outdated/attention needed. What do you think? — AfroThundr ^{(u · t · c)} 03:20, 11 June 2018 (UTC)

Doing it based on the number of months is easier than the number of days, since only the month+year is actually recorded in |date=. In terms of the "fresh" status, the main reason I suggested a longer timeframe was to avoid annoying portal maintainers too often – a couple, or a few, edits a year seems reasonable, to show a sustained interest. And I don't think the "stale" period needs to be as long as 90 days – around four weeks should be enough, since its really just a grace period between the flags being valid and invalid. I think removal should require an actual edit (by bot, awb, or manually), rather than just template logic, so that it actually shows up on watchlists and page histories. We don't really extra "stale" or "outdated" categories, since the portals will already be in dated maintenance subcategories. - Evad37 [talk] 07:01, 11 June 2018 (UTC)

Ideally this should only apply to portals that need maintenance. If we can produce automatically updating portals then this should not apply to them. · · · Peter (Southwood) ^(talk): 09:00, 18 June 2018 (UTC)

Portal flags: New template

I've started working on {{Portal maintenance status}}, as a proposed merged template. Instead of a top-icon flag, it uses a hidden-by-default message box, which those working on portal maintenance can display with custom css. @AfroThundr3007730: Did you want to add something for subpages to the template? - Evad37 [talk] 02:46, 9 June 2018 (UTC)

Good stuff, I like it. And yes I did want to add an argument for subpage triaging: subpages=( (0|untriaged|<empty>) | (1|triaged) | (2|single[page]) ) This flag would be set when a portal has been pruned of unnecessary subpages ("unnecessary" being subjective) and any portals tagged with this template without that flag set would be added to Category:Portals with untriaged subpages, and it would also populate Category:Single-page portals, as appropriate. The intent, of course, is not to wage war on subpages so much as reduce their number to a manageable level, as has been discussed elsewhere on this page. Single page portals should have this set automatically, if possible. Or maybe we need a separate singlepage flag, which could also be useful, and would populate another tracking category, that overrides the subpages flag. Just thinking out loud here. If you can think of other metadata tracking flags that would be useful in supporting project maintenance tasks, feel free to add to this. — AfroThundr ^{(u · t · c)} 04:34, 9 June 2018 (UTC)

Thanks for adding subpages to the template. Now we just need to update the module to provide parity in the WikiProject banner. Also, can we make the template expose the date it was last updated, kind of like {{refimprove}} and friends? I also made {{portal flag}} into a redirect to {{portal maintenance status}}. — AfroThundr ^{(u · t · c)} 13:18, 9 June 2018 (UTC)

The template does now display the date; thanks - Evad37 [talk] 00:48, 11 June 2018 (UTC)

I think the new template and module are now ready to be used, and I've updated my TFD !votes accordingly, but because of the bureaucracy of the TFDs we shouldn't be making widespread replacements. - Evad37 [talk] 00:48, 11 June 2018 (UTC)

Are we not allowed to begin the replacement of our own accord until the TfD is closed? That's a bit annoying, but there's not really a rush to move on this yet, I guess. — AfroThundr ^{(u · t · c)} 03:45, 11 June 2018 (UTC)

It's bad form to make edits that bypass discussion in order to achieve a fait acompli. Plus it is specifically mentioned at WP:TFD#Discussion: Templates are rarely orphaned—that is, removed from pages that transclude them—before the discussion is closed. - Evad37 [talk] 06:39, 11 June 2018 (UTC)

Errors with some portals after replacing /box-footer

@The Transhumanist and Pbsouthwood: As I was organizing portals for the Society and Social sciences section of Portal:Contents, I stumbled on a couple of portals that are throwing errors: Portal:Monarchy and Portal:Military of Pakistan. It seems that, after you replaced the /box-footer subpage with {{Box-footer}}, a few portals still need to have the subpage. The error is caused by {{Random portal component}} and {{Random portal component with nominate}} because the error appears only in the boxes where those templates are used. I have figured out that the Lua module for those templates tries to find the /box-footer subpage to make the template, but that doesn't explain why portals like Portal:History do not throw errors with the same template and module when you have deleted the /box-footer subpage there as well. Greatedits¹ _{(I hope so | If not, let me know)} 01:55, 7 June 2018 (UTC)

Also happening on Portal:Special Operations and all of the "Prehistory of ..." portals. Greatedits¹ _{(I hope so | If not, let me know)} 02:20, 7 June 2018 (UTC)

@Greatedits1, Pbsouthwood, and Evad37: Okay, I think I fixed it, with this edit to Module:Random portal component. Hopefully that doesn't cause other errors. :)    — The Transhumanist   02:53, 7 June 2018 (UTC)

Yep, those pages are fixed and it doesn't cause errors on Portal:History or Portal:Narnia. If you are thinking of replacing /box-header subpages at some point, it looks like you would have to do the same sort of thing again. Anyway, thanks! Greatedits¹ _{(I hope so | If not, let me know)} 04:03, 7 June 2018 (UTC)

Picture slideshow and Media Viewer

I noticed that pics in a portal's slideshow do not show up in Media Viewer. Do you have any idea why? Just curious.

Also, clicking on a picture in the slideshow goes to the file page, rather than the Media Viewer. It's a mystery to me. Could you clue me in? :)    — The Transhumanist   09:21, 17 June 2018 (UTC)

Template:Transclude lead excerpt

Portals that the {{Transclude lead excerpt}} template isn't catching the pictures in...

@The Transhumanist: I've updated the image detection code, can you check if there's any besides Germany still missing an image? - Evad37 [talk] 09:42, 13 July 2018 (UTC)

@Evad37: Happy to. All done (with those listed below). Very very nice. Note that Heavy metal wasn't missing an image - the image shows up at the end of the section, hanging off the bottom of the text, creating a bunch of white space to the left of it.    — The Transhumanist   10:14, 13 July 2018 (UTC)

Resolved issues

Portal:Geneva @Certes and Evad37: In Portal:Geneva, the template isn't picking up the pics from the infobox in the lead of Geneva. I'll keep posting 'em as I come across 'em. ;)    — The Transhumanist   06:12, 12 July 2018 (UTC)  Done Portal:Geography of Canada {{Transclude lead excerpt}} isn't picking up the map image from the infobox in Geography of Canada.    — The Transhumanist   06:43, 12 July 2018 (UTC)  Done Portal:Georgia (U.S. state) This one isn't picking up the flag, seal, and location map from the infobox.    — The Transhumanist   06:48, 12 July 2018 (UTC)  Done Portal:Ghana This one picks up the flag, but not the seal or locator map.    — The Transhumanist   06:53, 12 July 2018 (UTC)  Done Portal:Gibraltar Same here. (Shows flag, but nothing else).    — The Transhumanist   06:55, 12 July 2018 (UTC)  Done Portal:Gilbert and Sullivan Their portraits don't show up.    — The Transhumanist   06:57, 12 July 2018 (UTC)  Done Portal:Gilgit-Baltistan Most of the pictures don't show up.    — The Transhumanist   07:00, 12 July 2018 (UTC)  Done Portal:Goa No pictures show up.    — The Transhumanist   07:03, 12 July 2018 (UTC)  Done

Portal:Germany

Flag, seal, and location map not show up.    — The Transhumanist   06:50, 12 July 2018 (UTC)

The file description page for the flag includes the phrase "non-free", which causes the script to skip it – see Module talk:Excerpt#Free image not appearing - Evad37 [talk] 08:49, 18 July 2018 (UTC)

Portal:Heavy metal

The picture shows up at the end of the intro, rather than starting at the top.    — The Transhumanist   07:20, 12 July 2018 (UTC)

This is the same issue as Module talk:Excerpt § Placement of image in excerpt - Evad37 [talk] 02:43, 16 July 2018 (UTC)

Which has now been fixed. Looks much better. Thanks to Certes. Cheers, · · · Peter (Southwood) ^(talk): 18:10, 16 July 2018 (UTC)

Portal:Bohol

@Certes and Evad37:

Here's the excerpt:

Bohol (Tagalog pronunciation: [buˈhol]), officially the Province of Bohol (Cebuano: Lalawigan sa Bohol; Hiligaynon: Kapuroan sang Bohol; Tagalog: Lalawigan ng Bohol), is an island province of the Philippines located in the Central Visayas region, consisting of the island itself and 75 minor surrounding islands. Its capital is Tagbilaran. With a land area of 4,821 km² (1,861 sq mi) and a coastline 261 km (162 mi) long, Bohol is the tenth largest island of the Philippines. (Full article...)

"Is a ____ of the". Words have disappeared from the definition.    — The Transhumanist   19:30, 16 July 2018 (UTC)

Bohol's wikitext (omitting irrelevant complications) reads '''Bohol''' is a {{PH wikidata|settlement_text}}. {{PH wikidata}} gets wikidata for the current page. In the article, the current page is Bohol which has wikidata. In the portal, the current page is Portal:Bohol which quite correctly doesn't have wikidata. All the potential fixes that I can think of rely on MediaWiki features that don't exist. Certes (talk) 22:29, 16 July 2018 (UTC)

The article probably shouldn't even be using Wikidata in prose in the first place. WP:Wikidata#Appropriate usage in articles says it is "not appropriate to use Wikidata in article text on English Wikipedia". - Evad37 [talk] 01:37, 17 July 2018 (UTC)

 Done Removed it from the root aritlcle's lead.    — The Transhumanist   04:55, 18 July 2018 (UTC)

Portal:The X-Files

The image in the infobox doesn't show up.    — The Transhumanist   06:55, 18 July 2018 (UTC)

That's because File:Thexfiles.jpg is a non-free image - Evad37 [talk] 08:44, 18 July 2018 (UTC)

Portal:Togo

@Certes and Evad37: The coat of arms from the infobox doesn't show up, even though the other 2 images do.    — The Transhumanist   07:08, 18 July 2018 (UTC)

Template:Transclude list item excerpt

@Certes and Evad37:

This is a cool template.

As an experiment, I created or rebooted the following portals using the corresponding outlines as a base. (Reboots are marked with an asterisk).

• Portal:Athens
• Portal:Dresden
• Portal:Dubai *
• Portal:Florence
• Portal:Kyoto
• Portal:Milan *
• Portal:Munich *
• Portal:Palermo
• Portal:Prague *
• Portal:Saint Petersburg
• Portal:Stockholm
• Portal:Turin
• Portal:Vienna *

I ran into a few issues...

Issue #1: section links are misrecognized as the root article

When a list item is a section link, the template shows the lead of the page rather than the section. This is awkward when the section desired is on the root article, thereby duplicating the lead that is at the top of the portal.

For example, in the Environment section of the Outline of Dresden is the link [[Dresden#Climate|Climate of Dresden]]. When that is displayed in the "Selected environment article" of Portal:Dresden, it comes up as Dresden rather than the Climate section of Dresden. Which is awkward, because that is the same lead that is at the top of the portal. The same thing happens in the Sports section.

Issue #2: Including subsections is awesome, but is not always desired

One thing I really like is that the template gets all the links from the subsections as well. This works in most cases, but there are some in which I'd only want the root part of the section.

For example, Outlines have an Economy and infrastructure section. One of the subsectons is transportation, which usually dominates the section. For portals where I would like both and Economy section and a Transportation section, the Economy section would cover the same articles as the Transportation section. If I had just an Economy section, most of the articles that showed up would be about transportation.

Cool shoes

My assessment of the template is that it is awesome. When there are standard list sections to access, like with outlines, you can pop out a portal based on them from between 15 to 25 minutes per portal. I'm sure we can get this time down even lower...

The most time consuming part of building the portals above was compiling the image list in the pictures section. I essentially copied and converted the file links from the corresponding outlines, retaining their captions.

This has given me an idea for another template, {{Transclude random thumbnail from page}}, which would extract file thumbs instead of list items. It could be used to fetch a picture for a "Selected picture" section without the need for a compiled list of file arguments. (It wouldn't be a slide show). It could also have a section parameter like the one {{Transclude list item excerpt}} has. A transclusion template like this could save a portal builder/maintainer lots of time.    — The Transhumanist   14:58, 13 July 2018 (UTC)

I've added sectiononly=yes to address issue #2. Certes (talk) 10:49, 15 July 2018 (UTC)

Template: Box portal skeleton

I'm thinking the template should be converted to use our {{Box-header color}} variant, so that going forward, we don't make more instances of {{box-header}} that we have to clean up later. Plus, it would make every new portal from now on have an auto-generated color scheme, instead of the same one. Thoughts? — AfroThundr ^{(u · t · c)} 18:26, 18 July 2018 (UTC)

AfroThundr, great idea. Would you like to do the honors? ;)    — The Transhumanist   22:52, 19 July 2018 (UTC)

 Done. I tested it with a quick example here and didn't see any obvious problems. On another note, the {{transclude selected recent additions}} was set to |months=120, which I've noticed resulted in Lua timeouts on several occasions (the sandbox being one). I've reduced it to a year, unless we can figure out how to prevent that (or the portal maintainer can tweak it manually anyway). — AfroThundr ^{(u · t · c)} 23:40, 19 July 2018 (UTC)

Discussions about categories

Category trees

Can category trees be induced to display in columns? · · · Peter (Southwood) ^(talk): 07:24, 8 June 2018 (UTC)

{{Div col}} works: example. Certes (talk) 09:07, 8 June 2018 (UTC)

Discussions about specific portal technical issues

Portal:Biographies talk page issue

@The Transhumanist: According to this edit made to the Portal talk:Biography page, you enabled a recognized content listing on the main talk page. Was that intentional? At the moment JL-Bot has added 1.5 megabytes of text listing all of those pages. I've reverted the bot and the config. The Wikipedia:WikiProject Biography#Recognized content page just redirects to Category:FA-Class biography articles, so I guess they aren't using that bot. I was wondering why that page refused to load in AWB, and now I know it doesn't like pages over 1500k. — AfroThundr ^{(u · t · c)} 17:12, 2 June 2018 (UTC)

I did that to hundreds of portal talk pages, as a prelude to adding two possible sections to portal pages: 1) Quality content 2) DYK blurbs. Both handled by JL-bot. Rather than go straight to portal page, it was better to display the links in a test area where we can take a look at them first. In preparation for eventual related AWB runs on the portals, I intend to look at these, to see if I notice any patterns, anomalies, volume, etc.    — The Transhumanist   07:28, 3 June 2018 (UTC)

Portal:Toys missing selected pictures

I have an issue - the toys portal has two selected pictures missing , How can we fix that ? Kpgjhpjm (talk) 03:20, 5 June 2018 (UTC)

Short answer: They were deleted.

Explanation: From looking at the relevant subpages, image 1 had the following edit, and image 2 had the following edit. They in turn bring us to these two deletion requests here and here. It would seem that those images are still under copyright, and commons policy required their deletion, despite their still being in use. You will most likely have to find an alternative to replace them. There are plenty you could pull from Category:Toys. — AfroThundr ^{(u · t · c)} 04:11, 5 June 2018 (UTC)

Portal:Ferrari

I am having a bit of trouble adding a name to the Formula 1 drivers list . Can anybody help ? Kpgjhpjm (talk) 11:57, 5 June 2018 (UTC)

The list isn't stored directly in Portal:Ferrari. The list which appears in the "Categories" box (after you click the arrow by "Ferrari people") is Category:Ferrari Formula One drivers. To add a driver to that list, you need to edit the driver's article and add the line [[Category:Ferrari Formula One drivers]] near the bottom. The list in the "Selected Topics" box is transcluded from Portal:Ferrari/Topics. It can be changed by editing that subpage. Hope that helps, Certes (talk) 12:55, 5 June 2018 (UTC)

@Certes: Can you go to the portal and fix it . Actually you only have to add a dot between the bracket , but I do not have such a symbol . Kpgjhpjm (talk) 15:02, 5 June 2018 (UTC)

Resolved

I just copied and pasted one of the other dots. Certes (talk) 15:06, 5 June 2018 (UTC)

Help with WP:ANATOMY portal (Portal:Anatomy)

Moved from Wikipedia talk:WikiProject Portals § Triage

Hi all, thanks for your great work. Have tried to implement some of your changes onto the anatomy portal, however having some difficulty working with some sections and would value some help if possible:

1. If someone could help with the column display that would be really appreciated (so that there are no spaces between sections)
2. I can't get images to insert into the random article sampler... this works for the random biography but not for articles. Would appreciate if someone knowledgeable could help fix this :)

On our way to a one page portal! --Tom (LT) (talk) 01:09, 8 June 2018 (UTC)

ADDIT: I think I've fixed part 2, but if someone could have a look and simplify or remove unnecessary "divs" and formatting that would really help make the page more editable. --Tom (LT) (talk) 01:12, 8 June 2018 (UTC)

Thanks, I consider this done. --Tom (LT) (talk) 23:09, 9 June 2018 (UTC)

Portal:Poland/box-footer undelete

(Copied from User talk:Pbsouthwood, as it may have general relevance)

Hi Pbsouthwood, could you please undelete Portal:Poland/box-footer? It's still needed. Thanks — Kpalion^(talk) 15:42, 9 June 2018 (UTC)

Kpalion,  Done. Note that it is trivially simple to substitute the generic {{Box-footer}} as it is exactly the same thing disguised with another name. Cheers, · · · Peter (Southwood) ^(talk): 17:00, 9 June 2018 (UTC)

Thanks! Replacing the template is not that trivial to me, as I don't even know where exactly it is used. I only know that its deletion messed up the layout of Portal:Poland/Selected picture. Can you tell me where I should make the replacement? — Kpalion^(talk) 23:51, 9 June 2018 (UTC)

Kpalion, That may be less trivial than I thought, as I cannot find it in use anywhere. There is no visible use in Portal:Poland/Selected picture. It should be easy to fix once we find it. I will be unavailable for editing most of today, so will copy this discussion to the WikiProject talk page in the hope that someone else can work out what is going on. Cheers, · · · Peter (Southwood) ^(talk): 04:49, 10 June 2018 (UTC)

Can anyone track down where the template is being called from? · · · Peter (Southwood) ^(talk): 04:57, 10 June 2018 (UTC)

I've turned Portal:Poland/box-footer into a redirect to the actual {{box-footer}} since all that page did was call the real one. I'm not seeing any layout issues at the moment, but it might be because that page was re-created (and redirected to the main template). Still don't see what's calling the subpage version though, anyone else got any ideas? — AfroThundr ^{(u · t · c)} 13:21, 10 June 2018 (UTC)

@AfroThundr3007730 and Pbsouthwood:  Done Found the problem. First the Template:Numbered subpages is called, then this template calls the Module:Numbered_subpages, which has a line of code:

frame:expandTemplate(title='subpage',args={i})

This then in turn calls Template:Subpage, which calls the /box-footer page (for the respective portal).

I have changed the code on Template:Subpage to link to {{Box footer}} instead of the /box-footer page. I have marked the redirect for deletion as it no longer is used. Wpgbrown ^{talk | contribs} 13:35, 10 June 2018 (UTC)

Devious bit of code there! I thought it might be something like that, but I would never have recognised the line responsible, or been able to fix it, so thanks Wpgbrown for that bit of work. Kpalion, Looks like it was not so trivial after all. Sorry about that, it usually is trivial. I will delete the redirect, and if you have any further problems let us know. Cheers, · · · Peter (Southwood) ^(talk): 15:15, 10 June 2018 (UTC)

I don't see any problems now. Thank you, guys! — Kpalion^(talk) 18:38, 10 June 2018 (UTC)

Yeah, I had a look at the module, but I didn't even notice that. I gotta step my Lua game up. Thanks y'all. — AfroThundr ^{(u · t · c)} 23:25, 10 June 2018 (UTC)

Some off-portal side effects

See Wikipedia:Village_pump_(technical)#Wikiproject_front_page_displaying_bizarrely

The deletion of Portal:Cornwall/box-footer affected the front page layout of Wikipedia:WikiProject Cornwall as it was transcluding some portal boxes. I think this was another of those calls from within a transcluded template which called a module which called a subpage. This may happen elsewhere too, please keep a lookout for similar usage when listing for deletion.

Does anyone know how to check if this will happen? Cheers, · · · Peter (Southwood) ^(talk): 15:26, 13 June 2018 (UTC)

What links here shows transclusions as well as direct links. This has to be said: marking things for speedy deletion without using Special:WhatLinksHere to check whether they're still in active use is a tad irresponsible. (To be fair, the deleting admin should check as well, but usually WP:G6 requests are trustworthy and we're all busy people). I know we're excited about the new tools we have that enable us to tidy up the mass of portal subpages but I think we need to calm things down a bit. WaggersTALK 09:45, 14 June 2018 (UTC)

Replacing the /box-footer line with {{Box-footer}} should fix the problem. Some clean up is to be expected on mass deletions of this sort. Just report broken pages here, and we'll gladly and promptly fix them.    — The Transhumanist   21:29, 15 June 2018 (UTC)

Portal:Agriculture and agronomy

@Certes: A sidebar navigation box is mysteriously showing up in the intro section.    — The Transhumanist   21:21, 15 June 2018 (UTC)

@The Transhumanist: Portal:Agriculture and agronomy transcludes Agriculture which transcludes {{Agriculture}} which #invokes Module:Sidebar. {{Transclude lead excerpt}} isn't clever enough to spot that, and it's hard to see how it could be improved to do that type of analysis reliably and efficiently. One possibility is to edit the Agriculture article to enclose the Agriculture template in a noinclude tag. Certes (talk) 21:59, 15 June 2018 (UTC)

@The Transhumanist and Certes: I went with the latter option. Looks good now. — AfroThundr ^{(u · t · c)} 22:15, 15 June 2018 (UTC)

That's a good tip. I didn't know that. Thank you. Maybe we should include that on a trouble-shooting page.    — The Transhumanist   22:18, 15 June 2018 (UTC)

Making any kind of change to the article to make it work properly in the portal is an indication of bad code design. {{3x|p}}ery (talk) 18:28, 28 June 2018 (UTC)

I'm sure we'd all be grateful if someone could improve Module:Excerpt to detect and handle such cases. A problem is that there is no rigorous definition of "the lead" for use in implementing a bulletproof parser. Certes (talk) 18:38, 28 June 2018 (UTC)

Would it work to modify the module to remove all lines that consist entirely of templates and nothing else. {{3x|p}}ery (talk) 18:40, 28 June 2018 (UTC)

Not really, since the module currently needs to parse some kinds of templates. For instance, it looks inside infoboxes to extract the image to use for the displayed article excerpt. — AfroThundr ^{(u · t · c)} 20:59, 28 June 2018 (UTC)

That could work. We already do that for lines before the lead. I wasn't expecting a line consisting only of a template between the lead and the first section heading (or in the middle of the lead) but it would probably be safe to remove such a line. Infoboxes are already handled specially: they are removed but are searched for images on their way out. Certes (talk) 21:22, 28 June 2018 (UTC)

One snag: how do we tell the difference between unusually formatted but valid wikitext with a template we want to keep:

Pleasanton is a village

{{convert|5|mi|km}}

from Famousville.

and unwanted templates:

Pleasanton is a village.

{{Villagebox|name=Pleasanton|duckpond=yes}}

It is near Famousville.

? Should we just assume that the first case is unlikely, and accept that we will occasionally lose a bit of text? — Certes (talk) 21:43, 28 June 2018 (UTC)

That may be for the best. Even the navigation popups give up eventually with some templates (formulas and such) in the article text. — AfroThundr ^{(u · t · c)} 02:09, 29 June 2018 (UTC)

Thanks. I'd rather not change the Lua code today as I'm about to go on holiday and don't want to risk leaving a mess, but if it's not been done when I return then I'll have a go. Certes (talk) 10:58, 29 June 2018 (UTC)

Portal:Cenozoic

Someone please close Wikipedia:Miscellany for deletion/Portal:Cenozoic. The nominator has withdrawn his nomination. Thank you.    — The Transhumanist   11:04, 17 June 2018 (UTC)

 Done --Ancheta Wis   (talk | contribs) 12:06, 17 June 2018 (UTC)

Portal:Tamil civilization

Someone please close Wikipedia:Miscellany for deletion/Portal:Tamil civilization (2nd nomination). The nominator has withdrawn his nomination. Thank you.    — The Transhumanist   02:03, 18 June 2018 (UTC)

 Done · · · Peter (Southwood) ^(talk): 18:10, 18 June 2018 (UTC)

Portal:Mesoamerica

In the Associated Wikimedia section, is it possible to link Wikisource to a category, rather than a search? Wikisource has a Category:Mesoamerica that is much more useful than the results returned by a search on the word "Mesoamerica". Thanks, Simon Burchell (talk) 08:52, 18 June 2018 (UTC)

It is possible, but would require customising the section. Alternatively the template could be customised, allowing a choice between search and category for each project. I don't know whether this would be worth the effort, but suspect that it might be. Does anyone else have an opinion? A lot depends on whether the portal topic title is a valid category in the other projects, which may be the case only sometimes and for some portals. The search is generally more likely to work, but may not work as well in some cases. Maybe even two options per project, one to the category and the other to a search.

To fix it yourself, as a once off, it should be simple enough to substitute the template, then edit the Wikisource item to link to the category instead of the search. · · · Peter (Southwood) ^(talk): 18:24, 18 June 2018 (UTC)

On Wikisource, the category doesn't even show up in the first page of search results, which instead show pages from books which mention Mesoamerica (often only in passing). Looking at the long term, the option to default to search, but allow a category=yes parameter would be very useful. At the moment Commons does go straight to category, so it seems a bit arbitrary. Simon Burchell (talk) 09:19, 19 June 2018 (UTC)

Birds Portal

@Evad37 and Certes:

Hi Transhumanist: I've been watching with interest as the Birds Portal undergoes its metamorphosis. You "portal folks" are doing a nice job! One question though; why have you cut the lead article (from "Bird") down from the full four paragraphs to two? I see that your automatic template allows for all four paragraphs to be shown... MeegsC (talk) 09:20, 21 June 2018 (UTC)

@MeegsC: It was formatting bias on my part. I've now expanded it to 4 paragraphs, and have replaced the selected picture section with a picture slideshow. The initial slide selection includes all the bird-related featured pictures, but this can be expanded as desired.    — The Transhumanist   10:22, 21 June 2018 (UTC)

Looks great! Thanks. MeegsC (talk) 13:07, 21 June 2018 (UTC)

One comment — if I press the advance button (the right arrow) for the slideshow, there's a massive amount of "flickering" between pictures. The section below the slideshow appears briefly and this is replaced by the picture, over and over and over. Is there any way to keep that from happening? Have a dedicated "box size" or something? MeegsC (talk) 21:04, 21 June 2018 (UTC)

I don't know. I've copied this thread to here. Maybe someone on the team can figure it out.    — The Transhumanist   23:49, 21 June 2018 (UTC)

Making the box size static is as simple as wrapping the {{random slideshow}} template in <div style="height:XXXpx">...</div> tags, where XXX is the size in px. I'm not sure how to prevent the flickering, but setting a static box size is probably not a great idea. The images pulled by the random slideshow aren't all the same size. Unless you set the static size to that of the largest picture, you could end up with truncated images, and even with that you'd have too much whitespace in the box for smaller images. Allowing the box to dynamically resize presents the best results once the page is fully loaded. Now if we could perhaps solve the loading issue with the gallery before the slideshow is ready, the flickering and unstable load behavior would go away. — AfroThundr ^{(u · t · c)} 00:20, 22 June 2018 (UTC)

The flickering has been reported as a bug in phab:T196723; there's not much we can do about it on-wiki. - Evad37 [talk] 02:59, 22 June 2018 (UTC)

Discussions about other technical issues

Issue #009 of newsletter turns off TOC

Somehow the latest issue of the newsletter is turning off the TOC on whatever page it is posted on.    — The Transhumanist   11:34, 16 June 2018 (UTC)

It transcludes {{Box-header}}, which contains the __NOTOC__ magic word. Certes (talk) 11:57, 16 June 2018 (UTC)

@The Transhumanist: Use the parameter SPAN=yes to force the title to be a span (not a heading) and also use the parameter TOC=no to stop it forcing no toc. Wpgbrown ^{talk | contribs} 12:02, 16 June 2018 (UTC)

Fixed the TOC problem: it now uses the same box-header as was used in the previous newsletter. Thanks for the tips. I didn't know those.    — The Transhumanist   12:15, 16 June 2018 (UTC)

Added SPAN=yes. Works great. Problems solved. Will use TOC=no next time. Thank you.    — The Transhumanist   12:29, 16 June 2018 (UTC)

The Box-header for the newsletter is now by default set to use span and to not use the toc. Wpgbrown ^{talk | contribs} 12:37, 16 June 2018 (UTC)

Wpgbrown, now I don't have to remember to set it manually. Thank you.    — The Transhumanist   21:33, 16 June 2018 (UTC)

Guys, do we really need another subpage for the box-header in the newsletter archive? I'm sure the irony hasn't been lost here... — AfroThundr ^{(u · t · c)} 12:40, 18 June 2018 (UTC)

Question about Template:Random portal component

@Evad37 and Certes: So {{Random portal component}}, which depends on Module:Random portal component, is currently setup to pull the /box-header subpage for the header and {{box-footer}} for the footer on portal pages. Although the documentation states that it also uses the /box-footer subpage, I haven't found any evidence it actually does this, so the docs may be outdated. My question is, how difficult would it be to add a parameter to the module to pass a template name in place of the subpage? As an example: the 'Did You Know?' section of Portal:Amphibians, until I made the subpage a redirect to {{Box-header/13}}, pulled a portal-specific box header that no longer matched with the rest of the page. If the above parameter was added, something like {{Random portal component|headertemplate=Box-Header/13|...}} would make that section match with the rest of the portal, and obsolete another subpage. Would one of you template wizards be interested in adding this capability? — AfroThundr ^{(u · t · c)} 07:33, 17 June 2018 (UTC)

@AfroThundr3007730:  Done - Evad37 [talk] 06:51, 18 June 2018 (UTC)

@Evad37: Thanks for that. I've made the necessary update to the portal now. @The Transhumanist: there are currently a hair over a thousand portals using {{Random portal component}}. How would we go about triaging these for ones that already use a {{box-header}} variant so we can update the random component box header to match? — AfroThundr ^{(u · t · c)} 12:16, 18 June 2018 (UTC)

I was thinking of foregoing that step by waiting until after we replaced the {{Random portal component}} (RPC) instances with section conversions. For example, replacing RPC selected picture sections with standard /box-header sections using {{Random slideshow}}. Then, the /box-headers could be replaced at our leisure, one color at a time; converting all the portals that used the same color, via AWB, to a {{Box-header}} subpage equivalent. The key task is to get rid of (that is, replace) those RPCs...

Converting RPCs can be done 2 ways: 1) simply replace them with new sections built from scratch, or 2) replace them with new sections populated with the data from the subpages that the RPCs called. The latter would take a script to do, and is overkill for extracting article names from the subpages with just excerpts, but may be worthwhile for harvesting pictures with juicy picture descriptions which we could use as captions. Which brings us back to option 1 for excerpts. At this time, it is not scalable. A thousand is too many to do by hand, and so we should wait until we have an automated solution, probably something similar to JL-Bot that would (instead of inserting bullet lists) insert lists of page names into template calls (with each entry preceded by a pipe instead of a bullet).

I agree with Evad's previous assessment that automating the collection of quality pictures is not feasible. There are some that are quality rated (featured pictures) and sorted by subject, but those will only cover the corresponding titled portals. For the rest, it looks like we'll have to rely on human editors to gather the pics. Keep on the lookout for curated collections of pictures.    — The Transhumanist   13:38, 18 June 2018 (UTC)

@AfroThundr3007730: Removing all the box-footer subpages caused a problem with {{Random portal component}}, and so its module had to be updated to use {{Box-footer}} directly. See this edit. That's why the documentation is out of date. :)    — The Transhumanist   13:38, 18 June 2018 (UTC)

How would you get a list of all orphan subpages in portal space?

If that is not feasible, a list of all orphan pages in portal space would suffice.

I look forward to your reply.    — The Transhumanist   12:45, 17 June 2018 (UTC)

An offline method: we could get a list of all pages in portal space from a recent db dump. Then with some python magic, pull all top-level pages into one list, and all the subpages into another list (simple operation, since one has a / in the page title and the other doesn't). Then you'd compare each of the 140k entries in the subpage list to see if it has a prefix match against an entry in the top-level list. If it does, drop it, if it doesn't, add it to an orphan list. If I had some time, I could throw that together later. Or maybe there is a fancy wiki tool available to do this, and the python method is unnecessary. On-wiki, I'm not sure how to do that; maybe with WP:PetScan or something similar? I imagine any of those tools would choke on a 150k entry page query. — AfroThundr ^{(u · t · c)} 12:27, 18 June 2018 (UTC)

Here is a current list of orphan portal pages. They all happen to be subpages. There may be others which are effectively orphaned because they are part of a small group of pages which link only to each other. Note that some pages which happen to have no incoming links today may still be useful. For example, Portal:Foo/Subpage123 may be unlinked but Portal:Foo may transclude Portal:Foo/SubpageN, where N is a random number which happens not to equal 123 today. Certes (talk) 13:01, 18 June 2018 (UTC)

That's neat. SQL would've been my first choice, but I didn't know you could run those against the wiki. Another tool for my toolbox. — AfroThundr ^{(u · t · c)} 14:43, 18 June 2018 (UTC)

Those pages may be orphans, but at least some of them are transcluded into somewhere in the associated portal. · · · Peter (Southwood) ^(talk): 18:43, 18 June 2018 (UTC)

Good point. 21 of 137 pages were transcluded. I've now excluded them from the list. Certes (talk) 21:37, 18 June 2018 (UTC)

Transclude Category excerpt

Is there any way to make a template that can perform a function analogous to {{Transclude list item excerpt}} and {{Transclude linked excerpt}}, but selecting an article randomly from within a category? That way a category such as Category:FA-Class_MCB_articles could be cycled through. T.Shafee(Evo&Evo)^talk 08:54, 28 June 2018 (UTC)

Yes and no. Following discussions at WP:VPT, we believe that there is no way for a template or module to access the current members of a category (rather than just displaying them on the reader's screen). However, User:JL-Bot/Project content can create a list of FA-class articles in Wikiproject MCB, which is suitable for use by {{Transclude list item excerpt}}. The bot tends to run once per weekend. Certes (talk) 10:08, 28 June 2018 (UTC)

Ah, champion, thank you! T.Shafee(Evo&Evo)^talk 11:08, 28 June 2018 (UTC)

Random quotation

{{Random quotation}} does not work correctly. It randomises both quotation and author, so gets them mixed up, and uses double chevron style quote marks expressly deprecated by MoS. I could not work out how to fix it yet. It also applies a style that should be optional not default. I don't know if this is a thing we should try to fix or just create a better alternative. It is getting a bit late here, so do not intend to do anything more about it tonight. · · · Peter (Southwood) ^(talk): 19:20, 30 June 2018 (UTC)

@Pbsouthwood: Fixed the random number problem, using |same=yes to force the random number to be the same. Wpgbrown ^{talk | contribs} 21:29, 30 June 2018 (UTC)