Template talk:Asbox

Sorting of the stub templates themselves within their own stub categories

Could be

1. by tempsort parametr
2. standard * or space
3. Regardless of tempsort

Thoughts are to sort all by space. Rich Farmbrough, 18:29 26 September 2007 (GMT).

Metastub and Metapicstub

Yes I am aware of {{Metastub}} and {{Metapicstub}}. Rich Farmbrough, 08:23 27 September 2007 (GMT).

Other features possibilities please add to list

Template possibilities

1. a note field (to be trancluded to articles) <-- definitely needed
2. sfd parameter
3. date parameter
4. categorise template in a template category - or include "whatlinkshere" target. <-- definitely useful to help find new stubs - second option probably preferred by WSS
5. Support more than one categories explicitly.

   Second cat added. Rich Farmbrough, 13:20 27 September 2007 (GMT).

6. Remove conditional on template topsort per WP:WSS

   Rich Farmbrough, 11:40 28 September 2007 (GMT).

7. Add the ability to apply a border to the image (will generally be used for flags)

Retrofit

1. Standard header and/or footer on stub templates (not to be transcluded).

Maker template

1. subst: to create an Asbox call, plus any appropriate clichés.
2. includes Category:New stub template to help discover new stub templates.

Rich Farmbrough, 08:23 27 September 2007 (GMT).

Purpose

Copied (not verbatim) from User talk:Grutness

The purpose is to resolve a number of issues with existing stub templates, by

1. allowing modifications across the family of templates
2. allowing standard approaches in particular:
   1. making all templates part of their own class with a sort order of " ".
   2. allowing all templates to support a common sort-order syntax
   3. putting all templates in a category of stub templates if required
   4. allowing simple tests to identify/overrule image size
   5. getting stub boxen to line up better
3. avoid or reduce new stub templates being code which are broken.

I can very simply retrofit this to at least 95% of existing stub templates, and with a small amount of work to the rest.

Incidentally my idea would be to leave details of style and semantics in the hands of those that are expert in stubs.

Rich Farmbrough, 07:36 27 September 2007 (GMT).

Additional benefits

• Also will make discovery of new stub types easier.
• Will make discovery of substituted template boxen easier (any occurrence of the text "Asbox" in main space).
• At the same time as the retrofit, can make any other consistent changes to stub templates. (E.G add link to WP:WSS, advice nto to subst, etc. at top.
  • These changes might be better within the template anyway, in the unlikely event they are desired.
• Consistency will allow for future changes and simpler scanning for problems/features of boxen.

Rich Farmbrough, 08:36 27 September 2007 (GMT).

Status

• Tested in userspace
• Tested on half a baker's dozen score of stub templates.
• Floated at WP:WSS
• Piloted on couple of hundred stub templates.

Rich Farmbrough, 09:47 27 September 2007 (GMT).

To do

• Await more comments/changes  Done
• Implement round 1 of changes
  1. note field  Done
  2. remove conditional topsort  Done
  3. change default image size?  Done (Alai)
• User space/sandbox test.  Done
• Move to pilot  Done
• Involve more ppl?
• See if any more changes forthcoming
• Y. rinse and repeat
• N. start implementation.

Rich Farmbrough, 11:47 28 September 2007 (GMT).

Message

Please add {{pp-template}}. — redmond barry 02:11, 19 October 2007 (UTC) {{editprotected}}

{{pp-template}} is already in an includeonly tag on the (unprotected) /doc subpage as of me checking this request. It appears on the template page as needed. Nihiltres^(t.l) 03:17, 19 October 2007 (UTC)

Request

I think this should have the "expanding it" plain linked.   jj137 ♠ Talk 23:12, 2 December 2007 (UTC)

Me too,

<span class="plainlinks">[{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} expanding it]</span>

should work. — str4nd ☕ 15:50, 25 May 2008 (UTC)

Interwiki

Hello, Although I want to add an interwiki link into Template:Writingsystem-stub, it uses Template:Asbox. In this case, may I add a code as <noinclude>[[ja:Template:Grammatology-stub]]</noinclude>? Thanks. --Nightshadow28 (talk) 06:37, 5 January 2008 (UTC)

whatlinkshere

I just don't see what the Template:Asbox/whatlinkshere dummy page does that http://en.wiki.x.io/w/index.php?target=Template%3AAsbox&offset=&limit=5000&title=Special%3AWhatlinkshere&namespace=10 doesn't do, without requiring either a dummy page or the code to link to it. Since stub templates are generally not placed in other templates, there is no need to worry about separating out retransclusion. Caerwine Caer’s whines 23:13, 5 February 2008 (UTC)

Use

Is this template a standard of use for stub templates? I only saw it for the first time today. Are there plans on making it's use on all stub-templates like the other {{ambox}}, {{mbox}}, etc. templates are used for message boxes? —Borgarde^talk 05:45, 5 November 2008 (UTC)

There is an ongoing discussion about the creation of a new, simpler stub template here --Blooper (Talk) 13:51, 5 November 2008 (UTC)

Date parameter

Why? Stub templates are not dated. Should not be dated. Have a model coding that is covered by a long-standing set of guidelines, that is absent any concept of dating. This is the sort of "mission creep" that makes me nervous about the introduction of this sort of essentially-pointless, single-point-of-failure, resource-hog, job-queue-clogging, category-update-slowing metatemplate. This was introduced on a "pilot" basis, and seems to have achieved absolutely no consensus whatsoever. Time to cut our losses and TFD? Alai (talk) 05:15, 6 November 2008 (UTC)

Category suppression

Resolved

I have fiddled with this, but cannot suppress the category. Leaving the parameter blank simply creates a blank category. This template needs a category suppression method so that is can be listed without placing the page in the category. --—— Gadget850 (Ed) ^talk - 19:21, 15 January 2009 (UTC)

Never mind: I peeked at the code and noticed that it does namespace detection and includes the category only in articles. --—— Gadget850 (Ed) ^talk - 20:14, 15 January 2009 (UTC)

Third category

{{editprotect}}

This template needs an option for a third category, which I have provided the code for in the sandbox. Borgarde (talk) 11:16, 4 March 2009 (UTC)

 Done. Martin^msgj 13:41, 4 March 2009 (UTC)

Image borders

{{editprotected}} Could someone please check for the presence of an argument named border and, if present (and not equalling no), add a border to the image? — OwenBlacker (Talk) 18:37, 7 March 2009 (UTC)

Could you confirm that the version in the sandbox does what you want? There are some examples in testcases to compare. — Martin (MSGJ · talk) 21:32, 7 March 2009 (UTC)

External link icon on internal link

{{Editprotected}} Can an administrator remove the external link icon from the internal link? This can be done by changing "[{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} expanding it]" to "<span class="plainlinks">[{{fullurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} expanding it]</span>". -- IRP ☎ 22:46, 2 April 2009 (UTC)

I have to disagree. I think that the different type of link makes it easier to see that clicking it does something different than clicking on other Wikilinks. For new users this may help distinguish the link from just being to another article on how to expand articles as opposed to actually expanding the one they are looking at. I'd like to see more discussion before having this edit made. --CapitalR (talk) 01:31, 3 April 2009 (UTC)

I have posted an edit request at Wikipedia:Administrators' noticeboard#Request (please tell me if I posted in the incorrect place). Personally, I cannot understand why you disagree with my request. If the link title is "expanding it", then it is not possible for it to be confused with an article (especially due to the context that it is in). The icon is designed to indicate "external link", not a certain type of internal link. Even if you don't agree, do you understand my point? Do you think I'm missing something? -- IRP ☎ 02:49, 3 April 2009 (UTC)

I see what you're saying, but I don't agree that it is what all editors might think when seeing the link. If I saw the "expanding it" as an internal link, I would think it would point to something like this: expanding it as opposed to actually editing the article. Even though the edit page is an internal link, I don't think that that necessarily implies it should appear like a normal page link. I see some utility to the different link style (especially for users new to Wikipedia editing), and I think that utility may be why it has been like this for many years. That said, it's just my personal opinion and I will gladly go ahead and make the change if consensus agrees with you. --CapitalR (talk) 03:32, 3 April 2009 (UTC)

If I'm understanding this correctly, I don't think it would be an improvement. For instance, in {{Agri-stub}} the little icon after 'expanding it' would go away. In that situation, this icon signals to the reader that they are taking some action, not just viewing another normal wiki page. EdJohnston (talk) 17:44, 3 April 2009 (UTC)

I do not believe that you are understanding this correctly. The icon indicates "external link" not "action". What indicates "action" is that the link title is "expanding it". Expanding it is an action. It cannot possibly be confused with a page. -- IRP ☎ 20:23, 3 April 2009 (UTC)

I think removing the arrow is the correct approach. We have a very clear semantic distinction between the three types of links. A bluelink is an "internal link" in the proper sense of the word, a link to a page that the user may wish to read. The other link colour is for 'out of the ordinary' links that are still on-wiki: these may be interwikis, interlanguage links, or links to nonstandard pages like the edit screen. The addition of the arrow has the clear semantic distinction of "this link goes off wikimedia", a true "external link". As such, the correct appearance for the edit link here to convey the correct semantic connotations is the pale blue colour without the arrow. Happy‑melon 20:45, 3 April 2009 (UTC)

If you are trying to remove the external link icon, the correct way to do so is insert "<span class="plainlinks">" (without quotes) before the link and "</span>" (without quotes) after the link. -- IRP ☎ 21:08, 3 April 2009 (UTC)

Or just add that class to the table itself. This is what is proposed, no? Happy‑melon 21:11, 3 April 2009 (UTC)

I haven't seen a proposal like that, but yes, that's another way to do it. -- IRP ☎ 21:14, 3 April 2009 (UTC)

I agree that this should be done. To be perfectly clear, this would be the proposed edit. —Ms2ger (talk) 12:35, 4 April 2009 (UTC)

{{Editprotected}} Administrator, see the discussion above. -- IRP ☎ 17:38, 4 April 2009 (UTC)

All done. --CapitalR (talk) 21:34, 4 April 2009 (UTC)

Image borders (2nd try)

{{editprotected}}

Could someone update the template with the sandbox version? It adds the "border" parameter (which defaults to off), everything else is the same. Testcases page renders as expected. GregorB (talk) 10:57, 27 April 2009 (UTC)

Any link to discussion that this is needed/desirable? Consensus? — Martin (MSGJ · talk) 11:24, 27 April 2009 (UTC)

Well, there's none - other than no opposition, I guess (see two sections above). The feature is both useful (since it tries to emulate what current stubs do) and non-disruptive (it does not change the behavior of existing transclusions). Nevertheless, for the time being, I'll comment out the editprotected request to allow time for possible objections. GregorB (talk) 12:29, 27 April 2009 (UTC)

Okay, I'll be happy to add the code if there are no concerns or alternative suggestions in a couple of days time. Regards, — Martin (MSGJ · talk) 12:33, 27 April 2009 (UTC)

You can also use icon= instead of image=, which allows for custom image markup. — Edokter • Talk • 12:44, 27 April 2009 (UTC)

True, although not really obvious... I needed the border so that I can use a flag, but now I see that flags can be wrapped into {{flagicon}} (or {{border}}, if need be - duh!). So I guess border param is not needed after all... GregorB (talk) 13:07, 27 April 2009 (UTC)

Ah, for flags? I had a quick look before and I couldn't find a stub that was using a border.
Hmm, looking at {{US-stub}} and {{Germany-stub}} they aren't using a border either. Which ones are there? And should they be using a border in the first place? :)
Amalthea 14:12, 27 April 2009 (UTC)

I think pages with borders should just use "icon"... There's not too many, FWIW. –xeno^talk 15:09, 4 August 2009 (UTC)

Still ... if {{Chile-sport-bio-stub}}, {{Chile-struct-stub}}, {{Chile-scientist-stub}}, {{Chile-botanist-stub}}, and {{Chile-writer-stub}} can do without border, I'd think {{Chile-bio-stub}} can as well. Dito {{Maryland-newspaper-stub}} et al vs. {{Maryland-school-stub}}.
We (=you) can of course fix them all, but as long as we're that inconsistent I don't think it would be a problem to drop all borders. Amalthea 16:20, 4 August 2009 (UTC)

I agree... One can barely discern the border... And, well, these flags don't HAVE small 1-pixel borders around them in the first place, so it's kindof strange of us to add one. –xeno^talk 17:45, 4 August 2009 (UTC)

• Any objections to me eliminating the borders? –xeno^talk 21:32, 8 August 2009 (UTC)

boilerplate

This template has the class boilerplate. I don't think we have any such class anymore on en.wp. As far as I can gather, it stems from when all the boilerplate (copy and paste) messages, were turned into templates a long time ago. I doubt it's usefulness, and think we should remove it. —TheDJ (talk • contribs) 00:35, 4 May 2009 (UTC)

mbox

The CSS I propose for asbox (currently hardcoded into the sandbox template

table.asbox {
    clear: left;
    background: transparent;
}
.asbox th.mbox-text, 
.asbox td.mbox-text {            /* The message body cell(s) */

    font-style: italic;          /* Text is italic */
    padding: 0em;           /* We don't need padding to the left */
    width: auto;                 /* Use normal width */

}
.asbox td.mbox-image {           /* The left image cell */
    padding: 0em;                /* no padding */
}

possibly add also.

table.navbox + table.asbox,
p + table.asbox,
table + table.asbox,
div + table.asbox,
ol + table.asbox,
ul + table.asbox { 
  margin-top: 1em;   /* Margin at top of stack */
}

Your thoughts please ? —TheDJ (talk • contribs) 14:21, 4 May 2009 (UTC)

Didn't test it, but for stub templates I'd also add a "p + table.asbox { margin-top: 1em; }". Or 0.5em. I didn't find it important with the navboxes since paragraphs already have a .5 margin-bottom, but stubs offer a less clear separation from the text, and are much more likely to be placed directly beneath a paragraph. Amalthea 15:31, 4 May 2009 (UTC)

Good point. added. —TheDJ (talk • contribs) 15:36, 4 May 2009 (UTC)

Was this implemented or am I missing in in the CSS? ---— Gadget850 (Ed) ^talk 14:27, 19 August 2009 (UTC)

It was all reverted because at the time there was no consensus to implement changes to asbox —TheDJ (talk • contribs) 14:58, 19 August 2009 (UTC)

last mbox test. Would probably require quite some work again to bring it up to date with the current asbox template. —TheDJ (talk • contribs) 15:01, 19 August 2009 (UTC)

It would be nice to have the same top margin as the navboxes; this woul eliminate the current requirement for two blank lines before the asbox. ---— Gadget850 (Ed) ^talk 16:15, 19 August 2009 (UTC)

numbered params

What is the use for the numbered paramaters that are discussed on the documentation page ? I seems to be more confusing than useful ... —TheDJ (talk • contribs) 14:28, 4 May 2009 (UTC)

It seems that they are intended to offer easier extensibility of the asbox meta stub template which could immediately be used in articles, without having to change any of the actual stub templates.
It's a neat idea, but I'd tend to remove it, too. First, I really don't expect that we ever want to offer parametrized stub templates where that pass-through would make sense. Second, even if we do, it would probably be easy to AWB through all stub templates then. Amalthea 15:24, 4 May 2009 (UTC)

Removed from documentation —TheDJ (talk • contribs) 15:07, 20 May 2009 (UTC)

Options of this template

I have been thinking about how best to continue with this template. I have the following ideas, and I would like it people would comment.

1. Get rid of 1-4 params in the documentation. Too confusing, any introduction of new params, might as well be done with AWB or something.
2. I want to deprecate the subject and qualifier options, in favor of a new "article" option. The reason would be to bring it in line with metastub and metapicstub, as well as "simplifying" the usage of this template.
3. I'm in doubt about the image options. On one hand, the image + pix options allow for greater control of imageusage, but the icon option might be simpler and is the same method is used for ambox and friends.
4. I have removed the "date" option. It didn't seem like this was a convention being used, and can easily be reintroduced when needed.
5. How do you recruit an army to convert all the stubs ? :D

—TheDJ (talk • contribs) 18:38, 9 May 2009 (UTC)

I've initially wanted to read up on all the issues that were brought forward before replying here, but from what I can tell already:

1. Yep, per above.
2. Alright with me. Qualifier and Subject would make sense if there were no article, to enforce a common style, but since there is we don't win anything with both options
3. I'd propose using {{image|{{{image}}}|40x30px}}, which accepts both full image syntax as well as only the name of the image (with namespace or without).
4. no opinion
5. /me steps forward. I'd image that, since most stubs have been based on one substed template, most could be converted (semi-)automatically.

Since, as it looks, the signature changes are not backwards compatible, it might be easiest to create a new template {{smbox}} and set it up from scratch there. Amalthea 15:03, 20 May 2009 (UTC)

Agree with all this. And I'll sign on for the crusade: as Amalthea says, much of the conversion could probably be done with a bot.

The category syntax on this template looks a bit wierd; maybe it's just the way it's laid out, though. Happy‑melon 15:24, 20 May 2009 (UTC)

It seems the intent is multiple categories (up to 4), with a catkey of Pagename, except when it is transcluded from a template, in which case defaultsort to ' ' (so the stub template itself is at the top of the stub category), or tempsort# in cases where specified (in case multiple stubs sort into the same category). —TheDJ (talk • contribs) 17:30, 20 May 2009 (UTC)

We need some namespace detection or other means of category suppression so that we can refer to a stub template without adding the categories. ---— Gadget850 (Ed) ^talk 22:52, 20 May 2009 (UTC)

So that when we have

, the category is not added to this page? As you can see, this is already implemented as well :D —TheDJ (talk • contribs) 22:56, 20 May 2009 (UTC)

That is what I get for looking at the documentation and not at the markup. Good— this was one of my previous beefs with this template. Next time you are in the code, please fix the invalid <br />. I give up: what is <s />? ---— Gadget850 (Ed) ^talk 01:23, 21 May 2009 (UTC)

Both taken care of. —TheDJ (talk • contribs) 14:00, 21 May 2009 (UTC)

Was <s /> an error or a valid? ---— Gadget850 (Ed) ^talk 15:55, 21 May 2009 (UTC)

I couldn't figure it out, but since it was used for a "whatlinkshere" trick that is no longer required, I decided to remove it. —TheDJ (talk • contribs) 16:03, 21 May 2009 (UTC)

I am looking at writing documentation for stub templates and I would like a more rigorous method of category supression than just using namespace detection. Would there be any problem to using category=no to achieve this? This would allow examples to be shown without inappropriate categorisation. — Martin (MSGJ · talk) 22:02, 20 August 2009 (UTC)

Override category

Is there a way to over-ride the category, e.g. for sample display? –xeno^talk 12:48, 27 August 2009 (UTC)

Not at this time. See martin's last remark at Template_talk:Asbox#Options_of_this_template. —TheDJ (talk • contribs) 13:07, 27 August 2009 (UTC)

Thanks. Sections combined. –xeno^talk 13:16, 27 August 2009 (UTC)

The namespace detection is great, except when templates are being shown as examples on template pages... i.e.

• Template:Coord missing/sample 1 I would like to subst the asbox to take it out of Category:Stub message boxes needing attention but then I would need to add a category otherwise it would just move from "E" to "C". –xeno^talk 13:16, 27 August 2009 (UTC)

I suggest using category=no as proposed above. Of course, any templates where this is needed will need to pass this parameter in a different way, for example

category=History stubs

would need to become

category={{{category|History stubs}}}

On pages such as Template:Coord missing/sample 1, these are a little tricky, but I think we could use something like

{{Arizona-geo-stub<noinclude>|category=no</noinclude>}}

Any better solutions? — Martin (MSGJ · talk) 16:12, 2 September 2009 (UTC)

Actually yes, I think I have a better solution:

• Move the template categorisation to /templatepage. Therefore templates will only be categorised if name=FULLPAGENAME.
• Remove the warning for "erroneous name", and just leave the check for "undefined name".

— Martin (MSGJ · talk) 08:29, 3 September 2009 (UTC)

Proposed code is on Template:Asbox/sandbox. I had a slight rethink because the erroneous name check seems to be useful so it would be a shame to lose it. Therefore I've added a new parameter |demo= which can be set to suppress any categories and warnings. Anyone care to check the code for me? — Martin (MSGJ · talk) 15:31, 3 September 2009 (UTC)

Stub templates: the future

Sorry to ask this, but before doing all this work, would it be possible to take a step back and be sure that it's worth it. What is the purpose of these stub templates? Are they still necessary and do we need that extra bit of encouragement to get people editing stubs rather than other types of articles. Would it worthwhile consulting more generally about whether they are still wanted? I suppose there are kilobyes of discussion about this somewhere, so feel free to point me towards it :) — Martin (MSGJ · talk) 21:13, 20 May 2009 (UTC)

It might make more sense to get rid of a lot of the stub templates... I think that having them marked is good, but the uber-subcategorization seems excessive to me. –Drilnoth (T • C • L) 21:40, 20 May 2009 (UTC)

This should probably be discussed on the Village Pump (proposals), and/or at WikiProject Stub Sorting. But I think that stubs in their current form will live on for quite some time, although perhaps reduced a tad. —TheDJ (talk • contribs) 00:53, 21 May 2009 (UTC)

Agree— templates are aids to technical issues, but should not attempt to set guidelines or policies. ---— Gadget850 (Ed) ^talk 13:27, 21 May 2009 (UTC)

Category proposal

Please see Wikipedia:Village pump (proposals)#Message box categories. Thanks. Dragons flight (talk) 07:01, 3 June 2009 (UTC)

We should remove the nbsp's from stub templates

Because whatever good they're supposed to do, they don't even show up in the right place, see red outlines in screen-shot:

http://i40.tinypic.com/sljibd.jpg

I corrected the first one, but the second one uses this protected sub-template. — CharlotteWebb 14:24, 4 July 2009 (UTC)

I've removed it for now. I guess it was to put a small space between the image and the text. Is there a better way to do this? — Martin (MSGJ · talk) 11:15, 24 July 2009 (UTC)

I wondered whether the icons are actually a good thing. Presumably anyone who is able to add to a - for example - chemotherapy stub, knows what chemotherapy is without having a a picture to illustrate it - and knows that the stub is about chemotherapy. When I created {{Asbox}} my focus was on making sure it could handle the varieties of stub-templates that existed at that time - I didn't want people saying "it doesn't support this slightly oversized image, therefore it is useless" and the like. However the main value of stub templates is the categorization, I feel, allowing specialists to see where their help can be best used. Rich Farmbrough, 17:59, 24 July 2009 (UTC).

Navbar

I think it would be useful for the maintainers of stub templates to have a navbar somewhere on it. Obviously this is not needed for the general reader and should be hidden by default. On {{WPBM}} this was achieved by using style=display:none; and then allowing individual editors to override this in their monobooks. I'm not an expert, but I'll look into it if anyone thinks this is a nice idea. — Martin (MSGJ · talk) 11:20, 24 July 2009 (UTC)

I'm not quite sure I follow. How would having this template help with navbar functionality? And wouldn't {{PAGENAME}} work just as well (if not better)? Perhaps tell me how to view the navbar on WPBM and that might explain it. –xeno^talk 17:11, 31 July 2009 (UTC)

No, since {{PAGENAME}} always evaluates to the current page (i.e. the page the stub template is on) instead of to the name of the stub template. That's why navboxes, e.g. {{Britney Spears singles}} pass the template name explicitly in |name= to allow building the v·e·d links, like with {{v|d|e|template={{{name}}}}}.
Amalthea 17:41, 31 July 2009 (UTC)

So if I understand correctly people (who unhide it) will see a v*d*e on the stub templates? The problem that I see with this is that it's hidden with javascript (right?) that not all users may have enabled. I also am not a fan of the re-drawing delay. But if others agree it will be useful I can certainly have the bot add this parameter during the conversions. imo, the stubs won't change that much so I don't think it's particular necessary. –xeno^talk 17:52, 31 July 2009 (UTC)

No it is hidden with CSS. I'm not sure it's useful. But it sure can be done. That's not hard. Just a lot of bot work to add the name to all templates. —TheDJ (talk • contribs) 18:22, 31 July 2009 (UTC)

The bot's already going to be there (at least for the ones that haven't been converted yet), so if it's useful, it's not a problem for me to add it (just subst:pagename in the name= field). I just don't think it's necessary, at least not for stub types. I suppose we could do it for future proofing. –xeno^talk 18:25, 31 July 2009 (UTC)

I'm adding the parameter as I convert them. I see the benefits, even if we don't use it for v*d*e at present, the parameter may be useful in the future. –xeno^talk 23:06, 31 July 2009 (UTC)

I did play around with some options for a navbar in the sandbox (but I think TheDJ's latest version has erased it). I think it would be look best and be least intrusive on the far right. Alas I was unable to achieve this. If anyone can help, it would be appreciated. — Martin (MSGJ · talk) 22:06, 20 August 2009 (UTC)

Could someone check my code on the sandbox (this version) please? In order to see it you have to add

.stub .navbar {display:inline !important;}

to your monobook.css file. An example template using it is Template:Arizona-geo-stub/sandbox which produces:

Thanks in advance — Martin (MSGJ · talk) 19:07, 9 September 2009 (UTC)

Font is a little large for me; I think font-size:smaller; would be better. Technically the implementation is fine. Happy‑melon 22:33, 9 September 2009 (UTC)

Made it smaller. — Martin (MSGJ · talk) 07:13, 10 September 2009 (UTC)

Lovely. Happy‑melon 08:54, 10 September 2009 (UTC)

Okay, I'll implement this soon. — Martin (MSGJ · talk) 11:48, 10 September 2009 (UTC)

Hooray!

I gave up trying to get this template accepted back in.. whenever it was. I am pleased that an apparently obvious idea now seems to have some champions. And that it has been improved and brought up to date. Well done to all concerned. Rich Farmbrough, 17:11, 24 July 2009 (UTC).

Category Sorting

{{editprotected}} Could the copy in the sandbox be copied over to live. The change is to allow for better sorting within the categories for the templates. Thanks. -- WOSlinker (talk) 14:03, 1 August 2009 (UTC)

What is the current behavior? Does it end up sorting by article id or something like that? --- RockMFR 03:22, 2 August 2009 (UTC)

It's so that the templates at the start of the stub categories are sorted alphabetically rather than in some sort of random order. See Category:European actor stubs for an example. -- WOSlinker (talk) 07:05, 2 August 2009 (UTC)

Done. --- RockMFR 13:07, 2 August 2009 (UTC)

OK the way this was supposed to work was that the templates themselves were only included in in their categories if the appropriate tempsort was defined. I believe the reason was that I was implementing Asbox without changing anything in the stub templates behaviour, and different stubs templates at that time worked in different ways. I also believe I used AWB to convert about 20% of the stub templates and had some method for inserting the correct values into the tempsort keys. This is probably no longer relevant, but the documentation needs to catch up. Rich Farmbrough, 00:12, 3 August 2009 (UTC).

Yes, it looks like the docs don't match what the template is doing. I've also converted a few templates over to use asbox but didn't use the tempsort parameter. -- WOSlinker (talk) 06:25, 3 August 2009 (UTC)

I believe stub sorters almost always wants the templates included in their respective categories. I saw an edit summary to this effect, anyway. –xeno^talk 13:59, 4 August 2009 (UTC)

Alt text

User Xenobot its providing all the stub template icons with alt text. Can a default be simply inserted into {{Asbox}} ? Rich Farmbrough, 13:48, 4 August 2009 (UTC).

This is already done [1]. Xenobot is just converting to asbox rather than hard-coding the alt-text. –xeno^talk 13:52, 4 August 2009 (UTC)

Ah yes, just checking the code, before dropping you a note and I see that you have done it! Then you have replied to me here before I can! You are fast today. Incidentally it's a shame you had to re-invent the reg-exen to convert to asbox, it was all running sweet as a nut, but that was some time and several hard discs ago. Rich Farmbrough, 13:55, 4 August 2009 (UTC).

eh, don't sweat it. It was a useful learning exercise for me. I ran into a few issues where people would place code up in the middle of the standard business, which would get lost in the conversion, but I think I've all-but-fixed this issue. –xeno^talk 14:03, 4 August 2009 (UTC)

Slight breakage

In the doc page the example stub templates are showing empty categories with sort order. This is probably due to the changes above. Rich Farmbrough, 18:09, 4 August 2009 (UTC).

Maintenance categories

Can we add maintenance categories... split asbox'en into

1. Using icon=
2. Using image=
3. Using imagealt=
4. Using neither icon nor image
5. Lacking category=
6. Lacking name=
7. Erroneous name= (does not match fullpagename)
8. Lacking subject=/qualifier=/article=?

? –xeno^talk 18:11, 9 August 2009 (UTC)

I went ahead and did this. Feel free to prettify the code, etc. –xeno^talk 16:24, 12 August 2009 (UTC)

I took up your invitation to improve the code :) By the way, I can understand why we need categories to track missing things, but what is the purpose of categories such as Category:Stub message boxes using image parameter? — Martin (MSGJ · talk) 10:10, 18 August 2009 (UTC)

The last edit broke the maintenance categories, they are now appearing on all articles instead of just templates. Borgarde (talk) 10:36, 18 August 2009 (UTC)

I've undone it for now, since with a glance I saw no trivial way to fix it and keep the prettification. :) Amalthea 10:56, 18 August 2009 (UTC)

Sorry about that. I feel very stupid now. — Martin (MSGJ · talk) 11:00, 18 August 2009 (UTC)

Don't worry about it, and feel of course free to try again (in the sandbox;)). The job queue is amazingly short right now anyway, so ... :) Amalthea 11:06, 18 August 2009 (UTC)

The reason this happened was because the code I added for maintenance categories is nested in this if statement: {{#ifeq:{{BASEPAGENAME}}|{{SUBPAGENAME}}|{{#ifeq:{{NAMESPACE}}|Template|[[Category:Stub message boxes|{{PAGENAME}}]]. –xeno^talk 13:44, 19 August 2009 (UTC)

@Martin: I guess more for completeness sake... FYI I just added a maintenance category for asbox without the name= paramater. These will need to be fixed if the #Navbar functionality is added. –xeno^talk 13:40, 19 August 2009 (UTC)

• I guess we only need maintenance categories if they have some use, i.e. if there is something which needs to be done to the templates in those categories ...
• I'm just trying to work out why Category:Stub message boxes without name parameter is showing on its members even though it's supposed to be a hidden category. — Martin (MSGJ · talk) 22:10, 20 August 2009 (UTC)

• I don't mind to delete the "...using images" one. It basically contains almost every stub, so it's not helpful. ( Done)
• Boggle? Being that the lack of a name= paramater is arguably a serious omission, it may make sense to keep this category unhidden anyway. –xeno^talk 22:11, 20 August 2009 (UTC)

As soon as name has been added to all the templates, we can move all these maintenance categories (apart from "erroneous name" I guess) to /templatepage to keep the code nicer. — Martin (MSGJ · talk) 13:28, 24 August 2009 (UTC)

This is  Done, so feel free to go ahead with this. (Could you add #8 while there?) –xeno^talk 12:32, 25 August 2009 (UTC)

Certainly. I am thinking about creating a general category Category:Stub message boxes needing attention, and the individual problems can be identified using sortkeys. This saves creating new categories for everything we want to track. (See here for one I made earlier.) — Martin (MSGJ · talk) 14:05, 25 August 2009 (UTC)

Hm... That would be elegant... But does AWB have a way to build a list in a category based on sortkey? (It should!). I'd like to comb the 'using icon' boxen regularly to add alt-text where necessary and convert to use image when possible. –xeno^talk 14:08, 25 August 2009 (UTC)

No, it probably doesn't. But I wasn't planning to change that category anyway, just the broken things which need fixing, e.g. no category, wrong name, etc. — Martin (MSGJ · talk) 14:22, 25 August 2009 (UTC)

Sounds good. "Using imagealt" should probably go into "broken" since, presently, it's unused, and likely won't be, but I'd like to review it if it ever is. –xeno^talk 15:11, 25 August 2009 (UTC)

Would you care to check Template:Asbox/sandbox for me? — Martin (MSGJ · talk) 15:22, 25 August 2009 (UTC)

Looks good to me... Unfortunately only 1 entry is made even if multiple errors exist. Looks like "using imagealt" is on the bottom of the list which is appropriate. –xeno^talk 15:29, 25 August 2009 (UTC)

asbox that are categorizing into non-stub categories?

Is it possible with the str len magic that WOSlinker used for the heirarchy? And is it desirable? I know that Xenobot made a couple goofs (forgetting the word "stubs" at the end of the category) which I think I've fixed all, but a maintenance category to make sure would help me to be at ease, and it would also identify asbox that category into non-stub categories, which is and all-around bad idea. –xeno^talk 20:06, 4 September 2009 (UTC)

I've just added something that should hopefully do that. -- WOSlinker (talk) 22:24, 4 September 2009 (UTC)

There's a couple of false alerts so far since the {{str sub}} template only works for upto 50 characters. Could always change the code to not check those longer than 50. -- WOSlinker (talk) 22:34, 4 September 2009 (UTC)

Microformats in stubs

{{editprotected}}

To facilitate the inclusion of microformats in instances of this template, please change:

<table class="metadata plainlinks stub"

to:

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

allowing an extra class value to be specified when the template is deployed. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:41, 9 August 2009 (UTC)

What sort of class name would be passed in? --- RockMFR 23:21, 9 August 2009 (UTC)

The parent class-name of a microformat; for example, vcard if the hCard microformat is to be used; vevent for hCalendar and (most likely based on recent manual conversions) adr for an address or place-name - for example, in Template: Ghana-stub; removing the need for one pair of span tags. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:28, 9 August 2009 (UTC)

I don't know much about microformats, but is it useful to place them inside the stub templates where you have to assume that it will be removed without replacement at some point? I'd think it would be better to have a bot go through all of Category:Ghana stubs and place a permanent {{Locationdata}} or something (similar to {{Persondata}}). Amalthea 11:14, 10 August 2009 (UTC)

Yes, it will be useful, with or without Locationdata; conversely, it will do no harm. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:34, 10 August 2009 (UTC)

I don't want to be an ass, but can you try to explain how it is useful? As I said, I don't know much about them, but I think that a) it's much more logical to add more permanent meta data that doesn't need to be re-added in a different way once an article advances to Start class, and b) it's a bad idea to hardcode the span ids "<span class="adr"><span class="country-name">" in the first place, just as it was a bad idea to hardcode the stub template wikicode with classes and ids in thousands of stub templates in the first place. Amalthea 15:31, 10 August 2009 (UTC)

It will be useful because it will add semantic meaning to instances of the template about the types of subject I listed above (hCards for people, events, etc.); at no extra overhead for editors or readers. Can you say why you think it's a bad idea? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:59, 10 August 2009 (UTC)

Because when the article graduates from stub, the class will be lost, and the editor who removes the stub tag might not realize he has to add it to the article proper. The same goes for hardcoded non-stub categories in place on a handful of stub templates. –xeno^talk 20:04, 10 August 2009 (UTC)

The editor who removes the stub notice may never need to replace the class - it may, for example, be included in an infobox. But if not, how is thart more harmful than it never having been there at all? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:36, 10 August 2009 (UTC)

Can that create problems if there are several, possibly conflicting countries? Or is the format designed to handle that?
But of course, the names of the classes should in any case be abstracted away in a dedicated template, so there's no need to pass the class as a parameter. Amalthea 20:42, 10 August 2009 (UTC)

I foresee no problems around "conflicting" countries; and I regret taht I don't understand the rest of your post, Remember, though, that microformats are used un this way in hundreds of thoisands (possiblfy millions) of instances of thousands of infoboxes and navboxes. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:20, 10 August 2009 (UTC)

(ec)I believe I have:

1. Don't hardcode class names in hundreds or thousands of stub templates, it's tedious to update
2. Don't place information that isn't related to the stub status inside the stub templates since it will need to be re-added once it's advanced to Start or above.

Instead, have a bot monitor Category:Ghana stubs et al to add a permanent {{Locationdata}} template. Or add this process to the default fixes of AWB.
I can see that it's convenient to automagically add the desired meta information to thousands of articles by (ab)using the stub templates, but I think it's a short-lived joy, and should be done properly instead. Amalthea 20:42, 10 August 2009 (UTC)

You have not explained how including class names in templates will be "tedious to update"; nor even why you think they will need to be updated. You assert, without basis, that "information that isn't related to the stub status […] will need to be re-added once it's advanced to Start or above". Your hypothetical Locationdata template will not impart semantic meaning, nor serve our users, in the same way that the currently-available microformats would do so; and does not apply to the types of article I list above, which are not about locations. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:55, 10 August 2009 (UTC)

No answer? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:48, 31 August 2009 (UTC)

No. I don't particularly appreciate a discussion style where it's challenged that updating a classname in thousands of templates might be considered more tedious (wikt:tedious: boring, monotonous, time consuming) than updating one. Amalthea 12:14, 10 September 2009 (UTC)

I haven't challenged that. I have challenged that that will ever need to be done. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:21, 10 September 2009 (UTC)

I agree that adding permanent metadata to a transient template is a Very Bad Idea; it will just result in data either being duplicated, or lost. (also)Happy‑melon 19:47, 10 August 2009 (UTC)

If the template is transitory, then so will be the metadata it emits. Can you say why you think it's a bad idea; and how you think metadata will either be lost? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:59, 10 August 2009 (UTC)

Dunkwa-on-Offin is a city in Ghana. Dunkwa-on-Offin will still be a city in Ghana whether or not it has {{Ghana-stub}} on its article. If we add location metadata to the stub template, then there will be metadata on the Dunkwa-on-Offin article for the time being. 99.99% of readers will not be aware that the metadata is present; 99% of the remaining 0.01% will not understand where it is being added from. When the article is improved beyond Stub class, the stub template will be removed. The metadata will be lost, because even of the tiny number of people who were aware that it was ever there, who is going to suspect that it was being added by a completely unrelated template? That is a Bad Thing. To prevent that happening, the metadata must be encoded in a different template, either a permanent one like an infobox, or in a bespoke template such as the {{locationdata}} that has been proposed above. To avoid loss of data, that separate template needs to be added before the stub template is removed. At which point there will be duplication of the metadata. So why bother adding it to the stub template in the first place? (also)Happy‑melon 12:16, 11 August 2009 (UTC)

Can you explain how this will be used, in layman's terms? –xeno^talk 20:57, 10 August 2009 (UTC)

Suppose we have two stub notices (or navboxes, or whatever), "xxxx about Foobar". By using either <span class="biota"><span class="vernacular">Foobar</span></span> or <span class="adr"><span class="locality">Foobar</span></span>, a parser (a bot, or a tool operated by a human user) can tell whether the word "Foobar" refers to the vernacular name of a living thing, or a place name. This, for example, improves searchability. It also allows the term to be passed to a relevant search engine (such as a biological database or a gazetteer) thus making it easier for the editor improving the stub to find relevant information. For further information I suggest reading microformat and WP:UF. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:12, 10 August 2009 (UTC)

I too think this is a bad idea. A stub is basically a maintenance template with a categorization scheme, that just happens to have some contextual information. It is however not part of the article proper (unlike an infobox). It also adds further complexity to the stub templates, which might be confusing to some of our users. —TheDJ (talk • contribs) 21:56, 10 August 2009 (UTC)

Even if a stub is not, as you say, "an article proper" (that's debatable) that is immaterial; and no reason not to semantically identify the meaning of key terms used in a stub template. Since this will be a simple, optional parameter, your "confusion" claim is unsubstantiated, and unjustified. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:11, 10 August 2009 (UTC)

I know that the WSS project expressed concerns that the metatemplate would become too parameter-laden. Thank you for the links you provided above, I'll take a look. –xeno^talk 23:56, 10 August 2009 (UTC)

That's a slippery slope argument. Aren't such arguments discounted by policy? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:57, 11 August 2009 (UTC)

No answer? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:48, 31 August 2009 (UTC)

The example that seems to be being thrown around here is {{Ghana-stub}}, and the proposal to add locationdata for Ghana to it. If you look at Category:Ghana stubs, we see that the use of this template is by no means restricted to geographical articles: is such a tag appropriate on Elections in Ghana?? How about Abron?? These situations are not very clear-cut. (also)Happy‑melon 12:16, 11 August 2009 (UTC)

On every page on which {{Ghana-stub}} appears, the word "Ghana" means "the county Ghana"; it is semantically correct and meaningful to mark it up as such with an ADR microformat. How coudl it not be so? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:57, 11 August 2009 (UTC)

But the purpose of the metadata is to apply to the article, no? Of course "the word Ghana" means the country; that's not AFAICT the point of the microformat. The purpose of the code <span class="adr"><span class="locality">Ghana</span></span> is to say "the subject of this article is located in Ghana", no?? That is simply not consistently the case with all Ghana stubs, as many of them do not have a definable geographic location. What am I missing? (also)Happy‑melon 19:52, 11 August 2009 (UTC)

No. I don't know where you get the impression that the purpose of the code is to indicate that the subject of the article; but that's not the case. It's perfectly valid to have multiple microformats on one page, describing different things. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:56, 11 August 2009 (UTC)

Disabling edit request since there is not consensus for this change. --- RockMFR 23:13, 13 August 2009 (UTC)

I have addressed every concern raised; many of which were founded in - often admitted - ignorance of the purpose and nature of microformats. What do you think I should do to satisfy any remaining concerns? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:27, 13 August 2009 (UTC)

Have you run this by the stub sorting project? I still don't see how this microformat business is supposed to work; do we need to tag every instance of a country name with the microformat? Is it just search engines that read this microformats? Is it worth the effort? –xeno^talk 23:31, 13 August 2009 (UTC)

This won't affect the work of the stub-sorting project at all. Do you really think it worth bothering them? Yes, I think every instance of a country name (at least, using this and other similar templates) should be marked up, semantically, with a microformat. no, it is not just search engines which use microformats, as I've already said, above. And yes, this is worth the - very tiny amount of - effort (far, far, less effort, in fact, than this debate has taken!). Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:38, 14 August 2009 (UTC)

As they are the ones that maintain the over 10,000 stub templates that may require these microformats, yes, I think you should run it by them. –xeno^talk 15:44, 14 August 2009 (UTC)

I might also suggest a discussion at a wider venue to determine if Wikipedia is going to embrace these microformats. –xeno^talk 15:49, 14 August 2009 (UTC)

That discussion took place about two-three years ago; Wikipedia now has thousands of templates emitting hundreds of thousands, if not millions, of microformats. Wikipedia's microformats are already parsed by Google and Yahoo, among others. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:33, 14 August 2009 (UTC)

I've reinstated {{editprotected}} since, so far as I can see, discussion has ceased and all concerns have either been addressed or refuted. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:43, 17 August 2009 (UTC)

I still think it's pointless. I'll ask for feedback on the Village Pump. —TheDJ (talk • contribs) 19:51, 17 August 2009 (UTC)

Either that, or people have just given up discussing it with you.
FWIW, I'm still strongly against hardcoding any class names in thousands of templates. I have no strong opinion about placing microformat templates into the stub templates, but find that this too is the wrong approach. Amalthea 21:20, 17 August 2009 (UTC)

If people choose to absent themselves from a discussion, then they can hardly expect their views to be taken into account. You say you're " strongly against hardcoding any class names", but without reasons, such a statement (and things such as "I still think it's pointless") sound like WP:IDONTLIKEIT. If you can give reasons, I'd be happy to either address them or concede. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 09:47, 18 August 2009 (UTC)

It looks as though people have already expressed their reasons further up. When so many people oppose your idea it's time to start questioning it yourself. — Martin (MSGJ · talk) 09:52, 18 August 2009 (UTC)

Which reason do you think has been given, which has not already been addressed or refuted? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:15, 18 August 2009 (UTC)

I liked this proposal more when I didn't fully understand it. What is the point in doubling the bytecount of the sentence to add 'semantic meaning' to a word that only has one meaning in the first place? And you propose to (eventually) do this to every single word that represents a location on wikipedia? Yikes. But even if this process has consensus, why would this particular request facilitate this? You don't want to add the microformat to the whole template. The {{Ghana-stub}} template is not located in Ghana, nor does it represent a location. The word "Ghana" represents a location; that's what you need to wrap in the microformat. Why can't you just do that in the |text= parameter? (also)Happy‑melon 12:39, 19 August 2009 (UTC)

I can and do do it in the |text= parameter; the change requested above will streamline this and will make it easier for others to subsequently edit the template. The requested change does not equate the whole template in a microformat; it adds a parent class so that the specific word may be defined. Many words which are place names ("Bath", "Telford", "Wall", "Barry") do not uniquely mean that; and microformats are not just for placenames, but also for people, venues, events, species, products, recipes/ food items and more. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:33, 19 August 2009 (UTC)

To summarise the summary, stub templates are things we aren't supposed to have. Their (purported) function is self destructive - to get the article made non-stubby. They attempt this by two methods - a visible presence which is an invitation to expand the article (or to remove the template), and categorization. Because of the nature of stubs, stub templates (and categories) are being created and destroyed all the time - often "out of process" tsk-tsk. In particular they are made by comparative newbies to fill a ral or perceived need - generally by cut and paste. Adding a MF parameter will result in many many incorrectly MF'd stubs. If you want to make the meaning from the stub template available in MF a much stronger idea is to file a bug to have categories emit the MF, and make it heritable, therefore you would simply need to label

• Africa geography stubs
• Airport stubs
• Americas geography stubs
• Antarctica geography stubs
• Asia geography stubs
• Europe geography stubs
• Fictional location stubs
• Marine geography stubs
• Oceania geography stubs
• Protected area stubs

and you would have thousands of categories emitting location codes. Moreover the same would work on the main category tree. Rich Farmbrough, 19:04, 25 August 2009 (UTC).

The fact that stubs are intended to be transitory is no reason not to have them emit a microformat. Adding a microformat will increase the visibility of a stub's presence (and thereby increase the probability of it being improved). Raising a bug to have categories emit microformat might work (though I can see flaws, such as needing to add classes to parts of words in anchor links), but will take months if not years to achieve. Adding microformats via stub templates will work now. You say that "Adding a MF parameter will result in many many incorrectly MF'd stubs", but I don't see why that would be, and you don't substantiate the assertion. If it is the case, then surely categories would be similarly corrupted? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:29, 25 August 2009 (UTC)

Actually the categories are probably worse, because they need a massive overhaul. But that said the stub tree is relatively clean. Rich Farmbrough, 21:13, 31 August 2009 (UTC).

So where does this leave us? I note some of my questions, above, remain unanswered. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:48, 31 August 2009 (UTC)

Section break

Discussion has stalled; and there has been no apparent input from VP. Unless anyone has any unresolved concerns, I intend to reactivate the edit request. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:23, 10 September 2009 (UTC)

I don't believe you have to any completeness explained why implementing these microformats requires increasing the complexity of the templates by adding extra parameters, when the classes can just as easily (and arguably more transparently) be applied directly to the text input. Happy‑melon 11:51, 10 September 2009 (UTC)

Yes, my concerns are unresolved. We've only just managed to clean all stub templates up, by adding the {{asbox}} abstraction layer, and removed the hardcoded inconsistencies from thousands of templates. You want to change the stub template with the express intent to add hardcoded meta class names back in. I've stated two alternatives that wouldn't require that. Using a bot to add persistent meta data has no drawback I can see except for a higher initial effort, and the advantage to retain the meta data past stub status. Using a template has no drawback I can see except for a slight performance hit, and the advantage to be more flexible. The latter alternative would have the exact same end result you're looking for.
No, I don't immediately know when a {{locationdata}} template might be useful. That's part of the point of abstraction: you leave yourselves options that you wouldn't have if you hardcoded or substed everything. During the Asbox Stub Unification Drive nobody had all potential benefits in mind. You are currently trying to make use of that added abstraction layer, yet refuse to see that abstraction with the location meta data might have future benefits as well. Talk about WP:IDONTLIKEIT.
Amalthea 12:14, 10 September 2009 (UTC)

←[reply to both] Addressing your points in turn:

• "increasing the complexity": Adding one optional parameter (singular, not plural as suggested above) to this template, to reduce the need for adding inline markup to many, is hardly unnecessary complication. Surely that's what templates are for?
• "classes can just as easily … be applied directly to the text input. I've often been told, elsewhere on WP, that including classes as template parameters (e.g. bodyclass="vcard"), rather than in-line HTML (Foobar)is preferable, both technically, and for ease of updating by users who are not HTML proficient. Why do you think the latter is preferable in this case, but not others?
• "…arguably more transparently: I fail to see how what I propose is any less transparent; indeed I think it more so (because it will be included in this template's documentation), than in-line mark-up.
• "hardcoded inconsistencies: I fail to see how those inconsistencies are relevant here; indeed, adding a parameter centrally ensures greater consistency. Perhaps you care confusing the straightforward change I propose, with such inconsistencies, and that is giving you needless cause for concern?
• "Using a bot to add persistent meta data: Where have you initiated this programme? What text do you think the bot will mark up as a microformat? Can we see some examples in use? Without such answers, this seems to me a hypothetical red herring.
• "{{locationdata}} Another hypothetical red herring. And as I have already pointed out, my requested change does not apply only to lcoations, but also to taxa, organisations (including bands and other such groups of people) venues, events, foodstuffs and more. You likened {{locationdata}} to {{persondata}}; Note that {{persondata}} does not emit microformats and is often used alongside templates which do.
• "IDONTLIKEIT: not IDONTLIKEIT; it's NOTPOSSIBLENOW and quite possibly NEVERGOINGTOHAPPEN. On the other hand, once the requested change is made, it will be possible to make existing instances of stub templates emit microformat metadata with no "higher initial effort" of edits to every single one of the pages using them (again, that's what templates are for), and no performance hit. In the unlikely event that one of your hypothetical solutions does come to pass, then this edit can be undone at a stroke thereby disabling all the microformat emitted by all such stubs, without the need to manually remove them from hundreds.

I really don't see what you are worried about. Have either of you used microformats emitted by stub templates, or examined any of those currently configured, manually, to emit them? Perhaps we need additional outside opinions? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:12, 10 September 2009 (UTC)

I'm developing an increasing sense of "meh" towards this proposal; I find I'm increasingly objecting to the principle of using this convoluted method of attaching semantics to the phrases than I am to the actual implementation of them. What happens when you want to identify different objects within the same template? "This article about Ghanan plants in the taxon Quok", for instance? Happy‑melon 16:26, 10 September 2009 (UTC)

I don't think we actually have any stubs like that, do we? But in that case, bodyclass=hcard biota. And this proposal is less convoluted than the pure-markup method you advocated above. I asked some Qs of you, above, BTW. But let me put it anther way: what would it take, to satisfy you that this us a worthwhile change? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:36, 10 September 2009 (UTC)

I think you have convinced me that, taking the assumption that it is constructive and worthwhile to add these microformats in this convoluted fashion, the extra parameter is the way to go about it. I don't take that assumption; I'm sure that there is a better way of achieving these ends, but I really don't have the enthusiasm to pursue it. I'm glad that you do. Happy‑melon 18:53, 10 September 2009 (UTC)

This proposal is a bad idea and this has been extensively explained above. Continuing this discussion beyond this point and actively asking more people to participate sounds like a big waste of time and efforts. Cacycle (talk) 22:18, 10 September 2009 (UTC)

Broken page

I believe the recent conversion of the stub templates has left Wikipedia:WikiProject Roads in Maryland/Editing guide broken. Can this be fixed? --Rschen7754 (T C) 18:24, 17 August 2009 (UTC)

I admit that I am confused by that behaviour. But I think I have fixed it well enough for now. — Martin (MSGJ · talk) 09:54, 18 August 2009 (UTC)

Okay, thanks. --Rschen7754 (T C) 22:37, 20 August 2009 (UTC)

Stub template documentation

Per the discussion at Wikipedia talk:WikiProject Stub sorting#/docs I am planning to transclude some common documentation for stub templates on the template page itself (i.e. when {{{name}}}={{FULLPAGENAME}}. I've started a possible version at Template:Stub documentation. It's basically an abridged version of WP:Stub, although it needs further work. Are there any comments or concerns about this? I will of course put the proposed code on the sandbox so that people can look over it before implementing. — Martin (MSGJ · talk) 22:17, 20 August 2009 (UTC)

You should also only show it when {{{name}}}/doc doesn't exist. -- WOSlinker (talk) 22:23, 20 August 2009 (UTC)

I thought the plan was to allow the /doc subpages to function as a "sub-doc" of the "main" , containing template-specific instructions and interwikis? –xeno^talk 22:26, 20 August 2009 (UTC)

Yes, this is what I was thinking. — Martin (MSGJ · talk) 22:44, 20 August 2009 (UTC)

Ah wait, we will at least need a tracking category to find which templates have documentation subpages. Otherwise we will probably end up transcluding them twice. — Martin (MSGJ · talk) 07:34, 21 August 2009 (UTC)

What I think is best here, is to propose a change to {{documentation}}. The idea will be that it allows for a new parameter "super=pagename". We then use the asbox template to include {{documentation}} with the option "super=Template:Stub documentation". And documentation includes this first, followed, if present, by the local /doc page. Then we only have to remove the doc template from any templates that already have documentation. Does this sound realistic ? —TheDJ (talk • contribs) 11:45, 21 August 2009 (UTC)

It's an interesting idea. But wouldn't that be significantly complicating the Template:documentation unduly? This is likely to be the only such use of that parameter and it can easily be implemented locally rather than on that template. I've started /templatepage which would do this. — Martin (MSGJ · talk) 11:51, 21 August 2009 (UTC)

As well as name, you should also pass over the category, category1 & category2 parameters so that those categories can be mentioned in the docs. -- WOSlinker (talk) 12:13, 21 August 2009 (UTC)

Oh good idea. Please go ahead. We can also put warnings on the templatepage if those categories don't exist. — Martin (MSGJ · talk) 12:17, 21 August 2009 (UTC)

Oh, that is a nice idea indeed. —TheDJ (talk • contribs) 13:21, 21 August 2009 (UTC)

I've added it. -- WOSlinker (talk) 17:39, 21 August 2009 (UTC)

In order to keep {{stub documentation}} free of parser functions and editable by members of WP:WSS without needing any template knowledge I propose to move the template-specific documentation (which is using more and more parameters and parser functions) to /templatepage and keep Template:stub documentation for general (brief) information about stubs. Sound okay? — Martin (MSGJ · talk) 14:31, 22 August 2009 (UTC)

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)

Stub Documentation

Using some large clunky template code it is possible to show related templates in the documentation, so for example with {{England-footy-bio-stub}} we could include:

Related Stubs

• {{footy-bio-stub}}
• {{bio-stub}}

The code to do this is

===Related Stubs===
*{{#ifexist:Template:{{Str sub|{{PAGENAME}}|{{#expr:{{Str len|{{PAGENAME}}}}-18}}|18}}|{{tl|{{Str sub|{{PAGENAME}}|{{#expr:{{Str len|{{PAGENAME}}}}-18}}|18}}}}}}
*{{#ifexist:Template:{{Str sub|{{PAGENAME}}|{{#expr:{{Str len|{{PAGENAME}}}}-17}}|17}}|{{tl|{{Str sub|{{PAGENAME}}|{{#expr:{{Str len|{{PAGENAME}}}}-17}}|17}}}}}}
*{{#ifexist:Template:{{Str sub|{{PAGENAME}}|{{#expr:{{Str len|{{PAGENAME}}}}-16}}|16}}|{{tl|{{Str sub|{{PAGENAME}}|{{#expr:{{Str len|{{PAGENAME}}}}-16}}|16}}}}}}
*{{#ifexist:Template:{{Str sub|{{PAGENAME}}|{{#expr:{{Str len|{{PAGENAME}}}}-15}}|15}}|{{tl|{{Str sub|{{PAGENAME}}|{{#expr:{{Str len|{{PAGENAME}}}}-15}}|15}}}}}}
*{{#ifexist:Template:{{Str sub|{{PAGENAME}}|{{#expr:{{Str len|{{PAGENAME}}}}-14}}|14}}|{{tl|{{Str sub|{{PAGENAME}}|{{#expr:{{Str len|{{PAGENAME}}}}-14}}|14}}}}}}
*{{#ifexist:Template:{{Str sub|{{PAGENAME}}|{{#expr:{{Str len|{{PAGENAME}}}}-13}}|13}}|{{tl|{{Str sub|{{PAGENAME}}|{{#expr:{{Str len|{{PAGENAME}}}}-13}}|13}}}}}}
*{{#ifexist:Template:{{Str sub|{{PAGENAME}}|{{#expr:{{Str len|{{PAGENAME}}}}-12}}|12}}|{{tl|{{Str sub|{{PAGENAME}}|{{#expr:{{Str len|{{PAGENAME}}}}-12}}|12}}}}}}
*{{#ifexist:Template:{{Str sub|{{PAGENAME}}|{{#expr:{{Str len|{{PAGENAME}}}}-11}}|11}}|{{tl|{{Str sub|{{PAGENAME}}|{{#expr:{{Str len|{{PAGENAME}}}}-11}}|11}}}}}}
*{{#ifexist:Template:{{Str sub|{{PAGENAME}}|{{#expr:{{Str len|{{PAGENAME}}}}-10}}|10}}|{{tl|{{Str sub|{{PAGENAME}}|{{#expr:{{Str len|{{PAGENAME}}}}-10}}|10}}}}}}
*{{#ifexist:Template:{{Str sub|{{PAGENAME}}|{{#expr:{{Str len|{{PAGENAME}}}}-9}}|9}}|{{tl|{{Str sub|{{PAGENAME}}|{{#expr:{{Str len|{{PAGENAME}}}}-9}}|9}}}}}}
*{{#ifexist:Template:{{Str sub|{{PAGENAME}}|{{#expr:{{Str len|{{PAGENAME}}}}-8}}|8}}|{{tl|{{Str sub|{{PAGENAME}}|{{#expr:{{Str len|{{PAGENAME}}}}-8}}|8}}}}}}
*{{#ifexist:Template:{{Str sub|{{PAGENAME}}|{{#expr:{{Str len|{{PAGENAME}}}}-7}}|7}}|{{tl|{{Str sub|{{PAGENAME}}|{{#expr:{{Str len|{{PAGENAME}}}}-7}}|7}}}}}}

(although it could be simplified a bit if put into sub-templates)

Is this worth adding? -- WOSlinker (talk) 22:09, 25 August 2009 (UTC)

Looks expensive... –xeno^talk 22:11, 25 August 2009 (UTC)

It's a little slow but with sub-templates, would only need to call {{Str len}} once but would still need to call {{Str sub}} multiple times. This is the reason why I was asking though, wether it was worth adding. -- WOSlinker (talk) 22:13, 25 August 2009 (UTC)

I'm no expert but I think the expense might outweigh any benefits. It's also not that hard to just chop off the prefix words if one were looking for a parent template... –xeno^talk 22:17, 25 August 2009 (UTC)

I'm still tring to work out what that code does. Could you explain a bit more WOSlinker? — Martin (MSGJ · talk) 22:47, 25 August 2009 (UTC)

I believe it chops off pieces of the template name until it finds a parent. It's a nifty bit of code (still trying to figure out what makes it work), but (in my completely armchairish, speaking-out-of-my-ass opinion) deploying it on such a wide scale (13000+ templates) would probably blow up a server farm or two. –xeno^talk 22:49, 25 August 2009 (UTC)

Don't worry, we can have 500 expensive parser functions on a page :) — Martin (MSGJ · talk) 22:53, 25 August 2009 (UTC)

My implementation only adds one expensive parser function per dash in the title. -- WOSlinker (talk) 18:11, 26 August 2009 (UTC)

Add it! Expensive templates on template documentation pages don't worry me, I'd find it very useful to generate those parent stub links, and it's one more reason to get proper built-in string parsing functions. :)
Some thoughts:

• What's the stub template with the longest name? It should be tested whether that brings us (close) to any parser limit.
• I'd we don't want to list {{b}}. It shouldn't go below {{stub}}
• Maybe we only want to split it at the hyphens anyway, so that we don't show {{ad-stub}} on {{Africa-road-stub}}

Amalthea 00:37, 26 August 2009 (UTC)

I've got a slighly less expensive way, which is to pass over each character separately to a subtemplate (using {{Str index}} to get a single character) and then join them back in the template. Would also make it easier to check where the - splits are.

{{subtemplate|{{Str index|{{PAGENAME}}|1}}
             |{{Str index|{{PAGENAME}}|2}}
             |{{Str index|{{PAGENAME}}|3}}
             |...etc...}}

I'll work something out for a test later on today. -- WOSlinker (talk) 06:39, 26 August 2009 (UTC)

The longest stub name is currnetly 46, {{DominicanRepublic-baseball-second-baseman-stub}}, but the longest length ignoring the part before the first dash is only 33, {{UK-fieldhockey-Olympic-medalist-stub}}, so I'll just need to take the last 35 chars for the template. -- WOSlinker (talk) 06:48, 26 August 2009 (UTC)

It's now implemented. Let me know what you think. It could probably do with a sentence to describe what's it's all about. -- WOSlinker (talk) 18:12, 26 August 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)

Issues with the asbox documentation

It's late (for me) and I'd certainly cock things up if I started fiddling. here are things I;ve noticed in the documentation:

• Under Parameters we discuss icon and image, but in Full usage just above, icon is not listed.
• Under the discussion of pix, we do not specify the anticipated input format for pix. We talk about its default value of 40x30, which might lead a user to expect that this format of input is required. Lower down the page in the Using image an example shows a single input value of 30. Other templates (iirc) user 30px. Specifying the format anticipated by pix is recommended
• Per my End misaligned left justification with asbox? thread, above, might I suggest we include firm injunctions to users to keep to the 40x30 size, explaining that failure to do so will lead to the possibility of ragged justification and/or odd line spacing, both of which we'd prefer to avoid.

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

1, well the options are somewhat mutual exclusive. I guess that's why we don't list BOTH in full usage. A full usage should always use either one, or the other.

2, updated

3, that would need a significant discussion first.

—TheDJ (talk • contribs) 18:32, 26 August 2009 (UTC)

Yes, I was hoping that eventually icon would be phased out. As far as the pix goes there is a default value, and again it would be "best" if all templates used the default value, and the pix parameter could be obsoleted. Certainly updating the docs with strong advice to use 40x30 would be useful. Both these compromises came from my initial plan to cause minimum impact when implementing {Asbox}. Rich Farmbrough, 21:18, 31 August 2009 (UTC).

I have added to the pix parameter documentation a sentence: "(Note that in the interests of standardising the formats of stub messages, images of size 40x30 are much preferred.)". Trust that you'll all be happy with this. --Tagishsimon (talk) 22:41, 31 August 2009 (UTC)