On November 27th, 2022, the 8,000th article was added to the SuccuWiki!
Template talk:Asbox
| This is the talk page for discussing improvements to the Asbox template. | |||
|---|---|---|---|
| |||
 |
This page is an archive. Do not edit the contents of this page. Direct any additional comments to the current talk page. |
Display issue
If you specify a qualifier and the qualifier begins with a comma, then the template inserts a space in front of the comma. This is not correct English formatting. Vegaswikian (talk) 06:48, 23 April 2011 (UTC)
Curious; the fragment of this templates code below adds a hidden navbar to millions of articles. What is it's purpose ?
{{navbar|{{{name}}}|mini=yes|style=position:absolute; right:15px; font-size:smaller; display:none;}}
- TB (talk) 22:15, 26 July 2011 (UTC)
- Apologies for the self-response; I see some discussion at Template_talk:Asbox/Archive_2#Navbar now. To clarify my interest, this navbar seems to generate around 5% of all the red links in the main namespace of the English-language wikipedia - mostly to Template_talk pages. - TB (talk) 22:42, 26 July 2011 (UTC)
- More on this. A quick check shows only 5 users have enabled the viewing of the hidden navbar on stub messages. At 1,591,830 transclusions, the navbar adds 4.5 million rows to the pagelinks table and 556 bytes to each stub served. Even considering WP:DWAP, this seems profligate. - TB (talk) 20:59, 2 August 2011 (UTC)
- My first comment would be that that navbar is very useful for the few of us who are very active in creating, editing, and maintaining stub templates - although WP:WSS has a lot of members, most of them are involved primarily in stub sorting itself; only a handful of us do most of the template maintenance (probably the five editors who have it unhidden). My second comment is that you'll get far more responses to this at WT:WikiProject Stub sorting, which is where all discussion to do with stub templates usually takes place. My final comment is that - if a recent proposal at WP:WSS about putting a standardised message on stub template talk pages (to tell people to take discussion to WT:WSS) takes place, most of those redlinks should disappear. Grutness...wha? 23:47, 2 August 2011 (UTC)
- One option could be to possibly remove the "d" link, which would half the number of links and get rid of all the extra red links. -- WOSlinker (talk) 09:10, 3 August 2011 (UTC)
- Excellent idea. That would seemingly solve the most obvious problem. As pointed out below, I don't see the additional microsecond or two in loading is likely to be a problem, and this suggestion would drop the pagelinks by 1.5 million as well as getting rid of all the redlinks. Grutness...wha? 00:17, 4 August 2011 (UTC)
- One option could be to possibly remove the "d" link, which would half the number of links and get rid of all the extra red links. -- WOSlinker (talk) 09:10, 3 August 2011 (UTC)
- WP:PERF explains very clearly the circumstances in which it applies: to vain attempts to optimise sitewide performance. There is no "even considering...". Can you measure the impact on performance? Are those 556 bytes causing a measurable increase in page load time (hint, the stub image is usually about 100 times the size)? Are the sysadmins complaining about those 4.5 million rows? Since the answer to those questions is "no", Don't Panic. Do not inconvenience users based on such performance premises.
- That's not to say that you can't optimise it if you can do so without causing loss of functionality. Since users already need to 'opt in' to making the navbar visible, you could consider whether it could be implemented via JavaScript? And if users agree that the discussion links are superfluous, they could certainly be removed.
- You should certainly contact the five users who have enabled this functionality and invite them to join the discussion, if you haven't already. Happy‑melon 10:09, 3 August 2011 (UTC)
- Multiple response:
- All five users of the functionality have been directed here, and I've posted a note at Wikipedia talk:WikiProject Stub sorting#Hidden navbar on stub templates also. Cheers for the tip off.
- Dropping the 'd' links would seem like an excellent idea. If the edit and view links are both substantially useful (more so than the normal links to transcluded templates on the 'edit' page) to the five main stubmeisters, that's fine of course. If there's an alternative that meets their needs without adding hidden content to every stub, that's better still.
- In terms of measurable impact, lookups on the pagelinks table are order N.log(N). Removing 1.5 million rows (of 350 million) would reduce the cost of each lookup by 0.45%. Removing 4.5 million would reduce the cost by around 1.35%. Around a half of Mediawiki work is database bound, of which more than half is dependant on the pagelinks table. With a bit of hand waving, we can estimate the hidden navbar accounts for around a third of a percent of the load on the servers - small change, but measurable small change. Guessing wildly, I'd say that bandwidth impact is of a similar order.
- - TB (talk) 08:42, 4 August 2011 (UTC)
- For the direct equality lookups most common in pagelinks transactions, MySQL (AFAIK) uses hash indices, which are O(1) at the database level. The vast majority of cluster server load is on the Apache servers which have no connection to the database layer: of Wikimedia's 400 servers, fewer than 10% of them are database servers. "of which more than half is dependant on the pagelinks table" seems pretty much plucked out of thin air to me, I can't think of any published data that would suggest that.
In terms of bandwidth, we're looking at 556 times the total number of pages served, times the fraction of all pages that are enwiki stubs, divided by Wikimedia's total bandwidth. Total pageviews for Wikimedia are 12 billion a month, 4,600 per second; the fraction of pages that are enwiki stubs is 1,500,000/17,900,000 or 8.3%; the cluster's total bandwidth is around 4Gb/s. So that's roughly 556 * 4600 * 8.3% / 4,000,000,000 or 0.005%, analogous to one server reducing its output by 2% because of overheating caused by a lump of fluff caught in its air vent. Obviously this makes the poor assumption that all pages are viewed equally frequently; in reality there will be a bias towards pages that are not stubs, so this number is an overestimate.
Of course, I'm no more privy to the exact figures than you, because I'm not a sysadmin, just a developer. That's the entire point of WP:PERF: unless you can quantifiably measure a performance impact, you are in no position to make any accurate estimate of how serious it might or might not be. So Don't Worry About It™. Happy‑melon 17:22, 4 August 2011 (UTC)
- For the direct equality lookups most common in pagelinks transactions, MySQL (AFAIK) uses hash indices, which are O(1) at the database level. The vast majority of cluster server load is on the Apache servers which have no connection to the database layer: of Wikimedia's 400 servers, fewer than 10% of them are database servers. "of which more than half is dependant on the pagelinks table" seems pretty much plucked out of thin air to me, I can't think of any published data that would suggest that.
- Apologies for my lack of clarity; as you say I've no special knowledge of the live setup - my analyses are almost entirely carried out on my own crappy little Mediawiki installation which most definitely lacks a surrounding sphere of squids. Databasewise, I'd be delighted if we really did achieve O(1) on positive hash lookups - sadly, these are mythical beasts; oft sought after, but vanishingly scarce in the real world. Somewhere near the lower end of O(logN) to O(N) is most probable (RAM is cheap). Red links of course represent lookup failures (page table, natch - other direction) and garner costs at the upper end of this range. At worst, still well within fluff-in-the-fan territory, as you say.
- You're also quite right that the bandwidth considerations are vanishingly small in the bigger picture - although mentioning the hidden navbar to the mobile Wikipedia bods might be fruitful I suppose. Raise a glass to those poor souls on dialup-speed connections and be thankful.
- All this said, the hidden navbar exists on millions of pages. It's there to support the (of course excellent) work of a handful of stub sorters. I'm not suggesting it's a serious problem or advocating panic, just that it might be sub-optimal. Is there a more elegant solution ? - TB (talk) 20:30, 4 August 2011 (UTC)
- Good to know, Grutness - if you make use of the hidden navbar from the mobile interface then of course it is required on the 'optimised' pages there also. You've inspired me to have a dig through the pagecounters for the mobile site; I'd always imagined it to be 100% read-only which of course is wrong. - TB (talk) 08:30, 5 August 2011 (UTC)
- HM and I are mostly engaged in technobabble and hand waving. To translate:
- TB: This hidden stuff in the stub templates might be inefficient.
- HM: Nah, it's not that bad. Besides, not our problem if it is.
- TB: Ya, you're probably right.
- That sounds about right! :D Alternatively, you could come join us on the dark side... ;) Happy‑melon 12:26, 5 August 2011 (UTC)
Two new stub-template proposals
I believe that there should be British and Canadian templates equivalent to: Template:US-academic-administrator-stub Ottawahitech (talk) 13:29, 2 November 2011 (UTC)
- See Wikipedia:WikiProject Stub sorting/Proposals for the best place to discuss this. -- WOSlinker (talk) 18:43, 2 November 2011 (UTC)
stubtree styling
| Stub hierarchy |
|---|
|
This template presently uses a rather weird styling of its own to depict the subtree of a stub template in its documentation. I've cooked up a sandbox which just uses a {{sidebar}} instead, for consistency. Any objections to rolling this out? Chris Cunningham (user:thumperward) (talk) 14:06, 22 November 2011 (UTC)
- I think left-aligned looks better than centred. And this version seems to take up too much space, especially the width. — Martin (MSGJ · talk) 13:32, 23 November 2011 (UTC)
- Slightly puzzled. Where can I see such a subtree in action? — Edokter (talk) — 13:50, 23 November 2011 (UTC)
- Try Template:England-footy-bio-stub. (For more discussion see Template talk:Asbox/Archive 2#stubtree.) — Martin (MSGJ · talk) 14:37, 23 November 2011 (UTC)
- If you're going to center the list, at least use the
plainlistclass to get rid of the bullets. — Edokter (talk) — 15:59, 23 November 2011 (UTC)
The alignment was an oversight. Left-aligned with bullets sounds fine to me. Chris Cunningham (user:thumperward) (talk) 10:09, 25 November 2011 (UTC)
Template category
It would IMO be incredibly useful to have a parameter for template categories (|tempcat=. For example, the following templates
Should all be contained in Category:Academic journals stub templates. That way when we tell people "don't forget to tag the article with the appropriate stub template", we can point them to the relevant list of template they should be picking from. It's a real pain in the ass to find and build such complete listings. Headbomb {talk / contribs / physics / books} 21:13, 12 March 2012 (UTC)
- The category is created and templates are put under it. I agree that the stub templates should be more logically organised. It needs more editors to work together.--Quest for Truth (talk) 14:35, 16 May 2012 (UTC)