Module talk:Message box/Archive 1

This is an archive of past discussions about Module:Message box. 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.

Archive 1

Protected edit request on 22 January 2014

Note: This thread has been moved from Module talk:Message box/configuration in order to keep discussion together. — Mr. Stradivarius ^{♪ talk ♪} 01:12, 27 January 2014 (UTC)

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

Please make the edit to the live version of this module that I made in the sandbox to allow amboxs to have a "hidden" parameter (this is for the {{Orphan}} revamp that will allow it to be hidden when alone on a page and visible when inside a multiple issue) and have it be empty as-well-as to allow tmboxs to have custom id attributes passed (to allow me to complete my User:Technical 13/SandBox/help-helper-tools.js script (which I already want to adapt to use for assisting in answering EXp and EP requests once completed)). Thank you. Technical 13 (talk) 20:56, 22 January 2014 (UTC)

Question – Is it possible to test the use of this new Message box/configuration in {{Orphan/sandbox}} and {{Orphan/testcases}} before going live with it? Wbm1058 (talk) 13:58, 23 January 2014 (UTC)

I'm pretty sure it has been tested enough. The sandbox configuration module has been used in the sandbox module, and according to Mr. Stradivarius was working properly. As far as the second part of the request to allow tmboxs to have custom id attributes passed (to allow me to complete my User:Technical 13/SandBox/help-helper-tools.js script (which I already want to adapt to use for assisting in answering EXp and EP requests once completed)), I've slept on it and decided to use a class since there may be more than one tmbox on a page using the same id (or class name) and using class would be more correct. Technical 13 (talk) 15:22, 23 January 2014 (UTC)

I don't think I ever tested the new config file settings specifically, so best not to rely on that before going live. I'll try and have a look later on to see if things look ok. — Mr. Stradivarius ^{♪ talk ♪} 21:48, 23 January 2014 (UTC)

Also, I just found an old bug in the main module, so that should be fixed at the same time we roll this feature out. (The fix is in the sandbox.) The bug only affects calls from other Lua modules, and only when there is more than one message box created from the same module, so it's not so urgent that we need to fix it right this minute. I'll review Technical 13's changes and update both the module and the config file soon. — Mr. Stradivarius ^{♪ talk ♪} 06:59, 24 January 2014 (UTC)

Done. Sorry for the delay. Let me know if you see any odd behaviour from the module. — Mr. Stradivarius ^{♪ talk ♪} 01:08, 27 January 2014 (UTC)

Can you update Template:Ambox/doc to reflect the changes that just went live? I assume that there is a new hidden parameter, but that isn't documented yet. Wbm1058 (talk) 04:09, 27 January 2014 (UTC)

I can't figure out how it's supposed to work. The orphan message isn't hidden, but now it's in small type, and when it's in multiple issues, the message is way off on the right side of the message box. Wbm1058 (talk) 04:48, 27 January 2014 (UTC)

Make message boxes collapsible

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

I'm requesting that message boxes be collapsible. (not collapsed by default) I am unsure exactly how to make this change myself, but I'm assuming it would be as simple as adding the "mw-collapsible" class to where-ever classes are added to all message boxes. Discussion welcome if this is controversial in any way (although I don't see how it would be at this time). Thanks. — {{U|Technical 13}} ^{(t • e • c)} 14:14, 14 March 2014 (UTC)

Not done: This change would affect all user-facing message boxes on Wikipedia - all article cleanup notices, many talk page banners, all the "this page is an essay" notices, etc. etc. As it's so widely used, we are certain to have people come and ask, "Hey, why have all the message boxes changed?" If this was a behind-the-scenes kind of change then I might agree, but a noticeable user-facing change like this needs discussion. — Mr. Stradivarius ^{♪ talk ♪} 15:35, 14 March 2014 (UTC)

Mr. Stradivarius, the only visible change will be a [hide] link in the top right corner. I want to be able to collapse all talk page banners and various other long notices like {{Shared IP edu}}, which is a tmbox. Is there currently any way to add this class with a |class=mw-collapsible for specific messages? — {{U|Technical 13}} ^{(t • e • c)} 16:01, 14 March 2014 (UTC)

You can add |class=mw-collapsible, but it won't actually make anything collapsible. That's because there is only one table row in the mbox family templates - you can only collapse things that have more than one row. — Mr. Stradivarius ^{♪ talk ♪} 01:49, 15 March 2014 (UTC)

Protected edit request on 5 April 2014

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

Please make these changes. @Mr. Stradivarius: ping. Jackmcbarn (talk) 16:02, 5 April 2014 (UTC)

@Jackmcbarn: Looks good to me. I've also tidied up the code in the sandbox so that it mostly fits within 80 characters. I'm also tempted to remove the "hidden" parameter, as in this diff, as it didn't look like it was really doing anything. Technical 13, Wbm1058, did you end up using this in {{orphan}} or {{multiple issues}}? Thinking about this properly, I can't see how those classes would actually make anything hidden. — Mr. Stradivarius ^{♪ talk ♪} 17:51, 6 April 2014 (UTC)

Yes, I think you should remove "hidden". As I said earlier, its intended use wasn't documented and I couldn't figure out how it was supposed to be used either. My solution did not require changes at the message box level. Wbm1058 (talk) 12:49, 7 April 2014 (UTC)

@Mr. Stradivarius: Looks ready to merge. I have a MediaWiki code change in gerrit that will make the orphan issue a lot easier to fix, so I think it would be okay to remove the hidden parameter. Jackmcbarn (talk) 18:25, 6 April 2014 (UTC)

"code change in gerrit that will make the orphan issue a lot easier to fix"? Please do explain. I have implemented a fix; are you talking about the same issue or is there another one I'm not aware of? Wbm1058 (talk) 12:49, 7 April 2014 (UTC)

I'm adding frame.uargs, which contains the unexpanded content of arguments, so for example, {{#invoke:foo|main|{{orphan}}}} could see {{orphan}}, rather than the expanded content of Template:Orphan. (If that's still unclear, just wait and it'll make more sense once you can see it). Jackmcbarn (talk) 18:39, 7 April 2014 (UTC)

Done I've updated the module. frame.uargs is a brilliant idea, by the way - that will make a whole lot more things possible. — Mr. Stradivarius ^{♪ talk ♪} 04:40, 8 April 2014 (UTC)

Protected edit request on 19 April 2014

This edit request to Module:Message box/configuration has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

96.37.236.116 (talk) 04:08, 19 April 2014 (UTC)

Not done: it's not clear what changes you want made. Please mention the specific changes in a "change X to Y" format. — Mr. Stradivarius ^{♪ talk ♪} 06:08, 19 April 2014 (UTC)

Protected edit request on 7 April 2014

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

Please wrap it to <aside> element, that's a new element in HTML5 and a recommendation. It is used to content no directly connected to text, like website navigation or message boxes. See its specification on https://developer.mozilla.org/en-US/docs/Web/HTML/Element/aside Rezonansowy (talk | contribs) 11:50, 7 April 2014 (UTC)

Not done for now: We should probably leave a while for discussion before implementing this. Could you advertise this discussion at WP:VPT so that more people are aware of it? Best — Mr. Stradivarius ^{♪ talk ♪} 04:42, 8 April 2014 (UTC)

Reported --Rezonansowy (talk | contribs) 12:05, 27 April 2014 (UTC)

Double-check request

This edit request to Module:Message box/configuration has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

@Mr. Stradivarius: or someone else familiar with this module: I've made a small change to the configuration module in its sandbox. I tested it with {{imbox/sandbox}} and it seems to work, but I'd like another pair of eyes to be sure. I need to add the new class as part of the File metadata cleanup drive. It seems straightforward enough but I want to be extra careful so I'd appreciate if someone could take a look. Thank you! Guillaume (WMF) (talk) 17:40, 25 November 2014 (UTC)

Done @Guillaume (WMF): Thanks for the update. I've added it to the main module config. — Mr. Stradivarius ^{♪ talk ♪} 21:58, 25 November 2014 (UTC)

Thank you! Guillaume (WMF) (talk) 00:17, 26 November 2014 (UTC)

Protected edit request on 9 April 2014

Tracked in Phabricator
Task T64982

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

Please make these changes. Jackmcbarn (talk) 02:10, 9 April 2014 (UTC)

Not done: This is going to cause script errors when the inputs to mw.html:wikitext etc. are false. See Module:User:Mr. Stradivarius/html for a simple example. This is going to happen, for instance, when someone uses ambox without an info parameter, due to self.info not being checked before running the code :wikitext(self.info and ' ' .. self.info). To be honest, I think this is a design flaw in mw.html - it should just accept false and nil values silently so that it is easier to call-chain. — Mr. Stradivarius ^{♪ talk ♪} 05:35, 9 April 2014 (UTC)

@Mr. Stradivarius: Do you think it would be worth trying to fix this module further to work with it now, or should we just leave it unti mw.html is fixed? Jackmcbarn (talk) 18:47, 9 April 2014 (UTC)

I think that we should fix mw.html first. Now I look at this again I see that the problem doesn't occur in mw.html:wikitext if passed a nil value, so self.info is in fact safe. The problem is that if false values of self.info are going to fail, then we can't edit the box:export method without thinking about what the original arguments are doing. I'd rather keep box:export as decoupled as possible from the rest of the code (originally they were mixed together, and it was a real mess), but doing that with mw.html would mean writing more if statements, and it doesn't seem very clean. It's actually not so bad in this module, but in modules that use things like mw.html:css('foo', myValue) or mw.html:addClass(myClass) it can be a big headache. — Mr. Stradivarius ^{♪ talk ♪} 20:11, 9 April 2014 (UTC)

@Mr. Stradivarius: Look at bugzilla:62982. I think we should reopen that bug. Thoughts? Jackmcbarn (talk) 03:06, 21 April 2014 (UTC)

@Jackmcbarn: Ah, I should have known that that was done on purpose. Yes, I think we should reopen it - I can see Brad's and Marius's points, but it makes call-chaining so much harder. Do you know how jquery deals with situations like these, by the way? I gather that HtmlBuilder was originally modelled on jquery, so that might give us a precedent to go on. I've never done any JavaScript coding myself, though. If mw.html won't change, then we can just add if statements to the export method. It will be a pain, but not a showstopper. — Mr. Stradivarius ^{♪ talk ♪} 04:45, 21 April 2014 (UTC)

@Mr. Stradivarius: Can you leave a comment on the bug? Jackmcbarn (talk) 01:48, 22 April 2014 (UTC)

Not sure if you posted here before I posted there, but actually, I already did. — Mr. Stradivarius on tour ^{♪ talk ♪} 04:50, 22 April 2014 (UTC)

Now that mw.html is fixed, I've redone this patch. The new diff is here. (I also did some other things with it.) Jackmcbarn (talk) 03:31, 12 July 2014 (UTC)

Now that I've finished this, I'm wondering if it'd be worth sticking some "or nil"s in various places, since false still causes an error if it makes it to mw.html. Jackmcbarn (talk) 03:32, 12 July 2014 (UTC)

@Jackmcbarn: Yes, I think it would be worth it. That will help future-proof the code against changes to the functions other than box:export, and it will help prevent errors from existing Lua modules that pass through unexpected values. For example, in the sandbox console the code =p._main('ombox', {style=false}) currently gives an mw.html error. — Mr. Stradivarius ^{♪ talk ♪} 05:02, 12 July 2014 (UTC)

@Mr. Stradivarius: That's now done. See here. Jackmcbarn (talk) 13:26, 12 July 2014 (UTC)

I'm going to try and write some proper test cases for this today, so let's wait until that's finished before updating the module. — Mr. Stradivarius ^{♪ talk ♪} 23:46, 13 July 2014 (UTC)

@Mr. Stradivarius: Now that I see my SVG change popping up again, I think I should finish that before we do go live with all the changes. Jackmcbarn (talk) 02:24, 16 July 2014 (UTC)

@Jackmcbarn: Sounds good. I'm also planning to tidy the main module code up some more, and put category and error message values in the configuration page rather than hard-code them. And then there are those test cases... :) — Mr. Stradivarius ^{♪ talk ♪} 02:28, 16 July 2014 (UTC)

@Mr. Stradivarius: I finally got around to finishing this up. Are we ready to make these changes? Jackmcbarn (talk) 20:16, 28 November 2014 (UTC)

@Jackmcbarn: Thanks for working on this! Yes, the test cases look fine, so go ahead. — Mr. Stradivarius ^{♪ talk ♪} 11:07, 29 November 2014 (UTC)

Quite a strrretch

My work page archive has begun to stretch horizontally way beyond the right side of my screen (press "Show" to see the effect). Can someone look at this to see if it can be fixed and returned to the screen-fill it was before? – Paine Ellsworth ^CLIMAX! 16:18, 15 December 2014 (UTC)

It's not stretched at all for me, can you provide a screenshot? I'll note that I see a lot of deprecated HTML tags there, which usually stretches pages out for me because of the way I have my .css wrap bad tags in their markers visually. I'd be happy to bring it up to WP:HTML5 standards for you, but would like to see what you are seeing first so I can have an idea of what tweaks I may need to make in the process. The other possibility is that you need to press ctrl+0 on your keyboard to reset your browser's zoom level to base. Happy editing! — {{U|Technical 13}} ^{(e • t • c)} 16:42, 15 December 2014 (UTC)

Be sure to open the collapsed portion by clicking "Show" on the bar. I uploaded a screenshot as you asked. Note the scroll bar at the bottom, which indicates that there is a lot of page still to be seen to the right of the screen. I usually read and edit with the "largest" IE11 font size; however, I reduced this to "medium" for the screenshot. Tech 13, I don't mind at all if you would update the HTML, in fact, I would very much appreciate it! – Paine 18:12, 15 December 2014 (UTC)

@Paine Ellsworth: It's fixed now, though it actually didn't have anything to do with this module. It was caused by a really long line you had inside an <pre> tag on that page. Jackmcbarn (talk) 18:32, 15 December 2014 (UTC)

Paine Ellsworth, to prevent this from happening in the future, you might consider adding:

/* <pre>, <code>, and <tt> fix */
pre, code, tt {
     max-width: 1200px;
     white-space: pre-wrap !important;
     word-wrap: break-word;
     overflow: auto;
}

to your common.css page. — {{U|Technical 13}} ^{(e • t • c)} 18:43, 15 December 2014 (UTC)

I'm not sure that that's a good idea. Since it'll make all pages look non-broken to you, you'll likely end up inadvertently breaking a bunch of pages for everyone else. Jackmcbarn (talk) 19:00, 15 December 2014 (UTC)

Thank you so much, both of you. I don't understand how you did it, though, since according to this diff, my <pre style="font-size:95%;overflow:auto;"></pre> should have been enough to maintain the page width. Magic Jack, should I always use the white-space:pre-wrap with the pre tags from now on? – Paine 19:36, 15 December 2014 (UTC)

I personally think the code block above should be in MediaWiki:Common.css, but I don't feel up to proposing it to the community, unless that is one of those things that can just be done. It's a fairly simple change that will prevent those tags from causing unwanted page width issues. I guess, if it was going to be put in MW:Common.css, it shouldn't include the deprecated , tt though. I'll leave it to you to decide if it is worth putting in there. — {{U|Technical 13}} ^{(e • t • c)} 19:43, 15 December 2014 (UTC)

@Paine Ellsworth: What I did is the second-best way. The best way to handle it in the future is to not put an 800+-character line in a <pre> tag. @Technical 13: The point of <pre> is to have white-space be pre. I think that CSS would basically be the equivalent to div { display: inline; }. Also, wikimarkup is not bibtex. Why'd you mark it as such? Jackmcbarn (talk) 03:04, 16 December 2014 (UTC)

Jack, wikitext is not a language option, and the next closest thing formatting wise is bibtex. — {{U|Technical 13}} ^{(e • t • c)} 03:08, 16 December 2014 (UTC)
@Technical 13: Then why not just leave that as a pre tag? Jackmcbarn (talk) 03:22, 16 December 2014 (UTC)
- <syntaxhighlight>...</syntaxhighlight> doesn't force nowrap like <pre>...</pre> does. — {{U|Technical 13}} ^{(e • t • c)} 03:42, 16 December 2014 (UTC)
  @Technical 13: My fix didn't force nowrap either. Jackmcbarn (talk) 03:43, 16 December 2014 (UTC)
  I didn't even know you had applied a fix when I made mine. There was no indication it was fixed at all when I made my change. — {{U|Technical 13}} ^{(e • t • c)} 03:45, 16 December 2014 (UTC)
  ...the fact that the page wasn't stretched anymore? Jackmcbarn (talk) 03:54, 16 December 2014 (UTC)
  I wouldn't have seen it, I have the custom css I posted above in my common.css. — {{U|Technical 13}} ^{(e • t • c)} 03:56, 16 December 2014 (UTC)
  Then how did you know that that element was the problem? Jackmcbarn (talk) 04:00, 16 December 2014 (UTC)
  I searched for all tt, code, and pre sections, and that was the only one long enough to cause an issue. If that didn't fix it, I was expecting to have to go through all of the templates and see which ones injected those codes, as experience has told me it is nearly always those tags that cause width issues. — {{U|Technical 13}} ^{(e • t • c)} 04:19, 16 December 2014 (UTC)

Well, my workpage is fixed again thanks to Mr. Stradivarius. And thank you both as well for this learning experience. Not for anything, {{U|Technical 13}} ^{(e • t • c)}, because I revere both of you for your expertise, but I think Magic Jack is correct in this case as proven by what you said above... I wouldn't have seen it, I have the custom css I posted above in my common.css. If you can't see it, then you don't know if you might be breaking a page for other editors who don't have that code in their .css file. I took the code back out of my .css, which is how I was able to see that your second edit to my work page archive broke the "show width" again. You do what you think is right, and thank you again for this and past times when you and Jack (and Mr. S, too, for that matter) were my teachers and helped me fix things. Joys to all! – Paine 18:13, 16 December 2014 (UTC)

PE, my point of it is that if it is in MediaWiki:Common.css, then it won't look broken to anyone, at all, ever. — {{U|Technical 13}} ^{(e • t • c)} 18:20, 16 December 2014 (UTC)

(edit conflict) Yes, I get that, and hopefully you get that the code is not yet in MediaWiki:Common.css, so until it is in MediaWiki:Common.css then it will look broken to all those who don't have the code in their own .css file. – Paine 18:29, 16 December 2014 (UTC)

allowId

Could allowid be set to true for all types of messagebox? Is there any reason to exclude this functionality from certain types of message? — Martin (MSGJ · talk) 10:20, 6 March 2015 (UTC)

Pinging User:Mr. Stradivarius ... — Martin (MSGJ · talk) 13:19, 18 March 2015 (UTC)

I'm pretty sure I coded it like that because that's how the original templates worked. Any efforts to simplify/unify the codebase are good in my opinion, as long as they don't break existing transclusions. — Mr. Stradivarius ^{♪ talk ♪} 13:23, 18 March 2015 (UTC)

Okay great. If you cannot think of any reasons to exclude the id functionality, then please go ahead and simplify and remove the allowid parameter when you have time. — Martin (MSGJ · talk) 13:34, 18 March 2015 (UTC)

Ok, it's done. — Mr. Stradivarius ^{♪ talk ♪} 13:55, 18 March 2015 (UTC)

Thanks, and I've removed it from the documentation. — Martin (MSGJ · talk) 14:25, 18 March 2015 (UTC)

Date and small parameters

I was attempting to update {{Accessibility dispute}} per a recent request on my talk page. That template is based on {{Mbox}}, which uses this module. While the documentation for Mbox says This template takes the same parameters as {{Ambox}}, {{Imbox}}, etc., that doesn't seem to be the case. The template doesn't seem to support the date parameter or substing at all. For small versions, only |small=yes seems supported and that right aligns the template.

Mbox

Can this module be changed to make it more closely compatible with the other templates? --AussieLegend (✉) 06:08, 16 November 2015 (UTC)

Categorize using Main other

As I understand it, |all= may be used to add a maintenance category to the transcluding page (see {{Ambox}} documentation). My question is: can I use {{Main other}} in here to prevent the maintenance categopry being polluted with non-articles? Like: |all={{Main other|Articles with foo}}. -DePiep (talk) 08:59, 8 December 2015 (UTC)

Discussion that may affect this module

Please see Wikipedia:Village pump (proposals)#Implementing Help:Maintenance template removal. A new parameter for templates, placed through this module, may be needed to implement it.--Fuhghettaboutit (talk) 12:44, 14 April 2016 (UTC)

Plainlinks

(Copied from Template talk:Tmbox#Plainlinks)

a) Why does this default to class="plainlinks"? b) How to turn that off? {{Tmbox|plainlinks=no|text=[http://example.com example.com]}} gives:

example.com

-- Michael Bednarek (talk) 07:01, 3 October 2016 (UTC)

@Michael Bednarek: In {{imbox}}, you can use |plainlinks=no to turn off the plainlinks class, but this currently doesn't work in any of the other message box types. This is governed by the usePlainlinksParam flag in the code that I added because some of the old templates supported turning off plainlinks and some didn't. In retrospect, however, this seems like a bad idea, and I think the flag should be removed and |plainlinks=no be made available to all message box templates. — Mr. Stradivarius ^{♪ talk ♪} 08:14, 3 October 2016 (UTC)

@Michael Bednarek: And now |plainlinks=no is available in {{tmbox/sandbox}} and the other message box template sandboxes. — Mr. Stradivarius ^{♪ talk ♪} 08:31, 3 October 2016 (UTC)

Indeed: {{Tmbox/sandbox|plainlinks=no|text=[http://example.com example.com]}} now works as expected:

example.com

Can you give any indication when this will go live? -- Michael Bednarek (talk) 09:30, 3 October 2016 (UTC)

@Michael Bednarek: Well, there's no time like the present - I've just put it up live now. — Mr. Stradivarius ^{♪ talk ♪} 11:04, 3 October 2016 (UTC)

Many thanks. Cheers, Michael Bednarek (talk) 11:07, 3 October 2016 (UTC)

Changing span to div

A number of the errors at Lint errors: Misnested tag with different rendering in HTML5 and HTML4 could be fixed by changing one of the spans in this templates to a div. I've done this in the sandbox and the testcases all look the same. So if no-one has any issues with it then I'll make the change live soon. -- WOSlinker (talk) 09:08, 30 September 2017 (UTC)

I made a small followup which changes the variable name as well. --Izno (talk) 02:32, 1 October 2017 (UTC)

Thanks. I've now made the change. -- WOSlinker (talk) 09:07, 2 October 2017 (UTC)

@WOSlinker: I can confirm a fix for Ad-Libs after purging. Should we wait for the job queue or see if a purgebot can take care of the thousands of articles affected? --Izno (talk) 16:58, 3 October 2017 (UTC)

I would just leave it for now and see how it's going in a few days. -- WOSlinker (talk) 17:09, 3 October 2017 (UTC)

Moving to divs

I think it's time we think about moving these things to div's once and for all. It should be pretty easy. We cleanup the CSS to no longer depend on table elements. It should be pretty easy to move all the elements to divs. We just need to set display:table-cell for xbox-image, mbox-text and mbox-imageright. The harder part is assessing impact for the collapsible elements and the grouped/nested message boxes.. That's an area where we need to be a bit more careful I think. With those changes, table-cell support is the minimum requirement for browsers. As IE6 and IE7 can't even access the website any longer, due to very outdated HTTPS encryption algorithms this therefor should have 0 impact on readers. —TheDJ (talk • contribs) 14:00, 20 March 2018 (UTC)

@TheDJ: I agree that it is definitely time we moved away from styling with tables. That is so 1990s. ;) As far as the code goes, most of where the code needs to change is it MessageBox:export, plus it looks like we need to tweak the inline CSS for the imageEmptyCellStyle option. We will need to make some test cases, though - this module never did have proper tests. — Mr. Stradivarius ^{♪ talk ♪} 14:27, 20 March 2018 (UTC)

There is a huge list of cases here which can be used for visual comparison at least. —TheDJ (talk • contribs) 15:34, 20 March 2018 (UTC)

As a start, I've lowered the specificity of the styling rules of the fmbox family by removing table specific elements. I was already messing with those, so seems like a good place to start. Let's see what happens and then we can one by one do the other families before we start rewriting the html. —TheDJ (talk • contribs) 16:26, 20 March 2018 (UTC)

Protected edit request on 23 February 2018

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

Please merge the sandbox changes that skip loading Module:Category handler when there are no categories to handle. Luis150902 (talk | contribs) 17:30, 23 February 2018 (UTC)

Question: is this to reduce page loading time? — Martin (MSGJ · talk) 22:58, 24 February 2018 (UTC)

@MSGJ: No. This request is because there are many message box templates that do not pass categories to the main message box templates (*mbox), that are implemented using this module. This includes system messages, that use {{Fmbox}}. This request makes Module:Category handler no longer used in system messages and removes the need to fully protect it and the other 4 data modules associated with it, allowing template editors to edit it (currently it is impossible because of cascading protection: Wikipedia:Cascade-protected items/content → ... → Module:Message box → Module:Category handler, where arrows go from transcluding page to transcluded page). Luis150902 (talk | contribs) 18:21, 22 March 2018 (UTC)

Done. Sorry for the delay, I've been away and apparently no one else wanted to touch this. — Martin (MSGJ · talk) 12:59, 10 April 2018 (UTC)

Not done for now: no response from OP — Martin (MSGJ · talk) 12:15, 28 February 2018 (UTC)

A question to small param and TemplateStyle

hi, I have a question: on it.wikt I have imported this module and I put the associated CSS in MW:Common.css. Now I moved CSS in a subpages for TemplateStyle, I put the common code here, the template's specific code, exemple for Imbox, here and I think: «now I put the common small-code in Template:Mbox/commonSmall.css, write <templatestyles src="Mbox/common.css" /> <templatestyles src="Ambox/styles.css" /> <templatestyles src="Mbox/commonSmall.css" /> <templatestyles src="Ambox/compact.css" /> and "that's all folks"». No, common style it works, specific style idem, but small style don't. Ok, no subpage for the small style, «i copy this in "Template:Ambox/styles.css" after all code, it will same like write in this order in MW:Common.css». No, not even this way it works. does anyone have solutions, or do I have to give up the idea of TemplateStyle for these templates? --user talk:Wim b 11:07, 12 August 2018 (UTC)

Edit request 26 Nov 2018

This edit request to Module:Message_box/configuration has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

The configuration page currently lists File:Semi-protection-shackle.svg as the icon for protected pages; this was formerly an all-grey icon and so could be considered generic, but now has an image on it. It should probably be replaced with File:Semi-protection-shackle-no-text.svg so as to continue to represent all possible modes of protection. Many thanks, User:GKFX^talk 22:18, 26 November 2018 (UTC)

With icon
Without icon
With generic keyhole

We had a similar discussion over at MediaWiki talk:Protect-text where we switched to a keyhole padlock as it symbolized generic protection better. For context, there we went with File:Full-protection-shackle-keyhole.svg and if we would like to follow a similar approach here, I have created File:Semi-protection-shackle-keyhole.svg which is the semi lock with a keyhole (and is a semi-protection version of what we used on the other page.) I have also added it to the gallery above for easy comparison. Best, Mifter (talk) 02:07, 27 November 2018 (UTC)

@Mifter: Thanks for the info! I'd be all in favour of using the keyhole version for consistency with MediaWiki:Protect-text; it also looks a bit more aesthetically pleasing to leave an icon in. User:GKFX^talk 17:28, 27 November 2018 (UTC)

On hold I'll make this change, but first Mifter can you upload a local copy and protect as with the other new shackles? ~ Amory (u • t • c) 22:12, 28 November 2018 (UTC)

Thanks Amorymeltzer, I've uploaded and protected a local copy. Best, Mifter (talk) 04:57, 29 November 2018 (UTC)

Done ~ Amory (u • t • c) 12:10, 29 November 2018 (UTC)

Mark up date so that is is machine readable

I'd like to incorporate the following change into the template: change.

I'm working to improve how page issues display in mobile. One thing we've noted that would allow us to present issues better is if we were able to reliably access the date.

There are 2 classes as I am keen to separate the presentation (the brackets) from the actual date itself. Jdlrobson (talk) 18:20, 12 March 2018 (UTC)

@Jdlrobson: You didn't link back to the places (Template talk:Ambox#Fixing issues on mobile and Template talk:More citations needed#Semantically mark up date) where you have previously requested such a change; this is desirable since it provides context for those coming in cold. Although duplicate discussions are discouraged (see WP:MULTI), it is a good thing to link to related ongoing threads (see WP:TALKFORK). --Redrose64 🌹 (talk) 11:03, 13 March 2018 (UTC)

Looks uncontroversial, should have been implemented, @Jdlrobson: if you still want this to be done, better use {{editprotected}} for a proper response. SD0001 (talk) 11:22, 15 December 2018 (UTC)

Protected edit request on 18 December 2018

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

Add a class named "box-Template_name" to the table element of every ambox (or for good measure, every box).

This would help automated tools like Twinkle to efficiently identify the template being used (parsing the page wikitext for this is not reliable, because of the usages of template redirects). This would be used in Twinkle for implementing an untag feature - making the tag module able to add and remove tags as well.

For many of the tag templates, a class with name roughly of the form "ambox-Template_name" already exists, but they are not consistent across all templates: in some cases, the first char of the name is lowercase while in others it's uppercase; in some, the names don't match the template name such as in {{improve categories}} and {{more citations needed}}; in several others, there is no such class at all. It makes much more sense to get this class added centrally.

It need not necessarily be a class, some HTML(5) attribute could be used too.

SD0001 (talk) 18:52, 18 December 2018 (UTC)

Not done @SD0001: this section can certainly be discussed what to do, however I've deactivated the edit request as there is nothing actually ready to be done. Feel free to work on this in Module:Message_box/sandbox and once it is ready to go and has appropriate support reactivate the edit request. — xaosflux ^Talk 19:03, 18 December 2018 (UTC)

@Xaosflux: Haven't I made it more or less clear what is to be done? I think this would be fairly trivial to do for template editors familiar with the module. SD0001 (talk) 19:10, 18 December 2018 (UTC)

Once someone does it in the sandbox, and it is ready for anyone to implement go ahead and reactivate the edit request. The edit request queue is a check against the protection policy - so that improvements can be made even when a page is protected. I'm not suggesting this discussion stop happening, it is fine to ask for someone to do something for you and anyone is welcome to sandbox this, they don't need any special user groups for the next step. — xaosflux ^Talk 19:23, 18 December 2018 (UTC)

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

Alright, done in the sandbox. Please incorporate. SD0001 (talk) 15:58, 19 December 2018 (UTC)

To clarify: since this utilizes the |name= argument, the class would only be added to boxes that specify a |name=. This was done because it seems impossible to get the actual template page name, as mw.getCurrentFrame():getParent():getTitle() gives the metatemplate name (Template:Ambox), not the template name, and getParent() can only be called from the current frame. I guess this is why the |name= field exists in the first place. SD0001 (talk) 06:16, 20 December 2018 (UTC)

@SD0001: Sorry to be a pain, but can you confirm you have tested this change and it works as intended? I appreciate it is a trivial change but this is a widely used template I would not want to make any unnecessary changes. Thanks — Martin (MSGJ · talk) 09:07, 21 December 2018 (UTC)

@MSGJ: Yes. See User:SD0001/sandbox2. It works with all box types. SD0001 (talk) 09:09, 21 December 2018 (UTC)

Done — Martin (MSGJ · talk) 10:26, 21 December 2018 (UTC)

Translating this module

How can I translate this module to another wiki? I'm planning to allow parameters in English as well as in another language. Can someone help me? --CaiusSPQR (talk) 18:07, 30 January 2019 (UTC)

Edit request 13 February 2019

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

Please copy over the contents of Module:Message box/sandbox. I have made an edit there which implements the demospace feature documented at Template:Mbox. Testcases can be found at its testcases page: Template:Mbox/testcases. Danski454 (talk) 20:04, 13 February 2019 (UTC)

A little more background please. Is this feature currently not working? Did it previously work and you are fixing it? — Martin (MSGJ · talk) 14:38, 15 February 2019 (UTC)

@MSGJ: The demospace parameter was removed from the module by Mr. Stradivarius in a sandbox edit in July 2014, which was copied over with several other changes in November 2014. I cannot find any further explanation for the changes, but the feature still appears in the documentation of {{mbox}} and is used by the documentation of templates like {{notice}}. The proposed edits readd the parameter. Danski454 (talk) 17:03, 15 February 2019 (UTC)

I can't remember why I removed it from the sandbox. I suppose it must have made sense at the time, but it looks like it deployed either by accident or without any discussion, so I'm fine with reinstating it. I wonder how many places still use it? — Mr. Stradivarius ^{♪ talk ♪} 14:30, 16 February 2019 (UTC)

No further comments so

Done — Martin (MSGJ · talk) 20:36, 28 February 2019 (UTC)

July 2019: When and how vs. how and when (edit request)

This edit request to Module:Message box/configuration has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Moved from Template talk:Ambox

The current text of the last sentence of the template reads "Learn how and when to remove this template message." I propose switching the "how" and the "when", giving us "Learn when and how to remove this template message."

It not only sounds cleaner but also has more usage. Thoughts?

CampWood (talk) 18:00, 16 December 2018 (UTC)

Bumping thread. CampWood (talk) 23:04, 3 January 2019 (UTC) CampWood (talk) 23:04, 3 January 2019 (UTC)

Bumping thread. CampWood (talk) 17:47, 17 January 2019 (UTC)

@CampWood: I moved this to a better forum and added the request template to attract editors. — xaosflux ^Talk 18:33, 17 January 2019 (UTC)

Seems reasonable (the current text seems rather awkward); if there is no objection I'll do it in a couple of days. Galobtter (pingó mió) 17:29, 18 January 2019 (UTC)

I dunno, what's so awkward about it? It seems fine to me. I'm curious where the more usage comes from; google turns up 7.6M results for "learn how and when" but only 240k for "learn when and how". Likewise, I get 71.2M results for just "how and when" over 55.4M for "when and how". Not an exact science, to be sure, but that suggests to me that the current language is the more common. ~ Amory (u • t • c) 01:52, 19 January 2019 (UTC)

@Amory:: Huh, I get 75.5M results for "how and when" and 105M for "when and how". CampWood (talk) 15:01, 8 August 2019 (UTC)

Not done @CampWood: please establish a consensus for the change here, then reactivate the edit request if warranted. — xaosflux ^Talk 19:33, 22 January 2019 (UTC)

All right. The phrase "when and how" is not only more natural than its reciprocal (if you will), it's also more common. It doesn't matter how you do something unless you know that you want to do it! In other words, you'd want to find out when to do something before you find out how to do it; the word order should reflect that. So, who's with me? Let's establish some consensus!

CampWood (talk) 15:16, 8 August 2019 (UTC)

Support. CampWood (talk) 15:16, 8 August 2019 (UTC)
Support. --Obsuser (talk) 15:33, 8 August 2019 (UTC)

Making a small box with a custom width

I'm interested in making a small message box that's wider than the normal small box (to keep this from going onto three or four lines for pages with longer titles). Is there a way to do this, or could a parameter be introduced to allow for it? {{u|Sdkb}} ^talk 19:30, 23 April 2020 (UTC)

@Sdkb: See Special:Diff/952939847. It is possible, but making it too wide can cause problems in smaller screens. Ahmad^talk 21:36, 24 April 2020 (UTC)

Have you looked at the documentation for {{Ombox}} or {{Ambox}}? You can set a width using |style=. – Jonesey95 (talk) 21:48, 24 April 2020 (UTC)

@Ahmad252 and Jonesey95: Oops, I was overthinking that by a mile haha. I did look at the {{Ambox}} documentation but wasn't able to figure it out. I'll update it to help those confused in the future. Thanks for the help! {{u|Sdkb}} ^talk 21:52, 24 April 2020 (UTC)

@Ahmad252 and Jonesey95: sorry for my terrible HTML, but I just spent 15 minutes fiddling with min-content/max-width/etc. and couldn't figure this out: how do I set the box so that it adapts flexibly to the width of the text (so that there's no big margin on the right), and wraps onto a second line only if the reader's screen is too small for it to fit? max-width seems to solve the second part, but I have no clue about the first. {{u|Sdkb}} ^talk 23:27, 24 April 2020 (UTC)

Unfortunately, I don't know how this can be done. As far as I know, display: inline-block is supposed to do it, but given that there is already a width set in the module's default style, it still sets width to 238px (the default number) unless we can completely remove width. Maybe I'm missing something. Ahmad^talk 00:26, 25 April 2020 (UTC)

@BrandonXLF: this seems like something you might know how to fix? {{u|Sdkb}} ^talk 20:39, 25 April 2020 (UTC)

Sdkb, do you want it like this? – BrandonXLF (talk) 22:57, 25 April 2020 (UTC)

@BrandonXLF: Yes! Thank you as always for your techno-wizardry! {{u|Sdkb}} ^talk 23:07, 25 April 2020 (UTC)

Use TemplateStyles

Currently this module relies on CSS classes defined in MediaWiki:Common.css. While this is efficient considering the English Wikipedia alone, it leads to missing styles when people copy-and-paste the module to other wikis, without copying the styles with it (either because they don’t know about it, or because they don’t have the right to edit Common.css on the target wiki). Switching to TemplateStyles would resolve this issue (if the module containing the <templatestyles> tag is copied, but the TemplateStyles subpage isn’t, instead of silently not having styles, an error message appears, so the user is aware of the problem), makes the connection between the Lua and the CSS code stronger, and makes it possible for any administrator to fix eventual issues in the CSS code (instead of only interface administrators), with the possibility of lifting the protection even further (e.g. allowing template editors) as needed and considered appropriate. It also makes possible to use sandbox pages, so the module sandbox can load the TemplateStyles sandbox and thus CSS changes can be tested just like Lua changes. Thoughts? —Tacsipacsi (talk) 19:10, 30 May 2020 (UTC)

Just to add how I became aware the issue: multilingual wikis like MediaWiki.org have one more issue with the Common.css-based solution: Common.css styles are automatically modified by ResourceLoader (swapping “right” and “left”) based on user language—and this had to be disabled to present English pages correctly when the reader has e.g. Hebrew interface language—, while TemplateStyles uses page language. The Lua banner on mw:Template:Documentation/ar currently looks awful (floated to the wrong side, the Lua logo has margin on the wrong side etc.), which could be fixed by using TemplateStyles and not disabling the swapping functionality. —Tacsipacsi (talk) 19:15, 30 May 2020 (UTC)

Talk should not be hidden in small boxes

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

The behavior that using a small box hides the talk link is pretty unintuitive, especially given the convention that many problem boxes (say, {{disputed section}}) are supposed to come with a talk link for discussion of a fix. Please perform the following edits:

Replace if (self.talk or self.fix) and not self.isSmall then with if (self.talk or self.fix) then.

Replace the block of if ... end starting with if talkTitle and talkTitle.exists then with the following:

			if talkTitle and talkTitle.exists then
                local talkText
                if self.isSmall then
                    local talkLink = talkArgIsTalkPage and talk or (talkTitle.prefixedText .. '#' .. talk)
                    talkText = string.format('([[%s|talk]])', talkLink)
                else
                    talkText = 'Relevant discussion may be found on'
                    if talkArgIsTalkPage then
                        talkText = string.format(
                            '%s [[%s|%s]].',
                            talkText,
                            talk,
                            talkTitle.prefixedText
                        )
                    else
                        talkText = string.format(
                            '%s the [[%s#%s|talk page]].',
                            talkText,
                            talkTitle.prefixedText,
                            talk
                        )
                    end
                end
				self.talk = talkText
			end

The result should be that a small version of the talk page is generated as a single parenthesized link. Feel free to change it if you feel that's not the best presentation.--Artoria 2e5 🌉 05:28, 15 May 2020 (UTC)

Not done: this will need some discussion. Please sandbox your changes and test them fully - see WP:TESTCASES. Then I suggest starting a discussion at Template talk:Mbox to see what others think — Martin (MSGJ · talk) 08:50, 20 May 2020 (UTC)

@Artoria2e5:, can you sandbox this? Mathglot (talk) 02:04, 20 July 2020 (UTC)

@Mathglot:, I put the stuff in Module:Message box/sandbox, but for some reason the test at Template:Ambox/testcases and Module talk:Message box/testcases aren't updating even after a purge. What am I doing wrong again... --Artoria 2e5 🌉 06:24, 20 July 2020 (UTC)

@Artoria2e5:, thanks for getting back so quickly. I've only dealt with Template sandboxes, not Module ones, and I don't want to steer you wrong. Maybe someone here can help: User:MSGJ? Mathglot (talk) 06:39, 20 July 2020 (UTC)

@Artoria2e5: I see “(talk)” links at both Template:Ambox/testcases#talk=talk small=left text=text and Module talk:Message box/testcases#talk=talk small=left text=text. Isn’t this the difference you wanted to see? —Tacsipacsi (talk) 10:48, 20 July 2020 (UTC)

@Tacsipacsi: Yes! I must be getting confused by the different images. The config that specifies these seem to be leftover from some UI change test. The "fix" is also there for small=left, so I think I am ready to reopen this request. --Artoria 2e5 🌉 11:15, 20 July 2020 (UTC)

Administrator note: did you post a message at a more watched paged than this? (I suggested Template talk:Mbox above.) If not, I am willing to make the change as it seems low impact, but on the basis that it may be reverted on request. Can I just confirm if any of the changes at Module:Message box/configuration/sandbox are related to this request? — Martin (MSGJ · talk) 14:29, 2 August 2020 (UTC)

@Artoria2e5: in case you miss this — Martin (MSGJ · talk) 14:38, 2 August 2020 (UTC)

@MSGJ: thanks! No, the configuration stuff is not involved in this. It looks like someone's attempt at using SVG icons. --Artoria 2e5 🌉 13:35, 3 August 2020 (UTC)

Done — Martin (MSGJ · talk) 15:49, 3 August 2020 (UTC)

Site-local configuration source for sisters importing from here

On English Wikisource we have a couple of extra namespaces (Page: and Index:, provided by Extension:ProofreadPage), and so have created a new "pmbox" message box. And on re-sync'ing changes from enwp recently we ended up overwriting the configuration for this message box. (we also caused other issues that we're still trying to track down, but that's to be expected for this type of deployment strategy)

In order to avoid that particular problem in future it would be nice if this module supported a Module:Message box/siteconfig configuration module that, when it exists, is loaded and merged with the data from Module:Message box/configuration. Bonus feature: letting site config override the standard (upstream) config in case there's a need to override something rather than just add to it. That way we can both maintain the "upstream" configuration through periodic imports from enwp, and have additional configuration that is enWS-specific, without having to re-merge our local changes on each import.

One of the reasons we import from enWP is that we (like many of the smaller projects) have very limited technical resources, so remembering and understanding the need to do this integration on each import, much less doing it correctly, is a relatively tall order. Having explicit support for site-local configuration in the upstream module would make this a lot easier for us.

PS. I'd offer to mock this up in the sandbox for your consideration, but this module is being a bit too clever (with the overridden __index method and dynamically generated function lookup table) for my limited Lua-fu. My assessment is that the proposed functionality shouldn't introduce excessive complexity or an unreasonable maintenance burden or performance hit here, but, again, the code is a little over the level of my Lua skills so I may be missing gaping pitfalls.

PPS. TemplateStyles, as requested above, would also be of help for this, for similar reasons.

PPPS. Come to think of it, it may be that support for site-local configuration could be beneficially added to mw.loadData() to make supporting this kind of thing "free" for simple cases (probably not this one, since I don't think you can generalise the merging for arbitrarily complex datastructures, but possibly some common cases with simpler configuration needs). If anybody has ideas about this I would appreciate thoughts before I (at some unspecified point in the future) try to write that up for Phabricator. --Xover (talk) 09:46, 21 August 2020 (UTC)

Talk location

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? Debresser (talk) 00:47, 15 December 2020 (UTC)

Since there have not been any reactions here, I have posted about this at Template_talk:Ambox#Talk_location as well, which may be the better place to discuss this. So I propose that future reactions should go there. Debresser (talk) 12:57, 16 December 2020 (UTC)

Edit request

The "Submit an edit request" button links to Wikipedia:Main Page/Errors instead of creating an edit request, so my apologies for any errant formatting here.

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

Please update the module with the two changes of "small" to "span" shown in this diff. Note that the sandbox should not be copied in its entirety, since it has two other differences that I did not insert.

The change fixes a MOS:SMALLFONT accessibility error discussed at the ambox talk page.

The fix is demonstrated in this test case. – Jonesey95 (talk) 14:38, 3 June 2021 (UTC)

Done Izno (talk) 18:51, 6 June 2021 (UTC)

Fully-protected edit request on 27 June 2021

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Having weighed the arguments I am not convinced that the case to perform the edit has been made.It is a case of want vs need. If need had been demonstrated then I would be having a different set of consideratiions. Where need is not demonstrated there is no argument to make the change. This is a discussion between two main protagonists. There can be no consensus demonstrated by such a closed discussion. My conclusion is No consensus, status quo obtains, edit request declined. If arguments of need can be put forward in the future a new discussion should be held. Fiddle^Timtrent Faddle^Talk to me 18:50, 13 July 2021 (UTC)

Hello,

In Module:Message box/configuration, after line 201, please can someone add the following two lines:

smallParam                  = 'left',
smallClass                  = 'mbox-small-left',

This is to make it possible to have a small left-aligned ombox template. Regards, DesertPipeline (talk) 02:24, 27 June 2021 (UTC)

I should probably test this first actually. Commenting out the edit request template for now. DesertPipeline (talk) 02:46, 27 June 2021 (UTC)

I'm a little lost now. It seems that with the mbox-small-left class, it's no longer possible to have the right-aligned message box with non-article boxes. How can this be fixed? See Template:Tmbox/testcases#small=left (this one doesn't work right), Template:Mbox/testcases#left-aligned_mbox (this one does, but maybe it won't be able to show on the right for the namespaces where it should), Template:Ombox/testcases#small=left_text=text (works), and Template:Ombox/testcases#type=speedy_small=yes_text=text (the sandbox version is in the middle like a normal box rather than right-aligned and small). DesertPipeline (talk) 03:09, 27 June 2021 (UTC)

What DesertPipeline (talk · contribs) fails to mention is that this is in relation to Template talk:Ambox#Why is ambox the only message box which the "small" parameter works with?, where no valid use case has been offered. --Redrose64 🌹 (talk) 08:33, 27 June 2021 (UTC)

User:RedRose64: My use case is as demonstrated on that talk page – being able to have a small left-aligned message box without having to resort to ambox outside of article-space. Is that insufficient? Please advise. Regards, DesertPipeline (talk) 08:48, 27 June 2021 (UTC)

User:Redrose64: Pinging again as I capitalised your username wrong the first time. DesertPipeline (talk) 08:49, 27 June 2021 (UTC)

Addendum: I'll try to expand on my rationale. It would be nice to have small left-aligned boxes for use outside of mainspace, because they're less clutter on a page, and sometimes you don't need a big centred box. Since the other boxes only do small right-aligned, they don't really work for a situation where you need something that should be noticed before text below the box. It's a more noticeable 'hatnote' for something. DesertPipeline (talk) 09:26, 27 June 2021 (UTC)

OK, but that's still a general "this would be nice to have" suggestion. What is the specific case that you would use this for? That is, which page is the box needed on, and why would existing methods be unsuitable for that particular page? I'm sorry, but it is a fundamental principle of software development that you don't make a change without being able to justify it. First, establish the need for the change; demonstrate that the change would be beneficial and will not harm existing uses. As it is often stated: if it ain't broke, don't fix it. --Redrose64 🌹 (talk) 19:59, 27 June 2021 (UTC)

User:Redrose64: As long as whatever's preventing the right-aligned box from working with this gets fixed, it won't harm existing users. In my case, I would use it to request being pinged at the top of sections I start; I'm sure there are other uses. As I said, sometimes you don't need a big centred box for a message, but you still want it inside a message box. That would be what a left-aligned box would be for, as in article-space. Otherwise anyone who wants one has to use an article-space box for it.

Also, unless someone explicitly adds "small=left", it's not going to affect them (as the box would appear as it normally does without). "small=yes" would have to remain as it is (appearing right-aligned).

I don't really think this is a controversial change though. If you think it's a controversial change, please can you explain why? Thanks, DesertPipeline (talk) 03:48, 28 June 2021 (UTC)

You still have not stated where you need to use this. If you persist on being evasive, I shall shut down both discussions. --Redrose64 🌹 (talk) 19:38, 28 June 2021 (UTC)

User:Redrose64: I don't understand. I can't tell you where I need to use this, other than any non-article page where I might want to leave a message box smaller than a regular one, left-aligned and possibly width-variable. Again, maybe my most common usage will be on talk pages where I put a request to ping me at the top of a section I started. If you need more specific information than that, I can't provide it, because this is a request that I think would be generally helpful. In your opinion, is this change large enough that it needs a more specific rationale than that? I thought it was quite a small change myself. DesertPipeline (talk) 04:06, 29 June 2021 (UTC)

Essentially then, you're saying "I want this to be done because I want to have it", and not "I think that this should be done because it would be of great use at Talk:Foobar, on which the existing tmbox template is unable to (fill in deficiency here)". -Redrose64 🌹 (talk) 12:26, 29 June 2021 (UTC)

User:Redrose64: The deficiency is that the other message boxes can't do what ambox can do. I requested it because I have a use for a left-aligned message box on pages which aren't articles, and I believe that it's an uncontroversial change, because it's making the other message boxes capable of displaying in a way that currently only ambox can.

Small, left-aligned boxes are useful because you don't always need a big centred message box for something, and a right-aligned message box is less noticeable, so more useful for cases where the information isn't that important (for instance, the "this edit request has been answered" box). The regular message box is good for important information, and a left-aligned box is good for slightly less important information, or for when you want to take up less page space with a notice. DesertPipeline (talk) 13:45, 29 June 2021 (UTC)

Nope. Still reads like a "nice to have", with no specifics. --Redrose64 🌹 (talk) 20:55, 30 June 2021 (UTC)

User:Redrose64: Do you have any objections to my requested change other than this? DesertPipeline (talk) 03:20, 1 July 2021 (UTC)

Yes. It's a change with no demonstrable benefit. --Redrose64 🌹 (talk) 19:15, 1 July 2021 (UTC)

User:Redrose64: The benefit is that the other message box templates can then do what ambox can do; then there are more options when it comes to using message box templates. If this were not necessary, why does ambox have such a feature? Also, please consider that this change is not harmful, as long as the change is tested first to ensure it introduces no bugs. You may be against it, but do you consider it to be a bad change, or simply an unnecessary one? DesertPipeline (talk) 02:38, 2 July 2021 (UTC)

Both. It's bad because it will put thousands of pages into the job queue for no apparent benefit, and its unnecessary because you have not shown any necessity for it.

I've said it before, and shall say it again: Before making any change that will affect more than one page, you should demonstrate that there is a need for that change. --Redrose64 🌹 (talk) 08:03, 2 July 2021 (UTC)

User:Redrose64: Why is my reason for wanting this change insufficient? DesertPipeline (talk) 08:15, 2 July 2021 (UTC)

I'm sorry to have to say this, but "I want" is not the same as "I need". You have not yet shown any need. I am now going to request independent closure. --Redrose64 🌹 (talk) 08:45, 2 July 2021 (UTC)

User:Redrose64: I obviously don't "need" it; I'm not going to die if this change isn't made. However, I believe it to be a useful change. You say that it puts thousands of pages in the job queue after changing it – but isn't that worrying about performance? DesertPipeline (talk) 11:17, 2 July 2021 (UTC)

I would like to see a consensus on a particular template talk page that the small style is desirable for that template, before we think about adding it here. Consistency of message boxes is very important and we should not be adding new styles unless there is a demonstrated need. — Martin (MSGJ · talk) 12:06, 13 July 2021 (UTC)

User:MSGJ: Would you say it counts as a new style even though it's a style that ambox already has, though? DesertPipeline (talk) 12:17, 13 July 2021 (UTC)

I still don't know what decides whether a left-aligned or right-aligned message box is used though. I've looked through this module's code and also the configuration module, and "mbox-small-left" doesn't even seem to be defined. DesertPipeline (talk) 14:10, 13 July 2021 (UTC)

If you don't know what it does, don't ask for it to be added. --Redrose64 🌹 (talk) 16:48, 13 July 2021 (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.

Protected edit request on 2 March 2022

This edit request to Module:Message box/configuration has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

removalNotice               = '[[Help:Maintenance template removal|Learn how and when to remove this template message]]'

->

removalNotice               = '<small>[[Help:Maintenance template removal|Learn how and when to remove this template message]]</small>'

(make it smaller) ProcrastinatingReader (talk) 11:42, 2 March 2022 (UTC)

Can we make it disappear completely :))) — Martin (MSGJ · talk) 14:04, 2 March 2022 (UTC)

I would support that even more. ProcrastinatingReader (talk) 14:19, 2 March 2022 (UTC)

Done @ProcrastinatingReader and MSGJ: I'm pretty sure that came in via a larger discussion, so it will need another to delete it. — xaosflux ^Talk 15:05, 2 March 2022 (UTC)

@Xaosflux: can we reword it to "(removing this message)" or something without VP discussion? Still comes across as quite prominent to me, and unnecessarily lengthy. AFAICS the larger discussion only agreed on the general idea that something should about removals should be added, not on any specific details or text. ProcrastinatingReader (talk) 16:54, 2 March 2022 (UTC)

@ProcrastinatingReader for a shortening/rewording - I don't think a RfC is needed - perhaps just propose exactly what you want it changed to here, and advertise this a bit. (At perhaps: Template talk:Ambox, Template talk:Mbox, and Wikipedia talk:WikiProject Templates). Silence after a reasonable period (a week maybe) should be sufficient for a BOLD update. — xaosflux ^Talk 17:07, 2 March 2022 (UTC)

Lua error when certain maintenance templates used from ExpandTemplates with no context title

A Lua error is generated under certain conditions when attempting to expand certain maintenance templates from Special:ExpandTemplates:

Lua error in Module:Message_box at line 267: attempt to index field 'talk' (a nil value).

I'm still trying to work out exactly what the minimal conditions are, but there seems to be an interaction going on somewhere among {{Ambox}}, this Module, and Special:ExpandTemplates that causes the Lua error when certain templates are expanded from ExpandTemplates without a context title. It seems to occur more when certain Ambox-supported parameters, in particular |talk=, are available in Ambox but not used in the given template. Please bear with me, it's hard to identify exactly where the locus of this problem lies, but these examples will demonstrate the inconsistent behavior. First, the Lua error can be seen thus:

go to ExpandTemplates, leave context title empty, set wikitext to {{improve lead|talk=foo}}. Note: this template ~~does not~~ does support param 'talk'. update: looking for new example; Mathglot (talk) 22:07, 29 March 2022 (UTC)
or, go to Expandtemplates, context title empty, set wikitext to {{POV lead}}. Note: this template supports param 'talk'.

Note that in order for this error to be generated, from what I know so far:

Either: the param 'talk' is not supported by the Template, as in template {{improve lead}}, AND both of these are true:
1. missing context title in Special:ExpandTemplates
2. the param must be 'talk' (No error encountered with: |discuss=foo, |reason=bar, or |aardvark=cute)
Or: the param 'talk' *is* supported by the Template, as in {{POV lead}}, AND:
1. missing context title in Special:ExpandTemplates
- Examples: Lua error occurs with any of: {{POV lead}}, {{POV lead|talk=foo}}, {{POV lead|reason=bar}}, {{POV|aardvark=foo}}

In all cases where the Lua error appears, adding any context title at all, whether the title exists or not, whether it is a valid pagename or not (such as ;!#), makes the Lua error go away.

Apologies for the vagueness in this report; I'm still trying to figure out what's going on. As far as the proper venue for this discussion, Module:Message_box is identified when the error occurs, so I placed it here, though I realize the actual error may be upstream. Please move the discussion if it fits better somewhere else, and leave a link. The inspiration for this report is the unexpected errors I am encountering in ExpandTemplates, which is interfering with my ability to confidently test a change I made to Template:Lead missing. Thanks, Mathglot (talk) 21:41, 29 March 2022 (UTC)

I found what may be another necessary condition: to generate the error, the banner must attempt to emit the text, 'may be found on the talk page' where 'talk page' is wikilinked. Try ExpandTemplates containing the following:

a {{Lead extra info}}
b {{POV lead}}
c {{improve lead}}{{br}}
----
d {{Lead extra info|talk=foo}}
e {{POV lead|talk=foo}}
f {{improve lead|talk=foo}}

and contrast the results both with, and without a context title. Note that template {{Lead extra info}} does not emit the talk page link in the banner, and I haven't seen it generate the Lua error. Mathglot (talk) 22:17, 29 March 2022 (UTC)

What's going on is fairly clear. The line 267 the error points to is

				talkTitle = getTitleObject(
					self.title.text,
					mw.site.namespaces[self.title.namespace].talk.id
				)

The access of "talk" in there is more specifically part of mw.site.namespaces[self.title.namespace].talk.id. If you paste {{FULLPAGENAME}} into Special:ExpandTemplates you see that when no context title is specified that the title is "Special:ExpandTemplates", and since the Special namespace has no corresponding talk namespace mw.site.namespaces[-1].talk or mw.site.namespaces["Special"].talk is indeed nil. Anomie ⚔ 12:17, 31 March 2022 (UTC)

Mobile view

Could mbox be made visible for mobile users, please? fgnievinski (talk) 06:49, 10 May 2022 (UTC)

fgnievinski This is done by WMF, not by us. phab:T257394 is relevant. Izno (talk) 20:35, 24 May 2022 (UTC)

Removing image from the list of allowable demospaces

Over 13 years ago, in December 2008, the Image: namespace was renamed to File:. This Module however still support image as a demospace value, for backwards compatibility. However, there are only a few cases left which still used this value, and I recently cleared out all the ones I could find, which should mean its now unused. I have a sandboxed change ready which adds a maintenance check for |demospace = image just to be sure, but I think that after letting that run for a few weeks it should be safe to remove this code after 13 years. -- Asartea ^Talk ^| ^Contribs 19:39, 24 May 2022 (UTC)

This should not be done as long as the MediaWiki software still treats Image: as exactly equivalent to File:. --Redrose64 🌹 (talk) 20:34, 25 May 2022 (UTC)

Protected edit request on 3 August 2022

This edit request to Module:Message box/cmbox.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Can you change the .cmbox-protection background color to something that is not THAT "disgusting"? 187.175.48.172 (talk) 19:41, 3 August 2022 (UTC)

Not done this is not a ready-to-go request, and would need more discussion. The protection coloring scheme is fairly consistent across many templates. — xaosflux ^Talk 13:27, 5 August 2022 (UTC)

Moreover, these have had long consensus as they currently are. If you would like to change this color, you will need a broad consensus. Izno (talk) 23:03, 5 August 2022 (UTC)

mbox is now TemplateStyled only

Please report any issues you see at MediaWiki talk:Common.css#mbox is now TemplateStyled only. Thanks! Izno (talk) 18:04, 17 August 2022 (UTC)

Proposed change to removalNotice

Re: Module:Message box/configuration

Propose we change: removalNotice = 'Learn how and when to remove this template message'

To: removalNotice = 'Learn when to remove this message'

Or: removalNotice = 'when to remove this message?'

Second proposal: remove it entirely, and do it like frWiki, by adding a blue (i) icon in the top-right of templates that links to the template (and documentation). See for example fr:Modèle:Promotionnel. DFlhb (talk) 09:26, 3 June 2023 (UTC)

Edit request: use File:Information icon4.svg instead of File:Imbox notice.png

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

Request: replace Imbox notice.png with Information icon4.svg in Module:Message box so the main module is consistent with Module:Message box/configuration. —CalendulaAsteraceae (talk • contribs) 06:15, 29 August 2023 (UTC)

Done * Pppery * _{it has begun...} 14:30, 2 September 2023 (UTC)

FYI: watch for images needing the description page link for licensing and attribution

For the most part we can only use |link= to suppress the link to the file description page for images that are public domain or CC-0. Most other licenses, including the LGPL used on File:Cscr-featured.svg, need the link to the file description page for notice of the license and/or attribution of the author. I've updated the module to make this possible and the configuration to do so for that image. I think all the rest in the current configuration are ok, unless I missed one they're all either released into the public domain or are PD-ineligible. Anomie ⚔ 23:02, 2 September 2023 (UTC)

Edit request for Module:Message box/configuration

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

Description of suggested change: Change 'Imbox license.png' -- @todo We need an SVG version of this to 'Imbox-license.svg' because there's an SVG now. —CalendulaAsteraceae (talk • contribs) 03:28, 31 August 2023 (UTC)

Not done That file would need to be protected on Commons and or have a local copy uploaded before being deployed to such a widely-used module. I also don't see the point. * Pppery * _{it has begun...} 14:30, 2 September 2023 (UTC)

@Pppery: File:Imbox-license.svg is protected on Commons now; thanks for bringing that up! The point is that SVGs look sharper and scale up better than PNGs, and the rest of the images in this module have been SVGs since 2014.

PNG
SVG

Also, in light of @Anomie's comment below, I'd like to amend my request to ask that

			license = {
				class = 'imbox-license licensetpl',
				image = 'Imbox license.png' -- @todo We need an SVG version of this
			},

be changed to

			license = {
				class = 'imbox-license licensetpl',
				image = 'Imbox-license.svg',
				imageNeedsLink = true
			},

—CalendulaAsteraceae (talk • contribs) 02:16, 7 September 2023 (UTC)

Those two images don't look meaningfully different to me, and it seems unlikely this specific icon will need to be scaled up. Nevertheless, my task as FPER-responder (and the only active one right now) isn't to implement only changes I agree with, so I'll do this some time tomorrow assuming there are no further comments. In the mean time, though, it would be nice if you could get ReneeWrites to agree to license their SVG into the public domain so we don't have to include a link, especially since they didn't add one when they updated the module on Commons. * Pppery * _{it has begun...} 02:24, 7 September 2023 (UTC)

@Pppery: The image is currently protected on Commons, so I'll ask an admin if they can change the license to a public domain one for me. ReneeWrites (talk) 08:26, 7 September 2023 (UTC)

@Pppery: It has a PD license now! (Thank you @The Squirrel Conspiracy!) ReneeWrites (talk) 09:41, 8 September 2023 (UTC)

Done (and yes, I said I would do it yesterday - I got sidetracked). * Pppery * _{it has begun...} 14:10, 8 September 2023 (UTC)

Thank you! —CalendulaAsteraceae (talk • contribs) 07:03, 9 September 2023 (UTC)

Protected edit request on 15 October 2023

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

8.19.154.140 (talk) 04:09, 15 October 2023 (UTC)

I would like to edit because I seen some mistakes in the main page

Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. Kind regards~~ αvírαm|(tαlk) 04:32, 15 October 2023 (UTC)

Edit request 19 November 2023

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

Description of suggested change: Shorten the removalnotice at Module:Message box/configuration as it is currently longer than half of the full-width banner. Diff:

CactiStaccingCrane (talk) 02:57, 19 November 2023 (UTC)

Not done The current wording was the result of a major discussion. Replacing that with a general "help" would in practice overturn that discussion and hence would require a similar level of consensus to it, not a mere edit request. * Pppery * _{it has begun...} 05:20, 19 November 2023 (UTC)

This discussion is about adding a link to Help:Maintenance template removal, not about the wording of the link itself. I do agree that my suggestion is a bit vague so here's my new edit request:

CactiStaccingCrane (talk) 02:57, 19 November 2023 (UTC)

I would say that discussion not only included a link to the help page, but introduced wording into the template referencing the process, which "help" is so vague as to not do. But "template removal help" works for me, so

Done that. * Pppery * _{it has begun...} 16:45, 19 November 2023 (UTC)

@Pppery and CactiStaccingCrane: Hello! I am not thrilled with the new name. Clicking on "learn how and when to remove this template message" is how I got started editing Wikipedia, so the message has a special place in my heart. I feel the new version is less "inviting" than the old, if that makes sense. Would you (plural) be open to "learn about removing this message"? Best, House Blaster^talk 04:26, 21 November 2023 (UTC)

I'm fine with it, but I was fine the the original too so that doesn't mean much. * Pppery * _{it has begun...} 04:27, 21 November 2023 (UTC)

@HouseBlaster hard agree here, I don't think the new version makes any sense at all and I don't see why "longer than half of the full-width banner" is a problem that needs fixing. Strongly prefer the original wording. -- asilvering (talk) 16:43, 23 November 2023 (UTC)

I have reverted my edit due to multiple objections here. * Pppery * _{it has begun...} 17:54, 23 November 2023 (UTC)

Edit request 23 November 2023

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

On Module:Message box/configuration, after line 152, please add

		license-related = {
				class = 'imbox-license',
				image = 'Imbox-license.svg'
			},

.

Reasoning: Some templates, like {{Insignia}}, use the "license" type of imbox. But this produces a licensetpl class, which confuses whatever MediaWiki thing populates Category:Files with no machine-readable license. Adding this would allow those to be converted to an identical-looking type "license-related" without the class, depopulating much of the category.

Best, — Mdaniels5757 (talk • contribs) 20:47, 23 November 2023 (UTC)

Done * Pppery * _{it has begun...} 02:42, 24 November 2023 (UTC)

Edit request to alter removalNotice text

This edit request to Module:Message box/configuration has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

The removal notice in message boxes refers to the displayed banner as a "template message". That is overly described; nobody cares how it was produced (if they did, maybe we should call it a "module message", or a "template-driven, module-implemented message"); they only care what it is you want to remove (and how). Suggested improvement:

To me, it's a "banner", not a "message", so I'd prefer the former word, but I wouldn't object to just "message" without the "template" part. Among other things, the shorter version will cause a fraction of banners to have one fewer line at certain page widths. Thanks, Mathglot (talk) 22:26, 27 April 2024 (UTC)

Done * Pppery * _{it has begun...} 03:25, 29 April 2024 (UTC)

Protected edit request on 4 May 2024

This edit request to Module:Message box/ombox.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

This ombox defines a backgroundcolor, without defining a text color, which is problematic in the new darkmod. I suggest we add color: #202122 to the first styling block to. —TheDJ (talk • contribs) 15:58, 4 May 2024 (UTC)

Done — Martin (MSGJ · talk) 20:54, 6 May 2024 (UTC)

Ick, dark grey instead of ordinary black. I suppose that matches the same done in Vector, but it mismatches other skins. Anomie ⚔ 11:50, 7 May 2024 (UTC)

Yes, this is one reason I've been leery of fixing dark mode by adding color: definite_color... Izno (talk) 04:10, 21 May 2024 (UTC)

Edit request 8 May 2024

This edit request to Module:Message box/ombox.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Description of suggested change: Add CSS styling for night mode to the ombox styles.css. Diff:

Andumé (talk) 23:45, 8 May 2024 (UTC)

Another option with a darker/higher contrast/more consistent color scheme would be this:

Andumé (talk) 17:37, 11 May 2024 (UTC)

Not done: These diffs introduce duplicate styles and more color styles than are necessary to deal with the issue of dark mode. Thanks for throwing something up though, I will take a look. Izno (talk) 04:06, 21 May 2024 (UTC)

@I Am Andumé For the first, you copy-pasted the full .ombox definition in the context of the color CSS, which is surely not intended. For the second, you typoed the prefers-color-scheme dark selector (it should be -os, not -night), made multiple separate blocks for the prefers-color scheme (perhaps to show that you were consistent between -dark and -os settings, IDK), and more concerningly you strayed to changing the background rather than changing just the border. We should do something which matches the earlier rules in what is being set, which for most of these cases is just the border. Izno (talk) 04:22, 21 May 2024 (UTC)

Actually taking a look what happens when the background is dark, I don't think we need to change the border colors at all and can leave those the same as the base colors. That simplifies maintenance tremendously. We need to pick a good dark color for the typical background, as well as the speedy color. Izno (talk) 04:37, 21 May 2024 (UTC)

I put those in the official sandbox and loaded that so now you can see them on Template:Ombox/testcases#name=_text=text. Izno (talk) 04:55, 21 May 2024 (UTC)

@Izno:

Thanks for taking a look at my request. Here are a few things I'd like to mention:

The reason I copy-pasted the full .ombox definition, instead of just the styling that needed to be different in night mode was because I was afraid the other CSS would not be applied to the night mode version of the template if I omitted it.
That was a typo, yes.
I made separate block for the prefers-color-scheme as I was not yet aware it was possible to combine it all into one.
Changing the background color was necessary as otherwise it would have been very bright (as you seem to have noticed). Also, without either defining color or changing background color, the text would not have been readable.

Anyways, I wrote this CSS quite a while ago, so I was very inexperienced at the time, which explains a lot of the mistakes I made. Andumé (talk) 05:07, 21 May 2024 (UTC)

No worries. Yes, it was necessary to change the background, but only for the broad .ombox and for the more narrow .ombox-speedy. You included background colors elsewhere. Which can reasonably be explained by your inexperience with CSS as you explained. Izno (talk) 05:16, 21 May 2024 (UTC)

@Izno: iirc, the addition of the other background colors was also because I first worked on the cmbox CSS, and then reused much of the styling for ombox. Andumé (talk) 05:36, 21 May 2024 (UTC)

That would explain the blue! Izno (talk) 05:54, 21 May 2024 (UTC)

Protected edit request on 14 June 2024

This edit request to Module:Message box/ombox.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please add:

/** T367463 */
body.skin--responsive table.ombox img {
	max-width: none !important;
}

to Module:Message box/ombox.css as a workaround for phab:T367463, similar to {{tmbox}}'s Special:Diff/1228936760. I've applied the change to the sandbox (Special:Diff/1228972046/1229011205), but looking at testcases won't be helpful, because the sandbox template styles affect both live and sandbox versions of the template. Instead, compare Template:Wikibreak/testcases (uses live template styles as of Special:Diff/1229011841) and Template:Sockpuppet/testcases (uses sandbox styles as of Special:Diff/1229011265). See also Wikipedia:Village pump (technical)#Ombox images sometimes not showing. —⁠andrybak (talk) 10:41, 14 June 2024 (UTC)

Ping for awareness: User:Jon (WMF). —⁠andrybak (talk) 13:08, 14 June 2024 (UTC)

Done — Preceding unsigned comment added by Jon (WMF) (talk • contribs) 15:59, 14 June 2024 (UTC)

Edit request 28 June 2024

This edit request to Module:Message box/fmbox.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Description of suggested change: I propose changing transparent to #FFFFFF (white) on Module:Message box/fmbox.css because some edit filters use white backgrounds for friendly or standard warning messages. If transparent was used here, then it would not appear white, rather light-red seeping thorough the warning message (this shows a warning box covering the edit filter warning or disallow message). The same also goes for disallow messages that use | friendly = yes.

Diff:

Anybody can comment about the proposed change I suggested, thank you. Codename Noreste 🤔 Talk 19:10, 28 June 2024 (UTC)

Two things: fmbox should not be embedded in other (fm)boxes, making this change unnecessary here, and any change along this dimension should be sensitive to dark mode, and that isn't. Izno Public (talk) 12:47, 8 July 2024 (UTC)

Urgent: Please fix this template for printed content Module:Message box/sandbox/ombox.css.

Firstly, apologies for writing in English if this is not your first language (this is an automated message).

This template has been detected as one of 436 pages using styles that break the page when printed when the user is using dark mode. The fix is very straightforward - all your styles relating to dark mode must be scoped to. Since there is a high risk of this templates being copied to other wikis it is important this notice is acted on ASAP.

To fix this:

Update `@media (prefers-color-scheme: dark` to `@media screen and (prefers-color-scheme: dark`
Wrap any styles relating to `html.skin-theme-clientpref-night` in `@media screen`

If this message has not been acted on in 7 days, this will be fixed by an automated script. Thank you for your help fixing this important issue.

For any questions feel free to ask them at phab:T369874.

Jon (WMF) (talk) 18:22, 2 August 2024 (UTC) on behalf of the web team.

Urgent: Please fix this template for printed content Module:Message box/sandbox/ambox.css.

Firstly, apologies for writing in English if this is not your first language (this is an automated message).

This template has been detected as one of 436 pages using styles that break the page when printed when the user is using dark mode. The fix is very straightforward - all your styles relating to dark mode must be scoped to. Since there is a high risk of this templates being copied to other wikis it is important this notice is acted on ASAP.

To fix this:

Update `@media (prefers-color-scheme: dark` to `@media screen and (prefers-color-scheme: dark`
Wrap any styles relating to `html.skin-theme-clientpref-night` in `@media screen`

If this message has not been acted on in 7 days, this will be fixed by an automated script. Thank you for your help fixing this important issue.

For any questions feel free to ask them at phab:T369874.

Jon (WMF) (talk) 18:22, 2 August 2024 (UTC) on behalf of the web team.

Protected edit request on 25 June 2024

This edit request to Module:Message box/fmbox.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Change fmbox-warning background-color to #300 in night mode for consistency with other mboxes.

Diff:

Andumé (talk) 04:52, 25 June 2024 (UTC)

No opinion on the change request, but presumably if you want to change the bg color, then you'd want to change the comment to match? Mathglot (talk) 18:09, 25 June 2024 (UTC)

That would probably be a good idea, although those comments are often inaccurate anyway, especially on Module:Message box/cmbox.css. Andumé (talk) 21:30, 25 June 2024 (UTC)

Shouldn't be inaccurate? The only one I can think of is the blue of one of the specific cmboxes. Izno Public (talk) 06:48, 8 July 2024 (UTC)

@Izno: The specific inaccuracy I was thinking of was the cmbox.css's night mode styles refer to #300 as "pink", although that is not the only one. Andumé (talk) 20:29, 14 July 2024 (UTC)

And in fact cmbox makes no claim about similar hue/saturation that I can see?? Please ensure you're being factual. Izno Public (talk) 06:50, 8 July 2024 (UTC)

The light colors are also not consistent IIRC? Which specific other dark box are you trying to make this consistent with and what is the light color for that box? Izno Public (talk) 06:48, 8 July 2024 (UTC)

What I meant with "consistency" was that cmbox's night mode styles (cmbox being the only standard mbox to use colorful backgrounds afaik), for colored backgrounds, use the same background color as the light mode styles, except with a lightness of 10. Also, cmbox-delete and cmbox-speedy both have the same background in light mode as fmbox-warning, and they use #300 as background-color in night mode. I hope this makes sense. Andumé (talk) 20:41, 14 July 2024 (UTC)

Please don't reactivate the edit request while discussion is ongoing. I'll review this later. Izno (talk) 23:27, 14 July 2024 (UTC)

Done After looking at this and consistency among other templates, 300 is as fine as anything. Probably it would make sense to regularize the cmbox deletion colors and the fmbox warning color to match the deletion colors for all other templates in both light and dark mode, which is currently at fee7e6 for the speedy background and 310402 speedy dark background. And to reconsider that cmbox has colored backgrounds. Izno (talk) 21:58, 3 August 2024 (UTC)