WikiProject iconPortals  
WikiProject iconThis page is within the scope of WikiProject Portals, a collaborative effort to improve portals on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Project This page does not require a rating on the project's quality scale.
Note icon
See also: List of Portals


Discussions about possible cool new features

Please dream up new features, and post threads for them below...

How many articles does Wikipedia have on this subject?

How could we automatically generate the number of how many articles there are for the subject of a portal? So it can report: Wikipedia has "9,999 articles on geology", for example.    — The Transhumanist   21:14, 27 May 2018 (UTC)[reply]

Can we make portals talk with the user?

How far away are we from being able to do this? Are there resources that could be added to Wikipedia to facilitate this? If so, what are they?    — The Transhumanist   03:11, 28 May 2018 (UTC)[reply]

There was an IRC-style chat bot called I-God (or something), knocking about on the internet around 2005. You'd type something in and it would respond to you.

It probably used something like:

str = "Are you actually God?" /*Input */
if string.find(str, "God") then 
print "I am God, sacrifice your virgins" 
else 
print "I don't understand" 
end

Cesdeva (talk) 18:20, 28 May 2018 (UTC)[reply]

  • ahem. Yes well thankfully chatbots have progressed some since I-God. Using an IRC bot is a good idea, according to Wikipedia:IRC there is some kind of IRC setup associated with Wikipedia, but as far as I can tell it requires navigating off-site. We would need to embed it somehow. JLJ001 (talk) 18:29, 28 May 2018 (UTC)[reply]
If we hosted our own IRC we'd probably need moderators, or a very good way of filtering obsene and, most importantly, copyrighted content. Then there is dealing with lurkers who try privilege escalation. I think the Wikipedia associated IRCs are just various # on freenode, so maybe (as you said) we could embed one of those? Cesdeva (talk) 18:49, 28 May 2018 (UTC)[reply]
On reflection I think we would need substantially good reasons to get the devs to embed an external site into the software because of all the security issues, and notably the fact that nothing at presented is embedded at all. However the idea is still good, maybe we could have a bot written in Javascript and enabled via a page specific .js file, a bit like user js? I know pages can be made sort of interactive via things like jquery (ajax?), and this might be more compatible with the site. JLJ001 (talk) 18:56, 28 May 2018 (UTC)[reply]

What about portals that can read themselves out loud?

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

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

Transclude Did you know items from the WP:DYKA archives

In a similar way to ((transclude selected current events)). Maybe with some randomisation. - Evad37 [talk] 03:32, 28 May 2018 (UTC)[reply]

@Evad37: What about User:JL-Bot, in its JL-Bot 5 function, through use of the User:JL-Bot/Project content template, with the dyk-blurb= # parameter?    — The Transhumanist   05:05, 28 May 2018 (UTC)[reply]
That might work as an alternative, but it could get to be quite a lot of wikitext that gets added, e.g. Wikipedia:WikiProject Women in Red/DYK. Which isn't too bad for a subpage, from which a few entries are randomly transcluded to the portal, but I don't think its practical to have that much wikitext on a single-page portal. - Evad37 [talk] 15:23, 29 May 2018 (UTC)[reply]

Bot which scans for missing tags

A simple bot/script. You direct it at a category and it returns a list of pages not using a specified template. So if I input ((Portal|Suffolk)) as the template to search for, and Category:Suffolk as the category to search, the bot would search the category recursively and give me a list of pages which don't have the tag. JLJ001 (talk) 16:56, 28 May 2018 (UTC)[reply]

Automatic balancing of columns

Often, there is a lot of white space in one column because there is so much more in the opposite column. It would be nice if portals auto-adjusted for this. Any ideas on how?    — The Transhumanist   17:03, 28 May 2018 (UTC)[reply]

Portal sandboxes

@The Transhumanist: and others
Should we have some sandboxes attached to this WikiProject?

I'm losing track of the content in my sandboxes and it's not great having all this portal development marked as userspace edits. Cesdeva (talk) 18:34, 28 May 2018 (UTC)[reply]

Sandboxes are fine in the project namespace. I'm not sure what the ramifications are having them in the portal namespace. Thoughts?    — The Transhumanist   18:46, 28 May 2018 (UTC)[reply]
I'd guess it would mean adding another type of page for bots and quarry searches to avoid. Plus it would add to the 150,000+ total. I'm happy to just have a few in project space that we can use to share ideas and test things, Cesdeva (talk) 18:55, 28 May 2018 (UTC)[reply]
Shall we create Wikipedia:WikiProject Portals/sandbox, list it for some kind of 12 hour blanking bot, and see how we get on? Cesdeva (talk) 19:01, 28 May 2018 (UTC)[reply]
Seems fine, I assume we will end up with more. However on the subject of userpages I feel User:Wpgbrown/Portal Pages to Delete has a place as an official function. JLJ001 (talk) 19:27, 28 May 2018 (UTC)[reply]
I think we should treat Portal namespace as like the mainspace and ideally keep it free of anything not immediately usable. But project sandboxs seem fine. JLJ001 (talk) 19:00, 28 May 2018 (UTC)[reply]

Discussions about selective transclusion in intros

What's wrong with subportals?

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)[reply]

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)[reply]
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)[reply]
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)[reply]
@Pbsouthwood and 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)[reply]
@Bermicourt and 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)[reply]
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)[reply]
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)[reply]
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)[reply]

AWB team please tackle maintenance run on intro sections

Important: please read this whole section before getting started.

@Checkingfax, Dan Koehl, Emir of Wikipedia, Evad37, Iazyges, Mhhossein, Nick Moyes, Robertgombos, Samee, Vermont, Wpgbrown, User, , مصعب, JLJ001, and AfroThundr3007730:

I've called all of our AWB users here, because it is time to start applying AWB to the task of cleaning up the set of portals.

What we want to do here is obsolete the intro subpage of each portal, except for those portals listed under "Specific maintainers" on the WikiProject page. Those need to be handled more delicately, preferably by those who regularly maintain them. We're primarily interested in the vast majority of portals that have no regular maintainers. Most of those have been abandoned, and so we are going to automate them.

By "obsolete the subpage", I mean handle the intro entirely on the base portal page. Currently, most portals transclude an intro subpage that has a manually copied and pasted excerpt in there. Most of those haven't been updated in years, and have drifted somewhat from the text in the lead of the corresponding root article, resulting in a content-fork which is in many cases out of date or erroneous. We're going to replace that subpage transclusion with a selective transclusion of the live lead of the relevant root article directly on the portal base page, thus skipping the intro subpage.

The way to do that is with the ((Transclude lead excerpt)) template.

Note that some portals have already been upgraded in this regard, and so you will want to skip those.

After the intros have been automated, the intro subpages for those portals need to be tagged for speedy deletion (routine maintenance).

We want to leave the formatting on each portal intact. Almost all intros are included in a full-width section box at the top of the portal.

This discussion thread is for collaborating and coordinating. Work together, solve problems, ask and answer each other questions, and so on. Some may wish to discuss approaches, while others may start picking away at the task immediately. Beginners may want to watch this time around. When you run into obstacles, please talk them out here.

Don't be afraid to jump in and try something, as all mistakes are fixable.

Before starting, be sure to read the relevant discussion threads above and at /Archive 4#Discussions about selective transclusion in intros

Good luck, and have fun. Work together. Communicate.    — The Transhumanist   22:24, 28 May 2018 (UTC)[reply]

Got it! Robertgombos (talk) 22:27, 28 May 2018 (UTC)[reply]
If we were to use AWB to delete the '/Intro' pages, could we not directly tag them with G6, as the influx of speedy deletions cannot be handled easily by admins, as they have to delete each page individually. I would propose that editors who want to delete each '/Intro' page place it in this list or another suitable list. I, however, know that this cannot be easily done with AWB. Wpgbrown (talk) 22:30, 28 May 2018 (UTC)[reply]
Suggestion: We could run through all '/Intro' pages with AWB, replace the introduction with ((Transclude lead excerpt)) and then use something like the 'False Positives' Button to collate a list, where users can manually come through to: a) possibly check to see if the transclusion was appropriate and b) possibly move the new introduction to the main page (and delete the remaining redundant '/Intro' page). Wpgbrown (talk) 22:43, 28 May 2018 (UTC)[reply]
An AWB-friendly option is to tag the unwanted /Intro pages with ((G6temp)) and create that template by pasting from ((db-g6)). Then ask a friendly admin to delete the portal pages that link to ((G6temp)) as they would with G6 itself. Certes (talk) (Later edit: there is already a tag for this.) 22:44, 28 May 2018 (UTC)[reply]
We could do that (currently the admin Ansh666 has been very helpful deleting the pages on my list). However we would want to ensure that the introduction is actually on the main page before deletion. Is there a way we could move content to the main page using AWB first? Wpgbrown (talk) 22:48, 28 May 2018 (UTC)[reply]
I wouldn't worry about tagging the intro subpages for deletion until the intro sections on the portal base pages have been upgraded. Then you could use WP:SearchSuite and the insource parameter to create a list of all the portals that use ((Transclude lead excerpt)) and thus no longer need their intro base page.    — The Transhumanist   22:56, 28 May 2018 (UTC)[reply]
Ok. That sounds like a good idea. The idea of a list would allow a admin to to a D-Batch (with Twinkle) on the intro pages that are no longer needed. Wpgbrown (talk) 23:00, 28 May 2018 (UTC)[reply]
But bear in mind that some more complicated portals may use the intro page more than once (such as Portal:Africa), so we would need to ensure that the intro page is only deleted after the transclusion is placed on all of the pages (not just the main portal page). Wpgbrown (talk) 23:18, 28 May 2018 (UTC)[reply]
(edit conflict) Note that we don't want to apply transclusion in the intro pages, as those pages are going bye bye. Use ((Transclude lead excerpt)) directly on each portal's base page.    — The Transhumanist   22:52, 28 May 2018 (UTC)[reply]
(The Transhumanist's comment) The only problem with that is that we are left with a lot of intro subpages that we don't know if they are redundant or not (but I presume we could attempt to use 'What Links Here'). Unless we wanted to mark all the old intro pages as historical, it could get problematic if accidental deletions are carried out that are not noticed. Wpgbrown (talk) 22:56, 28 May 2018 (UTC)[reply]
On that note, there is already a tag for marking the page for G6 without putting it in the category and it is at User:JLJ001/tag. Note: This does not however place the page in any category, it is just a tag used to say what is going to happen with that page. An editor would manually add the page to a list or category for deletion. Wpgbrown (talk) 23:06, 28 May 2018 (UTC)[reply]

Concerning automated maintenance exclusions

a. You stated in your note: "So far, I've instructed the AWB'ers working on this task to not include the portals listed under the Specific Maintainers section in our project members list on the WikiProject page." I see no such instructions here. Where are they?
b. You further stated "But in case there are other portals besides these that are sensitive, perhaps you can help.". I would say that you should exclude for now all portals in Category:Featured portals and you should not make any changes without notifying the WikiProject whose banner appear of the portal talk page. And you should do this on the project's talk page, not simply on the portal talk page.
c. I have now formally listed myself as the Portal:Opera maintainer and I have reverted all the changes made to the portal yesterday. Amongst other things, our intro section has rotating images of famous opera houses as illustrations which had been eliminated when the "AWB team" changed Portal:Opera/Intro in addition to the main portal page.
d. The unwelcome and (in this case) inappropriate changes started within minutes of your "heads up" and in the middle of the night in the UK where I live, despite you stating in your note The reason I'm contacting you, is because you expressed concern over carte blanche automation of all portals". I am not happy. Especially after the "assurances" I received here when I raised serious concerns about this project and its perceived "mandate". It turns out those reassurances were completely empty. I will go into this issue in more detail below later today.
Voceditenore (talk) 06:38, 29 May 2018 (UTC)[reply]
@Voceditenore: Thank you for joining us. We definitely need editors who see things from various viewpoints, to point out potential pitfalls, which is why I notified you. We don't want to run blindfolded over a cliff. Sorry about the typo in the provided link; I'm glad you found the intended destination. In answer to your queries:
a. In the second paragraph at the top of this section: "What we want to do here is obsolete the intro subpage of each portal, except for those portals listed under "Specific maintainers" on the WikiProject page. Those need to be handled more delicately, preferably by those who regularly maintain them."
b. Keep in mind that time is of the essence. If we delay too long, we run the risk of another RfC proposal to delete. Also, if the task becomes too tedious and time-consuming due to walking on eggshells, we run the risk of losing our editing team out of sheer boredom or frustration. Avoiding the (176) featured portals, until their maintainers and attendant WikiProjects can be notified is reasonable. As for the rest of the portals without known maintainers, it is unreasonable to have to seek approval to work on those, as the vast majority of them have been abandoned or neglected. WikiProjects will be contacted as time allows, which is something we wish to do as part of our ongoing recruiting efforts as well. In the meantime, as the only major content we are actively replacing across the set of portals at this time are intro excerpts, reverting where necessary is a relatively simple straight-forward process. This will be our test case. Also, inspections of the subpages prior to migrating their functions could help to avoid overriding special features such as rotating pics. Thank you for pointing that out. As most of the intro subpages contain rather dated simple static excerpts, spotting anything more elaborate should be rather easy.
c. Thank you for joining the WikiProject. Your experience in portal development will be a great asset.
d. You were called in to provide reality checks, and we all appreciate your willingness to point things out. That edits are made isn't a problem as they can be reverted. So, there is no need to become distressed over changes that can be reversed. You can be happy, as we are we are willing to work with you, and we have the manpower and willingness to undue or otherwise solve any problems that we create. That's part of the beauty of a wiki, and part of the learning process. We are motivated to get things done quickly, but we also desire quality, and we don't believe there has to be a trade-off. The technology can be improved and adjusted as we go. Keep in mind that the assurances you received are backed up by a phase-by-phase development strategy. The main phase we are working on now is intro sections. Work across the set on other content sections such as Selected article, Selected picture, News, Did you know, and so on, will come later. So, while our effort is focused, so can be your concern. This serves as damage containment, and an opportunity to work out any differences we have in approach. By the time we move on to other content sections, our methods will be improved due to working together.
e. Note that work is also proceeding across the set on Associated Wikimedia (non-content) sections. Since this is based on a template ((Wikimedia for portals)), that can be improved further as desired, and adjusted via parameters, we were bold and moved forward with it without fanfare. Let us know if you have any ideas on improving the standard Associated Wikimedia section.
I hope my answers have helped alleviate any worries you may have. We look forward to your further feedback. Thank you. Sincerely,    — The Transhumanist   11:01, 29 May 2018 (UTC)[reply]
Thank you for your response The Transhumanist. I'm only partially re-assured by your comments, however. Despite saying that the assurances I had previously received "are backed up by a phase-by-phase development strategy", the first phase of this barrelled ahead and damaged Portal:Opera's presentation without any regard for what had been said before, despite it being a Featured Portal and apparently solely on the basis that I had not listed myself as the portal's maintainer on your project's page. Yes, I was able to revert those changes, but why should I have do that extra work? It took me a while to find out why despite reverting the change to the main portal page, the rotating images had completely disappeared. I am much more re-assured by JLJ001's quick response and practical solution of flagging articles which are either Featured Portals and/or have a named maintainer.
I understand and largely share your concern about the (probably 100s) of sub-standard/abandoned portals and the need to make some fairly rapid progress to avoid another RfC proposal to delete them all—good and bad. And yes, "walking on egg-shells" can potentially slow you down a bit, but the danger of becoming a walled garden operating in virtual isolation by not actively reaching out to WikiProjects about what this project is doing is the opposite side of that coin. As the Romans used to say festina lente. Voceditenore (talk) 16:19, 29 May 2018 (UTC)[reply]
@Voceditenore: We are working on a template to tag portals with that will prevent, among other things, accidental unwanted automated edits. Once we get it refined, we can ensure AWB activity doesn't touch portals marked with a flag such as wpport-autoedit=n or similar. — AfroThundr (tc) 16:56, 29 May 2018 (UTC)[reply]
@Voceditenore: More likely over a thousand. Walled gardens are another issue entirely, and one which you need not worry, as communications and recruiting are top priorities here. I've sent out hundreds of invitations so far, and posted thousands of notices, in the face of adversity, and it's only a matter of time before we can figure out 1) @Certes: how to make a list of all the WikiProjects with banners on the portal talk pages. The prospect of contacting them manually one-by-one is the only thing slowing us down there. 2) @Evad37: How to make a list of all the major contributors from the contributions of portals (the main problem being that most of the contributions to portals have taken place on subpages rather than base pages). Contributors will be easier to spot on the portals which are being converted to the new one-page design concept. To put your mind further at ease, transparency is also something we practice diligently: discussion archives are sorted by subject for ease of discovery, and to keep up with and monitor developments and intentions, you can find our Newsletter archive here. Also showing how seriously we take communications here, we also have a section on this talk page, for #Discussions about WikiProject communications. To top things off, we have a healthy team spirit. Please keep in mind that you were invited here specifically because of your concerns. We're all working together to achieve a worthy goal, and I hope you have discovered that the team is ready and willing to address all concerns conscientiously as they arise — and more certainly will, as we plunge forward into the unknown. I hope your are impressed. Sincerely,    — The Transhumanist   19:43, 29 May 2018 (UTC)[reply]
@The Transhumanist: Here is a list relating projects to portals. Some of the first few and last few entries look like rubbish but I think the rest is sound. There is a download button on the right. Certes (talk) 20:06, 29 May 2018 (UTC)[reply]
Yes. I've waffled vaguely about classifying portals before, but the time has come to mark each one clearly as "manually maintained; do not change", "revived portal; convert to standard format" and "other; edit with care". We're carrying out some good work, but there are pages on which it should not be done. (Later edit: see § New Markers.) Certes (talk) 09:24, 29 May 2018 (UTC)[reply]
When using that template on subpages it should be contained, tag subpages with <noinclude>((Maintained portal flag))</noinclude> so that the flag doesn't accidently transclude. I will make another one for the handle with care flag. JLJ001 (talk) 09:31, 29 May 2018 (UTC).[reply]
Thank you for that JLJ001. I am now in the process of flagging all the Portal:Opera sub-pages. Very laborious, but it appears there's no other way to avoid these unconstructive and still ill-thought out (in my view) changes. Sigh. Voceditenore (talk) 10:25, 29 May 2018 (UTC)[reply]
Someone can assist, with AWB, if you so desire.    — The Transhumanist   11:11, 29 May 2018 (UTC)[reply]
I did it with JWB. JLJ001 (talk) 15:00, 29 May 2018 (UTC)[reply]

We should use flags

I would suggest that AWB or other automated editing be restricted to only portals which are flagged for automation – apart from an initial run to add the flags, along with a talk page message explaining what the flag does and what to change it to in order to avoid future AWB/automated edits. (i.e. make it easy to both opt-in and opt-out.) - Evad37 [talk] 12:33, 29 May 2018 (UTC)[reply]

((nobots)) appears to render a couple of lines of whitespace, or maybe I'm using it wrong. Cesdeva (talk) 14:27, 29 May 2018 (UTC)[reply]
((nobots)) evaluates to the empty string, but if you add nobots on a new line of its own then you're adding line breaks around the template. Certes (talk) 14:50, 29 May 2018 (UTC)[reply]
I think nobots only works if directly in the source code of the page in question, I don't think it transcludes. But just in case it does, beware that it should not be used where any bot updated sections are used. JLJ001 (talk) 15:00, 29 May 2018 (UTC)[reply]

New Markers

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

Talk page instead. JLJ001 (talk) 20:41, 29 May 2018 (UTC)[reply]
This will be marked on the talk page instead. JLJ001 (talk) 13:52, 29 May 2018 (UTC)[reply]

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

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

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

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

Nice Cesdeva (talk) 11:35, 29 May 2018 (UTC)[reply]

Consolidate Them?

Perhaps it would be better to collapse these into a single template? Something like:
((Portal flag|maintained=y|standard=y|wpport-autoedit=y|subpages=y|subpage-keep=y))
Each of these flags should represent a single state/purpose and be set independently, which allows for more situations than mentioned above.
This is also more portable and would simplify management with a single template, that can be extended as needed. (We'll likely need to.) — AfroThundr (tc) 12:17, 29 May 2018 (UTC)[reply]
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 (tc) 12:19, 29 May 2018 (UTC)[reply]
They must be visible while loading the page in JWB, so although the talk pages may be tagged as well, the actual pages must have a visible template on them. The idea of having them all in a single template is good, but note that although they indicate the state, JWB & etc will match a string, so there must be a common string for excluding edits from it. I suggest we tag these additional parameters in another template just for the talk page. (eg ((Portal flag talk))) but retain the simple solution for bot/auto (in)exclusion. JLJ001 (talk) 12:27, 29 May 2018 (UTC)[reply]
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 (tc) 13:42, 29 May 2018 (UTC)[reply]
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)[reply]
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 (tc) 15:13, 29 May 2018 (UTC)[reply]
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)[reply]
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)[reply]
So subpages=y|subpage-keep=y then. Parameters are cheap. Updated the example above. — AfroThundr (tc) 15:17, 29 May 2018 (UTC)[reply]
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)[reply]

Template Fixes

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

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)[reply]
@JLJ001: Yes, I see that now, makes sense. Thanks for your swift action. Cactus.man 17:32, 29 May 2018 (UTC)[reply]
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)[reply]
@JLJ001: Just use ((ROOTPAGENAME)) instead - Evad37 [talk] 17:43, 29 May 2018 (UTC)[reply]
I should have checked the manual, ((ROOTPAGENAME)) is so much better. Thanks. JLJ001 (talk) 17:47, 29 May 2018 (UTC)[reply]

New maintenance categories

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)[reply]
  • Ok so if I get you, the main uses for those flags are:
  1. Unmaintained portals (free game)
  2. Unique portals (probably maintained, don't touch)
Any other scenarios I'm missing here? What about the case of unique yet unmaintained? Perhaps another use case for merging those templates and using parameters to record both states, you could have the icon change color if:
  1. unique=n && maintained=n (free game for auto-editing)
  2. unique=y && maintained=n (edit with care)
  3. unique=y && maintained=y (don't touch)
  4. unique=n && maintained=y (probably don't touch)
At least as far as auto-editing is concerned. Thoughts? — AfroThundr (tc) 20:25, 29 May 2018 (UTC)[reply]
  • As for the category tagging via talk page banner, that is certainly possible. See this edit to the Portal banner where Evad37 added the historical flag for me.
Using this method, we could add a flag for subpage retention, and whatever else we might need for portal tagging. — AfroThundr (tc) 20:26, 29 May 2018 (UTC)[reply]

Use Wikidata for image

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)[reply]

The templates do not currently find images from within ((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)[reply]
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)[reply]

Discussions about selected article sections

Semi-automating the importing of article titles

@Certes, Evad37, Slambo, Waggers, Pbsouthwood, Galobtter, Redrose64, Johnuniq, GreenC, JLJ001, and AfroThundr3007730: It was established in Wikipedia talk:WikiProject Portals/Archive 4#Listing category members in a module or template that importing names from a category from within a lua module is not possible at this time. So, how can we do this by user script? We need a tool that an editor can use so he/she doesn't have to copy/paste the article names by hand into the template on the portal base page. JWB fetches titles from a category, so it should be fairly straight-forward (however, JWB's source is still Greek to me and I can't fathom how it does it). We need a script that fetches the titles from a category prompted from the user, with a default of the subject of the portal, and then inserts a ((Transclude random excerpt)) template on the portal base page with those titles included as parameters in the template. I very much look forward to your replies. Sincerely,    — The Transhumanist   02:58, 28 May 2018 (UTC)[reply]

JavaScript is outside my area but it would be useful to provide an example, possibly in a sandbox. That is, a sample category name and a manually compiled list of article titles (links not needed), and the resulting excerpt template. What limit should be placed on the number of articles? Will excerpt work with that many? Johnuniq (talk) 03:49, 28 May 2018 (UTC)[reply]
Anyone writing a client can use their favourite language. If you choose JavaScript, User:Joeytje50/JWB.js may be a good model, especially function JWB.pl.generate. The API has a categorytree function which returns a list of pages as labyrinthine HTML; perhaps there is an option to use a more helpful format. Alternatively, mw:API:Query has a categorymembers function: example here. This query only returns the first few pages (see here for how to "continue") and probably excludes subcategories. The API sandbox may be useful. Certes (talk) 10:58, 28 May 2018 (UTC)[reply]
This might have alternative uses for creating outline and index lists. Consider getting the short description at the same time to use as a link annotation as an option. An outline list section could be a source for randomised lead transclusions. · · · Peter (Southwood) (talk): 11:46, 28 May 2018 (UTC)[reply]
The other side of this is that outline lists may be a useful source of page lists grouped in a similar way to categories, but maybe already directly readable by a Lua module. · · · Peter (Southwood) (talk): 14:29, 28 May 2018 (UTC)[reply]
@Pbsouthwood, Evad37, and Certes: What? You definitely have my attention. Are lists in outlines directly readable by a Lua module? And can those lists be inserted by Lua as a bunch of parameters in ((Transclude random excerpt))?    — The Transhumanist   03:33, 30 May 2018 (UTC)[reply]
I don't know the capabilities of Lua. I was speculating that it might be possible and don't yet know of a reason why it would not. Evad37 or Certes may know more, or my usual go-to guy for templates and Lua questions RexxS may be kind enough to venture an opinion. Using an outline list as a skeleton for a portal could allow a high level of automation, but it would require a well-constructed outline, which is also a good thing to have. It may also require some constraints on outline list formatting to work well. I dream of a module that would construct a whole portal using an outline list title as input, with a few added parameters to adjust display and other options, though probably not this week.... · · · Peter (Southwood) (talk): 05:09, 30 May 2018 (UTC)[reply]

Yes, it should be possible for a lua module to parse the wikitext of an index/outline page, extract the links, and pass them through to random excerpt module. - Evad37 [talk] 06:51, 30 May 2018 (UTC)[reply]

This is definitely worth doing, but I can't say I have any solid solutions yet. JLJ001 (talk) 11:59, 28 May 2018 (UTC)[reply]
@Johnuniq: For example, here are a couple portals that were saved from MfD by expanding them with a list of articles provided as parameters for instances of ((Transclude random excerpt)), the first by not that many, and the second by considerably more: Portal:Quidditch & Portal:Juanes.    — The Transhumanist   06:30, 29 May 2018 (UTC)[reply]
Perhaps we need ((Transclude linked excerpt|Somepage)) to show an excerpt from a page chosen randomly from those linked from Somepage. Replacing Somepage by Outline of geography (the first search suggestion for "outline of") might get us an excerpt from Outline (list) or Discipline (academia), neither of which are relevant. Heuristics such as excluding the lead and only considering the first wikilink on each line might help but wouldn't work everywhere. I think Somepage needs to be a new list in portal space. An editor can create that page manually using their skill and judgement, which may be as simple as copy-pasting Outline of … with the irrelevant links removed. Alternatively, a bot can maintain the page as a list of articles in one or more related categories. That should give us the flexibility we need for most portals. Does that work? Certes (talk) 10:05, 30 May 2018 (UTC)[reply]
+1 I like it. JLJ001 (talk) 10:10, 30 May 2018 (UTC)[reply]

Discussions about selected picture sections

How can we automate this?

Any ideas of how to automate this without relying on Commons categories, which are often not very reliable? Images already used in topic articles could be used as a stockpile, but often an image is meaningless when displayed in isolation, and the caption from the article is intended for use in the context of the article. Alt text may be useful in those rare cases where it exists, but I doubt there are enough of them to be worth considering as a default method. · · · Peter (Southwood) (talk): 05:21, 26 April 2018 (UTC)[reply]

Hello, in the Spanish-language Wikipedia I use a similar method to article selections, where each image is included in separate page (see here). It's not the most practical to create, but it works fine.
Also, the image template of the sports portal reuses the same image templates of the sports subportals (see here). This guarantees that all sports and regions get a chance at appearing at the main portal. --NaBUru38 (talk) 23:24, 28 April 2018 (UTC)[reply]

We need a template to display multiple pictures

@Certes, Evad37, Slambo, Waggers, Pbsouthwood, and Galobtter: To automate the selected pictures section of portals, it looks like we will need a template that displays random pictures. Kind of like what ((Transclude random excerpt)) does for excerpts. Does anything like this already exist? If not, what are the issues that need to be overcome? What details do you need to be able to write it? Will it require a lua module? I very much look forward to your replies. Sincerely,    — The Transhumanist   02:05, 28 May 2018 (UTC)[reply]

That sounds easy, but then so did excerpts. The devil will be in the detail such as getting the sizing right, copyright issues, and handling the myriad of arcane ways in which a minority of images can be stored in a way that differs subtly from the norm. Certes (talk) 11:01, 28 May 2018 (UTC)[reply]
I am using a rudimentary arrangement for random selected picture in Portal:Underwater diving based on ((#invoke:random|item |[[File:filename1|thumb|upright=1.4|center]]<center> caption1 </center> |[[File:filename2|thumb|upright=1.4|center]]<center> caption2 </center> etc... )) which does the job but requires manual input of the file name and caption parameters. · · · Peter (Southwood) (talk): 15:38, 28 May 2018 (UTC)[reply]
One of the difficult details is that of image quality (i.e. is properly exposed, is level, is well composed). I am a professional photographer, so my personal quality standards for photography are a little higher than the average reader. There is a huge number of photos relating to rail transport worldwide that are of poor quality and not suitable for use as the selected picture on the portal. An exceptionally small number of rail transport photos are marked as quality photos or better on Commons. Also, I sometimes select an image from the rail transport in art categories to show as the selected image on the portal, so more than just photography needs to be included. Until there is a large enough pool of quality images that are mechanically identifiable, random selection isn't really a viable option. Slambo (Speak) 16:27, 28 May 2018 (UTC)[reply]
I imagine there must a bot somewhere that can analyse a histogram to see if there is over-exposure/blow out. That would thin the field a bit. Cesdeva (talk) 16:47, 28 May 2018 (UTC)[reply]
Relying on the histogram doesn't help much if it is a naturally high-key image, such as a white train in a snow scene, or a low-key image like dark colored train (like the majority of steam locomotives) at a poorly-lit underground station platform. There are excellent photos that would fail a histogram check. I haven't seen a system that could automate this kind of check, let alone one for composition or level horizons, reliably. Slambo (Speak) 03:00, 29 May 2018 (UTC)[reply]
@Slambo: With ((Transclude random excerpt)), you enter the names of the articles you want to rotate through, and it randomly selects one of those for display. That makes it only semi-automated, I guess, but I'm looking for a similar solution for pictures, where the portal builder adds the names of the images to be displayed. We can work on full automation later.    — The Transhumanist   17:09, 28 May 2018 (UTC)[reply]
What happens if the file name it selects is for a file that was deleted? Also, there are so many railroad photos uploaded constantly, many of them meeting my standards for minimum quality, that it seems there would be even more work to get such a random selection going and maintained than it is to just pick one myself each week (which also lets me ensure that photos from railways around the world are more fairly represented). Slambo (Speak) 03:00, 29 May 2018 (UTC)[reply]
If ((Transclude random excerpt)) finds a deleted article, it picks another random number and tries again. An image template could do likewise. There are two cases here. Portals where someone is willing to pick a page weekly don't need any overcomplicated template nonsense; they can just use [[File:…]]. Other portals, which we need to edit once then forget, would benefit from a random image generator, with a hard-coded carousel set up manually as a one-off task. A proposed program discussed above could be extended to find good pictures and format their names into a template call. Certes (talk) 09:45, 29 May 2018 (UTC)[reply]

I'm after something similar for PortalButton. Multiple templates can form a nice gallery, but can only take manual input of file names. I'd really like to code a default ratio of div width:image width into the template too. Cesdeva (talk) 16:31, 28 May 2018 (UTC):[reply]

What would be needed to implement a slideshow feature?

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)[reply]

Extended content

Discussions about news sections

Alternative to Wikinews

Is there any option other than wikinews to fill news sections? Wikinews is useless, they don't supply anything except football updates and articles from a decade ago. JLJ001 (talk) 11:34, 22 May 2018 (UTC)[reply]

The daily pages of P:CE are another source of news items, but I don't how you could automate the updating of news sections. - Evad37 [talk] 12:19, 22 May 2018 (UTC)[reply]
@Certes: Do you think a module do could selective transclusion of bullet points from the monthly pages (e.g. Portal:Current events/May 2018) or the daily pages (e.g. Portal:Current events/2018 May 21), keeping only those that contain keywords supplied via a template parameter? - Evad37 [talk] 12:29, 22 May 2018 (UTC)[reply]
I've been experimenting with Module:Sandbox/Evad37/Current events and it is possible, see User:Evad37/Sandbox 2 for the results. (Note that this isn't ready to be used in real portals; it may break suddenly or require syntax changes as I further develop the module) - Evad37 [talk]
This gave very good results on my pet portal topic, hope you will go public with it soon!: Noyster (talk), 19:40, 22 May 2018 (UTC)[reply]
 Done @JLJ001, Noyster, and The Transhumanist: ((Transclude selected current events)) is ready to be tested in some actual portals. Let me know if you need help with the search patterns. - Evad37 [talk] 02:37, 23 May 2018 (UTC)[reply]
I am very impressed. I already installed it at Portal:United Kingdom. JLJ001 (talk) 07:43, 23 May 2018 (UTC)[reply]
This is the best portal innovation since sliced bread! Compare the news section of Portal:Spain with what we had before: Noyster (talk), 07:46, 23 May 2018 (UTC)[reply]
This is a great idea. But I think the results should be organised as groups going all the way up to the top level bullet point. One problem is that the leading bullet point can often vanish. For instance, looking at "United States", "America" for 24 May, the links to Harvey Weinstein sexual abuse allegations and 2018 Atlantic hurricane season don't appear; these are the most important links for those stories. Moreover, no results are found for the leading bullet point. "Malaysia" and "bombing" don't surface the Malaysia Airlines Flight 17 and Mississauga restaurant bombing stories because the keywords don't appear in the 2nd level bullet point text. The latter kayword also exposes another issue; there's a result that says "12 May 2018 – A low turnout is reported, but no bombings at polling stations. (AP via The Spokesman Review)" with no context for that statement (except the link).

I think the results should look like and display this:

"United States" "America"

24 May 2018

24 May 2018

"Malaysia"

24 May 2018

"bombing"

24 May 2018

12 May 2018

Instead of:

"United States" "America"

"Malaysia"

Nothing

"bombing"

 Fixed, though I put the date and "heading" item on the same line to save some space - Evad37 [talk] 10:41, 29 May 2018 (UTC)[reply]
I had doubts about this change, but yes it seems fine. (viewed on Portal:United Kingdom). JLJ001 (talk) 11:02, 29 May 2018 (UTC)[reply]

Discussions about did you know sections

Is there a way to automate Did you know sections?

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)[reply]

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)[reply]
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)[reply]


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)[reply]

How would you specify the search words for a given portal? · · · Peter (Southwood) (talk): 15:43, 26 April 2018 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Good idea! This actually would be the best solution. — Kpalion(talk) 14:28, 27 April 2018 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]

Did you know style

I was surprised at first about the citations policy, but now that I understand that the portals are meant to draw in readership, I am curious whether there is a 'Did you Know'-style to be followed. --Ancheta Wis   (talk | contribs) 03:52, 25 April 2018 (UTC)[reply]

I don't know what you are referring to when you say you were surprised. What surprised you?
The style is exactly the same as that used for the Main page. See Wikipedia:Did you know.
We will be attempting to develop an automated way of doing the Did you know section. Then there will probably be a template syntax to follow, to skip copying & pasting.    — The Transhumanist   10:11, 25 April 2018 (UTC)[reply]
I played with some of the older tech/styles a while back and made my user page up like a simple "portal" and included a rotating "did you know" section. Check it out.--Paul McDonald (talk) 16:00, 25 April 2018 (UTC)[reply]
Hello, Wikipedia:Did you know states that some of the gools are to "showcase new and improved content" and to "acknowledge the work that editors do to expand and improve Wikipedia". I strongly disagree with that. There are better ways to promote new edits. The DYK at portals should focus on presenting interesting facts to readers. --NaBUru38 (talk) 23:29, 28 April 2018 (UTC)[reply]

Discussions about portal page layouts

Another option for portal layout

I'd like to call your attention to Portal:Nanotechnology, which I designed with a distinct visual style. The portal uses Template:Voyage box, so named because it's loosely inspired by Wikivoyage's Main Page layout. Please feel free to use the template to lay out your own portals if you choose. Antony–22 (talkcontribs) 10:06, 19 May 2018 (UTC)[reply]

Discussions about one-page portal designs

Moving towards the one-page portal

Independently of Broter, I have reconstructed Portal:Underwater diving as a nearly one-page portal. It also only calls subpages /Boxheader, /Boxfooter and /Opentask. The effects are very similar to Broter's work

I would like to make new templates for Boxheader and Boxfooter which take the background and foreground colours as parameters, so they can be used for all portals. It would also be good to standardise on a set of colour schemes that are properly accessible to international standards, which could reduce to only one parameter.

The Opentask page should come from the relevant WikiProject, to avoid duplication. This would reduce the portal to a single page.

I use a slightly different system to randomise selected items, which I think is easier to use and allows more tweaking, but takes a bit more space. Comments and suggestions welcome Cheers, · · · Peter (Southwood) (talk): 07:57, 16 May 2018 (UTC)[reply]

I am also experimenting with a randomised banner header based on the system used on Wikivoyage and my user page. It provides a little extra related information, but mostly looks pretty. If anyone else decides to try this, the standard for banners on Wikitravel is maximum resolution, exactly 1:7 aspect ratio. I recommend sticking to that as it allows cross project use where applicable. I want to get the page name to display over the banner, and a ToC could be added for the boxed sections, displayed as on Wikivoyage. The coding should all be available at Wikivoyage, but the main template has some dependencies I don't follow. My coding is a bit of a kludge, but works well enough for demo purposes. · · · Peter (Southwood) (talk): 08:08, 16 May 2018 (UTC)[reply]

I have now bypassed the /Box-header and /Box-footer subpages. The only subpage left is /Opentask, which will be moved to a subpage of the WikiProject. · · · Peter (Southwood) (talk): 12:56, 16 May 2018 (UTC)[reply]

Opentask now superseded by a "To do" subpage of the project, which admittedly needs some formatting work. Now a one-page portal · · · Peter (Southwood) (talk): 08:41, 17 May 2018 (UTC)[reply]

Dead simple portal

I have been experimenting with a simple way of creating a single page portal from scratch. And in doing so I have developed Template:Dead simple portal. This template allows anyone with good wikitext coding skills to create a single-page portal by subst-ing the template. I have tested it, and while not perfected yet, I made Portal:Sark and Portal:Norfolk with it. JLJ001 (talk) 00:12, 22 May 2018 (UTC)[reply]

Discussions about building new portals

On random editors starting new Portals

User:The Transhumanist,

you wrote:

@SmokeyJoe and Paulmcdonald: Approval, by whom? As with other departments, such a page would be facilitated by a few regulars, and so bias always sets in. One was set up, sort of, with dismal results. They denied approval to an editor who wanted to create the cannabis portal, so I advised him to create it anyways. The department also turned into a bottleneck and created a hoop-jumping exercise. Many editors decided not to create any portals because of it. I mentioned "sort of", because it was suggestive only. We can't censor Wikipedia, but we can delete material that doesn't follow Wikipedia content policies. Because of the way the department was portrayed, people were under the impression that approval was required, but it wasn't. The only requirement for creating a page on Wikipedia is clicking the "edit" or "create" tab. The same thing applies to draft space and WP:AfC: they're optional. "Wasn't approved" is not a valid argument at the deletion departments. Wikipedia has developed into the wonderful resource that it is, because people are allowed to take the initiative - it is the core defining principal of the Wiki model and what makes it work. We don't wish to dowse the creative spark. Also, you sometimes don't know if something is going to work until you try it. If a portal proves to be inviable, it can be deleted. I like the deletion system, because it has a good cross-section of involved editors. An approval department is more like a hidden cabal (closed forum). Who do you invite to the discussions? With deletions, that's obvious: the creator and major contributors. But, with a page that hasn't been created yet, you don't know who the major contributors would be. The current system works fine. If it ain't broke, don't fix it. — The Transhumanist 22:30, 3 May 2018 (UTC)

Some good important points. The WikiProject Council is not very active, I would call it haphazard. Requiring approval there might just be a net non-positive bottleneck until a random anybody says "yes". Portals would be the same.
"Approval" is probably too strong a word. It begs "approval by who", suggests there is a committee, bureaucracy, yes TT, probably hopeless.
What I generally favour in many things is that a "second pair of eyes" be involved, minimally and sufficiently, in starting up any new little bureaucratic process. This includes RfCs, WikiProjects, Portals. The "second pair of eyes" is not intended to be an explicit supporter or author, but a check of sanity, technicalities. Someone proposes something (or in practice starts something), and then a second experienced Wikipedian in good standing says "yes, go ahead". Disputes, if experienced Wikipedians in good standing disagree, can go through WP:DR, or even MfD if the thing created is completely a bad idea. This would mean that someone like you can give immediate approval to anyone else, but you can't so easily stop a pair of Wikipedians proceeding with an ill-advised bad idea.
An even softer idea would be to write into instructions something like this:
It would then be up to the watchers of these pages to choose to offer advice.

> "If it ain't broke, don't fix it"?

It is my opinion, having seen them come to MfD for years, that there are plenty of ill-advised WikiProjects and Portals, and their existence adds disrepute to the rest.

--SmokeyJoe (talk) 23:48, 3 May 2018 (UTC)[reply]

And that's why we clean them up. The main problem has been an inactive WikiProject. Keep it going strong, and you'll have the editors you need to monitor and maintain the whole system.
I like your idea of reporting new portals. There could be a section for them to be listed on the WikiProject page. That way, their development could be monitored for quality and even joined by editors who wish to make them better. Finding them is a little tricky, but can be done comparing lists using AWB's list compare feature.    — The Transhumanist   00:09, 4 May 2018 (UTC)[reply]
I suggest: A list of portals, a sortable table, columns including Portal name, Parent portal (often occurs), date started, first author, current activity level.
"Current activity level"? It would be great if this were auto-reported. What would it measure? Last manual edit? Last auto-whatever? Number of page views in the last 30 days?
--SmokeyJoe (talk) 00:19, 4 May 2018 (UTC)[reply]
We tried that. Editors would edit it once, and then that entry would never be updated again. It became horribly out-of-date. And, it was redundant with Portal:Contents/Portals. List tools make it easier to track portals. SearchSuite can list all the base pages, and then you can use AWB to compare with an earlier version to find all the new ones.    — The Transhumanist   01:29, 4 May 2018 (UTC)[reply]
That's how I think it should work. Filled in once at the start, some fields auto-updating. --SmokeyJoe (talk) 02:04, 4 May 2018 (UTC)[reply]

My memory was fuzzy on this issue, so I went looking around to refresh my recall...

Portals approval department: rejected by the community

SmokeyJoe wrote: I don’t believe that Portals or WikiProjects should be allowed to be created unilaterally, without approval. For WikiProjects, there is an approval process somewhere under Wikipedia:WikiProject Council. I think a Portal creation board should exist. Does it? —SmokeyJoe (talk) 05:34, 29 April 2018 (UTC)[reply]

It took me awhile to recall the history on this, for portals. There was an approval department at Wikipedia:Portal/Proposals, but it got rejected by the community at Wikipedia:Miscellany for deletion/Wikipedia:Portal/Proposals, at my request. Some guy created the Portal:Cannabis, while I created the Portal:Thinking, both of which were nominated for deletion; Cannabis for having been previously rejected (see Wikipedia:Miscellany for deletion/Portal:Cannabis), and Thinking for not going through the approval process at all (see Wikipedia:Miscellany for deletion/Portal:Thinking). I was appalled that a page could be deleted before it was even created, so I nominated the process itself for deletion. It was marked "historical" and "rejected by the community".    — The Transhumanist   01:29, 4 May 2018 (UTC)[reply]
"I don’t believe that Portals or WikiProjects should be allowed to be created unilaterally, without approval." Backing back a but from that. Reporting would be OK. --SmokeyJoe (talk) 02:04, 4 May 2018 (UTC)[reply]
I agree. Keeping track of what portals we have, so we can look at them, would be good.    — The Transhumanist   02:47, 4 May 2018 (UTC)[reply]
On German Wiki, unless a portal topic falls under the various categories of 'relevance' (see for a translation), the creator has to garner support first. I think they have to have 3 'overseers' (i.e. maintainers) and a majority of 10 'supporters' on the approvals page i.e. 12 'support' votes and 2 'oppose' votes gets it through the process but 12 and 3 fails. I'm not saying we should clone that, but it's a less formal approach than a 'Portal Creation Board' and more in line with other Wiki processes and we might want to think about something similar. Otherwise we'll have portals for everything and it's already a challenge to manage them all. Bermicourt (talk) 14:44, 4 May 2018 (UTC)[reply]
If we can make them automatically dynamically self-updating, it won't take many editors to maintain them.    — The Transhumanist   04:34, 6 May 2018 (UTC)[reply]
For those interested on this discussion, I also initiated a related discussion here. In my opinion we need some minimum relevance/notability criteria or approval process. A portal on a narrow topic (like an individual person, or a specific video game, or a specific movie) - where the main article itself is not yet a featured aricle - should be discouraged and the editors should be encouraged to focus on improving the core article first. Arman (Talk) 10:35, 6 May 2018 (UTC)[reply]
I think creating a set of guidelines would be good. For example, a portal should be about a broad enough topic to have at least 50 (or maybe 100) or so articles that could be included in the portal. If it doesn't have that many, it's not really worth the effort to create the portal as just visiting the main topic would likely give you enough information and/or links to relevant related articles.
I reject any notion of requiring approval to create one. That's just a layer of bureaucracy. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 20:23, 18 May 2018 (UTC)[reply]
I agree with the idea of guidelines and translated German Wiki's guidelines to see what they said. They've kept a lid on portals by requiring evidence that the portal will be maintained (which it will need if it's more than a showcase page and is being used e.g. to support WikiProjects) and strong support from around a dozen editors. So it's not an approval committee, but does reduce the likelihood of someone creating a half-finished portal on a non-notable topic area, which seems to have happened on English Wikipedia. Bermicourt (talk) 21:14, 18 May 2018 (UTC)[reply]


Discussions about portal namespace cleanup

Should we delete all redundant Portal Introduction pages?

I want to get a consensus on whether after migrating the information from a /Intro page to the portal main page, the /Intro page should be marked as Historical or should the page be deleted under ((Db-g6))? I have been marking for G6 speedy deletion, but others are marking the pages as historical. Should I continue marking for deletion? Wpgbrown (talk) 10:00, 25 May 2018 (UTC)[reply]

Whenever the content was not absolutely identical to the article it should be marked as historical, just in case the person who made the portal comes back and complains their custom portal intro was deleted. But in most cases they are simple content forks and should be tagged ((Db-g6)). JLJ001 (talk) 10:12, 25 May 2018 (UTC)[reply]
I have been tagging with ((Portal subpage status)) myself in some cases. JLJ001 (talk) 10:13, 25 May 2018 (UTC)[reply]

Suggestion for Portal page deletions

Hi there, thanks for cleaning these out. It might be easier if you maintain a list of checked pages that can be deleted at once with Twinkle's batch delete, especially since nobody is going to see them. That way, you don't have to tag every one of them, and whoever deletes them won't have to click through to every page either. Thanks for your work, ansh666 01:40, 27 May 2018 (UTC)[reply]

@Ansh666: Ok. Would I do this by creating a MfD or create something different that allows me to say they are all tagged under Db-g6? Thanks Wpgbrown (talk) 08:14, 27 May 2018 (UTC)[reply]
No, MfD's not necessary, just a user subpage or something linking to all the pages that are to be deleted. Once you're done or get to a certain break point (say, you've gone through all the portals that start with the letter C), you can just let me or another admin know, or post at AN asking someone to deal with it (and if anyone questions it, point them to my comments here; I've seen enough of your tags to say that you don't really make mistakes). Of course, if this sounds too messy or complicated, the normal way of just tagging all the pages works perfectly fine. Thanks, ansh666 08:47, 27 May 2018 (UTC)[reply]
Thanks for your advice, I have created the page (see here) and will notify an admin when I reach enough subpages. Wpgbrown (talk) 08:57, 27 May 2018 (UTC)[reply]
Wpgbrown. Thanks for the message, I will probably add some more to your list because it is convenient idea. JLJ001 (talk) 13:20, 27 May 2018 (UTC)[reply]
Done, thanks. ansh666 21:22, 27 May 2018 (UTC)[reply]
@Ansh666: I have 190 subpages that are up for deletion (I have also double checked them), could you run D-Batch on them? Wpgbrown (talk) 19:03, 28 May 2018 (UTC)[reply]
Got em! ansh666 20:36, 28 May 2018 (UTC)[reply]

Discussions about WikiProject communications

Fixing article alerts

Copied from Wikipedia talk:WikiProject Portals/Article alerts#Re: Old Featured Portal Nominations

@The Transhumanist: Featured Portal nominations are one of the workflows that AAlertBot watches for when generating article alerts. If you're wondering why those old Featured Portal nominations keep appearing, it's because their talk pages still have the ((FPOC)) template. Those three portals are actually the only ones using that template. Perhaps we should remove it? This would probably be best since they are no longer candidates, as all three nominations failed. — AfroThundr (tc) 01:05, 25 May 2018 (UTC)[reply]

@Evad37: Thank you, AfroThundr for tracking this down. Yes, removing those would ensure that they don't appear again, even if we start up featured portals again. Evad37 came up with another solution as well (removing the featured portal workflow). See User_talk:Evad37#You_are_invited_to_join.... Thanks to both of you, for a complete solution.    — The Transhumanist   04:15, 25 May 2018 (UTC)[reply]
Copied from User talk:Evad37...
@The Transhumanist: This edit[2] should fix the article alerts problem, by telling the bot only to care about deletion and misc (i.e. requested move, rfc) alerts – per Wikipedia:Article alerts/Subscribing#Choosing workflows - Evad37 [talk] 01:07, 25 May 2018 (UTC)[reply]

Thank you guys, it works great!    — The Transhumanist   04:51, 27 May 2018 (UTC)[reply]

Size of this Talk Page / Archiving

This page has passed 250k in a little over a month. We should start thinking about how to keep it manageable and accessible for everyone, including those with less beefy devices. I would suggest auto-archiving, except we've reorganized the topics into subsections and lowercase sigmabot III won't play nice with this layout. Perhaps we should break this page into several subpages covering broad topic areas similar to what is happening with 2nd level headings already (except maybe less granular). Then if any of those subpages gets too big, they can be auto-archived. Editors may still be able to ask a question on the main talk page, but then it can be triaged and moved as appropriate, unless it concerns this WikiProject directly. @The Transhumanist: Thoughts? — AfroThundr (tc) 17:35, 27 May 2018 (UTC)[reply]

I like the idea of doing something like WP:VP, that works well. JLJ001 (talk) 18:33, 27 May 2018 (UTC)[reply]
@AfroThundr3007730 and JLJ001: I'm in the process of sorting the threads, by subject. The archive page is also sorted by subject. Our work falls into subprojects (not subWikiProjects), and it is useful to track the progress in each by having all relevant threads together. I'm about to post a slew of new threads, and so I don't mind archiving by hand, for now. If you don't mind, that is.    — The Transhumanist   20:11, 27 May 2018 (UTC)[reply]
Ok, what's the archive policy gonna be?[a] The primary reason I suggest the subpage route, is that way a bot could do it and you don't have to manually manage the topics,[b] e.g.
  1. Demoting section headers (H2 -> H3)
  2. Sorting by subject area
  3. Manually archiving old topics
  4. Tracking thread age / source and destination page size
  5. Keeping everything correctly formatted
If you defined 5 or 6 topic subpages to host the threads, you'd only need to move them once, off the main page to the relevant subpage. Auto-archiving could then be setup for each of the subpages[c] without human intervention[d]. If designed correctly, this could make it easier to find older discussions.[e] Just a few thoughts on this. It may become moot if this project ever slows down and the talk page becomes much less busy. — AfroThundr (tc) 20:46, 27 May 2018 (UTC)[reply]
  1. ^ I'd suggest something like min thread age=30 days, max page size=80k, max archive size=250k.
  2. ^ Although you seem to have limitless energy, so you do you. :)
  3. ^ and the main page as well
  4. ^ and potential human error
  5. ^ If you archive the subpages by year, for example, you could browse "Portal Template Discussion -> Archive 2017" to get what you needed.
Archiving  Done for now.    — The Transhumanist   20:59, 27 May 2018 (UTC)[reply]
Can message archiving bots archive by subject? See /Archive 4.    — The Transhumanist   20:59, 27 May 2018 (UTC)[reply]
Not as far as I'm aware, although I wonder how much work it would be for the bot authors to add that functionality. Probably couldn't hurt to ask. — AfroThundr (tc) 21:33, 27 May 2018 (UTC)[reply]
We should add a notice about the archiving criteria though. A variant of ((Auto archiving notice)), so something like:
Or if that's to distracting, you could make it smaller (by swapping text with smalltext, image with smallimage, and add |small=yes).
@The Transhumanist: Thoughts? — AfroThundr (tc) 23:16, 27 May 2018 (UTC)[reply]
That works for now, but the sooner we find a replacement for me, the better. :)    — The Transhumanist   01:43, 28 May 2018 (UTC)[reply]

Archiving going forward

@The Transhumanist and JLJ001: We're going to have to find a balance between talk page size (for which I recommend 150k as a hard upper limit) and thread age (where I'd recommend 14 days as a max) during future archiving runs. There are a lot of threads here that should stick around for a while, yet we can't keep them all here due to growing page size. This was also one of my rationales for subpages (a la WP:VP style), which would have allowed topic-based organization and still allowed for auto-archiving. In any case, if we want to continue to do this manually, the above numbers should be kept in mind. — AfroThundr (tc) 20:00, 29 May 2018 (UTC)[reply]

Completely agree, It's getting harder to find the right thread. JLJ001 (talk) 20:03, 29 May 2018 (UTC)[reply]

RfC Section?

I second this, since there seems to be no shortage of them. :) — AfroThundr (tc) 21:02, 27 May 2018 (UTC)[reply]
@JLJ001 and AfroThundr3007730: Good idea.  Done    — The Transhumanist   21:35, 27 May 2018 (UTC)[reply]
Good job. It all looks much tidier now. JLJ001 (talk) 21:37, 27 May 2018 (UTC)[reply]
I'll also suggest the RfC section not be as aggressively archived, since they hold some historical significance. — AfroThundr (tc) 22:08, 27 May 2018 (UTC)[reply]

We need a list of all the WikiProjects corresponding to portals

@Certes, Robertgombos, Voceditenore, and Wpgbrown:

After compiling a list of portals from the entries on Portal:Contents/Portals and its talk page (using the list maker of AWB), I used search/replace (in wp:wikEd to convert the list to WikiProject names, then pulled out the blue links using the list maker of AWB. To make the list complete, we need a way to gather all the WikiProject names from Portal talk pages.    — The Transhumanist   21:08, 29 May 2018 (UTC)[reply]

There is a list here. Certes (talk) 21:20, 29 May 2018 (UTC)[reply]
Waw, nice Certes! Robertgombos (talk) 21:39, 29 May 2018 (UTC)[reply]

How do we make a list of all significant contributors to portals?

@AfroThundr3007730, Certes, Dan Koehl, Evad37, JLJ001, and Voceditenore:

Most activity on portals has taken place on portal subpages. How do we get the user names of the contributors to those (minus bots and vandal reverters, etc.). And then, how do we contact only those contributors who have edited Wikipedia within the past 2 months?    — The Transhumanist   21:08, 29 May 2018 (UTC)[reply]

Not an expert on SQL but how about a query that orders contributors based on their overall number of edits to the portal namespace, cut this off at a certain point. Then query for a list of people who edited in the last two months. Then use a program to find people who are on both lists? JLJ001 (talk) 21:12, 29 May 2018 (UTC)[reply]
We may want to hold off the mass subpage deletion until this has been done. (There are also attribution issues to consider.) Certes (talk) 21:23, 29 May 2018 (UTC)[reply]

Discussions on mobile compatibility

Mobile compatibility progress

I'm working on a different way (than 2-Columns) to make portals scale down. Knowing my luck this approach has probably been scrapped before, but I'm giving it my best shot.

You can prevent divs overflowing by using this as a portal wrapper:

<!-- Wrapper -->
__NOTOC__ __NOEDITSECTION__
<div id="container" style="position:relative;
width:100%">
</div>
<!-- Wrapper end -->

Then add this to CSS of divs to stop text-overflow where it occurs:

;word-wrap:break-word">

And use this instead of px for sizing nested divs:

;width:%">

Fairly straightforward. I'm working on getting this into template form but that's a work in progress.

Any feedback would be appreciated.

Kind regards, Cesdeva (talk) 18:05, 8 May 2018 (UTC)[reply]

I've written markup for more elements to go with this too. Cesdeva (talk) 18:24, 8 May 2018 (UTC)[reply]
@Cesdeva: What is the name of the template you are working on?    — The Transhumanist   10:46, 11 May 2018 (UTC)[reply]
@The Transhumanist: I haven't come up with a name yet, and I'm still learning about how to put together a decent template. I've written Portal:Herbalism in HTML/CSS and it renders well on my mobile atleast (maybe some issues with smaller screen sizes). That's the guinea pig for this idea basically. So once I've got that markup completely ironed out, and added extra stuff, i'll make a generic template with those elements. Any ideas would be welcome. Cesdeva (talk) 17:24, 11 May 2018 (UTC)[reply]
@Cesdeva, Certes, and SmokeyJoe: Nice. Perhaps, in addition to being templatized, it could also be applied in the portal generation template Template:Box portal skeleton. Then it would be applied in new portals. Let me know when it is ready for mobile testing, and I'll add an announcement about Portal:Herbalism to the WikiProject's newsletter.    — The Transhumanist   22:59, 11 May 2018 (UTC)[reply]
@The Transhumanist, Certes, and SmokeyJoe: It may be simpler to continue using box-skeleton as is, but write a specific skeleton template for mobiles and smaller tablets. This way there would be two versions of a portal available. The mediawiki software can then render the most appropriate version based on screen-size. I'm pretty sure this functionality exists in general, so we'd just need some exceptions coding into the software. Cesdeva (talk) 16:13, 12 May 2018 (UTC)[reply]

Discussions about specific portals

Keep an eye on Portal:Right-wing populism

You might want to check Portal:Right-wing populism periodically as someone seems to want to whitewash it into a propaganda portal. 86.134.164.162 (talk) 13:15, 27 May 2018 (UTC)[reply]

RfC Announcements

RfC on new portal guidelines

Link: Wikipedia talk:Portal guidelines#RfC on new portal guidelines
Cheers, Cesdeva (talk) 12:17, 23 May 2018 (UTC)[reply]

 Closed
 – RfC was withdrawn by JLJ001 on 08:46, 24 May 2018 (UTC)[reply]

RfC on new Portal:Contents/Portals layout

See RfC at: Portal talk:Contents/Portals#RFC on layout update.
JLJ001 (talk) 16:12, 23 May 2018 (UTC)[reply]

 Closed
 – RfC was withdrawn by JLJ001 on 14:11, 25 May 2018 (UTC)[reply]

RfC on new Portal:Contents Layout

Please head over to Portal_talk:Contents#RfC_on_a_new_layout. where design input on a new version of Portal:Contents has been requested.

This is the "Contents" link on the sidebar, therefore of community wide importance, I have been told it should go on Wikipedia:Centralized discussion. @The Transhumanist: for help on how that's done.

Closed RfC as proposer is indef blocked, the discussion is stale and a discernable consensus was never going to happen. Cesdeva (talk) 15:51, 30 May 2018 (UTC)[reply]

Comments on project iconography

Not a formal RfC, but comment are wanted at Wikipedia:Village_pump_(proposals)#Making_widely-used_icons_consistent_and_modern, the idea is to update icons with newer "material design" icons, and it has been identified that this includes portals. JLJ001 (talk) 19:46, 28 May 2018 (UTC)[reply]

comments wanted

General discussion threads

Short descriptions for portals

Any suggestions for a standard style for short descriptions of portals? (As portals are not in article space they technically do not need a short description, but if one exists it might just increase visibility in some searches, depending on the search engine.) · · · Peter (Southwood) (talk): 08:53, 13 May 2018 (UTC)[reply]

I am doing this with ((Portal description)). I have done most the portals (about 925) using JWB). I will run through and tag the rest soon. Any portal where a custom description is wanted can use ((Short description)) instead. In this respect ((Portal description)) works a bit like a placeholder. I have also added it to the templates for portal creation. JLJ001 (talk) 21:19, 27 May 2018 (UTC) update 00:50, 28 May 2018 (UTC)[reply]
Nice work, nice and simple. Thanks. · · · Peter (Southwood) (talk): 11:32, 28 May 2018 (UTC)[reply]

Selected quotes

It would be great to have a template for selected quotes sections in a Portal that eleminates the need for subpages. Is there anyone out there who wants to programm such a template?--Broter (talk) 11:23, 13 May 2018 (UTC)[reply]

I found the Template:Random quotation.--Broter (talk) 11:30, 13 May 2018 (UTC)[reply]

Selected Anniversaries

Does someone know how I can improve the Selected Anniversaries Section to be without subpages?--Broter (talk) 21:37, 18 May 2018 (UTC)[reply]

Does it show a different page depending what day of the year it is? If so then a suggested enhancement might help, but this has not yet implemented and there's no promise that it ever will be! Certes (talk) 22:42, 18 May 2018 (UTC)[reply]

It shows a different page every month.--Broter (talk) 05:24, 19 May 2018 (UTC)[reply]

@Certes:: I need a template for showing different content every month without a subpage.--Broter (talk) 07:56, 19 May 2018 (UTC)[reply]

@Certes:: I am talking about Portal:LDS Church/Anniversaries.--Broter (talk) 12:48, 19 May 2018 (UTC)[reply]

@Broter: I have created a new template, ((Transclude selected excerpt)), which you may find useful. It has a selected= parameter to select a specific article. This should be a number from 1 to the article count, but you can use ((Date and time templates)) or time parser functions, such as ((#time:n)) which retrieves the current month number. For example, you could display the lead of an article about the current month with ((Transclude selected excerpt|selected=((#time:n))|January|February...|December)). Hope that helps, Certes (talk) 13:30, 19 May 2018 (UTC)[reply]

@Certes:: It would be great if I could write text like this:

BYU Jerusalem Center

in the template.--Broter (talk) 14:48, 19 May 2018 (UTC)[reply]

That looks good but I don't think you can do it by transcluding excerpts from existing articles. It sounds like a job for traditional subpages, with a top page to select the one for the current month. If you want it in a single page you could look into #switch, but I don't think Module:Excerpt can help here. Certes (talk) 15:06, 19 May 2018 (UTC)[reply]

@Certes:: I improved the Portal:Bible with the new template.--Broter (talk) 16:46, 19 May 2018 (UTC)[reply]

That looks good! I've made one enhancement: you can give each article a code and select with that code rather than a number. It may not be useful for monthly roatation such as Portal:Bible but could be handy in some cases. Certes (talk) 17:00, 19 May 2018 (UTC)[reply]

UX and good portals

So I am still trying to find a portal design that looks good, so I thought perhaps if people could put forward portals they are particularly pleased with. I for one have made Portal:Suffolk with interesting features. And as mentioned above Portal:Opera is a good portal, and Portal:Nanotechnology is an interesting alternative. The best portals may be put forward in a new draft guideline as portals to emulate when working on other portals. JLJ001 (talk) 08:21, 23 May 2018 (UTC)[reply]

Take into account how they look on mobile. · · · Peter (Southwood) (talk): 10:02, 23 May 2018 (UTC)[reply]
And in different skins like Timeless and Monobook - Evad37 [talk] 10:09, 23 May 2018 (UTC)[reply]
In my opinion all portals look crap on mobile, but until we get templatestyles this is hard to fix. JLJ001 (talk) 11:31, 23 May 2018 (UTC)[reply]
Lol, yes, I do 100%. I had a similar idea in my head but I hadn't figured out how to get the rascal buttons to sit neatly like that. Is Template:PortalButton fundamentally flawed or could it be tweaked to do this? Cheers, Cesdeva (talk) 12:34, 23 May 2018 (UTC)[reply]
No idea, but I went for making Template:Portal button 2 especially for the purpose. JLJ001 (talk) 13:41, 23 May 2018 (UTC)[reply]
I think it's the display:inline-block; css value that makes them sit neatly when PortalButton won't. JLJ001 (talk) 13:48, 23 May 2018 (UTC)[reply]
I just gave it another go and i can achieve very similar with the documented template, I just floated all the objects. It's normally best practice to use existing and documented universal templates where possible. Albeit PortalButton is still in alpha and I've just noticed something I need to troubleshoot. Kind regards, Cesdeva (talk) 13:59, 23 May 2018 (UTC)[reply]
Seems a good idea, but there are a few tweaks that ought to be made to it. For some reason it doesn't behave itself in very narrow sizes. JLJ001 (talk) 14:11, 23 May 2018 (UTC)[reply]
Ya it does misbehave. There's that issue and for some reason the default font-weight has stopped working. I should probably also use em units where appropriate, like you did. Cesdeva (talk) 14:23, 23 May 2018 (UTC)[reply]
Ok I have identified the problem, you are expressing the width in percentages. If you express the width in pixels then it works just like what I did, where the width is also in pixels. (using em seems to work fine). JLJ001 (talk) 14:39, 23 May 2018 (UTC)[reply]
Ya I know. I just happened to opt for the nearest % instead of looking up what units you used. Sorry i didn't explain earlier. Cesdeva (talk) 15:24, 23 May 2018 (UTC)[reply]
@Cesdeva: I started the RfC on getting this approved, but when the PortalButton template is worked out we should use that instead of the template I have in there at the moment. JLJ001 (talk) 16:12, 23 May 2018 (UTC)[reply]
Cheers, it may be a little while longer. When I floated those divs in my sandbox originally, they all floated in a perfect grid. Now when I look back at the revisions, they are wonky. I didn't subst: the template, so I think I'll need to troublshoot what went wrong with that latest fix I made. Cesdeva (talk) 18:07, 23 May 2018 (UTC)[reply]
Yes, I like that very much. Can we revive the title Portal:Portal? Certes (talk) 19:53, 23 May 2018 (UTC)[reply]
That's odd, i swear I saw blue links for that recently. I'll support any motion to restore such a ridiculous yet entirely appropriate name Cesdeva (talk) 20:10, 23 May 2018 (UTC)[reply]
It was only deleted 3 days ago. However the title is effectively fully protected because it's a double-namespace prefix. We need an admin to move the page. JLJ001 (talk) 01:09, 24 May 2018 (UTC)[reply]

To what extent does the MOS apply to portals?

Obviously, portals have a style different from what articles use. Yet many style principles should still apply. Minimally, it seems that since Portal titles often appear in articles, they should respect MOS:CAPS and MOS:DASH and such. Yet there has been a bit of pushback trying to get there, and I was advised to "Go to WT:Portals do an RfC to confirm that MOS applies to Portal titles." Is this really worth an RFC? I'll start one if someone seriously suggests that the MOS does not apply to portal titles in spite of what recent RM discussions seem to show. Dicklyon (talk) 04:46, 24 May 2018 (UTC)[reply]

I don't know how this boosterism crept into portal titles (or should I write "into Portal Titles"?). There's nothing special about portals that would justify caps. Besides, we deserve to see the real caps in a title, where they occur after first position, rather than losing them in a succession of caps. Tony (talk) 05:56, 24 May 2018 (UTC)[reply]

Well, I didn't really mean to have the debate yet, just to get comments on whether it's worth an RFC. Dicklyon (talk) 21:01, 24 May 2018 (UTC)[reply]

Good ideas. But do we have a question to put to an RFC, or should we just work on on it along the lines that Moxy suggests? Dicklyon (talk) 04:18, 25 May 2018 (UTC)[reply]

I started a draft at Wikipedia:Manual of Style/Portals; feedback and improvements are welcome - Evad37 [talk] 09:36, 25 May 2018 (UTC)[reply]

I'll add a link for MOS/Portals in the revised draft for portal guidelines. Cesdeva (talk) 14:22, 25 May 2018 (UTC)[reply]

It may be an idea to mention WikiProject specific style. For example MOS:IS, which in this case should ideally apply to Indian portals. Cesdeva (talk) 14:37, 25 May 2018 (UTC)[reply]

I added a see also link to Category:WikiProject style advice - Evad37 [talk] 16:21, 27 May 2018 (UTC)[reply]
Cheers. I didn't even know about that category. Cesdeva (talk) 16:59, 27 May 2018 (UTC)[reply]

New featured portals process

That would make sense. Once we're done overhauling everything we should restart the FP process. Not sure if anybody is thinking about that yet — AfroThundr (tc) 15:16, 27 May 2018 (UTC)[reply]
I came across Wikipedia:Portal peer review as well. It clearly hasn't been used for years but was some kind of review/improvement process. JLJ001 (talk) 23:46, 27 May 2018 (UTC)[reply]

Categorization of New portals

Where do I find out more about categorising new portals, I have been making new ones but don't have a clue how the categorisation of portals works. Portals like Portal:Suffolk & Portal:Plymouth may be fairly easy to place, but where do I put Portal:Profanity? JLJ001 (talk) 18:16, 27 May 2018 (UTC)[reply]

Maybe somewhere under "Society and social sciences", or perhaps "Culture and the arts / Culture / Language"? — AfroThundr (tc) 18:24, 27 May 2018 (UTC)[reply]
I am not sure really, because it's supposed to go with the Freedom of speech portal, which is under "Law portals" and "Society portals". JLJ001 (talk) 18:31, 27 May 2018 (UTC)[reply]
Would it be valid to list it in multiple sections then? I'm not sure if that is allowed or not, but it may make sense in some cases. — AfroThundr (tc) 18:36, 27 May 2018 (UTC)[reply]
Multiple sections is fine.    — The Transhumanist   01:35, 28 May 2018 (UTC)[reply]

Power tool up!

@JLJ001 and AfroThundr3007730: I noticed you aren't registered for WP:AWB/WP:JWB (AWB registration also applies to use of WP:JWB).

These are likely the most powerful tools available to Wikipedia editors. We need you up and running with these ASAP. If you use Windows, you'll be using AWB. JWB otherwise.

They are fun, you'll love 'em. :)

Requests are made at Wikipedia:Requests for permissions/AutoWikiBrowser.    — The Transhumanist   22:06, 27 May 2018 (UTC)[reply]

Yes I am using JWB to add short descriptions at the moment and it does help cut down the number of clicks needed. I will make a point to check out the AWB option. JLJ001 (talk) 22:11, 27 May 2018 (UTC)[reply]
@JLJ001: You don't appear to be on the Wikipedia:AutoWikiBrowser/CheckPage. That is weird. Did you have to register before JWB worked for you?    — The Transhumanist   22:15, 27 May 2018 (UTC)[reply]
Um... no. I just typed my username into the field that grants "full dev access", that seemed to do it. JLJ001 (talk) 22:17, 27 May 2018 (UTC)[reply]
Ah, a JWB fork. Impressive. I think it's best you get registered with AWB ASAP, and your use of JWB will be covered. Besides, there are many things AWB can do that JWB cannot. Let me know when you are registered.    — The Transhumanist   22:36, 27 May 2018 (UTC)[reply]
I may file a bug report for JWB to get them to hide that glaringly obvious "backdoor". But in the meantime I have to applied to correctly register for AWB. Perhaps I can be one of the "rare" approvals. (I have 20 edits to mainspace). JLJ001 (talk) 22:40, 27 May 2018 (UTC)[reply]
It would seem that if we abide strictly by the posted AWB selection criteria of

Users with under 250 non-automated mainspace edits or 500 total mainspace edits are rarely approved

Neither myself or JLJ001 would qualify, even though we both have quite a few edits.
I guess they were only expecting editors to primarily use the tool in the article namespace? Hmm... — AfroThundr (tc) 22:27, 27 May 2018 (UTC)[reply]
No. But, since it can be used there, where it could potentially do the most damage, they require main namespace experience.    — The Transhumanist   22:34, 27 May 2018 (UTC)[reply]
I won't make 500 minor edits to mainspace just to meet that limit unless absolutely necessary. But I guess I could add portal links to a bunch of articles if necessary. JLJ001 (talk) 22:42, 27 May 2018 (UTC)[reply]
@JLJ001: The sooner, the better. We are gearing up to do some major maintenance runs on the portals (many passes on the 1500), along with subpage tagging. When we get up to speed, we'll be tagging 140,000+ subpages. We may also be processing navigation templates to check for and add portal links where they are missing.    — The Transhumanist   23:14, 27 May 2018 (UTC)[reply]
I suspected we might have to do that at some point. JLJ001 (talk) 23:18, 27 May 2018 (UTC)[reply]
I suppose it wouldn't be difficult to generate a couple hundred legitimate mainspace edits to meet the requirements (there are plenty of maintenance categories to tackle) but I don't think that should be necessary. If you think it has any probability of success, I'll submit for access anyway. — AfroThundr (tc) 22:51, 27 May 2018 (UTC)[reply]
@AfroThundr3007730: According to this, you only need 13 more non-automated edits in main space to exceed 250. Therefore, get to it! :)    — The Transhumanist   22:55, 27 May 2018 (UTC)[reply]
BRB, contributing to the sum total of human knowledge... — AfroThundr (tc) 22:58, 27 May 2018 (UTC)[reply]
@The Transhumanist: Request is now live, we'll see how it goes. — AfroThundr (tc) 14:51, 28 May 2018 (UTC)[reply]
Or 250+ non-automated edits. You use tabs, don't you? Those go quick.    — The Transhumanist   09:07, 28 May 2018 (UTC)[reply]
@JLJ001: For storing images for ((Portal)), see Module:Portal/images/s    — The Transhumanist   09:13, 28 May 2018 (UTC)[reply]
@The Transhumanist: I want the template to display the county flag instead of the puzzle piece image. I think this means a edit request to Module:Portal/images but I would rather get confirmation on this first. JLJ001 (talk) 09:17, 28 May 2018 (UTC)[reply]

JS, anyone?

@JLJ001 and AfroThundr3007730: By the way, do you know JavaScript?    — The Transhumanist   22:36, 27 May 2018 (UTC)[reply]

I know a reasonable amount. JLJ001 (talk) 22:40, 27 May 2018 (UTC)[reply]
We're cooking with oil now. :)    — The Transhumanist   22:46, 27 May 2018 (UTC)[reply]
I know a bit. I tinker with a lot of things so I know a bit of everything. Although I wouldn't bet my life on my coding skills in any particular language. — AfroThundr (tc) 22:53, 27 May 2018 (UTC)[reply]
Good. Because, to fully automate portals, we are eventually going to need bots to do a portion of it. Leading up to that, we'll need semi-automated tools, such as in assisting editors in creating portals. For example, the user specifies a category, and the tool fetches the article titles from the category and inserts them into the transclusion template. Things like that.
I encourage you to join WP:JS, and familiarize yourself with the resources there. Especially the Wikipedia bots written in JavaScript, collecting the source code for those for which it is missing, if possible:
Enjoy.    — The Transhumanist   01:32, 28 May 2018 (UTC)[reply]

Assessments

The project banner ((WikiProject Portals)) can be used to assess portal quality and importance. If we can decide what quality and importance mean in terms of portals, then (once assessments have been done) we could use the auto-populated categories to prioritise work on higher-importance and/or low-quality portals with. Note that custom classes can be defined for the quality assessments, or we could just assess importance and not quality. - Evad37 [talk] 11:21, 29 May 2018 (UTC)[reply]

Good idea. This should be fairly straight forward. Cesdeva (talk) 11:31, 29 May 2018 (UTC)[reply]
Agreed, and I already built the missing categories so the tagging can proceed. — AfroThundr (tc) 15:24, 29 May 2018 (UTC)[reply]

By the way, those tagging/assessing portals (or other pages) may like to install my Rater script (which can be used from the pages themselves as well as their talk pages) - Evad37 [talk] 17:03, 29 May 2018 (UTC)[reply]

Dude, this thing is the bees knees. — AfroThundr (tc) 17:14, 29 May 2018 (UTC)[reply]
Rater +1 would recommend. JLJ001 (talk) 17:16, 29 May 2018 (UTC)[reply]

Interactive maps

Map
Map

Relaying from WP:India Noticeboard.
The Kartographer extension is now available.

May be useful on portals. Cesdeva (talk) 20:41, 29 May 2018 (UTC)[reply]

WikiProject collaboration notice from the Portals WikiProject

The reason I am contacting you is because there are one or more portals that fall under this subject, and the Portals WikiProject is currently undertaking a major drive to automate portals that may affect them.

Portals are being redesigned.

The new design features are being applied to existing portals.

At present, we are gearing up for a maintenance pass of portals in which the introduction section will be upgraded to no longer need a subpage. In place of static copied and pasted excerpts will be self-updating excerpts displayed through selective transclusion, using the template ((Transclude lead excerpt)).

The discussion about this can be found here.

Maintainers of specific portals are encouraged to sign up as project members here, noting the portals they maintain, so that those portals are skipped by the maintenance pass. Currently, we are interested in upgrading neglected and abandoned portals. There will be opportunity for maintained portals to opt-in later, or the portal maintainers can handle upgrading (the portals they maintain) personally at any time.

Background

On April 8th, 2018, an RfC ("Request for comment") proposal was made to eliminate all portals and the portal namespace. On April 17th, the Portals WikiProject was rebooted to handle the revitalization of the portal system. On May 12th, the RfC was closed with the result to keep portals, by a margin of about 2 to 1 in favor of keeping portals.

There's an article in the current edition of the Signpost interviewing project members about the RfC and the Portals WikiProject.

Since the reboot, the Portals WikiProject has been busy building tools and components to upgrade portals.

So far, 84 editors have joined.

If you would like to keep abreast of what is happening with portals, see the newsletter archive.

If you have any questions about what is happening with portals or the Portals WikiProject, please post them on the WikiProject's talk page.

Thank you.    — The Transhumanist   07:51, 30 May 2018 (UTC)[reply]

Well, good luck. You're (even more obviously than others of us) shoving water uphill with a rake, pushing string through keyholes, and coaxing camels through the eyes of needles (now there's a thought). I also think it pointless, unless you can quickly demonstrate actual readership. Chiswick Chap (talk) 08:52, 30 May 2018 (UTC)[reply]
Along with the gems, there were some awful portals out there, and a few still remain. I don't blame people for not reading the old versions, but this project is about producing a more attractive replacement. If you build it, they will come. Certes (talk) 09:32, 30 May 2018 (UTC)[reply]
Chiswick Chap, while I agree that WikiProject Portals has taken on a mammoth task, it is not an impossible one. I have never understood the argument for deletion of portals on the basis of low readership. That's never been applied as a criteria for deletion of articles. Portal:Opera has had on average 30 readers a day over the last 90 days, far more than many articles on highly notable figures in their day who have entries in both general and music encyclopedias, e.g. Nicola De Giosa, which has had on average 1 reader per day over the last 90 days. Likewise, essays in Wikipedia space are not deleted for low readership. Even defunct WikiProjects are kept as historical documents. There may be quite valid reasons for deleting some portals, but low readership isn't one of them. Just saying... Voceditenore (talk) 11:09, 30 May 2018 (UTC)[reply]
The time for debating deletion has passed: that's history. The risk now is the Concorde fallacy, that so much effort has been spent on building this thing that it must be worth spending more until (maybe) the thing eventually starts working. It isn't, and (I'm happy to predict) it won't. That's testable of course, come back in a year or two and show me how well it worked—or didn't. Chiswick Chap (talk) 11:43, 30 May 2018 (UTC)[reply]
But, Chiswick Chap, presumably you think the number of portal readers will be the test of the success or otherwise of the current drive. Or did you have other criteria in mind? Voceditenore (talk) 12:39, 30 May 2018 (UTC)[reply]
You are very persistent. Yes, the number of genuine readers who may be presumed actually to be benefiting in some way, however small, is the measurable criterion I mean. Success will mean a marked increase, both in percentage terms (not difficult, but not very useful if you increase readership from 3 to 5 per annum) and in absolute numbers. We can see that an article like Aristotle is meeting a need from its millions of views each year. You do the same for the portals, and everybody will agree with you. Chiswick Chap (talk) 13:05, 30 May 2018 (UTC)[reply]