Template talk:Asbox/Archive 4

Archive 1

Archive 2

Archive 3

Archive 4

Template:Begin-stub-templates

I assume this template is no longer necessary? –xeno^talk 05:50, 23 August 2009 (UTC)

Well the current asbox does not clear, but we can easily make that so of course. —TheDJ (talk • contribs) 11:50, 23 August 2009 (UTC)

It is the same as {{clear}} but with a horizontal rule for some reason. It is not widely used— I would expect that {{clear}} or {{-}} are used more for this. Putting the functionality into the asbox template would be good. ---— Gadget850 (Ed) ^talk 12:39, 23 August 2009 (UTC)

the mbox variant had this I think —TheDJ (talk • contribs) 13:45, 23 August 2009 (UTC)

Do we want to clear left, or clear both sides ? —TheDJ (talk • contribs) 12:43, 25 August 2009 (UTC)

I think both because of infoboxes an other tables. Locos epraix ~ Beastepraix 19:26, 20 September 2009 (UTC)

End misaligned left justification with asbox?

I came across the Atlantic Array article, and noticed that the two stub messages are misaligned & hence messy. Two questions arise:

1. Is there any move to standardise the pix (picture size) parameter so as to encourage aligned stub messages
2. If a stub message has no image, could {{asbox}} be tweaked to indent the message (e.g. by inserting a standard-sized blank image)

thanks --Tagishsimon (talk) 07:02, 26 August 2009 (UTC)

1, no

2, sure that would be simple (we could also add a generic stub image instead).

I don't think there is much support for that at this time however. —TheDJ (talk • contribs) 18:26, 26 August 2009 (UTC)

Even if the picture sizes are different, they could probably be padded so that the text aligns on the left? — Martin (MSGJ · talk) 18:33, 26 August 2009 (UTC)

You can only have fixed sized indenting. So unless you cut off the the image visibility or something, I don't think you can. —TheDJ (talk • contribs) 18:39, 26 August 2009 (UTC)

I have had issues like this and ended up using something like [[File:blank.png|30px|link=]]. ---— Gadget850 (Ed) ^talk 12:14, 10 September 2009 (UTC)

Populating stubtree with a tree?

I noticed that the template pages transclude {{Asbox/stubtree}} near the top.

However, in the examples I have looked at, there is no tree but simply 2 entries, the name of the current stub type, and stub itself.

For example Template:Classicalmechanics-stub has a box with just 2 entries like this:

{{#ifeq:Classicalmechanics-stub|Stub||<div style="float:right; border-style:dotted; border-width:2px; padding:5px">
<span title="This shows the hierarchy of the stub template in relation to other templates." style="font-size:125%; font-weight:bold;">Stub hierarchy</span>
*Classicalmechanics-stub{{Asbox/stubtree/2
 |Classicalmechanics-stub
 |{{Str len|Classicalmechanics-stub}}
}}
</div>}}

I think the current hierarchy is Classicalmechanics-stub <- Physics-stub <- Natural science stub <- Science stub

How are these trees calculated? Is there an intent that editors type in the hierarchy for each stub template, is the current look intended, or has asbox been used incorrectly for this stub?

--Hroðulf (or Hrothulf) (Talk) 13:18, 23 September 2009 (UTC)

The trees are calculated just by chopping off prefix segments at the hyphens, they aren't meant to show hierarchy in the sense you've described. –xeno^talk 13:26, 23 September 2009 (UTC)

It occasionally works well, for example the England-footy-bio one. — Martin (MSGJ · talk) 13:57, 23 September 2009 (UTC)

{{#ifeq:England-footy-bio-stub|Stub||<div style="float:right; border-style:dotted; border-width:2px; padding:5px">
<span title="This shows the hierarchy of the stub template in relation to other templates." style="font-size:125%; font-weight:bold;">Stub hierarchy</span>
*England-footy-bio-stub{{Asbox/stubtree/2
 |England-footy-bio-stub
 |{{Str len|England-footy-bio-stub}}
}}
</div>}}

Hrothulf makes agood point, this is more of a "family tree" than a hierarchy. –xeno^talk 14:10, 23 September 2009 (UTC)

For a proper hierarchy, it would either need a couple of huge switch statements, or one subpage for every stub template naming its logical parent. Neither is particularly attractive, but doable if found useful enough.
A point in favor is that if we ever defined and maintained a proper stub hierarchy somehow, some HotCat-like tool to place stub templates could be done quite nicely, where one only needs to walk the tree instead of guessing at stub names, and clicking through subcategories.
Amalthea 15:58, 23 September 2009 (UTC)

Could always add a |parentstub= parameter to asbox which could then be shown on the template docs if the parameter is set to something. -- WOSlinker (talk) 20:54, 23 September 2009 (UTC)

Ah, of course, the documentation is created by it anyway, so that would be easiest, if we want that. Amalthea 21:14, 23 September 2009 (UTC)

Image alt text

Right now the image in the stub icon is clickable, and has alt text. As it's purely decorative, I don't think this is appropriate. Instead, the image should be flagged with |link=|alt=. I didn't see any real discussion of this in the archives; thoughts? Chris Cunningham (not at work) - talk 13:58, 14 January 2010 (UTC)

In order to suppress the link, all images used on stub boxen would need to public domain - otherwise we are not properly attributing per cc-by-sa licensing requirements. Since we are showing the link, we need the alt text.

One user of a screen reader also commented it is preferable to have alt-text to a suppressed link without - see Wikipedia:Bots/Requests for approval/Xenobot 6.1. –xeno^talk 14:02, 14 January 2010 (UTC)

I'm the screen reader user mentioned above, and I don't know *what* I was thinking when I made that comment. :-) To clarify, I don't have a strong preference for having no alt text with no link versus having a link with generic alt text. However I strongly dislike images with a link but no alt text. If the images are under a CC or GFDL license, they must have a link, so therefore they must have alt text. I wouldn't want to have some stub templates with alt text and some without it for reasons which would seem arbitrary to the casual reader, so IMO all stub templates should have links and alt text. Graham87 15:23, 14 January 2010 (UTC)

Actually where possible, which it isn't in this case, I'd *slightly* prefer a decorative image to have no link and no alt text. I'm not too fussed about it though. Graham87 15:29, 14 January 2010 (UTC)

We don't omit alt text for purely decorative images because of some Wikipedia contrivance; we do so because it's prescribed by the bodies who control the development of HTML. (I see Graham87 has also reversed the position given in that page in his comment above.) As for image attribution, I am somewhat skeptical as to this interpretation of our requirements when it would seem to suggest that simply printing a Wikipedia page with cc-by-sa images on it and handing it to a friend would seem to be violating the license in that case unless one first wrote the names of all the image authors in the margins. Has there been wider discussion of this particular point? Chris Cunningham (not at work) - talk 15:41, 14 January 2010 (UTC)

Try Wikipedia:Media copyright questions/Archive/2009/July#W3C accessibility guidelines and image copyright notices, for a start. Haven't had a chance to read thru it tho. –xeno^talk 15:45, 14 January 2010 (UTC)

For book print, we actually do have this attribution of every image. For text print, where this is signficantly more complicated we have

Retrieved from "http://en.wikipedia.org/wiki/Template_talk:Asbox"

This page was last modified on January 14, 2010 at 16:45.
Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. See Terms of Use for details.
Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization"

so that people can go online and find out about image licenses. If the meta system for images ever gets of the ground, you can count on this information being in HTML pages in one form or another btw. That is just a lot more trouble to actually implement. —TheDJ (talk • contribs) 16:13, 14 January 2010 (UTC)

Xeno: I know about that discussion, because I participated in it. :) FWIW I think the most directly relevant discussion is this one, which basically came down to David Göthberg's interpretation of the license requirements (which I disagree with for the reasons above). I'd rather that if this is going to come down to a legal point that it be discussed with actual legal counsel. With {{portal}} and {{asbox}} pretty widely deployed, it's maybe worth doing just that. Chris Cunningham (not at work) - talk 09:28, 15 January 2010 (UTC)

Sure, that may be worthwhile. FWIW I am not particular married to either outcome; compliance in attribution is my main concern. –xeno^talk 13:40, 15 January 2010 (UTC)

Honest disclosure: I have not read the previous discussions on this, because I usually hang out in text land. That said, a literal reading of many of the licenses we use for images will require naming the author of an image on any form of distribution...or, at least, sort of. Take, for instance, CC-By-SA, 4(c). Names and titles are required "reasonable to the medium or means You are utilizing." The question would seem to be what is "reasonable to the medium and means" and, I suppose, whether identification in alt.text has any bearing on that. A reading of 4(c) suggests that naming the authors of images might require us to name all contributors to the collection, with equal prominence to contributors of text and images — "provided, however, that in the case of a Adaptation or Collection, at a minimum such credit will appear, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors." I've worked enough with legalese to suspect that this is never going to change, but I do wish they'd write in simple English. :/ ("If you can name names, name them. If you name any names, name them all.") Checking with Mike might be a good idea. --Moonriddengirl ^(talk) 14:08, 15 January 2010 (UTC)

What's the most appropriate avenue for that? This might have pretty far-reaching consequences, especially if it turns out that a non-trivial number of existing images are currently non-compliant with their respective licenses. Chris Cunningham (not at work) - talk 12:53, 18 January 2010 (UTC)

Not categorizing if in userspace?

It's practice that userspace pages (i.e. creation sandboxes) shouldn't be categorized into the stub categories. It seems that making the stub templates impose this restriction automatically might be useful. It avoids categorizing that which shouldn't be, and it encourages the use of the templates, even for new pages still in the sandbox.

The code to do this is simple enough. Are the load implications acceptable? Andy Dingley (talk) 02:03, 21 January 2010 (UTC)

I believe that the template does not categorise pages outside main (article) space. Do you have an example of where incorrect categorisation is happening? — Martin (MSGJ · talk) 11:56, 29 January 2010 (UTC)

Name proposal

"Asbox" is a strange name. Let's make it clearer what this template is for. I propose

Template:Asbox → Template:Stub meta

— Martin (MSGJ · talk) 13:48, 23 February 2010 (UTC)

The name is in accordance with the series of message box meta-templates: {{ambox}} {{tmbox}} {{imbox}} {{cmbox}} {{ombox}} {{mbox}} {{fmbox}} {{dmbox}}. ---— Gadget850 (Ed) ^talk 14:27, 23 February 2010 (UTC)

Proper name would be something like {{smbox}}, though. Amalthea 15:19, 23 February 2010 (UTC)

It's still not clear from the name what the template is for. I don't see the advantage of keeping "box" at the end. The stub template box is not even visible. — Martin (MSGJ · talk) 12:44, 24 February 2010 (UTC)

• The name (a_rticles_tubbox) is awfully entrenched to bother changing it now, no? –xeno^talk 15:20, 23 February 2010 (UTC)

  There would be no need to go around changing all the uses. {{asbox}} would probably be retained indefinitely as a redirect. — Martin (MSGJ · talk) 12:44, 24 February 2010 (UTC)

  Sure, but with the vast majority of them having the old name... –xeno^talk 17:25, 1 March 2010 (UTC)

Add 'bodyclass' parameter, redux

{{editprotected}}

Previous discussion: Template talk:Asbox/Archive 3#Microformats in stubs

To facilitate the inclusion of microformats in instances of this template, I propose an {{editprotected}} request, to change:

<table class="metadata plainlinks stub"

to:

<table class="metadata plainlinks stub {{{bodyclass|}}}"

allowing an extra class value, bodyclass, to be specified when the template is deployed (as is already done in, for example, {{Infobox}} and {{Navbox}}). Previous discussion floundered, not least due to the raising of several red herrings. May we now proceed with this? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:49, 18 March 2010 (UTC)

You mean the discussion that takes up the entirety of /Archive 3?? I don't think I'd describe that discussion as having "floundered", rather that the concerted and united opinions of a dozen editors was insufficient to convince you not to blunder onwards with the proposal. As I said before, I liked this proposal better when I was following a red herring; the reality of the situation is even less inspiring. Happy‑melon 19:00, 18 March 2010 (UTC)

No, I mean the one in which, when I identify straw men arguments raised against this trivial change, and ask people to justify them, they fall silent or change the subject. If you have a substantive objection, not based on a false belief, please make it known. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:25, 18 March 2010 (UTC)

Oh, sorry, I must have missed that discussion; where did that take place?

As I said before, "meh". I have many better things to do than debate this issue again. I'm sure you'll take that as some kind of vindication. Primarily, I object to you categorising what is unquestionably a consensus against inclusion as a 'petered out' discussion. Feel free to establish a new discussion and maybe a consensus for this time. But don't present the past as something it's not. Happy‑melon 21:52, 18 March 2010 (UTC)

You failed to present a substantive objection then; and you can't or won't do so now WP:IDONTLIKEIT is not consensus. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:10, 18 March 2010 (UTC)

I think substantive objections are K.I.S.S. and perhaps moreover that no one (other than you, apparently) really cares about microformats in stub templates. –xeno^talk 22:12, 18 March 2010 (UTC)

They may be objections, but they're certainly not substantive; indeed, the proposed change (and I'm grateful to you for bug-fixing that) will "keep it more simple" than the status quo. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:35, 18 March 2010 (UTC)

RFC

I can't believe that we still haven't been able to make this simple change. Therefore:

{{rfctag|style}}

Should we add a facility to apply an HTML class to {{Asbox}}, in the same manner as we can to {{Navbox}} and {{Infobox}}? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:17, 21 April 2010 (UTC)

Oppose - No I think the previous discussion and the comments above address my opinion as well. The is is a KISS situation, and microformats in stubs are just completely not necessary. You are a little too caught up in trying to put microformats in everything you see. And I would note the previous discussion was a complete consensus against you. You have a real issue with making a point alot of the time I have noticed. -DJSasso (talk) 11:52, 21 April 2010 (UTC)

I agree. I don't have an opinion on this issue, but I am seeing a battleground mentality here. — Martin (MSGJ · talk) 12:31, 21 April 2010 (UTC)

I also. Another resounding "meh" to the proposal itself, but the way this is being presented is not healthy. Happy‑melon 19:05, 21 April 2010 (UTC)

Could this be the same Happy Melon who wrote just above "Feel free to establish a new discussion and maybe a consensus for this time."? None of the few comments in this RfC give a substantive reason why this simple change should not be made, let alone how it might harm the encyclopedia. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:11, 23 April 2010 (UTC)

Andy, If the first thing an unrelated person in an RFC says, is something along the lines of "You are a little too caught up in trying to put microformats in everything you see." after you have been told the same thing multiple times in previous normal talk page requests, then perhaps it is time to take that criticism under consideration. I also note that recently after I opposed a request by you to implement a microformat in an audio template, you went to another similar template and made the same request where an uninvolved admin, unaware of my previous oppose, immediately implemented the change. I have not reverted this, but it has been noted, and in full disclosure I wasn't the only admin to notice. Wisely consider the best approach forward please. —TheDJ (talk • contribs) 02:36, 24 April 2010 (UTC)

It was delightful to see Djsasso make a rare foray outside the ice hockey project, where we have along-standing dispute. Unfortunately, his policy-breaching personal attack was so vague as to offer no meaningful criticism. As for adding microformats, three years or so ago I took great care to obtain consensus to add them to Wikipedia, starting a centralised discussion. We now emit several million. Our use of microformats has been explicitly praised by Yahoo's Chris Heilmann, and Google also collaborate with us to reuse them. If you wish to raise an RfC to have the all removed, feel free. Meanwhile, we now emit thousands of hAudio microformats from a series of templates; where I added them as part of the same single exercise (and your misguided objections at Template talk:Audio#Apply hAudio microformat, where I note that you have failed to respond to my last comment, do not apply to any of the other templates involved). This makes our data more easily searchable and reusable. Once we have the ability to a rel attributes to links, it will also make it possible to subscribe to some, such as our spoken word articles, as a podcast. I'm not clear why you think any of this is a bad thing. Indeed, I note that you - like DJSasso - still have no substantive reason why the requested change should not be made here. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 09:43, 24 April 2010 (UTC)

You do not think they are substantive, but that is kinda the point. You are pushy and ignore people, meanwhile passing your holy grail of microformats. You act like an evangelist that puts his foot in the door, when people want to shut the door on them. Regardless of your perceived righteousness, that is simply BAD behavior and if you continue along that route, then you will get in trouble. —TheDJ (talk • contribs) 11:34, 24 April 2010 (UTC)

Oppose Neutral. Mind you, this is the opinion of someone whose knowledge of microformats is limited to what I just learned 15 minutes ago reading the threads here. What Andy is calling "one small addition" sounds to me like hundreds of categories that would have to be understood by users for that one addition. If my reading of this situation is incorrect, then by all means disregard my opinion. In any case Andy, if you want to sell this idea, it would be nice to see a few concrete examples, and perhaps mock-ups of the stub boxes so those of us coming from the RFC with little infobox knowledge could see how these would look in the field. The issue is a little abstract, and more clarity would be appreciated (at least by me). --Rsl12 (talk) 10:05, 24 April 2010 (UTC)

Thank you for you interest; but you're mistaken. No categories would be involved. No changes would be made to the visual appearance of stub templates. This is only about adding metadata to them in the form of two HTML classes. I've already linked to examples, in the preceding discussion; see, for example, {{Ghana-stub}}, which had the classes added manually, with no issues arising. All that this proposal involves is using an existing HTML element for one of the classes, thereby reducing the amount of in-line HTML needed. Please let me now if that's not clear. Andy Mabbetts (User:Pigsonthewing); Andy's talk; Andy's edits 10:37, 24 April 2010 (UTC)

Thanks, the example helps. A few more questions: Who would be responsible for creating the

<span class="adr"><span class="country-name">[[Ghana]]</span></span>

portion for each stub template? And what benefits would accrue by doing so? It sounds like the purpose is to make it easier for outside search engines to find relevant information in Wikipedia, is this right? If that's really the reason, I'm against it. The "stub" marker is basically saying, "Hi! I'm an article that isn't very good. If someone comes here looking for information, they're going to be disappointed. Can you make me better?" While the microfilter would be yelling out "Hi! If you're looking for information about Ghana, this is the place! Come on over!" That sounds contradictory to me. But correct me if I don't see the picture right. --Rsl12 (talk) 02:30, 25 April 2010 (UTC)

I'm starting to agree with Happy-Melon's assessment--the more I understand, the less I like it. I don't know where the microfilter normally goes for non-stub articles, but since I assume there there's a normal repository for this kind of information, why bother placing it on the stub box as well? It sounds messy. I feel more and more confident in my opposition, but again, correct me if I'm missing something important. --Rsl12 (talk) 03:27, 25 April 2010 (UTC)

I plan to add some, and to document the facility so that others may do so, should they wish - note that this proposal makes it easier to do so, by reducing the HTML markup required. While search optimisation my be a benefit of microformats; its not the only one. microformats add semantic richness, which others can reuse in a number of ways. Consider it the equivalent of having a new <country> (or whatever) element in HTML - no different to using heading or paragraph tags, or the like. There is no separate "repository" elsewhere in articles for such information. The issue of people finding stubs is a red herring in this debate, but we do want people to find them - that's how they get edited into more complete articles. Otherwise, we'd keep them hidden from view, except to established editors. As it is, it is already Wikipedia policy to return stubs as results of searches made using our internal search facility. Your "Hi! If you're looking for information about Ghana, this is the place!" scenario is mistaken. No such assertion is implied by the presence of a microformat. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:10, 25 April 2010 (UTC)

Could you explain "semantic richness"? Like practically, what is the benefit, beyond search engines? And I think I agree with you that the "contradiction" isn't the major concern. But I think focusing on having a more permanent store for this kind of information (perhaps the "WikiProject" banners?) might be a more productive attack for this issue. --Rsl12 (talk) 20:08, 25 April 2010 (UTC)

He means that if you take the above example, that the searchengine will know that the information is about a country named Ghana, Instead of a village named Ghana. —TheDJ (talk • contribs) 20:34, 25 April 2010 (UTC)

No, I don't. Please don't try to speak for me. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:52, 25 April 2010 (UTC)

"Semantic richness" means "added meaning". Sorry for the jargon. I mean that the name of the country - and the fact that it is a country (or whatever; others will be about people, organisations, settlements, species, dates, etc.) - will be available, unambiguously, to a variety of user agents and on-line tools, including mapping services, mashups, search engines, screen-readers, timeline-generators, language-translators, and more. Microformats are an open standard, understood across the web; any Wikipedia-specific solution would not be; and is in any case purely hypothetical; and anything on talk pages will not help people viewing or tools accessing our articles. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:52, 25 April 2010 (UTC)

OK, thanks for all the info. I still think it's overkill for Wikipedia's equivalent of a post-it note, but I see that there's no additional labor asked of the run-of-the-mill editor. I'll change my opinion to neutral, because I'm unqualified to evaluate. The people that need to be convinced are the people that will have to actually modify/create the stub templates, and I'm not in a position to evaluate just how much work is involved. Final thought: I think your efforts at prosthelytization might be better channelled at the WikiProject template or the like. It doesn't look like you're having too much luck here. If you can show some success on a similar template, you might get a warmer reception. --Rsl12 (talk) 15:45, 26 April 2010 (UTC)

Thank you; we already emit millions of microformats from hundreds of infoboxes and navboxes (and many stubs have neither); largely as a result of my efforts. This has illustrated their usefulness (and indeed harmlessness). Nobody will have to do anything as a result of this change, unless they elect to do so, and the change itself is trivial effort. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:54, 26 April 2010 (UTC)

• FYI: Wikipedia:VPP#Microformats. (I've disabled the nearly expired, and exceedingly lightly-trafficked RFC) –xeno^talk 13:37, 19 May 2010 (UTC)

There being no decision at VPP to remove our existing microformats (see preceding comment), I have re-enabled the {{Editprotected}} request. Perhaps we can finally put this to bed? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:27, 11 June 2010 (UTC)

There is similarly no consensus to add more. –xeno^talk 16:29, 11 June 2010 (UTC)

There is; as demonstrated by the fact that we add more almost every day. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:19, 11 June 2010 (UTC)

fait accompli? –xeno^talk 17:20, 11 June 2010 (UTC)

I've disabled the {{editprotected}} template because I can't see a clear consensus for this change to be implemented and so making such a change to a fully protected template would be improper. By all means re-enable it if/when there is a clear consensus. HJ Mitchell | Penny for your thoughts? 16:36, 12 June 2010 (UTC)

FYI: Wikipedia:Requests for comment/Microformats. –xeno^talk 15:49, 10 August 2010 (UTC)

Closed with no mitigation against this change. Request reactivated. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:47, 12 September 2010 (UTC)

Use of editprotected

Please stop misusing the {{editprotected}} template. I came here expecting to make a non-controversial edit, but by the looks of it, it is nowhere near non-controversial. This template is strictly for edits which are non-controversial; if there is no consensus, this template is not to be used in order to force one's view. Thank you. — Edokter • Talk • 22:43, 12 September 2010 (UTC)

The above-referenced RfC closed with no mitigation against this change. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:46, 13 September 2010 (UTC)

That does not make is non-controversial, as is evident in the above thread. — Edokter • Talk • 01:28, 14 September 2010 (UTC)

which valid concern do you believe remains unresolved? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:39, 14 September 2010 (UTC)

Could you indicate what specific benefit(s) would be enjoyed if we added support for microformats to stub templates? –xeno^talk 20:41, 14 September 2010 (UTC)

I refer you to my previous answers to that question. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:22, 15 September 2010 (UTC)

You'll have to be more specific as to which of your answers provides a well-delineated specific benefit. –xeno^talk 14:27, 27 September 2010 (UTC)

Redux

There being no substantive objections, and no mitigation against this simple change in the above RfC, may we now make it? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:38, 30 December 2010 (UTC)

Wow, some threads never die...

I'm fascinated to read Wikipedia:Requests for comment/Microformats; and also the VPP discussion which preceeded it. The consensus of that RfC is quite clear: microformats are neither universally encouraged nor universally discouraged, but must be considered on a case-by-case basis; with particular consideration being given to weighing the usefulness of the implementation against its impact both on readers and on editors.

My position on this issue is and remains a resounding "meh"; I have not seen arguments which would convince me that it is either the next sliced bread, or the beginning of Ragnarok. In line with the consensus of that RfC, it would be helpful for you to highlight the benefits that this specific use of microformats will bring, in this specific instance. What would not be helpful would be for you to refer to the discussion above. The discussion above contains six separate editors in good standing universally agreeing that consensus does not exist for making this change, along with a further half-dozen in /Archive 3. Trying to claim that that discussion, in which you are the only unqualified supporter of the proposal, represents consensus, is Refusal to "get the point", which is a sanctionable form of disruptive editing. The preservation and development of a constructive editing community is more important than an individual user or an individual edit. Your proposal does not have to be "wrong" for it to be judged not a net benefit to the project, nor for your method of pushing for its adoption to be considered unconstructive. Happy‑melon 14:13, 30 December 2010 (UTC)

As I have said to you previously: "You failed to present a substantive objection then; and you can't or won't do so now. WP:IDONTLIKEIT is not consensus". Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:42, 30 December 2010 (UTC)

And for perhaps the fourth time, although never quite as plainly as this: the fact that you don't or won't see "substantive objections" does not equate to you having consensus for proceeding. The consensus of Wikipedia editors is that the implementation of microformats should be considered on a case-by-case basis, and should proceed where the community is satisfied that the benefits outweigh the costs. You haven't for months if not years even attempted to demonstrate "substantive benefits" to weigh. This whole issue is so teapestuous precisely because both pros and cons are so pathetically insubstantive. Much more important is the underlying behaviour. You are not working from a position of either consensus or the status quo, and the sooner you accept that and start to actually justify your position, the further you'll stay from comments which are actively disruptive. The consensus-building discussion is not waiting to end here, it's waiting to start. Happy‑melon 20:07, 30 December 2010 (UTC)

Sort key for categories that contain the template itself

WP:SORTKEY states (bolding mine):

To place entries after the main alphabetical list, use sort keys beginning with tilde ("~"). Other characters used for this purpose are "µ", commonly used to place stub categories at the end of subcategory lists; "β" for book subcategories; and "τ" for templates.

Template:Baronet-stub uses this template (Asbox), but it shows up at the beginning of Category:Baronet stubs instead of at the end. Is there a way to indicate that the sort key should be "τ"? Perhaps that should even be done for all templates that use Template:Asbox --Auntof6 (talk) 22:54, 21 August 2010 (UTC)

Error displays wikicode in article

There's apparently an error in this template that allows a parameter value that should be hidden to be displayed in articles when a non-existent image is referred to.

The following code used to be at Template:Textile-arts-stub (I fixed it there to point to an existing image):

{{asbox
| image     = Greekkey.png
| pix       = 38
| subject   = [[textile arts]] 
| qualifier = 
| category  = Textile arts stubs
| tempsort  = *
| name      = Template:Textile-arts-stub
}}

This generates:

As you can see, the picture size specification "38px" is being shown. - dcljr (talk) 01:13, 5 September 2010 (UTC)

As you're not supposed to refer to a non-existent image, i don't really see a problem. Normally in such a case, the entire filename should show up. — Edokter • Talk • 03:31, 5 September 2010 (UTC)

Thanks for pointing this out. We could make this more robust and add a simple ifexist check. Non-existent images could be highlighted in Category:Stub message boxes needing attention. — Martin (MSGJ · talk) 07:12, 5 September 2010 (UTC)

Seemed sane enough. Done. —TheDJ (talk • contribs) 09:12, 5 September 2010 (UTC)

Right, that is not something that you expect... Not possible due to cases such as | image = Flag of Finland.svg{{!}}border —TheDJ (talk • contribs) 09:29, 5 September 2010 (UTC)

I've moved the check over from main page into Template:Asbox/templatepage. Is it worth adding a border param to fix that issue? -- WOSlinker (talk) 09:32, 5 September 2010 (UTC)

I would say not. A little string thuggery in /templatepage is much cheaper than another parameter on 1.5 million pages. Rich Farmbrough, 07:53, 25 September 2010 (UTC).

I have added such code to Template:Asbox/templatepage/sandbox. Could this be implemeted? Svick (talk) 13:44, 18 December 2010 (UTC)

Done now. Svick (talk) 15:00, 26 December 2010 (UTC)

Could somebody please implement the parameter reverted here and add this to the documentation? As it is, people are sneaking the “border” specifier into any of several other parameters for stub templates of any country whose flag has white areas. ―cobaltcigs 13:41, 12 February 2011 (UTC)

Use icon= instead; you can pass a bare image there, whereas image= is preformatted. The doc also reflects this. — Edokter (talk) — 14:02, 12 February 2011 (UTC)

Please remove "Soccer icon" from the documentation

Should this be taged: {{rfctag|proj}} ?

Please remove {{Soccer icon}} from the documentation
My reason is because when trying to export {{Asbox}} with its documentation you need to include {{Soccer icon}} with all its sub-template calls or get a messy documentation.
It is also automatically included when using the cascaded export.
Because {{Soccer icon}} and those templates that are included because of this template, are not needed nor wanted for the proper functioning or understanding of {{Asbox}}, i think its best to remove the usage in the documentation.
⇐⇑©TriMoon™ Talk @ 19:49, 27 February 2011 (UTC)

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)

Why the navbar ?

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)

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)

I support Happy-Melon's suggestion of using a JS. Should be an easy script to write (no time here though). —TheDJ (talk • contribs) 19:17, 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)

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)

Now that is the correct question: is there a way to achieve the same functionality that users have come to expect, in a more elegant fashion? In this case, the answer may well be yes, and if so, that should certainly be pursued. Happy‑melon 20:54, 4 August 2011 (UTC)

For what it's worth, TB, I'm one of those "poor souls on dial-up", and I've never had a page slowing/freezing due to the links on a stub template. The length of pages like WP:AN/I and the daily WP:AFDs, though... Grutness...wha? 01:35, 5 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)

One of the problems with being a mere "end user" with little knowledge of the technical side of this, though, is that I haven't a clue what that means! :) Grutness...wha? 08:48, 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.

To be honest, I'd be a much better editor if I stopped fussing about the technical side of things myself but I just can't help msyelf ;) - TB (talk) 11:51, 5 August 2011 (UTC)

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

{{Asbox/stubtree/sandbox|England-footy-bio-stub}}

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 plainlist class to get rid of the bullets. — Edokter (talk) — 15:59, 23 November 2011 (UTC)

The present version looks okay, but perhaps left-aligned is better with bullets? — Martin (MSGJ · talk) 11:33, 24 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

• {{Academic-journal-stub}}
• {{Biology-journal-stub}}
• {{Chemistry-journal-stub}}
• {{Engineering-journal-stub}}
• {{Humanities-journal-stub}}
• {{Mathematics-journal-stub}}
• {{Medical-journal-stub}}
• {{Nursing-journal-stub}}
• {{Physics-journal-stub}}
• {{Science-journal-stub}}
• {{Social-science-journal-stub}}

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)

Bug notification

I don't know enough about templates to fix it myself, but the formatting of this template has led to a rather humorous recurring grammar error on, for instance, Template:US-poet-1900s-stub: This American poet-related article born between 1900-1909 is a stub. You can help Wikipedia by expanding it should read as This article on an American poet born between 1900-1909 is a stub. You can help Wikipedia by expanding it, unless of course the article was born between 1900-1909! elvenscout742 (talk) 08:32, 30 November 2012 (UTC)

This has now been fixed by User:John of Reading — Martin (MSGJ · talk) 10:26, 30 November 2012 (UTC)

Boarder and colour

Hi could someone add the support for boarder and colour please so that we can use colour or use a boarder please 86.159.27.221 (talk) 15:39, 23 March 2013 (UTC)

bodyclass

May we add a |bodyclass=, either by changing the current HTML from <table class="metadata plainlinks stub" to <table class="metadata plainlinks stub {{{bodyclass|}}}" or as part of the #Use of <table> proposal, above? (I've added into the sandbox verison of the latter) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:27, 28 March 2013 (UTC)

Template-protected edit request on 14 June 2014

172.56.4.245 (talk) 10:27, 14 June 2014 (UTC) Back in the 1930's there were people actually living here. So it may be unincorporated now but use to be a small town. — Preceding unsigned comment added by 172.56.4.245 (talk) 10:30, 14 June 2014 (UTC)

 Not done Request doesn't appear to be about this template. Please repost in the correct place. SiBr₄ (talk) 13:37, 14 June 2014 (UTC)

Use of <table>

This template uses <table>, which is bad for our readers using screen readers (info as to why). We should be using CSS positioning if we want to control where the icon appears.

I've created a test replacement at {{Asbox/no-table}}; here's a test of how a randomly selected stub template looks using it.

Old:

New: {{Asbox/sandbox/no-table}}

Comments? Please check for errors. — Scott • talk 17:40, 3 November 2012 (UTC)

I have no problem with changing this around. We might want to consider putting a display: inline-block on it perhaps, to improve block flow. —TheDJ (talk • contribs) 19:06, 3 November 2012 (UTC)

OK, I made a few changes. This would require a bit of style patching, and in case of IE6/7, you would have to set the 'image' to float. It would then not be centered from the block of text to right of it, but that is the the sacrifice you need to make if you want to stop using table semantics in an ecospace that still contains many browsers that are not able to understand table styling.

I think for asbox that is acceptable, but it immediately shows why we probably still cannot do this for ambox. There is simply no way you can make ambox behave as it does now on IE6/7 without seriously changing the way the thing looks or switching to a 'fixed' width layout. —TheDJ (talk • contribs) 20:22, 4 November 2012 (UTC)

Where are we with this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:15, 28 March 2013 (UTC)

It would be good to move forward with this. TheDJ, are you okay with bringing in your changes? — Scott • talk 20:32, 15 June 2014 (UTC)

@Scott: I'll look at this later today again. —TheDJ (talk • contribs) 08:29, 17 June 2014 (UTC)

Hmm, it's close, but the Navbar thing is really problematic. (whoever thought it was a good idea to make that a div instead of span deserves punishment.... —TheDJ (talk • contribs) 12:49, 17 June 2014 (UTC)

No I don't... It had to be a div because a span causes Tidy to throw a fit and bump out the embedded list. Blame Tidy instead. -- [[User:Edokter]] {{talk}} 13:30, 17 June 2014 (UTC)

For some reason, on my screen the flag and the text statement are on separate lines. The text is also not italicized but that may be intentional. Harej (talk) 18:46, 17 June 2014 (UTC)

Not really. I've made some tweaks; should look pretty close to original now. -- [[User:Edokter]] {{talk}} 20:25, 17 June 2014 (UTC)

I should have shared that. The CSS was in m User:TheDJ/common.css —TheDJ (talk • contribs) 21:37, 17 June 2014 (UTC)

Looks very good. Assuming it is compatible across browsers, I suggest implementing this. Harej (talk) 22:17, 17 June 2014 (UTC)

Changing the text

It's been years since this template has been modified, and I believe it needs a refresh. For context, I am engaged in other discussions relating to stub sorting here and here. One of the ideas I brought up involves a complete overhaul of the stub template. I am not asking for that right now because it would require some other things to happen first. Today I am asking more conservatively for a change to the text of the template. Currently the text reads:

This article [about X] is a stub. You can help Wikipedia by expanding it.

I would like to change this to:

This article [about X] is a stub. You can help Wikipedia by expanding this article. Need help?

The most significant change would be the inclusion of a link to the Teahouse so that anyone who takes the initiative to edit the article will be able to get help in case they run into a problem, instead of just giving up. My hope is that it makes editing ever-so-slightly easier for newcomers. Please let me know what you think. Thanks, Harej (talk) 04:59, 16 June 2014 (UTC)

No problem with adding the link to teahouse if people think this would be helpful. But the repeated "this article" does not read well and the current use of pronoun "it" should probably be retained. — Martin (MSGJ · talk) 08:48, 17 June 2014 (UTC)

I'll echo Martin's comments. However, I worry that potentially having several "Need help?"s in a row on multi-stub-tagged articles might look a bit odd (or imply different locations of getting help). Is there a template way of saying "if this element exists on the page already don't show it again"? — Scott • talk 08:58, 17 June 2014 (UTC)

That's actually the subject of a related conversation. I'm fine with retaining the language of the template as is and just adding the Teahouse link. Harej (talk) 11:54, 17 June 2014 (UTC)

So I guess that should be resolved first, and then we can discuss this? — Martin (MSGJ · talk) 09:53, 20 June 2014 (UTC)

CfD nomination of Template:Asbox

Template:Asbox has been nominated for deletion, merging, or renaming. You are encouraged to join the discussion on the Categories for discussion page. Sardanaphalus (talk) 09:01, 25 June 2014 (UTC)

Since this is a meta template and not a content-related stub template, I've sdeedily closed it. -- [[User:Edokter]] {{talk}} 09:50, 25 June 2014 (UTC)

Requested move 30 June 2014

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: not moved. (non-admin closure) Calidum ^{Talk To Me} 02:36, 9 July 2014 (UTC)

---

Template:Asbox → Template:Article stub – It's a line rather than a box. Sardanaphalus (talk) 08:14, 30 June 2014 (UTC)

Survey

Feel free to state your position on the renaming proposal by beginning a new line in this section with *'''Support''' or *'''Oppose''', then sign your comment with ~~~~. Since polling is not a substitute for discussion, please explain your reasons, taking into account Wikipedia's policy on article titles.

• Oppose Since it lacks borders, it might not look like a box: but it's built using the HTML <table>...</table> element, which is a block-level object, so it's a box. --Redrose64 (talk) 15:05, 30 June 2014 (UTC)
  • So it depend on whether this category is for web browsers (which see the HTML) or human beings (who see the resulting text); since this category is for humans, not web browsers, I think that your point is irrelevant. עוד מישהו Od Mishehu 07:40, 1 July 2014 (UTC)
• Oppose it will end up being directly added to articles by people who think that "article stub" means {{stub}}. Suggest {{WP stub-type meta-template}} -- 65.94.171.126 (talk) 05:19, 1 July 2014 (UTC)
  • ow about the simpler name {{meta stub}}, possibly with a dash in stead of the space? עוד מישהו Od Mishehu 07:37, 1 July 2014 (UTC)
    • I'd rather it not look like just another stub-type template. Someone could come around and think it should be attached to "meta" subjects. Considering the popcultural bias of Wikipedia, there are a lot of pop-"meta" with that. -- 65.94.171.126 (talk) 21:13, 1 July 2014 (UTC)
• Support a rename, but not this one - I think that 65.94.171.126 made a good point about this. I think that {{meta-stub}}, or something like that, would be better. עוד מישהו Od Mishehu 19:38, 2 July 2014 (UTC)

Discussion

Any additional comments:

I think that {{meta-stub}} would be better - this template is the meta template for the stub tags. עוד מישהו Od Mishehu 11:45, 30 June 2014 (UTC)

+1 That's a good idea. — Scott • talk 13:20, 30 June 2014 (UTC)

Support for something like that, but preferably in plain English without the hyphen (Template:Stub meta?) — Martin (MSGJ · talk) 13:45, 30 June 2014 (UTC)

Technically, it's in plain English already, while your suggestion isn't - "This template is a meta-stub", versus "This template is a stub meta". :) — Scott • talk 09:52, 1 July 2014 (UTC)

"stub meta" sounds much better than "meta stub", as it won't as likely be confused for a stub-type template that should be used on an article, but still I'd prefer my suggestion that completely takes it out of the running for confusion with a template usable on an article. -- 65.94.171.126 (talk) 22:48, 3 July 2014 (UTC)

• It's a meta template, do we really care ? Are we going to rename ambox to "article message box" after this ? I don't really see the need. —TheDJ (talk • contribs) 15:36, 30 June 2014 (UTC)
  • +1. Jenks24 (talk) 11:25, 8 July 2014 (UTC)

---

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Reverted change

I've just reverted an change to this template. If it was discussed anywhere then I can't find it. This change seems fairly pointless: it appear to be solely to encourage editors to type {{mammal-stub}} instead of {{Mammal-stub}}. I can't see the benefit of this. On a more general note, I believe that all additions to this template should be discussed first. — Martin (MSGJ · talk) 08:30, 16 July 2014 (UTC)

Lua conversion

• Please merge {{Asbox/sandbox}} into here. Although Module:Asbox is only the second thing I've ever written in Lua, it is pretty literal translation of wikitext into Lua so there aren't likely to be many glitches. All test cases at Template:Asbox/testcases match perfectly as far as I can tell. Be sure to edit protect the module as well. —CodeHydro 04:16, 24 December 2014 (UTC)

   Administrator note Before merging this in, templateeditor protection will need to be applied to Module:Asbox. — xaosflux ^Talk 14:17, 24 December 2014 (UTC)

  Ping to @Mr. Stradivarius:, who reviewed the module. — xaosflux ^Talk 14:19, 24 December 2014 (UTC)

Not done: It's not quite ready yet. The things that were brought up in the code reviews haven't been fixed - we should deal with those before we put this up live. Also, no matter what people think of all the Lua intricacies that were brought up in the code review, the lack of "is a" in "This article is a stub" is a very noticeable bug that will need to be fixed. — Mr. Stradivarius ^{♪ talk ♪} 14:40, 24 December 2014 (UTC)

• Oops, can't believe I missed that typo, though at least it's an easy fix. Anyhow, I think we've beat out all the bugs now that we can pre-release. Some minor things may or may not crop up post release, but there shouldn't be any more significant display issues or typos. Sorry for jumping the gun last time! Do you agree User:Mr. Stradivarius? —CodeHydro 17:48, 24 December 2014 (UTC)

The Lua version massively increases the codebase and complexity. I'd like to know what advantages this bring to editors to justify this; something I feel needs to be documented on a mandatory basis. -- [[User:Edokter]] {{talk}} 09:53, 28 January 2015 (UTC)

• @Edokter: Don't mistake a larger codebase for inefficiency. My Module:RoundN's codebase is 25KB versus Module:TeamBracket's 5KB and yet when generating something like Module_talk:RoundN/testcases/5, my module does it in about 0.3-0.5 seconds, while TeamBracket takes 1.3-1.7 seconds. I just converted Template:Asbox/templatepage and recorded the stats of the original versus the modularized version:

Original:

CPU time usage	0.259 seconds
Real time usage	0.330 seconds
Preprocessor visited node count	88/1000000
Preprocessor generated node count	0/1500000
Post-expand include size	9803/2097152 bytes
Template argument size	10/2097152 bytes
Highest expansion depth	5/40
Expensive parser function count	4/500
Lua time usage	0.126/10.000 seconds
Lua memory usage	1,003 KB/50 MB

Module

CPU time usage	0.136 seconds
Real time usage	0.193 seconds
Preprocessor visited node count	41/1000000
Preprocessor generated node count	0/1500000
Post-expand include size	4724/2097152 bytes
Template argument size	0/2097152 bytes
Highest expansion depth	3/40
Expensive parser function count	3/500
Lua time usage	0.058/10.000 seconds
Lua memory usage	1.21 MB/50 MB

As you can see, it does it in about half the time. While 0.1 seconds may not seem huge, multiply that by 1.8 million pages that transclude Asbox and that's 20 days less processing time. —CodeHydro 15:20, 28 January 2015 (UTC)

• I may also point out 'Post-expand include size' is cut in half; i.e. it spits out half as much garbage as the old template... why? Because the old template had a tendency to spit out the exact same category multiple times due to it's inability to check whether a category was previously included. The module checks for redundant categories before output and removes them, reducing the amount of çlean-up to be done by the mediawiki engine post-include. The cost is slightly higher Lua memory usage which is tiny fraction of the post-expand garbage avoided. —CodeHydro 15:34, 28 January 2015 (UTC)

That wasn't really my question; note I asked about advantages "to editors". Were the reasons you cite not also fixable in template code? -- [[User:Edokter]] {{talk}} 16:43, 28 January 2015 (UTC)

The speed benefit will reduce load on the job queue, which does benefit editors (after the initial spike caused from the conversion itself). The increase in speed should be a sufficient reason to convert the template to Lua. — Mr. Stradivarius ^{♪ talk ♪} 23:48, 28 January 2015 (UTC)

What increase in speed? It's such a small template that nobody will notice - or care about - the difference in the time taken to save and re-render the page. This is not like citation templates, where at the time of conversion they had reached more than 100 parameters and a lot of conditional coding, and the cumulative processing time was noticeable. It is not unfeasible to use several dozen - even hundreds - of citation templates on a single page, and they all add up. Stub templates are not in the same league: few articles have more than one or two stub templates, occasionally three. I have seen as many as six, but such cases are extremely rare. --Redrose64 (talk) 00:25, 29 January 2015 (UTC)

The increase in speed on a single page probably won't be noticeable. I'm talking about the overall increase in speed on the site, which should result in a speeding up of jobs on the job queue. And even just for a single stub template, a speed increase of 0.1 second per page may make the page save feel more responsive. I haven't read much on the subject, but apparently even small differences in load time can make a significant difference in users' perception of a site's speed. — Mr. Stradivarius ^{♪ talk ♪} 01:48, 29 January 2015 (UTC)

Since you mention the job queue, I take it you're thinking about what happens when one of the existing stub templates is amended. This doesn't happen very often, a few times a week (small compared to the 36,890 stub templates that exist), usually when we decide to create a single dedicated stub category where previously two or three upmerged categories were used. See e.g. Wikipedia:WikiProject Stub sorting/Proposals/2014/December#Speedys which resulted in this edit and this edit which together with edits to the six templates in Category:Nicaraguan sportspeople stubs, put just over 200 pages into the job queue. WP:DWAP#Editors still have a role to play. --Redrose64 (talk) 10:43, 29 January 2015 (UTC)

@Edokter: Some benefits:

• Module tells you specifically which category parameters are invalid. Original template only says 'Please double-check the parameters |category=, |category1= and |category2=.'
• Template is limited to only 3 categories because it requires explictly declared param named; module can have unlimited categories as long as param names are in the form category#=
• The module expands |demo= to allow previewing of error categories in article/template space in the sandbox. Original template doesn't show categories in the sandbox, so you don't see the Category:Stub message templates needing attention warnings until after it goes live.

In any case, I could add more features, but I've stuck mostly to what what available other than a few obvious improvements while the module is in early release. Once we've determined that the module will handle all situations correctly, then can we experiment with radical new features. —CodeHydro 23:26, 28 January 2015 (UTC)

I don't see why the first and third cannot be achieved with normal template code (Wiki markup). As for the second, is there a demonstrable need to allow for more than three categories? --Redrose64 (talk) 23:29, 28 January 2015 (UTC)

• @Redrose64: Please take a look at Template:Asbox/testcases#Ombox_messages_and_error_sorting. That's only about half the total possible error categories that can appear from {{Asbox/templatepage}}. To attempt to make a demo category in the sandbox for each individual category would be maddening and extremely hard to maintain if the format was ever changed. Since all category output in the module is handled in a single function, if ever we decide to rename the error categories, we would need only edit one line versus a dozen lines in normal template code —CodeHydro 23:48, 28 January 2015 (UTC)

How often do stub templates with errors come up? A few times a week, maybe. When errors are found in stub templates, how many have more than one simultaneous error in their coding? Very few, and normally only because either a vandal has been at them, or they were assembled by a novice. Either way, those of use with experience - such as myself, Dawynn (talk · contribs) and others - can simply open up the stub template page, and spot the error quickly. There won't be any more than thirteen parameters, and often just six or seven. Not as if we have myriads of code to wade through. --Redrose64 (talk) 00:25, 29 January 2015 (UTC)

Fair enough. But what is the advantage of using template code? The only possible reason I can see to use slower template code is that more editors know MediaWiki than Lua. However, editing is a non-issue as there have been an average of 3 edits per year since 2010 (of these nearly half were for Lua conversion in the past week). The output of this template has reached a mature form, and the being able to generate that output faster is much more important than making it easier to update it. While we may need to revamp this template some years in the future, the odds are good that most editors with the skill to edit the original template will also know Lua by then —CodeHydro 16:29, 30 January 2015 (UTC)

Unlimited categories

Since this now supports unlimited categories with the new module, what do editors think about creating a new maintenance category such as Category:Stub message templates with more than three categories to make it easier to find potentially over-categorized templates? Perhaps only flag if 5 or more just to be a little more lenient? —CodeHydro 16:29, 30 January 2015 (UTC)

• @MSGJ, Edokter, Redrose64, Od Mishehu, Wbm1058, and Mr. Stradivarius: I would like to get a consensus soon as I am about ready to implement another update (see #Obscure errors), so I'm pinging most folks who have posted on this talk page recently. (Would like to do both updates in one go as each separate update puts pages back on the job queue and slows down the site.). Should we or should we not add a new maintenance category for stub tags with more than X categories? Note that adding a count would not perceptibly affect speed, as this count would only be performed on the template page (i.e. not article space). Even if there were 10 million stub templates (there are only about 25,000), this check would add less than a second to the total time. —CodeHydro 21:15, 3 February 2015 (UTC)
  • Yes, I think we have too many stub templates and stub categories. So if this would discourage too much of a good thing, OK. Not that I would be keen to patrol such a category and fix such errors that don't directly effect the encyclopedia. Wbm1058 (talk) 22:38, 3 February 2015 (UTC)
  • I don't really mind either way about this. It's probably best to ask the editors who are actively involved in stub sorting, i.e. at Wikipedia talk:WikiProject Stub sorting. I've left a note there. — Mr. Stradivarius ^{♪ talk ♪} 23:16, 3 February 2015 (UTC)

function test() local t, c = {'category1', 'category2', 'category3'}, os.clock() for k = 1, 10000000 do if #t > 4 then table.insert(t, 'too many cats') end end return os.clock() - c end
=test()
0.232829718

Categorization of stub tags doesn't work on creation

For some reason, when I've been creating new stub tags, when I save them the first time they don't show up in the category. This is always fixed by saving it the second time without editing it (null edit). I saw this both with {{Arizona-sport-stub}} (created as upmerged to 2 populated categories) and to {{NYC-sport-stub}}. Any idea why that's happenning? עוד מישהו Od Mishehu 17:53, 3 February 2015 (UTC)

@Od Mishehu: Did this start recently (i.e. after the Lua conversion) or has it always been this way? —CodeHydro 19:49, 3 February 2015 (UTC)

(ec) That's normal. When you save a page, certrain actions like linking the categories, are placed in the job queue. Updating the categories are fairly low-priority. A null edit will force them to be updated. -- [[User:Edokter]] {{talk}} 19:52, 3 February 2015 (UTC)

It did start recently. And while I know about the job queue, I also know that when I save a page, it should instantly update everything, including informing the categories that it's there. (And, as I saw with {{Colorado-sport-stub}}, the stub tag thinks it's in the category.) עוד מישהו Od Mishehu 21:05, 3 February 2015 (UTC)

@Edokter: From Od Mishehu's initial post at Wikipedia:Village pump (technical)/Archive 134#Categorization of stub tags doesn't work on creation, I understood them to mean that the new stub template itself is not showing in the category. I can confirm that before Lua-isation, a new stub template which included e.g. |category=Foo stubs would always show in Category:Foo stubs the instant that it was saved. Current behaviour I don't know about, because I've not created any new stub templates recently. --Redrose64 (talk) 12:09, 4 February 2015 (UTC)

Normally, the job queue is small enough such that even low-priority task such as categorization are done within seconds, or at least faster than the time it takes you to reload the category page. However, the recent conversion to Lua added 1.9 million pages to the job queue in front of re-categorization. Note the current live version of the Module outputs the exact same wiki-category markup as the original, so there really isn't anything that can cause this delay. (Though the #Obscure errors fix, to be released very soon, will remove hidden unicode chars from the markup, but this is expected to speed up, not slow down categorization). In short, this lag is temporary and may crop up again occasionally whenever a major update to this (or any other highly transcluded template) is performed, regardless of whether this template was Lua-based or not. As long as you can see the proper category links on the bottom of the page, don't worry about what appears in the category itself. I would even suggest not performing null edits as that is like cutting in line on the job queue (and puts maintenance above article output). See the doc about |demo=art or |demo=doc and the examples at Template:Asbox/testcases if you need to preview sort keys (all sort keys except E and W are demo-able, as per the original Template which skips the check on |name= when demo is enabled) —CodeHydro 14:40, 4 February 2015 (UTC)

It's not a job queue issue. We're not talking about the categorisation of pages which transclude the stub template, but the categorisation of the template itself. For example, {{Arizona-sport-stub}} is in Category:Arizona sport stubs. --Redrose64 (talk) 19:33, 4 February 2015 (UTC)

• I just brought turned Template:Asbox/templatepage/sandbox back to the pre-module version and tested it on Arizona-sport-stub. The original puts it in Category:Arizona sport stubs, so I fail to see why that is an issue??? The only difference I could see that was not intentional is that the module re-arranges flips the order of the two categories, which shouldn't really matter since the template is still in both cats. —CodeHydro 23:07, 7 February 2015 (UTC)

I've just tested this by putting the code on Template:NYC-sport-stub on Template:Testing-NYC-sport-stub and the category Category:New York City sport stubs was there from the first save. I'll now delete the test version. — Martin (MSGJ · talk) 19:45, 4 February 2015 (UTC)

So that's pretty good evidence that the delay is a job-queue issue. —CodeHydro 23:07, 7 February 2015 (UTC)

No, it is not. If you alter a template such that the categorisation of the template itself changes, that change goes nowhere near the job queue and shows up instantly. It's the same as if you added a category to an article. If you alter a template such that the categorisation of the pages that transclude that template gets changed, then the job queue becomes involved - the transcluding pages are added to it, not the template itself. --Redrose64 (talk) 00:10, 8 February 2015 (UTC)

Obscure errors

This fix and this fix removed these two templates from Category:Stub message templates needing attention, where they were listed under the key:

• S: category names that don't end with "stubs"

I could not figure out why they were given this error key, or what the problem was. The way I fixed them was to find a similar template from another state that worked and model my changes after the working template. So, what exactly is the problem, and can the error key be made less obscure? Thanks, Wbm1058 (talk) 13:26, 4 January 2015 (UTC)

There was a hidden unicode character lurkin in there. See this diff and you won't notice it there either. -- WOSlinker (talk) 14:47, 4 January 2015 (UTC)

Thanks, and thanks for fixin' the rest of those! Wbm1058 (talk) 15:42, 4 January 2015 (UTC)

@Wbm1058: This kind of problem is surprisingly common, I fix several whenever I visit Category:Stub message templates needing attention. It's almost always a U+200E left-to-right mark (LRM) immediately after the word "stubs", and it happens when people copypaste the name of the stub category from somewhere else. Wikipedia has an annoying habit of sprinkling LRMs where they aren't needed, mainly on page histories (four per entry), user contrib lists (three per entry), and watchlists (five per entry), but in other places too. If you go to a page where LRMs are used, mouseover the category name just slightly too far, copy to clipboard and paste somewhere else, you might copy a LRM as well without noticing. There's one at Wikipedia:WikiProject Stub sorting/Proposals/2015/January#Cincinnati, Ohio sport stubs, immediately after "Cincinnati Reds season stubs".

Here's how to check it in a stub template. Go to this old version, click "edit", position your mouse pointer more than a character's width to the right of the text "Ohio sport stubs" and click. The cursor will appear to be positioned immediately after the word "stubs"; but press ← Backspace once - the last letter "s" is not deleted. When you find one of these "type S" problems in Category:Stub message templates needing attention, edit the stub template, and try to backspace out the last "s" of the |category= param in the above manner - if it gets removed, put it back. Do the same with |category1= and |category2= if these are non-blank. --Redrose64 (talk) 17:12, 4 January 2015 (UTC)

Thanks for the detailed explanation. I've run into these LRMs over at Wikipedia:Requested moves as well (see Wikipedia:Requested moves/Closing instructions § Bot considerations). Now I know the easy way to fix these. – Wbm1058 (talk) 17:32, 4 January 2015 (UTC)

• @WOSlinker, Wbm1058, and Redrose64: Just updated the module so that unicode characters which that do not are not either a letter, number, punctuation, or space are removed before attempting to verify category existance/naming (though note that the unicode char are still outputted in the result just in case such cats do exist? We'll have to watch the stub message attention cat to see if a lot of templates start appearing under 'N') Thus, this 'obscure error' should no longer be an issue. See Template:Asbox/testcases#Hidden unicode char for proof of concept. (PS: Avoiding hidden unicode chars is something that would have been impossible to do in normal template code, Redrose ;) ) —CodeHydro 23:18, 30 January 2015 (UTC)

You're missing the point. There should be exact correlation between the category that is declared in the template and the true name of the category. If they don't match, it needs to be reported as an error. If one or the other is being fiddled, then errors that should be reported will not be. --Redrose64 (talk) 23:24, 30 January 2015 (UTC)

Actually, you're missing the point. I'm not removing these chars for now because I do not want it break any categories. If after a few days we find that no 'correct' categories appear under sortkey N, then this replacement will be done for the output as well. In other words, we're first testing if the category name cleaning pattern is good and won't prevent any 'proper' categories. Once we know it's safe, then we'll change the output. Also note that hidden unicode chars don't break categories anyhow. —CodeHydro 23:28, 30 January 2015 (UTC)

The job queue for the cleaning pattern update is now empty. Judging from the utter lack of false positives for 'non-existing' categories, it is evident that it is safe to implement the cleaning pattern on the output. (This should further improve performance as it saves the MediaWiki engine the effort of performing the clean). I will implement the update in a few hours after I've completed testing for another module on which Asbox is dependent. (Planning to synchronize the updates to minimize double-updates on the same pages.) —CodeHydro 20:26, 3 February 2015 (UTC)

@Codehydro: I agree with Redrose64. The removal of characters should be reverted. Jackmcbarn (talk) 23:32, 8 February 2015 (UTC)

@Jackmcbarn: I don't think Redrose64 is opposed to the removal of hidden unicode from output. I believe his concern was regarding a mismatch between output and error sorting, which was done only for the sake of testing the cleaning pattern's safety. (By doing the cleaning after output, inappropriate char removal would only cause temporary false positives in the stub error category but leave articles unaffected). No such false patterns occurred and thus the pattern is determined to be safe. The recent bug involving non-categorization is unrelated. —CodeHydro 23:55, 8 February 2015 (UTC)

Extra line break in the text displayed by some stub templates

Is the recent Lua-ization of this template responsible for the extra line break in the text displayed by some stub templates, such as those on Bop (magazine)? Thanks! GoingBatty (talk) 21:05, 8 February 2015 (UTC)

I see that both of those stub templates ({{Entertainment-mag-stub}}, {{Teen-mag-stub}}) use the |note= parameter, which is unusual: there aren't many stub templates that have that. Have you come across the problem on any that don't use |note= ? --Redrose64 (talk) 21:14, 8 February 2015 (UTC)

@Redrose64: I checked many other pages with stub templates, and didn't find any other examples. I did see that {{Mag-stub}} (on Gala (magazine)) uses the |note= parameter and looks fine - maybe the text is just a little shorter so it doesn't need to wrap? GoingBatty (talk) 02:39, 9 February 2015 (UTC)

For me, there is no wrapping in either one. I do see a larger gap - which might be a blank line - at Bop (magazine) that isn't there on Gala (magazine). I notice that {{Mag-stub}} has an image, the other two don't. I don't even know why I'm bothering investigating this, since it clearly worked before Lua-isation - I do not understand Lua code one bit, and I'm not the only one. I vote that we put the template back to exactly how it was before. It worked, and more importantly we knew how it worked, and there was nothing wrong with it that we couldn't handle ourselves. There should be a demonstrable need to convert to Lua, and I see nothing above that shows that there is any need at all. --Redrose64 (talk) 11:58, 9 February 2015 (UTC)

• Just click this link if you want to see exactly how Bop (magazine) would have been rendered with the pre-Lua Asbox (for a quick comparison, just blank the Sandbox prefix field to see Lua version). As far as I can see, the output is identical (other than the pre-Lua version having slightly slower stats on the bottom) —CodeHydro 14:00, 9 February 2015 (UTC)

I've viewed the output in both Firefox & IE, and it's only going on two lines for Firefox. So appears to be a layout bug in Firefox. There is a slight difference, in the lua version, the br is inside the span tag and outside in the non-lua version. -- WOSlinker (talk) 15:48, 9 February 2015 (UTC)

See this screenshot. The upper half is Bop (magazine), the lower half is this link. Notice that although the gap between the templates (ringed in blue) is exactly the same, the gap within the templates (ringed in red) has increased by 20px. You should also see that there is no word-wrapping. Firefox 35.0.1 --Redrose64 (talk) 16:06, 9 February 2015 (UTC)

• Thanks for the screenshot! It's fixed now. Yeah, bloody non-standard Firefox... even very old versions of I.E. don't break that way. What happened was that I had moved a BR tag from in front of the note span tag to inside as the first item of the span for the sake of streamlining the code. Tested in at least 3 browser environments and none presented that bug, but I guess should have tried FF. Good job! (PS: One good thing that came out of the Firefox bug is that the Module is even faster than before. The part that connected to the bug was written months ago when I had a lot less experience with Module codes, so it was good to revisit it.) —CodeHydro 20:46, 9 February 2015 (UTC)

Thanks to everyone who worked on this - it looks much better in Firefox 35.0.1 now! The lesson for me is that I should check multiple browsers and report which ones I'm using. GoingBatty (talk) 01:29, 10 February 2015 (UTC)

Code review

Moved from Module talk:Asbox

 – {{3x|p}}ery (talk) 20:32, 23 February 2019 (UTC)

@Codehydro: Thanks for writing this! I have a few comments about the code:

• Looking at the test cases, the module is missing the words "is a" from "this article is a stub".
• Strings like '\'\'This ' may be easier to read using double quotes, i.e. "''This ". There is no speed penalty from using double quotes in Lua, unlike some other languages (PHP, I'm looking at you).
• The long line that starts '\'\'This ' .. (args.subject and args.subject .. ' ' or '') .. (args.article or 'article') would probably be more readable if it used string.format, i.e. something like the following, but with all the variables filled in:

buffer = string.format(
	"''This %s%s is a %s[[Wikipedia:stub|stub]].''",
	args.subject and args.subject .. ' ' or '',
	args.article or 'article',
	args.qualifier and args.qualifier .. ' ' or ''
)

• Slightly related - in Lua strings are indestructible, so concatenation is relatively inefficient. When doing 'a' .. 'b' .. 'c' .. 'd', Lua must store all the intermediate strings in memory, so the strings 'cd' and 'bcd' (concatenation is right-associative) stay in memory until they are cleaned up by the garbage collector. In this module it's probably not worth worrying about, but for large numbers of concatenations it is better to use string.format or to make an array of strings and concatenate them with table.concat. You might want to look into Module:OutputBuffer, which makes this easy to do. Also, mw.html objects already use a buffer like this, so you can just use html:wikitext to add new strings to it.
• frame:preprocess('Template talk:Asbox/Archive 4') == args.name would be better done as args.name and mw.title.getCurrentTitle() == mw.title.new(args.name). It normalises the user-input page name, and uses less resources than frame:preprocess. In general, the most resource-intensive things in a module are fetching arguments from frame objects, and expanding wikitext. If you absolutely have to expand a template or parser function, then frame:callParserFunction and frame:expandTemplate are faster than frame:preprocess. In the past, mw.title.new was expensive, but this has recently changed, so this type of normalisation is now the preferred method of comparing page titles.
• For performance reasons, it would be better to load Module:Navbar directly by using require, rather than going through frame:expandTemplate.
• page.nsText == '' is probably better as page.namespace == 0 - while the '' name probably won't change, the numbers definitely won't, and are more portable.
• You use require('Module:Arguments').getArgs(frame, {wrappers = 'Template:Asbox'}) twice. While Module:Arguments is cached, the result of getArgs isn't, so it would be better just to use the args variable the second time round.

Sorry, that's a lot to take in, but I hope it's useful. :) Best — Mr. Stradivarius ^{♪ talk ♪} 07:00, 24 December 2014 (UTC)

• @Mr. Stradivarius and Jackmcbarn: Thanks for you help the both of you. Hope it wasn't too painful to read the code considering it's been less than 24 hours since I even saw my first line of Lua. I actually originally did args = args but decided a second call of Module:Arguments would be safer since I do not yet have a full understanding of all Lua's quirks. Don't worry about overwhelming me; I'm a firm believer in immersion as a rapid way to acquire a language ;) The more complex, the more I learn —CodeHydro 17:41, 24 December 2014 (UTC)

  @Codehydro: I added a few more notes. Jackmcbarn (talk) 17:59, 24 December 2014 (UTC)

• @Jackmcbarn: Thanks for your latest comments. I've addressed most of the issues you raised. Converting Asbox/templatepage is probably a task that could be saved for a later date; it's transclusion count is a drop in the bucket compared to other higher priority templates. As for the main and _main split, I'm leaving that because User:Mr. Stradivarius implemented that and, as a non-admin, it isn't my place to decide which admin's opinion to take. In any case, do you see any other reason not to release? —CodeHydro 19:05, 24 December 2014 (UTC)

Asbox/templatepage merged

Moved from Module talk:Asbox

 – {{3x|p}}ery (talk) 20:32, 23 February 2019 (UTC)

• @Mr. Stradivarius and Jackmcbarn: Happy new year! Module now includes everything needed for Asbox/templatepage. I think all issues have been worked out, though p.templatepage is one very long string concatenation, but that's kind of the nature of the original template. Any thing else before we release this puppy? —CodeHydro 00:52, 5 January 2015 (UTC)

  @Codehydro: Sorry for the very late response, and thank you for your work on this! I've made some slight tweaks to the module comments, and all the test cases seemed to be working correctly, so I've gone ahead and put this up live. Could you update the documentation with the new features (e.g. the demo parameter)? Also, although I didn't find anything when I checked, it is probably worth looking through some of the live transclusions as well to see if you spot any errors. Best — Mr. Stradivarius ^{♪ talk ♪} 00:17, 28 January 2015 (UTC)

  Also, it looks like Template:Asbox/templatepage needs to be converted to use the module as well, but I'll leave that to you, as it's only semi-protected. Thanks again. :) — Mr. Stradivarius ^{♪ talk ♪} 00:22, 28 January 2015 (UTC)

Categorization of stub tags doesn't work on creation

Moved from Module talk:Asbox

 – {{3x|p}}ery (talk) 20:32, 23 February 2019 (UTC)

For some reason, when I've been creating new stub tags, when I save them the first time they don't show up in the category. This is always fixed by saving it the second time without editing it (null edit). I saw this both with {{Arizona-sport-stub}} (created as upmerged to 2 populated categories) and to {{NYC-sport-stub}}. Any idea why that's happenning? עוד מישהו Od Mishehu 14:40, 1 February 2015 (UTC)

Prevent categorization in user sandboxes?

It seems that there has recently been an explosion of stub templates listed on Wikipedia:Database reports/Polluted categories. Would it be possible to update this template so that stub templates only add categories in mainspace, and not in userspace? Thanks! GoingBatty (talk) 03:39, 7 February 2015 (UTC)

It is true that pre-Luaisation, the Asbox template would only categorise (into Category:All stub articles plus the cats defined by |category= |category1= |category2=) when used in mainspace; however, the recent change to this behaviour has enabled me to detect misuse, as with these ten bot edits. --Redrose64 (talk) 13:20, 7 February 2015 (UTC)

Then we'll need to add {{polluted category}} to all the stub categories to make Wikipedia:Database reports/Polluted categories usable again. Before I submit an RFBA, does anyone have a bot already approved to do this? Thanks! GoingBatty (talk) 15:55, 7 February 2015 (UTC)

I have a fix ready for this. Just doing a little more testing before I release it. I apologize for any inconvenience as I failed to anticipate userspace articles when coding the module. It will take a few days to a week for the patch to reach every userspace page due to the high number of transclusions. —CodeHydro 23:16, 7 February 2015 (UTC)

That last sentence is a fair description of pages being put in the job queue. --Redrose64 (talk) 00:12, 8 February 2015 (UTC)

Misuse on categorry pages can be found with this. -- WOSlinker (talk) 13:09, 8 February 2015 (UTC)

I have reverted Codehydro's patch, as it prevents ctegorization from articles, too. There's no need for a bot to add {{polluted category}} to all the stub categories - I did it with one edit. עוד מישהו Od Mishehu 13:28, 8 February 2015 (UTC)

• Brought the patched patch back. Basically, the module has two functions that deal with categories: one that find the category parameters, and one that outputs the categories. Long story short, I moved the 'find' function so that it would only be executed in in article space, but in trying to move the 'output' function to a place unreadable by user space, I failed to place it in a position that would be executed in article space. A single misplaced line of code that wasn't caught in tests since all testcases were in template space, which was obviously unaffected by my actions for article/user space. I've created new tests to prevent bugs like this from slipping through the cracks in the future. —CodeHydro 14:20, 9 February 2015 (UTC)

@Od Mishehu and Codehydro: There are still over 100 stub categories showing up on Wikipedia:Database reports/Polluted categories. Are there any other actions that should be taken to prevent this? Thanks! GoingBatty (talk) 03:01, 28 February 2015 (UTC)

@GoingBatty: Well, the job queue is fully cycled but looks like a few categories got left behind. There isn't really anything that can be done from Module:Asbox. For example [1] shows User:Revjlamont in the list, even though the user page itself does not show the category. All you can do is null edit user pages in each polluted category, perhaps via a bot —CodeHydro 03:16, 28 February 2015 (UTC)

@Legoktm and Joe Decker: Would either of you be willing to run your null edit bot over these user pages to fix the incorrect categorization? Thanks! GoingBatty (talk) 03:46, 28 February 2015 (UTC)

Removal of hidden characters

Moved from Module talk:Asbox

 – {{3x|p}}ery (talk) 20:32, 23 February 2019 (UTC)

@Codehydro: Why did you add code to remove all hidden characters? Jackmcbarn (talk) 04:41, 8 February 2015 (UTC)

• @Jackmcbarn: See Template talk:Asbox#Obscure_errors —CodeHydro 15:14, 8 February 2015 (UTC)

Removal of mainspace categories

Moved from Module talk:Asbox

 – {{3x|p}}ery (talk) 20:32, 23 February 2019 (UTC)

@Codehydro: Mainspace articles are no longer appearing in stub categories??? See Wikipedia:Help_desk#Joe_Cox_.28cricketer.29 -- John of Reading (talk) 08:55, 8 February 2015 (UTC)

• @John of Reading: Oh dear... it's an easy fix at least... while it's no excuse, the Template:Asbox/testcases mislead me into thinking that the categories would work in article space. I had reviewed all testcases, userspace, and several actual stub templates. Thought I checked article space, but I guess I must have misremembered my check on the 'article emulation' testcase as having done on it on actual articles. (The article emulation check showed categories because template space behavior was unaffected). —CodeHydro 15:25, 8 February 2015 (UTC)

Editnotice

Moved from Module talk:Asbox

 – {{3x|p}}ery (talk) 20:32, 23 February 2019 (UTC)

@Jackmcbarn, Mr. Stradivarius, and Od Mishehu: I created {{Editnotices/Page/Module:Asbox}}. As I've never made an edit notice before, I'd like your opinions about the procedures listed. It's a 24 step check, and that's only counting 'repeat the last four steps' as one step. Too complex? Not thorough enough? I try to follow all these steps every time I make an edit, but it's easy to forget one... the last bug come from my misrembering a single step. —CodeHydro 03:06, 9 February 2015 (UTC)

@Codehydro: Instead of having to make a bunch of temporary saves, why not use TemplateSandbox straight from the edit window? Jackmcbarn (talk) 03:21, 9 February 2015 (UTC)

@Jackmcbarn: Mainly because it was easier to code the links with specific template preloaded than to describe which template codes to test and on what namespace. Edit notice was getting long and I felt I needed to dumb it down :P —CodeHydro 03:53, 9 February 2015 (UTC)

IMO, it's more complicated now than it would be if you used the edit box one. Jackmcbarn (talk) 04:05, 9 February 2015 (UTC)

If it's not too much to ask, would you mind showing me an example of how it should be done? It's probably my inexperience in writing edit notices that I don't see how you way makes it easier to explain. —CodeHydro 13:26, 9 February 2015 (UTC)

Quite apart from the totally unnecessary signature (it's not a discussion page), it's WP:TLDR. No editnotice should require you to Page Down to reach the edit box. A typical editnotice is this one and there aren't many that are much larger. --Redrose64 (talk) 15:26, 9 February 2015 (UTC)

@Codehydro: I simplified it quite a bit. The remaining instructions still result in everything important being tested. Jackmcbarn (talk) 18:56, 9 February 2015 (UTC)

@Jackmcbarn: Thanks! It does look a lot better —CodeHydro 22:09, 9 February 2015 (UTC)

Template-protected edit request on 23 August 2016

"Herry Tangiri" Name Correction Ankitszone (talk) 20:51, 23 August 2016 (UTC)

Note: Yes, the name was incorrectly spelled in the article M.S. Dhoni: The Untold Story, and thank you for catching that, but what makes you think something in this template needs to be changed?  Rules of enpagement Paine  21:32, 23 August 2016 (UTC)

Visual editor or Markup?

Perhaps having the editing link default to Visual editor would be sensible. The people who this template is targeted to are unlikely to be comfortable with markup. Recommend: veaction=edit in stead of action=edit. T.Shafee(Evo&Evo)^talk 12:12, 15 June 2017 (UTC)

Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. action=edit should load the VisualEditor for people with it enabled. But even if it doesn't work like that, this is a change which definitely requires consensus (given the volatility of the English Wikipedia relative to VE). Izno (talk) 12:40, 15 June 2017 (UTC)

Requested move 17 July 2018

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: not moved. (non-admin closure) KSFT ^(t|c) 19:51, 24 July 2018 (UTC)

---

• Template:Asbox → Template:Stub template
• Module:Asbox → Module:Stub template
• Module:Asbox stubtree → ?

– Clearer template name -- this doesn't create a "box" of any sort, also expand the unnecessary abbreviation of "stub". {{3x|p}}ery (talk) 18:55, 17 July 2018 (UTC)

• Comment: I agree "asbox" means nothing intuitively, but would "Template:Stub template" not cause confusion with Template:Stub? What about "Template:Stub box" or "Template:Stub-detailed"? jamacfarlane (talk) 20:46, 17 July 2018 (UTC)

  Oppose both of those names: "Stub box" isn't right because this isn't a box, and "stub-detailed" seems to me like it would be the template you use on an article that one needs to explain why is a stub. {{3x|p}}ery (talk) 21:07, 17 July 2018 (UTC)

  I misunderstood. I thought it was a template used on an article that is a stub. I don't oppose your proposal. jamacfarlane (talk) 02:13, 18 July 2018 (UTC)

• Comment A means article, and S means stub, and box is the rest. Christian75 (talk) 09:55, 18 July 2018 (UTC)

  I understood what the name meant when I began this move request, but think it is inaccurate, overabbreviated, and unclear and should be renamed. {{3x|p}}ery (talk) 14:20, 18 July 2018 (UTC)

• Oppose - We should have one naming system for the boxes (which this template used to be too) and not randomly omving them around. Christian75 (talk) 09:55, 18 July 2018 (UTC)
• Note: notified Wikipedia_talk:WikiProject_Stub_sorting — xaosflux ^Talk 11:47, 18 July 2018 (UTC)
• This is a meta template/module, that most users will never, ever see. So.. does it really matter ? I'd prefer to keep the family (ambox, tmbox, imbox, mbox etc) intact. —TheDJ (talk • contribs) 14:20, 18 July 2018 (UTC)

  This isn't part of that family -- it's a template that happens to have a similar name even though it has an orthogonal function. {{3x|p}}ery (talk) 14:30, 18 July 2018 (UTC)

• Oppose because it would be unnecessary; the title isn't reader-facing. Jc86035 (talk) 14:23, 18 July 2018 (UTC)

  And thus it is a bad idea because... There is no reason that non-reader-facing templates should be allowed to have unclear names. {{3x|p}}ery (talk) 14:28, 18 July 2018 (UTC)

  @Pppery: Because you want to move a module without leaving a redirect, and the module is used on two million pages. What the module is called doesn't really matter because it's not supposed to be directly used in articles. In any case, the text right at the top of the template documentation explains exactly what the template does and why it's named such, and it does technically generate a box (table) even if it doesn't have a border or a background. There are also 87 templates and 35 modules on other WMF wikis named "Asbox". Jc86035 (talk) 15:19, 18 July 2018 (UTC)

  "Stub template" also isn't the clearest name, partly because it's not particularly obvious what "stub" means to the hypothetical new user who doesn't understand the jargon used to classify article development levels. Jc86035 (talk) 15:58, 18 July 2018 (UTC)

• Oppose It's not used in articles, except indirectly - this is the core around which all 36,890 stub templates are built. You may be thinking of {{stub}}, which is occasionally used in articles - by people who are not aware of (or can't be bothered to find) those specialised stub templates. --Redrose64 🌹 (talk) 19:49, 18 July 2018 (UTC)
• Oppose no improvement for readers, transparent to most editors - but has large usage, that it does not draw a visible border isn't a big deal to me. — xaosflux ^Talk 21:32, 18 July 2018 (UTC)

---

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Helper stub

Moved from Module talk:Asbox

 – {{3x|p}}ery (talk) 20:32, 23 February 2019 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Rejected. Consensus opposes the template. See Wikipedia:Templates_for_discussion/Log/2015_November_23#Template:Helper. The reason why they opposed it was because: Other help templates are available (and used), and talk pages exist for users to ask questions if they do not want to directly contact a WikiProject. Was closed by Primefac. The comment below is now obsolete. Closing to discourage recreation.--Mr. Guye (talk) 00:45, 25 April 2017 (UTC)

---

{{Helper stub}} by User:Buaidh is a good idea, providing the following message:

For help with this stub template or to suggest changes, please contact WikiProject Stub sorting

Clicking on the link opens a new section at WT:Stub sorting. I would think this could be a useful addition to this template/module.

All the best: Rich Farmbrough, 20:49, 27 November 2015 (UTC).

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The 223rd line of the module

Moved from Module talk:Asbox

 – {{3x|p}}ery (talk) 20:32, 23 February 2019 (UTC)

alt= should be deleted, otherwise imagealt won't work: :wikitext(args.icon or ('[[File:%s|%spx|alt=%s]]'):format( args.image or '', args.pix or '40x30', args.imagealt or 'Stub icon' )) --Химик1991 (talk) 17:41, 17 November 2015 (UTC)

Question

About Module:Asbox - how exactly does it check the stub's name parameter? I mean like where in the code and how easy would it be to add such functionality to other templates? Thanks, --DannyS712 (talk) 03:43, 4 April 2019 (UTC)

DannyS712, My guess is the part where it says: "Checks for valid name;" ;) —TheDJ (talk • contribs) 08:24, 4 April 2019 (UTC)

@TheDJ: Reading through that, I have absolutely no idea how it works. Can you help? --DannyS712 (talk) 02:21, 5 April 2019 (UTC)

Table usage

Granted, this template was created in 2007, when the internet was a lot different, but why is this template still using tables in the year 2019? The stub notices are not tabular information, where there is a correspondence between a header and content. Instead, it's merely a thumbnail and then normal text. Tables should not be used for formatting purposes. CSS is more than capable of it these days. Opencooper (talk) 03:30, 25 April 2019 (UTC)

Maybe you could look at Template_talk:Asbox/Archive_4#Use_of_<table> and see if any further work is needed. -- WOSlinker (talk) 06:53, 25 April 2019 (UTC)

WOSlinker, Opencooper a re-evaluation of that should be simple to do I think and I encourage anyone to pick it up. But it's work and someone needs to put in the time to really understand the work to be done. That replacement now at least needs conversion to a Module and the CSS should probably be split out into TemplateStyles (it's not like other templates are using this styling (as far as i'm aware)). —TheDJ (talk • contribs) 13:15, 25 April 2019 (UTC)

"note" parameter

The documentation page does not provide an example of intended and/or legitimate usage of the {{{note}}} parameter. Can anybody think of one? I can't. But I do see that in at least one case it's being used to promote a WikiProject group. ―cobaltcigs 23:04, 6 August 2019 (UTC)

"pix" parameter

I've recently seen stub graphics as large as 100px. The sizing feature too should be disabled for consistency purposes. ―cobaltcigs 21:29, 8 August 2019 (UTC)

Template-protected edit request on 5 September 2019

Mt._Gilead_Baptist_Church needs to be changed from Mt. Gilead Baptist Church to Mt. Gilead Christian Church. I am the current minister and am writing a history of the congregation. If possible I would like to expand the historic information once I complete my work. Please let me know what I may need in order to do this.

Harmon, Robert. "Mt. Gilead Christian Church". Mt Gilead Christian Facebook Page. Retrieved 5 September 2019. Brother.robbie (talk) 15:32, 5 September 2019 (UTC)Robert Harmon

@Brother.robbie:  Not done: this is the talk page for discussing improvements to the template {{Asbox}}. Please make your request at the talk page for the article concerned. --Redrose64 🌹 (talk) 16:21, 5 September 2019 (UTC)

Visible graphic characters removed from category names

Despite code comments to the contrary, Module:Asbox removes visible Unicode characters such as the graphic symbol "↔". So I have modified the module on my own fork (which is intended to be as close to Wikipedia as possible, but no closer), by simply adding my special character into [^%w%p%s↔]. Unfortunately Scribunto does not have a character class for graphics. Is there a MOS guideline forbidding such characters? Couldn't find it... Dpleibovitz (talk) 19:52, 30 January 2020 (UTC)

Template-protected edit request on 30 August 2020

The template has a small problem on mobile view, on some phones the image often resized to smaller size, I can see the effect on the article Bear Monument (viewed with Galaxy S6). To fix the problem, we need to add noresize class into this template, see the new source code at Module:Asbox/sandbox. -- Great Brightstar (talk) 05:28, 30 August 2020 (UTC)

To editor Great Brightstar: ? please link to the article where you see the effect. I cannot find it on enwiki. P.I. Ellsworth  ed. ^put'r there 13:10, 30 August 2020 (UTC)

OK. --Great Brightstar (talk) 13:56, 30 August 2020 (UTC)

I was seeing a tiny image to the left of the text in the mobile view (iOS Safari) at Template:SaxonyAnhalt-struct-stub and the other stub template that is used at Bear Monument. I implemented the fix suggested in the sandbox, and it appears to have fixed the problem. – Jonesey95 (talk) 00:42, 31 August 2020 (UTC)

Navbar position

I've got a sandbox edit (diff) which moves style attributes to new templatestyles (Template:Asbox/styles.css), and also moves the navbar to prevent it from overlapping text. The navbar is invisible by default, but can be made visible by user CSS. See Template:Asbox/testcases. Please let me know if you see any issues. Matt Fitzpatrick (talk) 15:09, 27 February 2021 (UTC)

Interaction between Asbox and Infobox

Following a discussion at WT:FOOTY#Francisco Wagsley, I have worked out that is there is an Asbox level with part of an Infobox that there is some strange behaviour. Any links with the infobox that are level with the Asbox will not be clickable, and if you try to select the content within the infobox and move into the same region, then text outside the infobox will become selected. Is this something that is known about, and if so is there anything that can be done about it? As an example, I created User:Spike 'em/sandbox/fw as a copy of an article exhibiting the problem and cut out as much as possible, and used subst to get down to the lowest level of template / module. Spike 'em (talk) 17:26, 11 March 2021 (UTC)

@Spike 'em: It's not specific to either asbox or infobox. The problem is one of a conflict between two divs, one being full-width (in this case, the asbox) and the other being absolutely-positioned (the infobox), which are trying to occupy the same portion of the screen. Only one of them can be on top. The area occupied by the infobox is obvious, because of its border; you can reveal the edges of the asbox div by styling it, such as by placing this CSS rule

/* reveal area occupied by an asbox */
div.asbox {
  background-color: #efefff;
  border: 1px solid blue;
}

into Special:MyPage/common.css. Then visit the problem article, and you should find that the asbox background now obscures part of the infobox, including the links that you refer to above. The normal asbox has no background, so it's transparent; but that doesn't mean that the background isn't there. --Redrose64 🌹 (talk) 09:39, 12 March 2021 (UTC)

Redrose64, this should be fixable by adding overflow:hidden to the asbox css style definition, to force it to create a new block formatting context (just like we do for headings) —TheDJ (talk • contribs) 12:25, 12 March 2021 (UTC)

@Redrose64:, I had a play with that, and indeed the asbox div does sit on top of the infobox. Is there anyway to make it go behind, given that the table within it resizes based on the presence of the infobox (so the text within wraps rather than overwriting the infobox)? I removed the asbox class from the div and can then access the links again, even though the div is still as wide as the page. Spike 'em (talk) 12:29, 12 March 2021 (UTC)

Or, based on the suggestion from TheDJ, I added .asbox{overflow:hidden} to the style tag just before the div, and that created a box just around the text and left the infobox unaffected. Spike 'em (talk) 12:33, 12 March 2021 (UTC)

And finally, I changed my common.css to

div.asbox {
  overflow: hidden;
}

and that fixes all the problematic articles. Spike 'em (talk) 13:02, 12 March 2021 (UTC)

@Spike 'em: I don't know what you mean by I added .asbox{overflow:hidden} to the style tag just before the div - which style tag is that? The MediaWiki software does not allow use of <style>...</style> tags, although they would indeed be used to enclose CSS rules - if they were whitelisted. --Redrose64 🌹 (talk) 10:20, 13 March 2021 (UTC)

I inspected / amended the html in chrome to test it directly and then amended my .css settings as mentioned. I'm not an expert on this, but it does seem that what TheDJ suggests will fix this problem. Spike 'em (talk) 10:53, 13 March 2021 (UTC)

Hello, just visiting from Module talk:Adjacent stations/Amtrak#Klamath Falls station where we saw the same issue. I agree that modifying the overflow property for asbox resolves the issue and it does feel like the right solution. Mackensen (talk) 13:18, 14 March 2021 (UTC)

I have added Template:Asbox/sandbox/styles.css and tested on pages in my own sandbox which are copies of the pages where the issue has been noticed (User:Spike 'em/sandbox/fw and User:Spike 'em/sandbox/KFS). I've checked the testcases page and all looks ok in there, but I did notice that when testing in my own sandbox that having both the asbox/sandbox and plain asbox on the same page caused both to work properly (I guess the .css attributes are additive). Spike 'em (talk) 10:34, 15 March 2021 (UTC)

Spike 'em, correct. I think we can make the edit request.

Please apply the following change to Template:Asbox/styles.css: diff —TheDJ (talk • contribs) 12:29, 15 March 2021 (UTC)

To editors TheDJ, Spike 'em, Redrose64 and Mackensen:  done, and thank you all very much! P.I. Ellsworth  ed. ^put'r there 18:18, 15 March 2021 (UTC)