Wikipedia talk:WikiProject Portals/Design/Archive 2#Enticing buttons

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

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

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

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

::{{done}} Cesdeva ^(talk) 19:34, 28 May 2018 (UTC)

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

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

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

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

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

::: That works great. Thank you.

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

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

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

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

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

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

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

::::::: {{ping|Certes}} It could be possibly done with Lua (see [https://stackoverflow.com/questions/17372330/lua-socket-post]), but I don't know if the libraries that it depends upon are enabled in wikipedia's version of Lua. Wpgbrown ^{talk | contribs} 14:24, 12 June 2018 (UTC)

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

{{ping|Cesdeva|Evad37|Certes|AfroThundr3007730|Wpgbrown|Waggers|Nihonjoe|Finnusertop|Greatedits1}}

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

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

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

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

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

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

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

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

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

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

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

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

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

:{{ec}} Using images as buttons has multiple problems or challanges:

:*Only a very limited set of image can be used, specifically those which are public domain or CC0. Other images are required to link to their description page to provide attribution

:*Images containing text aren't generally translatable. There is a way to do it with SVGs, but requires more advanced knowledge.

:*accessibility: Needs proper alt text; Looks pretty bad when images are turned off: colour contrast will fail MOS:COLOUR contrast requirements unless a light-coloured background is used

:*There are multiple ways portal icons are currently used besides {{tl|portal}}, e.g. {{tl|subject bar}}, {{tl|related portals2}}, wikiproject banners, {{tl|portal bar}}, {{tl|portal-inline}}; a large button-image-containing-text wouldn't be appropriate in all those situation.

:*A larger size would create more layout problems, especially for articles linking multiple portals.

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

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

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

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

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

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

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

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

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

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

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

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

{{ping|Certes|Evad37|Nihonjoe|Wpgbrown}}

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

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

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

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

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

{{Box-header|title=Some articles with pictures in the infobox|TOC=yes|EDIT=yes|SPAN=yes|}}

{{Transclude random excerpt|paragraphs=1-2|files=1-2

| Dog

| Cat

| Gharial

| Tuatara

| Tortoise

| Caiman

| Spectacled caiman

| Dwarf crocodile

| Horse

| Mouse

}}

{{Box-footer}}

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

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

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

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

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

{{Box-header|title=Snakes|TOC=yes|EDIT=yes|SPAN=yes|}}

{{Transclude random excerpt|paragraphs=1-2|files=1-2

| Snake

}}

{{Box-footer}}

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

:::{{done}} - Evad37 [talk] 04:40, 19 June 2018 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

= Discussions about overall portal design =

{{notice|General portal design discussions go here.}}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

: {{ping|Pbsouthwood}} Do you still get those problems when {{tl|{{wide image}} is used, such as on Portal:Munich and Portal:Vienna? Please provide some links, so we can see some specific examples of what doesn't work. (Please ping me in your reply).    — The Transhumanist   23:33, 19 July 2018 (UTC)

P.S. I'm also trying to understand why portal subpages are bad. I've created portals with and without subpages and can see merits in both... but perhaps I need to go back and re-read the discussion, lol. Bermicourt (talk) 22:09, 14 May 2018 (UTC)

:There's more than one way to produce a good portal. The templates are just one tool on offer; I hope there will be no pressure to use them where editors are happy to maintain the pages in other ways. Certes (talk) 23:32, 14 May 2018 (UTC)

::One possible way would be to select them from a category, but for that the category must exist, and the template must be able to select from categories. I envision a system where the template selects randomly from a set of categories, like the FA, GA and B-class articles in a project. A further refinement would be selecting or deselecting biographies, so FA, GA and B-class articles which are not bioraphies for the selected article, and FA, GA and B-class which are biographies for the selected biography. Selected images could be drawn from a list of images used in the articles of the set of categories. · · · Peter (Southwood) ^(talk): 16:31, 15 May 2018 (UTC)

:::Having the template select from a category is an unsolved problem. A VPT discussion came up with nothing better than having a bot copy the category listing periodically into a data page. Certes (talk) 18:31, 15 May 2018 (UTC)

:::: {{ping|Pbsouthwood|Certes}} There is a bot that can update a list with entries from categories. See Mathbot. That provides us with proof of concept.    — The Transhumanist   21:55, 15 May 2018 (UTC)

:::::An alternative is to select from an Outline list, assuming that the outline list exists. A well annotated outline could be better. It may be useful to separate any images in the outline with , depending on how the list is to be used. · · · Peter (Southwood) ^(talk): 06:01, 9 June 2018 (UTC)

: {{ping|Bermicourt|Broter}} Subpages are undesirable for 3 main reasons: 1) the more pages you have, the harder they are to maintain. We have 1500 portals that include about 150,000 subpages. Bots are allowed to process one page every six seconds. That's ten per minute. So, it would take about 150 minutes (2 hours, 30 minutes) for a bot to work through 1500 one-page portals, but 15,000 minutes (250 hours) to work through 150,000 pages (that's over 10 days, working 24/7). Human editors would take even longer (10,000 edits per year is considered a lot for an editor). 2) We have limited editor participation, and must use our labor wisely. 3) With portal maintenance and development active again, portal popularity is likely to rise, along with a slew of new portals. The number of portals could easily double over the next few years, much more than that and much more quickly if we find a way to automate the construction of quality portals. So, imagine 300,000 subpages for 3,000 portals if created manually, or 10,000 portals with a million subpages if created by bot or tool script. Therefore, it is very important to migrate subpage functions to the base pages. I see that our main job here initially is to tame this monster. The easiest way to do that is with a shrink ray. Broter has been very active in this regard. Perhaps he could shed some more light on this issue. I look forward to your thoughts, and any further questions you may have.    — The Transhumanist   22:59, 15 May 2018 (UTC)

::I contest this. The more specialized thos subpages are the more easy it is to maintain, by bot or otherways. For example in the German WP we have a boot which actualizes frequently (weekly or daily) the new pages subpages. Well, therefor, there is the need to maintain a functionable category system. Pityfully the EN:WP totally lacks off a system at all. It's a chaos. For eample: if a bot should list all new articles concerning Germany for the Portal:Germany he/it can't do so because you have also all landforms of France articles within the Category:Rhine which is part of the Category:Geography of Germany. [How the bot works: see for example :de:Wikipedia:WikiProjekt Vereinigte Staaten/Neue Artikel; documentation (German) @ :de:Benutzer:MerlBot/InAction. Note, that 1) in this case the new articles are listed on the WikiProject's subpage; and 2) MerlBot is inactive so TaxonBota took over. Similar lists the bot creates with lists of articles with maintenance tags.]

::What definitely is needed is standardization of the portals so that users won't have to find out every time the edit in a different portal how it is organized. --Matthiasb (talk) 01:11, 26 May 2018 (UTC)

:I am removing a fair few obsolete subpages. I would consider a subpage obsolete if:

:*The content on the subpage is not used anywhere on Wikipedia (such as most of the '/Wikimedia' pages)

:*The content on the subpage is so small that it does merit its own subpage (such as '/Categories' pages that use one or two category trees and '/Intro' pages that use {{Transclude lead excerpt}} and maybe a few images)

:If they did not meet the above, I would not remove the sub page. Wpgbrown (talk) 16:37, 28 May 2018 (UTC)

:: Keep in mind that any portal subpage that is transcluded onto a portal base page, or onto a page that is in turn transcluded onto a portal base page, should not be deleted. Until no longer transcluded.    — The Transhumanist   23:24, 28 May 2018 (UTC)

I edited Portal:Gujarat which was dead since two years. I found that the :Template:Transclude lead excerpt and similar :Template:Transclude selected excerpt does not excerpt images from Infoboxes so I have to manually add relevant image. This introductory images are helpful such as maps, country flags, images on biography etc. We can use Wikidata to display that image because Wikidata items have relevant images. I am not technical person so I can suggest only. What do you people think?--Nizil (talk) 13:03, 30 May 2018 (UTC)

:The templates do not currently find images from within {{tl|Infobox settlement}} because they are not marked with a recognised parameter name such as image=. Instead it has three images marked as image_seal, image_skyline (did you mean image_shylion?) and image_map. As it's not clear which image is most appropriate, it's probably best to select the image manually in these circumstances, as you have done. (Also leave files= off, in case this alpha module changes later to pick one of them up automatically). I would avoid using using Wikidata, as that can leave editors scratching their heads for hours trying to work out where the image is coming from. Certes (talk) 13:46, 30 May 2018 (UTC)

::I know as a fact there is some serious debate over not using Wikidata for these things. The details escape me but it's didn't seem resolved last I checked. It is easy enough to add the image manually, so I would say we should continue to add the image manually. JLJ001 (talk) 13:55, 30 May 2018 (UTC)

Purging the page is cludgy. What would it take for the user to be able to click "next picture", and the picture instantly appears in the selected picture section?    — The Transhumanist   21:14, 27 May 2018 (UTC)

• This is already possible. See Help:Gallery tag & MW:Help:Images. Basically you need to enable a gallery in mode="slideshow" JLJ001 (talk) 18:38, 28 May 2018 (UTC)

{{cot}}

Image:Astronotus_ocellatus.jpg|Astronotus ocellatus (Oscar)

Image:Salmonlarvakils.jpg|Salmo salar (Salmon Larva)

Image:Georgia Aquarium - Giant Grouper.jpg|Epinephelus lanceolatus (Giant grouper)

Image:Pterois volitans Manado-e.jpg|Pterois volitans (Red Lionfish)

Image:Macropodus opercularis - front (aka).jpg|Macropodus opercularis (Paradise fish)

Image:Canthigaster valentini 1.jpg|Canthigaster valentini (Valentinni's sharpnose puffer)

Image:Flughahn.jpg|25px Dactylopterus volitans (Flying gurnard)

Image:Fishmarket 01.jpg|Semicossyphus pulcher (California Sheephead)

Image:Pseudorasbora parva(edited version).jpg|Pseudorasbora parva (Topmouth gudgeon)

Image:MC Rotfeuerfisch.jpg|Pterois antennata (Antennata Lionfish)

Image:Cleaning station konan.jpg|Novaculichthys taeniourus

Image:Synchiropus splendidus 2 Luc Viatour.jpg|Synchiropus splendidus (Mandarin fish)

File:Psetta maxima Luc Viatour.jpg|Psetta maxima (Turbot)

File:Australian blenny.jpg|Ecsenius axelrodi

{{cob}}

• {{ping|Broter}} are you aware of this? It could be quite useful for the overall one page setup. JLJ001 (talk) 19:02, 28 May 2018 (UTC)

::It would be great if we could shuffle the list of images or make it so the first image shown is selected at random, rather than always displaying the first image in the list.

::It is possible to shuffle a list like so:

::{{#invoke:random|list

|sep=
}}

::But enclosing that output with ... does not produce the desired effect. WaggersTALK 07:18, 2 June 2018 (UTC)

:::You would need to use {{#tag}} syntax, see the bottom of mw:Help:Magic words. But it's probably better to make a new template rather using it directly. - Evad37 [talk] 07:50, 2 June 2018 (UTC)

::::{{ping|Waggers|The Transhumanist}} {{Done}}, see Template:Random slideshow - Evad37 [talk] 15:46, 3 June 2018 (UTC)

::::: {{ping|Evad37|Broter}} This template is awesome! I've tested it out on Portal:Sacramento, California. To emphasize it as a feature, I've changed the section name to "Picture slideshow".    — The Transhumanist   00:55, 6 June 2018 (UTC)

::::::Wonderful idea, but I am unable to get | width=nn% to work. 100% is just too big in a full width box, but dynamic sizing is a really desirable feature. What I would like most is a maximum size parameter, and dynamic sizing to 100% for box widths less than the maximum, so width and height would be less than maxsize=50em or whatever one chose, but as large as possible within that and the column width. Cheers, · · · Peter (Southwood) ^(talk): 17:31, 7 June 2018 (UTC)

The discussion above got me thinking and looking around a little more. As I am concerned about showing only high quality content for the selected image on a portal, specifically on Portal:Trains, I found that there are a few categories for Featured and Quality rail transport images on Commons, and linked to them on the candidates page. There are some pretty blatant gaps in the categorization (it seems the vast majority of the quality images categories show European subjects when there are plenty more of examples of quality images from the rest of the world), but this is a start. Because they don't present a comprehensive worldwide view of rail transport, these categories aren't enough to just make a random selection for the portal. They are a good start for a candidate suggestion when I update that section each week. What I would like is a template like {{tl|Random page in category}} that would show a random page from a category on Commons. Slambo (Speak) 12:11, 4 June 2018 (UTC)

Commons:Special:RandomInCategory doesn't appear to recurse subcategories or multiple category names at once. Slambo (Speak) 12:22, 4 June 2018 (UTC)

{{u|Evad37}}, this is amazing, and a major step in the right direction. Thank you!

I have couple questions/suggestions...

Is it possible to place the controls beneath the picture?

What does the middle doohickey do?

Could the size of the pictures be adjusted to the width of the frame?

Everybody, please post your comments and suggestions here. Thank you.    — The Transhumanist   02:19, 7 June 2018 (UTC)

:#Not easily, at least not on-wiki. The controls are generated by the gallery tag itself, so any changes would need to be requested on phab:Phabricator.

:#It toggles between slideshow mode and standard gallery mode the display of a standard gallery display below the slideshow

:#Possibly... would need to experiment with the outer {{tag|div|open}}'s CSS

:#:{{Done}}, this is now the default but other widths can still be specified - Evad37 [talk] 04:02, 7 June 2018 (UTC)

:- Evad37 [talk] 02:31, 7 June 2018 (UTC); updated 04:02, 7 June 2018 (UTC)

• That's an interesting feature, however it fails to credit the photographer and to provide a link to the most related article. --Mhhossein ^talk 06:50, 7 June 2018 (UTC)
• The captions are just wikitext, so you can fix it - Evad37 [talk] 07:25, 7 June 2018 (UTC)
• Plus credit is provided in the same way as every other image on Wikipedia, via the image description page shown by clicking on the image - Evad37 [talk] 07:28, 7 June 2018 (UTC)
• The navigation part is too wide for my width as I get the right arrow on a second line under the toggle thumbnails symbol. Also may be you could remove/reduce the white space under the image when not displaying the thumbnails. Keith D (talk) 10:32, 7 June 2018 (UTC)
• I've reduced the whitespace at the bottom, but there's not much we can do about the controls. I've reported the issue at phabricator:T196722. - Evad37 [talk] 05:10, 8 June 2018 (UTC)
• This looks great. One minor issue: when I change pictures, a thumbnail of the new picture appears briefly and the text below moves up, before the full size picture loads and everything flicks back into place. (I suspect the timing varies between seconds and too quick to notice, depending on internet speed.) Is there an easy way to fix that? Certes (talk) 23:42, 7 June 2018 (UTC)
• Again, not much we can do here. I've passed on your comments in phab:T196723 - Evad37 [talk] 05:19, 8 June 2018 (UTC)

The picture slideshow is a very cool tool and I’d love to incorporate this in a number of portals that I maintain.

However, I see the below shortcomings:

• Most portals prefer to separately highlight the photo credit, like it is done for the Featured Picture on the main page. In the current template, photo credit can be added to the description, if needed, but it does not stand out as a separate paragraph like the main page or how most portals currently do it.

:Suggestion: Can we have a separate field to put the photo credit? Even better if the template can automatically draw this from the image page if the field is left blank.

• Since the image names and descriptions are required to be input in the template itself, the complete volume of code for this template alone will be large when the number of images in the pool will be many. When this is going to be added to an already code-heavy portal page, the outcome would become difficult to manage and maintain.

:Suggestion: can we have the images, descriptions and credits in a fixed format in separate one or more archive page(s), from which the main template can draw in random fashion? Arman ^(Talk) 10:25, 10 June 2018 (UTC)

::First question: I'm not sure how difficult it would be to pull the data from the File: page. I suppose it would depend on if that data is accessible via Lua, in which case that functionality could be added to the module. {{ping|Evad37|Certes}} do you guys know if this is possible?

::Second question: I'm not sure if this template has the ability to draw from a list like some of the other ones do. You could just put the slideshow code on a subpage and transclude it into the relevant portal section if you need to keep the portal page size down. — AfroThundr ^{(u · t · c)} 13:11, 10 June 2018 (UTC)

::::That's a good suggestion AfroThundr3007730, I'll try that. Arman ^(Talk) 04:19, 11 June 2018 (UTC)

:::Lua can read the File: page. Module:Excerpt does so, to guess whether an image is non-free and hence might upset people if it appeared in a portal. The relevant code is at the end of function checkimage. Module:Excerpt also reads lists from subpages in a variety of ways, so that's also possible. I wonder if we should consider splitting Excerpt to produce a module of common utilities which can also be called from Module:Random slideshow and future developments. Certes (talk) 14:36, 10 June 2018 (UTC)

::::Lua can only see local file description pages, not ones on Commons. Which is fine for checking for non-free images, but won't work for the general case of extracting image information. - Evad37 [talk] 15:53, 10 June 2018 (UTC)

:{{ping|Armanaziz}} You can now specify credits using {{para|credit1}}, {{para|credit2}}, etc parameters. They will appear in small text below the the caption (as a separate paragraph) - Evad37 [talk] 15:48, 10 June 2018 (UTC)

::Great, will surely try. Arman ^(Talk) 04:19, 11 June 2018 (UTC)

:::Thank you folks - I have successfully implemented this feature in Portal:Bangladesh with excellent results. Arman ^(Talk) 09:21, 11 June 2018 (UTC)

I have a rather odd use-case, but it might apply to other groups of portals too. There are portals for each of the counties in South East England, and an over-arching South East England portal that pulls content from each of the county portals. {{t1|Transclude linked excerpt}} provides a great solution for selected articles and biographies, but I'm not sure I'd be able to get {{t1|Random slideshow}} to work in the same way for images; i.e. for each county portal to show a slideshow of images related to that county, and P:SEE to show a slideshow of all those images together (without having to duplicate the list). WaggersTALK 13:27, 11 June 2018 (UTC)

:{{ping|Waggers}} {{Done}}, see {{tl|Transclude files as random slideshow}}. It can work with any page that has images, so you could also specify a whole lot of articles to grab images from, and randomise into a slideshow gallery ({{ping|AfroThundr3007730|Certes|The Transhumanist|p=)}} - Evad37 [talk] 09:14, 12 June 2018 (UTC)

:: {{ping|Evad37}} Nice. What about captions?    — The Transhumanist   11:30, 12 June 2018 (UTC)

:::Captions are also transcluded (minus references, footnotes, and some templates). - Evad37 [talk] 12:00, 12 June 2018 (UTC)

::::{{ping|Evad37}} That's properly awesome, many thanks. I love that it can do multiple pages AND specific sections - so flexible! Will get that up and running on the portals I mentioned above very soon. WaggersTALK 14:52, 12 June 2018 (UTC)

If anyone is testing new image displays, Portal:Cenozoic might make a good test case. The entire portal has been nominated for deletion on the grounds that its picture is not visible. Certes (talk) 08:37, 16 June 2018 (UTC)

{{ping|Evad37|The Transhumanist|Certes|Pbsouthwood}} This is really great. Thank you for your work.

However, on the mobile site, or while using the mobile skin, the only thing that displays is the standard gallery without the slideshow. You can test this on [https://en.m.wikipedia.org/w/index.php?title=Portal:Cenozoic&mobileaction=toggle_view_mobile Portal:Cenozoic] or any portal that currently has the slideshow template. This also is even more of a problem if used in a selected article slideshow, as above. Is there any way to fix this on wiki, or would someone need to submit a Phabricator request? Greatedits¹ _{(I hope so | If not, let me know)} 19:34, 16 June 2018 (UTC)

:{{ping|Greatedits1}} I don't think there's anything we can do on-wiki. The

Is there a way for a computer program to fetch Did you know items based on subject?    — The Transhumanist   09:52, 25 April 2018 (UTC)

::If you had several of them as subpages of a portal, you could easily select one at random. But if you want to emulate the main DYK process, where the listed items specifically relate to new or updated content, then I'm not sure there's a straightforward way to do that without a fair chunk of manual maintenance. WaggersTALK 14:00, 25 April 2018 (UTC)

::: I'd want the new or updated content automatically placed on a subpage, so that it can cycle through the random generator along with the rest. Making and populating subpages by hand for 1500 portals would take years off your life. If we can figure out how to get the computer to do it, then we will still be young when the task is complete. :) `    — The Transhumanist   06:54, 27 April 2018 (UTC)

I think it should be possible (although I don't have the technical know-how to do it myself) to create a bot that would look for hooks with specific search words at T:DYK and copy them to a portal subpage. For each new hook it would also have to remove/archive the bottom one to keep the overall number of hooks constant. Perhaps it would be even feasible to check whether the new hook has an associated image and if it does, then replace the current hook-with-image on the subpage. This way, you would always have one hook with an image at the top and a constant number of others without.

A similar process could be implemented for an "in the news" section with blurbs copied from Portal:Current events (much better than Wikinews). What do you guys think? — Kpalion^(talk) 15:22, 26 April 2018 (UTC)

::How would you specify the search words for a given portal? · · · Peter (Southwood) ^(talk): 15:43, 26 April 2018 (UTC)

:::It might be easier for some portals than others. For Portal:Poland, to take an example that is familiar to me, "Poland" and "Polish" would be obvious choices (for "Polish" it would have to be case-specific, though). If you have doubts whether this would work, I've been doing this manually for nine years; if you look at Portal:Poland/Did you know/archive, you'll see that the vast majority of the hooks contain at least one of these two words. Of course, this could be further fine-tuned with time. — Kpalion^(talk) 15:55, 26 April 2018 (UTC)

:::Another thought: the bot would be looking at the wikicode, not the visible text, which means that it would be enough for the search term to appear in a piped link. You could also create a template (invisible to readers, but visible to the bot) to tag a DYK hook as pertaining to particular portal's topic and agree with member of the relevant wikiproject to remember to include the template in their DYK hooks (again, it might depend on the topic, but I believe in most cases wikiproject members would be the authors of most relevant hooks). — Kpalion^(talk) 16:08, 26 April 2018 (UTC)

::::Another possibility would be for the bot to examine the wikilinks in the hook and determine which categories the target articles are in, and add the book to the DYK page of portals related to that category. That in turns requiring a way of determining which portals are interested in which categories, but I would suggest managing a list of categories would be simpler and more accurate than managing a list of key words, and this approach doesn't require any hidden code to be added to the hook itself. WaggersTALK 09:40, 27 April 2018 (UTC)

:::::Yeah, that might work, especially if it were able to look at parent categories as well, although it would probably be slower (but likely still feasible). — Kpalion^(talk) 10:02, 27 April 2018 (UTC)

::::::Or it could look to see if the article is tagged by a particular WikiProject and use that to determine associated portals. I appreciate the relationship between portals and WikiProjects isn't always 1:1, but this could work for the majority of cases. WaggersTALK 11:51, 27 April 2018 (UTC)

:::::::Good idea! This actually would be the best solution. — Kpalion^(talk) 14:28, 27 April 2018 (UTC)

Other language Wikipedias have portals. The Spanish portals have Did you Know entries in them. I just copied some over. Can we mine those automatically? I copied/pasted them while in Chromium, which translated the whole page I was looking at. I copied them into subpage DYK/4 of Portal:Ancient Near East. That portal is set up with automatically rotating content.    — The Transhumanist   06:59, 27 April 2018 (UTC)

:But isn't the purpose of a DYK section to showcase the most recently created or expanded articles on the given topic? If so, then mining our own wikipedia's main page DYKs makes sense, but translating them from other wikipedias does not. And if not, then I don't know what other purpose it might have. — Kpalion^(talk) 08:52, 27 April 2018 (UTC)

:: I always thought they were interesting little tidbits. But you do have a good point: What's the point of presenting a factoid in a portal if it isn't included in the cited article?    — The Transhumanist   09:08, 27 April 2018 (UTC)

::In my view, every portal should do what they want on DYK, whether it is feeding off the main page DYK process, finding interesting stuff on other language Wikipedias or inventing their own wheel. Showcasing recent content or showcasing fun content or showcasing whatever should all be acceptable. (If we think of portals as mini-main pages, one of the great advantages they have over the real main page is the flexibility to try new things). For DYK bots, I would probably prefer something semi-automated: a bot that flags up candidates that I can then decide to paste into the portal DYK if I believe them to be appropriate. —Kusma (t·c) 09:26, 27 April 2018 (UTC)

:::Of course, it should be flexible. I was just talking about what makes most sense to me. I believe having a tool like this would be good, not that its use should be mandatory. It should be fairly easy to make the process either fully or semi-automated, depending on your preferences. The bot could copy the matching hooks to a page you specify; it could be a DYK subpage that is transcluded on the portal or it could be a proposal/waiting list that you could then use to select the hooks you want on your portal. — Kpalion^(talk) 09:50, 27 April 2018 (UTC)

Instead of creating portal subpages, is there any other way to put the DYK items as a numbered list in one archive page and the portal main page to draw items at random from that list? If currently there is no such way, can we develop that? This would eliminate the need of thoousand of portal "sub-pages". Arman ^(Talk) 10:06, 3 June 2018 (UTC)

:One solution could be to use {{User:JL-Bot/Project content|content-did-you-know-articles|category=…}} in its own section on a data page, then use {{tlx|Transclude linked excerpt|data page|section=header}} on the page where the random article is to appear. If you can link a concrete example of a portal that should do this, then I'm willing to have a go at setting it up as a model. Certes (talk) 10:41, 3 June 2018 (UTC)

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

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

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

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

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

= Discussions about portal-related templates =

{{notice|For discussion on template development, issues, etc.}}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

::::# Unmaintained portals (free game)

::::# Unique portals (probably maintained, don't touch)

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

::::# unique=n && maintained=n (free game for auto-editing)

::::# unique=y && maintained=n (edit with care)

::::# unique=y && maintained=y (don't touch)

::::# unique=n && maintained=y (probably don't touch)

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

:::* As for the category tagging via talk page banner, that is certainly possible. See [https://en.wikipedia.org/w/index.php?title=Template:WikiProject_Portals&type=revision&diff=843517761&oldid=843513771&diffmode=source this edit] to the Portal banner where {{u|Evad37}} added the historical flag for me.

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

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

{{dmf|Wikipedia talk:WikiProject Football#Portal templates affecting reflist templates}}

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

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

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

:::{{ping|The Transhumanist}} Thoughts? Kees08 (Talk) 17:45, 31 May 2018 (UTC)

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

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

{{Anchor|Template marking itself as historical}}

{{mdt|Template talk:WikiProject Portals#Template marking itself as historical|2=— AfroThundr ^{(u · t · c)} 02:05, 2 June 2018 (UTC)}}

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

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

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

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

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

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

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

:{{ping|The Transhumanist}} Yes. To prevent the subst: being processed on the template itself, put it within {{tag|includeonly}} tags. The only downside is that standard transclusion no longer works correctly (but that limitation can probably be overcome if necessary). See [https://en.wikipedia.org/w/index.php?title=User%3AEvad37%2Fsandbox&type=revision&diff=844507558&oldid=844182382], User:Evad37/X1, User:Evad37/X2 for examples. - Evad37 [talk] 11:28, 5 June 2018 (UTC)

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

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

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

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

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

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

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

These are the questions I want to start with:

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

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

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

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

This is now the current state of affairs:

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

{{fyi|1=Alternate discussion underway at TFD.}}

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

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

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

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

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

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

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

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

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

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

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

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

{{dmf|Template talk:WikiProject Portals#Portal flag integration}}

{{ping|Evad37}} First off, thanks for building that module. I have a couple questions and comments.

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

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

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

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

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

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

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

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

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

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

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

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

Issue raised in the TFD:

{{talkquote|text=

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

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

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

}}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

:: {{ping|Greatedits1|Pbsouthwood|Evad37}} Okay, I think I fixed it, with [https://en.wikipedia.org/w/index.php?title=Module:Random_portal_component&diff=844776098&oldid=844775297 this edit] to Module:Random portal component. Hopefully that doesn't cause other errors. :)    — The Transhumanist   02:53, 7 June 2018 (UTC)

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

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

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

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

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

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

{{cot|Resolved issues}}

{{ping|Certes|Evad37}}

In Portal:Geneva, the template isn't picking up the pics from the infobox in the lead of Geneva.

I'll keep posting 'em as I come across 'em. ;)    — The Transhumanist   06:12, 12 July 2018 (UTC)

{{done}}

{{tl|Transclude lead excerpt}} isn't picking up the map image from the infobox in Geography of Canada.    — The Transhumanist   06:43, 12 July 2018 (UTC)

{{done}}

This one isn't picking up the flag, seal, and location map from the infobox.    — The Transhumanist   06:48, 12 July 2018 (UTC)

{{done}}

This one picks up the flag, but not the seal or locator map.    — The Transhumanist   06:53, 12 July 2018 (UTC)

{{done}}

Same here. (Shows flag, but nothing else).    — The Transhumanist   06:55, 12 July 2018 (UTC)

{{done}}

Their portraits don't show up.    — The Transhumanist   06:57, 12 July 2018 (UTC)

{{done}}

Most of the pictures don't show up.    — The Transhumanist   07:00, 12 July 2018 (UTC)

{{done}}

No pictures show up.    — The Transhumanist   07:03, 12 July 2018 (UTC)

{{done}}

{{cob}}

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

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

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

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

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

{{ping|Certes|Evad37}}

Here's the excerpt:

::{{Transclude lead excerpt| Bohol | paragraphs=1 }}

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

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

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

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

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

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

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

{{ping|Certes|Evad37}}

This is a cool template.

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

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

I ran into a few issues...

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

For example, in the Environment section of the Outline of Dresden is the link

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

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

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

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

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

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

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

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

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

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

= Discussions about categories =

{{notice|For discussion on WikiProject categories and portal categorization in general.}}

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

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

= Discussions about specific portal technical issues =

{{notice|Exactly what it says on the tin. Post your specific technical issues here.}}

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

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

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

:Short answer: They were deleted.

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

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

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

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

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

{{dmf|Wikipedia_talk:WikiProject_Portals#Triage}}

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

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

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

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

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

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

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

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

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

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

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

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

:: {{ping|AfroThundr3007730|Pbsouthwood}} {{done}} Found the problem. First the Template:Numbered subpages is called, then this template calls the Module:Numbered_subpages, which has a line of code: frame:expandTemplate(title='subpage',args={i}) This then in turn calls Template:Subpage, which calls the /box-footer page (for the respective portal).

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

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

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

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

See Wikipedia:Village_pump_(technical)#Wikiproject_front_page_displaying_bizarrely

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

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

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

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

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

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

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

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

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

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

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

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

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

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

:::Pleasanton is a village

:::{{((}}convert|5|mi|km}}

:::from Famousville.

:::and unwanted templates:

:::Pleasanton is a village.

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

:::It is near Famousville.

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

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

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

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

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

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

:{{done}} · · · Peter (Southwood) ^(talk): 18:10, 18 June 2018 (UTC)

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

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

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

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

{{ping|Evad37|Certes}}

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

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

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

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

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

:::::Making the box size static is as simple as wrapping the {{tl|random slideshow}} template in

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

= Discussions about other technical issues =

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

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

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

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

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

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

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

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

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

:{{ping|AfroThundr3007730}} {{done}} - Evad37 [talk] 06:51, 18 June 2018 (UTC)

::{{ping|Evad37}} Thanks for that. I've made the necessary update to the portal now. {{ping|The Transhumanist}} there are currently a hair over [https://en.wikipedia.org/wiki/Special:WhatLinksHere/Template:Random_portal_component?hideredirs=1&hidelinks=1 a thousand] portals using {{tl|Random portal component}}. How would we go about triaging these for ones that already use a {{tl|box-header}} variant so we can update the random component box header to match? — AfroThundr ^{(u · t · c)} 12:16, 18 June 2018 (UTC)

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

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

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

: {{ping|AfroThundr3007730}} Removing all the box-footer subpages caused a problem with {{tl|Random portal component}}, and so its module had to be updated to use {{tl|Box-footer}} directly. See [https://en.wikipedia.org/w/index.php?title=Module:Random_portal_component&diff=844776098&oldid=844775297 this edit]. That's why the documentation is out of date. :)    — The Transhumanist   13:38, 18 June 2018 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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