Template talk:Ambox

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)

@Roscha: this is the talk page for discussing improvements to the template {{Ambox}}. You may find that either WP:HD or WP:TEAHOUSE is a more appropriate location for your query. --Redrose64 🌹 (talk) 18:21, 24 April 2024 (UTC)

Thank you for the reply. Much appreciated.

Roscha (talk) 00:30, 25 April 2024 (UTC)

Edit request 13 June 2024

I've updated Module:Message box/sandbox so amboxes have the notheme class. This improves how they appear in the night theme, see https://en.wikipedia.org/wiki/Template:Ambox/testcases?vectornightmode=1

🐸 Jdlrobson (talk) 05:23, 13 June 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)

Hmm, I hadn't considered ombox and cmbox - I guess we need to tackle these one by one. For example add color: #202122; to .tmbox in Module:Message box/tmbox.css - what do you think? 🐸 Jdlrobson (talk) 01:02, 14 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)

And now tmbox is done. Izno (talk) 05:28, 14 June 2024 (UTC)

Proposal to revisit param type severity scale to encompass ToU violations

There is an implicit severity scale in the description of Ambox param type, which is expressed primarily by the left border color, with red as the highest severity, and secondarily by the default image icon, and in one case, by background color. But I believe that the typing fails to take into account one of the most severe type of article issue, namely violation of Wikipedia's terms of use, and this should be corrected. Possibly this can be corrected solely by changes to the doc page, in how it specifies the purpose and values of param type, but more likely it will require an additional param value. I am proposing a modification to add support for this (extract in the style of the Ambox doc page for param type):

Currently, the top two (most severe) type values are |type=speedy and |type=delete and generate the red border and so on, but are restricted to deletion issues by dint of their names and of the doc explaining them. However, there is another category of issue that imho is of top severity, but that is not a deletion issue and that are not currently handled by the template (at any level of severity), namely, violations of the ToU, or at least, violations of portions of the ToU involving legal implications unrelated to content, such as WP:COPYRIGHTS (ToU §7). In this case, deletion does not solve the problem, nor is there any particular reason to delete the page, as long as the issue is speedily dealt with by compliance with the Terms, which at English Wikipedia is described at WP:RIA.

The best approach in a missing-attribution situation is just to provide it, but it is not always clear where content comes from, or the user may not have the permissions or the skills to do so. For the latter case, we have two templates (that I know of) to deal with it: {{copypaste}} (with red border/type=speedy), and {{Unattributed translation}} (orange border, type=content). In neither case is the type value accurate, because the first has nothing to do with speedy (or any) page deletion, and the second has nothing to do with content. Both are related to ToU violations in the area of COPYRIGHT, and this type of violation must be corrected, per the ToU, and may not be overruled by consensus, nor by Pillar Five (IAR), or by anything else. Nor is deletion appropriate; copying relevant material from sister projects is encouraged, and marking it speedy or delete would be entirely the wrong resolution.

The existing delete and speedy values are not adequate for the purpose, consequently, we need a new Ambox type imho, to flag cases of missing or incorrect attribution, perhaps |type=terms, and possibly a new border and background color as indicated above.

A test version is available in the Ambox sandbox and supporting module files. View and compare the look and feel in context of the other Ambox types at {{Ambox/sandbox/doc#type}}. You can use the sandbox version to generate different versions of existing templates, for example, here is how one template would look in the new style:

{{Copypaste/sandbox|section|source=another Wikipedia? |date=December 2024}} ⟶

And another:

{{Unattributed translation/sandbox|source=another Wikipedia}} →

(This demo requires sandbox versions: Template:Ambox/sandbox/doc rev. 1261227368, Module:Message box/sandbox rev. 1261223846, Module:Message box/sandbox/ambox.css rev. 1261219502, and Module:Message box/configuration/sandbox rev. 1261228574.)
(Not an edit request, yet, because I think it needs discussion first.) Thanks, Mathglot (talk) 03:52, 5 December 2024 (UTC)

Requested move 10 February 2025

• Template:Ambox → Template:Article message box
• Template:Cmbox → Template:Category message box
• Template:Imbox → Template:Image message box
• Template:Tmbox → Template:Talk page message box
• Template:Fmbox → Template:Footer and header message box
• Template:Ombox → Template:Other pages message box
• Template:Mbox → Template:Multi-namespace message box
• Template:Dmbox → Template:Disambiguation footer message box

– As per the result of Template talk:Article stub box#Requested move 15 January 2025, move all of the templates "...per WP:TMPG "Template function should be clear from the template name, but redirects can be created to assist everyday use"." Steel1943 (talk) 04:17, 10 February 2025 (UTC)

I'm a bit surprised that Template:Message box is a separate template, and isn't just a redirect to Template:Mbox. —⁠andrybak (talk) 12:05, 10 February 2025 (UTC)

Support per nom. This makes it much more clear for newer users. Gonnym (talk) 11:35, 11 February 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. - jc37 15:18, 11 February 2025 (UTC)