Jump to content

Wikipedia talk:WikiProject Portals/Design/Archive 3

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4Archive 5

Discussions about possible cool new features


Excerpt slideshows

Maybe we should try to do away with the purge links altogether. Slideshow galleries allow content to be changed just by clicking on arrows, and it is possible to get it to work with prose too:

Selected animal

When WP:TemplateStyles get enabled, we should be able to hide the blank filler images entirely, as well as the middle button that toggles the standard gallery view. - Evad37 [talk] 13:59, 12 June 2018 (UTC)

Cool results. A worthy objective. Though, that's some heavy-duty code...
{{Box-header|title=Selected animal|EDIT=yes|noedit=yes}}
{{Random_slideshow
| File:Blank.png | <div style{{=}}text-align:left;>{{#invoke:String|replace|{{Transclude lead excerpt|Cat}}|%c|<br>||false}}</div>
| File:Blank.png | <div style{{=}}text-align:left;>{{#invoke:String|replace|{{Transclude lead excerpt|Dog|files=1}}|%c|<br>||false}}</div>
| File:Blank.png | <div style{{=}}text-align:left;>{{#invoke:String|replace|{{Transclude lead excerpt|Mouse}}|%c|<br>||false}}</div>
| File:Blank.png | <div style{{=}}text-align:left;>{{#invoke:String|replace|{{Transclude lead excerpt|Horse}}|%c|<br>||false}}</div>
}}
{{Box-footer}}
@Evad37 and Certes: To simplify this for editors, and AWBers' sanity, can this be turned into a template, that accepts the same parameters as the {{Transclude random excerpt}} template?    — The Transhumanist   05:37, 16 June 2018 (UTC)
Sure, but I think we should wait until we actually have TemplateStyles – otherwise you can end up at File:Blank.png unexpectedly, or end up with a huge amount of text in narrow columns if the "toggle thumbnails" button in the middle is clicked - Evad37 [talk] 05:49, 16 June 2018 (UTC)
@The Transhumanist: I've started {{Transclude excerpts as random slideshow}}, see testcases - Evad37 [talk] 07:19, 16 June 2018 (UTC)
Like much. I was thinking of asking whether this could be done, but it looks like you have preempted me. I will use this when it is ready. Awaiting with antici..........pation! Kudos. · · · Peter (Southwood) (talk): 11:15, 16 June 2018 (UTC)

@Certes, The Transhumanist, and Pbsouthwood:: {{Transclude excerpts as random slideshow}} is now ready to be used - Evad37 [talk] 04:10, 20 July 2018 (UTC)

Cheers. See my response two subsections below.    — The Transhumanist   05:36, 20 July 2018 (UTC)

The excerpt slideshow above has stopped working

@Evad37 and Certes: It doesn't work anymore. Oddly, though, it still works when in the page preview.    — The Transhumanist   22:37, 4 July 2018 (UTC)

Still works for me. Is it still not working for you @The Transhumanist? - Evad37 [talk] 17:08, 9 July 2018 (UTC)
Doesn't work. I'll track it down. It's probably a script or gadget conflict.    — The Transhumanist   23:49, 9 July 2018 (UTC)

Transclude excerpts as random slideshow

Evad, this template is brilliant!

Here is a test using the same article titles as above.

Selected animals

Very nice. Much easier to work with.

By the way, what does this display in mobile devices?

Good job, keep up the great work. Now I'm off, to test it in a portal...    — The Transhumanist   05:36, 20 July 2018 (UTC)

On mobile devices, only one excerpt is shown. You can test this on desktop by making your browser window very narrow and going to the mobile website, i.e. https://en.m.wikipedia.org - Evad37 [talk] 06:11, 20 July 2018 (UTC)
Nice.    — The Transhumanist   06:31, 20 July 2018 (UTC)
@Evad37: I tested it in Portal:Reptiles here, and it only displays about half of the portal.    — The Transhumanist   06:31, 20 July 2018 (UTC)
Probably too many articles being passed through. There is a technical limit to the number of "expensive functions" in Lua modules that can be used on a page. - Evad37 [talk] 07:12, 20 July 2018 (UTC)
@The Transhumanist:  Fixed. The template now limits the number of excerpts shown to 50. If there are more than 50 pages, then a random subset of 50 will be chosen (and the subset will change with each page purge). - Evad37 [talk] 05:26, 21 July 2018 (UTC)
@Evad37: Excellent. One error message said something about exceeding a limit of 500 expensive calls. I like the randomization upon purging. Nice touch.    — The Transhumanist   05:57, 21 July 2018 (UTC)
@Evad37 and Certes: It is working on my laptop. Kudos. I checked the mobile version, just in case, and it is displaying the excerpts in tiny columns: https://en.m.wikipedia.org/wiki/Portal:Reptiles    — The Transhumanist   07:37, 21 July 2018 (UTC)
@The Transhumanist: You have to make your browser window very narrow like it would be on a mobile device (less than 720 pixels). - Evad37 [talk] 08:55, 21 July 2018 (UTC)
@Evad37: What I meant was, that there are 4 timy columns showing 4 excerpts, followed by 4 more excerpts in tiny columns, followed by the rest of them, all in 4 tiny columns. Above, you mentioned that it should only being showing a single excerpt in mobile view. Displaying all of them, the section is super long. Just a heads up. I'll report more glitches as I come across them. Thank you for all these wonderful templates you are developing. We would be nowhere without you. Sincerely,    — The Transhumanist   19:38, 21 July 2018 (UTC)
@Evad37: In Portal:Lithuania it caused the pictures in the picture slideshow to disappear.    — The Transhumanist   07:02, 20 July 2018 (UTC)
 Fixed - Evad37 [talk] 07:12, 20 July 2018 (UTC)
Turning {{Transclude list item excerpt}} into a slideshow analogous to {{Transclude files as random slideshow}}, would be awesome.
Perhaps call it {{Transclude list item excerpts as slideshow}}.    — The Transhumanist   07:11, 20 July 2018 (UTC)
That's on the to-do list, along with a slideshow equivalent for {{Transclude linked excerpt}} - Evad37 [talk] 07:13, 20 July 2018 (UTC)

Linked/list item excerpts

Now available as slideshows! See {{Transclude linked excerpts as random slideshow}} and {{Transclude list item excerpts as random slideshow}}. Pinging @The Transhumanist and Pbsouthwood. - Evad37 [talk] 03:22, 24 July 2018 (UTC)

Ooh. One moment, while I recover from hyperventilating....
There. I'm going to search/replace "Transclude list item excerpt" to "Transclude list item excerpts as random slideshow" right now in Portal:Lithuania.  Done    — The Transhumanist   04:51, 24 July 2018 (UTC)
@Evad37: I reverted it. See https://en.wikipedia.org/w/index.php?title=Portal:Lithuania&oldid=851719990. It seems to truncate the page, right after Municipalities of Lithuania. No error messages were showing up either.    — The Transhumanist   05:14, 24 July 2018 (UTC)
@The Transhumanist: Several of the municipalities are stubs without any section headings. This means the lead-section transclusion includes navboxes and other end-of-page content, which seems to mess up the gallery syntax. So all the articles will need to have at least one section heading, unless we find a way to fix it in Module:Excerpt. - Evad37 [talk] 06:05, 24 July 2018 (UTC)
@Evad37: Can you screen for that? Like if they have stub tags/cats?    — The Transhumanist   06:11, 24 July 2018 (UTC)
@The Transhumanist: Stub templates are named fairly consistently, so it should be fairly easy to identify stubs. Identifying what part of a stub is actually end-of-page stuff is much more tricky. - Evad37 [talk] 06:19, 24 July 2018 (UTC)
@Evad37: What about skipping the stubs, and making the list of pages for the slideshow without them?    — The Transhumanist   06:51, 24 July 2018 (UTC)
@The Transhumanist:  Fixed, more or less. See Template:Transclude list item excerpts as random slideshow/testcases/Portal:Lithuania. Fixing the Municipalities revealed that having all the excerpts in all the slideshows was taking up too much time in Lua, and giving "The time allocated for running scripts has expired" errors, so I introduced a |limit= parameter and set it to 15 on all the slideshows. There was also a weird problem with the gallery for the politics section being broken, but preventing non-mainspace pages from appearing and setting |paragraphs= to 1 instead of 1-2 fixed that. - Evad37 [talk] 05:49, 25 July 2018 (UTC)
@Evad37: The limit parameter is excellent. On your Portal:Lithuania test case, I like how the 15 are randomized each time the page is purged.    — The Transhumanist   08:17, 25 July 2018 (UTC)

Transclude section leads

 Done
 – This feature has been implemented. — AfroThundr (u · t · c) 04:26, 3 August 2018 (UTC)

@Evad37 and Certes: The templates so far transclude excerpts from article leads.

Could we have one that transcludes excerpts from a specified section of one or more articles, by section title? (Section number would be fine for a single page, but probably wouldn't work right if multiple pages were included).

For example, the Portal:Prehistory of Oceania doesn't have a corresponding article from which to pull a lead excerpt. The material about it is in the Prehistory section of History of Oceania.

Thoughts?    — The Transhumanist   10:10, 9 July 2018 (UTC)

Identifying sections by section title is possible, but what happens if a section gets renamed? - Evad37 [talk] 15:39, 11 July 2018 (UTC)
Same thing as with {{Transclude list item excerpt}}: error message.
A comment after the section title may help to prevent it from being changed.    — The Transhumanist   09:19, 15 July 2018 (UTC)
Enhancement: you can now specify History of Oceania#Prehistory as the source. The template will transclude the section's "lead", i.e. everything before its first subsection heading. However, in this case, the excerpt will be blank, as the section has no significant text before its first subsection on Polynesia theories. The enhancement also covers links in lists. For example, if Foo links to Bar#Baz, then {{Transclude linked excerpt|Foo}} displays not the lead of Bar but the start of its section called Baz. Certes (talk) 00:12, 17 July 2018 (UTC)

A link that leads to a random portal would be nice.

It could be placed at the end of the Template:Portals browsebar that is displayed at the top of most portals.

What would it take to create such a link?    — The Transhumanist   11:25, 25 July 2018 (UTC)

Just need a Category:All portals category (which could be added by {{Portal maintenance status}}), and then Special:RandomInCategory/All portals would link to a random portal. - Evad37 [talk] 11:41, 25 July 2018 (UTC)
 Done, except for editing {{Portals browsebar}}. It may take some time to fully populate the category, as of now there's only a few portals there - Evad37 [talk] 11:50, 25 July 2018 (UTC)
That template is template-protected, so I made a proposal at Template talk:Portals browsebar#Proposed new random portal link. If no one objects I'll make the edit in a couple of days time. - Evad37 [talk] 14:09, 25 July 2018 (UTC)
 Done - Evad37 [talk] 03:28, 29 July 2018 (UTC)
I like it! It adds a new dimension to portal navigation. It shows up at the same location on the page in most portals, so you can just keep clicking it until a topic catches your interest.    — The Transhumanist   08:16, 1 August 2018 (UTC)

Most portals aren't showing up

@Evad37 and Certes:

Random portal

The only country portal that shows up, for example, is Portal:Canada. It looks like a rather small subset of the whole collection.    — The Transhumanist   01:13, 2 August 2018 (UTC)

That link randomly selects a page from Category:All portals, which has 545 pages. So not that small, plus it includes other country portals like Portal:Australia, Portal:New Zealand, and Portal:United States. The only portals the link won't go to are those that are missing {{Portal maintenance status}}. - Evad37 [talk] 03:42, 2 August 2018 (UTC)
Once (a first pass at) the assessment process is complete, would it be better to show a random good portal, rather than any random portal? Country portals tend to be good. There are some vastly improved pages out there, and some that were already wonderful before we started, but there are still a few that aren't showpieces. Certes (talk) 12:07, 2 August 2018 (UTC)

Refdesk section

 Done
 – This feature has been implemented. — AfroThundr (u · t · c) 04:26, 3 August 2018 (UTC)

A portal section that displays a link to the WP:REFDESK that is relevant to that portal.

There are 8 reference desks. How could this be made to automatically display the appropriate link out of those 8?

Thoughts?    — The Transhumanist   11:44, 25 July 2018 (UTC)

A simple section with a reference to the main RefDesk page is sufficient.  Done
For an example, see Portal:Lithuania#Need help? and Portal:Monaco#Need help?.    — The Transhumanist   05:33, 30 July 2018 (UTC)

Self-adjusting "Get involved" section

 Done
 – This feature has been implemented. — AfroThundr (u · t · c) 04:26, 3 August 2018 (UTC)

Portal that adjusts layout depending upon what content is available.

For example, displays a news section only if there are news items to be displayed.

Another example, displays a "Did you know" section, only if there are DYK entries to be displayed.

Thoughts?    — The Transhumanist   11:49, 25 July 2018 (UTC)

That would make automated construction easier. · · · Peter (Southwood) (talk): 17:00, 25 July 2018 (UTC)

@Pbsouthwood, AfroThundr3007730, Evad37, Certes, Dreamy Jazz, and Waggers: Okay, found it. One way to do this is covered at mw:ifexist.

For example, to make a "Get involved" section only appear if the corresponding WikiProject exists, you could use code similar to this:

{{#ifexist: Wikipedia:WikiProject {{PAGENAME}}
 | {{Box-header colour | Get involved}}
For editor resources and to collaborate with other editors on improving Wikipedia's Lithuania-related articles, see [[Wikipedia:WikiProject {{PAGENAME}}|WikiProject {{PAGENAME}}]].
{{Box-footer}}
 |
}}

It has been placed in Portal:Lithuania, where it works.

I'm not sure what other features could be handled with this, or if there are better or similar methods.

Thoughts?    — The Transhumanist   07:13, 27 July 2018 (UTC)

Lining up box section bottoms

 Done
 – This feature has been implemented. — AfroThundr (u · t · c) 04:26, 3 August 2018 (UTC)

The tops of boxes at the top of the 2 columns line up. The bottoms don't, which leaves awkward white space between boxes. The box bottoms should line up too.

Then, white space would appear inside a box rather than outside it. This is more aesthetically pleasing, and is how the Main page is designed.

Portals with side-by-side box arrangement, like Portal:Lithuania, would look a lot better.

What is the best way to accomplish this?    — The Transhumanist   12:00, 25 July 2018 (UTC)

Making parallel boxes the same height (in pairs) might be a way, but has disadvantages. It could be done as a table or column of tables, which will maximise whitespace. Otherwise it becomes rather complicated, as both columns must be rendered to estimate total height as the maximum of both columns, then the shorter column must have the right number of blank lines added to all the boxes until it is the same length as the other. The height of a box will also be affected by screen size if there are images. Each time a slideshow is operated, tho whole rendition must be repeated. I think it will be slow, expensive in resources and jumpy. Or am I missing something? I gave up on the concept and changed to a single-column layout which avoids the problem altogether · · · Peter (Southwood) (talk): 17:17, 25 July 2018 (UTC)
This should actually be possible with CSS flexbox. It would work better with the current standard layout of a few sections on the left followed by a few sections on the right, with the CSS then ensuring that any extra space in either column is distributed evenly between the contents of the shorter column. - Evad37 [talk] 02:08, 26 July 2018 (UTC)
@The Transhumanist and Pbsouthwood:  Done by making {{Flex columns}}. See Template:Flex_columns/testcases for an example. It currently requires the portal components to be made with either {{box-header colour}} or {{box-header/lua}}. - Evad37 [talk] 03:47, 26 July 2018 (UTC)
Brilliant. I've applied it on Portal:Lithuania. Works great.    — The Transhumanist   07:46, 26 July 2018 (UTC)
Amazing. · · · Peter (Southwood) (talk): 15:53, 26 July 2018 (UTC)

Fitting panoramas to the width of the frame

 Done
 – This feature has been implemented. — AfroThundr (u · t · c) 04:26, 3 August 2018 (UTC)

We've started putting panoramas at the top of intro sections. For example, see the panorama at the top of Portal:Lithuania.

The problem is, they shrink when you zoom out.

Could they be fit to the width of the frame, and stay that way, even after each zoom change?    — The Transhumanist   07:53, 26 July 2018 (UTC)

@The Transhumanist: {{Portal image banner}} to the rescue! (thanks to FR30799386). But it should probably provide a link by default, and only omit or change the link if parameter specified to do so. - Evad37 [talk] 10:06, 26 July 2018 (UTC)
Maybe it needs to be a bit more complicated to do it properly; there should probably be a minimum height with the overflow available through scrolling. - Evad37 [talk] 10:11, 26 July 2018 (UTC)
Would that be a user defined minimum height? Would it handle mobile gracefully? · · · Peter (Southwood) (talk): 10:37, 26 July 2018 (UTC)
Evad37 - Would it be okay if the overflow where to be hidden from view ? Scrolling through a narrow section in my opinion is never really graceful. — FR+ 10:58, 26 July 2018 (UTC)
I have made the template scale the image to fit each and every size of screen. However the size at which the image overflows must be set by manually. — FR+ 13:45, 26 July 2018 (UTC)

This looks good! It has been put to use at the following portals.

Our WikiGnomes are going to have fun with this!    — The Transhumanist   23:10, 29 July 2018 (UTC)

Discussions about overall portal design


New portals construction time

I've been experimenting with the creation of new portals, to see how much editor effort is taken up by the new automated and semi-automated components.

The following portals took me about an hour to create each, though I had to return to fiddle with the Did you know section of Portal:Reference works for another half-hour or more, as the search terms I initially chose were matching off-topic topics. The template, {{Transclude selected recent additions}}, is quite powerful, and even has a do-no-match feature to help target searches more precisely. Here are the new portals I mentioned:

The previous typical creation time on portals like this used to be 6 to 10 hours, and so the tools are a great improvement, reducing creation time about an order of a magnitude. We should keep on with development of tools and components, and perhaps we can reduce creation time down to single digit minutes.    — The Transhumanist   21:54, 11 June 2018 (UTC)

What a great improvement! Great job everyone. Wpgbrown talk | contribs 21:56, 11 June 2018 (UTC)
I predict a target of a few minutes eventually, based on a good outline article with a good gallery section. At the moment that takes a lot of work, so not yet a huge gain yet. However a good outline article ias also a useful thing for other reasons, and more automation may be possible there too. The toolbox is growing. · · · Peter (Southwood) (talk): 07:56, 25 June 2018 (UTC)
@Pbsouthwood: The following portals draw most of their data from outlines, using the {{Transclude list item excerpt}} template. They are listed along with approximate creation (or conversion) times:
Portal:Munich – 22 minutes
Portal:Dresden – 19 minutes
Portal:Athens – 17 minutes
Did Portal:Florence – 13 minutes
Portal:Stockholm – 13
Portal:Palermo – 12 minutes
Most of the time was spent gathering and adding pictures. If we automate that, say, with another template that pulls all the pictures off a specific page (or page section), the creation time for this type of portal would drop to 3 minutes or less.
Therefore, I now firmly believe we can get portal creation times in general down to seconds, rather than minutes.    — The Transhumanist   04:49, 18 July 2018 (UTC)
@The Transhumanist: A template that pulls all the pictures off a specific page (or page section) already exists: {{Transclude files as random slideshow}} - Evad37 [talk] 05:03, 18 July 2018 (UTC)
@Evad37 and Certes: I was thinking of a template to power a "Selected article" section, that shows a single random picture upon each page purge, rather than a slideshow. Like {{Transclude list item excerpt}}, but for images instead of list items. I'll experiment with {{Transclude files as random slideshow}}, and will get back to you.    — The Transhumanist   05:46, 18 July 2018 (UTC)
@Evad37: Hi! I'm trying {{Transclude files as random slideshow}} on Portal:X-ray astronomy. The slideshow is great but its only showing five images randomly instead of all of them. What am I doing wrong? --Marshallsumter (talk) 03:41, 19 July 2018 (UTC)
It seems seems to be finding images using the [[File:...]], and not those using the older [[Image:...]] syntax. That's likely a bug in Module:Excerpt that needs fixing. - Evad37 [talk] 04:35, 19 July 2018 (UTC)

I thought that the picture slide show would be the biggest time consumer in portal construction. But, I discovered in building city portals that sourcepages for pics are easy to specify in a generation template.    — The Transhumanist   09:32, 2 August 2018 (UTC)

@Evad37: I was trying to convert this portal to {{Box-header colour}}, but, when I added the color from the {{/box-header}} subpage, it didn't match.

The page uses the colors of their flag, like this:

Alabama portal
Flag of Alabama
Flag of Alabama

The X in the flag is color code #BF0A30.

But, when you indicate the exact same color code in {{Box-header colour}}, it turns out like this:

The Alabama Portal
Flag of Alabama
Flag of Alabama

Whoever designed the portal, wanted to match the colors of the state flag.

Can we do that with {{Box-header colour}}?    — The Transhumanist   07:46, 29 July 2018 (UTC)

@The Transhumanist: Having an exactly-specified colour kind of defeats the purpose of having Box-header colour, which is designed to choose a similar colour to the input, but adjust it to be accessible if needed. If you want a darker red similar to the flag (but not exactly the same), you can set |mode=dark:
The Alabama Portal
Flag of Alabama
Flag of Alabama
If you really want to specify an exact colour, then you need to use {{Box-header}} or {{Box-header/lua}} - Evad37 [talk] 14:37, 29 July 2018 (UTC)
I didn't know about that second one. Thanks!    — The Transhumanist   21:52, 29 July 2018 (UTC)

Template:Portal tag to be placed on all article talk pages

IMO, the benefits of such a tag would be immense. For example, we could use it to automatically generate categories of articles related to each portal. This is especially beneficial to portals which do not have a corresponding WikiProject, extricating ourselves from a reliance on said projects. For example, the Portal:1980s has no corresponding WP:WikiProject 1980s.

The tag template would say something like,

This article is related to the following Portals:
Biography, 1980s, United States, United States Army, War

To call this new template for say Fred K. Mahaffey we add {{Portal tag|Biography|1980s|United States|United States Army|War}} just below the other WikiProject templates already on its talk page. Each parameter in this new template would automatically include the article in a category like Category:FA-Class articles related to 1980s Portal. The rest I believe easy to imagine.

I can imagine dozens of automated features for which specific portal-related categories would be a great boon.--- Coffeeandcrumbs 09:06, 13 July 2018 (UTC)

One example of a use is an adapted form of User:JL-Bot/Project content that generates lists of Quality content on the portals talk page. This list can then be used in our random selected article/biography/picture templates to maintain the portal.--- Coffeeandcrumbs 09:12, 13 July 2018 (UTC)

I support this idea in principle, however, it may be easy for editors (by accident or deliberately) to link non-relevant / not appropriate articles to a portal. Also, new articles on a topic may not have this proposed tag placed on their talk pages, due to editors not knowing about this tag. I, however, see that this tag would be useful in making portals fully automatic. Dreamy Jazz talk | contribs 09:23, 13 July 2018 (UTC)

Pinging @Evad37, AfroThundr3007730, The Transhumanist, Certes, and Lee Vilenski:

Something that automatically detects the portals linked to from the page would be better than having to input them manually. Maybe even as part of {{talk header}} so that it can be deployed to a huge number of talk pages at once. - Evad37 [talk] 10:29, 13 July 2018 (UTC)
Many editors including myself do not like portal links on articles. With your idea, we are still going to have to add portal links to the vast majority of articles lacking portal links. I think you underestimate the resistance we will face if we attempt that. But tagging the talk pages will generate little resistance and can be easily done using User:Evad37/rater.--- Coffeeandcrumbs 12:44, 13 July 2018 (UTC)
Funny, I only just realized you are the creator of the user script. I love that script!--- Coffeeandcrumbs 12:48, 13 July 2018 (UTC)
I'm not sure why so many would be opposed to linking to portals from a related article. If the portal link is at the bottom of the article, what harm is there in including it? The primary purpose of portals is to serve as a gateway to articles and other content related to a particular topic, and portals can often provide better topic area navigational facilities than just a few "see also" links or a category would. Anyone objecting to the presence of a portal link, despite the clear benefit they provide to readers, would be missing the point of the portal namespace entirely.
The alternative proposal of manual talk page tagging is infeasible, if the wider community doesn't adopt it the same way we currently do with WikiProject Banners. There are far too many articles being created for this project's members to chase after them to add a portal tag to each talk page. It would be a nightmare to even handle the existing articles ourselves. I think if we want this functionality, we're going to have to leverage the existing {{portal}} that most editors are at least vaguely aware of (and might be convinced to help us with), and build the needed functionality around that - either through the template directly, or detecting it from the talk page.
The problem with talk page detection is leveraging an existing template that is already ubiquitous on talk pages. This could include lobbying the relevant WikiProjects to ensure that their project banners all have the portal detection code embedded, or perhaps we could propose additional logic to {{WPBannerMeta}} (or a submodule) that would do the detection and categorization for us. The {{talk header}} modification is an interesting idea, though I'm not sure how well that would go over with the community, since portal detection is an unrelated function that we'd be trying to piggyback into a high use template.
The better method might be to modify {{portal}} directly to tag the article with the necessary (hidden) categories. The benefits of this method include:
  • Not needing to run extra Lua on every article talk page to detect the portal template
  • Not depending on the presence of the relevant talk page templates (even though they should be there)
  • Not needing to get mired in protracted discussions with the other projects/wider community regarding our ever-expanding scope
  • The modifications we make would be mostly contained to one template (and a boatload of categories)
In addition to the above, we could further limit the scope of the tagging feature during the pilot phase (for example, the top-level portals only) as we refine the process. The impact to articlespace would be minimal in this scenario, and leave little room for complaint (provided we can get the template modifications pushed without major issue).
Just my thoughts on the matter. — AfroThundr (u · t · c) 20:48, 14 July 2018 (UTC)
@AfroThundr3007730 and Evad37: I am not going to argue against the grain and hold us up. Let's go with modifying {{portal}} to add hidden categories and see if we can achieve wide acceptance. We can always move the code to a talk page template if that fails. I am not a good template coder. Can someone else take the charge or point me to a template to emulate for the addition of hidden categories.--- Coffeeandcrumbs 22:32, 15 July 2018 (UTC)
P.S. {{Portal}} uses {{Module:Portal}}. So we need a Lua coder. Not me.--- Coffeeandcrumbs 22:42, 15 July 2018 (UTC)

Short descriptions

Resolved
 – Template:Portal description has been upgraded.

Where are these coming from? I see an inadequate one at Portal:English (needs to say "the English language", for clarity), but there is no {{Short description}} at that page, so it's being injected from some other transclusion or something. While I can go dig it out, I want to ask whether this standardized, or being standardized, or just being done randomly on a per-portal basis?

PS: If you don't know what I"m talking about, see WP:Short description, especially Template:Short_description#Testing for the CSS to make all the short descriptions visible to you (I recommend this – many of them need work, in the mainspace, too).
 — SMcCandlish ¢ 😼  03:58, 1 July 2018 (UTC)

I tracked it down to {{Portal description}}, and upgraded it with a |topic= parameter to resolve this issue. Also fixed the documentation to stop mis-recommending that people add a separate {{Short description}} to override {{Portal description}}'s default behavior; it won't work and will instead create two conflicting short descriptions.  — SMcCandlish ¢ 😼  04:20, 1 July 2018 (UTC)
Good work.    — The Transhumanist   00:31, 14 July 2018 (UTC)
{{Short description}} should override any automatically generated short descrioptions in the article.· · · Peter (Southwood) (talk): 18:11, 23 July 2018 (UTC)

Portal:India

I have recently tried to tidy up Portal:India to a automated state. I have run into some questions.

  • Is it allowed to use TemplateStyles directly on the portal main page ? (Especially to improve placement and of the images at the top and to modify the box-header template)
  • Is it okay to scrap the dead Portal:India/Selected articles and Portal:India/Selected pictures processes in favor of automated processes ?
  • Is there a way to completely automate the Selected Pictures selection process ?
  • Can we include a selected list in the portal main page ?

Finally, Could some one advice me on thing that can still be improved in the portal — FR+ 07:32, 23 July 2018 (UTC)

P.S.: What should be done with Portal:India/Quiz/Archive33 and such semi-talk pages ? — FR+ 10:50, 23 July 2018 (UTC)
  • It should be OK to scrap selected articles and selected subpages in a portal after replacing with autmated processes unless someone objects with a good reason not to do so. If there are no editors claiming to be maintainers of the potal, I would sugeed boldly doing the chnge, and if no-one objects within a reasonabe interval, say a week, then cleaning up the redundant subpages. If you feel less bold, suggest doing this change on the talk page. If there is no response within a week, assume that no-one cares, and do it.
  • It is not clear what you mean by completely automating the selection process for pictures. If you mean finding pictures from commons, not at this stage. If you have ideas for how it might be possible, let us know. It would be a very useful tool.
  • Adding a selected list should be possible, but I am not sure what you mean. Cheers, · · · Peter (Southwood) (talk): 18:25, 23 July 2018 (UTC)
Pbsouthwood - I have nominated the quiz pages for deletion. I have answered some of your questions below :
  • Yes, I meant finding images from commons. Will it be possible to get all the featured pictures related to India from Commons and then feed it to the random slideshow along with an excerpt from the relevant articles (in an automated way)?
  • I was asking whether including a selected lists would put the portal into Category:All non-standard portal pages
Also, can TemplateStyles be used directly on Portal:India? — FR+ 09:22, 24 July 2018 (UTC)
  • FR30799386. As far as I know it is not possible to get all the featured images in a Commons category automatically and feed them into a random slideshow yet. I think there is a technical problem, but hope it can be resolved as this would be useful. It should be possible to manually create a list, but it would not update automatically. It may also be possible to get a bot to update a list on a weekly or monthly basis, but I am not skilled with bots.
  • Combining a featured image with an excerpt from a relevant article may be more tricky. How would you know which article to use, and which excerpt?
  • I know nearly nothing about Template Styles, Maybe Evad37 could advise.
  • I don't know about selected lists and Category:All non-standard portal pages. I see no obvious reason why it should, as there will be several new templates used in the new standard portal structure, which has not yet been finalised, but I will try to find out. Why does it matter?
  • You might also want to sign up with the project at Wikipedia:WikiProject_Portals#Specific_portal_maintainers, and fill in a few parameters on the portal maintenance template on Portal:India. Cheers, · · · Peter (Southwood) (talk): 10:13, 24 July 2018 (UTC)
TemplateStyles are really meant for templates, as per the name. If you have them as part of a template, then any cool features you come up with can easily be applied to other pages, without unnecessary duplication. Plus the style pages themselves can only be created in the template namespace (by default anyway). See WP:TemplateStyles for further information and usage guidelines. - Evad37 [talk] 13:14, 24 July 2018 (UTC)

Evad37 - I created Template: Portal image banner as a rough implementation of my idea — FR+ 08:45, 25 July 2018 (UTC)

👍 Looks good - Evad37 [talk] 08:56, 25 July 2018 (UTC)
Also like. Has potential for some interesting applications. I have commented on the template talk page. Cheers, · · · Peter (Southwood) (talk): 18:02, 25 July 2018 (UTC)

Regarding template talk pages

@Evad37, Certes, and The Transhumanist: Much like all of the templates that depend on Module:Excerpt have had their talk pages redirected to Module talk:Excerpt, I think we should do that for all templates that depend on a module, to keep the discussion centralized. Or perhaps all of the "lower traffic" templates should have their talk pages redirect here? As for me, I watchlist all of them whenever I see a new one, but it might make any issues posted more visible if we consolidated most of them (excluding the excerpt ones probably). What do you guys think? — AfroThundr (u · t · c) 02:21, 26 July 2018 (UTC)

Good plan.    — The Transhumanist   07:05, 26 July 2018 (UTC)
Sure, go ahead with template→module talk redirects. I already did so for the excerpt slideshow templates as well. Not sure about redirecting other template talk pages here though, especially since some templates may or could have usage beyond portals (e.g. in Wikiprojects). Maybe they just need a message box saying that to attract editors attention, a note should be left here (with a link to the template talkpage discussion). - Evad37 [talk] 07:18, 26 July 2018 (UTC)

When the page Wiltshire is specified as a source for files, the slideshow gets clogged up with icon images from its Places of interest section.

It would be useful if we could specify sections that the template is to exclude from the slideshow.    — The Transhumanist   22:50, 29 July 2018 (UTC)

Discussions about selected image sections

Tip: "image" instead of "picture"

Tip: Many files aren't pictures, and so the title "Selected picure" is a slight misnomer when a non-picture is displayed. The word "image" is more general, and covers them all.    — The Transhumanist   23:55, 1 August 2018 (UTC)

Discussions about news sections

Automating news support

Dear JJMC89 and Portals Project techies,

There was a huge debate over possible deletion of the entire portal system, including the portal namespace itself. One of the main objections to portals raised during that debate was the prevalence of portals that were extremely out-of-date and unmaintained, a condition that was noticeable, in large part, from their out-of-date news entries.

One of the outcomes of the debate was a rebooted Portals WikiProject, with a new team of editors dedicated to revamping and automating the entire portal system.

Accordingly, the portal system is undergoing a complete overhaul.

Each portal section type is being redesigned for automation, one-by-one, including the news section.

The problems we've been having with news sections on portals include:

1) Unmaintained news sections with news items that are years out of date
2) Empty news sections
3) Reliance upon subpages (portal subpages are being phased out)
4) Manual set up of news support, and its unscalability (due to lack of available human labor)

I'm interested in a type of news section that automatically appears in portals only when there is news to be reported. That is, when there is news within the past 30-days (recent news), there's a news section on the portal reporting it. When there is no recent news, there is no news section. How can this be done?

We are converting portals to a one-page design, with zero sub-pages. Therefore, I'm looking for ways that news support can be controlled externally from outside portal pages, based entirely on portal titles. Automatically. How can this be done?

Thus, portals would be automatically matched with their corresponding news categories on Wikinews, with zero human intervention. How can this be done?

That is, we need the set up of news support, and ongoing updating of news, on every portal (except those that have dedicated maintainers), to be fully automated. How can this be done?

There are currently 1500 portals, with 8500 or more additional portals likely to be created over the next year or two. News support for existing and new portals should initiate automatically. How can this be done?

Are there any other free and open news sources besides Wikinews that can be supported on Wikipedia portals? If so, what are they?

I look forward to your replies.    — The Transhumanist   23:44, 1 August 2018 (UTC) P.S.: Please {{ping}} me in your reply. Thank you. -TT

@The Transhumanist: {{transclude selected current events}} is aware of when it doesn't find any matching items. It should be possible to modify the module, such that if news items are found, it displays whatever's in a |header= parameter (i.e. a box-header template) plus the news items plus whatever's in a |footer= parameter (or just {{box-footer}}); and when no news items are found, it leaves out the section entirely. - Evad37 [talk] 03:52, 2 August 2018 (UTC)
@Evad37: That sounds exactly like what we need! That way, we wouldn't have any empty or out-of-date news sections. As long as the days parameter isn't set too high. :)    — The Transhumanist   08:08, 2 August 2018 (UTC)
Example with items:
In the news
21 November 2024 –
The European Southern Observatory announces that its astronomers in Chile capture the first close-up image of a star outside the Milky Way. (The New York Times)
20 November 2024 – German economic crisis
American automaker Ford announces that it will cut 4,000 jobs in Europe, including 2,900 in Germany, citing economic instability and conflicts with environmental regulations. (Newsweek)
20 November 2024 – 2024 Baltic Sea submarine cable disruptions
The Russian government denies accusations made by European governments of their involvement in sabotaging two submarine telecommunications cables in the Baltic Sea as a means of hybrid warfare. (DW)
11 November 2024 – 2024 European floods
2024 Spanish floods
Example without items:
(no output) - Evad37 [talk] 10:15, 2 August 2018 (UTC)
For a minute there, I thought the output was "(no output)". :) Thank you! I'll start putting it to use.    — The Transhumanist   10:48, 2 August 2018 (UTC)

Discussions about did you know sections

Automating DYK support

@Evad37: Can you do the same for DYK as you did for news above? That is, make it display if it has output, and not display if it has no output?    — The Transhumanist   10:53, 2 August 2018 (UTC)

Related: § New template: Transclude DYK. Certes (talk) 12:25, 2 August 2018 (UTC)
There is also a surprisingly relevant ten-year-old page: WP:DYK for Portals. Certes (talk) 20:03, 2 August 2018 (UTC)
@The Transhumanist:  Done, |header= and |footer= will now also work for {{Transclude selected recent additions}} - Evad37 [talk] 02:58, 3 August 2018 (UTC)

I believe that I've now fixed all links to disambiguation pages on the source text at WP:Recent additions/2018/July etc., unless you request pages from before 2010. If you see any such links coming out, please post a link and ping me, as I may have missed a page or misunderstood where the source text comes from. There are still a few anachronisms in there (this year's parliamentary poll etc.) and some redlinks to deleted pages, but it might be disruptive to remove them as the pages also constitute a historical record. Certes (talk) 13:03, 3 August 2018 (UTC)

New template: Transclude DYK

@Armanaziz and Pbsouthwood: I have edited Portal:Bangladesh to select DYKs automatically using a new template, {{Transclude DYK}}. Certes (talk) 16:30, 25 July 2018 (UTC)

Not really important, but should we make the canonical name {{Transclude Did You Know?}}, for which {{Transclude DYK}} would then be a shortcut? This would apply to the module too. Is there even a naming convention for templates? Didn't see much in WP:NAME. — AfroThundr (u · t · c) 02:28, 26 July 2018 (UTC)
I don't know if there are template naming conventions. Either option looks OK to me as both are reasonably meaningful and likely to be remembered and understood, and are not over-long. · · · Peter (Southwood) (talk): 06:21, 26 July 2018 (UTC)

Many older DYKs now link to disambiguation pages because the target articles have moved. A few editors are kindly fixing the portals, but JL-Bot undoes this work by restoring the original text each weekend. I'm working through the dab links in the source pages, so this problem should go away soon. Certes (talk) 16:14, 28 July 2018 (UTC)

Update: Done 2010–2018; still working on older pages. I'm also noticing a few DYKs with links to deleted articles (Did you know… that Spam Inc has an office in Ruritania?) and factoids that have been overtaken by events; particularly where something happened "this year" meaning 2011 etc. I'm not sure how best to weed these out without damaging the archives. Certes (talk) 12:32, 2 August 2018 (UTC)
I now have confirmation that JL-Bot uses the blurb in the {{DYK talk}} header on each article's talk page. As these rarely get updated to fix links etc., I think it's better to continue using {{Transclude selected recent additions}}, which uses the updated monthly pages, instead. Certes (talk) 14:16, 4 August 2018 (UTC)

Random page titles from category?

Okay, here's the next item on my portal maintenance wish list. I would like a way to list a random selection of article titles from the various maintenance categories populated by WikiProject:Trains.

On Portal:Trains, the "Things you can do" section lists various tasks that readers can jump into. Many of the tasks have associated maintenance tracking categories. For example, the assessment task is related to the unassessed articles category, and the infobox needed task is related to the infobox needed category. Other tasks are also closely related to tracking categories like this. What I would like is a script that would randomly select and list a specified number of article titles (usually I pick five article titles) to populate the task in this portal section. The closest tools that I can find right now are Special:RandomInCategory and {{Random page in category}}, but both of those will jump to the article and not return just the article title.

Thanks! Slambo (Speak) 17:23, 15 July 2018 (UTC)

As a side note, many of the WikiProject:Trains maintenance tracking categories will list the talk pages because that's where the project banner is placed. So the script I want will remove the Talk: namespace identifier and link to the article. Slambo (Speak) 17:26, 15 July 2018 (UTC)

@Slambo: Unfortunately, Lua can't currently return members of a category. So, this task would require a bot.    — The Transhumanist   03:19, 10 August 2018 (UTC)

@Waggers, AfroThundr3007730, Godsy, Rockmagnetist, and Dreamy Jazz:

The text is centered in Portal:American football, and I can't figure out why.

Looks awkward. Can someone fix this?    — The Transhumanist   06:21, 10 August 2018 (UTC)

@The Transhumanist: After some extensive investigation, I found a solution: adding "|text-align=left" to Portal:American football/box-header fixes the alignment (see Special:Diff/854285968). As to why that was necessary, I cannot say. — Godsy (TALKCONT) 06:56, 10 August 2018 (UTC)
Very clever. Thank you.    — The Transhumanist   06:59, 10 August 2018 (UTC)
Yeah, their box header subpage is using {{box-header-round}}, which defaults to |text-align=center. I'm guessing it's normally used for the intro and not every section. — AfroThundr (u · t · c) 11:55, 10 August 2018 (UTC)

The random portal link doesn't appear to be random.

If you click on it, and then click on that link on the new page that displays, and keep doing that, the same set of portals appear over and over.

Does anyone have any idea of why this is happening?    — The Transhumanist   03:06, 10 August 2018 (UTC)

@The Transhumanist: I've just done that 25 times, and a few duplicates did show up:
But that's basically because each time you visit the link, the software has no idea what portals you've already seen. Each portal always has a 1/545 chance of being the next random portal, and the odds of it being a duplicate is (number of unique portals you've seen)/545. It's basically equivalent to rolling dice – there's no way to guarantee the next roll won't be the same as any previous rolls. - Evad37 [talk] 07:47, 10 August 2018 (UTC)

@Evad37: Those are the same ones I keep getting (plus about double again that number). What I'm saying is, that around 75 portals (including the ones you posted above) are the ones that keep showing up. Click 200 times, and you'll see what I mean. There's a subset of a few dozen portals that is displayed, beyond which it does not seem to go. How do we pop this bubble?    — The Transhumanist   07:58, 10 August 2018 (UTC)

@Evad37: This appears to be most, if not all, of the bubble:

Extended content
  1. Portal:1910s
  2. Portal:Algae
  3. Portal:Alieu Ebrima Cham Joof
  4. Portal:Alpine Rhine Valley
  5. Portal:Amsterdam
  6. Portal:Android
  7. Portal:Archaeology
  8. Portal:Artsakh
  9. Portal:Athens
  10. Portal:Australia
  11. Portal:Barcelona
  12. Portal:Carry On
  13. Portal:Cetaceans
  14. Portal:China
  15. Portal:Civil rights movement
  16. Portal:Community of Christ
  17. Portal:Cryptography
  18. Portal:Dresden
  19. Portal:Edinburgh
  20. Portal:European Union
  21. Portal:Europe
  22. Portal:Example
  23. Portal:Florence
  24. Portal:H. P. Lovecraft
  25. Portal:Herbalism
  26. Portal:History
  27. Portal:History of science
  28. Portal:Hong Kong
  29. Portal:Humanism
  30. Portal:Kyoto
  31. Portal:Limited recognition
  32. Portal:Literature
  33. Portal:Lithuania
  34. Portal:Malayalam cinema
  35. Portal:Mandatory Palestine
  36. Portal:Medicine
  37. Portal:Milan
  38. Portal:Military of Pakistan
  39. Portal:Monaco
  40. Portal:Munich
  41. Portal:Nautical
  42. Portal:New York roads
  43. Portal:Pac-Man
  44. Portal:Palermo
  45. Portal:Philately
  46. Portal:Poland
  47. Portal:Prague
  48. Portal:Quantum computing
  49. Portal:Quebec
  50. Portal:Railways in Pakistan
  51. Portal:Reference works
  52. Portal:Religion
  53. Portal:Reptiles
  54. Portal:Rio de Janeiro
  55. Portal:Rivers
  56. Portal:Sacramento
  57. Portal:Saint Petersburg
  58. Portal:Samsung
  59. Portal:Saudi Arabia
  60. Portal:Scottish islands
  61. Portal:Singapore
  62. Portal:Stockholm
  63. Portal:Taipei
  64. Portal:Telephones
  65. Portal:Turin
  66. Portal:United States
  67. Portal:Vienna
  68. Portal:Webcomics
  69. Portal:Wolfgang Amadeus Mozart
  70. Portal:Westerwald

With these same ones coming up over and over.    — The Transhumanist   08:45, 10 August 2018 (UTC)

Do you have a wikilink to where this problem occurs? Perhaps whatever template you are using reads its arguments into a table, then uses only the first entries of the table using something like Lua's pairs. The order within the table isn't guaranteed and can vary between Lua interpreters but may tend to match the order given when invoking the template. You could mix things around using code similar to that near the end of Module:Transclude DYK (search for random entries). Certes (talk) 15:28, 10 August 2018 (UTC)
The template isn't using Lua, just the simple wikilink Special:RandomInCategory/All portals, which is equivalent to entering that category on the Special:RandomInCategory special page. Lua can't be used since it can't see pages within categories. - Evad37 [talk] 20:36, 10 August 2018 (UTC)
Thanks for the clarification. mw:Extension:Random In Category says that The core version gives much more biased results than this extension. mw:Category:Extensions used on Wikimedia suggests that Wikimedia doesn't use the extension. So I assume we're using the core version which gives biased results. I doubt that we can do much about this. Certes (talk) 20:48, 10 August 2018 (UTC)
... unless we (or a bot) were to maintain a subpage with a list of portals, and use a better random selector to pick from that. That would allow us to limit the display to certain portals only, which may or may not be desirable. Certes (talk) 20:56, 10 August 2018 (UTC)
@Certes and Evad37: Well, we need something better than a subset of 75 portals. If you create that something, we'll use it! ;)    — The Transhumanist   08:01, 11 August 2018 (UTC)
"That something" would need a list of portals. As we know, there's no way for Lua to list a category, and I don't think it can do any sort of search within a namespace either. So we'd need to dump Category:All portals onto a page. (If we want new portals to have a chance of appearing then a bot would need to update that page. Does anyone know of such a bot?) Then the relevant page (Portal:Contents/Portals/Intro?) can use a new template which produces a wikilink like [[Portal:Alpine Rhine Valley|Random portal]] to a genuinely random entry from a list. That template should be easy to write but it would keep showing the same portal until someone purges the page, which (surprise, surprise) you can't do from Lua. I do feel that all of this is using a sledgehammer to crack a nut. Perhaps we should just be submitting a Phabricator ticket to have Special:RandomInCategory made more random. I suspect that, for efficiency, it is just pulling out the first page of the category, just as Category:All portals does until you click "next page". Certes (talk) 12:14, 11 August 2018 (UTC)

Convert template body into portal body

I've been using {{Transclude list item excerpt}} and {{Transclude list item excerpts as random slideshow}} to pull items out of templates, like Template:Counties of Denmark, like this:

Selected counties of Denmark

This got me wondering about templates like {{Daytona 500}}:

Could a tempate/lua script be written to convert templates into portal guts (after the intro, alongside the image slideshow, and before the support sections (WikiProjects, Topics, Wikimedia, etc.), with a section created for the portal corresponding to each section of the template?

Thus, for Portal:Daytona 500, it would generate sections called "Selected track article", "Selected Statistics article", "Selected lore article", "Selected notable race", "Selected related event", "Selected related area" and "Selected Daytona race report".

The implications for portal creation would be stratospheric!

I look forward to your replies. Sincerley,    — The Transhumanist   21:21, 12 August 2018 (UTC)

Taking things to their logical conclusion, how feasible is it to have a portal link on the sidebar menu, or in one of the tab menus at the top of every page, that generates a portal for the current article's subject when you click on it?

So, if you are reading the article on chimpanzees, and you click on "Portal", a "Special:" page called "Special:Portal:Chimpanzees" is generated and displayed right then on chimpanzees.

I look forward to your replies. Sincerely,    — The Transhumanist   21:15, 12 August 2018 (UTC)

Quantum portals that exist only as a probability function (algorithm) until you collapse the wave form by observing through the portal button (run the script), and disappear again after use? · · · Peter (Southwood) (talk): 15:28, 14 August 2018 (UTC)
More seriously, what do you envisage as the structural foundation for such a portal? I can see an instant portal generator possibly working using a navbox or an outline list or a category as the source of the selected article set. The root article would presumeably be the one from which the portal is called, so how would it work if there is no similarly named category or outline list? How would it deal with orphan articles and others which don't have many associated articles? Would one just accept that instant portals would often be relatively low level and sparse of content, or would it only work for articles with the required associated structures? Some features commonly used in regular portals may be difficult to produce, or could be quite run time intensive to build. I like the idea in principle as a very user friendly introduction to a topic, but is it technically plausible for current technology within the Wikipedia environment, or would this be more appropriate as an external tool drawing on Wikipedia for the content? (just brainstorming here) · · · Peter (Southwood) (talk): 15:28, 14 August 2018 (UTC)
I believe it is feasible to build such a system, over time, but it is not a short-term project (maybe a year or three). However, I can't help but notice that we are heading in this direction, and the distance we've traveled in just the past 4 months.
With the right source pages (or other data sources), portal creation goes quick. Prior to the portals project reboot, portal creation typically took 6 hours or more, each. This morning, from 12:16am to 7:34am I created 51 portals. That's about 8 minutes each, on average. Now I'm thinking that portal creation could eventually be nearly instantaneous, via a universal gadget or Mediawiki extension, with the right data foundation.
But, we want human effort and computer power to intermingle, and so there would need to be a way for human contributions to be included. For example, if you wanted to add a particular section to a portal, or do most of it yourself. The tool could go off of existing portals, where they exist, augmenting those, and generating portals from scratch for subjects for which they don't exist. Or, users could control portals by editing the underlying data sources, perhaps with some special ones reserved for users.
Also, it's not feasible to do a portal for a stub article's title. So, there would be some formula for deciding whether a topic is extensive enough to even have a portal. See Portal:Quidditch for the lower end of the spectrum.
I'm not sure that initially, all of the instructions would be in the program, or if much of it would be in templates that were called, or other components. For example, in Template:Box portal skeleton, "In the news", "Did you know?", and "Get involved" are all conditional, appearing only if there is underlying data to populate them. So the portals that have a correspondingly named WikiProject, get a "Get involved" section automatically.
Focus might shift from building portals to standardizing the other navigation systems (navboxes, outlines, categories, etc.) from which portals would draw their data. We've yet to crack the categories egg, but so far, outlines and navigation footer templates have proven to be highly useful for populating portals. So, it doesn't have to be a single data source type. Tables look especially juicy and ready to harvest. :)
But, we're overlooking Wikipedia's database itself. I'm sure there are ways to mine that directly, to build portals. There are a myriad of data tables in there, for example.
The point is, that it's coming. We just need to remain alert as to how we can make it happen as we go along, and so this conversation should continue. Eventually, all of the resources will be available to click into place. But, what resources?
We've cut human input time on portal creation by a factor of about 36. If we do that again, in our ongoing development, portal creation will be down to around 13 seconds of human effort, for each portal. And from there, we'll probably see how to drop it by a factor of 36 again. :)
The fun part is, that we haven't even scratched the surface on the features that can be provided in this medium/venue. The future appears very bright for portals. (And for the other navigation systems, as much of this technology will be applicable or adaptable to them, as well. Self-building outlines, indexes, glossaries, books, navigation boxes, lists, tables, and categories, would be nice, for example).    — The Transhumanist   22:31, 14 August 2018 (UTC)

What would you want a portal tool to be able to do?

There are lots of tools that let editors do various things to pages on Wikipedia, like AWB, WikEd, and TWINKLE. There's now another one, called PortalTool.js, intended to work on portals, that currently does nothing.

What it will be able to do, will be in part up to you. What do you want this tool to be able to do to portals for you? Use your imagination: you click a menu item, and what happens? I look forward to your replies.    — The Transhumanist   12:37, 10 July 2018 (UTC)

A user script is probably best for one-off tasks, like a portal creation wizard, or converting a section to use one of the automation templates (though that may be redundant to just using AWB?). Ongoing maintenance-type work, like fetching category members for use in excerpt templates, would be better done by a bot, so it can be kept up to date by regularly repeating the task (e.g. on a daily or weekly schedule) across hundreds or thousands of portals. - Evad37 [talk] 07:56, 11 July 2018 (UTC)
I also prefer user scripts. I am on a system that won't allow installation of AWB. I suspect I may not be the only one.--- Coffeeandcrumbs 05:17, 14 July 2018 (UTC)
@Coffeeandcrumbs: By the way, much of the functionality of WP:AWB was ported to WP:JWB, which runs on most computers.    — The Transhumanist   04:39, 18 July 2018 (UTC)
Whatever it is, it should allow insertion of any of the automation templates we have been accumulating recently with hints for all the parameters. It would be nice if it allowed both creation of a new portal to a standard design containing one of each feature, and also upgrading by adding any of the features in a user-selected place in an existing portal. Manual portals will be with us for a while, so easy conversion aids would be useful for quite a long time, but they may well be the same thing as the tools for inserting additional features. It should encourage standardisation of components while allowing sufficient diversity of options that people will want to stick to the more automated layouts. · · · Peter (Southwood) (talk): 10:54, 26 July 2018 (UTC)

@Pbsouthwood, Evad37, Coffeeandcrumbs, AfroThundr3007730, Bermicourt, Dreamy Jazz, Nick Moyes, Auric, Waggers, and Godsy:

Thank you for the input. Let me summarize what we have dreamed up so far, and add some ideas and details that you have inspired by your input. Each of the below are menu items, to be displayed on the sidebar menu, when the user is viewing a portal:

  1. Create Portal – menu item for creating a new portal, defaulting to the subject of the current page. If you are reading the article "Saturn" and click "Create Portal", it will ask if you want the new portal to be on Saturn. If you answer "no", it will prompt you for the desired title. Not sure what it would ask next.
  2. Upgrade portal – for the current page (if it is a Portal), presents a list of section names beside a number, and "All". You enter the number of the section you wish to upgrade, or "All". If there are more than one upgrade available for a section type, it prompts you further.
  3. Add section – provides a selection of section types, by number. Specify the number to choose which type you want. If the heading is variable for that section type, it prompts for the heading title, and then prompts you for location in the portal to place it.
  4. Move section – provides list of sections, by number. User enters the number desired. Then script prompts for new location, in the form of a section number, and Right of, Left of, Before, After. Saves having to go into the editor and cut-and-paste-move the section.
  5. Rearrange sections – more elaborate move command, that allows you to rearrange the sections by number. If none is provided, rearranges to the standard presentation placement (whatever that is). Not sure what the interface would be.
  6. Analyze – not sure what this would do. Perhaps, provides a list of missing sections to choose from.

Concerning the fetching of categories, I was thinking that would be best to handle with user scripts first, until we actually know how, and then a bot could be adapted from that part of the program. Otherwise, I'd be oblivious on how to program a bot. Interactively develop it somewhere first, and then go to bot. Unless there's something I'm missing from the whole bot process?

Well, that's all for now. I hope this stirs your thinking further. Please feel free to share any new ideas you have or provide more details on how the above features should work. This is brainstorming. Anything goes. And just for the fun of it, I've invited some more people to the party.    — The Transhumanist   02:14, 13 August 2018 (UTC)

A WYSIWYG drag-and-drop layout tool for adding, arranging and removing sections would be very nice. WaggersTALK 11:22, 13 August 2018 (UTC)

Discussion:

  • Create portal
    Looks good. Will this use a defailt arrangement, or prompt for location of components? I suggest defailt, as Rearrange sections is available below and can be used to tweak the product, while allowing an easy revert to standard if it all goes pear-shaped. · · · Peter (Southwood) (talk): 05:36, 13 August 2018 (UTC)
  • Upgrade portal
    In principle, looks good. The details of what it would do are not clear yet, probably because this is still in development. I suggest that one of the things would be to fix accessibility problems with colours in the box-headers. Replace old templates with new where it does not break functionality. What else? · · · Peter (Southwood) (talk): 05:36, 13 August 2018 (UTC)
  • Add section
    Yes, useful.· · · Peter (Southwood) (talk): 05:36, 13 August 2018 (UTC)
  • Move section
    Yes, providing it leaves clean wikicode in the result, or at least not too nuch to clean up. It may be difficult to manage comments cleanly, and should warn if there may be anomalous comments after the move. · · · Peter (Southwood) (talk): 05:36, 13 August 2018 (UTC)
  • Rearrange sections
    I like the idea of reverting to a standard arrangement if we can agree on one, and allowing customised arrangement if needed. Also should leave clean wikicode. · · · Peter (Southwood) (talk): 05:36, 13 August 2018 (UTC)
  • Analyse
    This feature appeals to the inner nerd, so I like it in principle.
    • Agree that listing missing standard sections would be useful.
    • Calculation of depth of template calls, Lua load, time to render etc (or whatever these things are called) would be handy if they can be called from the html, because most of our editors probably don't know that such things exist. An explanation of what these things mean/comparison with the current limits would make this useful to see when a portal is approaching critical mass.
    • Check on accessibility issues.
    • It could have links to other page analysis tools and statistics. Some of the GA, FA and peer review tools could be useful.
    • Analysis might include a warning that the portal is tagged for manual maintenance, but has not been changed for say 3 months or date of last maintenance edit.
    • There could be a quality check against the criteria where reasonably feasible and a suggestion to look more closely if near a borderline or if the existing class is different.
    • Other things will be requested as we think of them. · · · Peter (Southwood) (talk): 05:36, 13 August 2018 (UTC)
My only hesitation about a portal creation tool is that, unless there is some sort of approval process, it could encourage an explosion in the number portals, which are either on very narrow topics or which fail to be maintained. So I'm not against the tool itself - I think it's a great concept - just concerned about this project then facing an issue of gazillions of low-value, poorly maintained portals which then put us back into a situation where portals as a whole come under attack by the community. Bermicourt (talk) 06:44, 13 August 2018 (UTC)
I agree. I like the idea of the creation tool, but not making it available on every article. Making it available on category pages could be a better approach, as these are likely to be on broader topics. Or the script could check whether an article is the main topic of a category, and only display the "create portal" link if it is. WaggersTALK 11:19, 13 August 2018 (UTC)
I also agree. I also like the idea of the script, but we will want to ensure that creating portals can only be done when the portal will meet the criteria (so the idea of categories idea is a good thought). It may be a good idea to ensure that a certain number of edits and time has passed before a user can use the script (perhaps checking for extended confirmed user group) so that new users cannot spam portal creation. Dreamy Jazz talk | contribs 14:16, 13 August 2018 (UTC)
If the portal creation tool worked only on a pre-existing structural framework such as an outline list, category, or navbox it could check that the framework was sufficiently complex to be suitable. · · · Peter (Southwood) (talk): 15:37, 14 August 2018 (UTC)
Having unfinished portals in "Portal:" space is a problem. Maybe we should move them all to the "Draft:" namespace, even if they are multi-paged. And then, in the future, if we come across an unfinished or poor quality portal, all we have to do to keep the collection clean is move those to Draft: space. In this regard, Draft: space would make a wonderful quality control tool. I've added a suggested feature below, for the PortalTool tool to create new portals only in the Draft: namespace.    — The Transhumanist   18:21, 13 August 2018 (UTC)

Some more possible features

@Pbsouthwood, Evad37, Coffeeandcrumbs, AfroThundr3007730, Bermicourt, Dreamy Jazz, Nick Moyes, Auric, Waggers, and Godsy:

@Slambo, SMcCandlish, FR30799386, Mercurywoodrose, Dicklyon, Dthomsen8, Espilio, Greatedits1, Nigos, and Wumbolo:

Here are some more possible features for the PortalTool. See the initial description for the script and discussion of features in the previous section above. (Typescript represents menu items):

  1. Creates new portals in the Draft: namespace – To avoid the consequences of having unfinished portals in the portals namespace, since we are dealing with a one-page design here, creating new portals is feasible in the draft namespace. If one goes 6-months without any edits, it gets summarily deleted by someone. We just have to make sure all the templates work the same in that namespace.
  2. Change color – not sure how this would handle portals that use different colors on its various sections. In such cases, it should probably present a warning before proceeding. See: Portal:Microsoft.
  3. WYSIWYG drag-and-drop interface – idea courtesy of Waggers. This might be possible by altering the HTML directly, which would require clicking a save button or menu item to convert the HTML to wiki format and edit and save the page accordingly.
  4. Unfinished portal alert – tool has discovered an unfinished portal, and asks the user if it should be moved to draft space. If answered, yes, the tool moves the portal to draft space. Is this possible?
  5. Portal has problems alert – in addition to displaying a notice of the problems, also prompts the user for appropriate tag placement. If the user answers "yes", the tool places the relevant tags, which in turn puts the portal in the corresponding category where our troubleshooters can spot it. Maybe we can borrow functionality from Twinkle?
  6. Manual maintenance alert – presents notice that the portal is manually maintained, then asks if user wishes to proceed.
  7. Subpages detected alert – not sure what the tool can do about subpages. Thoughts?
  8. Add to selection – presents a numbered list of the "Selected" sections and prompts for a number. After the user enters a number, the script prompts for the item to be added to that section. This would require use of a template that could accept both sourcepage names and excerpt article names. Is such a template possible?
  9. If draft already exists, loads the draft – self-explanatory.
  10. Automatically upgrade certain sections – news sections and DYK sections can be made conditional, so that they appear only when they have items to display. Categories section has some straightforward tweaks that can be applied. Prompts the user before proceeding on each operation.
  11. Check for extended confirmed user group – idea courtesy of Dreamy Jazz.

I look forward to your comments and further ideas.    — The Transhumanist   18:21, 13 August 2018 (UTC)

Concerning using the draft space for portals, it screws up the use of the {{PAGENAME}} magic word. The pagename for Draft:Portal:Whatever is Portal:Whatever, which makes many of the templates not work. The only fix I can think of off the top of my head is to have a "Portal draft:" namespace.    — The Transhumanist   19:30, 13 August 2018 (UTC)

Regarding the draft namespace portals, another factor must be considered: besides breaking the page name, some of the templates won't operate correctly outside of portal space. Having a draft step might be unnecessary for most portals though. If the portal pending creation is going to be standard layout, simply using the portal skeleton and tweaking the result would be sufficient. Since {{Box portal skeleton}} tags new portals as incomplete by default, we can track them, and most wouldn't need an extended stay in draft space. — AfroThundr (u · t · c) 23:47, 13 August 2018 (UTC)
Building on this idea, if the portal creation tool will not create a portal unless it meets the minimum requirements, this problem goes away. · · · Peter (Southwood) (talk): 15:44, 14 August 2018 (UTC)

In retrospect, it will probably be best to focus on portal editing features for now, rather than on one for portal creation. The community's concerns in the RfC focused on the inadequacy of existing portals. So fixing those up should remain our priority. Portal creation at the push of a button would be extremely distracting. Portal creation can still be done by using the various templates designed for that. This way, we don't need to worry about push button creation of a flurry of unfinished portals. Once the templates have been developed to automatically create completed portals of high quality, then adding creation to PortalTool makes sense. The tool would simply insert one of those, and perhaps ask for parameters.    — The Transhumanist   19:37, 13 August 2018 (UTC)

Working on a prototype for a portal creation tool can be done in parallel with developing portal fixing tools, and each may produce useful ideas for the other, but a production version is not high priority, and will not be until we have defined the minimum requirements more clearly. Eventually producing a substantial portal from scratch should be easier and less work than fixing an existing portal. When we reach that point it will be more efficient to rebuild from scratch then to patch up old portals. This point may not really be that far away if we can come up with a way to easily create a robust structural framework. Categories spring to mind, but not for long, as Wikipedias categories seem to be a bit of a mess (the ones I have looked at, anyway) Navboxes are probably too limited in most cases, and outline lists, while inherently suitable, still require a lot of manual input to create and maintain. · · · Peter (Southwood) (talk): 16:09, 14 August 2018 (UTC)

Detail discussion of new possible features:

  1. Draft space:
  2. Change colour:
  3. WYSIWYG drag-and-drop interface:
    • Can't comment on this as I don't understand what is being suggested. · · · Peter (Southwood) (talk): 16:47, 14 August 2018 (UTC)
      • @Pbsouthwood: This: You see the portal on your screen. You don't like the placement of the picture slideshow, so you click on it, holding down the mouse button. Then you drag it to where you want it on the page, and then let go. The picture slideshow is now where you want it. In the background, the tool has edited the underlying wikicode, so that it appears that way permanently.    — The Transhumanist   22:50, 14 August 2018 (UTC)
  4. Unfinished portal alert:
    • Part of the analysis toolset? Tag portal as unfinished, if it has not been edited in ? months, either fix using tools, tag as unfinished, or tag for deletion. · · · Peter (Southwood) (talk): 16:47, 14 August 2018 (UTC)
      • The tool should also be able to tell the user if the tool can fix it, and ask to proceed. Then there would be no need to tag any of them for deletion. Unless they are hopeless.    — The Transhumanist   22:50, 14 August 2018 (UTC)
        • Agreed. Even better if it also has a way to identify the probably hopeless cases. Also what is hopeless today may be quite apprpriate next year, but the portal should not exist until it is appropriate, because this toolkit will make it quick and easy to create when the time is right. It might even provide suggestions for what additional mainspace content is needed to make a portal appropriate for the topic.· · · Peter (Southwood) (talk): 05:52, 15 August 2018 (UTC)
  5. Portal has problems alert:
  6. Manual maintenance alert:
  7. Subpages detected alert:
    • Show on opening existing portal. If not manually maintained, fix using tool if conveniently possible, or tag if not already tagged. Not a high priority to fix if working OK, and in date, but fair game for conversion if not flagged as manually maintained. In some cases rebuilding from scratch may be less work, Leave to discretion of the editor. Tool to list acceptable options. · · · Peter (Southwood) (talk): 16:47, 14 August 2018 (UTC)
  8. Add to selection:
  9. If draft already exists, loads the draft:
    • Not as self explanatory as claimed, as I don't know what is proposed here. · · · Peter (Southwood) (talk): 16:47, 14 August 2018 (UTC)
      • There's no portal for a subject. You click "Create portal". The script checks draft space to see if there is a portal already started there. If there is, it loads that for you to continue work on.    — The Transhumanist   22:50, 14 August 2018 (UTC)
        • OK, Obviuous once you see it. Some things are like that. That would be a useful feature, though in some cases the draft may be more work to fix than creating a new portal from scratch (the draft may be really badly structured or full of deprecated formatting). It would be even more useful if it can tell the difference and advise which way to go.· · · Peter (Southwood) (talk): 05:43, 15 August 2018 (UTC)
  10. Automatically upgrade certain sections:
    • Proposal is for semi-automatic upgrades as user is prompted, but good idea. Disable if manually maintained? Disable tool altogether for manually maintained portals or require confirmation of edits after warning?
  11. Check for extended confirmed user group:

 You are invited to join the discussion at Template talk:Box-header#Switch to Module:Box-header?. Evad37 [talk] 07:22, 13 August 2018 (UTC)

I missed this, but see that you have already converted {{Box-header}} to match {{Box-header/lua}} and accept colour parameters. I think this makes a lot of sense, so well done and thanks. Also, thanks for updating Portal:Scotland accordingly. Cactus.man 17:01, 19 August 2018 (UTC)

Javascript tasks?

Hi, I read through the main project page, and I couldn't tell which tasks require knowledge of Javascript. Could someone elaborate? Thanks! --audiodude (talk) 21:46, 22 August 2018 (UTC)

@Audiodude: At the moment there's just an initial design discussion, see § Discussions about a portal tool above - Evad37 [talk] 02:06, 23 August 2018 (UTC)

Discussions about selected article sections

Maintaining portals that use transclusion

I've been constructing an automated page-lite portal at Portal:Scottish islands, but have increasingly found that, though initially very convenient to create, it's actually harder to maintain than the old hundred-subpages format, because one can't view all the selections at once to troubleshoot, as one can at, say, Portal:Cheshire/Selected article/Archive.

Is there a way of taking the content at a subpage such as Portal:Scottish islands/Island and using this as the portal's randomised rotation, without needing to create more than a single subpage level? This would be much more intuitive to old-fashioned portal maintainers, such as myself, and would, I believe, allow one to choose the image & image size, and to customise the number of paragraphs excerpted, without compromising the automated status or needing to fuss with creating hundreds of subpages. It would be particularly great if it could be applied to DYKs, as Portal:Cheshire/Did you know/Archive is a nightmare to update if you want to shuffle DYKs from selection to selection. Espresso Addict (talk) 17:38, 13 July 2018 (UTC)

@Espresso Addict: One possible solution is to upgrade to {{Transclude excerpts as random slideshow}}. That uses the same syntax as {{Transclude random excerpt}}, except for the template title, so the selections remain exactly the same. The difference is that you can now cycle through the excerpts by clicking on the < > keys. I've taken the liberty to adjust the portal to display excerpt slideshows (it looks the same except for the < > symbols at the tops of sections), so you can see the difference. Feel free to revert.    — The Transhumanist   02:24, 20 August 2018 (UTC)
@The Transhumanist: It looks ok to me, if a little spacy, but I don't know whether it works yet for mobile users?
As I wrote above, the thing that would be most useful would be the ability to customise on an article-by-article basis the number of paragraphs excerpted and to explicitly set the image. A lot of the article excerpts still aren't finding any image, despite the fact that the selected articles all have many excellent images. Espresso Addict (talk) 20:17, 22 August 2018 (UTC)
@Espresso Addict: Slideshows are not yet available for mobile users, nor will they likely be technically feasible anytime soon. Instead, mobile devices get a default view. To see it add a .m inbetween en. and wikipedia in the url, like this:
https://en.m.wikipedia.org/wiki/Portal:Scottish_islands
Concerning your template feature suggestions, I assume you are talking about {{Tranclude random excerpt}} and {{Transclude excerpts as random slideshow}} (correct me if I am mistaken). Those "accept any number of page names as unnamed parameters". I've pinged our Lua gurus. Perhaps they can let us know how feasible having parameters for each page would be to implement.    — The Transhumanist   00:21, 23 August 2018 (UTC)
Speaking for {{Transclude random excerpt}} only: yes, it could have those extra parameters but the syntax could become unwieldy. The change would also apply to {{Transclude selected excerpt}} (but not to {{Transclude linked excerpt}} nor {{Transclude list item excerpt}}, for which the articles are listed on another page). Here are a few options for how the entry for the 37th selectable article could look in the portal page which calls the template:
  1. … | Some article | paragraphs37 = 1-3 | files37 = 1,2
  2. … | Some article [paragraphs 1-3 files 1-2]
The first syntax is more standard but requires the editor to count the preceding articles and to update all parameter names whenever one is inserted or deleted. The second one is totally non-standard and abuses the fact that square brackets [] can't appear in an article name. (Angle brackets <> or braces {} would also work.) We can't use "[paragraphs = 1-3…" here: the = sign would prevent creation of an unnamed parameter and instead would give named parameter "Some article [paragraphs" the value "1-3 files = 1-2]". (Theoretically, we could parse article names from such unexpected parameters, but the resulting code would be arcane and unmaintainable.) Spacing is arbitrary in all cases. We could implement both but I think that might be even more confusing.
It is tempting to look for a way of allowing
3. … | Some article | paragraphs = 1-3 | files = 1,2
but, even if we managed to retain the parameters and detect their positions, the portal editor could get duplicate parameters warnings.
Further comments welcome, Certes (talk) 10:10, 23 August 2018 (UTC)

For regional portals (cities, counties, countries, etc.), I've been trying to build portals by pulling items out of lists (with {{Transclude list item excerpt}}, but a great many if not most of the lists in support of regions seem to be tables. For example, List of counties in Colorado, List of cities in China, List of provincial parks of Vancouver Island, and so on.

Can we get a transclusion template for pulling the main items out of templates? This would really help with creating regional portals. Here is a more detailed description, adapted from the template previously mentioned:

The template accepts one page name as an unnamed parameter. Wikilinked items in the first column of the indicated table are collected from that page, or a section of it. One such item is selected randomly, and its destination is transcluded. (If the selected page is invalid, the template will choose again.) Include a namespace where necessary.

Is this doable with Lua?

I look forward to your replies. Sincerely,    — The Transhumanist   20:15, 12 August 2018 (UTC)

That sounds easy but could be a pig in practice because everyone formats tables differently. For example, each row in the Colorado template uses {{Countyrow}}. It's all designed to display nicely to humans rather than to be machine readable, and any scraping we try to do may go badly wrong if someone decides to make the table look prettier in future. Certes (talk) 20:24, 12 August 2018 (UTC)
@Certes and Evad37: The links we want will be in a specific column. Would it be easy to identify the column specified as a parameter? If the user wants the links in the 3rd column, for example. How would differences in table formats affect column identification?    — The Transhumanist   18:46, 24 August 2018 (UTC)

Recognize sections in templates

For {{Transclude list item excerpt}} and {{Transclude list item excerpts as random slideshow}}, it would be very useful if they could recognize sections in a template. Such as in {{Mars}}.    — The Transhumanist   21:15, 12 August 2018 (UTC)

Whoa. I restarted Portal:Mars using a slight variation of box portal skeleton, and the revamp was completed in just 3 edits, complete with Did you know and In the news sections. The second edit was to refine the search string for those sections, and the third was to specify which file to use for the intro. Three edits! This would not have been possible without the portal components you guys developed. Thank you.
I can't help but wonder what miracles you guys will perform next. Well, when I look at the topics section, I begin to drool. Access to the subsections in there would allow those sections to be used to populate Selected sections further up the page. Then an editor could break the Selected general articles section into more specific sections, for a better mapping and presentation of the subject.
Is this possible?
When I try this now, by trying to specify the various sections of the Mars template that is used in the topic section of the Mars portal, it doesn't home in on the desired subsets of topics. See below...
Selected atmoshphere articles
Selected regions of Mars
Selected physical features of Mars
Selected geology articles
Each section above picks up items from the whole template, rather than the specified section of the template.
Can this be made to work? If so, what would that entail?    — The Transhumanist   19:49, 24 August 2018 (UTC)

From the portal:

Selected general articles

   — The Transhumanist   01:22, 24 August 2018 (UTC)

 Fixed, had parameter name typos in Module:Excerpt slideshow - Evad37 [talk] 04:54, 25 August 2018 (UTC)

Dynamic sizing of images

@Pbsouthwood, Evad37, and The Transhumanist: I have implemented a rough version of dynamic image sizing at Template:Portal dynamic image. I created some testcases at User:FR30799386/sandbox to show how it behaves. Please let me know if there are any other features that can be added — FR+ 05:29, 8 August 2018 (UTC)

Looks useful. Commented on template talk, and tested centering, which will be used fairly often. · · · Peter (Southwood) (talk): 06:13, 8 August 2018 (UTC)


@FR30799386: How does this differ from {{Portal image banner}}?    — The Transhumanist   18:33, 24 August 2018 (UTC)
@The Transhumanist: - The underlying CSS hack is the same. But implementing it inside the {{Portal image banner}} template would be a maintenance nightmare. I think this could be used to enlarge and display the accompanying extraneous images in the lead section of the portals. I am slightly involved in meatspace priorities these days, but once I get over them I'll try to convert it to lua and check for potential use-cases of the template. — fr+ 16:10, 25 August 2018 (UTC)
@FR30799386: Cool. By the way, if IRL is "meatspace", what is the space we are in right now called? :)    — The Transhumanist   23:50, 25 August 2018 (UTC)
Wikispace;) — fr+ 04:57, 26 August 2018 (UTC)

@John of Reading, The Transhumanist, Evad37, Certes, AfroThundr3007730, and Cesdeva:

Template:Number of portals is used to define how many portals currently exist on a couple of pages, including in Portal:Contents/Portals. However, it has to be updated by hand from database dumps, which John of Reading has been doing. The latest list is at User:John of Reading/List of portals. Could we replace it with something else? Since we have Category:All portals, {{PAGESINCATEGORY:All portals}} looks promising. It currently produces 545, which is quite a bit more than the template. However, it is also an expensive function call. If we want to replace it, we should probably replace Template:FPO number with {{PAGESINCATEGORY:Featured portals}} as well. Greatedits1 (I hope so | If not, let me know) 23:05, 16 August 2018 (UTC)

Yes, I'd use {{PAGESINCATEGORY:All portals}}. Good idea. I don't think one expensive call will be a problem, as the template isn't widely used. I hope that the comma which PAGESINCATEGORY inserts after the thousands digit won't trip up any automation which uses it. Certes (talk) 23:25, 16 August 2018 (UTC)
If any usage actually needs the plain number, it can formatted that way with {{formatnum:{{PAGESINCAT:All portals}}|R}} - Evad37 [talk] 03:37, 17 August 2018 (UTC)
Good. Do we even know if there are any usages which need the plain number? Greatedits1 (I hope so | If not, let me know) 16:01, 17 August 2018 (UTC)
Is it even worth having a template for this? Why not just use {{PAGESINCAT:All portals}} directly? (it's only three letters longer). - Evad37 [talk] 03:37, 17 August 2018 (UTC)
I don't think so. Really, that's what I was proposing above. Greatedits1 (I hope so | If not, let me know) 16:01, 17 August 2018 (UTC)
I've nominated it for deletion: Wikipedia:Templates for discussion/Log/2018 August 21#Template:Number of portals - Evad37 [talk] 07:07, 21 August 2018 (UTC)
Before we delete it, we need to update its callers to use PAGESINCATEGORY. Are we ready to do that? I am loath to edit User: pages, especially archives, but none of those editors still contribute regularly. Certes (talk) 10:33, 21 August 2018 (UTC)
Sure, but there's only actually 16 transclusions according to [1]. Plus the TFD regulars are pretty experienced with cleaning up template usage before implementing the result of a TFD discussion, see Wikipedia:Templates for discussion/Holding cell - Evad37 [talk] 10:54, 21 August 2018 (UTC)
Instead of deletion, we could also just replace the contents with the PAGESINCAT syntax. Doesn't matter much to me either way. — AfroThundr (u · t · c) 05:01, 27 August 2018 (UTC)

TemplateStyles RfC passed

@The Transhumanist, Cesdeva, and Evad37: Just a heads up guys, both the RfC to enable TemplateStyles on enwiki and the RfC to adopt the TemplateStyles guidelines were closed with consensus to implement. We may be able to make use of them soon, as soon as HTML Tidy gets replaced. — AfroThundr (u · t · c) 15:31, 18 June 2018 (UTC)

That is good news. · · · Peter (Southwood) (talk): 07:57, 25 June 2018 (UTC)
And now that we've switched from Tidy to Remex, the extension can be enabled (probably a couple weeks from now). — AfroThundr (u · t · c) 12:22, 6 July 2018 (UTC)

@The Transhumanist, Cesdeva, and Evad37: As of today, TemplateStyles are now enabled on enwiki. What's first on our agenda for these? — AfroThundr (u · t · c) 12:10, 19 July 2018 (UTC)

There's been various posts on the project's talk pages saying "we'll have to wait for TemplateStyles", or similar wording; we should go through the archives and current talk pages and make a list of what we want to do. I think a big priority should be getting a decent fallback for stuff that is currently broken on mobile, like slideshows. - Evad37 [talk] 13:36, 19 July 2018 (UTC)
I've started a list below, feel free to add to it - Evad37 [talk] 16:15, 19 July 2018 (UTC)

Things we need TemplateStyles for

Looking at the mobile view of Portal:Lithuania, the latest "showcase" portal to be mentioned in the project newsletter, it looks like all the slideshow elements are displaying. Is the fix mentioned above automatic or does something else need to be done to the template to stop all the selected items showing as a gallery? (cc: User:The Transhumanist)
A second but related question - do these slideshow templates work by loading all of the content from all of the pictures/articles and then hiding all but the selected one? If so that means users will be potentially downloading lots of content that they'll never actually see (unless they scroll through the entire slideshow). For mobile viewers on limited data packages, that's not a welcome development. Obviously not an issue if the images/excerpts are loaded on demand by AJAX. WaggersTALK 11:56, 27 July 2018 (UTC)
@Waggers: Evad37 is more qualified to answer these questions, as he developed the Lua module. I do recall that he reported that the slideshow does not work in the mobile view, and that he set at least one of the modules to default to an alternative behavior. So a fix of some sort is likely implementable...    — The Transhumanist   12:09, 27 July 2018 (UTC)

Is the fix mentioned above automatic or does something else need to be done to the template to stop all the selected items showing as a gallery?

The fix is automatic, through the TemplateStyles css files at Template:Random slideshow/style.css (image slideshows) and Template:Transclude excerpts as random slideshow/style.css (text excerpt slideshows).

do these slideshow templates work by loading all of the content from all of the pictures/articles and then hiding all but the selected one?

The higher resolutions images for {{random slideshow}} and {{transclude files as random slideshow}} are loaded via javascript, but the captions, small thumbnail images, and all the content for the text excerpt slideshows are loaded with the page. It's not great, but it makes the feature usable. As far as I know, there's no way of sending different content to mobile and desktop devices – apart for some reason for the gallery slideshow, which is missing on mobile website but present on the desktop website (along with the regular gallery, which is present on both but hidden by default on desktop). - Evad37 [talk] 17:24, 27 July 2018 (UTC)

Different text for mobile / desktop website

@The Transhumanist and Pbsouthwood: Remember Wikipedia talk:WikiProject Portals/Design/Archive 2 § Mobile view support ? Well, its now possible with a new template {{if mobile}}. Its really easy to use – {{if mobile|text for mobile website|text for desktop website}} – and will allow us to call a slideshow gallery a slideshow when it is a slideshow (i.e. on desktop website) but not when it isn't (i.e. on mobile website) - Evad37 [talk] 12:37, 30 August 2018 (UTC)

@Evad37: Nice. By the way, why is it that slideshows can't work on mobiles?    — The Transhumanist   13:21, 30 August 2018 (UTC)
See T194887 for details, but basically, it is currently not turned on for mobile. Turning it on would apparently break the media viewer, and cause severe reflow issues (content jumping around the page) - Evad37 [talk] 13:46, 30 August 2018 (UTC)
Thanks, it works for me. · · · Peter (Southwood) (talk): 16:44, 30 August 2018 (UTC)
Could this be worked into {{Random slideshow}} (or Module:Random slideshow) so that it provides a slideshow in desktop and a randomly selected single image (not a gallery) from the same set of images in mobile? The gallery view tends to be a bit overwhelming on mobile. · · · Peter (Southwood) (talk): 17:08, 30 August 2018 (UTC)

Transclude files as random slideshow

From an initial look, it seems that several, if not all, of the above issues is from the module getting confused by multiple images being specified on the same line (rather than with a linebreak between them), and maybe by images within tables. - Evad37 [talk] 15:07, 29 July 2018 (UTC)

Slideshow malfunctions

@Certes and Evad37:

I installed many slideshows, and most worked fine, but the following list of them are not working right:

Extended content
https://en.wikipedia.org/w/index.php?title=Portal:Animal_rights&oldid=854559045
https://en.wikipedia.org/w/index.php?title=Portal:Ancient_Japan&oldid=854561084
https://en.wikipedia.org/w/index.php?title=Portal:Alphabet_Inc.&oldid=854561399
https://en.wikipedia.org/w/index.php?title=Portal:Aerosmith&oldid=854559011
https://en.wikipedia.org/w/index.php?title=Portal:Czech_Republic&oldid=854563179
https://en.wikipedia.org/w/index.php?title=Portal:Buenos_Aires&oldid=854563033
https://en.wikipedia.org/w/index.php?title=Portal:Bihar&oldid=854562973
https://en.wikipedia.org/w/index.php?title=Portal:Beijing&oldid=854562969
https://en.wikipedia.org/w/index.php?title=Portal:Google&oldid=854567157
https://en.wikipedia.org/w/index.php?title=Portal:Human_spaceflight&oldid=854567266
https://en.wikipedia.org/w/index.php?title=Portal:Iowa&oldid=854572941
https://en.wikipedia.org/w/index.php?title=Portal:Kosovo&oldid=854573044
https://en.wikipedia.org/w/index.php?title=Portal:Lutheranism&oldid=854573098
https://en.wikipedia.org/w/index.php?title=Portal:Chandigarh&oldid=854574576
https://en.wikipedia.org/w/index.php?title=Portal:Punjab&oldid=854574591
https://en.wikipedia.org/w/index.php?title=Portal:San_Diego_County&oldid=854574727
https://en.wikipedia.org/w/index.php?title=Portal:Solar_System&oldid=854574787
https://en.wikipedia.org/w/index.php?title=Portal:Television_in_the_United_States&oldid=854578374
https://en.wikipedia.org/w/index.php?title=Portal:Terrorism&oldid=854578383

I hope the above links help.    — The Transhumanist   09:14, 12 August 2018 (UTC)

@The Transhumanist:  Mostly fixed. Many of these have been fixed by an edit to Module:Random slideshow. The remaining problematic ones are:

- Evad37 [talk] 10:43, 14 August 2018 (UTC)

Fixed Ancient Japan [2] - Evad37 [talk]
@The Transhumanist:  Fixed the remaining ones with another edit to Module:Random slideshow - Evad37 [talk] 17:37, 14 August 2018 (UTC)
@Evad37: That was amazing.    — The Transhumanist   21:12, 14 August 2018 (UTC)

Table troubles

@Evad37 and Certes: The new portals are sprinkled with this problem...

Notice the captions:

Selected images of lost architecture

Lua error in Module:Random_slideshow at line 200: No images found.

For every image that happens to be inside a table, we get the pixel size as the caption. This problem shows up sporadically in the new portals. Sincerely,    — The Transhumanist   01:48, 31 August 2018 (UTC)

@The Transhumanist: This is basically a problem with the source article List of missing landmarks in Spain. The files are specified as [[File:filename.ext|sizepx]], instead of [[File:filename.ext|sizepx|description]] (or [[File:filename.ext|sizepx|description|alt=alt text]]. Until the issue is fixed in the article, the module (Module:Excerpt) should probably just present the image without a caption – but detecting when this situation has occurred may be a bit tricky. - Evad37 [talk] 02:50, 31 August 2018 (UTC)

@Evad37 and Certes: The image slideshow is not picking up the images from X-Men. Do the slideshow templates pick up on .png images?    — The Transhumanist   01:52, 31 August 2018 (UTC)

@The Transhumanist: Those images are ignored by the module because they are non-free and thus can't be used - Evad37 [talk] 02:28, 31 August 2018 (UTC)

{{Portal image banner}} - Some questions / requests

I have recently been updating Portal:Scotland with Panorama header images (several versions as The Transhumanist will testify). Cuirrently they rotate randomly, dependant upon a user refresh / purge or page reload.

My question is this: Is it possible to get {{Portal image banner}} to behave in the same way as {{Random slideshow}} ? i.e allow the user to select a new banner image by clicking on a left / right navigation arrow without having to purge / refresh the page?

This is possible at present for panorama headers using {{Random slideshow}} at the head of the Portal, but it results in a truncated width banner image, with an ugly space above containing the user selection arrows. As things stand with {{Portal image banner}}, the images do rotate randomly, but it's dependant on a purge or page reload. It would be nice to allow user control, similar to {{Random slideshow}} / Selected Pictures. The banner image would remain full width, at the top header position with the user selectable navigation arrows showing at either side of the banner. Ideallly they would appear on top of the image at either side upon image hover. Alternatively, the navigation arrows could be static on either side of the banner image whilst keeping the image width as wide as possible and at the top header position.

Is this possible? I know it's a lot to ask, but I'm sure the technical folks here would love the challenge. (After all, Evad37 got CSS Flex to work seamlessly within the MediaWiki framework -(IMHO absolutely the BIGGEST thing since siced bread and BEYOND) - surely anything is possible?

I live in hope, Cheers Cactus.man 19:33, 30 August 2018 (UTC)

It should be possible to make the slideshow controls appear ontop of the image rather in a space above. I'm not sure about getting them to only display on hover though. Resizing the image take up 100% of the available width should also be possible, but with some loss of quality due to upscaling. And an appropriate fallback has to be provided for mobile (i.e. showing a regular {{Portal image banner}} for mobile). - Evad37 [talk] 09:30, 31 August 2018 (UTC)
It can be done....the only problem is the probable inconsistency in the positioning of the buttons over the image. — fr+ 06:39, 2 September 2018 (UTC)
Thanks for the replies, sounds promising. Cactus.man 07:13, 2 September 2018 (UTC)
Cactus.man I have put together a rough prototype here (the one on top). Is this what you wanted ?(It will need refinement though) — fr+ 05:52, 3 September 2018 (UTC)
@FR30799386: Thanks for that. it looks good and pretty much achieves what I was thinking of. My only comments are: 1) Is it possible to have the navigatonal arrows appear closer to the extreme left and right edges, in a similar fashion to a typical web gallery? 2) The navigational arrows may become difficult to see depending on the background colour where they appear, even though the image opacity lowers on mouse hover (not sure if that's technically the correct term). Is there a way of addressing this if it becomes an issue? Looking forward to having a working template. Cactus.man 08:46, 4 September 2018 (UTC)
@Cactus.man: I have added the requested functionality to Portal image banner. To access it add |mode=slideshow to the desired transclusion of the template. The template, however is configured not to work on mobile for the time being as I still have not figured out what to do . Please ping me for feedback bugs, improvements (I am quite busy IRL presently). Regards,  — fr+ 11:42, 12 September 2018 (UTC)
@FR30799386: Thanks a lot, the template works really well for navigating the panorama images. My only comments concern the effect on the associated captions: 1) A small "icon" like image appears immediately to the left of the caption text like a lower case "i" inside a circle. It's not causing a problem functionally, it's just a bit mysterious; 2) Any Wikilinks inside the caption text become unavailable because the caption text is within the area affected by mouse hovering and the entire caption text is subject to reduced opacity along with the banner image, rendering the Wikilinks un-clickable. That would be a nice thing to fix if at all possible. Other than that, it works brilliantly. You can see it in action at Portal:Scotland. -Cactus.man 19:31, 12 September 2018 (UTC)
@Cactus.man: The icon is added to provide attribution for the image per CC-BY-SA 3.0 . As for the other problem, it was due to my oversight while writing the code, it should be fixed now. — fr+ 11:30, 13 September 2018 (UTC)
@FR30799386: Thanks for the explanation and the quick fix for the caption issue. All working superbly now. - Cactus.man 12:07, 13 September 2018 (UTC)
@FR30799386: I have amended the template documentation page @ Template:Portal image banner/doc to include instructions for slideshow mode. You may wish to cast your eye over this to make sure I've covered everything correctly. Cheers, - Cactus.man 12:42, 13 September 2018 (UTC)

Override navbox styles

The purple and light-grey colour scheme of navboxes doesn't really fit it with how other content in portals are styled. But it is possible to make navboxes plain by specifying style parameters, like at Portal:U.S._roads#Numbered_highways_in_the_United_States. So the idea is to have a Lua module that takes in a navbox, or maybe just the template name, and outputs a plain version for the portal (without having to edit the navbox itself). - Evad37 [talk] 09:18, 15 June 2018 (UTC)

For that to work, would the module need to subst: the topic-specific navbox to get the original {{navbox}} call, where the style parameters can be specified? Or could it wrap the navbox in a div with a style tag using !important to override the various navbox-* classes? Since we can't put in style blocks, I'm not sure if we could target the classes directly. It sounds like we'd have to use the first approach. The module would parse the wikitext to pull out the navbox template, then parse the template's source, add or change the relevant style parameters, then return the resulting template code in place of the original. Sounds like this is feasible, but I'm not certain of the limitations of Lua in MediaWiki sites. — AfroThundr (u · t · c) 14:52, 16 June 2018 (UTC)
The first approach was more or less what I had in mind, but subst'ing shouldn't actually be necessary - it can get the page contents as a string, remove any <noinclude>...</noinclude> tags and their contents, and then just add extra style parameters before the last set of closing braces; finally preprocessing the resulting wikitext and return that as the output. I've already done something sort of similar at Module:Portal maintenance status, so it should be possible. The second approach wouldn't be possible yet, but probably would be when WP:TemplateStyles is enabled. - Evad37 [talk] 15:52, 16 June 2018 (UTC)
My current thinking is that a wrapper template like {{Plain navboxes|content= (navboxes go here) }}, which would use TemplateStyles to override the styles for the navboxes within. - Evad37 [talk] 02:08, 22 July 2018 (UTC)
@Evad37: That sounds interesting. Have you tested it out yet?    — The Transhumanist   09:27, 2 August 2018 (UTC)

@The Transhumanist:  Done, see Template:Plain navboxes/testcases for some examples - Evad37 [talk] 02:51, 30 August 2018 (UTC)

@Evad37: Tried it out on Portal:Genesis (band). Worked good. I'll test it out on some more.    — The Transhumanist   03:02, 30 August 2018 (UTC)
@Evad37: Okay, it is now in use on all of the Single-page portals. Seems to be working great. Makes the navigation templates blend in to look like part of the portal rather than something that was tacked on. A very nice upgrade.    — The Transhumanist   23:20, 14 September 2018 (UTC)

Can TemplateStyles be used to strip out the boxes altogether?

Can TemplateStyles be used to strip out the boxes altogether?    — The Transhumanist   18:04, 24 August 2018 (UTC)

Can TemplateStyles be used to reformat the entries as bullet lists?

Can TemplateStyles be used to reformat the navbox entries as bullet lists?    — The Transhumanist   18:04, 24 August 2018 (UTC)

No need. They are already bullet lists, as they have leading asterisks.    — The Transhumanist   23:21, 14 September 2018 (UTC)

Can TemplateStyles be used to reformat sidebar (vertical) templates to navfooter (horizontal) templates layout?

Can TemplateStyles be used to reformat sidebar (vertical) templates to navfooter (horizontal) templates layout? In generating portals using a creation template, with {{Template:subjectname}} specified in the creation template to transclude navigation templates into the portal's topic section, sometimes those turn out to be vertical sidebars or series boxes rather than horizontal navigation footer boxes. It would be nice if those were automatically reformatted into the navigation footer style. Can Templatestyles do that?    — The Transhumanist   18:04, 24 August 2018 (UTC)

Does Lua look at the html? Could TemplateStyles insert headings that Lua can see as sections?

It would be very convenient to populate Selected sections' slideshows with entries from the sections within a navbox within a portal's topics section.

The most convenient way these days for populating a portal's topics section is by transcluding navigation templates (which in turn typically use the navbox template inside them).

If we are reformatting navboxes via CSS, and WP:TemplateStyles is used to insert h3 headings into navbox content, will the Lua-powered templates, such as {{Transclude list item excerpts as random slideshow}} (which allows sections to be specified), recognize the headings as sections?    — The Transhumanist   18:04, 24 August 2018 (UTC)

Lua can only see wikitext, either before or after expanding templates. The only HTML it sees is any explicit <br> etc. in the wikitext. I've never used TemplateStyles. Certes (talk) 19:21, 24 August 2018 (UTC)
TemplateStyles doesn't affect the structure of the html that is is generated, only the various CSS styles that get applied to each element. So it hide things, but can't insert things that aren't already there. And it can adjust how things are displayed, e.g. colours used, and in certain circumstance perhaps even make vertical things appear horizontal (and vice-versa), but it can't e.g. remove all the box(table) markup, or change something that isn't a html list into a list. - Evad37 [talk] 04:05, 25 August 2018 (UTC)

Recognize sections in navbox templates

On a majority of all portals, navbox templates are used as sourcepages for populating their "Selected general articles" section.

However, navbox templates have much more potential. Most of those templates are arranged in sections, which provides a useful opportunity. Each navbox section ("group") could support a section on the portal, if a Lua script could be written or modified to access them.

This would allow improved context browsing. A "Selected biographies section" is an example of providing specific context.

Is this feasible?    — The Transhumanist   04:28, 15 September 2018 (UTC)

Could Lua extract list items from a navbox group?

How hard would this be? What would it take?    — The Transhumanist   04:28, 15 September 2018 (UTC)