Template talk:Mbox

From Wikipedia, the free encyclopedia

Message box standardisation Here are some useful pages: {{ambox}} – For article message boxes. {{tmbox}} – For talk page message boxes. {{imbox}} – For image page message boxes. {{cmbox}} – For category message boxes. {{ombox}} – For other pages message boxes. {{mbox}} – Has namespace detection, for message boxes that are used on several types of pages and thus need to change style depending on what page they are used on.

[edit] Why this template?

The discussion that lead to the creation of this template is at Template talk:Imbox#Other spaces message boxes.

Some message boxes are used on several types of pages and thus need to change style depending on what page they are used on. Coding such namespace detection is rather tricky. This template packages all that in an easy to use meta-template that can be used to build such message boxes.

One example of such a style shifting message box is the {{notice}} box above. When {{tmbox}} is ready for use then {{notice}} should probably use it.

Note that this template should only be used for message boxes that really need to adapt their style. Most message boxes do not need this and should use one of {{ambox}}, {{tmbox}}, {{imbox}}, {{cmbox}} or {{ombox}} directly. Using those templates directly means that your template will look the same on its template page and at any other place you show it, which makes it clear on what kind of pages it is supposed to be used. It also gives you access to any extra features those templates offer, and it saves some server load.

--David Göthberg (talk) 09:50, 30 May 2008 (UTC)

This is an excellent start, but it appears that some Types unique to talk messages need to be provided for (see also Template talk:Tmbox):

• Feature (used for Barnstars, Feature Article, FA candidate and FA failed)
• Good (used for Class A, Class A candidate, Class A failed,, Good Article, Good Article candidate, Good Article failed)
• Project (used for WikiProject banners; WPBannerMeta (beta) to include color blocks for Class and Priority)

Several classes of talk-page message, e.g. Peer Review, Consensus, Conclusion, FAQ, &c., may default to Notice for purposes of this Template. Warnings default to Notice, Content, Delete or Speedy; Blocks to Delete or Speedy, depending on level. Once a consensus is reached on all Types needed, in addition to the Format of this Template, this Template will probably be ready for standard. B. C. Schmerker (talk) 06:13, 26 June 2008 (UTC)

B.C.Schmerker: I think you have misunderstood the purpose of {{mbox}}. A message box that uses a talk space specific box type like say "type=feature" obviously is only meant to be used on talk pages, since that box type has no defined style for other kinds of pages. Thus such a message box should not use mbox, but instead use {{tmbox}} directly. Directly using tmbox has the advantage that the message box will look like a talk page message box on its template page and also on any other page where it is listed or shown, like when listed at Wikipedia:Template messages/Talk namespace.

--David Göthberg (talk) 06:45, 26 June 2008 (UTC)

[edit] A minor comment about {{mbox}}

This discussion was moved here from the talk page of David Göthberg:

Hi David,

Just a minor comment I wanted to make about {{mbox}} in followup to the comment you left me:

And you should not change {{ambox}} usage to {{mbox|demospace=main}} even in the future. Since using mbox costs much more server load and it makes your code unnecessarily complex since you add the "demospace" parameter.

What about in the case where a template might be used in both mainspace and talkspace? The particular example I'm thinking of is {{Whole Day Edit}}, which is currently used in both.

Chris Cunningham (not at work) - talk 15:26, 12 July 2008 (UTC)

Right, templates that are meant to be used on several types of pages are exactly the cases that are meant to use {{mbox}} when it is ready. Then you don't need the "demospace=something" parameter so then it doesn't add code complexity. And then we have to accept the extra server load that mbox costs. And {{Whole Day Edit}} seems to be exactly such a case.

However, mbox is not yet officially deployed since we still have no consensus on how it should look on talk pages. (It calls the {{tmbox}} when on talk pages and tmbox is not ready yet.) So templates like {{Whole Day Edit}} in theory should use the old methods for now. But I won't revert to the old methods since they are messy and we are hopefully officially deploying mbox soon anyway. But I would not convert more templates to mbox for the time being.

You are of course welcome to come to {{tmbox}} and its talk page, to help us achieve a consensus so we can deploy...

--David Göthberg (talk) 15:41, 12 July 2008 (UTC)

Thanks. My understanding of the "demospace" parameter was that it was basically just for displaying the template in the defined livery on its own template page instead of always using templatespace - is this incorrect?

Anyway, yeah, sorry about using the template pre-emptively. I've been doing quite a lot of work on templates recently and I'll try to pitch in on development discussion. Chris Cunningham (not at work) - talk 16:00, 12 July 2008 (UTC)

Right, the "demospace" parameter is meant to be supported by the message boxes that use mbox. Like this:

{{mbox
| demospace = {{{demospace|}}}
| text = Bla bla
}}<noinclude>

{{documentation}}
</noinclude>

Then in their green /doc box on their own template page they can show how they will look on different pages. Like this:

The {{tl|something}} template looks like this when on article pages:
{{something|demospace=main}}

And on talk pages it will look like this:
{{something|demospace=talk}}

I am going to explain all that with examples in the documentation for mbox, when it is being deployed. But it is not ready to be deployed yet...

--David Göthberg (talk) 16:11, 12 July 2008 (UTC)

[edit] We do not need this in a way

On Wikibooks, we are experimenting with an alternate method for namespace changing message boxes. Instead of using the namespace switching template {{switch}}, to flip between the existing metatemplates, we've modified the CSS classes THEMSELF to do this for us.

For example, here's some CSS classes we're testing out, modified versions of our Ambox and Imbox (our imbox has a thicker bottom border)

/* Default "notice" blue */
.messagebox { width:90%; margin:0px auto; padding:0em; border:2px solid #1e90ff; background:#fbfbfb; color:black; }
.messagebox img { border: none; padding:0em 0.5em; text-align:center; }
.messagebox + .messagebox { border-top-width:0em; }
 
/* book/main namespace */
.ns0 .messagebox.notice  { border:2px solid #1e90ff; border-left-width:10px; }
.ns0 .messagebox.warning { border:2px solid #b22222; border-left-width:10px; }
.ns0 .messagebox.serious { border:2px solid #b22222; border-left-width:10px; }
.ns0 .messagebox.content { border:2px solid #f28500; border-left-width:10px; }
.ns0 .messagebox.style   { border:2px solid #f4c430; border-left-width:10px; }
.ns0 .messagebox.merge   { border:2px solid #9932cc; border-left-width:10px; }
.ns0 .messagebox.growth  { border:2px solid #228b22; border-left-width:10px; }
.ns0 .messagebox.idea    { border:2px solid yellow; border-left-width:10px;  }
.ns0 .messagebox.query   { border:2px solid #ffb734; border-left-width:10px; }
.ns0 .messagebox.move    { border:2px solid #9932cc; border-left-width:10px; }
 
/* image namespace */
.ns6 .messagebox.notice { border:2px solid #1e90ff; border-bottom-width:0.4em; }
.ns6 .messagebox.warning { border:2px solid #b22222; border-bottom-width:0.4em; }
.ns6 .messagebox.serious { border:2px solid #b22222; border-bottom-width:0.4em; }
.ns6 .messagebox.content { border:2px solid #f28500; border-bottom-width:0.4em; }
.ns6 .messagebox.query { border:2px solid #ffb734; border-bottom-width:0.4em; }
.ns6 .messagebox.free { border:2px solid #79CC55; border-bottom-width:0.4em; }
.ns6 .messagebox.nonfree { border:2px solid #EF9132; border-bottom-width:0.4em; }
.ns6 .messagebox.pd { border:2px solid #7E80A3; border-bottom-width:0.4em; }
.ns6 .messagebox.move { border: 2px solid #9932cc; border-bottom-width:0.4em; }

(yes, we use separate colors for free/nonfree/pd licenses, free have green borders, pd are dark blueish grey like down here, non-free has orange borders)

Theoretically, you could just redirect all the metatemplates over to one central mbox, and let the CSS classes do the work instead of weird template hacks. For demospace stuff (forcing to render it a different way than intended), you'd use something like <div class="ns-0">...</div> ViperSnake151 22:47, 11 August 2008 (UTC)

Yes, we are aware of this method. See for instance my example at Template talk:Main talk other#CSS namespace detection. However CSS based namespace detection has some drawbacks, so I am still studying it to see if we can solve all the drawbacks:

1: Up until two days ago it was messy to detect talk space, since there are nine different talk spaces on Wikipedia. That meant adding nine class names for each talk space colour class in the CSS code, which made the CSS code bulky. We have now solved that by updating the MediaWiki software to add a "ns-talk" class to the HTML body tag for all talk pages. See discussion at Wikipedia:Village pump (technical)#CSS talkpage detection.

2: Detecting "other pages" like for the {{ombox}} is messy since that involves six namespaces. We can solve that by making the "other pages" style the default (first) style in the CSS, and then override that style for the other page types.

3: Most message boxes are only meant to be used on one type of pages. When such boxes are demonstrated or discussed on other pages then they should not change appearance. We can solve this by adding two class names to each colour class in the CSS code. For instance like this:

.ns-talk .mbox-notice,
.tmbox-notice { 
    /* tmbox notice colours */ 
}

And then having special non colour changing boxes for each type. Boxes that use the special class names like "tmbox-notice". That means the exact same code that we already have in for instance the {{tmbox}}. So we still need all the specialised mboxes.

4: Using the <div class="ns-0">...</div> approach to simulate the demospace option doesn't work for a number of reasons. First of all it means surrounding the box with a div when you want to lock its colours, which breaks the box flow, box sizing and box margins. Secondly if you are on say a talk page and want to show the "other pages" style then you can not achieve that, since the other pages classes have to come first and the talk page classes further down in the CSS file. (See point 2 above.) Since the div can not override to something further up in the CSS file, only to something further down. What we can do is if the mbox gets the demospace parameter then it can use internal parserfunctions to change from the style changing 'class="mbox"' code to more specific code like 'class="tmbox"'. However that gives you an mbox with way more complex code than the current mbox.

All this together means that CSS based namespace detection costs more CSS code (more class names, same amount of class content), just as many different boxes, and a much more complicated {{mbox}}. Of course, the demospace option is not that important, so we could simply drop that one, thus making the mbox code manageable. But that still means we need all the mboxes we have now, and an mbox with its own full code instead of just calling the other boxes, and it still means more CSS code than we use now. So at the moment I see no gain, just losses, in using CSS based namespace detection for the mbox. Sorry.

I think this all comes down to that CSS really is a very bad programming language, while Wikipedia template coding is a much more versatile programming language.

And ouch. I checked, you are actually using the code you show above at wikibooks:MediaWiki:Common.css. Your code contains this line: ".messagebox img {}". Shouldn't it be ".messagebox .img {}" (note the dot), or are you actually padding the images instead of the image cells? I don't think that will work well. And you use "width:90%; margin:0px auto;" for the whole box, instead of say "margin: 0px 10%". Your width+margin code makes the boxes flow left instead of centre in older browsers, and their box flow breaks in several modern browsers (boxes will overlap with other kinds of boxes).

Sorry to be so negativistic today. I really would like to see some neater approach than our current. (Not saying that our current approach is bad, but improvements are always welcome.) So I am still investigating and I am open for suggestions and discussions.

--David Göthberg (talk) 00:29, 12 August 2008 (UTC)

ViperSnake151: Thanks for bringing up the CSS classes and namespace detection. It inspired me to come up with what I think is an improvement. See the next section "Simpler to use class names".

--David Göthberg (talk) 10:13, 14 August 2008 (UTC)

[edit] CSS based namespace detection solved?

I have figured out how to make "CSS based namespace detection", complete with a working "demospace" parameter and very simple template code. Unfortunately it means fairly complex CSS code.

In the following examples the first two tables are a static ambox and a static imbox. The third table in each example is a "CSS based namespace detection" mbox. (When the namespace detecting boxes don't get a demospace parameter they do detection and adapt to the page type. The demospace parameter is only for demonstrating and testing the boxes.) I won't explain today how I would code this in CSS since that is somewhat messy.

[edit] Method 1

Fairly good class names, very good demospace parameter, but slightly weird to use a class name like "image". "demospace=image" gives an imbox. "demospace=portal" gives an ombox, which is right since that is the default mbox for portals.

<table class="mbox main mbox-notice">
<tr><td class="mbox-image">
<td class="mbox-text">
</table>
 
<table class="mbox image mbox-notice">
<tr><td class="mbox-image">
<td class="mbox-text">
</table>
 
<table class="mbox {{demospace|}} mbox-notice">
<tr><td class="mbox-image">
<td class="mbox-text">
</table>

[edit] Method 2

Confusing "mbox-image" and "mbox-" class names, inflexible demospace parameter. "demospace=image" gives an imbox. "demospace=portal" gives error.

<table class="mbox-main mbox-notice">
<tr><td class="mbox-image">
<td class="mbox-text">
</table>
 
<table class="mbox-image mbox-notice">
<tr><td class="mbox-image">
<td class="mbox-text">
</table>
 
<table class="mbox-{{demospace|}} mbox-notice">
<tr><td class="mbox-image">
<td class="mbox-text">
</table>

[edit] Method 3

Very good class names, inflexible demospace parameter. "demospace=i" gives an imbox. "demospace=p" gives error.

<table class="ambox mbox-notice">
<tr><td class="mbox-image">
<td class="mbox-text">
</table>
 
<table class="imbox mbox-notice">
<tr><td class="mbox-image">
<td class="mbox-text">
</table>
 
<table class="{{demospace|}}mbox mbox-notice">
<tr><td class="mbox-image">
<td class="mbox-text">
</table>

[edit] Method 4

Uses parserfunctions based namespace detection. Very good class names, very good demospace parameter. "demospace=image" gives an imbox. "demospace=portal" gives an ombox, which is right since that is the default mbox for portals.

<table class="ambox mbox-notice">
<tr><td class="mbox-image">
<td class="mbox-text">
</table>
 
<table class="imbox mbox-notice">
<tr><td class="mbox-image">
<td class="mbox-text">
</table>
 
<table class="{{mbox namespace detect|{{{demospace|}}}}} mbox-notice">
<tr><td class="mbox-image">
<td class="mbox-text">
</table>

If you want CSS based namespace detection then I am leaning towards method 3. Since I think it is acceptable with a fairly primitive demospace parameter. And that naming is close to the class naming we are already using.

CSS based namespace detection like this gives very simple template code. And only two things to copy to other Wikimedia projects: The CSS code in MediaWiki:Common.css, and the template code for each message box. However the CSS code is pretty messy to understand and thus is likely to cause future mistakes. And it costs extra CSS code, thus it will cost more bandwidth to send the style sheets to the web browsers. (Remember, only some mboxes need namespace detection, while all visiting browsers download the full CSS code.)

Parserfunctions based namespace detection like in example 4 above means simple and efficient CSS code, but slightly more complex table code for the namespace detecting mboxes. And you have to copy three things to other Wikimedia projects: The CSS code, the template code for each message box, and copy and adapt the template code for {{mbox namespace detect}}. Adapting that template to a different Wikimedia project takes some work.

Unfortunately I think the CSS code for CSS based namespace detection is too complex so it will cause too many mistakes when others edit it. And it will cost more bandwidth. While converting and testing the {{mbox namespace detect}} template to other Wikimedia projects is not that hard, and is more or less a one-time operation for each project. The same goes here on the English Wikipedia: I think people will damage the CSS too often if it is too complex, while the {{mbox namespace detect}} hardly ever will have to be updated.

So I think I still prefer to use parserfunctions based namespace detection. Darn.

--David Göthberg (talk) 04:41, 18 August 2008 (UTC)

I think what you've shown here is that you can't have your cake and eat it: you probably have to have at least two out of (complicated-CSS , complicated code , high bandwidth costs , high processor costs ). Since we've been told to not worry about performance, the two we should probably plump for are the "high" ones. I still think there's value to be had from simplifying the 'Xbox-image', 'Xbox-text' and 'Xbox-imageright' classes, but probably this CSS stuff is best restricted to sites without the ParserFunctions extension. Happy‑melon 09:23, 18 August 2008 (UTC)

Happy‑melon: I assume you mean that we should choose method 4 above, right? (Which is the same thing as the method described in section "Simpler to use class names" below.)

--David Göthberg (talk) 05:29, 19 August 2008 (UTC)

Yes indeed - the others smack of the same style as the admittedly ingenious, but ultimately very messy, hacks we used to invoke conditional statements in the days before parser functions. If the tools are available, we should use them. Happy‑melon 20:52, 19 August 2008 (UTC)

Ouch, yeah I am happy I wasn't coding templates for Wikipedia back then.

I think Happy-melon already knows the rest, but for anyone else reading this:

I think I have investigated CSS namespace detection enough for the mboxes now, and shown that parserfunctions are better in this case. So for hand coded message boxes method 4 is the best choice. (But CSS based namespace detection is still nice in some other situations.)

Method 4 differs slightly from how the mbox meta-templates work now. I will update the CSS classes to method 4. (See next section "Simpler to use class names" below.) But I think we still should have the {{mbox}} calling the other mboxes since that keeps mbox simpler and means mbox will have the special fixes that the other boxes have (they differ slightly from each other).

--David Göthberg (talk) 09:20, 20 August 2008 (UTC)

[edit] Simpler to use class names

Resolved.

I am thinking of changing the naming of the CSS classes for all the different kinds of mboxes. (This will not cause any change in looks, just an internal change in class naming.)

Some message boxes have special needs and can not use the mbox meta-templates such as the {{tmbox}}. Thus people sometimes hand code message boxes. I have noticed that people then often mix up the different CSS classes. For instance if someone has correctly coded a message box for the article space, like this:

<table class="ambox ambox-notice">
<tr><td class="ambox-image"> [[Image:Some image.svg|40px]]
<td class="ambox-text"> Message text.
</table>

Then when someone else copy and paste the code to make say a talk page message box they tend to miss to change all the class names, thus causing this faulty code:

<table class="tmbox tmbox-notice">
<tr><td class="ambox-image"> [[Image:Some image.svg|40px]]
<td class="ambox-text"> Message text.
</table>

So I am thinking of changing the naming of the CSS classes so the message boxes would be coded like this:

<table class="tmbox mbox-notice">
<tr><td class="mbox-image"> [[Image:Some image.svg|40px]]
<td class="mbox-text"> Message text.
</table>

Note how the namespace then is only determined by a single class name. All the other classes would then always be "mbox-something", no matter what namespace the box is for. The CSS code in MediaWiki:Common.css for the tmbox notice style would then look like this:

.tmbox.mbox-notice {
    border: 1px solid #c0c090;
}

This then also makes it easy to make hand coded namespace detecting message boxes, since then we only need to change one class name based on the namespace. Like this:

<table class="{{namespace detect 
| demospace = {{{demospace|}}}
| main      = ambox
| talk      = tmbox
| image     = imbox
| category  = cmbox
| other     = ombox
}} mbox-notice">
<tr><td class="mbox-image"> [[Image:Some image.svg|40px]]
<td class="mbox-text"> Message text.
</table>

I can make a special template for such mbox namespace detection making it even simpler, like this:

<table class="{{mbox namespace detect|{{{demospace|}}}}} mbox-notice">
<tr><td class="mbox-image"> [[Image:Some image.svg|40px]]
<td class="mbox-text"> Message text.
</table>

Sure, we could do the same with the current classes. But that would mean several transclusions of the rather complex {{mbox namespace detect}} template. Thus causing less readable code and causing more server load. Like this:

<table class="{{mbox namespace detect|{{{demospace|}}}}} 
{{mbox namespace detect|{{{demospace|}}}}}-notice">
<tr><td class="{{mbox namespace detect|{{{demospace|}}}}}-image">
[[Image:Some image.svg|40px]]
<td class="{{mbox namespace detect|{{{demospace|}}}}}-text">
Message text.
</table>

I am going to think about this a bit more, and I would like some comments from others before I do this change of the CSS class names. I can do the transition smoothly so that is not a problem.

--David Göthberg (talk) 09:26, 14 August 2008 (UTC)

When I was adding the tmbox CSS I noticed how similar the xbox-image and xbox-text CSS were in absolute terms, not just in usage. I can see how this would be easy to implement, and fully support it. I doubt the current classes are used directly outside the mbox series often enough for this change to cause too much damage, and it has numerous benefits that I can see. Happy‑melon 20:17, 14 August 2008 (UTC)

I can add the new class names (leaving the old ones too) in MediaWiki:Common.css, wait 31 days for the CSS caching to pass, then change the mbox meta-templates to use the new class names.

We can find many of the cases that use hand coded mbox templates by using the Wikipedia search function. I just did a search in template space and only found 7 cases for the ambox classes and 1 case for the tmbox classes, so they will be easy to fix. And I found no hand coded templates for the other mbox types. But in user space there seems to be a little more to fix, especially since some users skin the mboxes in their /monobook.css.

When we have fixed all the hand coded mbox cases and skin cases, then we can remove the old mbox class names from MediaWiki:Common.css. Thus I think we can do the transition perfectly smoothly without any damage at all.

Since the search was a bit tricky, here are the template cases I found, so that I/we can fix them when we get the time. Most of them can simply be changed to use one of the mbox meta-templates, so we can fix them already now: {{Move and semi protected}}, {{Pp-meta}}, {{Schooling late messages}}, {{Tcexpand}}, {{1632GGbook}}, {{24CleanupFlag}}, {{24Plot}}, {{Khmer}}.

I noticed that the search missed some cases that I know exist. So if/when we decide to do this change I will ask the nice people over at Wikipedia:Bot requests to do a full text-search of the database to find any remaining cases. Some of the bot owners do have local copies of the database and can do such full text-searches.

The drawbacks I see with all this is that the new CSS code in MediaWiki:Common.css will be harder to understand, and that might cost some future mistakes. And this change will cost some work. (But as I showed above the classes will be easier to use.) So I still want to think about this a bit more.

--David Göthberg (talk) 01:38, 15 August 2008 (UTC)

In the CSS code, the correct selector would be .tmbox.mbox-notice, not .tmbox .mbox-notice. The latter selects an element with the mbox-notice class inside a tmbox. —Ms2ger (talk) 11:44, 17 August 2008 (UTC)

Ms2ger: Ouch! Thanks for pointing that out. Scary that white space has meaning in CSS coding. As I've said before: CSS is a bad programming language. I gotta read up on those selectors again. Thankfully I test my stuff carefully before I deploy...

I took the liberty of correcting my example above so we won't be confused in the future. So it should be .tmbox.mbox-notice since they are both in the <table> tag, but .tmbox .mbox-text since the "mbox-text" is inside the table in the <td> tag. Tricky.

And this shows the risk with this new approach. The CSS code becomes complex, while the template code becomes simpler.

--David Göthberg (talk) 12:24, 17 August 2008 (UTC)

I have been testing the new "simpler to use class names". The code I suggested above doesn't work in Internet Explorer 5 and 6. IE 5 and 6 can not select on multiple class names in the same element. That is, IE 5 and 6 do not understand this:

.tmbox.mbox-notice {
    border: 1px solid #c0c090;
}

But they can select on class names for elements inside each other, so they do understand this:

.tmbox td.mbox-image {            /* The left image cell */
    border: none;
    padding: 2px 0px 2px 0.9em;
    text-align: center;
}

So the best we can do is this table code:

<table class="tmbox tmbox-notice">
<tr><td class="mbox-image"> [[Image:Some image.svg|40px]]
<td class="mbox-text"> Message text.
</table>

But that is still pretty neat, since this will work:

<table class="{{namespace detect 
| demospace = {{{demospace|}}}
| main      = ambox ambox
| talk      = tmbox tmbox
| image     = imbox imbox
| category  = cmbox cmbox
| other     = ombox ombox
}}-notice">
<tr><td class="mbox-image"> [[Image:Some image.svg|40px]]
<td class="mbox-text"> Message text.
</table>

As you can see we don't need to change the "mbox-image" and "mbox-text" tags to be able to change the styles. I intend to add the CSS for this in MediaWiki:Common.css in a day or so.

--David Göthberg (talk) 23:05, 23 August 2008 (UTC)

I have now added the new "simpler to use" mbox class names to MediaWiki:Common.css. We can change the mboxes to use them 31 days from now when the CSS cache in the web browsers have timed out. That is we can do the change on 25 September 2008.

--David Göthberg (talk) 17:19, 24 August 2008 (UTC)

The 31 days CSS caching has passed. I have now updated all the mbox meta-templates to use the new simpler class names as described above. What remains now is to search for and fix any remaining hard-coded use of the old class names. And then to remove the old class names from MediaWiki:Common.css. That is to remove any usage of "ambox-text", "ambox-image" and "ambox-imageright" and the same for the other mboxes.

--David Göthberg (talk) 20:23, 27 September 2008 (UTC)

I believe that this is now done - certainly neither I nor MelonBot can find any instances of 'a/c/o/t/i-mbox-text/image/imageright' anywhere (except when talking about the conversion process, like this page!), through either wikisearch or googlesearch. Happy‑melon 20:28, 29 September 2008 (UTC)

Sorry but not all done. Wikisearch shows me a small number of cases for most of the mbox types that still needs to be fixed. And then I also found this case that might interest you. :))

And you edited a number of code examples and discussions on talk pages and in talk page archives. You should not have done that. That was not running code but old discussions and examples. They should not be changed. Especially those cases that now show broken CSS code. I will have to revert them.

But I'll do that tomorrow or so, since I really need to get some sleep.

--David Göthberg (talk) 06:28, 30 September 2008 (UTC)

Where? I can't see any (apart from one ombox-image that was a substituted {{ombox}}). Remember that if the page appears in the search results, but doesn't have any text extract underneath it, it doesn't actually contain the string. I've just wikisearched all 10 classes, and only found that one template, Wikipedia:Catalogue of CSS classes, and this page. My googlesearch last night also flagged your talk page and one of your sandboxes, which I ignored. Everything else got changed.

I made a conscious decision to change everything (bar comments on this conversion process itself) to reduce confusion and the possibility of people learning techniques from old discussions that now do not work. I was not aware that it was possible to produce broken code from the transition - please extrapolate so I can see what I need to correct. If the differences were more blatant, perhaps there would be no disadvantage from having left the old discussions using obsolete code, but since they could, IIRC, be overlooked, it's, IMO, best to have coherence. There is precedent in updating links and shortcuts, etc. In discussions like this, for instance, I'd much rather the code and examples had been kept up to date, as it makes reading it in hindsight incredibly confusing otherwise. Just my £0.02. Happy‑melon 08:12, 30 September 2008 (UTC)

First of all, sorry if my comment above was a bit cranky. I have been a bit cranky lately for a number of reasons. (You are not to blame for any of those reasons.)

Okay, after now looking through your edits I see that I was mostly wrong. The grand majority of your edits were very nice. But I found two that caused broken CSS code in the examples so I reverted them: MediaWiki talk:Common.css/Archive 4 and MediaWiki talk:Common.css/Archive 3. And now that I thought about it I agree it perhaps is best to show the new working code when possible to avoid future confusion.

And regarding the internal Wikipedia search: Yes, I know that when one fixes a page one still gets "hits" for that page for a day or so, but one can see that it is a false hit due to not seeing any red text below it. However I did find some actual cases. I have noticed this before, it seems different people get a different "view" when they search. It's very weird, since each time a person searches he gets the same view. Perhaps we are connected to different search servers based on our IP-number or so? (Load balancing that is.) And I know the searches are not complete since I do not always find all cases I know are there. Anyway, I will take care of the cases I see. I'll report back when I am done. It's just a handful of cases.

--David Göthberg (talk) 22:25, 30 September 2008 (UTC)

I have now fixed the remaining cases that mattered. Most cases were in user space, but I also found this case: Template talk:Helpme (diff).

For the time being I skipped some cases of ambox-text/image code in three users' /monoboook.css that do not have any effect. That gives you something to search for if you want to test the Wikipedia search. The cases are User:Mscuthbert/monobook.css, User:Ilyasishak/monobook.css and User:Balloonguy/monobook.css.

Happy-melon: Since both you and I have searched and fixed the cases we can find I now agree that we can deem this done. I will remove the old mbox classes from MediaWiki:Common.css later tonight or tomorrow.

--David Göthberg (talk) 23:49, 30 September 2008 (UTC)

Y Done - I have now removed the old mbox classes from MediaWiki:Common.css. All seems to work.

--David Göthberg (talk) 17:14, 1 October 2008 (UTC)

[edit] Minor issue - bullet point as first line

Resolved.

On my talk page, I use {{notice}}, which was updated about two weeks ago to call {{mbox}}. I'm all for standardization; but it did produce one unintended slight change in how this template handles the first row. If you have bullet points as the first line of text, the bullet does not format correctly. Here's an example:

 {{notice| 
 *First bullet point
 *Second bullet point
 *Third bullet point}}

Which is now equivalent to:

{{mbox|text=
 *First bullet point
 *Second bullet point
 *Third bullet point}}

Displays as:

*First bullet point Second bullet point Third bullet point

This did not happen in the original structure of the "notice" template. I can do a work around by coding it to be:

{{mbox|text=  
 *First bullet point
 *Second bullet point
 *Third bullet point}}

But that inserts an extra blank row at the top of the notice, which displays as:

First bullet point Second bullet point Third bullet point

Is there a better solution for this available - or is it simply no longer an option to have a bullet point as the first line in these boxes? --- Barek (talk • contribs) - 16:17, 29 August 2008 (UTC)

Yes, the standard solution when feeding bullet lists and similar as a parameter to any template is to surround it with a div tag. Like this:

{{notice
| <div>
* First bullet point
* Second bullet point
* Third bullet point
</div>
}}

First bullet point Second bullet point Third bullet point

The div tag adds a slight extra top and bottom margin, but that is hardly noticeable. We kind of have documented this div trick for the mboxes that {{mbox}} calls. But we haven't had the time to fully document mbox yet.

I am surprised that not using the div tag worked for the old version of {{notice}}. I remember we investigated this last year for the {{navbox}} and it had something to do with the table cells and spaces and stuff, but that we couldn't fix it for more advanced templates. So the best solution was to use the div tag for the navbox too.

--David Göthberg (talk) 16:57, 29 August 2008 (UTC)

Thanks for the speedy reply ... I should have followed the link to {{tmbox}} and I would have seen the documentation for this. Sorry to cause the extra time to need to explain it here, but it is appreciated. --- Barek (talk • contribs) - 17:04, 29 August 2008 (UTC)

No problem. Our fault for not documentation what we know. Thankfully we have talk pages to ask and answer at! :))

--David Göthberg (talk) 20:17, 27 September 2008 (UTC)

[edit] Small non-talk messageboxes?

Resolved.

We've had this for a long time, with .messagebox.small (which screws up the font size). After the introduction of {{Ambox}}, it was implemented again in {{current sport-related}}. Should we make it possible to use small messageboxes easily with the *mbox-classes? We already have tmbox-small, so it shouldn't be too hard to port this to the other namespaces. —Ms2ger (talk) 20:51, 13 September 2008 (UTC)

Hi Ms2ger. I have noticed that you are doing excellent work in converting old message boxes to use the new mboxes. Thanks for that!

In MediaWiki:Common.css there currently is the "ambox-mini" class. I did a search some week ago and as far as I could see that class was not used anywhere. Not even the {{current sport-related}} template uses that class, but instead uses hard coded styles for its small version.

{{tmbox}} as you say have the "small=yes" option that uses the "tmbox-small" class. And that option is used somewhat frequently. (It is or should for instance be used for archive boxes.)

If we are going to add the small functionality to some other namespaces then I have some things to say about that:

1: Personally I don't want the "small=yes" functionality for any other mboxes than the tmbox. It adds a lot of code complexity and increases server load a lot since it involves using two templates for each mbox. If you look at the tmbox it now has the Template:Tmbox and the Template:Tmbox/core.

2: For the ambox I have only ever heard this request before for one single template, that is the {{current sport-related}}. Should we really add this option when there is no demand for it? Or do you have some usage in mind for it Ms2ger? If the demand is that low then I think that special case should stay hard-coded.

3: Just adding the class so it can be easily hard-coded in some templates is a much more low impact solution than adding it to the mboxes' code. Still, I wonder when and where it is needed?

4: If/when used in other mboxes it should use the same parameter name as for {{tmbox}}, that is "small=yes". Since that is a well established parameter name for that function and is much older than the tmbox itself. And we should have the same class naming as for the tmbox. Thus for ambox we should change the class name from "ambox-mini" to "ambox-small" instead.

5: I think that the "ambox-small" perhaps should use the same width as the {{infobox}}, not the same width as the "tmbox-small". At least as far as I remember one reason for the small {{current sport-related}} was so it would stack neatly on top of the infobox. And we probably should ask the infobox people why they set the width the way they do.

6: We are currently in the middle of a renaming of the mbox classes. The "subclasses" such as the "ambox-text" and "tmbox-text" will all instead be called the neutral "mbox-text" instead. Thus the "tmbox-small" will also be renamed to "mbox-small". (And I see now that I have missed to prepare that one in MediaWiki:Common.css.) And thus the "ambox-mini" really should be renamed to "mbox-small". This doesn't mean the class will automatically work for all the different mboxes. We still have to decide for which mboxes we will add such CSS code.

Ms2ger: But since you have been working a lot with the message boxes you probably know about cases and needs that I don't know about, so I am looking forward to your comments about this!

--David Göthberg (talk) 02:39, 14 September 2008 (UTC)

One of the main reasons I brought this up was that I found it strange that this old feature didn't get added to mbox, and I remembered that it had been discussed for amboxes. The other uses I remember off the top of my head are {{Archive box}} and {{Autoarchivingnotice}} (before I made it use mbox). That, indeed, is quite rare, but I think that might be because it isn't that easy to implement it right now. For me, just adding the class is enough, but then it would be useful to add a class parameter to the mbox-metatemplates. The exact width isn't that important to me, making it align with infoboxes makes sense. I suppose that, if we'd add CSS for this, we could limit it to amboxes and omboxes. Thanks for your extensive reply, I appreciate it. —Ms2ger (talk) 13:06, 14 September 2008 (UTC)

Ms2ger: Ah, you are right. The archiving boxes need a small class when on "other pages". So I think I will add the "ombox-small" class to the MediaWiki:Common.css today, since it seems to be a clear case. And adding a new class doesn't change anything old. And it makes the ombox classes kind of backwards compatible with the old message box classes, which they are meant to supersede. (But we have to wait 31 days due to caching of the CSS pages in the web browsers before we can use the new class.)

And a correction, regarding my point 6 above: I did some testing and reading up on this again. And rediscovered why I had not prepared the renaming of "tmbox-small" to "mbox-small". It's because Internet Explorer 5 and 6 don't understand the CSS selector ".tmbox.mbox-small". I had forgotten about that. So the small classes will have to stay named "tmbox-small" and so on. That makes it slightly trickier to make hardcoded boxes that can detect and adapt to different types of pages.

So I checked, the {{ombox}} is "only" used on 12,000 pages. So we perhaps should add the "small=yes" option to that one. Since then it doesn't hurt so much if it is a bit more server costly. But it will add code complexity and make the doc for the ombox much longer...

But I still don't want to add the "small=yes" option to the ambox. Since I have been thinking of this for some hours, now I remember: The "ambox-mini" class was added without consensus and only to satisfy one very vocal editor. And then he didn't even bother to use it in his template {{current sport-related}}, since someone helped him hard-code the small function instead. Actually, I think it is time we remove the "ambox-mini" class since it isn't used anywhere. (I searched for it again, no hits.)

--David Göthberg (talk) 17:44, 14 September 2008 (UTC)

An {{mbox}} with "small=yes" when on a talk page.

An {{mbox}} with "small=yes" when on "other" pages. Note! Will be a big box if placed on article, image or category pages.

I went ahead and did the changes and additions:

• I removed the ambox-mini class from MediaWiki:Common.css since it has never been used.
• I added the "ombox-small" class to MediaWiki:Common.css. Due to the 31 days CSS caching we can use that class no earlier than 17 October 2008.
• I added the "small=yes" functionality to {{ombox}} by using hard coded small styles. Thus we can use it immediately. And that means it works from {{mbox}} too. See the examples to the right.
• And I bloated the ombox doc with the full explanation of the small parameters. I hope that won't scare people. :))

So, I think this is Y Done.

--David Göthberg (talk) 21:31, 15 September 2008 (UTC)

[edit] Now we have a dmbox too

I was asked to solve a problem with the disambig and set index boxes. (There are a whole bunch of them.) And while solving that problem I realised it would be better if they used a single meta-template. And they have pretty much the same needs as the other mboxes. So I made the {{dmbox}} which works like the other mboxes but looks like a disambig or set index box.

--David Göthberg (talk) 15:09, 12 October 2008 (UTC)

ROFL! We really have let the genie out of the bottle now! Not that I have any objection to a move towards increased sensibility in template structure and naming... Happy‑melon 17:31, 13 October 2008 (UTC)

Awesome. Are there many more varieties left? Do hatnotes have a standardised base class? Chris Cunningham (not at work) - talk 19:56, 13 October 2008 (UTC)

Happy-melon: Yeah, I was laughing when I coded up the {{dmbox}}. I first called it {{disambigbox}}, but that caused hideous class names such as "disambigbox-image" and "disambigbox-text", and I kept misspelling those long names. And the template should be used for both "disambiguation" and "set index article" boxes. And it can partly reuse the "mbox-image" and "mbox-text" classes, thus saving some CSS code. So I resorted to using the shorter "dmbox".

Chris Cunningham: First let me misunderstand you on purpose: No worries! We have 19 more characters left in the English alphabet, so we are not running out of short mbox names just yet. :))

And slightly more seriously:

I don't know if there are any other mbox similar templates out there that might gain from being converted to use mbox compatible code and parameters. Well, there are the stub notices... Should we call that one {{smbox}}? :))

I took a look at the "hatnotes". That is, the "see also" and "main article" links that goes on the top of pages and sections. And yes, they do have a CSS class, a whole swarm of templates and a meta-template. But I have always found it strange to use templates and CSS for that when all one have to do is to use this code:

:''See also bla bla.''

That's just five characters of well known wikimarkup to handle all the formatting.

--David Göthberg (talk) 04:48, 14 October 2008 (UTC)

By using semantic classes we can do things like hide the text when the page is printed, mark it as disambiguation for spoken-word preparation and restyle every instance at once should the project suddenly find that there is consensus to make the text a couple of points smaller, for instance. Never know when it can come in handy. Chris Cunningham (not at work) - talk 10:09, 14 October 2008 (UTC)

Chris Cunningham: Oops, I think you just proved me wrong!

Yeah, considering your arguments it seems it might be a good thing that the hatnotes have a base-template and a CSS class. Although I still don't like all the sub-templates they use for it, they are confusing. From now on I will probably use the base-template {{dablink}}, since that means the full text of the message gets visible and editable in the edit window.

--David Göthberg (talk) 15:38, 14 October 2008 (UTC)

There are three sets of templates that I consider to be abominations in the eyes of the Template God: the Citation templates, the 'User' templates, and the hatnote constellation. All these collections are just crying out to be consolidated, cleaned up and generally straightened out. However, I don't really think any of them would benefit from an -mbox template - they are after all not actually boxes!! Ditto for the stub templates. I think we should restrict ourselves here to the genus of wikipedia templates that are actually box-shaped :D Happy‑melon 17:33, 14 October 2008 (UTC)

Happy-melon: Right, those template sets you list are a mess. And right, they are not mbox related. But the stub templates are somewhat mbox related, see my explanation below.

Everyone: This is probably stating the obvious for those who have been taking part in the mbox project for some time, but for everyone else: To me, the mbox templates have some common features, but they of course doesn't have to have all these features:

• Mboxes usually look like boxes.
• Mboxes are meta-templates, used to build many other message boxes.
• Mboxes have a left side image thus needing the "image" parameter. And that parameter takes an image with full wiki notation, thus can take any object or even two images on that side.
• Mboxes have a text cell in the middle, thus needing the "text" parameter. Using the "text" parameter is often better than using an unnamed first parameter, among other things since it forces the user to write "text=..." which solves the problem that unnamed parameters can not handle equal signs "=" in the parameter data. (Unless they feed it like "1 = bla=bla". But people don't know that, even if we document it properly, so they waste lots of time trying to figure out why their templates break.)
• Mboxes usually have several types, thus needing the "type" parameter. (Actually, the type parameter mostly helps us to keep the number of mbox meta-templates low. We could have used one meta-template for each type...)
• And when needed the mboxes have some other standardised parameters like "imageright", "style", "textstyle", and some other.
• When we build an mbox meta-template we apply the box flow tricks and other things we learnt when we made the ambox. Thus we package very well tested and working code.

A good thing with standardising on the mbox syntax is that lots of template coders now are used to the ambox parameter names and know how they work. And the more meta-templates that are standardised to this syntax the more people will get used to it.

So, let's take a look at the stub templates:

1: They are many and thus could have good use for a centralised meta-template.

2: They usually have a left side image and a text cell. So the meta-template could have good use for the standardised mbox "image" and "text" parameters.

3: They are messages put in articles, but they don't look like boxes.

4: They don't have different types as far as I know. They all look the same.

So I think they could need a somewhat mbox compatible meta-template, but it is not necessary to call that an "mbox". So perhaps some day when one of us is bored we can code up a {{stub-meta}}, or whatever the preferred name for it will be. And it should perhaps have the "stub", "stub-image" and "stub-text" CSS classes or so.

--David Göthberg (talk) 08:40, 15 October 2008 (UTC)

[edit] Now we have a dmbox too (section break 1)

I moved the comment below from Template talk:Fmbox#Sister project link templates to this discussion, since it really is a part of this discussion and not the "sister project box" discussion. --David Göthberg (talk) 10:36, 3 November 2008 (UTC)

I just came across a *box meta-template for stubs that already exists: {{asbox}}, or Article Stub Box. --Blooper (Talk) 05:24, 1 November 2008 (UTC)

After further research, it seems that a stub meta-template isn't particularly liked among the editors of the stub sorting Wikiproject, seen by these discussions. I'm not still really sure why they think that subst-ing a template is better than a meta-template, though, when a meta-template has so many advantages. --Blooper (Talk) 06:14, 1 November 2008 (UTC)

End of comment moved here from Template talk:Fmbox#Sister project link templates. --David Göthberg (talk) 10:36, 3 November 2008 (UTC)

Blooper: I hope you don't mind that I moved your comment here?

Thanks for finding the {{asbox}}, I was not aware of that one.

I took a quick look at that template and the discussion you linked to. It seems that he who made that meta-template made the mistake of mixing several things into the same meta-template. He mixed style, text and categorisation.

1: He added category handling to the meta-template. I have sometimes considered adding category handling to meta-templates, but so far I have always come to the same conclusion: It makes the meta-template too complex and instead of helping the editors it makes it harder to build templates with it. And that seems to be what happened with {{asbox}}, people disliked its category handling. I didn't see any complaints about the style. (But I just took a very quick look.)

2: He let the meta-template handle the text. He has several parameters just to insert the words for the one to two sentences of stub message. That is just unnecessary complication.

I would instead make a meta-template that normally only needs two parameters: The image, and the full text to display. As simple as this:

{{stub-meta
| image = [[Image:Some image.svg|30px]]
| text = The message body text.
}}

The stub-meta meta-template would take care of the width, margins, padding, and make the text italic. And it would add the proper CSS ids and classes for a stub message. It would not mess with the text (apart from making it italic), and it would not handle the categories at all. Since the formulation of the text and the category handling is unique to each stub template that is built from the meta-template. Thus that handling should be done in the templates, not in the meta-template.

--David Göthberg (talk) 10:36, 3 November 2008 (UTC)

Given the current holy war over the styling of the uw- templates, you'd be surprised how many people feel that consistency is the Great Satan. :) I'd support this of course. Chris Cunningham (not at work) - talk 11:47, 3 November 2008 (UTC)

Sounds like a good plan. The only thing I would suggest is putting the last sentence (You can help by expanding it.) in the meta-template, as that probably wont change from stub to stub. --Blooper (Talk) 17:50, 3 November 2008 (UTC)

Blooper: Oh no, the meta-template should not automatically add any text, no matter how standardised that text is. Since then it would get tangled into the text content discussions. It is easier and clearer if the entire text content is visible as one item in the templates that call the meta-template.

Chris Cunningham: Well, thankfully there doesn't seem to be any warring about the looks for stub templates. They seem to have a simple and unified look. Actually, as I have stated before, it seems the stub templates are in a pretty good shape. Thus there is no hurry to make a meta-template for them.

The same was true with the disambig and set index templates: Thanks to their good shape and unified look I think most people didn't even notice that I changed them to use the {{dmbox}} meta-template. Since there were hardly any change in looks at all. It was mostly a convenient packaging of the proper code, especially to handle the behind the scenes code for the difference between disambig and set index boxes.

And for that reason I haven't even bothered to convert all the disambig templates to use dmbox yet. It's no hurry to convert the remaining ones. It was just the set index templates that needed to be converted in a hurry, and that I have done.

Of course, there are some discussions about the text content for the disambig templates. But dmbox does not interfere with the text content, thus it doesn't get affected by the text content discussions.

--David Göthberg (talk) 18:09, 3 November 2008 (UTC)

I disagree, DG, often it can be useful and productive to include text in metatemplates. It depends entirely at what level you are pitching the metatemplate: for the mbox series, it would have been crazy to even consider adding default text. For a meta-template like {{db-meta}}, however, incorporating customised sections around standard text has significant benefits. The stub-meta template would be closer in position to db-meta than to, say, {{ambox}} and therefore some default text, where it genuinely is unified across the template collection, is a sensible idea given that it ensures standardisation of the edit-this-page link, and general style. My philosophy in meta-templates is that anything that would otherwise have to be hardcoded into every one of the instance templates should instead be coded at the meta level. Simplicity is still key, and so only one 'text' parameter should be utilised, but there is no reason, in my opinion, to duplicate a sentence (and some moderately complicated link code) a thousand times when it could be trivially coded into the meta template purely for the sake of "cleanliness". Happy‑melon 20:39, 3 November 2008 (UTC)

Happy-melon: And I disagree with your disagreement. Consider what happens if/when some WikiProject wants the "You can help" link for "their" stub template to link to a page explaining how to expand their kind of articles. Then it becomes a big problem if the meta-template adds a standard text.

--David Göthberg (talk) 22:14, 3 November 2008 (UTC)

That is only an issue if we decide to condone such a deviation; obviously if that's the case then the 'ubiquitous' text is not, in fact, ubiquitous, and indeed shouldn't be meta-content. However, if, as is highly likely, no deviations from the standard form are permitted, it remains ludicrous not to meta-code it. You are considering a somewhat different issue to me, I think; my immediate reaction to a WikiProject saying that they wanted their stub template to say something different to the heaven-knows-how-many other templates is to say "what's your very very very good reason for it? Oh, you don't have one that can outweigh the advantages of not having to edit a thousand templates? Then tough." :D Happy‑melon 23:59, 3 November 2008 (UTC)

Why should a link to a message about how to edit a page to a WikiProject's standards go on an article, especially an article that doesn't have much content and needs anything it can get? If that is necessary (which it really shouldn't be), it belongs on the talk page. Also, I doubt the stub sorting wikiproject would like that. --Blooper (Talk) 01:06, 4 November 2008 (UTC)

Happy-melon and Blooper: Well, that is exactly the kind of reasoning that causes unusable meta-templates, and forces people to code up their own special solutions. Which often ends up with the styles also differing.

It is fairly common that some templates need to have different text than the majority of templates of the same type. Some disambig boxes have slightly different text than the generic one just for grammatical reasons! Since the standard part of the text would otherwise not work with the unique part of the text.

And that a WikiProject has a separate page that explains well how to expand their type of articles would probably be a good thing. If we force them to not link that page would then be a loss. Anyway, that was just an example that I came up with. What I mean is that we can not know in advance what text needs the templates will have in the future.

If the text is not part of the meta-template then we will not have to resort to weird solutions, when some of the templates that use the meta-template have special text needs. And the standard text can of course be a part of the examples in the meta-template documentation, so it is easy to just cut and paste that part of the text when creating a template.

--David Göthberg (talk) 01:40, 4 November 2008 (UTC)

If you insist on it so badly, why not code it with an optional parameter to replace the "you can help by expanding it" sentence? --Blooper (Talk) 02:48, 4 November 2008 (UTC)

Or, it's the kind of reasoning that results in a cohesive set of templates that obey sensible standards. You're used to working with metatemplates that have an awe-inspiring range, used in every namespace for a myriad of different tasks. This isn't one of those templates; its instances are intended to do just one thing. There just isn't the same need for complete flexibility and adaptability here as there is with the mbox series. There isn't even a need to incorporate a 'style' parameter IMO, although we might as well add one since it's so trivial to do so. Really the only things that vary among stub templates, and the only things that should vary among stub templates, are the image and the first sentence. Anyone who wants to alter anything else needs to have a damn good reason why. Happy‑melon 08:54, 4 November 2008 (UTC)

I'm deeply skeptical of the alleged merits of having a metatemplate that'd be transcluded into about half the article space. (And yes, I'm also pretty skeptical about WP:PERF and the level of helpfulness of our dev cadre in such matters, before I'm pointed at either of those.) That there's a similar template already in significant use seems to be the results of its creator going on a kite-flying exercise by "piloting" it on several hundred unsuspecting exercise, as part of a "consultation exercise" that had a response someplace between "tepid" and "opposed", rather than being a sign of any popular uptake, as far as I'm aware. Given that those seem to be getting tweaked on a semi-regular basis, I'm really not sold on the benefits of them vs. leaving well-enough alone.

On the other hand, I do think that the format of stub templates should be as standardised as possible. There's a long-standing set of guidelines on what format they should be in, and there seems to have stabilised a consensus that there should not be WPJ links and such like, in light of these being transcluded into the articlespace. (Following a rash of such additions a while ago, that seemed to progressively get removed subsequently.) Having pointers from otherwise-innocent articles into exotic regions of the project space could have undesirable (and presumably unintended) connotations of article ownership, or just be entirely confusing to the passing reader and casual editor.

There are, however, a couple of special cases, such as stub categories with multiple upmerged templates, where a template sort key is handy, and templates that are upmerged to multiple stub categories. (Which might be arguments against the approach that asbox takes, as an editor above appears to argue.) Alai (talk) 04:51, 6 November 2008 (UTC)

Alai, just before posting this message I made null edits to Template:!, Template:Portal and Template:Stub-Class, which are the three most-used templates on en.wiki, having between them over five million transclusions. As you can see, we're still here; a set of edits that would have crashed the site a year ago is now inconsequential thanks to improvements to the MediaWiki software. We are in a position where we genuinely can not worry about performance; the rendering and caching backend of MediaWiki is so efficient and load-balanced compared to the rest of the software that it is only unrestrained editing that causes problems. If you believe that "the format of stub templates should be as standardised as possible" then I'm not sure how you can rationalise that with a disinterest in a meta-template. One leads inevitably to the other, IMO. If there are a clear set of guidelines, then it's a simple as rewriting them in template form and linking to it! I agree with your comments about cross-namespace links, and am pleased that there seems to be opposition to this; as I've said above, it will make our lives easier. I agree with you and DG that the major failing of {{asbox}} was trying to do category links; these should be handled separately. Happy‑melon 12:41, 6 November 2008 (UTC)

Any progress on anyone taking a look at a stub-meta? It's a great idea to get them all standardised. —Borgarde^talk 05:16, 20 November 2008 (UTC)

[edit] Recycling WP templates

This discussion was moved here from my talk page. --David Göthberg (talk) 22:50, 13 November 2008 (UTC)

Hi, David I note from the template talk pages, that your a template expert. I wonder if you could assist me or point me to the relevant info as I'm attempting to recycle (copy) Wikipedia templates to a Wikia project I started. The Msg box, Ambox and {{ombox}} templates display the Icon and characters outside the box border My version Here. I got a working Navbox look alike but it has faults (i.e. edit buttons centre and don't function correctly and if 2 added to apage they have a space of about 5 lines between them) Example here on my Caterpillar inc. page. Another problem i have is that after {{template}} in text the text jumps to a new line indented like this Example. Is some code missing from other files Like CSS & JS (I Dont fully understand how these work) but have seen these mentioned and an editor on the Wikia site did help a bit to fix Navbox for me?

I want to create a simpler version of Infobox companies, as thats non functioning (it displays loads of makup characters) and is over complex for my needs. Can you point me to a helpful guide to writing Wiki template code and understanding how to follow parameters used. (is there an online editor to help write them ?)

Thanks in anticipation BulldozerD11 (talk) 17:07, 13 November 2008 (UTC)

End, discussion moved here from my talk page. --David Göthberg (talk) 22:50, 13 November 2008 (UTC)

Hi BulldozerD11. I took a look at your Wikia code:

1: First of all you have gotten much farther than most, since you have correctly hard-coded the CSS styles into the templates. Good work.

2: You should be careful with newlines and whitespace. They have meaning in template programming and wikitext. For instance in your comment above you had a spurious newline followed by a space before the next word, that caused a dotted box around parts of your text. (I fixed that.) You have similar problems in several of your templates over at Wikia. And you also moved some stuff outside the noinclude tags in some of your templates, causing even more whitespace problems. I fixed it for your {{tl}} template. But it needs fixing in your {{t1}} template too, and likely in some other places too, since that is a mistake you seem to repeat.

3: Your Ombox problem with the visible