This is an archive of past discussions about Template:Ambox. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
For many years already, articles have been tagged with "issue tags." There are all different types of issue tags. POV, unreferenced, bare URLs, just to name a few. There are dozens of them. New ones are created a lot. In fact anyone can create one, and a consensus is not even needed. I have created some myself. They can also be deleted using the TfD process, and I have watched some long in use get deleted.
Here's the problem: they have gotten so out of hand that in many cases, their presence in an article does not always make sense anymore. Quite a lot of the time, they seem to be sitting there indefinitely, and one cannot figure out why they are there. The editor who originally tagged the article often has disappeared from the project, and the reason why the tag has been placed there to begin with cannot be determined. Not to mention, there are actually quite a lot of tags themselves that have a very ambiguous meaning, and many people do not really know what they are.
Here's another question: who are the tags for? Are they for the readers, the editors, or both? Or are some for the readers and some for the editors? This is yet another thing that remains unclear. The tags have gotten to be so overwhelmingly used that they are to the point of being an eyesore.
I am not in favor of abolishing the system, just revising it so that:
1.) The clear meaning of every tag be known to everyone who views the page, and there be a link to the policy or guideline it references
2.) The reason a tag was placed be stated in the tag, possibly in a collapsible section in case the explanation is long, so editors can more easily figure out how to solve the problem and fix it and know when to remove it
3.) The exact date a tag was placed (not just the month) be within the tag
4.) There be a link to the editor who placed the tag, so that editor can be contacted if possible to be asked more details as to why s/he placed it there
5.) Some tags seem to remain indefinitely and the issues never fixed. There should be a project aimed at getting to those that have remained beyond a certain amount of time.
After you had finished ranting, there were some interesting points there :)
Yes, the meaning of every tag should be clear, and there should be a relevant link to get more information. If you know any templates which don't do this, please fix them or draw my attention to them so that I can fix them.
I think in some situations this might be a good idea. For example it is now mandatory to add a reason when using the {{cleanup}} tag. However in other cases, e.g. {{wikify}} I'm not sure what other reason could be given except "this article needs wikifying"!
In fact I asked the bot's operator a while ago (see User talk:Anomie/Archives/2012#Questions from MSGJ) whether the date could be added to the template along with the month and year. This would obviously be a prerequisite before this can be displayed on the template. His response can be seen there.
Yes, this might be a good idea, and this info could be added by the bot at the same time as the date is added. I might make the suggestion to Anomie.
Re your second ob. Martin, about clarification on the Talk page, I think it should be mandatory to put in an entry there even in the "exceptional" case you cite. Doing so provides a ready place for the tag to be discussed and focuses any discussion. It obliges the tagger to think about and cite at least one example, or simply to say the entire article needs deleting or rewriting urgently. It also provides an author who can be referred to contacted etc. LookingGlass (talk) 19:27, 15 December 2012 (UTC)
Small ambox
There is a discussion currently taking place at Template talk:Unreferenced section#Date not showing about the small form of the ambox template and, in particular, whether these templates should be display the tagging date like the full-size amboxes do. Any comments there would be welcome. — Martin (MSGJ · talk) 21:56, 1 June 2012 (UTC)
More structure for this template
I'd like to add some new parameters to this template, which would allow us greater control over the formatting. It will greatly help with proposed changes being discussed here. — Martin (MSGJ · talk) 19:08, 11 June 2012 (UTC)
Talk page link
A lot of amboxes contain a sentence which is similar to "Relevant discussion may be found on the talk page." I propose we add this to ambox which will be called via a talk parameter, which will either be the name of the talk page or the name of the section on the talk page. — Martin (MSGJ · talk) 19:23, 7 June 2012 (UTC)
This is now coded on the sandbox and awaiting comments. The talk parameter can be either
the name of the section on the talk page of the article
a link to a different talk page (plus section anchor if needed)
the case will be determined by parser functions automatically. See the examples below. — Martin (MSGJ · talk) 09:28, 8 June 2012 (UTC)
{{ambox/sandbox|text='''There is something wrong with this article.'''|talk=Foo}}
produces
There is something wrong with this article. Relevant discussion may be found on the talk page.
and
{{ambox/sandbox|text='''There is something wrong with this article.'''|talk=Talk:Banana#Foo}}
produces
There is something wrong with this article. Relevant discussion may be found on Talk:Banana.
Would it be a good idea to roll out this feature to all ambox templates? So that |talk=Foo would always give a link to section Foo on the talk page, whichever template you were using. — Martin (MSGJ · talk) 21:44, 30 June 2012 (UTC)
advice for fixing the issues (e.g. Please help by adding relevant internal links, or by improving the article's layout.)
I propose that we add two parameters issue and fix designed for these two sentences. The current parameter text would still be supported for templates which do not fit this model. The advantages would be as follows:
Being able to display one without the other (the main application for this would be displaying a shortened version on {{multiple issues}})
Displaying the talk page link (described above) in a more natural position between the issue and the fix.
Allowing consistent control over formatting, for example making the issue bold.
Yes, there is going to be a complete overhaul of the documentation in due course, because there are lots of changes that need to be made! — Martin (MSGJ · talk) 07:30, 1 July 2012 (UTC)
Very nice! I fixed a few typos and combined the issue and fix sections. Should there be a better example than {{citation style}}, since it doesn't link to a policy or guideline? Thanks! GoingBatty (talk) 23:18, 11 July 2012 (UTC)
So, |fix= isn't used if the template is used inside of {{multiple issues}}? How then are new editors that are creating their first article learn how to improve and fix them? OR is this a bug where it is not working with the essay, tone, and orphan templates? I'm kind of here. — User:Technical 13 ( C • M • View signature as intended)13:01, 2 April 2013 (UTC)
It's not a bug. The goal of using {{Multiple issues}} (in both its current and previous incarnations) is to reduce the amount of space taken up on articles with many maintenace templates. The trade-off is removing some of the text that may be helpful to fix the issue, and then ultimately remove the template. GoingBatty (talk) 14:10, 2 April 2013 (UTC)
I think that instructions on possible ways to fix an article are crucial to new editors. That being said, would there be a way to offer an on-hover set of instructions to something that otherwise shows as a small "(FIXES)" or something of the sort? I think that would help the new editors learn how to fix their articles and get the issue templates removed instead of getting frustrated because their article has been deleted. There seems to be a lot of "Why did my page get deleted?" or "How can I keep my page from getting deleted?" type questions on WP:TH and WP:HD type forums. — User:Technical 13 ( C • M • View signature as intended)14:31, 2 April 2013 (UTC)
Wrapped around a lot of these templates is HTML comment like
<!--{{Fringe theories}} begin-->
and
<!--{{Fringe theories}} end-->
I imagine this was to aid fixing incorrectly substituted templates, but now we have the proper substitution detection I don't believe there is any need for this and it just makes the code look messy. — Martin (MSGJ · talk) 21:12, 15 June 2012 (UTC)
See this edit that even with the detection we need an indicator of where the template starts and where it ends. Also, I wasn't very pleased to see that you remove this without first seeking consensus. Also, messy is a relative concept. I do not find the addition of those remarks messy, rather they impart a feeling of order, imho. Debresser (talk) 19:39, 16 June 2012 (UTC)
Ah, so you are still here. I think we are the only two editors watching this template and I was wondering if I was on my own here! In response to your points,
even with the detection we need an indicator of where the template starts and where it ends
I would question how much the comment helps here. Most people working with templates would understand that the double braces indicate the start and end of the template call. But in situations like this, using undo is the much easiest solution and doesn't require any knowledge of the code.
I wasn't very pleased to see that you remove this without first seeking consensus
It is a very minor change and this is the first time anyone has questioned this, so I had no idea it would be controversial. Also I could turn this around and ask whether there was any consensus to add this stuff in the first place. (If so, perhaps you could point me towards the discussion.) Anyway I have now stopped removing it and am happy to discuss.
messy is a relative concept
Yes, I suppose it is :) One person's mess is another person's feeling of order I suppose. — Martin (MSGJ · talk) 13:50, 17 June 2012 (UTC)
Yes, I sometimes also think we are alone here. I think this is a wonderful template, and you are doing good things with it. You are, of course right about the fact that a knowledgeable editor will simply press "undo" or will know what code to remove, but we should take into account that not all editors are as knowledgeable and who knows where we will be in another five years etc. So I think the comment has a function and should stay or be (re-) added where it is absent. Debresser (talk) 18:47, 17 June 2012 (UTC)
There are 181 people watching this page, so where are they all? I still disagree with you about the comment, but as I stated above, I am stopped removing it until we get a consensus either way. — Martin (MSGJ · talk) 11:05, 21 June 2012 (UTC)
I dunno about the other 180, but I'm here, I just don't check this page every day.
I'll merely echo debresser's comments: a.) you're doing some good things and b.) I think that in general the "start/end" comments are very helpful. - jc3720:30, 26 June 2012 (UTC)
Tracking category
In order to track which amboxes have the name parameter set I am planning to set up a tracking category (perhaps Category:Article message templates) to place all named amboxes in. Category:Article message boxes will gradually clear out as the names are added. The advantage of this method is that we will only categorise the actual ambox templates and not every page in the template namespace which transcludes one of them. — Martin (MSGJ · talk) 21:16, 15 June 2012 (UTC)
I think this should be a CfD question. Personally, I'm torn on the issue, and would like to hear others' thoughts on this. - jc3720:33, 26 June 2012 (UTC)
You're welcome to take it to CfD but it seems a rather trivial issue, and is "back of house" — Martin (MSGJ · talk) 20:43, 26 June 2012 (UTC)
I understand, but you'd be surprised (well you probably wouldn't) how what may seem minor are suddenly big deals when dealing with category names.
I'll be happy to start a CfD, but I'd ask if you would write the nom/explanation, as I'm fairly certain that you would explain it better than I would : ) - jc3720:52, 26 June 2012 (UTC)
I'd rather not, simply because I have no opinion one way or the other. I needed to introduce a new tracking category for a technical reason, which I have now finished. Whether we stick with the new one or go back to the old one makes no difference to me ;) — Martin (MSGJ · talk) 13:20, 27 June 2012 (UTC)
I have seen many cases where changes were made to templates reflecting on categories, and unless somebody found a serious problem, these were not dealt with at Cfd. I propose to do the same in this case. Debresser (talk) 14:39, 27 June 2012 (UTC)
Supplementary material
Some templates (e.g. Template:Wikify) have some extra content which appears after the date. There is currently no way to display this properly using the issue, fix and date parameters. I propose to add an extra parameter supp to support these templates. Anything put inside this will be hidden inside the small and compact forms. — Martin (MSGJ · talk) 19:45, 26 June 2012 (UTC)
In fact I only know of that one, although it is possibly something which may be used elsewhere. Alternative names would be good, but the only minor consideration is that all the current parameter names have 5 characters or less and keeping within this limit would keep the code aligned nicely :) — Martin (MSGJ · talk) 20:47, 26 June 2012 (UTC)
Other possibilities: ps for postscript, add for addendum or additional, info for additional information. — Martin (MSGJ · talk) 11:36, 27 June 2012 (UTC)
Unless there are further comments in the next day I intend to go with info for this parameter. — Martin (MSGJ · talk) 10:12, 28 June 2012 (UTC)
Article / section
A lot of ambox templates have code to allow the wording to change based on whether it is applied to an article or a section of an article. Some go further and will allow variants such as list, biographical article, section of a biographical article, etc. Currently this is rather haphazard and the method to do this varies from one template to another. On some you must do
{{Wikify|section|date=}}
whereas on others you have to do something like
{{Cleanup-rewrite|section=yes|date=}}
I'd like to bring this code to the meta-template and make it consistent across all templates, so that you do not have to study the documentation of each separate template to learn how to do this. — Martin (MSGJ · talk) 11:41, 27 June 2012 (UTC)
Been racking my brains for a suitable parameter name for this. type is an obvious choice, but it is already used by ambox for something else. So how about form or mode? I think an unnamed parameter would be easiest to use for ambox templates, so we could choose to keep it unnamed at the meta-template as well. — Martin (MSGJ · talk) 10:50, 29 June 2012 (UTC)
Yes, we will keep it as an unnamed parameter on the templates that use ambox, but I think it would be sensible to give it a name on the meta-template. What about sect for section? So we would pass it through to ambox by specifiying |sect={{{1}}} on each template. — Martin (MSGJ · talk) 21:20, 30 June 2012 (UTC)
What do people think about defaulting to the |small=left format for section templates? In other words, if someone types {{Unreliable sources|section}} it will automatically display the small format
Some templates already do this actually. There would still be the option for an editor to override the default by specifying |small=no. — Martin (MSGJ · talk) 16:19, 9 July 2012 (UTC)
Note: there was some discussion on section templates at the village pump, although no consensus developed. Consistency was important for some of the participants of that discussion, and this proposal might help with that. — Martin (MSGJ · talk) 16:27, 9 July 2012 (UTC)
I have seen this style more and more lately. I personally like the large template better, but - as always - favor a uniform style. Debresser (talk) 22:28, 9 July 2012 (UTC)
Yes it looks terrible if adjacent templates are using different formats! I'm thinking we could maybe adjust the small format to be a little less narrow. There were some other suggestions on that discussion I linked to as well, such as making the text flow around the box. — Martin (MSGJ · talk) 22:43, 9 July 2012 (UTC)
Note: I have informed the four participants of the previous discussion, in case they are interested in this. — Martin (MSGJ · talk) 08:17, 11 July 2012 (UTC)
There are a few minor issues with the small format, one is that the left makes the appearance unbalanced, another is that the tag takes more vertical space, which is at a premium near the top of a page. RichFarmbrough, 20:31, 11 July 2012 (UTC).
This is rather interesting, and difficult to handle. Certainly space is a premium in many articles, and in others it's not the topmost priority. Uniformity is great, and it really can cause problems in some places too. Leaving it up to the editor works well to tailor the solution and get the best results from one wikiproject to the next with the different lengths and types of articles, but when it comes to uniformity, it's not breaking ranks to create a new default, it's simply creating a new norm. Then there is the whole alarm that some people seem to suffer from any changes, like the watchlist. Introduced, massive alarm, withdrawn, massive withdrawal symptoms, and eventually maybe they find the balance. This is nowhere near as big as the watchlist thing, but there'll still be some outcry, with luck, maybe one or two "ARRGHH I AM GOING TO DIE, IT'S THE END, 43:12 some bible verse" yeah, there has to be at least 3 of them for any good idea, and 3 dozen for any new thing project wide. There is the semi sneak-attack as well, having the cybernetic editors use them as default when they are tagging articles, but getting good comments for good ideas is harder, people are less likely to say 'this is fantastic' when they like it then they are to say it sucks if they don't like it. I guess asking more people and hassling them for an opinion is a good idea, but I am not suggesting it's any reason to stop, it's not, just thinking if you can catch the editors who are adding the tags into articles and survey them a little, you may get a lovely little CONSIDERED consensus, rather that the creme of the crap hit and run 'idontlikeanythingatallexcepttellingyouidon'tlikeit' sort of comments that go nowhere (ask them why is like asking why does the parrot want a cracker).
In short this is a good idea, and should be trialled a bit wider, and I love the sound of my own voice. Penyulap ☏ 00:38, 12 Jul 2012 (UTC)
can the text wrap around as default too ? Penyulap ☏ 00:39, 12 Jul 2012 (UTC)
My biggest problem with this proposal (as I stated in an earlier discussion about this issue) is that the date of the tag is not present. That, up until now (recently?), was always there. For me, when editing an article with this tag, I can then see at a glance how long the lack of sourcing has been tagged to decide whether I should remove unsourced material.--Bbb23 (talk) 00:16, 13 July 2012 (UTC)
This edit request has been answered. Set the |answered= parameter to no to reactivate your request.
Some specific subjects listed at Wikipedia:Template messages/Cleanup#Cleanup of specific subjects have one issue but different fixes for that same issue. For example, for the issue "This astrology-related article may require cleanup to meet Wikipedia's content standards," there are different fixes that are often needed in astrology-related articles. Is it possible to edit the template to provide multiple fix options, e.g. fix1=, fix2=, fix3=, ... fix5=, etc. so that users of specific subject clean-up templates can specify one or more pre-phrased fixes by, for example, specifying {{Cleanup-astrology|section|fix2=yes|fix5=yes}}? See current discussion at Template talk:Cleanup-astrology. -- Uzma Gamal (talk) 19:23, 21 October 2012 (UTC)
Wikipedia:Manual of Style/Article message boxes should be tagged as historical. It's not really a style guideline; it appears to have been an attempt to standardise the design of message boxes, in an era where message boxes were wildly inconsistent. These days, they all use {{ambox}}, so there's simply no need for this guideline any more.
(I realise this is an odd place to be having this discussion, but for some reason the guideline's talk page redirects here. So here we are...) DoctorKubla (talk) 09:44, 28 November 2012 (UTC)
I'm trying to use this on another MediaWiki wiki, hosted by Wikia, but it doesn't seem to work. I have pasted in the CSS and got the core and ambox templates, yet the box and colors won't appear. Can someone give me advice on everything I need to use this template? Thanks in advance Xtreme2000 (talk) 21:01, 8 December 2012 (UTC)
Having all maintenance template reasons display within multiple issues
Several maintenance templates contain a |reason= parameter to allow additional information to be displayed, in order to help editors understand what needs to be fixed. When we wrap these maintenance templates within {{multiple issues}}, some templates still display the |reason= parameter (e.g. {{cleanup}}), while others do not (e.g. {{BLP sources}}). When I requested for an update to {{BLP sources}} to make it more like {{cleanup}}, it was suggested I come here instead for assistance in updating {{ambox/core}}. What do others think? Thanks! GoingBatty (talk) 00:32, 3 March 2013 (UTC)
I think the reason is that some templates use {{mbox}} rather than {{ambox}} and the former has not kept up with all the updates that this template has had. I'm not sure what the solution is, but I did make a comment last year about this. — Martin (MSGJ · talk) 11:23, 3 March 2013 (UTC)
Actually perhaps this is not the issue in this case. In {{BLP sources}}, the reason is passed via the info parameter which was briefly discussed above (but not yet documented apparently). Are you proposing that a reason parameter be incorporated into {{ambox}}. How many maintenance templates actually use a reason parameter? — Martin (MSGJ · talk) 11:28, 3 March 2013 (UTC)
The only technical solution I was proposing was to change {{BLP sources}} so that the reason is part of the |issue= parameter. However, I'm open to other suggestions. Thanks! GoingBatty (talk) 02:50, 4 March 2013 (UTC)
I have made the change to {{BLP sources}}, but I think it may be worth adding support for the reason parameter to this template. — Martin (MSGJ · talk) 08:45, 5 March 2013 (UTC)
I'm personally not sure what you are asking for, it appears that the code you've specified is already in the template. Either way, you'll need an admin to apply your change since it is a fully protected template. Let me summon one for you...
This edit request has been answered. Set the |answered= parameter to no to reactivate your request.
Paladox2014 want some code added to or moved around in this template. I can't figure out what he wants, as you can see from my comment. I'll leave it to whichever admin answers this to figure out what they are looking to get added to or moved around in the template. Have a nice day! Technical 13 (talk) 18:17, 28 April 2013 (UTC)
That code is already there, so there is nothing to edit. Paladox, you need to provide more information about what your edits are supposed to accomplish. — Edokter (talk) — 18:35, 28 April 2013 (UTC)
In the phrase above "they are for the article section not for the template section", if we substitute the word "namespace" for "section", it reads to me as a request for the correct {{ambox}} equivalent for use in template namespace. That would be {{tmbox}}. I note that a template {{Expand template}} has recently created by Paladox2014 (talk·contribs) which is constructed around {{ambox}} - but (leaving its intended purpose aside) I suspect that it should use {{tmbox}}. --Redrose64 (talk) 20:21, 28 April 2013 (UTC)
Edit request on 5 May 2013
This edit request has been answered. Set the |answered= parameter to no to reactivate your request.
It doesn't just replace the images, it completely changes the code. Can you describe the code changes as well? In case you only want to replace the images, you need to create a version that reflect the current code. Thank you Petrb (talk) 06:53, 5 May 2013 (UTC)
Undone. The PNGs were specifically crafted to produce sharper images then the rendered SVGs. Plus not all images on Commons are protected, and cascaded protection does not work on images hosted on commons. — Edokter (talk) — 11:43, 5 May 2013 (UTC)
Ok, sorry for problems if it caused some, however, I disagree that png can be technically sharper than vector graphics. Vector will be always more sharp or same sharp, no matter of resolution. Petrb (talk) 18:45, 5 May 2013 (UTC)
Additionally, I talked to Brion on IRC today and he said that one of the thing's he will be pushing for is for small size .svgs will render naturally as .svgs. I can't remember all the details, but for unreasonably sized SVGS (where the svg is much bigger than the rendered png) or buggy SVGS it will automatically default to PNG. In this case I don't see what's wrong with replacing the outdated raster images with the SVGs. Thanks. --Addihockey10e-mail03:39, 6 May 2013 (UTC)
Should this template be made smaller?
I don't think it needs to be this big. A couple hatnotes, an infobox, a sidebar, maybe an image, the ToC, a couple of these and a short lead, and you have to scroll twice the length of your screen for content. We should do what we can to emphasise content. — Lfdder (talk) 22:39, 12 September 2013 (UTC)
Tabs on top, that sidebar on the left you can't hide, two of these and the infobox, and that's all the content that fits on the screen. — Lfdder (talk) 19:17, 14 September 2013 (UTC)
In fairness, the lead section is generally all that fits on a screen (especially at 1024x768), regardless of the presence of amboxes or an infobox. See any recently Featured Article, for examples, Eg. Middle Ages and The Hunger Games were TFA on the Main Page recently.
You might be able to get more vertical space by right-click customizing the layout of your browser-toolbars (if you haven't already), eg my Firefox is setup like this [2]. HTH. –Quiddity (talk) 20:11, 14 September 2013 (UTC)
Switch of mbox templates and category handler to Lua
I've made a request over at Template talk:Mbox about switching all of the {{mbox}} family templates, plus the {{category handler}} template, to use Lua modules. These templates have millions of transclusions, so I would appreciate comments and some more eyes on the code. Please let me know what you think over at the request page. — Mr. Stradivarius♪ talk ♪15:09, 15 October 2013 (UTC)
I have seen | subst = <includeonly>{{subst:</includeonly><includeonly>substcheck}}</includeonly> being replaced by | subst = <includeonly>{{subst:substcheck}}</includeonly> often. Is that okay, and if that is okay, shouldn't we update the documentation? Debresser (talk) 20:14, 19 October 2013 (UTC)
Good idea, and I've added it. By the way, the reason you might have seen it being used a lot is that was the code used in the "common parameters" box. Presumably editors were just copying the code wholesale. — Mr. Stradivarius♪ talk ♪13:03, 20 October 2013 (UTC)
I have added a warning to the documentation regarding the "cat" and "all" parameters that they should not be linked, nor should "Category:" be used. What ever happened to the "cat-date" parameter? Debresser (talk) 16:17, 4 January 2014 (UTC)
Testcase "talk= name=foo page=template:foo text=text" and the one directly below it.
That was like that before, and is actually a feature of MediaWiki, not of the module - see my sandbox for a demonstration. A little more complex is the question of why the ambox template put a hash in the fragment by default. I am assuming that the previous template needed a non-blank value, and the hash sign was a convenient one to use because it is unlikely to be a section heading, but I could be wrong there. — Mr. Stradivarius♪ talk ♪02:01, 27 January 2014 (UTC)
Protected edit request on 20 March 2014
This edit request has been answered. Set the |answered= parameter to no to reactivate your request.
Not done: it's not clear what changes you want made. Please mention the specific changes in a "change X to Y" format. — {{U|Technical 13}}(t • e • c)22:01, 20 March 2014 (UTC)
Feature request
Is it possible that this template produces "The article ..." instead of "This article ..." when used inside the {{multiple issues}} template? (This would require the sect parameter to be used of course.) This would improve the wording when multiple issues are used. — Martin (MSGJ · talk) 10:39, 10 June 2014 (UTC)
That doesn't sound right. Multiple issues does not actually call this template - it just sets up the class="hide-when-compact" which then means that some of the text is not displayed inside it. I'm not sure if we can use class="show-when-compact" which could then be used to display "The" instead of "This". It's a minor issue, so not worth coding anything complicated. Regards — Martin (MSGJ · talk) 13:45, 23 June 2014 (UTC)
Edokter, the message box module powers lots of different message boxes, and this issue is only related to article messages boxes, so I still maintain this is the correct venue :) — Martin (MSGJ · talk) 13:45, 23 June 2014 (UTC)
Change the color of the "Deletion" tag (not to be confused with the "Speedy Deletion" tag)
This edit request to Template:Ambox has been answered. Set the |answered= parameter to no to reactivate your request.
Excuse me, but would it be possible if we could change the color of the "Deletion" tag (maroon) to at least something close to a broad shade of red (a color which does not seem brighter than the used-for-content-messages orange)? I know that we can disambiguate those two tags because the speedy deletion one has a pale red color for its background, but, because they are both maroon on their left, that can confuse us from knowing whether one tag is for speedy deletion or just deletion. This idea of me is just to prevent ambiguity. Gamingforfun365(talk)06:37, 19 August 2015 (UTC)
What benefit do you see from distinguishing between the two? And how does that advantage outweigh the increased complexity of a more varied colour scheme? —Psychonaut (talk) 07:43, 20 August 2015 (UTC)
In contrast to omboxes, amboxes are not show in the mobile version. The boxes are completely omitted or produce error messages like "There are problems with this page". In the mobile version you can see the source code of these boxes but they are not presented. Do you know why? --RolandUnger (talk) 18:25, 8 November 2014 (UTC)
You can show them by clicking "there are problems with this page". This is done to conserve visual real estate. (some articles otherwise won't start for 2 pages). —TheDJ (talk • contribs) 19:25, 4 March 2015 (UTC)
Any content should never be placed in an ambox. Information such as the next eclipse is better served in an infobox (if there is one), or a hatnote (but these are sometimes hidden as well). -- [[User:Edokter]] {{talk}}19:00, 25 March 2015 (UTC)
I think the default behavior should be overridden for amboxes that allege factual error or say that this article contradicts another article. Also, what of amboxes that appear other than at the very top? If an ambox appears in a section, for example, then the “This article may have issues” notice should appear there, instead of being suppressed. 96.255.148.25 (talk) 18:18, 13 July 2015 (UTC) (UTC)
Is this problem already unsolved? I see it is causing problems in the Ambox page itself:
The mobile issue could be solved by renaming the CSS classes to something other than "ambox" (either something serious like "cleanupbox" or an internal joke like "drivebytag"). KMF (talk) 01:02, 22 November 2017 (UTC)
Fixing issues on mobile
Hey there! I'm working with my team to improve how issues display in mobile. We understand the current experience is terribly broken and we're keen to fix it. One thing we've noted that would allow us to present issues better is if we were able to reliably access the date. Could the date and brackets be wrapped in a span with class `date`? Jdlrobson (talk) 21:04, 2 March 2018 (UTC)
The backticks were probably confusion with the Markdown syntax used in Phabricator, where they have the effect of <code> tags. Much like how '' and ''' in wikitext work as <i> and <b>. Anomie⚔12:52, 13 March 2018 (UTC)
Feedback wanted on improvements to Ambox templates on mobile web
Hey all,
The Readers web team is working on improving how article message templates appear on the mobile web. We are focusing on templates that use this template. Right now these templates appear when you tap the gray link under the article title, making it difficult for readers and editors to know whether there are any important issues with the article they are reading. We're trying to make these message templates more visible by displaying their description on the top of the article. We hope this will increase awareness of these issues for readers and editors alike.
We would like to encourage template editors to add the type and issue parameters to your templates (if they're not already there). The type parameter will allow us to visually distinguish the severity of the issue and use the icon associated with that particular template type. The issue parameter will allow us to display only the summary of the issue on the main page. You may then tap on the issue to see details. This will prevent the issues from taking up too much space on the page and distracting from the rest of the content.
Documentation improvement: sub-templates are not used anymore
The section #Technical notes states This template calls {{Ambox/core}} or {{ambox/small}} which holds most of the code for {{Ambox}}, while {{Ambox}} itself does parameter preprocessing. → I suppose this is obsolete, the subtemplates /core and /small are unused since the switch to Lua [3]. — Preceding unsigned comment added by Escalatr (talk • contribs) 06:42, 10 September 2015 (UTC)
Change coming to how certain templates will appear on the mobile web
Change coming to how certain templates will appear on the mobile web
Please help translate to other languages.
Example of improvements
Hello,
In a few weeks the Readers web team will be changing how some templates look on the mobile web site. We will make these templates more noticeable when viewing the article. We ask for your help in updating any templates that don't look correct.
What kind of templates? Specifically templates that notify readers and contributors about issues with the content of an article – the text and information in the article. Examples like Template:Unreferenced or Template:More citations needed. Right now these notifications are hidden behind a link under the title of an article. We will format templates like these (mostly those that use Template:Ambox or message box templates in general) to show a short summary under the page title. You can tap on the "Learn more" link to get more information.
As you can see here, the sentence "Relevant discussion may be found on the talk page." is by default placed between the "issue" and "fix" parameters. Is that something new? Doesn't it make more sense to put it after the "fix" parameter?
Also, would it be possible to have 2 choices to place the talk page sentence? (one to be in the middle, and one to be after issue and fix.) Funandtrvl (talk) 19:54, 16 December 2020 (UTC)
Date and removal notice are too small (per MOS:SMALLFONT) in the small version of ambox
See the test case at issue small. The date and the removal notice are rendered at 74.8% of normal, which is an accessibility problem, per MOS:SMALLFONT. As far as I can tell, a small tag (85%) is being applied to the text as well as some sort of CSS class that reduces the size to 88%. (88%*85%=74.8%)
I think that the small tag can stay, as it is applied to the date and removal notice in the full version of the ambox, and it looks reasonable. The further reduction of 88% applied via a class (I presume), when the small-box version is rendered, needs to be removed. Is there someone more familiar with classes and Lua who can puzzle this out? Thanks in advance. – Jonesey95 (talk) 01:24, 9 May 2021 (UTC)
Thanks, that was helpful. It looks like that class lives in MediaWiki:Common.css and applies to multiple "box" templates. It looks like Template:Ambox/styles.css tries to set the font-size to 100%, but I think that ends up being 100% of 75%. I wonder if TheDJ or Ladsgroup, who worked on the latter css file, has any bright ideas. It is not clear to me where the problem should be fixed. One option is to include some Lua code in the Ambox module that says "if small=left, don't shrink the date or the removal notice", but that's beyond my skills. – Jonesey95 (talk) 13:52, 9 May 2021 (UTC)
The TemplateStyles version is unused (see what links here), I presume under the pretense that we have not fully migrated non-metatemplate uses, either to metatemplates or away from the class names. (See also MediaWiki talk:Common.css/to do for related; I haven't scoped the message box stuff there yet.) Accordingly, only the CSS from Common.css loads.
small's setting in Common.css is because browsers are somewhat inconsistent in how large the element is rendered and sometimes less than our minimum, so we set it to the general consensus minimum. (We should consider whether that minimum is still reasonable given that newer skins Minerva, new Vector, Timeless tend toward larger font size, whereas 85% was decided in the days of Monobook.)
Wherever in this module or template is set, I'd probably recommend inline font-size increase of the small text if it is desired to increase the size. It will be something for TemplateStyles at a later date. (Or we can just add it to Common.css now if the small is generally used in ambox.) Izno (talk) 06:41, 3 June 2021 (UTC)
When displaying on mobile this template has a fixed (or maximum) height of two lines of text and overflow is hidden. Unless there's a good reason not to, could someone please remove the height restriction? Thank you in advance. nagualdesign17:56, 23 June 2021 (UTC)
Mobile display of ambox today is basically controlled by WMF. This will not be happening here. Izno (talk) 19:09, 23 June 2021 (UTC)
Why is ambox the only message box which the "small" parameter works with?
Please ping the poster of this comment when replying to them. Thank you.
Hello,
As demonstrated by the above, I have to use an ambox outside of mainspace to have a small message box. Does anyone know why this is the case? Looking at Module:Message box, I can't see any reason why it wouldn't work. Does anyone know? Regards, DesertPipeline (talk) 13:45, 25 June 2021 (UTC)
Ah, I found what you mean. I was a bit confused: They do allow small, but not small=left. Would it be okay to change the other message box templates (or perhaps at least ombox) so that they can also use small=left? Is there some reason why this isn't the case already? Thanks, DesertPipeline (talk) 02:55, 26 June 2021 (UTC)
I have a hard time seeing why you would need to do that for the other kinds of boxes. What is the use case? Izno (talk) 05:04, 26 June 2021 (UTC)
User:Izno: See the box at the top of this section. I'd like to be able to use a message box which doesn't have the coloured part on the left, while still making it appear smaller and on the left so it's not too "glaring". DesertPipeline (talk) 06:06, 26 June 2021 (UTC)
No, I don't want to see what kind of box you want, I want to know where and why you want to use it. Izno (talk) 06:11, 26 June 2021 (UTC)
User:Izno: I just want to be able to use small message boxes left-aligned on other Wikipedia pages which aren't articles without having to use an ambox template, causing the coloured part on the left. DesertPipeline (talk) 10:25, 26 June 2021 (UTC)
@DesertPipeline: A long time ago there was a wide variety of message boxes that used different styles, so that the top of a page could look very messy (see c:File:NewbieTags.png). Then in 2007 came message box standardisation (see c:File:NewbieTagsAfter.png), and so we now have the {{ambox}} ones for articles, the {{tmbox}} ones for talk pages, and so on; and it's all neat and consistent. Why would you want to undo that careful work? --Redrose64 🌹 (talk) 10:19, 26 June 2021 (UTC)
You continue to be vague about where you're doing this, with phrases like "outside of mainspace" and "other Wikipedia pages which aren't articles". We can't give proper assistance unless you give us specifics. But, don't try to misuse {{ambox}} (which, as shown in its doc, is for messageboxes on article pages) for a purpose that it wasn't designed for. First, choose the appropriate message box for the namespace concerned, they're listed at Template:Ambox#Mbox family. Then, if it doesn't do what is intended and a change can be justified, propose an amendment on the talk page of that template. So, to suggest a change to {{ombox}}, you would do this at Template talk:Ombox. --Redrose64 🌹 (talk) 18:45, 26 June 2021 (UTC)
We have this bit of documentation in Template:Ambox#issue and fix: But when used inside {{Multiple issues}} or with small=left it displays only the issue:, yet with small = left, we see both the issue and the suggested fix. I am not sure which is supposed to be correct, the doc or the template. Izno (talk) 06:03, 3 June 2021 (UTC)
Learn how and when to remove this template message
This message is quite ugly and the link takes you to a generic page Help:Maintenance template removal rather than any specific advice to fix the actual issue. I question how useful this actually is. For a start I'd like to explore making the link less intrusive, perhaps a question mark icon with a tool-tip which will link to that page. It would be more useful if each maintenance template had its own help page which describes the issue in more detail and explains how to fix it. — Martin (MSGJ · talk) 11:47, 15 July 2021 (UTC)
User:MSGJ: I've done a small test and it seems the {{tooltip}} template can't be used with an image – the tooltip remains as the link (which in this case is Help:Template removal). Is there any other way to accomplish it? DesertPipeline (talk)
This template is intended only for use with abbreviations (including acronyms and initialisms).
The Web Content Accessibility Guidelines contain guidelines for using the <abbr> element generated by this template; see section H28: Providing definitions for abbreviations by using the abbr and acronym elements.
Furthermore, the HTML specifications (both those of the W3C and WHATWG) strictly define the <abbr> element as reserved for markup of abbreviations. Abusing it for mouse-over tooltips breaks our semantic markup and makes our content invalid HTML (technically, "not well-formed"; it will pass an basic automated validator test because such a tool can't tell that the logical application of the data to the structure isn't correct, only that tags are nested properly, etc.).
{{tooltip}} is Not For™ the kinds of things you're proposing. Wikipedia doesn't have anything that is for that, really, by design. "Tooltips" are an accessibility nightmare, and any sort of "hidden text" (that only reveals itself when action is taken by the reader) is typically discouraged in the article space — collapsibility of navboxes and etc. being the exception. Keeping the article layout "clean" will always be secondary to making information accessible to all readers.
MSGJ's suggestion about linking to an informational page is the only form this could realistically take. (Though personally I'm not sure I'm crazy about mystery "ⓘ" links dotting the article space, either, no matter what they do.) -- FeRDNYC (talk) 08:25, 6 September 2021 (UTC)
Tooltips - whether produced by (mis)use of <abbr>...</abbr> or otherwise - are generated by the browser. Depending upon the browser, the content of the tooltip may be obtained from either a title="..." attribute or an alt="..." attribute. Since these are attributes of tags, it follows that they cannot themselves contain any markup. So, there is no way for tooltips to contain images. I'm sure I have explained this before. --Redrose64 🌹 (talk) 21:40, 6 September 2021 (UTC)
Because categorization is applied only to pages in article space, per the template's documentation. "Ambox" is short for "article message box". – Jonesey95 (talk) 17:31, 27 November 2021 (UTC)
Draft articles are drafts, they are not articles until they are moved to mainspace and so become part of the encyclopedia. The categories are also suppressed when other cleanup templates - such as {{neutrality}}, {{original research}} or {{unverified}} - are used on drafts. --Redrose64 🌹 (talk) 00:06, 29 November 2021 (UTC)
The usual way to make a maintenance template apply a category is to add the category to the template code itself, preferably within <includeonly>...</includeonly> tags. YMMV. You'll need to change the word "article" to "page" within the template and its documentation if you do that. – Jonesey95 (talk) 16:16, 29 November 2021 (UTC)
Param "info" missing...
In the full parameter list, "info" is missing. Only when reading the detailed description does one fall over its existence. Nb, this is only a documentation issue. GrayanOne (talk) 06:06, 7 July 2023 (UTC)
I have implemented a requested edit at Template:Incomplete list which uses a custom designed smaller version of ambox which is left aligned and automatically adjusting width. If this change sticks it would make sense to modify other templates (e.g. {{expand section}}) to match. Rather than adding an additional variant of ambox, I wonder whether we should explore changing the small=left version to match this style? — Martin (MSGJ · talk) 11:29, 15 July 2021 (UTC)
User:MSGJ: Since nobody has objected, I think it might be okay to start an edit request for this – that might help to start a discussion with whoever responds at least, if they don't want to implement it yet. Also, would it be a better idea to have a different parameter variable for the width-variable version? Something like |small=variable maybe? DesertPipeline (talk) 14:14, 9 August 2021 (UTC)
Support new layout of small=left. Nice and compact. Question: would the modification be for {{ambox}} only? Looking at Module:Message box, it seems that the CSS is taken from the .mbox-small-left class at MediaWiki:Common.css, line 910. But that is used for when |small=left for any message box. Not sure what you're intending. — hike395 (talk) 04:09, 10 August 2021 (UTC)
User:Hike395: Only Template:Ambox supports |small=left, I think. I wanted to get that working for other message boxes while still allowing for |small=yes (which positions it on the right with templates other than ambox) but someone else opposed it because they didn't think my reason for requesting it was sufficient. DesertPipeline (talk) 09:10, 10 August 2021 (UTC)
No I would not mind at all. But do you know the specific pages and changes that need to be made to achive this? — Martin (MSGJ · talk) 13:37, 19 October 2021 (UTC)
User:MSGJ: I would presume that the changes only need to be made in the message box module. I'm fairly certain that it's acceptable to write an edit request for the module of a template on the template page. Am I correct? DesertPipeline (talk) 16:27, 19 October 2021 (UTC)
User:MSGJ: Okay. So I'm guessing the edit request would be "please change width: 238px; at line 831 to width: auto;", and explaining why. Also, I think I should check all of the templates which use (or can use) the small-left parameter before doing this, as depending on the amount of text, they may need to have line breaks added so they don't turn into a box spanning the entire width of a page. Regards, DesertPipeline (talk) 11:14, 20 October 2021 (UTC)
Addendum: How is textstyle changed via that file, actually? Unless it's redundant we also need the text style to be set to width = auto. DesertPipeline (talk) 11:17, 20 October 2021 (UTC)
Sorry, I'm not sure. I think it might involve mbox-text or mbox-text-span. Izno is pretty good with this stuff, perhaps he wouldn't mind helping. We are trying to encode |style=width: auto; and |textstyle=width: auto; to make it the default style in MediaWiki:Common.css. Can you advise please? — Martin (MSGJ · talk) 15:29, 23 October 2021 (UTC)
User:MSGJ: Not sure if this is the right way to do it, but if I add "text-align: center;" to the style parameter of a template with that parameter supported, it centres all the text. Presumably then, if that's added on a new line to that CSS page you linked in the relevant area, it should work. That is, as long as it's not the 'wrong' way to do it in this context. DesertPipeline (talk) 12:06, 24 October 2021 (UTC)
I have some thoughts about this discussion.
Regarding auto-width rather than fixed width, I believe it is fixed width because we have an interest in lining up the right edge of the small version of ambox for stacked templates being used at the section level. Do we believe that requirement has gone away or changed since we instituted small versions of these templates? (I doubt it, but maybe you can persuade me and/or others.)
The reason we have amboxes at all can be attributed basically to differing widths and variable, inconsistent colors in amboxes pre-standardization some 10+ years ago.
NB, if you decide to make it auto sizing, that will hamper future work to remove the reliance of ambox on being structured as a table for presentation. That is something of a soft oppose for me personally right there.
I am not interested in removing the fixed width globally regardless without a larger community discussion on the topic than here, at a minimum demonstrating the effects of the change in the single and multiple-mbox (i.e. stacked and/or separate section) template cases, such that the wider community can weigh in on appearance.
One thing to consider, without tossing the goose and gander, would be to set a larger width in the general case. (I am not necessarily a fan of the squat versions but I do not know if these templates will broadly appear any better in a world with wider, but still-fixed-width, templates.) Either way, our computer screens have gotten wider (and then smaller again with best web practice having a relatively 'narrow' main column of content), so that this may be a reasonable approach. 238px is more or less tiny at the end of the day, even if you have, say, an infobox to your right.
I assume this didn't go further? I highly support this; more readable, takes less space (and causes less whitespace), helps with banner blindness. Our fixed-width {{expand section}} can look much taller than the example given at the top, if the "Reason" parameter is filled; that's not great.
I think the frwiki design (see here and here) addresses Izno's concerns : left-aligned text, no left/right borders, full-width top/bottom borders, subtle background colour (= no edge-alignment issue). Looks clean and minimalistic. They've already switched from tables (if I understood Izno correctly) to divs (they're generally much further along than us in the Lua transition and in template standardisation efforts). Like them, we should also standardise all section banners to this "small" appearance (no opt-out), since consistency is the goal here. This looks terrible. DFlhb (talk) 11:41, 3 November 2023 (UTC)
How To Add School Songs?
I would like to add the two school songs; old one 'Morning Has Broken' and current one. I'm not sure how to open a new section. Roscha (talk) 15:03, 24 April 2024 (UTC)
@Jdlrobson Kind of only gives us back the left border color in exchange for changing the whole background to white? Not sure that's a win above how things display right now.
And also where it's been added will affect the two classes of boxes that currently support night mode ({{cmbox}}es and {{ombox}}es), which I think is not good? Izno (talk) 21:02, 13 June 2024 (UTC)
Or we can pick out a color background set. Just tmbox and ambox to poke at. Ambox will effectively be fixed when .metadata dark theme can be turned off. Izno (talk) 05:18, 14 June 2024 (UTC)
The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move reviewafter discussing it on the closer's talk page. No further edits should be made to this discussion.
The result of the move request was: No consensus. A consensus does not appear to be forthcoming. The support position has a straightforward argument based on Wikipedia:Template namespace guidelines (at WP:TMPG and WP:TPN), but the oppose position is also quite reasonable in its arguments based largely on consistency and non-brokenness of the established system. JensonSL (SilverLocust) 11:42, 4 March 2025 (UTC)
Meh I don't buy the "make it more clear for new users" argument. These templates shouldn't be used by new users, they're used to build other templates and by the time a "new" user should encounter them then they shouldn't be so "new" anymore. But the "we must rename all templates to over-long names" crowd will probably win out here anyway, because I can think of no good reason to oppose other than a forlorn hope that the abbreviated name might make it very slightly less likely for someone too-new to think they understand it well enough to misuse it (versus all the people who understand templates so poorly that they think they have to copy-paste the wikitext into articles). Anomie⚔12:53, 11 February 2025 (UTC)
Oppose per Anomie. I don't think this is a good move at all. I think the naming consistency in this case actually makes their usage clearer than the proposed rename targets. - jc3715:18, 11 February 2025 (UTC)
Oppose. "Message box" is a very generic term. There are probably dozens of different "message box" templates on Wikipedia. Whereas these templates are a well-known (to experienced template editors like me) part of the infrastructure with a well-known naming convention. Moving them from a name that's very familiar to a name which is totally unfamiliar is not helpful. This attempt to fix something that's not broken has broken my bot's processing, by requesting the move of cascade-protected templates. It's also distracted my attention from the backlogged maintenance tasks that should be my higher priority. I'd rather the editors trying to work above their pay grade helped me clear these backlogs, where I constantly feel obligated to work below my pay grade. – wbm1058 (talk) 18:17, 12 February 2025 (UTC)
For real though, may want to consider the target of WP:TMPG be rewritten since it's a guideline. Lack of adhering to a guideline can always be considered as something that is "broken". Steel1943 (talk) 18:31, 12 February 2025 (UTC)
It's a short, slippery slope around here, from a guideline to a law that MUST be followed without exception, given the number of obsessive personalities running all over the project. Meta-template families should be a perfectly allowable exception to the guidelines. – wbm1058 (talk) 19:03, 12 February 2025 (UTC)
Support the moves, with redirects left behind to help old-timers like me, per the guideline. We are gradually moving away from obscure, insider template names, which is helpful for new editors (or new template editors who might be experienced editors) when they are trying to understand what a template does and how it differs from similar templates. As for There are probably dozens of different "message box" templates on Wikipedia, it's not that difficult to do a search, which results in exactly one template with "message box" in the name that functions as a message box. This move can only result in reduced confusion. – Jonesey95 (talk) 19:10, 12 February 2025 (UTC)
I the thing prompting this move request is more-so the abbreviations, where WP:TPN would apply as well as WP:TMPG. There's always a chance that someone would request a move on that template, but it seems less likely to me, and less still that such a request would succeed. Mr. Starfleet Command (talk) 19:23, 13 February 2025 (UTC)
If this move does go through, the new names should follow the pattern, {{Article message box meta-template}} to explain to our clueless new editors that these are actually meta-templates, and not templates intended for broad, general stand-alone usage as message boxes. – wbm1058 (talk) 19:30, 12 February 2025 (UTC)
Support per WP:TPN and WP:TMPG. I seriously doubt this would lead to a significant increase in newbie editors misusing these, although I suppose it's possible. They'd still be usable by the old names via the redirects. Mr. Starfleet Command (talk) 19:31, 13 February 2025 (UTC)
Oppose per wbm1058 and Anomie. Going from systematic names to descriptive names makes it more difficult, rather than easier, to understand the relationships among the templates. Dekimasuよ!14:17, 15 February 2025 (UTC)
Oppose. There are good arguments on both sides and I had to think about it, but I have to come down as oppose. 1. Parallel structure is better achieved with short names. 2. Win or lose, I'm surprised nobody has turned all those red links blue yet with redirects, and when we do, doesn't that make half the issues in question here go away? 3. And that handy little box flush-right top on all of them, as created by {{Mbox templates}}: are we gonna change that to use the long names, too? That will be ugly. 4. There's a trade-off, perhaps, between more clarity for newbies (which I support and spend a good deal of time on), and efficiency and productivity enhancement of shorter terms for more senior editors, and for most things by far, I choose the former, but in this case, I tilt towards the latter. Mathglot (talk) 09:07, 16 February 2025 (UTC)
@Mathglot: For what it's worth, for your point 3: "3. And that handy little box flush-right top on all of them, as created by {{Mbox templates}}: are we gonna change that to use the long names, too? That will be ugly.", I'd say the template names should appear as their current titles but link to the new titles, such as what I did here. Steel1943 (talk) 22:13, 16 February 2025 (UTC)
But there would be no point link[ing] to the new titles, would there, given that the old ones would be redirects, right? So in fact, iiuc, no change at all to the template would render the way you wish to see it displayed, i.e., exactly as it is now. Or am I missing something? And if that is okay despite newbie-unfriendliness, then why are newbie-unfriendly titles not okay? Mathglot (talk) [subscribed]23:11, 16 February 2025 (UTC)
Sure, for the the bolding, good point. Doesn't answer the substantive question, though, about inconsistent approaches towards the use of short names, not okay in one case, okay in the other. Mathglot (talk) 23:40, 16 February 2025 (UTC)
Oppose. As a requested move attended by three users is not binding on the community, this proposal should be assessed on its merits. I am not sure that our template naming guidelines should apply to these extremely widely-known, established templates. Very likely there is greater consensus for the existence and current characteristics of the templates, including their names, than that guideline enjoys. Even were that not the case, the terms of the guideline itself support the current names, so they satisfy the requirement of "Template function should be clear from the template name". Everybody who wants to use these templates knows the 'ambox'. The move would create a lot of disruption and make a lot of work for no appreciable gain. I would argue that a proviso should be written into the template naming guideline: name the templates clearly except where a template is already widely known under an existing name, in which case prefer the existing name. Finally, I do support assessing these things and trying to simplify, so I would not want to discourage similar proposals from emerging in future. Times change and modernisation is good. However, the new names aren't great. They are appreciably longer and wordier. I also endorse Anomie's view. Arcticocean ■21:26, 17 February 2025 (UTC)
What is the disruption that you anticipate? I haven't seen disruption from previous renamings that bring template names into compliance with guidelines. – Jonesey95 (talk) 21:50, 19 February 2025 (UTC)
Users will inevitably try to use the new template names, which are not intuitive or easy to remember. Is it article message box or messagebox? Is there a hyphen in multinamespace? This is a rare case where the wasted editor time is quantifiable. Conversely, I can think of few use cases where a user inexperienced enough to have never met the mbox also needs to use the template or know what it is. I don't have any view on whether other moves have been fine, although I am sure that they have been, but if there have been "previous renamings" and there are going to be a lot more future ones, more views should probably be sought at WP:VPT or a similar forum. Arcticocean ■04:17, 20 February 2025 (UTC)
Support. I prefer templates to have full names that describe their function over shorter names. I'd strike "Multi-namespace message box" and just name it Template:Message box. Simple and clear. SWinxy (talk) 15:14, 22 February 2025 (UTC)
Do you have a suggestion for what to do with the existing Template:Message box and its 1,457 transclusions? It's not entirely the same thing. I've thought of two options:
rename it to something else (I have no ideas as to what) and use a bot to update all its uses
delete it and use a bot to update all its uses to work with what is currently Template:Mbox, i.e. replacing |image=Example.png with |image=[[File:Example.png|45px]].
Oppose I feel like this would just cause more confusion for the people who actually use them. Wouldn't it make more sense to just redirect the full names to the original ones? Sophisticatedevening(talk)02:15, 1 March 2025 (UTC)
If there is going to be a redirect and an easily understandable name, the guidelines say that the template should live at the easily understandable name. This may be one of those "we choose to ignore the guidelines because we like the way it is" situations that raises the question of why we have guidelines at all, though. – Jonesey95 (talk) 22:50, 2 March 2025 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.