|
|
|
| The big yellow "you have new messages" banner was created for a reason. If you want my attention, edit this page. If I want your attention, I will edit your page. If I just want to reply out of politeness, I'll do it here and save interrupting whatever you're doing... if you're interested in what I said, watch this page and find out. If I'm keen to see your response, I will be watching your talk page, or wherever I suspect you might post it. But if you have something to say you think I need to read, the big yellow banner is kind of hard to miss... |
|
mbox
I didn't bring this up there becauase adding a tangent to an existing discussion is a great way to sidetrack a discussion (making it near impossible to determine consensus).
One of the goals of this proposal is also the hope that this may remove at least one of the stumbling blocks in the way of possibly eventually merging at least a few of the several types of mbox.
I don't know if that is something you'd be for or against, but I thought it might be worth noting. - jc37 20:07, 21 November 2008 (UTC)
- Hmmm... I don't really think that the type names are much of a hindrance to merging mbox types, since they're standardised across the whole set. I would be opposed to merging mbox types, for a variety of reasons. Of the five 'namepsace' mbox template, I assume you'd advocate merging imbox, cmbox and ombox into one "other namespaces" box, to leave us with just ambox, tmbox and ombox. Imbox in particular contains a number of special features that are bespoke to the image namespace (like a whole new type!) that would by this amalgamation be propagated to all other namespaces... featured help page, anyone? Similarly, ombox contains code (the small option, for instance), that should not be available in the image namespace. I do happen to like each and every one of the styles we have, which seems to be something of a rarity, but that is just a personal preference and could easily be replicated even if the templates were merged. The main problem is that each mbox template is subtly different, each having its own quirks and foibles, and so merging them is a very complicated task that would result in single template that is more complicated, more bulky in terms of code length and processing time, and can't be so easily modified (since every time we wanted to change anything in one namespace we would have to be careful to check that nothing's broken in other incarnations). All in all, a system IMO inferior to what we have at the moment. Happy‑melon 11:41, 22 November 2008 (UTC)
- Other than imbox (which covers the double task of licenses, and really shouldn't be merged with anything as it currently exists), the differences of the others appears to be mostly cosmetic. (Unless there is something about tmbox that I'm missing?) And so yes, I believe the rest could be merged through consensual discussion.
- Anyway, this wasn't and isn't the main reason why I'm making the proposal, but I thought it might be worth mentioning as an additional benefit. - jc37 12:25, 22 November 2008 (UTC)
- Tmbox also has a "small" option, uses some clever tweaks to allow tmboxes to 'nest' (but not quite the same tweaks as used on imbox) and has, of course, the extremely deeply-ingrained coffeeroll background. I doubt you'll gain much support for changing the talkspace messageboxes to anything without that famous brown background. Good call, I think, on keeping this separate from the main discussion: it's certainly an issue for another day. Happy‑melon 12:31, 22 November 2008 (UTC)
- Yes, but we already have templates which note when they're in the talk-space, so I would presume that the cosmetic "look" of talkspace boxes wouldn't be much of an issue to implement? (Though I can definitely see the concern about adding "one more if statement, and another, and another, etc." : ) - jc37 13:02, 22 November 2008 (UTC)
- (Note: In reading the above, I thought tmbox was "template mbox", rather than "talkspace mbox". It's something I "know", but keep forgetting : )
- Also, is there a reason that the "extra" benefits of tmbox (such as "small") shouldn't be options on other mbox types? - jc37 14:57, 22 November 2008 (UTC)
- Er, the templates that switch style when they're in talkspace do so by using tmbox in talkspace!!! There is definitely no point in converting all the talkspace messageboxes to use a template other than tmbox if you're then going to tell that template to go back to displaying tmbox-like behavior in talkspace! that would be utterly pointless :D... Merging mbox templates only makes any sense at all when you also merge the associated mbox styles, which would be contentious to say the least. Probably a majority of users would want to see style A merged with style B, but try and get a consensus to agree on which styles A and B are? No chance :D. The majority of the unique features of each mbox template are generally pretty bespoke and not very useful outside that namespace: the "featured" and "license" types of imbox, the 100% width of fmbox, the automatically-expand-inside-templates-like-WPBS of tmbox, are all largely useless elsewhere and just clutter up the code. I can't see the utility of, for instance, {{cmbox|small=yes}} - are there any examples of image pages where such functionality would be genuinely useful? I'm not aware of any; ditto for category pages. The small code is probably the most complicated and messy part of the entire mbox structure, which is why it hasn't been propagated to other mbox templates. I think the only merger that would make any technical sense would be ombox/cmbox, but even then there are a few oddities (different default images, for instance), and there are probably enough people who like the more vibrant coloured backgrounds in an otherwise incredibly dull namespace enough to make it difficult to attain a consensus for such a change. While the road to get to this position certainly hasn't been smooth, I think the way the mbox series is laid out at the moment is probably, bar a few details (like the type names in your original thread), about as effective and efficient as we can make it. Happy‑melon 18:56, 22 November 2008 (UTC)
- Hmm. I seem to recall that there are templates which are used in multiple namespaces, which switch to different backgrounds depending on namespace. Perhaps you and I are talking about two separate things.
- And things like template width are just variable entries, and as such should be easily "set" on a switch of some kind, I would presume?
- (I always feel slightly handicapped in these discussions, because - as of yet - I haven't learned more about how wikimedia software does certain things, so, even though I'm a programmer, I'm not positive about syntax, and where code is "stored" page-wise. So please bear with me : ) - jc37 22:57, 22 November 2008 (UTC)
- No, you are correct in that there are templates that are 'shape shifting' and change appearance based on which namespace they are in. They use the template {{mbox}}, which is a 'director' template. {{mbox}} contains no rendering code at all; all it does is select, based on the namespace, one of the other mbox templates ({{ambox}}, {{imbox}}, etc) and passes all the parameters it is given to that template. So each namespace uses exclusively one metatemplate to render its boxes; in some cases, however, there is mbox in the middle directing the code flow to the right template. We have considered a variety of ways of making templates change appearances based on namespace. We have found that this 'flow control' template is the most efficient and clean solution; other implementations which combined functionality into one template were complicated, messy and much less efficient. It's quite simply cleaner and more elegant to use separate templates. The point is not that such things couldn't be "set on a switch of some kind" - you're right, they could and, where unavoidable, are - but it is a very hackish way to code. Happy‑melon 23:06, 22 November 2008 (UTC)
- (De-dent) - I dunno if I would call: "on A, do"; to be a "hack", but then perhaps it's a mediawiki syntax problem : )
- And Template:WPCOMICS Archive is one that changes styles per namespace. But then I suppose it also hasn't been modified to be an mbox clone either : ) - jc37 07:04, 23 November 2008 (UTC)
-
- Indeed that's not a hack, doing "on A, do X, else on B, do Y, else on C, do Z, now do something regardless, now on A, do X, else on B, do Y, else on C, do Z, now do something else, then on A, do X, else on B, do Y, else on C, do Z, now do something, etc etc etc" is very messy indeed. And if you're not going to do that (ie, if you're going to write "on A, do this whole box code, else on B, do this whole other box code") then what's the point of merging them at all? The only valid reason to merge templates is to remove duplication; either we remove the duplication and end up putting huge #switch: statements on just about every other line, or we keep the template codes separate and don't actually remove the duplication at all. Happy‑melon 10:45, 23 November 2008 (UTC)
- I think I may have to reluctantly agree.
- Mostly because I don't know what the performance costs are for each way. And it sounds like from what you're saying, that having them as separate constructs is "better" than using switches. Is that correct? - jc37 17:11, 23 November 2008 (UTC)
- Yes. Whether we had them in one template or five, the cleanest, most efficient and most convenient way to code them is to keep them as entirely separate structures. Given that, what's the point of including all the code for all five structures on every page, when only a fraction of that code is used? Happy‑melon 17:46, 23 November 2008 (UTC)
- enduser-friendliness. But then, that is apparently the goal of Template:mbox? - jc37 19:42, 23 November 2008 (UTC)
- Which "enduser" are you talking about? If you mean wikipedia readers, keeping the templates separate reduces the amount of code their browsers are forced to download and the time taken for the MediaWiki parser to process the page. If you mean people who code 'simple' templates, than yes, {{mbox}} was designed specifically to make switching between styles completely painless: if you code up a talkspace message using {{tmbox}}, and want to also use in it the image namespace (don't ask me why :D), just strip off that first 't' and you suddenly have a template that will seamlessly switch from one implementation to another when you move it around. All the features used by the main xmbox template for that namespace automagically become available when you move into that namespace, and disappear equally magically to avoid cluttering up other namespaces. What more do you want? :D Happy‑melon 19:47, 23 November 2008 (UTC)
- Nod, I can see the intent (which I suppose can be as valid as any other, it's merely a matter of presentation). Which is part of why I was reluctantly agreeing with you, several posts back : ) - jc37 13:54, 24 November 2008 (UTC)
- I noticed, I'm just working on the reluctance :D. Seriously though, I'm glad you're willing to change your mind; it indicates that you're a reasonable person. A lot of this stuff certainly isn't obvious at first glance and on first appearances it might well look counterintuitive. You're quite right to bring up such 'issues' when you see them as it's impossible to tell on the surface which parts have been carefully designed counterintuively and which are just genuinely stupid! It's just important to keep an open mind and assume the best at all times. For me on the other hand, it's often difficult for me to see why a piece of code appears poorly-designed to the uninitiated: it's often the case that the most elegant way to test a complicated condition or implement a particular idea looks confusing or counterintuitive; similarly it's always nice to have some feedback on how the systems we create look to those who see them as 'black boxes' the workings of which they don't fully understand. Then again, I wouldn't say that I'm completely divorced from that perspective: the geo- and flag-templates are just as incomprehensible to me as I assume they are to you! All in all, it's an exercise in collaboration, just like everything else on-wiki. Which is really a fantastic life skill... maybe I should put it on my CV :D Happy‑melon 15:52, 24 November 2008 (UTC)
-
- Well, it's nice to hear that at least "someone" considers me "reasonable" : )
- I have to say that it so feels like I'm banging my head against the wall in trying to get people to think "outside the box" for a moment, and look at other ways in which something could be organised or implemented.
- Once they've accepted or understood one way, they seem to become entrenched in that way, refusing any and all others.
- Needless to say that seems rather contrary to the Wiki-ideals of constant adpatability and of consensus can change.
- I've noticed that when editors focus on the unsupported/subjective/arbitrary they usually are dealing with ILIKEIT/IDONTLIKEIT. But for me, the biggest issues of unsupported/subjective/arbitrary that I tend to face are IWANTIT/IDONTWANTIT. Usually do to an underlying fear of some kind. (The most common being: give them an inch and they'll take a mile, so IWANTIT to stay like it is to stop "them" from doing whatever I'm afraid that they may do in the future. Logical fallacy that that is, it's fairly common.)
- Anyway, back on topic (somewhat anyway), I still think that cmbox and ombox, at the very least should be merged. The main difference is that one is for those who liked the shading on the "other namespaces", and the other doesn't have the shading.
- So while I can see your point about using different structive boxes to contain the different "styles", I wonder if a binary switch setting for the two styles might be possible/appropriate. (shading = yes/no)
- Though to be honest, I think that, other than ambox (white), and tmbox (coffee), all the other boxes should use the shading standard convention. It's how templates were, and honestly, I think it would resolve several disputes.
- For example the debate at MfD would be instantly resolved. All deletion templates get the pink shading, with speedy getting the bold border all the way aound. QED. (And interestingly enough, this "style" is how several of the XfD templates were in the past.)
- And it has the added benefit of the templates standing out even more from the wall-o-cleanup. (I am of the strong opinion that, while "delete" should be standardised as part of the mbox system, it shouldn't be part of the wall-o-cleanup.
- Look at Template:Notability, Template:Afd, and Template:Prod. At first glance, these are (and have repeatedly been) mistaken for each other. (Template:Blpdispute, Template:Fictionlist, and others on Wikipedia:Template messages/Disputes, have as well, just not as often.)
- This is a problem that needs resolving immediately. The purpose of the standardisation was to reduce confusion, and here it's causing it.
- Note also all the different "levels" to the cleanup notices on Wikipedia:Template messages/Cleanup alone. (Including red, by the way.)
- But of course, for any change to happen, we'd be facing IWANTIT factions who I'm not sure would even "give" this much yardage.
- So while the proposal I note above concerning XfD templates would resolve quite a bit, and presumably end disputes of editors (which would free them up for other discussions/tasks), I'm "reluctant" to be optimistic concerning such a proposal. - jc37 16:59, 24 November 2008 (UTC)
- So... What do you think? : ) - jc37 17:01, 25 November 2008 (UTC)
-
-
-
- Hmm... sorry for the delay; too many things floating around in my head... I certainly agree to a certain extent on the I(DONT)WANTIT front, although I don't agree that the argument is always a logical fallacy. If there is evidence to support the claims both that going a mile would be a bad thing, and that people genuinely would take a mile, then it's perfectly cohesive argument. Of course, objective evidence is often (even usually) lacking, particularly for the former claim. On the other hand, if you can argue cohesively that taking an inch is itself bad, then it's a separate argument entirely, which I consider to be the case in the specific instance of allowing non-deletion messages to use the "delete" type, for instance.
- From a technical perspective there is no advantage whatsoever to be gained by merging templates that use distinct styles, it's as simple as that. With the ease of the {{mbox}} template for switching between structures it really is counterproductive unless the intent is to fully replace two structures with one. So merging ombox and cmbox only makes sense if we also wish to unify the two styles, either deprecating one in favour of the other, or merging them both together into a third. That's very much a separate discussion. I don't agree that the three examples you give are easily or even plausibly confused, and the distinction would be more clear in other namespaces, not less, as full coloured borders would be employed. So I'm not really convinced by your argument, I'm afraid. Happy‑melon 14:14, 26 November 2008 (UTC)
Template:Namespace is giving an incorrect message in some of the articles where it's used
Hello Happy-melon! Please take a look at the top line of Wikipedia: The Missing Manual, an article whose name collides with our namespace conventions. It uses Template:Namespace to apologize for replacing its title with an altered version. But it claims it replaced the colon with a *semicolon*, which is not there at all! (It's a hyphen, not a semicolon). I think your edit of November 13 might have to be re-thought, since the previous text was more appropriate. (Refers to 'substitution or omission of a colon' without saying what it was replaced by. A 'Whatlinkshere' of the template shows a variety of other occurrences which also aren't right. Thanks, EdJohnston (talk) 05:17, 23 November 2008 (UTC)
- Mmmm, that edit was following on from the proposed policy change to standardise what we replace colons with when they're in invalid positions: I had originally suggested semicolons, but I'm coming round to the conclusion that a hyphen is actually better. Happy‑melon 10:40, 23 November 2008 (UTC)
Hi,
This seems to have stalled recently. Mind having a look to see if we can go with the simplest thing which works, and then jettison the old code? Just looking at some examples where the current code doesn't drop in nicely, Apollo 11 has some stacking / float issues. Chris Cunningham (not at work) - talk 21:55, 23 November 2008 (UTC)
- Awesome work on those, by the way - the current layout is clean and stylish. Have you a full list of what this has deprecated, or what work still needs to be done to get all our audio clips using this? Chris Cunningham (not at work) - talk 15:23, 25 November 2008 (UTC)
-
- The most important task is actually to clean out trancslusions of {{Sound sample box align left}} and {{Sound sample box align right}}. These were used as 'wrappers' to hold other templates; with the new code for {{listen}} this was causing very ugly formatting when a listen template was inside a sound sample box. I solved that issue by blanking those templates, but this inevitably broke any instances where the contents weren't listen templates. So the priority should be to replace all transclusions of those two with appropriate listen templates. Then we of course need to go through all transclusions of {{listen}} itself and make sure that they are now appropriate, especially since the default position has changed from left to right. Once that's done, I can see from a quick glance that {{listen}} deprecates the Template:Multi-listen start/item/end system as well; all the other templates seem to be for inline audio. Which is not to say that we can't have a go at clearing them up later... :D Happy‑melon 14:57, 26 November 2008 (UTC)
-
-
- Okay; I'll start chipping away at this. Didn't take that long to eliminated {{multi-video start}} et cetera - incidentally, the TfD for that template is still open; could you have a look at resolution? Chris Cunningham (not at work) - talk 15:10, 26 November 2008 (UTC)
-
-
-
- Closed and deleted :D Happy‑melon 18:28, 26 November 2008 (UTC)
-
-
-
-
- Cheers! Chris Cunningham (not at work) - talk 21:59, 26 November 2008 (UTC)
I have granted you admin rights on the labs wiki. Bastique demandez 02:35, 25 November 2008 (UTC)
I see that you are still interested in Flagged Revisions. I actually played sometime ago in LabWiki with sighting/unsighting too (without sysop access). So I am interested of your experience. Ruslik (talk) 14:34, 26 November 2008 (UTC)
((mfd)) on category pages?
Hi Happy-melon. I just noticed that you (or rather MelonBot) has tagged category pages for deletion by using {{mfd}}. I don't know that much about deletion procedures, but I think that for category pages you should use {{cfd}} instead. Here is the list of namespaces where {{mfd}} is intended to be used: Wikipedia:Miscellany for deletion#Introduction.
--David Göthberg (talk) 08:03, 25 November 2008 (UTC)
- If you follow the link, you will see that the MfD is a bulk nomination of pages in a variety of namespaces, including categories, templates and project pages. As such, it made more sense to treat the whole lot with one deletion debate than to have separate XfDs for each topic. I'd encourage you to participate in the discussion, it's in bad need of some contributions. Happy‑melon 08:43, 25 November 2008 (UTC)
-
- Ah, I see. You are right. And I will try to squeeze in some time to read up on and comment on the discussion you linked to. Even though I am really on a mini wikibreak since I have a lot of urgent things to do in real life.
- --David Göthberg (talk) 10:42, 25 November 2008 (UTC)
The sound templates
By removing the formatting for what you refer to as deprecated templates, you just broke a LOT of articles. The very definition of deprecated is that you should slowly lean away from using it. Erzsébet Báthory(talk|contr.) 12:02, 25 November 2008 (UTC)
- Hmm... I did considerable investigation and concluded that this was the best way to fix a lot of articles :D The audio templates are enough of a mess as to preclude us doing pretty much anything to fix them without breaking some in the process; make omlette, break eggs, sort of thing. I agree it's unfortunate so I'll be working to fix those articles that are broken as quickly as possible. Happy‑melon 14:36, 25 November 2008 (UTC)
- Just here to tell you I hate you. You broke a lot of articles, without any indication in those articles why they had to be broken. it took me several hours to find out who was the pseudonymous vandal. I assume I am not the only victim of your vandalism. Erik Warmelink (talk) 10:15, 26 November 2008 (UTC)
- Thankyou for your informed and informative post. Happy‑melon 13:52, 26 November 2008 (UTC)
- Well, no. I should thank you for your "improvements" to the layout of wikipedia. Unfortunately, someone (who doesn't even use colour in the signature) didn't understand your art and pages like the Fall (band) were reverted to their dull, boring appearance. Erik Warmelink (talk) 21:46, 26 November 2008 (UTC)
MfD
I've closed the discussion.
Based upon the results, I'm not certain if the MfD tags should be removed or not.
Perhaps a better solution might be to replace the MfD tags with some template as listed on Wikipedia:Template messages/Maintenance, in order to show that this task is currently undergoing work. - jc37 16:23, 25 November 2008 (UTC)
- Thanks! Something for me to do on a rainy day... :D Happy‑melon 16:28, 25 November 2008 (UTC)
-
- The latter part of the above was a question : ) - jc37 16:36, 25 November 2008 (UTC)
-
-
- Hmmn, maybe. It is raining at the moment :D. If I don't get around to doing this within a couple of days, I'll do a find-and-replace to change the mfd tags to a bespoke notice. Hopefully it won't drag that much. Happy‑melon 16:48, 25 November 2008 (UTC)
-
-
-
- Ok, thank you : ) - jc37 17:00, 25 November 2008 (UTC)
Merging "tmbox-small" and "ombox-small"
Hi Happy-melon. Just wanted to mention that I have responded to the message you left on my talk page. But I copied it to Template talk:Fmbox#Merging "tmbox-small" and "ombox-small" and responded there, since it was a continuation of the discussion there.
--David Göthberg (talk) 14:34, 27 November 2008 (UTC)
Audio template (again)
Hey, sorry to keep dragging you back to this (from the looks of your talk page you've had a lot of it recently), but I was wondering if you wouldn't mind checking over some proposals I've made for further changes to the Listen template. I would also like to say well done for getting a template updated when it needed it. There are too many templates that need changing which are left in disrepair, and it is worth "breaking" a few articles to fix them once and for all. Thank you – Ikara talk → 04:40, 28 November 2008 (UTC)
Trolish behaviour
Hello, Happy-melon ... thnx fer this revert of Template talk:Oldprodfull ... I was ignoring the troll, as is my habit. :-) Happy Editing! — 72.75.110.31 (talk · contribs) 23:00, 30 November 2008 (UTC)
- You're welcome! I'm not sure how that page made it onto my watchlist, but the edit certainly caught my eye! Happy‑melon 23:03, 30 November 2008 (UTC)
- That usually happens to me when I'm wikistalking a vandal and stumble across a comment page (in their edit history) for a user, article, or template that I've never encountered before. :-) — 72.75.110.31 (talk) 00:31, 1 December 2008 (UTC)
qualitycats
Hmmm, I just wrote a hook Template:WPBannerMeta/hooks/additquals but now I've just discovered one that you wrote Template:WPBannerMeta/hooks/qualitycats which seems to do a similar job, which was undocumented on the hooks page. Obviously we don't need both ... Martin 17:28, 1 December 2008 (UTC)
