Module talk:Random portal component

	This 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.PortalsWikipedia:WikiProject PortalsTemplate:WikiProject PortalsPortals
Template	This module does not require a rating on the project's quality scale.
	See also: List of Portals

Script errors

@Mr. Stradivarius: The recent changes to this module cause every portal that is missing a page to show up in Category:Pages with script errors. What should we do about this? Jackmcbarn (talk) 23:07, 4 December 2014 (UTC)[reply]

@Jackmcbarn: It looks like catching the error and putting them in a separate tracking category would be best. — Mr. Stradivarius ^{♪ talk ♪} 23:21, 4 December 2014 (UTC)[reply]

I've changed the module to catch errors in portals with non-existent content subpages and put them in Category:Portals needing attention. — Mr. Stradivarius ^{♪ talk ♪} 23:39, 4 December 2014 (UTC)[reply]

Subpage tracking algorithm

@BrownHairedGirl: Thank you for your recent addition of the subpage tracking code. :) I noticed that in Template:Portals with subpages count tracking category you have commented out categories for subpage counts of 51–100, 101–200, 201–500, 501–1000, and >1000, presumably because checking for them would exceed the expensive function count. How about using the shortcut of only checking the boundary pages exist, instead of checking that every page exists? The algorithm would go something like this:

Check whether subpage #2 exists. If it exists, then move to step 2. If it doesn't, put the page in the category Category:Random portal component with less than 2 available subpages and exit.
Check whether subpage #6 exists. If it exists, then move to step 3. If it doesn't, put the page in the category Category:Random portal component with 2–5 available subpages and exit.
Repeat with page #11, #16, #21, #26, #31, #41, #51, #101, #201, and #501.
Finally, check whether subpage #1001 exists. If it exists, then put the page in Category:Random portal component with more than 1000 available subpages. If it doesn't, put the page in the category Category:Random portal component with 501–1000 available available subpages.

This way you use at most 13 expensive function calls - one for each category. However, there is the drawback that the algorithm won't work properly if there are gaps in the subpage numbers. For example, if a portal has subpages #1, #3 and #4, but #2 doesn't exist, then the algorithm will put it in the "less than 2" category, when it should be in the "2–5" category. Let me know if you think this would be an acceptable trade-off or not. Best — Mr. Stradivarius ^{♪ talk ♪} 06:17, 2 May 2019 (UTC)[reply]

Many thanks, Mr. Stradivarius. That's a very thoughtful suggestion, and yes expensive function count was the issue. It caused the modules to fail on big sets, leaving redlinks and error messages, and sadly triggering some dramas like MFD:State-level road portals.

I think that as presented, it is open to gaming the system by creating only the boundary pages ... but if it was accompanied by some randomised checking of pages between the boundaries, then gaming could be avoided. E.g. if page 101 exists, then check a random sample of pages in the 51–100 range, and if any are missing, then categorise that somehow. That would probably still mean the end of the mismatch-checking, which would be a pity.

However, the really thoughtful feedback since creating the tracking system has made me re-evaluate my initial assumptions. I started out by simply copying and hacking the code I had used for automated portals, and retained the same thresholds. But now that I have looked at the results, I am less persuaded that the higher-numbered categories are useful. I view any set over 50 as "plenty big", and am nt sure that it's worth dividing that into "more than plenty big", "much more than plenty big", "shedloads more than plenty big" etc.

I think that @Espresso Addict regards that sort of number as a set that probably needs splitting. I hope I haven't put words in EA's mouth, but maybe EA will respond to the ping and lets us know what they think of breaking own the over-50 set. --BrownHairedGirl (talk) • (contribs) 20:30, 2 May 2019 (UTC)[reply]

It's just a personal view, but I've found something in the 20–40 range is probably optimal for each individual portal textbox. That way it usually comes up with something different when refreshed (and if you've got two columns side by side, at least one will nearly always change), but readers stand a chance of actually seeing the content. I'm not sure dividing the tracking category above 50 is therefore all that useful, except to identify portals with over-large selections that should be split up. But that isn't a good reason to take a portal to a deletion discussion, so I'm not sure such a tracking category would be all that useful. Espresso Addict (talk) 21:10, 2 May 2019 (UTC)[reply]