Template talk:Asbox/Archive 2

mbox

Latest comment: 14 years ago7 comments3 people in discussion

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)

Broken page

Latest comment: 14 years ago3 comments2 people in discussion

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

Latest comment: 14 years ago12 comments4 people in discussion

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)

Stub Documentation

Latest comment: 14 years ago12 comments4 people in discussion

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)

Options of this template

Latest comment: 14 years ago18 comments6 people in discussion

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.

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.
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.
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.
I have removed the "date" option. It didn't seem like this was a convention being used, and can easily be reintroduced when needed.
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:

Yep, per above.
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
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).
no opinion
/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)

Issues with the asbox documentation

Latest comment: 14 years ago4 comments3 people in discussion

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)

Navbar

Latest comment: 14 years ago18 comments5 people in discussion

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:

Search