Jump to content

Module talk:Message box/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< Module talk:Message box
This is an old revision of this page, as edited by Lowercase sigmabot III (talk | contribs) at 05:33, 15 May 2020 (Archiving 1 discussion(s) from Module talk:Message box) (bot). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
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)

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

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

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

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

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

@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

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)
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.

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)

(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:

-- 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:
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

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

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:GKFXtalk 22:18, 26 November 2018 (UTC)

  • With icon
    With icon
  • Without icon
    Without icon
  • With generic keyhole
    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:GKFXtalk 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

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)

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)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Module_talk:Message_box/Archive_1&oldid=956764557"