Module talk:Message box

This module was considered for deletion on 2020 February 15. The result of the discussion was "keep".

Module:Message box is permanently protected from editing because it is a heavily used or highly visible module. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use {{edit protected}} to notify an administrator to make the requested edit.

Archives

Archive 1

This page has archives. Sections older than 30 days may be automatically archived by when more than 4 sections are present.

Protected edit request on 13 September 2024

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Add |imageclass=, |imageleftclass=, and |imagerightclass= parameters as done in the sandbox at Special:Diff/1245579475. This will allow classes such as skin-invert to easily be added to the images. --Ahecht (TALK
PAGE) 20:46, 13 September 2024 (UTC)[reply]

Done Izno (talk) 23:05, 28 September 2024 (UTC)[reply]

Please add param class

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please add parameter |class=, so that those message boxes that were enabled for it, could pass the parameter to allow user styling, including turning off the box.

My use case is the issue of banner clutter on article talk pages, where there have been disputes about placement of many non-compulsory banners. The easiest way to handle this imho would be to permit the user to enter .banner-foo {display:none} in their common.css, applying it to a class passed in the message box but for that to work we need to have the class available in the box as a parameter. Imho, having this available would reduce the strife about talk page banners that seems to be a perennial issue; those most perturbed could simply turn them off individually. It should be clear that this feature would not permit users to arbitrarily turn off any banner, only those which had the passed the param through (via |class={{{class|}}}) in the *mbox template, and only one by one; so that it would allow adding, say, a |class= param to the {{Tmbox}} for Template:Talk header to allow it to be turned off, but not to an ArbCom template. Those templates are already mostly edit protected anyway, so there shouldn't be any problem with editors maliciously adding a class to an mbox where they shouldn't. (Full disclosure: I generally want to see all message boxes and wouldn't use the feature; I am interested in having it to reduce the disputes and wasted time about the topic by offering it to those who oppose them, and who are sufficiently motivated to go to the point of adjusting their common.css, which should quiet the disputes and keep everybody happy.) Mathglot (talk) 20:48, 14 September 2024 (UTC)[reply]

Listed: at WP:Village pump (proposals). Mathglot (talk) 20:44, 16 September 2024 (UTC)[reply]

I think an opt-in strategy might be better at allaying editor concerns about too many messages. If the message box is designated as a hidden message box, a general class could be added, with a rule that hides content with that class. A parameter could be used to provide a custom class, so someone could create a personal CSS rule to display messages that specified the custom class. Editors who want to see all the hidden messages would just need a personal rule for the general class. isaacl (talk) 22:22, 16 September 2024 (UTC)[reply]

Adding a class per the request maintains the status quo, as no page changes appearance after implementation. That doesn't need a heavy level of consensus, because nothing changes for anybody, unless they want it to. Your approach, if I understand it correctly, would require some committee to decide which templates were hidden by default, and allow users to opt in to view them. That would certainly reduce banner clutter by default, and technically, I see no problem with that. But it would represent a potentially big change to the status quo, and therefore would require a significant level of consensus, and might provoke a contentious discussion, as there have been in the past about the topic. I'm not sure that would serve the goal of reducing strife about banner clutter, and might even make it worse. Mathglot (talk) 11:16, 24 September 2024 (UTC)[reply]

I'm not suggesting that the status quo be changed. By default message boxes remain visible. If by English Wikipedia's usual decision-making processes there's a consensus agreement that some template should be hidden by default, then it would be modified accordingly. I imagine creators of new templates would be the first to try to use this functionality, again to preserve the status quo. isaacl (talk) 00:23, 29 September 2024 (UTC)[reply]

Not done: but not for the usual reason: this template already supports |class=. It is not advertised because its use should be limited.

That said, for the work you're suggesting I would recommend instead filling in |name=, which will add a class similar to box-name (for example, {{multiple issues}} outputs box-Multiple_issues today), a fact I discovered mostly after I implemented TemplateStyles (which needed support for setting a class). This parameter is fit for the purpose of hiding specific message boxes, unlike the more powerful suggested |class=. Izno (talk) 22:50, 28 September 2024 (UTC)[reply]

That not-done aside, I am definitely on the "we should get rid of as many talk page templates as is feasible and/or consensus allows", which is necessarily going to lead to conflict. For all the usual reasons of banner blindness. Having more classes to target available won't make everyone happy because not everyone can modify their CSS. Unregistered users also read talk pages and shouldn't have to deal with pages upon pages of banners that aren't pertinent to them. Izno (talk) 22:54, 28 September 2024 (UTC)[reply]

Agreed, and my motivation in posting was to improve the situation, if only ever so slightly, without just giving up because it doesn't fix the larger problem by a long shot, which indeed deserves further attention. Very much obliged for the tip about undocumented class; this should remove a roadblock on one particular use case I'm involved with. Thanks again, Mathglot (talk) 23:02, 28 September 2024 (UTC)[reply]

To me, it's just not a scalable approach to say that editors have to continually update their CSS to hide message boxes they're not interested in if the goal is to reduce the effect of banner blindness. So while I think it will be useful for some, and thus it's a good idea to set the |name= parameter, I don't think it's going to "keep everybody happy". isaacl (talk) 00:23, 29 September 2024 (UTC)[reply]

Indeed it isn't scalable, but maybe one day we will get a turn-off-all-TP-banners switch in Preferences, and I guess until then, I'm going for "happier" or shall we say, one quantum "less unhappy" rather than a perfect solution. My long term goal is to see you basking in contentment as you look around and see that everything at Wikipedia is exactly as it should be. Of course, it's a wiki, so it may not stay that way for very long, but still, something to strive for, eh?

Mathglot (talk) 01:22, 29 September 2024 (UTC)[reply]

Well, that's the heart of the problem: different people have different ideas regarding what they feel is the best approach, and so are striving for different end targets. isaacl (talk) 02:50, 29 September 2024 (UTC)[reply]

I mean, if someone wants to nuke all talk page banners, .tmbox {display: none !important} will basically do it. Izno (talk) 05:31, 29 September 2024 (UTC)[reply]

Feedback requested about proposed new param type for violation of wmf terms

A disussion is taking place about whether to add a new value to Ambox param |type= to accommodate violations of wmf terms that do not fall under any of the existing type values. Your feedback would be appreciated at Template talk:Ambox. Thanks, Mathglot (talk) 04:01, 5 December 2024 (UTC)[reply]

Edit request 7 January 2025

It is requested that an edit be made to the fully protected module at Module:Message box.
(edit · history · last · links · sandbox · edit sandbox · sandbox history · sandbox last edit · sandbox diff · test cases · transclusion count · protection log)

This template must be followed by a complete and specific description of the request, so that an editor unfamiliar with the subject matter could complete the requested edit immediately.

Edit requests to fully protected pages should only be used for edits that are either uncontroversial or supported by consensus. If the proposed edit might be controversial, discuss it on the protected page's talk page before using this template. Consider making changes first to the module's sandbox and test them thoroughly here before submitting an edit request. To request that a page be protected or unprotected, make a protection request. When the request has been completed or denied, please add the |answered=yes parameter to deactivate the template.

Description of suggested change: Currently, Template:Ambox/doc#talk says, "In order to make sure there is always a link to the talk page, you can use |talk={{{talk|#}}}." This implies that a "#" value for args.talk should just link to an article's talk page with no particular section, and several templates do this. However due to the code in Module:Message box, using just |talk=# actually creates a link with two pound signs like this: Module talk:Message box## (verified on Template:Ambox/testcases).

This type of double-hash URL actually causes errors, when I click on it I get these nonsensical messages No search results found for section "#" in archives. It may have been removed or renamed, or you may have followed a malformed link. and a popup saying This topic could not be found. It might have been deleted, moved or renamed.

I fixed it by adding a special case for "#" in Special:Diff/1268004582 and Special:Diff/1268011357, and verified functionality in the testcases.

Diff:

Thanks, --Habst (talk) 21:25, 7 January 2025 (UTC)[reply]